qualidade de software - danielbarbosa77.files.wordpress.com · qualidade de software • empresas...

Qualidade de Software

Daniel Oliveira, MSc, MCP, MCSD, MCDBA

• “Uma característica ou atributo de alguma coisa”.• Segundo a norma ISO 9000 (versão 2000),

a qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.

• Como atributo, a qualidade se refere a características mensuráveis;

• Quando falamos de software, por tratar-se de algo essencialmente intelectual, é mais difícil de caracterizar do que dos objetos físicos e, portanto, definir qualidade de software, não é uma tarefa simples.

• Existem medidas que podem ser atribuídas às características de um programa.

O que é qualidade?

• No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento, desta forma, é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento.


Porque Qualidade de Software?

• Hoje, quais são os problemas enfrentados na construção e utilização de software?

• Ao lermos o relatório da conferência da NATO de 1968 e outros documentos produzidos na década de 1970, fazemos uma descoberta assustadora: os problemas são os mesmos que encontramos atualmente.

Lista de problemas• Cronogramas não observados;• Projetos com tantas dificuldades que são abandonados;• Módulos que não operam corretamente quando

combinados;• Programas que não fazem exatamente o que era

esperado;• Programas tão difíceis de usar que são descartados;• Programas que simplesmente param de funcionar...

Imprevisibilidade no Desenvolvimento de Software

• Existe uma zona de sombra que envolve fatores desconhecidos.

Imprevisibilidade no Desenvolvimento de Software

• Conciliar a necessidade de disciplina – fundamental para garantir uma certa previsibilidade de resultados – com o caráter relativamente aleatório da criação de soluções talvez seja um dos maiores desafios.

• As metodologias têm sido desenvolvidas, testadas e adaptadas há décadas, buscando reduzir a um mínimo a necessidade de “inventar soluções”.

• Em grande parte, as metodologias têm caráter pedagógico:– mostram o que é preciso fazer para conduzir um projeto, quais procedimentos

adotar e como realizá-los, – como trabalhar em equipes de maneira a evitar a veiculação de informações

dúbias etc.

Projetos de Software

• Problemas conhecidos que geraram prejuízos:– Therac-25– Aeroporto de Denver– Ariane 5

Problemas no Desenvolvimento de Softwares

• Equipamento de Radioterapia.• Entre 1985 e 1987 se envolveu em 6

acidentes, causando mortes por overdoses de radiação.

• Software foi adaptado de uma antecessora, Therac-6:– falhas por falta de testes integrados– falta de documentação

Therac-25

Denver International Airport

• Custo do projeto: US$ 4.9 bilhões• 100 mil passageiros por dia• 1.200 voos• 53 milhas quadradas• 94 portões de embarque e desembarque• 6 pistas de pouso / decolagem

Denver International Airport

• Erros no sistema automático de transporte de bagagens (misloaded, misrouted, jammed):• Atraso na abertura do aeroporto com custo total estimado em

US$360 Milhões• 86 milhões para consertar o sistema

Ariane 5

• Projeto da Agência Espacial Européia que custou:– 10 anos.– US$ 8 Bilhões.

• Capacidade 6 toneladas.• Garante supremacia

européia no espaço.

Vôo inaugural em 4/junho/1996

Resultado

• Explosão 40 segundos após a decolagem.

• Destruição do foguete e carga avaliada em US$ 500 milhões.

• Fato: o veículo detonou suas cargas explosivas de autodestruição e explodiu no ar. Por que?

• Porque ele estava se quebrando devido às forças aerodinâmicas. Mas por que?

• O foguete tinha perdido o controle de direção (atitude). Causa disso?

• Os computadores principal e back-up deram shut-down ao mesmo tempo.

O que aconteceu?

• Por que o Shut-down? Ocorrera um run time error (out of range, overflow , ou outro) e ambos computadores se desligaram. De onde veio este erro?

• Um programa que convertia um valor em ponto flutuante para um inteiro de 16 bits recebeu como entrada um valor que estava fora da faixa permitida.

O que aconteceu?

• O resultado desta conversão não era mais necessário após a decolagem...

Ironia...

• Porque demora tanto para concluir um projeto (não cumprimos prazos)?

• Porque custa tanto (uma ordem de magnitude a mais)?• Porque não descobrimos os erros antes de entregar o

software ao cliente?• Porque temos dificuldade de medir o progresso enquanto o

software está sendo desenvolvido?

Perguntas que precisamos responder

Qualidade do Processo de Software

• Pontos Relevantes– Definição de um ciclo de vida;– Conformidade com requisitos especificados;– Integridade dos produtos do desenvolvimento

com os requisitos;– Controle de versões;– Padronização;– Testes e Inspeções;– Planejamento e gerenciamento efetivo.

Melhoria de Processode Software

• Princípios– Grandes mudanças devem ser iniciadas de cima pra

baixo;– Todos devem ser envolvidos;– Mudanças efetivas devem ser construídas com base em conhecimento;– Mudanças são contínuas;– Mudanças no processo são incorporadas através de

motivação e esforço;– Melhoria de processo de software requer investimento.


• Empresas que desenvolvem software com qualidade e dentro de custos aceitáveis são mais competitivas;

• Empresas que tem qualidade em seus processos podem, em geral, oferecer um melhor serviço a um preço mais competitivo.

• Para discutir: Processos garantem um software de Qualidade?

• Alguns desenvolvedores acreditam que a preocupação com a qualidade começa depois que o código foi gerado, no entanto, é importante que se esclareça que a Garantia da Qualidade de Software (SQA – Software Quality Assurance) é uma atividade guarda-chuva (de apoio), que é aplicada ao longo do processo de software.

Qualidade

• Garantir a qualidade do software implica diretamente em reduzir a quantidade de trabalho refeito, que por sua vez, resulta em menores custos e melhor prazo para colocação no mercado.

Qualidade

• Preocupados com o estreito vínculo entre qualidade doprocesso de software e qualidade do produto desoftware, surgiram então, na década de 90, abordagensimportantes como as normas/metodologias:– ISO 9000,– ISO/IEC 12207, – Modelo CMMi - Capability Maturity Model– SPICE - Software Process Improvement and Capability

dEtermination.– MPS BR

Qualidade do Processo de Software

CMM e CMMi

CMMI – Capacity Maturity Model

• São modelos que incluem uma coleção de melhores práticas que ajudam as organizações a melhorar seus processos.

• Estes modelos são desenvolvidos por equipes com membros da indústria, governo e da SEI (Software EngineeringInstitute)

CMMI no Mundo

http://www.blogcmmi.com.br/avaliacao/lista-de-empresas-cmmi-no-brasil

CMMI no Mundo

CMMI no Brasil – Nível 2• 7COMm SP 2005• Advance IT RS 2010• Algar Tecnologia MG 2010• Alstom Transportes SP 2002• AMS Tecnologia SP 2004• Atech Tecnologias Críticas SP 2003• Atos Origin SP 2004• ATT/PS Informática MG 2009• Avansys Tecnologia BA 2009• Brasília DF 2003• BRQ SP 2004• BSI Tecnologia PR 2004• C.E.S.A.R PE 2003• Cetil Sistemas de Informática SC 2009• Citibank SP 2003• Claro SP 2010• Complex SP 2009• CPM SC 2005• CPM SP 2005• CPqD SP 2003• Credicard SP 1998• CTIS DF 2005• CTIS PR 2007• DB1 Informática PR 2010• DBServer RS 2009• DBC Company RS 2010• Defferrari Sistemas RJ 2011• Dell RS 2003• Digistar RS 2010• Disoft SP 2003• DRM SP 2005• DTS Latin America SP 2003• e-Dablio RJ 2003• Embraer SP 2006• FITec PE 2005

• Fortaleza CE 2003• Foursys Projetos e Sistemas

SP 2010• Gad’Brivia RS 2010• G&P – Gennari & Peartree SP

2003• General Motors SP 2005• Getronics SP 2005• GSW SP 2008• GVDASA Informatica RS 2009• HP SP 2005• ilegra RS 2009• Inatel MG 2003• Infoserver SP 2004• Inovare Tecnologia PR 2010• Instituto Atlântico CE 2003• Interact Solutions RS 2009• Itaú SP 2005• Itautec SP 2008• IVIA CE 2008• Johnson & Johnson SP 2008• Kostal Eletromecânica SP

2008• LG Sistemas GO 2008• LinkNet DF 2010• Logocenter SC 2005• Kenta Informática RS 2010• M.I. Montreal Informática RJ

2004• Matera Systems SP 2005• MATERA Systems Informática

SP 2009• Message RJ 2008• META IT RS 2007• Microsiga Software SP 2005• MJV Tecnologia RJ 2009

• MSA Informática MG 2005• Nec do Brasil SP 2003• Pitang High Performance RS 2009• Prime Informática SP 2005 e 2011• Procwork SP 2005• Phoebus PB 2010• Recife PE 2002• Red & White IT Solutions GO 2009• Relacional - 2006• Relacional Consultoria RJ 2005• RGM Informática SP 2008• Santander Banespa SP 2005• Scopus SP 2010• SERPRO Salvador BA 2003• Sigma Dataserv Informatica PR 2010• Sistran SP 2009• Spress Informática S/A MG 2005• Stefanini SP 2002• Suntech SC 2009• SyMap Solutions SP 2010• T-Systems SP 2005• Techpeople SC 2011• Teclógica Serviços em Informática SC 2009• Tele Design SP 2002• Telefonica Pesquisa e Desenvolvimento SP 2007• Telefônica Pesquisa e Desenvolvimento SP 2008• TSE DF 2005• Unitech BA 2005• Vixteam ES 2006• Vorlans - 2007• ZCR Informática BA 2006• ZCR Informática BA 2009

