Seis Sigma + CMMI 21

www.infnet.edu.br - [email protected] - Central de Atendimento: (21) 2122-8800

E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O

PÓS-GRADUAÇÃO

Engenharia de Software: Desenvolvimento Java

Engenharia de Software: Desenvolvimento .NET

GRADUAÇÃO

Engenharia de ComputaçãoAnálise e Desenv. de Sistemas

FORMAÇÕES

Desenvolvedor Java

Desenv. Java: Sist. Distribuídos

Gestor de TI

Desenvolvedor Web .NET 2008

MCITP Server Administrator

SQL Server 2008

Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

A Escola Superior da Tecnologia da Informação oferece as melhores opções em cursos, formações, graduações e pós-graduações para profissionais de desenvolvimento e programação.

São programas voltados para a formação de profissionais de elite, com aulas 100% práticas, corpo docente atuante no mercado, acesso à mais atualizada biblioteca de TI do Rio, laboratórios equipados com tecnologia de ponta, salas de estudo e exames.

r/esti

TURMASNO RIO DEJANEIRO

Modéstia à parte, suamelhor opção para

se destacar no mercado!

EDITORIAL

Corpo Editorial

ColaboradoresRodrigo Oliveira Spí[email protected]

Marco Antônio Pereira AraújoEduardo Oliveira Spínola

CapaRomulo Araujo - [email protected]

DiagramaçãoJanete Feitosa

Coordenação GeralDaniella Costa - [email protected]

Revisor e SupervisorThiago Vincenzo - [email protected]

Na Webwww.devmedia.com.br/esmag

Ano 2 - 21ª Edição - 2010 Impresso no Brasil

O propósito da qualidade é estabelecer um diferencial competi-

tivo, através de contribuições como redução de defeitos, redu-

ção de custos, redução de retrabalho e aumento da produtivi-

dade, entre outras. Existem diversas iniciativas para garantia da qualida-

de de produtos e processos nas empresas. Nesta edição, a Engenharia

de Software Magazine destaca duas delas:

• CMMI, (Capability Maturity Model Integration), um modelo de ma-

turidade mundialmente conhecido, usado para criar uma infraestrutu-

ra de processos organizacionais, abordando domínios específicos, tais

como software e engenharia de sistemas.

• Seis Sigma, uma metodologia criada pela Motorola, caracterizada por

uma abordagem sistêmica e utilização intensiva do pensamento esta-

tístico, que visa a redução de defeitos nos produtos para 3,4 defeitos

por milhões de oportunidades (Seis Sigma) por meio da otimização de

produtos e processos.

Neste contexto, temos como capa desta edição um artigo que fornece

a compreensão necessária das relações entre as iniciativas e propor a

utilização do Seis Sigma na melhoria da qualidade de software para a

obtenção dos níveis de maturidade 4 e 5 do CMMI.

Além desta matéria, esta edição traz mais cinco artigos:

• Colaboração em Processos de Aquisição de Software

• Customização e Integração de Ferramentas Open-Source

• Organização Fábrica de Experiência

• Métricas de Software

• Integração contínua com Hudson, Maven2, TestNG e Subversion

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola [email protected] em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computa-ção (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), ten-do ministrado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação 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.

Marco Antônio Pereira Araújo([email protected])Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spínola([email protected]) É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva-dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).

Apoio

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, endereço de

bancas de jornal, entre outros, entre em contato com:

Cristiany Queiróz– Atendimento ao Leitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

Kaline [email protected]

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 sugestão!

Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

entre em contato com os editores, informando o título e mini-resumo do tema que você

gostaria de publicar:

Rodrigo Oliveira Spínola - Colaborador

[email protected]

Í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 - Colaboração em Processos de Aquisição de SoftwareJoão Condack, Rafael Vieira

38 - Organização Fábrica de ExperiênciaFernando Hadad Zaidan, George Leal Jamil e Leandro Libério da Silva

43 - Customização e Integração de Ferramentas Open-SourceFelipe Furtado, Gustavo Carvalho, Andrea Pinto e Ryan Albuquerque

50 - Métricas de SoftwareThamine Chaves Leite de Abreu, Leonardo da Silva Mota e Marco Antônio Pereira Araújo

Validação, Verificação e Teste

56 - Integração contínua com Hudson, Maven2, TestNG e SubversionVictor Vidigal Ribeiro, Fabrício Nogueira de Almeida e Marco Antônio Pereira Araújo

4 Engenharia de Software Magazine

Tipo: Requisitos Título: Diagrama de Casos de Uso na Prática – Partes 4 a 7 Autor: Rodrigo Oliveira SpínolaMini-Resumo: Estas aulas são parte de uma série sobre a construção de diagrama de casos de uso da UML. O objetivo do conjunto de aulas é apresentar de forma prática como elaborar o diagrama de casos de uso a partir de diferentes estudos de caso. Nestas aulas, serão elaborados diversos dia-gramas de casos de uso. Também será visto como especificar um caso de uso para um dos diagramas elaborados.

Caro Leitor, Para esta edição, temos um conjunto de 4 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software Magazine e certamente trarão uma significativa contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Edição 21 - Engenharia de Software Magazine 5

Marcelo Nascimento [email protected]

Diretor de Tecnologia da Kali Software. Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ. Bacharel em Ciência da Computação pela UFPA. Especialista em CMMI, tendo participado de diversas implementações e avaliações deste modelo. Professor do curso de Ciên-cia da Computação do Centro Universitário Metodista Bennett.

Ana Nathalie de Mello Rodrigues Estagiária na área de Governança de TI da Wilson, Sons. Bacharel em Ciência da Com-putação pelo Centro Universitário Metodis-ta Bennett. Técnica em Processamento de Dados pela FAETEC.

Luiz Fernando da Silva FielBacharel em Ciência da Computação pelo Centro Universitário Metodista Bennett.

Seis Sigma e CMMI Uso do Seis Sigma para Melhoria da Qualidade de Software junto aos Altos Níveis de Maturidade do CMMI

O propósito da qualidade é esta-belecer um diferencial compe-titivo, através de contribuições

como redução de defeitos, redução de custos, redução 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 domínios específicos, tais como software e enge-nharia de sistemas. • Seis Sigma, uma metodologia criada pela Motorola, caracterizada por uma abordagem sistêmica e utilização inten-siva do pensamento estatístico, que visa a redução de defeitos nos produtos para 3,4 defeitos por milhões de oportunida-des (Seis Sigma) por meio da otimização de produtos e processos.

O objetivo deste artigo é fornecer a compreensão necessária das relações entre as iniciativas e propor a utilização do Seis Sigma na melhoria da qualidade de software para a obtenção dos níveis de maturidade 4 e 5 do CMMI.

Introdução

MotivaçãoEm meados dos anos 80, influenciado

pela introdução crescente de técnicas industriais japonesas nas fábricas bra-sileiras, o conceito de melhoria da qua-lidade ganhou destaque. Foi o auge do impacto nipônico na indústria nacional, impulsionado por visita de técnicos bra-sileiros ao Japão em missões especiais e pelo sucesso das ferramentas japonesas de administração da qualidade.

O desenvolvimento de novas técnicas de produção e a adaptação de proce-dimentos criados, sobretudo no Japão, foram experiências marcantes no perío-do, caracterizado também pelo advento


Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens tradicionais de apoio ao desenvolvimento de projetos de software

6 Engenharia de Software Magazine - Seis Sigma e CMMI

da norma ISO 9000, então 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 esforço para minimizar defeitos. Como também permanece a visão de que a qualidade está restrita às melhorias localizadas. Ou até mesmo a uma maior qualificação das pessoas. Mas atual-mente a qualidade já pode ser vista como um diferencial ou até mesmo como um item básico de manutenção da empresa, principalmente nestes tempos de concorrência acirrada (CAR-VALHO; PALADINI, 2005).

Em termos simples e objetivos, o propósito da qualidade é estabelecer um diferencial competitivo. Ou seja: garantir um espaço para a organização, diferenciando-a das demais exis-tentes no mercado. Em outras palavras: fixar raízes à frente dos concorrentes.

A qualidade oferece contribuições operacionais que não po-dem ser desprezadas, como por exemplo: redução de defeitos, redução de custos, redução de retrabalho, aumento da produti-vidade. Existem também contribuições táticas relevantes como a formação de pessoas mais preparadas para tomar decisões gerenciais críticas para o funcionamento da empresa. Mas as contribuições mais relevantes são as de natureza estratégica: garantir não apenas a sobrevivência da organização, mas seu contínuo crescimento (evolução).

Considerando o escopo das empresas de processo de sof-tware, além das certificações ISO entre outras iniciativas aplicáveis, 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 obtenção das certifi-cações dos altos níveis de maturidade (tanto do CMMI quanto do MPS.BR) é a necessidade de se ter qualidade de processos, condições de previsibilidade em termos de prazo, de custo e de volume de trabalho a ser feito para que consiga satisfazer o cliente. As empresas estão sempre em evolução para atender as exigências do mercado cada vez mais competitivo e com as cer-tificações de maturidade, são adquiridas condições de medir a melhoria e comprovar as vantagens de se encontrar em outro nível de excelência em termos de controle de processos.

Para algumas empresas, as principais dificuldades encontra-das na obtenção dos mais altos níveis são: o custo de implemen-tação (melhorar requer mudanças e mudanças geram custos) e a maturidade organizacional, que requer também uma mudança cultural e a colaboração de todas as equipes. Estas dificuldades trazem resistência por parte dos envolvidos, porém, ao longo do tempo percebe-se que o custo é muito maior quando não se pratica estes processos, pois o nível de qualidade é menor e há muito retrabalho.

ObjetivosEste artigo propõe uma solução integrada em termos de me-

lhoria de processos de software e obtenção de altos níveis de maturidade, através da utilização de duas iniciativas: 1. CMMI (Capability Maturity Model Integration) - um modelo

de maturidade mundialmente conhecido, usado para criar uma infraestrutura de processos organizacionais, abordando domínios específicos, 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 “estratégia gerencial, filosofia ou metodologia”, que tem por objetivo reduzir dras-ticamente a variabilidade dos processos críticos e aumentar a lucratividade das empresas, por meio da otimização de produ-tos e processos, buscando satisfação de clientes e consumidores (CARVALHO; PALADINI, 2005).

Concepções tão diferenciadas podem gerar dúvidas 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 for-ma, o objetivo deste artigo é fornecer a compreensão necessária das relações entre as iniciativas, de modo que sua aplicação em conjunto seja bem sucedida.

Organização do ArtigoOs tópicos a seguir mostram como está organizado este

artigo. Inicialmente será abordado o histórico dos modelos de

qualidade, passando por gestão e excelência, e trata do mo-delo CMMI, mostrando suas principais características, como estrutura e benefícios.

Na sequencia, é apresentado o Seis Sigma, fazendo um relato do histórico, objetivos, perfis das pessoas responsáveis pela implementação do modelo e suas metodologias.

Feito isto, é apresentada aplicação do Seis Sigma na melhoria dos processos de qualidade de software, através do mapeamen-to de suas atividades com as práticas definidas nos níveis de maturidade 4 e 5 do CMMI. Ainda neste tópico, é apresentado um estudo de caso da aplicação integrada do Seis Sigma e CMMI em uma empresa de software, mostrando como esta estratégia de melhoria de processos pode trazer benefícios significativos. Finalmente, é apresentada a conclusão deste trabalho.

Histórico dos Modelos de Qualidade

Relatos HistóricosA necessidade pela gestão da qualidade surgiu há muitos

anos atrás, onde os artesãos faziam todo o processo, desde a concepção até o pós-venda de seus produtos. Como a popu-lação não era numerosa, as necessidades eram mínimas e o trabalho era artesanal. O artesão, sabendo que seus produtos dependiam da reputação 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, não o processo. Como exemplo disso, no final do século XIX, a montadora de automóveis Panhard e Levassor (P&L) montava


MEtoDoLoGIAS ÁGEIS

seus veículos atendendo às necessidades dos clientes que a procuravam, e como era um produto para poucos, não havia dois carros iguais.

Em 1750, durante a Revolução Industrial, surgiram as primeiras máquinas projetadas para obter grande volume de produção e uma nova forma de organização do trabalho permitiu alcançar a produção em massa. Nessa nova ordem produtiva, a customização foi substituída pela padronização e a produção em larga escala.

A linha de montagem era o modelo ideal para a produção em massa. O trabalho foi fragmentado e os trabalhadores tinham domínio apenas de uma pequena fração do trabalho. O trabalhador não fazia mais parte das etapas de concepção e planejamento e surgiu a função do inspetor, responsável pela qualidade dos produtos.

No período 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 milhões de unidades foram vendidas. O carro passou a ser um produto acessível à classe trabalhadora, mudando o conceito dessa indústria, que investiu em capacidade para atender à demanda, que era maior que a oferta. Como um veículo ainda diferia bastante de outro produzido sob o mesmo projeto, a Ford investiu na intercambialidade das peças e na facilidade de ajustes, adotando um sistema padronizado de medida para todas as peças. O modelo de linha de montagem se difundiu em outros industriais, e para garantir a intercambialidade das peças, tornou-se importante investir no desenvolvimento de áreas com a metrologia, sistema de medidas e especificações. O foco da qualidade ainda era a inspeção, mas já existiam elementos que mostravam o que viria a ser o conceito de qua-lidade que priorizava uma abordagem voltada à produção e à conformidade.

Gestão da QualidadeExistem algumas pessoas que são consideradas como Gu-

rus da Qualidade. Eles foram alguns teóricos que ajudaram a construir a área de qualidade e tiveram um papel especial para merecer a denominação. Alguns dos Gurus mais citados são: Walter A. Shewhart, W. Edwards Deming, Joseph M. Ju-ran, 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 gráficos de contro-le. Com essa ferramenta, Shewhart fundiu os conceitos de estatística em um método gráfico de fácil utilização no chão de fábrica e os aplicou à realidade produtiva da empresa de telefonia Bell Telephone Laboratories.

A ferramenta proposta analisava os resultados das inspeções, que até aquele momento eram utilizadas apenas para a segrega-ção dos produtos com defeito, por meio de gráficos de controle, que permitiam facilmente distinguir entre as causas de variação comuns ao processo e aquelas causas especiais, que deveriam ser investigadas. Com a análise desses resultados à luz dos conceitos estatísticos era possível sair de uma postura reativa e entender e

prever o comportamento do processo, o que permitiria uma ação proativa, evitando novas ocorrências. A facilidade de utilização do gráfico foi um dos aspectos que ajudou na sua difusão, pois era uma ferramenta visual, que podia ser preenchida no am-biente de trabalho, com os parâmetros estatísticos do processo já sintetizados (CARVALHO; PALADINI, 2005).

Geralmente, o gráfico de controle é utilizado na detecção de alterações inusitadas de uma ou mais características de um processo ou produto. Em outras palavras, é uma ferramenta estatística que alerta para a presença de causas especiais gran-des na linha de produção. Existem diversos tipos de gráficos de controle e cada um deles é melhor aplicável a determinadas situações. Normalmente, todos os tipos de gráficos de controle seguem a estrutura da Figura 1.

Figura 1. Gráfico de controle em formato conceitual (Fonte: Adaptação (CARVALHO; PALADINI, 2005))

O gráfico consiste na plotagem de três linhas e os pontos que representam as médias de pequenas amostras (chamados sub-grupos racionais), cada qual de tamanho n (= 1, 4, 9, 16, 1000, por exemplo), de mensurações periódicas de alguma característica importante de um processo (peso, cumprimento, volume etc.), ou o número ou porcentagem de peças defeituosas ou número de defeitos. As três linhas representam dois limites de controle, um superior (LCS) e outro inferior (LCI), e uma linha no meio que é a média da variável ou o alvo da característica.

Tradicionalmente, as linhas de controle ficam numa distância de três desvios-padrão da média ou do alvo do processo. Os limites definem uma área razoavelmente grande que vai evitar alarmes falsos. O desvio-padrão utilizado é o desvio-padrão das médias (erro-padrão); teoricamente, é o desvio-padrão da população dividido pela raiz quadrada do tamanho da amos-tra - σ/√n. Em termos estatísticos, os dois limites de controle definem um intervalo de confiança com nível de confiança de 99,73%. Esse número significa que um alarme falso pode ocor-rer uma vez em 370 subgrupos. Se forem tiradas 16 amostras por dia numa fábrica, o alarme falso iria ocorrer apenas uma vez a cada 23 dias, um preço muito razoável, considerando-se o grande valor relacionado aos gráficos de controle (CARVA-LHO; PALADINI, 2005).


Walter A. Shewhart também propôs o ciclo PDCA (plan-do-check-act), que direcionaria as atividades de análise e solução de problema, percorrendo o ciclo de planejar, fazer, checar o re-sultado e depois agir, ou seja, implementar a melhoria e garan-tir o alcance das metas na empresa, disseminado para o mundo por Deming William Edwards, que era seu discípulo.

O ciclo PDCA é composto das seguintes etapas (Figura 2):

Figura 2. Ciclo PDCA

Planejar (PLAN)• Definir as metas a serem alcançadas;• Definir o método para alcançar as metas propostas.

Executar (DO)• Executar as tarefas exatamente como foi previsto na etapa de planejamento;• Coletar dados que serão utilizados na próxima etapa de verificação do processo;• Nesta etapa são essenciais a educação e o treinamento no trabalho.

Verificar, checar (CHECK)• Verificar se o executado está conforme o planejado, ou seja, se a meta foi alcançada, dentro do método definido;• Identificar os desvios na meta ou no método.

Agir corretivamente (ACTION)• Caso sejam identificados desvios, é necessário definir e im-plementar soluções que eliminem as suas causas;

• Caso não sejam identificados desvios, é possível realizar um trabalho preventivo, identificando quais os desvios são passíveis de ocorrer no futuro, suas causas, soluções etc.

O PDCA pode ser utilizado na realização de toda e qualquer atividade da organização (Tabela 1). O ideal é que todos utilizem esta ferramenta de gestão no dia-a-dia de suas atividades.

Da Gestão da Qualidade para a Qualidade TotalA gestão da qualidade consiste no conjunto de atividades coor-

denadas para dirigir e controlar uma organização com relação à qualidade, englobando o planejamento, o controle, a garantia e a melhoria da qualidade (CARVALHO; PALADINI, 2005).

Esse conceito necessita ser trazido para o âmbito organiza-cional, ou seja, precisa ser “operacionalizado” na organização. Existe uma necessidade de gerenciar o conjunto de atividades re-lativas à qualidade, de modo que atenda a qualquer enfoque.

A Figura 3 mostra a relação entre a definição da qualidade estabelecida pela norma ISO 9000: 2000, seguido pela necessi-dade de trazer essa definição para a operação organizacional, por meio da gestão da qualidade, que, por sua vez, se subdivide em planejamento, controle, garantia, e melhoria da qualidade, cujas definições são também apresentadas na Figura 3 (CAR-VALHO; PALADINI, 2005).

PDCA FLUXO ETAPA OBJETIVO

P

1 Identificação do Problema Definir claramente o problema/processo e reconhecer sua importância.

2 Observação Investigar as características específicas do problema/processo com uma visão ampla e sob vários pontos de vista.

3 Análise Descobrir a causa fundamental.

4 Plano de ação Conceber um plano para bloquear a causa fundamental.

D 5 Execução Bloquear a causa fundamental.

C 6 Verificação Verificar se o bloqueio foi efetivo.

A

7 Padronização Prevenir contra o reaparecimento do problema.

8 Conclusão Recapitular todo o método de solução do problema para trabalhos futuros.

tabela 1. Etapas do Ciclo PDCA (Fonte: Adaptação (SSPJ, 2009))

Figura 3. Inter-relação entre o conceito de qualidade, Gestão da Qualidade e elementos que a compõem. Fonte: Adaptação (CARVALHO; PALADINI, 2005)


MEtoDoLoGIAS ÁGEIS

A partir da Figura 3, que mostra o conceito de gestão da qualidade, e das inter-relações mostradas, o que poderia definir a “qualidade total”?

De acordo com a ISO 8402: 1994, pode ser defini-da como o “modo de gestão de uma organização, centrado na qualidade, baseado na participação de todos os membros, visando ao sucesso a longo prazo, por meio da satisfação do cliente e dos be-nefícios para todos os membros da organização e sociedade”.

A origem da qualidade total remonta à década de 1950. Armand Feigenbaum foi o primeiro a tratar a qualidade de forma sistêmica nas organizações, for-mulando 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, porém diferen-ciadas, do TQC: a visão japonesa, conhecida como CWQC (Company-wide Quality Control – que no Brasil foi traduzido para Qualidade por Toda a Em-presa ou Controle da Qualidade Amplo Empresarial) e a visão norte-americana do TQC.

O CWQC surgiu no Japão no final de década de 60. Kaoru Ishikawa teve importante papel no CWQC, contribuindo para sua formulação. Em alguns livros, os autores traduzem o TQC japonês da seguinte forma: o compromisso para a qualidade total, enal-tecendo o envolvimento e comprometimento dos funcionários com essa prática, aliado ao apoio da alta direção da empresa.

Outro ponto central do CWQC é o gerenciamento pelas diretrizes, que direciona o foco organizacional às metas da organização por meio do desdobramen-to dessas metas e do envolvimento e autonomia dos funcionários na gestão das atividades diárias da organização.

No TQC americano existe outro foco, que Feigen-baum define como um sistema eficaz para integrar a manutenção da qualidade e os esforços de melhoria da qualidade dos vários grupos na organização, de modo a possibilitar a produção em níveis mais eco-nômicos, permitindo alcançar a completa satisfação dos clientes.

Mesmo existindo diferenças entre as linhas de pensamento japonesa e americana, sobre o que vem a ser o TQC, na essência, o conceito é bastante similar. No Japão acontece um maior envolvimento e comprometimento dos funcionários nas atividades da gestão da qualidade e nos Estados Unidos existe muita ênfase à aplicação de métodos e técnicas asso-ciadas à qualidade. Outro ponto é que nos Estados Unidos a maior preocupação é com a detecção dos problemas e segregação dos produtos com defeitos e no Japão, as empresas desenvolvem processos capazes de detectar e evitar os problemas.

Após uma evolução, o TQC viria a se tornar o TQM (Gestão de Qualidade Total ou Total Quality Management). Esse termo surgiu em 1980.

A ideia central do TQM é que a qualidade esteja presente na função de gerenciamento organizacional, em uma tentativa de ampliar seu foco, não se limitando às atividades inerentes ao controle (CARVALHO; PA-LADINI, 2005).

Desde seu surgimento até meados da década de 1990, diversos estudos indicaram elementos que são considerados como fatores críticos que devem estar presentes no TQM. São eles: • Liderança e apoio da alta direção;• Relacionamento com os clientes;• Gestão da força de trabalho;• Relação com os fornecedores;• Gestão por processos;• Projeto de produto;• Fatos e dados da qualidade.

Modelos de ExcelênciaA qualidade total é bastante ampla, envolvendo diversas áreas fun-

cionais das organizações, mas também diferentes conceitos, que vão desde a liderança até os meios de controle nos processos produtivos. Uma evolução no conceito da qualidade total veio com a necessidade de incorporar os diversos interesses dos stakeholders (partes interessadas) de


uma organização na busca da excelência em desempenho. No passado, o acionista ou proprietário da organização era a maior parte interessada em seu desempenho, para o qual era dada a maior atenção e importância. Atualmente ele continua sendo mais importante, mas a alteração do enfoque considera hoje outros indivíduos, grupos de indivíduos, ou seja, agentes inte-ressados no desempenho de uma organização. Essa mudança ocorreu pelo fato de não ser suficiente que uma organização concentre seus esforços somente no desempenho financeiro. O enfoque deve considerar as pessoas e processos e os agentes internos e externos, que são formados pelos acionistas ou pro-prietários, pelos clientes da organização, pela força de trabalho, pelos funcionários e pela comunidade e sociedade.

Os modelos de excelência visam a avaliar a gestão de uma organização com relação às práticas de gestão utilizadas e os resultados organizacionais, de forma direcionada para atender às necessidades de seus stakeholders. As organizações descrevem as práticas organizacionais por meio de um re-latório, que é avaliado por especialistas. Posteriormente, as organizações recebem um relatório de avaliação, podendo ou não ser premiadas. A premiação é um reconhecimento das práticas de gestão.

Prêmio DemingEm junho de 1950, W. Edwards Deming foi ao Japão falar

sobre controle de qualidade, a convite da União da Ciência e Engenharia Japonesa (JUSE). Entre 1950 e 1952 Deming conse-guiu reunir e sensibilizar os principais executivos japoneses das grandes empresas e mostrou-lhes a importância do con-trole estatístico da qualidade (ABRANTES, 2001).

A convivência com os japoneses durou quase duas décadas, período em que as empresas japonesas fizeram uma verda-deira revolução, em termos de qualidade. Em agradecimento ao papel desempenhado, Deming era tratado como pai do controle de qualidade no Japão e seu nome tornou-se o Prêmio Japonês da Qualidade – Deming Prize (CARVALHO; PALA-DINI, 2005).

O modelo de excelência Deming Prize ou Prêmio Deming, foi o primeiro prêmio da qualidade lançado no mundo, visando a avaliar o desempenho das organizações. Ele foi aberto para organizações não japonesas em 1984. O julgamento do prêmio é baseado em dez critérios principais:1. Política;2. Organização e sua Operação;3. Informação;4. Padronização;5. Recursos Humanos;6. Garantia da Qualidade;7. Manutenção;8. Melhoria;9. Efeitos (Resultados);10. Planos Futuros.

Atualmente o Japão conta com um outro modelo de exce-lência, chamado Japan Quality Award. Ele é dividido em oito

critérios e apresenta um critério especificamente direcionado à responsabilidade social, considerando resposta aos requisitos sociais e contribuição para a sociedade.

Malcolm Baldrige National Quality Award Em 1987, para aumentar a competitividade nas empresas

americanas, os Estados Unidos lançaram o Malcolm Baldrige National Quality Award, esse modelo foi uma das tentativas de resposta para responder à invasão de produtos japoneses naquele país.

O principal objetivo do prêmio nacional da qualidade americano é melhorar a competitividade das empresas ame-ricanas por meio da conscientização para a qualidade, do reconhecimento dos resultados de excelência em desempenho nas empresas americanas e da publicação desses resultados de sucesso das empresas premiadas, como fator de troca de informações e experiência.

