Gestão Estratégica da Tecnologia da Informação

Gestão Estratégica da Tecnologia da Informação

Pós-Graduação a distância

Gestão da Qualidade com Ênfase em BPM

Profº. João Caldas

Sumário

Introdução ............................................................................................................ 4

Conceitos relacionados a qualidade ....................................................................... 5

Qualidade do produto ...........................................................................................................6

Qualidade de processo .........................................................................................................6

Organizações Maduras x Organizações Imaturas .......................................................................7

Qualidade total ....................................................................................................................8

Qualidade e o ciclo de vida do Produto ....................................................................................9

Primeiros Modelos de Qualidade .............................................................................................9

Garantia da Qualidade ......................................................................................................... 10

Qualidade segundo PMBOK ................................................................................................... 11

Qualidade de Produtos de Software ...................................................................... 12

O que é Avaliação de Produtos de Software? ........................................................................... 12

Modelos de Qualidade ISO .................................................................................................... 13

Outras normas da ISO ......................................................................................................... 16

Qualidade de Processo de Software ...................................................................... 16

Modelos ISO para qualidade de processo de software ............................................................... 16

Modelos CMM para qualidade de processo de software .............................................................. 17

CMM versus CMMI ............................................................................................................... 20

CMMI ................................................................................................................................ 20

Histórico do CMMI ............................................................................................................... 21

O Modelo CMMI .................................................................................................................. 22

Representação Contínua ..................................................................................................................... 22

Representação por estágio .................................................................................................................. 23

Estrutura do modelo .......................................................................................................................... 23

Níveis de Maturidade ......................................................................................................................... 24

Disciplinas (áreas de Conhecimento) do CMMI ....................................................................................... 26

Categorias dos Componentes de uma Área de Processo ........................................................................... 27

Componentes de Modelo .................................................................................................................... 27

Metas Específicas .............................................................................................................................. 28

Práticas Específicas ........................................................................................................................... 28

Características Comuns ...................................................................................................................... 28

Produtos de Trabalho ......................................................................................................................... 29

Sub práticas ..................................................................................................................................... 29

Amplificações de disciplinas ................................................................................................................ 29

Metas genéricas ................................................................................................................................ 29

Práticas genéricas ............................................................................................................................. 29

Referências ...................................................................................................................................... 29

Comparações de representações de modelo ........................................................................................... 30

Nível de Maturidade 2: Gerenciado ........................................................................................ 30

Modelagem de Processos de Negócio .................................................................... 37

O que são processos ........................................................................................................... 39

Gestão por processos .......................................................................................................... 41

O Ciclo de Vida dos Processos de Negócio ............................................................................... 43

Captura da Definição do Processo ........................................................................................................ 43

Reengenharia do Processo .................................................................................................................. 44

Implementação do Processo ................................................................................................................ 44

Melhoria Contínua do Processo ............................................................................................................ 45

Gerenciamento de Processos de Negócio ................................................................................ 45

Modelagem e Otimização de Processos ................................................................................... 47

Automação de Processos – Workflow ...................................................................................... 49

O Ciclo do Workflow ........................................................................................................................... 51

Tipos de Workflow ............................................................................................................................. 51

Sistemas de Gerenciamento de Workflow .............................................................................................. 54

Escolha de um Sistema de Workflow .................................................................................................... 56

Metodologias de Modelagem de Processos .............................................................................. 57

Metodologia de Jacka & Keller (2002) ................................................................................................... 58

Referências .......................................................................................................... 61

www.posugf.com.br


4

IntroduçãoOs produtos de software possuem

atualmente um papel muito influente na vida humana, facilitando a realização de diversas atividades e provendo inúmeros serviços. O desenvolvimento de um produto de software com elevada produtividade, dentro do prazo estabelecido, sem necessitar de mais recursos do que aqueles alocados, assegurando um software de qualidade, têm sido um desafio da Engenharia de Software .

Apesar do reconhecimento em relação às facilidades que os produtos de software nos proporcionam, e de sucessos em sistemas maiores e em diferentes domínios, como por exemplo, o setor de transportes e pesquisas espaciais, ainda há muito que melhorar na qualidade dos produtos de software desenvolvidos (PFLEEGER, 2004). Neste contexto, a aplicação eficaz e eficiente da engenharia de software é fundamental para aprimorar a qualidade dos produtos desenvolvidos, diminuindo os custos de desenvolvimento do produto, e aumentando a produtividade e o tempo de atendimento ao mercado.

Alguns problemas ainda são comuns no desenvolvimento de software, isto se deve principalmente pelo aspecto não repetitivo do desenvolvimento de produtos de software o que torna a garantia da qualidade uma atividade difícil e, muitas vezes, imprevisível. A delimitação do escopo de sistemas e/ou produtos de software também não é uma tarefa trivial. Muitas vezes o usuário não consegue definir com precisão todos os requisitos necessários ao projeto. Além disso, ainda existe a volatilidade dos requisitos, que representa um aspecto muito comum no desenvolvimento de software.

Todo este cenário faz com que a importância da área de garantia da qualidade cresça continuamente nas organizações de desenvolvimento de software, pois a gerência de alto nível utiliza os resultados produzidos

por esta área para obter visibilidade da qualidade dos processos executados e dos produtos entregues aos clientes, além de tomar decisões estratégicas de negócio baseados em dados consolidados das atividades de garantia da qualidade. Estes e outros fatores aumentam a complexidade e a relatividade do conceito de qualidade de software devido à sua forte dependência da perspectiva de quem está avaliando determinado produto ou serviço.

Segundo PRESSMAN (2005), a garantia da qualidade de software está diretamente relacionada às características de qualidade do processo de desenvolvimento e de seus produtos intermediários, bem como aos esforços de melhoria de processos das organizações. Além disso, as atividades de garantia da qualidade devem estar presentes ao longo de todo o ciclo de vida de desenvolvimento do software, a fim de assegurar que o projeto, o desenvolvimento e a disponibilização de uma aplicação aconteçam de maneira bem sucedida. Para isso, normalmente as organizações definem padrões, processos e procedimentos que devem ser seguidos para assegurar a uniformidade e o controle com relação ao desenvolvimento e à manutenção de software. Estes padrões podem incluir especificação, documentação, revisões, auditorias e padrões de engenharia de software, que geralmente encontram-se especificados em um plano de garantia da qualidade.

A área de garantia da qualidade é constituída por um conjunto de atividades sistemáticas que provêem evidência da capacidade do processo de software de desenvolver um produto que atenda aos seus propósitos. Este conjunto de atividades que compõe a área de garantia da qualidade é tratado como atividades de um processo de apoio na implantação de outros processos e na elaboração e avaliação de produtos de trabalho gerados por estes processos.

www.posugf.com.br


5

No entanto, a execução de atividades para atingir graus elevados de qualidade em produtos e processos de software requer a aplicação de muitos recursos. Além disso, qualidade não pode ser considerada sinônimo de perfeição, pois trata-se de algo factível, relativo, substancialmente dinâmico e evolutivo, adequando-se ao nível dos objetivos a serem atingidos. Portanto, o mais importante é atingir o nível de qualidade desejado pelos usuários e necessário para o bom funcionamento dos produtos desenvolvidos, utilizando o mínimo de recursos possíveis para não impactar nos projetos (BOEGH et al., 1993).

O principal objetivo da garantia da qualidade é assegurar que padrões, procedimentos e políticas utilizados durante o desenvolvimento do software sejam adequados para prover o nível de confiança requerido para o processo ou produto de trabalho. No entanto, este nível de confiança varia de acordo com os diferentes tipos de usuários dos produtos de software, bem como o grau esperado de adequação do produto aos propósitos para os quais foi desenvolvido. Portanto, deve-se considerar que usuários diferentes provavelmente terão propósitos diferentes para o desenvolvimento de um mesmo produto.

De acordo com o glossário padrão de terminologia em engenharia de software do IEEE 610.12 (1990), qualidade pode ser definida como o grau no qual um sistema, componente, ou processo atende aos requisitos especificados, e às necessidades ou expectativas do cliente ou usuário. Da mesma forma, a norma ISO/IEC 9126 (1991) define qualidade como a totalidade de funcionalidades e características de um produto ou serviço que atendem à sua capacidade de satisfazer necessidades específicas ou implícitas. Além disso, esta norma ainda define uma lista de características de qualidade que um produto de software deve atender, como

funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

No contexto de desenvolvimento de software, qualidade pode ser entendida como um conjunto de características a serem satisfeitas em um determinado grau, de modo que o produto de software atenda às necessidades explícitas e implícitas de seus usuários (ROCHA et al., 2003). No entanto, ainda não está claramente definido como desenvolver produtos de software de qualidade, embora a qualidade do produto seja considerada fortemente dependente da qualidade e adequação de seu processo de desenvolvimento.

Conceitos relacionados a

qualidadeExistem diversas definições para o termo

qualidade, o que torna impossível ter-se uma postura em definitivo para a idéia do que seja realmente qualidade. O certo é que a mesma chegou para ficar, seja no trabalho, em casa, na produção de bens ou na prestação de serviços. Enfim, em qualquer atividade humana, a qualidade tornou-se consenso. Aqui, a ênfase será dada não só para a qualidade do produto, mas de forma idêntica para a qualidade da prestação de serviço (processo). A seguir serão feitos comentários do que seja realmente qualidade do produto, posteriormente, a ênfase será dada para a qualidade do processo.

Antes, porém, de serem feitas as considerações anteriores, será feito um breve retrospecto das principais etapas do movimento da qualidade. A qualidade num primeiro momento, era vista fundamentalmente sob a ótica da inspeção, na qual, através de instrumentos de medição, tentava-se alcançar a uniformidade do produto; posteriormente, buscava-se através de instrumentos e técnicas estatísticas conseguir um controle estatístico da

www.posugf.com.br


6

qualidade; a terceira etapa do movimento da qualidade está mais preocupada com a sua própria garantia. Para isso, coordena de forma tal toda o processo produtivo desde o projeto do produto até a sua chegada ao mercado consumidor; finalmente, a ênfase volta-se para o gerenciamento estratégico da qualidade, no qual a preocupação maior é poder concorrer num determinado mercado, buscando-se não só satisfazer as necessidades do consumidor, mas também a do próprio mercado. A metodologia que vai dar sustentação a essa nova mentalidade baseia-se no planejamento estratégico, no qual sob a liderança da direção, todos na empresa passam a ter a oportunidade de serem também agentes da qualidade.

Qualidade do produto

A qualidade de produto é a rigorosa definição das características relevantes do produto, estabelecendo os atributos e as variáveis que deve conter cuja dimensão deve ser assegurada. A especificação é o documento que formalizará essas definições.

Há duas formas de alcançar a conformidade à especificação. Uma é a inspeção final rigorosa que segrega os produtos sem qualidade. Essa é uma alternativa cara, já que espera o consumo de material, capital, mão de obra para, só ao final do processo produtivo, separar o bom produto. Gera imenso desperdício. A outra possibilidade é introduzir a qualidade ao longo do processo produtivo, desde a verificação da conformidade dos insumos até suas especificações, evitando a cada fase a má qualidade.

A qualidade no processo procura identificar a má qualidade o quanto antes, o que é feito pelo controle da conformidade à especificação, e corrigir o problema, evitando que continue o desperdício até o fim. Para garantir a conformidade à especificação ao longo do processo, é necessário especificar como executar atividades e seus resultados e controlar sistematicamente todo esse processo que irá atingir a qualidade. É preciso

ainda identificar e eliminar as fontes da má qualidade, mediante alterações apropriadas no processo, ou seja, nas especificações de suas atividades. Para tornar isso viável, surgiram os sistemas formais da qualidade, como por exemplo, a série de normas produzidas pela International Organization for Standardization(ISO).

Qualidade de processo

A qualidade de processo é a rigorosa especificação dos processos que serão realizados na produção de um bem ou serviço, incluindo as faixas de tolerância desejada dos resultados.

Aqui deve-se levar em consideração a definição de qualidade como adequação ao uso. Por exemplo, pode-se imaginar a existência de um cliente, que vai receber o bem ou serviço, cujas necessidades de uso precisam ser satisfeitas. Com o conceito de adequação ao uso, explicita-se que o produto deve cumprir as funções básicas que resolvem os problemas do cliente e, ao mesmo tempo, atender às características conexas como nível de desempenho, durabilidade, pouca manutenção e facilidade de uso, entre outras.

Abaixo, algumas perguntas que realçam essa perspectiva e apontam as consequências para os processos de produção:

● Quem são os clientes visados? ● O que desejam e necessitam? ● O que tais necessidades signifi-cam para os produtos e proces-sos?

● Quais características devem ter um produto/serviço para satis-fazê-las?

● Como fabricar esse produto ou prestar esse serviço?

Com isso, vê-se que o conceito de adequação ao uso também se dirige para a qualidade no processo. A qualidade não pode ser alcançada apenas com a verificação de conformidade dos resultados parciais em pontos escolhidos do processo. A qualidade no processo é mais que isso. Exige que

www.posugf.com.br


7

os processos sejam concebidos de forma a maximizar a produção de bens e serviços que atendam às especificações. Nasce a qualidade total. A preocupação é garantir qualidade em cada atividade realizada no processo de produção e evitar erros, de modo a produzir certo da primeira vez e até eliminar a necessidade de inspeções, as quais perdem sentido quando cada etapa entrega seus resultados sem defeitos para a etapa seguinte e se implanta um processo explícito para melhorar sistematicamente os processos, de modo a sempre aumentar a qualidade no processo.

Organizações Maduras x Organizações Imaturas

Organização Imatura Organização Madura

Processos de software improvisados pelos participantes durante o curso do projeto.

Atividades planejadas de acordo com o processo existente.

Mesmo que um processo de software tenha sido especificado ele não é seguido.

Processo disciplinado é consistentemente seguido porque os participantes entendem o seu valor e existe a infra-estrutura necessária para suportá-lo.

Gerentes focados em resolver problemas imediatos

Gerentes monitoram a qualidade do produto e do processo.

Cronogramas e orçamentos estourados e não baseados em estimativas realistas.

Cronogramas e orçamentos baseados em dados históricos e realísticos.

Quando prazos irrealísticos são impostos à equipe de desenvolvimento, a qualidade e funcionalidade do produto saem comprometidas.

Processo definido atualizado quando necessário. As melhorias são descobertas através de testes pilotos controlados e da análise da relação custo/benefício.

Não há base para julgar a qualidade do produto ou para resolver problemas no processo ou produto.

Base quantitativa para julgar qualidade e para analisar problemas com o produto ou processo.

Qualidade do produto imprevisível. Capacidade de gerenciar o desenvolvimento e manutenção dos processos e projetos.

Atividades que visam garantir a qualidade dos produtos (revisões e testes) são eliminadas quando o projeto está atrasado.

Papéis e responsabilidades estão claros dentro da organização.

www.posugf.com.br


8

Qualidade totalQualidade Total é a preocupação com

a qualidade em todas as atividades da empresa, buscando sistematicamente o zero defeito pela melhoria contínua dos processos de produção.

Os princípios da Qualidade Total estão fundamentados na Administração Científica de Frederick Taylor (1856-1915), no Controle Estatístico de Processos de Walter A. Shewhart (1891-1967) e na Administração por Objetivos de Peter Drucker (1909-2005). Seus primeiros movimentos surgiram e foram consolidados no Japão após o fim da II Guerra Mundial com os Círculos de Controle da Qualidade, sendo difundida nos países ocidentais a partir da década de 1970.

O termo TQM (Total Quality Management ou Gerenciamento da Qualidade Total), amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. De acordo com Kan (2003), “O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica.” (KAN, 2003). Independente dos seus vários tipos de implementação, os elementos chave do TQM podem ser resumidos conforme Figura 1, abaixo:

Figura 1: Elementos chave do Gerenciamento da Qualidade Total (TQM).

a) Foco do Cliente (Customer Focus) - O objetivo é atingir a satisfação total do cliente. O foco do cliente inclui o estudo das necessidades e vontades do cliente, coleta de requisitos do cliente e a medição e gerenciamento da satisfação do cliente.

b) Melhoria de Processo (Process Improvement) - O objetivo é reduzir as variações de processo e atingir a melhoria da qualidade contínua. Este elemento inclui ambos os processos de negócio e o processo de desenvolvimento do produto. Através da melhoria de processo, a qualidade do produto será reforçada.

c) Lado Humano da Qualidade (Human Side of Quality) - O objetivo é criar a cultura de qualidade por toda a empresa. As áreas de foco incluem liderança, apoio da alta gerência, participação total de todos os colaboradores da empresa, e outros fatores humanos como sociais e psicológicos.

d) Métricas, Modelos, Medições e Análises (Metrics, Models, Measurement and Analysis) - O objetivo é direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de medição orientado a metas.

Na organização moderna, portanto, qualidade significa simultaneamente adequação ao uso, conformidade às especificações e qualidade total no processo. Chega-se assim ao ponto que nos interessa. O processo de gerar as especificações de um produto chama-se desenvolvimento do produto. Por meio desse processo, necessidades e desejos do cliente, muitas vezes denominados requisitos, são transformados em especificações do produto e do processo. Tais especificações devem definir com rigor as características do produto e do processo que permitirá reproduzi-las. Isso implica adequação das especificações ao ambiente operacional de produção ou aos requisitos relacionados a manufatura. Como outro objetivo explícito, permite ainda alcançar baixos custos unitários.

Há muita evidência apontando o alto impacto do projeto do produto sobre a qualidade e os custos do produto. Não há uma estimativa consensual desses números, mas é comum entre especialistas avaliar que 60% a 80% dos custos unitários e da qualidade final do produto são estabelecidos no projeto, sobrando o restante para o processo de melhoria contínua.

www.posugf.com.br


9

Assim, na essência da qualidade de produto está a qualidade do processo de produção. E ambas dependem de uma boa qualidade de projeto, sem a qual se corre o risco de não alcançar nível suficiente de adequação ao às necessidades do cliente.

Qualidade e o ciclo de vida do Produto

A qualidade final de um produto resulta de um conjunto de características imputadas a ele ao longo de todo o seu ciclo de vida, que é entendido aqui como envolvendo as fases de concepção, projeto, produção e distribuição e consumo do produto. Ressalte-se que há outro conceito de ciclo de vida do produto vinculado ao aspecto satisfação das necessidades do cliente. Este conceito procura relacionar os níveis de venda com o tempo de maturação do produto e envolve as fases de lançamento, estagnação e declínio ( ou criação, difusão e desuso do produto). O conceito de ciclo de vida do produto utilizado em Controle de Qualidade é o explicitado inicialmente.

A qualidade final seria o resultado da soma e interação das características de qualidade introduzidas em cada uma das fases de obtenção do produto, não dependendo, portanto, exclusivamente, de uma única fase, como algumas vezes pode se imaginar. Portanto, não basta, por exemplo, que um produto tenha boas características de projeto se o processo de produção não for capaz de produzir tais especificações. Também não é o suficiente uma situação em que o processo tem grandes potencialidades para atingir as especificações se estas não forem condizentes com um bom projeto.

O uso genérico do termo qualidade para diferentes situações e etapas do ciclo de vida do produto dificulta o entendimento da questão da qualidade, uma vez que não se especifica a que tipo de qualidade, ou seja, à qualidade de qual fase do ciclo do produto está referindo-se.

Adaptando-se o conceito de qualidade às fases do ciclo de vida do produto, resultam nas seguintes categorias:

● Qualidade de projeto ● Qualidade de formação ● Qualidade de serviços

A qualidade de projeto refere-se ao grau em que o produto, através de sua concepção e especificações, atende às características de qualidade desejadas pelo consumidor. A qualidade de conformação seria o grau em que o bem é produzido em conformidade com as especificações estabelecidas pelo projeto.

