Seis Sigma + CMMI 21

Modstia parte, sua melhor opo para se destacar no mercado!
A Escola Superior da Tecnologia da Informao oferece as melhores opes em cursos, formaes, graduaes e ps-graduaes para profissionais de desenvolvimento e programao. So programas voltados para a formao de profissionais de elite, com aulas 100% prticas, corpo docente atuante no mercado, acesso mais atualizada biblioteca de TI do Rio, laboratrios equipados com tecnologia de ponta, salas de estudo e exames.
PS- GRADUAO
Engenharia de Software: Desenvolvimento Java Engenharia de Software: Desenvolvimento .NET

GRADUAO
Engenharia de Computao Anlise e Desenv. de Sistemas

F ORMAES
Desenvolvedor Java Desenv. Java: Sist. Distribudos Gestor de TI Desenvolvedor Web .NET 2008 MCITP Server Administrator SQL Server 2008
r/esti Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

TURMAS NO RIO DE JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
EDUCAO SUPERIOR ORIENTADA AO MERCADO
O
Ano 2 - 21 Edio - 2010 Impresso no Brasil
EDITORIAL
Corpo Editorial
Colaboradores Rodrigo Oliveira Spnola rodrigo@sqlmagazine.com.br Marco Antnio Pereira Arajo Eduardo Oliveira Spnola Capa Romulo Araujo - romulo@devmedia.com.br Diagramao Janete Feitosa Coordenao Geral Daniella Costa - daniella@devmedia.com.br Revisor e Supervisor Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br Na Web www.devmedia.com.br/esmag
Apoio
propsito da qualidade estabelecer um diferencial competitivo, atravs de contribuies como reduo de defeitos, reduo de custos, reduo de retrabalho e aumento da produtividade, entre outras. Existem diversas iniciativas para garantia da qualidade de produtos e processos nas empresas. Nesta edio, a Engenharia de Software Magazine destaca duas delas: CMMI, (Capability Maturity Model Integration), um modelo de maturidade mundialmente conhecido, usado para criar uma infraestrutura de processos organizacionais, abordando domnios especficos, tais como software e engenharia de sistemas. Seis Sigma, uma metodologia criada pela Motorola, caracterizada por uma abordagem sistmica e utilizao intensiva do pensamento estatstico, que visa a reduo de defeitos nos produtos para 3,4 defeitos por milhes de oportunidades (Seis Sigma) por meio da otimizao de produtos e processos. Neste contexto, temos como capa desta edio um artigo que fornece a compreenso necessria das relaes entre as iniciativas e propor a utilizao do Seis Sigma na melhoria da qualidade de software para a obteno dos nveis de maturidade 4 e 5 do CMMI. Alm desta matria, esta edio traz mais cinco artigos: Colaborao em Processos de Aquisio de Software Customizao e Integrao de Ferramentas Open-Source Organizao Fbrica de Experincia Mtricas de Software Integrao contnua com Hudson, Maven2, TestNG e Subversion Desejamos uma tima leitura! Equipe Editorial Engenharia de Software Magazine
Atendimento ao Leitor A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de jornal, entre outros, entre em contato com:
Cristiany Queirz Atendimento ao Leitor www.devmedia.com.br/mancad
(21) 2220-5338
Rodrigo Oliveira Spnola

rodrigo@sqlmagazine.com.br Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.
Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

(21) 2220-5338
Marco Antnio Pereira Arajo

(maraujo@devmedia.com.br) Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Linha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.
Publicidade Para informaes sobre veiculao de anncio na revista ou no site entre em contato com:
Kaline Dolabella publicidade@devmedia.com.br
Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugesto! Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine, entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria de publicar: Rodrigo Oliveira Spnola - Colaborador editor@sqlmagazine.com.br
Eduardo Oliveira Spnola

(eduspinola@gmail.com) Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
Caro Leitor,
Para esta edio, temos um conjunto de 4 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Tipo: Requisitos Ttulo: Diagrama de Casos de Uso na Prtica Partes 4 a 7 Autor: Rodrigo Oliveira Spnola Mini-Resumo: Estas aulas so parte de uma srie sobre a construo de diagrama de casos de uso da UML. O objetivo do conjunto de aulas apresentar de forma prtica como elaborar o diagrama de casos de uso a partir de diferentes estudos de caso. Nestas aulas, sero elaborados diversos diagramas de casos de uso. Tambm ser visto como especificar um caso de uso para um dos diagramas elaborados.
NDICE
Abordagens Tradicionais de Desenvolvimento 05 - Seis Sigma e CMMI
Luiz Fernando da Silva Fiel, Ana Nathalie de Mello Rodrigues e Marcelo Nascimento Costa
32 - Colaborao em Processos de Aquisio de Software

Joo Condack, Rafael Vieira
38 - Organizao Fbrica de Experincia

Fernando Hadad Zaidan, George Leal Jamil e Leandro Librio da Silva
43 - Customizao e Integrao de Ferramentas Open-Source

Felipe Furtado, Gustavo Carvalho, Andrea Pinto e Ryan Albuquerque
50 - Mtricas de Software
Thamine Chaves Leite de Abreu, Leonardo da Silva Mota e Marco Antnio Pereira Arajo
Validao, Verificao e Teste 56 - Integrao contnua com Hudson, Maven2, TestNG e Subversion
Victor Vidigal Ribeiro, Fabrcio Nogueira de Almeida e Marco Antnio Pereira Arajo
Engenharia de Software Magazine
Abordagens Tradicionais de Desenvolvimento

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens tradicionais de apoio ao desenvolvimento de projetos de software
Seis Sigma e CMMI

Uso do Seis Sigma para Melhoria da Qualidade de Software junto aos Altos Nveis de Maturidade do CMMI
O
Luiz Fernando da Silva Fiel
Bacharel em Cincia da Computao pelo Centro Universitrio Metodista Bennett.
Ana Nathalie de Mello Rodrigues

Estagiria na rea de Governana de TI da Wilson, Sons. Bacharel em Cincia da Computao pelo Centro Universitrio Metodista Bennett. Tcnica em Processamento de Dados pela FAETEC.
Marcelo Nascimento Costa

mnc@kalisoftware.com
Diretor de Tecnologia da Kali Software. Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ. Bacharel em Cincia da Computao pela UFPA. Especialista em CMMI, tendo participado de diversas implementaes e avaliaes deste modelo. Professor do curso de Cincia da Computao do Centro Universitrio Metodista Bennett.
propsito da qualidade estabelecer um diferencial competitivo, atravs de contribuies como reduo de defeitos, reduo de custos, reduo de retrabalho e aumento da produtividade, entre outras. Existem diversas iniciativas para garantia da qualidade de produtos e processos nas empresas. Para este artigo, selecionamos duas: CMMI, (Capability Maturity Model Integration), um modelo de maturidade mundialmente conhecido, usado para criar uma infraestrutura de processos organizacionais, abordando domnios especficos, tais como software e engenharia de sistemas. Seis Sigma, uma metodologia criada pela Motorola, caracterizada por uma abordagem sistmica e utilizao intensiva do pensamento estatstico, que visa a reduo de defeitos nos produtos para 3,4 defeitos por milhes de oportunidades (Seis Sigma) por meio da otimizao de produtos e processos.
O objetivo deste artigo fornecer a compreenso necessria das relaes entre as iniciativas e propor a utilizao do Seis Sigma na melhoria da qualidade de software para a obteno dos nveis de maturidade 4 e 5 do CMMI.
Introduo
Motivao
Em meados dos anos 80, influenciado pela introduo crescente de tcnicas industriais japonesas nas fbricas brasileiras, o conceito de melhoria da qualidade ganhou destaque. Foi o auge do impacto nipnico na indstria nacional, impulsionado por visita de tcnicos brasileiros ao Japo em misses especiais e pelo sucesso das ferramentas japonesas de administrao da qualidade. O desenvolvimento de novas tcnicas de produo e a adaptao de procedimentos criados, sobretudo no Japo, foram experincias marcantes no perodo, caracterizado tambm pelo advento
Edio 21 - Engenharia de Software Magazine
da norma ISO 9000, ento vista como nova forma de avaliar o processo produtivo. No Brasil, o termo qualidade tem mudado seguidamente de sentido. Ainda persiste a ideia de que a qualidade o esforo para minimizar defeitos. Como tambm permanece a viso de que a qualidade est restrita s melhorias localizadas. Ou at mesmo a uma maior qualificao das pessoas. Mas atualmente a qualidade j pode ser vista como um diferencial ou at mesmo como um item bsico de manuteno da empresa, principalmente nestes tempos de concorrncia acirrada (CARVALHO; PALADINI, 2005). Em termos simples e objetivos, o propsito da qualidade estabelecer um diferencial competitivo. Ou seja: garantir um espao para a organizao, diferenciando-a das demais existentes no mercado. Em outras palavras: fixar razes frente dos concorrentes. A qualidade oferece contribuies operacionais que no podem ser desprezadas, como por exemplo: reduo de defeitos, reduo de custos, reduo de retrabalho, aumento da produtividade. Existem tambm contribuies tticas relevantes como a formao de pessoas mais preparadas para tomar decises gerenciais crticas para o funcionamento da empresa. Mas as contribuies mais relevantes so as de natureza estratgica: garantir no apenas a sobrevivncia da organizao, mas seu contnuo crescimento (evoluo). Considerando o escopo das empresas de processo de software, alm das certificaes ISO entre outras iniciativas aplicveis, existem modelos de maturidade como o CMMI e o MPS.BR, que podem ser utilizados para atingir os objetivos de qualidade desejados. O que move as empresas no processo de obteno das certificaes dos altos nveis de maturidade (tanto do CMMI quanto do MPS.BR) a necessidade de se ter qualidade de processos, condies de previsibilidade em termos de prazo, de custo e de volume de trabalho a ser feito para que consiga satisfazer o cliente. As empresas esto sempre em evoluo para atender as exigncias do mercado cada vez mais competitivo e com as certificaes de maturidade, so adquiridas condies de medir a melhoria e comprovar as vantagens de se encontrar em outro nvel de excelncia em termos de controle de processos. Para algumas empresas, as principais dificuldades encontradas na obteno dos mais altos nveis so: o custo de implementao (melhorar requer mudanas e mudanas geram custos) e a maturidade organizacional, que requer tambm uma mudana cultural e a colaborao de todas as equipes. Estas dificuldades trazem resistncia por parte dos envolvidos, porm, ao longo do tempo percebe-se que o custo muito maior quando no se pratica estes processos, pois o nvel de qualidade menor e h muito retrabalho.
de maturidade mundialmente conhecido, usado para criar uma infraestrutura de processos organizacionais, abordando domnios especficos, tais como software e engenharia de sistemas; 2. Seis Sigma -uma iniciativa top-down que abrange toda a empresa, incluindo reas como engenharia, vendas, marketing e pesquisa. Pode ser definido como estratgia gerencial, filosofia oumetodologia, que tem por objetivo reduzir drasticamente a variabilidade dos processos crticos e aumentar a lucratividade das empresas, por meio da otimizao de produtos e processos, buscando satisfao de clientes e consumidores (CARVALHO; PALADINI, 2005). Concepes to diferenciadas podem gerar dvidas como: Ser que interessante utilizar ambos no mesmo processo de melhoria? A qualidade pode aumentar dessa forma? O Seis Sigma uma boa alternativa para empresas de TI?. Desta forma,o objetivo deste artigo fornecer a compreenso necessria das relaes entre as iniciativas, de modo quesua aplicao em conjunto seja bem sucedida.
Organizao do Artigo
Os tpicos a seguir mostram como est organizado este artigo. Inicialmente ser abordado o histrico dos modelos de qualidade, passando por gesto e excelncia, e trata do modelo CMMI, mostrando suas principais caractersticas, como estrutura e benefcios. Na sequencia, apresentado o Seis Sigma, fazendo um relato do histrico, objetivos, perfis das pessoas responsveis pela implementao do modelo e suas metodologias. Feito isto, apresentada aplicao do Seis Sigma na melhoria dos processos de qualidade de software, atravs do mapeamento de suas atividades com as prticas definidas nos nveis de maturidade 4 e 5 do CMMI. Ainda neste tpico, apresentado um estudo de caso da aplicao integrada do Seis Sigma e CMMI em uma empresa de software, mostrando como esta estratgia de melhoria de processos pode trazer benefcios significativos. Finalmente, apresentada a concluso deste trabalho.
Histrico dos Modelos de Qualidade

Relatos Histricos
A necessidade pela gesto da qualidade surgiu h muitos anos atrs, onde os artesos faziam todo o processo, desde a concepo at o ps-venda de seus produtos. Como a populao no era numerosa, as necessidades eram mnimas e o trabalho era artesanal. O arteso, sabendo que seus produtos dependiam da reputao de qualidade, que era feita pelo boca a boca dos clientes, usava como abordagem de qualidade o atendimento s necessidades do cliente. Por esse motivo, nessa poca o foco do controle da qualidade ainda era o produto, no o processo. Como exemplo disso, no final do sculo XIX, a montadora de automveis Panhard e Levassor (P&L) montava
Objetivos
Este artigo prope uma soluo integrada em termos de melhoria de processos de software e obteno de altos nveis de maturidade, atravs da utilizao de duas iniciativas: 1. CMMI (Capability Maturity Model Integration)-um modelo
Engenharia de Software Magazine - Seis Sigma e CMMI
M etodologias geis
seus veculos atendendo s necessidades dos clientes que a procuravam, e como era um produto para poucos, no havia dois carros iguais. Em 1750, durante a Revoluo Industrial, surgiram as primeiras mquinas projetadas para obter grande volume de produo e uma nova forma de organizao do trabalho permitiu alcanar a produo em massa. Nessa nova ordem produtiva, a customizao foi substituda pela padronizao e a produo em larga escala. A linha de montagem era o modelo ideal para a produo em massa. O trabalho foi fragmentado e os trabalhadores tinham domnio apenas de uma pequena frao do trabalho. O trabalhador no fazia mais parte das etapas de concepo e planejamento e surgiu a funo do inspetor, responsvel pela qualidade dos produtos. No perodo de 1908 a 1927, a Ford tinha apenas um carro na linha de montagem, o modelo Ford T ou Ford Bigode, como era conhecido. Tinha uma nica cor, a preta. De qualquer forma, 15 milhes de unidades foram vendidas. O carro passou a ser um produto acessvel classe trabalhadora, mudando o conceito dessa indstria, que investiu em capacidade para atender demanda, que era maior que a oferta. Como um veculo ainda diferia bastante de outro produzido sob o mesmo projeto, a Ford investiu na intercambialidade das peas e na facilidade de ajustes, adotando um sistema padronizado de medida para todas as peas. O modelo de linha de montagem se difundiu em outros industriais, e para garantir a intercambialidade das peas, tornou-se importante investir no desenvolvimento de reas com a metrologia, sistema de medidas e especificaes. O foco da qualidade ainda era a inspeo, mas j existiam elementos que mostravam o que viria a ser o conceito de qualidade que priorizava uma abordagem voltada produo e conformidade.
prever o comportamento do processo, o que permitiria uma ao proativa, evitando novas ocorrncias. A facilidade de utilizao do grfico foi um dos aspectos que ajudou na sua difuso, pois era uma ferramenta visual, que podia ser preenchida no ambiente de trabalho, com os parmetros estatsticos do processo j sintetizados (CARVALHO; PALADINI, 2005). Geralmente, o grfico de controle utilizado na deteco de alteraes inusitadas de uma ou mais caractersticas de um processo ou produto. Em outras palavras, uma ferramenta estatstica que alerta para a presena de causas especiais grandes na linha de produo. Existem diversos tipos de grficos de controle e cada um deles melhor aplicvel a determinadas situaes. Normalmente, todos os tipos de grficos de controle seguem a estrutura da Figura 1.
Figura 1. Grfico de controle em formato conceitual (Fonte: Adaptao (CARVALHO; PALADINI, 2005))
Gesto da Qualidade
Existem algumas pessoas que so consideradas como Gurus da Qualidade. Eles foram alguns tericos que ajudaram a construir a rea de qualidade e tiveram um papel especial para merecer a denominao. Alguns dos Gurus mais citados so: Walter A. Shewhart, W. Edwards Deming, Joseph M. Juran, Armand Feigenbaum, Philip B. Crosby, Kaoru Ishikawa e Genichi Taguchi. Em 1924, Walter A. Shewhart fez o conceito de controle da qualidade dar um novo salto, criando os grficos de controle. Com essa ferramenta, Shewhart fundiu os conceitos de estatstica em um mtodo grfico de fcil utilizao no cho de fbrica e os aplicou realidade produtiva da empresa de telefonia Bell Telephone Laboratories. A ferramenta proposta analisava os resultados das inspees, que at aquele momento eram utilizadas apenas para a segregao dos produtos com defeito, por meio de grficos de controle, que permitiam facilmente distinguir entre as causas de variao comuns ao processo e aquelas causas especiais, que deveriam ser investigadas. Com a anlise desses resultados luz dos conceitos estatsticos era possvel sair de uma postura reativa e entender e
O grfico consiste na plotagem de trs linhas e os pontos que representam as mdias de pequenas amostras (chamados subgrupos racionais), cada qual de tamanho n (= 1, 4, 9, 16, 1000, por exemplo), de mensuraes peridicas de alguma caracterstica importante de um processo (peso, cumprimento, volume etc.), ou o nmero ou porcentagem de peas defeituosas ou nmero de defeitos. As trs linhas representam dois limites de controle, um superior (LCS) e outro inferior (LCI), e uma linha no meio que a mdia da varivel ou o alvo da caracterstica. Tradicionalmente, as linhas de controle ficam numa distncia de trs desvios-padro da mdia ou do alvo do processo. Os limites definem uma rea razoavelmente grande que vai evitar alarmes falsos. O desvio-padro utilizado o desvio-padro das mdias (erro-padro); teoricamente, o desvio-padro da populao dividido pela raiz quadrada do tamanho da amostra - /n. Em termos estatsticos, os dois limites de controle definem um intervalo de confiana com nvel de confiana de 99,73%. Esse nmero significa que um alarme falso pode ocorrer uma vez em 370 subgrupos. Se forem tiradas 16 amostras por dia numa fbrica, o alarme falso iria ocorrer apenas uma vez a cada 23 dias, um preo muito razovel, considerando-se o grande valor relacionado aos grficos de controle (CARVALHO; PALADINI, 2005).
Walter A. Shewhart tambm props o ciclo PDCA (plan-docheck-act), que direcionaria as atividades de anlise e soluo de problema, percorrendo o ciclo de planejar, fazer, checar o resultado e depois agir, ou seja, implementar a melhoria e garantir o alcance das metas na empresa, disseminado para o mundo por Deming William Edwards, que era seu discpulo. O ciclo PDCA composto das seguintes etapas (Figura 2):
Caso no sejam identificados desvios, possvel realizar um trabalho preventivo, identificando quais os desvios so passveis de ocorrer no futuro, suas causas, solues etc. O PDCA pode ser utilizado na realizao de toda e qualquer atividade da organizao (Tabela 1). O ideal que todos utilizem esta ferramenta de gesto no dia-a-dia de suas atividades.
Da Gesto da Qualidade para a Qualidade Total

A gesto da qualidade consiste no conjunto de atividades coordenadas para dirigir e controlar uma organizao com relao qualidade, englobando o planejamento, o controle, a garantia e a melhoria da qualidade (CARVALHO; PALADINI, 2005). Esse conceito necessita ser trazido para o mbito organizacional, ou seja, precisa ser operacionalizado na organizao. Existe uma necessidade de gerenciar o conjunto de atividades relativas qualidade, de modo que atenda a qualquer enfoque. A Figura 3 mostra a relao entre a definio da qualidade estabelecida pela norma ISO 9000: 2000, seguido pela necessidade de trazer essa definio para a operao organizacional, por meio da gesto da qualidade, que, por sua vez, se subdivide em planejamento, controle, garantia, e melhoria da qualidade, cujas definies so tambm apresentadas na Figura 3 (CARVALHO; PALADINI, 2005).
Figura 2. Ciclo PDCA
Planejar (PLAN) Definir as metas a serem alcanadas; Definir o mtodo para alcanar as metas propostas. Executar (DO) Executar as tarefas exatamente como foi previsto na etapa de planejamento; Coletar dados que sero utilizados na prxima etapa de verificao do processo; Nesta etapa so essenciais a educao e o treinamento no trabalho. Verificar, checar (CHECK) Verificar se o executado est conforme o planejado, ou seja, se a meta foi alcanada, dentro do mtodo definido; Identificar os desvios na meta ou no mtodo. Agir corretivamente (ACTION) Caso sejam identificados desvios, necessrio definir e implementar solues que eliminem as suas causas;
PDCA 1 2 3 4 D C 5 6 7 A 8 Concluso FLUXO ETAPA Identificao do Problema Observao Anlise Plano de ao Execuo Verificao Padronizao
Figura 3. Inter-relao entre o conceito de qualidade, Gesto da Qualidade e elementos que a compem. Fonte: Adaptao (CARVALHO; PALADINI, 2005) OBJETIVO
Definir claramente o problema/processo e reconhecer sua importncia. Investigar as caractersticas especficas do problema/processo com uma viso ampla e sob vrios pontos de vista. Descobrir a causa fundamental. Conceber um plano para bloquear a causa fundamental. Bloquear a causa fundamental. Verificar se o bloqueio foi efetivo. Prevenir contra o reaparecimento do problema.
Recapitular todo o mtodo de soluo do problema para trabalhos futuros.
Tabela 1. Etapas do Ciclo PDCA (Fonte: Adaptao (SSPJ, 2009))
M etodologias geis
A partir da Figura 3, que mostra o conceito de gesto da qualidade, e das inter-relaes mostradas, o que poderia definir a qualidade total? De acordo com a ISO 8402: 1994, pode ser definida como o modo de gesto de uma organizao, centrado na qualidade, baseado na participao de todos os membros, visando ao sucesso a longo prazo, por meio da satisfao do cliente e dos benefcios para todos os membros da organizao e sociedade. A origem da qualidade total remonta dcada de 1950. Armand Feigenbaum foi o primeiro a tratar a qualidade de forma sistmica nas organizaes, formulando o sistema de Controle da Qualidade Total (TQC Total Quality Control) em seu livro. Essa origem desencadeou o conceito do que viria a tornar-se duas correntes similares, porm diferenciadas, do TQC: a viso japonesa, conhecida como CWQC (Company-wide Quality Control que no Brasil foi traduzido para Qualidade por Toda a Empresa ou Controle da Qualidade Amplo Empresarial) e a viso norte-americana do TQC. O CWQC surgiu no Japo no final de dcada de 60. Kaoru Ishikawa teve importante papel no CWQC, contribuindo para sua formulao. Em alguns livros, os autores traduzem o TQC japons da seguinte forma: o compromisso para a qualidade total, enaltecendo o envolvimento e comprometimento dos funcionrios com essa prtica, aliado ao apoio da alta direo da empresa. Outro ponto central do CWQC o gerenciamento pelas diretrizes, que direciona o foco organizacional s metas da organizao por meio do desdobramento dessas metas e do envolvimento e autonomia dos funcionrios na gesto das atividades dirias da organizao. No TQC americano existe outro foco, que Feigenbaum define como um sistema eficaz para integrar a manuteno da qualidade e os esforos de melhoria da qualidade dos vrios grupos na organizao, de modo a possibilitar a produo em nveis mais econmicos, permitindo alcanar a completa satisfao dos clientes. Mesmo existindo diferenas entre as linhas de pensamento japonesa e americana, sobre o que vem a ser o TQC, na essncia, o conceito bastante similar. No Japo acontece um maior envolvimento e comprometimento dos funcionrios nas atividades da gesto da qualidade e nos Estados Unidos existe muita nfase aplicao de mtodos e tcnicas associadas qualidade. Outro ponto que nos Estados Unidos a maior preocupao com a deteco dos problemas e segregao dos produtos com defeitos e no Japo, as empresas desenvolvem processos capazes de detectar e evitar os problemas.
Aps uma evoluo, o TQC viria a se tornar o TQM (Gesto de Qualidade Total ou Total Quality Management). Esse termo surgiu em 1980. A ideia central do TQM que a qualidade esteja presente na funo de gerenciamento organizacional, em uma tentativa de ampliar seu foco, no se limitando s atividades inerentes ao controle (CARVALHO; PALADINI, 2005). Desde seu surgimento at meados da dcada de 1990, diversos estudos indicaram elementos que so considerados como fatores crticos que devem estar presentes no TQM. So eles: Liderana e apoio da alta direo; Relacionamento com os clientes; Gesto da fora de trabalho; Relao com os fornecedores; Gesto por processos; Projeto de produto; Fatos e dados da qualidade.
Modelos de Excelncia
A qualidade total bastante ampla, envolvendo diversas reas funcionais das organizaes, mas tambm diferentes conceitos, que vo desde a liderana at os meios de controle nos processos produtivos. Uma evoluo no conceito da qualidade total veio com a necessidade de incorporar os diversos interesses dos stakeholders (partes interessadas) de
uma organizao na busca da excelncia em desempenho. No passado, o acionista ou proprietrio da organizao era a maior parte interessada em seu desempenho, para o qual era dada a maior ateno e importncia. Atualmente ele continua sendo mais importante, mas a alterao do enfoque considera hoje outros indivduos, grupos de indivduos, ou seja, agentes interessados no desempenho de uma organizao. Essa mudana ocorreu pelo fato de no ser suficiente que uma organizao concentre seus esforos somente no desempenho financeiro. O enfoque deve considerar as pessoas e processos e os agentes internos e externos, que so formados pelos acionistas ou proprietrios, pelos clientes da organizao, pela fora de trabalho, pelos funcionrios e pela comunidade e sociedade. Os modelos de excelncia visam a avaliar a gesto de uma organizao com relao s prticas de gesto utilizadas e os resultados organizacionais, de forma direcionada para atender s necessidades de seus stakeholders. As organizaes descrevem as prticas organizacionais por meio de um relatrio, que avaliado por especialistas. Posteriormente, as organizaes recebem um relatrio de avaliao, podendo ou no ser premiadas. A premiao um reconhecimento das prticas de gesto. Prmio Deming Em junho de 1950, W. Edwards Deming foi ao Japo falar sobre controle de qualidade, a convite da Unio da Cincia e Engenharia Japonesa (JUSE). Entre 1950 e 1952 Deming conseguiu reunir e sensibilizar os principais executivos japoneses das grandes empresas e mostrou-lhes a importncia do controle estatstico da qualidade (ABRANTES, 2001). A convivncia com os japoneses durou quase duas dcadas, perodo em que as empresas japonesas fizeram uma verdadeira revoluo, em termos de qualidade. Em agradecimento ao papel desempenhado, Deming era tratado como pai do controle de qualidade no Japo e seu nome tornou-se o Prmio Japons da Qualidade Deming Prize (CARVALHO; PALADINI, 2005). O modelo de excelncia Deming Prize ou Prmio Deming, foi o primeiro prmio da qualidade lanado no mundo, visando a avaliar o desempenho das organizaes. Ele foi aberto para organizaes no japonesas em 1984. O julgamento do prmio baseado em dez critrios principais: 1. Poltica; 2. Organizao e sua Operao; 3. Informao; 4. Padronizao; 5. Recursos Humanos; 6. Garantia da Qualidade; 7. Manuteno; 8. Melhoria; 9. Efeitos (Resultados); 10. Planos Futuros. Atualmente o Japo conta com um outro modelo de excelncia, chamado Japan Quality Award. Ele dividido em oito
critrios e apresenta um critrio especificamente direcionado responsabilidade social, considerando resposta aos requisitos sociais e contribuio para a sociedade. Malcolm Baldrige National Quality Award Em 1987, para aumentar a competitividade nas empresas americanas, os Estados Unidos lanaram o Malcolm Baldrige National Quality Award, esse modelo foi uma das tentativas de resposta para responder invaso de produtos japoneses naquele pas. O principal objetivo do prmio nacional da qualidade americano melhorar a competitividade das empresas americanas por meio da conscientizao para a qualidade, do reconhecimento dos resultados de excelncia em desempenho nas empresas americanas e da publicao desses resultados de sucesso das empresas premiadas, como fator de troca de informaes e experincia. Prmio Europeu da Qualidade O Prmio Europeu da Qualidade, EFQM (European Quality Award), a estrutura mais utilizada na Europa e a base para a maioria dos prmios de qualidade nacionais e regionais. usado como ferramenta de avaliao para as empresas e tambm como modelo de gesto para definir como as organizaes podem melhorar o desempenho. Sobre o modelo: uma estrutura para o sistema de gesto da organizao; Pode ser usado como parte de uma auto-avaliao; For ne c e u m q uad r o de c ompa ra o c om out ra s organizaes; Ajuda a identificar reas que podem passar por uma melhoria. O EFQM tem a seguinte premissa: excelentes resultados, no que diz respeito ao desempenho, clientes, pessoas e sociedade, so alcanados atravs da liderana conduzindo a poltica e a estratgia, que entregue atravs das pessoas, parcerias, recursos e processos. Ou seja, a ideia que a satisfao do consumidor, funcionrios e o impacto na sociedade so atingidos atravs de liderana, poltica de direo e estratgia, administrao de pessoas, recursos e processos, levando, finalmente a excelncia nos resultados da empresa. Prmio Nacional da Qualidade O Brasil tambm tem seu modelo de excelncia chamado PNQ (Prmio Nacional da Qualidade), que um importante incentivo competitividade, na forma de avaliao de empresas que buscam alcanar reconhecimento em excelncia daquilo que produzem e/ou comercializam, sejam produtos ou servios. O prmio concedido em reconhecimento a empresas com operao no Brasil, aps passarem por uma avaliao de suas prticas. Em 1989, um grupo de estudos iniciou um estudo sobre o desenvolvimento de um prmio brasileiro nos moldes dos existentes no mundo, e em 1990 o Comit Nacional de Qualidade e Produtividade considerou o estabelecimento de um prmio
10
M etodologias geis
nacional, com participao no processo. Como resultado, em 11 de outubro de 1991 foi instituda a FPNQ (Fundao para o Prmio Nacional da Qualidade), que mudou de nome em 2005 e passou a se chamar Fundao Nacional da Qualidade. Ela formada por organizaes pblicas e privadas para administrar o PNQ. A estrutura dos critrios de avaliao segue um enfoque sistmico, que deve ser trabalhado na forma de estratgias e planos de ao da empresa (Figura 4). Os oito Critrios de Excelncia referem-se a: 1. Liderana 2. Estratgias e Planos 3. Clientes 4. Sociedade 5. Informaes e Conhecimento 6. Pessoas 7. Processos 8. Resultados
Os oito Critrios de Excelncia se subdividem em 24 Itens, conforme o ilustrado na Figura 5.
Programa de Qualidade 8S
Em maio de 1950, o Centro de Educao para a Qualidade no Japo, com a equipe do Dr. Kaoru Ishikawa, criou um modelo prtico para o combate s causas de perdas e desperdcios. O modelo foi nomeado de Regra dos 5S, que formado pelas palavras japonesas Seiri, Seiton, Seiso, Seiketsu e Shitsuke. Estas palavras podem ser traduzidas para o portugus, sem perderem o sentido, da seguinte forma: Utilizao, Ordenao, Limpeza, Bem-Estar e Autodisciplina. No Japo, existem empresas que j acrescentaram mais 3S aos cinco j existentes. So eles: Shikari Yaro (Determinao e Unio), Shido (Treinamento), Setsuyaku (Economia e Combate aos Desperdcios). Dessa forma, o 5S passa a ser o Programa 8S, que uma metodologia que promove a mudana de comportamento de dirigentes e funcionrios, que passam a formar um grupo unido com viso de sobrevivncia e continuidade dos negcios, principalmente atravs das sugestes de melhorias dos funcionrios. O Programa 8S depende totalmente da ao das pessoas (Figura 6); assim sendo, trs fatores so fundamentais para a educao, treinamento e mudana de comportamento: motivao, liderana, e comunicao (ABRANTES, 2001). No final da dcada de 1980, surgiu o programa de Gesto da Qualidade, na Motorola, chamado Seis Sigma que ser detalhado e estudado ainda neste artigo.
CMMI
Figura 4. Modelo de excelncia do PNQ (Fonte: (FNQ, 2009)).
Esta seo tem por objetivo introduzir o conceito de CMMI, expondo como o modelo surgiu, quais so seus propsitos,
Figura 5. Subdivises dos Critrios de Excelncia PNQ (Fonte: (FNQ, 2009))
11
estrutura, componentes e abordagens, de modo a fornecer um contexto claro para os nveis de maturidade 4 e 5 que sero mapeados neste artigo.
e processo e terceirizao, alm do conceito de constelaes na arquitetura do modelo, que permite a sua expanso para outros focos, tais como aquisies e entrega de servios.
Figura 7. CMMI - Integrao dos Modelos CMM Figura 6. Programa 8S (Fonte: (ROCHA, 2009))
Definio e objetivos do modelo