Prêmio Europeu da Qualidade O Prêmio Europeu da Qualidade, EFQM (European Quality

Award), é a estrutura mais utilizada na Europa e é a base para a maioria dos prêmios de qualidade nacionais e regionais. É usado como ferramenta de avaliação para as empresas e tam-bém como modelo de gestão para definir como as organizações podem melhorar o desempenho. Sobre o modelo:• É uma estrutura para o sistema de gestão da organização;• Pode ser usado como parte de uma auto-avaliação;• Fornece um quadro de comparação com outras organizações;• 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, são alcançados através da liderança conduzindo a política e a estratégia, que é entregue através das pessoas, parcerias, recursos e processos. Ou seja, a ideia é que a satisfação do con-sumidor, funcionários e o impacto na sociedade são atingidos através de liderança, política de direção e estratégia, adminis-tração de pessoas, recursos e processos, levando, finalmente a excelência nos resultados da empresa.

Prêmio Nacional da Qualidade O Brasil também tem seu modelo de excelência chamado PNQ

(Prêmio Nacional da Qualidade), que é um importante incenti-vo à competitividade, na forma de avaliação de empresas que buscam alcançar reconhecimento em excelência daquilo que produzem e/ou comercializam, sejam produtos ou serviços. O prêmio é concedido em reconhecimento a empresas com operação no Brasil, após passarem por uma avaliação de suas práticas.

Em 1989, um grupo de estudos iniciou um estudo sobre o desenvolvimento de um prêmio brasileiro nos moldes dos exis-tentes no mundo, e em 1990 o Comitê Nacional de Qualidade e Produtividade considerou o estabelecimento de um prêmio


MEtoDoLoGIAS ÁGEIS

nacional, com participação no processo. Como resultado, em 11 de outubro de 1991 foi instituída a FPNQ (Fundação para o Prêmio Nacional da Qualidade), que mudou de nome em 2005 e passou a se chamar Fundação Nacional da Qualidade. Ela é formada por organizações públicas e privadas para ad-ministrar o PNQ.

A estrutura dos critérios de avaliação segue um enfoque sistêmico, que deve ser trabalhado na forma de estratégias e planos de ação da empresa (Figura 4).

Os oito Critérios de Excelência referem-se a:1. Liderança2. Estratégias e Planos3. Clientes 4. Sociedade5. Informações e Conhecimento6. Pessoas7. Processos8. Resultados

Os oito Critérios de Excelência se subdividem em 24 Itens, conforme o ilustrado na Figura 5.

Programa de Qualidade 8SEm maio de 1950, o Centro de Educação para a Qualidade no

Japão, com a equipe do Dr. Kaoru Ishikawa, criou um modelo prático para o combate às causas de perdas e desperdícios. O mo-delo foi nomeado de Regra dos 5S, que é formado pelas palavras japonesas Seiri, Seiton, Seiso, Seiketsu e Shitsuke. Estas palavras podem ser traduzidas para o português, sem perderem o sentido, da seguinte forma: Utilização, Ordenação, Limpeza, Bem-Estar e Autodisciplina.

No Japão, existem empresas que já acrescentaram mais 3S aos cinco já existentes. São eles: Shikari Yaro (Determinação e União), Shido (Treinamento), Setsuyaku (Economia e Combate aos Des-perdícios). Dessa forma, o 5S passa a ser o Programa 8S, que é uma metodologia que promove a mudança de comportamento de dirigentes e funcionários, que passam a formar um grupo unido com visão de sobrevivência e continuidade dos negócios, princi-palmente através das sugestões de melhorias dos funcionários.

O Programa 8S depende totalmente da ação das pessoas (Figura 6); assim sendo, três fatores são fundamentais para a educação, treinamento e mudança de comportamento: motivação, liderança, e comunicação (ABRANTES, 2001).

No final da década de 1980, surgiu o programa de Gestão da Qualidade, na Motorola, chamado Seis Sigma que será detalhado e estudado ainda neste artigo.

CMMIEsta seção tem por objetivo introduzir o conceito de CMMI,

expondo como o modelo surgiu, quais são seus propósitos, Figura 4. Modelo de excelência do PNQ (Fonte: (FNQ, 2009)).

Figura 5. Subdivisões dos Critérios de Excelência PNQ (Fonte: (FNQ, 2009))


estrutura, componentes e abordagens, de modo a fornecer um contexto claro para os níveis de maturidade 4 e 5 que serão mapeados neste artigo.

Figura 6. Programa 8S (Fonte: (ROCHA, 2009))

Histórico do modeloEm 1991, o Software Engineering Institute (SEI), da Univer-

sidade 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 contínua, trazendo discipli-na e controle no desenvolvimento e manutenção do software (BARTIÉ, 2002). Desta forma, passou a servir como uma das principais referências de modelo de qualidade para o mercado de empresas de software.

Com o passar do tempo, observou-se que variações aplicáveis a outras disciplinas, tais como engenharia de sistemas, aquisi-ção de software, gestão e desenvolvimento de mão-de-obra e desenvolvimento integrado de produtos e processos, surgiram de acordo com as diferentes necessidades das organizações. Como cada um destes modelos possuía a sua própria arqui-tetura e abordagem de implementação, a sua utilização por organizações que possuíam processos integrados envolvendo várias destas disciplinas tornou-se difícil devido aos altos custos de treinamento, avaliação e ações de melhoria.

Diante deste cenário, o CMMI (Capability Maturity Model Integration) foi criado pelo SEI em 2002 como um modelo evo-lutivo em relação aos vários CMMs, com o objetivo de combinar as suas várias disciplinas em uma estrutura única, flexível e componentizada (Figura 7), que pudesse ser utilizada de forma integrada por organizações que demandavam processos de melhoria em âmbito corporativo (FERNANDES, 2008).

A versão 1.2 do CMMI foi publicada pelo SEI em agosto de 2006, trazendo um conjunto de melhorias e simplificações em relação à versão anterior. Com o documento CMMI for Deve-lopment (CMMI para Desenvolvimento), houve a unificação do tratamento das disciplinas de engenharia de software, en-genharia de sistemas, desenvolvimento integrado de produto

e processo e terceirização, além do conceito de “constelações” na arquitetura do modelo, que permite a sua expansão para outros focos, tais como aquisições e entrega de serviços.

Figura 7. CMMI - Integração dos Modelos CMM

Definição e objetivos do modeloO CMMI (Capability Maturity Model Integration) é um mo-

delo de maturidade de melhoria de processos para desenvol-vimento de produtos e serviços. (CMMI, 2006). Seu principal propósito é fornecer diretrizes baseadas nas melhores práticas voltadas para atividades de desenvolvimento e manutenção, abrangendo todo o ciclo de vida do produto, desde a concepção, desenvolvimento, aquisição até a entrega e manutenção. As abordagens do CMMI envolvem a avaliação da maturidade da organização ou a capacitação das suas áreas de processo, o estabelecimento de prioridades e a implementação de ações de melhorias (FERNANDES, 2008).

Estrutura do modeloVisão Geral

O modelo possui duas abordagens: contínua e por estágios, permitindo à organização optar pela mais adequada a seu contexto. Atendendo a requisitos de “componentização”, a versão 1.2 do CMMI apresenta tais abordagens reuni-das em um mesmo documento, dentro do escopo de cada constelação.

Uma constelação é uma coleção de componentes do CMMI que compreende um modelo, seus materiais de treinamento e documentos relacionados à avaliação para uma área de in-teresse. “Adições” podem ser usadas para expandir constela-ções com conteúdos específicos adicionais. Atualmente, três constelações são suportadas pela versão 1.2 do CMMI:• CMMI for Development (CMMI-DEV) – fornece diretivas para monitoração, medição e gerenciamento de processos de desenvolvimento. Pode ser estendido através da adição para o Desenvolvimento Integrado de Produto e Processo (IPPD);• CMMI for Services (CMMI-SVC) – fornece diretivas para entrega de serviços dentro das organizações e para clientes externos;• CMMI for Acquisition (CMMI-ACQ) – fornece diretivas para suporte às decisões relacionadas à aquisição de produtos e serviços.


MEtoDoLoGIAS ÁGEIS

Componentes do ModeloOs componentes do modelo se agrupam em três categorias

que indicam como interpretá-los:• Componentes requeridos: descreve o que uma organização deve realizar para satisfazer uma área de processo. Devem ser visivelmente implementados nos processos de uma orga-nização. Os componentes requeridos no CMMI são as metas específicas e as metas genéricas. A satisfação das metas é utilizada em avaliações como base para determinar se uma área de processo foi realizada e satisfeita;• Componentes esperados: descreve o que uma organização pode implementar para realizar um componente requerido. Orientam os que implementam melhorias ou executam ava-liações. Incluem as práticas específicas e as práticas genéricas. Antes que os objetivos possam ser considerados satisfeitos, as práticas tal como descritas ou práticas aceitáveis alternativas a elas, deverão estar presentes nos processos planejados e implementados da organização;• Componentes informativos: proporciona detalhes que aju-dam as organizações a começar a pensar em como se aproximar dos componentes requeridos e esperados. As sub-práticas, os produtos de trabalho típicos, ampliações, a elaboração das práticas genéricas, os títulos de metas e práticas, as anotações de metas e práticas, e as referências são exemplos de compo-nentes informativos do modelo.

A Figura 8 representa esquematicamente os componentes e seus relacionamentos. A descrição de cada componente é feita em seguida.

Figura 8. Componentes da Estrutura do CMMI (Fonte: Adaptação (CMMI, 2006))

• Áreas de Processo: é um grupo de práticas 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 introdutórias: descreve os principais conceitos com-preendidos pela área de processo;

- Áreas de Processo Relacionadas: lista referências a áreas de processo relacionadas e reflete as relações de alto nível entre as áreas de processo.

• Metas Específicas: são metas relacionadas a uma deter-minada área de processo, que descrevem o que deve ser realizado para assegurar que esta esteja definitivamente implementada;• Metas Genéricas: se denominam “genéricas” porque a mes-ma declaração da meta se aplica a múltiplas áreas de processo. Descreve as características que devem estar presentes para institucionalizar os processos que implementam uma área de processo;• Práticas Específicas: descreve as atividades consideradas importantes para alcançar uma meta específica associada. Subcomponentes informativos:- Produtos de Trabalho Típicos: lista exemplos de resultados de uma prática específica.- Subpráticas: descrições detalhadas que proporcionam uma orientação para interpretar e implantar uma prática específica ou genérica.

• Práticas Genéricas: se denominam “genéricas” porque a mesma prática se aplica a múltiplas áreas de processo. Descreve as atividades consideradas importantes para alcançar uma meta genérica associada.Subcomponentes informativos:- Elaboração de Práticas Genéricas: proporciona um guia sobre como a prática genérica deveria aplicar-se de forma exclusiva à área de processo.

• Componentes Informativos de Suporte: informação adicio-nal necessária para descrever um conceito. São eles:- Notas: pode proporcionar detalhes, fundamentação teórica ou premissas/restrições relacionadas ao componente;- Exemplos: texto ou lista provendo um ou mais exemplos para esclarecer um conceito ou atividade descrita;- Ampliações: nota ou exemplo relevante para uma disciplina particular. As disciplinas cobertas neste modelo são Engenha-ria de Hardware, Engenharia de Sistemas e Engenharia de Software. Cada amplificação é rotulada com um cabeçalho que indica à qual disciplina se aplica;- Referências: indicação para informação adicional ou mais detalhada em áreas de processo relacionadas.

Abordagens de ImplementaçãoComo mencionado anteriormente, o CMMI possui duas abor-

dagens. Para desenvolvimento deste artigo, utilizamos como base a abordagem de implantação por estágios, devido à sua grande aderência no mercado e maior proximidade com os demais mo-delos CMMI que também utilizam níveis de maturidade para mensurar a qualidade dos processos organizacionais. Dessa maneira, daremos a esta representação um foco especial.

Objetivamente, podemos descrever as abordagens da se-guinte maneira:


• Abordagem contínua: permite que a organização selecione uma área de processo (ou um grupo de áreas de processo) e melhore os processos relacionados. Essa representação utiliza seis níveis de capacidade (numerados de 0 a 5) para caracterizar melhorias relativas a uma área de processo individual;• Abordagem por estágios: utiliza grupos pré-definidos de áreas de processo (PAs) para definir um caminho de melho-ria para uma organização. Este caminho é caracterizado por cinco níveis de maturidade (numerados de 1 a 5). Cada nível de maturidade contém uma série de áreas de processo que caracteriza diferentes condutas organizacionais.

A Figura 9 ilustra a estrutura de ambas as abordagens evi-denciando suas diferenças: níveis de capacidade x níveis de maturidade.

Figura 9. Estruturas das abordagens contínua e por estágios (Fonte: Adaptação (CMMI, 2006))

A Tabela 2 faz uma comparação entre os seis níveis de ca-pacidade e os cinco de maturidade. Como se pode observar, o ponto de início é diferente para as duas implementações, visto que não há nível 0 para a abordagem por estágios.

NívelNíveis de Capacidade da Abordagem

Contínua

Níveis de Maturidade da

Abordagem por Estágios

Nível 0 Incompleto ---

Nível 1 Executado Inicial

Nível 2 Gerenciado Gerenciado

Nível 3 Definido Definido

Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente

Nível 5 Otimizado Otimizado

tabela 2. Comparação dos níveis de capacidade e maturidade (Fonte: Adaptação (CMMI, 2006))

Níveis de MaturidadePara dar suporte àqueles que utilizam a abordagem por es-

tágios, todos os modelos CMMI trazem níveis de maturidade em seu desenho e conteúdo (Figura 10).

Um nível de maturidade pode ser considerado um degrau evolucionário para a melhoria do processo organizacional como um todo e consistem em práticas específicas e genéricas que integram um conjunto predefinido de áreas de processo. O cumprimento das metas específicas e genéricas correspondentes a estas áreas de processo é um pré-requisito para o alcance do nível de maturidade correspondente (FERNANDES, 2008).

Figura 10. Níveis de Maturidade do CMMI (Fonte: Adaptação (CITS, 2009))

A seguir são descritas as principais características de cada nível de maturidade e as áreas de processo pertencentes aos mesmos. Como o foco deste trabalho é relacionar as práticas do modelo de qualidade Seis Sigma com os altos níveis de maturidade do CMMI, os níveis 4 e 5 serão expostos de forma mais detalhada nos próximos capítulos.• Nível 1 – Inicial:É o nível de maturidade mais baixo. Em geral, as organizações desse nível têm processos imprevisíveis que são pobremente controlados e reativos. Nesse nível de maturidade os processos são normalmente “ad hoc” e caóticos. A organização geralmente não fornece um ambiente estável. Áreas de Processo: Não há.• Nível 2 – Gerenciado:Neste nível, o foco é o gerenciamento básico de projetos da or-ganização, proporcionando-lhes a garantia de que os requisitos são gerenciados, planejados, executados, medidos e controlados. Quando essas práticas são adequadas, os projetos são executados e controlados de acordo com o planejado. Áreas de Processo: Gestão de Requisitos (REQM), Planejamento do Projeto (PP), Controle e Monitoração do Projeto (PMC), Gestão do Acordo com o Fornecedor (SAM), Medição e Análise (MA), Garantia da Qualidade de Processo e do Produto (PPQA) e Gestão da Configuração (CM).• Nível 3 – Definido:Neste nível, processos são bem caracterizados, compreendidos e descritos em padrões, procedimentos, ferramentas e métodos. O conjunto de processos padrão da organização, que é a base para o nível 3 de maturidade, é estabelecido e melhorado ao longo do tempo. Esses processos padronizados são usados para estabelecer consistência em toda a organização. Todos os projetos utilizam


MEtoDoLoGIAS ÁGEIS

uma versão de um desses processos padrão adaptando-a às suas características especificas.Áreas de Processo: Desenvolvimento de Requisitos (RD), Solução Técnica (TS), Integração do Produto (PI), Verificação (VER), Vali-dação (VAL), Foco no Processo Organizacional (OPF), Definição do Processo Organizacional (OPD), Treinamento Organizacional (OT), Gestão Integrada do Projeto (IPM), Gestão de Riscos (RSKM), Análise de Decisões e Resolução (DAR).

• Nível 4 – Gerenciado Quantitativamente:A gestão quantitativa baseada em medições 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, são controlados estatisticamente.Áreas de Processo:- Desempenho do Processo Organizacional (OPP) – Tem por objetivos: estabelecer e manter uma visão quantitativa do de-sempenho dos processos padrões, e prover modelos e baselines de desempenho, visando melhorar a gestão dos projetos através de métricas de processo e produto.- Gestão Quantitativa do Projeto (QPM) – Tem por objetivo geren-ciar quantitativamente (através de métricas) o processo definido do projeto, visando o alcance dos objetivos preestabelecidos de desempenho de qualidade e processo.

• Nível 5 – Otimizado:Neste nível, os processos são continuamente aperfeiçoados com base em um entendimento quantitativo no qual a variação de um processo existe devido às interações, normais e presumidas, entre seus componentes. Esse nível de maturidade tem como objetivo a melhoria contínua do processo.Áreas de Processo:- Inovação e Desenvolvimento Organizacional (OID) – Tem por objetivo selecionar e implantar melhorias incrementais e inova-ções nos processos e nas tecnologias que promovam, quantitati-vamente, o aumento da habilidade da organização para cumprir os seus objetivos de desempenho de processos e qualidade.- Análise e Resolução de Causas (CAR) – Tem por objetivo identificar causas de defeitos e outros problemas e tomar ações corretivas para prevenir a sua ocorrência futura.

A Figura 11 representa de forma resumida, os níveis de maturi-dade, seus principais focos e áreas de processo envolvidas.

Benefícios do ModeloA utilização do modelo CMMI inclui uma série de bene-

fícios significativos e quantificáveis para a organização que o utiliza na melhoria de seus processos e podem ser categorizados e resumidos por: custo, prazo, produtivi-dade, qualidade, satisfação dos clientes e Retorno sobre o Investimento (ROI – Return on Investment).

Em 2006, o SEI publicou um relatório técnico (Perfor-mance Results of CMMI - Based Process Improvement) apresentando dados quantitativos de 35 organizações, entre elas grandes empresas com mais de uma organiza-ção constituinte (SEI, 2006). Os esforços no processo de melhoria dessas organizações incluem tanto pequenas como grandes unidades organizacionais que atuam em uma variedade de setores e domínios do mercado. Foram aplicadas as práticas do modelo CMMI para engenharia de software, engenharia de sistemas, e outras disciplinas de engenharia. Enquanto a maioria dos resultados vem de organizações de maior maturidade, melhorias notáveis também foram alcançadas pelas organizações de menor maturidade. Todas as organizações no relatório explici-tamente atribuem suas realizações a orientação fornecida pelo CMMI.

A Tabela 3 resume a média percentual de melhorias nas cinco categorias apresentadas.

Figura 11. Os Níveis de Maturidade e suas Áreas de Processo

Categoria Percentual Médio Exemplos

Custo Redução de 34% Redução dos custos de retrabalho, remoção de defeitos, overhead de projetos.

Prazo Melhoria de 50% Redução do número de dias de atraso de aproximadamente 50 para menos de 10.

Produtividade Aumento de 61% Aumento na quantidade de linhas de código por pessoa/dia, aumento do número de releases de software liberados por ano.

Qualidade Aumento de 48% Redução dos defeitos encontrados e das requisições de mudança no sistema em ambiente de produção.

Satisfação dos Clientes Aumento de 14% Aumento em 55% comparado ao SW-CMM nível 2 e 10% comparado ao nível 5.

Retorno sobre o Investimento 4,0 : 1 Retorno de 5:1 em relação às horas investidas em atividades de qualidade.

tabela 3. Benefícios Quantitativos da Utilização do CMMI (Fonte: Adaptação (SEI, 2006))


SEIS SIGMAEste tópico tem por objetivo introduzir o conceito de Seis

Sigma como modelo de gestão da qualidade, expondo o seu histórico, propósito, certificações relacionadas e metodologias criadas a partir de sua concepção. A aplicação na melhoria dos processos de qualidade de software e a estrutura da metodo-logia serão detalhadas no tópico seguinte, no qual será feito o mapeamento entre suas práticas no apoio à implementação dos níveis de maturidade 4 e 5 do CMMI.

Histórico do ModeloAs origens do Seis Sigma como um padrão de medição vêm

dos trabalhos de Carl Frederick Gauss (1777-1855), que intro-duziu o conceito da curva normal ou curva de Gauss. As raízes do Seis Sigma como um padrão de medição da variação dos produtos podem ser rastreadas até a década de 1920, quando Walter Shewhart mostrou que a partir de três desvios padrões ou três “sigmas” da média, o processo requer correção. Muitos padrões de medição (CPK, Zero Defeitos, etc.) entraram em cena posteriormente, dando base para o movimento da quali-dade total, liderado mais tarde por Edward Deming e outros profissionais militantes da qualidade (ISIXSIGMA, 2009a).

No início e meados dos anos 80, com o presidente Bob Galvin na direção, engenheiros da Motorola decidiram que os níveis tradicionais de qualidade – medição de defeitos em milhares de oportunidades – não forneciam granularidade suficiente. Esta conclusão partiu de informações vindas da força de vendas, a respeito da grande quantidade de reclamações de uso de garantias pelos clientes. Para reverter este quadro, eles deter-minaram a necessidade de medir os defeitos por milhões de oportunidades. Desta forma, a Motorola desenvolveu este novo padrão, criou a metodologia e, em 1986, o termo “Seis Sigma” foi cunhado pelo engenheiro da Divisão de Comunicações da Motorola, Bill Smith (Figura 12).

Figura 12. 1986: Processo de qualidade Seis Sigma (Fonte: Adaptação (MOTOROLA, 2009))

Em 1987, foi lançado um ambicioso programa por Bob Gal-vin visando a redução de defeitos nos produtos para “seis sigma” ou 3,4 defeitos por milhões 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 organização, documentando mais de 16 bilhões de dólares

em economias como resultado de seus esforços com o Seis Sigma. Tais resultados concederam à companhia a conquista do prestigioso prêmio Malcolm Baldrige National Quality Award (MBNQA) em 1988.

Em 1991, a Motorola introduziu treinamentos para a formação de especialistas em Seis Sigma, que foram denominados “black belts”. Em 1992, a metodologia passou a ser adotada por outras indústrias, incluindo seguros, serviços financeiros, saúde, etc.

Em 1999, a Motorola, através da Motorola University, começou a ensinar o Seis Sigma para outras organizações de sua cadeia de valor (fornecedores e clientes) e também para outras indústrias.

Em 2001, o agora ex-CEO da General Electric (GE), Jack Welch, dedicou um capítulo 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 próprias palavras, “Tornei-me um fanático pelo Seis Sigma” e “O Seis Sigma tornará a GE a maior empresa do mundo dos negócios”. De fato, o modelo ge-rou no ano de 2000 mais de 2,4 bilhões de dólares em benefícios (Figura 13), enquanto no mesmo período a GE teve a maior valorização de suas ações na história (Figura 14).

Figura 13. Benefícios do Seis Sigma na GE (1996-2000) (Fonte: Adaptação (VASQUES, 2006))

Figura 14. Situação das Ações 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 negócios, ou seja, seu foco se alargou para além da melhoria da qualidade em produ-tos. Um dos idealizadores deste programa, Michel Harry,


MEtoDoLoGIAS ÁGEIS

define o Seis Sigma como uma estratégia que não deve estar encapsulada na área de qualidade, devendo espalhar seus “tentáculos” por toda a organização, da manufatura e engenharia à área de serviço.

Em 2004, a Motorola obteve receitas 42% maiores e um lucro por ação 257% maior do que no primeiro trimestre do ano fiscal anterior com o uso do Seis Sigma em todos os seus processos (FERNANDES, 2008).

Definição e Objetivos do ModeloDiferentemente de outros programas de qualidade, as empresas

que utilizam o Seis Sigma divulgam cifras milionárias de ganhos obtidos com sua implementação. Desta maneira, podemos con-cluir que o Seis Sigma é mais do que apenas um sistema de qua-lidade como o TQM ou ISO. É uma maneira de fazer negócios.

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 fácil listar todas as coisas que a qualidade Seis Sigma não é. Seis Sigma pode ser visto como: uma visão; uma filosofia; um símbolo; uma métrica; um objeti-vo; uma metodologia”. (ISIXSIGMA, 2009a). A estas descrições pode-se acrescentar ainda: uma estratégia organizacional, um modelo de gestão, um conjunto de ferramentas estatísticas ou um método de comparação (benchmarking) – 3,4 defeitos por milhão de oportunidades.

É comum encontrar diferentes, embora convergentes, definições sobre o que é Seis Sigma.

Para VASQUES (2006) da ISD Brasil (Integrated System Diagnostics Brasil), a definição mais completa e íntegra seria: “Metodologia de grande rigor analítico, baseada em projetos de melhorias de processos de negócio onde utilizamos um conjunto preestabelecido de ferramentas (tipicamente estatísticas) que direciona a organização para uma mudança cultural profunda (filosofia), buscando sempre altos resultados financeiros e intenso foco nos clientes”.

Segundo CARVALHO e PALADINI (2005), o modelo de Gestão da Qualidade Seis Sigma é uma estratégia gerencial disciplinada, caracterizada por uma abordagem sistêmica e pela utilização intensiva do pensamento estatístico, que tem por objetivo reduzir drasticamente a variabilidade dos processos críticos e aumentar a lucratividade das empresas, por meio da otimização de produtos e processos, buscando satisfação de clientes e consumidores.

Os objetivos do Seis Sigma variam de acordo com os objetivos da melhoria, conforme a lista a seguir:• Redução de custos;• Melhoria da produtividade;• Crescimento de fatia de mercado;• Retenção de clientes;• Redução de tempo de ciclo;• Redução de defeitos;• Mudança cultural para a qualidade;• Excelência no desenvolvimento de produtos e serviços.

Ao contrário do “Total Quality Management – TQM”, que pretendia melhorar a qualidade de toda a organização, o Seis

Sigma procura melhorias que agreguem valor para o cliente e também pode ser aplicado para problemas localizados (FERNANDES, 2008).

Existem algumas estratégias para se alcançar uma produção com “zero erro”. PANDE, NEUMAN e CAVANAGH (2001) afirmam que há três estratégias Seis Sigma. As estratégias são: (i) estratégia de melhoria de processo; (ii) estratégia de projeto/reprojeto de processo; e, (iii) estratégia de gerenciamento de processo. A melhoria de processo refere-se à estratégia de desenvolver soluções com a finalidade de eliminar as causas-raiz dos problemas de desempenho de uma empresa, sem, no entanto, interferir na estrutura básica do processo. Na es-tratégia projeto/reprojeto de processo, o objetivo é substituir uma parte ou todo o processo por um novo. Já na estratégia de gerenciamento de processo, as exigências do cliente são claras e regularmente atualizadas, os processos são documentados e gerenciados com medições em todas as suas etapas. Nesta última estratégia, os gestores também usam as medições e o co-nhecimento do processo para avaliar os seus desempenhos.

