Definio de Processos de Software baseado em uma Arquitetura de Componentes de Processo

Luiz Carlos M. Ribeiro, Cristiane S. Ramos, Kamilla Crozara, Hilmer R. Neri, Eusyar Alves, Rejane M. C. Figueiredo Faculdade Gama, Campus Gama Universidade de Braslia (UnB).
{lcarlos, cristianesramos, hilmer, rejanecosta}@unb.br, holanda.kamilla@gmail.com, eusyar@hotmail.com

Abstract. In this work we present a standard process model from a component architecture of Software Process based on Software & Systems Process Engineering Meta-Model Specification (SPEM), that allows defining software and systems development processes and their components. From the standard process model we proceeded to the reuse of the processs components in order to establish a process in use in the context of game development using mechanisms related to the types of process variability. Resumo. Neste trabalho apresentado um modelo de processo padro elaborado a partir de uma arquitetura de componentes de Processo de Software baseada no meta-modelo Software & Systems Process Engineering Meta-Model Specification (SPEM), que permite definir processos de desenvolvimento de software e sistemas e seus componentes. A partir do modelo de processo padro foi realizada a reutilizao de componentes de processo para o estabelecimento de um processo em uso no contexto de desenvolvimento de jogos eletrnicos utilizando mecanismos relacionados aos tipos de variabilidade de processo.

1. Introduo
As organizaes de desenvolvimento de software tm buscado cada vez mais aumentar a sua participao e competitividade no mercado, investindo na melhoria de seus processos de software para que possam apoiar tanto a reduo dos custos de produo quanto o aumento da qualidade, produtividade e satisfao do usurio, implantando processos de software segundo modelos, tais como, CMMI-DEV [SEI 2006] e MRMPS [SOFTEX 2009]. Considerando processo de software como um conjunto coerente de atividades, prticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios para conceber, desenvolver, dispor e manter um produto de software [Fuggeta 2000], a padronizao de processos de software pode reduzir a diversidade de processos existentes em uma organizao, e ainda, promover o aprimoramento da comunicao e reduzir o tempo de treinamento dos envolvidos [Sommerville 2007], com a utilizao de conceitos de reutilizao de componentes de processo de software. Espera-se que com a reutilizao de processos de software seja possvel aumentar a qualidade e produtividade no desenvolvimento de software, minimizando a

duplicao do esforo e reaproveitando o mximo possvel das experincias de projetos passados. Assim, os conceitos do desenvolvimento de software baseado em componentes, em que o desenvolvimento do software realizado pela integrao planejada de componentes de software pr-existentes [Brown e Short 1997], vm sendo aplicados no contexto de processos de software, visando componentes de processos. A definio de processos de software baseada em uma arquitetura de componentes de processo contribui para que as organizaes possam promover a reutilizao de processos de forma mais efetiva. Algumas iniciativas de pesquisa tm sido conduzidas no sentido de se estabelecer mtodos para promover a reutilizao de processos [Lanna, 2009; Barreto et al., 2008; Barreto et al., 2009, Aleixo et al., 2010]. Muitos desses trabalhos utilizam tcnicas e processos de reutilizao de software comuns para derivar mtodos para reutilizao de processos de software. No entanto, Fiorini (2001) prope uma arquitetura de processos de software para facilitar o acesso e o reaproveitamento dos processos. Nesse sentido, este trabalho prope uma arquitetura de processos baseada em conceitos de Arquitetura de Software [Bass et al., 2003], definindo elementos que compe uma arquitetura, tais como: Modelos de Referncia; Estilos Arquiteturais; e Arquitetura de Referncia. A Arquitetura de Processos proposta foi baseada em modelos de referncia como CMMI-DEV [SEI, 2006] e MR-MPS [SOFTEX, 2009], e possui um estilo arquitetural composto por camadas e uma Arquitetura de Processos Padro, que pode ser estendida para Arquiteturas de Processos em Uso, contendo especificidades inerentes ao negcio ou ao tipo de software a ser desenvolvido. Este artigo est organizado em sees. Na Seo 2 apresentam-se os aspectos da definio do modelo de processo como: reutilizao de processos de software; conceitos de arquitetura de processos; e o meta-modelo SPEM. Na Seo 3 apresenta-se a proposta do Modelo de Processo Padro, com a Arquitetura de Processos e o Processo Padro. Na Seo 4 apresenta-se um exemplo do processo em uso aplicado no desenvolvimento de jogos. Finalizando, na Seo 5, apresentam-se a concluso e trabalhos futuros.

