Modelagem das áreas de processo do CMMI usando Business Process Management e Software Process Engineering Metamodel Specification

Transcrição

1 Modelagem das áreas de processo do CMMI usando Business Process Management e Software Process Engineering Metamodel Specification Jaguaraci Batista Silva¹, Hugo Saba² 1 Departamento de Computação Universidade Federal da Bahia (UFBA) Av Adhemar de Barros s/n, Ondina Salvador BA Brazil 2 Departamento de Exatas Universidade Estadual de Feira de Santana (UEFS) jaguarac@ufba.br, hugosaba@uefs.br Abstract. With the globalization, the lacks of documents standardization and agility on inquiry the norms in the guides as well as the Capability Maturity Model Integrated (CMMI), lead to the loss of competitiveness. In the effort for certifications, the agility becomes important to get and to apply the necessary norms that guarantee the processes quality of its. This research proposes a modeling of CMMI processes areas using Business Process Management (BPM) with goal to growth the agility and information reuse, being created an approach between CMMI and Software Process Engineering Metamodel Specification (SPEM) notations, to represent its components on the diagram forms, being sped up the understanding. Resumo. Com a globalização, as faltas de padronização de documentos e de agilidade em consultas de normas em guias como o Modelo Integrado de Maturidade da Capacitação (CMMI), conduzem à perda de competitividade. Na busca por certificações, torna-se importante a agilidade para obter e aplicar as normas necessárias, que garantam a qualidade de seus processos. Esta pesquisa propõe uma modelagem das áreas de processo do CMMI, utilizando, Business Process Management (BPM) com o objetivo de melhorar a agilidade e a reutilização de informações, criando uma relação do CMMI com as notações do Software Process Engineering Metamodel Specification (SPEM), para representar os seus componentes na forma de diagramas, acelerando a compreensão. 1. Introdução Durante a implantação de um modelo de processo em uma empresa produtora de software dificuldades precisam ser vencidas. A falta de padronização nos documentos que guiam a obtenção de informações e a adequação deste modelo a realidade da organização, são exemplos de problemas enfrentados durante esse processo. É importante ter domínio sobre os processos a serem executados ou um guia para acoplálos de forma coesa, para evitar a perda de produtividade (e. g. retrabalho). Uma ferramenta de modelagem de processos possibilita o desenho dos processos conduzindo a um entendimento rápido, publicar as informações e fazer análises sobre seus resultados de maneira ágil, papel de uma metodologia de Business Process Management

2 (BPM) (White, 2007). Essa pesquisa utiliza o BPM para demonstrar uma nova alternativa na obtenção das informações das áreas de processo do CMMI (Modelo Integrado de Maturidade da Capacitação) (Chrissis et al, 2001). Aproveitando a sua padronização de documentos, diagramas usados na representação dos processos e as notações do Software Process Engineering Metamodel Specification (SPEM) (OMG, 2005) para representar melhor o conjunto de práticas contidos no guia. Será proposta uma modelagem base, adaptável e aberta, a qual ajudará bastante a organização que deseja utilizar o modelo CMMI para implantar um novo processo de construção de software. O trabalho está organizado da seguinte forma: os problemas encontrados na obtenção das informações do CMMI e a proposta deste trabalho no capítulo 1. Uma visão geral do guia no capítulo 2. A criação de uma relação entre o CMMI e o SPEM para a utilização de símbolos que representem os seus componentes em forma de diagramas no capítulo 3. Uma breve apresentação da metodologia de BPM utilizada neste trabalho no capítulo 4. A proposta deste trabalho no capítulo 5. As conclusões e sugestões para um trabalho futuro estão no capítulo 6. As referências utilizadas constam na parte final deste artigo. 2. Visão geral do CMMI O Modelo Integrado de Maturidade da Capacitação (CMMI) (SEI, 2002) busca integrar e evoluir os modelos Capability Maturity Model for Software (SW-CMM) (Paulk et al, 1993), System Engineering Capability Maturity Mode (SE-CMM) e Integrated Product Development Capability Maturity Model (IPD-CMM) no intuito de minimizar os custos da implementação da melhoria do processo de software. Este modelo foi desenvolvido pelo Software Engineering Institute (SEI) e possui os elementos essenciais de um processo efetivo, os quais são baseados nos conceitos desenvolvidos por Crosby [4], Deming (Deming, 1986), Juran (Juran, 1989), and Humphrey (Humphrey, 1989). O CMMI não é um método, pois não estabelece ações específicas a serem seguidas, ele fornece uma diretriz para a seleção de estratégias de melhoria de processos, permitindo a determinação dos processos correntes e a identificação das questões mais críticas para a melhoria e qualidade de processos. Precisando ser compreendido e adaptado às características de cada organização. O CMMI SE/SW é organizado em duas representações diferentes de modelos, estagiado e contínuo, e sua arquitetura é composta basicamente por 22 áreas de processo. O modelo na representação de estágios é formado por cinco níveis de maturidade. As 22 áreas de processo estão agrupadas nos níveis 2, 3, 4 e 5, no nível 1 não existe nenhuma área de processo. Cada nível de maturidade representa um patamar evolutivo formado pelas áreas de processo, que estabelecem um conjunto coerente de metas. Estas metas quando satisfeitas em conjunto estabilizam o processo de software, resultando no aumento da capacitação do processo da organização. Quanto maior a capacitação, menor será a variação dos erros de estimativa em torno da média. O modelo na representação contínua é compatível com a norma internacional ISO/IEC (ISO, 2003) para avaliação de processos e é composto por seis níveis de capacidade e as mesmas 22 áreas de processo. A classificação em cada nível de capacidade é definida por um conjunto de características que o processo deve satisfazer.