A Figura 15 resume alguns métodos importantes do pro-grama Seis Sigma.

Figura 15. Métodos e ferramentas essenciais do programa Seis Sigma (Fonte: Adaptação (PANDE; NEUMAN; CAVANAGH, 2001))

Um programa Seis Sigma tem como requisitos:• Alinhar o esforço Seis Sigma aos objetivos do negócio;• Forte patrocínio da administração;• Focalizar em resultados de curto prazo;• Implantar uma nova forma de administração duradoura;• Tornar a aprendizagem uma tarefa contínua;• Selecionar os projetos corretos;• Ênfase em treinamento e capacitação de recursos humanos;• Definir claramente papéis e responsabilidades;• Forte liderança para a mudança.

O programa Seis Sigma foi batizado com o nome da letra grega sigma (σ), que representa o desvio-padrão em notação estatística, já evidenciando a grande ênfase na utilização destas ferramentas. O uso sistemático de ferramentas


estatísticas nos projetos tem como objetivo reduzir a varia-bilidade, até a obtenção da difícil meta de 3,4 defeitos por milhão (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 milhão.

Sigma Qualidade Defeitos por milhão

6 σ 99,9997% 3,4

5 σ 99,9767% 233

4 σ 99,379% 6.210

3 σ 93,32% 66.807

2 σ 69,1% 308.537

1 σ 31% 690.000 tabela 4. Qualidade e defeitos sigma (Fonte: Adaptação (FERNANDES, 2008))

Certificações e ResponsabilidadesExistem certificações profissionais para qualificar pessoas

como especialistas em Seis Sigma, relativas a “Black Belt”, “Green Belt” e outras. Ambas são 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 certificações (FERNANDES, 2008).

Os especialistas são responsáveis pela implantação da estra-tégia Seis Sigma. Sua formação é altamente focada em buscar soluções para a verdadeira causa dos problemas. Eles atuam como agentes de mudança na organização, aplicando e disse-minando o uso das ferramentas estatísticas 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 assegu-rar que seja fornecido o suporte necessário para obter bons resultados.

Existem duas certificações Seis Sigma da ASQ (ASQ, 2009a): A Six Sigma Green Belt Certification (SSGB) e a Six Sigma Black Belt Certification (SSBB). Seus criadores atribuíram tais títulos (“faixa verde”, “faixa preta”), pois acreditam que as certifica-ções têm habilidades em comum com as artes marciais.

Six Sigma Green Belt Certification – SSGBPapel na empresa

Esse profissional auxilia na coleta e análise de projetos de Black Belt. Lidera a resolução de problemas em projetos de Green Belt e outras equipes, de acordo com sua experiência.

Requisitos de experiênciaTrês anos de experiência de trabalho em uma ou mais áreas

do Seis Sigma Green Belt. Esta certificação não é um requisito para a Certificação Seis Sigma Black Belt.

Expectativas e atribuições mínimas para um SSGB

• Operar em apoio ou sob a supervisão de um Six Sigma Black Belt.• Analisar e resolver problemas de qualidade.• Envolvimento em projetos de melhoria da qualidade.• Participação em um projeto, mas não conduzí-lo sozinho.• Ter pelo menos três anos de experiência de trabalho.• Ter capacidade de demonstrar seu conhecimento das ferra-mentas do Seis Sigma e dos processos. (ASQ, 2009c)

ExameOs candidatos à certificação precisam passar por um exame

escrito que consiste em perguntas de múltipla escolha para medir a compreensão Six Sigma Green Belt Body of Knowledge (Corpo de Conhecimentos do Seis Sigma Green Belt). A prova dura quatro horas, tem 100 questões e é feita no idioma inglês, caso seja feita pela ASQ. Cada participante deve levar seu próprio material de referência, pois o exame é “open-book” (com consulta).

O comitê que prepara o exame utiliza o Six Sigma Green Belt Body of Knowledge como orientação para escrever as pergun-tas do teste. Este foi feito para ajudar a preparar os candidatos a identificar o conteúdo específico dentro de cada tema que pode ser cobrado.

Os exames são realizados duas vezes por ano, em junho e dezembro, pela ASQ e organizações internacionais.

Six Sigma Black Belt Certification – SSBBPapel na empresa

O profissional que possui a certificação Six Sigma Black Belt, está habilitado a explicar a filosofia e os princípios do Seis Sigma, incluindo sistemas de apoio e ferramentas. O Black Belt tem que demonstrar liderança, entender a dinâmica da equipe, saber resolver problemas em projetos, atribuir funções e responsabilidades aos membros e também preparar equipes de projeto. Também possui um profundo conhecimento dos aspectos do modelo DMAIC de acordo com os princípios do Seis Sigma.

Requisitos de experiênciaPara a certificação é preciso ter realizado dois projetos completos

e certificados/aprovados, ou ter finalizado um projeto certificado/aprovado e mais três anos de experiência em uma ou mais áreas do Seis Sigma Black Belt Body of Knowledge. A certificação Seis Sigma Green Belt não é requisito para este exame.

Expectativas e atribuições mínimas para um SSBBSegundo recomendação da American Society for Quality

(ASQ, 2009b), podemos citar:• Será capaz de explicar a filosofia e os princípios do Seis Sig-ma, incluindo sistemas e ferramentas (qualidade, processos / melhoria contínua, etc.), e poderá descrever seu impacto nos diversos processos de negócios em toda a organização;• Conhecer várias guias e saber sobre funções e responsabili-dades no Seis Sigma. Ao reconhecer obstáculos na organização, deverá ser capaz de utilizar técnicas de gestão de mudança para gerir a mudança organizacional;


MEtoDoLoGIAS ÁGEIS

• Será capaz de definir benchmarking, entender sobre várias medidas financeiras e outras de desempenho de negócios. 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 compreensão fundamental dos componentes e técnicas utilizados na gestão de equipes, incluindo o tempo de gestão, planejamento e ferramentas de tomada de decisão, formação de equipe e avaliação de desempenho e gratifica-ção. Saberá como usar as técnicas adequadas para superar os diferentes desafios da dinâmica de grupo;• Entenderá os elementos de um relatório do projeto (defi-nição do problema, escopo, metas, etc.) e será capaz de usar vários instrumentos para acompanhar seu andamento;• Será capaz de usar o feedback do cliente para determinar suas necessidades;• Terá um conhecimento básico sobre técnicas de coleta de dados, elementos do processo e suas ferramentas de análise;• Terá um con hecimento básico sobre sistemas de medição;• Terá um conhecimento básico de conceitos de probabili-dade e distribuições;• Será capaz de realizar cálculos estatísticos e de capacidade do processo;• Será capaz de realizar testes de hipóteses e analisar seus resultados;• Será capaz de utilizar várias ferramentas para eliminar o desperdício e reduzir o tempo de ciclo;• Terá uma compreensão fundamental de como implemen-tar 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.

ExameOs candidatos à certificação precisam passar por um exame

escrito que consiste em perguntas de múltipla escolha para medir a compreensão Six Sigma Black Belt Body of Knowledge (Corpo de Conhecimentos do Seis Sigma Black Belt). A prova dura quatro horas, tem 150 questões e é feita, pela ASQ, no idioma inglês. Assim como no exame para Green Belt, cada participante deve levar seu próprio material de referência, pois o exame é “open-book” (com consulta).

Os exames são realizados duas vezes por ano, em março e outubro, pela ASQ e organizações internacionais.

Resumo dos papéis da equipeA Tabela 5 mostra a descrição resumida dos papéis compo-

nentes de uma equipe Seis Sigma.

Metodologias do 6 SigmaEsta seção apresenta as principais metodologias existentes

no Seis Sigma, abordando suas definições, conceitos e aplica-bilidade. As metodologias DMAIC e DFSS são utilizadas na eliminação dos defeitos de um processo ou produto.

O modelo DMAICO DMAIC foca na robustez e simplificação dos processos,

visando diminuir o nível de defeitos, o aumento da satisfação dos clientes e a lucratividade da organização. O DMAIC é um aperfeiçoamento do processo Seis Sigma que passa por cinco fases: definir (define), medição (measure), análise (analyze), aperfeiçoamento (improve) e controle (control). Existem diversas ferramentas que são utilizadas de maneira integrada às fases do DMAIC, constituindo um método sistemático, disciplinado, baseado em dados e no uso de ferramentas estatísticas para se atingir os resultados almejados pela organização (CARVALHO; PALADINI, 2005).

Papel exercido no Seis Sigma Pessoa

Executivo Líder

É o principal executivo da empresa. Responsável pela implantação do Seis Sigma. Essa pessoa deve ter total comprometimento, pois ele é indispensável

para o sucesso da implantação da estratégia de melhoria. Deve conduzir, incentivar e supervisionar as iniciativas do programa Seis Sigma em toda

a empresa.

Champions Deve liderar os executivos-chave da organização rumo ao programa Seis Sigma. É responsável por organizar e guiar o começo, o desdobramento e a

implementação do Seis Sigma em toda a organização.

Master Black Belts

Ajuda o campeão na tarefa de implantar o Seis Sigma na organização. Também ajuda o campeão na escolha e no treinamento de novos projetos de

melhoria, oferecendo liderança técnica 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.

Black BeltsOs Black Belts dedicam 100% do tempo aos projetos Seis Sigma, assim como os Master Black Belts, recebendo treinamento intensivo em técnicas

estatísticas e de solução de problemas. Lideram equipes na condução dos projetos e são capazes de treinar até 100 Green Belts ao ano.

Green Belts

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 atuação.

Yellow BeltsParticipam como membros das equipes de projeto supervisionando a utilização das ferramentas Seis Sigma na rotina da empresa e executam

projetos mais focados e de desenvolvimento mais rápido que os executados pelos Green Belts.

White BeltsNão faz parte de uma equipe de projeto. São do nível operacional. Dão suporte aos Black Belts, Green Belts e Yellow Belts na implementação dos

projetos. São executores de ações, garantindo que os resultados alcançados sejam mantidos no longo prazo, na operação da rotina da empresa.

tabela 5. Papéis da equipe Seis Sigma (Fonte: Adaptação (GRUPO WERKEMA, 2008))


Primeira fase: Define (definir as prioridades)A primeira fase consiste em definir quais são os requisitos

do cliente (voz do cliente) e traduzir essas necessidades em Características Críticas para a Qualidade (CTQ – Critical to Quality). Esta etapa torna-se fundamental por levar a visão do cliente para dentro da empresa. Os objetivos dos projetos Seis Sigma de melhoria têm de estar relacionados a um CTQ.

Os desenhos dos processos críticos são feitos por uma equipe preparada para aplicar as ferramentas Seis Sigma e procuram identificar aqueles que têm relação com os CTQs do cliente e que estão gerando resultados ruins, como reclamações de clientes, problemas funcionais, problemas trabalhistas, baixa qualidade de suprimentos, altos custos de mão-de-obra, erros de forma, ajuste e funcionamento etc. Logo após, a equipe realiza uma análise custo-benefício do projeto, de modo a ter uma visão 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 saídas.

Para cada processo, deve-se utilizar o sistema de medição adequado. Em seguida, a equipe coleta os dados do processo por meio de um sistema que produza amostras representativas e aleatórias. Com isso, os índices de capacidade do processo a curto e longo prazos são determinados.

Terceira fase: Analyze (identificação das principais causas)A equipe Seis Sigma, na terceira fase, faz a análise dos dados

coletados, que é uma importante função da metodologia. Para esse trabalho, além de utilizar as ferramentas tradicionais da qualidade, são utilizadas ferramentas estatísticas de modo a identificar as causas óbvias e as causas não óbvias. A utiliza-ção de ferramentas estatísticas de forma competente e prática é uma das forças da metodologia. A estatística passa a ser a principal ferramenta a ser utilizada pela equipe, quando evoluímos para uma visão de que os processos devem ser a principal ferramenta a ser utilizada pela equipe.

Nesta fase, é imprescindível a utilização de software esta-tístico, que facilita muito o trabalho da equipe nos cálculos e desenha os gráficos necessários. A equipe consegue descobrir as causas geradoras dos defeitos e as fontes de variações nos processos.

Quarta fase: Improve (eliminação das causas dos defeitos)Na fase de aperfeiçoamento, a equipe deve fazer as melho-

rias no processo existente. Os dados estatísticos devem ser transformados em dados do processo, e a equipe deve estudar tecnicamente quais transformações deve executar. A equipe pode vir a ter que resolver problemas, pois podem ocorrer modificações técnicas do processo. O trabalho da equipe será modificar os elementos das atividades de transformação, atuando sobre as causas-raiz.

Essa é considerada uma fase crítica, onde as melhorias se materializam no processo, quando a equipe interage com as pessoas que executam as atividades.

As equipes promovem melhorias nas variáveis vitais do processo e realizam a quantificação dos efeitos nas CTQs, ou seja, nas metas financeiras e de desempenho (CARVALHO; PALADINI, 2005). Depois, deve testar as soluções, pois a equipe começa a passar para o pessoal operacional a responsabilidade de executar o processo modificado.

Quinta fase: Control (manutenção das melhorias)Nesta fase, pode surgir a seguinte pergunta: por que ir além

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 bagunçado no futuro, caso não esteja sob controle, e isso pode fazer a capacidade voltar para os níveis do início do projeto Seis Sigma.

A equipe deve definir como serão feitos esses controles e passar essa informação para aqueles que trabalham no pro-cesso normalmente no dia-a-dia. Também 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 medição e controle.

O monitoramento dos pontos (Xs) críticos é fundamental não só para manter a capacidade do processo estabelecida, mas para indicar melhorias futuras. O outro ponto (Y), que é a saída do processo, deve ser controlado para garantir que os resultados sejam conforme o planejado.

É elaborada a documentação do processo por meio de méto-dos estatísticos de controle de processo, além do monitoramen-to das novas condições do processo. A capacidade do processo é reavaliada para garantir que os ganhos sejam mantidos. A reavaliação pode mostrar no resultado, que pode ser necessário rever uma ou mais fases precedentes do processo.

A implementação 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 experiência de outra (CARVALHO; PALADINI, 2005).

O modelo DFSS (Design For Six Sigma)A metodologia lida com a qualidade no projeto de novos pro-

dutos e pode ser aplicada a processos produtivos e de serviços que precisam ser constituídos de forma que, ao estarem em funcionamento, já atinjam o nível Seis Sigma e também surgiu para preencher uma lacuna no DMAIC.

O DFSS também pode ser aplicado a processo nos quais seu nível de desempenho esteja tão baixo, e o próprio processo esteja tão ruim, que quaisquer esforços aplicados para se re-alizar um projeto DMAIC não resultarão em um processo de nível Seis Sigma. Ou seja, pode-se projetar um novo produto ou serviço, ou reprojetar um produto ou serviço já existente (CARVALHO; PALADINI, 2005).


MEtoDoLoGIAS ÁGEIS

Nesta metodologia existem ferramentas que podem reduzir custos e melhorar a qualidade, mas principalmente adicionar valor ao produto por meio de inovações e do atendimento das reais necessidades dos clientes. Como a qualidade do produto/processo é projetada, e não melhorada, o DFSS é o programa apontado como a única forma de atingir o nível Seis Sigma na qualidade. Para isso, é adotada a metodologia DMADV (definição, medição, análise, projeto e verificação) que também possui cinco fases bem definidas:• Definir (Define): identifica-se o que será projetado e os objetivos a serem alcançados;• Medir (Measure): entendimento das necessidades e expec-tativas dos clientes relativas ao produto ou serviço que está sendo criado. São definidas as características críticas para a qualidade (CTQ) do projeto, que serão os objetivos do novo processo;• Analisar (Analyze): escolher a melhor solução entre as possí-veis alternativas de desenho, visando atender as necessidades dos clientes;• Projeto (Design): será desenvolvido o design de alto nível (descrição do conceito de produto/serviço escolhido, mapas do processo e arranjo das instalações) para todos os elementos apropriados, como: produto/serviço, processo, informação, instalações, equipamentos, e materiais/suprimentos;• Verificação (Verify): testar e validar o projeto. A equipe irá monitorar o desempenho das CTQs do produto ou serviço por meio das cartas de controle. (CARVALHO; PALADINI, 2005)

Aplicabilidade do ModeloO modelo pode ser aplicado para projetos de melhoria de

processos, gerenciamento do processo e para projetos de novos processos.

Na área de segurança da informação, há um campo vasto para identificar melhorias nos processos de segurança, assim como

Figura 16. Descrição dos passos do modelo DMAIC (Fonte: Adaptação (SMIDT & PARTNERS, 2005; PDP net, 2008))

nos processos de infraestrutura, em especial gerenciamento de incidentes, gerenciamento de problemas, gerenciamento da disponibilidade e central de serviços.

O Seis Sigma também pode ser utilizado em questões de apoio ao CIO, como no caso de elaboração de orçamento, controle de custos, etc.

Na área de TI, pode ser aplicado em processos de desenvolvi-mento de software, principalmente em fábricas de programas e manutenção de sistemas, onde há maior quantidade de projetos e um maior índice de repetição dos mesmos.

Mapeamento entre Seis Sigma e CMMI Níveis 4 e 5Este tópico tem o objetivo de apresentar a aplicação do Seis

Sigma na melhoria dos processos de qualidade de software, através do mapeamento de suas atividades com as práticas definidas nos níveis de maturidade 4 e 5 do CMMI.

Qualidade de SoftwareHá algumas décadas, no desenvolvimento de software, nave-

gar pelo código e corrigir problemas era uma prática comum entre os desenvolvedores. Assim eram feitos os testes para verificação de erros e a busca pela qualidade. Foi através dos testes que as organizações começaram a prestar mais atenção na importância da qualidade do software. Apesar disso, no final da década de 1950, o teste ainda era encarado como uma atividade que ocorreria somente no final do processo de desenvolvimento.

Nas décadas seguintes (1960 e 1970), a Engenharia de Softwa-re passou a ser adotada pelas universidades e organizações. 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 é errôneo, pois toda


energia gasta para comprovar esse fato é em vão devido aos poucos defeitos encontrados. Desta maneira, ele definiu o teste como um “processo de trabalho com a intenção de encontrar erros”. Com esta definição, um maior número de problemas será encontrado, uma vez que os profissionais de qualidade buscarão vários cenários para avaliar o comportamento do software.

O conceito de qualidade de software surgiu no início da década de 1980, onde cada fase do processo passava por uma verificação feita por desenvolvedores e testadores, para garan-tir que a fase estava completa. Algumas organizações 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 avaliação CMM, foi o que mais se destacou e ganhou maior dimensão e importância para as organizações de software.

Atualmente, as organizações estão buscando maior eficiência para conseguir superar a concorrência e estão buscando as soluções através da tecnologia, que torna os sistemas informati-zados, reduzindo custos e ampliando a forma de atuação. Para acompanhar esse crescimento, os ambientes estão tornando-se mais complexos e fica mais difícil alcançar um elevado nível de qualidade. Implantar um processo de garantia de qualidade tornou-se essencial e uma boa estratégia para o mercado.

O produto final é o somatório de todas as decisões e rea-lizações geradas durante o ciclo de desenvolvimento. Essas decisões podem afetar a sua qualidade final. Para alcançar uma alta qualidade, é necessário investir em qualidade em todos os pontos do processo. Segundo Bartié (2002), Qualida-de de Software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e elimi-nando defeitos.

Gerentes, diretores e acionistas podem tomar decisões equivocadas, por terem como base informações com erros. Os prejuízos podem tornar-se enormes às organizações. A qualidade das informações depende da qualidade das deci-sões. Com processos de desenvolvimento frágeis e deficientes é impossível garantir a qualidade do software. Portanto, é importante verificar duas dimensões fundamentais para atingirmos a qualidade do software: a dimensão da qualidade do produto, onde o objetivo principal é garantir a qualidade do produto tecnológico gerado durante o ciclo de desenvolvi-mento, através de atividades testes e correção de problemas; e a dimensão da qualidade do processo, onde é feita a estru-turação de processos que possuam mecanismos de inibição e impedimento de falhas.

Relações entre CMMI e SEIS SIGMADo ponto de vista de definição do processo, há uma siner-

gia natural entre as áreas de alta maturidade do processo do CMMI e os princípios do framework DMAIC do Seis Sigma. Desta forma, as táticas do Seis Sigma podem ser utilizadas

para enriquecer diretamente os processos definidos que abor-dam as áreas de processo de alta maturidade. Por exemplo, os processos relacionados com a Gestão Quantitativa de Projeto e Análise de Causa e Solução de Problemas refletem tanto as práticas específicas destas áreas de processo quanto as etapas, sub-etapas e ferramentas do DMAIC. (SEI, 2005)

Existem várias definições 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: Adaptação (SEI, 2005))

A Tabela 6 apresenta os passos de forma mais detalhada dentro roteiro de atividades (roadmap) do DMAIC.

A aplicação bem sucedida do CMMI em conjunto com o Seis Sigma exige uma análise das relações entre os dois.

O CMMI é usado para criar uma infraestrutura de processos organizacionais, abordando domínios específicos, 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 específicos, que trarão benefícios significativos nos negócios. Centra-se no desempenho dos processos e práticas implementadas. Embo-ra estas duas iniciativas de melhoria sejam diferentes na sua concepção, elas são interdependentes em seu uso. Na prática, a alternância 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 práticas 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, de-vido ao fato do CMMI e Seis Sigma serem dois tipos diferentes de iniciativas, com muitas conexões e sobreposições diferentes,


MEtoDoLoGIAS ÁGEIS

um mapeamento completo e generalizado é complexo e ofe-rece pouco valor prático. É mais útil compreender seus focos complementares e as formas pelas quais eles estão conectados. Unir esse entendimento a uma estratégia consciente, permite que uma organização possa criar planos táticos e mapeamentos específicos para apoiar as suas implementações.

Partindo de uma visão macro, a metodologia DMAIC pode ser conjugada com as práticas genéricas para institucionali-zar, otimizar e atingir alta capacidade nesses processos (SEI, 2005). A Figura 18 faz uma relação visual entre várias áreas de processo do CMMI e práticas genéricas alinhadas com passos do roteiro DMAIC.

tabela 6. Six Sigma DMAIC Roadmap (Fonte: Adaptação (ISIXSIGMA, 2009b))

O diagrama da Figura 18 mostra um fluxograma do processo geral de medição de uma organização, revestido com passos DMAIC e áreas de processo selecionadas. Enquanto este pro-cesso da organização foi projetado com observância do modelo em mente, ele representa uma abordagem integrada para a utilização global de medição, em vez de uma replicação das práticas específicas de cada área de processo. Da mesma forma, esse processo organizativo aproveita ideias do DMAIC, mas não é uma replicação das etapas DMAIC (SEI, 2005).

A Figura 19 apresenta uma visão resumida dos relaciona-mentos dos passos do Seis Sigma com as práticas específicas dos níveis 4 e 5 do CMMI.

Figura 18. Áreas de Processo do CMMI e Passos do DMAIC (Fonte: Adaptação (SEI, 2005))

Mapeamento CMMI x Seis SigmaNesta seção, é feita a relação entre as metas e práticas es-

pecíficas das áreas de processo dos níveis de maturidade 4 e 5 com os passos das fases do Seis Sigma - DMAIC. Em seguida, há uma breve descrição das metas e práticas para que possa ser compreendido o relacionamento existente.

Desempenho do Processo Organizacional (OPP)A área de processo (PA) “Desempenho do Processo Or-

ganizacional (OPP)” (Tabela 7) está englobada no nível 4 de maturidade e possui uma única meta específica (SG): Estabelecer Baselines e Modelos de Desempenho, na qual são estabelecidas e mantidas as baselines e os modelos que caracterizam o desempenho esperado dos processos do conjunto de processos padrão da organização. Nesta área

Figura 19. DMAIC Roadmap e as áreas do CMMI (4 e 5) (Fonte: Adaptação (SEI, 2005))


existem três, das cinco práticas específicas (SP), que pode-mos relacionar com o DMAIC.

SP 1.1 Selecionar Processos Consiste em selecionar os processos ou subprocessos

no conjunto de processos padrão organização que serão incluídos nas análises de desempenho do processo. Não se aplica ao Seis Sigma, pois o mesmo parte do princípio 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 manutenção das definições das

medidas que serão incluídas nas análises de desempenho de processo da organização. No Seis Sigma há um conjunto de atividades que satisfazem esta meta específica, através da seleção das medidas apropriadas para fornecer visibilidade da qualidade e desempenho de processo da organização; o desenvolvimento do plano de coleta dos dados e da validação do sistema de medição que permite verificar se as medidas estabelecidas estão sendo úteis.

SP 1.3 Estabelecer Objetivos de Qualidade e de Desempe-nho de Processo

Consiste em estabelecer e manter objetivos quantitativos de qualidade e de desempenho de processo para a organização. No Seis Sigma, as atividades descritas na Tabela 7 se comple-mentam para atingir a definição de tais objetivos.

SP 1.4 Estabelecer Baselines de Desempenho de Processo O Seis Sigma atende a esta prática a partir da coleta e análise

das medidas para estabelecer a distribuição e o intervalo de resultados que caracterizam o desempenho esperado para os processos, gerando os índices de capacidade através dos cálculos estatísticos.

OPP Desempenho do Processo Organizacional (OPP)

SG1 Estabelecer Baselines e Modelos de Desempenho

Práticas Específicas - CMMI Passos do Seis Sigma

SP 1.1 Selecionar Processos ---- ---

SP 1.2 Estabelecer Medidas de Desempenho de Processo MEASURE

Definir defeitos, oportunidades, unidades e métricas

Desenvolver plano de coleta de dados

Validar o sistema de medição

SP 1.3 Estabelecer Objetivos de Qualidade e de Desempenho de Processo ANALYZE

Definir objetivos de desempenho

Identificar fontes de variação

Determinar a(s) causa(s) raiz(es)

MEASURE Mapa detalhado do processo e áreas adequadas

SP 1.4 Estabelecer Baselines de Desempenho de Processo MEASURE

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

SP 1.5 Estabelecer Modelos de Desempenho de ProcessoResume-se em estabelecer e manter os modelos de desem-

penho de processo para o conjunto de processos padrão da organização. Os modelos de desempenho de processo são usados para estimar ou prever os valores de uma medida de desempenho de processo a partir de valores de medições de outros processos, produtos e serviços. Neste caso, o próprio seis sigma (6σ) é o valor modelo, obtido através do cálculo do nível sigma.

