Anda di halaman 1dari 229

UNIVERSIDADE FEDERAL DE P ERNAMBUCO CENTRO DE I NFORMTICA PROGRAMA DE PS-G RADUAO MESTRADO EM CINCIA DA COMPUTAO

Carlos dos Santos Portela

SPIDER-PE: UM FRAMEWORK DE APOIO EXECUO FLEXVEL DE PROCESSOS DE SOFTWARE ADERENTE A MODELOS DE QUALIDADE

RECIFE 2012

ii

Carlos dos Santos Portela

SPIDER-PE: UM FRAMEWORK DE APOIO EXECUO FLEXVEL DE PROCESSOS DE SOFTWARE ADERENTE A MODELOS DE QUALIDADE
Dissertao de Mestrado apresentada como requisito parcial para a obteno do grau de Mestre em Cincia da Computao, pelo Programa de Ps-Graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco. rea de Concentrao: Engenharia de Software Orientador: Prof. Dr. Alexandre Marcos Lins de Vasconcelos Co-Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira

RECIFE 2012

iii

___________________________________________________________________ Portela, Carlos dos Santos Spider-PE: Um Framework de Apoio Execuo Flexvel de Processos de Software aderente a Modelos de Qualidade / Carlos dos Santos Portela; Orientador, Alexandre Marcos Lins de Vasconcelos; Co-Orientador, Sandro Ronaldo Bezerra Oliveira 2012. Dissertao (Mestrado) Universidade Federal de Pernambuco, Centro de Informtica, Programa de Ps-Graduao em Cincia da Computao, Recife, 2012. 1. Engenharia de Software. 2. Processo de Software. I. Vas-

concelos, Alexandre M. L. orientador. Oliveira, Sandro R. B. coorientador. II. Universidade Federal de Pernambuco, Centro de Informtica, Programa de Ps-Graduao em Cincia da Computao. III. Ttulo. ___________________________________________________________________

iv

Carlos dos Santos Portela

SPIDER-PE: UM FRAMEWORK DE APOIO EXECUO FLEXVEL DE PROCESSOS DE SOFTWARE ADERENTE A MODELOS DE QUALIDADE
Dissertao de Mestrado apresentada como requisito parcial para a obteno do grau de Mestre em Cincia da Computao, pelo Programa de Ps-Graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco. BANCA EXAMINADORA Prof. Dr. Alexandre Marcos Lins de Vasconcelos Programa de Ps-Graduao em Cincia da Computao CIn/UFPE Orientador

Prof. Dr. Simone Cristiane dos Santos Lima Programa de Ps-Graduao em Cincia da Computao CIn/UFPE Membro Interno

Prof. Dr. Cristine Martins Gomes de Gusmo Ncleo de Telessude (NUTES) CSS/UFPE Membro Externo

Data de Aprovao: Recife, ___ / ___ / ______.

Aos meus pais, por continuarem a acreditar e incentivar meus estudos, e a Sandro Oliveira, coordenador do Projeto SPIDER, que, atravs de seu apoio e confiana, permitiu com que a realizao deste trabalho fosse possvel.

vi

AGRADECIMENTOS

Primeiramente, agradeo a Deus por me ensinar a ser paciente quando achava que tudo estava dando errado, por colocar pessoas maravilhosas no meu caminho e por me proporcionar tantas bnos durante este perodo do mestrado. A minha famlia, em especial aos meus pais, que continuam incentivando meus estudos e, mesmo distantes, se fazem presente na minha vida. A tia Amada e a Miguel Pernambuco, que me deram todo apoio possvel quando fui morar em Recife. Agradeo-os imensamente por dividirem, alm do aluguel e despesas, tantos momentos neste curto perodo de tempo. Aos grandes amigos que conheci no CIn/UFPE, que considero a melhor coisa que me aconteceu em Recife-PE. As madrugadas em claro, programando em force.com com nosso scrum master, Josino Rodrigues que nos mantinha acordado com seu capuccino. Andreza Leite, a paraense que conquistou a todos com sua sutil brutalidade, sempre disponibilizava sua casa para as madrugadas de estudos. Wilton Oliveira e sua risada inconfundvel, com quem passava os finais de semana tentando fazer os projetos e sobreviver as disciplinas. Jlio Damasceno, um dos top 3 nerds que j conheci, pelos shows de Rock Band. E a Talitha Huanna, pela sua amizade e por nos permitir conhecer a belssima cidade de Garanhuns. Vocs me mostraram que no devemos medir esforos para atingirmos nossos objetivos. A Sandro Oliveira, por tornar possvel meu retorno ao Projeto SPIDER, por permitir e acreditar que eu pudesse realizar este trabalho. Mais que um orientador, tornou-se um amigo. Igualmente, agradeo a Alexandre Vasconcelos, por aceitar me orientar, dando toda a ateno e apoio necessrio para realizao deste trabalho. Aos membros do Projeto SPIDER, em especial ao meu amigo Wallace Lira, companheiro de consultoria e boxe. E a Maurcio Ronny, meu parceiro de turismo por Curitiba-PR. Muito obrigado pelos conselhos e apoio constante. Vocs me mostraram a importncia e a seriedade com que devemos tratar a pesquisa cientfica.

vii

Aprendi que vai demorar muito para me transformar na pessoa que quero ser, e devo ter pacincia. Mas, aprendi tambm, que posso ir alm dos limites que eu prprio coloquei. Charles Chaplin

viii

RESUMO

Este trabalho tem por objetivo fornecer uma soluo que possa contribuir com a melhoria contnua dos processos de indstrias de software, atravs do apoio adoo do padro SPEM (Software Process Engineering Metamodel) e dos modelos de qualidade MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) e CMMI-DEV (Capability Maturity Model Integration for Development). O SPEM define um conjunto de notaes especficas para apoiar a modelagem de processos de software, enquanto os modelos MR-MPS e CMMI-DEV definem nveis de maturidade e capacidade para a melhoria do processo de software de uma organizao. Primeiramente, realizou-se uma anlise comparativa entre os padres de modelagem SPEM e BPMN, a fim de identificar quais destes possui mais representatividade na modelagem de processos de software. Em seguida, definiu-se a linguagem xSPIDER_ML, que permite executar processos modelados a partir do SPEM. Posteriormente, realizou-se um mapeamento entre o Nvel F do MR-MPS e o Nvel 2 do CMMI-DEV a fim de identificar as recomendaes em comum destes modelos no que diz respeito execuo de processos. Com base no formalismo da linguagem xSPIDER_ML e nas recomendaes dos modelos MR-MPS e CMMI-DEV definiu-se um framework, denominado Spider-PE, que estabelece um fluxo conceitual de atividades genricas para apoiar a execuo de processos. Espera-se que o framework proposto neste trabalho permita com que qualquer organizao desenvolvedora de software possa executar seus processos de forma semi-automatizada e flexvel e de acordo com os principais padres e modelos de qualidade adotados no mercado.

Palavras-chave: Processo de Software, Modelos de Qualidade, Execuo de Processos, Formalismo para Execuo de Processos, Framework de Processo.

ix

ABSTRACT

This study aims to provide a solution to continuous improvement of software processes. It can be achieved through the usage of the SPEM (Software Process Engineering Metamodel) standard and MR-MPS (Reference Model for Software Process improvement) and CMMI-DEV (Capability Maturity Model Integration for Development) software process quality models. SPEM defines a set of notations that support the software process modeling models. Otherwise, the MR-MPS and CMMI-DEV models define maturity and capability levels software process improvement. Firstly, we carried out a comparative analysis of the SPEM and BPMN patterns modeling in order to identify which of these is more representative in the software processes modeling. After this, it was developed the xSPIDER_ML language which allows the enactment of SPEM processes. Subsequently, it was established a mapping between the MR-MPS Level F and CMMI-DEV Level 2 to identify the similarities between these models. This mapping regards the process enactment recommendations presented in these maturity models. Based upon the xSPIDER_ML language formalism and the recommendations of the MR-MPS and CMMI-DEV models it was created Spider-PE, which is a framework to support process enactment. That framework is expected to establish a generic activities flow to support the process enactment. It is expected that the created framework allows any software development organization to enact their processes in a semi-automated and flexible way. It is important that this framework is adherent to the recommendations of the main software process standards and quality models.

Keywords: Software Process, Quality Models, Process Enactment, Formalism for Process Enactment, Process Framework.

SUMRIO

LISTA DE FIGURAS ............................................................................................... XIII LISTA DE QUADROS ............................................................................................. XIV LISTA DE ABREVIATURAS.................................................................................... XV 1 INTRODUO .................................................................................................. 16

1.1 CONTEXTO DO TRABALHO ............................................................................. 17 1.2 MOTIVAO ...................................................................................................... 19 1.3 OBJETIVOS ....................................................................................................... 20 1.3.1 1.3.2 Objetivo Geral ............................................................................................. 20 Objetivos Especficos ................................................................................ 20

1.4 METODOLOGIA DO TRABALHO ..................................................................... 21 1.5 ESTRUTURA DO TRABALHO .......................................................................... 24 2 PROCESSO DE SOFTWARE: DEFINIO, MELHORIA E EXECUO .................................................................................................. 26

2.1 PROCESSOS DE SOFTWARE: UMA VISO GERAL ...................................... 27 2.2 MODELOS DE PROCESSO DE SOFTWARE ................................................... 30 2.3 MELHORIA DO PROCESSO DE SOFTWARE .................................................. 32 2.3.1 2.3.2 O Modelo CMMI-DEV .................................................................................. 34 O Modelo MR-MPS ...................................................................................... 38

2.4 EXECUO DE PROCESSOS DE SOFTWARE ............................................... 42

xi 2.4.1 2.4.2 2.4.3 Contextualizao da Execuo de Processos ......................................... 44 Caracterizao da Execuo de Processos ............................................. 46 Trabalhos Relacionados Execuo de Processos ............................... 49

2.5 CONSIDERAES FINAIS................................................................................ 53 3 A LINGUAGEM DE EXECUO DE PROCESSOS........................................ 54

3.1 ANLISE COMPARATIVA ENTRE O SPEM E O BPMN .................................. 55 3.2 A LINGUAGEM DE MODELAGEM SPIDER_ML .............................................. 57 3.3 A LINGUAGEM DE EXECUO XSPIDER_ML ............................................... 59 3.3.1 3.3.2 Trabalhos Relacionados ............................................................................ 59 Objetivos e Caractersticas da Linguagem xSPIDER_ML ............................................................................................... 62 Componentes da Linguagem xSPIDER_ML ............................................. 64 Estrutura da Linguagem xSPIDER_ML ..................................................... 66 Regras de Execuo da Linguagem xSPIDER_ML .................................. 71

3.3.3 3.3.4 3.3.5

3.4 AVALIAO DA LINGUAGEM XSPIDER_ML .................................................. 74 3.5 CONSIDERAES FINAIS................................................................................ 77 4 O FRAMEWORK DE EXECUO DE PROCESSOS ..................................... 78

4.1 MAPEAMENTO ENTRE O MR-MPS E O CMMI-DEV........................................ 79 4.2 O FRAMEWORK SPIDER-PE ............................................................................ 83 4.2.1 4.2.2 4.2.3 Fases do Framework Spider-PE ................................................................ 84 Atores do Framework Spider-PE ............................................................... 86 Descrio das Atividades do Framework Spider-PE ............................... 88

4.3 AVALIAO DO FRAMEWORK SPIDER-PE ................................................... 94

xii 4.4 DIFERENCIAL DA PROPOSTA......................................................................... 99 4.5 CONSIDERAES FINAIS.............................................................................. 100 5 CONCLUSES............................................................................................... 102

5.1 SUMRIO DO TRABALHO .............................................................................. 102 5.2 ANLISE DOS RESULTADOS ........................................................................ 103 5.3 TRABALHOS FUTUROS ................................................................................. 105 5.3.1 Desenvolvimento da Ferramenta de Execuo de Processos ................................................................................................. 105 Estudo de Caso Real (Aplicao do Framework) .................................. 106 Integrao com o Processo de Avaliao e Melhoria do Processo .............................................................................................. 106

5.3.2 5.3.3

REFERNCIAS....................................................................................................... 107 APNDICE A RELATRIO DE PESQUISA: ANLISE COMPARATIVA ENTRE OS PADRES SPEM E BPMN ............................. 114 APNDICE B ESPECIFICAO TCNICA DA LINGUAGEM DE EXECUO DE PROCESSOS XSPIDER_ML ........................................ 157 APNDICE C DEFINIO DO FRAMEWORK DE EXECUO DE PROCESSOS SPIDER-PE .................................................. 195

xiii

LISTA DE FIGURAS

Figura 1.1 - Metodologia de Pesquisa ....................................................................... 22 Figura 2.1 - Viso Genrica do Processo de Engenharia de Software (Adaptado de OLIVEIRA, 2006)....................................................................................................... 28 Figura 2.2 - Elementos envolvidos na realizao das Atividades do Processo (Adaptado de REIS et al., 2002)................................................................................ 30 Figura 2.3 - Nveis de Maturidade do CMMI-DEV (Adaptado de SEI, 2010) ............. 35 Figura 2.4 - Estrutura de Componentes do CMMI-DEV (Adaptado de SEI, 2010) .... 37 Figura 2.5 - Componentes do Modelo MPS (SOFTEX, 2011b) ................................. 39 Figura 2.6 - Nveis de Maturidade do MR-MPS (Adaptado de SOFTEX, 2011b) ...... 40 Figura 2.7 - Estrutura de Componentes do MR-MPS (SOFTEX, 2011a) .................. 40 Figura 2.8 - Meta-Processo do Ambiente ImPPros (Adaptado de OLIVEIRA, 2007) 45 Figura 3.1 - Estrutura de Pacotes da xSPIDER_ML (PORTELA e GOMES, 2011b) 66 Figura 3.2 - Classes do Pacote xSPIDERML_Core .................................................. 67 Figura 3.3 - Classes do Pacote ProcessParameters ................................................. 69 Figura 3.4 - Classes do Pacote ProjectVariables ...................................................... 70 Figura 3.5 - Classes do Pacote EventTypes ............................................................. 70 Figura 3.6 - Classes do Pacote ProcessTrace .......................................................... 71 Figura 3.7 - Transio de Estados de uma Tarefa .................................................... 73 Figura 3.8 - Transio de Status de uma Tarefa ....................................................... 73 Figura 3.9 - Modelagem do Processo RUP Instanciado ............................................ 74 Figura 3.10 - Execuo do Processo RUP Instanciado ............................................. 75 Figura 4.1 - Aderncia dos RAP do MR-MPS em Relao as GP do CMMI-DEV .... 83 Figura 4.2 - Ciclo de Vida de Processos no Contexto do Projeto SPIDER ............... 84 Figura 4.3 - Fase Gerenciamento do Processo ......................................................... 88 Figura 4.4 - Fase Execuo das Atividades do Processo ......................................... 91 Figura 4.5 - Fase Aplicao do Formalismo de Execuo ........................................ 92 Figura 5.1 - Mdulo de Gerncia do Processo da Ferramenta Spider-PE .............. 105

xiv

LISTA DE QUADROS

Quadro 2.1 - Comparao entre os Nveis de Capacidade e Maturidade do CMMIDEV (Adaptado de SEI, 2010)................................................................................... 36 Quadro 2.2 - Relao entre Nveis de Maturidade, Processos e Atributos de Processo (SOFTEX, 2011b) ...................................................................................... 41 Quadro 2.3 - Comparao entre Abordagens de Execuo de Processo ................. 52 Quadro 3.1 - Elementos do Processo Padro (BARROS, 2009)............................... 58 Quadro 3.2 - Comparao entre Abordagens de Execuo de Modelos de Processo SPEM ........................................................................................................................ 61 Quadro 3.3 - Elementos do Processo Instanciado (BARROS, 2009) ........................ 64 Quadro 3.4 - Elementos UML utilizados no Processo Instanciado (BARROS, 2009)65 Quadro 4.1 - Graus de Aderncia entre Componentes do CMMI-DEV e MR-MPS... 80 Quadro 4.2 - Mapeamento entre Resultados de Atributos de Processo do MR-MPS e Generic Practices do CMMI-DEV .............................................................................. 81 Quadro 4.3 - Nveis de Atendimento das atividades do Framework ao MR-MPS e CMMI-DEV ................................................................................................................ 95 Quadro 4.4 - Avaliao do Atendimento do Framework aos Modelos MR-MPS e CMMI-DEV ................................................................................................................ 95

xv

LISTA DE ABREVIATURAS

ADS BPMN CASE CMMI CMMI-DEV GP IEC ISO MDA MDE MPS.BR MR-MPS OMG PE PML PSEE RAP RUP SEI SOFTEX SPEM SPSM UML xSPEM

Ambientes de Desenvolvimento de Software Business Process Modeling Notation Computer-Aided Software Engineering Capability Maturity Model Integration CMMI for Development Generic Practices International Electrotechnical Commission International Organization for Standardization Model Driven Architecture Model Driven Engineering Melhoria do Processo de Software Brasileiro Modelo de Referncia para Melhoria do Processo de Software Object Management Group Process Enactment Processes Modeling Language Process-Centered Software Engineering Environment Resultado de Atributo de Processo Rational Unified Process Software Engineering Institute Associao para Promoo da Excelncia do Software Brasileiro Software Process Engineering Metamodel Software Process Simulator Machine Unified Modeling Language eXecutable SPEM

16

INTRODUO

Desenvolver software tem se mostrado uma atividade bastante complexa, pois nem todas as organizaes desenvolvedoras de software conseguem atingir o escopo definido, assegurar que os prazos sejam cumpridos, que os custos e recursos sejam estimados corretamente e ainda que o software desenvolvido possua a qualidade esperada pelo usurio (THE STANDISH GROUP INTERNATIONAL, 2009). Com o objetivo de solucionar estes problemas e buscando aumentar a qualidade de software, a Engenharia de Software tem produzido ferramentas a fim de auxiliar o desenvolvimento de software, assim como estudado e produzido formas de controlar o processo de desenvolvimento (REIS, 2003). Neste contexto, destaca-se a rea de Tecnologia de Processos de Software, que envolve a construo de ambientes para modelagem, execuo, simulao e evoluo de processos de desenvolvimento de software. Contudo, observou-se que apenas automatizar o desenvolvimento no suficiente para atingir todos os critrios de qualidade necessrios no desenvolvimento de software (BERTOLLO, 2006). Segundo Oliveira et al. (2005), uma das evolues mais importantes no estudo da qualidade est na constatao de que, apesar da qualidade do produto ser algo bom, a qualidade do processo de produo ainda mais importante. Sendo assim, pode-se dizer mais sobre a qualidade observando como o software foi desenvolvido (processo) ao invs de analisar apenas o produto final (software). Diante desta constatao, surgiram importantes mecanismos de avaliao e certificao da qualidade de software que se baseiam na maturidade e capacidade atingida pelas organizaes de desenvolvimento de software na conduo dos seus processos. Assim, modelos internacionais como o CMMI-DEV (Capability Maturity Model Integration for Development) (SEI, 2010) e, recentemente, modelos nacionais como o MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) (SOFTEX, 2011b), vm sendo amplamente utilizados para avaliar a qualidade de

17 software a partir do processo adotado para o seu desenvolvimento. Essas abordagens tiveram uma grande aceitao do mercado e passaram a ser uma ferramenta, de fato, para avaliar o nvel da qualidade de organizaes desenvolvedoras de software (OLIVEIRA, VASCONCELOS e ROUILLER, 2005). Esse captulo apresenta uma viso geral dos aspectos que caracterizam e justificam este trabalho. Inicialmente, uma contextualizao da dissertao apresentada para que se tenha um entendimento mais preciso da necessidade deste trabalho. Em seguida, apresentam-se as principais motivaes que levaram ao desenvolvimento deste trabalho. Alm disso, descrevem-se os objetivos do trabalho e a metodologia utilizada a fim de atender estes objetivos. Por fim, a estrutura desta dissertao descrita sucintamente atravs da organizao de seus captulos.

1.1

CONTEXTO DO TRABALHO

De acordo com Moitra (2001), um dos principais impasses para a consolidao de uma indstria de software de porte em pases em desenvolvimento consiste na falta de ferramental tecnolgico que atue de maneira decisiva na gerncia dos processos conduzidos nas organizaes, controlando prazos, gerenciando a alocao de recursos e mantendo controle sobre os produtos de trabalho resultantes. Este suporte ferramental pode fazer com que a indstria de software alcance um nvel mais satisfatrio de disciplina, assim como ocorreu o desenvolvimento bem sucedido de indstrias de outras reas (MOITRA, 2001). Alinhada a esta crescente necessidade de empresas qualificadas no que tange ao desenvolvimento de software, em busca de maior expresso no mercado nacional e internacional, o Governo Federal, atravs da instruo normativa 04/2007 do TCU (Tribunal de Contas da Unio), sugere que a adoo de padres/modelos de qualidade deve ser considerada para efeito de julgamento de propostas de organizaes desenvolvedoras de software em licitaes federais (TCU, 2010). Sendo assim, a partir destes padres, o agente pblico poder analisar, medir ou comparar os produtos entre si e decidir pelo melhor preo. Este cenrio caracteriza ainda mais a necessidade da implementao destes programas de melhoria da qualidade.

18 Diante deste cenrio, surgiu em 2009 o projeto SPIDER (Software Process Improvement: DEvelopment and Research) (OLIVEIRA, YOSHIDOME, et al., 2011) na Universidade Federal do Par. Este projeto tem como um dos focos principais, apresentar solues tecnolgicas (ferramentas de software livre, frameworks, ferramentais de apoio) com caractersticas adequadas para atender as boas prticas descritas nos modelos de qualidade CMMI-DEV (CMMI for Development) (SEI, 2010) e MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) (SOFTEX, 2011b). No contexto do Projeto SPIDER, no que diz respeito s pesquisas relacionadas ao ciclo de vida de processos, foi definida a linguagem SPIDER_ML (BARROS e OLIVEIRA, 2010a), para modelagem de processos, com base no padro SPEM (Software Process Engineering Metamodel) (OMG, 2008), definido pela OMG (Object Management Group). A partir desta linguagem, foi desenvolvida uma ferramenta de software livre para apoiar a modelagem de processos, a Spider-PM (BARROS e OLIVEIRA, 2010b). Tambm foi desenvolvida uma ferramenta para simulao de processos de software, denominada SPSM (Software Process Simulator Machine) (CHAVES, TAVARES, et al., 2010), que adota a sintaxe da SPIDER_ML como base para os modelos de processo que tero sua execuo simulada. Dando continuidade a estas pesquisas, o framework proposto neste projeto, denominado Spider-PE (Process Enactment), objetiva definir atividades genricas para apoiar a execuo de qualquer processo de software, conforme especificado em Portela et al. (2011). Um dos diferenciais desta proposta a adoo de um formalismo de execuo que determina uma semntica comportamental para execuo flexvel de processo. Estes conceitos, relacionados ao formalismo de execuo, foram definidos a partir de uma linguagem de execuo de processos, proposta neste trabalho, denominada xSPIDER_ML (eXecutable SPIDER_ML). Esta linguagem caracteriza-se como uma extenso da SPIDER_ML que permite a execuo de processos modelados a partir das notaes desta linguagem de modelagem. Outra caracterstica incorporada ao Framework Spider-PE foi a aderncia aos principais modelos de qualidade adotados pela indstria de software brasileira: CMMI-DEV e MR-MPS. Esta aderncia foi obtida atravs de um mapeamento entre o Nvel F do MR-MPS e Nvel 2 do CMMI-DEV. A partir deste mapeamento, foi possvel definir as atividades do framework relacionadas ao gerenciamento da execuo do processo.

19 Portanto, espera-se que este framework possa, alm de permitir a execuo flexvel e semi-automatizada de processos de software modelados a partir do padro SPEM, facilitar a adoo destes modelos de qualidade pelas organizaes devido visibilidade do andamento da execuo das atividades dos projetos de software que este tipo de tecnologia permite.

1.2

MOTIVAO

De acordo com Fuggeta (2000), a experincia internacional tem demonstrado que qualquer iniciativa de automao do processo de desenvolvimento de software seguida de grandes benefcios econmicos para as organizaes participantes. Estes benefcios variam desde a simples constatao e soluo de dificuldades especficas, relacionadas com a produtividade em projetos em andamento, at a certificao, a partir de avaliaes formais, de que as empresas participantes atingiram um reconhecimento da qualidade de seus produtos e processos. Apesar destes claros benefcios, a grande maioria dos projetos de automao de processos desenvolvida em mbito acadmico e no amplamente adotado pela indstria (REIS, 2003). Muitas abordagens propostas neste contexto acabam ficando restritas a laboratrios e centros de pesquisa. Observou-se, tambm, que a maioria destas abordagens para execuo de processos de software no adotam padres como o SPEM (OMG, 2008) e recomendaes de modelos de qualidade como CMMI-DEV (SEI, 2010) e MR-MPS (SOFTEX, 2011b). Diante do cenrio apresentado, este trabalho partilha da motivao do Projeto SPIDER (OLIVEIRA, YOSHIDOME, et al., 2011), que tem concentrado esforos em prover solues tecnolgicas para auxiliar a implementao da melhoria de processos de software atravs dos modelos de qualidade CMMI-DEV e MR-MPS. Sendo assim, pretende-se disponibilizar uma alternativa para a Execuo de Processos de Software, como forma de facilitar e, at mesmo, incentivar a implementao do processo em conformidade com modelos de qualidade, que ainda pouco explorado pelas abordagens do gnero. As atividades definidas no framework proposto permitem a gerao de indicadores do atendimento das prticas sugeridas por estes modelos de qualidade.

20 Alm disto, o framework proposto apoia a execuo de modelos de processo compatvel com o padro SPEM, pois apesar deste ser o padro para modelagem da OMG, no oferece mecanismos nativos para execuo automatizada do processo de software (BENDRAOU, COMBEMALE, et al., 2007). A partir da aderncia a estes padres e modelos, cada vez mais adotados pela indstria de software, espera-se que a proposta apresentada neste trabalho no se restrinja ao mbito acadmico e seja efetivamente utilizada pelas organizaes desenvolvedoras de software que fazem uso destes padres e modelos e que possuem pretenso de executar seus processos.

1.3

OBJETIVOS

1.3.1

Objetivo Geral

O principal objetivo deste trabalho fornecer uma soluo que possa contribuir com a melhoria contnua dos processos de indstrias de software, atravs do apoio execuo de processos de software em conformidade com o padro SPEM e com os modelos de qualidade CMMI-DEV Nvel 2 e MR-MPS Nvel F. A fim de atender este propsito, um framework de processo foi desenvolvido, composto essencialmente por um formalismo de execuo e por atividades genricas aderentes as recomendaes de modelos de qualidade do processo de software.

1.3.2

Objetivos Especficos

Para o atendimento do objetivo geral deste trabalho, os seguintes objetivos especficos devem ser contemplados: I. II. III. Revisar na literatura especializada os principais conceitos e caractersticas relacionadas execuo de processos de software; Identificar qual padro de modelagem adotado na indstria possui maior representatividade na definio de modelos de processo de software; Definir uma linguagem para execuo de processos, a partir da reviso

21 realizada em I e dos resultados da anlise comparativa realizada em II; IV. V. VI. Identificar as recomendaes de modelos de qualidade em relao execuo de processos de software; Desenvolver um framework de processo com base no formalismo da linguagem definida em III e nas recomendaes identificadas em IV; Avaliar o framework proposto atravs da anlise do atendimento das suas atividades s recomendaes dos modelos de qualidade mapeados em IV.

1.4

METODOLOGIA DO TRABALHO

A metodologia de trabalho adotada neste trabalho, representada na Figura 1.1 - Metodologia de PesquisaFigura 1.1, consistiu na realizao de pesquisas bibliogrficas, onde buscou-se identificar os principais conceitos e caractersticas relacionadas execuo de processos a partir de material j publicado em livros, artigos de peridicos, dentre outras fontes. Essas pesquisas apresentam carter conceitual, uma vez que visam relatar o estado da arte da rea de execuo de processos de software. Sendo assim, o tipo de estudo realizado neste trabalho caracteriza-se como Terico. De acordo com Easterbrook (2007), estudos tericos baseiam-se em um entendimento de uma rea a partir da referncia a outros trabalhos relacionados. Aps estas pesquisas bibliogrficas, foi realizada uma anlise comparativa entre os padres de modelagem SPEM (OMG, 2008) e BPMN (Business Process Modeling Notation) (OMG, 2011) a fim de avaliar a representatividade destes padres no contexto de processos de software (PORTELA, VASCONCELOS, et al., 2012a). Aps esta anlise, optou-se por realizar um experimento evolvendo a modelagem da rea de Processo REQM (Requirements Management) do CMMI-DEV e do Processo GRE (Gerncia de Requisitos) do MR-MPS, a fim de avaliar o resultado da anlise realizada. Segundo Travassos (2002), experimentos so realizados em laboratrio, objetivando manipular algumas variveis e manter outras fixas medindo o efeito do resultado. A partir deste experimento, disponvel em um Relatrio de Pesquisa (Apndice A), constatou-se que o SPEM, por ser um padro definido especificamente para a modelagem de processos de software, possui maior expressividade no atendimento deste propsito.

22

Figura 1.1 - Metodologia de Pesquisa

A partir do resultado desta anlise comparativa e das pesquisas relacionadas linguagem de modelagem SPIDER_ML (BARROS e OLIVEIRA, 2010a), especificou-se a linguagem de execuo xSPIDER_ML (PORTELA, VASCONCELOS, et al., 2012b). Esta linguagem define um formalismo de execuo constitudo de um conjunto estruturado de elementos e regras. Este formalismo permitiu acrescentar uma semntica comportamental linguagem de modelagem de processos SPIDER_ML para que esta suportasse a execuo de processos. A definio desta linguagem foi feita a partir de uma Pesquisa Aplicada, que visa gerar conhecimentos para aplicao prtica na soluo de problemas especficos (EASTERBROOK, SINGER, et al., 2007). No contexto deste trabalho, o problema consiste em permitir com que modelos de processos possam ser executados. A fim de avaliar a linguagem proposta, realizou-se uma prova de conceito a partir da aplicao do formalismo de execuo da xSPIDER_ML em uma instanciao do processo do RUP (Rational Unified Process). Uma prova de conceito pode ser considerada uma implementao, em geral resumida ou incompleta, de um mtodo ou de uma ideia, realizada com o propsito de verificar que o conceito ou teoria

23 em questo suscetvel de ser explorado de uma maneira til (TRAVASSOS, 2002). Esta prova de conceito, bem como os elementos e regras que compem a xSPIDER_ML, esto disponveis na sua Especificao Tcnica (PORTELA e GOMES, 2011b) e no Apndice B deste trabalho. Posteriormente definio desta linguagem, foi realizado um Mapeamento entre os modelos de qualidade CMMI-DEV Nvel 2 e MR-MPS Nvel F, procurando identificar similaridades e diferenas entre as prticas sugeridas pelos mesmos, para que fossem definidas as atividades necessrias para a execuo de um processo de software. O resultado deste mapeamento foi comparado com as orientaes para a implementao e avaliao do Modelo de Referncia MR-MPS:2009 em conjunto com o CMMI-DEV v1.2, constante no Guia de Implementao Parte 11 (SOFTEX, 2011a). Os resultados obtidos a partir das pesquisas bibliogrficas, da anlise comparativa entre padres de modelagem, do mapeamento entre modelos de qualidade e do formalismo proposto pela linguagem xSPIDER_ML, foram a base utilizada para definio do framework de apoio execuo de processos, denominado Spider-PE. Este framework foi definido a partir de uma Pesquisa Exploratria (EASTERBROOK, SINGER, et al., 2007), onde foram realizadas investigaes de pesquisas empricas com a finalidade de aumentar a familiaridade do pesquisador com a rea de execuo e abrir caminhos para realizao de pesquisas futuras mais precisas. Sendo o mapeamento entre modelos de qualidade e o formalismo proposto pela linguagem xSPIDER_ML as bases utilizadas para definio do Framework Spider-PE, uma forma de avaliar este framework atravs da avaliao destes componentes. Estes componentes foram avaliados, conforme descrito anteriormente, atravs de uma anlise comparativa e de uma prova de conceito. Outra abordagem para avaliao do Framework Spider-PE atravs da anlise do atendimento de suas atividades ao Guia de Implementao Parte 11 (SOFTEX, 2011a) e ao Mapeamento apresentado na Seo 4.1 deste trabalho. Nesta abordagem, para cada atividade do framework, identificaram-se os Resultados de Atributos de Processo (RAP) do MR-MPS (SOFTEX, 2011b) e as Prticas Genricas (GP) do CMMI-DEV (SEI, 2010) que so contemplados por estas atividades. Esta abordagem de avaliao apresentada em detalhes na Seo 4.3. Adicionalmente, este trabalho foi periodicamente avaliado a partir da submisso e aprovao de artigos em eventos e peridicos especficos das reas de Enge-

24 nharia de Software e Qualidade do Processo, a citar: IX Workshop de Teses e Dissertaes de Qualidade de Software (PORTELA, VASCONCELOS e OLIVEIRA, 2011); e Journal of Software Engineering and Applications (PORTELA, VASCONCELOS, et al., 2012a e 2012b).

1.5

ESTRUTURA DO TRABALHO

Alm desse captulo introdutrio, que apresenta uma viso geral das pesquisas realizadas neste trabalho, atravs da sua contextualizao, motivao, objetivos e metodologia utilizada para atendimento destes objetivos, descrita a seguir a estrutura dos demais captulos desta dissertao. O Captulo 2 apresenta o embasamento terico deste trabalho, resultado do estudo bibliogrfico realizado. Sendo assim, abrange os conceitos e caractersticas de processos de software a partir da apresentao de modelos para definio e melhoria destes processos de software. Alm disto, este captulo apresenta um detalhamento sobre a fase Execuo de Processos, atravs da sua contextualizao e caractersticas. Por fim, so apresentados os trabalhos relacionados execuo de processos no contexto de ambientes de desenvolvimento de software (ADS). O Captulo 3 dedicado apresentao da linguagem de execuo de processos xSPIDER_ML. A definio desta linguagem de execuo foi necessria para adicionar elementos e regras aos modelos de processos a fim de que estes pudessem ser formalmente executados. Inicialmente, apresentam-se a anlise comparativa entre os padres SPEM e BPMN e a linguagem SPIDER_ML, que serviram de base para definio desta linguagem. Em seguida, a linguagem xSPIDER_ML detalhada atravs da apresentao dos principais trabalhos relacionados, objetivos e caractersticas. Apresenta-se, tambm, o formalismo de execuo proposto pela xSPIDER_ML, a partir de seus componentes e regras associadas. Por fim, este captulo apresenta uma avaliao desta linguagem, atravs de uma prova de conceito envolvendo a instanciao de um processo RUP (Rational Unified Process). O Captulo 4 apresenta o Framework Spider-PE, principal contribuio deste trabalho. Para tal, inicialmente, apresenta-se o mapeamento realizado entre os modelos MR-MPS e CMMI-DEV, a partir do qual foram identificadas as atividades do

25 framework. Em seguida, o framework foi detalhado atravs da descrio de suas fases, atores e atividades. Por fim, este captulo apresentou a avaliao e os principais diferenciais desta proposta. Finalmente, o Captulo 5 apresenta as concluses e contribuies deste trabalho. Neste captulo so descritos, tambm, os trabalhos futuros a serem realizados, como o desenvolvimento de uma ferramenta que adote as atividades do Framework Spider-PE, um estudo de caso da aplicao deste framework em um contexto organizacional e a integrao desta proposta com as demais fases do processo.

26

PROCESSO DE SOFTWARE: DEFINIO, MELHORIA

E EXECUO

A Engenharia de Software a rea de conhecimento da Cincia da Computao responsvel pelo estudo dos elementos envolvidos no processo de desenvolvimento de software (ou simplesmente, processo de software). Esse processo o principal objeto de estudo da Engenharia de Software e pode ser definido como o mecanismo pelo qual um determinado problema do usurio, descrito por meio de um conjunto de requisitos, convertido em uma soluo automatizada, baseada em software (OLIVEIRA, 2006). Para tal, incorpora princpios, mtodos, metodologias e ferramentas, que permitem a gerncia do processo de software; e fornece mecanismos para a construo de software de forma produtiva. Um destes mecanismos diz respeito avaliao e certificao da qualidade de software que se baseiam na maturidade e capacidade atingida pelas organizaes de desenvolvimento de software na conduo dos seus processos. Este mecanismo apoiado por modelos e normas de qualidade que objetivam a melhoria contnua do processo de software, como o CMMI-DEV (SEI, 2010) e o MR-MPS (SOFTEX, 2011b). Outro mecanismo que se destaca neste contexto refere-se execuo de processos de software. Este mecanismo de execuo preocupa-se, dentre outras questes, em garantir que o processo esteja sendo executado conforme modelado (REIS, 2003), a partir da coordenao e automatizao das atividades deste processo. Neste captulo apresentada uma viso geral sobre processos de software, a partir de conceitos bsicos envolvidos na sua definio e de algumas caractersticas relacionadas sua melhoria contnua. Alm disso, sero discutidos, tambm, os principais aspectos relacionados execuo automatizada destes processos.

27 2.1 PROCESSOS DE SOFTWARE: UMA VISO GERAL

De uma maneira geral, o processo de software pode ser compreendido como o conjunto de tarefas necessrias para transformar os requisitos dos usurios em software (OSTERWEIL, 1987) (HUMPHREY, 1989). Nesta definio de processo de software devem-se considerar alguns conceitos, conforme ressaltado em Pfleeger (2001), como as atividades a serem realizadas; os recursos utilizados; os artefatos consumidos e gerados; os procedimentos, o paradigma e as tecnologias adotadas; e o modelo de ciclo de vida utilizado. No contexto da melhoria contnua do processo, Paulk et al. (1993) definem o processo de software como o conjunto de mtodos, prticas e transformaes que pessoas utilizam para desenvolver e manter software e seus produtos relacionados, como por exemplo: planos do projeto, cdigo-fonte e manuais. importante ressaltar que apesar das diversas definies, desenvolver software , sobretudo, uma atividade criativa, intelectual e social, realizada com o objetivo de resolver problemas especficos (SOMMERVILLE, 2010). No entanto, para garantir que este software desenvolvido ir solucionar o problema pretendido, o mesmo deve estar aderente aos requisitos do cliente, conforme j definido por Humphrey (1989). Buscando atingir esta aderncia, o processo de software pode ser compreendido como uma transformao de um conjunto de requisitos para um software, onde cada etapa dessa transformao considerada um refinamento do nvel de abstrao da soluo de um problema (HUMPHREY, 1989). Na Figura 2.1, as etapas de nveis mais elevados apresentam as caractersticas mais genricas do conjunto de requisitos. Por outro lado, as etapas de nveis mais baixos apresentam elementos que esto mais prximos da soluo final do problema. Cada uma destas etapas apresenta um conjunto parcialmente ordenado de atividades que interagem entre si e que podem estar associadas a artefatos, recursos humanos ou ferramentas (LOMCHAMP, 1993), sendo estes denominados elementos do processo. Um processo de software pode ser bastante complexo e apresentar uma grande variedade desses elementos (CONRADI e LIU, 1995). Alguns desses elementos so considerados bsicos em um processo de software. Elementos bsicos so aqueles que esto presentes em todos os processos de software, ou

28 seja, constituem o conjunto mnimo necessrio de elementos para a definio de um processo de software completo. Sendo assim, os elementos bsicos de um processo de software so: atividades, artefatos, recursos humanos, papis e ferramentas (CONRADI e LIU, 1995) (SUTTON, TARR e OSTERWEIL, 1995) (ZAMLI e LEE, 2001). Alm de cada um destes elementos bsicos, outro conceito importante em um processo de software o conceito de procedimento (FALBO, 1998).

Figura 2.1 - Viso Genrica do Processo de Engenharia de Software (Adaptado de OLIVEIRA, 2006)

Sendo o processo de software o conjunto de etapas necessrias para se desenvolver um software, a definio do processo de software consiste na descrio desse processo (HUMPHREY, 1995). Esta definio do processo de software um dos principais objetivos de uma organizao que desenvolve software (OLIVEIRA, 2006), pois caso seja realizada adequadamente, pode prover um conjunto de benefcios para esta organizao, tais como descritos por (HUMPHREY, 1995): possibilitar a comunicao efetiva sobre o processo entre os desenvolvedores, gerentes, e demais pessoas envolvidas no processo; auxiliar o gerenciamento do processo; permitir o reso do processo; facilitar o aperfeioamento do processo.

29 Apesar de facilitar o reso, uma definio de processo de software no pode ser genericamente aplicada em diferentes projetos de software uma vez que nenhum projeto idntico a outro (OLIVEIRA, 2006). Cada projeto apresenta caractersticas distintas como: complexidade do software, tamanho do software, recursos disponveis, tecnologias utilizadas, etc. Estas caractersticas devem ser consideradas no momento da definio de um processo de software. No entanto, apesar das diferenas existentes entre todos os projetos de software, existe um conjunto bsico de elementos presentes em todos os processos definidos, conforme j mencionado por Conradi e Liu (1995). Esse conjunto de elementos define um processo fundamental que guia a definio dos demais processos da organizao, sendo assim denominado Processo Padro (ISO/IEC, 2003). As razes que levam definio de um Processo Padro so diversas, conforme descritas por (HUMPHREY, 1989): reduzir os problemas relacionados a treinamento, revises e suporte ao processo; melhorar os processos a partir das experincias adquiridas reunidas no Processo Padro; fornecer bases para medies e avaliaes de qualidade; reduzir o tempo e esforo gasto na definio de novos processos. Conforme mencionado anteriormente, as organizaes utilizam o Processo Padro como base para a definio dos processos que so executados para cada um de seus projetos de desenvolvimento. Esses processos so denominados Processos Instanciados e so aqueles que de fato so executados pela organizao, levando-se em considerao os recursos disponveis e as caractersticas especficas do software que ser produzido (OLIVEIRA, 2006). Alm disso, com base nas observaes feitas a partir da execuo desses Processos Instanciados que o Processo Padro da organizao pode ser melhorado. A partir destes conceitos, pode-se estabelecer um modelo para definio de um processo de software constitudo de duas etapas: definio do Processo Padro e sua instanciao para projetos especficos. A seo a seguir apresenta o conceito e as caractersticas necessrias para definio de um modelo de processo de software.

30 2.2 MODELOS DE PROCESSO DE SOFTWARE

De acordo com Pressman (2010), um modelo de processo de software uma descrio simplificada que representa um processo de software, caracterizando-se como uma abstrao de um processo real que contm as atividades, os papis e os produtos (artefatos). Esta definio semelhante apresentada por Lomchamp (1993), que caracteriza este modelo de processo de software como uma descrio formal do desenvolvimento de software, onde vrios tipos de informaes devem ser integradas a este modelo de processo de maneira a indicar quem, quando, onde, como e por que os passos so realizados. Estes passos de um processo so constitudos por atividades, onde cada atividade produz mudanas concretas para concepo do produto de software em desenvolvimento. A execuo destas atividades pode ser feita de maneira escalonvel, onde a execuo da atividade seguinte pode depender do resultado da atividade anterior ou de um conjunto de atividades anteriores. Cada uma destas atividades possui uma descrio, relaes de dependncia com outras atividades, datas estimadas de incio e fim, recursos a serem alocados e agentes responsveis pela realizao da mesma (DOWSON, NEIMEH e RIDDLE, 1991), conforme ilustra a Figura 2.2.

Figura 2.2 - Elementos envolvidos na realizao das Atividades do Processo (Adaptado de REIS et al., 2002)

31 Um agente est relacionado s atividades de um processo e o responsvel pela execuo destas atividades. Estes agentes podem ser pessoas ou ferramentas automatizadas (REIS, 2003). Podem, tambm, estar distribudos em diferentes cargos e funes (papis) para que possam ter diferentes vises sobre o que ocorre no processo de software e se organizem de forma que as atividades que realizam sejam escolhidas de acordo com as suas habilidades. Artefatos so os produtos de um processo, de maneira que uma atividade pode gerar um produto como resultado de sua realizao, denominado artefato de sada, e este produto pode ser utilizado como artefato de entrada na realizao de uma ou mais atividades. Por fim, os processos podem ser limitados por restries (LOMCHAMP, 1993), onde uma restrio a condio que um passo do processo deve satisfazer antes ou depois de ser realizado (FEILER e HUMPHREY, 1993). Para representar estes elementos que compem o processo, ou seja, para construir modelos de processo de software, necessria uma linguagem para modelagem do processo (KELLNER e HANSEN, 1988). De um modo geral, estas linguagens para modelagem de processo estabelecem um mecanismo para a representao das atividades e tarefas do processo de software e os recursos relacionados com essas atividades e tarefas (OLIVEIRA, 2006). De acordo com Kellner e Hansen (1988), um dos objetivos desse tipo de representao facilitar o aperfeioamento contnuo do processo de software, pois possibilita o entendimento do processo de maneira visual e representativa entre os elementos que compem o processo. Na Seo 3.2 ser apresentada uma linguagem de modelagem de processos de software, denominada SPIDER_ML. Posteriormente, o modelo pode ser instanciado atravs da definio das atividades e dos desenvolvedores que atuaro no processo, do cronograma (prazos) e dos recursos a serem alocados. Aps esta instanciao, o modelo de processo poder ser executado atravs de um mecanismo de execuo. A respeito desta execuo, sero apresentados conceitos e trabalhos relacionados na Seo 2.4. Outra forma adotada pela indstria de definir, avaliar e melhorar seus processos de software atravs de normas, modelos e programas de qualidade. A seo a seguir trata da melhoria de processos de software a partir da apresentao dos principais modelos de qualidade adotados pela indstria brasileira de software.

32 2.3 MELHORIA DO PROCESSO DE SOFTWARE

Os processos de software so definidos por organizaes inseridas em ambientes de negcios que frequentemente sofrem modificaes. Essas modificaes exigem que as organizaes alterem seus processos de software visando uma adaptao s mudanas sofridas nestes ambientes de negcios (SOFTEX, 2011b). Dessa forma, caso desejem produzir softwares com qualidade e se manterem competitivas nesse mercado, faz-se necessrio que estas organizaes sejam capazes de melhorar continuamente os seus processos de software. A adaptao a estas mudanas pode ser facilitada quando os processos das organizaes so orientados por padres e modelos de referncia de processos (DE MELLO, 2011). Essa melhoria orientada a modelos e padres mais efetiva e eficiente do que quando considera-se apenas iniciativas ad-hoc, provenientes de demandas eventuais, dentro de uma organizao (MUTAFELIJA e STROMBERG, 2003). Estes padres e modelos sero, posteriormente, abordados com maiores detalhes. Segundo Oliveira et al. (2005), uma das evolues mais importantes no estudo da rea de qualidade est na constatao de que, apesar da qualidade do produto ser algo bom, a qualidade do processo de produo ainda mais importante. De acordo com esta constatao, apresentada em (PAULK, CURTIS, et al., 1997), pode-se dizer mais sobre a qualidade de um software observando como este foi desenvolvido (processo) ao invs de analisar apenas o produto final (software). Em suas pesquisas, para auxiliar organizaes a desenvolverem e manterem produtos e servios com qualidade, o SEI (Software Engineering Institute) encontrou trs dimenses em que uma organizao pode focar esforos para melhorar seus negcios: pessoas; procedimentos e mtodos; e ferramentas e equipamentos (SEI, 2010). A partir destas pesquisas, constatou-se que o que mantm a coeso entre estas dimenses so os processos utilizados na organizao. Os processos permitem alinhar a maneira de fazer negcio, alm de uma melhor compreenso das tendncias deste negcio. Permitem, tambm, otimizar recursos, explorar a escalabilidade e facilitar a incorporao do conhecimento e das melhores prticas nas organizaes.

33 Esta mesma constatao reafirmada pela SOFTEX (Associao para Promoo da Excelncia do Software Brasileiro), ao indica para as organizaes desenvolvedoras de software, que desejam atingir uma estabilidade e um crescimento contnuo, investirem tanto na melhoria de seus produtos de software quanto na melhoria de seus processos de software (SOFTEX, 2011b). Portanto, a melhoria de processo de software definida como todo esforo empreendido por uma organizao para que seu processo de software possa ser utilizado com o menor nmero de problemas advindos do crescimento de um software (SOMMERVILLE, 2010). Neste contexto, uma srie de normas, modelos e programas foram elaboradas com o intuito de definir, avaliar e melhorar os processos de software. Os modelos ajudam as organizaes a evolurem de forma sistemtica sua capacidade para cumprir prazos e construir software (PAULK, 2004). De uma maneira geral, estes modelos baseiam-se na maturidade atingida pelas organizaes de desenvolvimento de software em relao conduo dos seus processos (OLIVEIRA, VASCONCELOS e ROUILLER, 2005). Alm disto, uma das vantagens da utilizao desses padres o seu baixo custo associado se comparado ao desenvolvimento de padres prprios por parte de cada organizao (OLIVEIRA, 2006). Assim, os modelos e normas possuem um conjunto essencial de conhecimento e boas prticas para diversas disciplinas da Engenharia de Software, descrevendo um caminho evolutivo para a melhoria dos processos de uma organizao. Porm, apesar de auxiliar e recomendar a definio de processos, os modelos e normas no definem os processos que as organizaes devero seguir, pois a definio destes processos deve ser a mais adequada possvel natureza e cultura da organizao. Portanto, os processos devem ser definidos pelas prprias organizaes. Neste sentido, estes modelos so independentes de abordagens de processo, ou seja, as prticas destes modelos podem ser incorporadas tanto por processos tradicionais (como por exemplo, processos baseados no RUP) quanto por processos geis (como por exemplo, processos baseados no SCRUM). O valor destas abordagens de melhoria de processo tem sido confirmado ao longo do tempo (GIBSON, GOLDENSON e KOST, 2006), onde as organizaes tm observado um aumento de produtividade e qualidade, melhorias no tempo de ciclo (cycle time) e prazos, e oramentos mais precisos e previsveis. A utilizao destes padres busca, sobretudo, simplificar as relaes entre as organizaes e seus cli-

34 entes (OLIVEIRA, VASCONCELOS e ROUILLER, 2005), uma vez que os clientes podem identificar a qualidade dos servios oferecidos por essas organizaes por meio dos padres que elas utilizam. Nas sees a seguir, apresentam-se os modelos de melhoria considerados nesse trabalho: o CMMI-DEV (SEI, 2010) e o MR-MPS (SOFTEX, 2011b).

2.3.1

O Modelo CMMI-DEV

O CMMI (Capability Maturity Model Integration) um modelo de maturidade para melhoria de processo, destinado ao desenvolvimento de produtos e servios, e composto pelas melhores prticas associadas a atividades de desenvolvimento e de manuteno que cobrem o ciclo de vida do produto desde a concepo at a entrega e manuteno (SEI, 2010). Desenvolvido pelo SEI (Software Engineering Institute), possui uma verso especfica para desenvolvimento, denominada CMMI-DEV (CMMI for Development) que fornece uma soluo integrada e abrangente para as atividades de desenvolvimento e manuteno aplicadas a produtos e servios. Esta subseo apresentar alguns conceitos e elementos desse modelo, de acordo com o foco desta dissertao. Para um maior entendimento deste modelo, consulte a sua verso 1.3 (SEI, 2010), lanada em novembro de 2010. Conforme citado anteriormente, o objetivo do CMMI-DEV auxiliar as organizaes na melhoria de seus processos de desenvolvimento e manuteno de produtos e servios. Para tal, contm prticas que cobrem Gesto de Projeto, Gesto de Processo, Engenharia de Sistemas, Engenharia de Hardware, Engenharia de Software e outros processos de suporte utilizados em desenvolvimento e manuteno. O CMMI-DEV permite diferentes abordagens para a melhoria de processo, contendo os elementos essenciais de uma ou mais disciplinas associadas ao desenvolvimento de um produto e descrevendo um caminho de melhoria evolutiva desde processos imaturos, ad hoc, at processos maduros, disciplinados, com qualidade e eficcia melhoradas. Sendo assim, utiliza duas formas de representaes: contnua e por estgios. A representao contnua permite que a organizao escolha uma determinada rea de processo (ou grupo de reas de processo) e melhore os processos rela-

35 cionados a esta rea. Essa representao utiliza nveis de Capacidade para caracterizar a melhoria associada a uma rea de processo em particular. A representao por estgios utiliza conjuntos predefinidos de reas de processo para definir um caminho de melhoria para a organizao. Esse caminho de melhoria caracterizado por nveis de maturidade. Cada nvel de maturidade contm um conjunto de reas de processos que caracterizam diferentes comportamentos organizacionais. Se os processos da organizao que precisam ser melhorados so conhecidos e se as dependncias entre as reas de processo descritas no CMMI so bem compreendidas, recomenda-se para essa organizao a representao contnua (SEI, 2010). Esta representao oferece uma maior flexibilidade, pois permite que uma organizao melhore diferentes processos com diferentes nfases ao longo do tempo. Nesta abordagem, a organizao pode obter o nvel Definido em uma determinada rea de processo, independente de ter obtido apenas o nvel Realizado em outra rea de processo. A conquista de cada nvel de capacidade assegura apenas que uma determinada rea de processo (ou grupo de reas de processo) obteve um determinado nvel de capacidade, estabelecendo uma base de melhoria adequada para aquela determinada rea de processo. Se a organizao no sabe por onde comear e quais processos escolher para serem melhorados, recomenda-se a representao por estgios (SEI, 2010). Esta representao fornece uma ordem para implementao das reas de processo de acordo com nveis de maturidade, definindo um caminho de melhoria para a organizao, do nvel Inicial ao nvel Em Otimizao, conforme ilustra a Figura 2.3.

Figura 2.3 - Nveis de Maturidade do CMMI-DEV (Adaptado de SEI, 2010)

36 A conquista de cada nvel de maturidade assegura que foi estabelecida uma base de melhoria adequada para o prximo nvel de maturidade, permitindo, assim, uma melhoria incremental. O Quadro 2.1 relaciona os nveis de maturidade e capacidade do CMMI-DEV, onde os nveis representam uma evoluo para as reas de processo, na medida em que as exigncias do modelo so satisfeitas pela organizao.
Quadro 2.1 - Comparao entre os Nveis de Capacidade e Maturidade do CMMI-DEV (Adaptado de SEI, 2010)

Nvel 0 1 2 3 4 5

Nvel de Capacidade Incompleto Realizado Gerenciado Definido Inexistente Inexistente Inicial

Nvel de Maturidade Inexistente Gerenciado Definido Gerenciado Quantitativamente Em Otimizao

Os componentes do CMMI-DEV so agrupados em trs categorias, de acordo com a maneira de interpret-los: Componentes Requeridos: descrevem o que uma organizao deve realizar para implementar uma rea de processo; Componentes Esperados: descrevem o que uma organizao pode implementar para satisfazer um Componente Requerido, orientando os responsveis por implementar melhorias ou executar avaliaes; Componentes Informativos: fornecem detalhes s organizaes para auxili-las na implementao dos componentes requeridos e esperados. A Figura 2.4 representa esta estrutura de componentes do modelo CMMIDEV. Os componentes requeridos, representados por retngulos arredondados, so os objetivos especficos e os objetivos genricos. A satisfao destes objetivos o critrio utilizado nas avaliaes para decidir se uma rea de processo foi implementada de maneira adequada. Os componentes esperados, representados por losangos, so constitudos pelas prticas especficas e prticas genricas. Antes que os objetivos possam ser considerados satisfeitos, as prticas devem estar presentes tanto nos processos planejados quanto nos processos implementados da organizao. Por fim, os componentes informativos do modelo, representados por elipses,

37 so: subprticas, produtos de trabalho tpicos, orientaes para aplicao de prticas genricas, ttulos e notas de objetivos e prticas, e referncias a outras reas de processo.

Figura 2.4 - Estrutura de Componentes do CMMI-DEV (Adaptado de SEI, 2010)

Uma rea de processo um conjunto de prticas relacionadas a uma rea que, quando implementadas, satisfazem o seu Propsito a fim de realizar melhorias significativas naquela rea. Cada uma destas reas de processo possui Notas Introdutrias que descrevem os principais conceitos abordados nestas reas. Estas reas de processo possuem, tambm, reas de Processo Relacionadas que refletem o relacionamento de alto nvel entre estas reas de processo. Os Objetivos Especficos descrevem caractersticas especficas que devem estar presentes em uma determinada rea de processo enquanto que os Objetivos Genricos descrevem caractersticas necessrias para institucionalizar os processos da rea de processo em questo. So denominados genricos porque a mesma declarao de objetivo se aplica a vrias reas de processo. Cada um destes Objetivos Especficos contm um conjunto de Prticas Especficas que descrevem as atividades consideradas importantes para a satisfao do Propsito da rea em questo. De forma similar, os Objetivos Genricos possuem

38 Prticas Genricas que descrevem as atividades consideradas importantes para satisfao do Objetivo Genrico associado.

2.3.2

O Modelo MR-MPS

O MPS.BR1 um programa de longo prazo, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que possui como objetivo a melhoria de processo do software brasileiro, a partir de duas metas principais a alcanar (SOFTEX, 2011b): meta tcnica visando a criao e aprimoramento do modelo MPS, atravs de guias do modelo, Instituies Implementadoras, Instituies Avaliadoras e Consultores de Aquisio; meta de mercado visando a disseminao e adoo do modelo MPS, em todas as regies do pas, a um custo razovel, tanto em micro, pequenas e mdias empresas (foco principal) quanto em grandes organizaes pblicas e privadas. Espera-se, tambm, que o modelo MPS seja compatvel com os principais padres de qualidade internacionais para definio, avaliao e melhoria de processos de software. Sendo assim, a base tcnica para a construo e aprimoramento deste modelo composta pelas normas ISO/IEC 12207 (ISO/IEC, 2008) e ISO/IEC 15504-2 (ISO/IEC, 2003) e em conformidade com o modelo CMMI-DEV (SEI, 2010). O objetivo desta abordagem que o modelo seja reconhecido nacional e internacionalmente como aplicvel indstria de software (SOFTEX, 2011b). Consequentemente, espera-se que as organizaes que adotem este modelo possam alcanar competitividade em nvel internacional. Esta subseo apresenta alguns conceitos e elementos desse modelo, de acordo com o foco desta dissertao. Para um maior entendimento deste modelo, consulte a sua atual verso (SOFTEX, 2011b), lanada em junho de 2011. O modelo MPS estrutura-se em 3 (trs) componentes, conforme Figura 2.5: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Ne-

A sigla MPS.BR est associada ao programa MPS.BR Melhoria do Processo de Software Brasileiro e a sigla MPS est associada ao modelo MPS Melhoria do Processo de Software.

39 gcio (MN-MPS). Cada um destes componentes descrito por meio de guias e/ou documentos do modelo MPS. O MR-MPS contm os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MR-MPS, sendo composto por um Guia Geral, um Guia de Implementao e um Guia de Aquisio. O Guia Geral contm as definies dos nveis de maturidade, processos e atributos do processo. O Guia de Implementao sugere formas de implementar cada um dos nveis do MR-MPS. Por fim, o Guia de Aquisio trata de um documento complementar destinado a organizaes que pretendem adquirir software e servios correlatos.

Figura 2.5 - Componentes do Modelo MPS (SOFTEX, 2011b)

Este Modelo de Referncia MR-MPS define nveis de maturidade que estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao de processos na organizao (SOFTEX, 2011b). Sendo assim, o MR-MPS define uma escala de 7 (sete) nveis de maturidade, conforme ilustra Figura 2.6, iniciando-se no nvel G e progredindo at o nvel A. Esta diviso em nveis tem o objetivo de possibilitar uma implementao e avaliao de forma gradual, sendo os impactos e os custos divididos em maiores etapas, em comparao ao CMMI-DEV, por exemplo. A possibilidade de se realizar avaliaes considerando mais nveis permite, tambm, uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.

40

Figura 2.6 - Nveis de Maturidade do MR-MPS (Adaptado de SOFTEX, 2011b)

Para cada um destes nveis de maturidade atribudo um perfil de processos que indica onde a organizao deve colocar o esforo de melhoria. O progresso e o alcance de um determinado nvel de maturidade do MR-MPS obtm-se quando so atendidos os propsitos e todos os Resultados Esperados (RE) dos respectivos processos e os Resultados de Atributos de Processo (RAP) estabelecidos para aquele nvel (SOFTEX, 2011b). A Figura 2.7 apresenta a estrutura do MR-MPS e seus componentes.

Figura 2.7 - Estrutura de Componentes do MR-MPS (SOFTEX, 2011a)

Os processos no MR-MPS so descritos em termos de propsito e resultados. O propsito descreve o objetivo geral a ser atingido durante a execuo do proces-

41 so. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementao do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudana significativa de estado ao se executar o processo (SOFTEX, 2011b). A capacidade do processo representada por um conjunto de atributos de processo (AP) descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalizao com que o processo executado na organizao/unidade organizacional (SOFTEX, 2011b). No MR-MPS, medida que a organizao/unidade organizacional evolui nos nveis de maturidade, uma maior capacidade para desempenhar o processo deve ser atingida. Estas capacidades so acumulativas, ou seja, se a organizao est no nvel F, esta possui a capacidade do nvel F que inclui os atributos de processo dos nveis G e F para todos os processos relacionados no nvel de maturidade F. Isto significa que, ao passar do nvel G para o nvel F, os processos do nvel de maturidade G passam a ser executados na capacidade correspondente ao nvel F. A relao entre os nveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nvel apresentada no Quadro 2.2.
Quadro 2.2 - Relao entre Nveis de Maturidade, Processos e Atributos de Processo (SOFTEX, 2011b)

Nvel A B C

Processos

Atributos de Processo
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2 , AP 5.1 e AP 5.2

Gerncia de Projetos GPR (evoluo) Gerncia de Riscos GRI Desenvolvimento para Reutilizao DRU Gerncia de Decises GDE Verificao VER Validao VAL Projeto e Construo do Produto PCP Integrao do Produto ITP Desenvolvimento de Requisitos DRE

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2

Gerncia de Projetos GPR (evoluo) Gerncia de Reutilizao GRU Gerncia de Recursos Humanos GRH AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 Definio do Processo Organizacional DFP Avaliao e Melhoria do Processo Organizacional AMP

42 Nvel Processos
Medio MED Garantia da Qualidade GQA Gerncia de Portflio de Projetos GPP Gerncia de Configurao GCO Aquisio AQU Gerncia de Requisitos GRE Gerncia de Projetos GPR

Atributos de Processo

AP 1.1, AP 2.1 e AP 2.2

AP 1.1 e AP 2.1

2.4

EXECUO DE PROCESSOS DE SOFTWARE

As organizaes desenvolvedoras de software tm se esforado para aplicar modelos de processos (ver Seo 2.2) em seus projetos de desenvolvimento, a fim de facilitar o entendimento da complexidade destes processos de maneira visual e representativa. Porm, encontram muitas dificuldades, principalmente devido a duas fortes premissas que estas organizaes possuem durante a adoo de processos de software (SILVA, BLANC e BENDRAOU, 2011). A primeira que o modelo de processo adotado capta, de maneira correta, os passos, marcos, artefatos e papis necessrios para alcanar os objetivos destas empresas. A segunda que os agentes do processo vo seguir rigorosamente o modelo de processo adotado, sem tomar qualquer iniciativa pessoal para realizar o processo de forma diferente da especificada neste modelo de processo. Uma das maneiras de garantir que o processo seja realizado conforme modelado atravs de modelos executveis. Este modelo pode ser definido como uma instncia de uma definio do processo que inclui todos os elementos necessrios para a sua execuo (FEILER e HUMPHREY, 1993). Em outras palavras, este modelo executvel obtido a partir da instanciao dos conceitos abstratos do modelo de processo de software construdo na fase de modelagem e pode ser caracterizado como a realizao automatizada da construo de um software (SILVA, 2001). Desta forma, observa-se que o mecanismo de execuo fortemente influenciado pelo paradigma de modelagem utilizado (REIS, 2003). Uma das principais vantagens destes modelos executveis que uma vez construdos, eles podem ser executados, controlados, validados e aperfeioados em curtos ciclos incrementais e iterativos (BENDRAOU, COMBEMALE, et al., 2007).

43 Para estabelecer um modelo executvel deve-se instanciar um modelo de processo atravs da definio de suas atividades e dos desenvolvedores que atuaro neste processo, alm do cronograma (prazos) e dos recursos a serem alocados (humanos, hardwares e softwares). Estas atividades do processo podem ser realizadas tanto por desenvolvedores (quando demandam agentes humanos) quanto automaticamente (quando demandam a invocao de ferramentas autnomas). Essas questes fazem parte da fase do ciclo de vida de processos de software denominada execuo de processos de software (REIS, 2003). A fase de execuo de processos de software ocorre quando um modelo de processo est pronto para execuo, ou seja, o processo deve estar instanciado. Esta fase envolve questes importantes acerca de planejamento, controle, monitorao, garantia de conformidade com o processo modelado, treinamento, segurana e recuperao do processo (FEILER e HUMPHREY, 1993). De acordo com Oliveira (2006), o termo mais frequentemente utilizado na literatura para designar esta rea de execuo de processos process enactment, que significa que o processo no ser totalmente automatizado como sugere o termo execuo, mas sim executado por pessoas e mquinas. Neste trabalho ser adotado o termo execuo por ser mais utilizado na literatura nacional. Apesar de no ser totalmente automatizada, a fase de execuo depende de um mecanismo automatizado que compreenda o processo modelado e oriente os desenvolvedores no decorrer do seu trabalho, bem como execute automaticamente algumas tarefas (principalmente as repetitivas). Este mecanismo de execuo consiste na interpretao do modelo de processo instanciado de acordo com a semntica da linguagem de modelagem, gerenciando as informaes do ambiente e orientando os desenvolvedores de acordo com este modelo (HUFF, 1996). No entanto, processos de software possuem caractersticas peculiares, pois envolvem pessoas realizando tarefas criativas, no sendo, assim, possvel prever antecipadamente todo o desenvolvimento de software (SOMMERVILLE, 2010). Por este motivo, o mecanismo de execuo de processos deve ser capaz de lidar com: processos incompletos, incertezas e no-determinismos, escolhas entre caminhos alternativos durante a execuo, os quais podem depender de resultados de atividades anteriores (REIS, 2003). O atendimento destes requisitos define, de forma geral, a caracterstica de Flexibilidade na fase de execuo de processos a ser considerada neste trabalho.

44 O principal foco desta dissertao justamente esta rea de execuo de processos. Sendo assim, nesta seo apresentada uma viso geral sobre execuo de processos de software, a partir de sua definio e de algumas caractersticas consideradas relevantes no contexto deste trabalho. Alm disso, sero apresentados, tambm, um referencial terico desta rea e os principais trabalhos relacionados execuo semi-automatizada de processos de software.

2.4.1

Contextualizao da Execuo de Processos

Processos de software naturalmente tendem a evoluir, devido necessidade de estarem sendo continuamente melhorados em funo da instabilidade e competitividade do seu ambiente de negcios (SOFTEX, 2011b). Alcanar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software quanto dos processos de produo deste software. A partir desta abordagem, definiu-se um ciclo de vida para processos de software anlogo ao ciclo de vida de produtos de software. As atividades deste ciclo so chamadas de meta-atividades, j o ciclo de vida chamado de meta-processo de software (DERNIAME, KABA e WASTELL, 1999). As fases do meta-processo so representadas em alto nvel de abstrao, de forma que cada fase pode ser decomposta em sub-fases de pouca granularidade (HUMPHREY, 1989). Em outras palavras, o modelo primeiro estabelecido para representar o mundo real inicial, e, durante seu tempo de vida, exposto a mudanas causadas por eventos planejados e no planejados, externos e internos ao ambiente organizacional (OLIVEIRA, 2006). A Figura 2.8 apresenta um exemplo de meta-processo, derivado do ambiente ImPProS (Ambiente de Implementao Progressiva de Processo de Software) (OLIVEIRA, 2007). O meta-processo definido neste ambiente foi estabelecido como base para a abordagem de ciclo de vida de processos adotado neste trabalho. Este ambiente ser, posteriormente, detalhado na Subseo 2.4.3.

45

Figura 2.8 - Meta-Processo do Ambiente ImPPros (Adaptado de OLIVEIRA, 2007)

Uma das fases que se destaca neste meta-processo a de Execuo do Modelo de Processo, foco deste trabalho. Nesta etapa o modelo de processo instanciado executado atravs da invocao de ferramentas para guiar e assistir a realizao do processo no mundo real. Alm destes agentes automatizados, nesta fase h a participao de agentes humanos, atravs de: um gerente do processo que dever acompanhar a execuo e a avaliao do processo, analisando seu desempenho; e usurios do processo (desenvolvedores), responsveis pela realizao do processo. importante destacar, tambm, o papel do projetista de processo, responsvel por descrever o processo a ser executado atravs de uma linguagem de modelagem. Este paradigma de modelagem adotado influencia fortemente o mecanismo de execuo de processo de software (REIS, 2003). Entretanto, em alguns casos, a linguagem que modela o processo de software pode no ser utilizada para instanciar o modelo de processo na fase de execuo. Na Subseo 3.3.1 sero apresentados alguns destes casos. Um dos componentes desta fase de execuo chamado Mquina de Processo (REIS, 2003), responsvel pela coordenao das atividades que devem ser realizadas por pessoas e por ferramentas automatizadas. De acordo com Reis (2003), esta mquina de interpretao de processo deve: garantir a execuo das atividades na sequncia definida no modelo de processo (fluxo de controle); a repetio de atividades; a informao de feedback sobre o andamento do processo; a gerncia das informaes do processo; a coleta automtica de mtricas; a mudana

46 do processo durante sua execuo; a interao com as ferramentas do ambiente e a gerncia da alocao de recursos. Durante a execuo de processo de software so manipuladas informaes sobre o prprio processo, como tempo (estimado e realizado) e estado do processo. Isto significa que uma das tarefas do mecanismo de execuo manter o estado do processo consistente com o seu estado real (OLIVEIRA, 2006). O estado real do processo representado pelo componente Realizao do Processo, conforme mostra a Figura 2.8. Este componente deve receber orientao e suporte do componente Mquina de Execuo, atravs de feedbacks, a fim de manter esta consistncia entre o estado de execuo e o estado da realizao. Nesta subseo foram apresentados alguns conceitos e componentes associados execuo de processos, a fim de contextualizar esta fase do meta-processo de software. A subseo a seguir descreve as caractersticas associadas a estes componentes, alm de alguns requisitos inerentes a esta fase de execuo.

2.4.2

Caracterizao da Execuo de Processos

Para que os conceitos apresentados na subseo anterior sejam tratados de maneira adequada, algumas questes genricas devem ser tratadas pelo mecanismo de execuo (REIS, 2000) (OLIVEIRA, 2006): Automao do Processo: ativar automaticamente as atividades que podem ser executadas sem interveno humana, atravs de uma integrao com ferramentas de apoio ao processo; Trabalho Cooperativo: apoiar a coordenao e cooperao de pessoas trabalhando em um projeto de software atravs da orientao e assistncia durante todo o ciclo de vida de desenvolvimento. Em particular, deve assegurar que dependncias, restries de tempo e de recursos devem ser satisfeitas durante a execuo do processo; Monitorao: prover diferentes vises do estado da execuo do processo, permitindo que o gerente de projetos obtenha informaes relevantes sobre o andamento correto das atividades;

47 Registro da Histria do Processo: coletar dados da evoluo do processo para permitir que este processo melhore onde houver necessidade e seja corrigido para atender novos requisitos. A fim de tratar as questes acima descritas, foram estabelecidos, a partir da anlise apresentada em (FROEHLICH, 1994), alguns requisitos que devem ser satisfeitos pelo mecanismo de execuo. Esses requisitos relacionam-se com a forma de tratar a interferncia humana na execuo de processos, a preservao da consistncia e recuperao no caso de inconsistncias, a capacidade de permitir modificao dinmica durante a execuo, a integrao com ferramentas de apoio, o controle de acesso a artefatos do processo, as verses dos artefatos e sua gerncia, dentre outros. Estes aspectos diferenciam mecanismos de execuo e devem ser levados em considerao na sua definio. Sendo assim, as decises tomadas com relao a estes requisitos definem as caractersticas especficas de cada um destes mecanismos de execuo. As questes tratadas possuem diversas implicaes no projeto de uma mquina de execuo. Esta mquina composta por alguns componentes considerados necessrios para garantir as suas caractersticas bsicas. Um destes componentes o Gerenciador da Execuo (REIS, 2000), mecanismo responsvel pelo: controle dos estados das atividades e suas transies; sequncia de atividades do processo; alocao de recursos; verificao de restries do processo; e invocao de ferramentas quando necessrio. Este componente pode ser definido como um interpretador de processos e deve ser construdo com base na semntica da linguagem de modelagem de processos adotada. Normalmente, este componente trabalha com um formalismo considerado de baixo nvel devido sua complexidade e requer uma traduo do formalismo de alto nvel da modelagem para o formalismo de baixo nvel da execuo. Os tipos mais comuns de formalismos de execuo so apresentados sucintamente a seguir (REIS, 2000): Execuo Baseada em Regras: as atividades do processo so modeladas como regras com pr e ps-condies e o mecanismo de execuo assemelha-se a uma mquina de inferncia de um sistema especialista; Execuo Baseada em Regras ECA (Evento-Condio-Ao): o mecanismo de execuo verifica a ocorrncia de eventos e a pr-condio

48 das regras e, ento, dispara as aes que satisfazem a condio e o evento gerando novos eventos a serem tratados; Execuo Baseada em Redes de Tarefas: as atividades so encadeadas em uma rede com vrios nveis, expressando sua ordem de precedncia, dependncia de produtos e paralelismo; Execuo Baseada em Redes de Petri: utiliza o formalismo matemtico de Redes de Petri, onde as transies representam eventos que podem ocorrer e a topologia da rede descreve a relao de precedncia entre os eventos; Execuo Procedimental: modela os processos de software em paradigmas similares programao convencional, considerando o processo de software um caso particular de software. Alm das questes discutidas anteriormente, importante ressaltar que processos de software possuem caractersticas peculiares, pois envolvem pessoas realizando tarefas criativas, conforme citado na introduo desta seo. A caracterstica do mecanismo de execuo responsvel por lidar com caractersticas como processos incompletos, incertezas e no-determinismos, escolha entre caminhos alternativos, mudanas durante a execuo, dentre outros, denominada Flexibilidade. De acordo com estudo realizado em Reis (2003), constatou-se que o conceito de Flexibilidade no contexto da execuo de processos de software usado para definir a propriedade de mecanismos de execuo que toleram a informalidade, o envolvimento humano e processos incompletos sem deixar que os processos tornem-se inconsistentes. Uma dessas caractersticas diz respeito s mudanas, denominadas dinmicas, pois alteram definies enquanto so executadas em funo de falhas detectadas, necessidade de aperfeioamento ou simplesmente porque alguns aspectos da execuo de processos no puderam ser determinados antecipadamente. Estas mudanas dinmicas durante a execuo so bastante comuns e difceis de tratar, necessitando de suporte adequado por parte do mecanismo de execuo. Entretanto, a necessidade de suportar mudanas dinmicas implica na incluso de recursos especficos no formalismo de modelagem e no mecanismo de execuo (HUFF, 1996). Apesar da alta probabilidade de ocorrer mudanas durante a execuo do processo, necessrio manter a consistncia entre o estado de execuo e o esta-

49 do da realizao. Conforme descrito na Subseo 2.4.1, o mecanismo de execuo trata esta consistncia atravs de feedbacks. Estes feedbacks podem ser obtidos de vrias formas (OLIVEIRA, 2006): o usurio pode agir explicitamente de modo a avisar que concluiu uma atividade; questionamentos podem ser feitos para o usurio sobre o andamento do processo; uma ferramenta pode gerar um evento automaticamente; uma consulta ao banco de dados do ambiente pode obter esse feedback; ou o prprio banco de dados pode gerar eventos (banco de dados ativo). Entretanto, na maioria dos casos, algum tipo de deciso do usurio necessria para prover informaes sobre eventos significativos. importante ressaltar que as linguagens de modelagem de processos devem contribuir tanto com a flexibilidade de execuo quanto com o suporte s mudanas dinmicas durante a execuo, atravs de construtores adequados, que facilitem a adoo destes conceitos, sendo que o mecanismo de execuo o componente responsvel por interpretar o modelo descrito por esta linguagem. Nesta subseo foram apresentadas as principais caractersticas e requisitos inerentes execuo de processos. A subseo a seguir apresenta os trabalhos relacionados a esta rea, que fazem uso destes requisitos e adotam um determinado formalismo de execuo.

2.4.3

Trabalhos Relacionados Execuo de Processos

Paralelamente ao surgimento das primeiras propostas de um ciclo de vida para o software tiveram origem as pesquisas relacionadas tecnologia de processo de desenvolvimento de software. Esta tecnologia baseia-se no conceito de que o processo de software seja descrito formalmente, a fim de propiciar a sua automao, verificao, aperfeioamento e reutilizao (REIS, 2000). Um dos conceitos associados a esta tecnologia diz respeito s ferramentas CASE (Computer-Aided Software Engineering), que culminou com o surgimento de ambientes de desenvolvimento de software (ADS), estabelecendo, assim, uma cultura de utilizao de ferramentas para auxiliar a automao do desenvolvimento. Estes ADSs fornecem uma base de integrao para a utilizao de ferramentas CASE durante todo o processo de software.

50 Neste contexto, surgiram os PSEEs (Process-Centered Software Engineering Environments) a partir da necessidade de se incorporar aos ADSs mecanismos para o controle do processo de desenvolvimento, permitindo a descrio do processo e o acompanhamento das atividades pelo ambiente (OLIVEIRA, 2007). Conforme citado anteriormente, a fase de execuo de processos acontece quando um modelo de processo est pronto para execuo e leva em considerao a coordenao dos desenvolvedores, a interao entre as ferramentas e desenvolvedores, a garantia de que o processo est sendo executado conforme modelado, dentre outras questes. Com o apoio de um ambiente de desenvolvimento de software possvel obter resultados relevantes acerca do andamento da execuo, alm de possibilitar uma melhor gerncia do desenvolvimento (REIS, 2003). A Mquina de Execuo de processos o componente que diferencia ADSs comuns dos orientados a processos (REIS, REIS e NUNES, 2002). A mquina de execuo executa ou interpreta o modelo de processo instanciado e gerencia o restante do ambiente e os desenvolvedores de acordo com esse modelo. Nas diversas abordagens encontradas na literatura especializada no que diz respeito ao conceito de mquina de execuo, a maioria relaciona-se a um PSEE. A seguir so descritas caractersticas de alguns PSEEs, com foco no mdulo de execuo de processos e de apoio avaliao e melhoria de processos de software. Posteriormente, sero apresentados alguns pontos fortes, pontos fracos e oportunidades de melhoria destas abordagens. O WebAPSEE (LIMA, FRANA, et al., 2006) um ambiente para gesto de processos baseado em software livre. Foi concebido entre 2004 e 2005 como esforo de cooperao entre instituies acadmico-cientficas, destacando-se dentre estas o Laboratrio de Engenharia de Software da Universidade Federal do Par (LabES/UFPA), e um parceiro industrial, a Regional Belm do Servio Federal de Processamento de Dados (SERPRO). Utiliza a linguagem visual WebAPSEE-PML (Process Modeling Language) para modelagem de processos que adota a especificao formal com abordagem de gramticas de grafos, definida em Reis (2003). Este ambiente segue o paradigma de processo orientado a atividades, descrevendo um processo como uma coleo parcialmente ordenada de atividades. Em (FRANA, SALES, et al., 2009), destaca-se o uso deste ambiente na adoo do MPS.BR nvel G, numa organizao desenvolvedora de software, atravs da relao entre as funcionalidades destas e os resultados esperados dos processos

51 de Gerncia de Projeto (GPR) e de Gerncia de Requisitos (GRE). No entanto, nem todos os resultados esperados possuem evidncias diretas de atendimento pelo WebAPSEE, como, a rastreabilidade de requisitos integrada ao ambiente. Adicionalmente, esta relao no apresentada explicitamente, evidenciando quais funcionalidades atendem a implementao dos resultados esperados do nvel G do MPS.BR. O ambiente ODE (Ontology-based software Development Environment) foi concebido no Laboratrio de Engenharia de Software da Universidade Federal do Esprito Santo (LabES/UFES), tendo por base ontologias (GUIZZARDI, FALBO e GUIZZARDI, 2008). A premissa do Projeto ODE est baseada no argumento de que as ferramentas de um ADS construdo com base em ontologias permitem, mais facilmente, a integrao delas com diferentes ferramentas que apoiam atividades de engenharia de software correlacionadas. Este ambiente estabelece uma ontologia especfica para Qualidade de Software. A Estao TABA (TRAVASSOS, 1994), desenvolvida desde 1990, um metaambiente que tem por objetivo a gerao de ambientes de desenvolvimento de software adequados s particularidades de organizaes, processos de software e projetos especficos. A sua principal motivao est no fato de que os domnios de aplicao e projetos especficos possuem caractersticas prprias, sendo fundamental que tais caractersticas estejam presentes, de forma customizada, nos ambientes utilizados pelos engenheiros de software para o desenvolvimento de tais aplicaes. Posteriormente, foram adicionadas neste ambiente duas ferramentas relacionadas Avaliao e Melhoria de Processos: AvalPro e Pilot (ESTOLANO, 2005). A ferramenta AvalPro apoia as atividades do grupo de Garantia da Qualidade do Processo e do Produto (GQPP) da organizao. Seu principal objetivo apoiar o grupo de GQPP na avaliao de processos instanciados em projetos da organizao. J a Pilot apoia a realizao de avaliao de propostas de melhoria de um processo de forma sistemtica, planejada e controlada atravs de projetos-piloto para que essas melhorias possam ser observadas e mensuradas antes de serem institucionalizadas dentro de uma organizao. Atravs destas ferramentas, a Estao TABA afirma seu suporte direto s reas de processo do CMMI 2 e 3 e nveis G a C do MPS.BR. ImPProS (OLIVEIRA, 2007) um ambiente de apoio implementao de um processo de software em uma organizao de forma progressiva. Sua abordagem

52 leva em considerao o uso de modelos e normas da qualidade que orientem a melhoria contnua do processo e a transformao do processo de software com base nos possveis mapeamentos entre os modelos e normas da qualidade. O Quadro 2.3 resume as caractersticas destes ambientes para execuo e melhoria de processos de software, comparando-as com a proposta apresentada neste trabalho. Observa-se que, de um modo geral, esses ambientes executam processos modelados a partir de linguagens prprias e que, geralmente, so desenvolvidas sem levar em considerao as boas prticas de execuo de processos existentes nos padres e modelos de qualidade adotados pela indstria de software.
Quadro 2.3 - Comparao entre Abordagens de Execuo de Processo

Diferentemente destes ambientes, a proposta apresentada neste trabalho apresenta um formalismo de execuo baseado no padro SPEM, permitindo a execuo de modelos de processos sem utilizar modelos intermedirios, conforme detalha o Captulo 3. Alm disto, esta abordagem leva em considerao os modelos de qualidade MR-MPS e CMMI-DEV, atravs da utilizao de boas prticas relacionadas ao grau de institucionalizao com que os processos so executados em uma organizao desenvolvedora de software, conforme apresenta o Captulo 4.

53 2.5 CONSIDERAES FINAIS

O processo de desenvolvimento de software constitui o elemento base do Framework proposto neste trabalho. Dessa forma, o entendimento dos conceitos bsicos relacionados ao processo de software, bem como dos elementos que o constituem, so essenciais para a compreenso dos objetivos e contexto dessa proposta. Assim, neste captulo foi apresentada uma viso geral em relao a processos de software e seus principais elementos. Alguns conceitos relacionados definio e melhoria do processo de software, tambm, foram apresentados. Alm disso, a abordagem para execuo de processos de software utilizada nesse trabalho foi explicada. Essa abordagem consiste na definio de modelos executveis levando em considerao as caractersticas especficas de cada projeto e os requisitos inerentes a um mecanismo de execuo. Foram apresentados, tambm, alguns PSEEs que implementam este mecanismo de execuo. Observa-se que a maioria destes ambientes adota linguagem prpria de modelagem e, geralmente, so desenvolvidos sem levar em considerao as prticas de execuo de processos recomendadas pelos modelos de qualidade. Diante deste cenrio, apresenta-se no Captulo 3 uma proposta de linguagem de execuo de processos modelados a partir do padro SPEM 2.0 que objetiva apoiar a execuo de processos de forma aderente s recomendaes dos modelos de qualidade CMMI-DEV Nvel 2 e MR-MPS Nvel F.

54

A LINGUAGEM DE EXECUO DE PROCESSOS

Conforme discutido na Seo 2.2, modelos de processos de software podem ser utilizados para apoiar a comunicao, entendimento, gerenciamento, definio, avaliao e melhoria do processo de software. Com o intuito de atender a demanda por mecanismos que permitissem explicitar e construir estes modelos de processos, diversas linguagens para modelagem de processos (identificadas pelo termo PML Processes Modeling Language) foram elaboradas. Essas linguagens devem apresentar um conjunto mnimo de capacidades necessrias para representar um processo de software de forma precisa e abrangente (FUGGETTA, 2000). De acordo com o exposto na Subseo 2.4.1, possvel estabelecer um ciclo de vida para processos de software, conhecido como meta-processo. Uma das fases deste meta-processo a Execuo do Processo. O objetivo da linguagem de modelagem nesta fase descrever um modelo de processo com um nvel de detalhes suficiente para permitir que o mesmo seja executado (CONRADI e LIU, 1995). Um modelo de processo que possua esse nvel de detalhes caracteriza-se como um modelo executvel. Entretanto, em alguns casos, a linguagem de modelagem pode no apresentar requisitos suficientes para definir um modelo executvel. Nestes casos, geralmente, utiliza-se uma linguagem intermediria de processos, que permite traduzir um modelo de processo bsico para um modelo executvel (FEILER e HUMPHREY, 1993). Esta linguagem intermediria pode ser definida como uma linguagem de execuo, pois permite a especificao de modelos abstratos que estendem a semntica de processos a fim de que estes possam ser automatizados (OMG, 2011). Este captulo apresenta uma linguagem de execuo de processos denominada xSPIDER_ML. Para definir esta linguagem, inicialmente identificou-se qual seria o padro de modelagem mais adequado atravs de uma anlise comparativa, apresentada na Seo 3.1. Em seguida, apresenta-se a linguagem de modelagem SPIDER_ML, na Seo 3.2, um perfil do SPEM que serviu de base para definio da

55 xSPIDER_ML. Por fim, apresenta-se, na Seo 3.4, uma avaliao desta linguagem de execuo atravs de uma prova de conceito.

3.1

ANLISE COMPARATIVA ENTRE O SPEM E O BPMN

Antes de definir a linguagem de execuo, fez-se necessrio identificar qual o padro de modelagem existente no mercado mais adequado para representar os processos de software que posteriormente seriam executados. Sendo assim, identificaram-se duas abordagens que possuem bastante aceitao pela indstria de software na rea de modelagem: SPEM (Software Process Engineering Metamodel) e BPMN (Business Process Modeling Notation). Esta aceitao deve-se, em grande parte, ao suporte que ambas recebem da OMG (Object Management Group). A OMG (OMG, 1997) uma organizao que possui grandes empresas como membros, sendo mundialmente reconhecida, e que tem por objetivo aprovar e manter padres abertos para aplicaes orientadas a objetos. O SPEM (OMG, 2008) um padro estabelecido para especificar, definir processos e seus componentes. Seu modelo foi construdo a partir de um subconjunto, chamado de SPEM Foundation, do metamodelo da UML 1.4 (OMG, 2001). O SPEM oferece algumas representaes e esteretipos para modelar seus principais elementos em diagramas UML (Unified Modeling Language). Atualmente, encontra-se na verso 2.0. J o BPMN (OMG, 2011) um padro proveniente da metodologia de gerenciamento de processos de negcio e se trata de um conjunto de notaes para o desenho de processos. O objetivo do BPMN apoiar a gesto de processos de negcios, tanto para usurios tcnicos quanto para usurios de negcios. Foi desenvolvido pela BPMI (Business Process Management Initiative) e, atualmente, encontra-se na verso 2.0. A partir destes padres, realizou-se uma pesquisa (ver Apndice A) que teve como objetivo avaliar a representatividade dos padres SPEM e BPMN na modelagem de processos de software que adotam prticas do modelo CMMI-DEV e MRMPS. Esta pesquisa consistiu em uma anlise comparativa entre os componentes que constituem cada um destes modelos e as notaes destes padres de modelagem, a partir de suas semnticas e aplicaes.

56 A fim de atender este objetivo, inicialmente, definiu-se uma estrutura padro para processos de software sob a forma de um modelo de processo e sua representao diagramtica. Esta estrutura baseou-se em um modelo derivado de uma ontologia de fundamentao, denominada UFO (Unified Foundational Ontology) (GUIZZARDI, FALBO e GUIZZARDI, 2008), aplicada no domnio de processos de software no Projeto ODE (Ontology-based software Development Environment). Assim, com base nesta estrutura padro do processo de software e nas notaes definidas pelo SPEM e BPMN para representar os processos e seus elementos, realizou-se um mapeamento. Este mapeamento levou em considerao, tambm, os componentes dos modelos CMMI-DEV e MR-MPS a fim de representar estruturalmente um modelo de referncia para processos de software em geral. Este mapeamento entre padres de modelagem e modelos de qualidade pode levar concluso de qual padro conferir maior produtividade e qualidade aos processos de desenvolvimento de software. A fim de auxiliar o atendimento deste propsito, esta pesquisa apresentou um experimento. Este experimento tem por objetivo apresentar um cenrio mais prtico do uso dos padres de modelagem de processo SPEM e BPMN, no contexto de modelos de qualidade do processo, a partir da modelagem de reas do processo e processos destes modelos. Alm disto, este experimento permitiu a avaliao do mapeamento apresentado nesta pesquisa. O mapeamento, bem como o experimento e a anlise comparativa entre estes padres de modelagem so apresentados em detalhes em um Relatrio de Pesquisa (PORTELA, 2011), disponvel no Apndice A deste trabalho. Alm disto, esta pesquisa foi recentemente publicada no Journal of Software Engineering and Applications (PORTELA, VASCONCELOS, et al., 2012a). A partir deste experimento, concluiu-se que o SPEM possui uma maior diversidade de componentes e caractersticas necessrias para representar processos de software com uma semntica adequada. No entanto, o BPMN, apesar de no possuir tanta expressividade na representao de processos de software, tende a ser mais facilmente compreendido por profissionais no especialistas alm de ser mais facilmente integrado com os demais processos organizacionais. Espera-se que as concluses desta anlise comparativa, aliadas aos resultados obtidos nesse trabalho, forneam subsdios para auxiliar as organizaes desenvolvedoras de software a optarem por qual tecnologia seria mais adequada na definio e modelagem de seus processos de desenvolvimento.

57 3.2 A LINGUAGEM DE MODELAGEM SPIDER_ML

A partir da anlise comparativa descrita na Seo 3.1 e apresentada no Apndice A, constatou-se que o padro SPEM possui uma maior representatividade no que diz respeito a processos de software, levando em considerao o fato de que este foi estabelecido com o intuito de atender este propsito. J o BPMN, apesar de tender a ser mais facilmente compreendido e objetivar a integrao entre processos organizacionais, no possui tanta expressividade na representao de processos de software, com base no experimento realizado. Esta avaliao entre os padres de modelagem contribuiu para a concepo da SPIDER_ML (Modeling Language) (BARROS, 2009), uma linguagem de modelagem caracterizada como um perfil do SPEM 2.0. A SPIDER_ML foi criada a partir de um levantamento e anlise de diversas linguagens para modelagem apresentada em (OLIVEIRA, 2006) e com base em observaes realizadas durante a implementao de programas da melhoria dos processos organizacionais (OLIVEIRA, VASCONCELOS e MENDES, 2006). A partir destas observaes, obteve-se um conjunto de prticas frequentemente utilizado pela indstria de software, como por exemplo, a adoo do padro SPEM. No entanto, observou-se que apenas um conjunto bsico de elementos do SPEM era de fato adotado no processo de modelagem. Mediante estas constataes, a linguagem SPIDER_ML apresenta como principais objetivos (BARROS e OLIVEIRA, 2010a): incorporar e formalizar as prticas de modelagem de processos utilizadas pela indstria de software; refinar e reutilizar o conjunto de elementos do SPEM e da UML; e tornar a modelagem de processos mais simples a partir de um conjunto reduzido de elementos, se comparado com o conjunto de elementos do SPEM, mas suficiente para permitir a modelagem de quaisquer processos de software que sejam utilizados nas organizaes. Buscando atender estes objetivos, a SPIDER_ML foi concebida a partir de 16 elementos provenientes do SPEM 2.0. Estes elementos so organizados a partir de duas estruturas de processos: o Processo Padro e o Processo Instanciado. A seguir, o Quadro 3.1 apresenta os elementos que compem a estrutura do Processo Padro. Como os elementos referentes estrutura do Processo Instanciado so reutilizados pela linguagem de execuo apresentada neste captulo, estes somente sero apresentados na Subseo 3.3.3.

58
Quadro 3.1 - Elementos do Processo Padro (BARROS, 2009) Notao Elemento Descrio

Processo Padro Disciplina Definio de Tarefa Definio de Papel Definio de Produto de Trabalho Definio de Ferramenta

O conjunto de todos os ativos do processo de software que so reutilizveis. Um conjunto de definies de tarefa que contribuem para o atendimento de um mesmo objetivo do Processo Padro. Um trabalho reutilizvel e que no pode ser decomposto. Um conjunto de capacidades desejadas para um determinado papel que pode ser reutilizado em diferentes Processos Instanciados. Um conjunto de caractersticas desejadas para um produto de trabalho que pode ser reutilizado em diferentes Processos Instanciados. Um conjunto de caractersticas desejadas para uma ferramenta que pode ser reutilizada em diferentes Processos Instanciados.

Estas estruturas so descritas por meio de diagramas UML, onde: o diagrama de pacotes descreve o Processo Padro; o diagrama de atividades expressa o Processo Instanciado; e o diagrama de classes mostra as associaes existentes entre os elementos. Para fazer uso destes diagramas, a SPIDER_ML adota 7 relacionamentos da UML: associao, transio, dependncia, agregao, composio, generalizao e ncora de nota. O detalhamento destes elementos, bem como da estrututura da SPIDER_ML, esto disponveis na sua especificao tcnica (BARROS, 2009). A linguagem SPIDER_ML adotada pela ferramenta de modelagem de processos Spider-PM (Process Modeling) (BARROS e OLIVEIRA, 2010b), desenvolvida pelo Projeto SPIDER (OLIVEIRA, YOSHIDOME, et al., 2011), sob licena GPL (General Public License), disponvel em http://spider.ufpa.br/index.php?id=resultados. A sintaxe da SPIDER_ML foi adotada, tambm, como base para definio dos modelos de processo que tero sua execuo simulada atravs da ferramenta de simulao de processos de software denominada SPSM (Software Process Simulator Machine) (CHAVES, TAVARES, et al., 2010). No entanto, a SPIDER_ML, assim como o SPEM, no possui mecanismos nativos para simulao e execuo automatizada do processo de software. Sendo as-

59 sim, prope-se, na Seo 3.3, a linguagem xSPIDER_ML, criada com o intuito de permitir que processos modelados a partir da SPIDER_ML possam ser executados.

3.3

A LINGUAGEM DE EXECUO XSPIDER_ML

Conforme citado na Seo 3.2, a linguagem SPIDER_ML, assim como o SPEM, no oferece mecanismos nativos para simulao e execuo automatizada do processo de software, ou seja, no apresenta um conjunto de conceitos e uma semntica comportamental que permita a sua execuo. Diante deste contexto, dando prosseguimento s pesquisas realizadas no Projeto SPIDER, optou-se por definir a linguagem de execuo xSPIDER_ML. A xSPIDER_ML (eXecutable SPIDER_ML) uma extenso da linguagem de modelagem SPIDER_ML que objetiva apoiar a execuo de processos de forma flexvel. Esta linguagem uma das bases para definio das atividades do framework proposto neste trabalho.

3.3.1

Trabalhos Relacionados

Existem algumas abordagens que propem a automatizao da execuo de processos de software a partir do SPEM. A fim de alcanar este objetivo, duas destas abordagens (BENDRAOU, COMBEMALE, et al., 2007) (ZORZN e RIESCO, 2008) aplicam tcnicas de transformao aos modelos especificados no padro SPEM para uma especificao de subprocessos no padro BPMN (OMG, 2011), com o intuito de torn-los executveis a partir de BPEL (Business Process Execution Language), uma linguagem que permite a execuo de processos BPMN. Em (BENDRAOU, COMBEMALE, et al., 2007), prope-se uma extenso do SPEM 2.0, denominada xSPEM (eXecutable SPEM), que fornece os conceitos necessrios para executar um modelo de processo SPEM. Um subconjunto de notaes SPEM 2.0 utilizado como base sendo adicionadas outras caractersticas, como definio de recursos concretos atribudos ao projeto e atividades de dimensionamento. Define, tambm, recursos para armazenamento de estados do processo

60 durante o tempo de sua execuo. Uma vez que tanto o modelo de processo e o modelo do projeto foram definidos, prope-se a validao destes modelos a partir de instrumentos formais (modelos de checagem disponveis na rea de Redes de Petri). Por fim, apresentam-se regras de mapeamento entre um subconjunto de conceitos da SPEM 2.0 e a linguagem BPEL para permitir que este possa ser executado. A abordagem apresentada em (ZORZN e RIESCO, 2008) prope que as atividades de desenvolvimento de software especificadas no SPEM sejam transformadas em uma especificao de subprocesso do BPMN. Esta transformao feita por uma Linguagem de Relaes definida a partir da abordagem QVT (Query/Views/Transformations). Em seguida, o subprocesso BPMN obtido transformado em uma especificao de uma linguagem padro para, ento, ser definido em linguagem de workflows de processos, tais como BPEL4WS (Business Process Execution Language for Web Services) e o XPDL (XML Process Definition Language). Por fim, o processo definido, de acordo com a linguagem selecionada, ser a entrada para um motor de workflow, como o Open Business Engine (que suporta XPDL) e o BPEL Process Manager (que suporta BPEL). Outra abordagem (MACIEL, SILVA, et al., 2009) apresenta uma proposta integrada para modelagem de processos MDA (Model Driven Architecture) e execuo com base em especializaes de alguns conceitos do SPEM. Esta especializao de conceitos do SPEM realizada a fim de estabelecer uma notao padro e representar explicitamente processos de software no contexto de MDA. Esta abordagem designa um conjunto de diagramas para modelar a estrutura e comportamento do processo MDA. Sendo assim, fornece as ferramentas de execuo de processos e os recursos especficos de um processo MDA (UML, perfil de aplicao de transformaes e gerao de cdigo) alm das caractersticas comuns de qualquer processo de software (atribuio de responsabilidades, gerenciamento de configurao, gesto de mudanas, etc.). Neste trabalho, especifica-se, tambm, um ambiente para apoiar esta proposta. Por fim, a abordagem apresentada em (KEDJI, THAT, et al., 2011) baseada em um metamodelo de processo colaborativo, constitudo de um meta-processo de modelagem e de execuo de processos. A fim de auxiliar projetistas de processo e gerentes de projeto, prope um editor de modelos de processos colaborativos, e um gerador de plano de projeto aderente a duas ferramentas populares de gerncia de projeto: MS Project e Gantt Project. Este trabalho foi realizado no contexto do Proje-

61 to Galaxy, que aborda o desenvolvimento colaborativo de sistemas complexos usando ambientes de desenvolvimento altamente heterogneos e seguindo o modelo MDE (Model Driven Engineering). O Quadro 2.3 resume as caractersticas destas abordagens para execuo de modelos de processos SPEM, comparando-as com a proposta apresentada neste trabalho.
Quadro 3.2 - Comparao entre Abordagens de Execuo de Modelos de Processo SPEM

Observa-se que, de maneira geral, estas abordagens apresentam algumas carncias, principalmente no que diz respeito preparao e manuteno da execuo de processos, a citar: Os principais elementos do SPEM que fornecem semntica apropriada para modelagem de processos de software no possuem equivalentes em BPMN, o que ocasiona a perda de semntica apropriada para modelagem de processos de software; As transformaes entre modelos impem algumas etapas de refinamento antes que eles possam ser executados; Estas abordagens demandam um grande esforo na manuteno do mapeamento entre modelos, no caso de ser realizada alguma alterao no processo durante a sua execuo. Este, por sua vez, cria o problema de rastreabilidade e anlise do impacto destas alteraes no modelo SPEM. Sendo assim, a partir do exposto nesta seo, constata-se que o padro SPEM no fornece nativamente quaisquer conceitos ou formalismos para execuo

62 de processos (BENDRAOU, COMBEMALE, et al., 2007) e que as abordagens que permitem a execuo destes processos, a partir da transformao de modelos, demandam um grande esforo para manter a correspondncia entre o modelo inicial (SPEM) e o modelo final (BPMN, MDA ou MDE). Diante deste cenrio, apresentamse, na Subseo 3.3.2, os objetivos e caractersticas da linguagem xSPIDER_ML que prope a execuo de modelos SPEM sem a necessidade de utilizar modelos intermedirios durante este processo.

3.3.2

Objetivos e Caractersticas da Linguagem xSPIDER_ML

Conforme exposto na Subseo 2.4.3, existem diversas abordagens para execuo de processos de software. Porm, a maioria dessas abordagens foi concebida a partir de estudos acadmicos que desconsideram as prticas de modelagem e execuo de processos adotadas pela indstria de software. Ao executar o processo de software segundo critrios prprios e prticas no formalizadas, estas abordagens podem no usufruir de todos os benefcios da execuo de processos. Apesar do SPEM ser o padro da OMG definido para modelagem de processos e apresentar bastante expressividade neste propsito, constatou-se, a partir da anlise dos trabalhos relacionados, apresentada na Subseo 2.4.3, que este ainda pouco adotado na fase de Execuo do Processo. Constata-se, tambm, que as abordagens que permitem a execuo de processos SPEM geralmente utilizam transformao de modelos que, por sua vez, apresentam bastante carncias, conforme exposto na Subseo 3.3.1. Assim, a linguagem xSPIDER_ML busca atender as organizaes que pretendem acompanhar a execuo de seus processos a partir da aplicao de regras e formalismos para os vrios componentes que estruturam o processo. Com base nestas premissas e de acordo com as linhas de pesquisas do Projeto SPIDER, a linguagem xSPIDER_ML apresenta como principais objetivos: executar modelos de processos definidos a partir das notaes da SPIDER_ML (consequentemente, do padro SPEM); manter a consistncia semntica das notaes do padro de modelagem durante a execuo;

63 propor um formalismo de execuo que pode ser adotado por uma Mquina de Execuo; permitir que a execuo do processo seja flexvel e ocorra de forma semiautomatizada. A xSPIDER_ML foi concebida como uma extenso da linguagem de modelagem SPIDER_ML, acrescentando a esta alguns componentes e organizando-os em uma estrutura, conforme descrito na Subseo 3.3.4, alm de regras de execuo, descritas na Subseo 3.3.5, que adicionam uma semntica comportamental linguagem SPIDER_ML. A partir desta estrutura de componentes e regras, os processos modelados a partir das notaes da SPIDER_ML, e consequentemente a partir das notaes do SPEM 2.0, podem ser formalmente executados. Como se trata de uma extenso da SPIDER_ML, esta abordagem no utiliza modelos intermedirios na fase de Execuo do Processo. Sendo assim, possvel manter a integridade semntica dos elementos utilizados durante a modelagem de processos na fase de execuo. O formalismo proposto pela xSPIDER_ML definido a partir das abordagens SPEM 2.0 (OMG, 2008), BPMN (OMG, 2011), xSPEM (BENDRAOU, COMBEMALE, et al., 2007), WebAPSEE (REIS, 2003) (LIMA, FRANA, et al., 2006) (FRANA, SALES, et al., 2009) e SPSM (CHAVES, TAVARES, et al., 2010). Essas abordagens incorporam conceitos referentes s fases de Definio, Simulao e Execuo do Processo, o que adiciona caractersticas especficas ao formalismo da xSPIDER_ML que permitem que este possa ser adotado por uma Mquina de Execuo. A abordagem referente aos conceitos de flexibilidade e execuo semiautomatizada baseada no trabalho de (REIS, 2003), sendo esta descrita na Subseo 2.4.2. Um exemplo de aplicao deste conceito de flexibilidade apresentado na Seo 3.4. Quanto execuo semi-automatizada, esta ocorre com o apoio de uma Mquina de Execuo, que coordena a aplicao do formalismo desta linguagem por agentes automatizados e agentes humanos. importante ressaltar que estas abordagens que serviram de referncias foram contextualizadas na xSPIDER_ML a fim de atender o propsito especfico de tornar a SPIDER_ML executvel. A estrutura de componentes, juntamente com a base de regras e demais conceitos associados (flexibilidade, associao entre elementos, hierarquia do processo, etc.), compem o formalismo da xSPIDER_ML.

64 este formalismo que fornece uma semntica comportamental que permite com que modelos de processos SPEM possam ser executados.

3.3.3

Componentes da Linguagem xSPIDER_ML

A execuo formal do processo ocorre sob os elementos que compem a estrutura dos Processos Instanciados, pois estes processos so aqueles que de fato sero executados pela organizao, levando-se em considerao os recursos disponveis e as caractersticas especficas do software que ser produzido (OLIVEIRA, 2007). Sendo assim, a linguagem xSPIDER_ML reutiliza os componentes da SPIDER_ML referente estrutura do Processo Instanciado, incorporando a estes atributos e comportamentos especficos para que possam ser executados. Estes componentes bem como suas descries so apresentados no Quadro 3.3.
Quadro 3.3 - Elementos do Processo Instanciado (BARROS, 2009) Notao Elemento Descrio

Processo Instanciado Fase Iterao Marco Atividade

Uma instncia do Processo Padro para um projeto especfico. Um perodo significativo de um Processo Instanciado. Um conjunto de atividades e tarefas que sero repetidas dentro de uma fase. Um evento significativo em um Processo Instanciado. Um trabalho que deve ser realizado no decorrer de um Processo Instanciado e que pode ser decomposto em outras atividades ou tarefas. Um trabalho que deve ser realizado no decorrer de um Processo Instanciado e que no pode ser decomposto. Um papel desempenhado por um recurso no Processo Instanciado. Um produto de trabalho consumido, gerado ou modificado em um Processo Instanciado. Representa uma conduta que deve ser adotada durante a realizao de uma tarefa do Processo Padro ou de um Processo Instanciado. Uma ferramenta que deve ser utilizada durante a realizao de uma tarefa em um Processo Instanciado.

Tarefa Instanciada Papel Instanciado Produto de Trabalho Instanciado Procedimento Ferramenta Instanciada

65 Aliando a estes elementos, a linguagem SPIDER_ML incorpora notaes do diagrama de atividades da UML, conforme descrito na Seo 3.2. O Quadro 3.4 apresenta estes elementos da UML que so utilizados em conjunto com as notaes do Processo Instanciado e, consequentemente, adotados pela xSPIDER_ML.
Quadro 3.4 - Elementos UML utilizados no Processo Instanciado (BARROS, 2009) Notao Elemento Descrio

Estado Inicial Estado Final

Representa o ponto de partida de um fluxo representado no Processo Instanciado. Representa um ponto para a finalizao de um fluxo descrito no Processo Instanciado. Indica um ponto onde existem dois ou mais caminhos que podem ser seguidos, mas apenas um desses caminhos ser seguido. Tambm indica o ponto onde dois ou mais fluxos alternativos se unem novamente e um nico fluxo. Representa um ponto que inicia a execuo em paralelo de dois ou mais fluxos. Representa um ponto onde dois ou mais fluxos que ocorrem em paralelo so finalizados. Representa uma transio entre duas fases, iteraes, atividades, tarefas e demais elementos de um processo instanciado. Representa uma descrio ou informao adicional que pode ser provida a respeito de um componente, conectado atravs de uma ncora.

Deciso e Unio

Barra de Separao Barra de Juno Transio

Nota e ncora

O uso destes elementos da UML tende a facilitar o aprendizado da linguagem, considerando o reaproveitamento de conhecimentos comuns aos profissionais envolvidos com o processo de software no que diz respeito modelagem. De forma semelhante, a adoo das notaes do SPEM traz diversas vantagens, como a facilidade do entendimento dos modelos de processos, independente de qual processo de software esteja representado, pois estas notaes so padronizadas. Outra vantagem a manuteno e constante evoluo destes padres (UML e SPEM), devido ao suporte que ambos recebem da OMG.

66 3.3.4 Estrutura da Linguagem xSPIDER_ML

A fim de agrupar o conjunto de elementos que compem a xSPIDER_ML, de acordo com as suas caractersticas e finalidade, definiu-se uma estrutura em pacotes. O objetivo dessa estruturao em pacotes fornecer s organizaes meios para definir uma estrutura conceitual, proporcionando as noes necessrias para execuo de seus processos de desenvolvimento de forma semi-automatizada. Levando em considerao que o objetivo da xSPIDER_ML tornar executvel a linguagem de modelagem SPIDER_ML, a qual se caracteriza como um perfil da SPEM, optou-se por definir sua estrutura com base na estrutura proposta pelo xSPEM, apresentada em (BENDRAOU, COMBEMALE, et al., 2007), j que ambas as abordagens possuem o objetivo de tornar a SPEM 2.0 executvel. Sendo assim, a estrutura da xSPIDER_ML, como mostra a Figura 3.1, foi dividida em 5 (cinco) pacotes: xSPIDERML_Core, ProcessParameters, ProjectVariables, EventTypes e ProcessTrace.

Figura 3.1 - Estrutura de Pacotes da xSPIDER_ML (PORTELA e GOMES, 2011b)

67 Por razes de clareza, ser apresentado apenas um subconjunto de conceitos necessrios execuo do processo, selecionados de acordo com a sua relevncia para o entendimento da avaliao apresentada na Seo 3.4 deste captulo. O detalhamento dos demais conceitos e elementos que compem a xSPIDER_ML esto disponveis na sua especificao tcnica (PORTELA e GOMES, 2011b), disponvel no Apndice B deste trabalho. Devido execuo atuar diretamente sob os Processos Instanciados, conforme citado anteriormente, os elementos da SPIDER_ML relacionados a este (classes em amarelo), descritos no Quadro 3.3, so reagrupados no pacote xSPIDERML_Core. Alm destes elementos, o pacote xSPIDERML_Core reaproveita conceitos e elementos oferecidos pela xSPEM (classes em verde) a fim de fornecer todos os elementos necessrios para se definir e estruturar um processo de software para sua posterior execuo. Estes elementos definem a base para todos os demais pacotes da xSPIDER_ML e so apresentados na Figura 3.2.

Figura 3.2 - Classes do Pacote xSPIDERML_Core

Neste pacote destaca-se o componente Activity, uma especializao de WorkBreakdownElement e WorkDefinition, que define unidades bsicas de trabalho dentro de um processo, bem como um processo em si. Em outras palavras, cada

68 atividade representa um processo de acordo com o SPEM 2.0. Este componente relaciona-se com WorkProductUse atravs de instncias da classe ProcessParameter e relaciona-se, tambm, com RoleUse atravs de instncias de ProcessPerformerMap (um conjunto de competncias necessrias para executar uma atividade). A classe Process representa um conjunto de definies de trabalho parcialmente ordenados com a inteno de atingir metas de desenvolvimento, como a entrega de um sistema de software especfico. Estes Processos caracterizam-se como sequncias de Phases e Milestones e expressam o ciclo de vida de um produto em desenvolvimento. Phase uma classe que representa um perodo significativo de tempo para um projeto, onde, normalmente, ao seu final ocorrem pontos de controle, marco ou a entrega de um ou mais produtos para o cliente. Milestone um WorkBreakdownElement que representa um evento significativo para um projeto de desenvolvimento, onde, normalmente, ocorrem situaes como: tomadas de decises importantes ou a finalizao da construo de produtos de trabalho entregveis. Iteration consiste de um conjunto de atividades e tarefas que deve ser executado repetidamente. Ao final de uma iterao pode ocorrer um marco do projeto. Destaca-se, ainda, neste pacote, a classe TaskUse que um WorkBreakdownElement que representa uma instncia para uma TaskDefinition. TaskDefinition uma classe presente na estrutura do SPEM 2.0 e na SPIDER_ML, no contexto de uma atividade especfica. Esta classe deve fornecer informaes que estejam relacionadas com os recursos que de fato estaro envolvidos durante a execuo da tarefa que o mesmo representa, como procedimentos, ferramentas e recursos humanos. Durante a execuo, o processo evoluir de um estado para outro. Neste contexto, entende-se por estado a situao em que o processo encontra-se em relao execuo: no iniciado, em execuo, pausado, finalizado. A partir deste estado, possvel determinar em qual momento do desenvolvimento o projeto encontra-se. Assim, faz-se necessrio fornecer conceitos para a caracterizao de todos estes estados do processo durante o tempo de sua execuo. Este o objetivo do pacote ProcessParameters. O pacote ProcessParameters define propriedades que os elementos estruturais bsicos, provenientes do pacote xSPIDERML_Core (classes em amarelo), devem possuir para permitir a execuo de processos de software. Para tal, reaproveita conceitos do WebAPSEE (classes em roxo), do xSPEM (classes em verde) e do SPSM (classes em azul), conforme mostra Figura 3.3.

69

Figura 3.3 - Classes do Pacote ProcessParameters

Estas propriedades podem ser classificadas em universais e existenciais. As propriedades universais so aquelas que devem ser preenchidas a cada execuo. Por exemplo: toda atividade deve iniciar e terminar; todas as atividades suspensas devem ser retomadas; uma vez que uma atividade for concluda, ela tem que ficar neste estado. Estes estados esto definidos na classe StateType e ProcessState. As propriedades existenciais so aquelas que devem ser verdadeiras, pelo menos para uma execuo. Por exemplo: cada tarefa deve ser realizada em um tempo igual ou maior ao expectedStartTime e igual ou menor ao expectedEndTime. Recursos adicionais fazem-se necessrios a fim de adequar o processo para um determinado projeto. Isso implica em definir propriedades especficas para agendamento de tarefas e alocao de recursos. Essas propriedades so introduzidas no pacote ProjectVariables, apresentado na Figura 3.4, que adota: os conceitos de classificao e estados de recursos do WebAPSEE (classes em roxo); a carga de trabalho necessria, estimada e real para realizar as tarefas do xSPEM (classe em verde), a partir da classe ProcessPerformerMap e dos atributos de Resource e

70 TaskUse; e os atributos de HumanResource (classe em amarelo) que foram adicionados a fim de permitir uma maior expressividade linguagem xSPIDER_ML.

Figura 3.4 - Classes do Pacote ProjectVariables

Neste pacote redefine-se o conceito de TaskUse, acrescentando a esta o intervalo de tempo previsto durante o qual uma tarefa deve ser executada (expectedStartTime e expectedEndTime) e o tempo real em que esta tarefa ocorrer (realStartTime e realEndTime) para que comparaes possam ser realizadas. Definiu-se, tambm, os estados e transies que permitem a evoluo da execuo do processo, atravs do pacote EventTypes, apresentado na Figura 3.5.

Figura 3.5 - Classes do Pacote EventTypes

71 Estas transies so desencadeadas por eventos baseados nas abordagens apresentadas no xSPEM (classes em verde) e WebAPSEE (classes em roxo). Sendo assim, os eventos previstos neste pacote so: StartTask, PauseTask, ResumeTask, CancelTask, FailTask e FinishTask. Eles so modelados como especializaes de TaskEvent, um evento abstrato que envolve uma tarefa-alvo. Por fim, identificou-se a necessidade de registrar os eventos ocorridos sob as tarefas durante a execuo do processo que desencadeiam transies entre estados. Definiu-se, assim, o pacote ProcessTrace, conforme mostra a Figura 3.6.

Figura 3.6 - Classes do Pacote ProcessTrace

Este pacote baseia-se basicamente na proposta do xSPEM (classes em verde) devido esta abordagem possuir o mesmo propsito: registrar o log de eventos ocorridos durante a execuo do processo. Estes eventos podem ser exgenos (ExogenousEvent produzidos por meio do processo), como por exemplo, a mudana do status de uma tarefa de onTime para tooLate devido o clock interno desta ser superior a carga de trabalho prevista; ou endgenos (EndogenousEvent produzidos no processo), como por exemplo, a transio de uma tarefa do estado not_started para o estado started que corresponde a realizao do evento startTask na tarefa em questo. Esses eventos podem ser gravados por meio da classe Trace, que possibilita o acompanhamento dos estados dos processos.

3.3.5

Regras de Execuo da Linguagem xSPIDER_ML

Aps definida a estrutura de componentes da xSPIDER_ML, fez-se necessrio definir regras a serem aplicadas sobre estes elementos e seus relacionamentos, estabelecendo uma semntica comportamental para esta linguagem. Nesta aborda-

72 gem, regras definem pr e ps-condies de maneira semelhante a uma mquina de inferncia de um sistema especialista (REIS, 2003). Estas regras permitem estender a linguagem SPIDER_ML e, consequentemente, o padro SPEM 2.0, a fim de representar informaes dinmicas, inerentes s propriedades definidas anteriormente, na Subseo 3.3.4. As regras que compem o formalismo da xSPIDER_ML basicamente dizem respeito transio de estados e de tempo dos elementos do Processo. Para apresentar essas regras, ser utilizada especificao formal, baseada nas abordagens do xSPEM (BENDRAOU, COMBEMALE, et al., 2007) e SPSM (CHAVES, TAVARES, et al., 2010). Esta especificao indica um passo-a-passo para representar a aplicao de regras de execuo, a partir da definio de cenrios. Sendo assim, tm-se as seguintes especificaes:

ws

representa a instanciao da classe WorkSequence (constante no pacote xSPI-

DERML_Core), indicando a relao entre elementos do processo (base e predecessor);

predecessor representa um linkType representa um

atributo da classe WorkSequence que indica qual elemento

precede a execuo do elemento base; atributo da classe WorkSequence que indica o tipo de relao entre os elementos relacionados (estes tipos esto presentes na classe WorkSequenceKind do pacote xSPIDERML_Core);

linkToPredecessor.state

representa um atributo da classe WorkSequence que indica o

possvel estado da conexo entre os elementos relacionados (estes estados esto presentes nas classes StateType e ProcessState do pacote ProcessParameters);

clock

representa o clock interno associado ao conceito de tempo de execuo de um

determinado WorkBreakdownElement.

De acordo com a estrutura da xSPIDER_ML, podem-se identificar basicamente dois aspectos comuns aos componentes Task. Em primeiro lugar, uma tarefa pode possuir os estados notStarted, started, paused, finished. Em segundo lugar, h uma noo de tempo e relgio associado a cada tarefa que pode ser representado a partir do conjunto {tooEarly, onTime, tooLate}. A fim de aplicar as regras, faz-se necessrio expressar esses estados atravs da extenso do elemento Task de modo a introduzir atributos que refletem a informao dinmica, ou seja, o estado da tarefa atual. Para tal, necessrio levar em considerao o conceito de um relgio (clock) interno para a Task. Este conceito no

73 est representado na estrutura da xSPIDER_ML porque somente a sua abstrao necessria. Este relgio deve ser levado em considerao pelo mecanismo de execuo que adotar esta linguagem. Uma observao abstrata da semntica operacional de processos em execuo com relao a estas propriedades pode ser realizada. Considerando-se t como a tarefa a ser executada, cujo estado inicial notStarted, as possveis transies de estados so apresentadas na Figura 3.7.

Figura 3.7 - Transio de Estados de uma Tarefa

Vinculado a cada tarefa, tem-se o conceito de clock interno para verificar o status do tempo de execuo desta atividade. Sendo assim, para uma tarefa t, com estado inicial started e status onTime, a Figura 3.8 apresenta as possibilidades para transies de status.

Figura 3.8 - Transio de Status de uma Tarefa

Por razes de clareza, optou-se por apresentar apenas um subconjunto de regras associadas execuo do processo, selecionadas de acordo com a sua relevncia para realizao da avaliao apresentada na Seo 3.4 deste captulo. O detalhamento desta base de regras que compem a xSPIDER_ML est disponvel na sua especificao tcnica (PORTELA e GOMES, 2011b) e no Apndice B deste trabalho.

74 3.4 AVALIAO DA LINGUAGEM XSPIDER_ML

A fim de avaliar a linguagem de execuo proposta neste trabalho e auxiliar a compreenso em relao utilizao de seus componentes e regras associadas, apresenta-se uma prova de conceito envolvendo a instanciao de um perfil de Processo do RUP (Rational Unified Process) para pequenos projetos, disponvel em (IBM, 2006). O objetivo desta prova de conceito demonstrar que a linguagem xSPIDER_ML pode ser aplicada em um processo real, ou seja, avaliar o formalismo de execuo proposto por esta linguagem. importante ressaltar que esta prova de conceito apresenta algumas limitaes, pois trata apenas de um determinado momento da execuo deste processo e apresenta somente instncias de elementos do pacote ProcessParameters, descritos na Subseo 3.3.4. O detalhamento completo desta prova de conceito est disponvel no Apndice B deste trabalho. Supondo que uma determinada instncia de um Processo do RUP seja constituda de 4 (quatro) fases: Inception, Elaboration, Construction e Transition. Primeiramente, apresentado o modelo deste processo utilizando as notaes da SPIDER_ML, na Figura 3.9.

Figura 3.9 - Modelagem do Processo RUP Instanciado

75 importante ressaltar que a modelagem deste processo foi realizada com o auxlio da ferramenta Spider-PM (BARROS e OLIVEIRA, 2010b). Como esta ferramenta aplica as definies de hierarquia do processo, no permite o relacionamento visual entre elementos de nveis hierrquicos distintos, por exemplo: a conexo direta entre os elementos do Processes Level e os elementos do Phases Level. Suponha-se que este processo encontra-se na Fase Elaboration em um determinado momento de sua execuo. A fim de representar esta situao, optou-se por adotar o diagrama de objetos da UML (OMG, 2001), pois este permite instanciar as classes definidas no pacote ProcessParameters. Sendo assim, a Figura 3.10 apresenta um determinado momento da execuo deste Processo RUP.

Figura 3.10 - Execuo do Processo RUP Instanciado

Para este processo, que est em execuo (state = enacting) de acordo com o tempo previsto (time = onTime), tem-se que a Fase Inception foi finalizada como atrasada em relao ao planejamento (state = enacting e time = tooLate). As Fases

76 Construction e Transition ainda no foram iniciadas (state = notStarted). Na Figura 3.10 apresentado o perfil da Fase Elaboration do Processo RUP, constitudo de trs interaes, sendo que ao final da terceira iterao ocorre o Marco desta Fase, onde somente a primeira iterao (Iteration1) foi iniciada (state = started e time = onTime). Para esta iterao, representada a atividade PrepareEnvironmentForAnIteration, constituda da atividade ManageIteration, ambas representadas no estado em execuo e de acordo com o tempo estimado (state = started e time = onTime). Essa ltima atividade constituda das tarefas AcquireStaff, IdentifyAndAssessRisks e InitiateIteration. Suponha-se que a tarefa AcquireStaff tenha sido inicialmente finalizada onTime. Posteriormente, de acordo com a classificao da conexo de dependncia estabelecida entre as tarefas (AND), deve-se executar simultaneamente as tarefas IdentifyAndAssessRisks e InitiateIteration. No exemplo, a tarefa IdentifyAndAssessRisks foi finalizada mais cedo do que o tempo previsto (time = tooEarly). Porm, houve a necessidade de pausar (state = paused) a tarefa InitiateIteration porque esta precisava da alocao de mais recursos humanos para a sua realizao (stateDescription = Is necessary to allocate more staff). A alocao de recursos humanos foi realizada anteriormente na tarefa AcquireStaff. Sendo assim, a fim de remover o impedimento na realizao da tarefa InitiateIteration, utilizou-se uma conexo de feedback (FC1) para retornar a execuo do processo, permitindo, assim, a reexecuo da tarefa AcquireStaff. Esta avaliao permite uma melhor compreenso da utilizao dos elementos da xSPIDER_ML, atravs da modelagem apresentada na Figura 3.9 e da instanciao destes elementos em um processo real, a partir do diagrama da Figura 3.10. No entanto, esta prova de conceito apresenta como principal limitao a falta de visibilidade da aplicao das regras de execuo da xSPIDER_ML. Estas regras foram definidas atravs de uma especificao formal e a sua validao ser possvel atravs do apoio de uma mquina de execuo, atualmente em desenvolvimento no Projeto SPIDER, conforme descrito na Seo 5.3.1. Esta mquina de execuo permitir que estas regras sejam aplicadas sob os modelos de processo que estejam sendo executados. Desta forma, conceitos como a flexibilidade na execuo do processo podero ser avaliados de forma mais adequada.

77 Alm desta avaliao, importante destacar que esta linguagem foi recentemente publicada no Journal of Software Engineering and Applications (PORTELA, VASCONCELOS, et al., 2012b).

3.5

CONSIDERAES FINAIS

Este captulo apresentou a linguagem de execuo xSPIDER_ML, definida a partir de uma anlise comparativa entre os padres BPMN e SPEM. Esta linguagem caracteriza-se como uma extenso da SPIDER_ML e permite a execuo de modelos de processo aderentes ao SPEM 2.0 atravs da definio de componentes e de regras aplicadas a estes. Aps descrever tanto a estrutura de componentes quanto a base de regras, apresentou-se uma prova de conceito que consistiu na instanciao do formalismo desta linguagem em um processo do RUP. Esta prova de conceito, apesar de suas limitaes, permitiu avaliar a linguagem xSPIDER_ML atravs da utilizao de seus componentes e regras associadas em um processo real. Este formalismo de execuo da linguagem xSPIDER_ML constitui uma das bases para definio das atividades do Framework proposto neste trabalho. Dessa forma, o entendimento dos objetivos e caractersticas desta linguagem fundamental para a compreenso dos componentes que compem este framework. A partir da linguagem xSPIDER_ML e do Mapeamento entre o CMMI-DEV e MR-MPS, apresenta-se no Captulo 4 a principal contribuio deste trabalho: uma proposta de framework para a execuo flexvel de processos de software de forma aderente aos principais modelos de qualidades e padres adotados pela indstria de software brasileira. Sendo a linguagem xSPIDER_ML o componente que permite com que as atividades do framework sejam executadas por uma Mquina de Execuo, o Mapeamento entre os modelos CMMI-DEV e MR-MPS, apresentado na Seo 4.1, o componente que auxilia o framework a obter aderncia aos modelos de qualidade.

78

O FRAMEWORK DE EXECUO DE PROCESSOS

Mediante o exposto nos captulos anteriores, o principal objetivo deste trabalho a definio de um Framework de apoio execuo flexvel de processos de software que seja aderente aos nveis de Capacidade dos modelos de qualidade CMMI-DEV e MR-MPS. O conceito de framework adotado neste trabalho, adaptado de Souza e Oliveira (2010), retrata a customizao de um processo para seguir uma ou mais recomendaes dos modelos de qualidade, a partir de um fluxo de atividades genricas necessrias para a execuo de qualquer processo de software. Este framework, denominado Spider-PE (Process Enactment), foi proposto inicialmente em (PORTELA, VASCONCELOS e OLIVEIRA, 2011), e se caracteriza como resultado das pesquisas realizadas em parceria com o Projeto SPIDER (Software Process Improvement: DEvelopment and Research) (OLIVEIRA, YOSHIDOME, et al., 2011) da UFPA Universidade Federal do Par. O Projeto SPIDER possui como um dos focos principais, apresentar solues tecnolgicas (ferramentas de software livre, frameworks, ferramentais de apoio) com caractersticas adequadas para atender as boas prticas descritas nos modelos de qualidade CMMI-DEV (SEI, 2010) e MR-MPS (SOFTEX, 2011b). Sendo assim, este captulo apresenta detalhadamente o Framework para Execuo de Processos Spider-PE, a partir de suas fases, atores e atividades, Seo 4.2. Conforme descrito na Seo 3.5, as atividades deste framework so derivadas, alm do formalismo da xSPIDER_ML, de um Mapeamento entre os modelos de qualidade MR-MPS e CMMI-DEV em relao s boas prticas definidas para execuo de processos de software nas organizaes, apresentado na Seo 4.1. Posteriormente, ser apresentada, na Seo 4.3, uma avaliao deste framework a partir de uma anlise comparativa entre as atividades do framework e o mapeamento apresentado no Guia de Implementao do MPS.BR. Por fim, destacam-se os principais diferenciais desta proposta, na Seo 4.4.

79 4.1 MAPEAMENTO ENTRE O MR-MPS E O CMMI-DEV

Ao adotar mais de um modelo de qualidade de processo, a organizao tende a enfrentar uma srie de desafios, como a existncia de possveis sobreposies entre os modelos, os quais devem ser tratados (SOFTEX, 2011a). Estas sobreposies podem ocorrer na medida em que, para atender determinadas recomendaes de um modelo, faz-se necessrio gerar evidncias deste atendimento, como por exemplo, atravs de produtos de trabalho especficos como um Plano de Comunicao. Sendo assim, uma determinada evidncia gerada pode atender s recomendaes de mais de um modelo, evitando, assim, o retrabalho e esforo desnecessrio por parte da equipe de desenvolvimento. Neste contexto, uma forma de abordar as diferenas e similaridades entre estes modelos mapear os componentes de um modelo em relao aos componentes de outro modelo. Mesmo que estes componentes sejam aderentes e/ou complementares, as diferenas de rigor podem significar que os resultados de um modelo podem no atender ao outro modelo (PAULK, 2004). Isso ocorre porque, apesar de objetivarem a melhoria contnua dos processos de software, estes modelos de qualidade possuem objetivos/propsitos especficos que, por sua vez, so atendidos atravs de seus componentes. Desta maneira, um resultado que evidencie o atendimento de um componente de um determinado modelo pode no ser suficiente para atender o componente equivalente do outro modelo adotado. O objetivo deste trabalho comparar os modelos CMMI-DEV (SEI, 2010) e MR-MPS (SOFTEX, 2011b) no que diz respeito Capacidade, pois este conceito relaciona-se diretamente com a definio de execuo de processo. Entende-se por Capacidade do processo o grau de refinamento e institucionalizao com que o processo executado na organizao/unidade organizacional (SOFTEX, 2011b). Em outras palavras, esta Capacidade descreve as caractersticas que devem estar presentes para institucionalizar reas de processos em uma organizao (SEI, 2010). No modelo CMMI-DEV, a Capacidade expressa atravs de Objetivos Genricos Generic Goal (GG), que por sua vez so atendidos atravs de Prticas Genricas Generic Practices (GP). J no MR-MPS, a Capacidade representada atravs de Atributos de Processo (AP), que so atendidos a partir de Resultados de Atributos de Processo (RAP). Sendo assim, neste mapeamento, de forma equivalen-

80 te a apresentada no Guia de Implementao Parte 11 (SOFTEX, 2011a), os RAP do MR-MPS sero comparados com as GP do CMMI-DEV. Os GG do CMMI-DEV e os AP do MR-MPS foram excludos da comparao porque eles so avaliados indiretamente atravs do atendimento das GP e dos RAP, respectivamente (SOFTEX, 2011a). Este trabalho adotar como base o Nvel F do MR-MPS e o Nvel 2 do CMMIDEV, apresentados na Seo 2.3, onde o Processo considerado Gerenciado. A escolha destes nveis especficos deve-se ao fato de que eles so nveis iniciais dos modelos em questo e por isso tendem a ser de maior complexidade para implementao da maturidade organizacional (OLIVEIRA, YOSHIDOME, et al., 2011). Alm disto, nesses nveis os modelos recomendam que o Processo deva ser institucionalizado. Institucionalizar um processo significa coloc-lo em prtica na organizao, ou seja, execut-lo. Com base nestas justificativas e sendo a execuo o foco deste trabalho, estes foram os nveis considerados neste mapeamento. O principal objetivo deste mapeamento identificar as diferenas e as similaridades entre estes modelos, analisando o grau de aderncia entre os RAP do MRMPS em relao s GP do CMMI-DEV. Alm disto, este mapeamento serviu de base para definir as atividades de gerenciamento da execuo do framework e, desta forma, fundamental para evidenciar a aderncia deste framework s recomendaes destes modelos de qualidade durante a fase de execuo. Sendo assim, foram estabelecidos 3 (trs) graus de aderncia, apresentados no Quadro 4.1, para analisar esta equivalncia entre os modelos. Para cada grau de aderncia associada uma cor a fim de, posteriormente, representar visualmente estes graus no mapeamento realizado.
Quadro 4.1 - Graus de Aderncia entre Componentes do CMMI-DEV e MR-MPS

Grau de Aderncia Equivalente Parcialmente No Equivalente

Descrio As prticas do CMMI-DEV fazem exatamente as mesmas exigncias que os resultados do MR-MPS. As recomendaes das prticas do CMMI-DEV no so exatamente as mesmas que as dos resultados do MR-MPS. No existe uma prtica do CMMI-DEV equivalente a um resultado do MR-MPS ou vice-versa.

81 Um mapeamento deve ser estruturado pelos requisitos de um modelo em direo ao outro modelo de referncia (SOFTEX, 2011a). Assim, o MR-MPS foi selecionado como modelo de origem e o CMMI-DEV como modelo de destino, de maneira aderente a apresentada no Guia de Implementao Parte 11 (SOFTEX, 2011a). No entanto, importante ressaltar que a comparao apresentada no referido Guia feita em relao s verses 2009 do MR-MPS e 1.2 do CMMI-DEV, enquanto que o mapeamento apresentado neste trabalho compara as verses 2011 do MR-MPS (SOFTEX, 2011b) e 1.3 do CMMI-DEV (SEI, 2010). Alm disto, apesar do modelo MR-MPS afirmar seu embasamento no modelo CMMI-DEV, quando esta etapa do trabalho foi realizada, ainda no havia nenhuma publicao oficial que evidenciava a equivalncia entre as recomendaes destes modelos. A seguir, o Quadro 4.2 apresenta o mapeamento entre os componentes destes modelos. As consideraes necessrias para justificar o grau de aderncia entre os componentes destes modelos bem como a descrio da relevncia de cada componente para o processo de execuo encontram-se disponveis no Apndice C deste trabalho.
Quadro 4.2 - Mapeamento entre Resultados de Atributos de Processo do MR-MPS e Generic Practices do CMMI-DEV

Id 01 02 03 04

Resultado de Atributo de Processo do MR-MPS RAP 1 O processo atinge seus resultados definidos RAP 2 Existe uma poltica organizacional estabelecida e mantida para o processo RAP 3 A execuo do processo planejada RAP 5 (At o nvel F) As informaes e os recursos necessrios para a execuo do processo so identificados e disponibilizados RAP 6 (At o nvel F) As responsabilidades e a autoridade para executar o processo so definidas, atribudas e comunicadas RAP 7 (At o nvel F) As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia RAP 8 A comunicao entre as partes interessadas no processo gerenciada de forma a garantir o seu envolvimento RAP 4 (A partir do nvel F) Medidas so planejadas e coletadas para monitorao da execuo do processo e ajustes so realizados

Generic Practice do CMMI-DEV GP 1.1 Perform Specific Practices GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources

05

GP 2.4 Assign Responsibility

06

GP 2.5 Train People

07

GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process

08

82
Id Resultado de Atributo de Processo do MR-MPS RAP 10 (A partir do nvel F) A aderncia dos processos executados s descries de processo, padres e procedimentos avaliada objetivamente e so tratadas as no conformidades RAP 9 (At o nvel F) Os resultados do processo so revistos com a gerncia de alto nvel para fornecer visibilidade sobre a sua situao na organizao RAP 13 Os produtos de trabalho so colocados em nveis apropriados de controle RAP 11 Os requisitos dos produtos de trabalho do processo so identificados RAP 12 Requisitos para documentao e controle dos produtos de trabalho so estabelecidos RAP 14 Os produtos de trabalho so avaliados objetivamente com relao aos padres, procedimentos e requisitos aplicveis e so tratadas as no conformidades Generic Practice do CMMI-DEV GP 2.9 Objectively Evaluate Adherence

09

10

GP 2.10 Review Status with Higher Level Management GP 2.6 Control Work Products Inexistente Inexistente

11 12 13

14

Inexistente

Este mapeamento foi realizado a partir da anlise dos requisitos necessrios para atender as recomendaes destes modelos. Sendo, compararam-se as exigncias necessrias para atendimento dos RAP do MR-MPS com as exigncias necessrias para atendimento das GP do CMMI-DEV. Aps a concluso deste mapeamento entre os RAP do MR-MPS:2011 e as GP do CMMI-DEV 1.3, possvel realizar algumas anlises. O MR-MPS possui 14 (quatorze) RAP, referentes ao Nvel F de Capacidade, enquanto que o CMMI-DEV possui apenas 11 (onze) GP, referentes ao Nvel 2 da representao contnua. Destes 14 (quatorze) RAP do MR-MPS: 8 (oito) possuem GP equivalentes no CMMIDEV; 3 (trs) RAP so parcialmente equivalentes s suas respectivas GP no CMMIDEV; e 3 (trs) no possuem GP equivalentes no CMMI-DEV. A Figura 4.1 apresenta um grfico que sintetiza estes resultados obtidos a partir do mapeamento. Para os componentes considerados parcialmente e no aderentes, so realizadas consideraes a respeito da atribuio destes graus de aderncia, no Apndice C deste trabalho.

83

3 3 8

Graus de Aderncia

Equivalente Parcialmente No Equivalente

Figura 4.1 - Aderncia dos RAP do MR-MPS em Relao as GP do CMMI-DEV

Apesar destes resultados, constata-se, em relao Capacidade do Processo, que o Nvel F do MR-MPS:2011 totalmente aderente ao Nvel 2 do CMMI-DEV 1.3. No entanto, o CMMI-DEV 1.3, devido a no existncia de GP que contemplassem os RAP 11, 12 e 14, no equivalente ao MR-MPS:2011, em relao a este conceito de Capacidade.

4.2

O FRAMEWORK SPIDER-PE

O objetivo do Framework Spider-PE definir um fluxo conceitual de atividades genricas para que as organizaes desenvolvedoras de software possam executar seus processos de forma flexvel e semi-automatizada de acordo com as recomendaes dos modelos de qualidade CMMI-DEV e MR-MPS. Para tal, importante destacar que as atividades deste framework devem ser customizadas de acordo com o perfil e as caractersticas da organizao que ir adot-lo. Alm disto, ressalta-se que este framework deve ser aplicado no setor organizacional responsvel pelo desenvolvimento de software, exigindo um esforo estratgico, ttico e operacional por parte da alta administrao para que este possa ser implantado de forma adequada e satisfatria. A especificao deste framework foi feita utilizando a notao BPMN (Business Process Modeling Notation) (OMG, 2011), apresentada na Seo 3.1. Optou-se pela adoo deste padro devido possibilidade de integrao e interao com os

84 processos de outras reas da organizao (ver Apndice A), facilitando o alinhamento da definio do processo de execuo com os objetivos globais da organizao. Nas subsees a seguir sero detalhadas as atividades do framework, organizadas em fases e executadas por atores. A especificao completa deste framework encontra-se disponvel na sua definio (PORTELA e GOMES, 2011a) e no Apndice C deste trabalho.

4.2.1

Fases do Framework Spider-PE

Baseando-se no meta-processo proposto pelo ambiente ImPPros (OLIVEIRA, 2007), apresentado na Figura 2.8, as pesquisas do Projeto SPIDER (OLIVEIRA, YOSHIDOME, et al., 2011) relacionadas ao ciclo de vida de processos abordam as fases de: Definio do Processo, Simulao do Processo, Execuo do Processo, Avaliao do Processo e Melhoria do Processo. Esta abordagem apresentada atravs do diagrama da Figura 4.2.

Figura 4.2 - Ciclo de Vida de Processos no Contexto do Projeto SPIDER

85 Inicialmente, observa-se a necessidade de modelar o processo a partir da linguagem SPIDER_ML (BARROS e OLIVEIRA, 2010a) e do apoio ferramental da Spider-PM (BARROS e OLIVEIRA, 2010b). Caso a organizao j possua um modelo de processo, realiza-se a Avaliao do Processo. Se o processo ainda no estiver definido, realiza-se a Definio do Processo, que busca identificar as principais caractersticas da organizao, de projetos e de produtos de software necessrias para a implementao do processo. Posteriormente, a partir destas caractersticas, estabelece-se um processo abstrato que por sua vez deve ser planejado e modelado. Ento, a partir do processo modelado possvel realizar a Simulao Processo, onde a finalidade identificar possveis problemas no planejamento e/ou na definio do processo abstrato antes que este seja executado. Neste contexto, foi desenvolvida a ferramenta de simulao de processos de software, denominada SPSM (Software Process Simulator Machine) (CHAVES, TAVARES, et al., 2010). Caso o processo no tenha sido validado na simulao, este deve ser redefinido. Aps ter sido validado na simulao, o processo pode ser executado. Sendo assim, a entrada da Fase Execuo do Processo, destacada em verde na Figura 4.2, um modelo de processo. Esta fase deve auxiliar na coordenao das atividades realizadas por pessoas (gerentes e equipe de desenvolvimento) e por ferramentas automatizadas, obtendo, com isso, um feedback da realizao do processo, a partir da organizao das informaes constantes no modelo de Processo Instanciado. Este trabalho fornece os componentes que constituem a base desta fase de Execuo do Processo: a linguagem xSPIDER_ML (PORTELA e GOMES, 2011b) e o Framework SPIDER-PE (PORTELA e GOMES, 2011a). Na Fase Avaliao do Processo, a partir de informaes quantitativas e qualitativas sobre o desempenho do processo em execuo, estabelecem-se novas caractersticas para o processo. Se estas caractersticas forem consideradas necessrias, realiza-se a Melhoria do Processo. Esta fase verifica a necessidade de realizar mudanas no processo, a fim de que este processo seja continuamente melhorado. Caso esta necessidade seja identificada, o processo deve ser redefinido para atender tais melhorias. Ambas as fases de Avaliao e Melhoria do Processo fazem parte do escopo de pesquisas atualmente em andamento no Projeto SPIDER. Como forma de organizar e sistematizar o processo de Execuo do Processo, o framework foi divido em 3 (trs) fases: Gerenciamento do Processo (Figura 4.3); Execuo das Atividades do Processo (Figura 4.4); e Aplicao do Formalismo

86 de Execuo (Figura 4.5). Cada uma destas fases composta por atividades que foram definidas com o intuito de atender as recomendaes dos modelos MR-MPS e CMMI-DEV e ao formalismo de execuo da linguagem xSPIDER_ML. Sendo assim, estas atividades descrevem os objetivos, artefatos de entrada e sada, passos necessrios, ferramentas de apoio, dentre outras caractersticas necessrias para atender a estes requisitos. Sendo um modelo de processo a entrada necessria para utilizao do framework, este modelo ser executado atravs do apoio das atividades das fases Execuo das Atividades do Processo e Aplicao do Formalismo de Execuo. Quanto fase Gerenciamento do Processo, se faz necessria para realizar o planejamento da execuo do processo, conforme ser detalhado na Subseo 4.2.3. importante destacar que estas fases relacionam-se entre si como subfases. Sendo assim, a Fase Gerenciamento do Processo possui como subfase Execuo das Atividades do Processo que, por sua vez, possui como subfase Aplicao do Formalismo de Execuo. Os objetivos, os atores e as atividades que compem cada uma destas fases sero descritas com detalhes na Subseo 4.2.3. Alm disto, as fases deste framework sero avaliadas na Seo 4.3 e validadas atravs de uma ferramenta de execuo (Subseo 5.3.1).

4.2.2

Atores do Framework Spider-PE

Os atores do framework foram definidos de acordo com as atribuies necessrias para executar um processo de software. Estas atribuies foram identificadas a partir do meta-processo do ImPProS (OLIVEIRA, 2007), no qual este trabalho baseia-se, que define os usurios responsveis pela interao com o Mdulo de Execuo deste ambiente. A fim de descrever as responsabilidades dos atores envolvidos na execuo do processo, analisaram-se as seguintes referncias: o Guia PMBOK (Project Management Body of Knowledge) (PMI, 2008); os modelos de qualidade CMMI-DEV (SEI, 2010) e MR-MPS (SOFTEX, 2011b); e um Relatrio de Pesquisa sobre a Interao Humana Durante a Execuo de Processos de Software (SOUZA, REIS e REIS, 2001). Sendo assim, os atores deste framework podem exercer as seguintes funes:

87 Gerente de Processo o responsvel pelo acompanhamento da execuo do modelo de processo (SOUZA, REIS e REIS, 2001). No contexto deste trabalho, o termo Gerente de Processo ser utilizado para representar um ou mais integrantes da Equipe do Projeto que tm como responsabilidade a monitorao, coordenao e adaptao do modelo de processo aos requisitos de execuo (OLIVEIRA, 2007); Gerente de Projeto a pessoa designada pela organizao executora do projeto para atingir os objetivos deste (PMI, 2008). Para tal, se faz necessrio que este tenha um conhecimento slido sobre as prticas de gerenciamento de projeto. Neste trabalho, o gerente ser o responsvel pela instanciao do processo modelado, atravs da definio de cronograma, recursos e responsabilidades, identificao de riscos, dentre outras atividades; Equipe do Projeto composta pelo Gerente de Projeto e por outros membros que executam o trabalho de desenvolvimento do projeto (PMI, 2008). Esta equipe deve possuir um conjunto especfico de habilidades necessrias para executar as atividades do projeto (OLIVEIRA, 2007); Gerente de Configurao responsvel por estabelecer e manter a integridade de todos os artefatos de um processo ou projeto e disponibiliz-los a Equipe do Projeto (SEI, 2010) (SOFTEX, 2011b). Para tal, este responsvel deve preparar e oferecer suporte a um ambiente de gerncia de configurao que permita o versionamento e o controle de acesso aos produtos de trabalho gerados durante a execuo do processo; Equipe de Garantia da Qualidade pessoa ou grupo responsvel por avaliar objetivamente os processos executados, produtos de trabalho e servios em relao descrio de processos, padres e procedimentos (SEI, 2010) (SOFTEX, 2011b); Spider-PE ferramenta de software livre (em desenvolvimento no Projeto SPIDER) responsvel pela execuo semi-automatizada das atividades do processo. Esta ferramenta, proposta em (PORTELA, VASCONCELOS e OLIVEIRA, 2011), sistematizar as atividades do framework e aplicar o formalismo de execuo da xSPIDER_ML atravs de uma mquina de execuo (ver Subseo 5.3.1).

88 4.2.3 Descrio das Atividades do Framework Spider-PE

As atividades de cada fase do framework, descritas na Subseo 4.2.1, sero apresentadas a seguir. O detalhamento destas atividades, como os critrios de entrada e sada, os produtos de trabalhos gerados e consumidos, os passos necessrios, dentre outros detalhes esto descritos no Apndice C deste trabalho. 4.2.3.1 Fase Gerenciamento do Processo

A primeira fase do framework a Fase Gerenciamento do Processo, apresentada na Figura 4.3, composta por 3 (trs) etapas: Planejamento, Execuo e Monitoramento.

Figura 4.3 - Fase Gerenciamento do Processo

Esta fase derivada do mapeamento apresentado na Seo 4.1 e possui por objetivo a realizao do planejamento e acompanhamento da execuo do processo de acordo com as recomendaes dos modelos de qualidade CMMI-DEV e MRMPS. Sendo assim, nesta fase define-se a Poltica do Processo, estimam-se os recursos e o cronograma, dentre outras atividades. Alm disto, esta fase constituda

89 pela subfase Execuo das Atividades do Processo, destacada em verde na Figura 4.3. Inicialmente, realiza-se o planejamento do processo, onde o Gerente de Processo deve definir e publicar uma poltica organizacional. Esta poltica contm diretrizes e responsabilidades para reas especficas do processo, como Gerncia de Projeto, Gerncia de Requisitos, dentre outras. Nesta etapa, o Gerente de Projeto estima o esforo necessrio para realizar as atividades do processo. Com base neste esforo, define o cronograma do projeto e posteriormente identifica os riscos que possam afetar o projeto. Dependendo do impacto do risco, pode haver a necessidade de reestimar o esforo. importante destacar que, durante a etapa de Planejamento, apesar do Gerente de Projeto ser o responsvel pela realizao das principais atividades, estas devem ser realizadas juntamente com a Equipe do Projeto, pois os membros desta sero quem de fato executaro as atividades do projeto. Em seguida, o Gerente de Projeto define os recursos (hardware e software) e as responsabilidades (recursos humanos) necessrios para realizar as atividades. Estas responsabilidades so definidas a partir da anlise entre as habilidades necessrias para realizar as atividades do processo e a capacidade dos membros da Equipe do Projeto. Nesta etapa, tambm, deve-se verificar a necessidade de realizao de treinamentos para capacitao da equipe. Aps identificados os recursos (software, hardware e humano), realiza-se a alocao destes para o projeto. Devido esta alocao ser feita de acordo com a capacidade e disponibilidade dos recursos, pode haver a necessidade de reestimar o esforo necessrio para realizar o projeto. Depois de alocado os recursos humanos, o Gerente de Projeto deve atribuir os responsveis por realizar cada atividade do processo. Tambm deve identificar os interessados (stakeholders) afetados pela realizao do projeto, a fim de planejar a comunicao entre estes. Planejar a comunicao consiste em fazer com que os stakeholders tenham acesso s informaes e documentos relevantes. Nesta etapa de Planejamento, a Equipe de Garantia da Qualidade responsvel por identificar os requisitos dos produtos de trabalho, a partir da definio de padres, templates e demais atributos necessrios para a gerao de cada produto de trabalho durante o desenvolvimento do projeto. Por fim, o Gerente de Processo define as atividades de monitoramento e controle, a fim de garantir que a realizao do processo ocorra conforme o planejado.

90 Uma vez a etapa de Planejamento devidamente realizada, ser iniciada a etapa de Execuo, onde o Gerente de Projeto deve gerenciar a comunicao durante o andamento o projeto. A Equipe do Projeto, por sua vez, deve executar as atividades do processo. Esta atividade, destacada em verde na Figura 4.3, essencial para o processo de execuo, caracterizando-se como uma subfase, descrita na subseo a seguir. Por fim, esta fase possui a etapa de Monitoramento, onde o Gerente de Projeto deve identificar, registrar e monitorar os possveis problemas que surgirem durante a execuo do projeto, alm de acompanhar a resoluo destes. Nesta etapa, a Equipe de Garantia da Qualidade realiza revises no processo a fim de garantir que este esteja aderente a sua descrio e trata as no conformidades encontradas. 4.2.3.2 Fase Execuo das Atividades do Processo

A Fase Execuo das Atividades do Processo, tambm, derivada do mapeamento entre o CMMI-DEV e MR-MPS. Esta fase, apresentada na Figura 4.4, responsvel pela execuo do processo propriamente dita. Sendo assim, as tarefas e atividades definidas no modelo do processo so executadas por seus responsveis e os produtos de trabalho necessrios so gerados. A primeira etapa desta fase consiste em executar a Fase Aplicao do Formalismo de Execuo, destacada em verde. Esta subfase realizada atravs do apoio ferramental da Spider-PE e ser detalhada na subseo a seguir. importante destacar que essa subfase deve ser realizada simultaneamente as demais atividades desta fase, para que o formalismo possa atuar sob a execuo das atividades do processo. Nesta fase de Execuo das Atividades do Processo, a Equipe do Projeto responsvel por gerar os produtos de trabalho que se fazem necessrios para a conduo das atividades do projeto. Para cada produto de trabalho gerado, o Gerente de Configurao deve realizar o versionamento e o controle de acesso. Nos marcos e pontos de controle do projeto, a Equipe de Garantia da Qualidade deve verificar a aderncia do processo e dos produtos de trabalho aos padres e templates estabelecidos na Fase Gerenciamento do Processo. Caso seja identificada alguma inconsistncia, o produto de trabalho dever ser novamente gerado. importante destacar que a Equipe de Qualidade deve atuar juntamente Equipe do

91 Projeto, pois os membros desta sero responsveis por produzir os produtos de trabalho e seguir o processo definido.

Figura 4.4 - Fase Execuo das Atividades do Processo

4.2.3.3

Fase Aplicao do Formalismo de Execuo

A ltima fase do framework consiste na Aplicao do Formalismo de Execuo, apresentada na Figura 4.5, onde a ferramenta Spider-PE responsvel pela aplicao do formalismo de execuo definido na especificao tcnica da xSPIDER_ML (ver Apndice B). O objetivo desta fase possibilitar com que o Framework Spider-PE incorpore regras e caractersticas da xSPIDER_ML que permitam com que as suas atividades possam ser instanciadas por uma mquina de execuo e, consequentemente, atender os conceitos de flexibilidade e execuo semi-automatizada. Sendo assim, esta fase deve ocorrer em paralelo as demais fases do framework, pois este formalismo deve atuar sob as atividades destas fases.

92

Figura 4.5 - Fase Aplicao do Formalismo de Execuo

As atividades desta fase so organizadas de acordo com a ordem de importncia para a mquina de execuo da ferramenta em desenvolvimento. Contudo, estas atividades podem, tambm, ser adotadas por outras ferramentas que pretendem executar modelos de processos baseados no padro SPEM 2.0, pois, de acordo com a abordagem apresentada neste trabalho, no h necessidade de se realizar transformaes entre modelos, conforme descrito na Subseo 3.3.1. Sendo assim, inicialmente aplica-se a hierarquia de ativos de processo, a fim de distinguir os elementos do processo de acordo com seu nvel hierrquico. Em seguida, aplicam-se as restries do processo, atravs da especificao dos tipos de conexes entre as atividades, que determinam o fluxo de execuo do processo. Tambm deve-se controlar as variveis do projeto, a partir das informaes fornecidas na Fase Gerenciamento do Processo, ou seja, estimativas, recursos, cronograma, etc.

93 Constantemente, a mquina de execuo da Spider-PE deve monitorar os estados e tempos do processo e registrar em um log as mudanas que venham a ocorrer sob este processo, a fim de registrar um histrico dos eventos ocorridos. A monitorao do estado e tempo do processo permite a representao e acompanhamento do estado real do processo pela ferramenta de execuo. Um dos principais objetivos deste trabalho consiste em permitir que a execuo ocorra de forma flexvel. Isso implica na possibilidade de realizar mudanas e alteraes em um processo durante a sua execuo, conforme discutido na Subseo 2.4.2. A atividade responsvel por esta caracterstica a Realizar Feedback, que permite o retorno na realizao de uma atividade do processo que j tenha sido concluda (executada). Caso haja esse retorno, as restries do processo devem ser novamente aplicadas para as atividades que sero reexecutadas. Devido as caractersticas das atividades desta fase, a organizao que adotar o Framework Spider-PE poder, durante a execuo de seu processo, optar por fluxos alternativos, retornar execuo de uma atividade j realizada, obter informaes sobre o andamento do processo e realizar demais aes que demandem a interveno humana. As atividades que apoiam essas aes so Registar Histrico de Eventos e Realizar Feedback. Estas atividades permitem com que, mesmo que mudanas dinmicas ocorram durante a execuo, a consistncia em relao ao modelo do processo seja mantida. Alm disto, esta organizao poder realizar todas as atividades desta fase atravs do apoio de agentes automatizados. Sendo assim, para cada uma destas atividades proposta uma ferramenta de apoio (consultar a Seo 3.2 do Apndice C). A partir da atuao destes agentes automatizados e da interveno humana na conduo das atividades do Framework Spider-PE, possvel realizar a execuo semi-automatizada do processo. Alm da caracterstica de flexibilidade, atendida pela automao das atividades descritas anteriormente, possvel obter outros benefcios com a automao das demais atividades desta fase. A partir das atividades Aplicar Hierarquia de Ativos do Processo, Aplicar Restries do Processo e Controlar Variveis do Projeto, o framework pode garantir com que a execuo das atividades ocorra de acordo com a sequncia e parmetros definidos no modelo de processo. Por sua vez, as atividades Monitorar Estados do Processo e Monitorar Status do Processo permitem o

94 acompanhamento do andamento da execuo do processo, em relao ao planejamento, e a coleta automtica de mtricas.

4.3

AVALIAO DO FRAMEWORK SPIDER-PE

Conforme citado no incio deste captulo, o mapeamento entre os modelos CMMI-DEV e MR-MPS e o formalismo proposto pela linguagem xSPIDER_ML foram a base utilizada para definio do framework para execuo de processos SpiderPE. Sendo assim, uma forma de avaliar este framework atravs de avaliao de seus componentes. Neste sentido, o resultado do mapeamento entre os modelos de qualidade foi comparado com as orientaes para a implementao e avaliao do Modelo de Referncia MR-MPS:2009 em conjunto com o CMMI-DEV v1.2, constante no Guia de Implementao Parte 11 (SOFTEX, 2011a). O resultado desta comparao observvel, sobretudo na Seo 2.3 do Apndice C, a partir da coluna Consideraes, que alinha o mapeamento realizado neste trabalho ao mapeamento publicado no Guia de Implementao. A partir desta comparao, constatou-se a equivalncia entre os mapeamentos realizados. A fim de avaliar a linguagem xSPIDER_ML, realizou-se uma prova de conceito da aplicao do formalismo desta em uma instanciao do processo do RUP (Rational Unified Process). Esta avaliao encontra-se disponvel no Apndice B deste trabalho. Outra abordagem de avaliao do Framework Spider-PE atravs da anlise do atendimento de suas atividades ao Guia de Implementao Parte 11 (SOFTEX, 2011a). Nesta abordagem, para cada atividade do framework, identificaram-se os Resultados de Atributos de Processo (RAP) do MR-MPS (SOFTEX, 2011b) e Prticas Genricas (GP) do CMMI-DEV (SEI, 2010) atendidas por estas atividades. Para realizar esta avaliao, primeiramente definiram-se nveis de atendimento, conforme Quadro 4.3, para as atividades do framework em relao aos componentes dos modelos de qualidade. Para cada nvel de atendimento associada uma determinada cor a fim de, posteriormente, representar visualmente estes nveis na avaliao realizada.

95
Quadro 4.3 - Nveis de Atendimento das atividades do Framework ao MR-MPS e CMMI-DEV

Nvel de Atendimento

Descrio As atividades do framework atendem as recomendaes de um determinado RAP do MR-MPS e da GP correspondente no CMMI-DEV. No entanto, isto no significa que uma atividade por si s atenda completamente a este RAP ou a esta GP. As atividades do framework atendem parcialmente as recomendaes de um determinado RAP do MR-MPS e da GP correspondente no CMMI-DEV. Ou seja, estas atividades no atendem a todas as recomendaes deste RAP ou desta GP. As atividades do framework no atendem a recomendao de nenhum RAP do modelo MR-MPS e da GP correspondente no modelo CMMI-DEV.

Atendido

Parcialmente

No Atendido

Conforme citado anteriormente, esta anlise do atendimento realizada a partir das atividades do framework em direo aos componentes dos modelos de qualidade. A seguir, o Quadro 4.4 apresenta a relao entre estas atividades do framework e os resultados de atributos do processo do MR-MPS e as prticas genricas do CMMI-DEV. Posteriormente, sero feitas as consideraes necessrias para justificar o nvel de atendimento atribudo a cada uma destas atividades.
Quadro 4.4 - Avaliao do Atendimento do Framework aos Modelos MR-MPS e CMMI-DEV

Fase do Framework

Atividade do Framework Definir Poltica Organizacional Publicar Poltica Organizacional Estimar Esforo Definir Cronograma Identificar Riscos

Componente MRMPS/CMMI-DEV RAP 2 e GP 2.1 RAP 2 e GP 2.1 RAP 3 e GP 2.2 RAP 3 e GP 2.2 RAP 3 e GP 2.2 RAP 3 e GP 2.2, RAP 5 e GP 2.3 RAP 7 e GP 2.5 RAP 5 e GP 2.3 RAP 6 e GP 2.4 RAP 8 e GP 2.7 RAP 8 e GP 2.7 RAP 11

Gerenciamento do Processo

Definir Recursos e Responsabilidades Identificar Habilidades e Capacidade Alocar Recursos Atribuir Responsabilidades Identificar Stakeholders Planejar Comunicao Identificar Requisitos dos Produtos de Trabalho

96
Fase do Framework Atividade do Framework Definir Atividades de Monitoramento e Controle Gerenciar Comunicao Realizar Monitoramento e Controle Realizar Revises no Processo Gerar Produtos de Trabalho Execuo das Atividades do Processo Gerenciar Configuraes Verificar Aderncia do Processo Verificar Aderncia dos Produtos de Trabalho Aplicar Hierarquia de Ativos do Processo Aplicar Restries do Processo Controlar Variveis do Projeto Aplicao do Formalismo de Execuo Monitorar Estado do Processo Monitorar Tempo do Processo Registrar Histrico de Eventos Realizar Feedback RAP 1 e GP 1.1 Componente MRMPS/CMMI-DEV RAP 3 e GP 2.2 RAP 8 e GP 2.7 RAP 4 e GP 2.8 RAP 9 e GP 2.10 RAP 1 e GP 1.1 RAP 13 e GP 2.6, RAP 12 RAP 10 e GP 2.9 RAP 14

As atividades Definir Poltica Organizacional e Publicar Poltica Organizacional implicam tanto na definio de diretrizes de como a organizao planeja e implementa os seus processos, quanto na publicao e divulgao desta poltica a todos interessados na organizao, a fim de enfatizar a importncia dos processos e facilitar a sua institucionalizao. Sendo assim, estas duas atividades atendem totalmente ao RAP 2 e a GP 2.1. A fim de atender o RAP 3 e a GP 2.2, deve-se documentar um plano para a execuo do processo. Este planejamento deve incluir recursos, responsabilidades e tempo, bem como as atividades de controle e monitoramento da execuo do processo, a fim de identificar possveis riscos e o esforo necessrio para atingir o escopo do software a ser desenvolvido. Sendo assim, estas recomendaes dos modelos MR-MPS e CMMI-DEV so diretamente atendidas pelas atividades: Estimar Esforo, Definir Cronograma, Identificar Riscos, Definir Recursos e Responsabilidades e Definir Atividades de Monitoramento e Controle.

97 As atividades Definir Recursos e Responsabilidades e Alocar Recursos consistem em assegurar que as informaes e os recursos necessrios para executar o processo estejam disponveis quando necessrios, a fim de permitir que a conduo do projeto ocorra de acordo com o plano. Sendo assim, estas atividades atendem diretamente ao RAP 5 e a GP 2.3. O atendimento do RAP 7 e da GP 2.5 implica em assegurar que as pessoas alocadas tenham as habilidades, conhecimentos e experincias necessrias para executar ou apoiar o processo. Esta recomendao diretamente atendida pela atividade Identificar Habilidades e Capacidade. A atividade Atribuir Responsabilidades consiste em assegurar que as responsabilidades e a autoridade para executar o processo esto claramente definidas e bem compreendidas, a fim de que haja, ao longo da vida do processo, pessoas que se responsabilizem pela sua execuo e por alcanar os resultados especificados. Por esta razo, esta atividade atende totalmente ao RAP 6 e a GP 2.4. Para se atender as recomendaes do RAP 8 e da GP 2.7 deve-se identificar as partes interessadas no processo, planejar e manter o seu envolvimento, a fim de estabelecer uma interface que assegure a comunicao entre estas partes. Sendo assim, estas recomendaes so diretamente atendidas em conjunto pelas atividades: Identificar Stakeholders, Planejar Comunicao e Gerenciar Comunicao. Identificar Requisitos dos Produtos de Trabalho a atividade responsvel pela definio de critrios associados ao formato e padres de documentao e critrios de qualidade relacionados a estes produtos de trabalho. Por este motivo, esta atividade por si s atende totalmente ao RAP 11. O RAP 4 e a GP 2.8 indicam a necessidade de se realizar o monitoramento e controle do processo em marcos e pontos de controle, a fim de que aes corretivas apropriadas possam ser realizadas quando necessrias. A atividade do framework que atende estas recomendaes a Realizar Monitoramento e Controle. A atividade Realizar Revises no Processo implicar na realizao de revises com os gerentes responsveis pelas polticas e diretrizes gerais para o processo, a fim de proporcionar visibilidade apropriada do processo para a gerncia de nvel superior. Sendo assim, esta atividade permite atender ao RAP 9 e a GP 2.10. O RAP 1 e a GP 1.1 consistem na gerao de produtos de trabalho (entrada e sada) e no fornecimento de servios que so esperados a partir da execuo do processo, a fim de evidenciar o atendimento do propsito deste processo. No que

98 diz respeito gerao de produtos de trabalho, o framework possui a atividade Gerar Produtos de Trabalho. Relacionado ao fornecimento de servios que auxiliam o atendimento do propsito do processo, cada uma das atividades da Fase Aplicao do Formalismo de Execuo atende parcialmente a esta recomendao, pois apoiam o atendimento dos objetivos do processo uma vez que possibilitam a sua execuo. Como cada organizao possui um objetivo especfico, no possvel que as atividades desta fase atendam completamente os diversos propsitos dos processos de cada uma destas organizaes. No entanto, o fato das atividades da Fase Aplicao do Formalismo de Execuo atenderem somente parcialmente ao RAP 1 e a GP 1.1, refora o objetivo do framework de propor atividades genricas, considerando-se que esta recomendao implica diretamente na gerao dos principais produtos requeridos pelos resultados dos processos e reas de processo (SOFTEX, 2011b) (SEI, 2010). Desta maneira, cada organizao evidenciar o atendimento desta recomendao dos modelos MRMPS e CMMI-DEV de acordo com o propsito do nvel de maturidade em que estiver sendo avaliada. Gerenciar Configuraes a atividade do framework que atende tanto a GP 2.6 quanto aos RAP 12 e 13, pois define uma forma de controlar as mudanas e revises dos produtos de trabalho, atravs do versionamento. Esta atividade consiste, tambm, em especificar nveis apropriados de controle de acesso aos produtos de trabalho, de acordo com a importncia destes para o projeto. O RAP 10 e a GP 2.9 determinam que garantias devem ser fornecidas a fim de verificar se a execuo do processo est aderente sua descrio, aos seus padres e procedimentos. Por esta razo, estas recomendaes so diretamente atendidas pela atividade Verificar Aderncia do Processo. Por fim, a atividade Verificar Aderncia dos Produtos de Trabalho permite atender ao RAP 14, pois determina que os produtos de trabalho produzidos devem ser analisado a fim de verificar se esto em conformidade com o que foi planejado para o processo. A partir desta avaliao, constata-se que todas as atividades do framework atendem totalmente ou parcialmente as recomendaes dos modelos CMMI-DEV e MR-MPS. Ressalta-se que as atividades que atendem somente parcialmente a estas recomendaes auxiliam diretamente o framework a disponibilizar uma proposta genrica que permite com que este seja mais facilmente adotado pelas organizaes

99 desenvolvedoras de software. Desta forma, considera-se que todas as recomendaes destes modelos, no que diz respeito Capacidade do Processo (Nvel F do MR-MPS e Nvel 2 do CMMI-DEV) so contempladas pelo Framework Spider-PE. Alm das formas de avaliao apresentadas anteriormente, destacam-se como trabalhos futuros 2 (duas) formas de validar o Framework Spider-PE: o desenvolvimento de uma ferramenta de execuo, descrito na Subseo 5.3.1, que sistematizar as atividades propostas neste framework; e a realizao de um estudo de caso, descrito na Subseo 5.3.2, da aplicao deste framework em um projeto real. Adicionalmente, este trabalho foi avaliado a partir da submisso e aprovao de artigos em eventos e peridicos especficos das reas de Engenharia de Software e de Qualidade do Processo, a citar: Journal of Software Engineering and Applications (PORTELA, VASCONCELOS, et al., 2012a e 2012b) e IX Workshop de Teses e Dissertaes de Qualidade de Software (PORTELA, VASCONCELOS e OLIVEIRA, 2011).

4.4

DIFERENCIAL DA PROPOSTA

O grande diferencial da proposta apresentada neste trabalho em relao s demais abordagens analisadas na Seo 2.4.3 o fato do Framework Spider-PE ter sido definido levando em considerao a necessidade de estabelecer atividades genricas que possibilitem a adoo deste trabalho em diferentes organizaes que pretendam executar seus processos de software. Esta caracterstica obtida atravs da aderncia aos nveis de Capacidade dos modelos de qualidade MR-MPS e CMMI-DEV, que podem ser genericamente aplicados a diversas reas de processos de uma organizao. De maneira similar, o padro SPEM, adotado como base para definio dos modelos de processos que sero posteriormente executados com o auxlio da linguagem xSPIDER_ML, permite representar, de maneira genrica, qualquer processo de desenvolvimento de software. A partir desta caracterstica, este padro pode ser adotado em diferentes culturas organizacionais (OMG, 2008). O trabalho incentiva, tambm, a execuo do processo em conformidade com estes modelos de qualidade pelas organizaes, que ainda pouco explorado pelas

100 abordagens do gnero. Estes padres so altamente aceitos pelo mercado, apresentando as melhores prticas relacionadas com a melhoria de processos de desenvolvimento (SEI, 2010) (SOFTEX, 2011b). As atividades definidas no framework permitem a gerao de indicadores indiretos do atendimento das recomendaes destes modelos de qualidade devido visibilidade da relao entre estas atividades e recomendaes, conforme demonstrado na Seo 4.3. O atendimento destas recomendaes permite, ainda, com que o framework possa ser adotado tanto em contextos tradicionais quanto geis, pois, conforme destacado na Seo 2.3, estes modelos so independentes de abordagens de processo. Alm disto, o framework permite a execuo de modelos de processo compatvel com o SPEM (OMG, 2008), pois apesar deste ser o padro para modelagem da OMG, no oferece mecanismos nativos para execuo automatizada do processo de software (BENDRAOU, COMBEMALE, et al., 2007). Neste sentido, outro diferencial em relao s abordagens apresentadas na Subseo 3.3.1 a integridade semntica dos elementos utilizados durante a modelagem de processos na fase de execuo. Esta caracterstica aumenta a relevncia do modelo de processo para alm da definio e representao de processos de software, estendendo o seu uso para a execuo. Por fim, destaca-se que as atividades deste framework podem ser instanciadas por uma Mquina de Execuo que adote o formalismo de execuo proposto neste trabalho, pois este formalismo incorpora conceitos referentes s diversas fases do ciclo de vida de processos. Neste contexto, possvel incorporar a esta Mquina de Execuo os conceitos de flexibilidade e execuo semi-automatizada.

4.5

CONSIDERAES FINAIS

Neste captulo foi proposto um framework para execuo de processos de software que define um fluxo de atividades genricas para organizaes desenvolvedoras de software que pretendam executar seus processos. Este framework permite que esta execuo ocorra de forma flexvel e semi-automatizada de acordo com as recomendaes dos modelos de qualidade CMMI-DEV e MR-MPS.

101 O mapeamento realizado na Seo 4.1 permitiu identificar a equivalncia entre estes dois modelos. Sendo assim, alm de fornece a base para definio das atividades do framework, esse mapeamento permitiu, tambm, a anlise da aderncia das atividades deste framework em relao s recomendaes destes modelos. O Framework Spider-PE foi detalhado a partir da descrio de suas fases, atividades e atores responsveis pela realizao destas atividades. Em seguida, realizou-se uma avaliao a partir da anlise do atendimento das atividades deste framework aos modelos de qualidade MR-MPS e CMMI-DEV. A partir do exposto neste captulo, conclui-se que o Framework Spider-PE apresenta muitos diferenciais em relao as demais abordagens para execuo, sendo uma proposta bastante vivel para organizaes desenvolvedoras de software que adotam padres como o SPEM e modelos como o MR-MPS e o CMMI-DEV.

102

CONCLUSES

Neste captulo sero apresentadas as principais concluses e contribuies do trabalho realizado para a rea de Engenharia de Software no contexto da Execuo de Processos, bem como alguns trabalhos futuros a serem realizados a partir do estudo apresentado nesta dissertao.

5.1

SUMRIO DO TRABALHO

O trabalho apresentado teve como foco as recomendaes de padres e modelos bem aceitos pela indstria de software no que diz respeito ao apoio execuo de processos de software. Na medida em que se teve como meta a construo de um framework de processo que pudesse ser utilizado em organizaes desenvolvedoras de software, optou-se por definir uma linguagem de execuo de processos modelados a partir do padro SPEM e seguir as recomendaes dos modelos de qualidade CMMI-DEV e MR-MPS. Este framework, alm de possibilitar a execuo flexvel e semi-automatizada do processo, objetiva poupar tempo na implementao e aprendizagem destes modelos de qualidade, visto que a gerao de indicadores do atendimento das recomendaes destes modelos seria possvel atravs da implementao desta proposta. Inicialmente, analisaram-se os padres de modelagem SPEM e BPMN no que diz respeito expressividade na representao de processos de software, tendo em vista que a definio do processo a fase anterior execuo do processo. A partir da anlise destes padres e objetivando estender a linguagem SPIDER_ML, foi definida a linguagem xSPIDER_ML, que especifica um formalismo que permite a execuo de modelos de processos de software.

103 Em seguida, analisaram-se os modelos de qualidade CMMI-DEV e MR-MPS no que diz respeito capacidade do processo, j que esta capacidade est diretamente relacionada com a execuo do processo na organizao. A partir desta anlise, realizou-se um mapeamento entre estes modelos, e com base neste mapeamento e no formalismo da linguagem xSPIDER_ML, um framework de processo foi elaborado. Este framework possui os papis, as atividades, os critrios de entrada e sada e os procedimentos necessrios para a execuo de processos de software. Posteriormente, este framework foi avaliado a partir da avaliao de seus componentes (linguagem xSPIDER_ML e mapeamento entre modelos) e da aderncia de suas atividades s recomendaes dos modelos de qualidade CMMI-DEV e MR-MPS. Para avaliar o formalismo de execuo deste framework, bem como a sua aplicabilidade em um contexto organizacional e integrao com demais fases do ciclo de vida de processos, so propostos alguns trabalhos futuros na Seo 5.3.

5.2

ANLISE DOS RESULTADOS

A seguir so apresentados os principais resultados obtidos durante o desenvolvimento deste trabalho: Anlise Comparativa a anlise comparativa entre os padres de modelagem SPEM e BPMN foi relevante para justificar a adoo das notaes do SPEM como base para definio dos modelos de processos que sero executados. Esta anlise pode auxiliar organizaes desenvolvedoras de software a optarem por qual tecnologia seria mais adequada na modelagem do seu processo de desenvolvimento, de acordo com o seu propsito; Linguagem de Execuo a linguagem de execuo xSPIDER_ML apresenta-se como uma proposta vivel de execuo de modelos de processo definidos a partir do padro SPEM. Alm disto, esta linguagem possibilita a execuo de processos: de forma flexvel e semi-automatizada, atravs da aplicao de seu formalismo em uma mquina de execuo; e em conformidade com os principais modelos de qualidade adotados na indstria, atravs da anlise comparativa entre os padres SPEM e BPMN;

104 Mapeamento o mapeamento entre as recomendaes do MR-MPS e do CMMI-DEV foi importante na medida em que propicia uma anlise de pontos correlatos entre os modelos. Este fato pode auxiliar organizaes que j utilizam um processo baseado em determinado modelo e que por ventura precisam realizar alteraes no seu processo a fim de intercambiar a adequao deste processo entre os modelos mapeados; Framework o framework de processo foi importante na medida em que levou em considerao as notaes do padro SPEM e as boas prticas do MR-MPS e CMMI-DEV na sua concepo. Assim, espera-se que este framework seja mais facilmente aceito, na medida em que se baseia em modelos e padres amplamente aceitos. Ressaltando que a anlise desta aceitao est condicionada a um estudo de caso real, que se caracteriza como um trabalho futuro desta proposta, descrito na Subseo 5.3.2; Produtos de Trabalho durante o desenvolvimento deste trabalho, foram gerados diversos produtos de trabalho a fim de registrar os resultados das pesquisas realizadas. Sendo assim: para registrar a anlise comparativa entre os padres SPEM e BPMN foi gerado um Relatrio de Pesquisa (Apndice A); a fim de descrever os elementos, estrutura e regras da xSPIDER_ML, foi elaborada uma especificao tcnica (Apndice B); e para registrar o mapeamento entre os modelos de qualidade realizado e as atividades, atores e fases do framework, foi especificada a Definio do Framework Spider-PE (Apndice C); Artigos Publicados uma verso inicial da proposta deste trabalho foi publicada e apresentada durante o WTDQS Workshop de Teses e Dissertaes em Qualidade de Software, dentro do contexto do SBQS 2011 Simpsio Brasileiro de Qualidade de Software, realizado em junho de 2011 (PORTELA, VASCONCELOS e OLIVEIRA, 2011). Este projeto, caracterizando-se como um subprojeto do SPIDER, foi aceito para o ciclo 2011/2012 do PBQP-SW (Programa Brasileiro de Qualidade e Produtividade em Software). Em 2012, tanto a anlise comparativa entre SPEM e BPMN quanto a linguagem xSPIDER_ML foram publicados no JSEA Journal of Software Engineering and Applications (PORTELA, VASCONCELOS, et al., 2012a e 2012b).

105 5.3 TRABALHOS FUTUROS

Essa seo apresenta os trabalhos que podem ser realizados a partir desta dissertao, indicando algumas possveis melhorias no estudo realizado e evolues que podem torn-lo mais completo e adequado para o propsito especfico de apoiar execuo de processos de software.

5.3.1

Desenvolvimento da Ferramenta de Execuo de Processos

Atualmente, encontra-se em desenvolvimento no laboratrio do Projeto SPIDER uma ferramenta de software livre que sistematizar as atividades do Framework Spider-PE e implementar o formalismo da xSPIDER_ML atravs de uma Mquina de Execuo. Esta ferramenta, denominada, tambm, de Spider-PE, permitir validar o framework proposto, bem como permitir a execuo de processos modelados com o apoio da ferramenta Spider-PM (BARROS e OLIVEIRA, 2010b). Basicamente, esta ferramenta apresenta 2 (dois) mdulos: Gerncia do Processo, derivada do mapeamento entre os modelos de qualidade; e Execuo do Processo, derivada do formalismo de execuo. importante destacar que o Mdulo de Gerncia do Processo, conforme apresenta a Figura 5.1, j foi desenvolvido.

Figura 5.1 - Mdulo de Gerncia do Processo da Ferramenta Spider-PE

106 5.3.2 Estudo de Caso Real (Aplicao do Framework)

Para avaliar o comportamento do Framework Spider-PE e a efetividade de suas atividades, faz-se necessrio realizar um estudo de caso real da aplicao deste framework em uma organizao. Assim, o framework seria verdadeiramente implementado e teria a sua utilizao acompanhada. Somente, desta forma, ser possvel analisar os principais resultados alcanados (a partir da gerao de mtricas e indicadores) pela proposta apresentada neste trabalho. Infelizmente, o tempo de realizao desta pesquisa (2 anos) no se mostrou suficiente para realizao deste estudo de caso. Entretanto, este estudo de caso encontra-se em fase de planejamento, onde se procura identificar, dentre as instituies parceiras do Projeto SPIDER, a citar FabSoft/CESUPA (Fbrica de Software do Centro Universitrio do Estado do Par), Pronto Digital e IFPA (Instituto Federal de Educao, Cincia e Tecnologia do Par), um projeto com perfil adequado para aplicao deste framework.

5.3.3

Integrao com o Processo de Avaliao e Melhoria do Processo

Conforme descrito neste trabalho, o framework proposto integra-se com as fases de Definio e Simulao do Processo, atravs da linguagem SPIDER_ML (BARROS e OLIVEIRA, 2010a) e das ferramentas Spider-PM (BARROS e OLIVEIRA, 2010b) e SPSM (CHAVES, TAVARES, et al., 2010). Para uma melhor contextualizao do framework e atendimento das demais fases do ciclo de vida de processos do projeto SPIDER, seria relevante que esta proposta fosse integrada s fases de Avaliao e Melhoria do Processo. A Fase de Avaliao responsvel por analisar as informaes quantitativas e qualitativas da execuo. A Fase de Melhoria estabelece novas caractersticas para que o processo possa ser modificado de acordo com as necessidades identificadas. A partir desta integrao, ser possvel estabelecer um cenrio para melhoria contnua do processo. Ambas as fases so temas de dissertaes de mestrado em andamento no Projeto SPIDER.

107

REFERNCIAS

BARROS, R. S. SPIDER_ML: Especificao Tcnica. Universidade Federal do Par, 2009.

Projeto SPIDER Disponivel em:

<http://www.spider.ufpa.br/projetos/spider_pm/SPIDER_ML%5B1.1%5D.pdf>. BARROS, R. S.; OLIVEIRA, S. R. B. SPIDER_ML: Uma Linguagem de Modelagem de Processos de Software. Anais da II Escola Regional de Informtica, Manaus, 2010a. BARROS, R. S.; OLIVEIRA, S. R. B. Spider-PM: Uma Ferramenta de Apoio Modelagem de Processos de Software. Anais do VIII Encontro Anual de Computao, Catalo, 2010b. BENDRAOU, R. et al. Definition of an Executable SPEM 2.0. In 14th Asia-Pacific Software Engineering Conference, Aichi, 2007. pp. 390397. BERTOLLO, G. Definio de Processos em um Ambiente de Desenvolvimento de Software. Dissertao de Mestrado Universidade Federal do Esprito Santo. Vitria. 2006. CHAVES, R. et al. A Software Process Simulator Machine for Software Engineering Simulation Games. Brazilian Symposium on Games and Digital Entertainment, Florianoplis, 2010. 49-58. CONRADI, R.; LIU, C. Process Modelling Languages: One or Many? Proceedings of the 4th European Workshop on Software Process Technology, Londres, 1995. pp. 98-118. DE MELLO, M. S. Melhoria de Processos de Software Multi-modelos Baseada nos Modelos MPS e CMMI-DEV. Dissertao de Mestrado - Universidade Federal do Rio de Janeiro. Rio de Janeiro. 2011. DERNIAME, J.; KABA, B.; WASTELL, D. Software Process: Principles, Methodology and Technology. Lecture Notes in Computer Science. 1999.

108 DOWSON, M.; NEIMEH, B.; RIDDLE, W. Fundamental Software Process Concepts. European Workshop on Software Process Modelling, Milan, 1991. EASTERBROOK, S. et al. Selecting Empirical Methods for Software Engineering Research. Guide to Advanced Empirical Software Engineering, Springer, 2007. ESTOLANO, M. H. R. Base de Mtricas para a Estao TABA. Dissertao de Mestrado - COPPE/Universidade Federal do Rio de Janeiro. Rio de Janeiro. 2005. FALBO, R. Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado - COPPE/Universidade Federal do Rio de Janeiro. Rio de Janeiro. 1998. FEILER, P. H.; HUMPHREY, W. S. Software Process Development and Enactment: Concepts and Definitions. International Conference on the Software Processes IEEE Computer Society Press, Berlin, 1993. FRANA, B. et al. Utilizao do Ambiente WebAPSEE na implantao do nvel G do MPS.BR no CTIC-UFPA. Anais do VIII Simpsio Brasileiro de Qualidade de Software. Ouro Preto. 2009. FROEHLICH, G. Process Modelling Support in Metaview. Master of Science Thesis - University of Sakatchewan. Canada. 1994. FUGGETTA, A. Software Process: A Roadmap. Proceedings of the Conference on The Future of Software, New York, 2000. GIBSON, D.; GOLDENSON, D.; KOST, K. Performance Results of CMMI-Based Process Improvement. CMU/SEI-2006-TR-004 - Software Engineering Institute, Carnegie Mellon University. Pittsburgh. 2006. GUIZZARDI, G.; FALBO, R.; GUIZZARDI, R. Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The Case of the ODE Software Process Ontology. Anais do XI Iberoamerican Workshop on Requirements Engineering and Software Environments. Recife. 2008. HUFF, K. Software Process Modeling. In Trends in Software: Software Process, FUGGETTA, A. and WOLF, A.: John Wiley and Sons, 1996. HUMPHREY, W. S. Managing the Software Process. The SEI Series in Software Engineering: Addison-Wesley, 1989.

109 HUMPHREY, W. S. A Discipline for Software Engineering. [S.l.]: Addison-Wesley, 1995. IBM. RUP for Small Projects. IBM Rational Unified Process, 2006. Disponivel em: <http://www.wthreex.com/rup/smallprojects/index.htm>. ISO/IEC. ISO/IEC 15504-2: Information Technology - Process Assessment Part 2 Performing an Assessment. ISO. Geneve. 2003. ISO/IEC. ISO/IEC 12207 Systems and Software Engineering Software Life Cycle Processes. ISO. Geneve. 2008. KEDJI, A. et al. Towards a Tool-Supported Approach for Collaborative Process Modeling and Enactment. In 18th Asia PacificSoftware Engineering Conference (APSEC), Ho Chi Minh, 2011. pp. 414-421. KELLNER, M. I.; HANSEN, G. A. Software Process Modeling. Carnegie Mellon University. Pittsburgh. 1988. LIMA, A. et al. WebAPSEE: Um Ambiente Livre e Flexvel Para Gerncia de Processos de Software. Anais do VII Workshop de Software Livre. Porto Alegre. 2006. LOMCHAMP, J. A Structured Conceptual and Terminological Framework for Software Process Engineering. The Second International Conference on the Software Process: Continuous Software Process Improvement, Berlin, 1993. pp. 41-53. MACIEL, R. et al. An Integrated Approach for Model Driven Process Modeling and Enactment. In XXIII Brazilian Symposium on Software Engineering, Fortaleza, 2009. pp. 104-114. MOITRA, D. Indias Software Industry: the software superpower. IEEE Software, 2001. Vol. 18, pp. 77-80. MUTAFELIJA, B.; STROMBERG, H. Systematic Process Improvement Using ISO 9001: 2000 and CMMI. [S.l.]: Artech House, 2003. OLIVEIRA, S. et al. SPIDER: Uma Proposta de Soluo Sistmica de um SUITE de Ferramentas de Software Livre de Apoio Implementao do Modelo MPS.BR.

110 Revista do Programa Brasileiro da Qualidade e Produtividade em Software, 2011. pp. 103-107. OLIVEIRA, S. R. B. Processo de Software: Princpios, Ambientes e Mecanismos de Execuo. Exame de Qualificao - Universidade Federal de Pernambuco. Recife. 2006. OLIVEIRA, S. R. B. ProDefiner: Uma Abordagem Progressiva para a Definio de Processos de Software no Contexto de um Ambiente Centrado no Processo. Tese de Doutorado - Universidade Federal de Pernambuco. Recife. 2007. OLIVEIRA, S.; VASCONCELOS, A.; MENDES, R. Mapping of CMMI Guide Concepts on SPEM Notations from Software Process Definition Context. Infocomp Journal of Computer Science, 2006. Vol. 5, pp. 83-92. OLIVEIRA, S.; VASCONCELOS, A.; ROUILLER, A. C. Uma Proposta de um Ambiente de Implementao de Processo de Software. Infocomp Journal of Computer Science, 2005. Vol. 4, pp. 71-78. OMG. Official Website. Object Management Group, 1997. Disponivel em: <http://www.omg.org/>. OMG. Unified Modeling Language (UML). Object Management Group, 2001. Disponivel em: <http://www.omg.org/spec/UML/>. OMG. Software & Systems Process Engineering Meta-Model Specification. Object Management Group, 2008. Disponivel em: <http://www.omg.org/spec/SPEM/2.0/PDF>. OMG. Business Process Model and Notation (BPMN). Object Management Group, 2011. Disponivel em: <http://www.omg.org/spec/BPMN/2.0/PDF>. OSTERWEIL, L. Software Processes are Software Too. INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, Monterey, 1987. PAULK, M. Surviving the Quagmire of Process Models, Integrated Models, and Standards. Proceedings of the Annual Quality Congress, 2004. PAULK, M. et al. Capability Maturity Model - Version 1.1. 4. ed. [S.l.]: Software IEEE, v. 10, 1993.

111 PAULK, M. et al. Software Quality and the Capability Maturity Model,

Communications of the ACM, 40, 1997. pp. 30-45. PFLEEGER, S. Software Engineering: theory and practice. 2. ed. [S.l.]: PrenticeHall, 2001. PMI. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition. Project Management Institute. Pennsylvania. 2008. PORTELA, C. et al. A Comparative Analysis between BPMN and SPEM Modeling Standards in the Software Processes Context. Journal of Software Engineering and Applications, No prelo, May 2012a. PORTELA, C. et al. xSPIDER_ML: Proposal of a Software Processes Enactment Language Compliant with SPEM 2.0. Journal of Software Engineering and Applications, No prelo, June 2012b. PORTELA, C. S. Anlise Comparativa entre os Padres SPEM e BPMN no Contexto da Modelagem de Processos de Software. Relatrio de Pesquisa/Projeto SPIDER RPS-001, 2011. Disponivel em: <www.spider.ufpa.br/projetos/spider_pe/SPEMxBPMN_RPS-001.pdf>. PORTELA, C. S.; GOMES, M. J. Spider-PE: Definio do Framework de Execuo de Processos. Projeto SPIDER - Universidade Federal do Par, 2011a. Disponivel em: <http://www.spider.ufpa.br/projetos/spider_pe/SPIDERPE_Framework_Execucao_Processos.pdf>. PORTELA, C. S.; GOMES, M. J. xSPIDER_ML: Especificao Tcnica. Projeto SPIDER pdf>. PORTELA, C.; VASCONCELOS, A.; OLIVEIRA, S. Spider-PE: Um Ferramental de Apoio Execuo de Processos aderente a Modelos de Qualidade. IX Workshop de Teses e Dissertaes de Qualidade de Software, Curitiba, 2011. PRESSMAN, R. S. Software Engineering: A Practioners Approach. 7. ed. [S.l.]: McGraw-Hill, 2010. Universidade Federal do Par, 2011b. Disponivel em: <http://www.spider.ufpa.br/projetos/spider_pe/xSPIDER_ML_Especificacao_Tecnica.

112 REIS, C. A. L. Ambientes de Desenvolvimento de Software e seus Mecanismos de Execuo de Processos de Software. Exame de Qualificao - Universidade Federal do Rio Grande do Sul. Porto Alegre. 2000. REIS, C. A. L. Uma Abordagem Flexvel para Execuo de Processos de Software Evolutivos. Tese de Doutorado - Universidade Federal do Rio Grande do Sul. Porto Alegre. 2003. REIS, R.; REIS, C.; NUNES, D. Automao no Gerenciamento do Processo de Engenharia de Software. Anais da Escola de Informtica do Norte 2002, Belm, 2002. SEI. Capability Maturity Model Integration for Development CMMI-DEV. Verso 1.3. Software Engineering Institute, 2010. Disponivel em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. SILVA, F. Um Modelo de Simulao de Processos de Software Baseado em Conhecimento para o Ambiente PROSOFT. Dissertao de Mestrado Universidade Federal do Rio Grande do Sul. Porto Alegre. 2001. SILVA, M.; BLANC, X.; BENDRAOU, R. Deviation Management during Process Execution. International Conference on Automated Software Engineering (ASE), Lawrence, 2011. pp. 528-531. SOFTEX. Guia de Implementao Parte 11: Implementao e Avaliao do MRMPS:2009 em Conjunto com o CMMI-DEV v1.2. Associao para Promoo da Excelncia do Software Brasileiro, 2011a. Disponivel em: <http://www.softex.br/mpsbr/_guias/guias/MPSBR_Guia_de_Implementa%C3%A7% C3%A3o_Parte_11.pdf>. SOFTEX. MPS.BR: Guia Geral 2011. Associao para Promoo da Excelncia do Software Brasileiro, 2011b. Disponivel em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>. SOMMERVILLE, I. Software Engineering. 9. ed. [S.l.]: Addison-Wesley, 2010. SOUZA, A.; REIS, C.; REIS, R. Interao Humana Durante Execuo de Processos de Software: Classificao e Exemplos. Relatrio de Pesquisa, RP310 Universidade Federal do Rio Grande do Sul. Porto Alegre. 2001.

113 SOUZA, J. N. S.; OLIVEIRA, S. R. B. Uma Proposta de Apoio Sistmico Avaliao de Processos com base no MA-MPS, SCAMPI e ISO/IEC 15504. Anais do Workshop de Teses e Dissertaes de Qualidade de Software - WTDQS, Belm, 2010. SUTTON, S.; TARR, P.; OSTERWEIL, L. An Analysis of Process Languages. Technical Report 95-78. Computer Science Department, University of Massachusetts. Amherst. 1995. TCU. Habilitao dos Licitantes: Qualificao Tcnica. Licitaes e Contratos : Orientaes e Jurisprudncia do TCU / Tribunal de Contas da Unio, Braslia, n. 4, 2010. THE STANDISH GROUP INTERNATIONAL. CHAOS Summary 2009. Boston. 2009. TRAVASSOS, G. Introduo Engenharia de Software Experimental. RT-ES590/02 - COPPE / Universidade Federal do Rio de Janeiro. Rio de Janeiro. 2002. TRAVASSOS, G. H. O Modelo de Integrao de Ferramentas da Estao TABA. Tese de Doutorado - COPPE/Universidade Federal do Rio de Janeiro. Rio de Janeiro. 1994. ZAMLI, K.; LEE, P. Taxonomy of Process Modeling Languages. The ACS/IEEE International Conference on Computer Systems and Applications, 2001. pp. 435-437. ZORZN, F.; RIESCO, D. Transformation in QVT of Software Development Process based on SPEM to Workflows. Journal Latin America Transactions, vol. 6, IEEE, 2008. pp. 655-660.

114

APNDICE A RELATRIO DE PESQUISA: ANLISE COMPARATIVA ENTRE OS PADRES SPEM E BPMN

Carlos dos Santos Portela

Relatrio de Pesquisa / Projeto SPIDER RPS 001

Prof. Dr. Sandro Oliveira Orientador

Belm/PA Dezembro/2011

115

RESUMO

Este relatrio de pesquisa tem por objetivo principal a comparao entre os padres SPEM (Software Process Engineering Metamodel) e BPMN (Business Process Modeling Notation) no contexto da modelagem de processos de software. O SPEM define um conjunto de esteretipos especficos para apoiar modelagem de processos de software enquanto o BPMN trata o processo de software como um processo de negcio, assim como os demais processos encontrados em uma organizao. Para realizar esta comparao, primeiramente adotou-se uma estrutura padro para definio de um processo de software, com base em uma ontologia de processos. Em seguida, identificaram-se as notaes dos padres SPEM e BPMN correspondentes semanticamente a estes elementos do processo padro. Este mapeamento contempla, tambm, componentes dos modelos de qualidade CMMI-DEV (Capability Maturity Model Integration for Development) e MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) a fim de auxiliar, posteriormente, a sua avaliao atravs de um experimento da modelagem de boas prticas destes modelos. Este experimento objetiva apresentar um cenrio mais prtico de como estes padres expressam processos de software. Por fim, realizou-se uma anlise destes padres a partir de caractersticas especficas, consideradas fundamentais para a modelagem e representao de processos de software. Espera-se que a anlise comparativa apresentada neste relatrio de pesquisa contribua para uma organizao desenvolvedora de software optar por qual padro seria mais adequado na definio e modelagem do seu processo de desenvolvimento. Palavras-Chave: Processos de Software, Modelagem de Processos, SPEM, BPMN, Modelos de Qualidade.

116

ABSTRACT

The main objective of this research report is to compare the SPEM (Software Process Engineering Metamodel) and the BPMN (Business Process Modeling Notation) standards in the software processes modeling context. The SPEM defines a specific set of stereotypes to support the software processes modeling. However, the BPMN treats the software process as a business process as the other organizational processes. To compare this standards, it was adopted a standard structure to define a software process based on a process ontology. Then, the SPEM and BPMN standard notations and their semantically corresponding elements in the default process were identified. This mapping also includes components of the CMMI-DEV (Capability Maturity Model Integration for Development) and MR-MPS (Reference Model for Software Process Improvement) quality models. This was necessary to assist in the mapping evaluation through an experiment which models the best practices of these quality models. This case study aims to present a more practical scenario of how these standards represent software processes. Finally, we carried out an analysis of these standards through specific characteristics considered necessary to model and to represent software processes. The comparative analysis presented in this research report is expected to contribute to the software development organizations which wants to choose whose standard would be suitable to define and to model its development processes. Keywords: Software Processes, Process Modeling, SPEM, BPMN, Quality Models.

117

1.

INTRODUO

Desde os primeiros projetos de desenvolvimento de grandes sistemas de software, uma das maiores preocupaes das organizaes era fornecer um esquema conceitual para gerenciar a complexidade das atividades de desenvolvimento de software (BENDRAOU et al, 2007). Sendo assim, foram propostos vrios modelos de ciclo de vida para o desenvolvimento de software, como Cascata, Espiral e Incremental. Porm, a granularidade destes modelos de ciclo de vida era muito alta e no descrevia elementos bsicos do processo, como os papis instanciados (CURTIS et al, 1992). Surgiu ento a necessidade de descrever nestes processos mais informaes sobre o que as organizaes esto realmente realizando durante o desenvolvimento de software, como, por exemplo, os procedimentos adotados. A partir desta necessidade, surgiu o conceito de Modelo de Processo. O modelo de processo pode ser definido como uma descrio formal do desenvolvimento de software onde vrios tipos de informaes devem ser integrados a este modelo de processo de maneira a indicar quem, quando, onde, como e por que os passos so realizados (LOMCHAMP, 1993). Este processo de software constitui o principal objeto de estudo da Engenharia de Software e pode ser definido como o conjunto de atividades que objetivam a construo de um software a partir de um conjunto de requisitos (HUMPHREY, 1989). A utilizao de modelos de processos traz para uma organizao um conjunto de vantagens (KELLNER; HANSEN, 1988): permite que o processo seja entendido mais facilmente; propicia a identificao de elementos do processo que podem ser melhorados; permite a reutilizao dos processos; e apoia as reas de gerncia de processos da organizao. Para se construir um modelo de processo de software necessria uma linguagem de modelagem que define um conjunto de notaes necessrias para representar os elementos que constituem um processo de software. Existem diversas

118 linguagens de modelagem de processos de software, destacando-se dentre estas duas: SPEM Software Process Engineering Metamodel (OMG, 2008), que utiliza as notaes da UML Unified Modeling Language, definindo um conjunto de esteretipos especficos para apoiar modelagem de processos de software; e BPMN Business Process Modeling Notation (OMG, 2011a), uma abordagem que trata o processo de software como um processo de negcio, assim como os demais processos encontrados em uma organizao. Estas duas linguagens destacaram-se na rea de modelagem de processos de software devido, em grande parte, ao suporte que ambas recebem da OMG Object Management Group (OMG, 1997), uma organizao internacional que tem por objetivo aprovar e manter padres abertos para aplicaes orientadas a objetos. Paralelamente ao surgimento destes modelos de processo e linguagens de modelagem, destaca-se o surgimento de diversos programas de melhoria do processo de software que so, tambm, fortes indicadores da elevada importncia de mtodos que contribuem para o aperfeioamento do processo de software (OLIVEIRA et al., 2006). A maioria destes programas exige que os processos estejam representados de alguma maneira, evidenciando assim a relevncia da modelagem de processos dado que esta estabelece uma maneira de representar esses processos a partir de modelos, fornecendo um mecanismo de apoio ao aperfeioamento dos processos de software (SOFTEX, 2011b). A obteno de certificaes de Programas de Melhoria do Processo agrega valor competitivo s organizaes tanto no panorama nacional como internacional e tem por finalidade auxiliar uma organizao na definio e melhoria contnua de um processo de software. No cenrio nacional, destaca-se o MR-MPS Modelo de Referncia para Melhoria do Processo de Software (SOFTEX, 2011b), que tem o objetivo de adaptar os modelos e normas internacionais de melhoria do processo de software j existentes para a realidade das empresas brasileiras. J as organizaes desenvolvedoras de software que desejam uma maior visibilidade no cenrio internacional tm aderido a modelos j consolidados como o CMMI-DEV Capability Maturity Model Integrated for Development (SEI, 2010), que tem como propsito fornecer guias para o melhoramento de processos e para o desenvolvimento de produtos e servios. Porm, estes modelos de qualidade para o processo acabam por dificultar a avaliao da equivalncia entre diferentes processos institucionalizados, o que po-

119 deria contribuir de forma significativa melhoria dos processos e dos prprios modelos de qualidade (OLIVEIRA et al., 2006). Sendo assim, faz-se necessrio a definio de uma estrutura padro de processo, que fornea elementos comuns a todos os processos de software. Este relatrio de pesquisa possui dois objetivos principais. O primeiro apresentar um mapeamento entre os padres de modelagem de processo SPEM e BPMN com os modelos de melhoria de processo CMMI-DEV e MR-MPS, a fim de realizar uma anlise destas linguagens de modelagem em relao expressividade na representao de processos de software. O segundo realizar uma anlise destes padres, a partir de caractersticas consideradas fundamentais para modelagem de processos e de um experimento da modelagem de reas de processo dos modelos de qualidade mapeados.

1.1

Contextualizao

A anlise comparativa entre os padres de modelagem BPMN e SPEM contribuiu para a concepo da SPIDER_ML (BARROS, 2009), uma linguagem de modelagem caracterizada como um perfil da SPEM 2.0. A escolha por se basear no SPEM devese ao fato de que este o padro da OMG para modelagem de processos de software e ao objetivo da SPIDER_ML de incorporar e formalizar as prticas de modelagem de processos utilizadas pela indstria de software a partir de um conjunto reduzido de elementos se comparado com o conjunto de elementos do SPEM (BARROS e OLIVEIRA, 2010a). Esta linguagem adotada na ferramenta Spider-PM (BARROS e OLIVEIRA, 2010b) em uso no Projeto SPIDER (OLIVEIRA et al. 2011). Este projeto possui como um dos focos principais, apresentar solues tecnolgicas (ferramentas de software livre, frameworks de processo, ferramentais de apoio) com caractersticas adequadas para atender as boas prticas descritas nos modelos de qualidade CMMI-DEV e MR-MPS. A pesquisa apresentada neste relatrio faz parte do escopo de uma dissertao de mestrado que consiste na definio de um Framework de Apoio Execuo de Processos de maneira flexvel e semi-automatizada (PORTELA et al. 2011). Para tal, prope a extenso da linguagem de modelagem SPIDER_ML, para que esta suporte a execuo de processos, a partir da definio de um formalismo de execuo, caracterizando assim uma linguagem de execuo, denominada xSPIDER_ML (eXecutable SPIDER_ML).

120

1.2

Estrutura do Relatrio

Alm deste captulo introdutrio, o prximo captulo deste relatrio, Captulo 2, apresenta a definio e os elementos bsicos de um processo de software, a fim de estabelecer uma estrutura padro para representar processos de software. Em seguida, no Captulo 3, apresentam-se as principais abordagens para modelagem de processos a partir dos padres SPEM e BPMN. No Captulo 4, realiza-se um mapeamento que permite a visualizao da equivalncia das notaes dos padres de modelagem SPEM e BPMN em relao aos componentes do processo padro e aos elementos que compem os modelos CMMI-DEV e MR-MPS. Neste captulo, inicialmente apresentam-se os principais trabalhos relacionados a esta pesquisa, Seo 4.1, e o mapeamento propriamente dito, Seo 4.2. Para validar essa anlise, um experimento apresentado na Seo 4.3. A fim de avaliar qual destas linguagens mais adequada para a representao de processos de software, uma anlise realizada na Seo 4.4. Por fim, o Captulo 5 apresenta as consideraes finais desta pesquisa.

121

2.

PROCESSO DE SOFTWARE

2.1

Definio de Processo de Software

O desenvolvimento de software considerado um processo criativo, intelectual e social que objetiva resolver problemas especficos (SOMMERVILLE, 2010). No entanto, para garantir que este software desenvolvido ir solucionar o problema em questo, o mesmo deve atender aos requisitos do cliente. Sendo assim, o Processo de Software pode ser definido como o conjunto de tarefas da Engenharia de Software necessrias para transformar os requisitos dos usurios em software (HUMPHREY, 1989). Definir o seu processo de software um dos principais objetivos de uma organizao que desenvolve software (OLIVEIRA, 2006). Um processo definido prov um conjunto de benefcios para esta organizao como (HUMPHREY, 1995): possibilita uma comunicao efetiva entre as pessoas envolvidas no processo; facilita o gerenciamento do processo; facilita o reuso do processo; facilita o aperfeioamento do processo. Porm, apesar de facilitar o reuso, uma definio de processo de software no pode ser genericamente aplicada em diferentes projetos de software uma vez que nenhum projeto idntico a outro (OLIVEIRA, 2006). Cada projeto apresenta caractersticas distintas como: complexidade do problema a ser solucionado, tamanho do software, recursos disponveis, tecnologias utilizadas, etc. Essas caractersticas devem ser levadas em considerao no momento da definio do processo de software.

122

2.2

Estrutura de Processo de Software

Justamente pelo fato dos projetos de software apresentarem caractersticas distintas, faz-se necessrio definir processo de software sob a forma de um modelo de processo de software e sua representao diagramtica, antes de realizar o mapeamento propriamente dito. Isso implica em identificar os elementos que compem a estrutura de qualquer processo de software bem como o relacionamento entre estes elementos. Apesar das diferenas existentes entre todos estes projetos de software, existe um conjunto bsico de elementos comuns a todos os processos de desenvolvimento de software. Esse conjunto de elementos denominado Processo Padro (ISO/IEC, 2003), que estabelece um processo fundamental para guiar a definio dos demais processos da organizao. Sendo assim, a estrutura geral da composio dos processos de software adotada neste trabalho baseia-se em um modelo derivado de uma ontologia de fundamentao, denominada UFO (Unified Foundational Ontology) (FALBO et al., 2008), aplicada no domnio de processos de software no Projeto ODE (Ontologybased software Development Environment), conforme mostra a Figura 1.

Figura 1 - Modelo de Processo Derivado da Ontologia de Falbo et al. (2008)

123 Esta Ontologia de Processo de Software, que foi desenvolvida para estabelecer uma conceituao comum para organizaes de software falarem sobre processos de software, ser a base para definio do processo padro adotado nesta pesquisa. De acordo com esta ontologia (FALBO et al., 2008), Processos so colees de atividades relacionadas que devem ser realizadas durante o desenvolvimento de um produto. Sendo assim, um Processo consiste de um conjunto estruturado de Atividades e, por conseguinte, toda a infraestrutura envolvida na realizao destas (Artefatos, Procedimentos e Recursos). Por sua vez, Atividades so as tarefas ou trabalhos a serem realizados. Uma Atividade requer Recursos e pode consumir ou produzir Artefatos. Para sua realizao, uma Atividade pode adotar um Procedimento. Esta Atividade pode ser decomposta em outras Atividades. Alm disso, Atividades, em qualquer nvel, podem depender da finalizao de outras Atividades, denominadas pr-atividades. O conceito de Atividade est presente em todos os modelos de processo de software e so consideradas primitivas que geram Artefatos a partir de Artefatos de entrada auxiliados por Recursos. Atividades podem corresponder a diferentes nveis, seja uma tarefa ou uma etapa do processo de desenvolvimento. A fim de descrever as etapas do Processo e as Atividades a serem realizadas em cada etapa, surge o conceito de Modelo de Ciclo de Vida, que estrutura Atividades e define uma abordagem de como organizar um projeto em Fases. O Ciclo de Vida iniciado quando um software concebido at quando entra em desuso, ou seja, contm um conjunto de Atividades de desenvolvimento, operao e manuteno. Aliado a este conceito temos a Combinao, a qual define a forma como um conjunto de Fases de um Modelo de Ciclo de Vida deve ser realizado e especifica o tipo de ordenao em que a estrutura pode ser: sequencial ou iterativa. Os Artefatos so produtos de software produzidos ou consumidos por Atividades durante a sua realizao, podendo ser Artefatos de cdigo, documentos ou componentes de software. J os Procedimentos so condutas bem estabelecidas e ordenadas para a realizao de Atividades. So utilizados para auxiliar a realizao das Atividades, podendo ser direcionados a um tipo especfico de Atividade, devendo ser adequados a uma tecnologia e a um paradigma de desenvolvimento. Aliado a este conceito, temos o Padro de Atividades que deve sugerir um procedimento pa-

124 ra a execuo de uma atividade. Representa um comportamento em que decomposies de uma atividade tm em comum. As pessoas, as ferramentas de software, os equipamentos, ou quaisquer outras infraestruturas necessrias execuo de uma atividade, so denominados Recursos. De uma maneira geral, Recursos so elementos necessrios para a realizao de uma atividade, tais como agentes humanos, equipamentos de hardware e ferramentas de software. Um recurso humano, especificamente, desempenha um papel na execuo das atividades do processo. Por fim, para limitar e/ou restringir a execuo das atividades definidas no processo, tem-se as Restries, que especificam as regras de definio do processo de software.

2.3

Modelagem de Processo de Software

Uma maneira efetiva de descrever um processo de software consiste na modelagem do mesmo. Um modelo de processo de software a representao dos aspectos mais relevantes de um processo de software do mundo real (OLIVEIRA, 2006). A modelagem de processos prov um mecanismo para o registro, entendimento, avaliao e comunicao de um processo de software e de suas melhorias (KELLNER e HANSEN, 1998). Ainda de acordo com Kellner e Hansen (1998), a modelagem de processos de software apresenta quatro objetivos principais: possibilitar a comunicao do processo de software; contribuir para o reuso do processo de software; dar suporte evoluo do processo de software; facilitar a gerncia do processo de software. Um modelo permite a representao nica do processo de software que pode ser compartilhada entre todos os indivduos envolvidos nesse processo como clientes, desenvolvedores, usurios, etc. Um modelo de processo pode ser utilizado, tambm, para o compartilhamento de conhecimento e transferncia de experincias em uma organizao (KELLNER e HANSEN, 1988). A partir da definio de um modelo, diversos processos de software podem ser instanciados, sendo necessrias apenas modificaes nas estruturas que so

125 nicas em cada processo e reaproveitando toda a estrutura comum compartilhada pelos processos. A evoluo do processo suportada pela modelagem uma vez que ela permite registrar todas as modificaes e lies aprendidas no processo. Alm disso, possvel analisar a efetividade dessas evolues por meio de simulaes em laboratrio (KELLNER e HANSEN, 1988). Com base em um modelo de processo possvel realizar estimativas e planejamentos, facilitando assim a gerncia do processo. Alm disso, a partir de um modelo de processo possvel, tambm, antecipar o efeito de algumas decises tomadas, o que contribui para um melhor gerenciamento do mesmo.

2.4

Modelos de Qualidade

O desenvolvimento de software um processo coletivo, complexo e criativo. Assim, a qualidade de um produto de software depende fortemente das pessoas, da organizao e de procedimentos utilizados para cri-lo e disponibiliz-lo (FUGGETA, 2000). Neste sentido, alcanar a estabilidade e continuar em um crescimento contnuo implica tanto na melhoria dos produtos de software quanto na melhoria dos processos de software (SOFTEX, 2011b). Este crescente interesse pela melhoria dos processos por parte das organizaes de software motivou o surgimento de normas e modelos de referncia, usados como base para a implementao de melhorias em processos de software (BIRK e PFAHL, 2002). Os modelos ajudam as organizaes a evolurem, de forma sistemtica, sua capacidade de desenvolver software (PAULK, 2004), permitindo uma viso macro destas organizaes, no considerando as caractersticas individuais de cada projeto (SPINOLA et al., 2008). Assim, os modelos possuem um conjunto essencial de conhecimento e boas prticas para diversas disciplinas da Engenharia de Software, descrevendo um caminho evolutivo para a melhoria dos processos de uma organizao. Porm, estes modelos no definem os processos que as organizaes devero seguir, pois este processo deve ser o mais adequado possvel natureza e cultura desta organizao. A seguir so apresentados os modelos de melhoria de processos abordados no contexto desta pesquisa.

126

2.4.1 CMMI-DEV
O propsito do modelo CMMI-DEV (Capability Maturity Model Integrated for Development) fornecer guias para o melhoramento de processos e para o gerenciamento do desenvolvimento de produtos e servios (SEI, 2010). Este modelo possui duas representaes: contnua e em estgios. A representao contnua oferece uma abordagem mais flexvel para melhoria do processo, a partir do foco em reas de processo especficas diretamente relacionadas ao objetivo de negcio da organizao. J a representao em estgios, oferece um passo a passo detalhado para melhoria do processo, descrevendo a sequncia de execuo das reas de processo a partir do agrupamento em nveis de maturidade que, quando alcanados, indicam uma melhoria substancial do processo. O foco desta pesquisa na representao em estgios do CMMI. A representao em estgio do modelo CMMI-DEV composta de Nveis de Maturidade, que definem um grau de melhoria de processos atravs do atendimento de um conjunto predefinido de reas de Processo. reas de Processo so um conjunto de prticas relacionadas que, quando implementadas coletivamente, satisfazem um conjunto de metas consideradas importantes para a melhoria nessa rea. As Metas Especficas descrevem as caractersticas nicas que devem estar presentes para satisfazer a rea de processo, atravs da realizao de Prticas Especficas. J as Metas Genricas descrevem as caractersticas que devem estar presentes para institucionalizar processos que implementam uma rea de processo, atravs do atendimento de Prticas Genricas. Um detalhamento das definies de cada um destes e demais componentes do modelo utilizados no mapeamento pode ser encontrado em SEI (2010).

2.4.2 MR-MPS
O modelo MR-MPS (Modelo de Referncia para Melhoria do Processo de Software) visa melhoria de processos de software em empresas brasileiras, a um custo acessvel, focando especialmente micros, pequenas e mdias empresas. De uma forma geral, o programa MPS.BR descreve o qu deve ser feito para melhoria gradual de processos, definindo nveis de maturidade que so organizados por processos que possuem objetivos a serem alcanados atravs de resultados esperados os quais so evidenciados em produtos de trabalho.

127 A estrutura conceitual do MR-MPS definida por Nveis de Maturidade que expressam um grau de melhoria atravs de um conjunto predefinido de Processos em que todos os objetivos no conjunto devem ser atingidos. Estes Processos so definidos como um conjunto de prticas relacionadas em uma rea que, quando implementadas coletivamente, satisfazem um conjunto de resultados considerados importantes para a melhoria nessa rea. Cada um destes Processos possui um Propsito que corresponde ao objetivo geral da execuo do processo em questo, caracterizados por Resultados Esperados. Estes correspondem aos resultados observveis do sucesso da realizao de um Propsito do Processo. Atributos de Processo representam uma caracterstica mensurvel de perfil de capacidade do processo aplicvel a qualquer processo, atingindo atravs de Resultados de Atributo de Processo. E por fim, o modelo disponibiliza um Guia de Implementao que contm orientaes para a implementao do Modelo de Referncia MR-MPS. Um detalhamento das definies de cada um destes componentes pode ser encontrado em SOFTEX (2011).

128

3.

ABORDAGENS PARA MODELAGEM DE PROCESSOS

Para representar cada um dos elementos do processo padro definido na Seo 2.2, pode-se adotar um padro de modelagem a fim de representar o modelo do seu processo e sua posterior visualizao, conduo e avaliao. Nesta pesquisa, optouse por utilizar os padres SPEM e BPMN levando em considerao que ambos possuem bastante aceitao pela indstria no mbito da modelagem de processos. Esta aceitao deve-se, em grande parte, ao suporte que ambas recebem da OMG (1997), uma organizao que possui grandes empresas como membros, sendo mundialmente reconhecida, e que tem por objetivo aprovar e manter padres abertos para aplicaes orientadas a objetos. Existem diversas abordagens para a construo de um modelo de processo de software. Cada uma dessas abordagens deve lidar com um grande conjunto de informaes de diferentes tipos. As abordagens para modelagem de processos de software mais frequentemente utilizadas so: a tradicional, que utiliza tecnologias especificamente desenvolvidas com o intuito de representar processos de software; e a abordagem que trata o processo de software como um processo de negcio, como os demais processos encontrados em uma organizao. Nas sees a seguir, estas duas abordagens sero detalhadas bem como os seus principais padres.

3.1

Abordagem Tradicional

Tradicionalmente, as pesquisas por tecnologias de processo de software foram conduzidas considerando-se apenas o contexto de uma equipe de desenvolvimento de software, ou seja, tendo uma viso vertical do desenvolvimento de software. A partir desta perspectiva, foram desenvolvidas tecnologias e padres para definio e modelagem de processo, dentre os quais se destaca, neste trabalho, o metamodelo SPEM (OMG, 2008).

129 Nesse contexto, uma das tecnologias existentes que mais se destacou foi a de linguagens para modelagem de processos, conhecidas pelo termo PMLs (Process Modeling Languages). Essas linguagens devem apresentar um conjunto mnimo de capacidades necessrias para representar um processo de software de modo satisfatrio. De maneira geral, estas linguagens estabelecem um mecanismo para a representao das atividades e tarefas do processo de software e os recursos relacionados com essas atividades e tarefas. A partir da anlise de diversas linguagens para modelagem, estabeleceu-se o seguinte conjunto de requisitos bsicos que devem ser atendidos por estas linguagens (SUTTON et al., 1995): permitir a descrio das atividades, tarefas e demais etapas do processo de software; permitir a descrio dos artefatos que devem ser produzidos e modificados e utilizados no decorrer do processo; possibilitar a descrio dos recursos utilizados durante a execuo do processo como, por exemplo, recursos humanos e ferramentas; permitir a definio dos diferentes tipos de relacionamentos entre os elementos do processo de software; possuir um mecanismo que assegure que os modelos produzidos apresentem os seus elementos interligados de maneira semanticamente vlida.

3.2

Abordagem de Processos de Negcios

Alm da Tradicional, existe outra abordagem para a modelagem de processos de software, que defende a ideia de que um processo de software deve ser, tambm, considerado como um dos processos de negcio de uma empresa. A rea de Gesto de Processos de Negcio surgiu no mercado como uma necessidade das empresas atuais para conhecerem, gerirem e aprimorarem seus respectivos negcios. A gesto de processos de negcio pode ser considerada um conjunto de mtodos e prticas que auxiliam a organizao na gesto do negcio atravs da identificao, entendimento e controle dos seus processos. Para isso, necessrio formalizar os processos de negcio buscando a obteno do entendimento uniforme, e utilizando uma linguagem comum. Dessa forma, a modelagem de processos de negcio fundamental nessa formalizao, pois ajuda a responder s questes princi-

130 pais do processo de negcio (ARAUJO et al., 2004): o que est sendo feito, por que est sendo feito, onde, por quem, quando e de que forma feito. De um modo geral, pode-se dizer que o conjunto de mtodos da gesto de processos de negcio possui as seguintes caractersticas (FILHO, 2007): Aperfeioamento contnuo ao invs da simples resoluo de problemas; Orientao dos funcionrios para uma viso horizontal (organizacional); Necessidades dos clientes direcionam os objetivos e tomadas de deciso; Gerentes de diversas funes recebem e produzem constantemente informaes sobre processos intra e interfuncionais para os quais seus departamentos contribuem. Nesse contexto, um dos termos que se destaca o BPM (Business Process Management), que pode ser definido como o desenvolvimento e manuteno de uma arquitetura de processos de negcio, que se utiliza de tcnicas, metodologias, ferramentas e gerenciamento humano para garantir que os processos da organizao sejam continuamente monitorados e melhorados (OMG, 2011a). Dentre as tecnologias que do suporte a BPM, destacam-se o Workflow e o BPMN. Um Workflow tem como principal objetivo a modelagem, automao e melhoria de processos de negcio (business processes). Um processo de negcio formado por um conjunto de atividades interligadas que buscam atingir um objetivo relacionado ao contexto organizacional. Neste sentido, um Processo de Software pode ser considerado um caso particular de Workflow para tratar o desenvolvimento de software. Esta a abordagem defendida nesta pesquisa, tendo em vista que ambas as tecnologias possuem o mesmo objetivo (OLIVEIRA, 2006): apoiar o envolvimento conjunto de agentes humanos com o apoio de sistemas de computao a partir de elementos-chave comuns, como comunicao, colaborao e coordenao. J o BPMN prope uma padronizao para as notaes de modelagem de processos de negcio, o que considerado um ponto falho da tecnologia de Workflow. Levando em considerao que a rea de TI (Tecnologia da Informao) de uma empresa uma de suas unidades, com objetivos especficos, mas principalmente que tm por finalidade auxiliar a organizao a atender as suas metas principais, possvel dizer que um processo de software pode ser considerado um caso especfico de processo da organizao. Dessa forma, pode-se concluir que a viso, conceitos, ferramentas e tecnologias, como Workflow, da rea de Gesto de Pro-

131 cessos de Negcio podem ser perfeitamente aplicadas definio e, sobretudo, modelagem de processos de software. Esta abordagem traz como um dos principais benefcios a possibilidade de alinhar o processo de software aos objetivos globais da organizao (ARAUJO et al., 2004).

3.3

SPEM (Software Process Engineering Metamodel)

O SPEM um padro para especificar, definir processos de software e seus componentes. O modelo foi construdo a partir de um subconjunto, chamado de SPEM Foundation, do metamodelo da UML 1.4. O SPEM oferece algumas representaes e esteretipos para modelar seus principais elementos em diagramas UML. Atualmente encontra-se na verso 2.0 (OMG, 2008). Em seu modelo conceitual, o SPEM est fundamentado na ideia principal de que um processo de desenvolvimento de software uma colaborao entre entidades abstratas ativas, chamadas papis do processo (role definitions), que realizam operaes, denominadas atividades (activities), sob entidades concretas e tangveis, chamadas produtos de trabalho (work products). A descrio detalhada dos principais elementos que compem o SPEM pode ser encontrada em OMG (2008). Este relatrio apresenta apenas alguns destes conceitos considerados relevantes para atingir o propsito da pesquisa em questo.

3.3.1 Estrutura de Pacotes


O escopo do SPEM propositadamente limitado aos elementos mnimos necessrios para definir qualquer processo de desenvolvimento de software, sem a adio de caractersticas especficas para domnios de desenvolvimento ou disciplinas. O objetivo suportar uma grande variedade de mtodos e processos de desenvolvimento de diferentes estilos, origens culturais, nveis de formalismo e modelos de ciclo de vida (OMG, 2008). Ele oferece, tambm, estruturas especficas para reforar tais modelos de comportamento genricos que so caractersticos para descrever processos de software. Em outras palavras, o SPEM 2.0 se concentra em fornecer estruturas de informao adicionais necessrias para processos modelados a partir de diagramas de atividades da UML 2.0 a fim de descrever um processo de desenvolvimento real.

132 O metamodelo SPEM 2.0 est estruturado em 7 (sete) pacotes principais, conforme ilustrado na Figura 2. Esta estrutura divide o modelo em unidades lgicas, onde cada pacote trata um aspecto especfico. Estas unidades lgicas so relacionadas atravs do mecanismo de "merge".

Figura 2 - Estrutura do Metamodelo SPEM 2.0 (OMG, 2008)

O pacote Core introduz classes e abstraes que constroem a base para todos os demais pacotes do metamodelo. O bloco de construo deste pacote a classe WorkDefinition, que generaliza qualquer trabalho com a SPEM 2.0. O pacote ProcessStructure define elementos para representar modelos de processos bsicos atravs de um fluxo de Activities com seus WorkProductUses e RoleUses. A possibilidade de descrever textualmente esses elementos (ou seja, adicionar propriedades que descrevem o elemento) fornecida pelas classes do pacote ManagedContent, que fornecem os conceitos de gesto da descrio textual dos elementos do processo. Um exemplo de tal conceito disponibilizado pela classe Guidance, que permite descreve textualmente os procedimentos a serem adotados. O pacote MethodContent define conceitos fundamentais para a especificao de contedo, como Roles, Tasks e WorkProducts. O pacote ProcessWithMethods define o conjunto de elementos necessrios para a integrao de processos. Estes processos so definidos por meio de conceitos do pacote ProcessStructure e, tambm, a partir de instncias do pacote MethodContent.

133 O pacote MethodPlugin fornece mecanismos para a gesto e reutilizao de bibliotecas de contedos de mtodos e processos. Por fim, o metamodelo possui o pacote ProcessBehavior que fornece uma maneira de ligar os elementos do processo SPEM 2.0 com modelos de comportamento externo, como os modelos UML (OMG, 2011b) ou modelos BPMN (OMG, 2011a). Nesta seo foram apresentados os elementos do padro SPEM como um metamodelo. Contudo, o SPEM pode, tambm, ser definido como um UML Profile, o que adiciona a ele a expressividade da UML. UML Profiles so extenses da semntica padro da UML, com o objetivo de customizar a UML para um domnio ou propsito especfico. No caso do SPEM, o objetivo deste profile representar o processo de desenvolvimento de software. As notaes adicionadas por este profile so apresentadas na seo a seguir.

3.3.2 Notaes do SPEM 2.0


O uso do SPEM como um UML Profile faz com que uma grande quantidade de desenvolvedores, j familiarizados com a UML, possa utilizar esses conhecimentos no domnio da modelagem de processos de software. Esta relao permite que esteretipos deste profile possam ser utilizados em conjunto com diagramas da UML, como os diagramas de pacotes e de atividades. O Quadro 1 apresenta estes esteretipos do SPEM Profile, que apresentam notaes prprias do SPEM. Para visualizar a lista completa de esteretipos, consulte a especificao do SPEM (OMG, 2008).
Quadro 1 - Esteretipos do SPEM Profile (Adaptado de OMG, 2008) Esteretipo Notao Descrio

Process

Uma instncia do Processo Padro para um projeto especfico. Um conjunto de definies de tarefa que contribuem para o atendimento de um mesmo objetivo do processo. Um perodo significativo de um Processo que possui um objetivo especfico.

Discipline

Phase

134
Esteretipo Notao Descrio

WorkProductDefinition

Um conjunto de caractersticas desejadas para um produto de trabalho que pode ser reutilizado em diferentes processos. Um trabalho que deve ser realizado no decorrer de um Processo e que pode ser decomposto em outras atividades ou tarefas. Um trabalho reutilizvel e que no pode ser decomposto. Um conjunto de capacidades desejadas para um determinado papel que pode ser reutilizado em diferentes processos. Uma conduta que deve ser adotada durante a realizao de uma tarefa do Processo. utilizado para organizar a realizao de uma atividade, atravs de etapas ou subunidades de trabalho.

Activity

TaskDefinition

RoleDefinition

Guidance

Step

3.4

BPMN (Business Process Modeling Notation)

O BPMN uma notao da metodologia de gerenciamento de processos de negcio e trata-se de uma srie de cones padres para o desenho de processos. O objetivo apoiar a gesto de processos de negcios tanto para usurios tcnicos e usurios de negcios. Foi desenvolvido pela BPMI (Business Process Management Initiative) e atualmente, na sua verso 2.0, mantida pela OMG (2011a). A proposta do BPMN prover uma notao rapidamente compreensvel por todos os participantes do negcio, como os analistas de negcio (que faro os primeiros rascunhos dos processos), os desenvolvedores tcnicos (responsveis por implementar as tecnologias necessrias para realizao desses processos), como, tambm, as pessoas envolvidas no negcio (que gerenciam e monitoram o processo). Dessa forma, o BPMN procura criar uma ponte padro para o desnvel semntico entre modelagem de processos de negcio e implementao de processos. Para tal, BPMN prov a criao de BPD (Business Process Diagram), que so diagramas voltados para o uso de pessoas que modelam e gerenciam processos de

135 negcio, suportando conceitos como o B2B (Business to Business), ou seja, processos inter-organizacionais. Outro recurso do BPMN a possibilidade da sua extenso por modeladores e ferramentas, atravs de novos marcadores nos elementos estendidos, mas sem que sua forma bsica seja alterada. Isso permite com que necessidades de modelagem no suportadas pela notao padro possam ser atendidas (OMG, 2011a).

3.4.1 Classificao dos Processos


O BPMN cobre a criao de vrios tipos de processos de negcio, e permite a criao de processos de negcio completos. Ele define trs principais tipos de submodelos dentro de um modelo BPMN completo: privados, abstratos e colaborativos. Os Processos de Negcio Privados correspondem aqueles que ocorrem dentro da organizao. Estes processos possuem atividades realizadas internamente e que interagem entre si. So utilizados quando se deseja visualizar apenas parte de um processo sem se preocupar com o processo como um todo. o tipo de processo mais comum, composto por uma srie de atividades que so realizadas unicamente dentro de uma empresa. O fluxo da sequncia do processo contido dentro de um elemento Pool e no pode cruzar os limites desse Pool, conforme mostra exemplo na Figura 3. Neste exemplo, representa-se o fluxo realizado pela Fbrica 1 para tratar uma determinada Ordem de Servio, desde o seu recebimento at a sua execuo.

Figura 3 - Exemplo de Processo de Negcio Privado

J os Processos de Negcio Abstratos so utilizados quando se deseja visualizar as interaes entre os fluxos, ou seja, as comunicaes. So processos pblicos que retratam as interaes das atividades pertencentes a um processo privado com outra entidade de negcio externa ao processo privado.

136 comum um processo inclui atividades que so realizadas fora da empresa, onde no se tem a gerncia sobre a execuo destas atividades. Utiliza-se ento um modelo abstrato para representar uma entidade independente, com processos prprios, mas que no se pode modelar ou no interessa modelar. No exemplo da Figura 4, o Fornecedor responsvel pelo beneficiamento da matria prima. Este um processo interno do fornecedor, o qual no conhecido pela Fbrica 1. Sendo assim, deve ser modelado como um processo abstrato (caixa preta).

Figura 4 - Exemplo de Processo de Negcio Abstrato

Por fim, os Processos de Negcio Colaborativos so aqueles que permitem modelar as interaes entre dois ou mais processos de negcio, descrevendo processos B2B. Estes diagramas de processos geralmente permitem um ponto de vista global. As interaes so descritas como as sequncias de atividades e as trocas de mensagens entre os participantes, conforme mostra Figura 5.

Figura 5 - Exemplo de Processo de Negcio Colaborativo

137 No exemplo da Figura 5, a empresa Administradora de Carto de Crdito faz a autorizao de pagamento por carto de crdito. Neste caso, este processo interessa a Empresa 1 (que realiza a venda). Portanto, de fundamental importncia que este processo seja desenhado (modelado) explicitamente. A descrio dos principais elementos que compem estes processos BPMN pode ser encontrada em OMG (2011a). Este relatrio apresenta apenas alguns destes conceitos considerados relevantes para atingir o propsito da pesquisa em questo.

3.4.2 Notaes do BPMN 2.0


Os diagramas de processos de negcio modelados com BPMN permitem a compreenso desde os mais simples at os mais complexos processos de negcio. Esses elementos so organizados em quatro categorias (OMG, 2011a): Flow Objects (Objetos de Fluxo); Conecting Objects (Objetos de Conexo); Swimlanes (Raias); e Artifacts (Artefatos). A seguir, no Quadro 2, sero apresentados estes elementos e suas respectivas classificaes, descries e notaes grficas.
Quadro 2 - Elementos do BPMN 2.0 (Adaptado de OMG, 2011a) Classificao Elemento Notao Descrio Um evento algo que acontece durante a execuo do processo. Ele afeta a execuo do processo, baseado no momento em que afetam o processo: Start (Incio), Intermediate (Intermedirio) e End (Fim). Atividade um termo genrico para um trabalho desempenhado por uma organizao. Uma atividade pode ser atmica ou composta. Os tipos de atividades que so parte de um modelo de processo so: Process (Processo), Sub-Process (SubProcesso) e Task (Tarefa). Um Gateway usado para controlar a divergncia ou convergncia de fluxos de sequncia. Dessa forma, poder determinar ramificao, bifurcao, ligao e juno de caminhos.

Event

Flow Objects

Activity

Gateway

138
Classificao Elemento Notao Descrio Um fluxo de sequncia usado para indicar a ordem em que atividades sero executadas em um processo. Um fluxo de mensagem usado para mostrar a troca de mensagens entre dois participantes do processo. Uma Associao usada para associar informao a objetos de fluxo. Uma piscina representa um participante do processo. Pool representa um recipiente que separa um conjunto de atividades de outro Pool, geralmente no contexto de B2B. Uma raia uma sub-partio de uma Pool. Lanes so usadas para organizar e categorizar as atividades. Objetos de dados so considerados artefatos porque proveem informao acerca do que as atividades precisam para serem executadas e o que elas produzem.

Sequence Flow Connecting Objects Message Flow

Association

Pool Swimlanes

Lane

Data Object

Artifacts

Group

Um grupo de atividades engloba um grupo de objetos para propsitos de anlise ou documentao.

Text Annotation

Anotaes de texto so mecanismos utilizados pelos modeladores para prover informao adicional aos leitores do diagrama de processo de negcio.

139

4.

ANLISE COMPARATIVA ENTRE SPEM E BPMN

4.1

Trabalhos Relacionados

Uma pesquisa semelhante descrita neste relatrio apresentada em Oliveira et al. (2006), que prope a modelagem dos conceitos do guia do CMMI a partir das notaes definidas pelo SPEM, como base para a modelagem de processos de software. Este mapeamento visa capturar informaes sobre a aderncia e compatibilidade do CMMI no SPEM, identificando os componentes do processo de software e os seus relacionamentos baseando-se na anlise deste modelo. A motivao deste trabalho visa composio de um metamodelo de processo de software, para um Ambiente de Desenvolvimento de Software, que possibilite definies de processo aderentes ao CMMI e SPEM. No entanto, esta proposta no apresenta uma anlise entre as linguagens de modelagem existentes para fundamentar a escolha da linguagem adotada no seu metamodelo. Existem duas abordagens que propem a automatizao da execuo de processos de desenvolvimento de software modelados a partir do padro SPEM. A fim de alcanar este objetivo, ambas as abordagens (BENDRAOU et al., 2007) (ZORZN e RIESCO, 2008) aplicam tcnicas de transformao de modelos especificados no SPEM para uma especificao de subprocessos do BPMN, com o intuito de torn-los executveis a partir da linguagem de execuo de processos BPEL4WS (Business Process Execution Language for Web Services). Uma das etapas iniciais deste processo consiste justamente em realizar o mapeamento entre os componentes do SPEM e do BPMN. Porm, de maneira geral, transformaes entre modelos impem algumas etapas de refinamento antes que eles possam ser executados, o que, alm de poder ocasionar a perda de semntica apropriada, demanda um grande esforo na manuteno do mapeamento entre modelos no caso de qualquer alterao no processo.

140 Em Prez (2007) apresentado um estudo comparativo entre diversos padres para modelagem de processos, dentre eles o SPEM e o BPMN, no que diz respeito s caractersticas consideradas necessrias para atingir este propsito. Porm, este trabalho no apresenta nenhuma validao prtica da pesquisa realizada. Atravs do mapeamento apresentado neste relatrio, possvel verificar quais destes padres e modelos possuem componentes semanticamente equivalentes entre si. No caso dos componentes considerados no-equivalentes, destacam-se aqueles, que para uma melhor aderncia, requerem alguma condio, restrio ou at mesmo composio de mais de um componente do modelo. A partir do experimento, possvel ter um cenrio mais prtico de como os modelos e padres se relacionam, permitindo extrair informaes relevantes para uma proposta que satisfaa as principais prticas e recomendaes inerentes a processos de software no mbito de um modelo de qualidade.

4.2

Mapeamento

Esta seo pretende descrever o mapeamento entre as notaes para modelagem de processos de software dos padres SPEM (Seo 3.3) e BPMN (Seo 3.4) com os modelos de qualidade CMMI-DEV (Subseo 2.4.1) e MR-MPS (Subseo 2.4.2) para que posteriormente se realize uma anlise destas notaes no que diz respeito representatividade dos conceitos definidos nestes modelos de qualidade. Assim, com base na estrutura do processo de software padro, apresentada na Seo 2.2, nas notaes definidas pelo SPEM e BPMN para representar os processos e seus elementos, e nos componentes dos modelos CMMI-DEV e MR-MPS, o Quadro 3 apresenta um mapeamento que representa, estruturalmente, um modelo de referncia para processos de software em geral.
Quadro 3 - Mapeamento da Estrutura Padro do Processo versus Notaes do SPEM e BPMN versus Componentes do CMMI-DEV e MR-MPS Estrutura Padro do Processo Processo Modelo de Ciclo de Vida Combinao Process ProcessComponent Process Iteration Phase Embedded Sub-Process Maturity Levels Nveis de Maturidade Notaes do SPEM Notaes do BPMN Componentes do CMMI-DEV Componentes do MR-MPS

141
Estrutura Padro do Processo Discipline Activity TaskUse Notaes do SPEM Notaes do BPMN Embedded Sub-Process Task Componentes do CMMI-DEV Process Area (PA) Specific Pratices (SP) Specific Goal (SG) Subpractices Data Object Pool Lane Typical Work Product Stakeholders Subpractices Generic Practice (GP) Elaboration Shared Vision Amplification Specific Practices (SP) Generic Goal (GG) Generic Practice (GP) Rule Componentes do MR-MPS Processo Resultados Esperados (RE) Propsitos Guia de Implementao (Parcialmente)

Atividade

Step Artefato Recurso WorkProductDefinition WorkProductUse RoleUse RoleDefinition Guidance Guideline ToolMentor Template Checklist Step

Guia de Implementao Guia de Implementao (Indiretamente)

Procedimento

Text Annotation

Padro de Atividades

Restries

WorkSequence ContentDescription Goal Precondition WorkDefinitionParameter Category WorkProductRelationship

Guia de Implementao e Resultado de Atributo de Processo (RAP) Resultados Esperados Atributo de Processo (AP) Resultado de Atributo de Processo (RAP)

Purpose Statement Introductory Notes Related Process Areas

A representao de Processo foi mapeada em dois componentes no SPEM, o Process e o ProcessComponent, que possuem uma semntica semelhante e que expressam um conjunto estruturado de atividades para realizao do processo. J o BPMN no possui nenhuma notao especifica para representar o Processo, pois este processo representado pelo diagrama de processo como um todo. Os modelos CMMI-DEV e MR-MPS no possuem nenhum componente equivalente, pois es-

142 tes sugerem reas de conhecimento e processos para a definio de processos do ciclo de vida de software. O Modelo de Ciclo de Vida pode ser representado no SPEM a partir da juno de dois componentes, o Process e Iteration, descrevendo a vida do software desde a sua concepo at o seu desuso, onde o Process determina o tipo de ciclo de vida a ser executado (sequencial ou iterativo) e o Iteration especifica como este encontrasse organizado. Tanto o CMMI-DEV quanto o MR-MPS no abordam ciclo de vida em seus modelos, pois sugerem que a definio destes deve ser o mais adequado possvel natureza e cultura da organizao, ou seja, a prpria organizao deve definir seu ciclo de vida. Contudo, estes modelos de qualidade podem ser adotados em composio com diferentes tipos de ciclos de vida. O componente Combinao representado por Phase e ProcessPackage no SPEM e no BPMN por Independent Sub-Process e Embedded Sub-Process. Phase representa um perodo significativo de tempo para um projeto, sendo constitudo de interaes e marcos, e o ProcessPackage contm elementos de definio do processo (atividades, papis, produtos). Um Independent Sub-Process pode, tambm, englobar papis, atividades e produtos em sua definio. Um Embedded SubProcess representa qualquer tipo de trabalho realizado em um processo que constitudo por outras atividades. A Combinao nos modelos CMMI-DEV e MR-MPS est focada em nveis de maturidade, correspondente a fase de maturidade do processo, em composio notao Phase. Uma Atividade no modelo de referncia pode ser representada de maneiras diferentes no SPEM e no BPMN. Uma Discipline no SPEM agrupa prticas de acordo com um tema em comum, sendo este conceito representado por Process Area no CMMI-DEV, descrevendo todo o trabalho realizado para alcanar o objetivo e no MR-MPS por Processo, representando um conjunto de metas relacionadas, em uma determinada rea, consideradas importantes para a melhoria desta rea. Uma Discipline corresponde a um Embedded Sub-Process, no BPMN. Uma TaskUse no SPEM equivalente a uma Task no BPMN, pois ambas representam uma tarefa atmica, que no pode ser dividida em outras. J nos modelos de qualidade, uma Atividade corresponde as Specific Practices e Specific Goals no CMMI-DEV por representar uma parte do trabalho a ser realizado e um objetivo da rea de process. No MR-MPS, Atividades correspondem a Propsitos e Resulta-

143 dos Esperados, onde representam respectivamente o objetivo geral da execuo do processo e as atividades que devem ser realizadas a fim de atender este propsito. Relacionados aos conceitos de Propsitos e Specific Goals destes modelos, tem-se a notao Activity do SPEM, que representa qualquer tipo de trabalho realizado em um processo que constitudo por outras atividades. Este conceito mapeado para um Embedded Sub-Process, no BPMN que, tambm, pode ser formado por vrias atividades. Nos modelos de qualidade, est relacionado, tambm, rea de Processo e Processo. Um Step, no SPEM, pode representar uma atividade atmica, sendo mapeada para dois conceitos na estrutura do processo padro: Atividade, quando esta representar uma nica atividade de forma ordenada para especificar como uma macro-atividade pode ser executada, e, assim sendo, no CMMI-DEV equivale a Subpractices j que equivale a uma atividade atmica. De maneira parcial, o Guia de Implementao do MR-MPS especifica passos a serem seguidos na adoo de algumas eas de Processo; e Padro de Atividades, quando este representar uma coleo de atividades desordenadas que podero servir como sugesto para a deteco de subatividades de uma macro-atividade, quando a esta macro-atividade for associado um mtodo como procedimento. Assim sendo, equivale no CMMI-DEV a Specific Pratice e Specific Goal e aos Resultados Esperados do MR-MPS, pois engloba prticas e objetivos de uma rea de processo adotada. Um Artefato no processo padro considerado um WorkProductDefinition no SPEM e um Data Object no BPMN, que representa qualquer tipo de produto consumido ou gerado durante o processo, sendo o componente Typical Work Product do CMMI-DEV semanticamente equivalente. No caso do SPEM ele ainda possui um componente especial para artefatos que representa a instanciao de documentos, denominado WorkProductUse. No entanto, esta representao um subtipo do WorkProductDefinition. No caso do MR-MPS, o Guia de Implementao faz referncias a artefatos especficos que so indicadores do atendimento a determinados Resultados Esperados. Um Procedimento representado pelo componente Guidance e suas extenses como Guideline, Template, ToolMentor e Checklist no SPEM, e no BPMN por um Text Annotation, que basicamente uma descrio textual que pode ser vinculada a uma Atividade. No CMMI-DEV, procedimentos esto contidos nas Subpractices, Generic Practices Elaborations ou Discipline Amplifications, dependendo da

144 semntica da descrio destes componentes. J no MR-MPS, podemos encontrar exemplos de Procedimentos no Guia de Implementao e nos Resultado de Atributos de Processo, pois estes objetivam auxiliar a institucionalizao do processo. A representao de Recurso no processo padro mapeado no SPEM como um RoleDefinition e um RoleUse, pois representam os papis necessrios para a realizao das atividades e, no BPMN, como Pool que engloba uma srie de Tasks, representando um participante do processo e Lanes que so subdivises de um Pool. No caso do CMMI-DEV so definidos por Stakeholders. No caso do modelo MRMPS, recursos so representados indiretamente a partir do Guia de Implementao, pois este apenas indica o perfil de um recurso, no descrevendo habilidades e competncias necessrias. As Restries so representadas no SPEM basicamente por diversos componentes que especificam classificaes ou definem limitaes aos demais componentes. No BPMN, as restries so representadas pelo componente Rule, que especifica determinadas condies para realizao de um evento. No CMMI-DEV, as restries podem ser, dependendo do contexto agregado, representadas por Generic Goals, Generic Practices, Purpose Statement, Introductory Notes, Related Process Areas. Estes componentes do CMMI-DEV limitam e restringem a execuo das atividades nas reas de processo. J no MR-MPS, as restries so apresentadas a partir de Atributos de Processo e Resultados de Atributos de Processo, que determinam algumas condies para a institucionalizao do processo na organizao. O confronto dessas duas abordagens pode levar concluso de qual padro conferir maior produtividade e qualidade aos seus processos de desenvolvimento. A fim de auxiliar o atendimento deste objetivo, a Seo 4.3 deste relatrio apresenta um experimento. Este experimento tem por objetivo apresentar um cenrio mais prtico do uso dos padres de modelagem de processo SPEM e BPMN, no contexto de modelos de qualidade do processo, a partir da modelagem de reas do processo e processos destes modelos. Alm disto, o experimento apresentado na seo a seguir permite a validao do mapeamento apresentado neste relatrio de pesquisa.

4.3

Experimento

Para realizar o experimento relatado nesta seo foi tomado como base o mapeamento apresentado no Guia de Implementao Parte 11 do MPS.BR (SOFTEX, 2011a), que contm orientaes para a implementao e avaliao do Modelo de

145 Referncia MR-MPS:2009 em conjunto com o CMMI-DEV v1.2. Este mapeamento entre os dois modelos levou em considerao que os Processos do MR-MPS so correspondentes s reas de Processo do CMMI-DEV e que os Resultados Esperados dos Processos do MR-MPS so correspondentes s Prticas Especficas das reas de processo do CMMI-DEV. A partir deste pressuposto, optou-se por modelar a rea de Processo Gesto de Requisitos (REQM) do modelo CMMI-DEV, pertencente ao nvel 2 de maturidade na representao por estgios, juntamente com o Processo Gerncia de Requisitos (GRE) do MR-MPS, pertencente ao nvel G de maturidade. Sendo assim, ambos sero modelados conjuntamente tanto no padro SPEM quanto no BPMN, levando em considerao a equivalncia entre os componentes destes modelos de qualidade, conforme o mapeamento apresentado na Seo 4.2 deste relatrio e o mapeamento entre os Resultados Esperados do processo GRE do MR-MPS e as Prticas Especficas da rea de Processo REQM do CMMI-DEV, apresentado no Guia de Implementao do MPS.BR (SOFTEX, 2011a).

4.3.1 Modelagem da REQM e do GRE utilizando SPEM


A Figura 6 apresenta a modelagem dos componentes referentes ao Processo GRE do MR-MPS e a rea de Processo REQM do CMMI-DEV no SPEM.

Figura 6 - Estrutura do REQM e GRE no SPEM

A REQM e GRE so consideradas no SPEM uma disciplina classificada na fase (Phase) do Nvel de Maturidade 2 e G. Neste experimento, apresentamos o SG 1 do CMMI-DEV, que determina que os requisitos devem ser gerenciados e as inconsistncias devem ser identificadas em relao aos planos de projeto e produtos de trabalho. No MR-MPS, o componente correspondente Propsito, que no caso da GRE gerenciar os requisitos do produto e dos componentes do produto do pro-

146 jeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. A SP 1.2, que especifica Obter comprometimento dos participantes do projeto com os requisitos equivalente ao GRE 2, que por sua vez determina O comprometimento da equipe tcnica com os requisitos aprovados obtido. Ambos so representados pela notao TaskDefinition no SPEM e so detalhados na Figura 7.

Figura 7 - Representao da SP 1.2 e do GRE 2 no SPEM

De acordo com o CMMI-DEV, um dos artefatos (WorkProductDefinitions no SPEM) que deve ser utilizado nesta atividade : Avaliaes de impacto dos requisitos. J o MR-MPS exemplifica, em seu Guia de Implementao Nvel G, que o artefato Ata de Reunio pode auxiliar o atendimento deste Resultado Esperado. O Guia de Implementao Nvel G do MR-MPS no faz nenhuma referncia a sub-prticas e procedimentos para esta atividade. J o CMMI-DEV especifica as seguintes sub-prticas prticas (Steps no SPEM) para esta atividade: Avaliar o impacto dos requisitos nos acordos existentes; Negociar e registrar acordos. A amplificao referente ao Guia para Desenvolvimento de Produtos e Processos Integrados no CMMI-DEV, que ressalta a importncia de que diferentes equipes, que participam do projeto, tambm devem acordar com os requisitos, considerada um Guidance no SPEM.

4.3.2 Modelagem da REQM e do GRE utilizando BPMN


A Figura 8 apresenta a modelagem dos componentes referentes ao Processo GRE do MR-MPS e a rea de Processo REQM do CMMI-DEV no padro BPMN.

147

Figura 8 - Estrutura do REQM e GRE no BPMN

A REQM e GRE so consideradas no BPMN um Embedded Sub-Process correspondente a um outro Embedded Sub-Process que representa o Nvel de Maturidade 2 e G. Assim, como na Subseo 4.3.1, apresentamos o SG 1 do CMMI-DEV e o Propsito do Processo GRE do MR-MPS, neste caso representados pelo componente Task do BPMN. Tanto a SP 1.2 quanto o GRE 2 so representados pela notao Task no BPMN. Estas atividades, conforme apresentada na subseo 4.3.1, possuem: o artefato Avaliaes de impacto dos requisitos, representado pela notao Data Object; o Procedimento Guia para Desenvolvimento de Produtos e Processos Integrados, representado por um Text Annotation; e a Sub-prtica Avaliar o impacto dos requisitos nos acordos existentes. Estes detalhes so apresentados no modelo da Figura 9, com exceo da Sub-prtica, pois este componente no possui uma notao correspondente em BPMN.

Figura 9 - Representao da SP 1.2 e do GRE 2 no BPMN

Este

experimento

prov

uma

base

para

realizar

anlise

da

representatividade dos padres SPEM e BPMN no contexto da modelagem de processos de software, apresentado na Seo 4.4 deste relatrio. Previamente,

148 possvel constatar que a SP 1.2 e o GRE 2 no so igualmente representados nos dois padres de modelagem, o que nos permitir obter algumas concluses a partir de uma anlise mais detalhada.

4.4

Anlise da Representatividade

Aps apresentar o mapeamento e o experimento, possvel fazer uma anlise da representatividade dos padres SPEM e BPMN. Ao estabelecer o comparativo entre estes dois padres, consideramos o seguinte objetivo especfico: identificar qual destes padres o mais adequado para modelagem de processos de software. Assim, foram identificadas algumas caractersticas desejveis para realizao desta modelagem de processo, usando como base as recomendaes presentes em Prez (2007): Expressividade capacidade de representar a complexidade e todos os ativos dos processos de software, de acordo com os elementos da Ontologia definida em Falbo et al. (2008) e apresentada na Figura 1; Reuso capacidade de promover o reuso dos ativos constantes no modelo de processo; Gesto suporte gesto das instncias do processo (planejamento, monitoramento e controle); Evoluo facilidade de identificar pontos ineficientes do processo, visando melhoria e evoluo dos mesmos; Multinvel capacidade de proporcionar desde vises mais alto nvel do processo at outras com grande quantidade de detalhes; Entendimento capacidade de compreenso do modelo por parte de todos os envolvidos no processo, sejam pessoas da organizao ao qual o processo se destina ou os seus clientes, sobretudo aqueles que no so especialistas em modelagem de processo; Integrao Organizacional possibilidade de se estabelecer integrao e interao com os processos de outras reas da organizao, facilitando o alinhamento da definio dos processos com os objetivos globais da organizao.

149 A fim de analisar o atendimento destas caractersticas por parte dos padres SPEM e BPMN, foram estabelecidos trs critrios, como mostra o Quadro 4.
Quadro 4 Critrios de Atendimento das Caractersticas Avaliadas Notao Significado Descrio As notaes do padro de modelagem incorporam a caracterstica avaliada. As notaes do padro de modelagem incorporam parcialmente a caracterstica avaliada. As notaes do padro de modelagem no incorporam a caracterstica avaliada.

Totalmente Contemplada

Parcialmente Contemplada

No Contemplada

O Quadro 5 mostra a anlise realizada entre o SPEM e BPMN quanto as caractersticas identificadas como desejveis, utilizando-se dos critrios estabelecidos anteriormente e justificando, quando necessrio, a escolha destes.
Quadro 5 - Anlise da Representatividade do SPEM e BPMN Caractersticas SPEM BPMN Justificativa Todos os elementos bsicos apresentados na Ontologia de Processo de Falbo et al. (2008) foram identificados no SPEM. J no BPMN, foram identificados apenas alguns destes elementos. No se aplica. No se aplica. A modelagem realizada atravs dos dois padres, por si s, no suficiente para permitir a evoluo do processo. No se aplica. Pessoas que no so da rea de engenharia de software tendem a possuir dificuldade em entender as notaes do SPEM. A especificidade dos elementos de processo fornecidos pelo SPEM dificulta ou at mesmo impede que se consiga essa integrao organizacional.

Expressividade

Reuso Gesto

Evoluo

Multinvel

Entendimento

Integrao Organizacional

A partir da anlise comparativa realizada, possvel fazer algumas consideraes sobre as caractersticas avaliadas:

150 Expressividade por no ser um padro voltado especificamente para a modelagem de processos de software, o BPMN perde um pouco de expressividade, como foi possvel constatar no experimento, na representao de Sub-prticas especficas para a realizao de atividades, onde no caso do padro SPEM, esta Sub-prtica pode ser modelada atravs do elemento Step (Figura 7). No do padro BPMN, no h uma notao especfica para representar esta Sub-prtica (Figura 9); Reuso ambos os padres permitem a reutilizao das notaes usadas para representar os ativos de processo. No experimento, o elemento Activity do SPEM (Figura 6) foi reutilizado assim como o elemento Task do BPMN (Figura 8); Gesto por ser um padro especfico para modelagem de processos de software, o SPEM define notaes especficas para as instncias do processo, como Discipline e Phase (Figura 6). J no BPMN, o suporte as instncias do processo pode ser feita indiretamente, por meio do elemento Embedded Sub-Process (Figura 8); Evoluo a avaliao e melhoria do processo se dar a partir da execuo do mesmo. Esta execuo pode auxiliar na identificao de pontos falhos do processo, atravs de mtricas fornecidas sobre o seu andamento. Nesse sentido, o padro BPMN possui a linguagem de execuo BPEL4WS (Business Process Execution Language for Web Services). J o SPEM no muito claro em sua especificao quanto ao suporte execuo de processos, no possuindo mecanismos nativos para tal (BENDRAOU et al., 2007); Multinvel ambos os padres possuem notaes adequadas para descrever os processos em alto e baixo nvel de detalhamento. No entanto, o padro SPEM fornece uma maior quantidade de conceitos para expressar esses nveis, como por exemplo, Process e Phase (Quadro 1); Entendimento o BPMN um padro para modelagem de processos de negcio em geral e possui como objetivo fornecer uma notao compreensvel por todos os envolvidos no processo. J o objetivo do SPEM ser um padro referncia para modelagem de processos de software, a partir da utilizao de notaes comuns aos profissionais desta rea;

151 Integrao Organizacional devido ao seu propsito, o padro SPEM foca basicamente a rea de desenvolvimento de software da organizao. J o BPMN, por ser um padro voltado para modelagem de negcios, permite que processos de software modelados a partir de suas notaes possam ser integrados com os demais modelos de processo de negcio de uma organizao, conforme mostrado a partir dos exemplos na Subseo 3.4.1.

152

5.

CONCLUSES

Este relatrio de pesquisa teve como objetivo apresentar a avaliao da representatividade dos padres SPEM e BPMN na modelagem de processos de software que adotam prticas do modelo CMMI-DEV e MR-MPS, fazendo um estudo entre os componentes que constituem cada um destes modelos e as notaes destes padres de modelagem, a partir de suas semnticas e aplicaes. O objetivo dessa anlise comparativa trazer comunidade da engenharia de software informaes teis escolha de um ou outro padro, a partir da anlise do contexto organizacional sob o qual se definir o processo, incluindo culturas, caractersticas dos recursos humanos, relaes entre as diversas reas da empresa. Espera-se que estas informaes, aliadas aos resultados obtidos nessa pesquisa, forneam subsdios para uma organizao desenvolvedora de software optar por qual tecnologia seria mais adequada na definio e modelagem do seu processo de desenvolvimento. Alm disto, nesta pesquisa, realizou-se uma comparao entre os elementos que compem a estrutura do modelo CMMI-DEV e MR-MPS. Ambos modelos, por serem mais voltados a parte estrutural do processo, possuem carncias de representao quanto modelagem de processos com um maior grau de especificao, onde o SPEM possui muitos componentes para representar esse aspecto. Porm, o BPMN, apesar de tender a ser mais facilmente compreendido e objetivar a integrao entre processos organizacionais, no possuem tanta expressividade na representao de processos de softwares aderente a estes modelos, com base na anlise do experimento realizado. Em relao dissertao de mestrado da qual faz parte, os resultados desta pesquisa contriburam para a compreenso da motivao pela qual optou-se, no mbito do Projeto SPIDER (OLIVEIRA et al. 2011), por basear-se no padro SPEM 2.0 na definio da linguagem de modelagem SPIDER_ML (BARROS, 2009).

153 Uma das contribuies desta dissertao consiste na extenso desta linguagem de modelagem SPIDER_ML para que suporte a execuo de processos de maneira flexvel e semi-automatizada (PORTELA et al. 2011). Esta extenso, denominada xSPIDER_ML, define uma estrutura de componentes e um formalismo de execuo, permitindo com que a SPIDER_ML, e consequentemente o padro SPEM 2.0, contemple totalmente a caracterstica de evoluo do processo, atualmente uma das principais carncias deste padro de modelagem (BENDRAOU et al., 2007).

154

REFERNCIAS

ARAUJO, R.; CAPELLI, C.; GOMES, JR, A. G.; PEREIRA, M.; IENDRIKE, H. S.; IELPO, D.; TOVAR, J. A. A Definio de Processos de Software sob o ponto de vista da Gesto de Processos de Negcio. VI Simpsio Internacional de Melhoria de Processos de Software (SIMPROS), 2004, Rio de Janeiro, Brasil. BARROS, R. S. SPIDER_ML: Especificao Tcnica. 2009. Disponvel em <http://www.spider.ufpa.br/projetos/spider_pm/SPIDER_ML%5B1.1%5D.pdf>. Acesso em Nov/2011. BARROS, R. S.; OLIVEIRA, S. R. B. SPIDER_ML: Uma Linguagem de Linguagem de Modelagem de Processos de Software. Escola Regional De Informtica, 2010, Manaus, Brasil. BARROS, R. S.; OLIVEIRA, S. R. B. Spider-PM: Uma Ferramenta de Apoio Modelagem de Processos de Software. Encontro Anual De Computao, 2010, Catalo, Brasil. BENDRAOU, R., et al. Definition of an Executable SPEM 2.0. Procedings of the 14th Asia-Pacific Software Engineering Conference, 2007, IEEE CS Press, pp. 390 397. BIRK, A., PFAHL, D.. A Systems Perspective on Software Process Improvement. In: Proceedings of the 4th International Conference on Product Focused Software Process Improvement, 2002, v. 2559, pp. 4-18. CURTIS, B., et al. Process modeling. Communications of ACM, 1992, pp.7590. FALBO, R. A., et al., Grounding Software Domain Ontologies in the Unified Foundational Ontology (UFO): The Case of the ODE Software Process Ontology. In XI Iberoamerican Workshop on Requirements Engineering and Software Environments, 2008, Recife, Brasil. FILHO, J. B. A. P. Gesto por Processos de Negcio: Uma Adaptao da Metodologia de Rummler-Brache Baseada numa Aplicao Real. Dissertao de Mestrado, Centro de Informtica, Universidade Federal de Pernambuco, 2007, Recife, Brasil. FUGGETA, A. Software process: a roadmap. In Proceedings of the Conference on the Future of Software Engineering, 2000, ICSE. ACM, New York, NY, 25-34.

155 HUMPHREY, W. S. A Discipline for Software Engineering. Addison Wesley, 1995. HUMPHREY, W. S. Managing the Software Process, The SEI Series in Software Engineering, Addison-Wesley, 1989. ISO/IEC International Organization for Standardization/International Electrotechnical Comission. ISO/IEC 15504-2: Information Technology - Process Assessment Part 2 Performing an Assessment. ISO, 2003, Genve, Switzerland. KELLNER, M. I.; HANSEN G. A. Software Process Modeling. Technical Report CMU/SEI-88-TR-009, Carnegie Mellon University, Software Engineering Institute, 1998, Pittsburgh, EUA. LOMCHAMP, J. A Structured Conceptual and Terminological Framework for Software Process Engineering. The Second International Conference on the Software Process: Continuous Software Process Improvement, Berlin, 1993. 41-53. OLIVEIRA, S. R. B. et al. SPIDER: Uma Proposta de Soluo Sistmica de um SUITE de Ferramentas de Software Livre de Apoio Implementao do Modelo MPS.BR, Revista do Programa Brasileiro da Qualidade e Produtividade em Software, 2011. SEPIN, 2 ed, pp. 103-107. OLIVEIRA, S. R. B. Processo de Software: Ambiente e Mecanismos de Execuo. Exame de Qualificao do Doutorado, Centro de Informtica, Universidade Federal de Pernambuco, 2006, Recife, Brasil. OLIVEIRA, S. R. B., VASCONCELOS, A. M. L., MENDES, R. C. Mapping of CMMI Guide Concepts on SPEM Notations from Software Process Definition Context. Infocomp Journal of Computer Science, 2006, vol. 5, pp. 83-92. OMG Object Management Group. Business Process Model and Notation (BPMN). 2011. Disponvel em <http://www.omg.org/spec/BPMN/2.0/PDF>. Acesso em Out/2011. OMG Object Management Group. Unified Modeling Language (UML). 2011. Disponvel em <http://www.omg.org/spec/UML/>. Acesso em Out/2011. OMG Object Management Group. Software & Systems Process Engineering Meta-Model Specification. 2008. Disponvel em <http://www.omg.org/spec/SPEM/2.0/PDF>. Acesso em Out/2011. OMG Object Management Group. OMG Official Website. 1997. Disponvel <http://www.omg.org/>. Acesso em Nov/2011. PAULK, M.C. Surviving the Quagmire of Process Models, Integrated Models, and Standards. Proceedings of the Annual Quality Congress, 2004. PREZ, J. D. Notaciones y lenguajes de procesos: Una visin global. Research Report of the Ph.D. in Computer Engineering, 2007, University of Sevilla, Sevilla, Spain.

156 PORTELA, C. S., VASCONCELOS, A. M. L., OLIVEIRA, S. R. B. Spider-PE: Um Ferramental de Apoio Execuo de Processos aderente a Modelos de Qualidade. Workshop de Teses e Dissertaes de Qualidade de Software, 2011, Curitiba, Brasil. SEI Software Engineering Institute. CMMI for Development. 2010. Disponvel em < http://www.sei.cmu.edu/reports/10tr033>. Acesso em Out/2011. SOFTEX Associao para Promoo da Excelncia do Software Brasileiro. Guia de Implementao Parte 11: 2011. Disponvel em <http://www.softex.br/mpsbr/_guias/guias/MPSBR_Guia_de_Implementa%C3%A7% C3%A3o_Parte_11.pdf>. Acesso em Nov/2011. SOFTEX Associao para Promoo da Excelncia do Software Brasileiro. MPS.BR: Guia Geral 2011. Disponvel em <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>. Acesso em Out/2011. SOMMERVILLE, I. Software Engineering. Addison Wesley, 2010. SPINOLA, M. M., TONINI, A.C.; CARVALHO, M.M. Contribuio dos modelos de qualidade e maturidade na melhoria dos processos de software. EPUSP. Revista Produo, 2008. SUTTON, S. M.; TARR, P. L.; OSTERWEIL, L. J. An Analysis of Process Languages. Technical Report of the Laboratory for Advanced Software Engineering Research, 1995, University of Massachusetts, Amherst, EUA. ZORZN, F.; RIESCO, D. Transformation in QVT of Software Development Process based on SPEM to Workflows. Journal Latin America Transactions, 2008, IEEE, vol. 6, pp. 655-660.

157

APNDICE B ESPECIFICAO TCNICA DA LINGUAGEM DE EXECUO DE PROCESSOS XSPIDER_ML

1.
1.1

INTRODUO
Finalidade

Esse documento tem por finalidade descrever as especificaes tcnicas da linguagem de execuo de processos xSPIDER_ML. Deve ser utilizado como um guia para o entendimento da semntica comportamental utilizada nessa linguagem de execuo bem como para a contextualizao do uso da mesma. Alm disso, apresenta exemplos da aplicao do formalismo da xSPIDER_ML que objetivam demonstrar como a linguagem deve ser utilizada.

1.2

Escopo

O principal foco deste documento o detalhamento de todos os aspectos da linguagem xSPIDER_ML. A xSPIDER_ML (eXecutable SPIDER_ML) uma extenso da linguagem SPIDER_ML criada com o intuito de permitir que processos modelados a partir desta possam ser executados. Para isto, definiu-se um formalismo que adicionou novos componentes e atributos SPIDER_ML, alm de incorpora regras de execuo a esta linguagem. Nesse documento, a linguagem xSPIDER_ML contextualizada, os componentes utilizados por esta so elencados, bem como sua estrutura e regras associadas. Alm disso, esse documento apresenta exemplos da execuo de processos, a fim de ilustrar que tipos de mudanas no estado e no tempo dos elementos podem ocorrer durante esta execuo.

1.3

Definies / Glossrio
BPEL (Business Process Execution Language): uma linguagem executvel para especificar aes de processos de negcios dentro de web services; BPMN (Business Process Modeling Notation): uma notao da metodologia de gerenciamento de processos de negcio, fornecendo uma srie de cones padres para o desenho de processos;

158

CMMI-DEV (Capability Maturity Model Integrated for Development): um modelo de qualidade que tem como propsito fornecer guias para o melhoramento de processos e para o gerenciamento do desenvolvimento de produtos e servios; MR-MPS (Modelo de Referncia para Melhoria do Processo de Software): um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e mdias empresas de desenvolvimento de software no Brasil, compatvel com as principais normas e modelos j estabelecidos internacionalmente; OMG (Object Management Group): uma organizao internacional que aprova padres abertos para aplicaes orientadas a objetos, como a UML e SPEM; PSEE (Process-Centered Software Engineering Environments): um ambiente de engenharia de software orientado a processos contemplando o suporte a descrio e execuo dos processos, auxiliando e controlando atividades envolvidas no ciclo de vida do software; SPEM (Software Process Engineering Metamodel): um padro adotado pela OMG dedicado modelagem de processos de software, que possui como objetivo fornecer s organizaes meios para definir uma estrutura conceitual, proporcionando as noes necessrias para a modelagem; SPIDER_ML: um perfil da SPEM criado com o objetivo de incorporar prticas da indstria de software, permitindo que a modelagem de processos seja realizada a partir de um conjunto mnimo de elementos; SPSM (Software Process Simulator Machine): uma ferramenta de simulao de processo de software baseada na xSPEM e aderente sintaxe da SPIDER_ML; UML (Unified Modeling Language): uma linguagem de modelagem que permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados; xSPEM (eXecutable SPEM): uma extenso da linguagem SPEM 2.0 que permite a especificao de modelos de processos executveis.

1.4

Referncias
[1] BARROS, R. S. SPIDER_ML: Especificao Tcnica. Projeto SPIDER Universidade Federal do Par, 2009. Disponvel em: <http://www.spider.ufpa.br/projetos/spider_pm/SPIDER_ML%5B1.1%5D.pdf>. BARROS, R. S.; OLIVEIRA, S. R. B. SPIDER_ML: Uma Linguagem de Modelagem de Processos de Software. Anais da II Escola Regional de Informtica, Manaus, 2010. BENDRAOU, R. et al. Definition of an Executable SPEM 2.0. In 14th AsiaPacific Software Engineering Conference, Aichi, 2007. pp. 390397.

[2]

[3]

159

[4]

CHAVES, R. et al. A Software Process Simulator Machine for Software Engineering Simulation Games. Brazilian Symposium on Games and Digital Entertainment, Florianpolis, 2010. 49-58. HUFF, K. Software Process Modeling. In Trends in Software: Software Process, FUGGETTA, A. and WOLF, A.: John Wiley and Sons, 1996. HUMPHREY, W. S. Managing the Software Process. The SEI Series in Software Engineering: Addison-Wesley, 1989. HUMPHREY, W. S. A Discipline for Software Engineering. [S.l.]: AddisonWesley, 1995. IBM. RUP for Small Projects. IBM Rational Unified Process, 2006. Disponivel em: <http://www.wthreex.com/rup/smallprojects/index.htm>. OLIVEIRA, S. et al. SPIDER: Uma Proposta de Soluo Sistmica de um SUITE de Ferramentas de Software Livre de Apoio Implementao do Modelo MPS.BR. Revista do Programa Brasileiro da Qualidade e Produtividade em Software, 2011. pp. 103-107.

[5] [6] [7] [8] [9]

[10] OLIVEIRA, S. R. B. Processo de Software: Princpios, Ambientes e Mecanismos de Execuo. Exame de Qualificao - Universidade Federal de Pernambuco. Recife. 2006. [11] OMG. Business Process Model and Notation (BPMN). Object Management Group, 2011. Disponvel em: <http://www.omg.org/spec/BPMN/2.0/PDF>. [12] OMG. Software & Systems Process Engineering Meta-Model Specification. Object Management Group, 2008. Disponivel em: <http://www.omg.org/spec/SPEM/2.0/PDF>. [13] PORTELA, C. S. Anlise Comparativa entre os Padres SPEM e BPMN no Contexto da Modelagem de Processos de Software. Relatrio de Pesquisa/Projeto SPIDER RPS-001, 2011. Disponivel em: <www.spider.ufpa.br/projetos/spider_pe/SPEMxBPMN_RPS-001.pdf>. [14] PORTELA, C.; VASCONCELOS, A.; OLIVEIRA, S. Spider-PE: Um Ferramental de Apoio Execuo de Processos aderente a Modelos de Qualidade. IX Workshop de Teses e Dissertaes de Qualidade de Software, Curitiba, 2011. [15] REIS, C. A. L. Uma Abordagem Flexvel para Execuo de Processos de Software Evolutivos. Tese de Doutorado - Universidade Federal do Rio Grande do Sul. Porto Alegre. 2003. [16] SEI. Capability Maturity Model Integration for Development CMMI-DEV. Verso 1.3. Software Engineering Institute, 2010. Disponvel em: <http://www.sei.cmu.edu/reports/10tr033.pdf>.

160

[17] SOFTEX. MPS.BR: Guia Geral 2011. Associao para Promoo da Excelncia do Software Brasileiro, 2011b. Disponvel em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>.

2.

CONTEXTUALIZAO

A cada dia os sistemas de informao e softwares, de maneira geral, esto se tornando indispensveis na vida das pessoas. Os usurios destes sistemas esto se tornando cada vez mais exigentes no que diz respeito qualidade destes softwares, impactando assim diretamente no seu processo de desenvolvimento [14]. Estes processos esto ficando cada vez mais complexos, devido dificuldade em se atingir o escopo definido, cumprir os prazos estabelecidos, estimar e administrar os recursos alm de atender as expectativas do cliente e usurios do sistema [10]. A Engenharia de software surge nesse contexto buscando atender as demandas desses processos de software alm de ter por objetivo a melhoria da qualidade do software produzido. uma rea do conhecimento da computao voltada para a especificao, desenvolvimento e manuteno de sistemas de software [6]. Neste contexto, surge a rea de Tecnologia de Processos de Software que abrange a construo de ambientes para modelagem, execuo, simulao e evoluo de processos de desenvolvimento de software [15]. O Processo de Software pode ser definido como o conjunto de tarefas necessrias para transformar os requisitos dos usurios em software [6]. Nesta definio devem-se considerar alguns conceitos, como as atividades a serem realizadas; os recursos utilizados; os artefatos consumidos e gerados; os procedimentos, o paradigma e as tecnologias adotadas; e o modelo de ciclo de vida utilizado. Sendo o processo de software o conjunto de etapas necessrias para se desenvolver um software, a definio do processo de software consiste na descrio destas etapas [7], auxiliando na anlise e amadurecimento do processo, podendo este ser descrito em um modelo de processo de software. No Modelo de Processo de Software informaes para indicar quem, quando, onde, como e por que os passos so realizados, devem estar contidas para que o modelo possa ser analisado, compreendido e automatizado (executado) [15]. Na modelagem dos processos de software existem dois tipos de modelos de processos: o Modelo de Processo Padro e o Modelo de Processo Instanciado [1]. No existe processo de software que possa ser aplicado genericamente, pois, na definio de um processo devem ser levados em considerao diversos fatores como a adequao s tecnologias envolvidas na organizao, ao tipo de software que ser produzido, o grau de maturidade (ou capacitao) da equipe em engenharia de software, os paradigmas organizacionais alm da localizao geogrfica da equipe desenvolvedora [5]. Nas organizaes, diversos projetos podem estar sendo desenvolvimento em paralelo, onde cada projeto possui caractersticas especficas para seu desenvolvimento. Entretanto, existem elementos fundamentais que devem ser incorporados em qualquer processo da organizao. Este conjunto de elementos

161

fundamentais definido como Processo Padro [12]. Processos para projetos especficos so definidos a partir da instanciao do processo de software padro da organizao. Na instanciao, os processos so adaptados de acordo com as caractersticas e necessidades particulares de cada projeto de software. A esta instancia do processo padro denominamos de Processo Instanciado [12]. Dentre as pesquisas realizadas no Projeto SPIDER [9], no que diz respeito definio de processos, foi definida uma linguagem de modelagem chamada SPIDER_ML [1]. A SPIDER_ML estabelece um conjunto de elementos que podem ser empregados para a documentao, gerenciamento, anlise, e comunicao de um processo de desenvolvimento de software [2]. Para a modelagem de processos, existem diversas ferramentas e linguagens, no entanto, muitas dessas linguagens so elaboradas a partir de estudos acadmicos que muitas vezes no levam em considerao alguns aspectos dos processos organizacionais do mundo real [15]. Alm disso, algumas dessas linguagens so muito complexas o que dificulta a sua utilizao. A SPIDER_ML, por sua vez, foi desenvolvida de maneira que os processos de software sejam modelados de maneira prtica, de acordo como eles so utilizados dentro das organizaes [2]. No entanto, mesmo com essas caractersticas, a SPIDER_ML capaz de modelar os diversos tipos de processos de software. A SPIDER_ML foi concebida com base na linguagem SPEM [13] e assim sendo, se caracteriza como um perfil da SPEM [12], fazendo uso de alguns de seus componentes considerados importantes para a modelagem de processos padres e instanciados. Depois de instanciadas e modeladas, as atividades do processo podem ser executadas tanto por desenvolvedores (quando demandam agentes humanos) quanto automaticamente (quando demandam a invocao de ferramentas autnomas) [15]. Essas questes fazem parte da fase de Execuo de Processos de Software do ciclo de vida de processos de software. A Execuo de Processos consiste na interpretao do modelo de processo instanciado de acordo com a semntica da linguagem de modelagem, gerenciando as informaes do ambiente e orientando os desenvolvedores de acordo com este modelo [5]. Alguns dos principais objetivos desse mecanismo so: manter o estado da execuo do processo consistente com o estado real da realizao das tarefas e monitorar e coletar mtricas sobre o processo [10]. O mecanismo de execuo quem executa o modelo de processo, atravs da coordenao da realizao das atividades. Entretanto, a execuo desses processos de software no pode ser totalmente automatizada, ficando livre de qualquer interveno humana, pois elas dependem muito da capacidade das pessoas realizarem tarefas criativas [15]. Desta forma, no possvel prever antecipadamente todo o desenvolvimento de software. Alm disto, os processos de software so definidos por organizaes inseridas em ambientes de negcios que, com frequncia, sofrem modificaes. Essas modificaes exigem que as organizaes alterem seus processos de software visando uma adaptao s mudanas sofridas pelos ambientes de negcios [17]. Durante o ciclo de vida do projeto haver diversos tipos de problemas, como processos incompletos, incertezas e no-determinismos, escolhas entre caminhos alternativos durante a execuo, os quais podem depender de resultados de atividades anteriores [15].

162

Dessa forma, necessrio que as organizaes sejam capazes de adaptar e melhorar continuamente os seus processos de software, caso elas desejem produzir softwares com qualidade e de maneira competitiva [17]. Os mecanismos de execuo, por sua vez, devem dar suporte para que essas mudanas ocorram da melhor maneira possvel, devendo ser Flexvel s adversidades que surgirem no decorrer de cada projeto [15]. A SPIDER_ML, assim como a SPEM, no oferece mecanismos nativos para simulao e execuo automatizada do processo de software [2], ou seja, no apresenta um conjunto de conceitos e uma semntica comportamental que permita a sua execuo. Uma abordagem proposta em [3] a fim de estender o padro SPEM 2.0, para que os modelos de processo possam ser executados atravs de um mapeamento de redes de Petri, mantendo a consistncia do padro SPEM. Assim, prope-se a xSPEM (eXecutable SPEM) que define as semnticas comportamentais necessrias para a execuo de modelos de processo SPEM. Porm, nesta abordagem, a execuo realizada com o apoio da linguagem BPEL, o que faz com que haja perda da expressividade do SPEM. Sendo assim, pretende-se definir um formalismo para execuo a fim de permitir que os modelos de processos produzidos de acordo com a linguagem SPIDER_ML possam ser executados, de maneira compatvel com a SPEM 2.0. Este formalismo contemplado pela linguagem xSPIDER_ML, apresentada neste documento, que se caracteriza como uma extenso da SPIDER_ML, adicionando a esta elementos e atributos, alm de regras associadas para viabilizar a execuo flexvel de processos.

3.

VISO GERAL

A xSPIDER_ML utiliza-se de alguns componentes da linguagem de modelagem SPIDER_ML, mais especificamente os componentes que compem a estrutura dos Processos Instanciados. Esses componentes so utilizados para representar aspectos dos processos especficos para a execuo de um projeto [1]. Segue abaixo os componentes utilizados pela linguagem xSPIDER_ML assim como a descrio referente a cada um deles.
cone Nome Processo Instanciado Fase Iterao Marco Descrio Uma instncia do Processo Padro para um projeto especfico. Um perodo significativo de um Processo Instanciado. Um conjunto de atividades e tarefas que sero repetidas dentro de uma fase. Um evento significativo em um Processo Instanciado. Um trabalho que deve ser realizado no decorrer de um Processo Instanciado e que pode ser decomposto em outras atividades ou tarefas.

Atividade

163

cone

Nome Tarefa Instanciada Papel Instanciado Produto de Trabalho Instanciado Ferramenta Instanciada

Descrio Um trabalho que deve ser realizado no decorrer de um Processo Instanciado e que no pode ser decomposto. Um papel desempenhado por um recurso no Processo Instanciado. Um produto de trabalho consumido, gerado ou modificado em um Processo Instanciado. Uma ferramenta que deve ser utilizada durante a realizao de uma tarefa em um Processo Instanciado. Representa uma conduta que deve ser adotada durante a realizao de uma tarefa do Processo Padro ou de um Processo Instanciado. Representa o ponto de partida de um fluxo representado no Processo Instanciado. Representa um ponto para a finalizao de um fluxo descrito no Processo Instanciado. Indica um ponto onde existem dois ou mais caminhos que podem ser seguidos, mas apenas um desses caminhos ser seguido. Tambm indica o ponto onde dois ou mais fluxos alternativos se unem novamente e um nico fluxo. Representa um ponto que inicia a execuo em paralelo de dois ou mais fluxos. Representa um ponto onde dois ou mais fluxos que ocorrem em paralelo so finalizados. Representa uma transio entre duas fases, iteraes, atividades, tarefas e demais elementos de um processo instanciado. Representa uma descrio ou informao adicional que pode ser provida a respeito de um componente.

Procedimento

Estado Inicial Estado Final

Deciso e Unio

Barra de Separao Barra de Juno Transio Nota

4.
4.1

ESPECIFICAO
Definio

Existem basicamente dois padres distintos para a modelagem de processos de software: um tradicional, o SPEM Software Process Engineering Metamodel [12], que utiliza tecnologias desenvolvidas especificamente com esse intuito; e o BPMN Business Process Modeling Notation [11], uma abordagem que trata o processo de software como um processo de negcio. O SPEM possui mais expressividade que o BPMN, na representao de processos de software, por ser uma notao voltada especificamente para este propsito [13].

164

Por este motivo, a SPIDER_ML utiliza a linguagem SPEM como referncia, caracterizandose como um perfil desta. Porm, apesar do SPEM ser o padro da OMG (Object Management Group) para modelagem de processo, so poucas as organizaes que fazem uso desta [10]. A maioria das ferramentas de modelagem de processo, incorporadas a PSEEs (Process-Centered Software Engineering Environments), utilizam linguagem prpria. Recentemente, a OMG publicou uma nova reviso do seu padro para a Modelagem de Processos de Software, denominada SPEM 2.0. No entanto, mesmo a executabilidade sendo definida como um requisito obrigatrio na RFP (Request For Proposal), a especificao adotada no a atendeu [3]. A pesquisa apresentada em [3], prope uma extenso do padro a partir de um conjunto de conceitos e semntica comportamental que permita modelos de processo SPEM 2.0 possam ser executados atravs de um mapeamento de redes de Petri e monitorado atravs de uma transformao em BPEL. No entanto, esta abordagem apresenta alguns pontos fracos, pois nem todoos os elementos do xSPEM que fornecem semntica apropriada para modelagem de processos tem equivalente em BPEL. Alm disto, falta em BPEL mecanismos de interaes com o usurio e suporte para tarefas orientadas-humano. Isto dificulta a utilizao da linguagem xSPEM, pois processos de software so compostos principalmente de tarefas humanas criativas [15]. Neste contexto, dando prosseguimento s pesquisas realizadas no Projeto SPIDER, optou-se por definir a linguagem xSPIDER_ML. A xSPIDER_ML uma extenso da linguagem de modelagem SPIDER_ML que objetiva apoiar a execuo de processos de forma flexvel [14]. Alm disso, a xSPIDER_ML tem por objetivo permitir com que esta execuo seja realizada de forma aderente aos principais modelos de qualidade adotados no mercado brasileiro: MR-MPS [17] e CMMI-DEV [16]. Esta aderncia est relacionada Capacidade dos processos, conforme especificada nestes dois modelos. Entende-se por Capacidade do processo o grau de refinamento e institucionalizao com que o processo/rea de processo executado na organizao/unidade organizacional [16] [17]. O contexto no qual a xSPIDER_ML est inserido relaciona-se com os processos que so executados em um projeto de desenvolvimento de uma organizao. Esses processos so conhecidos como processos instanciados. Entende-se por processo instanciado o conjunto ordenado de atividades e tarefas que so executadas para a construo de um software [1]. Esse conjunto ordenado de atividades estabelecido levando em considerao os recursos disponveis e as caractersticas do software que ser produzido. A fim de apoiar a execuo destes processos, definiu-se um Framework de Apoio Execuo de Processos, do qual a linguagem xSPIDER_ML serve como base. Entende-se por apoio a execuo, a capacidade de monitorar e controlar um processo real de acordo com seu modelo de processo definido. Este framework, denominado Spider-PE (Process Enactment), possui como componentes, alm da xSPIDER_ML, um Mapeamento referente s recomendaes dos modelos CMMI-DEV e MR-MPS no que diz respeito Capacidade de institucionalizar o processo em uma organizao.

165

O objetivo do Framework Spider-PE definir um fluxo conceitual de atividades genricas para que as organizaes desenvolvedoras de software possam executar seus processos de forma flexvel e semi-automatizada de acordo com as recomendaes dos modelos de qualidade CMMI-DEV e MR-MPS. Para tal, importante destacar que as atividades deste framework devem ser customizadas de acordo com o perfil e as caractersticas da organizao que ir adot-lo.

4.2

Estrutura

A fim de agrupar o conjunto de elementos e caractersticas que permitem a adio de uma semntica comportamental linguagem SPIDER_ML, definiu-se uma estrutura em pacotes para a linguagem xSPIDER_ML. O objetivo desses pacotes fornecer, s organizaes, meios para definir uma estrutura conceitual, proporcionando as noes necessrias para execuo de seus processos de desenvolvimento de forma semi-automatizada. Levando em considerao que o objetivo da xSPIDER_ML tornar executvel a linguagem de modelagem SPIDER_ML, que caracteriza-se como um perfil da SPEM, optou-se por basear sua estrutura na proposta da linguagem xSPEM, apresentada em [3], j que esta tem por objetivo tornar a SPEM 2.0 executvel. Sendo assim, a estrutura da xSPIDER_ML, como mostra a Figura 1, foi dividida em cinco pacotes: xSPIDERML_Core, ProcessParameters, ProjectVariables, EventTypes e ProcessTrace. Devido a execuo atuar diretamente sob os processos instanciados, os elementos da SPIDER_ML relacionados a este so reagrupados no pacote xSPIDERML_Core (Seo 4.2.1). Durante a execuo, o processo evoluir de um estado para outro, assim, faz-se necessrio fornecer conceitos para a caracterizao de todos os estados do processo durante o tempo de sua execuo. Este o objetivo do pacote ProcessParameters (Seo 4.2.2). Recursos adicionais se fazem necessrio a fim de adequar o processo de um determinado projeto. Isso implica em definir propriedades especficas para agendamento de atividades e alocao de recursos. Essas propriedades so introduzidas no pacote ProjectVariables (Seo 4.2.3). Definiu-se, tambm, os eventos que provocam mudanas de estado no pacote EventTypes (Seo 4.2.4). Por fim, identificou-se a necessidade de registrar o histrico destes eventos, definindo-se assim o pacote ProcessTrace (Seo 4.2.5).

166

Figura 1 - Estrutura de Pacotes da xSPIDER_ML

4.2.1 xSPIDERML_Core
O pacote xSPIDERML_Core reaproveita conceitos e elementos oferecidos pela SPIDER_ML (classes em amarelo) [1], apresentados na Seo 3 deste documento, e demais elementos da xSPEM (classes em verde) [3] a fim de fornecer todos os elementos necessrios para se definir e estruturar um processo de software para sua posterior execuo, conforme apresenta a Figura 2. Estes elementos definem a base para todos os demais pacotes da xSPIDER_ML. A classe Process (Processo) representa uma atividade especial que descreve uma estrutura para tipos especficos de projetos de desenvolvimento ou partes destes projetos. Para realizar tal projeto de desenvolvimento, um processo deve ser adaptado para a situao especfica da organizao ou do projeto e depois instanciado, atravs da atribuio de recursos humanos para RoleUses (Papis), da criao de vrias instncias para WorkProductUses (Produtos de Trabalho), etc. Processos definem como projetos de desenvolvimento sero executados, sendo caracterizados como sequncias de Phases (Fases) e Milestones (Marcos). Sendo assim, Processos expressam o ciclo de vida de um produto em desenvolvimento.

167

Figura 2 - Classes do Pacote xSPIDERML_Core

168

Processos definem, tambm, como seguir de um Marco para outro atravs da definio de sequncias de trabalho e operaes ou acontecimentos que normalmente ocupam tempo. Processos so representados no SPEM 2.0 como um conjunto de definies de trabalho parcialmente ordenados com a inteno de atingir metas de desenvolvimento, como a entrega de um sistema de software especfico. Um processo centra-se no ciclo de vida e no sequenciamento de trabalho a partir de estruturas analticas. Phase (Fase) uma classe que representa um perodo significativo de tempo para um projeto, onde normalmente ao seu final, ocorrem pontos de controle, marco ou a entrega de um ou mais produtos para o cliente. Ela representada no modelo como uma atividade especial pr-definida, devido a sua importncia na definio de elementos. Tipicamente, a Fase uma Atividade para a qual seu atributo isRepeatable est definido como 'False'. Iteration (Iterao) um conjunto de atividades aninhadas que so repetidas mais de uma vez. Ela representa um elemento de estruturao importante para organizar o trabalho em ciclos repetitivos. O conceito de Iterao pode ser associado com diferentes regras, de acordo com a metodologia adotada. Normalmente, Iterao uma atividade para a qual o valor padro do seu atributo isRepeatable 'True'. Em outras palavras, uma Iterao consiste de um conjunto de atividades e tarefas que deve ser executado repetidamente. Ao final de uma iterao pode ocorrer um marco do projeto. No entanto, uma Iterao pode, tambm, representar um conjunto de Atividades e Tarefas que contribuem para o atendimento de um dos objetivos da Fase onde essa Iterao est inserida. Por exemplo, suponhamos que uma determinada Fase de construo deve produzir trs componentes de software independentes. Poderiam existir trs Iteraes ocorrendo paralelamente onde cada uma delas responsvel pela construo de um desses componentes. Nesse caso, as Iteraes no so constitudas de um conjunto de atividade que so repetidas e sim de um conjunto distinto de atividades e tarefas. Cada um desses conjuntos deve estar configurado de acordo com o componente que o mesmo responsvel. A classe Milestone (Marco) um WorkBreakdownElement que representa um evento significativo para um projeto de desenvolvimento. Normalmente, nesse evento, ocorrem situaes como: tomadas de decises importantes, a finalizao da construo de produtos de trabalho entregveis ou a finalizao de uma importante dependncia para o projeto como uma Fase ou Iterao. Esse componente usado, tambm, para representar o ponto no tempo no qual esse evento ocorre, ou seja, ele representa tanto o evento em si como o momento no qual esse evento ocorre. Uma Activity (Atividade) caracteriza-se tanto como um WorkBreakdownElement quanto como uma WorkDefinition que define unidades bsicas de trabalho dentro de um processo, bem como um processo em si. Em outras palavras, cada atividade representa um processo de acordo com a SPEM 2.0. Relaciona-se com a classe WorkProductUse atravs de instncias da classe Process Parameter e relaciona-se, tambm, com RoleUse atravs de instncias de ProcessPerformerMap (um conjunto de competncias necessrias para executar uma atividade). Dessa forma, esse componente deve fornecer informaes que estejam

169

relacionadas com os recursos que de fato estaro envolvidos durante a execuo da tarefa que o mesmo representa e deve prover, tambm, informaes que indiquem em qual momento do projeto essa tarefa deve ser executada. Esta classe Activity suporta o aninhamento e agrupamento lgico de BreakdownElement relacionados, formando estruturas analticas (breakdown structures). A estrutura analtica concreta define uma atividade (ou seja, seus elementos contidos) que podem ser reutilizados por outra Atividade por meio da associao de Atividade, que permite a segunda Atividade herdar a sua sub-estrutura completa. Desta forma, uma atividade pode ser compreendida como um conjunto formado por outras atividades e por tarefas atmicas, devendo ser estruturada para organizar basicamente a ordem de execuo das tarefas atmicas e agrupar essas tarefas de acordo com um critrio especfico. A classe TaskUse (Tarefa) um WorkBreakdownElement que representa uma instncia para uma TaskDefinition (presente na estrutura da SPEM 2.0) no contexto de uma atividade especfica. Esta classe relaciona-se diretamente com os recursos que de fato estaro envolvidos durante a execuo e deve prover, tambm, informaes que indiquem em qual momento do projeto deve ser executada. Por isto, toda estrutura analtica pode definir diferentes relaes de TaskUses para WorkProductUses e RoleUses. Pode haver diversas representaes de TaskUse dentro do contexto de uma atividade com seu prprio conjunto de relacionamentos. RoleUse (Papel) um BreakdownElement especial que representa tanto um executor de uma atividade quanto um participante da atividade. Caso represente um executor, o RoleUse precisa se relacionar com uma Atividade por meio de um ProcessPerformer (presente na estrutura do SPEM 2.0). Caso represente um participante, ento o RoleUse armazenado na composio nestedBreakdownElement (presente na estrutura do SPEM 2.0) da atividade e pode ser usado por uma das sub-atividades como um executor e/ou um ProcessResponsibilityAssignment (presente na estrutura do SPEM 2.0). RoleUses so vlidos somente dentro do contexto especfico de uma tarefa. Eles no podem ser reutilizados em todas as atividades. Em geral esse Papel atribudo a um recurso humano, representado pela classe HumanResource. ToolUse (Ferramenta) representa uma ferramenta que possui um conjunto de caractersticas especficas e necessrias para a execuo de uma tarefa de um processo instanciado. Essa ferramenta , em geral, definida baseando-se em um componente do tipo ToolDefinition da SPEM 2.0. Ambas as classes HumanResource e ToolUse herdam atributos da classe abstrata Resource, pois representam os recursos necessrios para realizar uma TaskUse. Esta abstrao se faz necessria para, posteriormente, no pacote ProjectVariables, essas classes incorporarem, alm dos atributos de Resource, o conceito de classificao de recursos, que ser melhor detalhado na Subseo 4.2.3. Um WorkProductUse (Produto de Trabalho) um elemento especial que representa tanto um tipo de entrada e/ou sada para uma atividade quanto representa um participante geral da atividade. Se for uma entrada/sada, ento o WorkProductUse deve relaciona-se

170

com a tarefa de uma atividade atravs da classe ProcessParameter. Se for um participante, ento o WorkProductUse armazenado na composio nestedBreakdownElement da atividade e pode ser usado por uma das tarefas como uma entrada/sada e/ou estar relacionada a um RoleUse atravs de um ProcessResponsibilityAssignment. Sendo assim, esta classe representa um produto de trabalho que pode ser consumido, produzido ou modificado por uma tarefa do processo instanciado. Guidance (Procedimento) um elemento descritvel que fornece informaes adicionais relacionadas execuo de uma tarefa. Procedimentos devem ser classificados atravs de Kinds que indicam um tipo especfico de orientao para que talvez uma estrutura especfica e tipo de contedo sejam assumidos. Exemplos de tipos de Guidances so orientaes, modelos, checklists, Estimativas, Materiais de Apoio, Relatrios, etc. Stereotypes (esteretipos) um conceito proveniente da UML para a extenso da semntica dos elementos e relacionamentos disponibilizados por ela. No contexto da SPIDER_ML, ela permite estender os conceitos de RoleUse, WorkProductUse, Guidance, ToolUse, Activity e TaskUse. BreakdownElement uma generalizao abstrata para qualquer tipo de elemento do processo que faz parte de uma estrutura analtica (breakdown structure). Ela define um conjunto de propriedades disponveis para todas as suas especializaes. Qualquer uma de suas subclasses concretas podem ser "colocadas dentro de" uma atividade (por meio da associao nestedBreakdownElement). As atividades so tipos de BreakdownElements e, portanto, podem ser aninhadas dentro de outras atividades, uma estrutura de diviso de n nveis definido pelas n Atividades aninhadas. Alm de Atividades, outros BreakdownElements podem ser aninhados dentro de Atividades como elementos analticos, como por exemplo, TaskUse. Um WorkBreakdownElement um tipo especial de estrutura analtica que fornece propriedades especficas para os BreakdownElement que representam o trabalho. Caracteriza-se como uma classe abstrata. ActivityKinds uma classe abstrata que fornece a capacidade para um engenheiro de processo definir modelos de ciclo de vida usando a terminologia que eles esto acostumados. Por exemplo, se um engenheiro de processo necessita distinguir nveis especficos do elemento para representar um tipo especial de Atividades, ele pode definir vrios tipos de atividades e ocorrncias para atribuir a essas atividades. Fase e Iterao so exemplos comuns de Breakdown Element Kinds. Eles seriam representados em uma estrutura analtica de Atividades com os respectivos tipos atribudos. WorkSequence um Breakdown Element que representa uma relao entre dois Work BreakdownElements em que um WorkBreakdownElement depende do incio ou trmino de outro WorkBreakdownElement, para ser iniciado ou finalizado. WorkSequenceKind define os diferentes tipos de relaes (kinds) para um WorkSequence, de acordo com a SPEM 2.0. Este conceito usado para fornecer valores para o atributo linkKind da classe WorkSequence.

171

A fim de exemplificar o uso desta classe, suponha-se que um WorkSequence represente uma relao entre dois WorkBreakdownElement em que um destes WorkBreakdownElements (referido como o elemento B no exemplo abaixo) dependa do incio ou trmino de um outro WorkBreakdownElement (denominado como o elemento A no exemplo abaixo), a fim de ser iniciado ou finalizado. De acordo com os valores da classe WorkSequenceKind, poder haver quatro tipos de dependncias entre estes elementos: finishToStart: um determinado WorkBreakdownElement (B) no pode iniciar at o
WorkBreakdownElement (A) finalizar. Por exemplo, se existirem dois WorkBreakdownElements, Criar DAO e Testar DAO, Testar DAO no poder ser iniciada at que Criar DAO seja finalizada. Este o tipo mais comum de dependncia, estabelecido como o padro para uma nova instncia de WorkSequence;

finishToFinish: um determinado WorkBreakdownElement (B) no pode finalizar at


o WorkBreakdownElement (A) finalizar. Por exemplo, se existirem dois WorkBreakdownElements, Cadastrar Cliente e Editar Dados do Cliente, Editar Dados do Cliente no pode finalizar at Cadastrar Cliente ser finalizada;

startToStart: um determinado WorkBreakdownElement (B) no pode inicializar at o


WorkBreakdownElement (A) for iniciado. Por exemplo, se existirem dois WorkBreakdownElements, Codificar Requisitos e Coletar Mtricas, Coletar Mtricas no pode iniciar at que Codificar Requisitos inicie;

startToFinish: um determinado WorkBreakdownElement (B) no pode finalizar at o WorkBreakdownElement (A) ser iniciado. Este tipo de dependncia pode ser utilizado para agendamento just-in-time, para um Marco ou para a data de trmino do projeto a fim de minimizar o risco de um WorkBreakdownElement finalizar antes de seus WorkBreakdownElements dependentes. Se um WorkBreakdownElement relacionado precisa finalizar antes da data de concluso de um Marco do projeto, mas no importa exatamente quando, e no existe a necessidade de finalizar, pois isso afetaria o just-intime do WorkBreakdownElement, poderia criar-se uma startToFinish dependency (ver SPEM 2.0) entre o WorkBreakdownElement que necessita ter um just in time (o predecessor) e o WorkBreakdownElement relacionado (o sucessor). Ento, se o progresso no WorkBreakdownElement sucessor for atualizado, isso no afetar as datas previstas do WorkBreakdownElement predecessor. WorkDefinition um classificador abstrato que generaliza todas as definies de trabalho dentro da SPEM 2.0. Essa classe define algumas associaes padres para WorkDefinitionParameter. WorkDefinition pode conter conjuntos de pr e ps-condies que definem restries que precisam ser vlidas perante o trabalho realizado, podendo comear antes ou depois que o trabalho possa ser declarado como finalizado. WorkDefinitionParameter uma generalizao abstrata de elementos do processo que representam parmetro para WorkDefinition. usado para declaraes de entradas e sadas. As meta-classes para os tipos de entrada/sada devem ser definidos por WorkDefinitionParameters de subclasses concretas. ParameterDirectionKind definem instncias para os parmetros de WorkDefinitionParameter para representar uma entrada, sada ou entrada/sada (in, out, inout). J um Pro-

172

cessParameter um WorkDefinitionParameter que usado para definies de processo. Ele define meta-tipos de entrada e sada para WorkProductUses. A classe WorkDefinitionPerformer, presente na SPEM 2.0, um classificador abstrato que representa a relao de trabalho de um executor de tarefas (RoleUse) para um Work Definition. Diferentes especializaes de WorkDefinition apresentam diferentes tipos de executores. Neste contexto, a classe abstrata WorkDefinitionPerformerMap, presente no pacote xSPIDERML_Core, mapeia um conjunto de competncias necessrias (ProcessPerformerMap) para um RoleUse executar um WorkDefinition. Todos estes elementos do pacote xSPIDERML_Core e os relacionamentos entre eles, conforme descritos anteriormente, esto representados no diagrama de classes da Figura 2. Posteriormente, a fim de auxiliar a compreenso em relao aos componentes do pacote xSPIDERML_Core, apresenta-se um diagrama de objetos que instancia as classes deste pacote, na Figura 3. No exemplo deste diagrama, representa-se o perfil de um Processo do RUP (Rational Unified Process) [8] em um determinado momento de sua execuo. Este Processo RUP constitudo de quatro fases: Inception, Elaboration, Construction e Transition. A fase Inception executada em trs interaes, sendo que ao final da terceira iterao ocorre o Marco da Fase. Para a Iteration1 representada a atividade DefineProjectPlans conectada com a tarefa PlanPhasesAndIterations atravs da sequncia WS1 que estabelece o tipo de conexo finishToStart entre estes dois elementos. A tarefa PlanPhasesAndIterations possui como artefato de entrada os documentos DevelopmentProcess e RiskList. A atividade DefineProjectPlans constituda da atividade PlanTheProject, que, por sua vez, possui a tarefa DefineProjectOrganizationAndStaffing, que indica a adoo do procedimento BusinessCaseTemplate para a sua realizao e possui como artefato de entrada o documento BusinessCase. Para a sua efetiva execuo, tanto a tarefa DefineProjectOrganizationAndStaffing quanto a tarefa PlanPhasesAndIterations necessitam de um conjunto de habilidades, definido no objeto SetSkills, incorporado pelo papel ProjectManager que no exemplo exercido pelo recurso humano CarlosPortela. Ambas necessitam, tambm, da adoo da ferramenta OpenProject e geram como artefato de sada o documento SoftwareDevelopmentPlan.

173

Figura 3 - Instncias das Classes do Pacote xSPIDERML_Core

174

4.2.2 ProcessParameters
O pacote ProcessParameters define propriedades que os elementos estruturais bsicos, provenientes do xSPIDERML_Core (classes em amarelo), devem possuir para permitir a execuo de processos de software. Para tal, reaproveita conceitos do WebAPSEE (classes em roxo) [15], xSPEM (classes em verde) [3] e do SPSM (classes em azul) [4], conforme mostra a Figura 4.

Figura 4 - Classes do Pacote ProcessParameters

Estas propriedades podem ser classificadas em universais e existenciais. Da abordagem proposta no WebAPSEE, so adotados os conceitos referentes aos tipos de estados do processo (classes ProcessState e StateType), tipos de tarefa (classe TaskType) e relacionados Flexibilidade na execuo do processo (classe FeedbackConnection) [15]. Da proposta do xSPEM, foram adotados os conceitos de estados relacionados ao tempo de execuo dos elementos do processo (classe TimeState) [3]. Por fim, este pacote adotou elementos da abordagem SPSM (Software Process Simulator Machine) no que diz respeito conexo e especializao da classe Tarefa (classes DependencyConnection, StochasticTask e ContinuousTask) [4]. Esta abordagem [4] implica na simulao da execuo de processos modelados a partir da linguagem SPIDER_ML. As propriedades universais so aquelas que devem ser preenchidas a cada execuo. Por exemplo: toda tarefa deve iniciar e terminar; todas as tarefas pausadas devem ser retomadas; uma vez que uma tarefa for concluda, ela tem que permanecer neste estado.

175

Estes estados esto definidos na classe StateType. Os elementos Atividade, Fase e Iterao compartilham, tambm, desses estados. J o elemento Processo possui seus prprios estados que determinam quais eventos podem ser realizados neste, presentes na classe ProcessState. Os valores destas classes e as regras associadas a estes so detalhados nas Subsees 4.5.1 e 4.5.2. As propriedades existenciais so aquelas que devem ser verdadeiras pelo menos para uma execuo. Por exemplo: cada tarefa deve ser realizada em um tempo igual ou maior ao expectedStartTime e igual ou menor que o expectedEndTime; todo o processo pode terminar quando todas as tarefas estiverem finalizadas entre expectedStartTime e expectedEndTime. As tarefas podem ser classificadas em: contnuas (ContinuousTask) e estocrticas (StochasticTask). Tarefas contnuas so aquelas que possuem tempo de durao (expectedStartTime e expectedEndTime), sendo medido atravs de um valor percentual. J as tarefas estocrticas so aquelas que durante a execuo podem proceder para uma de duas tarefas destinos, dependendo de uma deciso. Alm disto, as atividades podem ser de dois tipos: automtica e manual. A definio de tempo das tarefas so provenientes da classe TimeState que possui os estados: adiantado (tooEarly), em tempo (onTime) e atrasado (tooLate). Esses estados so definidos de acordo com uma noo de tempo e relgio associado a cada tarefa. Os valores destas classes e as regras associadas a estes so detalhados nas Subsees 4.5.1 e 4.5.2. Por fim, a cada tarefa associada uma classe de dependncia (DependencyConnection) para classificar a conexo entre tarefas, que pode ser AND ou OR ou XOR (proveninente do BPMN), e uma conexo de feedback (FeedbackConnection), para permitir que se possa retornar um determinado ponto do processo, a partir da reexecuo de uma tarefa. A necessidade deste conceito para a execuo, bem como a exemplicao do uso deste, apresentado detalhadamente na Figura 5. importante ressaltar que o objetivo inicial da pesquisa relacionada a esta linguagem de execuo analisar o quo granular a complexidade (nvel de complexidade) de se realizar a execuo flexvel de processos modelados a partir da linguagem SPIDER_ML. Sendo assim, nesta verso 1.0 da linguagem xSPIDER_ML no sero adotados os conceitos relacionados s classes FeedbackConnection, TaskType e StochasticTask e ContinuousTask. Os elementos do pacote ProcessParameters e os relacionamentos entre eles so apresentados no diagrama de classes na Figura 4. Posteriormente, na Figura 5, a fim de auxiliar a compreenso em relao aos componentes deste pacote, apresenta-se um diagrama de objetos que instancia as classes deste pacote.

176

Figura 5 - Instncias das Classes do Pacote ProcessParameters

177 Dando prosseguimento ao exemplo apresentado na subseo anterior, temos que o Processo RUP est em execuo (state = enacting) de acordo com o tempo previsto (time = onTime). Para este processo, temos que a Fase Inception foi finalizada como atrasada em relao ao planejamento (state = enacting e time = tooLate). As Fases Construction e Transition ainda no foram iniciadas (state = notStarted). Apresentamos o perfil da Fase Elaboration do Processo RUP, constitudo de trs interaes, sendo que ao final da terceira iterao ocorre o Marco desta Fase, onde somente a primeira iterao (Iteration1) foi iniciada (state = started e time = onTime). Para esta iterao, representada a atividade PrepareEnvironmentForAnIteration, constituda da atividade ManageIteration, ambas representadas no estado execuo e de acordo com o tempo estimado (state = started e time = onTime). Essa ltima atividade constituda das tarefas AcquireStaff, IdentifyAndAssessRisks e InitiateIteration. Suponha-se que a tarefa AcquireStaff tenha sido inicialmente finalizada onTime. Posteriormente, de acordo com a classificao da conexo de dependncia estabelecida entre as tarefas (AND), deve-se executar simultaneamente as tarefas IdentifyAndAssessRisks e InitiateIteration. No exemplo, a tarefa IdentifyAndAssessRisks foi finalizada mais cedo do que o tempo previsto (time = TooEarly). Porm, houve a necessidade de pausar (state = paused) a tarefa InitiateIteration porque esta necessita da alocao de mais recursos humanos para a sua realizao (stateDescription = Is necessary to allocate more staff). A alocao de recursos humanos foi realizada anteriormente na tarefa AcquireStaff. Sendo assim, a fim de remover o impedimento na realizao da tarefa InitiateIteration, utilizou-se uma conexo de feedback (FC1) para retornar a execuo do processo, permitindo assim a reexecutar a tarefa AcquireStaff.

4.2.3 ProjectVariables
O pacote ProjectVariables possibilita adequar um modelo de processo para um determinado projeto. Sendo assim, permite dimensionar as tarefas a serem realizadas e identificar os recursos alocados para o projeto. Para tal, adota os conceitos de classificao e estados de recursos do WebAPSEE (classes em roxo) [15]; carga de trabalho necessria, estimada e real para realizar as tarefas do xSPEM (classe ProcessPerformerMap e os atributos de Resource e TaskUse) [3]; e os atributos de HumanResource foram adicionados pela xSPIDER_ML a fim de permitir uma maior expressividade linguagem, conforme mostra a Figura 6.

178

Figura 6 - Classes do Pacote ProjectVariables

Considera-se o Resource como os recursos necessrios para realizar uma atividade (recursos humanos, software e hardware). Estes podem ser classificados em exclusivo (Exclusive), compartilhado (Shareable) e consumvel (Consumable). Os recursos exclusivos so aqueles que no podem ser alocados para vrias tarefas simultaneamente, como uma sala, por exemplo. J os compartilhados podem ser utilizados por vrias tarefas simultaneamente, como uma impressora, por exemplo. E os recursos consumveis so aqueles que aps utilizado em uma atividade no podero mais ser utilizados por outra, como por exemplo, dinheiro. Sendo assim, faz-se necessrio saber o estado de um recurso durante um determinado momento da execuo: usado, no usado e finalizado (used, notUsed e finished em ResourceState). Os valores da classe ResourceState e as regras associadas a estes so detalhados na Subseo 4.5.3. Redefine-se os conceitos de TaskUse, acrescentando a este o intervalo de tempo estimado durante o qual uma tarefa deve ser realizada (expectedStartTime e expectedEndTime) e o tempo real em que esta tarefa foi realizada (realStartTime e realEndTime) para que comparaes possam ser feitas; o nmero de ocorrncias (occurenceNb em Resource) e as habilidades, capacidades e responsabilidades (abilities, capabilities e responsibilities em HumanResource) que um recurso humano deve possuir e exercer para executar uma tarefa, alm da carga de trabalho (charge em ProcessPerformerMap) necessria para tal. Posteriormente, a fim de auxiliar a compreenso em relao aos componentes deste pacote, apresenta-se um diagrama de objetos, na Figura 7, que instancia as classes destes pacotes. Dando prosseguimento ao exemplo apresentado na

179 Subseo 4.2.1, temos a tarefa PlanPhasesAndIterations provenientes do Processo RUP.

Figura 7 - Instncias das Classes do Pacote ProjectVariables

Para esta tarefa, foi previsto que sua execuo iniciaria s 08:00 do dia 12/11/2011 e finalizaria s 18:00 do mesmo dia. Porm, sua execuo foi iniciada s 09:15 do dia 11/11/2011 e finalizou s 11:45 do dia 12/11/2011. Alm do tempo estimado e realizado, este exemplo indica que esta tarefa necessita de trs recursos para sua execuo. Uma impressora (Printer) que compartilhada entre as tarefas do processo. No exemplo, esta impressora est alocada para uso em duas tarefas (occurenceNb = 2) e no est sendo utilizada pela tarefa PlanPhasesAndIterations (state = notUsed). Esta tarefa utilizou (state = finished), tambm, uma resma de papel (PaperStack, occurenceNb = 1). Por fim, necessita de um recurso exclusivo, o Gerente de Projeto (ProjectManager), cuja carga horria alocada ser de 8 horas (SetSkills, charge = 8 hours). Este recurso humano deve possuir um conjunto de habilidades, capacidades e responsabilidades (abilities, capabilities e responsibilities) que permitam que este realize de maneira adequada esta tarefa.

4.2.4 EventTypes
O pacote EventTypes descreve os estados e transies que permitem a evoluo da execuo do processo. Estas aes so desencadeadas por eventos. Estes eventos foram baseados nas abordagens apresentadas no xSPEM (classes em verde) [3] e WebAPSEE (classes em roxo) [15], conforme mostra a Figura 8.

180

Figura 8 - Classes do Pacote EventTypes

Os eventos previstos neste pacote so: StartTask, PauseTask, ResumeTask, CancelTask, FailTask e FinishTask. Eles so modelados como especializaes de TaskEvent, um evento abstrato que envolve uma tarefa-alvo. A transio de estados, provenientes destes eventos, e as regras associados a estes so apresentados nas Subsees 4.5.1 e 4.5.2. A fim de auxiliar a compreenso em relao aos componentes deste pacote, o diagrama de objetos da Figura 9 instancia as classes destes pacotes. Dando prosseguimento ao exemplo apresentado na Subseo 4.2.2, temos a tarefa AcquireStaff provenientes do Processo RUP.

Figura 9 - Instncias das Classes do Pacote EventTypes

Esta tarefa, assim como toda tarefa (Subseo 4.5.1), possui como estado inicial notStarted (Figura 9.A). Aps ocorrer o evento StartTask (Figura 9.B), associado a esta tarefa, AcquireStaff muda do estado notStarted para started (Figura 9.C).

181 importante ressaltar que nesta verso 1.0 da xSPIDER_ML no sero adotados os tipos de eventos CancelTask e FailTask, de acordo com o objetivo inicial desta linguagem, citado na Seo 4.2.

4.2.5 ProcessTrace
O pacote ProcessTrace registra os eventos ocorridos nas tarefas durante a execuo do processo que desencadeiam transies entre estados. Este pacote foi baseado basicamente na proposta do xSPEM (classes em verde) [3], conforme mostra a Figura 10, devido o atendimento da necessidade de gravar o log de eventos ocorridos durante a execuo do processo. Estes eventos podem ser exgenos (ExogenousEvent produzidos por meio do processo), como por exemplo, a mudana do status de uma tarefa de onTime para tooLate devido o clock interno desta ser superior a carga de trabalho prevista; ou endgenos (EndogenousEvent produzidos no processo), como por exemplo, a transio entre os estados not_started e started corresponde ao evento startTask aplicado na tarefa correspondente. Esses eventos podem ser gravados por meio doTrace, que possibilita o acompanhamento dos estados dos processos.

Figura 10 - Classes do Pacote ProcessTrace

A Figura 10 apresenta as classes deste pacote e os relacionamentos entre elas. E a Figura 11 apresenta um diagrama de objetos, a fim de auxiliar a compreenso em relao aos componentes deste pacote.

Figura 11 - Instncias das Classes do Pacote ProcessTrace

182 No exemplo, apresentam-se dois exemplos de eventos: ChangeOfTaskState e ChangeOfTimeState. O evento ChangeOfTaskState endgeno e registrado no Trace T1. J o evento ChangeOfTimeState exgeno e registrado no Trace T2.

4.3

Hierarquia do Processo

A execuo de processo atua sob os processos instanciados, representados pela notao , que identifica os mesmos, distinguindo-os do processo padro. Em um processo instanciado, todo o fluxo de execuo de trabalho deve estar bem definido. Dessa forma, todas as fases, iteraes, marcos, atividades e tarefas que compem o processo instanciado devem estar organizados de maneira que seja possvel identificar o momento no qual cada um deles ser executado. Na abordagem utilizada pela SPIDER_ML, um processo instanciado sempre decomposto em um conjunto sequencial de fase. Isso ocorre devido ao fato das fases representarem perodos de tempo dentro do processo padro, dessa forma, no possvel que em um mesmo processo instanciado sejam executadas duas fases simultaneamente. Basicamente, um processo consiste de um conjunto ordenado de componentes do tipo Fase . Os componentes do tipo Fase devem ser dispostos de maneira que no seja possvel que um processo instanciado execute duas Fases simultaneamente. Sendo assim, um componente do tipo Fase pode ser descrito a partir de duas abordagens distintas: ciclo de vida sequencial, onde deve ser decomposta atravs dos componentes do tipo Atividade e Tarefa Instanciada; e ciclo de vida iterativo, onde deve ser decomposta atravs dos componentes do tipo Iterao e Marco . No ciclo de vida iterativo, os Marcos podem ocorrer ao final de cada uma das interaes. Marcos so as etapas entre as Iteraes de cada Fase, onde so feitas revises no projeto. J as Iteraes podem ser compostas por Atividades e Tarefas Instanciadas . Atividade o componente usado para descrever: uma Fase com ciclo de vida sequencial; um componente do tipo Iterao; e outros componentes do tipo Atividade. J a Tarefa usada basicamente para descrever os componentes do tipo Atividade e Fase, no caso do ciclo de vida sequencial. Estas Tarefas so o principal componente para execuo de processo. Elas correspondem ao que de fato ser realizado (executado) no decorrer do projeto. Em cada tarefa necessrio definir alguns elementos para que esta possa ser realizada. Estes elementos so: Papel Instanciado , que representa o recurso responsvel pela execuo desta tarefa; a Ferramenta Instanciada , que ser o instrumento necessrio para que a realizao da tarefa; os Procedimentos , que so condutas que devem ser adotadas durante a realizao de uma tarefa; e os Produto de Trabalho Instanciado , que so artefatos que podem ser tanto o insumo necessrio para a execuo de uma tarefa (artefato de entrada) quanto o resultado da execuo desta tarefa (artefato de sada).

183 A Figura 12 apresenta a relao hierrquica entre os componentes do processo descritos anteriormente.

Figura 12 - Hierarquia dos Elementos do Processo

4.4

Extenso dos Componentes

Esta subseo apresenta as adaptaes que foram necessrias aplicar a alguns componentes da SPIDER_ML para que estes apoiassem a execuo de processos. importante ressaltar que, para a modelagem de processo, esses detalhes no so relevantes, e sim, somente para a execuo. Sendo assim, para o elemento Barra de Bifurcao foram adicionados operadores lgicos: AND, OR e XOR. Estas relaes de dependncia foram baseadas nas dependncias do BPMN (gateway). Na Figura 13, o operador lgico AND determina que as duas tarefas T2 e T3 devem ser executadas simultaneamentes a partir do trmino da atividade T1, devido dependncia da relao (finishToStart).

Figura 13 - Conexo AND

Na Figura 14, o operador lgico OR determina que somente uma das atividades, T2 ou T3, deve ser executada para satisfazer o fluxo de execuo definido pela

184 Barra de Bifurcao. O mesmo ocorreria para o operador lgico XOR, porm somente uma das atividades deveria ser executada aps o trmino da atividade T1.

Figura 14 - Conexo OR

4.5

Regras do Formalismo

As Regras aplicadas ao Formalismo da xSPIDER_ML basicamente dizem respeito Transio de Estados e Tempo dos Elementos que compem o Processo, caracterizando a semntica comportamental desta linguagem. Para apresentar essas regras, ser utilizada especificao formal. A seguir, so apresentadas as regras referentes s Tarefas e demais elementos do Processo (Atividade, Iterao, Fase e Processo), alm das regras aplicadas aos componentes Recursos. Os estados adotados pela linguagem xSPIDER_ML so provenientes da abordagem WebAPSEE [15], devido as referncias utilizadas por esta e a sua abrangncia. Os estados e possveis transies entre eles, desta abordagem, so representados na Figura 15.

Figura 15 - Diagrama de Transio de Estados (Adaptado de [15])

Porm, devido o objetivo desta verso 1.0 da linguagem xSPIDER_ML, citado na Seo 4.2 deste documento, somente alguns destes estados sero instanciados, inicialmente. Estes estados so notStarted, started, paused e finished baseados, respectivamente, nos estados Pronto, Em Execuo, Em Pausa e Concluda, apresentados na Figura 15. Sendo assim, para o elemento Tarefa, tm-se as seguintes possibilidades de mudanas de estado, de acordo com o evento realizado sobre estas, representadas no diagrama de transio de estado apresentado na Figura 16.

185

Figura 16 - Transio de Estados do Elemento Tarefa

Em relao ao status da Tarefa, tm-se as seguintes possibilidades de mudanas, de acordo com o conceito de tempo associado (Estimado e Realizado) a estas Tarefas, representadas no diagrama de transio de status da Figura 17.

Figura 17 - Transio de Tempos do Elemento Tarefa

A fim de representar as transies entre estados e tempos das Tarefas de maneira adequada, adotou-se a especificao formal utilizada em [3]. Esta especificao indica um passo-a-passo para representar a aplicao de regras de execuo. Sendo assim, temos: Passo 1 Primeiramente, descreve-se o cenrio inicial da execuo, representado pelas seguintes notaes: ws representa a instanciao da classe WorkSequence (constante no pacote xSPIDERML_Core), indicando a relao entre elementos do processo (base e predecessor); predecessor representa um atributo da classe WorkSequence que indica qual elemento precede a execuo do elemento base;

linkType representa um atributo da classe WorkSequence que indica o tipo de relao entre os elementos relacionados (estes tipos esto presentes na classe WorkSequenceKind do pacote xSPIDERML_Core); linkToPredecessor.state representa um atributo da classe WorkSequence que indica o possvel estado da conexo entre os elementos relacionados (estes estados esto presentes nas classes StateType e ProcessState do pacote ProcessParameters). Passo 2 Aps a definio do cenrio inicial, apresenta-se o elemento, o qual ser a base para apresentar as regras de execuo, a partir da seguinte estrutura: wbe.state, wbe.time, wbe.clock. Onde:

186 wbe representa uma instancia da classe WorkBreakdownElement (pacote xSPIDERML_Core) que indica o tipo de elemento (Tarefa, Atividade, Iterao, Fase e Processo); state representa um atributo de um WorkBreakdownElement que representa o estado deste (constante nas classes StateType e ProcessState do pacote ProcessParameters);

time representa um atributo de um WorkBreakdownElement que representa o status do tempo de execuo deste (constante na classe TimeState do pacote ProcessParameters); clock representa o clock interno associado ao conceito de tempo de execuo de um determinado WorkBreakdownElement. Passo 3 Por fim, indica-se qual evento atuar sob o elemento base. As setas indicam a realizao deste determinado evento (de acordo com os tipos de eventos definidos no pacote EventTypes), que implicar na mudana dos atributos do elemento base e consequentemente do cenrio descrito no Passo 1. A especificao formal descrita acima, relacionada transio de estados dos elementos do processo, apresentada na Figura 18.

Figura 18 - Representao do Formalismo de Regras (Transio de Estados)

No caso das regras associadas s mudanas de status dos elementos em funo do seu tempo de execuo, tm-se os seguintes conceitos associados: clockant, charge, comparation, CheckClockTask e CheckClock. Onde: clockant representa o clock interno de um elemento a partir da somatria dos clocks
internos dos elementos hierarquicamente inferiores relacionados a este. Ex.: O clockant de uma Atividade dado pela somatria do clock interno das tarefas que constituem esta Atividade. Este atributo no se aplica ao elemento Tarefa (que utiliza o conceito de clock);

charge representa a carga de trabalho necessria para executar um determinado elemento do processo, representado pela relao diferena entre o tempo estimado de incio e trmino de execuo (expectedEndTime - expectedStartTime) de uma tarefa (classe TaskUse do pacote ProjectVariables). No caso dos elementos do processo hierarquicamente superior tarefa, esta carga ser obtida a partir da somatria das cargas estabelecidas para os elementos hierarquicamente inferiores que estejam relacionados a estes; comparation representa um operador matemtico para comparao de valores. Os
possveis valores adotados so igual (=), maior que (>) e menor que (<);

CheckClockTask representa um agente inteligente que compara constantemente o clock interno de uma Tarefa em relao ao tempo estimado (expectedEndTime - expectedStartTime) para execuo desta, a fim de verificao a necessidade de alterar o seu status de tempo; CheckClock representa um agente inteligente que compara constantemente o clock interno dos demais elementos do processo (Atividade, Iterao, Fase e Processo) em relao ao tempo estimado (expectedEndTime - expectedStartTime) para execuo destes, a fim de verificao a necessidade de alterar o seu status de tempo.

187 Neste contexto, no necessria a realizao do Passo 1 e para o Passo 2 deve-se adotar a seguinte estrutura: wbe.time, wbe.charge <comparation>, wbe.clock. A especificao formal da situao descrita anteriormente, relacionada transio de status de tempo dos elementos do processo, apresentada na Figura 19, onde situao A se aplica s Tarefas e a B aos demais elementos do processo.

Figura 19 - Representao do Formalismo de Regras (Transio de Tempos)

Nas subsees a seguir, so apresentadas as regras relacionadas s Tarefas e demais elementos do Processo, bem como as regras relacionadas ao elemento Recurso.

4.5.1 Tarefas
Considera-se t como a tarefa a ser executada. Sendo assim, para uma tarefa base com o estado inicial notStarted as relaes de transies de estados so:

Vinculado a cada tarefa, tem-se o conceito de clock interno para verificar o status do tempo de execuo desta tarefa. Sendo assim, para uma tarefa t com estado inicial started e status onTime tem-se as seguintes possibilidades:

Para uma tarefa com o estado inicial started e status onTime temos a seguinte relao de transio de estado, a partir do estado da tarefa predecessora:

188

As mudanas de status de tempo de uma tarefa so disparadas a partir de um verificador que compara o clock interno de uma atividade (tempo real) com o seu tempo de realizao estimado (expectedEndTime - expectedStartTime). Para uma tarefa com estado inicial started e status onTime, temos as seguintes mudanas de status em funo do clock da tarefa:

4.5.2 Atividade, Iterao, Fase e Processo


Para os demais elementos do processo (Atividade, Iterao, Fase e Processo), as mudanas de status so disparadas, tambm, a partir de um verificador que compara a soma dos clocks internos dos sub-elementos que o compem com a soma dos tempos de realizao estimado destes sub-elementos (expectedEndTime expectedStartTime).

189 Em relao mudana de status destes componentes, as transies ocorrero de acordo com a hierarquia do processo. Sendo assim: Quando todas as tarefas do processo possurem o mesmo estado, os demais componentes do processo possuiro, tambm, este mesmo estado; Quando pelo menos uma Tarefa estiver sido iniciada (estado = started), os demais componentes do processo hierarquicamente relacionados a esta Tarefa possuiro, tambm, estado igual started; Quando pelo menos uma Tarefa estiver sido pausada (estado = paused), e as demais tarefas do mesmo nvel hierrquico desta estiverem pausadas ou finalizadas, os demais componentes do processo hierarquicamente relacionados a esta Tarefa possuiro estado igual paused; Caso uma Tarefa do processo tenha estado igual a finalizado e todas as demais estiverem no iniciadas, os demais componentes do processo hierarquicamente relacionados a esta Tarefa possuiro estado igual started (para o elemento Processo, o estado correspondente enacting). Estas mudanas sero melhor apresentadas na Seo 5 deste documento, atravs de exemplos.

4.5.3 Recursos
As regras associadas s transies de estados dos recursos so adaptadas de [15]. Sendo assim, para os recursos classificados como Exclusive e Shareable, na Figura 20, temos o seguinte diagrama de transio de estado:

Figura 20 - Diagrama de Transio de Estados de Recursos Exclusive e Shareable

Para os recursos classificados como Consumable, na Figura 21, temos o seguinte diagrama de transio de estado:

Figura 21 - Diagrama de Transio de Estados de Recursos Consumable

190

5.
5.1

EXEMPLOS DE APLICAO DA TECNOLOGIA


Transies de Estado de uma Tarefa

Nestes exemplos sero mostradas as possveis transies de estado de uma tarefa com estado inicial notStarted . Para tal, em nvel de exemplo, convencionou-se que o estado started ser representado pelo cone , o paused pelo cone e o finished pelo cone . Sendo assim, as seguintes mudanas de estado poderiam ocorrer com esta tarefa:
Transio de uma Tarefa No Iniciada (notStarted) para o estado Em Execuo (started); Transio de uma Tarefa Em Execuo (started) para o estado Pausado (paused); Transio de uma Tarefa Pausada (paused) para o estado Em Execuo (started); Transio de uma Tarefa Em Execuo (started) para o estado Concludo (finished);

5.2

Transies de Estado do Processo

Quando todas as Tarefas do processo possurem o mesmo estado (notStarted, started, paused ou finished), os demais componentes do processo, tambm, possuiro este determinado estado, como mostra o exemplo abaixo:

Quando pelo menos uma Tarefa estiver Em Execuo (started), os demais componentes do processo hierarquicamente relacionados a esta Tarefa devero possuir, tambm, estado igual started:

191

Quando pelo menos uma Tarefa estiver sido Pausada (paused), e as demais tarefas do mesmo nvel hierrquico desta no estiverem iniciadas (notStarted) ou estiverem finalizadas (finished), os demais componentes do processo hierarquicamente relacionados a esta Tarefa possuiro estado igual paused:

Caso uma Tarefa do processo tenha estado igual a concludo (finished) e todas as demais no estiverem iniciadas (started), os demais componentes do processo hierarquicamente relacionados a esta Tarefa possuiro estado igual started (exceto para o elemento Processo, onde o estado correspondente ser enacting):

192

5.3

Transies de Tempo de uma Tarefa

Neste exemplo sero mostradas as mudanas de tempo que podem ocorrer em uma Tarefa durante a execuo do processo. Suponhamos que o tempo estimado para realizar uma Tarefa tenha sido de 8 horas. Neste caso, existem trs possibilidades de mudana de status: Caso a Tarefa tenha sido concluda de acordo com o tempo estimado (8 horas), o status da Tarefa ser onTime; Caso a Tarefa tenha sido concluda em um tempo menor que o estimado (6 horas, por exemplo), o status da Tarefa ser tooEarly; Por fim, caso a Tarefa tenha sido concluda em um tempo maior que o estimado (12 horas, por exemplo), o status da Tarefa ser tooLate; O exemplo abaixo mostra essas possibilidades de mudanas de status:

5.4

Transies de Tempo do Processo

Para exemplificar as mudanas de status nos demais elementos do processo (Atividade, Iterao, Fase e Processo), considere a situao descrita a seguir. Suponha que um Projeto P foi estimado para ser realizado em 15 horas e que cada Fase do projeto (F1 e F2) foi estimada para ser realizada em 12 e 3 horas, respectivamente. Dentro da Fase F1, foi planejado que haveriam duas Iteraes (I1 e I2) que seriam realizadas em 9 e 3 horas, respectivamente. A Iterao I1 constituda de duas Atividades (A1 e A2), estimadas para serem realizadas em 7 e 2 horas cada. A Atividade A1 dividida em duas Tarefas (T1 e T2), para serem executadas em um tempo estimado de 3 e 4 horas, respectivamente. J a Atividade A2, estimada em 2 horas, possui apenas uma Tarefa (T3), estimada no mesmo perodo de tempo (2 horas). A Iterao I2 constituda de uma Atividade (A3) e uma Tarefa (T4) que, de acordo com o planejamento, seriam realizadas no mesmo tempo estimado da Iterao (3 horas). O exemplo abaixo representa a situao descrita:

193

Uma vez que o esforo necessrio para realizar as atividades do processo tenha sido estimado e todo o planejamento realizado, o processo pode ento ser executado. Suponha que, neste exemplo, durante a execuo no foram finalizadas as Fases F1 e F2. Suponha, tambm, que a Iterao I2, a Atividade A3 e a Tarefa T4 no foram finalizadas. Consequentemente, o Processo ainda no foi concludo (encontra-se Em Execuo). Entretanto, suponha que j foram realizadas as Tarefas T1, T2 e T3 no tempo de 4, 2 e 3 horas, respectivamente, e que as Atividades A1 e A2 foram realizadas em 6 e 3 horas, respectivamente. Tambm, suponha que a Iterao I1 foi realizada em 9 horas. O exemplo abaixo representa a situao descrita anteriormente:

194 Ao final de cada execuo, dado aos elementos do processo um status, referente relao do tempo em que a sua execuo foi realizada com o tempo estimado para sua execuo. Alguns elementos que so executados com atraso (A2, T1 e T3) recebem o status de tooLate; outros que so terminados adiantados em relao ao tempo estimado (A1 e T2) recebem o status de tooEarly; e um elemento finalizado no tempo estimado (I1) recebe o status de onTime. importante ressaltar que o atraso na execuo de um elemento hierarquicamente inferior no infere necessariamente que o elemento hierarquicamente superior a este ter a sua execuo atrasada. Um exemplo desta situao a Tarefa T1, que apesar de ter sido concluda com atraso, no atrasou a realizao da Atividade A1. Isso ocorreu devido a Tarefa T2 ter sido finalizada antes do prazo estimado. Alm disto, a Iterao I1 foi concluda no prazo estimado, apesar de seus elementos hierarquicamente inferiores no terem sido terminados no prazo estimado.

195

APNDICE C DEFINIO DO FRAMEWORK DE EXECUO DE PROCESSOS SPIDER-PE

1.

INTRODUO

1.1 Finalidade
Este documento define um framework de execuo de processos de software, denominado Spider-PE (Process Enactment), alinhado aos nveis de capacidade do MR-MPS [5] e CMMI-DEV [3]. Este conceito de framework retrata a customizao de um processo para seguir as recomendaes dos modelos de qualidade, a partir de um fluxo de atividades genricas necessrias para a execuo de qualquer processo de software [2]. O uso de tal framework permitir verificar, de maneira mensurvel, o grau de institucionalizao com que o processo deve ser executado na organizao e a capacidade necessria para que um processo possa atingir seus objetivos.

1.2

Escopo
O framework descrito neste documento baseia-se nos modelos de qualidade MR-MPS [5] e CMMI-DEV [3] e na linguagem de execuo xSPIDER_ML [1], aderente ao SPEM 2.0. Este framework define um fluxo de atividades necessrias para realizar a execuo de processos em conformidade com os nveis de capacidade destes modelos de qualidade e com o formalismo da linguagem xSPIDER_ML.

196 Sendo assim, este documento apresenta o mapeamento entre os modelos MR-MPS e CMMI-DEV, a definio das fases e atividades do framework e a anlise da aderncia deste framework ao mapeamento realizado.

1.3

Termos e Definies
AP (Atributo de Processo): Uma caracterstica mensurvel da capacidade do processo aplicvel a qualquer processo do MR-MPS; Capacidade do Processo: Uma caracterizao do grau de refinamento e institucionalizao com que o processo ou rea de processo executada na organizao/unidade organizacional; CMMI-DEV (CMMI for Development): Modelo do CMMI voltado ao processo de desenvolvimento de produtos e servios; Execuo de Processos (Process Enactment): Consiste na interpretao do modelo de processo instanciado de acordo com a semntica da linguagem de modelagem, gerenciando as informaes do ambiente e orientando os desenvolvedores de acordo com este modelo; MPS.BR (Melhoria do Processo de Software Brasileiro): Adapta os modelos e normas internacionais de melhoria do processo de software j existentes para a realidade das empresas brasileiras; MR-MPS: Modelo de referncia do MPS.BR para melhoria do processo de software; Nvel de Capacidade (Capability Level): Alcance de um determinado patamar de melhoria caracterizado pela satisfao de um conjunto de prticas genricas e especficas em uma determinada rea de processo do CMMI-DEV; Objetivo Genrico (Generic Goal): Componente requerido do modelo CMMI-DEV que descreve as caractersticas necessrias para institucionalizar os processos que implementam uma rea de processo; Prtica Genrica (Generic Practice): Componente esperado do modelo CMMI-DEV que descrevem as atividades esperadas para se satisfazer aos objetivos genricos associados. Estas prticas contribuem para a institucionalizao dos processos associados rea de processo; RAP (Resultado de Atributo de Processo): Resultados que devem ser satisfeitos para alcanar cada atributo de processo associado a estes resultados no modelo MR-MPS.

197

1.4

Referncias
[1] PORTELA, C. S.; GOMES, M. J. xSPIDER_ML: Especificao Tcnica. Projeto SPIDER - Universidade Federal do Par, 2011. Disponivel em: <http://www.spider.ufpa.br/projetos/spider_pe/xSPIDER_ML_Especificacao_Tecnica.pdf>. [2] PORTELA, C.; VASCONCELOS, A.; OLIVEIRA, S. Spider-PE: Um Ferramental de Apoio Execuo de Processos aderente a Modelos de Qualidade. IX Workshop de Teses e Dissertaes de Qualidade de Software, Curitiba, 2011. [3] SEI. Capability Maturity Model Integration for Development CMMI-DEV. Verso 1.3. Software Engineering Institute, 2010. Disponivel em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. [4] SOFTEX. Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS:2009 em Conjunto com o CMMI-DEV v1.2. Associao para Promoo da Excelncia do Software Brasileiro, 2011. Disponivel em: <http://www.softex.br/mpsbr/_guias/guias/MPSBR_Guia_de_Implementa%C3%A7%C3%A3o_Parte_11.pdf>. [5] SOFTEX. MPS.BR: Guia Geral 2011. Associao para Promoo da Excelncia do Software Brasileiro, 2011. Disponivel em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>.

2.

MAPEAMENTO ENTRE OS MODELOS MR-MPS E CMMI-DEV


O mapeamento apresentado pretende analisar a equivalncia entre os componentes de dois modelos de qualidade de software: o MR-MPS e o CMMI-DEV. O MPS.BR um programa que possui como objetivo a melhoria de processo de software brasileiro, de forma compatvel com os principais padres de qualidade internacionais para definio, avaliao e melhoria de processos de software. Um dos componentes do MPS.BR o Modelo de Referncia (MR-MPS), que define nveis de maturidade, estabelecendo

198 patamares de evoluo de processos [5]. Desta forma, o MR-MPS define uma escala de sete (7) nveis de maturidade a fim de possibilitar uma implementao e avaliao de maneira gradual, permitindo uma visibilidade dos resultados de melhoria de processos em prazos mais curtos. O CMMI (Capability Maturity Model Integration) um modelo de maturidade para melhoria do processo de software, desenvolvido pelo SEI (Software Engineering Institute) que possui uma verso especfica para desenvolvimento, denominada CMMI-DEV [3]. Por sua vez, o CMMI-DEV permite diferentes abordagens para a melhoria do processo de desenvolvimento, a partir de duas formas de representaes contnua e por estgios. A representao contnua permite que a organizao escolha uma determinada rea de processo e melhore os processos relacionados a ela, atravs de nveis de capacidade. J a representao por estgios utiliza conjuntos predefinidos de reas de processo para definir um caminho de melhoria para a organizao, atravs de nveis de maturidade.

2.1

Objetivo do Mapeamento
Este mapeamento objetiva analisar a equivalncia entre os nveis de Capacidade dos modelos CMMI-DEV e MR-MPS. Entende-se por Capacidade o grau de institucionalizao com que os processos ou reas de processo so executados em uma organizao. Institucionalizar o processo implicar em execut-lo na organizao. Sendo assim, a partir deste mapeamento, podero identificar-se as recomendaes destes modelos no que diz respeito execuo de processos. A fim de atender este objetivo, sero comparados os Resultados de Atributos de Processos (RAP) do MR-MPS com as Prticas Genricas Generic Practices (GP) do CMMI-DEV.

2.2

Modelos Envolvidos

2.2.1 Modelo A: MR-MPS: 2011


a) Objetivo do Modelo: o MR-MPS define nveis de maturidade que estabelecem patamares de evoluo de processos, caracterizando estgios de melhoria da implementao do processo de software brasileiro [5]. Este modelo compatvel com os principais padres de qualidade internacionais para definio, avaliao e melhoria de processos de software para que as organizaes brasileiras possam alcanar competitividade a nvel internacional.

199 b) Elemento do Modelo: Atributos de Processo (AP) c) Objetivo: a capacidade do processo representada por um conjunto de Atributos de Processo descrito em termos de resultados esperados. Esta capacidade do processo expressa o grau de refinamento e institucionalizao com que o processo executado na organizao/unidade organizacional. No MR-MPS, medida que a organizao/unidade organizacional evolui nos nveis de maturidade, um maior nvel de capacidade para desempenhar o processo deve ser atingido. O atendimento aos Atributos do Processo (AP), pelo atendimento aos Resultados dos Atributos do Processo (RAP), requerido para todos os processos no nvel correspondente ao nvel de maturidade. Os nveis so acumulativos; ou seja, na adoo de um nvel de maturidade superior, alm dos processos correspondentes a este nvel, os processos dos nveis anteriores devem, tambm, ser executados. d) Item a ser Mapeado do Modelo: Resultados de Atributos de Processo (RAP) Nvel F e) Objetivo do Item: Os diferentes Nveis de Capacidade dos processos so descritos por Atributos de Processo (AP). O alcance de cada um destes Atributos de Processo avaliado utilizando os respectivos Resultados de Atributos de Processo (RAP).

2.2.2 Modelo B: CMMI-DEV v.1.3


a) Objetivo do Modelo: o CMMI-DEV permite diferentes abordagens para a melhoria de processo, desde que um modelo contenha os elementos essenciais de uma ou mais disciplinas e descreva um caminho de melhoria evolutiva desde processos imaturos, ad hoc, at processos maduros, disciplinados, com qualidade e eficcia melhoradas [3]. Sendo assim, utiliza duas formas de representaes: contnua e por estgios. b) Elemento do Modelo: Generic Goal (GG) c) Objetivo: Os Objetivos Genricos (GG) so componentes requeridos do modelo utilizadas nas avaliaes para determinar se uma rea de processo est implementada. So denominados genricos porque a mesma declarao de objetivo se aplica a vrias reas de Processo. Estes objetivos descrevem as caractersticas necessrias para institucionalizar os processos que implementam a rea de Processo em questo.

200 d) Item a ser Mapeado do Modelo: Generic Practice (GP) Nvel 2 e) Objetivo do Item: As Prticas Genricas (GP) so componentes esperados do modelo e so denominadas genricas porque a mesma prtica se aplica a vrias reas de processo. Elas descrevem uma atividade considerada importante para a satisfao do objetivo genrico associado.

2.2.3 Consideraes
Os Objetivos Genricos (Generic Goals) do modelo CMMI-DEV foram excludos da comparao porque eles no so avaliados diretamente, mas sim, atravs das Prticas Genricas (Generic Practices) [4]. Estes Objetivos Genricos do CMMI-DEV no tm correspondentes na estrutura do modelo MR-MPS. Portanto, neste mapeamento, sero considerados apenas os componentes RAP do MR-MPS e as GP do CMMI-DEV.

2.3

Mapeamento MR-MPS/CMMI-DEV
A fim de comparar a equivalncia entre os itens dos modelos de qualidade, no que diz respeito ao nvel de aderncia, foram estabelecidos trs graus de aderncia: a) Totalmente Equivalente: Os itens do CMMI-DEV fazem exatamente as mesmas exigncias que os itens do MR-MPS; b) Parcialmente Equivalente: As exigncias dos itens do CMMI-DEV no so exatamente as mesmas que as dos itens do MR-MPS; c) No Possui Equivalente: No existe um item do CMMI-DEV equivalente no MR-MPS ou vice-versa.

201

Id.

Resultado do Atributo de Processo do MR-MPS

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

01

RAP 1 O processo atinge GP 1.1 Perform Specific Practices seus resultados definidos

No se aplica.

A fim de evidenciar o atendimento do propsito do processo, devem-se gerar produtos de trabalho (entrada e sada) e fornecer servios que so esperados a partir da execuo do processo. A fim de enfatizar a importncia dos processos e facilitar a sua institucionalizao, devem-se definir diretrizes que guiem a organizao no planejamento e implementao de seus processos, bem como informaes sobre as expectativas organizacionais para a execuo dos processos. Esta poltica deve ser publicada e divulgada a todos interessados na organizao.

02

RAP 2 Existe uma poltica GP 2.1 Establish an Organorganizacional estabelecida izational Policy e mantida para o processo

No se aplica.

03

RAP 3 A execuo do proGP 2.2 Plan the Process cesso planejada

A fim de identificar os possveis riscos e o esforo necessrio para atingir o escopo Embora a redao seja diferente, do software a ser desenvolvido, deve-se RAP 3 e GP 2.2 exigem o estabe- documentar um plano para a execuo do lecimento e a manuteno de um processo. Este planejamento deve incluir plano para execuo do processo. recursos, responsabilidades e tempo, bem como as atividades de controle e monitoramento da execuo do processo.

202

Id.

Resultado do Atributo de Processo do MR-MPS

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

04

RAP 5 (At o nvel F) As informaes e os recursos necessrios para a execuo do processo so identificados e disponibilizados

GP 2.3 Provide Resources

O MR-MPS exige a identificao e disponibilizao de informaes e dos recursos necessrios para A fim de permitir que a conduo do projeto ocorra de acordo com o plano, deve-se execuo do processo. assegurar que as informaes e os recurJ o CMMI-DEV s exige o forne- sos necessrios para executar o processo cimento dos recursos, o que estejam disponveis quando necessrios. apenas parte do que exigido no MR-MPS.

05

RAP 6 (At o nvel F) As responsabilidades e a autoridade para executar o processo so definidas, atribudas e comunicadas

Haver compatibilidade nas exigncias quando a organizao alcanar o nvel 3 de maturidade do CMMI-DEV ou superior, no qual exigido um processo padro, pois embora a redao seja diferente, GP 2.4 Assign ResponsibiRAP 6 e GP 2.4 possuem as lity mesmas exigncias, associadas a definio e atribuio das responsabilidades e autoridade pela execuo do processo, considerandose a comunicao contemplada na atribuio.

A fim de que haja, ao longo da vida do processo, pessoas que se responsabilizem pela execuo do processo e por alcanar os resultados especificados, devese assegurar que as responsabilidades e a autoridade para executar o processo esto claramente definidas e bem compreendidas.

203

Id.

Resultado do Atributo de Processo do MR-MPS

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

06

RAP 7 (At o nvel F) As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia

GP 2.5 Train People

Embora a redao seja diferente, RAP 7 e GP 2.5 possuem as mesmas exigncias: (i) as pessoas devem possuir as habilidades, conhecimentos e experincias necessrios para execuo do processo (o que no CMMI-DEV consta no propsito da prtica); e (ii) devem ser realizados treinamentos, quando necessrio.

A fim de garantir que as pessoas que esto executando o processo tenham as habilidades, conhecimentos e experincias necessrias para executar ou dar suporte ao processo, deve-se assegurar que estas pessoas recebem treinamento apropriado.

07

RAP 8 A comunicao entre as partes interessadas no processo gerenciada de forma a garantir o seu envolvimento

GP 2.7 Identify and Involve Relevant Stakeholders

No se aplica.

A fim de estabelecer uma interface que assegure a comunicao, devem-se identificar as partes interessadas no processo, planejar e manter o seu envolvimento.

08

RAP4 (A partir do nvel F) Medidas so planejadas e coletadas para monitorao da execuo do processo e ajustes so realizados

Tanto o MR-MPS quanto o CMMIDEV exigem a monitorao de controle do processo e a impleGP 2.8 Monitor and Control mentao de aes corretivas para the Process realizao de ajustes. Porm, apenas o MR-MPS exige que se tenha uma medio.

A fim de que aes corretivas apropriadas possam ser realizadas quando necessrio, deve-se realizar o monitoramento e o controle do processo em marcos e pontos de controle.

204

Id.

Resultado do Atributo de Processo do MR-MPS RAP 10 (A partir do nvel F) A aderncia dos processos executados s descries de processo, padres e procedimentos avaliada objetivamente e so tratadas as no conformidades

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

09

GP 2.9 Objectively Evaluate Adherence

No se aplica.

A fim de garantir que o processo implementado est de acordo com o planejado, deve-se fornecer garantias de que este processo est aderente sua descrio, aos seus padres e procedimentos.

10

RAP 9 (At o nvel F) Os resultados do processo so revistos com a gerncia de alto nvel para fornecer visibilidade sobre a sua situao na organizao

Tanto o MR-MPS quanto o CMMIDEV exigem que os resultados da execuo do processo sejam revistos com a gerncia de alto nvel A fim de proporcionar a visibilidade apropriada do processo para a gerncia de GP 2.10 Review Status with para fornecer visibilidade de sua nvel superior, devem-se realizar revises situao. Higher Level Management com os gerentes responsveis pelas polPorm, apenas o CMMI-DEV faz ticas e diretrizes gerais para o processo. referncia ao tratamento de questes crticas, o que no exigido neste resultado pelo MR-MPS. A fim de que a integridade dos produtos de trabalho do processo seja preservada, de acordo com a sua importncia para o projeto, deve-se especificar um nvel de controle apropriado para os artefatos ao longo de sua vida til.

11

RAP 13 Os produtos de trabalho so colocados em GP 2.6 Control Work Pronveis apropriados de con- ducts trole

No se aplica.

205

Id.

Resultado do Atributo de Processo do MR-MPS

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

12

RAP 11 Os requisitos dos produtos de trabalho do Inexistente processo so identificados

No existe uma prtica genrica no CMMI-DEV que explicite a identificao dos requisitos dos produtos de trabalho do processo. Apenas existe referncia a identificao dos produtos de trabalho nas notas introdutrias da GP 2.6, mas sem citao aos seus requisitos, o que mesmo assim no constitui uma obrigatoriedade. O CMMI-DEV no exige que os produtos de trabalho do processo tenham seus requisitos de documentao estabelecidos. Apenas existe referncia identificao dos produtos de trabalho nas notas introdutrias da GP 2.6, mas sem citao aos requisitos de documentao, o que mesmo assim no constitui uma obrigatoriedade.

Define o que ser necessrio para a produo de cada produto de trabalho durante o desenvolvimento do processo. Consiste na definio de critrios associados ao formato e padres de documentao e critrios de qualidade relacionados a estes produtos de trabalho.

13

RAP 12 Requisitos para documentao e controle Inexistente dos produtos de trabalho so estabelecidos

Especifica uma forma de controlar as mudanas e revises dos produtos de trabalho, atravs do versionamento. Tambm define nveis de controle de acesso aos produtos de trabalho, de acordo com a importncia destes para o projeto.

206

Id.

Resultado do Atributo de Processo do MR-MPS

Generic Practices do CMMI-DEV

Consideraes

Relevncia para o Processo

14

RAP 14 Os produtos de trabalho so avaliados objetivamente com relao aos padres, procedimen- Inexistente tos e requisitos aplicveis e so tratadas as no conformidades

No existe uma prtica genrica no CMMI-DEV que explicite a avaliao dos produtos de trabalho do processo. S h referncia avaliao dos produtos de trabalho selecionados do processo nas notas introdutrias da GP 2.9, o que no constitui uma obrigatoriedade.

Analisa se os produtos de trabalho produzidos esto em conformidade com o que foi planejado para o processo, verificando a corretude e completude destes. As no conformidades encontradas devem ser tratadas at serem solucionadas.

207

3.
3.1

FRAMEWORK DE PROCESSO
Fluxo do Processo

Figura 1. Fase Gerenciamento do Processo

208

Figura 2. Fase Execuo das Atividades do Processo

209

Figura 3. Fase Aplicao do Formalismo de Execuo

210

3.2

Descrio do Processo

3.2.1 Fase Gerenciamento do Processo


a) Definir Poltica Organizacional Objetivo: Especificar uma Poltica de Desenvolvimento de Software para a Organizao, a partir da definio de diretrizes, responsabilidades e polticas especficas para cada processo ou rea de processo. Critrios de Entrada Artefatos de Entrada Processo Definido ou em Definio. Processo e/ou Necessidades/Objetivos Organizacionais Passos Definir Diretrizes Gerais e Responsabilidades Gerais; Definir Polticas de Qualidade, Desenvolvimento e Polticas Especficas por rea de Engenharia de Software. Critrios de Sada Artefatos de Sada Poltica Organizacional definida. Poltica Organizacional Responsveis Gerente de Processo Templates Template de Poltica Organizacional Ferramentas de Apoio Utilizadas Editor de Texto ou Ferramenta de Execuo de Processos b) Publicar Poltica Organizacional Objetivo Publicar e disponibilizar a Poltica Organizacional a todos os stakeholders. Critrios de Entrada Artefatos de Entrada Possuir uma Poltica Organizacional definida. Poltica Organizacional Passos Disponibilizar a Poltica Organizacional em meio adequado;

211 Comunicar e disseminar a todos os stakeholders. Critrios de Sada Artefatos de Sada A Poltica Organizacional deve est disponvel a todos os inte- No se aplica. ressados. Responsveis Gerente de Processo Templates No se aplica. Ferramentas de Apoio Utilizadas Site na Intranet da Organizao e/ou Ferramenta de Execuo de Processos c) Estimar Esforo Objetivo Estimar o esforo necessrio para realizar cada tarefa do processo. Critrios de Entrada Artefatos de Entrada O escopo operacional do projeto (tarefas do processo) deve es- Plano de Projeto (seo Escopo), Lista de Requisitos e Casos t definido. de Uso Passos Escolher a tcnica de estimativa de tamanho do projeto; Aplicar a tcnica de estimativa de tamanho escolhida; Escolher a tcnica de estimativa de esforo que mais se adeque ao projeto; Calcular o esforo necessrio para realizar as tarefas do projeto segundo a tcnica escolhida. Critrios de Sada Artefatos de Sada Estimativas de esforo para o projeto realizadas. Plano de Projeto (seo Estimativas) Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Spider-APF ou Spider-UCP e Spider-Cocomo (disponveis em spider.ufpa.br/index.php?id=resultados)

212 d) Definir Cronograma Objetivo Estimar o tempo esperado para incio e trmino de realizao das tarefas do processo. Critrios de Entrada Artefatos de Entrada Ter definido o esforo necessrio para execuo das tarefas. Plano de Projeto (seo Estimativas) Passos Analisar a relao entre o esforo e o tempo para execuo de cada tarefa; Definir os marcos e pontos de controle para a execuo do processo; Estimar a data de incio e trmino previsto para cada tarefa com base na anlise do esforo gasto para execuo destas. Critrios de Sada Artefatos de Sada Cronograma definido. Plano de Projeto (seo Cronograma) Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos e) Identificar Riscos Objetivo Identificar e cadastrar os riscos inerentes execuo do processo. Critrios de Entrada Artefatos de Entrada Analisar o Plano de Projeto e a Base Histrica. Plano de Projeto Passos Analisar a Base Histrica e o Plano de Projeto a fim de identificar possveis riscos; Cadastrar os riscos identificados; Caso seja encontrado algum risco durante o desenvolvimento do projeto que no foi identificado previamente, este risco deve ser adicionado lista de riscos, contendo sua severidade, probabilidade de ocorrncia e prioridade; Definir um plano de mitigao para prevenir a ocorrncia de riscos identificados; Caso um risco previsto ocorra, uma medida de contingncia deve ser tomada.

213 Critrios de Sada Riscos do Projeto identificados. Responsveis Gerente de Projeto Templates Template de Lista de Riscos Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos f) Definir Recursos e Responsabilidades Objetivo Identificar os recursos (hardware e software) e as responsabilidades (recursos humanos) necessrias para realizar cada tarefa do processo. Critrios de Entrada Artefatos de Entrada Escopo definido e Esforo mensurado. Plano do Projeto Passos Definir as responsabilidades necessrias para executar o processo; Definir recursos a serem utilizados em cada tarefa, levando-se em considerao o esforo estimado para realizao destas. Critrios de Sada Artefatos de Sada Lista com Recursos Necessrios para realizar as Atividades e a Plano de Projeto (seo Recursos e Responsabilidades) Lista de Responsabilidades do Projeto definidas. Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Spider-PM (disponvel em spider.ufpa.br/index.php?id=resultados) Artefatos de Sada Plano de Projeto (seo Riscos)

214 g) Identificar Habilidades e Capacidade Objetivo Verificar quais pessoas esto aptas para executar uma determinada tarefa, a partir da anlise de suas capacidades e habilidades a fim de atender as responsabilidades previamente definidas para esta tarefa. Nesta etapa deve-se verificar, tambm, se a pessoa necessita ou no de treinamento. Critrios de Entrada Artefatos de Entrada Verificar os projetos anteriores em que os membros da equipe Currculo dos membros da Equipe e Plano de Cargos e Funes participaram, bem como seus currculos e treinamentos realizados. Passos Analisar os currculos dos membros da equipe e os perfis de desenvolvimento da organizao; Entrevistar os membros da equipe; Identificar habilidades e capacidades de cada membro da equipe; Verificar a necessidade de treinamento. Critrios de Sada Artefatos de Sada Capacidade e Habilidades identificadas. Plano de Projeto (seo Recursos Humanos) Responsveis Gerente de Projeto Templates Template de Lista de Recursos Humanos do Projeto Ferramentas de Apoio Utilizadas Spider-PM (disponvel em spider.ufpa.br/index.php?id=resultados)

h) Alocar Recursos Objetivo Atribuir aos projetos os recursos (hardware e software) necessrios para a sua realizao. Critrios de Entrada Artefatos de Entrada Recursos Necessrios para realizao das Atividades definidos. Plano de Projeto (seo Escopo)

215 Passos Verificar o esforo estimado para realizar as tarefas; Alocar os recursos de acordo com a disponibilidade e o esforo estimado para realizao das atividades. Critrios de Sada Artefatos de Sada Recursos alocados para cada tarefa. Plano de Projeto (seo Recursos) Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos i) Atribuir Responsabilidades Objetivo Atribuir aos recursos humanos responsabilidades no projeto levando em considerao o perfil de cada um destes. Critrios de Entrada Artefatos de Entrada Recursos e papis definidos, capacidade e habilidade dos re- Plano de Cargos e Funes e Plano de Projeto (seo Escopo) cursos humanos identificadas. Passos Verificar os Papis necessrios para executar o projeto; Analisar as Habilidades e Capacidades dos Recursos Humanos para definir os Papis; Alocar os membros da equipe s responsabilidades definidas em cada tarefa. Critrios de Sada Artefatos de Sada Responsabilidades atribudas. Plano de Projeto (seo Recursos e Responsabilidades) Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos

216 j) Identificar Stakeholders Objetivo Cadastrar todos os interessados afetados pelo projeto. Critrios de Entrada Plano de Projeto definido. Passos Identificar todos os interessados no projeto; Registrar o contato dos interessados. Critrios de Sada Identificar todos os interessados. Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos

Artefatos de Entrada Plano de Projeto

Artefatos de Sada Plano de Projeto (seo Stakeholders)

k) Planejar Comunicao Objetivo Fazer com que todos os interessados no projeto tenham acesso s informaes e documentos relevantes. Critrios de Entrada Artefatos de Entrada Todos os Stakeholders devem ser identificados bem como os Plano do Projeto com Lista de Stakeholders e Lista de Artefatos. artefatos relevantes gerados no projeto. Passos Verificar quais artefatos precisam ser divulgados; Definir forma e meios de comunicao; Disponibilizar acesso aos artefatos. Critrios de Sada Artefatos de Sada O Plano de Comunicao deve est criado. Plano de Comunicao

217 Responsveis Gerente de Projeto Templates Template de Plano de Comunicao Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos l) Identificar Requisitos dos Produtos de Trabalho Objetivo Definir os padres, templates e demais atributos necessrios para a produo de cada produto de trabalho durante o desenvolvimento do projeto. Critrios de Entrada Artefatos de Entrada Plano de Projeto estabelecido. No se aplica. Passos Definir requisitos para a manuteno das informaes a serem geradas pelo projeto; Associar os requisitos aos templates, padres de documentao e critrios de qualidade relacionados a produtos de trabalho. Critrios de Sada Artefatos de Sada Requisitos dos Produtos de Trabalho identificados. Padres e Templates de Produtos de Trabalho Responsveis Equipe de Garantia da Qualidade Templates No se aplica. Ferramentas de Apoio Utilizadas Spider-CL (disponvel em spider.ufpa.br/index.php?id=resultados) m) Definir Atividades de Monitoramento e Controle Objetivo Definir mtodos para monitorar e controlar as atividades que esto sendo desenvolvidas durante o projeto, a fim de garantir que a realizao destas ocorra conforme o planejado.

218 Critrios de Entrada Artefatos de Entrada Escopo, Cronograma e Lista de Risco para o Projeto definidos. Plano do Projeto Passos Verificar os marcos e os pontos de controle previamente definidos; Identificar atividades do processo e associar os marcos e os pontos de controle a estas; Definir tcnicas para monitorar o andamento da execuo do Processo nos marcos e pontos de controle. Critrios de Sada Artefatos de Sada Ter as atividades para Monitoramento e Controle definidas. Plano de Projeto (seo Monitoramento e Controle) Responsveis Gerente de Projeto Templates No se aplica. Ferramentas de Apoio Utilizadas Spider-MPlan (disponvel em spider.ufpa.br/index.php?id=resultados) e Ferramenta de Execuo de Processos n) Gerenciar Comunicao Objetivo Fazer com que as informaes gerais em relao ao progresso de execuo das atividades cheguem a todos os stakeholders. Critrios de Entrada Artefatos de Entrada Possuir um Plano de Comunicao definido. Plano de Comunicao. Passos Utilizar os meios e formas de comunicao definidos para interao entre os envolvidos no projeto; Acompanhar a interao entre os envolvidos no projeto e solucionar possveis problemas que possam surgir. Critrios de Sada Artefatos de Sada Gerenciamento efetivo da Comunicao. Plano de Comunicao atualizado Responsveis Gerente de Projeto Templates Template de Plano de Comunicao Ferramentas de Apoio Utilizadas Ferramenta de Execuo de Processos

219 o) Realizar Monitoramento e Controle Objetivo Cadastrar e monitorar os possveis problemas que surgem durante a execuo do projeto, alm de acompanhar a resoluo destes. Critrios de Entrada Artefatos de Entrada Ter Atividades para Monitoramento e Controle definidas. Plano de Projeto (seo Monitoramento e Controle) Passos Monitorar o projeto nos marcos e pontos de controle, verificando se o que foi planejado est de acordo com o que est sendo executado, afim de que aes corretivas apropriadas possam ser realizadas quando necessrio; Cadastrar dos problemas e no conformidades que ocorrerem durante as etapas do projeto; Realizar ajustes necessrios; Acompanhar a resoluo destes problemas e no conformidades. Critrios de Sada Artefatos de Sada Problemas identificados cadastrados e acompanhados. Relatrio de Problemas e No conformidades do Projeto Responsveis Gerente de Projeto Templates Template de Lista de Problemas e No conformidades do Projeto Ferramentas de Apoio Utilizadas Spider-MPlan (disponvel em spider.ufpa.br/index.php?id=resultados) e Redmine (disponvel em www.redmine.org) p) Realizar Revises no Processo Objetivo Realizar revises no processo a fim de garantir que este esteja aderente a sua descrio e tratar as no conformidades encontradas. Critrios de Entrada Artefatos de Entrada A execuo de um projeto deve est em um marco. Padres e Procedimentos Passos Estabelecer critrios de avaliao do processo; Fazer um checklist com os critrios estabelecidos;

220 Fazer avaliao objetiva; Listar as no conformidades e trat-las; Elaborar o Parecer tcnico da avaliao; Apresentar os resultados da avaliao gerncia de nvel superior. Critrios de Sada Artefatos de Sada Reviso no processo efetuada. Checklist e Parecer Tcnico da Avaliao Responsveis Equipe de Garantia de Qualidade Templates Template de Checklist e Parecer Tcnico Ferramentas de Apoio Utilizadas Spider-CL (disponvel em spider.ufpa.br/index.php?id=resultados)

3.2.2 Fase Execuo de Atividades do Processo


a) Gerar Produtos de Trabalho Objetivo Gerar os produtos de trabalho necessrios para atender o propsito do processo. Critrios de Entrada Artefatos de Entrada Templates, Padres e Procedimentos definidos. Modelo do Processo, Padres, Procedimentos e Templates Passos Analisar a atividade do processo a ser executada, bem como as suas restries e limitaes; Identificar artefatos que necessitam ser gerados na execuo de uma atividade. Critrios de Sada Artefatos de Sada Produtos de trabalhos gerados. Artefatos do processo Responsveis Equipe do Projeto Templates Templates de Artefatos do Processo

221 Ferramentas de Apoio Utilizadas Editor de Texto, IDE, Ferramenta de Execuo de Processo, etc. b) Gerenciar Configuraes Objetivo Gerenciar a evoluo do projeto atravs do gerenciamento de verses destes bem como a atravs do controle de acesso aos produtos de trabalho. Critrios de Entrada Artefatos de Entrada Repositrio configurado e/ou Poltica de Configurao definida. Poltica de Configurao Passos Especificar e manter um sistema de gerncia de configurao; Definir uma poltica de versionamento; Definir o nvel de controle apropriado para cada produto de trabalho; Especificar o nvel de acesso de cada envolvido no projeto; Registrar e disponibilizar situao dos produtos de trabalho; Controlar as mudanas nos produtos de trabalho; Realizar auditorias para garantir que os itens de configurao estejam ntegros, completos e consistentes. Critrios de Sada Artefatos de Sada Nvel de acesso definido, poltica de versionamento, produtos de Plano de Configurao atualizado, Lista de Problemas Identifitrabalhos versionados e disponveis. cados, Plano de Ao e Relatrios de Auditoria Responsveis Gerente de Configurao Templates Templates de Plano de Configurao atualizado, Lista de Problemas Identificados, Plano de Ao e Relatrios de Auditoria Ferramentas de Apoio Utilizadas SVN (disponvel em subversion.apache.org) e Redmine (disponvel em www.redmine.org) c) Verificar Aderncia do Processo Objetivo Verificar se o processo esta aderente aos padres definidos.

222 Critrios de Entrada Checklist de Avaliao, Padres e Modelo do Processo estabelecidos. Passos Aplicar checklist de Avaliao do Processo; Realizar entrevistas; Analisar resultados obtidos; Gerar relatrio. Critrios de Sada Aderncia do Processo avaliada. Responsveis Equipe de Garantia da Qualidade Templates Template de Checklist e Relatrio de Avaliao Ferramentas de Apoio Utilizadas Spider-CL (disponvel em spider.ufpa.br/index.php?id=resultados) d) Verificar Aderncia dos Produtos de Trabalho Objetivo Verificar se os produtos de trabalho esto aderentes aos requisitos estabelecidos. Critrios de Entrada Artefatos de Entrada Checklist de Avaliao definido. Checklist de Avaliao Passos Aplicar checkist; Realizar entrevistas; Analisar resultados obtidos; Gerar relatrio. Critrios de Sada Artefatos de Sada Aderncia dos produtos de trabalho checada. Checklist de Avaliao aplicado e Relatrio de Avaliao gerado Responsveis Equipe de Garantia da Qualidade Artefatos de Entrada Checklist de Avaliao

Artefatos de Sada Checklist de Avaliao aplicado e Relatrio de Avaliao gerado

223 Templates Template de Checklist e Relatrio de Avaliao Ferramentas de Apoio Utilizadas Spider-CL (disponvel em spider.ufpa.br/index.php?id=resultados)

3.2.3 Fase Aplicao do Formalismo de Execuo


a) Aplicar Hierarquia de Ativos do Processo Objetivo Distinguir os elementos do processo de acordo com seu nvel hierrquico. Critrios de Entrada O nvel hierrquico da linguagem de modelagem do processo deve estar definido. Passos Consultar Especificao Tcnica da xSPIDER_ML; Avaliar o modelo do processo de acordo com o nvel hierrquico definido na xSPIDER_ML. Critrios de Sada Hierarquia do processo aplicada aos seus elementos. Responsveis Ferramenta de Execuo de Processos / Equipe de Garantia da Qualidade b) Aplicar Restries do Processo Objetivo Especificar a relao das conexes entre as atividades para permitir a execuo do processo. Critrios de Entrada Processo modelado. Passos Consultar Especificao Tcnica da xSPIDER_ML; Definir as regras de restries entre as atividades do processo modelado. Critrios de Sada Fluxo de execuo entre as atividades dos processos definidos.

224 Responsveis Ferramenta de Execuo de Processos / Gerente de Processo c) Controlar Variveis do Projeto Objetivo Cadastrar e acompanhar as especificidades do projeto em relao a recursos (tipo), em relao s atividades (cronograma e carga horria). Critrios de Entrada Plano de Projeto. Passos Consultar Especificao Tcnica da xSPIDER_ML; Definir as variveis para execuo das atividades do processo modelado. Critrios de Sada Acompanhar a utilizao de Recursos e Cronograma. Responsveis Ferramenta de Execuo de Processos d) Monitorar Estado do Processo Objetivo Efetuar o monitoramento dos estados dos elementos do processo de acordo com as regras de transio de estados. Critrios de Entrada Processo est em execuo. Passos Consultar Especificao Tcnica da xSPIDER_ML; Avaliar a mudana de estados nos elementos do processo de acordo com as regras de transio definidas na xSPIDER_ML. Critrios de Sada Monitoramento do estado dos elementos do Processo em execuo at que o mesmo seja concludo. Responsveis Ferramenta de Execuo de Processos

225 e) Monitorar Tempos do Processo Objetivo Monitorar o processo em relao ao tempo estimado e real de execuo do mesmo. Critrios de Entrada Iniciar a execuo do processo. Passos Consultar Especificao Tcnica da xSPIDER_ML; Contabilizar o tempo de execuo de uma tarefa e comparar com o tempo estimado; Atualizar o status da tarefa de acordo com o tempo de execuo e a carga horaria definida para a tarefa. Critrios de Sada Acompanhamento da execuo do processo e informao dos tempos de execuo de cada elemento desse processo. Responsveis Ferramenta de Execuo de Processos f) Registar Histrico de Eventos Objetivo Visa registrar as transies de estados e tempo assim como os principais eventos que ocorrem durante a execuo do processo. Critrios de Entrada Iniciar a execuo do processo. Passos Consultar Especificao Tcnica da xSPIDER_ML; Cadastrar os eventos (transio de estados, status das tarefas, tempo de execuo, entre outros) gerados a partir da execuo de cada tarefa do processo. Critrios de Sada O Log de eventos realizados deve ser salvo e est disponvel para consulta. Responsveis Ferramenta de Execuo de Processos

226 g) Realizar Feedback Objetivo Dar flexibilidade execuo do processo, permitindo retornar a realizao de uma atividade do processo durante a sua execuo. Critrios de Entrada Processo modelado. Passos Consultar Especificao Tcnica da xSPIDER_ML; Permitir, quando necessrio, o retorno da execuo de uma atividade do processo de acordo com as regras de hierarquia e restries definidas ao processo. Critrios de Sada Processo poder ser alterado durante sua execuo. Responsveis Ferramenta de Execuo de Processos

4.

ADERNCIA DO FRAMEWORK DE PROCESSO AO MAPEAMENTO


A fim de comparar a aderncia entre as atividades do Framework e os itens mapeados dos modelos de qualidade foram estabelecidos trs nveis: a) Totalmente Aderente: As atividades do Framework so totalmente aderentes s recomendaes dos modelos de qualidade; b) Parcialmente Aderente: As atividades do Framework contemplam parcialmente as recomendaes dos modelos de qualidade; c) No Aderente: As atividades do Framework no so aderentes s recomendaes dos modelos de qualidade.

227
Atividade do Framework Identificador Mapeamento 02 Nvel de Aderncia Totalmente Justificativa Implica na definio de diretrizes de como a organizao planeja e implementa os seus processos, bem como informaes sobre as expectativas organizacionais para a execuo dos processos. Esta poltica deve ser publicada e divulgada a todos interessados na organizao, a fim de enfatizar a importncia dos processos e facilitar a sua institucionalizao. A fim de planejar o Processo, deve-se estimar o esforo. A fim de planejar o Processo, deve-se definir o cronograma. A fim de planejar o Processo, deve-se estimar o esforo. A fim de planejar o Processo e fornecer recursos, devem-se definir os recursos e responsabilidades a serem utilizadas na organizao. A fim de assegurar que as pessoas que realizaro o trabalho estejam devidamente treinadas para tal, deve-se cadastrar suas capacidades e habilidades como verificar, tambm, se necessitam de treinamento. A fim de fornecer recursos, deve-se atribuir responsabilidades aos envolvidos no desenvolvimento do processo. A fim de atribuir responsabilidades, deve-se assegurar que as responsabilidades e autoridade para executar o processo esto bem definidas. A fim de identificar e envolver os Stakeholders deve-se primeiramente identific-los. A fim de identificar e envolver os Stakeholders, deve-se planejar a comunicao entre eles.

Definir Poltica Organizacional

Publicar Poltica Organizacional Estimar Esforo Definir Cronograma Identificar Riscos Definir Recursos e Responsabilidades

02 03 03 03 03, 04

Totalmente Totalmente Totalmente Totalmente Totalmente

Identificar Habilidades e Capacidade

06

Totalmente

Alocar Recursos Atribuir Responsabilidades Identificar Stakeholders Planejar Comunicao

04 05 07 07

Totalmente Totalmente Totalmente Totalmente

228
Atividade do Framework Identificar Requisitos dos Produtos de Trabalho Definir Atividades de Monitoramento e Controle Gerenciar Comunicao Identificador Mapeamento 12 Nvel de Aderncia Totalmente Justificativa A fim de identificar os requisitos dos produtos de trabalho, deve-se definir critrios associados a formato e padro de documentao e critrios de qualidade destes produtos de trabalho. A fim de planejar o processo, deve-se definir mtodos de monitoramento e controle do processo. A fim de envolver os Stakeholders, deve-se gerenciar a comunicao com os mesmos. A fim de monitorar e controlar o processo, deve-se realizar monitoramento e controle dirio buscando identificar problemas que surgem durante a execuo do projeto. A fim de dar visibilidade das no conformidades identificadas e do andamento da realizao do processo, deve-se realizar revises nestes e apresentar os resultados a gerncia de nvel superior. Durante a execuo do processo os produtos de trabalho sero gerados. A fim de gerenciar configurao e controlar produtos de trabalho, especificar uma forma de controle destes produtos de trabalho como, tambm, critrios de qualidade relacionados a estes produtos de trabalho. A fim de verificar aderncia do Processo, deve-se averiguar se o Processo est em conformidade com o que foi planejado. A fim de verificar a aderncia dos produtos de trabalho, deve-se averiguar se os produtos de trabalho esto em conformidade com o que foi planejado para o processo.

03 07

Totalmente Totalmente

Realizar Monitoramento e Controle

08

Totalmente

Realizar Revises no Processo Gerar Produtos de Trabalho Gerenciar Configuraes

10 01 11, 13

Totalmente Totalmente Totalmente

Verificar Aderncia do Processo Verificar Aderncia dos Produtos de Trabalho

09

Totalmente

14

Totalmente

229
Atividade do Framework Aplicar Hierarquia de Ativos do Processo Aplicar Restries do Processo Controlar Variveis do Projeto Monitorar Estado do Processo Monitorar Tempo do Processo Registrar Histrico de Eventos Realizar Feedback 01 Parcialmente Estas tarefas no so provenientes do mapeamento e sim derivadas de requisitos de Execuo de Processo. Contudo auxiliam parcialmente no atendimento do propsito do processo. Identificador Mapeamento Nvel de Aderncia Justificativa