CMMI no Brasil – Nível 3• 7COMm SP 2008• Accenture SP 2005• Accenture Brazil SP 2009• Accenture Delivery Center SP 2004• Atos Origin SP 2007• B2Br – Business to Business Informática

DF 2008• BRQ PR 2011• BSI Tecnologia PR 2010• Cast Informática DF 2010• C.E.S.A.R – Recife Center PE 2007• Chemtech RJ 2011• Cinq Technologies PR 2009• CI&T SP 2004• CITS – Centro Internacional de

Tecnologia de Software PR 2009• CPqD SP 2009• CTIS DF 2010• CWI Software Ltda RS 2009• DATUM RS 2009• DBA Engenharia de Sistemas RJ 2001 e

2011

• e-Core RS 2009• EDS SP 2001• Ericsson SP 2001• G&P SP 2011• GPTI SP 2010• Hold SP 2009• IBM Fábrica de Software SP 2003• Inovare PR 2010• Instituto Atlantico CE 2006• Instituto de Pesquisas Eldorado

SP 2005• Itaú SP 2007• Itatec SP 2010• Kaizen Consultoria e Serviços SP

2008• Meta IT PR 2010• Motorola SP 2001• NTConsult RS 2009• Pitang Consultoria & Sistemas PE

2011• Politec SP 2005 e 2009• Qualitas SP 2006• Resource SP 2010

• Senior Sistemas SC 2008• Serasa SP 2008• Senior Sistemas SC 2011• Sofhar Gestão e Tecnologia PR

2009• Spress Informática S/A MG

2007• Stefanini SP 2003• Synapsis Brasil Ltda RJ 2009• T-Systems do Brasil SP 2009• TIVIT SP 2007• Tlantic SI RS 2009• Triad System SP 2009• Unisys Corporation SP 2009• Xerox do Brasil ES 1997

CMMI no Brasil – Nível 4

• Ci&T SP 2006• EDS RJ 2003

CMMI no Brasil – Nível 5• Accenture SP 2005 e 2009• BRQ SP 2006• Ci&T SP 2007• CPM Braxis BA 2007 e 2010• EDS SP 2006• EDS SP 2008• IBM RJ 2005• Instituto Atlantico CE 2009• Politec DF 2006• Spread Systems – MSA-Infor Unit MG 2010• Stefanini SP 2005• Tata Consultancy Services DF 2004• Unisys MG 2005

Histórico• O SW-CMM (Capability Maturity Model for Software) é

um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software deste último.

• Início dos trabalhos deu-se em 1986, tendo sido publicada a versão 1.0 do SW-CMM em agosto de 1991.

• Em fevereiro de 1993, foi publicada a versão 1.1.• O objetivo inicial era:

– Avaliar a capacidade de fornecedores– Melhoria dos processos dos fornecedores

Histórico• Por ser específico para a área de software, o SW-CMM

não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas.

• Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas:– Gestão de Recursos Humanos (People-CMM)– Aquisição de Software (SA-CMM)– Engenharia de Sistemas (SE-CMM)

• Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.

SoftwareCMM

SystemsSecurity

Engineering CMM

SystemsEngineering

CMM

PeopleCMM

SECM (EIA 731)

IntegratedProduct

DevelopmentCMM

SoftwareAcquisition

CMM

• Diferentes estruturas, formatos, termos, maneiras de medir maturidade

• Causa confusão, especialmente quando mais de um modelo é utilizado

• Difícil de integrar em um único programa de melhoria

Histórico

• Proliferação de Modelos e Padrões em diversas áreas

Histórico• O CMMI (Capability Maturity Model Integration)

foi criado, então, com a finalidade de integrar os diversos modelos CMM.

• Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated – System / Software Engineering).

• Versões do CMMI:– Versão 1.0: 2000– Versão 1.1: 2002– Versão 1.2: 2006 (CMMI for Development)– Versão 1.3: 2010

Histórico

SW-CMM• Modelo de Maturidade de Capacitação para Software• Objetivo Principal: guiar organizações a conhecerem e

melhorarem seus processos de software.• Identifica práticas para um processo de software

maduro, definindo as características de um processo de software efetivo.

• Descreve como as práticas de engenharia de software evoluem sob certas condições.

• Organiza os estágios de evolução da melhoria dos processos em cinco níveis de maturidade.

SW-CMM: Estrutura• Cada nível de maturidade, com exceção do primeiro, é

composto por áreas-chave de processo (Key ProcessAreas – KPAs).

• Cada KPA identifica atividades relacionadas que, quando executadas adequadamente, atingem determinados objetivos considerados importantes para o aumento da capacidade do processo.

• As KPAs são os requisitos para a obtenção de um nível no CMM.

• As KPAs são cumulativas, isto é, para uma organização atingir um determinado nível de maturidade, ela deve satisfazer todas as KPAs daquele nível e de seus inferiores.

SW-CMM: Estrutura

• Cada KPA é descrita em termos de práticas-chave (Key Practices).

• Uma prática-chave descreve as atividades e a infra-estrutura necessárias para a efetiva implementação e institucionalização de uma KPA.

• Uma prática-chave descreve “o quê” deve ser feito, e não “como” deve ser feito.

SW-CMM: Estrutura

• Para cada KPA há metas a serem alcançadas, que caracterizam o seu conteúdo, escopo e limite.

• Metas são usadas para determinar se a organização ou projeto efetivamente implantou a KPA em questão.

• Em uma avaliação de conformidade com o CMM, o mais importante é verificar se todas as metas da KPA foram atingidas

SW-CMM – Níveis de Maturidade

• Um nível de maturidade é um patamar evolutivo bem definido, que visa a alcançar um processo de software maduro.

• Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de software.

• No nível 2 por exemplo, são focados aspectos gerenciais dos projetos.

• O conceito de maturidade é baseado na noção de que alguns processos provêm mais estrutura e controle do que outros.



Nível CMM Áreas-chave de processo (KPA)1) Inicial2) Repetível Gerenciamento de requisitos

Planejamento do projetoVisão geral e acompanhamento do projetoGerenciamento de sub-contratadosGarantia da qualidade do softwareGerenciamento de configuração

3) Definido Foco do processo organizacionalDefinição do processo organizacionalPrograma de treinamentoGerenciamento de software integradoEngenharia de produto de softwareCoordenação intergruposRevisão conjunta

4) Gerenciado Gerenciamento quantitativo dos processosGerenciamento da qualidade de software

5) Otimizado Prevenção de defeitosGerenciamento de mudanças tecnológicasGerenciamento de mudanças no processo

SW-CMM: Nível 1 (Inicial)

• O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico.

• Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heroicos.

• O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.

SW-CMM: Nível 1

• Organizações no nível 1 apresentam deficiências de planejamento e enfrentam dificuldades ao realizarem previsões.

• Cronogramas e planos são irrealistas.• Como não há credibilidade no planejamento, mesmo aquilo que foi

planejado não é seguido.• Não há controle de requisitos e o cliente só os avalia na entrega do

produto.• É comum passar diretamente dos requisitos à codificação.• A documentação é encarada como algo inútil.• São comuns reações intransigentes à coleta de dados e ao uso de

padrões, documentação e ferramentas.

SW-CMM: Nível 2 (Repetível)

• Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo.

• É possível repetir sucessos de projetos anteriores em aplicações similares.

• Ao invés do processo ser uma única caixa preta, ele passa a ser uma sequência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

SW-CMM: Nível 2

• Neste nível, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente.

• A organização é disciplinada, mas não está bem preparada para mudanças.

• Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise.

• Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos.

• Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.

SW-CMM: KPAs do Nível 2

• Gerência de Requisitos• Planejamento de Projetos• Supervisão e Acompanhamento de

Projetos• Gerência da Subcontratação de Software• Garantia da Qualidade de Software• Gerência de Configuração de Software

SW-CMM: Nível 3 (Definido)• Um processo de software, composto por atividades de gerência e

engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização.

• Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software.

• A organização interna das tarefas está definida e visível

SW-CMM: Nível 3• Processos utilizados são estabelecidos e padronizados em toda a

organização.• Os processos pertencem à organização e não aos projetos.• O Grupo de Processos (Software Engineering Process Group - SEPG) é

responsável pelos processos da organização.• Apesar da padronização, é possível adaptar os processos para as

necessidades particulares de um projeto.• Processos de engenharia de software são considerados ao lado dos

processos gerenciais.• Há treinamento técnico e gerencial.• A organização consegue se manter dentro do processo mesmo em

períodos de crise.• Como o processo é bem definido, caso um desenvolvedor abandone o

projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores.

• Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores práticas existentes na organização.


• Foco no Processo da Organização • Definição do Processo da Organização • Programa de Treinamento • Gerência de Software Integrada • Coordenação entre grupos • Engenharia de Produtos de Software • Revisão por Pares

