modelagem das areas de processo do cmmi usando bpm cmmi e spem

1

Abstract— With the globalization, the lack 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 paper 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.

Index Terms— BPM; CMMI; SPEM;

I. 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 à 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, a publicação das informações e análises sobre seus resultados de maneira ágil, papéis esses de uma metodologia de Business Process

Management (BPM) [White, 2006]. 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 são usados na representação dos processos e as

Artigo publicado na InfoBrasil 2008. Jaguaraci Batista Silva é estudante da especialização avançada em sistemas

distribuídos na Universidade Federal da Bahia, BA 40302-370 BRA (e-mail: [email protected]).

Hugo Saba é professor da Universidade Estadual de Feira de Santana na Bahia, BA, BRA (e-mail [email protected]).

notações do Software Process Engineering Metamodel

Specification (SPEM) [OMG, 2005], para representar melhor o conjunto de práticas contido 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. Este artigo está organizado da seguinte forma: esta introdução apresenta os problemas encontrados na obtenção das informações do CMMI e a proposta deste trabalho. A seção 2 apresenta uma visão geral do guia CMMI. 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 é apresentada na seção 3. Uma breve apresentação da metodologia de BPM utilizada neste trabalho é apresenta na seção 4. A seção 5 apresenta a proposta deste trabalho. As conclusões e sugestões para um trabalho futuro estão na seção 6. As referências utilizadas constam na parte final deste artigo.

II. VISÃO GERAL DO CMMI

O Modelo Integrado de Maturidade da Capacitação (CMMI) [SEI CMMI, 2002] busca integrar e evoluir os modelos Capability Maturity Model for Software (SW-CMM) [Paulk et

al, 1993], System Engineering Capability Maturity Model (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 (1979), Deming (1986), Juran (1989) e 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

Modelagem das áreas de processo do CMMI usando Business Process Management e

Software Process Engineering Metamodel Specification

Jaguaraci Batista Silva, Hugo Saba.

2

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. Essas 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 15504 [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. 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.

III. 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, 2005] 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. A metodologia proposta buscou uma aproximação dos

elementos apresentados nos guias do SPEM [OMG, 2005] e CMMI [Chrissis et al, 2001] na utilização da metodologia de BPM (Seção 4), para a representação dos guias por meio de diagramas. Um produto típico ou “Workproduct”, relacionado a alguns dos elementos da tabela 1, simboliza 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 de 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 sub-prá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, que podem estar relacionadas a outras. Os elementos “Workdefinition” e “ProcessPackage” representam essa informação.

Tabela 1. Tabela de relacionamento dos elementos comuns utilizados no CMMI e SPEM.

Figuras Notações do SPEM Componentes do CMMI

WorkProduct Produto típico de trabalho.

Activity or Step Práticas e sub-práticas genéricas ou específicas.


Guidance Guia ou manual.

Phase Nível de maturidade.

ProcessPackage Área de processo

relacionada.

SPEM Packages Metas genéricas ou específicas.

ProcessPerformer Habilidade requerida para executar atividades.

ProcessRole Habilidade requerida para executar atividades.

WorkDefinition Área de processo.


IV. 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 representassem usando a BPMN (Business Process Management Notation) [White, 2006] 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.

A. Etapa 1 – Emoldurar processos

O mapeamento de processos define claramente como funciona os macros e sub-processos, seus relacionamentos, quem realiza cada atividade, apoiando a compreensão do contexto dos processos através de uma documentação detalhada da

3

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 constitui 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), quando 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.

Figura 1 – Etapas da metodologia [Santos et

al, 2007]

B. 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 exibido na Figura 2 permite uma 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 nas 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 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?.

Figura 2. Diagrama de handoff (Santos et al,

2006).

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

C. 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 e deficiências foram detalhadamente identificados 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 à modelagem realizada na organização, pois, se a idéia era apenas identificar os processos 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á se decidir por mantê-lo, melhorá-lo ou abandoná-lo criando um novo modelo.

V. 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.

A. Emoldurar processos

O objetivo desta fase, como já foi explicado, é obter informações da organização para servir de base para modelagem. Utilizaram-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 Integração de Produto (Product

Integration) [Chrissis et al, 2001] [SEI CMMI, 2002]. A escolha dessa PA (Process Area) se deu devido à existência de vários trabalhos 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 é 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.

1) 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, portanto foram definidas duas atividades: Obtenção da lista de atividades (Seção 5.1.1.1) e Agrupamento das atividades em sub-processos (Seção 5.1.1.2).

a) 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 Integração de Produto.

Meta específica Práticas específicas SG 1.0

Preparar para a integração do produto

SP – 1.1-1 Determinar a seqüência de integração; SP – 1.2-1 Estabelecer o ambiente de integração; SP – 1.3-1 Estabelecer os procedimentos e critérios; As áreas 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 às 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ão armazenados os artefatos de saída e mídia utilizada.