3 O conjunto de atividades correspondente a cada área de processo pode ter sua capacidade de execução classificada em Nível 0 Incompleto, Nível 1 Executado, Nível 2 Gerenciado, Nível 3 Definido, Nível 4 Gerenciado Quantitativamente e Nível 5 Em Otimização. Estes modelos focalizam na capacitação das organizações em produzirem consistentemente e previsivelmente produtos de qualidade assegurada. Também focalizam na premissa básica da gerência de processo, na qual a qualidade do produto é determinada principalmente pela qualidade do seu processo. 3. Mapeamento do CMMI usando o SPEM O Software Process Engineering Metamodel Specification (SPEM) (OMG, 2005), modelo utilizado para especificar, definir processos e seus componentes, foi construído a partir de um subconjunto, chamado de SPEM Foundation, um perfil do metamodelo Unified Modeling Language (UML) (Booch et al, 2003) que oferece algumas representações e estereótipos para modelar artefatos, processos, ferramentas e outros componentes utilizados em um processo de construção de softwares. A descrição dos principais elementos que compõem o SPEM e a sua relação com o CMMI estão descritas na tabela 1. Tabela 1. Tabela de relacionamento dos elementos comuns utilizados no CMMI e SPEM. Figuras Notações do SPEM Componentes do CMMI WorkProduct Activity or Step WorkProduct Produto típico de trabalho. Práticas e sub-práticas genéricas ou específicas. Produto típico de trabalho. Guidance Phase ProcessPackage SPEM Packages Guia ou manual. Nível de maturidade. Área de processo relacionada. Metas genéricas ou específicas. ProcessPerformer Habilidade requerida para executar atividades. ProcessRole Habilidade requerida para executar atividades.

