Gerência de Ativos de Processo

Uma questão não discutida na seção 0 referente a melhoria de processos de software foi como garantir um controle adequado sobre as diferentes versões dos processos e como prover algum mecanismo eficiente para garantir a rastreabilidade das mudanças ocorridas nestes processos. A identificação das mudanças ocorridas nos processos e dos motivos que levaram a estas mudanças pode ser útil, por exemplo, para que a corporação mantenha o controle sobre a evolução dos processos e também para identificar novas oportunidades de melhoria nos processos corporativos.

Como foi dito anteriormente nas seções 4.2.4 e 4.3.4, os AESCorp devem possuir uma biblioteca de ativos de processo responsável pela gerência e controle destes ativos. Parte deste controle está relacionado a mecanismos associados à gerência de configuração. Esta gerência de configuração segue o mesmo padrão qualquer que seja o tipo de ativo de processo sendo gerenciado (por exemplo, roteiros, processos, item de conhecimento etc.), porém, pode haver particularidades específicas para determinado tipo e adaptações devem ser realizadas conforme pertinente.

Além da ligação com melhoria de processos de software, a gerência de ativos de processos está diretamente relacionada a outros elementos deste trabalho, por exemplo, à definição de processos (sejam eles padrão, especializados ou definidos para o projeto), definição de ambientes corporativos, organizacionais e de projetos e gerência de conhecimento. Um AESCorp deve, dessa forma, prover mecanismos para o controle de versão, controle de modificação e rastreabilidade de versões e mudanças, além de possuir bases independentes de ativos de processo e de versões de ativos de processo.

4.4.5.1 Controle de versão

As diferentes versões dos ativos de processo geradas por uma corporação devem ser armazenadas e gerenciadas de forma a garantir um nível de controle adequado para cada tipo de ativo de processo. É preciso, também, manter um histórico das modificações realizadas em determinado ativo de processo para garantir uma rastreabilidade das alterações realizadas. Também é preciso garantir que versões concorrentes de diferentes

ativos existam e sejam utilizadas por diferentes organizações e/ou projetos ao mesmo tempo. Por exemplo, o processo padrão de uma organização pode ter sido alterado devido a uma melhoria, mas os projetos já em andamento devem continuar a utilizar a versão anterior para que não haja um impacto que possa ser prejudicial ao andamento dos projetos. Entretanto, novos projetos a serem iniciados devem ser criados já com base no novo processo padrão. Outro exemplo de versões concorrentes é a existência de variantes de um procedimento para realização de uma tarefa de acordo com a maturidade da organização que vai utilizá-lo ou com características e desejos da organização.

O controle de versões é crítico num ambiente corporativo, pois diferentes versões de um mesmo ativo de processo podem coexistir nos ambientes corporativo, organizacional e de projeto. Outra realidade que pode ser constante neste cenário é a possibilidade de que as evoluções nos ativos de processo possam ser efetuadas de forma independente e em paralelo em várias organizações e, num determinado momento, a corporação deseje ter acesso a estas versões para analisar oportunidades de melhoria dentro do contexto corporativo e, então, disponibilizar novas versões dos ativos às organizações.

Uma questão importante quando se fala do controle de versão dos ativos de processo, assim como de quaisquer outros tipos de itens de configuração, é a granularidade do item a ser gerenciado. Artefatos e roteiros de artefatos geralmente são controlados como um único item de configuração. Por outro lado, processos de software podem ter sua granularidade aumentada ao identificar como itens de configuração não o processo como um todo, mas cada atividade. Ao diminuir o tamanho do grão a itens elementares ganha-se precisão para determinar o ponto específico em que a mudança ocorreu, porém, aumenta- se a complexidade do versionamento e nem sempre a relação custo-benefício é adequada. Deve-se, portanto, analisar o custo-benefício da escolha dos itens de configuração a serem tratados para manter o controle adequado da evolução dos itens sem aumentar desnecessariamente a burocracia relacionada à sua gerência.

4.4.5.2 Controle de modificação

Controlar as versões, no entanto, não é suficiente para garantir o controle das alterações realizadas. A corporação e suas organizações devem ser capazes de registrar todas as suas necessidades de alteração/evolução dos ativos de processo existentes. Por exemplo, uma organização pode solicitar ao grupo de qualidade da corporação a alteração do conteúdo de um procedimento interno que regule a construção de um determinado artefato para adequá-lo a novos padrões internacionais que surjam ou que deveriam ser adotados. Todas as informações geradas por esta solicitação (por exemplo, justificativas do

pedido, pareceres do grupo de qualidade do processo, relatório de modificações realizadas) devem ser registradas de alguma forma e tornadas disponíveis a todos os possíveis interessados.

Por outro lado, pode ser desejo da corporação limitar as alterações num ativo de processo organizacional ou então saber das mudanças com antecedência para autorizá-las ou não. Nestes casos, o controle de versão é mantido, porém deve ser implementado um controle de alteração nos processos de forma que um comitê específico autorize as alterações e evoluções de um determinado ativo de processo. Através da ação deste comitê todas as alterações têm que ser formalmente solicitadas, aprovadas, implementadas, verificadas e aprovadas para que, só então, sejam disponibilizadas aos interessados. Isto pode ser útil caso se deseje assegurar mais facilmente que versões de diferentes ativos de processo não fiquem inconsistentes entre si, comprometendo possíveis melhorias de processos em andamento ou garantir que as alterações realizadas estejam de acordo com as diretrizes corporativas.