2. Definio do Modelo de Processo de Software

Esta seo apresenta os conceitos que foram utilizados para definio do processo padro, so eles: reutilizao de processos de software (Seo 2.1), arquitetura de software (Seo 2.2) e o meta-modelo SPEM (Seo 2.3).

2.1.Reutilizao de Processo de Software

Succi et al. (1997) definem reutilizao de processo como sendo a rplica de um conjunto de aes de um processo j executado em um novo contexto. Bayer (1999) afirma que necessrio que a definio do processo seja feita de forma flexvel para que possa ser adaptado a diferentes situaes, que possua diretivas e suporte suficientes, e que no seja muito vago, caso contrrio o mesmo no ir atender s necessidades de variadas situaes da indstria sem uma forte interpretao e suporte adicionais.

Para Barreto et al. (2007), a definio de processo de software uma tarefa desafiadora, pois alm de exigir experincia ela envolve muito aspectos da Engenharia de Software e esperado que o conhecimento de profissionais mais experientes possa ser compartilhado e reutilizado por outros profissionais. Com isso, faz-se necessrio estabelecer mecanismos que sejam capazes de representar semelhanas e variabilidade de processos de software, facilitando a reutilizao dos processos de software, o que contribuir para diminuio de custo e esforo da atividade de definio de processos e aumento da qualidade dos processos [Barreto et al. 2009]. Segundo Fiorini (2001), o conceito de reutilizao de processo o uso de um modelo de processo, na criao de outro processo. O modelo de processo representa a descrio de um processo na linguagem de modelagem de processos. Para a criao de processos reutilizveis necessrio que a sua definio seja feita de forma que a organizao possa adapt-los aos requisitos do projeto, para isso Hollenbach e Frakes [Hollenbach e Frakes apud Fiorini 2001] definiram o ciclo de vida para descrio de processo: (i) Definir o processo reutilizvel: definir um processo propriamente dito e garantir que eles realmente possam ser reutilizados; (ii) Desenvolver treinamento para o processo reutilizvel: Definir treinamento; (iii) Adaptar o processo reutilizvel ao projeto: Adaptar o projeto para atender as necessidades especficas do(s) projeto(s) que ir(o) utiliz-lo; (iv) Adaptar o treinamento do processo reutilizvel para o processo adaptado ao projeto: Adaptar o treinamento para as necessidades do projeto que utilizar o processo; (v) Executar o processo no projeto: Significa que o projeto passa a utilizar na prtica o processo. Acompanhamento de garantia de qualidade e medies devem ser realizados; (vi) Refinar o processo: O processo avaliado com base nas medies e passos anteriores. Caso o processo no tenha alcanado os seus objetivos ele deve ser ajustado e novos treinamentos so realizados. Arquitetura de processo um conceito que tambm vem sendo utilizado no contexto de reutilizao de processo de software. Para Barreto et al. (2007), de forma simplificada, pode-se considerar que a arquitetura define um esqueleto que o processo deve possuir, determinando os principais elementos e como estes se relacionam, sem necessariamente definir como ser o detalhamento desses elementos principais.

2.2.Arquitetura de Software
Segundo Larman (2002), uma Arquitetura de Software um conjunto de decises significativas sobre a organizao do sistema de software, envolvendo a seleo dos elementos estruturais e suas interfaces, o comportamento e como esses elementos se interagem e colaboram para alcanar tal comportamento. Tais caractersticas auxiliam a obteno da reusabilidade. Bass et al. (2003) e Kruchten et al. (2006) definem Arquitetura de Software como sendo a estrutura ou estruturas de um sistema, que