O CMMI (Capability Maturity Model Integration) um modelo de maturidade de melhoria de processos para desenvolvimento de produtos e servios. (CMMI, 2006). Seu principal propsito fornecer diretrizes baseadas nas melhores prticas voltadas para atividades de desenvolvimento e manuteno, abrangendo todo o ciclo de vida do produto, desde a concepo, desenvolvimento, aquisio at a entrega e manuteno. As abordagens do CMMI envolvem a avaliao da maturidade da organizao ou a capacitao das suas reas de processo, o estabelecimento de prioridades e a implementao de aes de melhorias (FERNANDES, 2008).
Histrico do modelo
Em 1991, o Software Engineering Institute (SEI), da Universidade Carnegie Mellon (EUA), criou o SW-CMM (Capability Maturity Model para Software) a partir de uma encomenda feita pelo Departamento de Defesa dos Estados Unidos. Esse modelo foi criado focando o processo de engenharia de software na proposta de melhoria contnua, trazendo disciplina e controle no desenvolvimento e manuteno do software (BARTI, 2002). Desta forma, passou a servir como uma das principais referncias de modelo de qualidade para o mercado de empresas de software. Com o passar do tempo, observou-se que variaes aplicveis a outras disciplinas, tais como engenharia de sistemas, aquisio de software, gesto e desenvolvimento de mo-de-obra e desenvolvimento integrado de produtos e processos, surgiram de acordo com as diferentes necessidades das organizaes. Como cada um destes modelos possua a sua prpria arquitetura e abordagem de implementao, a sua utilizao por organizaes que possuam processos integrados envolvendo vrias destas disciplinas tornou-se difcil devido aos altos custos de treinamento, avaliao e aes de melhoria. Diante deste cenrio, o CMMI (Capability Maturity Model Integration) foi criado pelo SEI em 2002 como um modelo evolutivo em relao aos vrios CMMs, com o objetivo de combinar as suas vrias disciplinas em uma estrutura nica, flexvel e componentizada (Figura 7), que pudesse ser utilizada de forma integrada por organizaes que demandavam processos de melhoria em mbito corporativo (FERNANDES, 2008). A verso 1.2 do CMMI foi publicada pelo SEI em agosto de 2006, trazendo um conjunto de melhorias e simplificaes em relao verso anterior. Com o documento CMMI for Development (CMMI para Desenvolvimento), houve a unificao do tratamento das disciplinas de engenharia de software, engenharia de sistemas, desenvolvimento integrado de produto
Estrutura do modelo
Viso Geral O modelo possui duas abordagens: contnua e por estgios, permitindo organizao optar pela mais adequada a seu contexto. Atendendo a requisitos de componentizao, a verso 1.2 do CMMI apresenta tais abordagens reunidas em um mesmo documento, dentro do escopo de cada constelao. Uma constelao uma coleo de componentes do CMMI que compreende um modelo, seus materiais de treinamento e documentos relacionados avaliao para uma rea de interesse. Adies podem ser usadas para expandir constelaes com contedos especficos adicionais. Atualmente, trs constelaes so suportadas pela verso 1.2 do CMMI: CMMI for Development (CMMI-DEV) fornece diretivas para monitorao, medio e gerenciamento de processos de desenvolvimento. Pode ser estendido atravs da adio para o Desenvolvimento Integrado de Produto e Processo (IPPD); CMMI for Services (CMMI-SVC) fornece diretivas para entrega de servios dentro das organizaes e para clientes externos; CMMI for Acquisition (CMMI-ACQ) fornece diretivas para suporte s decises relacionadas aquisio de produtos e servios.
12
M etodologias geis
Componentes do Modelo Os componentes do modelo se agrupam em trs categorias que indicam como interpret-los: Componentes requeridos: descreve o que uma organizao deve realizar para satisfazer uma rea de processo. Devem ser visivelmente implementados nos processos de uma organizao. Os componentes requeridos no CMMI so as metas especficas e as metas genricas. A satisfao das metas utilizada em avaliaes como base para determinar se uma rea de processo foi realizada e satisfeita; Componentes esperados: descreve o que uma organizao pode implementar para realizar um componente requerido. Orientam os que implementam melhorias ou executam avaliaes. Incluem as prticas especficas e as prticas genricas. Antes que os objetivos possam ser considerados satisfeitos, as prticas tal como descritas ou prticas aceitveis alternativas a elas, devero estar presentes nos processos planejados e implementados da organizao; Componentes informativos: proporciona detalhes que ajudam as organizaes a comear a pensar em como se aproximar dos componentes requeridos e esperados. As sub-prticas, os produtos de trabalho tpicos, ampliaes, a elaborao das prticas genricas, os ttulos de metas e prticas, as anotaes de metas e prticas, e as referncias so exemplos de componentes informativos do modelo. A Figura 8 representa esquematicamente os componentes e seus relacionamentos. A descrio de cada componente feita em seguida.
- reas de Processo Relacionadas: lista referncias a reas de processo relacionadas e reflete as relaes de alto nvel entre as reas de processo. Metas Especficas: so metas relacionadas a uma determinada rea de processo, que descrevem o que deve ser realizado para assegurar que esta esteja definitivamente implementada; Metas Genricas: se denominam genricas porque a mesma declarao da meta se aplica a mltiplas reas de processo. Descreve as caractersticas que devem estar presentes para institucionalizar os processos que implementam uma rea de processo; Prticas Especficas: descreve as atividades consideradas importantes para alcanar uma meta especfica associada. Subcomponentes informativos: - Produtos de Trabalho Tpicos: lista exemplos de resultados de uma prtica especfica. - Subprticas: descries detalhadas que proporcionam uma orientao para interpretar e implantar uma prtica especfica ou genrica. Prticas Genricas: se denominam genricas porque a mesma prtica se aplica a mltiplas reas de processo. Descreve as atividades consideradas importantes para alcanar uma meta genrica associada. Subcomponentes informativos: - Elaborao de Prticas Genricas: proporciona um guia sobre como a prtica genrica deveria aplicar-se de forma exclusiva rea de processo. Componentes Informativos de Suporte: informao adicional necessria para descrever um conceito. So eles: - Notas: pode proporcionar detalhes, fundamentao terica ou premissas/restries relacionadas ao componente; - Exemplos: texto ou lista provendo um ou mais exemplos para esclarecer um conceito ou atividade descrita; - Ampliaes: nota ou exemplo relevante para uma disciplina particular. As disciplinas cobertas neste modelo so Engenharia de Hardware, Engenharia de Sistemas e Engenharia de Software. Cada amplificao rotulada com um cabealho que indica qual disciplina se aplica; - Referncias: indicao para informao adicional ou mais detalhada em reas de processo relacionadas.
Figura 8. Componentes da Estrutura do CMMI (Fonte: Adaptao (CMMI, 2006))
reas de Processo: um grupo de prticas relacionadas que, quando implementadas coletivamente, satisfazem um grupo de objetivos considerados importantes para uma determinada rea. Subcomponentes informativos: - Objetivo: descreve a finalidade da rea de processo; - Notas introdutrias: descreve os principais conceitos compreendidos pela rea de processo;
Abordagens de Implementao Como mencionado anteriormente, o CMMI possui duas abordagens. Para desenvolvimento deste artigo, utilizamos como base a abordagem de implantao por estgios, devido sua grande aderncia no mercado e maior proximidade com os demais modelos CMMI que tambm utilizam nveis de maturidade para mensurar a qualidade dos processos organizacionais. Dessa maneira, daremos a esta representao um foco especial. Objetivamente, podemos descrever as abordagens da seguinte maneira:
13
Abordagem contnua: permite que a organizao selecione uma rea de processo (ou um grupo de reas de processo) e melhore os processos relacionados. Essa representao utiliza seis nveis de capacidade (numerados de 0 a 5) para caracterizar melhorias relativas a uma rea de processo individual; Abordagem por estgios: utiliza grupos pr-definidos de reas de processo (PAs) para definir um caminho de melhoria para uma organizao. Este caminho caracterizado por cinco nveis de maturidade (numerados de 1 a 5). Cada nvel de maturidade contm uma srie de reas de processo que caracteriza diferentes condutas organizacionais. A Figura 9 ilustra a estrutura de ambas as abordagens evidenciando suas diferenas: nveis de capacidade x nveis de maturidade.
Nveis de Maturidade Para dar suporte queles que utilizam a abordagem por estgios, todos os modelos CMMI trazem nveis de maturidade em seu desenho e contedo (Figura 10). Um nvel de maturidade pode ser considerado um degrau evolucionrio para a melhoria do processo organizacional como um todo e consistem em prticas especficas e genricas que integram um conjunto predefinido de reas de processo. O cumprimento das metas especficas e genricas correspondentes a estas reas de processo um pr-requisito para o alcance do nvel de maturidade correspondente (FERNANDES, 2008).
Figura 10. Nveis de Maturidade do CMMI (Fonte: Adaptao (CITS, 2009))
Figura 9. Estruturas das abordagens contnua e por estgios (Fonte: Adaptao (CMMI, 2006))
A Tabela 2 faz uma comparao entre os seis nveis de capacidade e os cinco de maturidade. Como se pode observar, o ponto de incio diferente para as duas implementaes, visto que no h nvel 0 para a abordagem por estgios.
Nvel Nvel 0 Nvel 1 Nvel 2 Nvel 3 Nvel 4 Nvel 5 Nveis de Capacidade da Abordagem Contnua Incompleto Executado Gerenciado Definido Gerenciado Quantitativamente Otimizado --Inicial Gerenciado Definido Gerenciado Quantitativamente Otimizado Nveis de Maturidade da Abordagem por Estgios
Tabela 2. Comparao dos nveis de capacidade e maturidade (Fonte: Adaptao (CMMI, 2006))
A seguir so descritas as principais caractersticas de cada nvel de maturidade e as reas de processo pertencentes aos mesmos. Como o foco deste trabalho relacionar as prticas do modelo de qualidade Seis Sigma com os altos nveis de maturidade do CMMI, os nveis 4 e 5 sero expostos de forma mais detalhada nos prximos captulos. Nvel 1 Inicial: o nvel de maturidade mais baixo. Em geral, as organizaes desse nvel tm processos imprevisveis que so pobremente controlados e reativos. Nesse nvel de maturidade os processos so normalmente ad hoc e caticos. A organizao geralmente no fornece um ambiente estvel. reas de Processo: No h. Nvel 2 Gerenciado: Neste nvel, o foco o gerenciamento bsico de projetos da organizao, proporcionando-lhes a garantia de que os requisitos so gerenciados, planejados, executados, medidos e controlados. Quando essas prticas so adequadas, os projetos so executados e controlados de acordo com o planejado. reas de Processo: Gesto de Requisitos (REQM), Planejamento do Projeto (PP), Controle e Monitorao do Projeto (PMC), Gesto do Acordo com o Fornecedor (SAM), Medio e Anlise (MA), Garantia da Qualidade de Processo e do Produto (PPQA) e Gesto da Configurao (CM). Nvel 3 Definido: Neste nvel, processos so bem caracterizados, compreendidos e descritos em padres, procedimentos, ferramentas e mtodos. O conjunto de processos padro da organizao, que a base para o nvel 3 de maturidade, estabelecido e melhorado ao longo do tempo. Esses processos padronizados so usados para estabelecer consistncia em toda a organizao. Todos os projetos utilizam
14
M etodologias geis
uma verso de um desses processos padro adaptando-a s suas caractersticas especificas. reas de Processo: Desenvolvimento de Requisitos (RD), Soluo Tcnica (TS), Integrao do Produto (PI), Verificao (VER), Validao (VAL), Foco no Processo Organizacional (OPF), Definio do Processo Organizacional (OPD), Treinamento Organizacional (OT), Gesto Integrada do Projeto (IPM), Gesto de Riscos (RSKM), Anlise de Decises e Resoluo (DAR). Nvel 4 Gerenciado Quantitativamente: A gesto quantitativa baseada em medies e indicadores cobre, de forma integrada, todo o conjunto de processos organizacionais, assim como os projetos e respectivos produtos, como instrumento de suporte para o atendimento dos objetivos de desempenho de processo e de qualidade. Os projetos e seus produtos assim como o processo organizacional, so controlados estatisticamente. reas de Processo: - Desempenho do Processo Organizacional (OPP) Tem por objetivos: estabelecer e manter uma viso quantitativa do desempenho dos processos padres, e prover modelos e baselines de desempenho, visando melhorar a gesto dos projetos atravs de mtricas de processo e produto. - Gesto Quantitativa do Projeto (QPM) Tem por objetivo gerenciar quantitativamente (atravs de mtricas) o processo definido do projeto, visando o alcance dos objetivos preestabelecidos de desempenho de qualidade e processo. Nvel 5 Otimizado: Neste nvel, os processos so continuamente aperfeioados com base em um entendimento quantitativo no qual a variao de um processo existe devido s interaes, normais e presumidas, entre seus componentes. Esse nvel de maturidade tem como objetivo a melhoria contnua do processo. reas de Processo: - Inovao e Desenvolvimento Organizacional (OID) Tem por objetivo selecionar e implantar melhorias incrementais e inovaes nos processos e nas tecnologias que promovam, quantitativamente, o aumento da habilidade da organizao para cumprir os seus objetivos de desempenho de processos e qualidade. - Anlise e Resoluo de Causas (CAR) Tem por objetivo identificar causas de defeitos e outros problemas e tomar aes corretivas para prevenir a sua ocorrncia futura. A Figura 11 representa de forma resumida, os nveis de maturidade, seus principais focos e reas de processo envolvidas.
Categoria Custo Prazo Produtividade Qualidade Satisfao dos Clientes Retorno sobre o Investimento Percentual Mdio Reduo de 34% Melhoria de 50% Aumento de 61% Aumento de 48% Aumento de 14% 4,0 : 1
Figura 11. Os Nveis de Maturidade e suas reas de Processo
Benefcios do Modelo A utilizao do modelo CMMI inclui uma srie de benefcios significativos e quantificveis para a organizao que o utiliza na melhoria de seus processos e podem ser categorizados e resumidos por: custo, prazo, produtividade, qualidade, satisfao dos clientes e Retorno sobre o Investimento (ROI Return on Investment). Em 2006, o SEI publicou um relatrio tcnico (Performance Results of CMMI - Based Process Improvement) apresentando dados quantitativos de 35 organizaes, entre elas grandes empresas com mais de uma organizao constituinte (SEI, 2006). Os esforos no processo de melhoria dessas organizaes incluem tanto pequenas como grandes unidades organizacionais que atuam em uma variedade de setores e domnios do mercado. Foram aplicadas as prticas do modelo CMMI para engenharia de software, engenharia de sistemas, e outras disciplinas de engenharia. Enquanto a maioria dos resultados vem de organizaes de maior maturidade, melhorias notveis tambm foram alcanadas pelas organizaes de menor maturidade. Todas as organizaes no relatrio explicitamente atribuem suas realizaes a orientao fornecida pelo CMMI. A Tabela 3 resume a mdia percentual de melhorias nas cinco categorias apresentadas.
Exemplos
Reduo dos custos de retrabalho, remoo de defeitos, overhead de projetos. Reduo do nmero de dias de atraso de aproximadamente 50 para menos de 10. Aumento na quantidade de linhas de cdigo por pessoa/dia, aumento do nmero de releases de software liberados por ano. Reduo dos defeitos encontrados e das requisies de mudana no sistema em ambiente de produo. Aumento em 55% comparado ao SW-CMM nvel 2 e 10% comparado ao nvel 5. Retorno de 5:1 em relao s horas investidas em atividades de qualidade.
Tabela 3. Benefcios Quantitativos da Utilizao do CMMI (Fonte: Adaptao (SEI, 2006))
15
SEIS SIGMA
Este tpico tem por objetivo introduzir o conceito de Seis Sigma como modelo de gesto da qualidade, expondo o seu histrico, propsito, certificaes relacionadas e metodologias criadas a partir de sua concepo. A aplicao na melhoria dos processos de qualidade de software e a estrutura da metodologia sero detalhadas no tpico seguinte, no qual ser feito o mapeamento entre suas prticas no apoio implementao dos nveis de maturidade 4 e 5 do CMMI.
Histrico do Modelo
As origens do Seis Sigma como um padro de medio vm dos trabalhos de Carl Frederick Gauss (1777-1855), que introduziu o conceito da curva normal ou curva de Gauss. As razes do Seis Sigma como um padro de medio da variao dos produtos podem ser rastreadas at a dcada de 1920, quando Walter Shewhart mostrou que a partir de trs desvios padres ou trs sigmas da mdia, o processo requer correo. Muitos padres de medio (CPK, Zero Defeitos, etc.) entraram em cena posteriormente, dando base para o movimento da qualidade total, liderado mais tarde por Edward Deming e outros profissionais militantes da qualidade (ISIXSIGMA, 2009a). No incio e meados dos anos 80, com o presidente Bob Galvin na direo, engenheiros da Motorola decidiram que os nveis tradicionais de qualidade medio de defeitos em milhares de oportunidades no forneciam granularidade suficiente. Esta concluso partiu de informaes vindas da fora de vendas, a respeito da grande quantidade de reclamaes de uso de garantias pelos clientes. Para reverter este quadro, eles determinaram a necessidade de medir os defeitos por milhes de oportunidades. Desta forma, a Motorola desenvolveu este novo padro, criou a metodologia e, em 1986, o termo Seis Sigma foi cunhado pelo engenheiro da Diviso de Comunicaes da Motorola, Bill Smith (Figura 12).
em economias como resultado de seus esforos com o Seis Sigma. Tais resultados concederam companhia a conquista do prestigioso prmio Malcolm Baldrige National Quality Award (MBNQA) em 1988. Em 1991, a Motorola introduziu treinamentos para a formao de especialistas em Seis Sigma, que foram denominados black belts. Em 1992, a metodologia passou a ser adotada por outras indstrias, incluindo seguros, servios financeiros, sade, etc. Em 1999, a Motorola, atravs da Motorola University, comeou a ensinar o Seis Sigma para outras organizaes de sua cadeia de valor (fornecedores e clientes) e tambm para outras indstrias. Em 2001, o agora ex-CEO da General Electric (GE), Jack Welch, dedicou um captulo inteiro em sua biografia (WELCH, 2001) iniciativa Seis Sigma, fazendo elogios que se tornaram ao longo do tempo a grande bandeira da rea de qualidade e melhorias de processos no mundo. Em suas prprias palavras, Tornei-me um fantico pelo Seis Sigma e O Seis Sigma tornar a GE a maior empresa do mundo dos negcios. De fato, o modelo gerou no ano de 2000 mais de 2,4 bilhes de dlares em benefcios (Figura 13), enquanto no mesmo perodo a GE teve a maior valorizao de suas aes na histria (Figura 14).
Figura 13. Benefcios do Seis Sigma na GE (1996-2000) (Fonte: Adaptao (VASQUES, 2006))
Figura 12. 1986: Processo de qualidade Seis Sigma (Fonte: Adaptao (MOTOROLA, 2009))
Em 1987, foi lanado um ambicioso programa por Bob Galvin visando a reduo de defeitos nos produtos para seis sigma ou 3,4 defeitos por milhes de oportunidades, tendo como meta o ano de 1991 e como pilar o modelo Seis Sigma (FERNANDES, 2008). O modelo ajudou a Motorola a obter excelentes resultados em sua organizao, documentando mais de 16 bilhes de dlares
Figura 14. Situao das Aes na GE (1965-2004) (Fonte: (FINANCE, 2009))
Em 2002, a Motorola ganhou novamente o MBNQA e milhares de empresas ao redor do mundo adotaram o Seis Sigma como uma maneira de fazer negcios, ou seja, seu foco se alargou para alm da melhoria da qualidade em produtos. Um dos idealizadores deste programa, Michel Harry,
16
M etodologias geis
define o Seis Sigma como uma estratgia que no deve estar encapsulada na rea de qualidade, devendo espalhar seus tentculos por toda a organizao, da manufatura e engenharia rea de servio. Em 2004, a Motorola obteve receitas 42% maiores e um lucro por ao 257% maior do que no primeiro trimestre do ano fiscal anterior com o uso do Seis Sigma em todos os seus processos (FERNANDES, 2008).
Definio e Objetivos do Modelo

Diferentemente de outros programas de qualidade, as empresas que utilizam o Seis Sigma divulgam cifras milionrias de ganhos obtidos com sua implementao. Desta maneira, podemos concluir que o Seis Sigma mais do que apenas um sistema de qualidade como o TQM ou ISO. uma maneira de fazer negcios. Geoff Tennant descreve em seu livro Six Sigma: SPC and TQM in Manufacturing and Services (TENNANT, 2001): Seis Sigma muitas coisas e talvez fosse mais fcil listar todas as coisas que a qualidade Seis Sigma no . Seis Sigma pode ser visto como: uma viso; uma filosofia; um smbolo; uma mtrica; um objetivo; uma metodologia. (ISIXSIGMA, 2009a). A estas descries pode-se acrescentar ainda: uma estratgia organizacional, um modelo de gesto, um conjunto de ferramentas estatsticas ou um mtodo de comparao (benchmarking) 3,4 defeitos por milho de oportunidades. comum encontrar diferentes, embora convergentes, definies sobre o que Seis Sigma. Para VASQUES (2006) da ISD Brasil (Integrated System Diagnostics Brasil), a definio mais completa e ntegra seria: Metodologia de grande rigor analtico, baseada em projetos de melhorias de processos de negcio onde utilizamos um conjunto preestabelecido de ferramentas (tipicamente estatsticas) que direciona a organizao para uma mudana cultural profunda (filosofia), buscando sempre altos resultados financeiros e intenso foco nos clientes. Segundo CARVALHO e PALADINI (2005), o modelo de Gesto da Qualidade Seis Sigma uma estratgia gerencial disciplinada, caracterizada por uma abordagem sistmica e pela utilizao intensiva do pensamento estatstico, que tem por objetivo reduzir drasticamente a variabilidade dos processos crticos e aumentar a lucratividade das empresas, por meio da otimizao de produtos e processos, buscando satisfao de clientes e consumidores. Os objetivos do Seis Sigma variam de acordo com os objetivos da melhoria, conforme a lista a seguir: Reduo de custos; Melhoria da produtividade; Crescimento de fatia de mercado; Reteno de clientes; Reduo de tempo de ciclo; Reduo de defeitos; Mudana cultural para a qualidade; Excelncia no desenvolvimento de produtos e servios. Ao contrrio do Total Quality Management TQM, que pretendia melhorar a qualidade de toda a organizao, o Seis
Sigma procura melhorias que agreguem valor para o cliente e tambm pode ser aplicado para problemas localizados (FERNANDES, 2008). Existem algumas estratgias para se alcanar uma produo com zero erro. PANDE, NEUMAN e CAVANAGH (2001) afirmam que h trs estratgias Seis Sigma. As estratgias so: (i) estratgia de melhoria de processo; (ii) estratgia de projeto/ reprojeto de processo; e, (iii) estratgia de gerenciamento de processo. A melhoria de processo refere-se estratgia de desenvolver solues com a finalidade de eliminar as causasraiz dos problemas de desempenho de uma empresa, sem, no entanto, interferir na estrutura bsica do processo. Na estratgia projeto/reprojeto de processo, o objetivo substituir uma parte ou todo o processo por um novo. J na estratgia de gerenciamento de processo, as exigncias do cliente so claras e regularmente atualizadas, os processos so documentados e gerenciados com medies em todas as suas etapas. Nesta ltima estratgia, os gestores tambm usam as medies e o conhecimento do processo para avaliar os seus desempenhos. A Figura 15 resume alguns mtodos importantes do programa Seis Sigma.
Figura 15. Mtodos e ferramentas essenciais do programa Seis Sigma (Fonte: Adaptao (PANDE; NEUMAN; CAVANAGH, 2001))
Um programa Seis Sigma tem como requisitos: Alinhar o esforo Seis Sigma aos objetivos do negcio; Forte patrocnio da administrao; Focalizar em resultados de curto prazo; I mpla nt a r u ma nova for ma de ad m i n i st rao duradoura; Tornar a aprendizagem uma tarefa contnua; Selecionar os projetos corretos; nfase em treinamento e capacitao de recursos humanos; Definir claramente papis e responsabilidades; Forte liderana para a mudana. O programa Seis Sigma foi batizado com o nome da letra grega sigma (), que representa o desvio-padro em notao estatstica, j evidenciando a grande nfase na utilizao destas ferramentas. O uso sistemtico de ferramentas
17
estatsticas nos projetos tem como objetivo reduzir a variabilidade, at a obteno da difcil meta de 3,4 defeitos por milho (CARVALHO; PALADINI, 2005) ou seis sigma, que equivale a um rendimento de 99,9997% de resultados do processo isentos de defeitos. A Tabela 4 mostra o que significa o Seis Sigma em termos de qualidade e defeitos por milho.
Sigma 6 5 4 3 2 1 99,9997% 99,9767% 99,379% 93,32% 69,1% 31% Qualidade 3,4 233 6.210 66.807 308.537 690.000 Defeitos por milho
Operar em apoio ou sob a superviso de um Six Sigma Black Belt. Analisar e resolver problemas de qualidade. Envolvimento em projetos de melhoria da qualidade. Participao em um projeto, mas no conduz-lo sozinho. Ter pelo menos trs anos de experincia de trabalho. Ter capacidade de demonstrar seu conhecimento das ferramentas do Seis Sigma e dos processos. (ASQ, 2009c) Exame Os candidatos certificao precisam passar por um exame escrito que consiste em perguntas de mltipla escolha para medir a compreenso Six Sigma Green Belt Body of Knowledge (Corpo de Conhecimentos do Seis Sigma Green Belt). A prova dura quatro horas, tem 100 questes e feita no idioma ingls, caso seja feita pela ASQ. Cada participante deve levar seu prprio material de referncia, pois o exame open-book (com consulta). O comit que prepara o exame utiliza o Six Sigma Green Belt Body of Knowledge como orientao para escrever as perguntas do teste. Este foi feito para ajudar a preparar os candidatos a identificar o contedo especfico dentro de cada tema que pode ser cobrado. Os exames so realizados duas vezes por ano, em junho e dezembro, pela ASQ e organizaes internacionais.
Tabela 4. Qualidade e defeitos sigma (Fonte: Adaptao (FERNANDES, 2008))
Certificaes e Responsabilidades
Existem certificaes profissionais para qualificar pessoas como especialistas em Seis Sigma, relativas a Black Belt, Green Belt e outras. Ambas so fornecidas pela Motorola University, por diversas empresas especializadas e pela ASQ (American Society for Quality). A ASQ dedicada a assuntos relacionados qualidade e a mais indicada para realizar as certificaes (FERNANDES, 2008). Os especialistas so responsveis pela implantao da estratgia Seis Sigma. Sua formao altamente focada em buscar solues para a verdadeira causa dos problemas. Eles atuam como agentes de mudana na organizao, aplicando e disseminando o uso das ferramentas estatsticas e da qualidade no aprimoramento dos projetos. Para realizar o treinamento, essencial selecionar pessoas adequadas, definir claramente as expectativas de como este treinamento deve ser aplicado no local de trabalho e assegurar que seja fornecido o suporte necessrio para obter bons resultados. Existem duas certificaes Seis Sigma da ASQ (ASQ, 2009a): A Six Sigma Green Belt Certification (SSGB) e a Six Sigma Black Belt Certification (SSBB). Seus criadores atriburam tais ttulos (faixa verde, faixa preta), pois acreditam que as certificaes tm habilidades em comum com as artes marciais.
Six Sigma Black Belt Certification SSBB