4 WorkDefinition WorkProduct Área de processo. Produto típico de trabalho. A metodologia proposta buscou uma aproximação dos elementos apresentados nos guias do SPEM (OMG, 2005) e CMMI (Chrissis, 2001) na utilização da metodologia de BPM (Seção 4) para a representação dos guias através de diagramas. Um produto típico ou Workproduct, relacionados a alguns dos elementos da tabela 1, simbolizam um ou mais artefatos gerados a partir de uma prática ou sub-prática e normalmente são utilizados materiais de apoio para o seu conhecimento como um guia ou manual elementos que também estão associados como Phase e Guidance. As atividades no CMMI são agrupadas e guiadas por metas, estas podem ser específicas, no caso das habilidades requeridas para a sua execução serem de nível técnico ou genéricas que apóiam a sua institucionalização, o perfil de execução das atividades são representadas pelos elementos ProcessRole, ProcessPerformer, as práticas e subpráticas estão sendo representadas pelo componente Activity ou Step e as metas pelo SPEM Packages. Essa institucionalização se dá através das necessidades da empresa e são associadas em níveis de maturidade (Seção 2). Um nível de maturidade contém áreas de processos e esta pode estar relacionada a outras, os elementos Workdefinition e ProcessPackage representam essa informação. 4. Visão geral da metodologia de BPM A metodologia de modelagem e gerenciamento dos processos de negócio foi construída durante o programa de residência em software com foco em e-government na Universidade Federal da Bahia (Santos et al, 2007). A construção dessa modelagem, deve-se ao fato de ocorrer em paralelo vários projetos de modelagem propostos pelo programa. Com isso, foi necessário estabelecer critérios de padronização dos documentos para a obtenção de dados, a forma de compor os elementos gráficos que os representasse usando a BPMN (Business Process Management Notation) (White, 2007) em diagramas e um guia que servisse de base para outros projetos de modelagem na universidade. No caso específico da residência, foi adotada uma seqüência de atividades agrupadas em três etapas, conforme a figura 1 abaixo: Figura 1 Etapas da metodologia (Santos et al, 2007)

5 4.1 Etapa 1 Emoldurar processos O mapeamento de processos define claramente como funciona os macros e subprocessos, seus relacionamentos, quem realiza cada atividade. Apoiando a compreensão do contexto dos processos através de uma documentação detalhada da organização, possibilitando uma visão geral dos seus processos e atividades.. O relacionamento pode ser de três tipos: 1:1 (i.e. um para um), geralmente constituem processos bem formados, 1:M (i.e. um para muitos) quando um processo pode ter várias ações de um outro diretamente relacionado a ele e M:M (i.e. muitos para muitos), onde vários processos se relacionam com tantos outros. O relacionamento 1:1 ocorre entre sub-processos e entre processos ocorrem 1:M - M:1, M:M - M:1 ou 1:M - M:M. 4.2 Etapa 2 Compreender o processo Para a modelagem e avaliação dos processos, utilizando as informações colhidas nos documentos da etapa anterior, são utilizados diagramas compondo três ou mais níveis de detalhamento, classificados como diagramas de Handoff, de Fluxo e Atividades. O diagrama de Handoff permite um visão geral dos processos envolvidos em uma determinada tarefa, dando ênfase aos atores dos procedimentos. Neste aspecto, são abordados os itens de evento inicial que desencadeia a execução do processo, o evento final representando o fim do processo, as estruturas de decisões que afetam o fluxo, os operadores lógicos e raias de responsabilidade. As estruturas de decisões de processo representado pelo símbolo se, podem ser usadas como forma de indicar uma decisão de fluxo a partir de alguma característica dos passos anteriores. Alguma característica deve ser analisada e se ela for verdadeira o fluxo a ser seguido será um, e se for falsa o fluxo será outro. Os loops servem para indicar a necessidade de voltar a executar um determinado passo ou seqüência de passos até que uma determinada condição de parada seja alcançada, e o fluxo do processo possa seguir seu caminho normal. Os operadores lógicos ou representam a possibilidade de seguir por um ou mais caminhos subseqüentes a esse passo. O operador (i.e. exclusivo) representa a possibilidade de seguir apenas um dos fluxos possíveis a partir do processo em que se encontra. Fluxos concorrentes são representados pelo símbolo e indicando que para que um passo fora do e possa ser executado, todos os passos que estão inclusos nesse fluxo paralelo devem ter sido completados. A representação em raias é exclusiva para o participante e contém todos os processos executados por ele, facilitando conhecer as suas responsabilidades. O diagrama de Fluxo é gerado a partir do Handoff e apresenta um maior nível de detalhamento que o seu predecessor. Para obtê-lo, é necessário criar novos níveis de detalhamento para cada um dos passos originais, e em cada um desses níveis gerados, incluir novos passos que para não afetar a legibilidade do diagrama, devem ser criados com um certo critério. Neste Diagrama são abordados os mesmos itens do diagrama de Handoff, que são as decisões que afetam o fluxo, loops significantes, evento inicial, evento final e a representação em raias dos participantes do passo. O evento inicial e o evento final são considerados as interfaces que comunicam o processo em questão com o anterior e posterior respectivamente. Além desses itens devem ser considerados: os mecanismos de Handoff, cuja finalidade é a identificação da transição entre as atividades e suas entradas e saídas, dos fluxos de dados que são transferidos de um