54

SW-CMM: Nível 4 (Gerenciado)

• Métricas detalhadas do processo de software e da qualidade do produto são coletadas.

• Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.

SW-CMM: Nível 4• A organização estabelece metas quantitativas de qualidade e

produtividade para as atividades do processo e para os produtos produzidos são estabelecidas para cada projeto.

• Medidas de qualidade e produtividade são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento e a ocorrência de problemas.

• Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída.

• É estabelecido o controle estatístico de processos.• Uma organização no nível 4 passa a ter uma gestão feita com

bases quantitativas.


• Gerência Quantitativa dos Processos• Gerência da Qualidade de Software

SW-CMM: Nível 5 (Otimizado)

• A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa, e da implantação planejada e controlada de tecnologias e ideias inovadoras.

SW-CMM: Nível 5

• A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos.

• O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo.

• Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina.

• Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo / benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4.


• Prevenção de Defeitos • Gerência da Evolução dos Processos • Gerência da Evolução das Tecnologias

60

CMMI• Proposta de um modelo integrado que pode ser utilizado

em várias disciplinas.• Disciplinas do CMMI

– Engenharia de Software – Engenharia de sistemas: abordagem interdisciplinar cujo

objetivo é o desenvolvimento bem-sucedido de sistemas como um todo, envolvendo software ou não.

– Desenvolvimento integrado do produto e processo: abordagem sistemática que utiliza a colaboração dos stakeholders para melhor satisfazer as expectativas e requisitos dos clientes. Usada em conjunto com práticas de produção de um produto específico.

– Fontes de Aquisição: aquisição de produtos de fornecedores.

Objetivos do CMMI

• Além da integração dos modelos e redução dos custos com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI:– Aumento do foco das atividades– Integração dos processos existentes– Eliminar inconsistências– Reduzir duplicações– Fornecer terminologia comum– Assegurar consistência com a norma ISO 15504– Flexibilidade e extensão para outras disciplinas

CMMI• É um modelo que descreve orientações para a definição

e implantação de processos.• O modelo não descreve processo algum, são

orientações definidas através das práticas especificadas.

• Método de avaliação utilizado: SCAMPI (Standard CMMI Assessment Method for Process Improvement)– Método que reúne as melhores práticas do CBA-PI e SCE

(métodos amplamente utilizados pelo SW-CMM e outros modelos de melhoria de processos)

CMMI: Conceitos Básicos

• Área de Processo (Process Area – PA): práticas relacionadas em uma área que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria nessa área.

• Metas Específicas: se aplicam a uma PA e tratam de características que descrevem o que deve ser implementado para satisfazer essa PA. São utilizadas nas avaliações para auxiliar a determinar se a PA está sendo satisfeita.


• Práticas Específicas: atividades que são consideradas importantes na satisfação de uma meta específica associada.

• Metas Genéricas: aparecem em diversas PAs.• Práticas genéricas: oferecem uma institucionalização que

assegura que os processos associados com a PA serão eficientes, repetíveis e duráveis.

• Produtos de trabalho típicos: exemplos de saídas de uma prática específica ou genérica.

• Sub-práticas: descrições detalhadas que fornecem um direcionamento para a interpretação de práticas específicas ou genéricas.

Exemplo: Meta e Prática Específicas

• PA: Gerência de Requisitos– Meta Específica: Gerenciar Requisitos

• Requisitos são gerenciados e inconsistências com planos de projeto e produtos de trabalho são identificados.

– Prática Específica: Manter rastreabilidade bidirecional entre requisitos.

• Manter rastreabilidade bidirecional entre os requisitos e planos de projeto e produtos de trabalho.

– Produtos de Trabalho Típicos: Matriz de rastreabilidade, Sistema de Acompanhamento de Requisitos

Exemplo: Meta e Prática Genéricas

• Meta Genérica (do Nível 2 de Capacidade ou Maturidade)– Institucionalizar um processo gerenciado.

• Prática Genérica (do Nível 2 de Capacidade ou Maturidade)– Estabelecer uma política organizacional.


• Metas específicas e metas genéricas são componentes exigidos do modelo. Esses componentes devem ser atingidos pelos processos planejados e implementados por uma organização.

• Práticas específicas e práticas genéricas são componentes esperados do modelo. Os componentes esperados descrevem o que uma organização normalmente implementará para satisfazer um componente exigido.


• Sub-práticas, produtos de trabalho típicos, entre outros, são componentes informativos do modelo que auxiliam os usuários do modelo a entender as metas e práticas e a maneira como elas devem ser satisfeitas. Os componentes informativos fornecem detalhes que auxiliam os usuários do modelo a começar a pensar em como abordar as metas e práticas.

CMMI: Representações

• Contínua– Níveis de Capacidade– Agrupamento de Áreas de Processo por Categoria– Avaliação da Capacidade nas Áreas de Processo

• Por Estágios– Níveis de Maturidade– Agrupamento de Áreas de Processo por Nível– Avaliação da Organização / Unidade Organizacional como um

todo

• As PAs do CMMI são as mesmas para ambas as representações.

Áreas de Processo do CMMI

• PAs são organizadas em quatro categorias de processo: Gerenciamento de Processos, Gerenciamento de Projetos, Engenharia e Suporte.

Gerenciamento de Processos• Atividades relativas à definição, planejamento,

distribuição de recursos, aplicação, implementação, monitoramento, controle, avaliação, medição e melhoria de processos.

• Envolve as seguintes PAs:– Foco no Processo Organizacional (básica)– Definição do Processo Organizacional (básica)– Treinamento Organizacional (básica)– Desempenho do Processo Organizacional

(avançada)– Inovação e Desenvolvimento Organizacional

(avançada)

Gerenciamento de Projetos• Atividades de gerência de projetos relacionadas

ao planejamento, monitoramento e controle do projeto.

• Envolve as seguintes PAs:– Planejamento de Projetos (básica)– Monitoramento e Controle de Projetos (básica)– Gerência de Acordos com Fornecedores (básica)– Gerência Integrada de Projetos (avançada)– Gerência de Riscos (avançada)– Integração de Equipes (avançada)– Gerência Quantitativa de Projetos (avançada)

Engenharia• Atividades de desenvolvimento e manutenção

que são compartilhadas entre as disciplinas de engenharia (por exemplo, engenharia de sistemas e engenharia de software).

• Envolve as seguintes PAs:– Desenvolvimento de Requisitos (RD)– Solução Técnica (TS)– Integração de Produtos (PI)– Verificação (VER)– Validação (VAL)

Suporte• Atividades que apoiam o desenvolvimento e a

manutenção de produtos. • As PAs de Suporte tratam os processos que são

utilizados no contexto da execução de outros processos, a saber:– Gerência de Configuração (básica)– Garantia da Qualidade do Processo e do Produto (básica)– Medição e Análise (básica)– Ambiente Organizacional para Integração (avançada)– Análise de Decisões e Resoluções (avançada)– Análise de Causas e Resoluções (avançada)

Representação Contínua: Estrutura

Representação Contínua: Estrutura

• Metas específicas organizam práticas específicas.

• Metas genéricas organizam práticas genéricas • Cada prática (específica / genérica)

corresponde a um nível de capacidade.• Metas e práticas específicas aplicam-se a áreas

de processo individuais.• Metas e práticas genéricas aplicam-se a várias

áreas de processo.

Representação Contínua: Níveis de Capacidade

• Um nível de capacidade descreve a capacidade de uma área de processo.

• Há seis níveis de capacidade, cada um representando uma camada na base para a melhoria contínua do processo.

• Assim, níveis de capacidade são cumulativos, ou seja, um nível de capacidade mais alto inclui os atributos dos níveis mais baixos.

• Uma vez que os modelos CMMI são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade proveem uma ordem recomendada para abordar a melhoria de processo dentro de cada área de processo.

Representação ContínuaNíveis de Capacidade

Representação Contínua

Representação Por Estágios: Estrutura

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Características Comuns

Process Area 1 Process Area n

Ability Implementation

Verifying to Perform

Commitment Directing Implementation

Specific Goals

Implementation Specific Practices

Níveis de Maturidade

Práticas Genéricas

Metas Genéricas

Área de Processo 2 Área de Processo 1 Área de Processo n

Habilitação Implementation Verificação da Compromisso Implementação

Metas Específicas

Implementação Práticas Específicas

Representação por Estágios: Níveis de Maturidade

• Um nível de maturidade é um plano bem definido de um caminho para tornar a organização mais madura.

• Existem cinco níveis de maturidade.• Cada nível representa uma camada na base

para a melhoria contínua do processo.

Representação Por Estágios: Características Comuns

• Agrupamentos que oferecem uma maneira de apresentar as práticas genéricas. São elas:– Compromisso: agrupa as práticas genéricas relacionadas à criação de

políticas e à garantia de patrocínio. – Habilitação: agrupa as práticas genéricas relacionadas a assegurar que

o projeto e/ou organização possuem os recursos que necessitam. – Implementação: agrupa as práticas genéricas relacionadas à gerência

do desempenho do processo, gerência da integridade de seus produtos de trabalho e envolvimento dos stakeholders relevantes.