Papel na empresa O profissional que possui a certificao Six Sigma Black Belt, est habilitado a explicar a filosofia e os princpios do Seis Sigma, incluindo sistemas de apoio e ferramentas. O Black Belt tem que demonstrar liderana, entender a dinmica da equipe, saber resolver problemas em projetos, atribuir funes e responsabilidades aos membros e tambm preparar equipes de projeto. Tambm possui um profundo conhecimento dos aspectos do modelo DMAIC de acordo com os princpios do Seis Sigma. Requisitos de experincia Para a certificao preciso ter realizado dois projetos completos e certificados/aprovados, ou ter finalizado um projeto certificado/ aprovado e mais trs anos de experincia em uma ou mais reas do Seis Sigma Black Belt Body of Knowledge. A certificao Seis Sigma Green Belt no requisito para este exame. Expectativas e atribuies mnimas para um SSBB Segundo recomendao da American Society for Quality (ASQ, 2009b), podemos citar: Ser capaz de explicar a filosofia e os princpios do Seis Sigma, incluindo sistemas e ferramentas (qualidade, processos / melhoria contnua, etc.), e poder descrever seu impacto nos diversos processos de negcios em toda a organizao; Conhecer vrias guias e saber sobre funes e responsabilidades no Seis Sigma. Ao reconhecer obstculos na organizao, dever ser capaz de utilizar tcnicas de gesto de mudana para gerir a mudana organizacional;
Six Sigma Green Belt Certification SSGB

Papel na empresa Esse profissional auxilia na coleta e anlise de projetos de Black Belt. Lidera a resoluo de problemas em projetos de Green Belt e outras equipes, de acordo com sua experincia. Requisitos de experincia Trs anos de experincia de trabalho em uma ou mais reas do Seis Sigma Green Belt. Esta certificao no um requisito para a Certificao Seis Sigma Black Belt. Expectativas e atribuies mnimas para um SSGB
18
M etodologias geis
Ser capaz de definir benchmarking, entender sobre vrias medidas financeiras e outras de desempenho de negcios. Ser capaz de identificar as necessidades dos clientes e descrever o impacto que os projetos Seis Sigma podem ter sobre os diversos tipos de clientes; Ter uma compreenso fundamental dos componentes e tcnicas utilizados na gesto de equipes, incluindo o tempo de gesto, planejamento e ferramentas de tomada de deciso, formao de equipe e avaliao de desempenho e gratificao. Saber como usar as tcnicas adequadas para superar os diferentes desafios da dinmica de grupo; Entender os elementos de um relatrio do projeto (definio do problema, escopo, metas, etc.) e ser capaz de usar vrios instrumentos para acompanhar seu andamento; Ser capaz de usar o feedback do cliente para determinar suas necessidades; Ter um conhecimento bsico sobre tcnicas de coleta de dados, elementos do processo e suas ferramentas de anlise; Ter u m con hec i mento b sico s obre si stema s de medio; Ter um conhecimento bsico de conceitos de probabilidade e distribuies; Ser capaz de realizar clculos estatsticos e de capacidade do processo; Ser capaz de realizar testes de hipteses e analisar seus resultados; Ser capaz de utilizar vrias ferramentas para eliminar o desperdcio e reduzir o tempo de ciclo; Ter uma compreenso fundamental de como implementar um processo de melhoria e como analisar e interpretar estudos de risco; Ser capaz de criar planos de controle e usar ferramentas para manter e sustentar melhorias.
Exame Os candidatos certificao precisam passar por um exame escrito que consiste em perguntas de mltipla escolha para medir a compreenso Six Sigma Black Belt Body of Knowledge (Corpo de Conhecimentos do Seis Sigma Black Belt). A prova dura quatro horas, tem 150 questes e feita, pela ASQ, no idioma ingls. Assim como no exame para Green Belt, cada participante deve levar seu prprio material de referncia, pois o exame open-book (com consulta). Os exames so realizados duas vezes por ano, em maro e outubro, pela ASQ e organizaes internacionais.
Resumo dos papis da equipe

A Tabela 5 mostra a descrio resumida dos papis componentes de uma equipe Seis Sigma.
Metodologias do 6 Sigma
Esta seo apresenta as principais metodologias existentes no Seis Sigma, abordando suas definies, conceitos e aplicabilidade. As metodologias DMAIC e DFSS so utilizadas na eliminao dos defeitos de um processo ou produto.
O modelo DMAIC
O DMAIC foca na robustez e simplificao dos processos, visando diminuir o nvel de defeitos, o aumento da satisfao dos clientes e a lucratividade da organizao. O DMAIC um aperfeioamento do processo Seis Sigma que passa por cinco fases: definir (define), medio (measure), anlise (analyze), aperfeioamento (improve) e controle (control). Existem diversas ferramentas que so utilizadas de maneira integrada s fases do DMAIC, constituindo um mtodo sistemtico, disciplinado, baseado em dados e no uso de ferramentas estatsticas para se atingir os resultados almejados pela organizao (CARVALHO; PALADINI, 2005).
Papel exercido no Seis Sigma Executivo Lder
Pessoa o principal executivo da empresa. Responsvel pela implantao do Seis Sigma. Essa pessoa deve ter total comprometimento, pois ele indispensvel para o sucesso da implantao da estratgia de melhoria. Deve conduzir, incentivar e supervisionar as iniciativas do programa Seis Sigma em toda a empresa. Deve liderar os executivos-chave da organizao rumo ao programa Seis Sigma. responsvel por organizar e guiar o comeo, o desdobramento e a implementao do Seis Sigma em toda a organizao. Ajuda o campeo na tarefa de implantar o Seis Sigma na organizao. Tambm ajuda o campeo na escolha e no treinamento de novos projetos de melhoria, oferecendo liderana tcnica no preparo dos profissionais de Seis Sigma, treinando e instruindo os Black Belts e os Green Belts. Dedicam 100% do tempo s atividades relacionadas ao programa Seis Sigma. Os Black Belts dedicam 100% do tempo aos projetos Seis Sigma, assim como os Master Black Belts, recebendo treinamento intensivo em tcnicas estatsticas e de soluo de problemas. Lideram equipes na conduo dos projetos e so capazes de treinar at 100 Green Belts ao ano. Ficam parcialmente envolvidos com as atividades Seis Sigma. Esses profissionais possuem duas tarefas principais: 1. Auxiliar aos Black Belts na coleta de dados e no desenvolvimento de experimentos; 2. Liderar pequenos projetos de melhoria nas suas respectivas reas de atuao. Participam como membros das equipes de projeto supervisionando a utilizao das ferramentas Seis Sigma na rotina da empresa e executam projetos mais focados e de desenvolvimento mais rpido que os executados pelos Green Belts. No faz parte de uma equipe de projeto. So do nvel operacional. Do suporte aos Black Belts, Green Belts e Yellow Belts na implementao dos projetos. So executores de aes, garantindo que os resultados alcanados sejam mantidos no longo prazo, na operao da rotina da empresa.
Champions
Master Black Belts
Black Belts
Green Belts
Yellow Belts White Belts
Tabela 5. Papis da equipe Seis Sigma (Fonte: Adaptao (GRUPO WERKEMA, 2008))
19
Primeira fase: Define (definir as prioridades) A primeira fase consiste em definir quais so os requisitos do cliente (voz do cliente) e traduzir essas necessidades em Caractersticas Crticas para a Qualidade (CTQ Critical to Quality). Esta etapa torna-se fundamental por levar a viso do cliente para dentro da empresa. Os objetivos dos projetos Seis Sigma de melhoria tm de estar relacionados a um CTQ. Os desenhos dos processos crticos so feitos por uma equipe preparada para aplicar as ferramentas Seis Sigma e procuram identificar aqueles que tm relao com os CTQs do cliente e que esto gerando resultados ruins, como reclamaes de clientes, problemas funcionais, problemas trabalhistas, baixa qualidade de suprimentos, altos custos de mo-de-obra, erros de forma, ajuste e funcionamento etc. Logo aps, a equipe realiza uma anlise custo-benefcio do projeto, de modo a ter uma viso clara do retorno que a atividade dever trazer para a empresa. Segunda fase: Measure (como o processo medido e como executado?) Na segunda fase a equipe assessorada pela Black Belt vai agora desenhar o processo e os subprocessos que se relacionam com as CTQs, definindo as entradas e sadas. Para cada processo, deve-se utilizar o sistema de medio adequado. Em seguida, a equipe coleta os dados do processo por meio de um sistema que produza amostras representativas e aleatrias. Com isso, os ndices de capacidade do processo a curto e longo prazos so determinados. Terceira fase: Analyze (identificao das principais causas) A equipe Seis Sigma, na terceira fase, faz a anlise dos dados coletados, que uma importante funo da metodologia. Para esse trabalho, alm de utilizar as ferramentas tradicionais da qualidade, so utilizadas ferramentas estatsticas de modo a identificar as causas bvias e as causas no bvias. A utilizao de ferramentas estatsticas de forma competente e prtica uma das foras da metodologia. A estatstica passa a ser a principal ferramenta a ser utilizada pela equipe, quando evolumos para uma viso de que os processos devem ser a principal ferramenta a ser utilizada pela equipe. Nesta fase, imprescindvel a utilizao de software estatstico, que facilita muito o trabalho da equipe nos clculos e desenha os grficos necessrios. A equipe consegue descobrir as causas geradoras dos defeitos e as fontes de variaes nos processos. Quarta fase: Improve (eliminao das causas dos defeitos) Na fase de aperfeioamento, a equipe deve fazer as melhorias no processo existente. Os dados estatsticos devem ser transformados em dados do processo, e a equipe deve estudar tecnicamente quais transformaes deve executar. A equipe pode vir a ter que resolver problemas, pois podem ocorrer modificaes tcnicas do processo. O trabalho da equipe ser modificar os elementos das atividades de transformao, atuando sobre as causas-raiz.
Essa considerada uma fase crtica, onde as melhorias se materializam no processo, quando a equipe interage com as pessoas que executam as atividades. As equipes promovem melhorias nas variveis vitais do processo e realizam a quantificao dos efeitos nas CTQs, ou seja, nas metas financeiras e de desempenho (CARVALHO; PALADINI, 2005). Depois, deve testar as solues, pois a equipe comea a passar para o pessoal operacional a responsabilidade de executar o processo modificado. Quinta fase: Control (manuteno das melhorias) Nesta fase, pode surgir a seguinte pergunta: por que ir alm da fase de melhoria, j que os objetivos do projeto foram atingidos? Qualquer sistema, mesmo que esteja em ordem, pode vir a ter algum tipo de desordem, ou seja, o processo pode ficar mais bagunado no futuro, caso no esteja sob controle, e isso pode fazer a capacidade voltar para os nveis do incio do projeto Seis Sigma. A equipe deve definir como sero feitos esses controles e passar essa informao para aqueles que trabalham no processo normalmente no dia-a-dia. Tambm nesta fase, para medir continuamente o processo de modo a garantir que a capacidade do processo seja mantida, deve ser estabelecido e validado um sistema de medio e controle. O monitoramento dos pontos (Xs) crticos fundamental no s para manter a capacidade do processo estabelecida, mas para indicar melhorias futuras. O outro ponto (Y), que a sada do processo, deve ser controlado para garantir que os resultados sejam conforme o planejado. elaborada a documentao do processo por meio de mtodos estatsticos de controle de processo, alm do monitoramento das novas condies do processo. A capacidade do processo reavaliada para garantir que os ganhos sejam mantidos. A reavaliao pode mostrar no resultado, que pode ser necessrio rever uma ou mais fases precedentes do processo. A implementao correta do programa Seis Sigma permite criar uma linguagem comum entre as diversas reas de uma empresa (Figura 16), compartilhando sucessos e fracassos, fazendo com que uma unidade aprenda com a experincia de outra (CARVALHO; PALADINI, 2005).
O modelo DFSS (Design For Six Sigma)

A metodologia lida com a qualidade no projeto de novos produtos e pode ser aplicada a processos produtivos e de servios que precisam ser constitudos de forma que, ao estarem em funcionamento, j atinjam o nvel Seis Sigma e tambm surgiu para preencher uma lacuna no DMAIC. O DFSS tambm pode ser aplicado a processo nos quais seu nvel de desempenho esteja to baixo, e o prprio processo esteja to ruim, que quaisquer esforos aplicados para se realizar um projeto DMAIC no resultaro em um processo de nvel Seis Sigma. Ou seja, pode-se projetar um novo produto ou servio, ou reprojetar um produto ou servio j existente (CARVALHO; PALADINI, 2005).
20
M etodologias geis
Figura 16. Descrio dos passos do modelo DMAIC (Fonte: Adaptao (SMIDT & PARTNERS, 2005; PDP net, 2008))
Nesta metodologia existem ferramentas que podem reduzir custos e melhorar a qualidade, mas principalmente adicionar valor ao produto por meio de inovaes e do atendimento das reais necessidades dos clientes. Como a qualidade do produto/ processo projetada, e no melhorada, o DFSS o programa apontado como a nica forma de atingir o nvel Seis Sigma na qualidade. Para isso, adotada a metodologia DMADV (definio, medio, anlise, projeto e verificao) que tambm possui cinco fases bem definidas: Definir ( Define ): identifica-se o que ser projetado e os objetivos a serem alcanados; Medir ( Measure ): entendimento das necessidades e expectativas dos clientes relativas ao produto ou servio que est sendo criado. So definidas as caractersticas crticas para a qualidade (CTQ) do projeto, que sero os objetivos do novo processo; Analisar ( Analyze ): escolher a melhor soluo entre as possveis alternativas de desenho, visando atender as necessidades dos clientes; Projeto (Design ): ser desenvolvido o design de alto nvel (descrio do conceito de produto/servio escolhido, mapas do processo e arranjo das instalaes) para todos os elementos apropriados, como: produto/servio, processo, informao, instalaes, equipamentos, e materiais/suprimentos; Verificao (Verify ): testar e validar o projeto. A equipe ir monitorar o desempenho das CTQs do produto ou servio por meio das cartas de controle. (CARVALHO; PALADINI, 2005)
nos processos de infraestrutura, em especial gerenciamento de incidentes, gerenciamento de problemas, gerenciamento da disponibilidade e central de servios. O Seis Sigma tambm pode ser utilizado em questes de apoio ao CIO, como no caso de elaborao de oramento, controle de custos, etc. Na rea de TI, pode ser aplicado em processos de desenvolvimento de software, principalmente em fbricas de programas e manuteno de sistemas, onde h maior quantidade de projetos e um maior ndice de repetio dos mesmos.
Mapeamento entre Seis Sigma e CMMI Nveis 4 e 5

Este tpico tem o objetivo de apresentar a aplicao do Seis Sigma na melhoria dos processos de qualidade de software, atravs do mapeamento de suas atividades com as prticas definidas nos nveis de maturidade 4 e 5 do CMMI.
Qualidade de Software
H algumas dcadas, no desenvolvimento de software, navegar pelo cdigo e corrigir problemas era uma prtica comum entre os desenvolvedores. Assim eram feitos os testes para verificao de erros e a busca pela qualidade. Foi atravs dos testes que as organizaes comearam a prestar mais ateno na importncia da qualidade do software. Apesar disso, no final da dcada de 1950, o teste ainda era encarado como uma atividade que ocorreria somente no final do processo de desenvolvimento. Nas dcadas seguintes (1960 e 1970), a Engenharia de Software passou a ser adotada pelas universidades e organizaes. Isso ajudou o processo de desenvolvimento de software a ter uma abordagem mais profunda. Glenford J. Myers, em 1979, produziu um dos primeiros trabalhos sobre um processo de teste, no qual afirmou que realizar testes com o objetivo de provar a boa funcionalidade de um projeto errneo, pois toda
Aplicabilidade do Modelo
O modelo pode ser aplicado para projetos de melhoria de processos, gerenciamento do processo e para projetos de novos processos. Na rea de segurana da informao, h um campo vasto para identificar melhorias nos processos de segurana, assim como
21
energia gasta para comprovar esse fato em vo devido aos poucos defeitos encontrados. Desta maneira, ele definiu o teste como um processo de trabalho com a inteno de encontrar erros. Com esta definio, um maior nmero de problemas ser encontrado, uma vez que os profissionais de qualidade buscaro vrios cenrios para avaliar o comportamento do software. O conceito de qualidade de software surgiu no incio da dcada de 1980, onde cada fase do processo passava por uma verificao feita por desenvolvedores e testadores, para garantir que a fase estava completa. Algumas organizaes foram formadas com o intuito de padronizar a qualidade, entre elas: IEEE (Institute of Eletrical and Electronics Engineers), ANSI (American National Standards Institute), ISO (International Organization for Standardization), CMM (Capability Maturity Model). O modelo avaliao CMM, foi o que mais se destacou e ganhou maior dimenso e importncia para as organizaes de software. Atualmente, as organizaes esto buscando maior eficincia para conseguir superar a concorrncia e esto buscando as solues atravs da tecnologia, que torna os sistemas informatizados, reduzindo custos e ampliando a forma de atuao. Para acompanhar esse crescimento, os ambientes esto tornando-se mais complexos e fica mais difcil alcanar um elevado nvel de qualidade. Implantar um processo de garantia de qualidade tornou-se essencial e uma boa estratgia para o mercado. O produto final o somatrio de todas as decises e realizaes geradas durante o ciclo de desenvolvimento. Essas decises podem afetar a sua qualidade final. Para alcanar uma alta qualidade, necessrio investir em qualidade em todos os pontos do processo. Segundo Barti (2002), Qualidade de Software um processo sistemtico que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos. Gerentes, diretores e acionistas podem tomar decises equivocadas, por terem como base informaes com erros. Os prejuzos podem tornar-se enormes s organizaes. A qualidade das informaes depende da qualidade das decises. Com processos de desenvolvimento frgeis e deficientes impossvel garantir a qualidade do software. Portanto, importante verificar duas dimenses fundamentais para atingirmos a qualidade do software: a dimenso da qualidade do produto, onde o objetivo principal garantir a qualidade do produto tecnolgico gerado durante o ciclo de desenvolvimento, atravs de atividades testes e correo de problemas; e a dimenso da qualidade do processo, onde feita a estruturao de processos que possuam mecanismos de inibio e impedimento de falhas.
para enriquecer diretamente os processos definidos que abordam as reas de processo de alta maturidade. Por exemplo, os processos relacionados com a Gesto Quantitativa de Projeto e Anlise de Causa e Soluo de Problemas refletem tanto as prticas especficas destas reas de processo quanto as etapas, sub-etapas e ferramentas do DMAIC. (SEI, 2005) Existem vrias definies sobre as etapas de cada fase do DMAIC. A Figura 17 apresenta um roteiro resumido sobre os passos executados no DMAIC, oferecido no curso Measuring for Performance-Driven Improvement do SEI (SEI, 2005).
Figura 17. DMAIC Roadmap (Fonte: Adaptao (SEI, 2005))
Relaes entre CMMI e SEIS SIGMA

Do ponto de vista de definio do processo, h uma sinergia natural entre as reas de alta maturidade do processo do CMMI e os princpios do framework DMAIC do Seis Sigma. Desta forma, as tticas do Seis Sigma podem ser utilizadas
A Tabela 6 apresenta os passos de forma mais detalhada dentro roteiro de atividades (roadmap) do DMAIC. A aplicao bem sucedida do CMMI em conjunto com o Seis Sigma exige uma anlise das relaes entre os dois. O CMMI usado para criar uma infraestrutura de processos organizacionais, abordando domnios especficos, tais como software e engenharia de sistemas. Seis Sigma uma iniciativa top-down que abrange toda a empresa, incluindo reas como engenharia, vendas, marketing e pesquisa. O Seis Sigma foi concebido para ser implementado com um foco em problemas e oportunidades, muitas vezes com escopos especficos, que traro benefcios significativos nos negcios. Centra-se no desempenho dos processos e prticas implementadas. Embora estas duas iniciativas de melhoria sejam diferentes na sua concepo, elas so interdependentes em seu uso. Na prtica, a alternncia entre os focos muitas vezes eficaz. Por exemplo, o Seis Sigma pode ser usado para descobrir que os processos precisam ser mais repetitivos, enquanto o CMMI pode ser usado para instituir processos baseados nas melhores prticas da comunidade, e, em seguida, o Seis Sigma pode ser usado para otimizar os processos (SEI, 2005). Normalmente, criado um mapeamento quando se compara uma outra iniciativa de melhoria com CMMI. Neste caso, devido ao fato do CMMI e Seis Sigma serem dois tipos diferentes de iniciativas, com muitas conexes e sobreposies diferentes,
22
M etodologias geis
um mapeamento completo e generalizado complexo e oferece pouco valor prtico. mais til compreender seus focos complementares e as formas pelas quais eles esto conectados. Unir esse entendimento a uma estratgia consciente, permite que uma organizao possa criar planos tticos e mapeamentos especficos para apoiar as suas implementaes. Partindo de uma viso macro, a metodologia DMAIC pode ser conjugada com as prticas genricas para institucionalizar, otimizar e atingir alta capacidade nesses processos (SEI, 2005). A Figura 18 faz uma relao visual entre vrias reas de processo do CMMI e prticas genricas alinhadas com passos do roteiro DMAIC.
Figura 18. reas de Processo do CMMI e Passos do DMAIC (Fonte: Adaptao (SEI, 2005))
Figura 19. DMAIC Roadmap e as reas do CMMI (4 e 5) (Fonte: Adaptao (SEI, 2005))
Mapeamento CMMI x Seis Sigma

Tabela 6. Six Sigma DMAIC Roadmap (Fonte: Adaptao (ISIXSIGMA, 2009b))
O diagrama da Figura 18 mostra um fluxograma do processo geral de medio de uma organizao, revestido com passos DMAIC e reas de processo selecionadas. Enquanto este processo da organizao foi projetado com observncia do modelo em mente, ele representa uma abordagem integrada para a utilizao global de medio, em vez de uma replicao das prticas especficas de cada rea de processo. Da mesma forma, esse processo organizativo aproveita ideias do DMAIC, mas no uma replicao das etapas DMAIC (SEI, 2005). A Figura 19 apresenta uma viso resumida dos relacionamentos dos passos do Seis Sigma com as prticas especficas dos nveis 4 e 5 do CMMI.
Nesta seo, feita a relao entre as metas e prticas especficas das reas de processo dos nveis de maturidade 4 e 5 com os passos das fases do Seis Sigma - DMAIC. Em seguida, h uma breve descrio das metas e prticas para que possa ser compreendido o relacionamento existente.
Desempenho do Processo Organizacional (OPP)

A rea de processo (PA) Desempenho do Processo Organizacional (OPP) (Tabela 7) est englobada no nvel 4 de maturidade e possui uma nica meta especfica (SG): Estabelecer Baselines e Modelos de Desempenho, na qual so estabelecidas e mantidas as baselines e os modelos que caracterizam o desempenho esperado dos processos do conjunto de processos padro da organizao. Nesta rea
23
OPP SG1 Estabelecer Baselines e Modelos de Desempenho Prticas Especficas - CMMI SP 1.1 Selecionar Processos
Desempenho do Processo Organizacional (OPP) Passos do Seis Sigma -----Definir defeitos, oportunidades, unidades e mtricas SP 1.2 Estabelecer Medidas de Desempenho de Processo MEASURE Desenvolver plano de coleta de dados Validar o sistema de medio Definir objetivos de desempenho SP 1.3 Estabelecer Objetivos de Qualidade e de Desempenho de Processo ANALYZE MEASURE SP 1.4 Estabelecer Baselines de Desempenho de Processo MEASURE Identificar fontes de variao Determinar a(s) causa(s) raiz(es) Mapa detalhado do processo e reas adequadas Coleta de dados Determinar capacidade do processo e Baseline Sigma ----
SP 1.5 Estabelecer Modelos de Desempenho de Processo Tabela 7. Mapeamento da rea de processo OPP e DMAIC
----
existem trs, das cinco prticas especficas (SP), que podemos relacionar com o DMAIC. SP 1.1 Selecionar Processos Consiste em selecionar os processos ou subprocessos no conjunto de processos padro organizao que sero includos nas anlises de desempenho do processo. No se aplica ao Seis Sigma, pois o mesmo parte do princpio de que tudo um processo, e, portanto tudo deve ser medido e analisado. SP 1.2 Estabelecer Medidas de Desempenho de Processo Atua no estabelecimento e manuteno das definies das medidas que sero includas nas anlises de desempenho de processo da organizao. No Seis Sigma h um conjunto de atividades que satisfazem esta meta especfica, atravs da seleo das medidas apropriadas para fornecer visibilidade da qualidade e desempenho de processo da organizao; o desenvolvimento do plano de coleta dos dados e da validao do sistema de medio que permite verificar se as medidas estabelecidas esto sendo teis. SP 1.3 Estabelecer Objetivos de Qualidade e de Desempenho de Processo Consiste em estabelecer e manter objetivos quantitativos de qualidade e de desempenho de processo para a organizao. No Seis Sigma, as atividades descritas na Tabela 7 se complementam para atingir a definio de tais objetivos. SP 1.4 Estabelecer Baselines de Desempenho de Processo O Seis Sigma atende a esta prtica a partir da coleta e anlise das medidas para estabelecer a distribuio e o intervalo de resultados que caracterizam o desempenho esperado para os processos, gerando os ndices de capacidade atravs dos clculos estatsticos.
SP 1.5 Estabelecer Modelos de Desempenho de Processo Resume-se em estabelecer e manter os modelos de desempenho de processo para o conjunto de processos padro da organizao. Os modelos de desempenho de processo so usados para estimar ou prever os valores de uma medida de desempenho de processo a partir de valores de medies de outros processos, produtos e servios. Neste caso, o prprio seis sigma (6) o valor modelo, obtido atravs do clculo do nvel sigma.
Gesto Quantitativa do Projeto (QPM)

