CAPÍTULO 3 – Reutilização de Processos de Software
3.3 Modelagem e Reutilização de Processos de Software
Ainda no contexto da reutilização de processos de software, muitos trabalhos utilizam o termo "modelagem de processos de software" com significado na maioria das vezes semelhante à "definição de processos de software", mas normalmente com um enfoque mais formal para a definição de processos.
CURTIS et al. (1992) afirmam que um modelo é uma representação abstrata da realidade que exclui muitos dos infinitos detalhes do mundo real e que o propósito de um modelo é reduzir a complexidade para entender ou interagir com um fenômeno através da eliminação de detalhes que não influenciam seu comportamento relevante. Portanto, um modelo exibe o que seu criador acredita ser importante para entender ou predizer o fenômeno modelado. A seleção de limites para o fenômeno a ser modelado depende das utilizações que serão feitas do modelo.
Considerando o contexto de processos, um modelo de processo é uma descrição abstrata de um processo real ou proposto que representa elementos de processo selecionados que são considerados importantes para o propósito do modelo e que podem ser executados por um humano ou uma máquina (CURTIS et al., 1992).
Mais especificamente no contexto de processos de software, modelos de processo de software são estruturas complexas utilizadas para descrever formalmente os passos realizados durante o desenvolvimento de software (REIS, 2002). O desenvolvimento de software é um foco desafiador para a modelagem de processos por causa da criatividade envolvida na resolução de problemas em etapas como a análise de requisitos e projeto, ou a coordenação de interações entre equipes ao longo do desenvolvimento de um artefato complexo (CURTIS et al., 1992). Modelos de processos de software são usados
para avaliar e melhorar as práticas de trabalho, e para apoiar a execução do trabalho em projetos de software (JØRGENSEN, 2000).
Atualmente, a definição de um modelo de processo é baseada principalmente no conhecimento do projetista de processo sobre a organização, contextos e projetos anteriores, ficando ele responsável por descrever um modelo completo para representar a melhor forma de se desenvolver software em um domínio e contexto específico. Desde a proposta de OSTERWEIL (1987) para estimular o uso de formalismos de software para descrever processos de software, existe um considerável esforço para adaptar a tecnologia disponível de reutilização de software tradicional para o contexto de reutilização de processos de software (REIS, 2002).
Um modelo de processo de software é uma descrição formal do processo de software. Vários tipos de dados são integrados em um modelo de processo para indicar quem, quando, onde, como e por que os passos são realizados (LONCHAMP, 1993). Para representar um modelo de processo de software é frequentemente adotada uma Linguagem de Modelagem de Processos (Process Modelling Language - PML), a qual deve oferecer recursos para descrever e manipular os passos do processo (REIS, 2002).
A literatura especializada distingue três tipos principais de modelos de processo (FEILER e HUMPHREY, 1992; DERNIAME et al., 1999; FRANCH e RIBÓ, 2002; REIS, 2002):
• Modelos Abstratos (também denominados patterns ou templates), que fornecem moldes de solução para um problema comum, em um nível de detalhe que idealmente não está relacionado a uma organização específica. Um processo abstrato é um modelo de alto nível que é projetado para regular a funcionalidade e interações entre cargos de desenvolvedores, gerentes, usuários e ferramentas;
• Modelos Instanciados (ou executáveis) são modelos prontos para execução, podendo ser submetidos à execução por uma máquina de processo. O modelo instanciado é considerado uma instância de um modelo abstrato, com objetivos e restrições específicos, envolvendo agentes, prazos, orçamentos, recursos e um processo de desenvolvimento (o encadeamento de atividades necessárias para atingir o objetivo);
• Modelos em Execução ou Executados registram o histórico da execução de um processo, incluindo os eventos e desvios (modificações realizadas no modelo relacionado).
A Figura 3.4 representa o ciclo de vida de processos de software simplificado e orientado de acordo com a ótica da reutilização dos modelos proposta por JØRGENSEN (2000), apud COSTA et al. (2007).
Modelagem de Processos Visando a Reutilização Execução de Processos Recuperação e Adaptação de Processos Generalização e Avaliação de Processos Encerrados Processos Genéricos Processos Específicos
Figura 3.4 – Cenário geral para reutilização de processos de software – adaptado de (JØRGENSEN, 2000) apud COSTA et al. (2007)
Na Figura 3.4, as setas são etapas, enquanto que os vértices, rotulados em itálico, são estados. Sendo assim, a etapa “Modelagem de Processos Visando a Reutilização” tem como objetivo definir, através de uma linguagem, os modelos de processos bem como componentes genéricos e abstratos que possam ser reutilizados em diferentes contextos. A etapa “Recuperação e Adaptação de Processos” prevê critérios, estratégias e mecanismos para auxiliar um projetista na seleção, adaptação e instanciação de processos genéricos que se tornem soluções para os problemas vigentes. A etapa “Execução de Processos” descreve todas as ocorrências de um modelo de processo desde o início de sua execução, incluindo as modificações referentes à evolução do processo. Por fim, a “Generalização e Avaliação de Processos
Encerrados” extrai informações a partir da experiência adquirida com processos bem
sucedidos para alimentar o repositório de modelos de processos reutilizáveis (COSTA et al., 2007). Ainda no contexto da reutilização de processos, REIS (2002) define um conjunto de requisitos para automação da reutilização de processos de software, conforme ilustrado na Tabela 3.1.
Uma das principais questões envolvidas na modelagem de processos de software é o nível de formalidade matemática necessária nas linguagens de modelagem de processos. Uma linguagem precisa e formal é executável por uma máquina. O nível de formalidade requerida pode depender do propósito esperado para o modelo de processo e do agente
responsável por executar o processo especificado. Ou seja, programas de processos descritos em código fonte (process program) e executados por uma máquina precisam ser muito formais, enquanto descrições de processo mais simples (process scripts) executados por humanos podem necessitar de menos formalidade (CURTIS et al., 1992). Apesar de autores como OSTERWEIL (1987) e muitos outros defenderem a programação de processos, comparando com a programação de um produto de software, outros como CURTIS et al. (1992) mantêm a opinião de que a programação de computadores é muito determinística para ser executada por humanos.
Tabela 3.1 – Requisitos para apoiar a reutilização de processos em ambientes automatizados (PSEE’s) e linguagens de modelagem (PML’s) (REIS, 2002)
Humanos exibem muito mais variabilidade que computadores na execução de um processo definido. No entanto, pessoas são capazes de executar descrições de processo ambíguas, pois podem preencher as lacunas nessas descrições antes de executá-las. Expressividade e inteligibilidade são mais importantes para humanos, uma vez que exibem menos precisão na análise de instruções de processo. A experiência mostra que mesmo aqueles usando linguagens de especificação formal normalmente transformam suas especificações para uma versão em linguagem natural, que é mais fácil de entender. Infelizmente, a facilidade de entendimento e a comunicação humana receberam menos atenção da comunidade de pesquisa do que a execução por máquinas. Modelos de processos e definições não podem ser usadas se não puderem ser entendidos (CURTIS et al., 1992).
exemplo, atividades, produtos (artefatos), recursos (pessoal e ferramentas) e papéis, podem ser modelados (HUFF, 1996). Existem várias classificações referentes aos principais elementos de um modelo de processos (FEILER e HUMPHREY, 1992; LONCHAMP, 1993; CONRADI et al., 1994). Os elementos mais comumente modelados são apresentados a seguir (BENALI e DERNIAME, 1992; FINKELSTEIN et al., 1994; MCCHESNEY, 1995; FUGGETTA e WOLF, 1996). A Figura 3.5 mostra esses relacionamentos e seus inter-relacionamentos (ACUÑA et al., 2000).
• Agente ou ator: entidade que executa um processo.
• Papel: descreve um conjunto de agentes ou agrupa responsabilidades, direitos e
capacidades necessárias para executar uma atividade específica de um processo. • Atividade: estágio de um processo que produz resultados visíveis externamente
no estado do produto de software. Pode possuir produtos de entrada, de saída e alguns intermediários, chamados genericamente de produtos. A atividade inclui e implementa procedimentos, regras, políticas e objetivos para gerar e modificar um conjunto de artefatos. Podem ser divididas em atividades mais elementares. Podem ser executadas por humanos ou por alguma ferramenta.
• Artefato ou Produto: é o (sub) produto e também a entrada de um processo. Um artefato produzido por um processo pode ser usado mais tarde como entrada para o mesmo ou para outro processo para produzir outros artefatos. Um conjunto de artefatos de software a serem entregues a um usuário normalmente é chamado produto de software.
Figura 3.5 – Componentes básicos de modelagem de processos (ACUÑA et al., 2000).
Para minimizar o problema da falta de uma padronização dos conceitos envolvidos em um modelo de processo, ontologias têm sido também utilizadas como formalismos para modelagem de processos. Uma ontologia define um vocabulário específico usado
para descrever certa realidade, mais um conjunto de decisões explícitas fixando o significado pretendido para o vocabulário. Uma ontologia envolve, então, um vocabulário de representação que captura conceitos, relações e propriedades em algum domínio e um conjunto de axiomas, estabelecendo restrições que têm de ser respeitadas (GUARINO, 1998).
Uma ontologia no contexto de processo de software permite que as ferramentas e os ambientes que apoiam a definição e execução dos processos, além dos usuários que os utilizam, compartilhem um entendimento comum sobre o que é um processo de software. FALBO (1998) define uma ontologia de processo de software. Dada a complexidade do domínio de processos de software, essa ontologia é dividida em subontologias de atividade, recurso e procedimento. Sua primeira versão foi desenvolvida por FALBO (1998), tendo sido objeto de evolução por FALBO e BERTOLO (2005), GUIZZARDI et al. (2008) e BRINGUENTE et al. (2011). VILLELA (2004) definiu uma ontologia de organização, com o propósito de fornecer um vocabulário comum que pudesse ser utilizado para representar conhecimento útil para os desenvolvedores de software sobre as organizações envolvidas em um projeto de software, tendo sido evoluída por BARCELLOS e FALBO (2009). A ontologia de organização de VILLELA (2004) incluía a ontologia de processos de software definida por FALBO (1998). SOUZA (2008) evolui a ontologia, acrescentando conceitos relacionados a corporações.
3.4
Considerações Finais
Este capítulo apresentou uma revisão da literatura sobre reutilização de processos de software. Foram apresentadas algumas abordagens de reutilização de processos de software baseadas em técnicas da reutilização de produtos de software tradicional, tais como componentes, arquiteturas, frameworks, templates, linhas e famílias de produtos e padrões.
A análise dos trabalhos apresentados neste capítulo indica que as técnicas de reutilização de produtos de software tradicionais realmente possuem grande potencial de serem aplicadas também no contexto de processos de software. No entanto, é possível perceber por meio da revisão da literatura realizada e da execução do estudo baseado em revisão sistemática (apresentado no Apêndice I) que, apesar de existirem muitas
sobre o tema ainda não está consolidado. Várias técnicas são mencionadas e não há um consenso sobre as características das técnicas utilizadas, uma vez que várias definições diferentes existem. Das publicações analisadas, um grande percentual não descreve apoio ferramental e a maioria não menciona a utilização de dados da execução para apoiar na definição dos processos. Além disso, mais da metade das publicações analisadas ou não mencionam qualquer avaliação da abordagem que propõem ou fornecem apenas exemplos. O contexto multiorganizacional é considerado em pouquíssimos trabalhos e a alta maturidade praticamente não é mencionada nas publicações analisadas.
Assim, conforme relatado em mais detalhes no Apêndice I desta tese, com base nas questões secundárias do estudo baseado em revisão sistemática realizado, é possível perceber que:
• Não há um consenso sobre as características das técnicas utilizadas, uma vez que várias definições diferentes existem para cada uma delas e muitas vezes ocorrem, inclusive, sobreposições. Componentes, linhas e padrões de processo são as abordagens mais citadas;
• Das publicações analisadas, um grande percentual não descreve apoio ferramental (53%) e a maioria não menciona a utilização de dados da execução para apoiar na definição dos processos (77%);
• Mais da metade das publicações analisadas (54%) não mencionam qualquer avaliação da abordagem que propõem ou fornecem apenas exemplos;
• O contexto multiorganizacional é considerado em pouquíssimos trabalhos (12%), indicando que as oportunidades de reutilização neste contexto ainda merecem melhor aproveitamento;
• A definição de processos em alta maturidade não é mencionada nas abordagens citadas, apesar de algumas características das abordagens analisadas poderem auxiliar no caminho para a alta maturidade. Por exemplo, o encapsulamento de fragmentos de processo (componentes de processo) pode auxiliar na definição de subprocessos a serem usados ao longo da definição, as abordagens de linhas ou famílias de processo podem auxiliar na seleção dos subprocessos que devem compor o processo de um projeto. Entretanto ainda há muita necessidade de apoio focando especificamente nesse contexto.
As considerações expostas parecem mostrar que ainda é necessário um amadurecimento maior do tema, e que são necessários mais trabalhos de forma a se criar massa crítica sobre o assunto. Boa parte dos trabalhos citados parece relatar apenas ideias, dado o grande número de propostas sem mencionar apoio ferramental e sem mencionar qualquer utilização.
Foi também abordada, neste capítulo, a questão da modelagem de processos de software e como através dessa modelagem a reutilização de processos pode ser alcançada. Foram citados os principais conceitos e problemas envolvidos. A análise desses trabalhos indica que a maioria das abordagens existentes utiliza um formalismo grande nos modelos de processos, o que pode dificultar seu entendimento e utilização. Enquanto há muitos estudos voltados a definir linguagens e mecanismos para automatizar processos, há menos trabalhos voltados a fornecer conhecimento sobre como realizar as definições de processos, independentemente da forma de representação, facilitando o entendimento e execução da atividade por pessoas.
No próximo capítulo, é apresentada a visão geral da abordagem de definição de processos de software baseada em reutilização proposta neste trabalho.
CAPÍTULO 4
– Uma Abordagem para Definição de Processos
de Software Baseada em Reutilização – Visão Geral e
Fundamentos
4.1
Introdução
Nos capítulos anteriores foram apresentadas abordagens existentes para a definição de processos de software e também para a reutilização de processos de software. É possível perceber nesses trabalhos que ainda há questões em aberto em relação à definição de processos de software com base em reutilização, tais como:
• Como definir processos utilizando técnicas de reutilização considerando os requisitos da definição de processos em alta maturidade?
• O que exatamente deve ser considerado um componente de processo, qual deve ser sua estrutura e que informações deve possuir? O mesmo vale para arquitetura de processos, linhas de processos, entre outros.
• Como medir componentes de processos, de forma a ser possível analisar sua capacidade e entender seu comportamento em diferentes situações?
• Como deve ser realizada a definição de itens reutilizáveis de processos1 para reutilização, considerando, inclusive, processos pré-existentes?
• Como deve ser realizada a definição de processos de software com reutilização? • Como deve ocorrer a reutilização de processos nos diferentes contextos
envolvidos, incluindo o contexto multiorganizacional (por exemplo, em uma instituição implementadora de processos, em uma organização ou em um projeto)?
• Como deve ser o apoio ferramental para apoiar a definição de processos de software por meio de técnicas de reutilização?
Apesar de alguns trabalhos focarem em questões listadas acima, na maioria das vezes, o foco é em aspectos específicos, sem muita evidência de utilização ou avaliação e com muito espaço para melhorias. Além disso, o contexto da alta maturidade não é abordado. Ainda, muitas abordagens têm uma preocupação muito grande com a
1
“Item reutilizável de processo” pode ser qualquer estrutura de processo que possa ser reutilizada, como
automatização e possível execução e simulação do processo, o que introduz um formalismo excessivo nas representações e nos métodos utilizados. Isso pode dificultar o uso dessas abordagens por organizações de software da indústria. Por fim, uma abordagem que integrasse os fatores listados anteriormente na definição de processos baseada em reutilização, principalmente considerando os aspectos da alta maturidade, não foi encontrada na literatura.
Este capítulo está estruturado em seis seções, incluindo esta introdução. A Seção 4.2 apresenta os requisitos para a abordagem proposta. A Seção 4.3 apresenta como os principais conceitos relacionados à reutilização e à definição de processos foram definidos, adaptados e utilizados nesta tese. A Seção 4.4 apresenta os cenários para utilização da abordagem proposta, considerando o contexto multiorganizacional. A Seção 4.5 apresenta uma pesquisa realizada com engenheiros de processo experientes para caracterizar suas expectativas relacionadas à aplicação de técnicas de reutilização na definição de processos, que foi um importante insumo para o desenvolvimento desta tese. Finalmente, a Seção 4.6 apresenta as considerações finais do capítulo.