Gestão Quantitativa do Projeto (QPM)A área de processo (PA) “Gestão Quantitativa do Projeto

(QPM)” (Tabela 8) está englobada no nível 4 de maturidade e possui duas metas específicas (SG): Gerenciar o Projeto Quan-titativamente, 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 práticas específicas (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 prática através do termo de abertura do projeto que é gerado na atividade “Desenvolver a declaração do problema, objetivos e benefícios” na fase de Definição.

SP 1.2 Compor o Processo Definido Consiste em selecionar os subprocessos que compõem o

processo definido do projeto com bases históricas de estabili-dade e de dados de capacidade. Não há atividade equivalente no Seis Sigma.


MEtoDoLoGIAS ÁGEIS

QPM Gestão Quantitativa do Projeto (QPM)

SG 1 Gerenciar o Projeto Quantitativamente


SP 1.1 Estabelecer os Objetivos do Projeto DEFINE Desenvolver a declaração do problema, objetivos e benefícios

SP 1.2 Compor o Processo Definido ---- ----

SP 1.3 Selecionar os Subprocessos que serão Gerenciados Estatisticamente ---- ----

SP 1.4 Gerenciar o Desempenho do Projeto

MEASURE Determinar capacidade do processo e Baseline Sigma

ANALYZE

Identificar valor/não-valor de etapas adicionadas no processo



IMPROVE

Desenvolver potenciais soluções

Definir tolerâncias operacionais do sistema em potencial

SG 2 Gerenciar Estatisticamente o Desempenho de Subprocessos

Práticas Específicas - CMMI Seis Sigma

SP 2.1 Selecionar Medidas e Técnicas Analíticas MEASURE

Definir defeitos, oportunidades, unidades e métricas


Validar o sistema de medição

SP 2.2 Aplicar Métodos Estatísticos para Compreender a Variação

MEASURE Coleta de dados

ANALYZEIdentificar fontes de variação


SP 2.3 Monitorar o Desempenho dos Subprocessos SelecionadosMEASURE

Determinar capacidade do processo e Baseline Sigma

ANALYZE Identificar fontes de variação

SP 2.4 Registrar Dados de Gerenciamento Estatístico --- ---

tabela 8. Mapeamento da área de processo QPM e DMAIC

SP 1.3 Selecionar os Subprocessos que serão Gerenciados Estatisticamente

Consiste em selecionar os subprocessos e identificar o proces-so e os atributos de produto a serem medidos e controlados.

As práticas específicas SP 1.2 e SP 1.3 não possuem etapas correspondentes, pois, conforme mencionado anteriormente, o Seis Sigma executa a gerência quantitativa em todos os pro-cessos 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 serão satisfeitos e identificar ações 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 práticas específicas:

SP 2.1 Selecionar Medidas e Técnicas Analíticas Consiste em selecionar as medidas e as técnicas analíticas a

serem usadas no gerenciamento estatístico dos subprocessos

selecionados. Três passos do Seis Sigma podem ser utilizados: “Definir defeitos, oportunidades, unidades e métricas” que fornece as definições das medidas a serem usadas no geren-ciamento estatístico; “Desenvolver plano de coleta de dados” que documenta as definições operacionais das medidas, suas coleções de pontos e como a integridade das medidas será determinada; e “Validar o sistema de medição” que permite a atualização das medidas e técnicas de análise estatística quando necessário.

SP 2.2 Aplicar Métodos Estatísticos para Compreender a Variação

Consiste em estabelecer e manter um entendimento da va-riação dos subprocessos selecionados usando as medidas e as técnicas analíticas selecionadas.

O entendimento da variação é conseguido, em parte, coletando e analisando as medidas de processo e de produ-to de forma que as causas especiais de variação possam ser identificadas e endereçadas para atingir desempenhos previ-síveis. Desta forma, utilizam-se os passos Seis Sigma “Coletar dados”, “Identificar fontes de variação” e “Determinar a(s) causa(s) raiz(es)”.


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 ob-jetivos de qualidade e de desempenho de processo, e identificar ações corretivas quando necessário. No Seis Sigma, os passos “Determinar capacidade do processo e Baseline Sigma” e “Iden-tificar fontes de variação” permitem obter os limites naturais de desempenho de processo comparados com seus objetivos estabe-lecidos e a capacidade de processo de cada subprocesso.

SP 2.4 Registrar Dados de Gerenciamento EstatísticoTrata-se de realizar o registro dos dados de gerenciamento esta-

tístico e de qualidade no repositório de medidas da organização. O Seis Sigma não possui um passo definido para esta prática, pois considera a coleta e o armazenamento como um único passo.

Inovação Organizacional (OID)A área de processo (PA) “Inovação Organizacional (OID)”

(Tabela 9) está inserida no nível de maturidade 5 e possui duas

metas específicas (SG): Selecionar Melhorias, onde são selecio-nadas 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 mensuráveis para os processos e tecnologias da organização são continuamente e sistematicamente implementadas.

A primeira meta contempla as seguintes práticas especí-ficas (SP):

SP 1.1 Coletar e Analisar Propostas de Melhoria Consiste em coletar e analisar propostas de melhoria de proces-

so e de tecnologia. No Seis Sigma, através do desenvolvimento da declaração do problema, objetivos e benefícios, são definidos os projetos de melhoria. Na fase de melhoria, são desenvolvidas as potenciais soluções para os projetos estabelecidos.

SP 1.2 Identificar e Analisar InovaçõesEsta prática identifica e analisa melhorias inovadoras que po-

deriam aumentar a qualidade e o desempenho de processo de uma organização. No Seis Sigma, através do desenvolvimento

OID Inovação e Desenvolvimento Organizacional (OID)

SG 1 Selecionar melhorias


SP 1.1 Coletar e Analisar Propostas de Melhoria DEFINE Desenvolver a declaração problema, objetivos e benefícios

IMPROVE Desenvolver potenciais soluções

SP 1.2 Identificar e Analisar Inovações IMPROVE Desenvolver potenciais soluções

SP 1.3 Melhorias Piloto IMPROVE Realizar projetos experimentais


SP 1.4 Selecionar Melhorias para Implantação IMPROVE Validar melhorias em potencial de estudos-piloto

SG 2 Implementar Melhorias


SP 2.1 Planejar a Implantação MEASURE

Definir defeitos, oportunidade, unidade e métricas

Mapa detalhado do processo e áreas adequadas


SP 2.2 Gerenciar a Implantação

IMPROVE

Realizar projetos experimentais


Definir tolerâncias operacionais do sistema em potencial

CONTROL Definir e validar acompanhamento e controle do sistema

SP 2.3 Medir os Efeitos de Melhorias

IMPROVE Validar melhorias em potencial de estudos-piloto

Corrigir/reavaliar o potencial da solução

CONTROL

Determinar capacidade do processo

Verificar benefícios, redução/economia de custos, crescimento do lucro

tabela 9. Mapeamento da área de processo OID e DMAIC


MEtoDoLoGIAS ÁGEIS

de potenciais soluções, são analisadas as todas as propostas de melhoria, incluindo as inovadoras.

SP 1.3 Melhorias Piloto Implantação de melhorias de processo e tecnologia através de

um piloto para selecionar aquelas a serem implementadas. Pi-lotos são realizados para avaliar mudanças novas importantes, sendo implantadas de forma abrangente, quando apropriado. O Seis Sigma realiza esta implantação piloto através dos projetos experimentais na fase de melhoria, criando soluções para os pilotos que apresentam os melhores resultados.

SP 1.4 Selecionar Melhorias para Implantação Nesta prática, ocorre a seleção de melhorias de processo e de

tecnologia para implantação na organização. O levantamento é baseado nos critérios quantificáveis derivados dos objetivos de qualidade e de desempenho de processo da organização. No Seis Sigma, está relacionada com a validação de melhorias em potencial de estudos-piloto, da fase de melhoria.

A segunda meta desta PA contempla as seguintes práticas específicas:

SP 2.1 Planejar a Implantação Estabelece e mantém os planos de implantação das melho-

rias de processo e de tecnologia selecionadas. No Seis Sigma, alguns passos podem ser utilizados: o “Definir defeitos, oportunidade, unidade e métricas” estabelece medidas e objetivos para determinar o valor de cada melhoria de pro-cesso e de tecnologia com relação 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 identificação de estratégias para endereçar potenciais barreiras na implantação de cada melhoria de processo e de tecnologia; e “Desenvolver plano de coleta de dados” para agregar o uso de dados quantitativos na orien-tação da implantação.

SP 2.2 Gerenciar a ImplantaçãoRealiza o gerenciamento da implantação das melhorias de pro-

cesso e de tecnologia selecionadas. Nesta prática, o planejamento pode ser quantificado em relação aos objetivos de negócio da organização. Duas fases do Seis Sigma podem ser utilizadas: • A fase de Medição, através dos passos: “Realizar projetos experimentais”, para implantação das melhorias de forma controlada e disciplinada; “Desenvolver potenciais soluções”, para identificar ações corretivas, caso a habilidade dos pro-cessos definidos em atingir os objetivos de qualidade e de desempenho de processo seja afetada negativamente pela melhoria de processo; “Definir tolerâncias 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 implantação, identificando lições aprendidas, novas propostas e melhorias de processo.

SP 2.3 Medir os Efeitos de MelhoriasEstabelece a medição dos efeitos das melhorias de proces-

so e tecnologia implantadas. Após medir custos, esforço, cronogramas reais, valor das melhorias, progresso da qualidade e desempenho, acontece o armazenamento das medidas no repositório da organização. Os passos do Seis Sigma que podem ser utilizados na fase de melhoria são: validar melhorias em potencial de estudos-piloto, corrigir/reavaliar o potencial da solução. E na fase de controle: determinar capacidade do processo, verificar benefícios, redução/economia de custos, crescimento do lucro.

Análise de Causa e Solução de Problemas (CAR)A área de processo (PA) “Análise de Causa e Solução de

Problemas (CAR)” (Tabela 10) está incluída no nível 5 de maturidade e possui duas metas específicas (SG): Deter-minar Causas de Defeitos, onde as causas de defeitos e de outros problemas são sistematicamente determinadas; e a SG Tratar as Causas dos Defeitos, na qual as causas raiz dos defeitos e de outros problemas são tratadas de forma sistemática para prevenir suas ocorrências futuras.

A primeira meta contempla as seguintes práticas es-pecíficas (SP):

SP 1.1 Selecionar Dados de Defeitos para Análise Seleciona os defeitos e outros problemas para análise. Na

fase Medir do Seis Sigma, realiza-se a definição de defei-tos, oportunidades, unidades e métricas que reúne dados de defeitos ou de problemas relevantes; há o desenvolvi-mento do plano de coleta de dados para fazer relatórios e medições de problemas relevantes; e por último a coleta de dados para determinar e selecionar defeitos.

SP 1.2 Analisar Causas Realiza a análise de causas de defeitos selecionados e

de outros problemas e propõe ações para tratá-los. O Seis Sigma utiliza o passo “Determinar a(s) causa(s) raiz(es)” para conduzir as análises nas reuniões e o passo “Identi-ficar fontes de variação” para analisar os defeitos e outros problemas para determinar soluções. Ambos os passos são da fase de Análise.

A segunda meta desta PA contempla as seguintes prá-ticas específicas:

SP 2.1 Implementar Propostas de Ação Implementa as propostas de ação selecionadas que fo-

ram elaboradas na análise de causa. As propostas descre-vem as tarefas necessárias para remover as causas raízes dos defeitos ou dos problemas analisados e evitar suas recorrências. Durante a implementação as informações e tarefas podem fazer parte do passo de desenvolver o plano de transferência (handoff para o proprietário do processo), da fase controlar no Seis Sigma, contribuindo para que os experimentos sejam conduzidos de forma transparente.


SP 2.2 Avaliar os Efeitos das Mudanças Avalia os efeitos das mudanças no desempenho do processo

após a sua implementação modificada no projeto. O efeito deve ser verificado para reunir evidências de que essa mudança está corrigindo o problema e melhorando o desempenho. Três passos da fase de melhoria do Seis Sigma podem ser utiliza-dos: “Avaliar modos de falha de soluções em potencial” que determina a influência das mudanças no desempenho, “Va-lidar melhorias em potencial de estudos-piloto” que valida a eficiência da melhoria e, por fim, “Verificar redução/economia de custos, crescimento do lucro”.

SP 2.3 Registrar Dados Faz o registro dos dados de análise de causa e resolução para

uso no projeto e na organização, que pode ser usado para fazer mudanças de processo apropriadas e alcançar resultados simi-lares. No Seis Sigma, o passo de controle que fecha o projeto e finaliza a documentação é responsável por fazer os registros de todo material.

Estudo de CasoNeste tópico é apresentado um exemplo de utilização do

Seis Sigma para o alcance do nível 5 de maturidade do CMMI, realizado pelo Instituto Atlântico.

A EmpresaFundado em 2001 pelo CPqD, (Centro de Pesquisa de Desen-

volvimento em Telecomunicações do Brasil), o Atlântico atua em P&D/Inovação, Projetos de Desenvolvimento e Consulto-ria, atendendo principalmente à Indústria, Governo e Setor Financeiro. Suas unidades em Fortaleza-CE, Sobral-CE e São Paulo-SP agregam mais de 290 profissionais.

CAR Análise e Resolução de Causas (CAR)

SG 1 Determinar Causas de Defeitos


SP 1.1 Selecionar Dados de Defeitos para Análise MEASURE

Definir defeitos, oportunidade, unidade e métricas


Coleta de dados

SP 1.2 Analisar Causas ANALYZE Determinar a(s) causa(s) raiz(es)


SG 2 Tratar as Causas dos Defeitos


SP 2.1 Implementar Propostas de Ação CONTROLDesenvolver plano de transferência, Handoff para o proprietário do processo

SP 2.2 Avaliar os Efeitos das Mudanças IMPROVE

Avaliar modos de falha de soluções em potencial

Validar melhorias em potencial de estudos-piloto

Verificar redução/economia de custos, crescimento do lucro

SP 2.3 Registrar Dados CONTROL Fechar o projeto, finalizar documentação

tabela 10. Mapeamento da área de processo CAR e DMAIC

O Atlântico desenvolve projetos de tecnologia da informação na linha de software, hardware e sistemas, para clientes de diversos segmentos de mercado, gerando soluções em Compu-tação Móvel, Integração de Sistemas, TV Digital, Aplicações Fi-nanceiras, Web, Sistemas para Redes, Automação, Engenharia de Telecom, Hardware e Sistemas Embarcados. Estas soluções são desenvolvidas em J2EE, J2ME e. NET (ATLANTICO, 2009b).

Qualidade como Ferramenta EstratégicaDesde o início de suas operações, o Atlântico coloca em práti-

ca a ideia de que o investimento em um amplo sistema de qua-lidade é a forma mais eficiente de se gerar bons resultados.

Em 2005, a empresa conquistou a certificação ISO 9001:2000. Em fevereiro de 2006 o Atlântico foi avaliado como CMMI Nível 3, sendo a primeira organização Norte/Nordeste com esse nível de maturidade. Em 2009, a qualidade atingiu seu auge com a avaliação CMMI nível 5, que apoiados em filoso-fias de trabalho como Six Sigma, RUP, PMBoK, Agile e MSF (ATLANTICO, 2009c).

A Figura 20 apresenta um breve histórico das certificações obtidas pela empresa, acompanhado das filosofias de quali-dades utilizadas.

Figura 20. Histórico de Certificações e Filosofias de Qualidade (Fonte: Adaptação (ATLÂNTICO, 2009c))


MEtoDoLoGIAS ÁGEIS

Desta forma, o Atlântico obteve ótimos resultados, possi-bilitando maior índice de entregas dentro do custo e prazo, com alto padrão de qualidade e aumento na satisfação dos seus clientes.

Estratégia CMMI x Seis SigmaAtualmente, o Instituto Atlântico é a sexta organização no

Brasil reconhecida com o CMMI-5. Para o alcance deste ob-jetivo, 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 estratégia utilizada para o alcance do Nível 5 com base no Seis Sigma, foi implementada em três fases (ATLANTICO, 2009a):

Fase 1 – Planejamento e Definição da Estratégia• Formação de yellow belts e green belts (consultoria de black belts)• Reestruturação dos processos de “melhoria contínua” para incorporar a nova filosofia 6σ (DMAIC)• Reestruturação dos indicadores de acordo com as estratégias (BSC e M&A)• Seleção de projetos de melhoria DMAIC e líderes (DAR)

Fase 2 – Execução da Estratégia de Melhoria (DMAIC)• D – Definição dos Projetos e Casos de Negócios• M – Medição do Estado Atual• A – Análise e Teste das Causas• I – Propostas de Melhoria• C – Estabelecimento de Controles Organizacionais

• Acompanhamento dos projetos DMAIC• Transição das melhorias e ganhos obtidos para a “produção”

Fase 3 – Avaliação da Estratégia• Acompanhamento das melhorias e ganhos obtidos• Avaliação independente dos resultados dos projetos DMAIC

ResultadosAndré Pinho, analista da ISD que acompanhou as avaliações

ao longo da preparação para o CMMI5, destaca a redução de retrabalho, redução de problemas, a melhoria da produtividade e afirma que a certificação se traduz em ganhos para a empresa (ATLANTICO, 2009d):

“Quando a empresa começa a medir, controlar e a usar fer-ramentas estatísticas, é possível melhorar o desempenho, que se traduz em resultados - inclusive financeiros”.

Os gráficos a seguir permitem uma visualização resumida dos benefícios em termos de produtividade (Figura 21), densidade de defeitos (Figura 22) e atendimento ao prazo (Figura 23).

Gabriela Teles, que coordenou a equipe do Atlântico nos dois anos de preparação para chegar ao CMMI5 faz suas considerações sobre os benefícios para a empresa (ATLANTICO, 2009d):

“É o grande diferencial: a organização vai sempre executar os seus pro-cessos de forma melhor, mais otimizada, mais eficiente e eficaz. O controle estatístico é um pré-requisito para fazer essa melhoria dos processos. A partir desse controle se sabe qual o desempenho e se executam as ações para melhorar – tudo baseado em controle estatístico”.

Conforme Cláudio Violato, atual presidente do Instituto Atlântico e vice-presidente de Tecnologia do CPqD, o Atlân-tico 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 condições de trazer mais projetos para fazer. E segundo porque a gente faz o projeto com mais controle: a chance de perda é muito menor. Então o resultado financeiro começa a melhorar também”.

ConclusãoDiante do atual cenário de mercado altamente competitivo, é

mais importante do que nunca para as organizações o investi-mento na melhoria de processos para atender às suas missões (satisfação dos clientes, lucratividade, qualidade, entre outras).

Figura 21. Produtividade (Fonte: (ATLÂNTICO, 2009a))

Figura 22. Densidade de Defeitos (Fonte: (ATLÂNTICO, 2009a))

Figura 23. Atendimento ao Prazo (Fonte: (ATLÂNTICO, 2009a))


Muitas empresas percebem sabiamente que não é preciso fazê-lo a partir do zero, sendo possível otimizar os processos existentes, utilizando iniciativas de melhoria e práticas. No entanto, pode ha-ver uma “sobrecarga” de iniciativas. Desta forma, os responsáveis por aplicar os esforços de melhoria de processos organizacionais devem projetar a sua estratégia e táticas de implementação para que as múltiplas iniciativas escolhidas possam interagir.

Determinar o que é apropriado requer uma compreensão das iniciativas selecionadas e suas ligações. Este artigo abordou os aspectos comuns existentes entre o Seis Sigma e o CMMI de modo que a sinergia entre ambos possa ser percebida.

ABRANTES, José. Programa 8S: da alta administração à linha de produção: o que fazer para aumentar o lucro?: a base da filosofia Seis Sigma. Rio de Janeiro: Interciência, 2001.

ASQ 2009a – American Society for Quality. Organization-Wide Approaches. Disponível 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. Disponível 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. Disponível em: http://www.asq.org/certification/six-sigma-green-belt/index.html. Acessado em: 08/11/2009.

ATLANTICO 2009a – Instituto Atlântico. Utilização do Six Sigma para o alcance do nível 5 de maturidade do CMMI. Disponível em: http://www.atlantico.com.br/ sites/default/files/biblioteca/utilizacao-do-six-sigma-para-o-alcance-do-nivel-5-de-maturidade-do-cmmi.pdf. Acessado em: 09/12/2009.

ATLANTICO 2009b – Website do Instituto Atlântico. Quem Somos. Disponível em: http://www.institutoatlantico.com.br/quem-somos. Acessado em: 09/12/2009.

ATLANTICO 2009c – Website do Instituto Atlântico. Quem Somos - Qualidade. Disponível em: http://www.institutoatlantico.com.br/quem-somos/qualidade. Acessado em: 09/12/2009.

ATLANTICO 2009d – Website do Instituto Atlântico. Notícias – Instituto Atlântico conquista CMMI Nível 5. Disponível em: (http://www.institutoatlantico.com.br/ noticias/instituto-atl%C3%A2ntico-conquista-cmmi-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. Gestão da Qualidade: Teoria e Casos. Rio de Janeiro: Elsevier, 2005.

CITS - CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE. CMMI (CAPABILITY MATURITY MODEL INTEGRATION). Disponível 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-TR-2006-008). Software Engineering Institute, Carnegie Mellon University, 2006.

EFQM – European Foundation for Quality Management. The EFQM Excellence Model. Disponível em: http://ww1.efqm.org/en/Home/aboutEFQM/Ourmodels/TheEFQMExcellenceModel/tabid/170/Default.aspx. Acessado em: 24/09/2009.

FERNANDES, Aguinaldo Aragon. Implantando a governança de TI: da estratégia à gestão dos processos e serviços. 2. ed. Rio de Janeiro: Brasport, 2008.

FINANCE, Yahoo. GE Interactive Charts. Disponível em: http://finance.yahoo.com/echarts?s=GE#chart2:symbol=ge;range=19650104,20040101;indicator=volume+mfi;charttype=line;crosshair=on;ohlcvalues=0;logscale=on;source=undefined. Acessado em: 11/11/2009.

FNQ – FUNDAÇÃO NACIONAL DA QUALIDADE. Critérios de Excelência 2009 - Avaliação e Diagnóstico da Gestão Organizacional. Disponível 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 Comunicação Estratégica. Dúvidas frequentes sobre o Seis Sigma. Disponível 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. Disponível 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. Disponível em: http://www.isixsigma.com/library/ content/c020617a.asp. Acessado em: 11/12/2009.

MOTOROLA – Website da Motorola Brasil. Linha do Tempo. Disponível 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. Estratégia seis sigma: como a GE, a Motorola e outras grandes empresas estão aguçando seu desempenho. Rio de Janeiro: Qualitymark, 2001.

PDP Net – Ambiente de Compartilhamento de Conhecimentos em Desenvolvimento de Produtos. Roteiro DMAIC. Disponível 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. Disponível em: http://www.profitability.pt/conteudos.aspx?cat=30&catMae=26. Acessado em: 06/11/2009.

ROCHA, Hélio. Simples Soluções Desenvolvimento Organizacional Ltda. Programa 8S – Promovendo a Qualidade de Vida. Disponível 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-TR-004, ESC-TR-2006-004). Software Engineering Institute, Carnegie Mellon University, 2006. Disponível 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. Disponível 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. Disponível em: http://smidt-partners.dk/six-sigma_uk/dmaic.html. Acessado em: 12/11/2009.

SSPJ - SECRETARIA DA SEGURANÇA PÚBLICA DO ESTADO DE GOIÁS. Ferramentas da Qualidade. Disponível 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.

Referências Bibliográficas

O valor potencial que é adicionado trata-se da obtenção acelerada de metas de desempenho, otimização da adoção do CMMI (nos níveis mais altos), desenvolvimento das habilidades mais importan-tes de medição e análise para permitir uma melhor quantificação dos resultados, e toda a mudança de cultura correspondente que acompanha essas melhorias.

Dê seu feedback sobre esta edição!

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, através do link: www.devmedia.com.br/esmag/feedback

Dê

seu Feedback

sob

re esta edição


MEtoDoLoGIAS ÁGEIS

AMIGO

Existem coisasque nãoconseguimosficar sem!

Renove Já!

www.devmedia.com.br/renovacao

...só pra lembrar,sua assinatura pode

estar acabando!

Para mais informações:www.devmedia.com.br/central

32 Engenharia de Software Magazine - Colaboração em Processos de Aquisição de Software

João [email protected]

Mestre em Informática e Engenheiro de Computação pela PUC-Rio. Coordenador de Instituição Implementadora MPS.Br. Rea-lizou consultoria empresas como Furnas, Smart Solutions e Banco Itaú. Também é instrutor de cursos na área de processos de software pela PrimeUp e pela CCE/PUC-Rio atendendo organizações como Caixa Econô-mica Federal, Firjan, Petrobrás entre outras.

Rafael Vieira [email protected]

Bacharel em Sistemas de Informação pela PUC-Rio. Foi analista de sistemas em pro-jetos junto organizações tais como: IBGE, M4U e MP-RJ. Instrutor do Programa de Residência em Desenvolvimento de Sof-tware do LES/PUC-Rio. Também atuou no projeto e desenvolvimento de framework para aplicações colaborativas visando apoio aquisição de software.

De que se trata o artigo?Utilizando o Modelo de Colaboração 3C e o Guia de Aquisição do MPS.Br, este artigo discorre sobre os aspectos colaborativos em processos de aquisição de software. Ele identifica suas principais ques-tões e também algumas ferramentas para apoio ao trabalho colaborativo no contexto descrito.

Para que serve?O objetivo deste artigo é apresentar os problemas específicos relacionado à colaboração em proces-sos de aquisição de software e indicar algumas das possíveis soluções para estes.

Em que situação o tema é útil?O tema é útil para organizações que adqui-rem softwares produzidos por terceiros e que desejam melhorar seu processo de aquisição, com o fim de torná-lo eficiente e eficaz.

Colaboração em Processos de Aquisição de Software

Organizações que tenham neces-sidades de adquirir software e serviços relacionados se de-

param frequentemente com problemas inerentes ao trabalho colaborativo, que se caracteriza pelo trabalho através da interação entre diversos indivíduos. Os desafios e problemas de interação não possuem uma solução simples, como um produto único disponível no mercado, e não podem ser tratados somente por meio de ferramentas. Os desafios podem envolver desde a integração de pessoas com perfis profissionais diferentes até as dificuldades de identificação das necessidades de aquisição, dado que cada stakeholder tem sua própria visão e abordagem. Para ilustrar a situação considere o seguinte cenário: • Equipes de departamentos jurídico e técnico discutindo questões legais sobre contratos de software;• Analistas de requisitos discutindo e obtendo aprovação de requisitos, junto aos usuários;