A rea de processo (PA) Gesto Quantitativa do Projeto (QPM) (Tabela 8) est englobada no nvel 4 de maturidade e possui duas metas especficas (SG): Gerenciar o Projeto Quantitativamente, onde o projeto gerenciado quantitativamente a partir do uso dos objetivos de qualidade e de desempenho de processo; e a SG Gerenciar Estatisticamente o Desempenho de Subprocessos, na qual o desempenho de subprocessos selecionados no processo definido do projeto gerenciado estatisticamente. A primeira meta contempla as seguintes prticas especficas (SP): SP 1.1 Estabelecer os Objetivos do Projeto Consiste em estabelecer e manter os objetivos de qualidade e de desempenho de processo do projeto. O Seis Sigma atende a esta prtica atravs do termo de abertura do projeto que gerado na atividade Desenvolver a declarao do problema, objetivos e benefcios na fase de Definio. SP 1.2 Compor o Processo Definido Consiste em selecionar os subprocessos que compem o processo definido do projeto com bases histricas de estabilidade e de dados de capacidade. No h atividade equivalente no Seis Sigma.
24
M etodologias geis
QPM SG 1 Gerenciar o Projeto Quantitativamente Prticas Especficas - CMMI SP 1.1 Estabelecer os Objetivos do Projeto SP 1.2 Compor o Processo Definido
Gesto Quantitativa do Projeto (QPM) Passos do Seis Sigma DEFINE ------MEASURE Desenvolver a declarao do problema, objetivos e benefcios ------Determinar capacidade do processo e Baseline Sigma Identificar valor/no-valor de etapas adicionadas no processo SP 1.4 Gerenciar o Desempenho do Projeto ANALYZE Identificar fontes de variao Determinar a(s) causa(s) raiz(es) Desenvolver potenciais solues IMPROVE Definir tolerncias operacionais do sistema em potencial
SP 1.3 Selecionar os Subprocessos que sero Gerenciados Estatisticamente
SG 2
Gerenciar Estatisticamente o Desempenho de Subprocessos Prticas Especficas - CMMI SP 2.1 Selecionar Medidas e Tcnicas Analticas Seis Sigma Definir defeitos, oportunidades, unidades e mtricas MEASURE MEASURE SP 2.2 Aplicar Mtodos Estatsticos para Compreender a Variao ANALYZE MEASURE ANALYZE SP 2.4 Registrar Dados de Gerenciamento Estatstico --Desenvolver plano de coleta de dados Validar o sistema de medio Coleta de dados Identificar fontes de variao Determinar a(s) causa(s) raiz(es) Determinar capacidade do processo e Baseline Sigma Identificar fontes de variao ---
SP 2.3 Monitorar o Desempenho dos Subprocessos Selecionados
Tabela 8. Mapeamento da rea de processo QPM e DMAIC
SP 1.3 Selecionar os Subprocessos que sero Gerenciados Estatisticamente Consiste em selecionar os subprocessos e identificar o processo e os atributos de produto a serem medidos e controlados. As prticas especficas SP 1.2 e SP 1.3 no possuem etapas correspondentes, pois, conforme mencionado anteriormente, o Seis Sigma executa a gerncia quantitativa em todos os processos incluindo, assim, todos os respectivos subprocessos. SP 1.4 Gerenciar o Desempenho do Projeto realizado o monitoramento do projeto para determinar se os objetivos de qualidade e de desempenho de processo do projeto sero satisfeitos e identificar aes corretivas quando apropriado. No Seis Sigma, executado um conjunto de 6 passos de monitoramento de desempenho do processo, citados na Tabela 8. A segunda meta desta PA contempla as seguintes prticas especficas: SP 2.1 Selecionar Medidas e Tcnicas Analticas Consiste em selecionar as medidas e as tcnicas analticas a serem usadas no gerenciamento estatstico dos subprocessos
selecionados. Trs passos do Seis Sigma podem ser utilizados: Definir defeitos, oportunidades, unidades e mtricas que fornece as definies das medidas a serem usadas no gerenciamento estatstico; Desenvolver plano de coleta de dados que documenta as definies operacionais das medidas, suas colees de pontos e como a integridade das medidas ser determinada; e Validar o sistema de medio que permite a atualizao das medidas e tcnicas de anlise estatstica quando necessrio. SP 2.2 Aplicar Mtodos Estatsticos para Compreender a Variao Consiste em estabelecer e manter um entendimento da variao dos subprocessos selecionados usando as medidas e as tcnicas analticas selecionadas. O entendimento da variao conseguido, em parte, coletando e analisando as medidas de processo e de produto de forma que as causas especiais de variao possam ser identificadas e endereadas para atingir desempenhos previsveis. Desta forma, utilizam-se os passos Seis Sigma Coletar dados, Identificar fontes de variao e Determinar a(s) causa(s) raiz(es).
25
SP 2.3 Monitorar o Desempenho dos Subprocessos Selecionados Monitorar o desempenho dos subprocessos selecionados para determinar a capacidade dos mesmos de satisfazer aos seus objetivos de qualidade e de desempenho de processo, e identificar aes corretivas quando necessrio. No Seis Sigma, os passos Determinar capacidade do processo e Baseline Sigma e Identificar fontes de variao permitem obter os limites naturais de desempenho de processo comparados com seus objetivos estabelecidos e a capacidade de processo de cada subprocesso. SP 2.4 Registrar Dados de Gerenciamento Estatstico Trata-se de realizar o registro dos dados de gerenciamento estatstico e de qualidade no repositrio de medidas da organizao. O Seis Sigma no possui um passo definido para esta prtica, pois considera a coleta e o armazenamento como um nico passo.
metas especficas (SG): Selecionar Melhorias, onde so selecionadas as melhorias de processo e de tecnologia que contribuem para atingir os objetivos de qualidade e de desempenho de processo; e a SG Implementar Melhorias, na qual melhorias mensurveis para os processos e tecnologias da organizao so continuamente e sistematicamente implementadas. A primeira meta contempla as seguintes prticas especficas (SP): SP 1.1 Coletar e Analisar Propostas de Melhoria Consiste em coletar e analisar propostas de melhoria de processo e de tecnologia. No Seis Sigma, atravs do desenvolvimento da declarao do problema, objetivos e benefcios, so definidos os projetos de melhoria. Na fase de melhoria, so desenvolvidas as potenciais solues para os projetos estabelecidos. SP 1.2 Identificar e Analisar Inovaes Esta prtica identifica e analisa melhorias inovadoras que poderiam aumentar a qualidade e o desempenho de processo de uma organizao. No Seis Sigma, atravs do desenvolvimento
Inovao Organizacional (OID)

A rea de processo (PA) Inovao Organizacional (OID) (Tabela 9) est inserida no nvel de maturidade 5 e possui duas
OID SG 1 Selecionar melhorias Prticas Especficas - CMMI SP 1.1 Coletar e Analisar Propostas de Melhoria Passos do Seis Sigma DEFINE IMPROVE SP 1.2 Identificar e Analisar Inovaes SP 1.3 Melhorias Piloto SP 1.4 Selecionar Melhorias para Implantao SG 2 Implementar Melhorias Prticas Especficas - CMMI Passos do Seis Sigma IMPROVE IMPROVE IMPROVE
Inovao e Desenvolvimento Organizacional (OID)
Desenvolver a declarao problema, objetivos e benefcios Desenvolver potenciais solues Desenvolver potenciais solues Realizar projetos experimentais Desenvolver potenciais solues Validar melhorias em potencial de estudos-piloto
Definir defeitos, oportunidade, unidade e mtricas SP 2.1 Planejar a Implantao MEASURE Mapa detalhado do processo e reas adequadas Desenvolver plano de coleta de dados Realizar projetos experimentais IMPROVE SP 2.2 Gerenciar a Implantao CONTROL IMPROVE SP 2.3 Medir os Efeitos de Melhorias CONTROL Desenvolver potenciais solues Definir tolerncias operacionais do sistema em potencial Definir e validar acompanhamento e controle do sistema Validar melhorias em potencial de estudos-piloto Corrigir/reavaliar o potencial da soluo Determinar capacidade do processo Verificar benefcios, reduo/economia de custos, crescimento do lucro
Tabela 9. Mapeamento da rea de processo OID e DMAIC
26
M etodologias geis
de potenciais solues, so analisadas as todas as propostas de melhoria, incluindo as inovadoras. SP 1.3 Melhorias Piloto Implantao de melhorias de processo e tecnologia atravs de um piloto para selecionar aquelas a serem implementadas. Pilotos so realizados para avaliar mudanas novas importantes, sendo implantadas de forma abrangente, quando apropriado. O Seis Sigma realiza esta implantao piloto atravs dos projetos experimentais na fase de melhoria, criando solues para os pilotos que apresentam os melhores resultados. SP 1.4 Selecionar Melhorias para Implantao Nesta prtica, ocorre a seleo de melhorias de processo e de tecnologia para implantao na organizao. O levantamento baseado nos critrios quantificveis derivados dos objetivos de qualidade e de desempenho de processo da organizao. No Seis Sigma, est relacionada com a validao de melhorias em potencial de estudos-piloto, da fase de melhoria. A segunda meta desta PA contempla as seguintes prticas especficas: SP 2.1 Planejar a Implantao Estabelece e mantm os planos de implantao das melhorias de processo e de tecnologia selecionadas. No Seis Sigma, alguns passos podem ser utilizados: o Definir defeitos, oportunidade, unidade e mtricas estabelece medidas e objetivos para determinar o valor de cada melhoria de processo e de tecnologia com relao aos objetivos de qualidade e de desempenho de processo; obter o Mapa detalhado do processo e reas adequadas auxilia no entendimento do processo e na identificao de estratgias para enderear potenciais barreiras na implantao de cada melhoria de processo e de tecnologia; e Desenvolver plano de coleta de dados para agregar o uso de dados quantitativos na orientao da implantao. SP 2.2 Gerenciar a Implantao Realiza o gerenciamento da implantao das melhorias de processo e de tecnologia selecionadas. Nesta prtica, o planejamento pode ser quantificado em relao aos objetivos de negcio da organizao. Duas fases do Seis Sigma podem ser utilizadas: A fase de Medio, atravs dos passos: Realizar projetos experimentais, para implantao das melhorias de forma controlada e disciplinada; Desenvolver potenciais solues, para identificar aes corretivas, caso a habilidade dos processos definidos em atingir os objetivos de qualidade e de desempenho de processo seja afetada negativamente pela melhoria de processo; Definir tolerncias operacionais do sistema em potencial que pode ser utilizada para determinar a habilidade dos processos; A fase de Controle, que define e valida o acompanhamento e controle do sistema para documentar e revisar os resultados de implantao, identificando lies aprendidas, novas propostas e melhorias de processo.
SP 2.3 Medir os Efeitos de Melhorias Estabelece a medio dos efeitos das melhorias de processo e tecnologia implantadas. Aps medir custos, esforo, cronogramas reais, valor das melhorias, progresso da qualidade e desempenho, acontece o armazenamento das medidas no repositrio da organizao. Os passos do Seis Sigma que podem ser utilizados na fase de melhoria so: validar melhorias em potencial de estudos-piloto, corrigir/ reavaliar o potencial da soluo. E na fase de controle: determinar capacidade do processo, verificar benefcios, reduo/economia de custos, crescimento do lucro.
Anlise de Causa e Soluo de Problemas (CAR)

A rea de processo (PA) Anlise de Causa e Soluo de Problemas (CAR) (Tabela 10) est includa no nvel 5 de maturidade e possui duas metas especficas (SG): Determinar Causas de Defeitos, onde as causas de defeitos e de outros problemas so sistematicamente determinadas; e a SG Tratar as Causas dos Defeitos, na qual as causas raiz dos defeitos e de outros problemas so tratadas de forma sistemtica para prevenir suas ocorrncias futuras. A primeira meta contempla as seguintes prticas especficas (SP): SP 1.1 Selecionar Dados de Defeitos para Anlise Seleciona os defeitos e outros problemas para anlise. Na fase Medir do Seis Sigma, realiza-se a definio de defeitos, oportunidades, unidades e mtricas que rene dados de defeitos ou de problemas relevantes; h o desenvolvimento do plano de coleta de dados para fazer relatrios e medies de problemas relevantes; e por ltimo a coleta de dados para determinar e selecionar defeitos. SP 1.2 Analisar Causas Realiza a anlise de causas de defeitos selecionados e de outros problemas e prope aes para trat-los. O Seis Sigma utiliza o passo Determinar a(s) causa(s) raiz(es) para conduzir as anlises nas reunies e o passo Identificar fontes de variao para analisar os defeitos e outros problemas para determinar solues. Ambos os passos so da fase de Anlise. A segunda meta desta PA contempla as seguintes prticas especficas: SP 2.1 Implementar Propostas de Ao Implementa as propostas de ao selecionadas que foram elaboradas na anlise de causa. As propostas descrevem as tarefas necessrias para remover as causas razes dos defeitos ou dos problemas analisados e evitar suas recorrncias. Durante a implementao as informaes e tarefas podem fazer parte do passo de desenvolver o plano de transferncia (handoff para o proprietrio do processo), da fase controlar no Seis Sigma, contribuindo para que os experimentos sejam conduzidos de forma transparente.
27
CAR SG 1 Determinar Causas de Defeitos Prticas Especficas - CMMI SP 1.1 Selecionar Dados de Defeitos para Anlise
Anlise e Resoluo de Causas (CAR)
Passos do Seis Sigma Definir defeitos, oportunidade, unidade e mtricas MEASURE Desenvolver plano de coleta de dados Coleta de dados Determinar a(s) causa(s) raiz(es) Identificar fontes de variao
SP 1.2 Analisar Causas SG 2 Tratar as Causas dos Defeitos Prticas Especficas - CMMI SP 2.1 Implementar Propostas de Ao
ANALYZE
Passos do Seis Sigma CONTROL Desenvolver plano de transferncia, Handoff para o proprietrio do processo Avaliar modos de falha de solues em potencial Validar melhorias em potencial de estudos-piloto Verificar reduo/economia de custos, crescimento do lucro
SP 2.2 Avaliar os Efeitos das Mudanas
IMPROVE
SP 2.3 Registrar Dados Tabela 10. Mapeamento da rea de processo CAR e DMAIC
CONTROL
Fechar o projeto, finalizar documentao
SP 2.2 Avaliar os Efeitos das Mudanas Avalia os efeitos das mudanas no desempenho do processo aps a sua implementao modificada no projeto. O efeito deve ser verificado para reunir evidncias de que essa mudana est corrigindo o problema e melhorando o desempenho. Trs passos da fase de melhoria do Seis Sigma podem ser utilizados: Avaliar modos de falha de solues em potencial que determina a influncia das mudanas no desempenho, Validar melhorias em potencial de estudos-piloto que valida a eficincia da melhoria e, por fim, Verificar reduo/economia de custos, crescimento do lucro. SP 2.3 Registrar Dados Faz o registro dos dados de anlise de causa e resoluo para uso no projeto e na organizao, que pode ser usado para fazer mudanas de processo apropriadas e alcanar resultados similares. No Seis Sigma, o passo de controle que fecha o projeto e finaliza a documentao responsvel por fazer os registros de todo material.
O Atlntico desenvolve projetos de tecnologia da informao na linha de software, hardware e sistemas, para clientes de diversos segmentos de mercado, gerando solues em Computao Mvel, Integrao de Sistemas, TV Digital, Aplicaes Financeiras, Web, Sistemas para Redes, Automao, Engenharia de Telecom, Hardware e Sistemas Embarcados. Estas solues so desenvolvidas em J2EE, J2ME e. NET (ATLANTICO, 2009b).
Qualidade como Ferramenta Estratgica

Desde o incio de suas operaes, o Atlntico coloca em prtica a ideia de que o investimento em um amplo sistema de qualidade a forma mais eficiente de se gerar bons resultados. Em 2005, a empresa conquistou a certificao ISO 9001:2000. Em fevereiro de 2006 o Atlntico foi avaliado como CMMI Nvel 3, sendo a primeira organizao Norte/Nordeste com esse nvel de maturidade. Em 2009, a qualidade atingiu seu auge com a avaliao CMMI nvel 5, que apoiados em filosofias de trabalho como Six Sigma, RUP, PMBoK, Agile e MSF (ATLANTICO, 2009c). A Figura 20 apresenta um breve histrico das certificaes obtidas pela empresa, acompanhado das filosofias de qualidades utilizadas.
Estudo de Caso
Neste tpico apresentado um exemplo de utilizao do Seis Sigma para o alcance do nvel 5 de maturidade do CMMI, realizado pelo Instituto Atlntico.
A Empresa
Fundado em 2001 pelo CPqD, (Centro de Pesquisa de Desenvolvimento em Telecomunicaes do Brasil), o Atlntico atua em P&D/Inovao, Projetos de Desenvolvimento e Consultoria, atendendo principalmente Indstria, Governo e Setor Financeiro. Suas unidades em Fortaleza-CE, Sobral-CE e So Paulo-SP agregam mais de 290 profissionais.
Figura 20. Histrico de Certificaes e Filosofias de Qualidade (Fonte: Adaptao (ATLNTICO, 2009c))
28
M etodologias geis
Desta forma, o Atlntico obteve timos resultados, possibilitando maior ndice de entregas dentro do custo e prazo, com alto padro de qualidade e aumento na satisfao dos seus clientes.
Estratgia CMMI x Seis Sigma

Atualmente, o Instituto Atlntico a sexta organizao no Brasil reconhecida com o CMMI-5. Para o alcance deste objetivo, o instituto foi auxiliado pela empresa de consultoria internacional com foco exclusivo em qualidade de processos, ISD (Integrated System Diagnostics Brasil S/C Ltda). A estratgia utilizada para o alcance do Nvel 5 com base no Seis Sigma, foi implementada em trs fases (ATLANTICO, 2009a): Fase 1 Planejamento e Definio da Estratgia Formao de yellow belts e green belts (consultoria de black belts) Reestruturao dos processos de melhoria contnua para incorporar a nova filosofia 6 (DMAIC) Reestruturao dos indicadores de acordo com as estratgias (BSC e M&A) Seleo de projetos de melhoria DMAIC e lderes (DAR) Fase 2 Execuo da Estratgia de Melhoria (DMAIC) D Definio dos Projetos e Casos de Negcios M Medio do Estado Atual A Anlise e Teste das Causas I Propostas de Melhoria C Estabelecimento de Controles Organizacionais Acompanhamento dos projetos DMAIC Tra nsio das mel horias e ga n hos obt idos para a produo Fase 3 Avaliao da Estratgia Acompanhamento das melhorias e ganhos obtidos Avaliao independente dos resultados dos projetos DMAIC
Figura 23. Atendimento ao Prazo (Fonte: (ATLNTICO, 2009a)) Figura 21. Produtividade (Fonte: (ATLNTICO, 2009a))
Figura 22. Densidade de Defeitos (Fonte: (ATLNTICO, 2009a))
o grande diferencial: a organizao vai sempre executar os seus processos de forma melhor, mais otimizada, mais eficiente e eficaz. O controle estatstico um pr-requisito para fazer essa melhoria dos processos. A partir desse controle se sabe qual o desempenho e se executam as aes para melhorar tudo baseado em controle estatstico. Conforme Cludio Violato, atual presidente do Instituto Atlntico e vice-presidente de Tecnologia do CPqD, o Atlntico se tornou muito mais capaz de planejar, de organizar, de estruturar e de garantir o resultado de acordo com o planejado (ATLANTICO, 2009d): O CMMI contribui para melhorar o resultado financeiro em dois sentidos, disse ele. Primeiro porque temos mais condies de trazer mais projetos para fazer. E segundo porque a gente faz o projeto com mais controle: a chance de perda muito menor. Ento o resultado financeiro comea a melhorar tambm.
Resultados
Andr Pinho, analista da ISD que acompanhou as avaliaes ao longo da preparao para o CMMI5, destaca a reduo de retrabalho, reduo de problemas, a melhoria da produtividade e afirma que a certificao se traduz em ganhos para a empresa (ATLANTICO, 2009d): Quando a empresa comea a medir, controlar e a usar ferramentas estatsticas, possvel melhorar o desempenho, que se traduz em resultados - inclusive financeiros. Os grficos a seguir permitem uma visualizao resumida dos benefcios em termos de produtividade (Figura 21), densidade de defeitos (Figura 22) e atendimento ao prazo (Figura 23). Gabriela Teles, que coordenou a equipe do Atlntico nos dois anos de preparao para chegar ao CMMI5 faz suas consideraes sobre os benefcios para a empresa (ATLANTICO, 2009d):
Concluso
Diante do atual cenrio de mercado altamente competitivo, mais importante do que nunca para as organizaes o investimento na melhoria de processos para atender s suas misses (satisfao dos clientes, lucratividade, qualidade, entre outras).
29
Referncias Bibliogrficas ABRANTES,Jos.Programa 8S:da alta administrao linha de produo:o que fazer para aumentar o lucro?: a base da filosofia Seis Sigma.Rio de Janeiro: Intercincia, 2001. ASQ 2009a American Society for Quality.Organization-Wide Approaches.Disponvel em: http://www.asq. org/learn-about-quality/six-sigma/overview/belts-executives-champions.html.Acessado em: 01/11/2009. ASQ 2009b American Society for Quality.Six Sigma Black Belt Certification CSSBB.Disponvel em: http:// www.asq.org/certification/six-sigma/index.html.Acessado em: 09/11/2009. ASQ 2009c American Society for Quality.Six Sigma Green Belt Certification CSSBB.Disponvel em:http:// www.asq.org/certification/six-sigma-green-belt/index.html.Acessado em: 08/11/2009. ATLANTICO 2009a Instituto Atlntico. Utilizao do Six Sigma para o alcance do nvel 5 de maturidade do CMMI. Disponvel em: http://www.atlantico.com.br/ sites/default/files/biblioteca/utilizacao-do-six-sigmapara-o-alcance-do-nivel-5-de-maturidade-do-cmmi.pdf.Acessado em: 09/12/2009. ATLANTICO 2009b Website do Instituto Atlntico. Quem Somos. Disponvel em: http://www. institutoatlantico.com.br/quem-somos.Acessado em: 09/12/2009. ATLANTICO 2009c Website do Instituto Atlntico. Quem Somos - Qualidade. Disponvel em: http://www. institutoatlantico.com.br/quem-somos/qualidade.Acessado em: 09/12/2009. ATLANTICO 2009d Website do Instituto Atlntico. Notcias Instituto Atlntico conquista CMMI Nvel 5. Disponvel em: (http://www.institutoatlantico.com.br/ noticias/instituto-atl%C3%A2ntico-conquistacmmi-n%C3%ADvel-5) Acessado em: 09/12/2009. BARTI, Alexandre. Garantia da Qualidade de Software: Adquirindo maturidade organizacional. Rio de Janeiro: Elsevier, 2002. CARVALHO, Marly Monteiro de, PALADINI, Edson Pacheco.Gesto da Qualidade:Teoria e Casos.Rio de Janeiro: Elsevier, 2005. CITS - CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE. CMMI (CAPABILITY MATURITY MODEL INTEGRATION).Disponvel em: http://www.cits.br/cmmi.do.Acessado em 24/09/2009. CMMI Product Development Team. CMMI for Development, Version 1.2 (CMU/SEI-2006-TR-008, ESC-TR2006-008).Software Engineering Institute, Carnegie Mellon University, 2006. EFQM European Foundation for Quality Management.The EFQM Excellence Model. Disponvel em: http:// ww1.efqm.org/en/Home/aboutEFQM/Ourmodels/TheEFQMExcellenceModel/tabid/170/Default.aspx. Acessado em: 24/09/2009. FERNANDES, Aguinaldo Aragon. Implantando a governana de TI: da estratgia gesto dos processos e servios.2.ed.Rio de Janeiro: Brasport, 2008. FINANCE,Yahoo. GE Interactive Charts. Disponvel em: http://finance.yahoo.com/echarts?s=GE#chart2:sym bol=ge;range=19650104,20040101;indicator=volume+mfi;charttype=line;crosshair=on;ohlcvalues=0 ;logscale=on;source=undefined.Acessado em: 11/11/2009. FNQ FUNDAO NACIONAL DA QUALIDADE. Critrios de Excelncia 2009 - Avaliao e Diagnstico da Gesto Organizacional. Disponvel em: http://www.fnq.org.br/Portals/_FNQ/Documents/web_ CriteriosExcelencia2009_mais_recente.pdf.Acessado em: 22/09/2009. GRUPO WERKEMA - Six Sigma Consultores, Werkema Editora e Ousar Comunicao Estratgica. Dvidas frequentes sobre o Seis Sigma. Disponvel em: http://www.werkemaconsultores.com/inside.php?ident=8. Acessado em: 05/11/2009. ISIXSIGMA 2009a Six Sigma Quality Resources for Achieving Six Sigma Results. The History of Six Sigma. Disponvel em: http://www.isixsigma.com/library/content/ c020815a.asp .Acessado em: 05/11/2009. ISIXSIGMA 2009b Six Sigma Quality Resources for Achieving Six Sigma Results. Six Sigma DMAIC Roadmap. Disponvel em: http://www.isixsigma.com/library/ content/c020617a.asp.Acessado em: 11/12/2009. MOTOROLA Website da Motorola Brasil. Linha do Tempo. Disponvel em: http://www.motorola.com/ content.jsp?globalObjectId=485-914#top.Acessado em: 05/10/2009. PANDE, P. S.; NEUMAN, R. P.; CAVANAGH, R. R. Estratgia seis sigma: como a GE, a Motorola e outras grandes empresas esto aguando seu desempenho.Rio de Janeiro: Qualitymark, 2001. PDP Net Ambiente de Compartilhamento de Conhecimentos em Desenvolvimento de Produtos. Roteiro DMAIC. Disponvel em: http://www.pdp.org.br/ModeloLivroWeb/modelo/met_ferram/seissigma/ fm6sigma_rot1.htm.Acessado em: 12/11/2009. PROFITABILITY Engineers. Six Sigma Green Belt. Disponvel em: http://www.profitability.pt/conteudos. aspx?cat=30&catMae=26.Acessado em: 06/11/2009. ROCHA, Hlio. Simples Solues Desenvolvimento Organizacional Ltda. Programa 8S Promovendo a Qualidade de Vida. Disponvel em: http://www.simplessolucoes.com.br/blog/wp-content/ uploads/2009/04/programa-8s-rev02.pdf.Acessado em 05/10/2009. SEI. Performance Results of CMMI - Based Process Improvement (TECHNICAL REPORT CMU/SEI-2006-TR004, ESC-TR-2006-004). Software Engineering Institute, Carnegie Mellon University, 2006. Disponvel em: http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html.Acessado em 23/09/2009. SEI. Relationships Between CMMI and Six Sigma (TECHNICAL NOTE CMU/SEI-2005-TN-005). Software Engineering Institute, Carnegie Mellon University, 2005. Disponvel em: http://www.sei.cmu.edu/ reports/05tn005.pdf.Acessado em 02/12/2009. SMIDT & PARTNERS. The phase model for problem solving is named DMAIC. Disponvel em: http://smidtpartners.dk/six-sigma_uk/dmaic.html.Acessado em: 12/11/2009. SSPJ - SECRETARIA DA SEGURANA PBLICA DO ESTADO DE GOIS. Ferramentas da Qualidade. Disponvel em: http://www.sspj.go.gov.br/policia-comunitaria/aulas-do-curso/gestao-qualidade/material-de-apoio. doc.Acessado em: 21/09/2009. TENNANT, Geoff.SIX SIGMA: SPC and TQM in Manufacturing and Services.Gower Publishing Ltd, 2001.
30
edio ta
Muitas empresas percebem sabiamente que no preciso faz-lo a partir do zero, sendo possvel otimizar os processos existentes, utilizando iniciativas de melhoria e prticas. No entanto, pode haver uma sobrecarga de iniciativas. Desta forma, os responsveis por aplicar os esforos de melhoria de processos organizacionais devem projetar a sua estratgia e tticas de implementao para que as mltiplas iniciativas escolhidas possam interagir. Determinar o que apropriado requer uma compreenso das iniciativas selecionadas e suas ligaes. Este artigo abordou os aspectos comuns existentes entre o Seis Sigma e o CMMI de modo que a sinergia entre ambos possa ser percebida.
O valor potencial que adicionado trata-se da obteno acelerada de metas de desempenho, otimizao da adoo do CMMI (nos nveis mais altos), desenvolvimento das habilidades mais importantes de medio e anlise para permitir uma melhor quantificao dos resultados, e toda a mudana de cultura correspondente que acompanha essas melhorias.
D s
D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Feedback eu
sobre e s
M etodologias geis
AMIGO
Existem coisas que no conseguimos ficar sem!
...s pra lembrar, sua assinatura pode estar acabando!
Renove J!
www.devmedia.com.br/renovacao
Para mais informaes: www.devmedia.com.br/central
31

Colaborao em Processos de Aquisio de Software

De que se trata o artigo?
Utilizando o Modelo de Colaborao 3C e o Guia de Aquisio do MPS.Br, este artigo discorre sobre os aspectos colaborativos em processos de aquisio de software. Ele identifica suas principais questes e tambm algumas ferramentas para apoio ao trabalho colaborativo no contexto descrito.
O
Joo Condack
condack@primeup.com.br
Mestre em Informtica e Engenheiro de Computao pela PUC-Rio. Coordenador de Instituio Implementadora MPS.Br. Realizou consultoria empresas como Furnas, Smart Solutions e Banco Ita. Tambm instrutor de cursos na rea de processos de software pela PrimeUp e pela CCE/PUC-Rio atendendo organizaes como Caixa Econmica Federal, Firjan, Petrobrs entre outras.
Rafael Vieira
rafael.vieira@primeup.com.br
Bacharel em Sistemas de Informao pela PUC-Rio. Foi analista de sistemas em projetos junto organizaes tais como: IBGE, M4U e MP-RJ. Instrutor do Programa de Residncia em Desenvolvimento de Software do LES/PUC-Rio. Tambm atuou no projeto e desenvolvimento de framework para aplicaes colaborativas visando apoio aquisio de software.
rganizaes que tenham necessidades de adquirir software e servios relacionados se deparam frequentemente com problemas inerentes ao trabalho colaborativo, que se caracteriza pelo trabalho atravs da interao entre diversos indivduos. Os desafios e problemas de interao no possuem uma soluo simples, como um produto nico disponvel no mercado, e no podem ser tratados somente por meio de ferramentas. Os desafios podem envolver desde a integrao de pessoas com perfis profissionais diferentes at as dificuldades de identificao das necessidades de aquisio, dado que cada stakeholder tem sua prpria viso e abordagem. Para ilustrar a situao considere o seguinte cenrio: Equipes de departamentos jurdico e tcnico discutindo questes legais sobre contratos de software; Analistas de requisitos discutindo e obtendo aprovao de requisitos, junto aos usurios;
Para que serve?

O objetivo deste artigo apresentar os problemas especficos relacionado colaborao em processos de aquisio de software e indicar algumas das possveis solues para estes.
Em que situao o tema til?

O tema til para organizaes que adquirem softwares produzidos por terceiros e que desejam melhorar seu processo de aquisio, com o fim de torn-lo eficiente e eficaz.
O gerenciamento do contrato, o qual poderia ser verificado, ou mesmo renegociado, a cada nova verso do sistema com o cliente. O objeto da aquisio definido pelo Guia de Aquisio do MPS.BR o produto de software propriamente dito, bem
32
Engenharia de Software Magazine - Colaborao em Processos de Aquisio de Software
processo
como servios tipicamente relacionados ao desenvolvimento, implantao, suporte operao e manuteno do software. O processo de aquisio trata das atividades relacionadas contratao deste objeto, com o fim de criar e manter uma relao entre cliente e fornecedor em que expectativas de incorporao e entrega de sistemas sejam atendidas. Esse processo pode ser descrito atravs de quatro fases: 1. preparao da aquisio 2. seleo do fornecedor 3. monitorao do fornecedor 4. aceitao pelo cliente
Nestas fases, as atividades apresentadas na Tabela 1 so executadas.