6 passo para outro e dos tipos de mídias usadas nesses fluxos. Além disso, devem ser feitas cinco perguntas para a sua validação: O que faz o passo prosseguir? Quem mais está envolvido nesse passo? O nome desse passo reflete o seu resultado? Todas as saídas são representadas?, E no caso de um Handoff, como o trabalho é passado adiante?. O diagrama de Atividade serve para descrever partes confusas ou problemáticas do processo. Novos passos podem ser desenhados no diagrama com o objetivo de tornar o processo o mais claro possível. O nível de detalhamento deste diagrama é maior que os diagramas de Handoff e Fluxo, pois além dos itens abordados nestes diagramas, outros serão adicionados, como: recursos, custos, sistemas e outras informações que possam facilitar o entendimento do processo. 4.3 Etapa 3 Projetar o processo desejado Definição da decisão a ser tomada em relação aos processos identificados durante a etapa AS-IS, onde os fatores como processos, suas principais características, deficiências, foram detalhadamente identificados e junto ao alinhamento com os objetivos e estratégias da organização. Apoiando a organização na definição de aspectos que tornem os processos identificados e coerentes com os objetivos e estratégias da mesma, se essa for a decisão tomada pela empresa. Nesses casos, é necessário aplicar simulações, desenvolver um novo modelo de processos com as melhorias previstas para a situação atual identificada, dentre outros. A decisão a ser tomada pela empresa dependerá do foco dado a modelagem realizada na organização, pois, se a idéia era apenas identificar os processo atuais da organização, alterações nos mesmos não serão necessárias. Dentre as várias decisões a serem tomadas pelas organizações, após a realização da etapa de identificação dos processos atuais da organização, poderá decidir por mantê-lo, melhorá-lo ou abandonálo criando um novo modelo. 5. Modelagem da área de processo do CMMI usando BPM e notações do SPEM Na construção da modelagem proposta, com base na metodologia de BPM (Seção 4), foram utilizados diversos documentos e elementos visuais através de ferramentas de escritório para edição de textos com a capacidade de criação de planilhas e uma ferramenta de modelagem de processos de negócio denominada Bonapart (Bonapart, 2007). A Bonapart apresenta-se em três etapas, a etapa de emoldurar e de compreender o processo, as quais foram utilizadas na modelagem proposta, por se tratarem da aquisição e modelagem da informação, enquanto a terceira, projetar o processo desejado, não foi utilizada, pois poderá ser executada durante a implantação do CMMI, para a sua melhor adequação aos processos de negócio da empresa. 5.1 Emoldurar processos O objetivo deste fase como já foi explicado, é obter informações da organização para servir de base para modelagem. Utilizou-se os templates e padrões, utilizados na modelagem, com o objetivo de modelar as práticas específicas da área de processo do CMMI de Produto (Product Integration) (Chrissis et al, 2001)(SEI, 2002). A escolha dessa PA (Process Area) se deu devido á existência de vários trabalhos