A qualidade de serviços diz respeito às facilidades disponíveis para se assegurar a continuidade do produto em operação durante a etapa de seu consumo. Estas facilidades seriam assistência técnica, manutenção, orientação quanto ao uso do produto, etc.

Na prática, estas categorias muitas vezes são confundidas. Assim não se faz muita distinção entre falhas decorrentes de um projeto deficiente e aquelas oriundas da falta de conformidade durante a produção. No entanto, a distinção entre qualidade de projeto e qualidade de conformação é importante, uma vez que esta representa significações marcadamente distintas, e que, geralmente, não é devidamente diferenciada e explicitada.

A qualidade final de um produto, também chamada qualidade de uso, resulta da soma e interação destas três categorias. A grosso modo pode-se dizer que a qualidade de projeto está associada à qualidade intrínseca do produto, ou seja, à qualidade inerente ao próprio produto, enquanto a qualidade de conformação está associada aos níveis de qualidade obtidos na produção, ou, em sentido inverso, aos níveis de defeituosos.

Primeiros Modelos de Qualidade

Um dos primeiros modelos de qualidade de software é o que McCall e Cavano (1978) sugerem como métricas para qualidade

www.posugf.com.br


10

de software. Conhecido como Fatores da Qualidade, estes fatores avaliam o software em três pontos distintos: Transição do Produto, Revisão do Produto e Operação do Produto. Na Figura 2 são mostrados os Fatores da Qualidade de McCall:

Figura 2: Os Fatores da Qualidade (McCall).

Colocando-se todos esses conceitos dentro do contexto apresentado, podemos dizer que qualidade não é uma fase do ciclo de desenvolvimento de software, mas sim integrante fundamental de todas as fases.

Portanto, é necessário um planejamento adequado para que a qualidade de software seja atingida, conforme a definição de qualidade que deverá ser alcançada. Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir essas metas de qualidade propostas. Para tanto, todas as etapas do ciclo de vida de engenharia de software devem ser contempladas com atividades que visam garantir a qualidade tanto do processo quanto do produto.

Garantia da Qualidade

Podemos definir como Garantia da Qualidade (Quality Assurance) o conjunto de atividades de apoio para fornecer confiança

de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido.

Portanto, isso consiste em realizar a qualidade tanto do processo quanto to produto. No processo, podemos quantificar a sua qualidade através de métricas para qualidade e no produto com as técnicas de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, auditorias, inspeções formais, testes, revisões. Ainda no processo podemos usar os métodos de garantia da qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e análise estatística de controle do processo. No produto os métodos de garantia da qualidade são revisões, inspeção formal e testes, além de revisão dos resultados do teste realizada por profissionais altamente capacitados, auditorias do produto e testes realizados pelo cliente.

Não podemos confundir os conceitos e a aplicação dos termos Controle da Qualidade (Quality Control) e Garantia da Qualidade (Quality Assurance). Embora usados erroneamente em muitos lugares, ambos os termos têm propósitos totalmente diferentes.

Vejamos a Tabela 1 que mostra a diferença entre estas duas atividades [IPCC, 2009]:

www.posugf.com.br


11

Garantia da Qualidade Controle da Qualidadea) Garantia da qualidade garante que o processo é definido e apropriado. b) Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. c) Garantia da qualidade é orientada a processo. d) Garantia da qualidade é orientada a prevenção. e) Foco em monitoração e melhoria de processo. f) As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software. g) Garantia da qualidade garante que você está fazendo as coisas certas e da maneira correta.

a) As atividades de controle da qualidade focam na descoberta de defeitos em i específicos. b) Um exemplo de controle da qualidade poderia ser: “Os requisitos definidos são os requisitos certos?”. c) Controle da qualidade é orientado a produto. d) Controle da qualidade é orientado a detecção. e) Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados. f) As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. g) Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.

Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software é orientado a produto e está dentro do domínio do controle da qualidade.

Qualidade segundo PMBOK

De acordo com o PMBOK (Project Management Body Of Knowledge) do PMI (Project Management Institute), na versão 2004, os processos de gerenciamento da qualidade do projeto detêm todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles desenvolvem o sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao fim, conforme adequado.

Com isso os três principais processos são:a) Planejamento da Qualidade: Identificação dos padrões de qualidade relevantes para o

projeto e determinação de como satisfazê-los.b) Garantia da Qualidade: Aplicação das atividades de qualidade planejadas e sistemáticas

para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.

c) Controle da Qualidade: Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

Há diversas semelhanças entre os conceitos usados no PMBOK e os conceitos da própria ISO. Com isso, é possível ainda relacionar estes três processos do PMBOK com as definições de qualidade de processo, qualidade de projeto, controle da qualidade, garantia da qualidade e arquitetura de software.

Neste contexto a arquitetura de software passa a ser de grande importância para a qualidade de um software. O software, de modo genérico, é uma entidade que se encontra em quase constante estado de mudança. As mudanças ocorrem por necessidade de

www.posugf.com.br


12

corrigir erros existentes no software ou de adicionar novos recursos e funcionalidades. Igualmente, os sistemas computacionais (isto é, aqueles que têm software como um de seus elementos) também sofrem mudanças frequentemente. Essa necessidade evolutiva do sistema de software o torna ‘não confiável’ e predisposto a defeitos, atraso na entrega e com custos acima do estimado. Concomitante com esses fatos, o crescimento em tamanho e complexidade dos sistemas de software exige que os profissionais da área raciocinem, projetem, codifiquem e se comuniquem por meio de componentes de software. Como resultado, qualquer concepção ou solução de sistema passa então para o nível arquitetural, onde o foco recai sobre os componentes e relacionamentos entre eles num sistema de software.

Video You Tube - Webcast: http://www.youtube.com/watch?v=n8sAGdxmsaQ&feature=related

Qualidade de Produtos de

SoftwareDesenvolver software com qualidade

tem sido o grande desafio do mercado atualmente. Cumprir prazos, atender aos requisitos do software, estimar custos e recursos, não são tarefas simples. É necessário um controle muito grande dos processos que envolvem a fabricação do software, desde a sua criação até a sua completa instalação no cliente. Um desafio ainda maior é identificar se, ao final do processo de desenvolvimento, o software atende aos requisitos funcionais e não funcionais pré-estabelecidos. Para tanto, vários investimentos foram realizados e processos de Avaliação de Produtos de Software foram desenvolvidos.

O que é Avaliação de Produtos de Software?

A avaliação de produtos de software é definida como uma operação técnica que

consiste em elaborar um julgamento de uma ou mais características de um produto de software de acordo com um procedimento definido. O processo de avaliação deve possuir 4 características principais [WEBBER ET AL ,2001]:

1.Repetível;2.Reprodutível;3.Imparcial;4.Objetivo.Além do objetivo principal de alcançar a

qualidade, estas avaliações podem ter como objetivo a obtenção de certificações de qualidade que são adquiridas por meio da utilização de normas fornecidas por uma organização, a organização mais conhecida na área de certificações de qualidade é a International Organization for Standardization - ISO (Organização Internacional de Normalização), que tem promove o desenvolvimento de normas, testes e certificação, com o intuito de encorajar o comércio de bens e serviços. Esta organização é formada por representantes de 91 países, cada um representado por um organismo de normas, testes e certificação. Por exemplo o American National Standards Institute (ANSI) é o representante ISSO dos Estados Unidos e no Brasil a ISO é representada pela ABNT (Associação Brasileira de Normas Técnicas). A ABNT é uma organização de normas que apóia o desenvolvimento de normas consensuais e providência estrutura e mecanismos a fim de que grupos industriais ou de produtos se juntem para estabelecer um consenso e desenvolver diretivas de qualidade.

A ISO definiu, através da norma ISO 14598, macro-processos de avaliação de qualidade de produtos de software. Estes macro-processos podem ser instanciado para avaliação do produto por desenvolvedores, adquirentes ou agentes externos dependendo dos objetivos e infra-estrutura da organização.

Abaixo é mostrado o processo proposto na ISO 14598-5 para avaliação por agentes externos.

www.posugf.com.br


13

Figura 2: Processo de Avaliação de Software - ISO 14598-5

Cada fase descrita acima possui uma série de recomendações, porém, como toda norma, ela recomenda o que fazer, mas não explica como deve ser feito. Como pode ser visto na Figura 2, as principais etapas são:

● Estabelecimento dos requisitos da avaliação, onde os requisitos do software são recebidos e os requisitos da avaliação são defi-nidos

● Especificação da Avaliação, onde utiliza-se a descrição do produto e os requisitos da avaliação para definir o que será contemplado na avaliação

● Projeto da Avaliação, onde agrega-se os dados utilizados na etapa anterior ao conhecimento de métodos de avaliação e proje-ta-se o Plano de Avaliação

● Execução da Avaliação, onde usam-se as ferramentas específi-cas para por o Plano de Avaliação em prática

● Conclusão da Avaliação, onde o Relatório de Avaliação é emitido e todos os resultados obtidos são sintetizados e emite-se um parecer ao requisitante da aval-iação.

As etapas “Estabelecimento dos requisitos da avaliação” e “Especificação da avaliação” são etapas crucias da avaliação, pois é neste momento que precisamos definir o QUE será

medido no software e quais são os níveis aceitáveis dessas medidas.

Essa definição não é uma tarefa fácil e além dessa dificuldade ainda enfrentamos o problema da imaturidade da indústria de software que veio se consolidar como indústria propriamente dita há menos de 50 anos. Bastante diferente da engenharia, por exemplo, que já possui maturidade, padrões muito bem definidos e quantificáveis.

Modelos de Qualidade ISO

Para que a avaliação seja mais efetiva é importante que se utilize um modelo de qualidade que permita estabelecer e avaliar requisitos de qualidade e também que o processo de avaliação seja bem definido e estruturado.

Na norma ISO 14598 recomenda-se a utilização do modelo de qualidade proposto na ISO 9126, que é o mais difundido na indústria. Este modelo propõe a divisão da qualidade do produto de software em qualidade interna, externa e em uso. A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, com cada uma delas divididas em sub-características, conforme podemos ver na figura abaixo:

www.posugf.com.br


14

Figura 3: Modelo de Qualidade - ISO 9126 (Qualidade interna e externa)

No nível mais alto temos as características de qualidade e nos quadros abaixo as suas sub-características. Cada característica/sub-característica compõe um Atributo de Qualidade do software.

Note que em todas as características temos uma sub-categoria com o nome de Conformidade. A conformidade é utilizada para avaliar o quanto o software obedece aos requisitos de legislação e todo o tipo de padronização ou normalização aplicável ao contexto.

FuncionalidadeA capacidade de um software prover funcionalidades que satisfaçam o usuário em suas

necessidades declaradas e implícitas, dentro de um determinado contexto de uso.Suas sub-características são:

● Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;

● Acurácia (ou precisão) representa a capacidade do software de fornecer resulta-dos precisos ou com a precisão dentro do que foi acordado/solicitado;

● Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s) especificados;

● Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas (e sempre) às pessoas autorizadas;

ConfiabilidadeO produto se mantém no nível de desempenho nas condições estabelecidas.Suas sub-características são:

● Maturidade, entendida como sendo a capacidade do software em evitar falhas decorrentes de defeitos no software;

● Tolerância a Falhas representando a capacidade do software em manter o fun-cionamento adequado mesmo quando ocorrem defeitos nele ou nas suas inter-faces externas;

● Recuperabilidade que foca na capacidade de um software se recuperar após uma falha, restabelecendo seus níveis de desempenho e recuperando os seus dados;

UsabilidadeA capacidade do produto de software ser compreendido, seu funcionamento aprendido, ser

operado e ser atraente ao usuário.Note que este conceito é bastante abrangente e se aplica mesmo a programas que não

possuem uma interface para o usuário final. Por exemplo, um programa batch executado

www.posugf.com.br


15

por uma ferramenta de programação de processos também pode ser avaliado quanto a sua usabilidade, no que diz respeito a ser facilmente compreendido, aprendido, etc. Além disto, a operação de um sistema é uma interface Humano-Computador sujeita às avaliações de usabilidade.

Suas sub-características são: ● Inteligibilidade que repre-senta a facilidade com que o usuário pode compreender as suas funcionalidades e avaliar se o mesmo pode ser usado para satisfazer as suas necessidades específicas;

● Apreensibilidade identifica a facilidade de aprendizado do sistema para os seus potenciais usuários;

● Operacionalidade é como o produto facilita a sua operação por parte do usuário, incluindo a maneira como ele tolera erros de operação;

● Atratividade envolve carac-terísticas que possam atrair um potencial usuário para o sistema, o que pode incluir desde a ad-equação das informações presta-das para o usuário até os re-quintes visuais utilizados na sua interface gráfica;

EficiênciaO tempo de execução e os recursos

envolvidos são compatíveis com o nível de desempenho do software.

Suas sub-características são: ● Comportamento em Relação

ao Tempo que avalia se os tem-pos de resposta (ou de processa-mento) estão dentro das especifi-cações;

● Utilização de Recursos que mede tanto os recursos consu-midos quanto a capacidade do sistema em utilizar os recursos disponíveis;

Manutenibilidade

A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as melhorias ou extensões de funcionalidade quanto as correções de defeitos, falhas ou erros.

Suas sub-características são: ● Analisabilidade identifica a fa-cilidade em se diagnosticar even-tuais problemas e identificar as causas das deficiências ou falhas;

● Modificabilidade caracteriza a facilidade com que o compor-tamento do software pode ser modificado;

● Estabilidade avalia a capacidade do software de evitar efeitos colaterais decorrentes de modifi-cações introduzidas;

● Testabilidade representa a capacidade de se testar o sis-tema modificado, tanto quanto as novas funcionalidades quanto as não afetadas diretamente pela modificação;

PortabilidadeA capacidade do sistema ser transferido de

um ambiente para outro.Como “ambiente”, devemos considerar

todo os fatores de adaptação, tais como diferentes condições de infra-estrutura (sistemas operacionais, versões de bancos de dados, etc.), diferentes tipos e recursos de hardware (tal como aproveitar um número maior de processadores ou memória). Além destes, fatores como idioma ou a facilidade para se criar ambientes de testes devem ser considerados como características de portabilidade.

Suas sub-características são: ● Adaptabilidade, representando a capacidade do software ser a adaptar a diferentes ambientes sem a necessidade de ações adi-cionais (configurações);

● Capacidade para ser Instala-do identifica a facilidade com que pode se instalar o sistema em um novo ambiente;

www.posugf.com.br


16

● Coexistência mede o quão facilmente um software convive com outros instalados no mesmo ambiente;

● Capacidade para Substituir representa a capacidade que o sistema tem de substituir outro sistema especificado, em um contexto de uso e ambiente es-pecíficos. Este atributo interage tanto com adaptabilidade quanto com a capacidade para ser insta-lado;

Outras normas da ISO

A norma ISO/IEC 12119 visa à qualidade de pacotes de software através de: documentação do usuário de fácil compreensão, com sumário e índice; manual de instalação com instruções detalhadas; possibilidade de verificar se uma instalação foi bem sucedida; especificação e verificação de valores limites para todos dados de entrada; consistência de vocabulário entre as mensagens e a documentação. Esta norma é aplicável à avaliação de pacotes de software na forma em que são oferecidos e liberados para uso no mercado. Um Pacote de software é entendido como o conjunto completo e documentado de programas fornecidos a diversos usuários para uma aplicação ou função genérica. Os potenciais usuários desta norma são fornecedores, entidades certificadoras, laboratório de testes, entidades de credenciamento, auditores de laboratório de testes, compradores e usuários que podem se beneficiar com produtos melhor especificados.

A norma ISO/IEC 14598 contém um conjunto de guias para avaliação do software contendo diferentes visões: de quem desenvolve, de quem adquire, de quem faz certificação de software. Inclui modelos para relatórios de avaliação, técnicas para medição de características, documentos necessários

para avaliação e fases de avaliação. Esta norma deve ser usada em conjunto com a série ISO/IEC 9126.

Qualidade de Processo de

Software

Um processo de software bem definido é muito importante, pois, a partir deste, pode-se estabelecer um plano para o desenvolvimento do projeto. A qualidade de processo de software ter no aumento da qualidade do produto reduzindo o retrabalho, obtendo maior produtividade e diminuindo o tempo de desenvolvimento. Assim, aumenta a competitividade de companhias que

obtêm maior precisão nas estimativas de planejamento. Um dos benefícios indiretos da qualidade está relacionado à melhoria da satisfação do cliente e condições de trabalho.

Modelos ISO para qualidade de processo de software

Práticas de qualidade são aplicadas a todas as etapas de desenvolvimento. As normas ISO 9001 [CORTES, 2001] foram desenvolvidas para aplicação em qualquer setor produtivo. Para facilitar sua aplicação em qualidade de software, a ISO desenvolveu o guia ISO 9000-3. Outra norma da ISO para aplicação em desenvolvimento de software é a ISO 12207, que trata dos processos de ciclo de vida de software. A abordagem dessas normas da série ISO é fundamentada nos preceitos da documentação do sistema de qualidade que estabelece a visão da empresa com relação aos interesses e necessidades dos clientes e por isso resulta na percepção desses. A abordagem da ISO para qualidade é considerada uma das mais antigas e estabelecidas para a indústria em geral e tem alguma penetração nas empresas de software.

www.posugf.com.br


17

Na norma ISO/IEC 12207, os processos que envolvem ciclo de vida de software são agrupados em classes que representam sua natureza. Cada processo é definido em termos de suas próprias atividades e cada uma é adicionalmente definida em termos de suas tarefas:

● Processos fundamentais: at-endem ao início, execução do desenvolvimento, operação ou manutenção de software durante o seu ciclo de vida.

● Processos de apoio: provêem su-porte aos outros processos.

● Processos organizacionais: imple-mentam uma estrutura constituí-da de processos de ciclo de vida e pessoal associados, melhoran-do continuamente a estrutura e os processos.

● Processo de adaptação: define as atividades necessárias para adaptar a norma para sua apli-cação na organização ou em projetos.

Esta norma é flexível do ponto de vista da Engenharia de Software podendo ser usada em qualquer método ou técnica da área, qualquer modelo de ciclo de vida (cascata, incremental, evolutivo etc.) e quaisquer linguagens de programação. Implementa os princípios de gerência de qualidade executando três etapas básicas: Integração de qualidade no ciclo de vida; processo de

garantia de qualidade e processo de melhoria.

A norma ISO/IEC 9000-3 estabelece um guia para facilitar a aplicação da ISO/IEC 9001 para desenvolvimento, suporte e manutenção de software. A ISO/IEC 9001 é um padrão internacional que “especifica requisitos para um sistema gerencial de qualidade de uma organização”, o que dificulta adaptação da norma para software, pois é aplicada a qualquer organização.

Vídeo ISO 9001http://www.youtube.com/

embed/6yD5ExXTSsg

A norma ISO/IEC 15504 [CORTES, 2001] está sendo desenvolvida desde 1993 pela ISO em conjunto com a comunidade internacional através do projeto SPICE [CORTES, 2001] (Software Process Improvement and Capability dEtermination) com base nos modelos já existentes como ISO 9000 e CMM.

Em outubro de 2003, a norma ISO/IEC 15504 (SPICE) para a avaliação de processos de software foi oficialmente publicada pela ISO. Esta define um modelo bi-dimensional que tem por objetivo a realização de avaliações de processos de software com o foco da melhoria dos processos (gerando um perfil dos processos, identificando os pontos fracos e fortes, que serão utilizados para a elaboração de um plano de melhorias) e a determinação da capacidade dos processos viabilizando a avaliação de um fornecedor em potencial.