– Verificação da Implementação: agrupa as práticas genéricas relacionadas a revisões pelo nível mais alto de gerenciamento e a avaliações objetivas de conformidade a descrições de processos, procedimentos e padrões.

Representação por EstágiosNíveis de Maturidade

Comparando as Representações

Em Estágios

NM1

NM2

NM3

NM4

NM5

Um conjunto de áreas de processo de um nível de maturidade (NM).

PA PA

Cap

acid

ad

e

PA

Contínua

Uma única área de processo (PA) ou um conjunto de áreas de processo.

Representação Estagiada

Representação Contínua: Vantagens

• Fornece maior flexibilidade focando em áreas de processo específicas de acordo com metas e objetivos de negócio;

• Permite a comparação de áreas de processo entre diferentes organizações;

• Estrutura familiar para aqueles que estão migrando da comunidade de engenharia de sistemas;

• Foco bem definido nos riscos específicos de cada área de processo;

• Estrutura compatível com a ISO/IEC 15504.

Representações Por Estágios: Vantagens

• Fornece uma rota de implementação por meio de:– grupos de área de processo– implementação em sequência– cada nível funciona como a fundação para o próximo

• Estrutura familiar para aqueles que estão migrando do SW-CMM.

• Habilidade de gerenciar processos ao longo da organização.

• Em uma avaliação, atribui um nível de maturidade em que a organização se encontra, permitindo, assim, comparar organizações de forma direta.

Áreas de Processo – Nível 2

Representação por Estágio: PAs do Nível 2

• Suporte:– Gerência de Configuração – Configuration Management (CM)– Garantia da Qualidade do Processo e do Produto – Process

amd Product Quality Assurance ( PPQA)– Medição e Análise – Measurement and Analysis (MA)

• Gerenciamento de Projetos– Gerência de Requisitos – Requirements Management (REQM)– Planejamento de Projeto – Project Planning (PP) – Monitoração e Controle de Projeto – Project Monitoring and

Control (PMC)– Gerência de Acordo com Fornecedores – Supplier Agreement

Management (SAM)

CMMI: Objetivos das PAs do Nível 2

• Gerência de Requisitos(REQM): gerenciar os requisitos dos produtos e componentes de produtos do projeto e identificar as inconsistências entre estes requisitos e os planos e os produtos de trabalho do projeto.

• Envolve:– Assegurar que o conjunto de requisitos acordados é gerenciado

para apoiar as necessidades de planejamento e execução do projeto.

– Documentar as mudanças nos requisitos e suas justificativas, e manter a rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos de produtos e componentes de produtos.


• Planejamento de Projetos(PP): estabelecer e manter planos que definem as atividades do projeto. Envolve:– Desenvolver o plano do projeto– Interagir com os stakeholders de forma

apropriada– Obter compromissos com o plano– Manter o plano


• Monitoramento e Controle do Projeto(PMC): oferecer um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. Envolve:– Monitorar atividades, comunicar status e tomar as a ções

corretivas. – O progresso é basicamente determinado pela comparaç ão

dos atributos reais de produtos de trabalho e taref as, esforço, custo e cronograma com o que foi planejado .


• Gerenciamento de Acordos com Fornecedores(SAM): gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal. Envolve:– Determinar o tipo de aquisição que será utilizada para os

produtos a serem adquiridos– Selecionar os fornecedores– Estabelecer e manter acordos com fornecedores– Executar o acordo com o fornecedor– Aceitar a entrega dos produtos adquiridos– Fazer a transição dos produtos adquiridos para o projeto


• Medição e Análise(MA): desenvolver e sustentar a capacidade de medições que é utilizada para apoiar as necessidades de gerenciamento de informações. Envolve:– Especificar os objetivos de medições e análises, de forma que

estes estejam alinhados com as necessidades e objetivos de informações identificados

– Especificar as medidas, mecanismos de coleta de dados e armazenamento, técnicas de análises e mecanismos de comunicação e de feedback

– Implementar a coleta, armazenagem, análise e relatórios sobre os dados

– Fornecer resultados objetivos que possam ser utilizados na tomada de decisões bem informadas e na tomada das ações corretivas apropriadas


• Garantia da Qualidade do Processo e do Produto(PPQA): fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Envolve:– Avaliar objetivamente os processos, produtos de trabalho e

serviços executados contra as descrições de processo, padrões e procedimentos aplicáveis

– Identificar e documentar questões de não conformidades– Fornecer feedback para a equipe do projeto e gerentes sobre os

resultados das atividades de garantia da qualidade– Assegurar que as questões de não conformidades sejam

tratadas


• Gerência de Configuração (CM): estabelecer e manter a integridade dos produtos de trabalho, utilizando a identificação da configuração, controle da configuração, comunicação do status da configuração e auditorias de configurações.

• Envolve:– Identificar a configuração de produtos de trabalho selecionados que

compõem as baselines em determinados momentos no tempo– Controlar as mudanças nos itens de configuração– Construir ou fornecer especificações para construir produtos de trabalho a

partir do sistema de gerenciamento de configurações– Manter a integridade das baselines– Fornecer um status preciso e os dados atuais de configurações para

desenvolvedores, usuários finais e clientes

Áreas de Processo – Nível 3

Representação por Estágio: Nível 3

• Gerenciamento de projetos– Gerência de Projeto Integrada (IPM) – Integrated Project

Management– Desenvolvimento de Requisitos (RD) – Requirements

Development– Gerência de Riscos (RSKM) – Risk Management

• Engenharia:– Solução Técnica (TS) – Technical Solution– Integração do Produto (PI) – Product Integration– Verificação (VER) - Verification– Validação (VAL) - Validation

Representação por Estágio: Nível 3

• Gerenciamento de Processos:– Foco no Processo Organizacional (OPF) - Organizational

Process Focus– Treinamento Organizacional (OT) – Organizational Training– Definição do Processo Organizacional (OPD) _ Organizational

Process Definition

• Suporte– Análise de Decisão e Resolução (DAR) – Decision Analysis and

Resolution


• Gerência de Projeto Integrada (IPM): O objetivo o IPM é estabelecer e gerenciar o projeto e os envolvidos (Stakeholders) de acordo com um processo definido, integrado e alinhado com o conjunto de processos organizacionais.

• Envolve:– Estabelecer processos definidos;– Gerenciar os projetos usando esses processos;– Estabelecer o ambiente de trabalho baseado nos padrões organizacionais;– Estabelecer equipes responsáveis por atingir os objetivos do projeto;– Usar e contribuir para melhoria dos processos organizacionais;– Identificar e envolver todos os stakeholders durante o projeto;– Assegurar que todos os envolvidos estão executando suas tarefas conforme

planejado, gerenciar os requisitos, planos, objetivos, problemas e riscos e resolver possíveis problemas;


• Desenvolvimento de Requisitos (RD): O objetivo do RD é elicitar, analisar e estabelecer os requisitos do cliente e do produto.

• Essa área de processo descreve três tipos de requerimentos: – Requerimentos do cliente– Requerimentos do Produto– e Requerimentos dos componentes do produto.

• Envolve:– Elicitação, analise, validação e comunicação das expectativas e necessidades

do cliente;– Coordenação das necessidades dos stakeholders;– Desenvolvimento dos requerimentos de ciclo de vida do produto;– Identifica e define os atributos de qualidade;


• Gerência de Riscos (RSKM): o objetivo do RSKM é identificar potenciais problemas antes que eles ocorram e definir atividades que possam ser planejadas e evocadas caso algum imprevisto aconteça durante o ciclo de vida do produto ou projeto. Essas atividades irão mitigar os possíveis impactos sobre os objetivos do projeto.

• Envolve:• Definir a estratégia de gerenciamento de Riscos;• Identificar e analisar riscos;• Gerenciar os riscos identificados, incluindo a implementação de planos de

mitigação de riscos, caso sejam necessários;


• Solução Técnica (TS): O objetivo do TS é selecionar e implementar soluções para os requisitos. Soluções, projetos e implementações envolvendo produtos, componentes e processos de ciclos de vida.

• Envolve:– Avaliar e selecionar soluções que satisfação de forma apropriada o

conjunto de requisitos funcionais e de qualidade;– Desenvolver projetos detalhados para selecionar as soluções;– Implementar os projetos.


• Integração do Produto(PI): A integração do produto é a montagem do produto a partir dos seus componentes, garantindo que o produto seja integrado e que se comporte de forma apropriada( de acordo com os requisitos funcionais e de qualidade) além de entregar o produto.

• Envolve:– Gerenciamento das interfaces internas e externas dos produtos e seus

componentes para assegurar a compatibilidade entre elas;– A integração pode ser realizada de forma incremental usando processos

iterativos;


• Verificação (VER): O objetivo do VER é assegurar que os produtos gerados estão de acordo com os requerimentos especificados.

• Envolve: – Identificação dos produtos de trabalho que devem ser verificados, dos métodos

para executar a verificação e dos requerimentos a serem satisfeitos;– Estabelecer um ambiente de verificação;– Estabelecer os procedimentos e critérios de verificação;– Executar a verificação de acordo com os procedimentos e critérios pré-

estabelecidos.


• Validação (VAL): O objetivo do VAL é demonstrar que o produto ou componentes atingirão seu objetivo de uso no seu ambiente definitivo.