• O gerenciamento do contrato, o qual poderia ser verificado, ou mesmo rene-gociado, a cada nova versão do sistema com o cliente.

O objeto da aquisição definido pelo Guia de Aquisição do MPS.BR é “o pro-duto de software propriamente dito, bem




PRoCESSo

como serviços tipicamente relacionados ao desenvolvimento, implantação, suporte à operação e manutenção do software.” O processo de aquisição trata das atividades relacionadas à con-tratação deste objeto, com o fim de criar e manter uma relação entre cliente e fornecedor em que expectativas de incorporação e entrega de sistemas sejam atendidas. Esse processo pode ser descrito através de quatro fases:1. preparação da aquisição2. seleção do fornecedor 3. monitoração do fornecedor4. aceitação pelo cliente

O problemaPara atender novas demandas organizacionais por tecnologia

de informação, pode ser necessário:• Desenvolver novos sistemas no lugar dos que já existem;• Desenvolver sistemas que reutilizem os que já existem ou realizar serviços para sua manutenção;• Contratar outra empresa que realize as atividades mencio-nadas acima;• Adquirir sistemas gratuitos que atendam às necessidades.

Caso a decisão tomada seja por contratar o desenvolvimento, será necessário, em linhas gerais: definir as necessidades que o sistema atenderá; selecionar o fornecedor; criar um ou mais con-tratos, formalmente ou informalmente definido, dependendo do nível de cerimônia combinado com o contratante; estabelecer meios de comunicação com o fornecedor e acompanhar o cum-primento do contrato; e, por fim, aceitar ou não o sistema.

Esse processo poderia se repetir diversas vezes. Por conta disso, surgem questões indagando se a forma de trabalho au-xiliou na integração e na comunicação entre os interessados no projeto, ou se o conhecimento adquirido, que poderia ser útil para novas aquisições, foi registrado adequadamente.

O Guia de Aquisição do MPS.BR e a ColaboraçãoO Guia de Aquisição do MPS.BR é um modelo de referên-

cia para processos de aquisição de software. Ele define que esses processos são constituídos de atividades, as quais são executadas em fases específicas e possuem produtos como pré-condições ou pós-condições. Essas fases são:1. Preparação da aquisição: trata da definição de necessidades, requisitos de software, metas e critérios de aceitação do software a ser contratado, bem como a definição do plano da aquisição; aqui se busca entender as necessidades do sistema a ser adquirido;2. Seleção do fornecedor: trata da preparação e negociação de contratos com fornecedores e avaliação e seleção destes; 3. Monitoração do fornecedor: visa manter canais de comu-nicação com o fornecedor e acompanhar a aquisição propria-mente dita, ou seja, se as entregas estão dentro dos critérios de aceitação definidos anteriormente;4. Aceitação pelo cliente: realiza a aceitação final do produto desenvolvido, com base nos critérios definidos na preparação da aquisição; momento em que o sistema é integrado totalmen-te à organização contratante.

Nestas fases, as atividades apresentadas na Tabela 1 são executadas.

Guia de Aquisição – Atividades Tarefas

Preparação da aquisição

Estabelecer a necessidade

Definir os requisitos

Revisar requisitos

Desenvolver uma estratégia de aquisição

Definir os critérios de seleção de fornecedores

Seleção do fornecedor

Avaliar a capacidade dos fornecedores

Selecionar o fornecedor

Preparar e negociar um contrato

Monitoração do fornecedor

Estabelecer e manter comunicações

Trocar informação sobre o progresso técnico

Inspecionar o desenvolvimento com o fornecedor

Monitorar a aquisição

Obter acordo quanto às alterações

Acompanhar problemas

Aceitação pelo cliente

Definir critérios de aceitação

Avaliar o produto entregue

Manter conformidade com o contrato

Aceitar o S&SC

tabela 1. Fases e tarefas do Guia de Aquisição do MPS.BR

Neste processo, diversos papéis são desempenhados, entre os quais os mais evidentes são o do cliente e o do fornecedor. Representando o cliente, outros papéis po-dem ser identificados, como, por exemplo, analistas de requisitos, pessoal técnico, usuários ou responsáveis pelo projeto. Representando o fornecedor, também 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 interações com o fornecedor. Segundo o trabalho de Fuks, “um grupo também tem mais capacidade de gerar alterna-tivas, levantar as vantagens e desvantagens de cada uma, selecionar as viáveis e tomar decisões”. Ou seja, por um lado essa diversidade de papéis pode apresentar desafios, mas também possui um potencial positivo para a melhoria da análise e geração de soluções mais adequadas ao que é necessário.

Dessa forma, a natureza colaborativa desse processo se torna evidente, bem como toma contornos diferentes de um processo de desenvolvimento. Sabendo disso, faz-se necessário entender quais são as carências e oportunidades inerentes ao trabalho colaborativo, com o fim de maximi-zar o efeito positivo das interações entre diversos agentes. Fuks, em seu trabalho, propõe o modelo 3C, que classifica os sistemas colaborativos segundo três necessidades a que estes devem atender: comunicação, coordenação e cooperação. Ou seja, necessidades de compartilhamen-to de informações, delegação e sincronismo de tarefas e operação conjunta e benéfica, resumidamente. Mais detalhadamente:


• Comunicação: “Durante a comunicação, as pessoas almejam construir um entendimento comum e compartilhar idéias, discutir, negociar e tomar decisões. Os participantes de uma equipe de trabalho devem se comunicar para conseguir rea-lizar tarefas interdependentes, não completamente descritas ou que necessitem de negociação”;• Coordenação: “Conversação para ação gera compromissos Winograd and Flores, (1987) e Winograd (1988). Para garantir o cumprimento destes compromissos e a realização do traba-lho colaborativo através da soma dos trabalhos individuais, é necessária a coordenação das atividades. Esta coordenação organiza o grupo para evitar que esforços de comunicação e cooperação sejam perdidos e que as tarefas sejam realizadas na ordem correta, no tempo correto e cumprindo as restrições e objetivos [Raposo et al., 2001].”;• Cooperação: “Cooperação é a operação conjunta dos membros do grupo no espaço compartilhado. Em um espaço virtual de informação, os indivíduos cooperam produzindo, manipulan-do e organizando informações, bem como construindo e refi-nando artefatos digitais, como documentos, planilhas, gráficos, etc. O ambiente pode fornecer ferramentas de gerenciamento destes artefatos, como por exemplo, registro e recuperação de versões, controle e permissões de acesso, etc.”

Ferramentas de Apoio ao Trabalho ColaborativoFerramentas colaborativas que apóiem tarefas do processo de

aquisição de software devem considerar os elementos expostos anteriormente. Muitas delas estão disponíveis para uso na Web ou para customização ou integração e se encaixam nas características mencionadas, sendo até mesmo passíveis de integração, visando o suporte completo a fluxos de interação entre os stakeholders. Na Tabela 2, algumas delas são apresentadas dentro da classificação do modelo 3C.

Comunicação Coordenação Cooperação

E-mail Agenda Gerenciador de documentos

Lista de discussão Relatório de atividades Quadro branco

Fórum Acompanhamento de participação Ferramenta de busca

Mural Questionários Glossário

Brainstorming Tarefas Links

Chat Grupos de trabalho Jornal cooperativo

Messenger Gerenciamento de recursos Classificador

Blog Workflow Wiki

Videoconferência Gerenciador de contatos

Revisão em pares

FAQs

Anotações

RSS

tabela 2. Ferramentas de colaboração

• Brainstorming: ferramentas que apóiem a geração de idéias podem ser úteis nas fases iniciais, como apoio ao planejamento. Foram levantadas as seguintes ferramentas que ajudam na geração ou organização de idéias:- Mind map: forma intuitiva de registro e organização de conhecimento, onde conceitos se relacionam com conceitos adjacentes a eles, formando uma árvore;- Gráfico de Ishikawa: possibilita a visualização das relações de causa e efeito entre os conceitos. É útil para a análise de pro-blemas e das necessidades de alto nível que levam à aquisição do software ou serviço correlato.• FAQs (Frequently Asked Questions): possibilita o registro de dúvidas e de soluções simples que possam ser reutilizadas, em vários projetos de aquisição. Problemas mais complexos poderiam ser registrados em uma ferramenta de workflow;• Fórum: para apoio à discussão, manutenção das discussões e suas conclusões, bem como seu registro;• Gerenciador de documentos: manutenção de documentos diversos, como páginas wiki, mensagens em fóruns e docu-mentos 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 conteúdo e ao gerenciamento de recursos;• Quadro branco: possibilita fazer esboços rápidos, para apoio à comunicação falada e à construção colaborativa de esboços. Pode ser usada em conjunto com videoconferência, para apoio às reuni-ões virtuais, no caso de equipes geograficamente distribuídas. A dificuldade do uso da ferramenta se dá pela necessidade de habi-lidades para desenho, quando esta não oferece apoio à construção de telas e montagem de cenários 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 alterações nas páginas, notificando os usuários de atualizações de conteúdo. Facilita o acompanhamento de alterações de conteúdos de interesse do usuário, que pode escolher ou não acompanhar a evolução das páginas Web.• Videoconferência: para apoio à discussão, bem como seu registro, em tempo real. Útil para apoio a reuniões;• Wiki: ferramenta para a construção de conteúdo coletivo, em que qualquer usuário pode inserir ou editar o conteúdo. É útil, no contexto de aquisição, para a manutenção de informações comuns a diversos projetos de aquisição. Poderia ser usado também para a publicação do processo de aquisição;• Workflow, para acompanhamento do fluxo de tarefas e de resolução de problemas.

Cenários de uso em que seriam empregadas tais ferramentas podem ser ilustrados da seguinte forma: • Uma equipe integrando o departamento jurídico e técnico discutem através de um fórum, questões legais sobre contratos de software, e, em seguida, documentando o conhecimento produzido em um wiki ou em um repositório de documentos central, em uma tarefa de preparação do contrato;


PRoCESSo

• Analistas de requisitos, entre outros envolvidos, discutindo sobre os requisitos com o apoio de protótipos em um quadro branco, os quais poderiam passar por um fluxo de aprovação (integração com um mecanismo de workflow), com possível documentação do conhecimento de negócio obtido, no wiki;• O acompanhamento do cumprimento financeiro, fiscal e físi-co do contrato é verificado a cada nova release, tendo um fluxo de aprovação definido na ferramenta de workflow integrada à plataforma colaborativa.

A correlação entre processos de aquisição e ferramentas colaborativas

Nesta seção vamos exemplificar mais detalhadamente como o processo de aquisição pode ser associado às ferramentas cola-borativas. O relacionamento se dá através do mapeamento entre as tarefas do Guia de Aquisição do MPS.BR e as referidas ferra-mentas. Este mapeamento, além de informar as partes associadas, também define como tal relacionamento ocorre, definindo como será o apoio da ferramenta específica sobre determinada tarefa.

Para fins de síntese, consideraremos apenas as tarefas da fase de Preparação da Aquisição, considerada estratégica para o processo como um todo. Resumiremos também o conjunto de ferramentas colaborativas às mais comumente encontradas. Sendo assim temos:

Tarefa: Estabelecer a necessidadeFerramenta: Workflow

• Apoio: Criação de uma solicitação “Estabelecer a necessida-de” para acompanhamento da tarefa. Registros de evolução gerados automaticamente a partir de atualizações em colabo-rações relacionadas a esta tarefa.

Ferramenta: Blog• Apoio: Divulgar chamada de participantes para os Fóruns e Enquetes desta tarefa.

Ferramenta: Fórum• Apoio: Discutir: Qual é o objetivo da aquisição? Quais são nossas necessidades e quais serão atendidas para o alcance do objetivo? Buscar consenso sobre as necessidades estratégicas envolvidas na aquisição e qual o efetivo escopo das necessi-dades a serem contempladas pela aquisição.

Ferramenta: Enquetes• Apoio: As necessidades estão levantadas apropriadamente? Sim, Não, Apenas parte relevante delas.• Apoio: A aquisição atenderá.....das necessidades.: a)a totali-dade; b)parte definida; c)parte desconhecida;• Apoio: O projeto de aquisição deve: a) Seguir em frente c) Aprofundar esta atividade c) Ser cancelado

Ferramenta: Wiki• Apoio: Construção colaborativa da “análise da necessidade da aquisição”, pode ter como anexo documentos sobre a estratégia organizacional relacionada às necessidades (motivadores/

antecedentes do projeto de aquisição). Ao final, um documento deve ser gerado e anexado.

Tarefa: Definir os requisitosFerramenta: Workflow

• Apoio: Criação de uma solicitação “Definir os requisitos” para acompanhamento da tarefa. Registros de evolução gera-dos automaticamente a partir de atualizações em colaborações relacionadas a esta tarefa• Apoio: Criação de uma solicitação “Pesquisa de Mercado” para obter informações que substanciem os requisitos. Veri-ficar possíveis fornecedores, outras empresas, e informações da própria organização.

Ferramenta: Blog• Apoio: Divulgar chamada de participantes para definição de estrutura dos requisitos;• Apoio: Divulgar chamada de participantes para definição dos requisitos;• Apoio: Divulgar execução de pesquisa de mercado;• Apoio: Divulgar chamada de participantes para definição das restrições do projeto.

Ferramenta: Fórum• Apoio: Discutir: Qual a estrutura de requisitos necessária? Buscar consenso sobre quais os tipos/categorias de requisitos esperados, presença ou não de Priorização, Restrições, Graus de Aceitação, Restrições Legais etc...• Apoio: Discutir: Quais são os requisitos desta aquisição? Definir quais requisitos atendem as necessidades desta aquisição. Forte-mente recomendado que sejam descritos em estrutura definida tendo em mente como eles deverão futuramente ser aceitos. • Apoio: Discussão sobre técnicas de requisitos documentadas no wiki.

Ferramenta: Enquetes• Apoio: As informações colhidas são suficientes para definir os requisitos? Sim, A maior parte, A metade, A menor parte, Não• Apoio: Os requisitos estão estruturados apropriadamente? Sim, A maior parte, A metade, Alguns apenas, Não• Apoio: Os requisitos contemplam....das necessidades.: a)a totalidade; b)parte definida; c)parte desconhecida;• Apoio: Precisamos rever as necessidades e alterá-las? Sim, Não• Apoio: Sabemos como medir os requisitos para aceitá-los? Sim, A maior parte, A metade, Alguns apenas, Não• Apoio: O projeto de aquisição deve: a) Seguir em frente c) Aprofundar esta atividade c) Ser cancelado• Apoio: As técnicas de requisitos utilizadas foram adequadas? Sim, Para a maior parte dos requisitos, Para a menor parte dos requisitos, Não

Ferramenta: Wiki• Apoio: Construção colaborativa da “Especificação de requisi-tos”, pode ter como anexo pesquisas de mercado, informações


de fornecedores, práticas de outras organizações. Deve estar clara a estrutura dos requisitos. Relacionar com as necessi-dades da aquisição e os critérios de aceitação. Ao final, um documento deve ser gerado e anexado.• Apoio: Identificar e relacionar a legislação, jurisprudência e normas pertinentes.• Apoio: Catalogar lições aprendidas na tarefa que podem ser úteis em outros momentos da aquisição.• Apoio: Documentação e publicação das técnicas associadas às atividades de requisitos.

Tarefa: Revisar requisitosFerramenta: Workflow

• Apoio: Criação de uma solicitação “Revisar os requisitos”. Registros de evolução gerados automaticamente a partir de atualizações em colaborações relacionadas a esta tarefa.

Ferramenta: Blog• Apoio: Divulgar chamada para a revisão de requisitos. Definirá critérios de revisão, por exemplo: para verificar ambiguidade, estabelecer uma matriz para preenchimento das comparações dos requisitos entre si; estabelecer que cada requisito deverá ter uma avaliação de custo/benefício; etc

Ferramenta: Fórum• Apoio: Discutir: Quais requisitos são críticos ou que devem ser priorizados? Buscar consenso quanto ao que é funda-mental ao software após uma análise individual.• Apoio: Discutir: Como solucionar as incompatibilidades entre os requisitos? Buscar soluções quanto a requisitos inconsistentes, se apresentarem alguma ameaça para o projeto.• Apoio: Discutir: Qual é o custo/benefício de cada requisito? Estes estão compatíveis com o projeto?

Ferramenta: Enquetes• Apoio: A lista de requisitos proposta está completa? Sim, A maior parte, A metade, A menor parte, Não• Apoio: A lista de requisitos proposta está priorizada e com custo/benefício definido? Sim, A maior parte, A metade, A menor parte, Não

Ferramenta: Wiki• Apoio: Registro e armazenamento da revisão da “Especi-ficação de requisitos”.• Apoio: Documentação e publicação de técnicas de revisão de requisitos.

Tarefa: Desenvolver uma estratégia de aquisiçãoFerramenta: Workflow

• Apoio: Definir e implantar o fluxo de contratação • Apoio: Criação de uma solicitação “Adequar modelo de contrato” visando detalhar a abordagem a respeito de prazos, custo, escopo, multa, direito de distribuição uso e propriedade.

Ferramenta: Blog• Apoio: Divulgar chamada para o desenvolvimento da estra-tégia de aquisição.

Ferramenta: Fórum• Apoio: Discussão sobre os termos contratuais, financeiros e técnicos; Apoio: Discussão sobre os critérios de aceitação do produto, frente aos requisitos. Estruturar discussões por requisitos ou grupo de requisitos relacionados;• Apoio: Discussão para definição da forma de acompanha-mento: pessoas, lista de produtos gerados, controle do projeto de aquisição, suficiência dos testes realizados, normas e mo-delos a seguir e riscos identificados. Distribuição de tarefas entre as equipes.

Ferramenta: Enquetes• Apoio: Os requisitos estão associados a critérios de aceitação que os avaliem?• Apoio: Os requisitos e as necessidades para definição do plano de aquisição estão associados a termos de contrato que os formalizem?

Ferramenta: Wiki• Apoio: Construção colaborativa do “Plano de aquisição”, do “Plano de testes de aceitação”, da “Requisição de propostas” e da “Minuta do contrato”

Tarefa: Definir os critérios de seleção de fornecedoresFerramenta: Workflow

• Apoio: Criação de uma solicitação “Definir critérios de sele-ção” para acompanhamento da tarefa. Registros de evolução gerados automaticamente a partir de atualizações em colabo-rações relacionadas a esta tarefa

Ferramenta: Blog• Apoio: Divulgar chamada para a definição dos critérios de aceitação.

Ferramenta: Fórum• Apoio: Discussão sobre os critérios de seleção dos fornece-dores. Poderá contemplar os seguintes fatores: localização ge-ográfica do fornecedor; registro de desempenho em trabalhos similares; equipe e infra-estrutura disponíveis para o desenvol-vimento do produto desejado; tempo de mercado; experiência no domínio do problema; nível de qualidade de seus processos utilizados; e certificações exigidas.

Ferramenta: Enquetes• Apoio: A lista de critérios proposta está completa incluindo a forma de análise e priorização? Sim, A maior parte, A metade, A menor parte, Não

Ferramenta: Wiki• Apoio: Construção colaborativa dos “Critérios de seleção e análise de fornecedores”


PRoCESSo

Alinhando soluçõesPara atender as questões, interações e integrações levantadas

até então, uma solução deve levar em conta requisitos que tenham como objetivos finais a promoção da integração das equipes e pessoas envolvidas nos projetos de aquisição, bem como a promoção do reuso do conhecimento adquirido nos projetos antigos em projetos novos de aquisição. Dentre estes requisitos citamos:• Integração de equipes e pessoas- Apoio à seqüência de tarefas de aquisição;- Suporte e acompanhamento de discussões;- Avaliação de resultados, busca de consenso e alinhamento de percepções em discussões;- Integração das diversas equipes em um mesmo ambiente de trabalho.• Reuso de conhecimento- Documentação do conhecimento e lições aprendidas, obtidos em cada projeto de aquisição;- Manutenção de base de documentos, com mecanismo de busca integrado;

Vale ressaltar que esses requisitos tratam de diversos proble-mas inerentes a projetos de software, e que na sua ausência geram prejuízos ou mesmo cancelamentos. Eles abordam, por exemplo, questões relacionadas a falha no entendimento das necessidades, rotatividade da equipe, requisitos incompletos e falta de participação do cliente.

Outra característica fundamental relacionada a implementa-ção deste tipo de solução é a integração de diversas aplicações sobre uma arquitetura comum que permita a gestão, publica-ção e acompanhamento de fluxos de trabalhos e documentos. Neste ponto, a flexibilidade para reuso e extensão são requi-sitos essenciais.

Requisitos e protótipos poderiam ser anotados ao longo das conversas com usuários e, ao final, salvos em um servidor central da plataforma colaborativa, ao qual o processo (fluxo) de desenvolvimento é integrado. Outro exemplo poderia ser a disponibilização de um repositório central de documentos, em que toda a documentação do cliente passível de análise 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 fácil recuperação e apoio às tarefas de especificação de requisitos, posteriormente.

Já na fase de monitoração e aceitação do fornecedor, tarefas de acompanhamento do projeto ganham importância maior. A cada nova versão disponível para homologação, o registro das funcionalidades entregues e testes realizados podem servir para a geração de relatórios de acompanhamento no servidor central. Esses relatórios, disponíveis para o cliente, o permite acompanhar

o progresso técnico em relação ao estipulado em contrato. Para o acompanhamento de problemas, sistemas já disponíveis no mercado poderiam ser integrados onde fluxos de tarefas são adequados para rastrear os problemas identificados. Da mesma forma, o sistema coletaria dados para a produção de relatórios e acompanhamento do progresso técnico pelo cliente.

É importante observar que essa plataforma central, pela qual toda a equipe de projeto interagiria, precisa ser integrada a ferramentas de apoio à elicitação de requisitos, de construção e de acompanhamento de solicitações, para o registro dos requisitos contratados e a geração automática dos relatórios de acompanhamento frente a esses requisitos.

Essas são possíveis linhas de solução para os desafios colabo-rativos apresentados ao longo do processo de aquisição de sof-tware. Muitas outras integrações entre ferramentas e soluções podem ser propostas. Entretanto, o importante a ser observado é que, seja qual for a estratégia de solução, as tecnologias em-pregadas devem levar em conta os diversos atores existentes no processo, apoiando-os nas suas interações. De forma geral, esse apoio seria direcionado ao acompanhamento do projeto por parte do cliente e ao entendimento das necessidades do cliente pelo pessoal técnico, permitindo assim a realização efetiva da aquisição contratada entre as partes.

ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR -

Guia de Aquisição, versão 1.2, junho 2007. Disponível em: <www.softex.br>

ALVES, Ângela M; GUERRA, Ana. Aquisição de Produtos e Serviços 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-ICE’00). Junho 2000.

FUKS, Hugo; RAPOSO, Alberto Barbosa; GEROSA, Marco Aurélio. Do Modelo de Colaboração 3C à

Engenharia de Groupware. In: Simpósio Brasileiro de Sistemas Multimídia e Web – Webmídia

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

Aplicações Colaborativas, XXI Jornada de Atualização em Informática, Anais do XXII Congresso

da Sociedade Brasileira de Computação, V2, Cap. 3, ISBN 85-88442-24-8, pp. 89-128. Disponível

em http://www.les.inf.puc-rio.br/groupware.

Referências Bibliográficas


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, através do link:

www.devmedia.com.br/esmag/feedback

Dê

seu Feedback

sob

re esta edição

38 Engenharia de Software Magazine - Organização Fábrica de Experiência

Fernando Hadad [email protected]

Atua no ramo de TI há mais de 25 anos. Douto-rando na Ciência da Informação - UFMG. Mestre em Administração pela Universidade FUMEC Bacharel em Ciência da Computação pela Uni-versidade FUMEC. Gestor e desenvolvedor de Sistemas Web pelo UNI-BH. Analista de Sistemas e Programador de Computadores pela UFMG. In-clui cargos de diretor de empresas de desenvol-vimento de software, administrador de TI, ana-lista/desenvolvedor de sistemas e arquiteto de dados. Consultor de TI e organizacional. Professor e Coordenador da Pós-graduação da Faculdade Pitágoras. Professor de graduação da Faculdade Ined. Palestrante. Autor de artigos e livro.

Leandro Libério da [email protected]

É mestrando em Educação Tecnológica pelo Centro Federal de Educação Tecnológica - CEFET-MG. MBA em Gestão Comercial pela Fundação Getúlio Vargas - FGV. Especialista em Banco de Dados pelo Centro Universitário de Belo Horizon-te - UNI-BH (2002). Possui graduação em Tecno-logia em Informática pelo Centro Universitário Newton Paiva (2001). Atua também como pro-fessor e coordenador de cursos de especialização em Tecnologia da Informação do Núcleo de Pós-Graduação do Sistema Universitário Pitágoras. Também leciona no UNI-BH.

George Leal [email protected]

Possui graduação em Engenharia Elétrica pela Universidade Federal de Minas Gerais (UFMG) (1982), Mestrado em Ciência da Computação pela UFMG (1999) e doutorado em Ciência da Informação pela UFMG (2005). Atualmente é professor adjunto da Fundação Mineira de Edu-cação e Cultura - FUMEC/BH . Tem experiência na área de Ciência da Computação e Gestão Estratégica de Empresas, com ênfase em En-genharia de Software, atuando principalmente nos seguintes temas: ciência da computação, engenharia de software, sistemas de informa-ção, informática, processo de software, gestão estratégica e de marketing.

De que se trata o artigo?Neste artigo compreenderemos o modelo de pro-cesso de desenvolvimento de software denominado organização fábrica de experiência. A criação deste modelo se deu no laboratório de Engenharia de Sof-tware da Universidade de Maryland, EUA. A caracte-rística principal é a presença de uma equipe destina-da à finalidade de externalizar o conhecimento dos desenvolvedores.

Para que serve?Visa à obtenção de vantagens competitivas e melhores resultados no desenvolvimento de software – como exemplo na estimativa de custos, qualidade e prazos – por meio da contribuição de experiências de projetos de software anteriores e da gestão da informação e do conhecimento.

Em que situação o tema é útil?Este modelo permite que as organizações de desen-volvimento retenham conhecimento dos projetos do passado para melhorar as habilidades no desenvolvi-mento futuro, não permitindo que o conhecimento se perca ou se dissipe facilmente.

Organização Fábrica de ExperiênciaObtendo vantagens competitivas nas empresas desenvolvedoras de software

Compreendemos a gestão do co-nhecimento como um processo contínuo onde uma organização