Uma das vantagens desta norma é que integra padrões existentes de forma muito flexível. Mas, sua aplicação na prática requer muito esforço, tempo e experiência consideráveis, o que complica sua aplicação em micro e pequenas empresas de software.

Modelos CMM para qualidade de processo de software

A abordagem CMM [ROCHA, 2003] é mais recente e foi desenvolvida especialmente para software. O CMM é uma marca registrada da SEI (Software Engineering Institute). Este modelo é construído a partir do conceito de processo. Na medida em que a maturidade dos processos de software evoluem em uma determinada empresa, os

www.posugf.com.br


18

processos passam a ser mais definidos e efetivos. O CMM está organizado em uma série de práticas, organizadas em cinco níveis crescentes de maturidade.

Cada nível de maturidade agrega áreas chave de um processo de software. Cada área chave é detalhada nas práticas-chave a serem cumpridas na implantação do modelo. Estas práticas chaves especificam o que deve ser feito, exigindo documentos, treinamentos ou políticas definidas para atividades, mas nunca especificam o modo como devem ser implementadas. Cada área possui um conjunto de metas que, se satisfeitas rotineiramente, tendem a aumentar a capacitação do processo em produzir resultados previsíveis, assegurando a qualidade.

O CMM fornece e descreve um caminho de melhoria evolutiva a partir de um processo ad hoc para um processo maduro e altamente disciplinado. Na Figura 4 são ilustradas as várias etapas de maturação de processo de desenvolvimento de software segundo CMM.

Fonte da imagem: http://www.followscience.com/user_uploads/6764d644ccf54b56914c9e692069a4a5/images/cmm1.png

No nível 1 (Inicial), as qualidades, os procedimentos e conhecimento pertencem às pessoas, e não ao processo. Não há controle de requisitos e o cliente só os avalia na entrega do produto. Os cronogramas, orçamentos, funcionalidades e qualidade do produto são geralmente imprevisíveis.

No nível 2 (Repetitivo), a evolução dos requisitos é controlada de tal forma que o cliente possa avaliá-los ao final de cada marco do projeto. São estabelecidas políticas para gerenciar projetos de desenvolvimento de software bem como procedimentos para implementá-las. O planejamento de novos projetos é baseado em experiência anteriores de projetos semelhantes, já realizados. Para cada projeto são estabelecidos processos que são definidos, documentados, praticados, executados, treinados, medidos, obedecidos e passíveis de melhoria.

www.posugf.com.br


19

No nível 3 (Definido), os processos utilizados são estabelecidos e padronizados em toda a organização. Os envolvidos (gerentes e técnicos) conhecem seus papéis, responsabilidades e a forma com que as atividades interagem entre si. O processo padrão e os processos utilizados para desenvolver e manter software estão documentados. Tanto os processos gerenciais quanto os técnicos passam a ser repetitíveis. Esses processos pertencem à organização e não a uma ou mais equipes.

No nível gerenciado (Nível 4), a organização estabelece metas quantitativas para os seus produtos e processos. O cliente passa a ter um entendimento quantitativo da capacitação e do risco antes do projeto iniciar. A capacitação do processo de software para organizações deste nível é quantificável e previsível.

No nível otimizado (Nível 5), a organização como um todo estará engajada na melhoria contínua de seus processos. É realizada rotineiramente a melhoria do processo como um todo. Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.

O entendimento dos níveis de maturidade do CMM são simples de serem assimilados, a partir do momento que sua estrutura é entendida. Com exceção do nível 1 que não possui nenhum detalhamento, os demais níveis podem ser decompostos em partes estruturais idênticas, porém com conteúdos distintos. Estas partes podem ser visualizadas conforme a Figura 5.

Figura 5: Estrutura do CMM.

A hierarquia mais alta da estrutura compreende os cinco níveis de maturidade do modelo. Cada nível de maturidade à exceção do nível 1, contém uma série de Áreas de Processo-chave (KPA), que compreende o segundo nível hierárquico da estrutura. Os agrupamentos de KPAs de cada nível de maturidade definem uma série de metas que devem ser alcançadas para que o nível de maturidade respectivo possa ser considerado alcançado. Cada KPA se refere a uma área de processo-chave de um determinado nível. Estas áreas de processo-chave definem os aspectos que devem ser atacados para que a maturidade do nível corrente possa ser obtido. As metas de cada KPA definem escopo, limites e intenção para que ações possam ser tomadas e assim as metas possam ser alcançadas. Ao todo o CMM define 18 áreas-chave, 52 objetivos e 316 práticas.

O modelo CMM é comparável à norma ISO 9001, em particular à norma 9000-3. Pode haver um perfil de empresa certificada em ISO que satisfaz a determinadas áreas chave no CMM. Entretanto, essa empresa teria pontos fortes significativos nas áreas chave do nível dois e três, ou seja, poderia satisfazer algumas características de áreas chave deste nível. Também é possível existir empresas que estejam no nível 1 do CMM e que consigam certificação ISSO 9001. Mas é muito provável que uma empresa que obtenha e mantenha um certificado ISO 9001

www.posugf.com.br


20

tenha maturidade medida no nível dois na escala CMM.

Para uma empresa Nível 3 conseguir certificação da série ISO 9001 deve atender a alguns requisitos a mais de elementos normativos desta norma mas empresa Nível 2 não deve encontrar muitas dificuldades em satisfazer os requisitos da ISO 9001.

CMM versus CMMI

De acordo com Royce [9], o modelo inicial de CMM, foi desenvolvido pela SEI e

especificamente destinado à maturação de processo de software. Seu primeiro lançamento em 1990, e depois sua adoção com sucesso e uso em muitos domínios, outros CMMs foram desenvolvidos para outras disciplinas e funções tais como Engenharia de Sistemas, pessoas, desenvolvimento de produto integrado, aquisição de software, e outros. Apesar de muitas organizações acharem estes modelos úteis, eles também encontram problemas causados por sobreposições, inconsistências e integração. Muitas organizações também encontram conflitos de auditoria ou programas de melhorias de software entre estes modelos e ISO 9001.

O projeto CMM Integration (CMMI) [ROYCE,2005] foi concebido como uma iniciativa para integrar os diversos CMMs dentro de um conjunto de modelos integrados. Os modelos que serviram como a base para CMMI inclui: CMM para Software v2.0 (Draft C), EIA-731 Engenharia de Sistemas, e IPD CMM (IPD) v0.98 [CHRISSIS,2003].

Alguns casos associados com a prática de CMM estão repetindo sintomas do modelo tradicional em cascata e processo excessivamente baseado em gerenciamento. A atividade de medição baseada em gerenciamento está mais alinhada com

seqüencial, ou seja, paradigma de atividade baseada em gerenciamento de processo em cascata (por exemplo, fazer atividades de requisitos, integração de atividades e teste de sistema). Isto provavelmente explica porque muitas perspectivas de organizações em CMM seguem princípios de mentalidade de cascata.

Alternativamente, técnicas de desenvolvimento iterativo, melhores práticas de indústria de software, e motivações econômicas guiam organizações a tornarem uma abordagem baseada em resultados: desenvolvimento de casos de negócio, visão e protótipo de solução; elaboração dentro de uma arquitetura de linha de base; elaborar dentro de lançamentos utilizáveis; e então finalizar dentro de campos lançados. O CMMI integra muitas das melhores práticas das indústria moderna, e isto desencoraja padrões de alinhamento com mentalidade de cascata.

CMMI

O CMMI – Capability Maturity Model Integration foi desenvolvido pelo SEI – Software Engineering Institute (Instituto de Engenharia de Software) – sediado na CMU – Carnegie Mellon University – em Pittsburgh, Pennsylvania, Estados Unidos. O SEI é um centro de pesquisa e desenvolvimento criado em 1984 pelo Departamento de Defesa dos Estados Unidos e é patrocinado pelo OUSD (Office of the Under Secretary of Defense for Acquisition and Technology). O SEI tem por missão aprimorar a prática de Engenharia de Software. As áreas de atuação do SEI são: capacitação de gerência de software, tecnologia para a

engenharia, e aptidão para a transição. O SEI focaliza a transição tecnológica, ou seja, o desenvolvimento e a adoção das melhores práticas de engenharia de software.

Como outros CMMs (como engenharia de sistemas, engenharia de software, aquisição

www.posugf.com.br


21

de software), os modelos CMMI (Capability Maturity Model Integration) fornecem um guia a ser usado para o desenvolvimento de processos. Os reais processos usados em uma organização dependem de muitos fatores, incluindo domínios de aplicação e estrutura e tamanho de organização. Em particular, as áreas de processo de um modelo CMMI tipicamente não mapeiam diretamente com processos usados em outra organização.

Histórico do CMMI

O projeto de CMMI foi desenvolvido para fornecer um guia que encoraja o melhoramento de processos em organizações de qualquer estrutura. Desde 1991, modelos de maturidade foram desenvolvidos para as mais diversas disciplinas. Algumas das mais notáveis incluem modelos para engenharia de sistemas, engenharia de software, aquisição de software, gerenciamento de workforce e desenvolvimento, e Produto Integrado e Desenvolvimento de Processo.

Apesar desses modelos provarem utilidade em muitas organizações, o uso de múltiplos modelos tem sido problemático. Muitas organizações gostariam de focar seus esforços de melhoramento através de suas disciplinas. Entretanto, as diferenças entre os modelos específicos dessas disciplinas, incluindo sua arquitetura, conteúdo, e acesso, tem limitado as habilidades das organizações de focarem seus melhoramentos com sucesso. Além disso, aplicar modelos que não são integrados em uma organização torna mais caros treinamento, avaliação, e atividades de melhoramento. Um conjunto de modelos que, com sucesso, se destina a múltiplas disciplinas e tem treinamento integrado e suporte de avaliação resolve estes problemas.

O projeto CMM Integration foi formado para resolver o problema de usar múltiplos

CMMs. A missão do grupo de produto CMMI foi combinar três modelos — (1) Capability Maturity Model for Software (SW-CMM) v2.0 draft C, (2) Electronic Industries Alliance Interim Standard (EIA/IS) 731, e (3) Integrated Product Development Capability Maturity Model (IPDCMM) v0.98 — dentro de uma único arcabouço de melhoramento para uso de organizações aspirando melhoramento dos processos como um todo.

Desenvolver um conjunto de modelos integrados tem envolvido mais que uma simples adição de materiais de modelos existentes juntos. Usando processos que promovem consenso, o grupo de produto CMMI construiu um arcabouço que acomoda múltiplas disciplinas e é bastante flexível para apoiar duas representações diferentes (por estágio e contínuo).

Usando informação de modelos populares e observados como material de pesquisa, o grupo de produto CMMI criou um conjunto coeso de modelos integrados que podem ser adotados por aqueles outros usuais CMMs, bem como por seus novos conceitos CMMI.

Durante a fase de desenvolvimento de projeto CMMI, a missão do grupo incluía o desenvolvimento de um arcabouço comum para apoiar a futura integração de outros modelos CMMI de disciplinas específicas. Além do mais, a missão do grupo incluiu o objetivo de garantir a consistência e compatibilidade de produtos desenvolvidos com ISO/IEC 15504 para avaliação de processo de software.

A versão de CMMI 0.2 (2002) foi revisada em público e usada em atividades-piloto iniciais. Após o lançamento desta versão, melhoramentos foram guiados por requisições de mudanças de revisão pública, organizações-piloto, e vários focus de sessões de grupo. O grupo de produto CMMI avaliou mais que 3.000 requisições de mudanças para criar a versão 1.0. Pouco tempo depois, a versão 1.02 (2002) foi lançada, a qual

www.posugf.com.br


22

incorporou diversos melhoramentos menores. Como com qualquer lançamento, entretanto, a oportunidade para melhoramento futuro permaneceu. Versão 1.1 (2003) acomoda mais melhoramentos de uso recente como bem mais que 1.500 mudanças requeridas.

O Modelo CMMI

O propósito de CMM Integration [CPqD] é fornecer um guia para melhorar processos de organizações e sua habilidade de gerenciar o desenvolvimento, aquisição, e manutenção de produtos ou serviços. O CMM Integration através de sua estrutura, ajuda a organização, avaliar sua maturidade organizacional ou capacidade em área de processo, estabelecendo prioridades para melhoramento, e implementação desses melhoramentos.

A suíte de produtos CMMI contém e é produzida por um arcabouço que fornece a habilidade para gerar múltiplos modelos e materiais de avaliação e treinamento associados. Estes modelos podem refletir conteúdo de corpus (tais como, engenharia de sistemas, engenharia de software, produto integrado e processo de desenvolvimento) em combinação ao mais útil para a organização (CMMI-SE/SW, CMMI-SE/SW/IPPD/SS).

A organização pode usar um modelo de CMMI para ajudar a estabelecer objetivos e prioridades do melhoramento de processos, melhoria de processos, e fornece um guia para garantir estabilidade, processos estáveis e maduros.

É recomendável usar julgamento profissional para interpretar práticas genéricas e específicas de CMMI. Embora áreas de processo descrevam o comportamento que deve ser exibido em qualquer organização, todas as práticas devem ser interpretadas usando um conhecimento profundo de modelo CMMI, da

organização, do ambiente de negócios, e de circunstâncias envolvidas.

Seleção de um modeloHá múltiplos modelos CMMI disponíveis

gerados a partir do arcabouço CMMI.Conseqüentemente, é necessária uma

preparação para decidir qual modelo CMMI melhor se adéqua a uma organização, de acordo com as necessidades de melhoria de processo da organização. Deve ser selecionada a representação, contínua ou por estágios, e quais corpos de conhecimento, serão incluídos no modelo que a organização usará.

Há muitas razões para selecionar uma representação ou outra. Talvez a organização escolherá usar a representação com qual é mais familiar. A seguinte lista descreve algumas das possíveis vantagens e desvantagens de com qual selecionar cada uma das duas representações.

Representação Contínua

Se escolher a representação contínua para a organização o modelo fará o seguinte:

● Permite selecionar a ordem e melhoria que mais se adéqua aos objetivos de negócios da organi-zação e diminui as áreas de risco.

● Habilita que haja comparações em uma empresa e entre empre-sas por área de processo ou pela comparação de resultados em estágio equivalentes.

● Permite uma fácil comparação de melhoria de processo para ISO/IEC (International Organization for Standardization e Internation-al Electrotechnical Commission) 15504, porque organização de área de processo é similar a ISO/IEC 15504.

www.posugf.com.br


23

Representação por estágioSe escolher representação por estágio para

a organização, espera-se que o modelo fará o seguinte:

● Fornece uma seqüência de mel-horias, começando com práticas básicas de gerenciamento, pro-gredindo através de um caminho predefinido provado de níveis de sucessivos, cada um servindo como um fundamento para o seguinte.

● Permite comparações entre or-ganizações pelo uso de níveis de maturidade.

● Fornece uma migração fácil de SW-CMM para CMMI.

● Fornece um valor simples que sumariza resultados avaliados e permite comparações entre or-ganizações.

Se usado para melhoria de processos ou avaliações, ambas as representações são projetadas para oferecer resultados equivalentes.

2.4 Estrutura do modelo por estágioOs componentes dos modelos por

estágio e contínuo são: áreas de processo, metas específicas, práticas específicas, metas genéricas, práticas genéricas, sub práticas, notas, amplificações de disciplinas, elaborações de práticas genéricas e referências.

A representação por estágio organiza áreas de processos dentro de cinco níveis de maturidade, indicando qual área de processo deve ser implementada para alcançar cada nível de maturidade. Níveis de maturidade representam um caminho de melhoria de processo ilustrando evolução da melhoria da organização inteira em busca da melhoria do processo.

Com cada área de processo, as metas específicas e práticas específicas são listadas primeiro, seguidas por metas genéricas e práticas genéricas. A representação por estágio usa quatro características comuns para organizar as práticas genéricas.

Nesta seção,é descrito cada componente de uma representação por estágio, as relações entre os componentes e as relações entre as duas representações. Muitos dos componentes descritos são também componentes de modelos CMMI com uma representação contínua.

Estrutura do modelo

Um modelo CMMI com uma representação por estágio é ilustrado na Figura 6

Modelos CMMI são projetados para descrever níveis discretos de melhorias de processos.Em uma representação por estágios, níveis de maturidade fornecem uma ordem recomendada para acessar melhorias de processos em estágios.

Níveis de maturidade organizam as áreas de processo. Como ilustrado na Figura 6, com as áreas de processo estão metas genéricas e específicas como práticas genéricas e específicas.

Características comuns organizam práticas genéricas. Estas representações focam nas melhores práticas que uma organização pode usar para melhorar processos nas áreas de processo que está no nível de maturidade escolhido para ser alcançado. Antes de começar usar um modelo CMMI para melhoramento de processo, deve-se mapear o processo em áreas de processo CMMI. Este mapeamento permite controlar o melhoramento de processo na organização ajudando a rastrear o nível de conformidade em relação ao modelo CMMI. Não é pretendido que toda área de processo de CMMI mapeie totalmente em um processo da organização.

www.posugf.com.br


24

Níveis de Maturidade

O nível de maturidade de uma organização fornece uma maneira de prever o futuro de desempenho de uma organização como uma dada disciplina ou conjunto de disciplinas. A experiência tem mostrado que organizações fazem o melhor quando focam seus esforços de melhoramentos de processos em número gerenciável de áreas de processo que requerem esforço crescente com o aperfeiçoamento da organização.

Um nível de maturidade é um patamar evolutivo de processo de melhoramento. Cada nível de maturidade estabelece uma parte importante dos processos da organização.

Em modelos CMMI com representação por estágio, há cinco níveis de maturidade, cada nível é base para melhoramento de processo:

1. Inicial2. Gerenciado3. Definido4. Gerenciamento Quantitativo5. Otimizado

Detalhes de Níveis de Maturidade:

Níveis de maturidade consistem em um conjunto pré-definido de áreas de processo. Os níveis de maturidade são medidos pelo alcance de metas específicas e genéricas que aplicam para cada conjunto predefinido de áreas de processo.

Nível de Maturidade 1: Inicial

No nível de maturidade 1, processos são geralmente informais e caóticos e a organização, geralmente, não fornece um ambiente estável. Sucesso nestas organizações depende, da competência e heroísmo de pessoas na organização e não no uso dos processos. Ambientes caóticos, organizações em níveis de maturidade

1 geralmente produzem produtos e serviços que funcionam, entretanto, eles freqüentemente excedem prazo orçamento de seus projetos.

Organizações de níveis de maturidade 1 são caracterizadas pela tendência de ultrapassar compromisso, abandonar processo em tempos de crise, e não ser capaz de repetir seus sucessos anteriores.

Nível de Maturidade 2: Gerenciado

No nível de maturidade 2, uma organização alcança todas as metas específicas e genéricas de áreas de processo. Em outras palavras, os projetos das organizações garantem que requisitos são gerenciados e que processos, são planejados, executados, medidos, e controlados.

A disciplina do processo refletido pelo nível de maturidade 2 ajuda garantir que práticas existentes são retidas durante tempos de estresse. Quando essas práticas estão no lugar, projetos são executados e gerenciados de acordo com os planos documentados.

O status dos produtos e a entrega de serviços são visíveis para controle em pontos definidos (por exemplo, nos principais marcos do desenvolvimento e na conclusão das principais tarefas). Compromissos são estabelecidos entre os stakeholders relevantes e revisados quando necessário. Produtos de trabalho são revisados com os stakeholders e controlados. Os produtos e serviços satisfazem seus requisitos, padrões e objetivos especificados.

Nível de Maturidade 3: Definido

No nível de maturidade 3, uma organização alcançou metas específicas e genéricas das áreas de processo atribuídas aos níveis 2 e 3. No nível da maturidade 3, processos são bem

www.posugf.com.br


25