compreende elementos de software, as propriedades externamente visveis de tais elementos e os relacionamentos entre os elementos. Ainda, Bass et al. (2003) definem que uma arquitetura de referncia consiste em componentes de software e os relacionamentos entre eles que implementam funcionalidades relativas s partes definidas no modelo de referncia. Uma arquitetura de referncia serve de base para a elaborao de arquiteturas de software e so definidas a partir de modelos de referncia e estilos arquiteturais, que so aplicados a um domnio especfico. Os modelos de referncia, os estilos arquiteturais e as arquiteturas de referncia no podem ser generalizados e confundidos com arquitetura de software, pois nenhum deles arquitetura de software [Bass et al., 2003], mas sim elementos teis para a definio da arquitetura de um sistema, que indicam decises importantes. Um modelo de referncia consiste na decomposio padronizada do problema em partes conhecidas que cooperam entre si em prol de uma soluo. Geralmente, estes problemas so de domnio bastante amadurecido e trazem a experincia de analistas de negcio em conjunto com desenvolvedores [Bass et al. 2003]. Os estilos arquiteturais expressam esquemas de organizao estrutural de sistemas, fornecendo um conjunto de componentes do sistema, suas responsabilidades e a forma de interao entre eles, estabelecendo um padro de utilizao. Por sua vez, uma arquitetura de referncia consiste em componentes de software e os relacionamentos entre eles que implementam funcionalidades relativas s partes definidas no modelo de referncia. Na Figura 1 apresenta-se o relacionamento entre esses conceitos:

Figura 1. Relacionamento entre modelo de referncia, estilo de arquitetura e arquitetura de referncia implementando uma arquitetura de software (adaptado de BASS et al., 2003)

2.3.O meta-modelo SPEM

O meta-modelo Software & Systems Process Engineering Meta-Model Specification (SPEM) [OMG 2008], define os conceitos necessrios para modelar, documentar, apresentar, gerenciar e representar mtodos e processos de desenvolvimento. O SPEM um meta-modelo de processo mantido pelo consrcio W3C [OMG 2008]. Ele permite definir processos de desenvolvimento de software e sistemas e seus componentes. O foco do SPEM so projetos de desenvolvimento, sendo que o objetivo principal acomodar o maior nmero possvel de mtodos e processos de desenvolvimento de diferentes estilos, nveis de formalismo e modelos de ciclo de vida. De maneira geral, possvel representar com o SPEM as atividades e tarefas, papis e

responsabilidades, artefatos produzidos e consumidos e o conhecimento gerado a partir ou relacionados a tais elementos. Este meta-modelo permite que processos de software sejam representados de duas formas: Contedo de Mtodo (Method Content): descreve a estrutura dos processos, as tarefas que o compem, os artefatos produzidos e consumidos, o conhecimento armazenado por meio de guias, conceitos, idias e lies aprendidas. Todo o contedo definido de maneira independente do ciclo de vida de desenvolvimento. Processos (Processes): a partir da reutilizao do contedo, so definidos os fluxos de atividades e tarefas e as fases do ciclo de vida de um processo de desenvolvimento, bem como os objetivos de cada etapa do processo. Outro aspecto importante do SPEM o conceito de Variabilidade. O metamodelo permite derivao de elementos de processos a partir de outros elementos prexistentes. Os tipos de variabilidade permitidos so apresentados no Quadro 1.
Quadro 1 - Tipos de variabilidade (OMG, 2008) Tipo de variabilidade Caractersticas O elemento herda as caractersticas do elemento base sem alterar as caractersticas do mesmo. A extenso fornece um mecanismo para o plug-in de mtodos reutilizar elementos, utilizando uma espcie de herana, a partir de uma base de plug-ins. Os valores dos atributos e associaes tambm so herdados do elemento base para o elemento de extenso. O resultado que o elemento de extenso tem as mesmas propriedades que o elemento base, mas pode definir suas prprias alteraes. Um elemento de substituio substitui as partes do elemento base. A substituio fornece um mecanismo para um elemento substituir o elemento base sem alterar diretamente qualquer uma das suas propriedades existentes. A substituio aparece no site publicado, mas o elemento base no. Fornece uma maneira para elementos contriburem com as suas propriedades ao seu elemento base sem diretamente alterar quaisquer de suas propriedades j existentes, de uma forma aditiva. A base aparece no site publicado, mas o elemento que contribui no. Esta relao combina os efeitos de variabilidade de extenso e substituio. Tal tipo de variabilidade substitui todos os atributos e instncias do elemento base com novos valores e instncias ou remove todos os valores ou associaes se o elemento de substituio no estiver definido nenhum.