Tabela 2 – Prática Específica SP – 1.1-1 Determinar a seqüência de integração.

Atividade Atores Área de Processo

SG 1.0 - SP 1.1-1

Determinar a Seqüência

de Integração

Engenheiro de Software, Analista de Integração

1- Identificar os componentes para Integração

Engenheiro de Software

Gerência de acordo com o fornecedor

2 - Identificar as relações entre os componentes

Engenheiro de Software

3 - Identificar uma seqüência para Integração

Analista de Integração

Gerência de Risco

4 - Identificar uma seqüência alternativa para Integração


Gerência de Risco

5

5 - Verificar qual a melhor seqüência


Decisão de Análise de Resolução

6 - Revisar a seqüência de Integração quando necessário


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.

b) 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.

2) Construção do mapa geral

A construção de um mapa geral de processos de software em uma empresa pode ser fundamental para melhorar a forma de execução das atividades. Busca-se ter uma visão clara dos sub-processos necessários para, de maneira ágil, alcançar os objetivos traçados. Também será possível identificar qual sub-processo precisa ser melhorado e, se necessário, redesenhá-lo para se ter uma forma de trabalho mais produtiva e coerente com as atividades desenvolvidas. È possível visualizar um exemplo do diagrama do mapa geral de atividades para o sub-processo de preparação para integração do produto na Figura 3.

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 são 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 utilizados 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 visuais predefinidos internamente. Na criação do diagrama acima foram utilizados símbolos do BPMN [White, 2006], para representação de processos, e o “SPEM Packages”, conforme o mapeamento criado (Seção 3).

B. 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 (Seção 4).

Os elementos foram organizados da seguinte forma: as áreas de processos e perfis habilitados para executar as atividades, localizados à esquerda. As atividades estão no centro do diagrama e seguem 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 4): 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 4). 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.

Figura 3. Mapa geral SG 1.0 Preparar para integração do produto.

6

Figura 4. Diagrama de atividades SP 1.1-1 Determinar a Seqüência de Integração.

7

VI. CONSIDERAÇÕES FINAIS

A modelagem da área de processo do CMMI, utilizando uma metodologia de BPM e notações do SPEM, minimizou o fato de as coletas de informação contidas no CMMI serem exaustivas para os consultores, transformando em uma modelagem por 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 tornaram a leitura e a interpretação mais dinâmicas.

As informações geradas pela modelagem proposta, utilizando os modelos previamente construídos em uma ferramenta de BPM, possibilitam a reutilização e são adaptáveis a outras empresas. Uma modelagem completa da área de Integração de Produto foi realizada como exemplo, e seus documentos podem ser vistos em http://www.jaguaracisilva.blogspot.com. 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

[1] Bonapart (2007) “Ferramenta de Modelagem de Processo de Negócios”, Disponível em http://www.emprise-process.com/, acessado em agosto de 2007.

[2] Booch, G., Jacobson, I., Rumbaugh, J. (2005) “Unified Modeling Language User Guide”, Addison-Wesley, 2a. Edição.

[3] Chrissis, M. B., Konrad M., Shrum S. (2001) “CMMI: Guidelines for Process Integration and Product Improvement”, Addison Wesley, Fevereiro.

[4] Crosby, P. B. (1979) “Quality is Free”, McGraw Hill, Book Co., 309p. [5] Deming, W. E. (1986) “Out of Crisis”, MIT Center for Advanced

Engineering Studies, Cambridge, MA. [6] Humphey, W. (1989) “Managing the Software Process”, Reading, Mass.:

Addison-Wesley. [7] ISO (2003) “ISO/IEC TR 15504 - The International Organization for

Standardization and International Eletrotechnical Commission”, Information Technology – Software Process Assessment, Outubro.

[8] Juran, J. M. (1989) “On leadership for Quality”, New York: Free Press. [9] OMG (2005) “Software Process Engineering Metamodel Specification”,

Object Management Group, Janeiro, Versão 1.1. [10] Paulk M. C., et al. (1993) “The Capability Maturity Model for Software”,

Version 1.1, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA.

[11] 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. (2006) “Metodologia de Processos de Negócios”, Universidade Federal da Bahia, Programa de Residência em Software com foco em e-government, disponível em http://twiki.im.ufba.br/bin/view/Residencia/Trabalhos, acessado em agosto de 2007.

[12] SEI CMMI (2002) “The Capability Maturity Model for Software”. Version 1.1- CMU/SEI-2002-TR-012, March.

[13] White, S. A. (2006) “Introduction to BPMN”, IBM. BPMN Articles and Papers. Disponível na Internet em http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf, acessado em março de 2008.