orienta suas várias ações com base no co-nhecimento empresarial. Como tarefas típicas temos a geração, valorização, re-gistro, compartilhamento e aplicação do conhecimento para planos e processos variados dentro da empresa. Os resulta-dos positivos da gestão do conhecimento são inegáveis, uma vez que torna este precioso acervo – o conhecimento – num elemento decisivo para a formulação de vantagem competitiva pela empresa em seu cenário competitivo.

Considerar o processo de desenvolvi-mento de software com o apoio da gestão do conhecimento, ou sob sua ótica, é extremamente oportuno. O processo




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 estratégicos. Atividade de intensiva comunicação e que estru-tura ideias e procedimentos muitas vezes não formalmente documentados, o processo de desenvolvimento de software oferece uma perspectiva muito interessante se for analisado sob as lentes da gestão do conhecimento. Neste contexto, o trabalho das “fábricas de experiência” oferece possibilidades importantes para a associação que evidenciamos.

A Organização Fábrica de Experiência (OFE) é um modelo desenvolvido pelo laboratório de Engenharia de Software da Universidade de Maryland. É composta de duas organizações que trabalham perfeitamente integradas. Neste modelo, existe uma equipe específica destinada à finalidade de externalizar (ou seja, difundir ou publicar) o conhecimento gerado dos próprios desenvolvedores. O desenvolvimento de software pode obter melhores resultados – como exemplo na estimati-va de custos, qualidade e prazos – por meio da contribuição de experiências de projetos anteriores. Com cronogramas pressionados, elevadas expectativas quanto à qualidade e produtividade e desafios técnicos constantes, muitos projetos de software não oferecem possibilidades de explicitar (ou seja, estruturar formalmente, a partir do informal) o conhecimento. Porém, neste modelo, esta importante atividade fica por conta da equipe chamada fábrica de experiência. Esta equipe será encarregada de analisar e sintetizar todos os tipos de experi-ência, incluindo as lições aprendidas, dados de projetos e rela-tórios que explicitam estas experiências mediante a criação de repositórios. Tal atividade, se considerada diante do processo de gestão do conhecimento, se constitui em potencial ganho para o produtor de software ao realizar as funções de geração, formalização, retenção, compartilhamento e valorização.

ContextualizaçãoAs organizações de fábrica de software são empreendimentos

que têm expressiva demanda por informações para a execução de seus processos. O uso adequado da gestão do conhecimento e da informação pode ser revertido em vantagens competitivas para este tipo de organização.

Compreende-se a engenharia de software como uma disci-plina que visa o desenvolvimento de software de computador, integrando processo, métodos e ferramentas. Existem modelos de processo para que cada produtor implemente a melhor solução em termos de um processo de produção real, eficaz e efetivo, porém todos definem um conjunto de atividades, uma coleção de tarefas que são conduzidas para realizar cada ati-vidade, produtos de trabalho produzidos como conseqüência das tarefas a serem exigidos para o aceite ou complementação da tarefa, bem como um conjunto de atividades padrões 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 aplicação pelas organizações como fator

de uma nova realidade. As organizações devem almejar a apli-cabilidade do conhecimento dos funcionários 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 desen-volvimento de sistemas de informação, estão em constante melhoria, tornando-se uma busca constante por parte das or-ganizações. O processo de desenvolvimento de software pode ser compreendido como um método de trabalho estruturado, em etapas gerenciáveis individual e coletivamente, que tem como objetivo produzir, de forma coordenada, software para uma aplicação em geral.

O modelo proposto por Victor Basili e seus colaboradores da Universidade de Maryland – USA, denominado Organização Fábrica de Experiência, apresenta uma equipe destinada à fi-nalidade de externalizar o conhecimento. Os principais ativos das empresas de desenvolvimento de software não são as constru-ções, 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 organizações na permanência dos mesmos. A seguir, estudamos o processo de desenvolvimento de software, sua interação com a gestão do conhecimento e a oportunidade das Organizações de Fábricas de Software neste poderoso contexto.

Processo de desenvolvimento de softwareAo se abordarem o conceito de processo de software, verifica-

se que este é configurado como um conjunto de atividades, tais como a análise de requisitos, planejamento de produção, projeto, desenvolvimento dos códigos, testes, manutenção, aquisições ou contratações e demais providências que levem à produção de um software. O processo é proposto como uma rotina que necessita de documentação que detalhe aspectos e artefatos como: especificação formal e precisa do produto a ser desenvolvido; os passos ou fases que serão executados, incluindo sua ordem, gestão de risco e precedência; preparo e atribuições dos agentes que atuarão na produção; os insumos que serão utilizados e os resultados que se espera alcançar. Como casos típicos de especificações para processo de sof-tware, citamos os modelos Personal Software Process (PSP) e Team Software Process (TSP), ambos de autoria do Software Engineering Institute (www.sei.cmu.edu).

N o t a d o D e v M a n

Externalizar o conhecimento: Nonaka e Takeuchi explicam no seu livro “criação de conhecimento na empresa: como as empresas japonesas geram a dinâmica da inovação”, que a criação do conhecimento organizacional é uma interação contínua e dinâmica entre o conhecimento tácito e o conhecimento explícito. Tal interação é mol-dada pelas mudanças entre diferentes modos de conversão, que são a socialização, a externalização, a internalização e a combinação. Dentre os quatro modelos de conver-são do conhecimento, a externalização é a chave para a criação do conhecimento, pois elabora conceitos novos e explícitos a partir do conhecimento tácito.


Há uma imensa diversidade de modelos para processos de software, não se considerando a existência de um processo ideal para todos os produtores. Numa concepção atual da En-genharia de Software, disciplina que prioriza em seu estudo a criação, implantação e manutenção do processo de desen-volvimento de software, aplicam-se tais modelos para que o Engenheiro, conhecendo as demandas do produtor, adapte estas técnicas 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 organizações desen-volveram abordagens diferentes para o processo de software. O desenvolvimento de software sofre mudanças rápidas. Este tipo de negócio se utiliza do conhecimento intensivo e envolve muitas pessoas trabalhando em diferentes fases ou atividades. São diversos os conhecimentos encontrados nas empresas desenvolvedoras, porém, existem problemas para identificar o conteúdo, localização e o uso deste conhecimento. O uso apurado deste conhecimento é uma motivação básica para conduzir a gestão do conhecimento nas empresas desenvol-vedoras, merecendo uma análise profunda.

No desenvolvimento de software, cada pessoa envolvida toma decisões técnicas ou administrativas, muitas delas pontuais ou eventuais, diante de situações inéditas. Membros do time de desenvolvimento tomam decisões baseadas no conhecimento pessoal, experiências ou conhecimento obtido usando contatos informais. Isso é possível em empresas me-nores, com um potencial caótico em empresas maiores, con-duzindo a conflitos e imprecisões nos trabalhos de produção do software. Porém, em empresas que lidam com um grande número de informações, este processo torna-se ineficiente. Grandes organizações não podem confiar na participação informal do conhecimento pessoal dos funcionários, bem como em situações temporárias em que estes funcionários eventualmente atuem, refletindo-se tais situações em im-provisos, informalidades que não podem ser adotadas como comportamentos organizacionais padronizados. Tal situação é frequentemente referenciada na literatura da Engenharia de Software ao afirmar que processos não estruturados de-pendem de atuações “salvadoras” de gerentes e especialistas (bons programadores, analistas que dominem o contexto da aplicação, gerentes que conseguem improvisar com sucesso), eventos que não trazem em si garantia nenhuma que poderão ser repetidos em novos projetos.

O conhecimento individual, sobre técnicas, processo, métodos, infraestrutura, bases e gerenciamento, principalmente, precisa ser compartilhado. Desta forma, os processos de compartilhamento do conhecimento precisam ser perfeitamente definidos.

Vantagem CompetitivaEntende-se a vantagem competitiva como uma diferença

positiva que um determinado competidor apresenta, em um segmento, sobre seus concorrentes, percebido pelos clientes daquele segmento. O software oferece inúmeras situações de potencial construção da vantagem competitiva, indo desde a melhora ou customização do atendimento, passando pelo

aprimoramento na oferta de produtos e serviços que sejam diferenciados aos olhos dos consumidores. Destaca-se aqui também a diferenciação, e consequente vantagem, nas formas de oferta, como bons serviços de comércio eletrônico.

Analisando o contexto do processo de desenvolvimento de software, da gestão do conhecimento e a construção da vanta-gem competitiva, pode-se afirmar que, no desenvolvimento de software, inúmeros documentos são 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 neces-sita ser explicitamente capturado, oferecendo a oportunidade para o aprendizado de outros.

A busca por posições estratégicas que combinem ou superem as existentes nas organizações é um grande desafio que as empresas enfrentam, e norteará a direção futura delas, tanto para o sucesso, quanto para o fracasso.

A empresa é um conjunto de recursos cuja utilização é orga-nizada por um quadro de referência administrativo, tornando os produtos finais da organização representantes das possibi-lidades pelas quais se pode utilizar seu conjunto de recursos para desenvolver suas potencialidades básicas.

Definimos recursos como todos os ativos, processos organi-zacionais, atributos, informação, conhecimento, etc., controla-dos pelas organizações, que as tornam capazes de conceber e implementar estratégias que melhorem sua eficiência e eficácia. As organizações não podem ser consideradas idênticas, bem como os recursos reais são heterogêneos (originais) e imóveis (não são adquiríveis). É aqui que o software, como afirmamos antes, pode se constituir num diferenciador potencial, produ-zindo vantagem competitiva.

Tipos de conhecimento e a aplicação para produção de software

Dentre os conhecimentos típicos que são encontrados num ambiente de desenvolvimento de software, podemos exemplificar:• Os métodos de cálculos de estimativas de prazos e custos financeiros;• Especificações técnicas de modelagem de programas, lógicas e relacionamentos entre módulos;• Métodos de planejamento de atividades, de delegação de controle e tarefas durante a produção de software, como os de testes;• Formulários e artefatos variados, como definições de layout para repositórios de requisitos;

N o t a d o D e v M a nProcessos organizacionais: procurando estruturar-se em processos, as or-

ganizações terão maior eficiência na obtenção de produtos e serviços e estarão mais preparadas para mudanças, com melhor integração de seus esforços e maior capacidade de aprendizado.


ENGENhARIA DE SoFt WARE

• Melhores práticas de processos e projetos, a serem aplicadas sucessivamente na formulação de novos produtos.

Algumas das áreas do conhecimento e das necessidades relativas às organizações são:• Adquirir conhecimento sobre novas tecnologias: novas tecnologias podem ser bastante eficientes para o desenvol-vimento de software, mas tornam-se pesadelos para os ge-rentes de projeto. É difícil para os desenvolvedores ficarem aptos com as novas tecnologias e, para os gerentes, entende-rem seus impactos e estimar os novos custos. Tecnologias não muito familiares fazem uso intensivo do “aprender fazendo”, que pode trazer retardo nos resultados;• Conhecimento de acesso do domínio: o desenvolvimento de software necessita de acesso ao conhecimento não apenas do seu domínio e em novas tecnologias, mas também sobre o domínio para o qual o software está sendo desenvolvido;• Compartilhamento do conhecimento das práticas e políti-cas locais: os conhecimentos são passados, entre desenvolve-dores experientes e os com pouca experiência, em encontros informais; com isso, nem todos têm acesso. Esta prática deve ser estimulada, mas a captura e compartilhamento formal do conhecimento asseguram que todos os funcionários terão acesso a ele.

As organizações devem analisar os projetos do passa-do para melhorar as habilidades no desenvolvimento. Isto requer conhecimentos extensivos baseados nas mais diferentes experiências no desenvolvimento, bem como insights. Padrões, melhores práticas, modelos e recomen-dações são exemplos de resultados destas atividades do conhecimento.

A organização Fábrica de Experiência (OFE)O modelo desenvolvido denominado organização fábrica

de experiência, conforme mostrado na (Figura 1), possui duas organizações perfeitamente integradas. Uma equipe específica é destinada à finalidade de externalizar o conhe-cimento dos próprios desenvolvedores. Este processo tem como objetivo obter melhores resultados no desenvolvimen-to de software – custos, qualidade e prazos – por meio da alavancagem de experiências de projetos anteriores.

Com cronogramas, expectativas quanto à qualidade e pro-dutividade e desafios técnicos, muitos projetos não podem dedicar recursos suficientes para explicitar o conhecimento. Porém, isto fica por conta da equipe chamada fábrica de experiência. Esta equipe está encarregada de analisar e sintetizar todos os tipos de experiência, incluindo as lições aprendidas, dados de projetos e relatórios que explicitam estas experiências mediante a criação de repositórios.

A OFE agrega valor ao conhecimento, mediante a criação de modelos baseados em documentos ou em indivíduos. Externalização e internalização são integradas, de modo que a equipe do projeto trabalhe em harmonia com a OFE. Implantar o conceito de OFE requer mudanças culturais nas organizações, devido à criação de equipes e processos distintos de trabalho. O que é mais essencial na OFE não é a experiência, mas os novos conhecimentos gerados a partir da experiência. As OFE precisam empacotar a experiência, por meio da análise, síntese e avaliação da experiência bruta, e construir modelos que representam a abstração dessas experiências.

A aprendizagem organizacional é o know-how incorpo-rado, resultante da capacidade de absorção, bem como da receptividade da empresa a uma nova tecnologia. Cada organização tem sua capacidade e habilidade de aprender a partir de outras organizações. 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 organização conhece sua tecnologia, mais fácil torna-se o aprendizado.

A Gestão do Conhecimento na Engenharia de Software

As organizações podem aplicar a gestão do conhecimento para fornecer soluções nos seus negócios. Para evitar erros e retrabalho, para diminuir tempo e custos de desenvolvi-mento e aumentar a qualidade, as empresas desenvolvedoras


Estratégia: Não existe uma definição única e universalmente aceita para estraté-gia. Inicialmente deu-se ênfase especial ao uso militar do termo estratégia, originada das mais antigas literaturas do mundo. Strategos referia-se ao papel de um general no comando de um exército, passando posteriormente a ser a arte de habilidades psicológicas e comportamentais com as quais exercia esse seu papel. Uma estratégia bem formulada ajuda a ordenar e alocar os recursos de uma organização para uma postura singular e viável. Diversos autores relacionam o conceito de estratégia em uma série de pontos de vista, como plano, padrão, posição e perspectiva.

Figura 1. Arquitetura da solução – Victor Basili – adaptada pelos autores


necessitam aplicar, nos futuros projetos, o conhecimento obtido em projetos anteriores. Infelizmente, a realidade é que o time de desenvolvimento não se beneficia das ex-periências anteriores e repete os mesmos erros cometidos, embora alguns desenvolvedores saibam como evitá-los. O ganho individual e da organização poderia ser maior se o conhecimento fosse compartilhado.

As atividades da gestão do conhecimento que suportam o desenvolvimento de software são:• Gestão de documentos: muitos documentos, processos e atividades são envolvidos na engenharia de software. Estes documentos são freqüentemente criados, revisados e utilizados. Existem diversas ferramentas para a gestão de documentos;• Gestão de competência: ou gestão de habilidades; quem sabe o quê – uso do conhecimento não documentado;• Reuso de software: programadores não se cansam de imple-mentar a mesma solução; o reuso é para evitar o retrabalho; incentivo ao repositório de reuso. Somente será desenvolvido algo novo caso não se encontre nada para reusar;• Aprender com experiências necessita de um suporte à me-mória do produto e do projeto. As práticas da engenharia de software que ajudam a construir memórias são: controle de versão, gestão de modificações, documentação de padrões e rastreabilidade de requisitos. Em todas estas práticas, a retenção do conhecimento é altamente indicada.

Implementando a gestão do conhecimento na Engenharia de Software

Para implementar a gestão do conhecimento na engenharia de software, muitos desafios e obstáculos estão presentes. Três questões são particularmente importantes:• Questão tecnológica: A tecnologia de software su-porta a gestão do conhecimento? É possível integrar todas as ferramentas para alcançar o nível planejado de compartilhamento?• Questão organizacional: É um erro focar somente na tecnologia e esquecer a metodologia. É um risco cair na cilada tecnológica sem um planejamento adequado para a implementação da gestão do conhecimento;• Assuntos individuais: Funcionários frequentemente não têm tempo de entrar ou procurar por conhecimento, ou não desejam disponibilizar seus conhecimentos. E não querem reusar conhecimentos dos outros.

Uma análise das características da gestão do conheci-mento revela que muitas organizações que falharam não

determinaram seus objetivos e estratégias antes de imple-mentar sistemas de gestão do conhecimento, não tendo uma boa preparação do método ou processo da gestão do conhecimento. É necessário despender um tempo antes de os benefícios da gestão do conhecimento aparecerem.

Algumas culturas organizacionais incentivam o indivi-dualismo e limitam o trabalho cooperativo. A falta de uma cultura do conhecimento tem sido citada como um obstáculo para o sucesso da gestão do conhecimento. Se a organização não incentiva a cultura de compartilhamento, o funcionário se sente dono do seu conhecimento. Os funcionários não se sentem à vontade com as suas experiências negativas e lições aprendidas por falhas, temendo que as informações fornecidas possam ser usadas contra eles.

ConclusãoAs organizações não devem apenas encorajar os funcio-

nários, mas recompensá-los por compartilhar seus conheci-mentos, procurar por conhecimentos e usá-los. A vantagem da experiência ou do conhecimento explícito é que pode ser armazenado, organizado e disseminado para terceiros, sem o envolvimento de quem o originou. Para alcançar vanta-gem máxima do compartilhamento, as empresas deveriam encorajar os funcionários a documentar e armazenar seus conhecimentos em um repositório. As comunidades são bons exemplos de compartilhamento de conhecimento. Elas se formam de modo relativamente fácil.

As organizações se esforçam para aprender e aumentar suas expertises mediante as entradas vindas de fora da organização. Projetos em empresas de desenvolvimento de software cujo ob-jetivo é construir uma base de conhecimento incluem um centro para estas bases, assim como o acúmulo de modelos empíricos para serem utilizados na validação de novos projetos.

A maioria do conhecimento das empresas de software não é explícito. O tempo é curto para tornar o conhecimento explícito, e existem poucas ferramentas para transformar o conhecimento tácito em explícito. Porém, os artefatos do de-senvolvimento de software se encontram em formato eletrôni-co, possibilitando o uso de ferramentas de TI para a retenção, e facilitando o compartilhamento e a disseminação.


Insights: Uma visão que se manifesta de repente, como a compreensão de como resolver um problema difícil. O termo foi cunhado pelo psicólogo alemão e teórico linguista Karl Bühler.

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

Links




Dê

seu Feedback

sob

re esta edição


Felipe [email protected]

É graduado em Engenharia Mecânica pela UFPE, especialista em Tecnologias da Infor-mação pelo Centro de Informática da UFPE e mestre em Ciência da Computação na área de produtividade de software também pela UFPE. Com 13 anos na área de desenvolvimento de software, atualmente é coordenador da garan-tia da qualidade de software e do SEPG (Sof-tware Engineering Process Group), liderando também a melhoria dos processos das áreas de gestão de projetos no C.E.S.A.R.

Andrea [email protected]

É graduada em Ciência da Computação pela UFPE e mestra em Ciências da Com-putação pela UFPE na área de Engenharia de Requisitos. Com 9 anos de experiência na área de desenvolvimento de software, atualmente é Engenheira de Qualidade de software do C.E.S.A.R. Possui experiência na definição e implantação de processos de garantia da qualidade aderentes ao CMMI e em avaliação SCAMPI, tendo participado da avaliação 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 ga-rantia de qualidade, modelos de qualidade, requisitos e metodologias ágeis.

Ryan [email protected]

É graduado em Ciência da Computação pela UFC e mestre em Ciências da Computação pela UFPE na área de Inteligência Artificial. Com 10 anos de experiência na área de desenvolvimento de software, 7 deles como Engenheiro de Configu-ração de Software. Atualmente é Engenheiro de Sistemas do C.E.S.A.R. Possui experiência na defi-nição e implantação de processos de Gerência de Configuração aderentes ao CMMI e em avaliação SCAMPI, tendo participado da avaliação Classe A CMMI 2 e 3 do C.E.S.A.R.

Gustavo [email protected]

É graduado em Ciência da Computação pelo UNIPE e especialista em Engenharia de Software pela FBV/Qualiti. Com 8 anos de experiência na área de desenvolvimento de software, atualmente é Engenheiro de Confi-guração do C.E.S.A.R, além de ministrar aulas de Programação Orientada a Objetos, Estrutu-ra de Dados e Teoria Geral dos Sistemas na Fa-culdade Joaquim Nabuco. Possui experiência em desenvolvimento de software, elicitação de requisitos e na definição e implantação de processos de gerência de configuração aderentes ao CMMI.

De que se trata o artigo?Este artigo relata a experiência de uma Organização CMMI (Capability Maturity Model Integration), nível 3, na customização e integração de ferramentas open-source para melhoria de processo e aumento da produ-tividade das equipes de desenvolvimento de software.

Para que serve?A utilização de ferramentas desta natureza é útil para as Organizações que possuem um ambiente de me-lhoria dos processos de software e tem a necessidade de adotar ferramentas de baixo custo e de forma in-tegrada. Tais ferramentas darão suporte ao processo institucional com uma maior agilidade pelas equipes de desenvolvimento de software.

Em que situação o tema é útil?Em ambientes que necessitam integrar ferramentas de apoio ao processo organizacional de forma produtiva e consistente. Especificamente em processos relaciona-dos com gerenciamento de mudanças, gerenciamento de testes, gerenciamento de requisitos e revisão de artefatos (código ou documentos).

Customização e Integração de Ferramentas Open-Source Uso de ferramentas integradas para melhoria de processo e aumento de produtividade

As organizações de desenvolvi-mento de software têm buscado diversas formas para melhoria

de seus processos com o objetivo de au-mentar a produtividade das equipes de desenvolvimento. Uma forma de obter

ganhos significativos de produtividade requer iniciativas integradas em diver-sas áreas, por exemplo, melhoria em ferramentas, metodologia, ambiente de



44 Engenharia de Software Magazine - Customização e Integração de Ferramentas Open-Source

trabalho, gerenciamento, reuso, dentre outros fatores [Bohem et AL, 1982].

Por outro lado, a inclusão de ferramentas em um projeto nem sempre está associada a ganho de produtividade. Isso irá depen-der, dentre outros fatores, do tamanho da equipe e da maturidade do processo de desenvolvimento [Bruckhaus et AL, 1996].

Neste contexto, a Organização aqui apresentada estabele-ceu dois principais objetivos em seu programa de melhoria contínua:• Seleção de ferramentas free e open source que propiciem au-mento da produtividade das equipes de desenvolvimento de software de forma controlada, gerenciada e com baixo custo;• Customização das ferramentas selecionadas considerando o processo definido na organização 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 Organização EstudadaO C.E.S.A.R – Centro de Estudos e Sistemas Avançados do