7 publicados com algumas áreas de processo no nível 2 e por acreditar que todos os documentos utilizados neste trabalho podem servir para muitas empresas no Brasil que encontram-se atualmente no nível de maturidade 3. Além disso, por não se tratar de uma modelagem de processos de negócios na organização, pois o uso da metodologia de BPM e construir uma modelagem de apoio com as informações da PA, não foram utilizadas as etapas de documentar a missão, estratégia, metas e objetivos da organização. Estas devem ser feitas posteriormente, quando da implantação do modelo de processo na empresa. Apenas duas etapas foram abordadas: a preparação da modelagem e a construção do mapa geral do processo Preparação da modelagem Durante a fase da preparação da modelagem, é necessário conhecer todas as atividades relacionadas para compor uma visão geral do processo, foram definidas duas atividades: Obtenção da lista de atividades (Seção ) e Agrupamento das atividades em subprocessos (Seção ) Obtenção da lista de atividades As sub-práticas contidas na tabela 1, estão agrupadas junto a práticas específicas. As informações sobre os atores, são recomendações do próprio guia para o perfil profissional com as qualificações necessárias para execução das atividades (Tabela 2). Tabela 1 Meta específica da PA de Produto. Meta específica SG 1.0 Preparar para a integração do produto Práticas específicas SP 1.1-1Determinar a seqüência de integração; SP 1.2-1Estabelecer o ambiente de integração; SP 1.3-1Estabelecer os procedimentos e critérios; As área de processo estão contidas nas descrições das práticas específicas, são referenciadas através de recomendações para questões relacionadas as atividades como: soluções de problemas, onde requisitar os artefatos de entrada, qual PA será responsável pela gerência de versões dos documentos, onde será armazenado os artefatos de saída e mídia utilizada. Tabela 2 Prática Específica SP Determinar a seqüência de integração. Atividade Atores Área de Processo SG SP Determinar a Seqüência de 1- Identificar os componentes para Engenheiro de Software, Analista de Engenheiro de Software Gerência de acordo com o fornecedor

8 2 - Identificar as relações entre os componentes 3 - Identificar uma seqüência para 4 - Identificar uma seqüência alternativa para Engenheiro de Software Analista de Analista de Gerência de Risco Gerência de Risco 5 - Verificar qual a melhor seqüência Analista de 6 - Revisar a seqüência de quando necessário Analista de Decisão de Análise de Resolução Os recursos, documento do domínio da aplicação, ferramenta de criação de protótipo, aplicativos de escritório e guias para análise são os produtos típicos de trabalho recomendados pelas sub-práticas e os exemplos de recursos presentes em Ability to Perfom ou habilidade para execução da PA. Os documentos de entrada (e.g. documento dos componentes do produto) e saída (e. g. documento da seqüência de integração) foram extraídos das informações dos produtos típicos de trabalho e agrupados para o conhecimento de quais artefatos são necessários para a execução e o que será gerado como produto de trabalho após a realização das atividades Agrupamento das atividades em sub-processos Os sub-processos representam as práticas específicas da meta SG 1.0 (Tabela 1). O documento de informação sobre os sub-processos contém entre outras informações: o seu objetivo, uma breve descrição e o agrupamento das sub-práticas ou atividades listadas acima. Na modelagem abordada, os sub-processos são criados a partir de um agrupamento lógico e coeso das atividades para então construir o diagrama de Mapa Geral do processo. Este documento será útil também quando da criação do diagrama de atividades, pois os diagramas serão organizados em níveis de detalhamento Construção do mapa geral Para alcançar a meta SG 1.0,(i.e. processo aqui representado), são necessárias práticas específicas (SP) (i.e. um conjunto de atividades apresentadas acima). No diagrama de mapa geral é possível perceber a orientação sobre o início e final do processo, facilitando o entendimento sobre quais os conjuntos de atividades necessárias a sua execução. A relação entre as práticas específicas são iguais ás definidas para os processos utilizada na modelagem, ou seja, 1:1 (i.e. um para um). A ferramenta de modelagem BPM utilizada para a construção do diagrama, a Bonapart (Bonapart, 2007), não permite o uso de elementos visuais do SPEM, sendo necessário utilizar as figuras para adaptação dos objetos visual predefinidos internamente. Na criação do diagrama acima foram utilizados símbolos do BPMN (White, 2007), para representação de processos, e o SPEM Packages, conforme o mapeamento criado (Capítulo 3).

