Desafios associados à Composição de Processos de Software

#Introdução

A indústria de software no mundo é um mercado de grande volume financeiro. Considerando apenas os 10 maiores mercados de software do mundo, essa indústria movimenta quase 800 bilhões de reais por ano. No entanto, diversos estudos demonstram que boa parte desses recursos são de alguma forma desperdiçados ou subutilizados. Por exemplo, perdas são associadas a atrasos superiores a 50% de não atendimento, a 25% de projetos que são interrompidos, módulos de um mesmo sistema que não funcionam integrados entre si, funcionalidades inadequadas que não atendem às expectativas, e grande volume de retrabalho em projetos de software (Cerpa 2009). Existe portanto, uma necessidade de melhoria na qualidade e competitividade dos produtos e serviços prestados pelas empresas de software.

Uma das estratégias para atingir esses objetivos é através da Gestão e Melhoria dos Processos de Software (SPI - Software Process Improvement) (Sommerville 2004) (Dumas 2013) (Kelly 1999). As organizações investem na melhoria de seus processos de software com a expectativa de que isso resultará na melhoria da qualidade do software que esses processos produzem (Unterkalmsteiner 2012). E, de fato, diversos estudos demonstram que a melhoria dos modelos e padrões de processos de desenvolvimento de software (PDS) podem melhorar a qualidade do software e a produtividade da organização (Buttler 1995) (Yamamura 1999) (Pitterman 2000) (Gibson 2006) (Nasir 2008) (Hani 2009). Um programa SPI tem como base uma disciplina conhecida como Gerenciamento de Processos de Negócio (BPM). Normalmente a implantação eficaz da Gestão de Processo exige: (a) a formalização dos Processos de Software em uma Linguagem de Modelagem de Processos de Software (LMPS) e (b) a gestão dos Processos apoiada por um Sistema para Gestão de Processos (BPMS) (Kelly 1999).

No entanto, existe uma dificuldade por parte das organizações em implantar e manter a gestão de seus processos (Santos 2010) (Colenci 2011) (TCU 2010) (TCU 2012). Parte dessa dificuldade está relacionada à complexidade dos Processos de Software. Uma consequência negativa das iniciativas de melhoria de processo é que eles tendem a aumentar a complexidade dos Processos de Software. Ou seja, os PDSs costumam tornar-se cada vez mais complexos: maior números de atividades, maior quantidade de ligações entre as atividades, maior número de tomadas de decisões, interações mais complexas entre sistemas e pessoas, etc (Istoan 2012). Nesse contexto, técnicas de Reutilização de Processos - como Adaptação e Composição de Processos - podem ser utilizadas para minimizar os problemas relacionados a manter processos complexos (Rong 2014) (Rong 2014).

Apesar disso, a Reutilização de Processos ainda é bastante difícil de ser implantada na indústria de software (Koschmider 2014). Os autores apresentam um estudo detalhado de como a indústria e a acadêmia estão tratando a Reutilização de Processos de Software. Sob o ponto de vista acadêmico, apesar de o tema de Reutilização ser bastante discutido, existem poucas contribuições sobre Reutilização de Processos de Software quando comparado ao volume de produções acadêmicas sobre Reutilização de Software. Já sob a perspectiva da indústria, a principal reclamação está relacionada a falta de recursos das ferramentas e notações para executar operações necessárias para a Reutilização de Processos. As operações relacionadas à Reutilização de Processos que estão sendo consideradas são: Adaptação de Processos, Composição de Processos e Instanciação de Processos.

Esse texto tem como objetivo trazer uma discussão inicial sobre alguns aspectos relacionados à operação de Composição de Processos de Software. Serão apresentados os principais desafios relacionados a essa operação e algumas considerações sobre o tema serão discutidas. Além disso, serão apresentadas algumas propostas da literatura atual para Composição de Processos de Software e analisar como elas se comportam diante dos desafios identificados.

O restante do texto está dividido da seguinte forma: a seção 2 apresenta o Referêncial Teórico necessário para esse texto. A seção 3 apresenta os principais problemas/desafios relacionados à Composição de Processo. A seção 4 traz algumas considerações adicionais essa operação. Na seção 5 algumas das soluções de Composição de Processos de Software são apresentadas e a seção 6 traz as conclusões desse texto e uma discussão sobre trabalhos futuros.

#Referencial Teórico

Processos de Negócio e Processos (de Desenvolvimento) de Software

Um Processo de Negócio pode ser representado por um conjunto de atividades que são executadas sob determinadas regras e ordem a fim de atingir um objetivo de negócio bem definido (Weske 2007). (Dumas 2013) vai além e define Processos de Negócio como uma coleção de eventos, atividades e pontos de decisão interconectados que envolve um número de atores e objetos que coletivamente interagem a fim de atingir um objetivo comum e gerar um valor agregado ao negócio.

Os Processos de Desenvolvimento de Software (ou simplesmente Processos de Software) (PDS) são processos de negócios envolvidos na construção de um software (Kroll 2003). Um PDS deve decrever - dentre outras coisas - as Atividades, Papéis e Artefatos presentes no desenvolvimento de um software. As Atividades representam um conjunto de tarefas que precisam ser realizadas e envolvem manipulação/elaboração de um ou mais artefatos de software. Artefatos por sua vez, representam os componentes de software (documentação, modelagem, código, cenários de teste, etc) necessários para garantir a entrega do software; e Papéis representam os perfis necessários aos integrantes do processo de software.

Existem vários Processos de Software denominados modelos de referência. Um modelo de referência representa modelo padrão de desenvolvimento de software que descreve formalmente um ciclo de vida e um conjunto de atividades, artefatos e papéis associados a cada ciclo. Normalmente tais modelos são bastante prescritivos e abrangem uma grande gama de situações e características da construção de um software. Por essa razão, os Modelos de Referência dificilmente são implantados de forma integral. Ao invés disso, as organizações utilizam um ou mais modelos de referência (como o Processo Unificado, Lean, Scrum, etc) como base para elaborar/definir os seus próprios métodos de produção (Sommerville 2010).