• Envolve:– Identificar os produtos e componentes a serem validados e a metodologia a ser

utilizada;– Criar um ambiente de validação, semelhante ao ambiente de produção;– Estabelecer procedimentos e critérios para a validação;– Executar a validação de acordo com os procedimentos e critérios estabelecidos.


• Foco no Processo Organizacional (OPF): O objetivo do OPF é planejar e, implementar e disponibilizar melhorias em processos organizacionais, baseado mas forças e fraquezas dos processos organizacionais.

• Envolve:– Processos de analise, lições aprendidas, resultados de avaliações, resultados de

pesquisas de satisfação dos clientes, recomendações e benchmarks com outras organizações;

– Normalmente se criar grupos de processos com a participação daqueles que executam os processos;

– Planejamento e criação do Plano de melhoria dos processos da organização.


• Treinamento Organizacional (OT): O objetivo do OT é desenvolver habilidades e conhecimentos para que as pessoas executem suas funções de forma eficaz e eficiente.

• Envolve:– Identificar o treinamento necessário para a organização;– Obter e providenciar os treinamentos de acordo com essas necessidades;– Estabelecer e manter a capacidade de fornecer treinamentos;– Estabelecer e manter registro dos treinamentos;– Determinar a efetividade dos treinamentos.


• Definição do Processo Organizacional (OPD): O objetivo do OPD é estabelecer e manter um conjunto utilizável de processos, padrões de trabalho, papéis e guias para grupos.

• Envolve:– Manter uma biblioteca de padrões de processos;


• Análise de Decisão e Resolução (DAR): O propósito do processoAnálise de Decisão e Resolução é analisar possíveis decisõesusando um processo formal da avaliação das alternativasidentificadas em relação. a critérios estabelecidos;

• Envolve:• Estabelecer critérios para avaliar alternativas;• Identificar soluções alternativas;• Selecionar métodos para avaliar as alternativas;• Avaliar as soluções alternativas usando os métodos e critérios estabelecidos;• Selecionar soluções recomendadas para as alternativas baseadas nos critérios

estabelecidos.

Áreas de Processo Níveis 4

Representação por Estágio: PAs do Níveis 4 e 5

• Nível 4:– Gerenciamento de Projetos

• Gerência Quantitativa do Projeto(QPM) – Quantitative Project Management.

– Gerenciamento de processos• Desempenho do Processo Organizacional (OPP) – Organizational Process

Performance.

• Nível 5:– Suporte:

• Análise de Causas e Resolução (CAR) – Causal Analysis and Resolution.

– Gerenciamento de Processos• Gerenciamento do Processo Organizacional (OPM) – Organizational

Performance Management.


• Gerência Quantitativa do Projeto(QPM): Gerenciar quantitativamente o processo definido para o projeto alcançar metas estabelecidas de qualidade e desempenho;

• Envolve: • Estabelecer e manter a qualidade dos projetos e os objetivos dos processos;• Compor e definir processos para ajudar para atingir a qualidade do projeto e os

objetivos dos processos;• Selecionar sub-processos e atributos críticos para entender o desempenho dos

processos e para ajudar para atingir a qualidade do projeto e os objetivos dos processos;

• Selecionar métricas e técnicas de análise para ser utilizado de forma quantitativa nos projetos;

• Monitorar o desempenho dos sub-processos usando as métricas definidas;• Gerenciar o projeto usando ferramentas estatísticas;• Executar a analise de causa raiz pata endereçar as deficiências;


• Desempenho do Processo Organizacional(OPP): O objetivo do OPP é estabelecer e manter um entendimento quantitativo do desempenho de processos selecionados e suportar o alcance dos objetivos de qualidade e desempenho dos processos. Além de fornecer dados, linhas de base e modelos para gerenciar de forma quantitativa os projetos da organização.

• Envolve:• Estabelecer de forma quantitativa objetivos de desempenho, qualidade dos

processos baseado nos objetivos organizacionais;• Selecionar processos ou subprocessos para realizar a analise de desempenho;• Estabelecer definições de métricas a serem usadas nos processos para serem

usados nas analise de desempenho;• Estabelecer linhas de base de desempenho para processos e modelos de

desempenho.


• Análise de Causas e Resolução (CAR): O objetivo do CAR é identificar causas de resultados selecionados e tomar ações para melhorar o desempenho.

• Envolve:– Identificar e analisar causas de resultados selecionados. Esses resultados

podem representar defeitos e problemas que podem ser previstos em desenvolvimentos futuros.

– Tomar ações para:• Remover as causas e prevenir a recorrência desses problemas;• Analisar de forma proativa para identificar potenciais problemas e prevenir sua ocorrência;• Incorporar as causas de sucesso nos processo para melhorar o desempenho.


• Gerenciamento do Processo Organizacional(OPM): O objetivo do OPM é gerenciar de forma proativa o desempenho da organização para atingir os objetivos organizacionais.

• Envolve:• Melhorar a qualidade do produtos;• Melhorar a produtividade;• Melhorar a eficiência e eficácia dos processos;• Melhorar a consistência em atingir prazos e orçamentos;• Reduzir o tempo de ciclo de desenvolvimento;• Aumentar a satisfação do cliente;• Reduzir o tempo de desenvolvimento para mudanças de funcionalidades, novas

funções e adaptação à novas tecnologias;• Melhorar o desempenho dos fornecedores;• Melhorar o uso dos recursos na organização.

Projeto SPICE e ISO/IEC 15504

• Norma ISO/IEC 15504 (desenvolvida pela ISO e pelo IEC, com o apoio do projeto SPICE -Software Process Improvement and CapabilitydEtermination);

• Padrão Internacional para Avaliação de Processos de Software;

• Tem como modelo de referência de Processo a Norma ISO/IEC 12207.

Objetivos

• Determinar a capacidade dos processos de uma empresa;

• Orientar a empresa para uma melhoria contínua de seus processos.

Benefícios

• Para Indústria de Software– Fornecedores de software submetem-se a apenas

um esquema de avaliação de software;– Organizações de desenvolvimento de software têm

uma ferramenta para iniciar e manter um processo contínuo de melhoria;

• Para os Compradores de Software– Permite determinar a capacidade dos fornecedores

de software e avaliar os riscos na seleção de um fornecedor sobre outro.

Histórico

• Em 1993, a ISO (International Organization for Standardization) realizou um estudo sobre as necessidadese requisitos de um padrão internacional para avaliação de processos de software .

• Conclusões:– Consenso sobre a necessidade de um padrão internacional para

avaliação de processos de software;– Os resultados deveriam ser utilizados o mais breve possível,

garantindo que o padrão atendesse completamente a seus requisitos.

• Criado o projeto SPICE (Software Process Improvement andCapability dEtermination): equipe responsável pelo desenvolvimento das versões iniciais da norma e por coordenar a utilização destas na comunidade.

Histórico• 1993: estudo da ISO sobre as necessidades e os requisitos

de um padrão internacional para avaliação de processos de Software;

• 1993-1994: criação do projeto SPICE e elaboração da versão inicial; Realização de trials - Fase 1 (35 avaliações);

• 1996: Versão PDTR (Previous Draft Technical Report);• 1997: Versão DTR (Draft Technical Report), Trials - Fase 2

(70 avaliações);• 1998: Versão TR (Technical Report), denominada de ISO/IEC

TR 15504: Information Technology - Software Process Assessment;

• 1999-2005: Transformação em Norma ISO/IEC 15504;• 2003: Inicia a publicação como Norma ISO/IEC 15504,

denominada de ISO/IEC 15504: Information Technology -Process Assessment.– ISO – International Organization for Standardization– IEC - International Electrotechnical Commission

Visão Geral da Norma ISO/IEC 15504– Framework:

• Define requisitos para Avaliação de Processo;• Na prática, é utilizado com Modelo de Referência para Melhoria de

Processo;

– Avaliação em 2 Contextos:• Melhoria Contínua

– Entender o estado dos processos;– Avaliação identifica oportunidades de melhoria;– Foca na melhoria de processo;

• Determinação da Capacidade– Determinar a adequação dos processos;– Geralmente realizada para uma organização interessada em contratar a

organização avaliada como fornecedor.

Utilização da 15504

Processo

Avaliação do Processo

Melhoria doProcesso

Identificaaplicabilidade

Leva a

Identificamudanças no

Leva a

É sujeito a

Pode levar a Determinaçãoda Capacitação

Modelo de Referência

• Um Modelo de Referência de Processo define basicamente um conjunto de processos que representam melhores práticas de um determinado domínio.

• Um exemplo de um modelo de referência de processo é a nova versão da Norma ISO/IEC 12207.

Modelo para Avaliação de Processo

• Um Modelo para Avaliação de Processo deve ser:– baseado em um Modelo de Referência de Processo,

e – detalhar os processos (todos ou alguns) de forma a

viabilizar uma avaliação de processo e também detalhar a estrutura de medição.

Exemplos: CMMI, ISO 15504-5, MPS-BR ...

Método de Avaliação de Processos

• Um método de avaliação de processo para ser conforme com a 15504, tem que satisfazer três requisitos básicos:– ser verificada por um avaliador competente;– ter como referência um modelo de avaliação de