Estender

Substituir

Contribuir

Estender e Substituir

3.Proposta do Modelo de Processo Padro 3.1.Arquitetura de Processos

Os trabalhos de Kammer (2000) e Oquendo (2006) so os que mais aproximam o conceito de Arquitetura de Software da idia de Arquitetura de Processos, embora eles se refiram a processos distribudos e cooperativos. Kammer (2000) utiliza o termo Arquitetura de Processos para descrever uma infraestrutura para execuo de processos que relaciona os vrios elementos do processo, como as pessoas, os artefatos, os processos automatizados e os recursos. Oquendo (2006) se refere arquitetura de modelo de processo como um conjunto de papis e de componentes de processo. Os componentes definem as atividades que os membros de um projeto devem realizar e os

papis representam o que esses membros podem executar. Os papis esto sujeitos a obrigaes e habilidades necessrias [Borsoi, 2008]. Desse modo, uma Arquitetura de Processos pode ser conceituada como um conjunto de vises representadas por modelos de processos. Esses modelos representam uma estrutura de processos e dos seus componentes em termos da sua composio, comportamento e relacionamentos, de acordo com um domnio e um contexto [Borsoi 2008]. O conjunto de vises determina os nveis de processos de software definidos, sendo que desde o processo padro at o nvel de instanciao os componentes so descritos em diferentes nveis de abstrao. Sendo assim, em uma abordagem top down, quanto mais baixo o nvel, mais especfico ser o seu contedo. Percebe-se ento que a organizao em nveis da Arquitetura de Processos permite o reuso de todo o contedo do processo padro. A Arquitetura de Processos proposta neste trabalho foi organizada conforme a viso de Bass et al. (2003) (Figura 1). As camadas da arquitetura de processo de software so apresentadas na Figura 2.

Figura 2. Arquitetura de Processos de Software

Os modelos de referncia agregam soluo aos problemas do ponto de vista do domnio, e carregam um conjunto de conhecimento bastante amadurecido. Nesse sentido, para o domnio Desenvolvimento de Software por exemplo, pode-se citar como modelos de referncia o CMMI-DEV [SEI 2006] e o MR-MPS [SOFTEX 2009]. Normalmente, os modelos de referncia so bastante genricos e necessitam de interpretao para serem colocados em prtica. Assim, o Processo Padro ou Processo

de Referncia deve carregar os elementos mnimos de um processo, tais como: tarefas; entradas; sadas; papis; responsabilidades; habilidades necessrias e medidas de qualidade de processo e de produto, em conformidade com os modelos de referncia adotados. As instncias de processos definem a camada Processo em Uso. Essa composta por processos especficos, que podem possuir dependncia com outros processos ou prticas, tais como: SCRUM [Schwaber e Sutherland 2010] para gesto de projetos; OPENUP [Eclipse Foundation 2010]; e XP [Wells 2011]. Com isso, o estilo arquitetural em camadas (Figura 2) fornece um esquema de organizao estrutural bastante favorvel reutilizao, deixando claras as responsabilidades e a forma de interao entre cada camada, alm de definir um padro de utilizao.

3.2.Processo Padro
Para a elaborao do modelo de Processo Padro foi seguido um ciclo de vida para definio de processos reutilizveis [Hollenbach e Frakes apud Fiorini 2001], em que na fase Definir o processo reutilizvel o Modelo de Processo Padro (Figura 3) baseado no meta-modelo SPEM [OMG 2008]. Os elementos com o esteretipo <<spem>> possuem relao direta com o metamodelo. Adicionalmente, os demais elementos de processo foram inseridos para estender a semntica de representao do Modelo do Processo padro. o caso, por exemplo, dos elementos de processo Medio e Ferramenta.

Figura 3. Modelo do Processo Padro

No Quadro 2, apresenta-se uma breve descrio de alguns elementos do processo padro.