Guia de Aquisio Atividades Tarefas Estabelecer a necessidade Definir os requisitos Revisar requisitos Desenvolver uma estratgia de aquisio Definir os critrios de seleo de fornecedores Avaliar a capacidade dos fornecedores Selecionar o fornecedor Preparar e negociar um contrato Estabelecer e manter comunicaes Trocar informao sobre o progresso tcnico Inspecionar o desenvolvimento com o fornecedor Monitorar a aquisio Obter acordo quanto s alteraes Acompanhar problemas Definir critrios de aceitao Avaliar o produto entregue Manter conformidade com o contrato Aceitar o S&SC
Preparao da aquisio
Seleo do fornecedor
O problema
Para atender novas demandas organizacionais por tecnologia de informao, pode ser necessrio: Desenvolver novos sistemas no lugar dos que j existem; Desenvolver sistemas que reutilizem os que j existem ou realizar servios para sua manuteno; Contratar outra empresa que realize as atividades mencionadas acima; Adquirir sistemas gratuitos que atendam s necessidades. Caso a deciso tomada seja por contratar o desenvolvimento, ser necessrio, em linhas gerais: definir as necessidades que o sistema atender; selecionar o fornecedor; criar um ou mais contratos, formalmente ou informalmente definido, dependendo do nvel de cerimnia combinado com o contratante; estabelecer meios de comunicao com o fornecedor e acompanhar o cumprimento do contrato; e, por fim, aceitar ou no o sistema. Esse processo poderia se repetir diversas vezes. Por conta disso, surgem questes indagando se a forma de trabalho auxiliou na integrao e na comunicao entre os interessados no projeto, ou se o conhecimento adquirido, que poderia ser til para novas aquisies, foi registrado adequadamente.
Monitorao do fornecedor
Aceitao pelo cliente
Tabela 1. Fases e tarefas do Guia de Aquisio do MPS.BR
O Guia de Aquisio do MPS.BR e a Colaborao

O Guia de Aquisio do MPS.BR um modelo de referncia para processos de aquisio de software. Ele define que esses processos so constitudos de atividades, as quais so executadas em fases especficas e possuem produtos como pr-condies ou ps-condies. Essas fases so: 1. Preparao da aquisio: trata da definio de necessidades, requisitos de software, metas e critrios de aceitao do software a ser contratado, bem como a definio do plano da aquisio; aqui se busca entender as necessidades do sistema a ser adquirido; 2. Seleo do fornecedor: trata da preparao e negociao de contratos com fornecedores e avaliao e seleo destes; 3. Monitorao do fornecedor: visa manter canais de comunicao com o fornecedor e acompanhar a aquisio propriamente dita, ou seja, se as entregas esto dentro dos critrios de aceitao definidos anteriormente; 4. Aceitao pelo cliente: realiza a aceitao final do produto desenvolvido, com base nos critrios definidos na preparao da aquisio; momento em que o sistema integrado totalmente organizao contratante.
Neste processo, diversos papis so desempenhados, entre os quais os mais evidentes so o do cliente e o do fornecedor. Representando o cliente, outros papis podem ser identificados, como, por exemplo, analistas de requisitos, pessoal tcnico, usurios ou responsveis pelo projeto. Representando o fornecedor, tambm podem ser identificados gerentes de projetos, analistas de requisitos, arquitetos ou representantes comerciais. importante destacar que, diferentemente de processos convencionais de desenvolvimento de software, h um foco muito maior no cliente e no gerenciamento de suas interaes com o fornecedor. Segundo o trabalho de Fuks, um grupo tambm tem mais capacidade de gerar alternativas, levantar as vantagens e desvantagens de cada uma, selecionar as viveis e tomar decises. Ou seja, por um lado essa diversidade de papis pode apresentar desafios, mas tambm possui um potencial positivo para a melhoria da anlise e gerao de solues mais adequadas ao que necessrio. Dessa forma, a natureza colaborativa desse processo se torna evidente, bem como toma contornos diferentes de um processo de desenvolvimento. Sabendo disso, faz-se necessrio entender quais so as carncias e oportunidades inerentes ao trabalho colaborativo, com o fim de maximizar o efeito positivo das interaes entre diversos agentes. Fuks, em seu trabalho, prope o modelo 3C, que classifica os sistemas colaborativos segundo trs necessidades a que estes devem atender: comunicao, coordenao e cooperao. Ou seja, necessidades de compartilhamento de informaes, delegao e sincronismo de tarefas e operao conjunta e benfica, resumidamente. Mais detalhadamente:
33
Comunicao: Durante a comunicao, as pessoas almejam construir um entendimento comum e compartilhar idias, discutir, negociar e tomar decises. Os participantes de uma equipe de trabalho devem se comunicar para conseguir realizar tarefas interdependentes, no completamente descritas ou que necessitem de negociao; Coordenao: Conversao para ao gera compromissos Winograd and Flores, (1987) e Winograd (1988). Para garantir o cumprimento destes compromissos e a realizao do trabalho colaborativo atravs da soma dos trabalhos individuais, necessria a coordenao das atividades. Esta coordenao organiza o grupo para evitar que esforos de comunicao e cooperao sejam perdidos e que as tarefas sejam realizadas na ordem correta, no tempo correto e cumprindo as restries e objetivos [Raposo et al., 2001].; Cooperao: Cooperao a operao conjunta dos membros do grupo no espao compartilhado. Em um espao virtual de informao, os indivduos cooperam produzindo, manipulando e organizando informaes, bem como construindo e refinando artefatos digitais, como documentos, planilhas, grficos, etc. O ambiente pode fornecer ferramentas de gerenciamento destes artefatos, como por exemplo, registro e recuperao de verses, controle e permisses de acesso, etc.
Ferramentas de Apoio ao Trabalho Colaborativo

Ferramentas colaborativas que apiem tarefas do processo de aquisio de software devem considerar os elementos expostos anteriormente. Muitas delas esto disponveis para uso na Web ou para customizao ou integrao e se encaixam nas caractersticas mencionadas, sendo at mesmo passveis de integrao, visando o suporte completo a fluxos de interao entre os stakeholders. Na Tabela 2, algumas delas so apresentadas dentro da classificao do modelo 3C.
Comunicao E-mail Lista de discusso Frum Mural Brainstorming Chat Messenger Blog Videoconferncia Agenda Relatrio de atividades Acompanhamento de participao Questionrios Tarefas Grupos de trabalho Gerenciamento de recursos Workflow Coordenao Cooperao Gerenciador de documentos Quadro branco Ferramenta de busca Glossrio Links Jornal cooperativo Classificador Wiki Gerenciador de contatos Reviso em pares FAQs Anotaes RSS Tabela 2. Ferramentas de colaborao
Brainstorming: ferramentas que apiem a gerao de idias podem ser teis nas fases iniciais, como apoio ao planejamento. Foram levantadas as seguintes ferramentas que ajudam na gerao ou organizao de idias: - Mind map: forma intuitiva de registro e organizao de conhecimento, onde conceitos se relacionam com conceitos adjacentes a eles, formando uma rvore; - Grfico de Ishikawa: possibilita a visualizao das relaes de causa e efeito entre os conceitos. til para a anlise de problemas e das necessidades de alto nvel que levam aquisio do software ou servio correlato. FAQs (Frequently Asked Questions): possibilita o registro de dvidas e de solues simples que possam ser reutilizadas, em vrios projetos de aquisio. Problemas mais complexos poderiam ser registrados em uma ferramenta de workflow; Frum: para apoio discusso, manuteno das discusses e suas concluses, bem como seu registro; Gerenciador de documentos: manuteno de documentos diversos, como pginas wiki, mensagens em fruns e documentos e templates de, por exemplo, contratos de software, RFP (request for proposal), entre outros; Grupos de trabalho: ferramentas que permitem gerenciar grupos de trabalho, auxiliam no controle de acesso ao contedo e ao gerenciamento de recursos; Quadro branco: possibilita fazer esboos rpidos, para apoio comunicao falada e construo colaborativa de esboos. Pode ser usada em conjunto com videoconferncia, para apoio s reunies virtuais, no caso de equipes geograficamente distribudas. A dificuldade do uso da ferramenta se d pela necessidade de habilidades para desenho, quando esta no oferece apoio construo de telas e montagem de cenrios de uso (storyboarding); RSS (Really Simple Syndication): tecnologia que faz uso de arquivos XML (RSS feeds) gerados por sistemas Web para informar programas leitores (RSS readers) das alteraes nas pginas, notificando os usurios de atualizaes de contedo. Facilita o acompanhamento de alteraes de contedos de interesse do usurio, que pode escolher ou no acompanhar a evoluo das pginas Web. Videoconferncia: para apoio discusso, bem como seu registro, em tempo real. til para apoio a reunies; Wiki: ferramenta para a construo de contedo coletivo, em que qualquer usurio pode inserir ou editar o contedo. til, no contexto de aquisio, para a manuteno de informaes comuns a diversos projetos de aquisio. Poderia ser usado tambm para a publicao do processo de aquisio; Workflow, para acompanhamento do fluxo de tarefas e de resoluo de problemas. Cenrios de uso em que seriam empregadas tais ferramentas podem ser ilustrados da seguinte forma: Uma equipe integrando o departamento jurdico e tcnico discutem atravs de um frum, questes legais sobre contratos de software, e, em seguida, documentando o conhecimento produzido em um wiki ou em um repositrio de documentos central, em uma tarefa de preparao do contrato;
34
processo
Analistas de requisitos, entre outros envolvidos, discutindo sobre os requisitos com o apoio de prottipos em um quadro branco, os quais poderiam passar por um fluxo de aprovao (integrao com um mecanismo de workflow), com possvel documentao do conhecimento de negcio obtido, no wiki; O acompanhamento do cumprimento financeiro, fiscal e fsico do contrato verificado a cada nova release, tendo um fluxo de aprovao definido na ferramenta de workflow integrada plataforma colaborativa.
antecedentes do projeto de aquisio). Ao final, um documento deve ser gerado e anexado. Tarefa: Definir os requisitos Ferramenta: Workflow Apoio: Criao de uma solicitao Definir os requisitos para acompanhamento da tarefa. Registros de evoluo gerados automaticamente a partir de atualizaes em colaboraes relacionadas a esta tarefa Apoio: Criao de uma solicitao Pesquisa de Mercado para obter informaes que substanciem os requisitos. Verificar possveis fornecedores, outras empresas, e informaes da prpria organizao. Ferramenta: Blog Apoio: Divulgar chamada de participantes para definio de estrutura dos requisitos; Apoio: Divulgar chamada de participantes para definio dos requisitos; Apoio: Divulgar execuo de pesquisa de mercado; Apoio: Divulgar chamada de participantes para definio das restries do projeto. Ferramenta: Frum Apoio: Discutir: Qual a estrutura de requisitos necessria? Buscar consenso sobre quais os tipos/categorias de requisitos esperados, presena ou no de Priorizao, Restries, Graus de Aceitao, Restries Legais etc... Apoio: Discutir: Quais so os requisitos desta aquisio? Definir quais requisitos atendem as necessidades desta aquisio. Fortemente recomendado que sejam descritos em estrutura definida tendo em mente como eles devero futuramente ser aceitos. Apoio: Discusso sobre tcnicas de requisitos documentadas no wiki. Ferramenta: Enquetes Apoio: As informaes colhidas so suficientes para definir os requisitos? Sim, A maior parte, A metade, A menor parte, No Apoio: Os requisitos esto estruturados apropriadamente? Sim, A maior parte, A metade, Alguns apenas, No Apoio: Os requisitos contemplam....das necessidades.: a)a totalidade; b)parte definida; c)parte desconhecida; Apoio: Precisamos rever as necessidades e alter-las? Sim, No Apoio: Sabemos como medir os requisitos para aceit-los? Sim, A maior parte, A metade, Alguns apenas, No Apoio: O projeto de aquisio deve: a) Seguir em frente c) Aprofundar esta atividade c) Ser cancelado Apoio: As tcnicas de requisitos utilizadas foram adequadas? Sim, Para a maior parte dos requisitos, Para a menor parte dos requisitos, No Ferramenta: Wiki Apoio: Construo colaborativa da Especificao de requisitos, pode ter como anexo pesquisas de mercado, informaes
A correlao entre processos de aquisio e ferramentas colaborativas

Nesta seo vamos exemplificar mais detalhadamente como o processo de aquisio pode ser associado s ferramentas colaborativas. O relacionamento se d atravs do mapeamento entre as tarefas do Guia de Aquisio do MPS.BR e as referidas ferramentas. Este mapeamento, alm de informar as partes associadas, tambm define como tal relacionamento ocorre, definindo como ser o apoio da ferramenta especfica sobre determinada tarefa. Para fins de sntese, consideraremos apenas as tarefas da fase de Preparao da Aquisio, considerada estratgica para o processo como um todo. Resumiremos tambm o conjunto de ferramentas colaborativas s mais comumente encontradas. Sendo assim temos: Tarefa: Estabelecer a necessidade Ferramenta: Workflow Apoio: Criao de uma solicitao Estabelecer a necessidade para acompanhamento da tarefa. Registros de evoluo gerados automaticamente a partir de atualizaes em colaboraes relacionadas a esta tarefa. Ferramenta: Blog Apoio: Divulgar chamada de participantes para os Fruns e Enquetes desta tarefa. Ferramenta: Frum Apoio: Discutir: Qual o objetivo da aquisio? Quais so nossas necessidades e quais sero atendidas para o alcance do objetivo? Buscar consenso sobre as necessidades estratgicas envolvidas na aquisio e qual o efetivo escopo das necessidades a serem contempladas pela aquisio. Ferramenta: Enquetes Apoio: As necessidades esto levantadas apropriadamente? Sim, No, Apenas parte relevante delas. Apoio: A aquisio atender.....das necessidades.: a)a totalidade; b)parte definida; c)parte desconhecida; Apoio: O projeto de aquisio deve: a) Seguir em frente c) Aprofundar esta atividade c) Ser cancelado Ferramenta: Wiki Apoio: Construo colaborativa da anlise da necessidade da aquisio, pode ter como anexo documentos sobre a estratgia organizacional relacionada s necessidades (motivadores/
35
de fornecedores, prticas de outras organizaes. Deve estar clara a estrutura dos requisitos. Relacionar com as necessidades da aquisio e os critrios de aceitao. Ao final, um documento deve ser gerado e anexado. Apoio: Identificar e relacionar a legislao, jurisprudncia e normas pertinentes. Apoio: Catalogar lies aprendidas na tarefa que podem ser teis em outros momentos da aquisio. Apoio: Documentao e publicao das tcnicas associadas s atividades de requisitos. Tarefa: Revisar requisitos Ferramenta: Workflow Apoio: Criao de uma solicitao Revisar os requisitos. Registros de evoluo gerados automaticamente a partir de atualizaes em colaboraes relacionadas a esta tarefa. Ferramenta: Blog Apoio: Divulgar chamada para a reviso de requisitos. Definir critrios de reviso, por exemplo: para verificar ambiguidade, estabelecer uma matriz para preenchimento das comparaes dos requisitos entre si; estabelecer que cada requisito dever ter uma avaliao de custo/benefcio; etc Ferramenta: Frum Apoio: Discutir: Quais requisitos so crticos ou que devem ser priorizados? Buscar consenso quanto ao que fundamental ao software aps uma anlise individual. Apoio: Discutir: Como solucionar as incompatibilidades entre os requisitos? Buscar solues quanto a requisitos inconsistentes, se apresentarem alguma ameaa para o projeto. Apoio: Discutir: Qual o custo/benefcio de cada requisito? Estes esto compatveis com o projeto? Ferramenta: Enquetes Apoio: A lista de requisitos proposta est completa? Sim, A maior parte, A metade, A menor parte, No Apoio: A lista de requisitos proposta est priorizada e com custo/benefcio definido? Sim, A maior parte, A metade, A menor parte, No Ferramenta: Wiki Apoio: Registro e armazenamento da reviso da Especificao de requisitos. Apoio: Documentao e publicao de tcnicas de reviso de requisitos. Tarefa: Desenvolver uma estratgia de aquisio Ferramenta: Workflow Apoio: Definir e implantar o fluxo de contratao Apoio: Criao de uma solicitao Adequar modelo de contrato visando detalhar a abordagem a respeito de prazos, custo, escopo, multa, direito de distribuio uso e propriedade.
Ferramenta: Blog Apoio: Divulgar chamada para o desenvolvimento da estratgia de aquisio. Ferramenta: Frum Apoio: Discusso sobre os termos contratuais, financeiros e tcnicos; Apoio: Discusso sobre os critrios de aceitao do produto, frente aos requisitos. Estruturar discusses por requisitos ou grupo de requisitos relacionados; Apoio: Discusso para definio da forma de acompanhamento: pessoas, lista de produtos gerados, controle do projeto de aquisio, suficincia dos testes realizados, normas e modelos a seguir e riscos identificados. Distribuio de tarefas entre as equipes. Ferramenta: Enquetes Apoio: Os requisitos esto associados a critrios de aceitao que os avaliem? Apoio: Os requisitos e as necessidades para definio do plano de aquisio esto associados a termos de contrato que os formalizem? Ferramenta: Wiki Apoio: Construo colaborativa do Plano de aquisio, do Plano de testes de aceitao, da Requisio de propostas e da Minuta do contrato Tarefa: Definir os critrios de seleo de fornecedores Ferramenta: Workflow Apoio: Criao de uma solicitao Definir critrios de seleo para acompanhamento da tarefa. Registros de evoluo gerados automaticamente a partir de atualizaes em colaboraes relacionadas a esta tarefa Ferramenta: Blog Apoio: Divulgar chamada para a definio dos critrios de aceitao. Ferramenta: Frum Apoio: Discusso sobre os critrios de seleo dos fornecedores. Poder contemplar os seguintes fatores: localizao geogrfica do fornecedor; registro de desempenho em trabalhos similares; equipe e infra-estrutura disponveis para o desenvolvimento do produto desejado; tempo de mercado; experincia no domnio do problema; nvel de qualidade de seus processos utilizados; e certificaes exigidas. Ferramenta: Enquetes Apoio: A lista de critrios proposta est completa incluindo a forma de anlise e priorizao? Sim, A maior parte, A metade, A menor parte, No Ferramenta: Wiki Apoio: Construo colaborativa dos Critrios de seleo e anlise de fornecedores
36
processo
Alinhando solues
Para atender as questes, interaes e integraes levantadas at ento, uma soluo deve levar em conta requisitos que tenham como objetivos finais a promoo da integrao das equipes e pessoas envolvidas nos projetos de aquisio, bem como a promoo do reuso do conhecimento adquirido nos projetos antigos em projetos novos de aquisio. Dentre estes requisitos citamos: Integrao de equipes e pessoas - Apoio seqncia de tarefas de aquisio; - Suporte e acompanhamento de discusses; - Avaliao de resultados, busca de consenso e alinhamento de percepes em discusses; - Integrao das diversas equipes em um mesmo ambiente de trabalho. Reuso de conhecimento - Documentao do conhecimento e lies aprendidas, obtidos em cada projeto de aquisio; - Manuteno de base de documentos, com mecanismo de busca integrado; Vale ressaltar que esses requisitos tratam de diversos problemas inerentes a projetos de software, e que na sua ausncia geram prejuzos ou mesmo cancelamentos. Eles abordam, por exemplo, questes relacionadas a falha no entendimento das necessidades, rotatividade da equipe, requisitos incompletos e falta de participao do cliente. Outra caracterstica fundamental relacionada a implementao deste tipo de soluo a integrao de diversas aplicaes sobre uma arquitetura comum que permita a gesto, publicao e acompanhamento de fluxos de trabalhos e documentos. Neste ponto, a flexibilidade para reuso e extenso so requisitos essenciais. Requisitos e prottipos poderiam ser anotados ao longo das conversas com usurios e, ao final, salvos em um servidor central da plataforma colaborativa, ao qual o processo (fluxo) de desenvolvimento integrado. Outro exemplo poderia ser a disponibilizao de um repositrio central de documentos, em que toda a documentao do cliente passvel de anlise seria armazenada, podendo ser recuperada por um mecanismo de busca textual. Tudo isso poderia ser relacionado a (rastreado em) requisitos previamente registrados no servidor central, para fcil recuperao e apoio s tarefas de especificao de requisitos, posteriormente. J na fase de monitorao e aceitao do fornecedor, tarefas de acompanhamento do projeto ganham importncia maior. A cada nova verso disponvel para homologao, o registro das funcionalidades entregues e testes realizados podem servir para a gerao de relatrios de acompanhamento no servidor central. Esses relatrios, disponveis para o cliente, o permite acompanhar
o progresso tcnico em relao ao estipulado em contrato. Para o acompanhamento de problemas, sistemas j disponveis no mercado poderiam ser integrados onde fluxos de tarefas so adequados para rastrear os problemas identificados. Da mesma forma, o sistema coletaria dados para a produo de relatrios e acompanhamento do progresso tcnico pelo cliente. importante observar que essa plataforma central, pela qual toda a equipe de projeto interagiria, precisa ser integrada a ferramentas de apoio elicitao de requisitos, de construo e de acompanhamento de solicitaes, para o registro dos requisitos contratados e a gerao automtica dos relatrios de acompanhamento frente a esses requisitos. Essas so possveis linhas de soluo para os desafios colaborativos apresentados ao longo do processo de aquisio de software. Muitas outras integraes entre ferramentas e solues podem ser propostas. Entretanto, o importante a ser observado que, seja qual for a estratgia de soluo, as tecnologias empregadas devem levar em conta os diversos atores existentes no processo, apoiando-os nas suas interaes. De forma geral, esse apoio seria direcionado ao acompanhamento do projeto por parte do cliente e ao entendimento das necessidades do cliente pelo pessoal tcnico, permitindo assim a realizao efetiva da aquisio contratada entre as partes.
Referncias Bibliogrficas ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio, verso 1.2, junho 2007. Disponvel em: <www.softex.br> ALVES, ngela M; GUERRA, Ana. Aquisio de Produtos e Servios de Software. Rio de Janeiro: Elsevier, 2004. 213p. GUTWIN, C. & GREENBERG, S. The Mechanics of Collaboration: Developing Low Cost Usability Evaluation Methods for Shared Workspaces. IEEE 9th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE00). Junho 2000. FUKS, Hugo; RAPOSO, Alberto Barbosa; GEROSA, Marco Aurlio. Do Modelo de Colaborao 3C Engenharia de Groupware. In: Simpsio Brasileiro de Sistemas Multimdia e Web Webmdia 2003, Trilha especial de Trabalho Cooperativo Assistido por Computador, 03 a 06 de Novembro, Salvador-BA FUKS, H.; RAPOSO, A.B.; GEROSA, M.A. (2002), Engenharia de Groupware: Desenvolvimento de Aplicaes Colaborativas, XXI Jornada de Atualizao em Informtica, Anais do XXII Congresso da Sociedade Brasileira de Computao, V2, Cap. 3, ISBN 85-88442-24-8, pp. 89-128. Disponvel em http://www.les.inf.puc-rio.br/groupware.
www.devmedia.com.br/esmag/feedback
edio ta
A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link:
D s
D seu feedback sobre esta edio!
Feedback eu
sobre e s
37

Organizao Fbrica de Experincia

Obtendo vantagens competitivas nas empresas desenvolvedoras de software
Fernando Hadad Zaidan
fhzaidan@gmail.com
Leandro Librio da Silva

leandroliberio@gmail.com

Neste artigo compreenderemos o modelo de processo de desenvolvimento de software denominado organizao fbrica de experincia. A criao deste modelo se deu no laboratrio de Engenharia de Software da Universidade de Maryland, EUA. A caracterstica principal a presena de uma equipe destinada finalidade de externalizar o conhecimento dos desenvolvedores.
Atua no ramo de TI h mais de 25 anos. Doutorando na Cincia da Informao - UFMG. Mestre em Administrao pela Universidade FUMEC Bacharel em Cincia da Computao pela Universidade FUMEC. Gestor e desenvolvedor de Sistemas Web pelo UNI-BH. Analista de Sistemas e Programador de Computadores pela UFMG. Inclui cargos de diretor de empresas de desenvolvimento de software, administrador de TI, analista/desenvolvedor de sistemas e arquiteto de dados. Consultor de TI e organizacional. Professor e Coordenador da Ps-graduao da Faculdade Pitgoras. Professor de graduao da Faculdade Ined. Palestrante. Autor de artigos e livro.
mestrando em Educao Tecnolgica pelo Centro Federal de Educao Tecnolgica - CEFETMG. MBA em Gesto Comercial pela Fundao Getlio Vargas - FGV. Especialista em Banco de Dados pelo Centro Universitrio de Belo Horizonte - UNI-BH (2002). Possui graduao em Tecnologia em Informtica pelo Centro Universitrio Newton Paiva (2001). Atua tambm como professor e coordenador de cursos de especializao em Tecnologia da Informao do Ncleo de PsGraduao do Sistema Universitrio Pitgoras. Tambm leciona no UNI-BH.
Para que serve?

Visa obteno de vantagens competitivas e melhores resultados no desenvolvimento de software como exemplo na estimativa de custos, qualidade e prazos por meio da contribuio de experincias de projetos de software anteriores e da gesto da informao e do conhecimento.
George Leal Jamil

gljamil@gmail.com
Possui graduao em Engenharia Eltrica pela Universidade Federal de Minas Gerais (UFMG) (1982), Mestrado em Cincia da Computao pela UFMG (1999) e doutorado em Cincia da Informao pela UFMG (2005). Atualmente professor adjunto da Fundao Mineira de Educao e Cultura - FUMEC/BH . Tem experincia na rea de Cincia da Computao e Gesto Estratgica de Empresas, com nfase em Engenharia de Software, atuando principalmente nos seguintes temas: cincia da computao, engenharia de software, sistemas de informao, informtica, processo de software, gesto estratgica e de marketing.
ompreendemos a gesto do conhecimento como um processo contnuo onde uma organizao orienta suas vrias aes com base no conhecimento empresarial. Como tarefas tpicas temos a gerao, valorizao, registro, compartilhamento e aplicao do conhecimento para planos e processos variados dentro da empresa. Os resultados positivos da gesto do conhecimento so inegveis, uma vez que torna este precioso acervo o conhecimento num elemento decisivo para a formulao de vantagem competitiva pela empresa em seu cenrio competitivo.

Este modelo permite que as organizaes de desenvolvimento retenham conhecimento dos projetos do passado para melhorar as habilidades no desenvolvimento futuro, no permitindo que o conhecimento se perca ou se dissipe facilmente. Considerar o processo de desenvolvimento de software com o apoio da gesto do conhecimento, ou sob sua tica, extremamente oportuno. O processo
38
Engenharia de Software Magazine - Organizao Fbrica de Experincia
engenharia de soft ware
de desenvolvimento de software , segundo estudado na engenharia de software, um conjunto coordenado de tarefas organizacionais destinado a disponibilizar software de todas as formas para que uma empresa o utilize segundo seus planos estratgicos. Atividade de intensiva comunicao e que estrutura ideias e procedimentos muitas vezes no formalmente documentados, o processo de desenvolvimento de software oferece uma perspectiva muito interessante se for analisado sob as lentes da gesto do conhecimento. Neste contexto, o trabalho das fbricas de experincia oferece possibilidades importantes para a associao que evidenciamos. A Organizao Fbrica de Experincia (OFE) um modelo desenvolvido pelo laboratrio de Engenharia de Software da Universidade de Maryland. composta de duas organizaes que trabalham perfeitamente integradas. Neste modelo, existe uma equipe especfica destinada finalidade de externalizar (ou seja, difundir ou publicar) o conhecimento gerado dos prprios desenvolvedores. O desenvolvimento de software pode obter melhores resultados como exemplo na estimativa de custos, qualidade e prazos por meio da contribuio de experincias de projetos anteriores. Com cronogramas pressionados, elevadas expectativas quanto qualidade e produtividade e desafios tcnicos constantes, muitos projetos de software no oferecem possibilidades de explicitar (ou seja, estruturar formalmente, a partir do informal) o conhecimento. Porm, neste modelo, esta importante atividade fica por conta da equipe chamada fbrica de experincia. Esta equipe ser encarregada de analisar e sintetizar todos os tipos de experincia, incluindo as lies aprendidas, dados de projetos e relatrios que explicitam estas experincias mediante a criao de repositrios. Tal atividade, se considerada diante do processo de gesto do conhecimento, se constitui em potencial ganho para o produtor de software ao realizar as funes de gerao, formalizao, reteno, compartilhamento e valorizao.
de uma nova realidade. As organizaes devem almejar a aplicabilidade do conhecimento dos funcionrios no intuito de gerar novos conhecimentos. Os trabalhadores do conhecimento podem descobrir, criar, compilar, distribuir ou aplicar o conhecimento. Os processos organizacionais, dentre eles o processo de desenvolvimento de sistemas de informao, esto em constante melhoria, tornando-se uma busca constante por parte das organizaes. O processo de desenvolvimento de software pode ser compreendido como um mtodo de trabalho estruturado, em etapas gerenciveis individual e coletivamente, que tem como objetivo produzir, de forma coordenada, software para uma aplicao em geral. O modelo proposto por Victor Basili e seus colaboradores da Universidade de Maryland USA, denominado Organizao Fbrica de Experincia, apresenta uma equipe destinada finalidade de externalizar o conhecimento. Os principais ativos das empresas de desenvolvimento de software no so as construes, materiais ou equipamentos caros o capital intelectual. O maior problema com o capital intelectual que ele tem pernas e caminha para casa todos os dias, dificultando as organizaes na permanncia dos mesmos. A seguir, estudamos o processo de desenvolvimento de software, sua interao com a gesto do conhecimento e a oportunidade das Organizaes de Fbricas de Software neste poderoso contexto.
Processo de desenvolvimento de software