caracterizados e entendidos, e são descritos como padrões, procedimentos, ferramentas e métodos.

O conjunto de padrões de processos da organização, que são a base para o nível de maturidade 3, é estabelecido e melhorado toda vez. Estes processos de padronização são usados para estabelecer consistência através da organização. Projetos estabelecem seus processos definidos por costurar o conjunto da organização de processos padrões de acordo com guias.

O gerenciamento de organizações estabelece objetivos de processos baseados no conjunto de processos padrão da organização e garante que estes objetivos sejam apropriadamente buscados. Uma distinção entre nível de maturidade 2 e 3 está no escopo de padrões, descrições de processos e procedimentos. No nível de maturidade 2, os padrões, descrições de processos e procedimentos podem estar diferentes de cada instância específica do processo.

No nível de maturidade 3, os padrões, descrições de processos e procedimentos para um projeto são adaptados a partir de um conjunto de processos padrões para se adequar a um projeto particular. O conjunto de processos padronizados da organização inclui os processos que estão no nível de maturidade 2 e 3. Como resultado, os processos que executam através da organização são consistentes exceto para diferenças permitidas para guias.

Outra distinção é que no nível de maturidade 3, processos são tipicamente descritos em mais detalhes e mais rigorosamente que no nível 2. No nível 3, processos são gerenciados mais proativamente usando um entendimento das atividades dos processos e medidas detalhadas dos processos, seu produto e seus serviços.

Nível de Maturidade 4: Quantitativamente Gerenciado

No nível de maturidade 4, uma organização alcançou todas metas específicas das áreas de processo determinadas para os níveis de maturidade 2, 3 e 4 e metas genéricas dos níveis de maturidade 2 e 3. Subprocessos são selecionados que significativamente contribuam a toda parte de desempenho de processo. Estes subprocessos selecionados são controlados usando técnicas estatísticas e outras técnicas quantitativas.

Objetivos quantitativos para qualidade e desempenho de processo são estabelecidos e usados como critério em gerenciamento de processos.

Objetivos quantitativos são baseados em necessidades de clientes, usuários finais, organização, e implementadores de processos. Qualidade e desempenho de processos são entendidos em termos estatísticos e são gerenciados ao longo de vida de processos. Para estes processos, medidas detalhadas do desempenho dos processos são coletadas as fontes e analisadas estatisticamente. Casos especiais de variação são identificados e, quando apropriado, causas especiais são corrigidas para prevenir futuras ocorrências.

Medidas de qualidade e desempenho de processos são incorporados ao repositório de medição da organização para apoiarem tomadas de decisões reais no futuro baseadas em fatos. Uma distinção entre os níveis 3 e 4 está na previsão de desempenho de processo. No nível 4, o desempenho de processos é controlado usando técnicas estatística e outras técnicas quantitativas e é quantitativamente previsível. No nível 3, processos são apenas quantitativamente previsíveis.

Nível de Maturidade 5: Otimizado

www.posugf.com.br


26

No nível 5, uma organização alcançou todas as metas específicas das áreas de processo determinadas para os níveis 2, 3, 4 e 5 e metas genéricas determinadas para os níveis 2 e 3. Processos são continuamente melhorados baseados em entendimentos quantitativos de causas comuns de variação inerente aos processos.

O nível 5 foca na melhoria contínua de desempenho de processo através de melhorias incremental e tecnologicamente inovadora.

Objetivos quantitativos do melhoramento do processo são estabelecidos, continuamente revisados para refletir mudanças de objetivos de negócios, e

usados como critério em gerenciamento de melhoria de processo. Os efeitos de melhoria de processos desenvolvidos são medidos e avaliados com os objetivos quantitativos de melhoria de processos. Ambos processos definidos e conjunto de processos padrões da organização são objetivos de atividades de melhoramento.

Melhoramentos de processos para lidar com causas comum de variação de processos e de melhoramento de processos de organização, de forma mensurável, são definidos, avaliados e desenvolvidos. Melhoramentos são selecionados baseados em entendimento quantitativo de suas contribuições esperadas para alcançar os objetivos de melhoramento de processos da empresa versus o custo e impacto na organização. O desempenho de processos de organização é continuamente melhorado.

Otimizar processos que são ágeis e inovadores depende da participação da força de trabalho alinhada aos valores e objetivos da organização. A habilidade da organização para rapidamente responder a mudanças e oportunidades está melhorada por encontrar maneiras de acelerar e compartilhar aprendizado.

Melhoramento de processos é inerente ao papel de todos, resultando em um ciclo de melhoramento contínuo. Uma distinção entre nível 4 e nível 5 é o tipo de variação de processo com que se lida. No nível 4, processos estão preocupados com causas especiais de variação de processos e fornecem estatística previsível de resultados. Apesar de processos poderem produzir resultados previsíveis, os resultados podem ser insuficientes para alcançar os objetivos estabelecidos. No nível 5, processos estão preocupados em lidar com causas comuns de variação de processos e mudar o processo (isto é, aumentando a média de desempenho do processo) para melhorar performance de processo (enquanto fazendo manutenção de previsão estatística) para alcançar os objetivos quantitativos estabelecidos para o melhoramento do processo.

Disciplinas (áreas de Conhecimento) do CMMI

O objetivo do CMMI é fornecer um CMM que aborde o desenvolvimento do produto ou serviço além da manutenção, mas que permite a inclusão de novas áreas de conhecimento, que são conhecidas como disciplinas do CMMI. Atualmente o CMMI aborda quatro áreas de conhecimento que auxiliam na melhoria do processo: engenharia de sistemas, engenharia de software, produtos integrados e desenvolvimento de processos e fornecimento de recursos.

1) Engenharia de Sistemas

A engenharia de sistemas aborda o desenvolvimento de sistemas completos, que podem ou não incluir software. O enfoque dessa disciplina é capturar as necessidades do cliente, expectativas e restrições em produtos, fornecendo suporte necessário durante toda a vida do produto.

www.posugf.com.br


27

2) Engenharia de Software

A engenharia de software aborda o desenvolvimento de sistemas essencialmente de software. O papel dos engenheiros de software é aplicar abordagens quantificáveis ao desenvolvimento, operação e manutenção do software, de forma sistemática, disciplinada.

3) Produtos Integrados e Desenvolvimento de Processos

A área de conhecimento de Produtos Integrados e Processo de Desenvolvimento abordam de maneira sistemática o relacionamento e interação dos stakeholders mais representativos durante o tempo de vida do produto, objetivando a satisfazer as necessidades do cliente, expectativas e

requisitos. Os processos que contribuem com esta disciplina estão integrados a outros processos na organização.

4) Fornecimento de Recursos

A disciplina de Fornecimento de Recursos tem como objetivo abordar a aquisição de produtos que podem melhorar, agilizar ou simplificar o projeto, principalmente quando o esforço de trabalho é muito extenso ou complexo.

Categorias dos Componentes de uma Área de Processo

A idéia do CMMI é integrar várias práticas utilizadas antes em separado para o desenvolvimento de sistemas. O CMMI não é um modelo de desenvolvimento de software, ele tem uma abrangência muito maior do que isso, tendo como foco 4 categorias, e cada categoria tem uma série de processos relacionados, os quais listo alguns aqui:

● Gestão do Processo: Foco no processo organizacional, Treina-mento organizacional.

● Gestão do Projeto: Planejamento do Projeto, Gestão Integrada do Projeto, Gestão de Riscos.

● Engenharia: Desenvolvimento de requisitos, Gestão de requisitos.

● Suporte: Gestão da Configu-ração, medição e análise, análise de resolução as causas.

Quando o CMMI é usado como guia, são implementados e planejados processos que têm conformidade com componentes requeridos e esperados de áreas de processo. Conformidade com uma área de processo significa que em processos planejados e implementados há um processo associado (ou processos) que lidam com, práticas específicas e genéricas de uma área de processo ou alternativas que claramente alcançam um resultado de acordo com uma meta associada com prática específica ou genérica.

Componentes de Modelo

Áreas de Processo:

Uma área de processo é um conjunto de práticas relacionadas em uma área que, quando executada coletivamente, satisfaz um conjunto de metas consideradas importantes para fazer melhorias significativas na área. Todas as áreas de processo CMMI são comuns para ambas representações contínuas e por estágio. Na representação por estágio, áreas de processo são organizadas por níveis de maturidade (Ver Figura 7).

www.posugf.com.br


28

Figura 7 - Áreas de Processos por nível de maturidade

Metas Específicas

Metas específicas se aplicam à área de processo e lidam, com uma única característica que descreve o que deve ser implementado para satisfazer a área de processo. Metas específicas são componentes de modelo requerido e são usadas em avaliações para ajudar a determinar se uma área de processo é satisfeita.

Práticas Específicas

Uma prática específica é uma atividade que é considerada importante para alcançar a meta específica associada. A prática específica descreve as atividades esperadas para alcançar metas específicas de uma área de processo. Práticas específicas são componentes de modelo esperado.

Características ComunsQuatro características comuns organizam práticas genéricas de cada área de processo.

Características comuns são componentes de modelo que não são classificadas de qualquer maneira. Elas não apenas agrupamentos que fornecem uma maneira para apresentar práticas genéricas. Cada característica comum é projetada como mostrado:

- Compromisso para executar: agrupa práticas genéricas relatadas para criar políticas e conseguir patrocínio.

www.posugf.com.br


29

- Habilidade para executar: agrupa as práticas genéricas relatadas para garantir que o projeto e/ou organização tem recursos necessários.

- Diretrizes de implementação: agrupam práticas genéricas relatadas para gerenciar a execução de processos, gerenciar a integridade dos produtos gerados, e envolver relevantes pessoas significativas.

- Verificações de implementação: agrupam práticas genéricas relatadas para rever por nível de gerenciamento mais alto e objetiva avaliação de conformidade de descrição de processo, procedimentos e padrões.

Produtos de Trabalho

Produtos são um componente de modelo informativo que fornece exemplo de saídas de uma prática específica ou genérica. Estes exemplos são chamados produtos típicos porque há freqüentemente outros produtos que são efetivos, mas não listados.

Sub práticas

Sub práticas são descrições detalhadas que fornecem guia para interpretar práticas específicas ou genéricas. Sub prática podem ser expressas como se fixo, mas são geralmente componentes informativos em modelos CMMI apenas para fornecer idéias que podem ser úteis para melhoria de processo.

Amplificações de disciplinas

Amplificações de disciplinas são componentes do modelo informativo que contém informação relevante para uma disciplina particular e estão associadas com práticas específicas. Por exemplo, se no modelo CMMI-SEI/SW, quiser encontrar uma amplificação de disciplina para

engenharia de software, procurará em modelo por itens rotulados “Para Engenharia

de Software”. O mesmo é verdadeiro para outras disciplinas.

Metas genéricas

Metas genéricas são chamadas “genéricas” porque a mesma meta aparece em múltiplas áreas de processo. Na representação por estágio, cada área de processo tem apenas uma meta genérica. Realização de uma meta genérica em uma área de processo significa controle de melhoramento em planejamento e implementação de processos associados com aquela área de processo, assim indicando se esses processos são, provavelmente, efetivos, repetitível, e

duradouro. Metas genéricas são componentes de modelo requerido e são usados nas avaliações para determinar se uma área de processo está satisfeita.

Práticas genéricas

Práticas genéricas fornecem institucionalização para garantir que processos associados com áreas de processo serão efetivos, repetitíveis e duradouros.

Práticas genéricas são categorizadas por objetivos genéricos e características comuns e são componentes esperado em modelos CMMI.

Elaborações de práticas genéricas são componentes de modelo informativo que aparecem em cada área de processo que fornecem um guia em como práticas genéricas deveriam unicamente ser aplicadas a áreas de processo. Por exemplo, quando prática genérica “Treinar pessoas executar ou apoiar processos planejados como necessidade” é incorporado na área de processo de Gerenciamento de Configuração, os tipos específicos de treinamento para fazer gerenciamento de configuração são descritos.

Referências

www.posugf.com.br


30

Referências são componentes de modelo informativos que direciona o usuário a informação adicional ou mais detalhada em relatadas áreas de processo.

Comparações de representações de modelo

As representações contínuas usam níveis de capacidade para medir a melhoria de processo, enquanto representação por estágio usa níveis de maturidade. A principal diferença entre níveis de maturidade e níveis de capacidade é a que a representação a que pertence e como são aplicadas:

- Níveis de capacidade são os quais pertencem a representações contínuas, são aplicados a uma realização de processo de melhoramento de organização para cada área de processo. Há seis níveis de capacidade, numerado de 0 até 5. Cada nível da capacidade corresponde a metas genéricas e um conjunto de práticas genéricas e específicas.

Tabela Níveis de Capacidade

A representação contínua tem mais práticas específicas que a representação por estágio porque a representação contínua tem dois tipos de práticas específicas, básico e avançado, enquanto que a representação estagiada tem apenas um tipo específico de prática.

Na representação contínua, práticas genéricas existem para níveis de capacidade um a cinco, enquanto que, em representação por estágio, apenas as práticas genéricas para níveis de capacidade dois e três aparecem, não há práticas genéricas para níveis 1,4 e 5.

Nível de Maturidade 2: Gerenciado

Como este curso concentra-se na Modelagem de Processo de Negócio (BPM) apenas o as áreas de processo do nível dois do CMMI serão detalhadas, o detalhamento de todos os níveis pode ser obtida no próprio site da SEI < http://www.sei.cmu.edu/cmmi/start/ > ou no ótimo blog em português < http://www.blogcmmi.com.br > .