Quadro 2 Descrio dos elementos do Modelo do Processo Padro Elemento do Processo Infraestrutura Descrio Os processos necessitam de infraestrutura e ambiente de trabalho adequados. Podem incluir questes ergonmicas, estaes de trabalho, servidores e ambiente fsico. Todo processo, tarefa ou produto de trabalho pode ter medies associadas. Uma medio pode ser til para analisar o desempenho do processo em uma organizao e subsidiar um plano de melhoria que contemple o processo em questo. Tambm ser til para medir a qualidade de um produto de trabalho de entrada ou resultante de um processo. Uma medio contm informaes como: necessidade de informao, descrio, frmula. As tarefas dos processos de software podem ser apoiadas por ferramentas de software, que automatizam todo ou parte do processo. Papis so os responsveis pelas tarefas dos processos. Tais tarefas podem exigir que os ocupantes de um papel realizem treinamentos para desempenhar adequadamente a funo, desde que no se encaixem nos critrios de dispensa de treinamento. Aos papis so associadas habilidades necessrias para desempenhar a funo. As habilidades podem ser de ordem tcnica, gerencial, intrapessoal e interpessoal. Os produtos de trabalho esto sujeitos a um determinado nvel de controle ao longo de sua vida til, com o objetivo de manter sua integridade. Nveis de controle incluem: padres de versionamento de produtos, controle de mudanas, aprovaes necessrias, controle de linha de base, entre outros.

Medio

Ferramenta

Necessidade de Treinamento

Habilidade Nvel de Controle

A Figura 4 apresenta um exemplo de um processo padro e seus elementos para Desenho de Software, em conformidade com a rea de processo Technical Solution (TS) do modelo de referncia CMMI-DEV [SEI 2006].

Figura 4. Processo Padro Desenho de Software

Na Figura 5 apresenta-se o detalhamento da atividade Projetar Componentes de Software.

Figura 5. Atividade Projetar Componentes de Software

O diagrama da atividade Projetar Componentes de Software apresenta o fluxo de tarefas, os produtos de trabalho de entrada e sada de cada tarefa, um guia de projeto de software e o papel responsvel pelas tarefas. A especificao de cada elemento deste modelo deve estar em conformidade com as prticas da rea de Processo TS do CMMIDEV [SEI 2006], mas no indica modelos de documentos ou artefatos, uma vez que o processo mais tarde pode ser instanciado com uso de tcnicas variadas, como por exemplo, Projeto Orientado a Objetos ou Diagramas de Fluxo de Dados. No Quadro 3 apresenta-se a especificao da Tarefa Projetar Componentes.
Quadro 3 Detalhamento da tarefa Projetar Componentes Atributos Propsito: Descrio: Descrio Especificar os elementos de projeto (design), fazendo uso de mtodos que englobam tcnicas e ferramentas, a partir dos requisitos detalhados do software. A tarefa consiste em: analisar o comportamento dos subsistemas / componentes identificados por meio dos requisitos de software, identificar responsabilidades, atributos e associaes entre as entidades dos componentes / subsistemas e detalhar a interao entre as entidades do componente / subsistema. Gerar o modelo esttico e modelo dinmico do software. O principal produto de trabalho gerado na atividade o Projeto de Componentes, um modelo que descreve a realizao dos requisitos funcionais e serve como uma abstrao do modelo de implementao e seu cdigo-fonte. O projeto de componentes usado como base para atividades de implementao e teste. O projeto de componentes deve conter, no mnimo: a) Modelagem dinmica (seqncia de operaes)

Atributos

Passos:

Papis: Entradas: Sadas: Conhecimento:

Habilidades:

Treinamentos necessrios:

Descrio b) - Modelagem esttica (dados e estados) c) - Relacionamentos entre os elementos de projeto 1. Analisar funcionalidades do software 2. Identificar entidades e responsabilidades 3. Projetar modelo esttico 4. Projetar modelo dinmico 5. Validar modelos Projetista Especificao de Requisitos de Software, Arquitetura de Software Subsistemas e componentes, Interfaces internas e externas, projeto (design) de componentes, testes unitrios. a) Guia de Projeto (Design). b) Material de estudo sobre Anlise e Projeto Orientado a Objetos com uso de UML. a) Tcnicas de modelagem esttica e dinmica. Ex: UML, DFD, SADT, IDEF0. b) Conhecimentos em requisitos de sistema e software c) Tecnologias e linguagens de programao. Ex: (JEE, dotNET, C, C++, COBOL, NATURAL, SGBD, Webservices, XML, Web) d) Tcnicas de componentizao de sistemas. a) Anlise e Projeto de Software com UML. b) Componentizao de software.