Ao se abordarem o conceito de processo de software, verificase que este configurado como um conjunto de atividades, tais como a anlise de requisitos, planejamento de produo, projeto, desenvolvimento dos cdigos, testes, manuteno, aquisies ou contrataes e demais providncias que levem produo de um software. O processo proposto como uma rotina que necessita de documentao que detalhe aspectos e artefatos como: especificao formal e precisa do produto a ser desenvolvido; os passos ou fases que sero executados, incluindo sua ordem, gesto de risco e precedncia; preparo e atribuies dos agentes que atuaro na produo; os insumos que sero utilizados e os resultados que se espera alcanar. Como casos tpicos de especificaes para processo de software, citamos os modelos Personal Software Process (PSP) e Team Software Process (TSP), ambos de autoria do Software Engineering Institute (www.sei.cmu.edu).
Contextualizao
As organizaes de fbrica de software so empreendimentos que tm expressiva demanda por informaes para a execuo de seus processos. O uso adequado da gesto do conhecimento e da informao pode ser revertido em vantagens competitivas para este tipo de organizao. Compreende-se a engenharia de software como uma disciplina que visa o desenvolvimento de software de computador, integrando processo, mtodos e ferramentas. Existem modelos de processo para que cada produtor implemente a melhor soluo em termos de um processo de produo real, eficaz e efetivo, porm todos definem um conjunto de atividades, uma coleo de tarefas que so conduzidas para realizar cada atividade, produtos de trabalho produzidos como conseqncia das tarefas a serem exigidos para o aceite ou complementao da tarefa, bem como um conjunto de atividades padres que se espalham por todo o processo. Neste contexto, o trabalhador do conhecimento, notadamente presente nas empresas de desenvolvimento de software, valoriza o conhecimentos e sua aplicao pelas organizaes como fator
Nota do DevMan
Externalizar o conhecimento: Nonaka e Takeuchi explicam no seu livro criao de conhecimento na empresa: como as empresas japonesas geram a dinmica da inovao , que a criao do conhecimento organizacional uma interao contnua e dinmica entre o conhecimento tcito e o conhecimento explcito.Tal interao moldada pelas mudanas entre diferentes modos de converso, que so a socializao, a externalizao, a internalizao e a combinao. Dentre os quatro modelos de converso do conhecimento, a externalizao a chave para a criao do conhecimento, pois elabora conceitos novos e explcitos a partir do conhecimento tcito.
39
H uma imensa diversidade de modelos para processos de software, no se considerando a existncia de um processo ideal para todos os produtores. Numa concepo atual da Engenharia de Software, disciplina que prioriza em seu estudo a criao, implantao e manuteno do processo de desenvolvimento de software, aplicam-se tais modelos para que o Engenheiro, conhecendo as demandas do produtor, adapte estas tcnicas para criar o modelo ideal a ser ali utilizado, de acordo com as especificidades de cada produtor. Diante de tal fato, pode-se afirmar que as organizaes desenvolveram abordagens diferentes para o processo de software. O desenvolvimento de software sofre mudanas rpidas. Este tipo de negcio se utiliza do conhecimento intensivo e envolve muitas pessoas trabalhando em diferentes fases ou atividades. So diversos os conhecimentos encontrados nas empresas desenvolvedoras, porm, existem problemas para identificar o contedo, localizao e o uso deste conhecimento. O uso apurado deste conhecimento uma motivao bsica para conduzir a gesto do conhecimento nas empresas desenvolvedoras, merecendo uma anlise profunda. No desenvolvimento de software, cada pessoa envolvida toma decises tcnicas ou administrativas, muitas delas pontuais ou eventuais, diante de situaes inditas. Membros do time de desenvolvimento tomam decises baseadas no conhecimento pessoal, experincias ou conhecimento obtido usando contatos informais. Isso possvel em empresas menores, com um potencial catico em empresas maiores, conduzindo a conflitos e imprecises nos trabalhos de produo do software. Porm, em empresas que lidam com um grande nmero de informaes, este processo torna-se ineficiente. Grandes organizaes no podem confiar na participao informal do conhecimento pessoal dos funcionrios, bem como em situaes temporrias em que estes funcionrios eventualmente atuem, refletindo-se tais situaes em improvisos, informalidades que no podem ser adotadas como comportamentos organizacionais padronizados. Tal situao frequentemente referenciada na literatura da Engenharia de Software ao afirmar que processos no estruturados dependem de atuaes salvadoras de gerentes e especialistas (bons programadores, analistas que dominem o contexto da aplicao, gerentes que conseguem improvisar com sucesso), eventos que no trazem em si garantia nenhuma que podero ser repetidos em novos projetos. O conhecimento individual, sobre tcnicas, processo, mtodos, infraestrutura, bases e gerenciamento, principalmente, precisa ser compartilhado. Desta forma, os processos de compartilhamento do conhecimento precisam ser perfeitamente definidos.
aprimoramento na oferta de produtos e servios que sejam diferenciados aos olhos dos consumidores. Destaca-se aqui tambm a diferenciao, e consequente vantagem, nas formas de oferta, como bons servios de comrcio eletrnico. Analisando o contexto do processo de desenvolvimento de software, da gesto do conhecimento e a construo da vantagem competitiva, pode-se afirmar que, no desenvolvimento de software, inmeros documentos so elaborados. Dessa forma, o conhecimento produzido deve ser retido e disponibilizado para o time de desenvolvimento, possibilitando o reuso em projetos futuros. Para tanto, o conhecimento individual necessita ser explicitamente capturado, oferecendo a oportunidade para o aprendizado de outros. A busca por posies estratgicas que combinem ou superem as existentes nas organizaes um grande desafio que as empresas enfrentam, e nortear a direo futura delas, tanto para o sucesso, quanto para o fracasso. A empresa um conjunto de recursos cuja utilizao organizada por um quadro de referncia administrativo, tornando os produtos finais da organizao representantes das possibilidades pelas quais se pode utilizar seu conjunto de recursos para desenvolver suas potencialidades bsicas. Definimos recursos como todos os ativos, processos organizacionais, atributos, informao, conhecimento, etc., controlados pelas organizaes, que as tornam capazes de conceber e implementar estratgias que melhorem sua eficincia e eficcia. As organizaes no podem ser consideradas idnticas, bem como os recursos reais so heterogneos (originais) e imveis (no so adquirveis). aqui que o software, como afirmamos antes, pode se constituir num diferenciador potencial, produzindo vantagem competitiva.
Tipos de conhecimento e a aplicao para produo de software

Dentre os conhecimentos tpicos que so encontrados num ambiente de desenvolvimento de software, podemos exemplificar: Os mtodos de clculos de estimativas de prazos e custos financeiros; Especificaes tcnicas de modelagem de programas, lgicas e relacionamentos entre mdulos; Mtodos de planejamento de atividades, de delegao de controle e tarefas durante a produo de software, como os de testes; Formulrios e artefatos variados, como definies de layout para repositrios de requisitos;
Vantagem Competitiva
Entende-se a vantagem competitiva como uma diferena positiva que um determinado competidor apresenta, em um segmento, sobre seus concorrentes, percebido pelos clientes daquele segmento. O software oferece inmeras situaes de potencial construo da vantagem competitiva, indo desde a melhora ou customizao do atendimento, passando pelo
Nota do DevMan
Processos organizacionais: procurando estruturar-se em processos, as organizaes tero maior eficincia na obteno de produtos e servios e estaro mais preparadas para mudanas, com melhor integrao de seus esforos e maior capacidade de aprendizado.
40
engenharia de soft ware
Melhores prticas de processos e projetos, a serem aplicadas sucessivamente na formulao de novos produtos. Algumas das reas do conhecimento e das necessidades relativas s organizaes so: Adquirir conhecimento sobre novas tecnologias: novas tecnologias podem ser bastante eficientes para o desenvolvimento de software, mas tornam-se pesadelos para os gerentes de projeto. difcil para os desenvolvedores ficarem aptos com as novas tecnologias e, para os gerentes, entenderem seus impactos e estimar os novos custos. Tecnologias no muito familiares fazem uso intensivo do aprender fazendo, que pode trazer retardo nos resultados; Conhecimento de acesso do domnio: o desenvolvimento de software necessita de acesso ao conhecimento no apenas do seu domnio e em novas tecnologias, mas tambm sobre o domnio para o qual o software est sendo desenvolvido; Compartilhamento do conhecimento das prticas e polticas locais: os conhecimentos so passados, entre desenvolvedores experientes e os com pouca experincia, em encontros informais; com isso, nem todos tm acesso. Esta prtica deve ser estimulada, mas a captura e compartilhamento formal do conhecimento asseguram que todos os funcionrios tero acesso a ele. As organizaes devem analisar os projetos do passado para melhorar as habilidades no desenvolvimento. Isto requer conhecimentos extensivos baseados nas mais diferentes experincias no desenvolvimento, bem como insights. Padres, melhores prticas, modelos e recomendaes so exemplos de resultados destas atividades do conhecimento.
Figura 1. Arquitetura da soluo Victor Basili adaptada pelos autores
A organizao Fbrica de Experincia (OFE)

O modelo desenvolvido denominado organizao fbrica de experincia, conforme mostrado na (Figura 1), possui duas organizaes perfeitamente integradas. Uma equipe especfica destinada finalidade de externalizar o conhecimento dos prprios desenvolvedores. Este processo tem como objetivo obter melhores resultados no desenvolvimento de software custos, qualidade e prazos por meio da alavancagem de experincias de projetos anteriores.
Nota do DevMan
Estratgia: No existe uma definio nica e universalmente aceita para estratgia. Inicialmente deu-se nfase especial ao uso militar do termo estratgia, originada das mais antigas literaturas do mundo. Strategos referia-se ao papel de um general no comando de um exrcito, passando posteriormente a ser a arte de habilidades psicolgicas e comportamentais com as quais exercia esse seu papel. Uma estratgia bem formulada ajuda a ordenar e alocar os recursos de uma organizao para uma postura singular e vivel. Diversos autores relacionam o conceito de estratgia em uma srie de pontos de vista, como plano, padro, posio e perspectiva.
Com cronogramas, expectativas quanto qualidade e produtividade e desafios tcnicos, muitos projetos no podem dedicar recursos suficientes para explicitar o conhecimento. Porm, isto fica por conta da equipe chamada fbrica de experincia. Esta equipe est encarregada de analisar e sintetizar todos os tipos de experincia, incluindo as lies aprendidas, dados de projetos e relatrios que explicitam estas experincias mediante a criao de repositrios. A OFE agrega valor ao conhecimento, mediante a criao de modelos baseados em documentos ou em indivduos. Externalizao e internalizao so integradas, de modo que a equipe do projeto trabalhe em harmonia com a OFE. Implantar o conceito de OFE requer mudanas culturais nas organizaes, devido criao de equipes e processos distintos de trabalho. O que mais essencial na OFE no a experincia, mas os novos conhecimentos gerados a partir da experincia. As OFE precisam empacotar a experincia, por meio da anlise, sntese e avaliao da experincia bruta, e construir modelos que representam a abstrao dessas experincias. A aprendizagem organizacional o know-how incorporado, resultante da capacidade de absoro, bem como da receptividade da empresa a uma nova tecnologia. Cada organizao tem sua capacidade e habilidade de aprender a partir de outras organizaes. A capacidade em absorver o conhecimento vem da habilidade em reconhecer os valores novos, externos, e assimilar e aplicar em fins comerciais. Quanto mais a organizao conhece sua tecnologia, mais fcil torna-se o aprendizado.
A Gesto do Conhecimento na Engenharia de Software

As organizaes podem aplicar a gesto do conhecimento para fornecer solues nos seus negcios. Para evitar erros e retrabalho, para diminuir tempo e custos de desenvolvimento e aumentar a qualidade, as empresas desenvolvedoras
41
necessitam aplicar, nos futuros projetos, o conhecimento obtido em projetos anteriores. Infelizmente, a realidade que o time de desenvolvimento no se beneficia das experincias anteriores e repete os mesmos erros cometidos, embora alguns desenvolvedores saibam como evit-los. O ganho individual e da organizao poderia ser maior se o conhecimento fosse compartilhado. As atividades da gesto do conhecimento que suportam o desenvolvimento de software so: Gesto de documentos: muitos documentos, processos e atividades so envolvidos na engenharia de software. Estes documentos so freqentemente criados, revisados e utilizados. Existem diversas ferramentas para a gesto de documentos; Gesto de competncia: ou gesto de habilidades; quem sabe o qu uso do conhecimento no documentado; Reuso de software: programadores no se cansam de implementar a mesma soluo; o reuso para evitar o retrabalho; incentivo ao repositrio de reuso. Somente ser desenvolvido algo novo caso no se encontre nada para reusar; Aprender com experincias necessita de um suporte memria do produto e do projeto. As prticas da engenharia de software que ajudam a construir memrias so: controle de verso, gesto de modificaes, documentao de padres e rastreabilidade de requisitos. Em todas estas prticas, a reteno do conhecimento altamente indicada.
determinaram seus objetivos e estratgias antes de implementar sistemas de gesto do conhecimento, no tendo uma boa preparao do mtodo ou processo da gesto do conhecimento. necessrio despender um tempo antes de os benefcios da gesto do conhecimento aparecerem. Algumas culturas organizacionais incentivam o individualismo e limitam o trabalho cooperativo. A falta de uma cultura do conhecimento tem sido citada como um obstculo para o sucesso da gesto do conhecimento. Se a organizao no incentiva a cultura de compartilhamento, o funcionrio se sente dono do seu conhecimento. Os funcionrios no se sentem vontade com as suas experincias negativas e lies aprendidas por falhas, temendo que as informaes fornecidas possam ser usadas contra eles.
Concluso
As organizaes no devem apenas encorajar os funcionrios, mas recompens-los por compartilhar seus conhecimentos, procurar por conhecimentos e us-los. A vantagem da experincia ou do conhecimento explcito que pode ser armazenado, organizado e disseminado para terceiros, sem o envolvimento de quem o originou. Para alcanar vantagem mxima do compartilhamento, as empresas deveriam encorajar os funcionrios a documentar e armazenar seus conhecimentos em um repositrio. As comunidades so bons exemplos de compartilhamento de conhecimento. Elas se formam de modo relativamente fcil. As organizaes se esforam para aprender e aumentar suas expertises mediante as entradas vindas de fora da organizao. Projetos em empresas de desenvolvimento de software cujo objetivo construir uma base de conhecimento incluem um centro para estas bases, assim como o acmulo de modelos empricos para serem utilizados na validao de novos projetos. A maioria do conhecimento das empresas de software no explcito. O tempo curto para tornar o conhecimento explcito, e existem poucas ferramentas para transformar o conhecimento tcito em explcito. Porm, os artefatos do desenvolvimento de software se encontram em formato eletrnico, possibilitando o uso de ferramentas de TI para a reteno, e facilitando o compartilhamento e a disseminao.
Links Artigo A Reference Architecture for the Component Factory http://www.lib.umd.edu/drum/bitstream/1903/7521/1/A%20Reference%20Architecture.pdf Artigo Knowledge Management in Software Engineering http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1003450
Implementando a gesto do conhecimento na Engenharia de Software

Para implementar a gesto do conhecimento na engenharia de software, muitos desafios e obstculos esto presentes. Trs questes so particularmente importantes: Questo tecnolgica: A tecnologia de software suporta a gesto do conhecimento? possvel integrar todas as ferramentas para alcanar o nvel planejado de compartilhamento? Questo organizacional: um erro focar somente na tecnologia e esquecer a metodologia. um risco cair na cilada tecnolgica sem um planejamento adequado para a implementao da gesto do conhecimento; Assuntos individuais: Funcionrios frequentemente no tm tempo de entrar ou procurar por conhecimento, ou no desejam disponibilizar seus conhecimentos. E no querem reusar conhecimentos dos outros. Uma anlise das caractersticas da gesto do conhecimento revela que muitas organizaes que falharam no
42
edio ta
Insights: Uma viso que se manifesta de repente, como a compreenso de como resolver um problema difcil. O termo foi cunhado pelo psiclogo alemo e terico linguista Karl Bhler.
D s
Nota do DevMan
Feedback eu
sobre e s

Customizao e Integrao de Ferramentas Open-Source

Uso de ferramentas integradas para melhoria de processo e aumento de produtividade
Andrea Pinto
andrea.pinto@cesar.org.br
Felipe Furtado
felipe.furtado@cesar.org.br

Este artigo relata a experincia de uma Organizao CMMI (Capability Maturity Model Integration), nvel 3, na customizao e integrao de ferramentas opensource para melhoria de processo e aumento da produtividade das equipes de desenvolvimento de software.
graduada em Cincia da Computao pela UFPE e mestra em Cincias da Computao pela UFPE na rea de Engenharia de Requisitos. Com 9 anos de experincia na rea de desenvolvimento de software, atualmente Engenheira de Qualidade de software do C.E.S.A.R. Possui experincia na definio e implantao de processos de garantia da qualidade aderentes ao CMMI e em avaliao SCAMPI, tendo participado da avaliao Classe A CMMI 3 do C.E.S.A.R. Ministra aulas de Garantia da Qualidade de Software na faculdade Unibratec e orienta alunos em monografias para essa rea.Tem interesse principalmente nas reas de garantia de qualidade, modelos de qualidade, requisitos e metodologias geis.
graduado em Engenharia Mecnica pela UFPE, especialista em Tecnologias da Informao pelo Centro de Informtica da UFPE e mestre em Cincia da Computao na rea de produtividade de software tambm pela UFPE. Com 13 anos na rea de desenvolvimento de software, atualmente coordenador da garantia da qualidade de software e do SEPG (Software Engineering Process Group), liderando tambm a melhoria dos processos das reas de gesto de projetos no C.E.S.A.R.
Para que serve?

A utilizao de ferramentas desta natureza til para as Organizaes que possuem um ambiente de melhoria dos processos de software e tem a necessidade de adotar ferramentas de baixo custo e de forma integrada. Tais ferramentas daro suporte ao processo institucional com uma maior agilidade pelas equipes de desenvolvimento de software.
Ryan Albuquerque
ryan@cesar.org.br
Gustavo Carvalho
gustavo.carvalho@cesar.org.br
graduado em Cincia da Computao pelo UNIPE e especialista em Engenharia de Software pela FBV/Qualiti. Com 8 anos de experincia na rea de desenvolvimento de software, atualmente Engenheiro de Configurao do C.E.S.A.R, alm de ministrar aulas de Programao Orientada a Objetos, Estrutura de Dados e Teoria Geral dos Sistemas na Faculdade Joaquim Nabuco. Possui experincia em desenvolvimento de software, elicitao de requisitos e na definio e implantao de processos de gerncia de configurao aderentes ao CMMI.
graduado em Cincia da Computao pela UFC e mestre em Cincias da Computao pela UFPE na rea de Inteligncia Artificial. Com 10 anos de experincia na rea de desenvolvimento de software, 7 deles como Engenheiro de Configurao de Software. Atualmente Engenheiro de Sistemas do C.E.S.A.R. Possui experincia na definio e implantao de processos de Gerncia de Configurao aderentes ao CMMI e em avaliao SCAMPI, tendo participado da avaliao Classe A CMMI 2 e 3 do C.E.S.A.R.

Em ambientes que necessitam integrar ferramentas de apoio ao processo organizacional de forma produtiva e consistente. Especificamente em processos relacionados com gerenciamento de mudanas, gerenciamento de testes, gerenciamento de requisitos e reviso de artefatos (cdigo ou documentos).
s organizaes de desenvolvimento de software tm buscado diversas formas para melhoria de seus processos com o objetivo de aumentar a produtividade das equipes de desenvolvimento. Uma forma de obter
ganhos significativos de produtividade requer iniciativas integradas em diversas reas, por exemplo, melhoria em ferramentas, metodologia, ambiente de
43
trabalho, gerenciamento, reuso, dentre outros fatores [Bohem et AL, 1982]. Por outro lado, a incluso de ferramentas em um projeto nem sempre est associada a ganho de produtividade. Isso ir depender, dentre outros fatores, do tamanho da equipe e da maturidade do processo de desenvolvimento [Bruckhaus et AL, 1996]. Neste contexto, a Organizao aqui apresentada estabeleceu dois principais objetivos em seu programa de melhoria contnua: Seleo de ferramentas free e open source que propiciem aumento da produtividade das equipes de desenvolvimento de software de forma controlada, gerenciada e com baixo custo; Customizao das ferramentas selecionadas considerando o processo definido na organizao com o objetivo de aumentar a maturidade do processo de desenvolvimento de software, obter ganhos na produtividade das equipes e na qualidade dos produtos gerados.
A Organizao Estudada
O C.E.S.A.R Centro de Estudos e Sistemas Avanados do Recife um instituto privado de inovao que cria produtos, processos, servios e empresas usando Tecnologia da Informao e Comunicao (TIC), atuando h mais de 10 anos em mbito nacional e internacional. O C.E.S.A.R faz parte do Porto Digital, ambiente de empreendedorismo, inovao e negcios de TIC do estado de Pernambuco que rene mais de 100 empresas no plo do Bairro do Recife. Desde sua inaugurao, a instituio recebeu reconhecimentos na rea de TIC, entre eles: o Prmio Info200 de Melhor empresa de servios de software, o prmio FINEP de mais inovadora instituio de pesquisa do Brasil, a escolha da instituio como exemplo de criao de negcios pelo World Economic Frum e uma meno honrosa no Stockholm Challenge. Alm do prmio que a Revista poca Negcios concedeu ao C.E.S.A.R com o ttulo de um dos Modelos de Negcios mais Inovadores do Brasil, em 2009. Em junho/2003, o C.E.S.A.R alcanou o nvel 2 de maturidade do modelo SW-CMM [Paulk et AL 1999] na vertical de telecomunicaes, e em Novembro/2007 atingiu o nvel 3 de maturidade do modelo CMMI-DEV, verso 1.2 [SEI 2006]. Atualmente, utiliza metodologias geis em conjunto com o modelo de maturidade.
Em seguida, foi realizada uma pesquisa e anlise de ferramentas disponveis no mercado levando em considerao as necessidades anteriormente identificadas em cada um dos processos selecionados. Como resultado desta pesquisa, um processo de tomada de deciso foi realizado para identificar quais ferramentas seriam adquiridas e adaptadas realidade da organizao. Os principais requisitos estavam relacionados com o baixo custo necessrio para aquisio e com a possibilidade de customizao e integrao das ferramentas para que elas, de fato, se adaptassem ao processo organizacional. Portanto, foi dada preferncia na seleo de ferramentas open source e as escolhidas foram: Mantis e Salom. Originalmente, o Mantis foi concebido como uma ferramenta para bug tracking. Porm, pela sua flexibilidade e facilidade de customizao, tambm foi utilizada para gerenciamento de mudanas, gerenciamento de requisitos e reviso de artefatos. A Salom, por sua vez, foi concebida como uma ferramenta de gerenciamento de testes e foi customizada para atender ao processo de gerenciamento de testes da organizao estudada. A seguir, ser brevemente descrito cada uma das ferramentas utilizadas.
Mantis Bug Tracker Gerenciamento de Mudanas

O Mantis uma ferramenta de gerenciamento de bugs baseado na web. um dos mais populares sistemas de bug tracker do mundo, sendo open-source, sob os termos da GNU General Public License (GPL), estando livre para ser usado e modificado. O Mantis desenvolvido em PHP, com suporte a banco de dados, incluindo o MySQL, MS SQL, PostgreSQL e DB2, podendo rodar em qualquer sistema operacional que seja suportado pelo PHP. Ele foi projetado para ser facilmente modificvel, personalizvel e atualizvel. Esse foi um dos motivos que pesou na escolha da ferramenta de gerenciamento de mudanas. As customizaes no Mantis comearam a surgir a partir da necessidade de padronizao na abertura das CRs (Change Requests) ou Requisies de Mudana. O formulrio das CRs possui vrios campos, mas em alguns deles no era clara a forma de preenchimento. Em especial os campos descritivos (e.g. descrio da requisio de mudana e passos para reproduo) poderiam ser escritos com texto livre, fazendo assim com que a falta de informaes importantes ou falhas de interpretao acontecessem com certa freqncia. Para minimizar esse tipo de situao, foi criado um modelo em XML que descrevia de forma mais estruturada as informaes importantes de cada campo. Foi dada uma opo para o relator da CR incluir o modelo no campo a ser editado e o mesmo poderia preencher as informaes nos campos delimitados pelas tags XML. A utilizao desse modelo ajudou tambm na formatao das informaes e no processo de automao de checagens em auditorias, pois as informaes estavam mais estruturadas, e no mais em texto livre. No processo interno, as CRs poderiam ser de diversos tipos: Defeitos de Cdigo, Defeitos de Documento, Mudanas, Tarefas, Requisies de Baseline e Requisies de Release, e,
Processo de Seleo das Ferramentas

A estratgia de seleo das ferramentas iniciou com um levantamento dos requisitos necessrios levando em considerao as necessidades do processo e projetos da organizao. Nesta primeira etapa, o grupo envolvido analisou os processos que estavam diretamente relacionados com a equipe de engenharia de software e que demandavam um esforo significativo em passos que poderiam ser automatizados e/ou integrados. Como resultado desta anlise, quatro processos foram selecionados: Gerenciamento de Requisitos, Gerenciamento de Mudanas, Gerenciamento de Testes e Reviso de Artefatos.
44
Engenharia de Software Magazine - Customizao e Integrao de Ferramentas Open-Source
processo
para cada tipo, os campos obrigatrios relativos ao processo eram diferentes, o que acarretava em um enorme tempo consumido para o Engenheiro de Configurao verificar cada CR. Neste sentido, o cdigo fonte do Mantis foi alterado para que a visualizao e obrigatoriedade de alguns campos fossem dependentes do valor de um campo novo chamado Tipo, que listava os tipos de requisies possveis no processo da organizao. Alm disso, a mquina de estados padro tambm foi reformulada para se adaptar a esse novo contexto, como ilustrado na Figura 1.
Figura 1. Mquina de Estados do Mantis
A integrao dos sistemas de controle de verso (CVS e Subversion) com o Mantis tem sido de enorme utilizao por parte dos projetos. Atravs dela, todos os comentrios dos commits realizados via CVS/Subversion so registrados automaticamente na respectiva CR que est sendo resolvida. Com a integrao, consegue-se garantir um rastreamento bidirecional entre CRs e artefatos: Identificao a partir do Mantis de todos os artefatos (seus branches, revises e responsveis) alterados para resolver cada requisio de mudana; Identificao a partir dos comentrios dos commits de todas as CRs que ocasionaram as mudanas. Ainda foram implementadas integraes do Mantis com os outros sistemas descritos neste documento: Rev.I.S.E e ITReq. A partir da tela de visualizao de cada CR possvel acessar suas respectivas revises e requisitos impactados pela mudana.
repositrio dos projetos. Para que os membros da equipe seguissem o processo definido de reviso formal utilizando planilhas fazia-se necessrio realizar um conjunto de atividades meramente operacionais como: recuperar o ltimo template da planilha no site do processo organizacional, renomear o arquivo de acordo com as regras de gerncia de configurao para o projeto, preencher a planilha com os dados da reviso e incluir a planilha no repositrio. Havia tambm uma grande dificuldade de se auditar o processo de reviso, visto que se fazia necessrio abrir cada planilha para checagem das informaes. Tudo isso tornava a execuo do processo de reviso custoso para a equipe, para o projeto e para a empresa devido ao esforo envolvido. O processo era ainda propcio a erros em cada um dos passos descritos, visto que todos eles eram realizados manualmente. Inicialmente, para resolver o problema de forma mais rpida, pensou-se numa soluo para coleta de informaes das prprias planilhas automaticamente. Uma aplicao consultava determinadas clulas das planilhas, gerava uma pgina web consolidando as informaes e realizava a maioria das checagens de consistncias. Mas, essa soluo tinha a desvantagem de se basear num modelo fixo de planilha. Toda vez que o modelo mudava, a aplicao teria que ser adaptada. Devido a essas dificuldades, o SEPG (Software Engineering Process Group) props o uso de uma ferramenta web que automatizasse todas essas atividades, agilizando a criao, o preenchimento e o acesso aos dados entre os participantes do processo de reviso formal. Foram feitas pesquisas, mas nenhuma soluo gratuita foi encontrada para suprir as necessidades da organizao e, por isso, resolveu-se construir uma ferramenta. Em uma anlise prvia dos requisitos bsicos e imediatos para a ferramenta, foi identificado que o Mantis, ferramenta para gerenciamento de mudanas j largamente utilizado na organizao, supriria a maioria deles: suporte de projetos, controle de acesso de usurios, mquina de estados e campos customizveis. Assim, decidiu-se utilizar o Mantis como base
Nota do DevMan
CMMI (Capability Maturity Model Integration): um framework que descreve princpios e prticas relacionadas ao processo de desenvolvimento de produtos e servios tecnolgicos. O modelo visa ajudar organizaes envolvidas com o desenvolvimento de software a melhorar a capacidade de seus processos por meio de um caminho evolucionrio, com resultados mais previsveis e com possibilidade de melhoria contnua. [SEI, 2006]. CR (Change Request): Solicitaes de Mudana em um artefato. CVS (Concurrent Version System) e SVN (SubVersion): so sistemas de controle de verso que permitem que se trabalhe com diversas verses de arquivos organizados em um diretrio e localizados local ou remotamente, mantendo-se suas verses antigas e os logs de quem e quando manipulou os arquivos.
Rev.I.S.E Revision Infrastructure for Software Engineering

A ferramenta Rev.I.S.E foi idealizada, principalmente, para substituir as planilhas de reviso contendo as informaes das revises formais realizadas e que eram armazenadas no
45
para todo o desenvolvimento, batizando a nova ferramenta de Rev.I.S.E. Durante o desenvolvimento houve a preocupao de disponibilizar um ambiente amigvel e fcil de usar para incluso das no-conformidades e os dados das revises. Assim, decidiu-se usar algum framework com componentes Ajax/DHTML para que os dados fossem postados facilmente com edies inline de tabelas. Neste intuito, escolheu-se o framework Ext.JS. A mquina de estados do Rev.I.S.E tambm foi reformulada de acordo com a Figura 2.
Verificao de mtricas de tempo planejado versus o realizado.