Recife – é um instituto privado de inovação que cria produtos, processos, serviços e empresas usando Tecnologia da Infor-mação e Comunicação (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 em-preendedorismo, inovação e negócios de TIC do estado de Pernambuco que reúne mais de 100 empresas no pólo do Bairro do Recife.

Desde sua inauguração, a instituição recebeu reconhecimen-tos na área de TIC, entre eles: o Prêmio Info200 de Melhor empresa de serviços de software, o prêmio FINEP de mais inovadora instituição de pesquisa do Brasil, a escolha da ins-tituição como exemplo de criação de negócios pelo World Eco-nomic Fórum e uma menção honrosa no Stockholm Challenge. Além do prêmio que a Revista Época Negócios concedeu ao C.E.S.A.R com o título de um dos Modelos de Negócios mais Inovadores do Brasil, em 2009.

Em junho/2003, o C.E.S.A.R alcançou o nível 2 de maturi-dade do modelo SW-CMM [Paulk et AL 1999] na vertical de telecomunicações, e em Novembro/2007 atingiu o nível 3 de maturidade do modelo CMMI-DEV, versão 1.2 [SEI 2006]. Atualmente, utiliza metodologias ágeis em conjunto com o modelo de maturidade.

Processo de Seleção das FerramentasA estratégia de seleção das ferramentas iniciou com um levan-

tamento dos requisitos necessários levando em consideração as necessidades do processo e projetos da organização. Nesta primeira etapa, o grupo envolvido analisou os processos que estavam diretamente relacionados com a equipe de engenharia de software e que demandavam um esforço significativo em passos que poderiam ser automatizados e/ou integrados. Como resultado desta análise, quatro processos foram selecionados: Gerenciamento de Requisitos, Gerenciamento de Mudanças, Gerenciamento de Testes e Revisão de Artefatos.

Em seguida, foi realizada uma pesquisa e análise de ferra-mentas disponíveis no mercado levando em consideração as necessidades anteriormente identificadas em cada um dos processos selecionados. Como resultado desta pesquisa, um processo de tomada de decisão foi realizado para identificar quais ferramentas seriam adquiridas e adaptadas à realidade da organização. Os principais requisitos estavam relacionados com o baixo custo necessário para aquisição e com a possi-bilidade de customização e integração das ferramentas para que elas, de fato, se adaptassem ao processo organizacional. Portanto, foi dada preferência na seleção de ferramentas open source e as escolhidas foram: Mantis e Salomé.

Originalmente, o Mantis foi concebido como uma ferramenta para bug tracking. Porém, pela sua flexibilidade e facilidade de customização, também foi utilizada para gerenciamento de mudanças, gerenciamento de requisitos e revisão de artefatos. A Salomé, por sua vez, foi concebida como uma ferramenta de gerenciamento de testes e foi customizada para atender ao pro-cesso de gerenciamento de testes da organização estudada.

A seguir, será brevemente descrito cada uma das ferramentas utilizadas.

Mantis Bug Tracker – Gerenciamento de MudançasO 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 da-dos, 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 modificável, perso-nalizável e atualizável. Esse foi um dos motivos que pesou na escolha da ferramenta de gerenciamento de mudanças.

As customizações no Mantis começaram a surgir a partir da necessidade de padronização na abertura das CR s (Change Requests) ou Requisições de Mudança. O formulário das CR’s possui vários campos, mas em alguns deles não era clara a for-ma de preenchimento. Em especial os campos descritivos (e.g. descrição da requisição de mudança e passos para reprodução) poderiam ser escritos com texto livre, fazendo assim com que a falta de informações importantes ou falhas de interpretação acontecessem com certa freqüência.

Para minimizar esse tipo de situação, foi criado um modelo em XML que descrevia de forma mais estruturada as informa-ções importantes de cada campo. Foi dada uma opção para o relator da CR incluir o modelo no campo a ser editado e o mes-mo poderia preencher as informações nos campos delimitados pelas tags XML. A utilização desse modelo ajudou também na formatação das informações e no processo de automação de checagens em auditorias, pois as informações estavam mais estruturadas, e não mais em texto livre.

No processo interno, as CR s poderiam ser de diversos ti-pos: Defeitos de Código, Defeitos de Documento, Mudanças, Tarefas, Requisições de Baseline e Requisições de Release, e,


PRoCESSo

para cada tipo, os campos obrigatórios relativos ao processo eram diferentes, o que acarretava em um enorme tempo con-sumido para o Engenheiro de Configuração verificar cada CR. Neste sentido, o código fonte do Mantis foi alterado para que a visualização e obrigatoriedade de alguns campos fossem dependentes do valor de um campo novo chamado “Tipo”, que listava os tipos de requisições possíveis no processo da organização. Além disso, a máquina de estados padrão tam-bém foi reformulada para se adaptar a esse novo contexto, como ilustrado na Figura 1.

Figura 1. Máquina de Estados do Mantis

A integração dos sistemas de controle de versão (CVS e Subversion) com o Mantis tem sido de enorme utilização por parte dos projetos. Através dela, todos os comentários dos commits realizados via CVS/Subversion são registrados automaticamente na respectiva CR que está sendo resolvida. Com a integração, consegue-se garantir um rastreamento bi-direcional entre CR’s e artefatos:• Identificação a partir do Mantis de todos os artefatos (seus branches, revisões e responsáveis) alterados para resolver cada requisição de mudança;• Identificação a partir dos comentários dos commits de todas as CR’s que ocasionaram as mudanças.

Ainda foram implementadas integrações do Mantis com os outros sistemas descritos neste documento: Rev.I.S.E e ITReq. A partir da tela de visualização de cada CR é possível acessar suas respectivas revisões e requisitos impactados pela mudança.

Rev.I.S.E – Revision Infrastructure for Software Engineering

A ferramenta Rev.I.S.E foi idealizada, principalmente, para substituir as planilhas de revisão contendo as informações das revisões formais realizadas e que eram armazenadas no


CMMI (Capability Maturity Model Integration): é um framework que des-creve princípios e práticas relacionadas ao processo de desenvolvimento de produ-tos e serviços tecnológicos. O modelo visa ajudar organizações envolvidas com o desenvolvimento de software a melhorar a capacidade de seus processos por meio de um caminho evolucionário, com resultados mais previsíveis e com possibilidade de melhoria contínua. [SEI, 2006].

CR (Change Request): Solicitações de Mudança em um artefato.

CVS (Concurrent Version System) e SVN (SubVersion): são sistemas de con-trole de versão que permitem que se trabalhe com diversas versões de arquivos organizados em um diretório e localizados local ou remotamente, mantendo-se suas versões antigas e os logs de quem e quando manipulou os arquivos.

repositório dos projetos. Para que os membros da equipe se-guissem o processo definido de revisão formal utilizando pla-nilhas fazia-se necessário 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 gerência de configuração para o projeto, preencher a planilha com os dados da revisão e incluir a planilha no repositório. Havia também uma grande dificuldade de se auditar o processo de revisão, visto que se fazia necessário abrir cada planilha para checagem das infor-mações. Tudo isso tornava a execução do processo de revisão custoso para a equipe, para o projeto e para a empresa devido ao esforço envolvido. O processo era ainda propício a erros em cada um dos passos descritos, visto que todos eles eram realizados manualmente.

Inicialmente, para resolver o problema de forma mais rápida, pensou-se numa solução para coleta de informações das pró-prias planilhas automaticamente. Uma aplicação consultava determinadas células das planilhas, gerava uma página web consolidando as informações e realizava a maioria das checa-gens de consistências. Mas, essa solução tinha a desvantagem de se basear num modelo fixo de planilha. Toda vez que o modelo mudava, a aplicação teria que ser adaptada.

Devido a essas dificuldades, o SEPG (Software Engineering Process Group) propôs o uso de uma ferramenta web que automatizasse todas essas atividades, agilizando a criação, o preenchimento e o acesso aos dados entre os participantes do processo de revisão formal. Foram feitas pesquisas, mas nenhuma solução gratuita foi encontrada para suprir as ne-cessidades da organização e, por isso, resolveu-se construir uma ferramenta.

Em uma análise prévia dos requisitos básicos e imediatos para a ferramenta, foi identificado que o Mantis, ferramenta para gerenciamento de mudanças já largamente utilizado na organização, supriria a maioria deles: suporte de projetos, controle de acesso de usuários, máquina de estados e campos customizáveis. Assim, decidiu-se utilizar o Mantis como base


para todo o desenvolvimento, batizando a nova ferramenta de Rev.I.S.E.

Durante o desenvolvimento houve a preocupação de disponi-bilizar um ambiente amigável e fácil de usar para inclusão das não-conformidades e os dados das revisões. Assim, decidiu-se usar algum framework com componentes Ajax/DHTML para que os dados fossem postados facilmente com edições inline de tabelas. Neste intuito, escolheu-se o framework Ext.JS.

A máquina de estados do Rev.I.S.E também foi reformulada de acordo com a Figura 2.

Figura 2. Máquina de estados do Rev.I.S.E

Dependendo do papel na revisão do usuário autenticado no sistema, e do estado da revisão, alguns campos são habilitados ou desabilitados, conforme as responsabilidades descritas na Tabela 1.

Algumas automações foram feitas na ferramenta para que os esforços com as checagens em auditorias pudessem ser diminuídos, entre elas:• Checagem das transições de estados específicas por papel; • Verificação da consistência dos papéis por tipo de revisão; • Verificação e validação de campos obrigatórios; • Envio automático do convite por e-mail aos envolvidos na revisão; • Integração com a ferramenta de controle de mudanças (Mantis); • Seleção automática do checklist de auditorias definido no processo da organização; • Acompanhamento do estado da revisão por e-mail;


Ext.JS: é um framework javascript com uma extensão rica em funcionalidades e componentes de interface gráfica com o usuário.

Findings: São os erros, problemas, lapsos, oportunidades de melhoria ou pontos de investigação identificados durante o processo de revisão de artefatos.

GNU GPL (General Public License): é a designação da licença para software livre idealizada por Richard Stallman no final da década de 1980, no âmbito do pro-jeto GNU da Free Software Foundation (FSF). A GPL é a licença com maior utilização por parte de projetos de software livre.

• Verificação de métricas de tempo planejado versus o realizado.

Papel Responsabilidades

Autor Criar e/ou atualizar o artefato a ser revisado;

Planejar a revisão;

Definir os papéis e responsabilidades da equipe de revisão;

Agendar a reunião de revisão;

Realizar o retrabalho após a revisão, garantindo que todos os pontos

levantados tenham sido corretamente analisados e resolvidos.

Moderador Determinar quando a revisão estará completa e indicar, caso necessário,

uma nova revisão;

Analisar se o retrabalho foi realizado conforme descrito no Rev.I.S.E;

Realizar o fechamento da revisão.

Redator Cadastrar os findings na ferramenta.

Revisor Revisar os artefatos.

Leitor Apresentar o artefato aos participantes ao longo da reunião. Obs: o papel do

Leitor só existe para técnicas que realizam reunião de revisão.

tabela 1. Papéis e Responsabilidades

ITReq - Infrastructure to Track RequirementsA ferramenta para Desenvolvimento e Gerenciamento de

Requisitos (ITReq) trata-se de uma customização da ferramen-ta de Gerência de Mudanças, o Mantis. O layout de algumas funcionalidades é idêntico à ferramenta original, como o me-canismo de busca e a visão 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 máquina de estados também foi adaptada de acordo com a Figura 3.

Cada requisito cadastrado no ITReq é identificado uni-camente e tratado de forma independente dos demais requisitos, com suas prioridades e estados. Além do identi-ficador único, cada requisito possui Nome, Descrição, Tipo (requisito funcional, requisito não funcional, caso de uso ou restrição) e Prioridade. O campo Descrição é livre, sendo possível ser utilizado para descrever um requisito funcional


PRoCESSo


PHP (PHP: Hypertext Preprocessor): é uma linguagem de programação in-terpretada, livre e muito utilizada para gerar conteúdo dinâmico na Web.

SEPG (Software Engineering Process Group): grupo estabelecido e desig-nado como responsável pela definição, manutenção e melhoria do processo de engenharia de software [SEI 2006].

de forma textual, ou um caso de uso com pré-condição, atores, passos e pós-condições.

Figura 3. Máquina de Estados do ITReq

A máquina de estados do ITReq (Figura 3) está diretamente relacionada ao processo de revisão e aprovação definido na organização. O tratamento individual de requisitos através da máquina de estados trouxe também um ganho não planejado para os projetos: maior agilidade no processo de revisão de requisitos, visto que os requisitos podem ser revisados indi-vidualmente, o que não poderia ser feito facilmente com o uso de documentos.

Outra funcionalidade essencial é o controle das alterações de documentos com o uso de um histórico de revisões e com o armazenamento, tornando possível a comparação com outras versões de documentos (Figura 4).

A ferramenta gera o documento de requisitos em formato HTML seguindo o template definido no processo organiza-cional com seções para descrição do projeto, aprovadores, glossário, histórico de revisões, referências e requisitos agrupados em seções definidas pelo usuário.

Salomé – Gerenciamento de TestesDiferentemente das ferramentas descritas até agora, Sa-

lomé TMF (Test Management Framework) é uma ferramenta independente, isto é, não foi construída 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 requi-sito cadastrado no ITReq, bem como registrar os resultados da execução dos casos de testes para cada ciclo de testes

executado. Para cada ciclo, o usuário seleciona as suítes de testes (conjunto de casos de testes) que serão executados e reporta o resultado da execução (Figura 5).

Figura 4. Ferramenta ITReq: armazenamento das versões, histórico de versões e os requisitos relacionados

Figura 5. Ferramenta Salomé


Salomé-TMF é também compatível com JUnit, Abbot e Be-anshell, sendo possível a definição de testes automáticos.

Integração entre as FerramentasTodas as ferramentas descritas possuem alguma integração

entre si. ITReq está integrada com Salomé, sendo possível acessar os casos de testes de cada requisito a partir dessa ferramenta, como mostra a Figura 6.

O Mantis possui integrações com o Rev.I.S.E, ITReq e Salo-mé. A partir de uma CR de melhoria criada no Mantis, por exemplo, pode-se acessar as revisões 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 CR’s, é possível visualizar todos os requisitos impactados e os respectivos casos de testes, facilitando a identificação dos casos de testes que devem ser executados devido à melhoria implementada no projeto.

Projeto Piloto e Institucionalização das Ferramentas

Após a conclusão do processo de seleção das ferramentas, foi dado início ao planejamento do projeto piloto para a customização e testes das ferramentas selecionadas. As seguintes fases podem ser destacadas:• Planejamento e alocação dos recursos necessários para implementação das melhorias e customizações com o su-porte organizacional;

• Implementação e testes dos requisitos de cada uma das ferramentas;• Planejamento de quais projetos em execução na organização iriam adotar e avaliar as ferramentas;• Execução dos projetos piloto com o apoio do SEPG (Software Engineering Process Group) e Engenheiros de Qualidade e Configuração alocados ao projeto;• Coleta de resultados e de sugestão de melhorias nas ferra-mentas após finalização do período do piloto.

Após a execução do projeto piloto, o primeiro passo foi o envolvimento do SEPG na seleção e priorização das me-lhorias 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 início à implementação das mudanças.

O grupo também precisou realizar um planejamento do uso institucionalizado das ferramentas, isto é, como colocar as ferramentas em uso em novos projetos. Essa ação incluía também as alterações a serem realizadas no processo orga-nizacional, como elaboração de guias e treinamentos para uso das ferramentas customizadas e integradas.

Além das mudanças no processo, o SEPG passou a atuar como facilitador na utilização das ferramentas pelos de-mais projetos da organização.

Conclusões e Resultados ObtidosA produtividade dos projetos aumentou notavelmente

com as customizações e integrações de todas as ferramentas supracitadas. É possível ter uma maior rastreabilidade entre as mudanças, um melhor controle do processo, além de agi-lidade na hora da criação e manutenção das requisições de mudança, requisitos do produto e revisões de artefatos.

Para se ter uma idéia da grande aceitação dessas ferra-mentas na organização, faz-se necessário destacar alguns números:• 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 revisões em código e documentos;• Salomé: em uso por quatro projetos.

Antes de utilizar as ferramentas, os membros das equi-pes passam por um treinamento organizacional para que consigam utilizar melhor os recursos oferecidos por elas, aumentando ainda mais sua produtividade.

As ferramentas estão em constante melhoria. As soli-citações de melhoria podem ser realizadas por qualquer pessoa dentro da organização através do próprio Mantis, onde há um projeto específico para cada ferramenta para reportagem de sugestões de melhoria, bem como de defeitos encontrados.

Em relação aos ganhos deste processo de tomada de deci-são e do uso das ferramentas, pode-se destacar os seguintes aspectos:

Figura 6. Ferramenta ITReq integrada com a Salomé

Figura 7. Integração do Mantis com o Rev.I.S.E


PRoCESSo

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.

Referências• Quanto ao impacto, houve uma disseminação 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 esforço de alteração e manutenção nas ferramentas, visto que se tratam de ferramentas open-source;• Quanto à inovação, apesar do uso de ferramentas open-source em projetos de desenvolvimento de software já ser algo conhe-cido pela comunidade, foi possível, a partir de uma ferramenta já institucionalizada na organização, realizar customizações para atender outros processos relacionados, integrando-os e automatizando seus passos.




Dê

seu Feedback

sob

re esta edição

Figura 8. Integração do Rev.I.S.E com o Mantis

Figura 9. Integração com o ITReq a partir do Mantis

50 Engenharia de Software Magazine - Métricas de Software

Thamine Chaves de Abreu [email protected]

Atualmente cursa especialização em De-senvolvimento de Aplicações para Web no Centro de Ensino Superior de Juiz de Fora (CES/JF), Bacharel em Sistemas de Infor-mação pela Universidade Severino Sombra (USS), Desenvolvedor de Sistemas Web na Granbery Consultoria Júnior em projeto para a Fundação COPPETEC, possui expe-riência de 4 anos em desenvolvimento de sistemas Java (web/desktop).

Leonardo da Silva Mota [email protected]

Atualmente cursa especialização em De-senvolvimento de Aplicações para Web no Centro de Ensino Superior de Juiz de Fora (CES/JF), Bacharel em Sistemas de Infor-mação pela Universidade Severino Sombra (USS), Desenvolvedor de Sistemas Web na Granbery Consultoria Júnior em projeto para a Fundação COPPETEC, programa-dor certificado Java (SCJP), atuou como professor assistente no curso de Sistemas de Informação da USS e dos cursos de in-formática da Fundação de Apoio a Escola Técnica (FAETEC), possui experiência de 4 anos em desenvolvimento de sistemas Java (web/desktop).

Marco Antônio Pereira Araújo [email protected]

Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor dos cursos de Bacharelado em Sistemas de Informação 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.

De que se trata o artigo?O artigo trata da utilização de métricas de software no gerenciamento de projetos, sendo fortes aliadas na estimativa, acompanhamento e apoio em toma-da de decisões durante a construção de produtos de software, visando uma melhor qualidade de todo este processo.

Para que serve?Métricas de software servem para apresentar medi-das, preferencialmente quantitativas, que reflitam características específicas de processos e de produtos em construção, podendo ser utilizadas em diferentes dimensões, como esforço, tamanho, complexidade, dentre outras.

Em que situação o tema é útil?A coleta adequada de métricas, com suas res-pectivas análises, pode auxiliar o Engenheiro de Software na tomada de decisões ao longo do desenvolvimento de um projeto, visando a melhoria da qualidade do processo e do produto em construção.

Métricas de Software Como utilizá-las no gerenciamento de projetos de software

A garantia da qualidade é uma das principais preocupações da indústria de desenvolvimento

de software, pois atualmente a maior parte das empresas atuantes no mercado utiliza esse tipo de aplicação para gerir seus negócios, produtos e relacionamen-tos com clientes, necessitando maior confiabilidade e qualidade. Existem diversas medidas de garantia de qua-lidade fundamentais para o sucesso de qualquer tipo de aplicação de software,

dentre elas, uma das mais simples e menos custosa, é a medição de software. Nesse sentido, a medição de software auxilia a tomada de decisão, pois através




GERêNCIA DE PRojEtoS

de dados quantitativos, é capaz de informar que aspectos do produto atendem ou não ao padrão de qualidade especificado, além de permitir a avaliação dos benefícios de novos métodos e ferramentas de engenharia de software, o entendimento e aperfeiçoamento do processo de produção, a avaliação do retorno do investimento e tornar o gerenciamento de projetos baseado em fatos e não “achismos”, por exemplo.

Para medir software, são utilizadas diversas métricas que são como tipos de medições aplicadas a um sistema de software, documentação ou processo relacionado. Através dessas métri-cas é possível determinar o esforço ou tempo para realização de uma tarefa ou o tamanho do produto, por exemplo. Além disso, as métricas de software são facilmente calculadas, en-tendidas e testadas e independem do observador que as aplica, sendo também uma boa fonte para estudos estatísticos acerca do ciclo de vida do software.

Dentro desse contexto, este artigo tem por objetivo apresentar algumas métricas de software e sua importância no processo de desenvolvimento. Para isso, algumas métricas serão aplica-das em pequenos exemplos, permitindo ao leitor compreender e analisar seus benefícios imediatos.

Utilização de métricasExistem dois tipos de métricas no contexto de desenvolvi-

mento de produtos de software: as métricas diretas, que são realizadas em termos de atributos observáveis, como por exemplo, esforço, tamanho e custo, e as métricas indiretas ou derivadas, que podem ser obtidas através de outras métricas, como por exemplo, complexidade, confiabilidade, e facilidade de manutenção. Quanto ao contexto, podem ser aplicadas em produtos ou em processos. Quando as métricas incidem dire-tamente no produto de software, são chamadas de métricas de predição, quando em processos de software, são comumente chamadas de métricas de controle e sua aplicação normalmente é realizada em processos já maduros e controlados.

Para obter resultados significativos, as métricas devem ser aplicadas em um ciclo constante, que envolve as etapas de planejamento, medição, análise de resultados, tomada de de-cisão e implementação das decisões. Desta maneira, pode-se construir uma base histórica do artefato medido que permitirá ao engenheiro de software analisar que processos, ferramentas e métodos melhor se aplicam àquele tipo de produto. Alguns cuidados também devem ser tomados no processo de medição, como o momento e a escolha do conjunto de métricas mais relevantes a serem aplicadas, e a comparação entre produtos através da aplicação de métricas (pois nenhum produto é igual a outro). O escopo, os desenvolvedores e o ambiente são fatores que podem influenciar o processo de desenvolvimento. Assim, comparações devem ser cuidadosamente analisadas.

As métricas 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 softwa-re através de métricas significativas, as medições devem ser definidas de acordo com objetivos específicos. Nesse sentido, o

GQM (Goal/Question/Metric), desenvolvido por Basili em 1988, é uma abordagem para aplicação de métricas afim de aprimorar o processo de desenvolvimento de software (e, consequente-mente, os produtos de software gerados) enquanto mantém os objetivos de negócio e objetivos técnicos da organização nivelados. É uma abordagem top-down que estabelece uma medição sistemática para objetivos relacionados ao processo de desenvolvimento, em que a equipe começa estabelecendo os objetivos organizacionais, define metas de medição, insere questões com o propósito de abordar os objetivos especifica-dos e identifica as métricas que fornecem respostas para as questões definidas.

O GQM define um modelo de três níveis, ilustrado na Figura 1.

Figura 1. Níveis do modelo do GQM

O GQM pode ser aplicado em todo o ciclo de vida de produ-tos, processos e artefatos de software e é bem alinhado com o ambiente organizacional, sendo um meio adequado para conseguir dados confiáveis e conhecimento sobre as práticas de software da organização para conduzir a melhoria do processo. Nesse contexto, é útil para auxiliar na compreensão e formar um baseline das práticas aplicadas no desenvolvi-mento de software, evoluir as atividades de medição, guiar e monitorar processos de software e reduzir custos de desen-volvimento, por exemplo. O GQM pode ser utilizado também como base de fundamentação para outras técnicas de medição de software.

O GQM pode ser muito útil na definição de quais métricas são necessárias de serem coletadas e analisadas para responder questões sobre um determinado objetivo. Isso é importante para evitar que esforço seja gasto com coleta desnecessária de métricas, que provavelmente nunca serão utilizadas.

Algumas métricas comumente utilizadasSoftwares podem ser medidos (ou estimados) baseados em

diversos tipos de perspectivas, como tamanho e complexidade. Além disso, em função da etapa do desenvolvimento, diferen-tes métricas podem ser colhidas para um mesmo produto. Por exemplo, para a medição de tamanho na etapa de levantamento de requisitos, podemos utilizar como métrica o número de requisitos especificados. Já na fase de projeto, o tamanho pode ser medido em função do número de classes e, na fase de codi-ficação, a partir no número de linhas de código fonte.

A seguir, serão apresentadas algumas das principais mé-tricas baseadas nos tipos de medição citados e, para melhor


compreensão, serão utilizados exemplos de códigos e aplicação das métricas.

Análise de Pontos de Função (APF): visa estimar o ta-manho do software baseado em Pontos de Função (PFs). Seu objetivo é medir as funcionalidades do software, sem se preocupar com a tecnologia que será utilizada na im-plementação e, pode ser aplicado já nos estágios iniciais do desenvolvimento de software. A Tabela 1 apresenta as fases para sua medição.

Número de linhas de código (LOC, KLOC): assim como a APF, visa estabelecer o tamanho de um sistema, baseando-se no número de linhas de código. Essa medição pode auxiliar o engenheiro de software a determinar o tamanho de uma aplicação já construída ou estimar o esforço a ser conside-rado para a obtenção de um produto a ser desenvolvido. Embora seja bastante objetiva, bastando analisar o código-fonte de produtos concluídos para obtê-la, ela pode variar de acordo com a linguagem de programação utilizada e, portanto, as estimativas devem considerar dados de projetos similares apenas na mesma linguagem.

Complexidade Ciclomática (CC): proposta por McCabe em 1976, fornece uma medida quantitativa da complexidade lógica de um programa. Através dessa métrica é possível definir o número de caminhos possíveis de um algoritmo através do seu número de condições (if, for, while, do e switch) e assim, especificar o quanto um sistema é complexo e, por conseqüência, testável, pois apresenta um indício do número de casos de teste a serem realizados para cobrir as possibilidades de um algoritmo. O ideal é que a complexi-dade ciclomática seja baixa, pois desta forma, as funções podem ser mais facilmente entendidas e modificadas. O

FASE DESCRIÇÃO

Determinar o tipo de contagem de pontos de função Existem três tipos de contagem que podem ser levadas em conta: contagem de PF de projeto de desenvolvimento, de aplicações instaladas e

de projetos de manutenção.

Determinar o escopo de contagem e a fronteira da aplicação A fronteira da aplicação é definida estabelecendo um limite lógico entre a aplicação que está sendo medida, o usuário e outras aplicações. O

escopo para a contagem define a parte do sistema (funcionalidades) a ser contada.

Determinar a contagem de pontos de função não ajustados Essa contagem leva em conta dois tipos de função: de dados e transacionais, bem como sua complexidade (simples, média ou complexa).

Contagem das funções de dados Contagem referente às funcionalidades relativas aos requisitos de dados internos e externos à aplicação.

Contagem das funções transacionais Contagem referente às funcionalidades de processamento de dados do sistema fornecidas para o usuário, como entradas e consultas externas.

Determinar o valor do fator de ajuste Baseado em diversas características gerais de sistemas, que avaliam a funcionalidade geral da aplicação que está sendo contada e seus níveis

de influência que podem ser determinados com base em uma escala de 0 a 5.

Calcular os pontos de função ajustados PFs ajustados são calculados, considerando o tipo de contagem definido no primeiro passo.

tabela 1. Fases para a medição por pontos de função

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 cálculo da complexidade ciclomática, será utilizado um algoritmo para cálculo de aprovação de um aluno. Os possíveis caminhos no algoritmo são nume-rados, conforme mostra a Figura 2.

Figura 2. Numeração de possíveis caminhos em um algoritmo

Existem diversas formas de cálculo da CC, através de fór-mulas, ou pela contagem de caminhos possíveis. A Tabela 3 ilustra as possíveis formas de cálculo da complexidade ciclomática para este algoritmo.

Para programas grandes e complexos, calcular a com-plexidade ciclomática de cada função pode se tornar uma tarefa exaustiva. Por este motivo, ferramentas automatizadas podem ser utilizadas, como o plugin Metrics for Eclipse (ver seção Links), um plugin gratuito para a IDE Eclipse que calcula a complexidade em sistemas desenvolvidos na linguagem Java. A Figura 3 ilustra o cálculo realizado pela ferramenta.

Complexidade Situação1-10 Programa simples, baixo risco.

11-20 Programa mais complexo, risco moderado.

21-50 Programa complexo, risco alto.

Maior que 50 Programa não testável, risco elevado.

tabela 2. Faixas de Complexidade Ciclomática. Fonte: SEI – Software Engineering Institute (http:// www.sei.cmu.edu)



Métricas de Chidamber & Kemerer (CK): foram propostas por Chidamber & Kemerer em 1994, um conjunto de seis mé-tricas que permitem a análise quantitativa dos artefatos de software construídos utilizando o paradigma da orientação a objetos. Essas métricas têm o objetivo de salientar as classes que possivelmente contém maior número de defeitos, com o propósito de direcionar os esforços de teste.

1. WMC (Weighted methods per class - Métodos ponderados por classe): cálculo do número de serviços por classe, que pode auxiliar o engenheiro de software indicando o esforço necessário para o teste de complexidade da classe. Quando classes apresentam um alto WMC, significa que tendem ser específicas, ou seja, destinando-se a necessidades individuais, o que restringe sua reutilização.

2. DIT (Depth of the inheritance tree - Profundidade da árvore de herança): número máximo de superclasses acima da classe em questão. Um DIT alto pode indicar que (i) a classe em questão herdou muitas características comuns a outras classes, indicando que suas superclasses estão preparadas

Forma de cálculo Cálculo

Contagem através dos números de

arcos e nós

CC = E – N + 2

onde:

E= número de arcos

N= número de nós

Contagem através do número de

nós predicados (que indicam uma

decisão)

CC = P + 1

onde:

P= número nós predicados (decisões)

Contagem visual Através do número de regiões fechadas do gráfico

construído, considerando também a região externa

Contagem dos caminhos possíveis 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 cálculo da Complexidade Ciclomática

Figura 3. Cálculo da complexidade ciclomática no plugin Metrics for Eclipse

para reutilização, visto que provavelmente possuem alto nível de abstração, (ii) pode indicar que a classe herda mui-tos serviços, o que pode aumentar consideravelmente sua complexidade.

3. NOC (Number of children - Número de filhos): número de subclasses posicionadas imediatamente abaixo da classe em questão. Um NOC alto indica que uma superclasse possui muitos filhos que necessitaram implementar características próprias, demonstrando baixo nível de abstração, visto que podem existir poucas características em comum entre as classes filhas. A Figura 4 exibe uma hierarquia de classes, que demonstra um NOC de valor três. Pode-se observar que quanto maior o número de métodos e atributos especializados, menores são as chances de reutilização das classes filhas e mais complexas ficam as operações de polimorfismo. Em uma situação simples, como a do exemplo, o valor NOC não tem impacto negativo sobre o sistema, porém caso o cenário seja um sistema complexo com muitas classes “filhas”, é importante acompanhar os valores de NOC, com o propósito de tomar medidas que evitem números altos.

Figura 4. Hierarquia de classes, que demonstra um NOC de valor 3

4.CBO (Coupling between object classes - Acoplamento entre classes de objetos): é o nível de acoplamento entre as classes. Um CBO alto indica que a classe possui muitos rela-cionamentos, o que dificulta sua reutilização e aumenta sua complexidade, visto que a classe torna-se dependente de outras para efetuar suas operações. Essa métrica auxilia o engenheiro de software a avaliar o nível de reaproveitamento da aplicação e o esforço despendido em testes.

5.LCOM (Lack of cohesion in methods - Falta de coesão em métodos): Número de acessos a um ou mais atributos em co-mum pelos métodos da própria classe. Quanto maior o LCOM, menos coesa é a classe. A coesão em métodos é a capacidade dos métodos realizarem apenas a função a que são destinados e, para isso devem acessar apenas atributos essenciais ao seu funcionamento. Portanto, é importante que o LCOM seja baixo a fim de aumentar a reutilização e diminuir a complexidade da classe.


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 número de métodos que podem ser chamados em resposta a uma mensa-gem recebida por um objeto ou por algum método da classe. Quanto maior o RFC, maior a possibilidade da classe atender às suas funções. Em contrapartida, para obter um RFC alto, é necessário projetar uma estrutura de classes adequada que possa tender a essa particularidade, o que acaba gerando maior complexidade, tornando necessário maior esforço de teste.

Métricas de Lorenz & Kidd: Lorenz & Kidd, também em 1994, propuseram um conjunto de quatro métricas, comumente cha-madas métricas LK, que se baseiam assim como as métricas CK, no cálculo quantitativo de alguns aspectos fundamentais da Orientação a Objetos, como os atributos, métodos, herança, coesão e acoplamento. A diferença entre as métricas LK e as métricas CK é em relação à metodologia empregada em seu cálculo.

1.CS (Class size - Tamanho da classe): é o número de métodos e atributos da própria classe e herdados de suas superclasses. Um número alto de CS indica que a classe pode ser muito espe-cífica, atendendo necessidades privadas, o que pode dificultar sua reutilização e aumentar sua complexidade.

2.NOO (Number of operations overriden by a subclass - Número de operações redefinidas por uma subclasse): número de sobrescritas de métodos em subclasses. Os métodos herdados de uma superclasse podem ser sobres-critos, ou seja, redefinidos em subclasses, com o propósito de tornar sua funcionalidade mais específica. De certa forma, essa redefinição de métodos pode ferir a abstração implícita da superclasse e um número elevado de NOO pode indicar problemas estruturais, pois muitas subclas-ses do sistema têm métodos redefinidos e possivelmente estão hierarquicamente mal projetadas. Utilizando ainda o exemplo da Figura 4, nas Listagens 1, 2 e 3 pode-se ob-servar trechos de código das três classes (Gerente, Diarista e Vendedor), que redefinem o método calculaSalario(). As classes Gerente e Vendedor também redefinem o método getCargo(), e ainda,a classe Vendedor redefine o método getDepartamento(). Apesar de não representar um risco estrutural para o projeto, no caso do exemplo, o número de métodos redefinidos indica quais classes devem ter sua evolução acompanhada. Em um projeto de grande porte e crítico, 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 métrica com a ferramenta Metrics for Eclipse.

3. NOA (Number of operations added by a subclass - Número de operações adicionadas por subclasse): número de métodos e atributos definidos em uma subclasse. Um NOA alto quer

Figura 5. Coleta da Métrica NOO pela ferramenta Metrics for Eclipse, aqui chamada de Number of Overridden Methods

Listagem 1. métodos gerCargo() e calculaSalario() redefinidos na classe Gerente

public String getCargo (){ return “Gerente”;}public double calculaSalario(){double taxaTotal=(getSalario()*taxaDependentes)*numDependentes; return getSalario()-getDesconto() + taxaTotal; }

Listagem 2. método calculaSalario() redefinido na classe Diarista

public double calculaSalario(){ return horasTrabalhadas * valorHora;}

Listagem 3. métodos 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);}