Da mesma forma que a adoção de um controle formal de modificação aumenta o controle sobre o ativo de processo, também aumenta a burocracia relacionada a suas evoluções. Dessa forma, é necessário estabelecer regras que identifiquem que tipos de ativos de processos devem estar sob um controle formal de alteração e aqueles cujo controle necessário pode ser somente através de controle de versões.

4.4.5.3 Rastreabilidade de versões e mudanças

Através da adoção de controle de versão ou de controle de mudanças nos ativos de processo a corporação e suas organizações podem manter registros das evoluções ocorridas nos ativos de processo. Esta rastreabilidade pode ser útil para determinar fontes de erros ou falhas em definições assim como permitir que abordagens para melhoria de processos (e ativos de processos) ocorram em ambientes controlados. Também pode ser útil durante análises dos processos visando a melhoria dos ativos de processo corporativos ao facilitar a análise das modificações implementadas nos ativos por parte das organizações.

A definição de linhas base deve ser gerenciada de forma a garantir que a liberação de um conjunto de ativos de processo para uso de uma organização seja feita de forma controlada e que os itens que componham essa linha base estejam consistentes entre si. Por exemplo, os ativos de processo utilizados por uma organização com certo nível de maturidade devem ser consistentes e adequados àquele nível.

4.4.5.4 Bases de Ativos de Processo e Base de Versões de Ativos de Processo

Para garantir um menor grau de intrusividade da solução adotada para o controle de configuração dos ativos de processo, deve haver uma diferença entre os ativos disponibilizados para uso (que compõem a base de ativos de processos) e as diferentes versões pelas quais estes ativos já tiveram (que compõem a base de versões de ativos de processos). Dessa forma, a base de ativos de processo é, na prática, um subconjunto da base de versões de ativos.

Da mesma forma que as bases de ativos de processo da corporação e das organizações devem ser independentes, as bases de versões de ativos de processo também devem manter sua independência:

- O Meta-ambiente deve ter uma base de versões de ativos de processo que pode

ser utilizada durante a definição do Ambiente Corporativo;

- O Ambiente Corporativo deve ter uma base de versões de ativos de processo

que pode ser utilizada durante a definição do Ambiente Organizacional;

- O Ambiente Organizacional deve ter uma base de versões de ativos de

processo que pode ser utilizada durante a definição do Ambiente de Projetos. Os itens da base de versão de ativos de processo do Meta-ambiente devem ser disponibilizados para a corporação durante a configuração do Ambiente Corporativo. Da mesma forma, os itens da base corporativa devem ser disponibilizados às organizações durante a configuração do Ambiente Organizacional, que utilizará tais ativos para a definição dos ambientes de projetos.

Algum mecanismo deve ser disponibilizado para realimentar as bases originais com possíveis evoluções dos itens utilizados ao longo do tempo. Dessa forma, deve haver uma análise da evolução dos ativos de processos nas organizações para determinar sua reincorporação à base de ativos corporativa. Há, portanto, três possibilidades de atualização de um item na base corporativa após disponibilização e alteração na base organizacional. Após uma análise da alteração realizada (e de acordo com o cenário de melhoria), pode-se decidir refletir a mudança na base corporativa, aceitar apenas parte das alterações realizadas ou, então, ignorar todas as alterações realizadas.

4.4.6 Gerência de Conhecimento

Conhecimentos adquiridos nas organizações devem ser armazenados no repositório de conhecimento organizacional e devem ficar associados a informações de contexto de

forma a avaliar a sua adequação à realidade dos projetos, das organizações e da corporação ao longo do tempo, além de permitir que possam ser reavaliados e reclassificados. Estas informações de contexto incluem, mas não se resumem a, atividades onde a coleta foi realizada ou a que se refere e conceitos e instâncias de teorias de domínio que possam servir como classificadores.

Uma vez que a base de conhecimento, pelo menos em sua versão inicial, tiver sido construída, deve-se garantir que os itens de conhecimento sejam prontamente compartilhados e disponibilizados aos membros da corporação e das organizações e dos executantes dos processos. Esta disponibilização de conhecimento será mais eficiente se acontecer de forma pró-ativa inserida no contexto de uso e aplicabilidade do conhecimento. Deve-se, também, no entanto, garantir um acesso à base de conhecimento por meio de buscas e pesquisas específicas. Possuir mecanismos que permitam incorporar conhecimentos e experiências registrados nos demais ambientes como, por exemplo, evoluções em lições aprendidas e novas melhores práticas.

Outra importante fonte de conhecimento dentro da estrutura corporativa são os especialistas em áreas específicas, como, por exemplo, o próprio domínio de processos de software. Dessa forma, deve-se garantir que haja a identificação de tais especialistas e que eles possam ser encontrados e contatados visando a uma maior disseminação do conhecimento. Uma possibilidade para a disseminação desse conhecimento detido por especialistas é a criação de um fórum específico em uma comunidade de prática de forma a disseminar mais facilmente as informações sobre a evolução os ativos de processo e, até mesmo, estimular a discussão sobre eles entre os membros da organização.

4.5 Considerações Finais

Este capítulo apresentou as principais necessidades que motivaram a definição dos Ambientes de Engenharia de Software Orientados a Corporações e também os seus principais requisitos e características de infra-estrutura, englobando apoio a definição, execução e melhoria de processos, definição de ambientes, gerência de ativos de processos e gerência de conhecimento. No próximo capítulo serão discutidas as alterações realizadas na Estação Taba para a construção de tais ambientes.

CAPÍTULO 5 - DEFINIÇÃO E CONSTRUÇÃO DE