Componentes de Processo

Há diversas definições para componentes de software. Segundo KRUCHTEN (2001), um componente é visto como parte não trivial, independente e substituível de sistemas. Componentes, que são partes reutilizáveis de software (D'SOUZA e WILLS, 1998), fazem uso de interfaces descritas de forma contratual para interagir com os demais elementos de software (PAGE-JONES, 1999; SZYPERSKI, 2002) apud (MURTA, 2006). De maneira mais geral, MURTA (2006) considera componentes, no contexto do desenvolvimento baseado em componentes, como elementos fundamentais, que servem como unidade de encapsulamento com interfaces bem definidas e podem ser reutilizados ou substituídos, alavancando a produtividade e a qualidade.

De forma semelhante, um componente de processo pode ser visto como um encapsulamento de informações e comportamentos de processo em um dado nível de granularidade (GARY e LINDQUIST, 1999). Assim, um processo pode ser tratado como a integração de um conjunto de componentes de processo em diferentes níveis de granularidade (FUSARO et al., 1998).

Componentes de processo reutilizáveis podem fornecer apoio eficiente aos engenheiros de processo e membros de projetos na construção de modelos de processo e na realização de ajustes dinâmicos no processo, o que contribui para a melhoria e controle do processo (XU et al., 2005).

Os componentes de processo são descritos e estruturados de diferentes formas por diferentes autores, não existindo um consenso sobre quais informações devem estar contidas em um componente nem sobre o nível de detalhe a ser utilizado, ficando essas informações dependentes do uso pretendido para os componentes por cada abordagem. Até mesmo a nomenclatura varia entre abordagens.

FUSARO et al. (1998), ao apresentar a abordagem REP (ChaRacterizing and Exploiting Process Components), consideram que um componente de processo pode representar: (i) uma técnica, isto é, um algoritmo ou série de passos cuja execução

requer algum conhecimento e habilidade e que produz um determinado efeito; (ii) um método, isto é, um procedimento particular para aplicar uma técnica, organizado como um conjunto de regras que avaliam, selecionam e estabelecem como e quando usar e parar de aplicar as técnicas relacionadas (critérios de entrada e saída); ou (iii) um processo, isto é, um conjunto de métodos e inter-relacionamentos necessários para atingir um objetivo específico. Mais tarde, TORTORELLA e VISAGGIO (2001) voltam a mencionar a abordagem REP, acrescentando mais uma possibilidade de representação. Um componente de processo poderia representar, também, algo mais simples que uma técnica: um guia, que seria um conjunto simples de regras. Além disso, apresentam uma abordagem que utiliza métodos formais para substituir componentes de processo em um processo existente, de modo a realizar uma espécie de inovação no processo para sua melhoria.

GARY et al. (1998), e posteriormente GARY e LINDQUIST (1999), apresentam o OPC (Open Process Framework), um framework baseado em componentes para a modelagem de processos de software. Segundo essa abordagem, a informação de processo contida em um componente pode ser expressa em qualquer formalismo ou linguagem para representar a semântica do componente. Os autores separam essas informações de três formas: esquema de processo, estados e transições de processo, e implementação do processo, conforme ilustrado na Figura 3.1. O esquema do processo define um vocabulário para o componente, identificando entidades e relacionamentos que têm significado para o componente específico. Os estados e transições de processo são representados por uma máquina de estados finitos. O conjunto de estados e transições entre estados possíveis é definido para cada componente. A implementação do processo é a representação base do componente e do ferramental que interpreta essa representação. Pode ser uma rede de Petri, uma linguagem de programação de processos ou qualquer outro meio utilizado para representar a semântica do processo. Pode, também, ser uma ferramenta de processo encapsulada para fornecer a implementação do processo. A implementação de um componente é incluída no componente, de forma que componentes possam interagir sem a necessidade de homogeneidade de representações.

Figura 3.1 – Componente de Processo segundo (GARY e LINDQUIST, 1999)

Outra estrutura foi proposta por XU et al. (2005), em seu Framework de Representação de Componentes de Processo Orientado à Reutilização. Nesse framework, uma descrição de componente de processo deve ser composta de três partes, conforme ilustrado na Figura 3.2: informações de descrição geral, descrição da especificação e descrição de dados.

Figura 3.2 – Framework de Representação de Componentes de Processo Orientado à Reutilização (XU et al., 2005)

As informações de descrição geral são orientadas aos usuários do componente de processo e são usadas para a classificação dos componentes. Basicamente descrevem os objetivos e alguma informação específica do componente, incluindo funções, domínios

de aplicação, classificações, padrões de representação, contextos de uso do componente, entre outros. A linguagem de representação pode ser linguagem natural ou alguma linguagem semiformalizada que seja familiar aos usuários. A descrição da especificação é orientada ao engenheiro de processo e é usada para criar, dirigir e apoiar processos de software em ambiente de execução e descreve, para cada componente de processo, as atividades e inter-relacionamentos, artefatos e produtos do processo, agentes, recursos, pré e pós-condições, entre outros. Podem ser usadas linguagens informais, semiformais ou até mesmo formais como forma de representação. A descrição de dados é principalmente orientada a gerentes e engenheiros de processos. Essa descrição é utilizada para avaliar, gerenciar, controlar e melhorar o processo de software, envolvendo dados de medições da execução dos componentes. Para cada componente específico, normalmente inclui informações sobre o tempo de início e de fim, esforço e sua distribuição, recursos como número de membros da equipe envolvidos, custos, riscos do processo, defeitos no processo, tamanho do projeto e contexto. A descrição de dados dos componentes pode ser representada através de gráficos, figuras e outros formatos. Na abordagem de XU et al. (2005) , para se construir o processo definido para um projeto, deve-se primeiro procurar componentes de processo na biblioteca de componentes. Se for possível encontrar o componente que se procura, pode-se usá-lo diretamente. Se não há o componente procurado, pode-se procurar um que se aproxime do que se deseja, modificá-lo e instanciá-lo, e usá-lo como um componente especializado. Se não há componente similar ao esperado, pode-se criar um novo componente.

Para o SPEM – Software & Systems Process Engineering Meta-Model, um componente de processo era considerado, na versão anterior do modelo (OMG, 2005), um agrupamento de descrições de processo (elementos de processo) internamente consistente e que podia ser reutilizado com outros componentes de processo para compor um processo completo. Deveria ser autocontido, ou seja, não deveria haver referências de dentro de um componente para elementos fora do componente. Com essa definição abrangente, a estrutura de um componente de processo poderia ser bastante variável, podendo possuir diferentes tipos de elementos de processos (atividade, fases, guias, produtos de trabalho, etc) e combinações entre eles. Em sua versão atual, o SPEM (OMG, 2008) define componente de processo como um pacote de processos especial que aplica princípios de encapsulamento. Segundo o modelo, um componente de

conjunto de portas de produtos de trabalho que define as entradas e saídas de um componente. Podem existir vários componentes definindo as mesmas portas de produtos de trabalho (mesmas entradas e saídas), mas usando diferentes técnicas para atingir resultados similares para entradas similares. Enquanto uma porta de produto de trabalho representa a especificação do componente (visão de caixa preta do componente), bons candidatos para a realização dos componentes podem ser encontrados em padrões de processo, um tipo de processo para fornecer uma visão de caixa branca do componente (OMG, 2008).

KOUDRI e CHAMPEAU (2010) descrevem o MODAL (Model Oriented Development Application Language) uma extensão ao SPEM para incluir ou reforçar alguns conceitos, como intenção (a razão para o processo, espécie de requisitos), estratégia (uma estratégia para atingir as intenções, um exemplo seria um ciclo de vida), restrições (para garantir a consistência), e componentes de processo. Os autores estendem a definição do SPEM para componentes de processo, definindo-os como uma entidade concorrente que se comunica através de conectores que implementam serviços de alto nível e que é basicamente caracterizado por suas partes pública e privada. A parte pública expõe todos os serviços que oferece para seu exterior, enquanto sua parte privada trata da realização desses serviços. Mais precisamente, sua parte privada encapsula a definição de atividades (humanas ou não) em diferentes níveis de abstração, linguagens e ferramentas relacionadas, assim como componentes de processos internos necessários para realizar os serviços publicados.

HONGWEI et al. (2008) descrevem os EPCs (Evolution Process Components) que são fragmentos de processos em evolução (segundo os autores, conjunto de processos inter-relacionados sob os quais o software correspondente está evoluindo) altamente coesos e consistentes. Os componentes possuem diversas informações descritivas associadas para caracterizá-los, tais como: nome, fornecedor, versão, função no processo, tipo de processo, ambiente do processo, etc. Os EPCs também possuem um "corpo" que descreve os fragmentos de processo. A definição de um EPC é apresentada como uma tupla com várias informações (atividades, condições, entradas, etc).

FADILA e MOHAMED (2009) descrevem componentes de processo como em outras abordagens, ou seja, como um fragmento de modelo de processo que pode ser usado independentemente do modelo de processo original. A estrutura dos componentes, segundo os autores, é composta por: (i) Critérios básicos: tipo de processo de software, objetivo, produtos de entrada, produtos de saída; (ii) Critérios de

classificação: Linguagem de modelagem de processo, as entidades do metamodelo que o compõem, desempenhos atingidos, idade do componente, fonte do componente (quem definiu), plataformas de execução, recursos humanos, de hardware e de software, fluxo de controle; (iii) Atributos qualitativos: permitem descrever a qualidade do componente. SEGRINI (2009) apresenta uma abordagem de definição de processo baseada em componentes. Fazendo um paralelo com o Desenvolvimento Baseado em Componentes (DBC), o autor apresenta um processo de Definição de Processos Baseado em Componentes (DPBC). Nessa abordagem, componentes de processo podem ser definidos em três diferentes níveis de granularidade (processos complexos, processos simples e macroatividades), devem ser definidos considerando-se os níveis de abstração de processo (processos padrão, processos padrão especializados e processos de projeto), devem possuir interfaces que os descrevam, possibilitando a reutilização e devem ser armazenados em repositórios, de onde possam ser buscados visando à reutilização. O autor também apresenta o DPBC para cada nível de abstração de processo e apresenta a ferramenta ProcODE-Com, que apoia a abordagem.

LANNA (2009) também apresenta uma abordagem de reutilização de processos de software com base em componentização e conhecimento. O autor define um componente de processo de software como: (i) uma unidade de composição com interfaces e dependências de contexto bem definidas; (ii) uma unidade capaz de representar um processo de software ou partes dele, em seus três aspectos (técnico, organizacional e humano), seja qual for o nível de abstração que ele represente (subprocesso, atividade ou tarefa); e (iii) uma unidade capaz de armazenar o conhecimento agregado ao processo representado pelo próprio componente. O autor apresenta brevemente como seria a definição de processos para reutilização e com reutilização. Também é apresentado apoio ferramental que apoia apenas parte da abordagem descrita.

Processos de software completos podem ser decompostos em subprocessos. Uma vez que componentes de processo são decomposições de um processo de software inteiro, os componentes podem ser considerados subprocessos que podem ser utilizados para compor um processo completo. Assim, componentes de processo podem ser utilizados para representar subprocessos conforme definido em modelos como o CMMI- DEV (SEI, 2010) e o MPS.BR (SOFTEX, 2011). Muitas vezes, também, utiliza-se o termo “elemento de processo” com um significado muito parecido ao de componente de

a unidade fundamental (ou seja, atômica) de definição de processos e descreve as atividades e tarefas necessárias para realizar o trabalho de forma consistente.

Apesar de o uso de componentes para composição de processos aparentar fornecer muitas vantagens, partir de unidades tão pequenas para compor grandes processos pode ser ainda insuficiente. Caso se analise a reutilização no contexto de produtos de software, é possível observar que uma das lições aprendidas com os esforços para se alcançar a reutilização nas últimas décadas foi a de que a reutilização bottom-up, ou seja, a composição de componentes arbitrários para construir sistemas, não funciona bem na prática. Programas de reutilização bem sucedidos empregam, também, uma abordagem top-down, ou seja, componentes são desenvolvidos de forma a se encaixarem em uma estrutura de alto nível definida por uma arquitetura de software (BOSCH, 2000). Assim, combinar as duas abordagens tende a ser mais adequado, ou seja, iniciar a partir de um nível mais alto (top-down) e, ao longo da composição, considerar também componentes individuais (bottom-up).

É de se esperar que para a definição de processos, apesar de os componentes de processo serem fundamentais, uma abordagem de definição que se inicie top-down facilite e potencialize a definição de processos. Ou seja, componentes de processo seriam encaixados em estruturas reutilizáveis maiores, tais como frameworks para modelos de ciclos de vida, ou templates de processos de um determinado nível de maturidade. Essas estruturas reutilizáveis maiores poderiam ser usadas tanto para compor um componente de mais alto nível (ex.: macroatividades) quanto para compor estruturas maiores do processo (ex.: subprocessos, fases de processos).