Papel Autor Responsabilidades Criar e/ou atualizar o artefato a ser revisado; Planejar a reviso; Definir os papis e responsabilidades da equipe de reviso; Agendar a reunio de reviso; Realizar o retrabalho aps a reviso, garantindo que todos os pontos levantados tenham sido corretamente analisados e resolvidos. Determinar quando a reviso estar completa e indicar, caso necessrio, uma nova reviso; Analisar se o retrabalho foi realizado conforme descrito no Rev.I.S.E; Realizar o fechamento da reviso. Cadastrar os findings na ferramenta. Revisar os artefatos. Apresentar o artefato aos participantes ao longo da reunio. Obs: o papel do Leitor s existe para tcnicas que realizam reunio de reviso.
Moderador
Redator Revisor Leitor
Tabela 1. Papis e Responsabilidades
ITReq - Infrastructure to Track Requirements

A ferramenta para Desenvolvimento e Gerenciamento de Requisitos (ITReq) trata-se de uma customizao da ferramenta de Gerncia de Mudanas, o Mantis. O layout de algumas funcionalidades idntico ferramenta original, como o mecanismo de busca e a viso inicial dos requisitos, organizada pelo estado no qual o requisito se encontra. O requisito criado no ITReq da mesma forma que uma CR registrada no Mantis. Para isto, os campos relacionados a um requisito tiveram seus nomes reeditados para se adequar aos termos normalmente utilizados no gerenciamento de requisitos. A mquina de estados tambm foi adaptada de acordo com a Figura 3. Cada requisito cadastrado no ITReq identificado unicamente e tratado de forma independente dos demais requisitos, com suas prioridades e estados. Alm do identificador nico, cada requisito possui Nome, Descrio, Tipo (requisito funcional, requisito no funcional, caso de uso ou restrio) e Prioridade. O campo Descrio livre, sendo possvel ser utilizado para descrever um requisito funcional
Figura 2. Mquina de estados do Rev.I.S.E
Dependendo do papel na reviso do usurio autenticado no sistema, e do estado da reviso, alguns campos so habilitados ou desabilitados, conforme as responsabilidades descritas na Tabela 1. Algumas automaes foram feitas na ferramenta para que os esforos com as checagens em auditorias pudessem ser diminudos, entre elas: Checagem das transies de estados especficas por papel; Verificao da consistncia dos papis por tipo de reviso; Verificao e validao de campos obrigatrios; Envio automtico do convite por e-mail aos envolvidos na reviso; Integrao com a ferramenta de controle de mudanas (Mantis); Seleo automtica do checklist de auditorias definido no processo da organizao; Acompanhamento do estado da reviso por e-mail;
Nota do DevMan
Ext.JS: um framework javascript com uma extenso rica em funcionalidades e componentes de interface grfica com o usurio. Findings: So os erros, problemas, lapsos, oportunidades de melhoria ou pontos de investigao identificados durante o processo de reviso de artefatos. GNU GPL (General Public License): a designao da licena para software livre idealizada por Richard Stallman no final da dcada de 1980, no mbito do projeto GNU da Free Software Foundation (FSF). A GPL a licena com maior utilizao por parte de projetos de software livre.
46
processo
de forma textual, ou um caso de uso com pr-condio, atores, passos e ps-condies.
Nota do DevMan
PHP (PHP: Hypertext Preprocessor): uma linguagem de programao interpretada, livre e muito utilizada para gerar contedo dinmico na Web. SEPG (Software Engineering Process Group): grupo estabelecido e designado como responsvel pela definio, manuteno e melhoria do processo de engenharia de software [SEI 2006]. executado. Para cada ciclo, o usurio seleciona as sutes de testes (conjunto de casos de testes) que sero executados e reporta o resultado da execuo (Figura 5).
Figura 3. Mquina de Estados do ITReq
A mquina de estados do ITReq (Figura 3) est diretamente relacionada ao processo de reviso e aprovao definido na organizao. O tratamento individual de requisitos atravs da mquina de estados trouxe tambm um ganho no planejado para os projetos: maior agilidade no processo de reviso de requisitos, visto que os requisitos podem ser revisados individualmente, o que no poderia ser feito facilmente com o uso de documentos. Outra funcionalidade essencial o controle das alteraes de documentos com o uso de um histrico de revises e com o armazenamento, tornando possvel a comparao com outras verses de documentos (Figura 4). A ferramenta gera o documento de requisitos em formato HTML seguindo o template definido no processo organizacional com sees para descrio do projeto, aprovadores, glossrio, histrico de revises, referncias e requisitos agrupados em sees definidas pelo usurio.
Figura 4. Ferramenta ITReq: armazenamento das verses, histrico de verses e os requisitos relacionados
Salom Gerenciamento de Testes

Diferentemente das ferramentas descritas at agora, Salom TMF (Test Management Framework) uma ferramenta independente, isto , no foi construda a partir do Mantis. uma ferramenta open-source que foi melhorada e adaptada ao processo de testes organizacional, bem como, integrada ferramenta ITReq anteriormente descrita. Nela pode-se especificar os casos de testes para cada requisito cadastrado no ITReq, bem como registrar os resultados da execuo dos casos de testes para cada ciclo de testes
Figura 5. Ferramenta Salom
47
Salom-TMF tambm compatvel com JUnit, Abbot e Beanshell, sendo possvel a definio de testes automticos.
Integrao entre as Ferramentas

Todas as ferramentas descritas possuem alguma integrao entre si. ITReq est integrada com Salom, sendo possvel acessar os casos de testes de cada requisito a partir dessa ferramenta, como mostra a Figura 6. O Mantis possui integraes com o Rev.I.S.E, ITReq e Salom. A partir de uma CR de melhoria criada no Mantis, por exemplo, pode-se acessar as revises realizadas no projeto para aquela melhoria (Figura 7) e vice-versa (Figura 8) e os requisitos impactados por ela (Figura 9). Desta forma, ao criar uma baseline no Mantis com suas respectivas CRs, possvel visualizar todos os requisitos impactados e os respectivos casos de testes, facilitando a identificao dos casos de testes que devem ser executados devido melhoria implementada no projeto.
Implementao e testes dos requisitos de cada uma das ferramentas; Planejamento de quais projetos em execuo na organizao iriam adotar e avaliar as ferramentas; Execuo dos projetos piloto com o apoio do SEPG (Software Engineering Process Group) e Engenheiros de Qualidade e Configurao alocados ao projeto; Coleta de resultados e de sugesto de melhorias nas ferramentas aps finalizao do perodo do piloto. Aps a execuo do projeto piloto, o primeiro passo foi o envolvimento do SEPG na seleo e priorizao das melhorias que haviam sido propostas. Este grupo, formado por especialistas em cada uma das reas impactadas pelas ferramentas, analisou e priorizou as melhorias solicitadas para dar incio implementao das mudanas. O grupo tambm precisou realizar um planejamento do uso institucionalizado das ferramentas, isto , como colocar as ferramentas em uso em novos projetos. Essa ao inclua tambm as alteraes a serem realizadas no processo organizacional, como elaborao de guias e treinamentos para uso das ferramentas customizadas e integradas. Alm das mudanas no processo, o SEPG passou a atuar como facilitador na utilizao das ferramentas pelos demais projetos da organizao.
Projeto Piloto e Institucionalizao das Ferramentas

Aps a concluso do processo de seleo das ferramentas, foi dado incio ao planejamento do projeto piloto para a customizao e testes das ferramentas selecionadas. As seguintes fases podem ser destacadas: Planejamento e alocao dos recursos necessrios para implementao das melhorias e customizaes com o suporte organizacional;
Concluses e Resultados Obtidos

A produtividade dos projetos aumentou notavelmente com as customizaes e integraes de todas as ferramentas supracitadas. possvel ter uma maior rastreabilidade entre as mudanas, um melhor controle do processo, alm de agilidade na hora da criao e manuteno das requisies de mudana, requisitos do produto e revises de artefatos. Para se ter uma idia da grande aceitao dessas ferramentas na organizao, faz-se necessrio destacar alguns nmeros: Mantis: em uso por mais de 40 projetos; ITReq: em uso por mais de 20 projetos; Rev.I.S.E: em uso por 19 projetos, onde j foram realizados mais de 2 mil revises em cdigo e documentos; Salom: em uso por quatro projetos. Antes de utilizar as ferramentas, os membros das equipes passam por um treinamento organizacional para que consigam utilizar melhor os recursos oferecidos por elas, aumentando ainda mais sua produtividade. As ferramentas esto em constante melhoria. As solicitaes de melhoria podem ser realizadas por qualquer pessoa dentro da organizao atravs do prprio Mantis, onde h um projeto especfico para cada ferramenta para reportagem de sugestes de melhoria, bem como de defeitos encontrados. Em relao aos ganhos deste processo de tomada de deciso e do uso das ferramentas, pode-se destacar os seguintes aspectos:
Figura 6. Ferramenta ITReq integrada com a Salom
Figura 7. Integrao do Mantis com o Rev.I.S.E
48
processo
Figura 8. Integrao do Rev.I.S.E com o Mantis
Figura 9. Integrao com o ITReq a partir do Mantis
Quanto ao impacto, houve uma disseminao do uso de ferramentas open-source para melhoria de produtividade das equipes de desenvolvimento; Quanto ao investimento, nota-se o baixo custo do projeto que se restringiu ao esforo de alterao e manuteno nas ferramentas, visto que se tratam de ferramentas open-source; Quanto inovao, apesar do uso de ferramentas open-source em projetos de desenvolvimento de software j ser algo conhecido pela comunidade, foi possvel, a partir de uma ferramenta j institucionalizada na organizao, realizar customizaes para atender outros processos relacionados, integrando-os e automatizando seus passos. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Feedback eu
sobre e s
Referncias Mantis (2009) Ferramenta Mantis Bug Tracker , http://www.mantisbt.org/ Salom (2009) Ferramenta para Gerenciamento de Testes , https://wiki.ow2.org/salome-tmf/ Boehm,B et AL (1982).The TRW Software Productivity System .International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA. p. 148-156. Bruckhaus, T. et AL (1996).The Impact of Tools on Software Productivity . IEEE Software v. 13, n 5. p. 29-38. SEI (2006). CMMI for Development, version 1.2, staged representation . http://www.sei.cmu.edu/ pub/documents/06.reports/pdf/06tr008.pdf, CMU/SEI-2006-TR-008 Paulk et al (1999) The Capability Maturity Model: Guidelines for Improving the Software Process , Addison-Wesley.
D s
edio ta
49

Mtricas de Software
Como utiliz-las no gerenciamento de projetos de software
O artigo trata da utilizao de mtricas de software no gerenciamento de projetos, sendo fortes aliadas na estimativa, acompanhamento e apoio em tomada de decises durante a construo de produtos de software, visando uma melhor qualidade de todo este processo.
Thamine Chaves de Abreu

thamine.abreu@gmail.com

maraujo@acessa.com
Atualmente cursa especializao em Desenvolvimento de Aplicaes para Web no Centro de Ensino Superior de Juiz de Fora (CES/JF), Bacharel em Sistemas de Informao pela Universidade Severino Sombra (USS), Desenvolvedor de Sistemas Web na Granbery Consultoria Jnior em projeto para a Fundao COPPETEC, possui experincia de 4 anos em desenvolvimento de sistemas Java (web/desktop).
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor dos cursos de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora e Editor da Engenharia de Software Magazine.
Para que serve?

Mtricas de software servem para apresentar medidas, preferencialmente quantitativas, que reflitam caractersticas especficas de processos e de produtos em construo, podendo ser utilizadas em diferentes dimenses, como esforo, tamanho, complexidade, dentre outras.
Leonardo da Silva Mota

leonardo.smota@hotmail.com
Atualmente cursa especializao em Desenvolvimento de Aplicaes para Web no Centro de Ensino Superior de Juiz de Fora (CES/JF), Bacharel em Sistemas de Informao pela Universidade Severino Sombra (USS), Desenvolvedor de Sistemas Web na Granbery Consultoria Jnior em projeto para a Fundao COPPETEC, programador certificado Java (SCJP), atuou como professor assistente no curso de Sistemas de Informao da USS e dos cursos de informtica da Fundao de Apoio a Escola Tcnica (FAETEC), possui experincia de 4 anos em desenvolvimento de sistemas Java (web/desktop).

A coleta adequada de mtricas, com suas respectivas anlises, pode auxiliar o Engenheiro de Software na tomada de decises ao longo do desenvolvimento de um projeto, visando a melhoria da qualidade do processo e do produto em construo.
garantia da qualidade uma das principais preocupaes da indstria de desenvolvimento de software, pois atualmente a maior parte das empresas atuantes no mercado utiliza esse tipo de aplicao para gerir seus negcios, produtos e relacionamentos com clientes, necessitando maior confiabilidade e qualidade. Existem diversas medidas de garantia de qualidade fundamentais para o sucesso de qualquer tipo de aplicao de software,
dentre elas, uma das mais simples e menos custosa, a medio de software. Nesse sentido, a medio de software auxilia a tomada de deciso, pois atravs
50
Engenharia de Software Magazine - Mtricas de Software
Gerncia de Projetos
de dados quantitativos, capaz de informar que aspectos do produto atendem ou no ao padro de qualidade especificado, alm de permitir a avaliao dos benefcios de novos mtodos e ferramentas de engenharia de software, o entendimento e aperfeioamento do processo de produo, a avaliao do retorno do investimento e tornar o gerenciamento de projetos baseado em fatos e no achismos, por exemplo. Para medir software, so utilizadas diversas mtricas que so como tipos de medies aplicadas a um sistema de software, documentao ou processo relacionado. Atravs dessas mtricas possvel determinar o esforo ou tempo para realizao de uma tarefa ou o tamanho do produto, por exemplo. Alm disso, as mtricas de software so facilmente calculadas, entendidas e testadas e independem do observador que as aplica, sendo tambm uma boa fonte para estudos estatsticos acerca do ciclo de vida do software. Dentro desse contexto, este artigo tem por objetivo apresentar algumas mtricas de software e sua importncia no processo de desenvolvimento. Para isso, algumas mtricas sero aplicadas em pequenos exemplos, permitindo ao leitor compreender e analisar seus benefcios imediatos.
GQM (Goal/Question/Metric), desenvolvido por Basili em 1988, uma abordagem para aplicao de mtricas afim de aprimorar o processo de desenvolvimento de software (e, consequentemente, os produtos de software gerados) enquanto mantm os objetivos de negcio e objetivos tcnicos da organizao nivelados. uma abordagem top-down que estabelece uma medio sistemtica para objetivos relacionados ao processo de desenvolvimento, em que a equipe comea estabelecendo os objetivos organizacionais, define metas de medio, insere questes com o propsito de abordar os objetivos especificados e identifica as mtricas que fornecem respostas para as questes definidas. O GQM define um modelo de trs nveis, ilustrado na Figura 1.
Utilizao de mtricas
Existem dois tipos de mtricas no contexto de desenvolvimento de produtos de software: as mtricas diretas, que so realizadas em termos de atributos observveis, como por exemplo, esforo, tamanho e custo, e as mtricas indiretas ou derivadas, que podem ser obtidas atravs de outras mtricas, como por exemplo, complexidade, confiabilidade, e facilidade de manuteno. Quanto ao contexto, podem ser aplicadas em produtos ou em processos. Quando as mtricas incidem diretamente no produto de software, so chamadas de mtricas de predio, quando em processos de software, so comumente chamadas de mtricas de controle e sua aplicao normalmente realizada em processos j maduros e controlados. Para obter resultados significativos, as mtricas devem ser aplicadas em um ciclo constante, que envolve as etapas de planejamento, medio, anlise de resultados, tomada de deciso e implementao das decises. Desta maneira, pode-se construir uma base histrica do artefato medido que permitir ao engenheiro de software analisar que processos, ferramentas e mtodos melhor se aplicam quele tipo de produto. Alguns cuidados tambm devem ser tomados no processo de medio, como o momento e a escolha do conjunto de mtricas mais relevantes a serem aplicadas, e a comparao entre produtos atravs da aplicao de mtricas (pois nenhum produto igual a outro). O escopo, os desenvolvedores e o ambiente so fatores que podem influenciar o processo de desenvolvimento. Assim, comparaes devem ser cuidadosamente analisadas. As mtricas podem e devem ser aplicadas durante as fases de desenvolvimento do software, o que garante ainda mais seu impacto positivo no produto final. Segundo alguns especialistas, para medir artefatos de software atravs de mtricas significativas, as medies devem ser definidas de acordo com objetivos especficos. Nesse sentido, o
Figura 1. Nveis do modelo do GQM
O GQM pode ser aplicado em todo o ciclo de vida de produtos, processos e artefatos de software e bem alinhado com o ambiente organizacional, sendo um meio adequado para conseguir dados confiveis e conhecimento sobre as prticas de software da organizao para conduzir a melhoria do processo. Nesse contexto, til para auxiliar na compreenso e formar um baseline das prticas aplicadas no desenvolvimento de software, evoluir as atividades de medio, guiar e monitorar processos de software e reduzir custos de desenvolvimento, por exemplo. O GQM pode ser utilizado tambm como base de fundamentao para outras tcnicas de medio de software. O GQM pode ser muito til na definio de quais mtricas so necessrias de serem coletadas e analisadas para responder questes sobre um determinado objetivo. Isso importante para evitar que esforo seja gasto com coleta desnecessria de mtricas, que provavelmente nunca sero utilizadas.
Algumas mtricas comumente utilizadas