Conforme classifica Fiorini (2001), uma instncia de processo um processo usual, no sendo um padro normativo e tampouco um pattern, pois no precisa necessariamente ter sido testado em um considervel nmero de vezes para garantir a soluo de um problema recorrente. Na arquitetura proposta, uma instncia do processo resultado da especializao do processo padro e incluem detalhes suficientes para execuo em um ambiente real. O processo padro pode ser instanciado para cada projeto, sendo que novos elementos especficos de processo podem ser includos quando necessrio. Um processo especfico pode possuir dependncia com outras instncias de processos, tais como SCRUM [Schwaber e Sutherland 2010], XP Wells 2011], OPENUP [Eclipse Foundation 2010] ou algum outro especfico da organizao. A prxima seo apresenta um exemplo de reutilizao do modelo de processo padro.

4.Exemplo de Processos em Uso

Para a definio do processo em uso, alm dos treinamentos no processo padro e sua arquitetura, tambm foram realizados treinamentos na ferramenta EPF e os mecanismos disponveis para facilitar a reutilizao de processo (tipos de variabilidade). Os treinamentos nesta etapa referem-se fase Desenvolver treinamento para o processo reutilizvel do ciclo de vida de Hollenbach e Frakes. A fase seguinte Adaptar o processo reutilizvel ao projeto ocorreu com a implementao do Processo em Uso. Para implementar esse componente da Arquitetura de Processos, foi utilizada a ferramenta Eclipse Process Framework1 (EPF). O EPF uma ferramenta livre, desenvolvida com a mesma aparncia do Eclipse, mas com a

Ferramenta disponvel em http://www eclipse.org/epf/downloads/tool/tool_downloads.php

funo de criao, gerenciamento da biblioteca de componentes, configurao, manuteno e publicao de processos e mtodos e aderente ao meta-modelo SPEM. Trabalha com uma terminologia comum, o Unified Method Architecture (UMA), que permite que mtodos ou prticas sejam reaproveitados em processos diferentes, possui ainda mecanismos de extenso para adaptar prticas em contextos variados, o que possibilita uma maior flexibilizao dos modelos disponveis. O framework conta com vrios exemplos de processos prontos que podem ser adaptados como o OPENUP, que uma verso bsica do Rational Unifield Process (RUP), o eXtreme Programming (XP) e o Scrum, que descrevem prticas de desenvolvimento gil. Ainda possui ferramentas que do suporte a vrios tipos de formas de desenvolvimento.

4.1.Game Process Development

O desenvolvimento de um jogo eletrnico uma tarefa de grande desafio e dificuldade, assim como a de desenvolvimento de um software. Desenvolver jogos pode ser encarado, a principio, como desenvolver softwares [Bethke, 2003; Gershenfeld et al., 2003]. A cada avano no mercado de jogos a complexidade em cri-los aumenta de maneira significativa devido a novas tecnologias e a necessidade de equipes maiores. Devido ao fato da indstria de jogos envolver atividades multidisciplinares, profissionais com perfis totalmente diferentes (artistas, programadores e produtores) somam criatividade ao ambiente. Porm, uma verdadeira ciso pode ocorrer na equipe, sendo ela dividida entre programadores e artistas [Callele et al, 2005), sem que os mtodos clssicos de desenvolvimento de software prevejam como lidar com essa situao de desencontro entre os grupos. Com o aumento de complexidade, fatores como a multidisciplinaridade dos profissionais presentes no desenvolvimento interagindo com um processo tradicional de software, problemas como a definio de escopos irreais com acrscimo ou retirada de funcionalidades ao longo dos projetos, os problemas recorrentes na indstria de jogos [Petrillo 2007] e as dificuldades no levantamento de requisitos trazem a tona a necessidade da criao de um processo especfico para a rea de desenvolvimento de jogos [Callele et al., 2005]. No entanto, o mais comum a falta de um processo, tambm chamado de codeand-fix. Essa tcnica envolve pouco ou nenhum planejamento e os problemas so resolvidos a medida que eles aparecem. As conseqncias da ausncia de um processo so a baixa qualidade e a no confiana do jogo final. Percebe-se que os problemas recorrentes de qualidade pela falta de um processo definido e institucionalizado so potencializados no caso de desenvolvimento de jogos eletrnicos. A multidisciplinaridade envolvida, embora proporcione grande criatividade para elaborao do jogo, incorre no esquecimento de boas prticas bsicas em desenvolvimento de software. Nesse sentido, o modelo de processo padro pode fornecer uma base de conhecimento importante para os desenvolvedores de jogos, permitindo a criao do prprio processo de desenvolvimento de jogos a partir de um processo convencional. Obviamente, o conhecimento embutido no processo padro ser reutilizado, pois o jogo eletrnico um software, porm com algumas particularidades.

