Reutilização de Processos de acordo com Contexto

Para lidar com a diversidade de processos, também é preciso levar em consideração o contexto onde os processos serão aplicados. Esta seção resume alguns trabalhos relacionados que utilizam as particularidades do contexto do projeto para a reutilização de processos.

a) Contingency factors e situational method engineering

Situational method engineering (SME) (BRINKKEMPER, 1996, SLOOTEN e

BRINKKEMPER, 1993) propõe a construção de métodos de desenvolvimento de software para situações específicas (HENDERSON-SELLERS e RALYTÉ, 2010, PEREIRA, 2012). Esta área tem por objetivo oferecer flexibilidade às organizações na configuração de um processo específico para o projeto de desenvolvimento, usando métodos ou fragmentos de métodos, construídos pela própria organização, armazenados em um repositório e recuperados para satisfazer a situação de um projeto em particular (HARMSEN et al., 1994, HENDERSON-SELLERS e RALYTÉ, 2010).

SME define os seguintes quatro passos para a construção de um método (ou definição de um processo específico para o projeto): (i) especificação da situação do projeto; (ii) definição dos requisitos dos fragmentos de método, que refletem as situações; (iii) seleção de um conjunto de fragmentos que satisfaça os requisitos; (iv) construção de uma metodologia coerente a partir da montagem dos fragmentos selecionados (ABAD et al., 2010).

A área de contingency factors (BEKKERS et al., 2008, KUMAR e WELKE, 1992) refere-se às variáveis que caracterizam um projeto para determinar a seleção do método apropriado a partir de um portfólio de métodos (DAVIS, 1982). Assim, SME e contingency factors podem ser combinados para recuperar fragmentos de acordo com as características situacionais, que auxiliam na determinação de quais elementos são mais apropriados. Essa ideia de caracterização do projeto é semelhante ao proposto neste trabalho, em que as informações de contexto são usadas para compor um processo que utilize as características e componentes de uma LPS.

carência de orientações sobre o modo como os contingency factors se relacionam com os métodos de desenvolvimento (KUMAR e WELKE, 1992). Além disso, não são encontrados relatos de experiências práticas da aplicação dessas abordagens e existe uma carência por dados resultantes de experimentos na área (HENDERSON-SELLERS e RALYTÉ, 2010).

Outro problema fundamental é que o gerente de projeto precisa de apoio para tomar decisões sobre o processo a ser adotado no projeto. Enquanto SME pode apresentar todos os detalhes sobre cada fragmento de processo individual, não dá indicações sobre a seleção e combinação deles para garantir que o processo resultante é executável. Esta capacidade de compor este processo, considerando o contexto do projeto, é uma contribuição da presente tese.

No contexto da área de pesquisa de SME, Pereira (2012) propôs a abordagem Octopus SME – Process Tailoring Approach (OSPTA). Trata-se de uma sistemática para construção de processos de software específicos para cada projeto, através da adaptação de processos, com a utilização de fragmentos de métodos (PEREIRA, 2012, PEREIRA et al., 2012).

A abordagem OSPTA visa à construção de um processo específico para cada projeto, que atenda as características situacionais do mesmo. Assume que já existe um processo padrão da organização definido. A Figura 3.3 apresenta uma visão geral da abordagem OSPTA, detalhando as suas principais atividades.

Primeiramente, devem ser definidas as características situacionais do projeto. Então, o projeto deve ser analisado em relação ao(s) critério(s) de adaptação estabelecido(s). Os fragmentos de métodos adequados em relação a um ou mais critérios de adaptação são recuperados da base de métodos de acordo com o resultado da atividade anterior. Para isso, deve haver na base de métodos fragmentos previamente associados ao critério de adaptação. Caso não existam, o responsável deve editar um fragmento existente ou definir novos elementos e armazená-los na base de métodos.

A ferramenta de apoio, usando um algoritmo de priorização, classifica os fragmentos previamente recuperados em ordem de relevância em relação ao contexto do projeto para sugerir os fragmentos mais apropriados para serem inclusos no processo de software adaptado. Após a priorização dos fragmentos

pelo algoritmo, o engenheiro de processos pode selecionar o conjunto final de fragmentos de métodos. Finalmente, o processo adaptado é construído pela ferramenta de apoio. Estudos de caso considerando “riscos do projeto” como critério de adaptação foram conduzidos para validar a abordagem (PEREIRA, 2012, PEREIRA et al., 2012).

Figura 3.3 – Visão Geral da Abordagem OSPTA (PEREIRA, 2012) b) Gerenciamento dinâmico de ativos de processos de software

A abordagem para gerenciamento dinâmico de ativos de processos de software (Figura 3.4) tem o foco na aprendizagem organizacional (SANTOS, 2009). O componente principal da abordagem é o repositório de ativos de processos, onde são armazenados os modelos de processo de software reutilizáveis. Estes modelos são contextualizados através de atributos de projeto e processo.

O usuário fornece os requisitos de processo através dos atributos de projeto e processo, e a máquina de busca realiza o cálculo de similaridade para os casos do repositório. A máquina de busca utiliza a técnica de Raciocínio Baseado em Casos (RBC) para a recuperação de casos similares através da medida de similaridade da representação de cada caso. Assim, esta

abordagem requer a existência de uma base de casos, ou seja, um conjunto de processos que já foram adaptados para contextos de projetos específicos.

Após a recuperação e a adaptação do(s) processo(s), conforme Figura 3.4, um processo é definido para atender às necessidades de um determinado projeto da organização. Ao encerrar a execução do processo, a instância do processo reutilizado é avaliada em relação à sua utilidade. Assim, é possível realimentar o repositório da base de casos de processos. O registro do fracasso ou do sucesso ajuda a melhorar o resultado das futuras situações.

Figura 3.4 – Abordagem para gerenciamento dinâmico de ativos de processos de software (SANTOS,

2009)

Dependendo da avaliação realizada sobre o processo executado, o usuário poderá escolher entre generalizá-lo ou não. O ato de generalizar consiste em transformar o processo executado em um modelo de processo abstrato, isto significa que os detalhes específicos do processo são retirados para deixá-lo apropriado para a reutilização em diversos projetos.

3.5. Considerações Finais

Este capítulo complementou o referencial teórico desta tese. Os processos de software foram abordados sob a perspectiva da diversidade de organizações, projetos, modelos de desenvolvimento de software, processos e pessoas.

Como abordagem para a definição de processos de software considerando a diversidade, foram apresentadas as estratégias de reutilização de processos de software. A composição de processos é a estratégia adotada

neste trabalho, como forma de promover a reutilização do conhecimento relacionado a processos de software. Por isso, técnicas de composição, tais como o uso de componentes e linhas de processos, foram abordadas no capítulo.

Um aspecto particular da diversidade de processos, a colaboração, foi discutido. Observa-se que, independente do modelo de desenvolvimento utilizado, a colaboração está presente no processo, com diferentes ênfases e formas. Esta observação reforça a questão introduzida no capítulo anterior, de que a colaboração possa ser planejada na definição do processo para um projeto e posteriormente acompanhada em sua execução, como forma de abordar a diversidade apresentada por diferentes contextos e situações.