processo compatível (ex. 15504-5);– ser realizada seguindo um processo compatível.

15504-5Software

MR-MPS

FAAiCMM

CMMISE/SW

OOSPICE

SCAMPI MA-MPS

modelos paraavaliação

de processo

...

RAPID

AutomotiveSPICE

MARES

métodos deavaliação

de processo

ISO/IEC 15504-2níveis de capacidade e requisitos para:

QuickLocus ...

SPICE4Space

15504MPE

Composição da Norma• 15504-1: Conceitos e Vocabulário (Concepts and Vocabulary) -

Publicação 2004;• 15504-2: Executando uma Avaliação (Performing an Assessment) -

Publicação 2003, apresenta os Requisitos para uma avaliação compatível com a 15504;

• 15504-3: Guia sobre Executando uma Avaliação (Guidance onperforming an assessment) - Publicação 2004, apresenta um Exemplo de um processo de avaliação;

• 15504-4: Guia sobre Utilização do Resultado de Avaliação(Guidance on using assessment results) - Publicação 2004, apresenta um Guia para orientação na melhoria de processos;

• 15504-5: Um Exemplo de Modelo de Avaliação de Processo (Anexemplar process assessment model) - Publicação 2005, apresenta um Modelo de capacidade para a Engenharia de Software com base nos processos da ISO 12207.

Modelo de Processo da ISO 15504

• A arquitetura dos modelos é denominada de arquitetura contínua, com duas dimensões:– dimensão de processo – dimensão de capacidade de processo.

• A 15504-5 define um exemplo de um modelo compatível com a 15504: � denominado de ISO/IEC 15504-5, e � representa um conjunto de melhores práticas para a

engenharia de software.

nível de capacidade de processos

pa pb ... pn

processos

Modelo de Processo da ISO 15504

• A 15504-5 organiza estas em duas grandes categorias:– aquelas relacionadas a “o que fazer”,

organizadas em processos específicos;

(“dimensão de processos”)

(“dimensão de capacidade”)

� aquelas relacionadas ao “quão bem fazer qualquer coisa que seja feita”, organizadas em níveis de capacidade genéricos.

Fundamentais Organizacionais

Apoio

15504-5:Dimensão de Processos• 48 processos que estão organizados em 3 categorias de

processo e 10 grupos de processo.

• Aquisição

• Fornecimento

• Engenharia

• Operação

• Gerência• Melhoria de Processo • Recursos e Infraestrutura• Reuso

• Controle de Configuração• Garantia da Qualidade

15504-5:Dimensão de Processos

15504-5:Dimensão de Processos

• Cada processo é descrito com os seguintes seis elementos: – Identificação (process identifier);– Nome (process name);– Propósito (process purpose);– Resultados (Outcomes);– Práticas base (base practice): – Produtos de trabalho (work-products).

• Resultados (Outcomes): – Descreve os resultados esperados de uma implementação

com sucesso deste processo.• Práticas base (base practice):

– Atividade que quando executada de forma consistente, contribui para o atendimento do propósito de um processo.

– Para cada prática base estão relacionados os resultados (outcomes) que a prática ajuda a alcançar.

• Produtos de trabalho (work-products):– Os produtos de trabalho de um processo são aqueles

esperados de serem utilizados e/ou produzidos pela execução do processo.

– A lista de produtos de trabalho para cada processo deve ser utilizada como orientação para avaliação ou melhoria do processo.

Elementos

• Identificação: ACQ.1• Nome: Prepara para aquisição (Acquisition preparation )• Propósito: estabelecer as necessidades e objetivos da aquisição e comunicá-los aos potenciais

fornecedores.• Resultados:

– R1 - o conceito ou a necessidade de aquisição, desenvolvimento ou melhoria é estabelecido;– R2 - os requisitos de aquisição necessários, definindo as necessidades do projeto, são definidos e

validados;– R3 - os requisitos conhecidos do cliente são definidos e validados;– R4 - uma estratégia de aquisição é desenvolvida; e– R5 - os critérios de seleção do fornecedor são definidos.

• Práticas Base:– ACQ.1.BP1: Establish the need. Establish a need to acquire, develop, or enhance a system, software

product or service. [Outcome: 1]– ACQ.1.BP2: Define the requirements. Identify the customer/stakeholder requirements for a system and/or

software product or service. [Outcomes: 2, 3]– ACQ.1.BP3: Review requirements. Analyze and validate the defined requirements against the identified

needs. Validate the requirements to reduce risk of misunderstanding by the potential suppliers. [Outcome: 3]– ACQ.1.BP4: Develop acquisition strategy. Develop a strategy for the acquisition of the product according to

the acquisition needs. [Outcome: 4]– Note 1: The strategy may include reference to the life cycle model, schedule and selection criteria. – ACQ.1 ....

Exemplo: Processo de Aquisição - The Acquisition Process Group (ACQ)

Dimensão da Capacidade de Processo

• Em uma organização vários processos podem ter níveis de capacidade variáveis

• A 15504 define 6 níveis de capacidade – Seqüenciais e cumulativos

• Os níveis podem ser usados:– para avaliar como uma organização está realizando um

determinado processo – Como guia para a melhoria

• Cada nível de capacidade é descrito basicamente por um nome, definição e atributos.

15504 - Níveis de CapacidadeNíveis de Capacidade:

Métrica para avaliação e

roteiro para melhoria, ...

Processoexecutadodentro delim ites decontroledefinidos ecom mediçõesdetalhadas eanalisadas

Processoplanejado eacompanhando,e satisfazrequisitosdefinidos de:� qualidade,� prazo,� e custos, eseus produtosde trabalho sãogerenciados

Processoexecutadoe gerenciadocom umaadaptação deum processopadrãodefinido, eficaze eficiente

Processoatinge osobjetivos,porem sempadrão dequalidadee sem controlede prazos ecustos

5

Otimizando

4

Previsível

3

Estabelecido

2

Gerenciado

1

Executado

0

Incompleto

Processo nãoexiste ougeralmente falha

Processomelhoradocontinuamentede formadisciplinada

... baseados na

capacidade

do processo

Níveis de Capacidade e Atributos de Processo

Nível 0: Processo Incompleto(não tem atributos)

Nível 1: Processo ExecutadoPA 1.1: Atributo de Execução de Processo

Nível 2: Processo GerenciadoPA 2.1: Atributo da Gerência de Execução PA 2.2: Atributo de Gerência de Produto de Trabalho

Nível 3: Processo EstabelecidoPA 3.1: Atributo de Definição de Processo PA 3.2: Atributo de Implementação de Processo

Nível 4: Processo PrevisívelPA 4.1: Atributo de Medição de Processo PA 4.2: Atributo de Controle de Processo

Nível 5: Processo em OtimizaçãoPA 5.1: Atributo de Inovação de ProcessoPA 5.2: Atributo de Otimização do Processo

• Existe uma falha geral na satisfação do propósito do processo

• Existem poucos (ou difíceis de serem identificados) produtos de trabalho ou resultados de processos

Nível 0 - Incompleto

• O propósito do processo é geralmente alcançado – talvez de uma forma não planejada e acompanhada

• As pessoas da organização reconhecem que uma ação deve ser executada e quando isto deve ser feito

• Existem produtos de trabalho para o processo e eles evidenciam a satisfação do propósito do processo

Nível 1 - Executado

• O processo produz produtos de trabalho de acordo com procedimentos específicos– Processo planejado e acompanhado

• Os produtos de trabalho estão conforme os padrões e requisitos especificados

• A execução do processo passa a construir produtos de trabalho que satisfazem os requisitos de qualidade especificados, dentro do cronograma de tempo e dos recursos necessários

Nível 2 - Gerenciado

• O processo é executado e gerenciado utilizando um processo definido

• A implantação de um processo usa uma versão customizada e aprovada de um processo padrão

• O processo utiliza um processo padrão que é capaz de atingir seus resultados definidos

Nível 3 - Estabelecido

• O processo definido é executado consistentemente na prática, dentro de limites de controle definidos

• Medições detalhadas de desempenho são coletadas e analisadas

• A qualidade dos produtos é conhecida de forma quantitativa

• O processo passa a ser executado consistentemente dentro de limites definidos para atingir seus resultados

Nível 4 - Previsível

• O desempenho do processo é continuamente melhorado

• O processo consegue repetibilidade em atingir suas metas de negócio definidas

• Otimização contínua do processo envolve experiências de ideias e tecnologias inovadoras

Nível 5 - Otimizando

Avaliação de Processo com a ISO 15504

• A 15504-2 define os requisitos para uma avaliação compatível com a 15504.

• E incluindo os principais elementos de um processo de avaliação de processo.

Elementos de um processo de avaliação de processo:

Modelo de Referência deProcesso (compatível)• Processos• Objetivos e Resultados

Framework de Medição• Níveis de Capacidade• Atributos de Processo• Escala de Medição

Modelo de Avaliação de Processo (compatível)

Escopo•

PROCESSO DE AVALIAÇÃOPlanejamento

Coleta de dadosValidação dos dados

Pontuação dos atributos de processoRepresentação dos resultados

Papéis e responsabilidades. Patrocinador. Avaliador Competente. Avaliadores

ENTRADA. Identificação do patrocinador. Objetivo e escopo. Restrições. Equipe de avaliação