A Figura 6 apresenta um exemplo de reutilizao da atividade Projetar Componente de Software (Figura 5) e tambm exemplifica a implementao da 3. etapa (Adaptar o processo reutilizvel ao projeto) do ciclo de vida de Hollenbach e Frakes.

Figura 6. Atividade Projetar Componentes de Software

A Figura 6 apresenta algumas tarefas, produtos e papis que foram estendidos ou substitudos a partir do Processo Padro. A Tarefa Identificar Elementos do Jogo, por exemplo, estende a tarefa Identificar Subsistemas e Componentes. Por sua vez, o produto Elementos do Jogo substitui o produto padro Subsistemas e Componentes. A Tarefa Projetar Componentes do Processo Padro estendida pela Tarefa Projetar Jogo, no processo de desenvolvimento de Jogos. Isso ocorre, pois alm do projeto de software comum definido no Processo Padro, o projeto de jogos deve incluir as especificaes das caractersticas do jogo, os elementos do jogo, o fluxo do jogo e a histria do jogo. O principal produto de trabalho gerado pela tarefa passou a ser o Game Designer Document (GDD), que inclui o contedo do projeto de componentes de software do processo padro alm das particularidades do projeto de um jogo eletrnico. Encontra-se em fase de planejamento as fases Adaptar o treinamento do processo reutilizvel para o processo adaptado ao projeto e Executar o processo no projeto. O processo ser executado por estudantes da Universidade de Braslia que

trabalham em projetos de desenvolvimento de jogos eletrnicos, por meio de um estudo de caso. Aps essa fase, ser realizado o refinamento do processo de acordo com as necessidades identificadas.

5. Concluses
Neste artigo foi apresentada uma proposta de modelo de processo padro baseada em uma arquitetura de componentes de processo, adotando o ciclo de vida para definio de processos reutilizveis. A partir do processo padro foi gerado um processo em uso para o contexto de desenvolvimento de jogos eletrnicos. Foram utilizados os conceitos de reutilizao e os tipos de variabilidade de processo por meio das funcionalidades da ferramenta Eclipse Process Framework, que implementa os conceitos do meta-modelo SPEM (Software and Systems Process Engineering Meta-Model Specification). A reutilizao do processo de software padro para a definio do processo de jogos forneceu uma base de conhecimento relevante para os desenvolvedores de jogos, uma vez que apesar das suas particularidades no processo de desenvolvimento, desenvolver jogos eletrnicos desenvolver software. A proposta do Processo em Uso para desenvolvimento de jogos encontra-se em fase de validao e planejamento para uso em projetos reais de desenvolvimento de jogos. Encontra-se tambm em andamento a definio de um novo Processo em Uso abordando metodologias geis de desenvolvimento de software e o modelo de referncia MR-MPS [SOFTEX 2009].