dizer que a subclasse adicionou muitos métodos e atributos em sua definição, o que indica um problema estrutural, já que boa parte de seus atributos deveria ser definida em super-classes. Além de aumentar a complexidade do sistema como um todo, um valor elevado de NOA reduz as possibilidades de reutilização.

4. SI (Specialization index - Índice de especialização): nú-mero de métodos adicionados, eliminados ou redefinidos em uma classe. Na verdade, essa métrica complementa as métricas NOO e NOA e um valor alto indica também um problema de estruturação de classes, já que possivelmente foram realizadas alterações para atendimento de necessidades específicas. Clas-ses muito específicas dificilmente são reaproveitadas, ferindo um dos princípios básicos da OO, a reutilização.

A seguir, são apresentadas na Figura 6 as possíveis mé-tricas coletadas de um fragmento de sistema de controle de Recursos Humanos, através da ferramenta Metrics for Eclipse, para demonstrar como é simples e rápida a coleta de um conjunto significativo de métricas através de ferramentas automatizadas.



Alguns outros tipos de métricasDiversos outros tipos de métricas são largamente utilizados,

como métricas de confiabilidade e esforço. Métricas de confiabilidade são normalmente baseadas em

número de defeitos apresentados por uma aplicação, poden-do ser medidas por intervalo de tempo ou por versão de um produto em uso. Nessa categoria, ferramentas de apoio como BugZilla, Mantis ou Trac são boas aliadas para o registro e acompanhamento de defeitos.

Métricas de esforço são importantes no acompanhamento de processos de software, sendo comumente utilizada a medição de esforço por Homem/Hora, ou alguma derivada desta, como Homem/Mês, que refletem a quantidade de recursos humanos alocados ao projeto por unidade de tempo.

ConclusãoMétricas de software são medidas quantitativas acerca de

processos ou produtos de software. O artigo procurou mostrar

Figura 6. Métricas coletadas pela ferramenta Metrics for Eclipse




Dê

seu Feedback

sob

re esta edição

algumas das métricas mais conhecidas e exemplificar o uso de algumas delas através de exemplos simplificados, com o propósito de acentuar a importância de sua utilização em um projeto. As métricas são capazes de indicar pontos em que são necessários maiores esforços de teste e acompanhamento. Através de ferramentas automatizadas, é possível coletar um grande número de métricas com menor esforço, o que viabi-liza a implantação de processos de medição em qualquer tipo de sistema, desde os mais simples até os mais críticos, o que contribui para a qualidade do produto final.

56 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion

Victor Vidigal Ribeiro [email protected]

É pós-graduando do Curso de Gerência de Projetos em Engenharia de Software pelo Centro de Ensino Superior de Juiz de Fora – CES/JF, Bacharel em Sistemas de Infor-mação pela Faculdade Metodista Granbery e Analista de Sistemas da Granbery Consul-toria Junior, atuando em projeto vinculado à Fundação COPPETEC/UFRJ.

Fabrício Nogueira de [email protected]

É pós-graduando do Curso de Gerência de Projetos em Engenharia de Software pelo Centro de Ensino Superior de Juiz de Fora – CES/JF, Bacharel em Sistemas de Infor-mação pela Faculdade Metodista Gran-bery e Analista de Sistemas da Uptodate Consulting.

De que se trata o artigo?Montagem de um ambiente de integração con-tínua utilizando um conjunto de ferramentas para este fim.

Para que serve?O ambiente de integração contínua proposto mantém o código fonte do repositório sempre testado, aumentando sua confiabilidade, além de diminuir a alocação de recursos humanos em atividades de teste.

Em que situação o tema é útil?Em ambientes em que é preciso manter um repositório com código fonte confiável e em sis-temas em que os testes atingiram uma comple-xidade relevante e estão consumindo recursos humanos em excesso ao serem executados.

Integração contínua com Hudson, Maven2, TestNG e Subversion

Devido à crescente demanda por softwares cada vez mais com-plexos e de maior qualidade,

várias técnicas vêm sendo propostas para auxiliar na sua construção. Uma dessas técnicas é o teste de unidade que tem como principal finalidade a busca por defeitos na menor unidade de um sistema como um método ou função, por exemplo.

Porém, em um sistema com uma com-plexidade relevante, os testes de unidade podem consumir um tempo excessivo da equipe cada vez que uma alteração no sistema seja necessária e os testes tenham que ser executados.

Marco Antônio Pereira Araújo [email protected]

Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor dos cursos de Bacharelado em Sistemas de Informação 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.

É neste contexto que se pode tirar pro-veito da integração contínua, onde um servidor faz periodicamente o checkout do código fonte do repositório e executa automaticamente os testes já criados.

Com isto, ao subir um código para o repositório não é necessário que todos os testes do sistema sejam executados. Pode ser definida uma estratégia onde o

Validação, Verificação e Teste

Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens de VV&T no apoio ao desenvolvimento de projetos de software


PRojEto

responsável por enviar o código para o repositório execute apenas os testes diretamente relacionados com a alteração realizada, diminuindo o tempo gasto com a execução dos testes.

Além disto, a execução periódica dos testes ajuda a manter a confiabilidade do código fonte que está no repositório.

Este artigo tem por finalidade demonstrar a configuração de um ambiente de integração contínua utilizando um servidor de integração contínua chamado Hudson, em um repositório controlado pelo Subversion, e um projeto criado no Eclipse utilizando o Maven2 através do plug-in Maven2Eclipse e o framework de testes TestNG.

Criando o repositórioO primeiro passo para iniciar a construção do ambiente é

baixar e instalar o Subversion. Será utilizado o VisualSVN que é um servidor do Subversion que disponibiliza uma interface gráfica para configuração e que pode ser baixado no endereço http://www.visualsvn.com/.

A instalação do VisualSVN é bastante simples, basta executar o arquivo de instalação baixado e seguir os passos mantendo sempre as configurações padrões sugeridas pelo instalador.

Depois de instalado e executado, o VisualSVN apresenta uma tela semelhante à Figura 1.

Figura 1. Configuração VisualSVN

Neste momento é preciso configurar os usuários e grupos de usuários que terão acesso ao repositório. Como exemplo, será criado apenas um usuário chamado “devmedia” que pode ser incluído clicando com o botão direito sobre a opção Users, selecionando a opção New User e definindo um login e senha para este usuário.

Depois de criar o usuário, será criado um repositório chama-do CalcularAprovacao. Para isso, clique com o botão direito sobre a opção Repositories e selecione a opção Create New Repository. Uma caixa de texto será aberta onde deve ser di-gitado CalcularAprovacao no nome do repositório.

Note que a URL do Subversion pode ser vista na tela inicial do VisualSVN no campo Server URL is. Posteriormente essa URL será necessária para configurar o servidor de integração e o Eclipse.

Feito isto, as configurações necessárias no repositório estão prontas.

Configurando o EclipsePara facilitar a criação do ambiente, primeiro será instalado

um plug-in chamado Subclipse que permite a comunicação entre o Eclipse e o repositório. Para isto, abra o eclipse e acesse o menu Help / Install New Software. Uma janela será apresen-tada onde o endereço http://subclipse.tigris.org/update_1.6.x deve ser digitado no campo Work with e, em seguida, deve-se acessar a opção Add. Ao acessá-la, algumas opções irão apare-cer no campo Name desta janela, onde devem ser marcadas as opções Core SVNKit Library, Optional JNA Library e Subclipse, como pode ser visto na Figura 2 e, logo em seguida, deve-se selecionar a opção Next até que a instalação seja concluída.

Figura 2. Instalação do Subclipse

Neste momento o plug-in Subclipse está instalado e deve-se agora instalar o plug-in Maven2Eclipse. Para isso, siga o mesmo procedimento, porém, utilizando o endereço http://m2eclipse.sonatype.org/update/ e selecionando apenas a opção Maven Integration no campo Name.

Com isto, o Eclipse já está com todos os plug-ins que preci-samos para começar a criar o projeto de exemplo e se integrar com o Hudson.

Criando o projeto de testePara criar o projeto de exemplo utilizaremos o Maven2

através 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 convenção, ou seja, permite a compilação e a distribuição de


uma aplicação com um mínimo de configuração, desde que o projeto respeite a estrutura proposta, e ainda gerencia as dependências do projeto.

Para iniciar a construção do projeto, acesse o menu File / New / Other. Uma janela será apresentada onde a opção Maven / Maven Project deve ser escolhida. Após isto, uma nova janela é apresentada onde a opção Create a simple project deve ser marcada e, logo em seguida, deve ser selecionada a opção 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 organiza-ção 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 versão do artefato gerado pelo projeto, deixare-mos esta opção como padrão.• 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 relatórios que podem ser gerados pelo Maven. Neste campo será digitado CalcularAprovacao.• Description: neste campo pode ser digitada uma breve des-crição sobre o projeto.

Figura 3. Criação de um projeto Maven2

Após preencher os dados do projeto, clique sobre o botão Finish que o Maven irá criar o projeto utilizando sua estrutura padrão.

Depois de criar o projeto, deve ser adicionada a dependência do TestNG, que é o framework de testes que será utilizado. Clique com o botão direito sobre o projeto e selecione o menu

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 repo-sitório online as dependências com o nome TestNG. Selecione a opção org.testng testng e clique sobre o botão Ok. Feito isto, o Maven2Eclipse adiciona algumas linhas no arquivo de configuração do Maven (chamado pom.xml) e irá baixar as dependências necessárias para que o TestNG funcione.

Apesar do Maven2Eclipse facilitar bastante a configuração do Maven, uma configuração manual deve ser adicionada no arquivo pom.xml. A tag <build> e suas sub-tags devem ser adicionadas indicando que o código do projeto deve ser com-pilado para versão 1.6 do Java. Com isto, o arquivo pom.xml deve ficar semelhante ao mostrado na Listagem 1.

Depois disso, clique com o botão direito sobre o projeto e selecione a opção New / Package e crie um pacote chamado br.com.calcularAprovacao dentro de src/main/Java para armazenar o código do exemplo. Outro pacote com o mesmo nome também deve ser criado dentro de src/test/java para armazenar os casos de testes.

Neste momento, a estrutura do projeto está criada e confi-gurada para trabalhar com o TestNG. Agora, é preciso criar uma classe chamada Aluno que contém um método chamado calcularAprovacao(). Este método será testado pelos casos de testes que serão 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>


PRojEto

Crie a classe Aluno. Ela deve ser criada dentro de src/main/Java utilizando o código 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; } } } } } }

Depois de criar a classe Aluno, será criada a classe Calcu-larAprovacaoTest que contém os casos de teste. Esta classe deve ser criada dentro de src/test/Java, e deve conter o código mostrado na Listagem 3.

Pode-se perceber que esta classe contém a anotação @Test que faz com que o TestNG a reconheça 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 repositório. Para isto, clique com o botão direito sobre o projeto e selecione a opção Team / Share Project. Ao selecionar essa opção, uma janela é exibida onde deve ser escolhido o tipo do repositório. Selecione a opção SVN, que é a sigla para Subversion, e clique sobre Next. Uma nova janela é exibida onde a opção Create a

new repository location deve ser selecionada e, logo em segui-da, a opção Next deve ser escolhida. Feito isto, uma nova janela é exibida onde a URL do Subversion (https://localhost:8443/svn/CalcularAprovacao/) deve ser digitada. Após isso, clique sobre a opção Finish.

Listagem 3. Classe de teste CalcularAprovacaoTest

package br.com.testeAprovacao;import org.testng.annotations.Test;import org.testng.*;import br.com.calcularAprovacao.Aluno;

@Testpublic class CalcularAprovacaoTest { public void testAlunoReprovadoFrequencia() { Aluno aluno = new Aluno(); aluno.setNome(“João”); 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(“João”); aluno.setNota1(70); aluno.setNota2(70); aluno.setNotaFinal(0); aluno.setFrequencia(75); Assert.assertTrue(aluno.calcularAprovacao()); } public void testAlunoReprovadoNota() { Aluno aluno = new Aluno(); aluno.setNome(“João”); 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(“João”); aluno.setNota1(30); aluno.setNota2(30); aluno.setNotaFinal(69); aluno.setFrequencia(75); Assert.assertFalse(aluno.calcularAprovacao()); } public void testAlunoAprovadoFinal() { Aluno aluno = new Aluno(); aluno.setNome(“João”); aluno.setNota1(30); aluno.setNota2(30); aluno.setNotaFinal(70); aluno.setFrequencia(75); Assert.assertTrue(aluno.calcularAprovacao()); }}

Figura 4. Estrutura do Projeto

Com o procedimento anterior, o Subclipse vinculou o projeto ao repositório, mas ainda não subiu o código para este repo-sitório. Para subir o código clique novamente sobre o projeto


e selecione a opção Team / Commit. Ao selecionar esta opção uma janela é exibida onde é possível escrever um comentário sobre o código que está sendo enviado ao repositório. Digite “Primeiro commit para o subversion” e clique sobre o botão Ok. Com isto, o código é enviado ao repositório.

Configurando o HudsonDepois de ter realizado os procedimentos anteriores, chegou

a hora de configurar o Hudson, que é um servidor de integra-ção contínua.

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 através 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 endereço http://localhost:8080/hudson para entrar na interface de configuração.

Na página de configuração do Hudson, o menu Gerenciar Hudson / Configure System deve ser acessado para iniciar a configuração, como mostra a Figura 5.

Figura 5. Configurações do Hudson

Há muitas maneiras diferentes de se configurar o Hudson e, por conta disso, serão mostradas as principais configurações que são necessárias para seu funcionamento.

O primeiro campo, Mensagem do Sistema, é apenas a men-sagem inicial que será exibida ao acessar o Hudson.

O campo Número de executores informa qual é a quantidade de builds concorrentes que o Hudson pode fazer. Isso porque um servidor do Hudson pode rodar vários projetos simulta-neamente. Já no campo Período de Silêncio 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 aconteça algum erro nesse procedimento.

A opção Habilitar segurança deve estar marcada para que se possa definir como o Hudson irá controlar os usuários. Ao habilitar a segurança, o Hudson fornece opções de controle de usuário. Selecione a opção Hudson’s own user database para que os usuários sejam controlados pelo próprio Hudson.

Logo abaixo, marque também a opção Logged-in users can do anything para permitir que os usuários criados posteriormente tenham permissão para fazer qualquer coisa no Hudson.

Um pouco mais abaixo na janela de configuração, como pode ser visto na Figura 6, é possível configurar o Maven e o JDK que serão utilizados. Para incluir o Maven, clique sobre o botão Add Maven e digite Maven no campo Name e, em Version, selecione a opção 2.2.1.

Para adicionar o JDK, clique sobre o botão Add JDK, digite jdk6 no campo Name e, em JAVA_HOME, informe o diretório onde o JDK está instalado.

Figura 6. Configuração do Maven e JDK

A próxima e última configuração é referente ao envio de e-mails. Caso esteja configurado, o Hudson envia e-mails cada vez que é executado, informando o resultado de sua execução. Para configurar essa funcionalidade, na parte de Notificação de E-mail, informe o endereço do servidor SMTP no campo Servidor SMTP e o sufixo padrão para e-mail de usuário. Sufixo padrão para e-mail de usuário indica ao Hudson que o endereço de e-mail de cada usuário é formado pelo nome do usuário mais o sufixo padrão. Por exemplo, se o sufixo padrão for configurado como @gmail.com e um usuário chamado de-vmedia for adicionado, o Hudson irá entender que o endereço de e-mail desse usuário é [email protected].

Deve-se preencher o Endereço de e-mail do Administrador do sistema com o endereço de e-mail do administrador.

No campo URL do Hudson deve ser definido o endereço do Hudson, com http://localhost:8080/hudson.

Como exemplo, será utilizado o SMTP do GMail que necessita de autenticação para funcionar. Para configurar esta autenticação clique sobre o botão Avançado, marque a opção Use SMTP Authentication, digite o nome do usuário, a senha e, caso seja necessário, marque a opção Usar SSL. A Figura 7 mostra como ficou a configuração dessa parte do Hudson.

O envio de e-mail pode ser testado através do botão Con-figuração de teste para enviar e-mail para o endereço do Administrador do Sistema. Acessando esse botão, um e-mail de teste é enviado.


PRojEto

Pode-se perceber que do lado de cada campo há um , que caso acionado, exibe a descrição do campo que está a sua esquerda. Este recurso é de grande auxílio na configuração do Hudson.

Após realizar as configurações anteriores, o botão Salvar deve ser acionado. Com isso, o Hudson exibe uma página onde o primeiro usuário deve ser criado. Para o exemplo, foi criado um usuário chamado devmedia.

Criando tarefas no HudsonDepois de configurar o Hudson, é preciso criar uma tarefa

informando a ele que deve baixar o projeto do repositório e executar os testes criados.

Ao clicar na opção 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 CalcularAprova-cao. É preciso definir também o tipo de tarefa que, no caso do exemplo, será escolhida a opção Construir um projeto Maven2. Após isto, clique sobre o botão Ok e uma nova janela é exibida onde é possível configurar a tarefa construída.

Em Gerenciamento de Código Fonte, selecione a opção Sub-version e digite a URL do Subversion em URL do Repositório. O Hudson irá informar que não consegue acessar o repositório, isto é porque ainda não foi definido um usuário e senha para acessá-lo. Clique sobre o link enter credential para definir o usuário do repositório.

No campo Diretório do módulo local deve ser digitado o nome do projeto que foi criado no Eclipse e, portanto, deve-se digitar CalcularAprovacao.

A opção Usar Atualização é bastante interessante. Caso seja marcada, o Hudson não faz o checkout de todo o projeto no-vamente. Ele faz o checkout apenas dos arquivos que foram alterados no repositório. A Figura 8 mostra como esta parte da configuração do repositório deve estar.

A próxima configuração diz respeito à periodicidade do Hu-dson, ou seja, o Hudson pode ser configurado para rodar de tempos em tempos. Para isso, em Disparadores de Construção,

Figura 7. Configurações do servidor de SMTP

a opção Construir periodicamente deve ser marcada, e o cam-po 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_mês mês dia_semana.

Figura 8. Configuração do Subversion no Hudson

Após isto, em Construir, é preciso informar no campo POM Raíz 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 parâmetro que faz com que o Hudson execute o Maven para rodar os testes criados.

Uma última configuração que deve ser feita é marcar a opção Notificação de E-mail para que um e-mail com os relatórios de execução do Hudson seja enviado cada vez que o Hudson for executado.

Para salvar as configurações, deve ser acionado o botão Salvar. Com isso, o Hudson exibe a página inicial da tarefa que acabou de ser criada.

Com essas configurações, o Hudson irá baixar o projeto do repositório e executar os testes criados às 0:00 horas de cada dia. É possível executar a tarefa criada a qualquer momento também através do menu Construir Agora.

Na parte esquerda do Hudson, como pode ser visto na Figura 9, pode ser visualizado um histórico das construções que foram realizadas, e também de alguma eventual cons-trução que esteja sendo executada.

Figura 9. Histórico de Construção

Caso alguma construção não tenha sido realizada com sucesso, é possível ver o motivo do erro clicando sobre a construção e, em seguida, sobre o menu Console output. Ao acessar esta opção, o Hudson exibe a saída gerada pela construção. A Figura 10 mostra um exemplo de saída em que a construção falhou, sendo possível verificar o motivo da falha.


O Hudson também disponibiliza um relatório de tendência onde é possível visualizar graficamente os resultados dos testes executados. A Figura 11 mostra o relatório gerado no projeto de exemplo.

O gráfico apresenta o número da construção pelo seu tempo de execução. Enquanto as áreas vermelhas do gráfico represen-tam as construções que falharam, as cinzas são construções que foram abortadas. Já as amarelas são as construções que foram executadas com sucesso parcial e as construções executadas com sucesso total são representadas pela cor azul.

Figura 11. Gráfico de tendências

Apesar do ambiente proposto ter mostrado apenas a execução de testes de unidade através do Hudson, é possível integrar também ferramentas de checkstyle de código, detecção de bugs e cobertura de testes, por exemplo.

Além disso, o Hudson é extensível através de plug-ins que podem fornecer funcionalidades como integração com

Figura 10. Saída de Console

ferramentas de acompanhamento de defeitos (Bugzilla, Man-tis, Trac), suporte a outras linguagens (.net, ruby) e até mesmo integração com o Twitter.

ConclusãoO artigo procurou mostrar como configurar um ambiente de

integração contínua utilizando diferentes ferramentas.O ambiente foi construído utilizando o servidor de integração

Hudson, o repositório Subversion, com o uso do VisualSVN para instalação do servidor, e o plug-in Subclipse para integra-ção com o Eclipse, o gerenciador de projetos Maven2, através do plug-in Maven2Eclipse, e o framework de teste TestNG.

Um ambiente de integração contínua, como o apresentado neste artigo, possibilita a execução de testes de maneira auto-matizada o que pode torná-los mais eficientes e economizar recursos humanos nessa tarefa. Além disso, com a execução periódica dos testes, é mais rápida a identificação de falhas inseridas no código fonte pelos desenvolvedores. Devido a isto, o código do repositório pode ser considerado mais confiável.

Outra vantagem desse ambiente é que se torna possível um melhor acompanhamento da execução de testes através de relatórios gerados pelo Hudson.

Hudsonhttp://hudson-ci.org/

VisualSVNhttp://www.visualsvn.com/

Subclipsehttp://subclipse.tigris.org/

TestNGhttp://testng.org

Links




Dê

seu Feedback

sob

re esta edição


PRojEto

Seis Sigma + CMMI 21

Documents

Transcript of Seis Sigma + CMMI 21