9 Figura 2. Mapa geral SG 1.0 Preparar para integração do produto. 5.2 Compreender o processo Um dos benefícios das ferramentas de BPM é a criação de diagramas que representam as atividades a serem desempenhadas nos processos. Nesta etapa, foi utilizado o diagrama de atividades diretamente, por já apresentar as informações (e. g. atores, recursos e sistemas) que facilitam o entendimento do processo. Na construção do diagrama foi utilizada a padronização de elementos da metodologia BPM (Capítulo 4). Os elementos foram organizados da seguinte forma: as área de processos e perfis habilitados para executar ás atividades, localizados á esquerda. As atividades estão no centro do diagrama e segue a orientação de execução, começando no topo deslocando-se para baixo e com os nomes começando por números seqüenciais. Os recursos como (Figura 3): ferramentas, guias e documentos, localizam-se à direita As setas pretas indicam a direção do caminho a ser percorrido, a necessidade da informação obtida na atividade anterior e o fluxo de seqüência para o próximo passo. As setas vermelhas ou azuis, os recursos, as áreas de processo, o perfil necessário para execução das atividades e a direção da busca por esses elementos. No evento de entrada, por exemplo, representado pela figura Workproduct do SPEM, a direção da seta indica que os artefatos necessários para a execução deste sub-processo devem ser entregues pela PA Desenvolvimento de Requisitos e o seu produto final enviado pela PA de Gerência de Configuração para que esta possa controlar as versões dos documentos especificados (Figura 3). No diagrama também estão presentes os estereótipos utilizados nas setas, tais como: uses, Retrieves information e o relacionamento 1:1 (i.e. um para um). O uses indica que para a execução da atividade é necessário utilizar um recurso ou guia. Para saber se existe alguma informação a ser recuperada de um documento ou sistema, é utilizado o Retrieves information. O relacionamento indica que deve existir na empresa apenas um perfil para executar a função e uma área de processo a qual esse profissional deve se reportar. A existência de um único perfil não restringe a delegação deste para uma ou mais pessoas, apenas a capacidade técnica exigida.

10 Figura 3. Diagrama de atividades SP Determinar a Seqüência de. 6. Considerações Finais A modelagem da área de processo do CMMI utilizando uma metodologia de BPM e notações do SPEM, minimizou o fato das coletas de informação contidas no CMMI serem exaustivas para os consultores, transformando em uma modelagem por

11 simbologia o que facilita a compreensão. A concentração das informações em documentos e a busca por organizar o entendimento através de diagramas tornou a leitura e interpretação mais dinâmicas. As informações geradas pela modelagem proposta, utilizando os modelos previamente construídos em uma ferramenta de BPM, possibilita a reutilização e é adaptável a outras empresas. Uma modelagem completa da área de de Produto foi realizada como exemplo e seus documentos podem ser vistos em Como trabalho futuro, busca-se uma comparação entre a implantação de uma área de processo do CMMI, seguindo a abordagem proposta neste artigo, e a abordagem convencional (i.e. com base no guia de implantação do CMMI) para efetuar uma análise minuciosa dos benefícios entre uma técnica e outra. Referências Bonapart. Ferramenta de Modelagem de Processo de Negócios. Disponível em acessado em agosto de Booch, G., Jacobson, I., Rumbaugh, J (1999). Unified Modeling Language User s Guide. Addison-Wesley. Chrissis, M. B., Konrad M., Shrum S.. CMMI: Guidelines for Process Integration and Product Improvement. Addison Wesley, fevereiro de ISBN Crosby, P.B.. Quality is Free. McGraw Hill, Book Co. 1979, 309p. Deming, W.E., Out of Crisis, MIT Center for Advanced Engineering Studies, Cambridge, MA, Humphey, Watts.. Managing the Software Process. Reading, Mass.: Addison-Wesley, ISO. ISO/IEC TR The International Organization for Standardization and International Eletrotechnical Commission, Information Technology Software Process Assessment. Outubro de Juran, J. M., Juran.. On leadership for Quality. New York: Free Press, OMG. Software Process Engineering Metamodel Specification. Object Management Group. Janeiro de 2005, Versão 1.1. Paulk Mark C., et al. The Capability Maturity Model for Software. Version 1.1, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA (USA), Santos, A.G., Santos F. G., Mendes F. A. T., Cruz G. M., Silva J. B., Freitas J.V. V.B., Santana M. R., Pastor S. O.Metodologia de Processos de Negócios. Universidade Federal da Bahia, Programa de Residência em Software com foco em e-government, Disponível em acessado em agosto de SEI. CMMI., et al. The Capability Maturity Model for Software. Version 1.1- CMU/SEI-2002-TR-012, March 2002.

12 White, S. A.. Introduction to BPMN, IBM, BPMN Articles and Papers. Disponível na Internet em acessado em agosto de 2007.