Esta seção contém todas áreas de processo que pertencem ao nível dois de maturidade, que são explanadas de forma genérica. Todas as práticas descritas nessa seção se encontram no documento Capability Maturity Model Integration (CMMI) (CMU SEI-2002 – TR-029 Version 1.1 http://www.sei.cmu.edu/reports/02tr029.pdf ).

Primeiramente são apresentadas as metas específicas de suas respectivas áreas de processo e depois uma sessão para metas genéricas, pois estas tendem a se repetir a cada área de processo.

As áreas de processo do nível de maturidade 2, de CMMI por estágio, são as seguintes:

Gerenciamento de requisitos:

O propósito de gerenciamento de requisitos é gerenciar os requisitos de produtos de projetos e componentes de produto e identificar inconsistências entre estes requisitos e planos de projetos e produtos de trabalho relacionados a ele. Envolve:

www.posugf.com.br


31

- Identificação de entendimento claro dos requisitos;

- Obtenção de comprometimento da equipe em relação aos requisitos a serem

implementados;- Controle de mudança dos requisitos;- Manutenção de rastreabilidade dos

requisitos_ vertical, que tudo será impactado com a mudança no requisito (artefatos, planos de teste) e horizontal, analisando os requisitos que serão impactados pela mudança em requisito;

- Identificação das inconsistências entre os requisitos e os produtos de trabalho.

Práticas Específicas por Meta:

SG1 Gerenciar Requisitos

Os requisitos devem ser gerenciados e as inconsistências entre os planos de projeto e os produtos de trabalho devem ser identificadas.

SP1.1 Obter um Entendimento dos Requisitos:

Desenvolver um entendimento junto aos fornecedores dos requisitos sobre o significado dos requisitos.

SP1.2 Obter Compromisso para com os Requisitos:

Obter um compromisso dos participantes do projeto para com os requisitos.

SP1.3 Gerenciar Mudanças nos Requisitos:

Gerenciar as mudanças nos requisitos de acordo com a evolução destes.

SP1.4 Manter uma Rastreabilidade Bidirecional dos Requisitos:

Manter uma rastreabilidade bidirecional entre os requisitos, os planos de projeto e os produtos de

trabalho.

SP1.5 Identificar inconsistências entre o Produto Desenvolvido e os seus Requisitos:

Identifique inconsistências entre os planos de projeto, os produtos de trabalho e os requisitos.

Gerenciamento de configuração:

O propósito de gerenciamento de configuração é estabelecer e manter a integridade de produtos de trabalho usando identificação de configuração, controle de configuração, status de contabilidade de configuração e auditoria de configuração. Envolve:

· Estabelecimento de linhas de base:- Identificação de itens de configuração;- Montagem da infra-estrutura de gerência

de configuração;

· Liberação de linhas de base: - Versões ou “patchs”;

· Rastreamento e controle de mudanças:- Controle de Change Requests (CR);- Uso de CCB (Change Control Band),

ajuda na análise de impacto e autorização de mudanças;

- Controle dos itens de configuração modificados a partir das CR´s (Change

Request).

Práticas Específicas por Objetivo:

SG1 Estabelecer linhas de base:

Linhas de base de trabalhos de produto identificados são estabelecidas.

www.posugf.com.br


32

SP1.1 Identificar os Itens de Configuração:

Identifica os itens, componentes, e produtos de trabalhos relacionados o qual serão colocados sob gerência de configuração.

SP1.2 Estabelecer um sistema de gerência de configuração:

Estabelece e mantém um gerenciamento de configuração e sistema de gerenciamento de mudança para controlar produtos de trabalho.

SP1.3 Criar ou liberar linhas de base:

Cria ou libera linhas de base para uso interno e para entregar ao cliente.

SG2 Rastrear e controlar mudanças:

Fazer com que as mudanças nos artefatos que estão sob a gerência de configuração sejam rastreados e controlados.

SP 2.1 Rastrear mudanças requisitados:

Rastrear mudanças requisitados para itens de configuração.

SP2.2 Controle dos itens de configuração:Controlar mudanças para configuração de

itens.

SG3 Estabelecer integridade:

Integridade de linhas de base é estabelecida e mantida.

SP3.1 Estabelecer registros de gerência de configuração

Estabelecer e manter os registros que descrevem os itens de configuração.

SP3.2 Realizar auditorias de configuração:

Realizar auditorias de configuração para manter integridade de linhas de base de configuração.

Garantia de controle de processo e de produto

O propósito de Garantia de Qualidade de Processo e Produto é fornecer pessoal e gerenciamento com percepção objetiva nos processos e produtos de trabalho associados. Envolve:

· Avaliação dos processos:- Verificação da execução do processo de

acrodo com o que foi escrito;

· Avaliação dos produtos de trabalho:- Uso de templates e padrões definidos nos

processos;· Rastreamento e controle de não-

conformidades - verifica aderência aos padrões :

- Garantia de resolução dos desvios detectados durante as avaliações.


SG1 Avaliar objetivamente processos e produtos de trabalho:

Aderência de execução de processo e produtos associados e serviços para descrição de processo, padrões, procedimentos estar objetivamente avaliada.

SP1.1 Avaliar processos objetivamente:

Avaliar objetivamente o processo realizado que foi projetado em relação à descrição de processos aplicável, padrões e procedimentos.

SP1.2 Avaliar objetivamente produtos de trabalho e serviços:

Avaliar objetivamente os produtos de trabalho projetados e serviços em relação à

www.posugf.com.br


33

descrição de processo aplicável, padrões e procedimentos.

SG2 Fornecer objetivo perceptível:

Casos de não-conformidade são objetivamente rastreados e comunicados, e resolução é garantida.

SP2.1 Comunica e garante resolução de casos de não-conformidade:

Comunica casos de qualidade e garante resolução de casos de não conformidade com o pessoal e gerentes.

SP2.2 Estabelece registros:

Estabelece e mantém registros de atividades de garantia de qualidade.

Medição e análise

O propósito de medição e análise é desenvolver e sustentar uma capacidade de medição que é usada para apoiar as necessidades de informação da gerência. Envolve:

· Identificação de métricas que atendam a objetivos estabelecidos pela organização;

· Coleta e análise das métricas identificadas:

- Avaliação para determinar ações para melhorias de processos ou correção de problemas identificados.


SG1 Atividades de Alinhamento de Medição e Análise:

Objetivos das medições e atividades são alinhados com necessidades de informação e objetivos.

SP1.1 Estabelece objetivos de medição:

Estabelece e mantém objetivos de medição que são derivados de informações identificadas necessárias e objetivos.

SP1.2 Medições especificadas:

Especifica medições para lidar com os objetivos de medições.

SP1.3 Especifica Coleta de dados e procedimentos armazenados:

Especifica como dados de medições serão obtidos e armazenados.

SP1.4 Especifica procedimentos de análises:

Especifica como dados de medições serão analisados e reportados.

SG2 Fornece resultados de medições:

Resultados de medições que lidam com informações necessárias identificadas e objetivos são fornecidos.

SP2.1 Coleta de dados da medição:

Obtém específica coleção de dados.SP2.2 Analisa dados de medição:

Analisa e interpreta dados de medição.

SP2.3 Armazena dados e resultados:

Gerencia e armazena dados de medição, especificações de medição, e resultados de análises.

SP2.4 Comunica resultados:

Relata resultados de medição e análises de atividades para todos stakeholders relevantes.

Planejamento de Projeto

www.posugf.com.br


34

O propósito de planejamento de projeto é estabelecer e manter planos que definem as atividades de projeto. Envolve:

· Estabelecimento de estimativas:- Delimitação do escopo de projeto;- Definição do ciclo de vida do projeto;- Realização de estimativa de recursos,

tamanho, esforço, custo, etc.;

· Desenvolvimento de plano de projeto:- Definição de orçamento e cronograma de

projeto;- Identificação de riscos;- Planejamento de gerenciamento de

dados;- Envolvimento de stakeholders no projeto;

· Obtenção do comprometimento com o plano:

- Negociações entre envolvidos até aprovação do plano.


SG 1 Estabelecer Estimativas:Estimativas de planejamento de projeto e

parâmetros são estabelecidas e mantidas.

SP 1.1 Estimar o escopo do projeto:

Estabelecer em alto nível uma estrutura analítica de projeto (WBS) para estimar o escopo do projeto.

SP 1.2 Estabeleça estimativas de produto de trabalho e atributos de tarefas:

Estabelecer e manter estimativas de atributos de produtos de trabalho e ferramentas requeridas.

SP 1.3 Definir ciclo de vida para o projeto:

Definir as fases do ciclo de vida, que serão o escopo para o esforço de planejamento do projeto.

SP 1.4 Determinar estimativas de esforço e custo:

Estimar os esforços e custos do projeto para os produtos de trabalho e atividades, baseado em métodos/modelos/práticas apropriadas de estimativas.

SG 2 Desenvolver um plano de projeto:

Um plano de projeto é estabelecido e mantido como base para a gerência do projeto.

SP 2.1 Estabelecer um orçamento e cronograma:

Estabelecer e manter o orçamento e cronograma do projeto.

SP 2.2 Identificar riscos do projeto:

Identificar e analisar riscos do projeto.

SP 2.3 Planejar e gerenciar as dados:

Planejar e gerenciar as dados do projeto.

SP 2.4 Planejar os recursos para o projeto:

Planejar os recursos necessários para executar o projeto.

SP 2.5 Planejar as necessidades de conhecimentos e habilidades:

Planejar os conhecimentos e habilidades necessárias para executar o projeto.

SP 2.6 Planejar o envolvimento dos Stakeholder:

Planejar o envolvimento dos stakeholders identificados.

SP 2.7 Estabelecer o plano de projeto:

www.posugf.com.br


35

Estabelecer e manter o conteúdo do plano de projeto.

SG 3 Obter Compromissos para o plano:

Compromissos para o plano de projeto são estabelecidos e mantidos.

SP 3.1 Rever planos que afetam o projeto:

Revisar todos os planos que afetam o projeto e o entendimento dos compromissos.

SP 3.2 Reconciliar níveis de trabalho e recursos:

Reconciliar o plano de projeto para refletir a estimativa de recurso disponíveis.

SP 3.3 Obter planos de compromissos:

Obter compromissos e responsabilidades com os stakeholders mais relevantes para executar e suportar o plano de execução.

Controle e monitoramento de projetos

O propósito de Controle e Monitoramento de Projetos é fornecer um entendimento do progresso do projeto e que ações corretivas apropriadas podem ser tomadas quando o desempenho do projeto desvia significativamente do plano. Envolve:

· Acompanhamento do projeto em relação ao plano:

- Acompanhamento do escopo de projeto;- Acompanhamento de estimativas;- Acompanhamento do orçamento e

cronograma do projeto;- Acompanhamento dos riscos;- Acompanhamento dos compromissos

estabelecidos;

· Condução de revisões:- Revisões de progresso;- Revisões em marcos;

· Tomada de ações corretivas diante dos desvios do planejamento;


SG1 Monitora o projeto em relação ao plano:

Desempenho real e progresso do projeto são monitorados em relação ao plano.

SP1.1 Monitora valores reais dos parâmetros de planejamento de projeto:

Monitora valores reais de parâmetros de planejamento de projeto em relação ao plano de projeto.

SP1.2 Monitora Compromissos:

Monitora compromissos em relação àqueles identificados em plano de projeto.

SP1.3 Monitora riscos de projetos:

Monitora riscos em relação àqueles identificados em plano de projeto.

SP1.4 Monitora gerenciamento de dados:

Monitora o gerenciamento de dados de projeto em relação a plano de projeto.

SP1.5 Monitora envolvimento de stakeholders:

Monitora o envolvimento de stakeholders em relação ao projeto.

SP1.6 Conduz revisão de progresso:

Periodicamente revisa progresso de projeto, desempenho.

SP 1.7 Conduz marco de revisões:

Revisa as realizações e resultados do projeto em marcos definidos para o mesmo.

www.posugf.com.br


36

SG2 Gerencia ações corretivas:

Ações corretivas são gerenciadas quando a desempenho do projeto ou resultados desviam significativamente do plano.

SP2.1 Analisa casos:

Coleta e analisa os casos e determina as ações corretivas necessárias.

SP2.2 Tomar ações corretivas:

Tomar ações corretivas em casos identificados.

SP2.3 Gerencia ações corretivas:

Gerencia ações corretivas.

Gerenciamento de Sub-Contratação

O propósito de gerenciamento de sub-contratação é gerenciar a aquisição de produtos de fornecedores com os quais existe um acordo formal. Envolve:

· Estabelecimento do Contrato de aquisição com os fornecedores escolhidos:

- Utilização de critérios bem definidos para a escolha;

- Estabelecimento de critérios de aceitação do produto ou serviço contratado;

· Monitoramento do contrato de aquisição:- Garantia no recebimento do produto ou

serviço conforme estabelecido no contrato;


SG1. Estabelecer acordos com fornecedores:

Acordos com fornecedores são estabelecidos e mantidos.

SP1.1. Estabelecer tipo de aquisição:

Determina o tipo de aquisição para cada produto ou componente de produto a ser adquirido.

SP1.2. Selecionar fornecedores:

Seleciona fornecedores baseados em uma avaliação de suas habilidades para encontrar requisitos específicos e estabelecer critério.

SP1.3. Estabelecer acordos com fornecedor:

Estabelecer e manter acordos formais com fornecedor.

SG2. Satisfazer acordos com fornecedores:

Acordos com fornecedores são satisfeitos tanto pelo projeto quanto pelo fornecedor.

SP2.1. Rever produtos COTS:

Rever produtos COTS candidatos para garantir que eles satisfazem os requerimentos específicos que são feitos sob um acordo com o fornecedor.

SP2.2. Executar o acordo com o fornecedor:

Realizar atividades com o fornecedor como especificado no acordo formal.

SP2.3. Aceitar o produto adquirido:

Garantir que o acordo com o fornecedor é satisfeito antes de aceitar o produto adquirido.

SP2.4. Transição de produtos:

Transição dos produtos adquiridos do fornecedor para o projeto.

Metas Genéricas

www.posugf.com.br


37

Nesta sessão estão as metas em comum a áreas de processo. Todas as práticas descritas nessa seção se encontram no documento Capability Maturity Model Integration (CMMI) (CMU SEI-2002 – TR-029 Version 1.1). As metas genéricas são divididas por características comuns:

GG 2.1 Institucionalize um Processo Gerenciado

O processo é institucionalizado como um Processo Gerenciado.

Compromissos

GP 2.1 Estabelecer uma Política Organizacional(CO 1)

Estabelecer e manter uma política organizacional para planejamento e realização do processo.

Habilidades

GP 2.2 Planejar o Processo(AB 1)

Estabelecer e manter os requisitos e objetivos, e planejar para a realização do processo.

GP 2.3 Fornecer Recursos(AB 2)

Disponibilizar os recursos necessários para a realização do processo, o desenvolvimento dos produtos de trabalho e o fornecimento dos serviços do processo.

GP 2.4 Atribuir Responsabilidade (AB 3)

Atribuir responsabilidade e autoridade para a realização do processo.

GP 2.5 Treinar Pessoal (AB 4)

Treinar o pessoal que realiza ou dá suporte ao processo conforme necessário.

Diretrizes

GP 2.6 Gerenciar configurações (DI 1)

Colocar produtos de trabalho designados do processo sob níveis adequados de gerenciamento de configuração.

GP 2.7 Identificar e envolver stakeholders relevantes (DI 2)

Identificar e envolver os stakeholders relevantes conforme planejado.

GP 2.8 Monitorar e controlar o processo (DI 3)

Monitorar e controlar o processo com relação ao plano e tomar as ações corretivas adequadas.

Verificações

GP 2.9 Avaliar objetivamente a aderência (VE 1)

Avaliar objetivamente a aderência do processo e dos produtos de trabalho e serviços do processo aos requisitos, objetivos e normas aplicáveis e tratar as não conformidades.

GP 2.10 Rever o status com a gerência de alto nível(VE 2)

Rever as atividades, status e resultados do processo com a alta gerência e resolver aspectos pertinentes.

Modelagem de Processos de

Negócio

Embora os estudos sobre processos, quer sejam industriais ou empresariais, e sua constante melhoria já sejam feitos há mais de um século, conforme estudos de Taylor, Ford e outros, a compreensão dos processos de negócios tem se mostrado como uma das tendências na compreensão do

www.posugf.com.br


38

funcionamento das organizações. Diferente de momentos em décadas anteriores, em que a montagem de esquemas era utilizada com maior foco na compreensão do funcionamento dos processos, com ênfase na redução de erros e aumento da qualidade, hoje se pretende acompanhar, automatizar e obter ganhos efetivos com estes processos, gerando assim interesse de ganhos reais com os mesmos, seja na imagem da organização, de ganhos financeiros, ou de aumento da competitividade.

A partir da década de 1990, as organizações têm experimentado uma evolução em termos de modelos estruturais e tecnológicos, trazendo como novos paradigmas as mudanças e o conhecimento. Esse fato tem exigido uma nova postura nos estilos pessoal e gerencial, voltados para uma realidade diferenciada e emergente. Não exatamente abandonando a estrutura de funções na empresa, como mencionam Maranhão & Macieira (2004), mas reduzindo a sua importância, as empresas contemporâneas estão gradualmente passando a se organizar de forma orientada aos processos que as permeiam, acompanhando a lógica dos mesmos, e não mais o raciocínio compartimentado da abordagem funcional. A maior vantagem da orientação por processos é que esta ajuda a entender como as coisas são realmente feitas na organização, revelando problemas, gargalos e ineficiências que poderiam permanecer escondidos em uma organização que, aparentemente, funciona normalmente. O gerenciamento dos processos também ajuda a reduzir tempos de ciclos, diminuir custos, melhorar a eficiência interna e a qualidade global e aumentar a satisfação do cliente e do empregado.

A orientação por processos também contribui para um melhor entendimento da meta e produto finais da organização e o papel desempenhado por cada indivíduo. Porém, mais importante é a noção de que

os processos e seus produtos são a real interface com os clientes, não apenas funções individuais de uma organização. Nesse contexto, a modelagem e a análise dos processos de negócio permitem desenvolver a organização e melhorar sua efetividade e qualidade de trabalho.

Em empresas que adotaram uma perspectiva de processos, a modelagem tornou-se um elemento crucial no entendimento e representação desses processos, de modo que esta contribui de forma efetiva em projetos de melhoria dos procedimentos adotados na condução dos mesmos ou de implantação de novos processos. A modelagem de processos deve consistir em construir um modelo que apresente os relacionamentos entre atividades, pessoas, dados e objetos envolvidos na produção de um produto específico.

A construção de um modelo orientado a processos pode resolver muitos

problemas que não aparecem quando se trabalha sob o ponto de vista funcional tradicional. Um modelo de processo é projetado para ajudar a todas as pessoas envolvidas a entender o cenário inteiro e a parte que lhes cabe dentro dele. A construção de um modelo requer um trabalho em equipe, de modo a assegurar que todo o conhecimento disponível seja usado nessa tarefa. Um modelo básico consiste em atividades específicas, passos de processo, funções organizacionais, informações e materiais. O modelo também pode conter notas sobre problemas potenciais no processo de negócio, ideias para melhorias e outros comentários.

A documentação é uma parte importante no gerenciamento de processos de negócio, pois ajuda no seu entendimento e na comunicação ao longo da organização. O maior desafio neste caso é manter a documentação atualizada e acessível a todos

www.posugf.com.br


39

os envolvidos. Para isso é essencial que se tenha uma metodologia que permita a análise e proposição de melhorias com facilidade e rapidez, a partir da documentação do processo. Para Damij (2007), o sucesso da modelagem de processos de negócio depende da seleção apropriada da metodologia de modelagem ou técnica de análise do fluxo de processo. Existe um grande número de metodologias ou técnicas de análise usadas neste campo, como gráficos de processos gerais, gráficos de atividades de processo, fluxogramas, diagramas de fluxo de dados, desenvolvimento da função qualidade (QFD), definição integrada de modelagem de função (IDEF), redes petri coloridas, métodos orientados a objeto, sete ferramentas de gerenciamento e planejamento, entre outras.

O entendimento do problema a ser resolvido é o fator mais importante na

escolha da metodologia que será utilizada como apoio à modelagem dos processos da organização. A análise da metodologia mais adequada passa, então, por questões como: para que propósito a empresa pretende modelar os processos, que decisões ela apoiará, que características são necessárias, quais os desdobramentos para o futuro. A partir desse entendimento tem-se uma visão mais clara da ferramenta de modelagem a ser utilizada.

Invariavelmente, o ponto de partida para a implantação de um sistema de fluxo de trabalho automatizado (workflow) é o modelo do processo, e este pode conter informações diversas, tais como atividades, papeis funcionais, dados de entrada e saída, comentários. Em função da metodologia adotada na modelagem do processo, essas informações podem estar explicitadas no modelo com maior ou menor nível de profundidade. No caso dessas informações não estarem suficientemente explícitas, esses “gaps” de informação podem tornar a montagem do workflow um processo árduo ou até impraticável. Dessa forma, o modelo

do processo, obtido através dos métodos de modelagem, é uma ferramenta valiosa para a definição do modelo do fluxo de trabalho e deve estar voltado ao seu objetivo final que, neste caso, é a construção do workflow.

O que são processos

Um processo pode ser definido de diferentes formas. Segundo Davenport (1994), processo é “uma ordenação específica das atividades de trabalho no tempo e no espaço, com um começo, um fim, e inputs e outputs claramente identificados: uma estrutura para a ação.” Mais formalmente, Hammer e Champy (1994) definem processo como um grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes.

Sob a ótica do gerenciamento de processos, Ould (2005) define processo como um conjunto coerente de atividades conduzido por um grupo de colaboradores para atingir um objetivo. Das definições apresentadas, pode-se depreender que o conceito de processo envolve um sequenciamento de atividades, com entradas e saídas, executadas por pessoas ou sistemas, que visam atender as necessidades de um cliente interno ou externo. Um processo é, portanto, um conjunto estruturado de operações que conduzem a um determinado fim.

Harrington et al. (1997) estratificam hierarquicamente a estrutura dos processos dentro de uma organização em quatro níveis, do mais amplo para o mais específico, da seguinte forma: macroprocessos, subprocessos, atividades e tarefas, conforme mostrado na Figura 8.

www.posugf.com.br


40

Figura 8 – Processo, subprocesso, atividades e tarefas

Os macroprocessos ou processos principais são processos que geralmente envolvem mais de uma função na estrutura organizacional e sua operação tem um impacto significativo no funcionamento da organização. Um subprocesso é uma porção de um macroprocesso que desempenha um objetivo específico dentro do processo principal. Todo processo ou subprocesso é constituído de um determinado número de atividades. Atividades são ações executadas dentro dos processos, necessárias para produzir resultados específicos. Cada atividade é constituída por um determinado número de tarefas, que normalmente indicam como um determinado trabalho é executado.

A Norma ISO 9000:2000 requer que as organizações adotem a abordagem por processos e explicita a intenção da Organização Internacional para Normalização Técnica de encorajar a adoção desta abordagem para a gerência de uma organização. No entanto, é importante ressaltar que uma estrutura organizacional baseada em processos é uma estrutura alicerçada no modo em que o trabalho é executado, não em torno de habilitações específicas departamentalizadas. Davenport (1994, p. 10) argumenta que:

“Como a perspectiva de um processo implica uma visão horizontal do

negócio, que envolve toda a organização, começando pelos insumos do

produto e terminando com os produtos finais e os clientes, a adoção de uma

estrutura baseada no processo significa, em geral, uma não enfatização da

estrutura funcional do negócio”.Observando a estrutura organizacional

das empresas, percebe-se que os processos possuem uma estrutura horizontal, enquanto a organização departamentalizada confere à empresa uma estrutura funcional verticalizada. O

processo de criação de um novo produto, por exemplo, inclui atividades que recorrem a variados conhecimentos funcionais e atravessa horizontalmente todos os setores da organização (Figura 9).

Figura 9 – Um processo genérico

Reduzindo gradativamente a estrutura por funções, que foi a forma organizacional predominante nas empresas do século XX, as empresas estão

organizando seus recursos e fluxos ao longo de seus processos básicos de operação, adotando uma estrutura orientada para processos (GONÇALVES, 2000).

Ao longo de décadas, os processos industriais sofreram aperfeiçoamentos contínuos que, mais recentemente, passaram a ser utilizados também nos processos empresariais. Isto explica em parte a intensa utilização do conceito de processo na modernização das empresas. Sob esta ótica, pensar nos processos em termos de coordenação de atividades em vez de fluxos de trabalho ou fluxos físicos de materiais

www.posugf.com.br


41

ou produtos, como tem sido a abordagem predominante na reengenharia e no TQM (Total Quality Management), é importante para identificar e tratar processos industriais como importantes ativos de negócio e para poder analisar qualquer tipo de processo. (GONÇALVES, 2000)

Em função da crescente relevância atribuída aos processos, cresce dentro das organizações a necessidade de se melhorar sua agilidade e desempenho operacional, através de uma gestão cada vez mais voltada a eles, ou seja, uma

gestão por processos.

Gestão por processos

Há muitas razões pelas quais as organizações não administram bem seus processos. Quando um processo envolve diferentes departamentos, não é incomum surgir uma luta de poder em torno da propriedade e responsabilidade sobre diferentes aspectos do processo, pois os gerentes são frequentemente compensados pela produção e eficiência dos seus próprios departamentos, sem levar em conta os demais departamentos. Assim, administrar projetos e processos transfuncionais torna-se uma tarefa difícil devido à existência desses silos funcionais. Entender como funcionam os processos e quais são os tipos existentes é importante para determinar como eles devem ser gerenciados para a obtenção do máximo resultado (GONÇALVES, 2000). Assim, para desenvolver uma estrutura organizacional por processos, é fundamental ter uma visão clara e profunda dos processos da empresa através do mapeamento das atividades, regras e relacionamentos que constituem tais processos.

Diante dessa tendência, vem crescendo no meio empresarial a prática do Gerenciamento de Processos de Negócio (Business Process Management – BPM) como uma forma de

gerenciamento e controle das organizações. Vários fatores são cruciais para o sucesso do BPM, mas que também podem complicar ou impedir sua implementação. Entre outros fatores de sucesso críticos, comumente mencionados, estão a mudança organizacional e cultural, o alinhamento da abordagem do BPM com as metas e estratégias corporativas, o enfoque no cliente e suas exigências, as medições do processo e melhorias, a necessidade de uma abordagem estruturada para o BPM, o compromisso da alta administração,os sistemas de informação dos processos, a infraestrutura e o realinhamento.

A implementação efetiva de uma solução de Gerenciamento de Processos de

Negócios (BPM) requer elementos estratégicos e de tecnologia. Um dos principais benefícios que as organizações ganham com um sistema completamente integrado e implementado é o alinhamento da estratégia empresarial e a infraestrutura de tecnologia na qual são construídos os negócios.

As organizações têm percebido cada vez mais que os seus processos de negócio lhes oferecem vantagens competitivas. Atualmente, para serem efetivas, as organizações devem ser capazes de definir, analisar, melhorar, medir e controlar os seus processos. Nas empresas de serviço, em especial, os processos tornam-se fundamentalmente importantes uma vez que a sequência de atividades nem sempre é visível, nem pelo cliente nem por quem realiza as atividades. Para estas empresas, a sequência de atividades é necessária para a realização de transações e prestação do serviço. Os processos de trabalho ganham mais importância à medida que as empresas ficam com conteúdo cada vez mais intelectual, afastando-se do modelo fabril (GONÇALVES, 2000).

www.posugf.com.br


42

Segundo Larson & Larson (2005), existem dois modos de realizar trabalho em

uma organização: através de projetos ou de processos. Considerando que o

gerenciamento de projeto é o planejamento e execução de esforços temporários para produzir algo de valor, o Gerenciamento de Processos de Negócio (Business Process Management – BPM) emprega técnicas e sistemas para ajudar uma organização a supervisionar continuamente processos e aumentar a eficiência enquanto eles reproduzem algo de valor. Enquanto projetos são sempre temporários, processos podem ser contínuos e repetitivos.

Organizações orientadas a processos mudam seus objetivos para melhor apoiar os processos que as conduzem. Por exemplo, se reduzir o lead-time de três dias para um dia é um objetivo de uma companhia, ao invés de iniciar um projeto para cumprir o objetivo, a organização deveria identificar seus processos e então iniciar um projeto para melhorá-los. Isso diminuiria o tempo de produção e alcançaria o objetivo esperado. Dessa forma, projetos são necessários para apoiar processos, e estes aumentam a eficiência em alcançar metas empresariais.

As estratégias que falham, 90% falham porque a empresa não conseguiu implementá-las corretamente, ou seja, não conseguiu fazer com que os processos espelhassem a estratégia”. No nível estratégico do BPM, são montadas as estratégias dos processos a fim de que estas estejam alinhadas com as estratégias da organização, pois, para administrar novas e rápidas mudanças nas áreas empresariais, é de importância extrema unir processos de negócio com estratégias corporativas. Nesse nível, são definidas as estratégias de melhoria ou inovação dos processos da empresa, indicando a arquitetura dos novos processos e das aplicações que lhes darão suporte. A partir da análise dos dados levantados é montada a especificação do

novo processo ou da melhoria/inovação do existente.

Os fatores de sucesso em utilizar uma ferramenta estratégica não se resumem apenas no envolvimento da alta gerência, mas também na integração dos empregados, através de uma comunicação adequada. Um elemento adicional de grande influência é o amadurecimento do gerenciamento da mudança contínua, pois repensar processos empresariais e seus realinhamentos completa o ciclo do BPM.

Assim, após completar o gerenciamento da mudança, a estratégia é revisada para a nova realidade e, se necessário, atualizada. Na administração de empresas moderna, os processos empresariais são os condutores operacionais das organizações, exigindo uma administração pró-ativa desses processos. Há alguns anos atrás, metas estratégicas só poderiam ser monitoradas quando os próximos resultados trimestrais fossem publicados. Porém, o gerenciamento do desempenho dos processos monitora continuamente os objetivos fixados e fornece alertas de divergências com o que foi planejado, indicando medidas a serem implementadas. Assim, as organizações alcançam uma qualidade de processo melhorada, que tem um impacto direto nos resultados da corporação. O monitoramento contínuo de processos de negócio atual diminui a distância entre a estratégia organizacional e sua implementação operacional.

Sabe-se que do taylorismo/fordismo aos dias de hoje, passando pelo modelo

japonês de produção, os gestores industriais debruçaram-se na busca de uma

gestão empresarial que conduzisse a organização ao nível competitivo face ao

crescente consumo especializado da sociedade atual. De fato, o aumento na complexidade dos mercados, devido ao contexto social que dia a dia mescla-se numa

www.posugf.com.br


43

tendência de dinâmicas inovadoras, globalização e elevação de poder dos atores sociais, conduz a gestão empresarial a focar suas ações em estratégias dinâmicas. A empresa passa a ser modelada, via organização por processo, sob uma proposta de um sistema aberto, em que mais se preocupa com fluxos do que com operações isoladas de produção.

Assim, a gestão empresarial passou a reconhecer que o gerenciamento dos processos deve se fundamentar nas interações intra e extra organização de forma a entregar ao cliente final um produto com valor agregado reconhecido pelo mesmo. Desta forma, observa-se que toda a implantação de um sistema de gestão integrada passa a ter como ponto de partida a modelagem de processos, assim como todas as decisões estratégicas passam também a ser apoiadas em um bom sistema de BPM.

Para situar e destacar a importância da modelagem de processos dentro de um ambiente de gestão por processos é necessário conhecer os estágios que compõem o ciclo de vida de um processo de negócio, apresentados a seguir

O Ciclo de Vida dos Processos de Negócio

A realização de qualquer atividade de trabalho se dá através de um processo de negócio e este possui um ciclo de vida que passa necessariamente por quatro estágios: Captura, Reengenharia, Implementação e Melhoria Contínua (Figura 10). Se esses estágios forem bem conhecidos, e adequadamente conduzidos, o gerenciamento dos processos de negócio de uma organização pode se tornar efetivo em relação a seu potencial de ganho.

Figura 10 – O ciclo de vida dos processos de negócio

Captura da Definição do Processo

Ainda que escondidos na estrutura organizacional da empresa, os processos sempre existirão. Para capturá-los necessário se torna entendê-los, e isto se dá

www.posugf.com.br


44

através da análise da documentação existente e de entrevistas com os atores

envolvidos. Assim, após obter uma quantidade suficiente de informação, o processo é capturado através de uma definição de processo, que pode ser conduzida a um nível mais conceitual ou mais profundo, dependendo da utilização que se deseja lhe dar.

Davenport (1994) aponta pelo menos quatro razões para documentar os processos existentes antes de proceder a inovação. Primeira, o entendimento a ser dado aos mesmos facilita a comunicação entre os participantes. Segunda, na maioria das organizações complexas não há como passar para um novo processo sem compreender o existente. Terceira, o reconhecimento dos problemas de um processo existente pode ajudar a evitar a sua repetição no novo processo.

Finalmente, o entendimento dos processos existentes proporciona uma medida do valor da mudança proposta. A execução da definição do processo requer a criação de um modelo, que inclui suas atividades, as regras de coordenação dessas atividades e as habilidades necessárias à sua execução (papeis – pessoas ou sistemas de informação). Esses elementos são combinados através de uma linguagem de modelagem de processos.

Reengenharia do Processo

Existem hoje diversas metodologias propostas para a reengenharia de processos de negócio. Para que um projeto de reengenharia de processos seja efetivo, o corpo executivo responsável pelo projeto deve repensar o negócio de forma completamente nova, desconsiderando a maneira tradicional de se executar cada atividade. É o começar de novo, trabalhar com uma folha de papel em branco, esquecer dos modelos tradicionais e criar algo

inteiramente novo na forma de se trabalhar de uma empresa, uma nova abordagem de um processo existente na empresa. É a ferramenta do “papel em branco”. De acordo com esse conceito, tentar modificar um processo baseado na sua configuração atual levará a organização a preservar antigos vícios, que por sua vez atrapalham a efetividade das modificações. Ainda que não necessariamente se efetue uma mudança radical, como propõem os autores acima citados, após o levantamento e a modelagem dos processos, passa-se a uma etapa de otimização e redesenho desses processos.Nesta fase os processos deverão ser cuidadosamente analisados, a fim de que seja possível identificar inconsistências, atividades redundantes e desnecessárias, ineficiências.

Implementação do Processo

Após a modelagem dos processos ser concluída, o passo natural seguinte é a

implementação do que foi modelado. A automatização dos processos mapeados é realizada mediante a utilização das ferramentas de tecnologia da informação mais apropriadas à situação particular. A implementação de processos tradicionalmente tem sido realizada embutindo partes do processo em softwares e confiando em ações humanas para prover aderência ao resto do processo. Deve-se tomar cuidado na implementação dos processos, pois frequentemente, a implementação é feita pelo pessoal de Tecnologia da Informação (TI) sem a discussão com o pessoal envolvido no negócio, o que pode gerar barreiras e resistências desnecessárias.

Durante a etapa de implementação, ferramentas de workflow podem ser utilizadas para apoiar a transferência de informações através do fluxo de atividades que compõem um determinado processo.

www.posugf.com.br


45

Melhoria Contínua do Processo

A maioria dos processos são estruturas dinâmicas e necessitam ser revistas e

melhoradas ao longo do tempo, quer seja para se adaptarem às estratégias da

organização, quer seja para fazer uso das novas tecnologias da informação. Melhorar um processo implica em fazer pequenas correções de curso, ao invés de se ocupar em uma mudança radical. A melhoria nos processos de negócio procura tornar os processos mais efetivos (produzindo os resultados desejados), mais eficientes (minimizando os recursos usados) e mais adaptáveis (podendo satisfazer as mudanças dos clientes e as necessidades do negócio).

Um processo que era satisfatório ontem é apenas adequado hoje e será ineficiente amanhã. Como resultado, um esforço de melhoria contínuo deve ser

empreendido pelas equipes de trabalho e indivíduos envolvidos no processo.

Os esforços de melhoria contínua resultam em um acréscimo anual de 10 a 15% na eficiência do processo. Isto é necessário se a organização visa manter os lucros estratégicos obtidos como resultado da implementação de melhoria nos processos.

A base para as melhorias são as medidas de desempenho do processo. Estas podem mostrar com que frequência certos caminhos são utilizados, quais são os tempos decorridos de cada processo, quais os custos envolvidos e resultados semelhantes. A análise destes dados pode conduzir a idéias para a melhoria do processo, baseado nos resultados atuais. Tradicionalmente, essas medições são realizadas adicionando-se instrumentações nos softwares e criando maneiras de medir a atividade humana. Conhecidos os ciclos de vida dos processos, é necessário gerenciá-los, de modo a garantir

que sejam atualizados e aprimorados ao longo do tempo. Essa função é exercida através do Gerenciamento de Processos de Negócio.

Gerenciamento de Processos de Negócio

O Gerenciamento de Processos de Negócio (Business Process Management – BPM) consolida objetivos e metodologias que foram propostas por váriasabordagens, incluindo Reengenharia de Processos de Negócio, Inovação de Processos, Modelagem de Processos de Negócio e Automação de Processos de Negócio/Gerenciamento de Fluxos de Trabalho (Workflow).

A análise das definições de BPM revela que o enfoque está frequentemente voltado para a análise e melhoria dos processos. Existem dois fatores que exerceram influência na mudança da abordagem dos processos do nível operacional para o nível organizacional. O primeiro é o gerenciamento da qualidade total, que expande para toda a organização o conceito de que uma empresa é formada por um conjunto de processos de negócio. O segundo fator é a reengenharia de processos, que leva muitos dos princípios de fluxo e organização da cadeia de produção industrial para outros domínios onde o fluxo de processo são de pessoas e informação, principalmente na empresas de prestação de serviços financeiros e de saúde. Este fato leva à conclusão de que os processos não mais são apenas operacionais, mas incluem processos estratégicos que apóiam o operacional; por exemplo, o gerenciamento de recursos humanos e os sistemas de informação.

O BPM está concentrado em como administrar processos de uma forma contínua, e não somente em mudanças radicais associadas à reengenharia de processos. O BPM não só se baseia em

www.posugf.com.br


46

bons sistemas e mudança estrutural, mas, até mesmo mais importante, em mudança cultural. Vários fatores contribuem para o sucesso do BPM, mas também podem complicar ou impedir sua implementação. Entre outros, os fatores de sucesso críticos comumente mencionados são: mudança organizacional e cultural, alinhamento da abordagem do BPM com as metas e estratégias corporativas, enfoque no cliente e suas exigências, medições do processo e melhorias, necessidade de uma abordagem estruturada para o BPM, compromisso da alta administração, benchmarking, sistemas de informação dos processos, infraestrutura e realinhamento.

Ao lado dos fatores críticos de sucesso, existem várias barreiras, baseadas principalmente em problemas organizacionais e culturais. Barreiras comumente mencionadas incluem resistência à mudança, falta de compreensão dos princípios de BPM, falta de consistência de uma abordagem ampla de BPM e do desenvolvimento de uma organização orientada a processos. Pode-se dizer que o Gerenciamento de Processos de Negócio (BPM) objetiva a execução eficiente e efetiva de processos empresariais e consequentemente auxilia organizações na transição para uma visão orientada a processos. Isto alavanca a existência de plataformas técnicas para coordenação de processos, como sistemas de gerenciamento de fluxos de trabalho (workflow) ou aplicações de

grupos colaborativos (groupware), colocando-os no contexto do gerenciamento do ciclo de vida de processos.

No cerne do BPM está a compreensão de que um processo de negócios tem sua existência própria, separado em uma forma que – dado um modelo de representação – possa ser executado ou “rodado”, ser mudado a qualquer momento, ser evoluído como o negócio evolui, ser monitorado em tempo real

e ser desdobrado à vontade pela organização. Um sistema de computador que

apóia essa organização não simplesmente ajuda a gerenciar a informação, mas, primeiramente, ajuda a gerenciar os processos da organização.

O uso de um Sistema de Gerenciamento de Processos de Negócios (Business Process Management System – BPMS) envolve o registro de processos, incluindo análise e otimização, implementação de processos na infraestrutura de TI, medição e monitoramento automático dos processos e seus indicadores chaves de desempenho. Isso permite à organização ajustar a demanda de mudanças internas e externas. O BPM é, portanto, um ciclo fechado.

Porém, conforme afirma Davenport (1994), antes de partir para a implantação

e gerenciamento, é preciso projetar o processo de negócio, de forma que este

atenda aos objetivos estratégicos da organização. O alinhamento dos processos de negócio às necessidades e exigências do mercado inclui o projeto, a análise e a otimização desses processos, como parte da melhoria contínua do seu ciclo de vida. A fase de projeto tem duas tarefas primárias: a primeira é a criação de um panorama relativo à qualidade atual dos processos

existentes e a segunda é o realinhamento desses para as demandas atuais do

mercado. Para ambas as tarefas, uma abordagem metodológica e uma linguagem de descrição unificadas são essenciais. A fase de projeto procura respostas para a pergunta “Quem faz o que, em que sequência, quais serviços são fornecidos e quais sistemas de software são usados no processo?” O projeto consiste em registrar o estado atual dos processos que estão em utilização. Processos somente podem ser tornados transparentes e sujeitados a uma análise mais detalhada quando todo o conhecimento disponível sobre eles, que existe na maior parte nas mentes dos empregados que os usam, for reunido e

www.posugf.com.br


47

consolidado. Modelos estruturais e orientados a processos mapeiam a complexidade da realidade da organização e a reduz para condições manejáveis.

A fase de análise fornece informação vital sobre a verdadeira eficiência dos processos de negócio. São registradas alocação de pessoal e recursos materiais junto com a ocorrência de tempos de espera do processo, que representam onerosos gargalos para a organização. Isto torna evidente o desarranjo do sistema e permite determinar as “melhores práticas” (best pratices), ou seja, variantes de processo que são reveladas comparativamente como as melhores em termos de tempo e custos. Nessa linha de pensamento, as tecnologias de informação frequentemente encontradas nas organizações constituem um obstáculo para a implementação dos projetos de otimização de processos porque elas incluem componentes individuais funcionalmente separados que foram costurados às necessidades individuais de unidades organizacionais individuais. Como resultado, aparecem paisagens de sistema heterogêneas, com aplicativos redundantes e frequentemente antiquados que usam diferentes versões. Modificar estes sistemas para servir novos processos

de negócio integrados é praticamente impossível ou requer muito trabalho de desenvolvimento. Como resultado, muitas implantações de projetos falham em

atender o conjunto de exigências esperado.

Um fator crítico no sucesso de projetos de TI é a comunicação entre o departamento operacional e os desenvolvedores de software. Este problema surge das diferentes atitudes, métodos e ferramentas utilizadas pelos departamentos operacional e de implementação. Como consequência, introduzir novas ou modificar soluções de TI existentes acaba se tornando um processo muito caro porque em muitos casos não há nenhuma descrição uniforme dos processos empresariais a serem suportados.

Combinando as visões empresarial e tecnológica, as organizações reduzem a complexidade dos seus projetos de TI e iniciam um modo de reutilizar o seu recurso de conhecimento mais importante: o conhecimento de como suas organizações

funcionam.

Modelagem e Otimização de Processos

Os fluxogramas e mapas de processos sempre foram utilizados para visualizar

processos de negócio. Fluxogramas de todos os tipos, formas e tamanho têm sido utilizados no gerenciamento das organizações, na formulação de suas políticas, procedimentos e manuais. Atualmente, os analistas de processos empresariais preferem o termo “modelagem de processos” em lugar de fluxogramação ou mapeamento. A modelagem de processos implica em uma abordagem mais disciplinada, padronizada, consistente e sobretudo mais científica e madura. Ela tem que atender um grupo cada vez mais heterogêneo de trabalhadores e, para isto, deve ser escalável, configurável e estabelecer uma ponte entre as Tecnologias de Informação e as exigências do negócio. Diversos fatores, como a identificação do processo, estabelecimento de seus

objetivos e limites, identificação dos diversos papeis funcionais envolvidos e escolha da ferramenta de modelagem a ser utilizada, podem afetar o sucesso da melhoria de processos. Porém, o mais importante é a habilidade de representar e modelar o processo. O propósito básico de um modelo é reduzir a complexidade de compreensão ou interação de um fenômeno, através da eliminação de detalhes que não influenciam seu comportamento pertinente.

Notadamente, a Modelagem de Processos de Negócio (Business Processes

www.posugf.com.br


48

Modeling) é essencial para a reengenharia ou reestruturação de processos. Ela

abrange dois importantes papeis:

capturar os processos existentes através da representação estruturada de suas atividades e elementos relacionados;

representar novos processos a fim de avaliar seu desempenho. Além das duas funções acima, um método de modelagem de processos de negócios também possui a capacidade de análise na avaliação de processos e seleção de alternativas. Para alcançar esse propósito, a simulação computadorizada pode ser aplicada, como uma função do progresso da Tecnologia da Informação.

Gonçalves (2000) afirma que “o sucesso do novo desenho para um processo depende fundamentalmente de sua operacionalização, e o desenho do processo é o mapa essencial do caminho a ser percorrido.” Dessa forma, um modelo de processo muito simples ou que apresente um nível elevado de

complexidade pode dificultar o entendimento completo do processo real.

Existem dois condutores de complexidade para a criação de um modelo de processo. O primeiro é a forma como a modelagem é abordada, isto é, a complexidade da modelagem. Neste caso, pode-se questionar: Quão difícil é projetar um modelo dentro do ambiente de modelagem? (ferramenta, técnicas, diretrizes, etc.) E quão complexo é o modelo obtido, isto é, pode o modelo ser representado em uma página? O segundo condutor é a complexidade do próprio processo, isto é, a complexidade do processo. Um modelo de processo é como um espelho, reflete. Mas diferente de um espelho, também permite um enfoque mais profundo nos elementos de interesse, ou seja, a complexidade de um processo é tão grande quanto a profundidade que se esteja olhando. Assim é possível reduzir e administrar a

complexidade da modelagem para uma extensão que permita se concentrar na complexidade do processo.

A fim de modelar um processo é necessário estabelecer as diferentes perspectivas em que se deseja analisá-lo. Em resumo existem as seguintes visões de um processo, em função do tipo de informação requerida:

● Visão funcional – representa qual atividade ou elemento do processo está sendo executada. Representa a ação ou atividade que está sendo executada pelos atores ou empregados;

● Visão comportamental – rela-ciona quando e como o pro-cesso está sendo executado. A atividade ou o processo como um todo poderiam estar passando por um ciclo de realimentação ou um processo de repetição;

● Visão informacional – representa os detalhes da informação ou objetos que estão sendo manipu-ladas pelo processo, estes podem ser dados ou detalhes do objeto produto. A visão informacional considera os dados envolvidos e as relações entre eles;

● Visão organizacional – representa quem está executando o pro-cesso.

Dentro do conceito de ciclo de vida dos processos apresentado por Georgakopoulos & Tsalgatidou (1997), pode-se dizer que a modelagem de processos compreende as seguintes etapas:

● Modelagem do estado atual (“As Is”);

● Otimização e modelagem do estado futuro (“To Be” – quando aplicável).

www.posugf.com.br


49

A primeira etapa consiste em mapear o estado atual do processo, como ele existe atualmente (“As Is”). Isto significa que, juntando dados de pessoas que executam de fato o processo, é possível aprender exatamente como as coisas

acontecem dentro da organização. Uma vez que o “As Is” do processo esteja

documentado, pode-se entender onde poderiam ser feitas melhorias.

Qualquer processo horizontal, que atravessa os limites da unidade de negócios, requer a colaboração de vários departamentos, inclusive as pessoas da linha-de-negócio cujo processo está sendo modelado. Também inclui o departamento de finanças que entende dos custos do processo e recursos relacionados, o departamento de recursos humanos que pode oferecer subsídios para se definir quais empregados deveriam ser nomeados para tarefas específicas e departamentos adjacentes que serão afetados pelo novo fluxo de trabalho.

Para executar a modelagem do processo atual, algumas etapas são comuns:

● Preparação do projeto de mod-elagem;

● Entrevistas e coleta de dados com usuários;

● Documentação do processo; ● Validação do processo.

Na fase de documentação do processo, torna-se necessária a utilização de uma linguagem para a sua representação. Dentre as linguagens existentes para representação de modelos de processos, três possuem destaque devido ao grau de aplicabilidade, capacidade intuitiva de representação e simplicidade:

IDEF0 – Integration DEFinition for Function Modeling;

EPC – Event-driven Process Chain;

BPMN – Business Process Modeling Notation.

Video sobre BPM - BUSINESS PROCESS MODELING http://www.youtube.com/watch?v=D6MYXj8YD9Q

Automação de Processos – Workflow

Ambientes empresariais modernos são caracterizados por um conjunto de processos de negócios que precisam ser acompanhados para atingir os objetivos estabelecidos. Até a década de 1990, o trabalho era transferido de um trabalhador para outro manualmente. Assim que uma tarefa era entregue a uma pessoa, cada participante poderia assumir que o trabalho estava pronto para processamento. O foco da tecnologia da informação era a automação de atividades individuais desenvolvidas pelos participantes, de forma que estas fossem completadas de um modo mais rápido e eficiente.

Nos anos mais recentes, a possibilidade de automatizar a coordenação dos processos tem sido explorada, resultando em uma área de pesquisa e tecnologia comumente referenciada como tecnologia de workflow. Em uma das definições da literatura relativa à tecnologia de workflow, Georgakopoulos et al. (1995) a associam à especificação de processos de negócio, reengenharia e automação, quando definem workflow como uma coleção de tarefas organizadas para realizar processos de negócio. Segundo esses autores, workflows são processos – sucessões temporais e lógicas de funções que são necessárias para executar operações em objetos economicamente relevantes – com transições automatizadas, ou seja, processos cujo controle lógico está dentro de um sistema de informação.

Um workflow normalmente é baseado em um modelo de processo, que foi aprimorado com tipos de objetos adicionais, como

www.posugf.com.br


50

estruturas de dados, e atributos, como condições iniciais, que permitem sua automatização, passando a ser chamado de Modelo de Workflow. Modelos de Workflow são normalmente descritos usando gráficos dirigidos cujos elementos representam funções elementares ou compostas. A WfMC (Workfow Management Coalition) define workflow como “a automação de processos de negócio, total ou em parte, na qual documentos, informações e tarefas são passadas de um participante para outro através de uma ação, de acordo com um conjunto de regras de procedimento” (WFMC, 1999).

Ainda segundo a WfMC, os sistemas de gerenciamento de Workflow são “sistemas para definição, criação e gerência da execução de fluxos de trabalho

através do uso de software, capaz de interpretar a definição de processos, interagir com seus participantes e, quando necessário, invocar ferramentas e aplicações.” (WFMC, 1999).

Por estarem diretamente relacionados à área de negócios das organizações, os sistemas de Workflow têm sido indicados como ferramenta para o apoio computacional a processos de negócio. A Figura 11 representa os relacionamentos existentes entre os conceitos de workflow dentro de um processo de negócio.

Figura 11 – Relacionamentos entre a terminologia básica de Workflow.

Pode-se observar nesta figura a estreita relação existente entre a modelagem do processo, representada pela definição do negócio, sub processos e atividades, e a gestão do mesmo, realizada através de Sistemas de Gerenciamento de Workflow.

www.posugf.com.br


51

O Ciclo do Workflow

Quando comparado ao ciclo de vida de um processo, o ciclo do workflow apresenta singular semelhança. E não é por acaso, já que o objetivo principal deste é automatizar processos de negócio. A implantação de um sistema de Workflow obedece a um ciclo composto por cinco etapas:

Revisão do fluxo de trabalho atual;Projeto do modelo do fluxo de informação

do fluxo que se querProgramação do modelo de informação,

com definição e detalhamento de cada um dos elementos nele contidos;

Implantação do Workflow;Atualização do modelo implantado.

O projeto de um novo modelo de informação deve partir de alguma realidade. Assim, é preciso primeiro analisar como o processo atual é executado a fim de que se tenha os elementos necessários para projetar o novo fluxo de trabalho. Nesse ponto a modelagem de processos constitui-se como uma ferramenta de grande valia, principalmente quando o modelo do processo é gerado visando a montagem do workflow.

A segunda etapa consiste em montar o modelo do fluxo de trabalho, definindo

as tarefas e procedimentos existentes, as regras para roteamento dos documentos e informações e os atores (ou papeis) que executarão as tarefas necessárias. Nesta etapa, o modelo do processo, obtido através dos métodos de modelagem de processos é uma ferramenta valiosa para a definição do modelo do fluxo de trabalho.

A próxima etapa envolve a programação/configuração do modelo dentro do

software escolhido para suportar o sistema de workflow. Os softwares de workflow de última geração têm procurado cada vez mais diminuir o trabalho de programação,

fornecendo interfaces mais amigáveis e padronizadas, em que o usuário monta o workflow utilizando estruturas e funções pré-definidas, aumentando o trabalho de configuração e diminuindo o de programação. Interfaces que permitem a montagem gráfica do workflow auxiliam nesta etapa.

A etapa de implantação do workflow exige cuidados quanto ao tamanho do sistema que está sendo implantado. Não se deve querer implantar todos os processos de uma única vez, é sempre aconselhável fazer um piloto do projeto. Além disso, deve-se estar atento ao gerenciamento da mudança imposta pela

introdução dessa tecnologia, pois conforme destaca Cruz (2000):

“A mudança de uma forma de trabalhar, como a que encontramos na maioriadas empresas ainda hoje, para uma

totalmente diferente, por meio daimplantação do fluxo de trabalho automatizado não é pequena, e

reconhecer isso com antecedência é garantir melhores condições para que

o projeto tenha sucesso.”

A quinta e última etapa consiste em revisar e atualizar o sistema implantado e

tem por objetivo a melhoria contínua do processo. Durante a implantação e principalmente no início da utilização do sistema é comum serem detectadas várias deficiências que precisam ser tratadas e saneadas, a fim de que não se acentuem ao longo do tempo.

Em função dos objetivos a serem alcançados, das características dos processos e área de atividade em que estes são utilizados existem diversos tipos de workflow.

Tipos de Workflow

Para Cruz (2000), ainda não existe um consenso entre os especialistas sobre a forma de caracterizar ou categorizar sistemas de

www.posugf.com.br


52

workflow. No entanto, para tornar a modelagem de processos de negócios mais efetiva, é importante que se identifique em qual categoria o processo se enquadra, visto que alguns modelos podem não ser adequados para uma representação de determinadas estruturas de fluxo e decisão. A identificação dos tipos de workflow permite maior segurança na escolha de modelos e de ferramentas de modelagem para representação dos processos de negócios.

Uma classificação que possui boa aceitação é a proposta por McCready (1992), que classifica os sistemas de workflow em três tipos básicos:

● Ad hoc ● Administrativo ● Produção

As dimensões básicas ao longo das quais são caracterizados estes tipos deprocessos incluem:

● repetibilidade e previsibilidade do processo e suas atividades; ● criticidade da missão; ● valor para a organização.

Workflows Ad hoc Os workflows ad hoc executam processos de negócios onde não há um padrão pré-

determinado de movimentação de informação entre pessoas, tais como documentação de produtos ou propostas para venda de produtos. A ordenação e a coordenação de tarefas em um workflow do tipo Ad hoc não são automatizadas, mas controladas por humanos. Esta classe de workflow envolve tipicamente pequenos grupos de profissionais que têm o objetivo de apoiar pequenas atividades que requerem uma solução rápida. A Figura 12 representa um workflow simplificado tipo Ad hoc envolvendo o processo de revisão de artigos para publicação.

Figura 12 – WorkflowAdhocpara revisão de artigos.

O processo mostrado consiste em selecionar os revisores, distribuir os artigospara os revisores selecionados, possibilitar que estes executem as revisões emcolaboração, de forma a produzir um documento de revisão conjunta, e finalmente enviar

para os autores. Neste caso percebem-se duas características do workflow Ad hoc: a

www.posugf.com.br


53

negociação para a seleção de revisores e a colaboração entre os revisores para produção de uma revisão agrupada.

Sistemas de e-mail são exemplos de workflow Ad hoc, onde os usuários podem rotear formulários de negócios eletrônicos como mensagens de correio eletrônico com documentos anexados (attachments).

Workflows Administrativos Os workflows administrativos envolvem

processos repetitivos com regras de coordenação de tarefas simples, tal como roteamento de um relatório de despesa ou requisição de viagem através de um processo de autorização. Não são utilizados para processos com grande complexidade de informação e não requerem acesso a múltiplos sistemas de informação externos. Workflows administrativos geralmente não são usados em sistemas críticos. (GEORGAKOPOULOS et al., 1995)

Considerando novamente o processo de revisão de artigos, para exemplificar

um workflow administrativo, supõe-se que os revisores são previamente conhecidos, ou seja, os mesmos revisores são convidados para revisão de todos os artigos. Além disso, os revisores não colaboram na produção de uma revisão conjunta, produzindo revisões individuais que são consideradas pelo editor para tomar a decisão final (Figura 13).

Figura 13 – WorkflowAdministrativo para revisão de artigos.

Workflows de Produção Oe workflows de produção reúnem

processos de negócios repetitivos e previsíveis, onde a ordenação e coordenação

de tarefas podem ser automatizadas, tais como aprovação de empréstimos e seguros. Diferentemente dos administrativos, os workflows de produção englobam um processamento de informações complexas envolvendo acesso a múltiplos sistemas de informação.

Esse tipo de workflow é utilizado para processos mais críticos, onde o nível de

controle na execução das tarefas deve ser alto, com baixa ou nenhuma intervenção humana. A Figura 14 ilustra um workflow para um processo de requisição de seguro saúde.

Figura 14 – Workflowpara Requisição de Seguro Saúde.

Pode-se observar nesse workflow a presença de sistemas especialistas e bancos de dados auxiliares que são acessados ao longo do processo, de forma a automatizar determinadas tarefas. Dessa forma, elimina-se a necessidade da

intervenção humana nas decisões e encaminhamentos.

Geogakopoulos et al. (1995) classificam os sistemas de workflow em um escala contínua, que possui num extremo os workflows orientados a humanos e no outro os workflows orientados a sistemas (Figura 15). No primeiro tipo a execução e coordenação das tarefas envolvem a colaboração humana. Ambientes desse tipo são utilizados para possibilitar a coordenação e a colaboração entre pessoas, aumentando-lhes o desempenho. Sistemas desse tipo são conhecidos como CSCW (Computer

www.posugf.com.br


54

Supported Cooperative Work), em português, trabalho cooperativo suportado por computador, ou simplesmente “workflow colaborativo”.

Figura 15 – Caracterizando workflow.

O segundo tipo de workflow envolve sistemas de computadores que executam operações computacionais intensas e softwares especializados na execução de tarefas com pequena ou nenhuma intervenção humana (workflow do tipo produção). Esses sistemas precisam incluir um software para controle de concorrência e técnicas de recuperação para assegurar consistência e segurança. A metodologia de modelagem de processos apresentada nesse trabalho pode ser aplicada como etapa inicial de qualquer um dos tipos de workflow apresentados, porém esta se torna relevante para os workflows administrativos e de produção, onde a possibilidade de automatização é maior e, consequentemente, os ganhos também podem ser maiores. O exemplo de validação estudado trata-se de um workflow de produção, já que faz acesso a outros sistemas da organização para atualização de dados e tomadas de decisão.

Sistemas de Gerenciamento de Workflow

Sistemas de Gerenciamento de Workflow (Workflow Management Systems –WFMS) representam hoje uma infraestrutura tecnológica chave por gerenciar efetivamente

processos de negócios em vários setores, incluindo bancos e financeiras, serviços de saúde, telecomunicações, manufatura e produção. Muitas pesquisas têm trabalhado com a fase de modelar esquemas de workflow e vários formalismos já foram propostos para apoiar o projetista na execução desta tarefa. Para dar uma descrição simples e intuitiva da estrutura de um workflow, tais formalismos estão baseados em representações gráficas, como o gráfico de fluxo de controle. Nele, o workflow é representado por um gráfico etiquetado dirigido, cujos nós representam as tarefas a ser executadas, e dos quais partem setas que descrevem a precedência entre eles (Figura 16).

Figura 16 – Exemplo de gráfico de fluxo de controle.

www.posugf.com.br


55

Além disso, a Workflow Management Coalition também identificou controles adicionais, como loops (laços) e subworkflows.

As áreas tradicionais de modelagem de processos de negócio, coordenação de processos de negócio e gerenciamento de documentos e imagens, junto com áreas emergentes como interações business-to-business e business-to-consumer, impulsionaram uma grande diversidade de diferentes sistemas de gerenciamento de workflow a estarem disponíveis como produtos comerciais ou protótipos de pesquisa. Apesar de uma contínua padronização, estes produtos estão frequentemente baseados em diferentes paradigmas e apóiam uma grande variedade de linguagens de modelagem de processos.

As especificações de Workflow podem ser entendidas sob diferentes perspectivas. A perspectiva de controle de fluxo (ou processo) descreve atividades e sua ordem de execução através dos diferentes participantes, o que permite o controle de execução do fluxo, por exemplo, sequência, escolha, paralelismo e sincronização. Atividades na forma elementar são unidades atômicas de trabalho que, em forma de combinação, regula uma ordem de execução de um conjunto de atividades.

A perspectiva de dados classifica dados do negócio e do processamento na perspectiva de controle de fluxo. Documentos empresariais e outros objetos que trafegam entre atividades, assim como variáveis locais do workflow, são classificados em efeito pré e pós-condições de execução da atividade. A perspectiva de recursos proporciona um suporte de estrutura organizacional para o workflow na forma de papeis (roles) de recursos humanos e dispositivos responsáveis por executar atividades.A perspectiva operacional descreve as ações elementares

executadas por atividade, onde as ações são mapeadas dentro das aplicações subjacentes.

Tipicamente, dados empresariais e de workflow são passados para dentro e para fora das aplicações através de interfaces atividade-aplicação, permitindo

manipulação dos dados dentro das aplicações. Um workflow normalmente inclui vários passos lógicos (conhecidos como tarefas), dependências entre tarefas, regras para roteamento e participantes. Uma tarefa pode requerer envolvimento humano ou ser executada automaticamente por aplicações de Tecnologia de Informação (TI).

Um sistema de workflow lê, automatiza, processa e administra fluxos de trabalho, coordenando o compartilhamento e roteando a informação. Durante o processamento, tarefas, informação e documentos são passados de um participante para outro de acordo com um conjunto de regras, rotas e papeis. A automatização de itens de trabalho aumenta a eficiência do processo. Além disso, a administração e análise de instâncias de workflow fornecem uma oportunidade para medir parâmetros dos processos de negócio, a fim de que possam ser feitas melhorias contínuas.

Instâncias de um workflow rodam em um ou mais “motores” de workflow, que

são capazes de interpretar definições de workflow, interagir com participantes do fluxo, e, onde for exigido, interagir com ferramentas e aplicações externas. A WFMC (1995) estabeleceu um Modelo de Referência de Workflow (Workflow Reference Model) que é uma representação gráfica da arquitetura de um sistema de workflow. Neste modelo estão evidenciadas cinco interfaces entre um sistema de gerenciamento de workflow e seu ambiente externo, apresentadas na Figura 17.

www.posugf.com.br


56

Figura 17 - Modelo de Referência de Workflow.

A importância do modelo de referência de workflow estabelecido pela WfMC incide no fato de que ele indica os elementos básicos necessários para que um

sistema de Tecnologia da Informação possa ser considerado como um sistema de gerenciamento de workflow. Um elemento essencial para a identificação de um sistema como sendo de workflow é a presença de um motor, que é o responsável por ativar e dar movimento ao processo. Essa informação normalmente é usada na etapa de comparação e seleção de um sistema de workflow para a organização.

Escolha de um Sistema de Workflow

Atualmente encontra-se disponível um grande número de sistemas comerciaisde gerenciamento de workflow. Estes sistemas diferem no que diz respeito à eficiência,

devido ao fundo histórico distinto entre eles. A seleção de um sistema de gerenciamento de workflow apropriado demanda um processo de seleção eficiente. Durante o processo tradicional de avaliação de software, o enfoque principal baseia-se em aspectos técnicos, como confiabilidade, operacionabilidade, sustentabilidade e adaptabilidade, como também em aspectos econômicos dos sistemas analisados.

O uso de catálogos de critérios representa a prática comum de avaliação desoftware. Porém, eles falham durante a avaliação dos métodos de modelar, porque

não refletem o vasto número de alternativas de modelagem oferecido por um método. A complexidade destas alternativas pode ser reduzida pela formalização da descrição do método.

No caso deste estudo, cuja aplicação está voltada para o setor de prestação de serviços, em especial serviços públicos, a escolha do Sistema de Workflow deve levar em consideração a disponibilidade do workflow não somente para a realização dos serviços internos à

www.posugf.com.br


57

instituição, mas também para o atendimento ao cidadão. A utilização de sistemas de workflow na administração pública está ligada ao conceito de governo eletrônico. Esses sistemas compõem, juntamente com outros sistemas, a estrutura tecnológica que serve de base para a disponibilização de serviços via Web aos cidadãos. Dessa forma, a escolha do sistema de workflow não pode estar desvinculada dos objetivos que se deseja alcançar com a implantação do governo eletrônico.

Video sobreBPM X WORKFLOW http://www.youtube.com/watch?v=KI6x6oJHmGg

Metodologias de Modelagem de Processos

Em função da natureza abstrata dos processos, ter uma compreensão exata deles torna-se uma tarefa difícil sem o uso de uma metodologia de modelagem

padronizada. A modelagem de processos de negócio é uma técnica para compreensão dos processos de uma organização e pode ser considerada um mapa que simula o mundo real, através da representação de pessoas, materiais de trabalho e distribuição de tarefas.

Uma Metodologia de Modelagem de Processos é uma poderosa ferramenta gerencial para identificação de oportunidades de melhorias e visualização de restrições e gargalos. A modelagem de processos não só é uma das exigências da ISO 9000 para a gestão da qualidade e garantia, como também é uma das questões chave na implementação da maioria dos sistemas de informação, como sistemas de gerenciamento de workflow, ERP e e-business.

Os livros sobre processos de negócio fornecem conceitos, uma visão geral e algum estímulo, mas não entram em detalhes a respeito da identificação do processo, modelagem e análise que os profissionais

estão buscando. A descrição encontrada na literatura a respeito da maioria das metodologias de modelagem existentes está centralizada na forma como os objetos são nelas representados. Existem poucos estudos relativos à forma de levantamento dos

dados, à coleta de informações e à interação com a montagem de um sistema de workflow, utilizadas em cada metodologia para a montagem do modelo do processo.

O sucesso da modelagem de processos de negócio depende da seleção apropriada de métodos de modelagem disponíveis, técnicas ou análises de fluxo de processo. Existem muitas técnicas ou análises usadas neste campo, porém a literatura sugere que não existe uma única técnica para uso em modelagem de processos. O mais comum é a utilização de um conjunto de ferramentas que permite o uso de técnicas diferentes, baseado nos dados disponíveis para o desenvolvimento do modelo e relativo ao propósito da modelagem.

Damij (2007) divide as pesquisas e as práticas na área de modelagem de processos em três grupos. O primeiro grupo de estudos compara várias fases da modelagem de processo com ferramentas e técnicas usadas por algumas das principais companhias ao redor do mundo.

O segundo grupo de estudos trabalha com o desenvolvimento de técnicas existentes para modelagem de processo de negócio. Após comparar várias técnicas, eles concluíram que os modelos possuem limitações sérias, como não permitir análises quantitativas, serem subjetivos, apresentarem dados mecanicamente e sua manutenção ser relativamente trabalhosa.

O terceiro grupo estuda e compara várias ferramentas para modelagem de processo de negócio. Como conclusão eles identificaram os seguintes elementos que influenciam no uso dessas ferramentas: objetivo do

www.posugf.com.br


58

projeto, escopo e propósito das mudanças, possibilidade de desenvolvimento de TI, cultura organizacional.

Será apresentada a seguir uma metodologia para modelagem de processos que possuem uma visão mais abrangente, que engloba desde o levantamento dos processos da organização até a montagem do modelo do processo selecionado.

Metodologia de Jacka & Keller (2002)

Para Jacka e Keller (2002), a modelagem de processos não só proporciona uma administração com uma visão global das operações, mas também fornece aos colaboradores uma visão geral de como o seu trabalho agrega valor ao produto ou serviço e como eles fazem parte de uma equipe. Além disso, o sucesso da análise de processos deve levar em consideração os clientes, e isso pode ser qualquer nível de cliente.

Assim como os processos de uma organização passam por numerosas mudanças ao longo do tempo, a compreensão deles também é alterada. Nesse

sentido, em uma organização, os executivos têm uma ideia do processo, os gerentes e supervisores têm outra, o pessoal da linha de produção tem uma terceira e a pessoa que primeiro imaginou o processo não reconheceria o produto acabado.

O modelo de processo é uma visualização da compreensão variável do processo. Após tudo ter sido exposto e realizado, o modelo do processo deveria conciliar o entendimento de todos os envolvidos para espelhar o processo real. Segundo Jacka e Keller (2002), os passos que vão mudar o modelo para refletir a realidade é que o fazem efetivo. Estes passos são:

● identificação do processo (saber o que compõe o processo sob revisão);

● coleta de dados (saber o que ex-iste dentro do processo e quem está com ele envolvido);

● entrevistas e geração do modelo (identificar e registrar as ações dentro do processo);

● análise dos dados (verificar o que pode ser feito para melhorar o processo);

● apresentação (mostrar para to-dos o que foi feito).

Identificação do processo

Ao iniciar a identificação do processo é importante ter em mente que, durante todo o processo de modelagem, deve-se pensar como o cliente, não como a

organização.

As etapas da identificação do processo são as seguintes:

● Identificar os eventos que dispar-am os processos (triggers);

● Identificar os processos críticos para o cliente;

● Identificar os processos de su-porte;

● Nomear os processos; ● Preparar o mapa geral dos pro-cessos.

Uma vez identificados os processos, deve-se começar a resumir a informação

que foi coletada e desenvolver um plano para reunir informações detalhadas

adicionais sobre cada processo.

Coleta de dados

Qualquer análise de processos requer uma metodologia sistemática por reunir

www.posugf.com.br


59

e documentar informações. Existem diversas abordagens possíveis, mas para Jacka e Keller (2002) esta é a que apresenta melhor resultado:

● Identificar o processo; ● Descrever o processo; ● Identificar os donos do processo ou da unidade;

● Entrevistar os donos de pro-cesso ou da unidade, segundo os seguintes aspectos:

o Verificar seu entendimento do processo;

o Determinar os objetivos do negócio;

o Determinar os riscos do negócio;o Determinar os controles chaves;o Determinar as medidas para o

sucesso.

A meta desta etapa é usar as fontes de informação da maneira mais eficiente.

À medida que a informação vai sendo coletada, é necessário um reservatório para armazená-la. Para isso, Jacka e Keller (2002) propõem o uso de tabelas chamadas de Folhas de Trabalho. No início do projeto, o revisor deve estabelecer um conjunto de folhas de trabalho em branco e parcialmente preenchidas para armazenar as informações chave coletadas.

A técnica consiste em reunir os pedaços deste quebra-cabeça e ordenar corretamente as formas para encontrar as partes que encaixam. A Folha de Trabalho mais importante é a do Perfil do Processo, mostrada na Figura 20. Este formulário deve ser criado e preenchido para cada processo sob revisão.

Figura 20 – Folha de Trabalho do Perfil do Processo.

Entrevistas e geração do modelo

A chave para o sucesso da modelagem de processos é a entrevista e a chave

para uma entrevista eficiente é a criação de um ambiente no qual a informação

possa ser compartilhada abertamente. Entrevistas para modelagem de processos não são particularmente diferentes de qualquer outra entrevista para coleta de informação, pois todas envolvem planejamento, conversa, e, acima de tudo, escuta.

Nesta metodologia, os modelos devem ser construídos em tempo real, através do uso da técnica de “post-its”. Isto permite uma sessão muito interativa, que resulta em uma maior quantidade de informação e adicionalmente assegura sua precisão. O topo da página deve mostrar os indivíduos envolvidos e o tempo progride à medida que se desloca para baixo (Figura 21).

www.posugf.com.br


60

Figura 21 – Processo de pagamento através de cheque.

Os modelos e os símbolos utilizados devem ser simples. Não se trata de tentar impressionar as pessoas com a quantidade de informação que se pode colocar em uma página, mas de procurar facilitar a compreensão visual do processo. Se for necessário explorar o modelo mais detalhadamente, pode-se quebrar um processo nos vários elementos que o compõem. Além disso, é recomendável criar uma visão geral para resumir os processos sob revisão.

A geração dos modelos, quando executada cronologicamente, facilita a visualização das ações que possuem desmembramento. À medida que o modelo vai sendo montando, os pontos de demora e retrabalho encontrados no fluxo devem ser identificados para análise de melhoria posterior.

Análise dos dados

Para Jacka e Keller (2002), a análise dos dados deve ser executada através de duas abordagens: revisão das Folhas de Trabalho do Perfil do Processo e busca através dos modelos. A primeira abordagem visa assegurar que a compreensão inicial do processo esteja correta e ter a certeza de que a análise final corresponda à maioria das categorias da folha de trabalho. Estas incluem gatilhos, entradas, saídas, propriedade do processo, objetivos do negócio, riscos do negócio, chaves de controle e medidas do sucesso.

www.posugf.com.br


61

A maioria destas revisões está baseada nas mesmas informações contidas nas folhas de trabalho conforme foram originalmente elaboradas. Porém, os produtos devem ser vistos sob uma ótica diferente. É importante pensar em produtos como resultados e reconhecer que existem quatro tipos de resultados diferentes:

● produtos (o que se espera que o processo produza);

● desperdícios (itens produzidos que não satisfazem as expectati-vas de produção);

● surpresas (ramificações do pro-cesso que podem ser favoráveis ou desfavoráveis, mas são ines-peradas);

● consequências invisíveis (efeitos de longo prazo que não são per-cebidos até que o processo esteja sendo executado durante algum tempo).

Reconhecer e analisar esses resultados ajuda a identificar áreas que necessitam de atenção adicional. Durante a análise dos modelos atuais, o revisor deveria estar atento aos indicadores que representam áreas que necessitam de revisão adicional. A remoção de aprovações aumenta a autoridade dos trabalhadores para completar suas ações de uma maneira mais oportuna. Erros de looping são situações em que o processo tende a voltar pelo mesmo caminho várias vezes até que condições restritivas sejam atendidas. Demoras, retrabalhos e operações manuais devem ser amenizados ou eliminados.

Formulários e relatórios devem ser revisados de perto para verificar se eles podem ser eliminados ou reduzidos. Situações em que os modelos estão incompletos, (por exemplo, ações duvidosas e decisões sem resposta) devem ser identificadas para assegurar que todos os caminhos tenham sido revisados

corretamente. Filas de espera também devem ser revisadas para ver se são realmente necessárias e, caso o sejam, que tenham sido corretamente estabelecidas.

O tempo total do ciclo (lead time) também deve ser observado de perto. Para

as ações individuais, a identificação daquelas que demandam maior tempo mostra onde uma redução do tempo de execução produzirá maior efeito. O tempo total de ciclo para os processos, unidades e tarefas também devem ser revisados, para determinar se medidas de sucesso baseadas no tempo podem ser de fato encontradas. De acordo com os tempos de ciclo, também devem ser revisados os caminhos críticos, para determinar onde podem ocorrer restrições de tempo.

Antes de finalizar o projeto, os indivíduos entrevistados para a montagem dos

modelos devem fazer uma verificação final para assegurar que esses estejam

corretos. O mesmo deve ser feito com qualquer supervisor ou gerente envolvido. Finalmente, deve ser obtida a validação do dono do processo. Esta discussão ajuda a identificar qualquer problema com o modelo e prepara o dono para o relatório final.

Apresentação

Ao colocar juntas a definição do processo, a coleta de dados, as entrevistas, a

geração do modelo e a análise, o resultado deve ser um relatório final. Este é o

produto que o revisor trabalhou para construir e é o produto que a gerência deseja ver. Eventualmente, este relatório pode ser apresentado para o público interessado.

ReferênciasPFLEEGER, S. L. EnGEnhaRia dE SoFtwaRE:

tEoRia E PRática, PREnticE haLL do BRaSiL, 2ª Edição, 2004

www.posugf.com.br


62

Pressman R. EnGEnhaRia dE SoFtwaRE - 6a Edição - McGRaw-hiLL ... oF thE 27th intERnationaL conFEREncE on SoFtwaRE EnGinEERinG 2005

BOeGH, J., HaUsen, H. L., WeLZeL, D., 1993, “a PractiOners GUiDe tO evaLUatiOn OfsOftWare”, in: SoFtwaRE EnGinEERinG StandaRdS SyMPoSiuM, BriGHtOn, inGLaterra, aGOstO.

iSo/iEc 9126, 1991, inFoRMation tEchnoLoGy

– SoFtwaRE PRoduct EvaLuation – QuaLity

chaRactERiSticS and GuidELinES FoR thEiR uSE.

PMi. uM Guia dE conhEciMEntoS EM GEREnciaMEnto dE PRojEtoS - Guia PMBoK. Eua, PMi, 3ª Edição, 2004.

nawaR Khan “BESt tQM PRacticES GuaRdianS SatiSFaction indEx - a caSE Study” (2003 ) PaKiStanS FiRSt nationaL conFEREncE on QuaLity aSSuRancE in Education May 10 - 11, at LahoRE, PaKiStan voL: PP:- (conFEREncE PuBLication)

cavano, j.P., MccaLL, j.a., a FRaMEwoRK FoR thE MEaSuREMEnt oF SoFtwaRE QuaLity, PRoc. oF thE acM SoFtwaRE QuaLity aSSuRancE woRKShoP, PP. 133-139, nov. 1978.

wEBER, K.c.; da Rocha, a.R.c.; do naSciMEnto, c.j. (oRGS.) QuaLidadE E PRodutividadE EM SoFtwaRE. São PauLo: MaKRon, 2001.

iSo/iEc 12119. [on-LinE]tRadução LivRE, PRiMEiRa Edição dE 06/11/98. [acESSado 20 Maio dE 2000] diSPonívEL na intERnEt <httP://www.inSoFt.SoFtEx.BR/hoME/coPES/GEQS/indEx.htML>

iSo/iEc diS 14598-5 inFoRMation tEchnoLoGy

EvaLuation oF SoFtwaRE PRoduct PaRt 5: PRocESS FoR EvaLuatoRS. oBtido na intERnEt EM Maio/2000 httP://www.cSE.dcu.iE/ESSiScoPE/SM4/14598-5.htML

cÔRtES, MaRio, “ModELoS dE QuaLidadE

dE SoFtwaRE”, caMPinaS, SP: EditoRa da unicaMP,inStituto dE coMPutação, 2001, 148 P.

iPcc - chaPtER 8 QuaLity aSSuRancE and QuaLity contRoL iPcc Good PRacticE GuidancE and uncERtainty ManaGEMEnt in nationaL GREEnhouSE GaS invEntoRiES 8.1 8 QuaLity aSSuRancE and acESSado EM 30 dE juLho dE 2009 http://www.ipcc-nggip.iges.or.jp/public/gp/english/8_QA-QC.pdf

Rocha. “PRocESSoS dE SoFtwaRE”. diSPonívEL EM:<httP://www.Lia.uFc.BR/~Eti/2003/MEnu/ModuLoS/EnGSoFt/EnGSoFtPRocESSodESoFtwaRE.PdF>.

chRiSSiS, M. B., KonRad, M., ShRuM, S. (2003), cMMi®: GuidELinES FoR PRocESS intEGRation and PRoduct iMPRovEMEnt, addiSon wESLEy.

RoycE, waLKER. “cMM vS. cMMi: FRoM

convEntionaL to ModERn SoFtwaRE ManaGEMEnt”, vicE PRESidEnt and GEnERaL ManaGER _StRatEGic SERvicES. <www.thERationaLEdGE.coM/contEnt/FEB_02/F_convEntionaLtoModERn_wR.htM>

cMMi® PaRa dESEnvoLviMEnto, vERSão 1.2 - Fundação cPQd

cRuZ, t. woRKFLow: a tEcnoLoGia QuE vai REvoLucionaR PRocESSoS. 2. Ed. São PauLo: atLaS, 2000.

daMij, n. BuSinESS PRocESS ModELinG uSinG diaGRaMMatic and taBuLaR

tEchniQuES. BuSinESS PRocESS ManaGEMEnt jouRnaL, v. 13, n. 7, P. 70-90, 2007.

davEnPoRt, t. h. REEnGEnhaRia dE PRocESSoS. Rio dE janEiRo: caMPuS, 1994.

GEoRGaKoPouLoS, d.; hoRnicK, M.; ShEt, a. an ovERviEw oF woRKFLow ManaGEMEnt: FRoM PRocESS ModELinG to woRKFLow autoMation inFRaStRuctuRE. diStRiButEd and PaRaLLEL dataBaSES, v. 3, n. 2, P. 119-153, 1995.

GEoRGaKoPouLoS, d.; tSaLGatidou, a. tEchnoLoGy and tooLS FoR

www.posugf.com.br


63

coMPREhEnSivE BuSinESS PRocESS LiFEcycLE ManaGEMEnt. in: PRocEEdinGS oF thE nato advancEd Study inStitutE on woRKFLow. voL. 164. iStaMBuL, tuRKEy. auGuSt,1997.

GonçaLvES, j. E. L. aS EMPRESaS São GRandES coLEçõES dE PRocESSoS. RaE - REviSta dE adMiniStRação dE EMPRESaS. v. 40, n. 1, jan./MaR., 2000.

haMMER, M.; chaMPy, j. REEnGinEERinG thE coRPoRation. nEw yoRK:

haRPERBuSinESS, 1994.

haRRinGton, h. j.; ESSELinG, E. K. c.; niMwEGEn, h. v. BuSinESS PRocESS iMPRovEMEnt woRKBooK: docuMEntation, anaLySiS, dESiGn and ManaGEMEnt oF BuSinESS PRocESS iMPRovEMEnt. nEw yoRK: McGRaw hiLL, 1997.

jacKa j. M.; KELLER, P. j. BuSinESS PRocESS MaPPinG: iMPRovinG cuStoMER

REFERênciaS 125 PPGEP – GEStão induStRiaL (2009). nEw yoRK: john wiLEy & SonS, 2002.

LaRSon, E.; LaRSon, R. BPM: an anaLyticaL PERSPEctivE. diSPonívEL EM:

<httP://www.BPM.coM/FEatuRERo.aSP?FEatuREid=174>. acESSo EM: 05 jun. 2011.

MaRanhão, M.; MaciEiRa, M. E. B. o PRocESSo noSSo dE cada dia: ModELaGEM dE PRocESSoS dE tRaBaLho. Rio dE janEiRo: QuaLityMaRK Ed., 2004.

MccREady, S. thERE iS MoRE than onE Kind oF woRKFLow SoFtwaRE.

coMPutERwoRLd, v. 26, novEMBER 2, 1992.

ouLd, M. a. BuSinESS PRocESS ManaGEMEnt: a RiGoRouS aPPRoach. FLoRida: MEGhan-KiFFER PRESS, 2005.

wFMc – woRKFLow ManaGEMEnt coaLition. tERMinoLoGy & GLoSSaRy. docuMEnt nuMBER wFMc-tc-1011, docuMEnt StatuS - iSSuE 3.0, FEvEREiRo 1999. diSPonívEL EM: <httP://www.wFMc.oRG/StandaRdS/docS/tc-

1011_tERM_GLoSSaRy_v3.PdF>. acESSo EM: 03 Mai. 2011.

wFMc – woRKFLow ManaGEMEnt coaLition. thE woRKFLow REFEREncE ModEL. docuMEnt nuMBER wFMc-tc-1003, docuMEnt StatuS - iSSuE 1.1, janEiRo 1995. diSPonívEL EM:<httP://www.wFMc.oRG/StandaRdS/docS/tc003v11.PdF>. acESSoEM: 03 Mai. 2011.

Documents

Gestão Estratégica da Tecnologia da Informação