Referncias
Aleixo, F. A.; Freire, M. A.; Santos, W. C.; Kulesza, U. "An Approach to Manage and Customize Variability in Software Processes," SBES, pp.118-127, 2010 Brazilian Symposium on Software Engineering, 2010 Barreto, A., Murta, L., Rocha, A.R., 2008, "Software Process Definition: a Reuse-based Approach". In: XXXIV Conferencia Latinoamericana de Informtica (CLEI'08), Santa Fe, Argentina, Setembro de 2008. Barreto, A.; Murta, L.; Rocha, A. R. Componentizando processos legados de software visando a reutilizao de processos. In: Simpsio Brasileiro de Qualidade de Software 2009. [S.l.: s.n.], 2009. Barreto, A.; Murta, L.; Rocha, A. R. Uma abordagem de definio de processo de software baseada em reutilizao. In: Workshop Anual de Melhoria de Processo de Software 2007. Bayer, J. et al PuLSE: A methodology to develop software product lines. In: Symposium on Software Reusability (SSR). Los Angeles, USA: ACM Press, 199. p. 122-131. Bethke, E. Game Development and Production. Plano: Wordware Publishing, 2003. Borsoi, B. T. Arquitetura de processo aplicada na integrao de fbricas de software, So Paulo, 2008, p. 37-61.

Brown, A. W.; Short, K. On components and objects: The foundations of componentbased development. International Symposium on Assessment of Software Tools, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 0112, 1997. Callele, D.; Neufeld, E.; Sschneider, K. Requirements engineering and the creative process in the video game industry. In: 13th IEEE International Conference on Requirements Engineering. Proceedings... Washington, DC, USA: IEEE Computer Society, 2005. p. 240252. Eclipse Foundation. OPENUP, 2010. http://epf.eclipse.org/wikis/openup/>, Janeiro. Fiorini, S. T. Arquitetura para reutilizao de processos de software. Tese (Doutorado) PUC-RJ, Rio de Janeiro, 2001. Fuggetta, A. Software process: a roadmap. In: ICSE '00: Proceedings of the Conference on The Future of Software Engineering. New York, NY, USA: ACM, 2000.p. 25-34. Gershenfeld, A.; Loparco, M.; Barajas, C. Game Plan: the insiders guide to breaking in and succeeding in the computer and vieo game business. New York: St. Martin s Griffin Press, 2003. Hollenbach, C., Frakes, W.: Software Process Reuse in an Industrial Setting, Fourth International Conference on Software Reuse, Orlando, Florida, IEEE Computer Society Press, Los Alamitos, CA, pp 22-30, 1996. K. Schwaber e J. Sutherland. Scrum Guide, 2010. Kammer, P. J. Supporting dynamic distributed work processes with a component and event based approach. In: 22nd International Conference on Software Engineering (IEEE-CS), 2000, ACM Press, p. 710-712. Kruchten, P.; Obbink, H.; Stafford, J. The past, present, and future of software architecture, IEEE Software, v. 23, n. 2, p. 22-30, 2006. L. Bass, P. Clements, R Kazman. Software Architecture in Practice, Second Edition. Addison-Wesley, 2003. Lanna, A. L. P. M. Reso de Processos de Software baseado na componentizao de Processos e Conhecimento. Dissertao de Mestrado. Dezembro, 2009. Larman, C. Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and the Unified Process. USA. 2002. OMG. Software & Systems Process Engineering Meta-Model Specification. [S.l.], Abril 2008. Oquendo, F. Formally modelling software architectures with the UML 2.0 profile for ADL. ACM SIGSOFT Software Engineering Notes, v. 31, n. 1, p. 1-13, jan. 2006 Petrillo, F. S. P., Prticas Agis no Processo de Desenvolvimento de Jogos Eletrnicos. Dissertao de Mestrado. 2008. SEI, Software Engineering Institute, CMMI for Development. http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm, Janeiro. 2006,

SOFTEX, Associao para Promoo da Excelncia do Software Brasileiro, MPS.BR Guia Geral. 2009, http://www.softex.br, Maro.

Sommerville, I. Engenharia de Software. 8. ed. So Paulo: Pearson Addison-Wesley, 2007. Succi, G., Benedicenti, L., Predonzani, P., Vernazza, T. Standardizing the Reuse of Software Process. In StandardView - Special issue on reuse standards and software. ACM. Volume 5, Issue 2. Pages 74-83. 1997. Wells, D. Extreme Programming: A http://www.extremeprogramming.org/, Maro. gentle introduction, 2011.