1 qualidade de software mps-br prof. guilherme alexandre monteiro reinaldo recife

1

Qualidade de Software

MPS-BR

Prof. Guilherme Alexandre Monteiro Reinaldo

Recife

Contatos Prof. Guilherme Alexandre Monteiro Reinaldo Apelido: Alexandre Cordel E-mail/gtalk: alexandrecordel@gmail.com

greinaldo@fbv.edu.br Site: http://www.alexandrecordel.com.br/fbv Celular: (81) 9801-1878

Qualidade em software via MPS.BR / Gerenciamento de Projetos

Qualidade em software via MPS.BR / Gerenciamento de Projetos

Qualidade do produto de software

Qualidade do processo dedesenvolvimento de software

Modelo de maturidade(MPS.BR)

Gerenciamento deprojetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base

Qualidade em software via MPS.BR / Gerenciamento de Projetos

Qualidade do produto de software

Qualidade do processo dedesenvolvimento de software

Modelo de maturidade(MPS.BR)

Gerenciamento deprojetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base

[

Qualidade do produto x Qualidade do processo Porque processo é importante?

O bom e velho triângulo mágico...

Qualidade do produto x Qualidade do processo Porque processo é importante?

Mesmo as melhores pessoas não conseguem trabalhar de forma eficiente se o processo é problemático ou mal compreendido.

O processo é a ponta do triângulo que unifica os outros aspectos

Qualidade do produto x Qualidade do processo Porque processo é importante?

Investimentos em tecnologia sem um guia que defina como utilizá-la é um desperdício de recursos.

Sem processos claros e eficientes, uma empresa não é escalável.

Qualidade em software via MPS.BR / Gerenciamento de Projetos

Qualidade do produto de software

Qualidade do processo dedesenvolvimento de software

Modelo de maturidade(MPS.BR)

Gerenciamento deprojetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base

[

Qualidade do processo x Modelos de maturidade Porque usar modelos como referência?

Modelos definem os requisitos a que os processos devem atender, apresentando flexibilidade em relação a como antendê-los.

Modelos, especialmente os estruturados “por estágio”, definem um caminho evolucionário para melhoria de processo.

Qualidade do processo x Modelos de maturidade Porque usar modelos como referência?

Modelos são repositórios de melhores práticas que vêm sendo utilizadas ao longo de vários anos com sucesso.

Modelos permitem avaliações dos processos de forma objetiva e a detecção de pontos fortes e fracos

Qualidade do processo x Modelos de maturidade Porque usar modelos como referência?

Mas atenção: Não se deve encarar o uso de um modelo como fim em si mesmo!!!O importante é a melhoria dos processose das organizações como um todo!

Qualidade do produto de software

Qualidade do processo dedesenvolvimento de software

Modelo de maturidade(MPS.BR)

Gerenciamento deprojetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base

O que é MPS.BR? [

Qualidade em software via MPS.BR / Gerenciamento de Projetos

MPS.BR O MPS.BR é um programa para Melhoria de Processo

de Software Brasileiro e está dividido em 3 componentes:•Modelo de Referência (MR-MPS)•Método de Avaliação (MA-MPS) •Modelo de Negócio (MN-MPS)

Em OtimizaçãoEm Otimização

Gerenciado QuantitativamenteGerenciado Quantitativamente

DefinidoDefinido

Largamente DefinidoLargamente Definido

Parcialmente DefinidoParcialmente Definido

GerenciadoGerenciado

Parcialmente GerenciadoParcialmente Gerenciado

AA

BB

CC

DD

EE

FF

G

2

3

4

5

Relacionamentocom o CMMI

MR-MPS

MN-MPS: Modelo de Negócio

Programa MPS.BR

(SOFTEX)

II-MPS.BR & IA-MPS.BR

MNEMNC

Contrato Contrato Convênio

Convênio, se pertinente

LEGENDA:

II-MPS.BR – Instituição Implementadora do Modelo MPS.BR

IA-MPS.BR – Instituição Avaliadora do Modelo MPS.BR

MNE – Modelo de Negócio Específico para cada empresa (personalizado)

MNC – Modelo de Negócio Cooperado em grupo de empresas (pacote)

Porque MPS.BR? Acesso à melhoria de processos a pequenas e médias

em empresas em larga escala. Compatibilidade com os padrões de qualidade

aceitos internacionalmente. Caminho evolutivo mais suave e incremental que

outros modelos.

Qualidade do produto de software

Qualidade do processo dedesenvolvimento de software

Modelo de maturidade(MPS.BR)

Gerenciamento deprojetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base [

Qualidade em software via MPS.BR / Gerenciamento de Projetos

O que GP tem a ver com tudo isto?

MPS.BR x Gerenciamento de projetos Projetos como base para avaliação

Avaliação é feita sobre um conjunto de projetos representativos da organização.

Isto faz com que o trabalho nas empresas que buscam melhoria via MPS.BR seja cada vez mais orientado a projetos.

Projeto é entendido como instância do processo da organização.

MPS.BR x Gerenciamento de projetos Foco em GP no níveis iniciais G e F

Nível G•Gerência de requisitos•Gerência de projetos

Nível F•Medição•Gerência de configuração•Aquisição•Garantia da qualidade

Parcialmente Gerenciado

Gerenciado

Processo Gerência de projetos

Gerenciamento de escopo Definição de ciclo de vida de projeto Análise de viabilidade do projeto Gerenciamento de recursos (inclusive humanos) Gerenciamento de tempo Gerenciamento de riscos (inicial) Gerenciamento de dados (comunicação) Gerenciamento de custos Gerenciamento dos stakeholders

Gerenciamento de projetos

MPS.BRMelhoria de processosQualidade em software

MPS.BR x Gerenciamento de projetosProcessos ligados a GP em níveis superiores

Adaptação do Processo para Gerência do Projeto (nível E)

Gerência de Riscos (nível C) Gerência Quantitativa do Projeto (nível B)

MPS.BR x Gerenciamento de projetosRequisitos de experiência em GP para avaliadores

Avaliador líder•Experiência comprovada de 6 (seis) anos em gerência de projetos de software, no mínimo, ou experiência comprovada de implementação de processos de software onde a unidade organizacional obteve nível de maturidade MR-MPS ou CMMI em avaliação oficial.

MPS.BR x Gerenciamento de projetosRequisitos de experiência em GP para avaliadores

Avaliador adjunto•Experiência comprovada de 4 (quatro) anos em gerência de projetos de software, no mínimo, ou experiência comprovada de implementação de processos de software onde a unidade organizacional obteve nível de maturidade MR-MPS ou CMMI em avaliação oficial

MPS.BR x Gerenciamento de projetosRequisitos de experiência em GP para avaliadores

Participação na equipe de avaliação•Deve ter experiência em desenvolvimento de software, preferencialmente em gerência de projetos.

MPS.BR no Brasil e na América Latina

Meta 1 Desenvolvimento e Aprimoramento do Modelo MPS

•Guias do MPS.BR•Cursos, Provas e Workshops MPS.BR•Instituições Implementadoras (II)•Instituições Avaliadoras (IA)•Consultores de Aquisição (CA)

Meta 1 - Resultados 3 guias do MPS.BR Cursos, provas e Workshops

• 1600 participantes de cursos• 400 pessoas aprovadas nas provas MPS.BR

10 II credenciadas 2 IA em análise, 5 avaliadores líder e 20 adjuntos Treinamento de 40 pessoas para formação de novos avaliadores

(com prova para certificação de novos adjuntos) Certificação de consultores de aquisição (curso + prova + projeto

assistido)

Meta 2 Implementação e Avaliação MPS em Empresas no Brasil

•2005-2006: 120 empresas com MR-MPS implementado, seguido da avaliação MA-MPS de no mínimo 50% das mesmas

•2007-2008: + 160 empresas com MR-MPS implementado, seguido da avaliação MA-MPS de no mínimo 50% das mesmas

Meta 2 - Resultados Maio de 2006 – mais de 50 empresas implementando o MR-MPS,

muitas seguindo modelo cooperado.

Setembro de 2005 a maio de 2006 – 7 avaliações MA-MPS realizadas em níveis variados (G, F, E, A) do MR-MPS.

Adoção do modelo está se acelerando.

Meta 3 Disseminação Regional do Modelo MPS em 2 Países

da América Latina

Meta 3 - Resultados Tradução dos 3 Guias para o Espanhol (contratada)

Manifestações de Interesse:• Argentina (MPS.AR)• Chile (MPS.CL)• Peru (MPS.PE)• Uruguai (MPS.UY)

MPS.BR em Minas Gerais

MPS.BR em Minas Gerais CCOMP-MG (FUMSOFT) é uma Instituição

Implementadora credenciada oficialmente junto ao Softex.

MPS.BR em Minas Gerais Iniciativas CCOMP:

•Treinamentos para consultores e empresas (40 h)

•Realização de workshop para organizadores de grupos de empresas

•Criação de 10000 cartilhas sobre o MPS.BR•Formação de grupos de empresas para implementação MPS.BR

•Aplicação de treinamentos e provas de certificação MPS.BR

Projeto 2006-01 INICIADO EM 25/04/2006 10 EMPRESAS

•NÍVEL F:- POWERLOGIC CONSULTORIA E SISTEMAS S.A- SYNOS CONSULTORIA E INFORMÁTICA LTDA- USS TECNOLOGIA- PDCASE INFORMÁTICA LTDA

•NÍVEL G:- ARTE INFORMÁTICA LTDA- CONSULTBRASIL TECNOLOGIA E NEGÓCIOS LTDA- EDS-ENGESOFT DESENVOLVIMENTO DE SISTEMAS LTDA- TEKNISA SOFTWARE LTDA- ETEG INTERNET LTDA- TTY2000 TECNOLOGIA E SISTEMAS LTDA

Projeto 2006-01 TRABALHOS JÁ REALIZADOS

•TREINAMENTO•DIAGNÓSTICO INICIAL•CONSULTORIA EXECUTIVA( 5ª / 6ª sessão)

DATAS IMPORTANTES•TÉRMINO EM ABRIL/2007•AVALIAÇÃO JULHO/AGOSTO de 2007

Projeto 2006 - 02 16 empresas inscritas para implementação do modelo

nos níveis F e G

Início provável previsto para Outubro/2006•TÉRMINO EM OUTUBRO/2007•AVALIAÇÃO INÍCIO DE 2008

Implementação do MPS.BR em uma empresa mineira (TTY2000)

Roteiro Apresentar TTY2000 Implementação do MPS.BR na TTY2000

•Preparação•Formação do SEPG•Definição dos processos•Gerência de projetos

TTY2000 – Tecnologia e Sistemas

75 colaboradores 10 anos atuando no mercado:

•Desenvolvimento de soluções de intranet e internet.•Desenvolvimento e manutenção de sistemas.•Consultoria em informática.•Disponibilização de profissionais.•Fábrica de softwares.•Produto GAMA (software para gestão da indústria)

Implementação do MPS.BR na TTY2000 Preparação

•+ 10 colaboradores fizeram o curso “Introdução ao MPS.BR”

•3 colaboradores certificados como implementadores do MPS.BR

•1 colaborador certificado como avaliador do MPS.BR

•Análise do processo de desenvolvimento de software da TTY2000 – Nível G

Implementação do MPS.BR na TTY2000 Formação do SEPG (Software Engineering Process

Group) •SEPG– grupo de colaboradores responsável em mapear, definir e avaliar os processos de desenvolvimento de software, gerência de requisitos e gerência de projetos.

•Grupo pequeno e coeso, com participações pontuais de determinados profissionais.

Implementação do MPS.BR na TTY2000 Definição de processos

•Ótimo é inimigo do bom•O processo é melhorado continuamente •Conhecer processos de outras empresas

•Ferramentas X Processos•A prática valida os processos

Implementação do MPS.BR na TTY2000 Gerência de projetos

•Nível G – parcialmente gerenciado•Conhecimento das fases de um projeto (iniciação, planejamento, execução, controle e encerramento)

•Planejar um projeto não é apenas elaborar um cronograma

Exercício Pesquise sobre como funciona e elabore a simulação

de um pequeno projeto utilizando KANBAN. Faça o mesmo para OKR (Objectives and Key Results)

Referências Gerold Keefer, Hanna Lubecka, The CMMI in 45 Minutes, Dec. 2001 CMMI Product Development Team, CMMI for Systems Engineering and

Software Engineering – Continuous Representation, Version 1.1. CMU/SEI-2002-TR-001, Dec. 2001.

CMMI Product Development Team, CMMI for Systems Engineering and Software Engineering – Staged Representation, Version 1.1. CMU/SEI-2002-TR-001, Dec. 2001.

Dennis A. Ahern, Aaron Clouse, Richard Turner, CMMI Distilled. Addinson-Wesley, 2001.

Upgrading from SW-CMM to CMMI. Software Engineering Institute, The Road to CMMI. Mary Beth Chrissis, Mike Konrad, Sandy Shrum, CMMI Guidelines for

Process Integration and Product Improvement, Addinson-Wesley, 2003. www.sucesues.org.br/eventos/57/cmm.pdf http://www.process-strategies.com/105.htm