SAIDA. Identificação das evidências. Processo utilizado. Perfil dos processos avaliados

Indicadores•Mapeamento•Tradução•

Pontuação de Atributo de Processo

• Um valor tem que ser atribuído a cada atributo de processo, baseado nos dados validados.

• composta pelos seguintes quatro valores:– “N”: o atributo não foi atingido pelo processo;– “P”: o atributo foi atingindo apenas parcialmente pelo

processo;– “L”: o atributo foi atingido largamente pelo processo; e – “F”: o atributo foi atingido completamente (em inglês, fully)

pelo processo.

Para estar em um nível de capacidade, um processo tem que ter notas “L” ou “F” nos atributos do nível e “F” em todos os atributos dos níveis anteriores.

Exemplos de Pontuação de Atributos de Processo

F L F P P P N -- --Proc.1:

F F L F F P P N NProc.2:

P P N N N -- -- -- --Proc.3:

F F F F L P P N NProc.4:

..... 2 .....

..... 2 .....

..... 0 .....

..... 3 .....

Nível 1 2 3 4 5Atributo 1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2

Pontuação dos atributos Nível decapacidade

do processo

F P L P N -- -- -- --Proc.5:

F F F F F F L P PProc.6:

..... 1 .....

..... 4 .....

Melhoria de Processo (ISO 15504)

• A ISO/IEC 15504-4 descreve um guia para orientação da melhoria de processo, tendo como referência um modelo de processo e como uma das etapas a realização de uma avaliação de processo

1 - Examinar necessidades da

organização

2 - Inicia processo de

melhoria 3 - Avalia Processo

4 - Planeja Melhoria

5 -Implementa melhoria

6 - Confirmar melhoria

7 - Mantem melhoria

8 - Monitorar desempenho

Melhoria de Processo ISSO/IEC 15504-4

Considerações Finais• Não pressupõe modelos de ciclo de vida de

software, tecnologias de software ou metodologias de desenvolvimento.

• O ISO/IEC 15504 não define um método explícito de avaliação, define os requisitos para o Método de Avaliação de Processos.

• Na prática, uma avaliação de processos de software é conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos.

Exercícios

• Faça uma comparação entre o CMMI e o SPICE.

– Enviar para: [email protected]

MPS.BRMelhoria do Processo de Software

Motivação• Em 2003, dados da Secretaria de Política de Informática do MCT

apontavam que apenas 30 empresas no Brasil possuíam avaliação CMM e 214 possuíam certificação ISO 9001.

• Claramente, as empresas locais favoreceram a ISO 9000.• Dados de uma pesquisa do MIT 1, apontavam que até 2003, na

Índia 32 empresas atingiram o nível 5 do CMM, enquanto a China tinha apenas uma e o Brasil nenhuma.

• Em relação ao CMM, a maioria das empresas chinesas e brasileiras não estava em um nível suficientemente alto de maturidade do processo para competir com as empresas indianas.

1 Ref: Slicing the Knowledge-based Economy in Brazil, China and India: a tale of 3 software industries [MIT, 2003]

Como atingir níveis de maturidade CMMI no Brasil?

• As empresas exportadoras de software e outras grandes empresas que desejam atingir níveis mais altos de maturidade (CMMI níveis 4 e 5) e serem formalmente certificadas pelo SEI, em um processo de longo prazo. – O fator custo não é crítico.– O processo como um todo pode levar de 4 a 10 anos e custar centenas de

milhares de dólares.

• A grande massa de micro, pequenas e médias empresas (PMEs) que desenvolvem software no Brasil e que necessitam melhorar radicalmente os seus processos de software, em conformidade com normas internacionais (como ISO/IEC 12207 e 15504) e em compatibilidade com outros modelos (como CMMI níveis 2 e 3). – O fator custo é crítico.– Esse processo pode levar de 2 a 4 anos e custar dezenas de milhares de dólares.

MPS.BR

Realidade das Empresas Brasileiras

ISO /IEC 12207

ISO /IEC 15504

CMMI

SOFTEX

Governo

Universidades

Base Técnica

MPS.BR: Desenvolvimento e Aprimoramento

Histórico• Dezembro de 2003: Início do programa mobilizador para

a Melhoria do Processo de Software Brasileiro, coordenado pela Softex (Associação para Promoção da Excelência do Software Brasileiro), com apoio do Ministério da Ciência e Tecnologia (MCT) e do Banco Interamericano de Desenvolvimento (BID).

• Abril de 2005: Versão 1.0• Maio de 2006: Versão 1.1• Junho de 2007: Versão 1.2• Junho 2009: MR-MPS:2009.

MPS.BR - Objetivos

• Visa a melhoria de processos de software em empresas brasileiras, a um custo acessível, especialmente na grande massa de micro, pequenas e médias empresas.

MPS.BR - Objetivos

• Define e aprimora um modelo de melhoria e avaliação de processo de software, visando preferencialmente as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software.

MPS.BR - Objetivos

• MPS.BR também estabelece um processo e um método de avaliação, o qual dá sustentação e garante que o MPS.BR está sendo empregado de forma coerente com as suas definições.

MPS.BR - Propósito• O propósito do Programa MPS.BR é a Melhoria de

Processo do Software Brasileiro, compreendendo 2 processos:– Desenvolvimento e aprimoramento do Modelo MPS

• Baseado nas melhores práticas da Engenharia de Software• Em conformidade com as normas ISO/IEC 12207 E ISO/IEC

15504• Compatível com o modelo CMMI, do SEI/CMU• Adequado à realidade das empresas brasileiras

– Disseminação e adoção do Modelo MPS, a um custo razoável, em todas as regiões do país

• Tanto em pequenas e médias empresas (PME)• Como em grandes organizações públicas e privadas

Base Técnica do MPS.BR

MPS.BR

CMMI

Complementação de Processos

ISO/IEC 12207

Definição de Processos

Propósitos e Resultados

ISO/IEC 15504

Definição da Capacidade de Processos

Requisitos de Avaliação

Estrutura do Modelo MPS.BR

ProgramaMPS.BR

Modelo de Negócio

(MN-MPS)

Método de Avaliação (MA-MPS)

Guia de Aquisição Guia Geral

Modelo de Referência (MR-MPS)

Guia de Avaliação Documento do Programa

ISO/IEC 12207

Guias de Implementação

ISO/IEC 15504CMMI-DEV

MPS.BR: Guia Geral

• Descreve o Modelo de Referência para Melhoria do Processo de Software (MR-MPS) e fornece uma visão geral sobre os demais guias que apoiam os processos de avaliação e de aquisição.

• Público-alvo: – Instituições interessadas em aplicar o MR-MPS para melhoria

de seus processos de software.– Instituições Implementadoras (IIs) e avaliadoras (IAs) segundo o

MR-MPS– outros interessados em processos de software e que pretendam

conhecer e utilizar o MR-MPS como referência técnica.

Estrutura do MPS.BR

Níveis de maturidade

Processo Capacidade

PropósitoAtributo de Processo

AP

Resultados Resultados

Práticas

Atributo de Processo é uma

característica mensurável da capacidade do

processo aplicável a qualquer processo

[ISO/IEC 15504-1, 2003] RAP – Resultado do

Atributo do Processo

Cada AP está detalhado em termos dos resultados

para alcance completo do

atributo (RAP)

MPS.BR: Guia Geral

Níveis de Maturidade

• O MR-MPS define sete níveis de maturidade:– A. Em Otimização– B. Gerenciado Quantitativamente– C. Definido– D. Largamente Definido– E. Parcialmente Definido– F. Gerenciado– G. Parcialmente Gerenciado

Níveis de maturidade MR-MPS

Equivalência com CMMI

Nível MPS.BR Nível CMMI

G

2F

E

3D

C

B 4

A 5

Nível G – Parcialmente Gerenciado

Nível Processos Capacidade

G

Gerência de Projetos

Resultados: GPR 1 a GPR 17

GPR 4, 10 e 13 (até o Nível F)

AP 1.1 e AP 2.1

Resultados:

RAP 1 a RAP 8

sendo RAP 4 (G)

Gerência de Requisitos

Resultados: GRE 1 a GRE 5

Nível G: Gerência de Projetos

• Propósito: estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto.

• O propósito deste processo evolui à medida que a organização cresce em maturidade (nos níveis E eB).


• Resultados Esperados (GPR 1 a GPR 8):1. O escopo do trabalho para o projeto é definido.2. As tarefas e os produtos de trabalho do projeto são dimensionados

utilizando métodos apropriados.3. O modelo e as fases do ciclo de vida do projeto são definidas. 4. O esforço e o custo para a execução das tarefas e dos produtos de

trabalho são estimados com base em dados históricos ou referências técnicas.

5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.

6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados.

7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo.

8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.


• Resultados Esperados (GPR 9 a GPR 15): 9. Os dados relevantes do projeto são identificados e planejados quanto à

forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança.

10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.

11. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados.

12. O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido.

13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados.

14. O envolvimento das partes interessadas no projeto é gerenciado.15. Revisões são realizadas em marcos do projeto e conforme estabelecido no

planejamento.


• Resultados Esperados (GPR 16 e GPR 17):16. Registros de problemas identificados e o resultado da análise de questões

pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas.

17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão.

Nível G: Gerência de Requisitos

• Propósito: Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.

Nível G: Gerência de Requisitos• Resultados Esperados (GRE 1 a GRE 5):

1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;;.

2. Os requisitos de software são aprovados utilizando critérios objetivos;

3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;;

4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.

5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

Nível F: Processo e Propósitos• Aquisição: gerenciar a aquisição de produtos e/ou serviços que

satisfaçam a necessidade expressa pelo adquirente.• Gerência de Configuração: estabelecer e manter a integridade de

todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.

• Garantia da Qualidade: assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos e recursos predefinidos.

• Medição: coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.

Nível D: Processo e Propósitos• Desenvolvimento de Requisitos: estabelecer os requisitos dos

componentes do produto, do produto e do cliente.• Projeto e Construção do Produto: projetar, desenvolver e

implementar soluções para atender aos requisitos.• Integração do Produto: compor os componentes do produto,

produzindo um produto integrado consistente com o projeto, e demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o ambiente alvo ou equivalente.

• Verificação: confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente aos requisitos especificados.

• Validação: confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.

Nível C: Processo e Propósitos• Análise de Decisão e Resolução: analisar possíveis decisões

usando um processo formal, com critérios estabelecidos, para avaliação das alternativas identificadas.

• Desenvolvimento para Reutilização: identificar oportunidades de reutilização sistemática na organização e, se possível, estabelecer um programa de reutilização para desenvolver ativos a partir de engenharia de domínios de aplicação.

• Gerência de Riscos: identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.

Níveis A e B: Processo e Propósitos

• Nível B: não possui processos específicos.• Nível A:

– Análise de Causas de Problemas e Resolução: identificar causas de defeitos e de outros problemas e tomar ações para prevenir suas ocorrências no futuro.

Atributos de Processos

• AP 1.1 - O processo é executado;• AP 2.1 - O processo é gerenciado;• AP 2.2 - Os produtos de trabalho do processo são

gerenciados;• AP 3.1 - O processo é definido;• AP 3.2 - O processo está implementado;• AP 4.1 - O processo é medido;• AP 4.2 - O processo é controlado;• AP 5.1 - O processo é objeto de inovações;• AP 5.2 - O processo é otimizado continuamente.

Atributo de Processo – AP 1.1

• O processo é executado– Medida do quanto o processo atinge seu

propósito.

• Resultado esperado:– RAP 1. O processo atinge seus

resultados definidos.

Atributo de Processo – AP 2.1• O processo é gerenciado

– Medida do quanto a execução do processo é gerenciada.

• Resultados esperados:– RAP 2. Existe uma política organizacional

estabelecida e mantida para o processo;– RAP 3. A execução do processo é planejada;– RAP 4 (Para o Nível G). A execução do processo é

monitorada e ajustes são realizados;– RAP 5. (Até o Nível F) As informações e os

recursos necessários para a execução do processo são identificados e disponibilizados;

– RAP 6. (Até o Nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas.


• Resultados esperados:– RAP 7. (Até o Nível F) As pessoas que executam o

processo são competentes em termos de formação, treinamento e experiência;

– RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento;

– RAP 9. (Até o Nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização.

– RAP 10 (Para o Nível G). O processo planejado para o projeto é executado.

Atributo de Processo 2.2• Os produtos de trabalho do processo são gerenciados;

– É uma medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente.

• Resultados esperados: – RAP 11. Os requisitos dos produtos de trabalho do processo são

identificados; – RAP 12. Requisitos para documentação e controle dos produtos de

trabalho são estabelecidos; – RAP13. Os produtos de trabalho são colocados em níveis apropriados

de controle; – RAP 14. Os produtos de trabalho são avaliados objetivamente com

relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades.

Atributo de Processo – AP 3.1• O processo é definido:

– É uma medida do quanto um processo padrão é mantido para apoiar a implementação do processo definido;

• Resultados esperados: – RAP 15. Um processo padrão é descrito, incluindo diretrizes

para sua adaptação para o processo definido para um projeto;– RAP 16. A sequência e interação do processo padrão com

outros processos são determinadas; – RAP 17. Os papéis e competências requeridos para executar o

processo são identificados como parte do processo padrão;– RAP 18. A infraestrutura e o ambiente de trabalho requeridos

para executar o processo são identificados como parte do processo padrão.

Atributo de Processo – AP 3.2• Processo está implementado:

– É uma medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados.

• Resultados esperados: • RAP 19. Um processo definido é implementado para o projeto baseado nas

diretrizes para seleção e/ou adaptação do processo padrão; • RAP 20. A infraestrutura e o ambiente de trabalho requeridos para executar

o processo definido são disponibilizados, gerenciados e mantidos;• RAP 21. Dados apropriados são coletados e analisados, constituindo uma

base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo;

• RAP 22. Produtos de trabalho e lições aprendidas são coletados e armazenados na biblioteca de ativos de processo, para uso futuro e apoio à melhoria contínua do processo.

Atributo de Processo – AP 4.1• O processo é medido:

– É uma medida do quanto os resultados de medição são usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e apoia o alcance dos objetivos de negócio definidos.

• Resultados esperados: – RAP 23. As necessidades de informação dos processos, requeridas

para apoiar objetivos de negócio relevantes da organização, são identificadas;

– RAP 24. A partir do conjunto de processos padrão da organização e das necessidades de informação, são selecionados os processos e/ou subprocessos que serão objeto de análise de desempenho;

– RAP 25. Objetivos de medição do processo e/ou subprocesso são derivados das necessidades de informação do processo;

– RAP 26. Objetivos quantitativos de qualidade e de desempenho.

Atributo de Processo – AP 4.1• RAP 27. Medidas, bem como a frequência de realização

de suas medições, são identificadas e definidas de acordo com os objetivos de medição do processo/subprocesso e os objetivos quantitativos de qualidade e de desempenho do processo;

• RAP 28. Resultados das medições são coletados, analisados e comunicados para monitorar o atendimento dos objetivos quantitativos de qualidade e de desempenho do processo/subprocesso;

• RAP 29. Resultados de medição são utilizados para caracterizar o desempenho do processo/subprocesso.

Atributo de Processo – AP 4.2• O processo é controlado

– é uma medida do quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos.

• Resultados esperados: – RAP 30. Técnicas de análise e de controle de desempenho são

identificadas e aplicadas quando necessário; – RAP 31. Limites de controle de variação são estabelecidos para o

desempenho normal do processo; – RAP 32. Dados de medição são analisados com relação a causas

especiais de variação; – RAP 33. Ações corretivas são realizadas para tratar causas especiais

de variação; – RAP 34. Limites de controle são redefinidos, quando necessário,

seguindo as ações corretivas; – RAP 35. Modelos de desempenho do processo são estabelecidos e

mantidos.


• O processo é objeto de melhorias e inovações:– é uma medida do quanto as mudanças no processo são

identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo.

• Resultados Esperados– RAP 36. Propostas de melhoria são coletadas e analisadas para

estabelecer os objetivos de melhoria do processo, que são definidos de forma a apoiar os objetivos de negócio relevantes;

– RAP 37. Defeitos e outros problemas são identificados, classificados e selecionados para análise;


• RAP 38. Defeitos e outros problemas selecionados são analisados para identificar sua causa raiz e soluções aceitáveis para evitar sua ocorrência futura;

• RAP 39. Dados adequados são analisados para identificar causas comuns de variação no desempenho do processo;

• RAP 40. Dados adequados são analisados para identificar oportunidades para aplicar melhores práticas e inovações;

• RAP 41. Oportunidades de melhoria derivadas de novas tecnologias e conceitos de processo são identificadas;

• RAP 42. Uma estratégia de implementação é estabelecida e executada para alcançar os objetivos de melhoria do processo e para resolver problemas.

Atributo de Processo – AP 5.2• O processo é otimizado continuamente:

– é uma medida do quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo.

• Resultados esperados: – RAP 43. O impacto de todas as mudanças propostas é avaliado com

relação aos objetivos do processo definido e do processo padrão; – RAP 44. A implementação de todas as mudanças acordadas é

gerenciada para assegurar que qualquer alteração no desempenho do processo seja entendida e que sejam tomadas as ações pertinentes;

– RAP 45. As ações implementadas para resolução de problemas e melhoria no processo são acompanhadas com medições para verificar se as mudanças no processo corrigiram o problema e melhoraram o seu desempenho;

– RAP 46. Dados da análise de causas de problemas e de sua resolução são armazenados para uso em situações similares.

Referências• Melhoria e Avaliação de Processo com ISO/IEC 15504-

5:2006, Clênio Figueiredo Salviano. – Lavras: UFLA, 2006.

• http://www.sqi.gu.edu.au/spice/• The International Organization for Standardization and

the International Electrotechnical Commission, ISO/IEC 15504 - Information Technology - Process Assessment

• Softex, MPS.BR - Melhoria de Processo do Software Brasileiro – Guia Geral, Versão 1.2, Junho 2009.

Contatos

• Daniel Oliveira– [email protected]

–OBRIGADO!

qualidade de software - danielbarbosa77.files.wordpress.com · qualidade de software • empresas...

Documents