Softwares podem ser medidos (ou estimados) baseados em diversos tipos de perspectivas, como tamanho e complexidade. Alm disso, em funo da etapa do desenvolvimento, diferentes mtricas podem ser colhidas para um mesmo produto. Por exemplo, para a medio de tamanho na etapa de levantamento de requisitos, podemos utilizar como mtrica o nmero de requisitos especificados. J na fase de projeto, o tamanho pode ser medido em funo do nmero de classes e, na fase de codificao, a partir no nmero de linhas de cdigo fonte. A seguir, sero apresentadas algumas das principais mtricas baseadas nos tipos de medio citados e, para melhor
51
compreenso, sero utilizados exemplos de cdigos e aplicao das mtricas. Anlise de Pontos de Funo (APF): visa estimar o tamanho do software baseado em Pontos de Funo (PFs). Seu objetivo medir as funcionalidades do software, sem se preocupar com a tecnologia que ser utilizada na implementao e, pode ser aplicado j nos estgios iniciais do desenvolvimento de software. A Tabela 1 apresenta as fases para sua medio. Nmero de linhas de cdigo (LOC, KLOC): assim como a APF, visa estabelecer o tamanho de um sistema, baseando-se no nmero de linhas de cdigo. Essa medio pode auxiliar o engenheiro de software a determinar o tamanho de uma aplicao j construda ou estimar o esforo a ser considerado para a obteno de um produto a ser desenvolvido. Embora seja bastante objetiva, bastando analisar o cdigofonte de produtos concludos para obt-la, ela pode variar de acordo com a linguagem de programao utilizada e, portanto, as estimativas devem considerar dados de projetos similares apenas na mesma linguagem. Complexidade Ciclomtica (CC): proposta por McCabe em 1976, fornece uma medida quantitativa da complexidade lgica de um programa. Atravs dessa mtrica possvel definir o nmero de caminhos possveis de um algoritmo atravs do seu nmero de condies (if, for, while, do e switch) e assim, especificar o quanto um sistema complexo e, por conseqncia, testvel, pois apresenta um indcio do nmero de casos de teste a serem realizados para cobrir as possibilidades de um algoritmo. O ideal que a complexidade ciclomtica seja baixa, pois desta forma, as funes podem ser mais facilmente entendidas e modificadas. O
FASE Determinar o tipo de contagem de pontos de funo
SEI (Software Engineering Institute) definiu uma faixa de valores para a CC, que indicam o grau de complexidade de um algoritmo, conforme mostra a Tabela 2 . Para exemplificar o clculo da complexidade ciclomtica, ser utilizado um algoritmo para clculo de aprovao de um aluno. Os possveis caminhos no algoritmo so numerados, conforme mostra a Figura 2 .
Figura 2. Numerao de possveis caminhos em um algoritmo
Existem diversas formas de clculo da CC, atravs de frmulas, ou pela contagem de caminhos possveis. A Tabela 3 ilustra as possveis formas de clculo da complexidade ciclomtica para este algoritmo. Para programas grandes e complexos, calcular a complexidade ciclomtica de cada funo pode se tornar uma tarefa exaustiva. Por este motivo, ferramentas automatizadas podem ser utilizadas, como o plugin Metrics for Eclipse (ver seo Links), um plugin gratuito para a IDE Eclipse que calcula a complexidade em sistemas desenvolvidos na linguagem Java. A Figura 3 ilustra o clculo realizado pela ferramenta.
DESCRIO
Existem trs tipos de contagem que podem ser levadas em conta: contagem de PF de projeto de desenvolvimento, de aplicaes instaladas e de projetos de manuteno. Determinar o escopo de contagem e a fronteira da aplicao A fronteira da aplicao definida estabelecendo um limite lgico entre a aplicao que est sendo medida, o usurio e outras aplicaes. O escopo para a contagem define a parte do sistema (funcionalidades) a ser contada. Determinar a contagem de pontos de funo no ajustados Essa contagem leva em conta dois tipos de funo: de dados e transacionais, bem como sua complexidade (simples, mdia ou complexa). Contagem das funes de dados Contagem das funes transacionais Determinar o valor do fator de ajuste Calcular os pontos de funo ajustados Contagem referente s funcionalidades relativas aos requisitos de dados internos e externos aplicao. Contagem referente s funcionalidades de processamento de dados do sistema fornecidas para o usurio, como entradas e consultas externas. Baseado em diversas caractersticas gerais de sistemas, que avaliam a funcionalidade geral da aplicao que est sendo contada e seus nveis de influncia que podem ser determinados com base em uma escala de 0 a 5. PFs ajustados so calculados, considerando o tipo de contagem definido no primeiro passo.
Tabela 1. Fases para a medio por pontos de funo
Complexidade
1-10 11-20 21-50 Maior que 50 Programa simples, baixo risco. Programa mais complexo, risco moderado. Programa complexo, risco alto. Programa no testvel, risco elevado.
Situao
Tabela 2. Faixas de Complexidade Ciclomtica. Fonte: SEI Software Engineering Institute (http:// www.sei.cmu.edu)
52
Gerncia de Projetos
Forma de clculo Contagem atravs dos nmeros de CC = E N + 2 arcos e ns onde: E= nmero de arcos
Clculo
para reutilizao, visto que provavelmente possuem alto nvel de abstrao, (ii) pode indicar que a classe herda muitos servios, o que pode aumentar consideravelmente sua complexidade. 3. NOC (Number of children - Nmero de filhos): nmero de subclasses posicionadas imediatamente abaixo da classe em questo. Um NOC alto indica que uma superclasse possui muitos filhos que necessitaram implementar caractersticas prprias, demonstrando baixo nvel de abstrao, visto que podem existir poucas caractersticas em comum entre as classes filhas. A Figura 4 exibe uma hierarquia de classes, que demonstra um NOC de valor trs. Pode-se observar que quanto maior o nmero de mtodos e atributos especializados, menores so as chances de reutilizao das classes filhas e mais complexas ficam as operaes de polimorfismo. Em uma situao simples, como a do exemplo, o valor NOC no tem impacto negativo sobre o sistema, porm caso o cenrio seja um sistema complexo com muitas classes filhas, importante acompanhar os valores de NOC, com o propsito de tomar medidas que evitem nmeros altos.
Contagem atravs do nmero de ns predicados (que indicam uma deciso) Contagem visual Contagem dos caminhos possveis
N= nmero de ns CC = P + 1 onde: P= nmero ns predicados (decises) Atravs do nmero de regies fechadas do grfico construdo, considerando tambm a regio externa CC = 5 1, 2, 10 1, 3, 4, 10 1, 3, 5, 6, 10 1, 3, 5, 7, 8, 10 1, 3, 5, 7, 9, 10
Tabela 3. Formas para clculo da Complexidade Ciclomtica
Figura 3. Clculo da complexidade ciclomtica no plugin Metrics for Eclipse
Mtricas de Chidamber & Kemerer (CK): foram propostas por Chidamber & Kemerer em 1994, um conjunto de seis mtricas que permitem a anlise quantitativa dos artefatos de software construdos utilizando o paradigma da orientao a objetos. Essas mtricas tm o objetivo de salientar as classes que possivelmente contm maior nmero de defeitos, com o propsito de direcionar os esforos de teste. 1. WMC (Weighted methods per class - Mtodos ponderados por classe): clculo do nmero de servios por classe, que pode auxiliar o engenheiro de software indicando o esforo necessrio para o teste de complexidade da classe. Quando classes apresentam um alto WMC, significa que tendem ser especficas, ou seja, destinando-se a necessidades individuais, o que restringe sua reutilizao. 2. DIT (Depth of the inheritance tree - Profundidade da rvore de herana): nmero mximo de superclasses acima da classe em questo. Um DIT alto pode indicar que (i) a classe em questo herdou muitas caractersticas comuns a outras classes, indicando que suas superclasses esto preparadas
Figura 4. Hierarquia de classes, que demonstra um NOC de valor 3
4.CBO (Coupling between object classes - Acoplamento entre classes de objetos): o nvel de acoplamento entre as classes. Um CBO alto indica que a classe possui muitos relacionamentos, o que dificulta sua reutilizao e aumenta sua complexidade, visto que a classe torna-se dependente de outras para efetuar suas operaes. Essa mtrica auxilia o engenheiro de software a avaliar o nvel de reaproveitamento da aplicao e o esforo despendido em testes. 5.LCOM (Lack of cohesion in methods - Falta de coeso em mtodos): Nmero de acessos a um ou mais atributos em comum pelos mtodos da prpria classe. Quanto maior o LCOM, menos coesa a classe. A coeso em mtodos a capacidade dos mtodos realizarem apenas a funo a que so destinados e, para isso devem acessar apenas atributos essenciais ao seu funcionamento. Portanto, importante que o LCOM seja baixo a fim de aumentar a reutilizao e diminuir a complexidade da classe.
53
6.RFC ( Response for a class - Resposta de uma classe): Indica a capacidade de resposta que a classe tem ao receber mensagens de seus objetos (conjunto resposta). o nmero de mtodos que podem ser chamados em resposta a uma mensagem recebida por um objeto ou por algum mtodo da classe. Quanto maior o RFC, maior a possibilidade da classe atender s suas funes. Em contrapartida, para obter um RFC alto, necessrio projetar uma estrutura de classes adequada que possa tender a essa particularidade, o que acaba gerando maior complexidade, tornando necessrio maior esforo de teste. Mtricas de Lorenz & Kidd: Lorenz & Kidd, tambm em 1994, propuseram um conjunto de quatro mtricas, comumente chamadas mtricas LK, que se baseiam assim como as mtricas CK, no clculo quantitativo de alguns aspectos fundamentais da Orientao a Objetos, como os atributos, mtodos, herana, coeso e acoplamento. A diferena entre as mtricas LK e as mtricas CK em relao metodologia empregada em seu clculo. 1.CS (Class size - Tamanho da classe): o nmero de mtodos e atributos da prpria classe e herdados de suas superclasses. Um nmero alto de CS indica que a classe pode ser muito especfica, atendendo necessidades privadas, o que pode dificultar sua reutilizao e aumentar sua complexidade. 2.NOO ( Number of operations overriden by a subclass - Nmero de operaes redefinidas por uma subclasse): nmero de sobrescritas de mtodos em subclasses. Os mtodos herdados de uma superclasse podem ser sobrescritos, ou seja, redefinidos em subclasses, com o propsito de tornar sua funcionalidade mais especfica. De certa forma, essa redefinio de mtodos pode ferir a abstrao implcita da superclasse e um nmero elevado de NOO pode indicar problemas estruturais, pois muitas subclasses do sistema tm mtodos redefinidos e possivelmente esto hierarquicamente mal projetadas. Utilizando ainda o exemplo da Figura 4, nas Listagens 1, 2 e 3 pode-se observar trechos de cdigo das trs classes (Gerente, Diarista e Vendedor), que redefinem o mtodo calculaSalario(). As classes Gerente e Vendedor tambm redefinem o mtodo getCargo(), e ainda,a classe Vendedor redefine o mtodo getDepartamento(). Apesar de no representar um risco estrutural para o projeto, no caso do exemplo, o nmero de mtodos redefinidos indica quais classes devem ter sua evoluo acompanhada. Em um projeto de grande porte e crtico, pode ser complicado reestruturar uma hierarquia de classes no meio do projeto e o NOC indica que classes possivelmente devem ser reestruturadas o quanto antes. A Figura 5 apresenta o resultado da coleta dessa mtrica com a ferramenta Metrics for Eclipse. 3. NOA (Number of operations added by a subclass - Nmero de operaes adicionadas por subclasse): nmero de mtodos e atributos definidos em uma subclasse. Um NOA alto quer
Listagem 1. mtodos gerCargo() e calculaSalario() redefinidos na classe Gerente

public return } public double return } String getCargo (){ Gerente; double calculaSalario(){ taxaTotal=(getSalario()*taxaDependentes)*numDependentes; getSalario()-getDesconto() + taxaTotal;
Listagem 2. mtodo calculaSalario() redefinido na classe Diarista

public double calculaSalario(){ return horasTrabalhadas * valorHora; }
Listagem 3. mtodos getDepartamento(), getCargo() e calculaSalario() redefinidos na classe Vendedor

public Departamento getDepartamento(){ return new Departamento(Departamento.VENDAS); } public String getCargo(){ return vendedor; } public double calculaSalario(){ return (getSalario()- getDesconto())+(numeroVendas * comissaoPorVenda); }
Figura 5. Coleta da Mtrica NOO pela ferramenta Metrics for Eclipse, aqui chamada de Number of Overridden Methods
dizer que a subclasse adicionou muitos mtodos e atributos em sua definio, o que indica um problema estrutural, j que boa parte de seus atributos deveria ser definida em superclasses. Alm de aumentar a complexidade do sistema como um todo, um valor elevado de NOA reduz as possibilidades de reutilizao. 4. SI (Specialization index - ndice de especializao): nmero de mtodos adicionados, eliminados ou redefinidos em uma classe. Na verdade, essa mtrica complementa as mtricas NOO e NOA e um valor alto indica tambm um problema de estruturao de classes, j que possivelmente foram realizadas alteraes para atendimento de necessidades especficas. Classes muito especficas dificilmente so reaproveitadas, ferindo um dos princpios bsicos da OO, a reutilizao. A seguir, so apresentadas na Figura 6 as possveis mtricas coletadas de um fragmento de sistema de controle de Recursos Humanos, atravs da ferramenta Metrics for Eclipse, para demonstrar como simples e rpida a coleta de um conjunto significativo de mtricas atravs de ferramentas automatizadas.
54
Gerncia de Projetos
Figura 6. Mtricas coletadas pela ferramenta Metrics for Eclipse
Alguns outros tipos de mtricas

Diversos outros tipos de mtricas so largamente utilizados, como mtricas de confiabilidade e esforo. Mtricas de confiabilidade so normalmente baseadas em nmero de defeitos apresentados por uma aplicao, podendo ser medidas por intervalo de tempo ou por verso de um produto em uso. Nessa categoria, ferramentas de apoio como BugZilla, Mantis ou Trac so boas aliadas para o registro e acompanhamento de defeitos. Mtricas de esforo so importantes no acompanhamento de processos de software, sendo comumente utilizada a medio de esforo por Homem/Hora, ou alguma derivada desta, como Homem/Ms, que refletem a quantidade de recursos humanos alocados ao projeto por unidade de tempo.
algumas das mtricas mais conhecidas e exemplificar o uso de algumas delas atravs de exemplos simplificados, com o propsito de acentuar a importncia de sua utilizao em um projeto. As mtricas so capazes de indicar pontos em que so necessrios maiores esforos de teste e acompanhamento. Atravs de ferramentas automatizadas, possvel coletar um grande nmero de mtricas com menor esforo, o que viabiliza a implantao de processos de medio em qualquer tipo de sistema, desde os mais simples at os mais crticos, o que contribui para a qualidade do produto final. D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback
Feedback eu
sobre e s
D s
Concluso
Mtricas de software so medidas quantitativas acerca de processos ou produtos de software. O artigo procurou mostrar
55
edio ta
Validao, Verificao e Teste

Esta seo traz artigos que apresentam como e quando utilizar as diferentes abordagens de VV&T no apoio ao desenvolvimento de projetos de software
Integrao contnua com Hudson, Maven2, TestNG e Subversion

De que se trata o artigo? Victor Vidigal Ribeiro
victorvidigal@gmail.com
ps-graduando do Curso de Gerncia de Projetos em Engenharia de Software pelo Centro de Ensino Superior de Juiz de Fora CES/JF, Bacharel em Sistemas de Informao pela Faculdade Metodista Granbery e Analista de Sistemas da Granbery Consultoria Junior, atuando em projeto vinculado Fundao COPPETEC/UFRJ.
Montagem de um ambiente de integrao contnua utilizando um conjunto de ferramentas para este fim.
Para que serve?

O ambiente de integrao contnua proposto mantm o cdigo fonte do repositrio sempre testado, aumentando sua confiabilidade, alm de diminuir a alocao de recursos humanos em atividades de teste.
Fabrcio Nogueira de Almeida

fnalmeida@gmail.com
ps-graduando do Curso de Gerncia de Projetos em Engenharia de Software pelo Centro de Ensino Superior de Juiz de Fora CES/JF, Bacharel em Sistemas de Informao pela Faculdade Metodista Granbery e Analista de Sistemas da Uptodate Consulting.

Em ambientes em que preciso manter um repositrio com cdigo fonte confivel e em sistemas em que os testes atingiram uma complexidade relevante e esto consumindo recursos humanos em excesso ao serem executados.

maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor dos cursos de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora e da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora e Editor da Engenharia de Software Magazine.
evido crescente demanda por softwares cada vez mais complexos e de maior qualidade, vrias tcnicas vm sendo propostas para auxiliar na sua construo. Uma dessas tcnicas o teste de unidade que tem como principal finalidade a busca por defeitos na menor unidade de um sistema como um mtodo ou funo, por exemplo. Porm, em um sistema com uma complexidade relevante, os testes de unidade podem consumir um tempo excessivo da equipe cada vez que uma alterao no sistema seja necessria e os testes tenham que ser executados.
neste contexto que se pode tirar proveito da integrao contnua, onde um servidor faz periodicamente o checkout do cdigo fonte do repositrio e executa automaticamente os testes j criados. Com isto, ao subir um cdigo para o repositrio no necessrio que todos os testes do sistema sejam executados. Pode ser definida uma estratgia onde o
56
Engenharia de Software Magazine - Integrao contnua com Hudson, Maven2, TestNG e Subversion
PROJETO
responsvel por enviar o cdigo para o repositrio execute apenas os testes diretamente relacionados com a alterao realizada, diminuindo o tempo gasto com a execuo dos testes. Alm disto, a execuo peridica dos testes ajuda a manter a confiabilidade do cdigo fonte que est no repositrio. Este artigo tem por finalidade demonstrar a configurao de um ambiente de integrao contnua utilizando um servidor de integrao contnua chamado Hudson, em um repositrio controlado pelo Subversion, e um projeto criado no Eclipse utilizando o Maven2 atravs do plug-in Maven2Eclipse e o framework de testes TestNG.
Feito isto, as configuraes necessrias no repositrio esto prontas.
Configurando o Eclipse
Para facilitar a criao do ambiente, primeiro ser instalado um plug-in chamado Subclipse que permite a comunicao entre o Eclipse e o repositrio. Para isto, abra o eclipse e acesse o menu Help / Install New Software. Uma janela ser apresentada onde o endereo http://subclipse.tigris.org/update_1.6.x deve ser digitado no campo Work with e, em seguida, deve-se acessar a opo Add. Ao acess-la, algumas opes iro aparecer no campo Name desta janela, onde devem ser marcadas as opes Core SVNKit Library, Optional JNA Library e Subclipse, como pode ser visto na Figura 2 e, logo em seguida, deve-se selecionar a opo Next at que a instalao seja concluda.
Criando o repositrio
O primeiro passo para iniciar a construo do ambiente baixar e instalar o Subversion. Ser utilizado o VisualSVN que um servidor do Subversion que disponibiliza uma interface grfica para configurao e que pode ser baixado no endereo http://www.visualsvn.com/. A instalao do VisualSVN bastante simples, basta executar o arquivo de instalao baixado e seguir os passos mantendo sempre as configuraes padres sugeridas pelo instalador. Depois de instalado e executado, o VisualSVN apresenta uma tela semelhante Figura 1.
Figura 2. Instalao do Subclipse Figura 1. Configurao VisualSVN
Neste momento preciso configurar os usurios e grupos de usurios que tero acesso ao repositrio. Como exemplo, ser criado apenas um usurio chamado devmedia que pode ser includo clicando com o boto direito sobre a opo Users, selecionando a opo New User e definindo um login e senha para este usurio. Depois de criar o usurio, ser criado um repositrio chamado CalcularAprovacao. Para isso, clique com o boto direito sobre a opo Repositories e selecione a opo Create New Repository. Uma caixa de texto ser aberta onde deve ser digitado CalcularAprovacao no nome do repositrio. Note que a URL do Subversion pode ser vista na tela inicial do VisualSVN no campo Server URL is. Posteriormente essa URL ser necessria para configurar o servidor de integrao e o Eclipse.
Neste momento o plug-in Subclipse est instalado e deve-se agora instalar o plug-in Maven2Eclipse. Para isso, siga o mesmo procedimento, porm, utilizando o endereo http:/ /m2eclipse. sonatype.org/update/ e selecionando apenas a opo Maven Integration no campo Name. Com isto, o Eclipse j est com todos os plug-ins que precisamos para comear a criar o projeto de exemplo e se integrar com o Hudson.
Criando o projeto de teste

Para criar o projeto de exemplo utilizaremos o Maven2 atravs do plug-in Maven2Eclipse, instalado anteriormente. O Maven um projeto da Apache que tem por finalidade o gerenciamento de projetos. Ele trabalha com o conceito de conveno, ou seja, permite a compilao e a distribuio de
57
uma aplicao com um mnimo de configurao, desde que o projeto respeite a estrutura proposta, e ainda gerencia as dependncias do projeto. Para iniciar a construo do projeto, acesse o menu File / New / Other. Uma janela ser apresentada onde a opo Maven / Maven Project deve ser escolhida. Aps isto, uma nova janela apresentada onde a opo Create a simple project deve ser marcada e, logo em seguida, deve ser selecionada a opo Next. Feito isso, outra janela, semelhante Figura 3, apresentada, onde devem ser digitados alguns dados do projeto: Goup Id: o identificador exclusivo do grupo ou organizao que criou o projeto. No projeto de exemplo ser digitado br.com.calcularAprovacao neste campo. Artifact Id: indica um nome nico para o projeto, deve ser digitado CalcularAprovacao neste campo. Version: a verso do artefato gerado pelo projeto, deixaremos esta opo como padro. Packaging: o tipo de artefato que ser gerado pelo projeto, por exemplo, JAR, WAR, EAR. Para o exemplo ser gerado um artefato do tipo JAR. Name: o nome que ser visualizado nos relatrios que podem ser gerados pelo Maven. Neste campo ser digitado CalcularAprovacao. Description: neste campo pode ser digitada uma breve descrio sobre o projeto.
Maven / Add Dependency. Uma janela ser apresentada onde se deve digitar TestNG no campo Enter groupId, artifactId or sha1 prefix or pattern. Com isto, o Maven busca em seu repositrio online as dependncias com o nome TestNG. Selecione a opo org.testng testng e clique sobre o boto Ok. Feito isto, o Maven2Eclipse adiciona algumas linhas no arquivo de configurao do Maven (chamado pom.xml) e ir baixar as dependncias necessrias para que o TestNG funcione. Apesar do Maven2Eclipse facilitar bastante a configurao do Maven, uma configurao manual deve ser adicionada no arquivo pom.xml. A tag <build> e suas sub-tags devem ser adicionadas indicando que o cdigo do projeto deve ser compilado para verso 1.6 do Java. Com isto, o arquivo pom.xml deve ficar semelhante ao mostrado na Listagem 1. Depois disso, clique com o boto direito sobre o projeto e selecione a opo New / Package e crie um pacote chamado br.com.calcularAprovacao dentro de src/main/Java para armazenar o cdigo do exemplo. Outro pacote com o mesmo nome tambm deve ser criado dentro de src/test/java para armazenar os casos de testes. Neste momento, a estrutura do projeto est criada e configurada para trabalhar com o TestNG. Agora, preciso criar uma classe chamada Aluno que contm um mtodo chamado calcularAprovacao(). Este mtodo ser testado pelos casos de testes que sero criados posteriormente.
Listagem 1. Arquivo pom.xml
<project xmlns=http://maven.apache.org/POM/4.0.0 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd> <modelVersion>4.0.0</modelVersion> <groupId>br.com</groupId> <artifactId>CalcularAprovacao</artifactId> <packaging>jar</packaging> <version>0.0.1-SNAPSHOT</version> <dependencies> dependency> < <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.10</version> <classifier>jdk15</classifier> /dependency> < </dependencies> <build> <finalName>CalcularAprovacao</finalName> plugins> < <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> /plugins> < </build> </project>
Figura 3. Criao de um projeto Maven2
Aps preencher os dados do projeto, clique sobre o boto Finish que o Maven ir criar o projeto utilizando sua estrutura padro. Depois de criar o projeto, deve ser adicionada a dependncia do TestNG, que o framework de testes que ser utilizado. Clique com o boto direito sobre o projeto e selecione o menu
58
PROJETO
Crie a classe Aluno. Ela deve ser criada dentro de src/main/ Java utilizando o cdigo mostrado na Listagem 2.
Listagem 2. Classe Aluno
package br.com.calcularAprovacao; public class Aluno { private String nome; private float nota1; private float nota2; private float notaFinal; private int frequencia; public String getNome(){ return nome; } public void setNome(String nome){ this.nome = nome; } public float getNota1() { return nota1; } public void setNota1(float nota1) { this.nota1 = nota1; } public float getNota2() { return nota2; } public void setNota2(float nota2) { this.nota2 = nota2; } public float getNotaFinal() { return notaFinal; } public void setNotaFinal(float notaFinal) { this.notaFinal = notaFinal; } public int getFrequencia() { return frequencia; } public void setFrequencia(int frequencia) { this.frequencia = frequencia; } public boolean calcularAprovacao(){ float media; if (frequencia < 75) { return false; } else { media = (nota1 + nota2) / 2; if (media < 30) { return false; } else { if (media >= 70) { return true; } else { if (((media + notaFinal) / 2) >= 50) { return true; } else { return false; } } } }
new repository location deve ser selecionada e, logo em seguida, a opo Next deve ser escolhida. Feito isto, uma nova janela exibida onde a URL do Subversion (https://localhost:8443/ svn/CalcularAprovacao/) deve ser digitada. Aps isso, clique sobre a opo Finish.
Listagem 3. Classe de teste CalcularAprovacaoTest
package br.com.testeAprovacao; import org.testng.annotations.Test; import org.testng.*; import br.com.calcularAprovacao.Aluno; @Test public class CalcularAprovacaoTest { public void testAlunoReprovadoFrequencia() { Aluno aluno = new Aluno(); aluno.setNome(Joo); aluno.setNota1(0); aluno.setNota2(0); aluno.setNotaFinal(0); aluno.setFrequencia(74); Assert.assertFalse(aluno.calcularAprovacao()); } public void testAlunoAprovadoNota() { Aluno aluno = new Aluno(); aluno.setNome(Joo); aluno.setNota1(70); aluno.setNota2(70); aluno.setNotaFinal(0); aluno.setFrequencia(75); Assert.assertTrue(aluno.calcularAprovacao()); } public void testAlunoReprovadoNota() { A luno aluno = new Aluno(); aluno.setNome(Joo); aluno.setNota1(29); aluno.setNota2(30); aluno.setNotaFinal(0); aluno.setFrequencia(75); Assert.assertFalse(aluno.calcularAprovacao()); } public void testAlunoReprovadoFinal() { Aluno aluno = new Aluno(); aluno.setNome(Joo); aluno.setNota1(30); aluno.setNota2(30); aluno.setNotaFinal(69); aluno.setFrequencia(75); Assert.assertFalse(aluno.calcularAprovacao()); } public void testAlunoAprovadoFinal() { A luno aluno = new Aluno(); aluno.setNome(Joo); aluno.setNota1(30); aluno.setNota2(30); aluno.setNotaFinal(70); aluno.setFrequencia(75); Assert.assertTrue(aluno.calcularAprovacao()); } }
Depois de criar a classe Aluno, ser criada a classe CalcularAprovacaoTest que contm os casos de teste. Esta classe deve ser criada dentro de src/test/Java, e deve conter o cdigo mostrado na Listagem 3. Pode-se perceber que esta classe contm a anotao @Test que faz com que o TestNG a reconhea como uma classe de teste. Neste momento, o projeto est criado e deve ter uma estrutura semelhante apresentada na Figura 4. Agora preciso subir nosso projeto para o repositrio. Para isto, clique com o boto direito sobre o projeto e selecione a opo Team / Share Project. Ao selecionar essa opo, uma janela exibida onde deve ser escolhido o tipo do repositrio. Selecione a opo SVN, que a sigla para Subversion, e clique sobre Next. Uma nova janela exibida onde a opo Create a
Figura 4. Estrutura do Projeto
Com o procedimento anterior, o Subclipse vinculou o projeto ao repositrio, mas ainda no subiu o cdigo para este repositrio. Para subir o cdigo clique novamente sobre o projeto
59
e selecione a opo Team / Commit. Ao selecionar esta opo uma janela exibida onde possvel escrever um comentrio sobre o cdigo que est sendo enviado ao repositrio. Digite Primeiro commit para o subversion e clique sobre o boto Ok. Com isto, o cdigo enviado ao repositrio.
Configurando o Hudson
Depois de ter realizado os procedimentos anteriores, chegou a hora de configurar o Hudson, que um servidor de integrao contnua. O Hudson disponibilizado como um arquivo WAR e tem um servidor web integrado a ele. Por conta disso, ele pode ser executado utilizando o comando java jar hudson.war ou atravs de um servidor externo. No exemplo, ser utilizado o Tomcat. Portanto, copie o arquivo hudson.war para a pasta webapps e reinicie o Tomcat para que ele efetue o deploy do Hudson. Feito isto, basta acessar o endereo http://localhost:8080/hudson para entrar na interface de configurao. Na pgina de configurao do Hudson, o menu Gerenciar Hudson / Configure System deve ser acessado para iniciar a configurao, como mostra a Figura 5.
Logo abaixo, marque tambm a opo Logged-in users can do anything para permitir que os usurios criados posteriormente tenham permisso para fazer qualquer coisa no Hudson. Um pouco mais abaixo na janela de configurao, como pode ser visto na Figura 6, possvel configurar o Maven e o JDK que sero utilizados. Para incluir o Maven, clique sobre o boto Add Maven e digite Maven no campo Name e, em Version, selecione a opo 2.2.1. Para adicionar o JDK, clique sobre o boto Add JDK, digite jdk6 no campo Name e, em JAVA_HOME, informe o diretrio onde o JDK est instalado.
Figura 6. Configurao do Maven e JDK
Figura 5. Configuraes do Hudson
H muitas maneiras diferentes de se configurar o Hudson e, por conta disso, sero mostradas as principais configuraes que so necessrias para seu funcionamento. O primeiro campo, Mensagem do Sistema, apenas a mensagem inicial que ser exibida ao acessar o Hudson. O campo Nmero de executores informa qual a quantidade de builds concorrentes que o Hudson pode fazer. Isso porque um servidor do Hudson pode rodar vrios projetos simultaneamente. J no campo Perodo de Silncio pode-se definir quanto tempo o Hudson ir aguardar at que comece o build e, em SCM checkout retry count, a quantidade de vezes que o Hudson deve tentar fazer checkout caso acontea algum erro nesse procedimento. A opo Habilitar segurana deve estar marcada para que se possa definir como o Hudson ir controlar os usurios. Ao habilitar a segurana, o Hudson fornece opes de controle de usurio. Selecione a opo Hudsons own user database para que os usurios sejam controlados pelo prprio Hudson.
A prxima e ltima configurao referente ao envio de emails. Caso esteja configurado, o Hudson envia e-mails cada vez que executado, informando o resultado de sua execuo. Para configurar essa funcionalidade, na parte de Notificao de E-mail, informe o endereo do servidor SMTP no campo Servidor SMTP e o sufixo padro para e-mail de usurio. Sufixo padro para e-mail de usurio indica ao Hudson que o endereo de e-mail de cada usurio formado pelo nome do usurio mais o sufixo padro. Por exemplo, se o sufixo padro for configurado como @gmail.com e um usurio chamado devmedia for adicionado, o Hudson ir entender que o endereo de e-mail desse usurio devmedia@gmail.com. Deve-se preencher o Endereo de e-mail do Administrador do sistema com o endereo de e-mail do administrador. No campo URL do Hudson deve ser definido o endereo do Hudson, com http://localhost:8080/hudson. Como exemplo, ser utilizado o SMTP do GMail que necessita de autenticao para funcionar. Para configurar esta autenticao clique sobre o boto Avanado, marque a opo Use SMTP Authentication, digite o nome do usurio, a senha e, caso seja necessrio, marque a opo Usar SSL. A Figura 7 mostra como ficou a configurao dessa parte do Hudson. O envio de e-mail pode ser testado atravs do boto Configurao de teste para enviar e-mail para o endereo do Administrador do Sistema. Acessando esse boto, um e-mail de teste enviado.
60
PROJETO
a opo Construir periodicamente deve ser marcada, e o campo Agenda configurado com o seguinte texto: 0 0 * * *. Desta maneira, o Hudson ir rodar no minuto 0 da hora 0 de cada dia do ano, pois este campo segue a mascara: minuto hora dia_ms ms dia_semana.
Figura 7. Configuraes do servidor de SMTP
Figura 8. Configurao do Subversion no Hudson
Pode-se perceber que do lado de cada campo h um , que caso acionado, exibe a descrio do campo que est a sua esquerda. Este recurso de grande auxlio na configurao do Hudson. Aps realizar as configuraes anteriores, o boto Salvar deve ser acionado. Com isso, o Hudson exibe uma pgina onde o primeiro usurio deve ser criado. Para o exemplo, foi criado um usurio chamado devmedia.
Criando tarefas no Hudson

Depois de configurar o Hudson, preciso criar uma tarefa informando a ele que deve baixar o projeto do repositrio e executar os testes criados. Ao clicar na opo Nova Tarefa, localizada na parte esquerda do Hudson, uma janela exibida onde se pode digitar o nome da tarefa. A tarefa de teste ser chamada de CalcularAprovacao. preciso definir tambm o tipo de tarefa que, no caso do exemplo, ser escolhida a opo Construir um projeto Maven2. Aps isto, clique sobre o boto Ok e uma nova janela exibida onde possvel configurar a tarefa construda. Em Gerenciamento de Cdigo Fonte, selecione a opo Subversion e digite a URL do Subversion em URL do Repositrio. O Hudson ir informar que no consegue acessar o repositrio, isto porque ainda no foi definido um usurio e senha para acess-lo. Clique sobre o link enter credential para definir o usurio do repositrio. No campo Diretrio do mdulo local deve ser digitado o nome do projeto que foi criado no Eclipse e, portanto, deve-se digitar CalcularAprovacao. A opo Usar Atualizao bastante interessante. Caso seja marcada, o Hudson no faz o checkout de todo o projeto novamente. Ele faz o checkout apenas dos arquivos que foram alterados no repositrio. A Figura 8 mostra como esta parte da configurao do repositrio deve estar. A prxima configurao diz respeito periodicidade do Hudson, ou seja, o Hudson pode ser configurado para rodar de tempos em tempos. Para isso, em Disparadores de Construo,
Aps isto, em Construir, preciso informar no campo POM Raz onde est o arquivo pom.xml do projeto gerado. Nesse campo deve ser digitado CalcularAprovacao/pom.xml. No campo Goals and options deve ser digitado test. Esse um parmetro que faz com que o Hudson execute o Maven para rodar os testes criados. Uma ltima configurao que deve ser feita marcar a opo Notificao de E-mail para que um e-mail com os relatrios de execuo do Hudson seja enviado cada vez que o Hudson for executado. Para salvar as configuraes, deve ser acionado o boto Salvar. Com isso, o Hudson exibe a pgina inicial da tarefa que acabou de ser criada. Com essas configuraes, o Hudson ir baixar o projeto do repositrio e executar os testes criados s 0:00 horas de cada dia. possvel executar a tarefa criada a qualquer momento tambm atravs do menu Construir Agora. Na parte esquerda do Hudson, como pode ser visto na Figura 9, pode ser visualizado um histrico das construes que foram realizadas, e tambm de alguma eventual construo que esteja sendo executada.
Figura 9. Histrico de Construo
Caso alguma construo no tenha sido realizada com sucesso, possvel ver o motivo do erro clicando sobre a construo e, em seguida, sobre o menu Console output. Ao acessar esta opo, o Hudson exibe a sada gerada pela construo. A Figura 10 mostra um exemplo de sada em que a construo falhou, sendo possvel verificar o motivo da falha.
61
ferramentas de acompanhamento de defeitos (Bugzilla, Mantis, Trac), suporte a outras linguagens (.net, ruby) e at mesmo integrao com o Twitter.
Figura 10. Sada de Console
Concluso
O artigo procurou mostrar como configurar um ambiente de integrao contnua utilizando diferentes ferramentas. O ambiente foi construdo utilizando o servidor de integrao Hudson, o repositrio Subversion, com o uso do VisualSVN para instalao do servidor, e o plug-in Subclipse para integrao com o Eclipse, o gerenciador de projetos Maven2, atravs do plug-in Maven2Eclipse, e o framework de teste TestNG. Um ambiente de integrao contnua, como o apresentado neste artigo, possibilita a execuo de testes de maneira automatizada o que pode torn-los mais eficientes e economizar recursos humanos nessa tarefa. Alm disso, com a execuo peridica dos testes, mais rpida a identificao de falhas inseridas no cdigo fonte pelos desenvolvedores. Devido a isto, o cdigo do repositrio pode ser considerado mais confivel. Outra vantagem desse ambiente que se torna possvel um melhor acompanhamento da execuo de testes atravs de relatrios gerados pelo Hudson.
Links Hudson http://hudson-ci.org/ VisualSVN http://www.visualsvn.com/ Subclipse http://subclipse.tigris.org/ TestNG http://testng.org
O Hudson tambm disponibiliza um relatrio de tendncia onde possvel visualizar graficamente os resultados dos testes executados. A Figura 11 mostra o relatrio gerado no projeto de exemplo. O grfico apresenta o nmero da construo pelo seu tempo de execuo. Enquanto as reas vermelhas do grfico representam as construes que falharam, as cinzas so construes que foram abortadas. J as amarelas so as construes que foram executadas com sucesso parcial e as construes executadas com sucesso total so representadas pela cor azul.
Figura 11. Grfico de tendncias
62
edio ta
Apesar do ambiente proposto ter mostrado apenas a execuo de testes de unidade atravs do Hudson, possvel integrar tambm ferramentas de checkstyle de cdigo, deteco de bugs e cobertura de testes, por exemplo. Alm disso, o Hudson extensvel atravs de plug-ins que podem fornecer funcionalidades como integrao com
D s
Feedback eu
sobre e s
PROJETO
63
64

Seis Sigma + CMMI 21

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Seis Sigma + CMMI 21

Enviado por

Direitos autorais:

Formatos disponíveis

Modstia parte, sua melhor opo para se destacar no mercado!

Engenharia de Software: Desenvolvimento Java Engenharia de Software: Desenvolvimento .NET

Engenharia de Computao Anlise e Desenv. de Sistemas

r/esti Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti

EDUCAO SUPERIOR ORIENTADA AO MERCADO

Rodrigo Oliveira Spnola

Kaline Dolabella Gerente de Marketing e Atendimento kalined@terra.com.br

Marco Antnio Pereira Arajo

Fale com o Editor!

Eduardo Oliveira Spnola

32 - Colaborao em Processos de Aquisio de Software

38 - Organizao Fbrica de Experincia

43 - Customizao e Integrao de Ferramentas Open-Source

Engenharia de Software Magazine

Abordagens Tradicionais de Desenvolvimento

Seis Sigma e CMMI

Ana Nathalie de Mello Rodrigues

Marcelo Nascimento Costa

Edio 21 - Engenharia de Software Magazine

Histrico dos Modelos de Qualidade

Engenharia de Software Magazine - Seis Sigma e CMMI

Edio 21 - Engenharia de Software Magazine

Da Gesto da Qualidade para a Qualidade Total

Figura 2. Ciclo PDCA

Recapitular todo o mtodo de soluo do problema para trabalhos futuros.

Tabela 1. Etapas do Ciclo PDCA (Fonte: Adaptao (SSPJ, 2009))

Engenharia de Software Magazine - Seis Sigma e CMMI

Edio 21 - Engenharia de Software Magazine

Engenharia de Software Magazine - Seis Sigma e CMMI

Os oito Critrios de Excelncia se subdividem em 24 Itens, conforme o ilustrado na Figura 5.

Figura 5. Subdivises dos Critrios de Excelncia PNQ (Fonte: (FNQ, 2009))

Edio 21 - Engenharia de Software Magazine

Definio e objetivos do modelo

Engenharia de Software Magazine - Seis Sigma e CMMI

Figura 8. Componentes da Estrutura do CMMI (Fonte: Adaptao (CMMI, 2006))

Edio 21 - Engenharia de Software Magazine

Figura 10. Nveis de Maturidade do CMMI (Fonte: Adaptao (CITS, 2009))

Engenharia de Software Magazine - Seis Sigma e CMMI

Figura 11. Os Nveis de Maturidade e suas reas de Processo

Tabela 3. Benefcios Quantitativos da Utilizao do CMMI (Fonte: Adaptao (SEI, 2006))

Edio 21 - Engenharia de Software Magazine

Figura 14. Situao das Aes na GE (1965-2004) (Fonte: (FINANCE, 2009))

Engenharia de Software Magazine - Seis Sigma e CMMI

Definio e Objetivos do Modelo

Edio 21 - Engenharia de Software Magazine

Tabela 4. Qualidade e defeitos sigma (Fonte: Adaptao (FERNANDES, 2008))

Six Sigma Black Belt Certification SSBB

Six Sigma Green Belt Certification SSGB

Engenharia de Software Magazine - Seis Sigma e CMMI

Resumo dos papis da equipe

Papel exercido no Seis Sigma Executivo Lder

Master Black Belts

Yellow Belts White Belts

Edio 21 - Engenharia de Software Magazine

O modelo DFSS (Design For Six Sigma)

Engenharia de Software Magazine - Seis Sigma e CMMI

Mapeamento entre Seis Sigma e CMMI Nveis 4 e 5

Edio 21 - Engenharia de Software Magazine

Figura 17. DMAIC Roadmap (Fonte: Adaptao (SEI, 2005))

Relaes entre CMMI e SEIS SIGMA

Engenharia de Software Magazine - Seis Sigma e CMMI

Mapeamento CMMI x Seis Sigma

Desempenho do Processo Organizacional (OPP)

Edio 21 - Engenharia de Software Magazine