Qualidade de Software MPS-BR

Apresentação em tema: "Qualidade de Software MPS-BR"— Transcrição da apresentação:

1 Qualidade de Software MPS-BR
Prof. Guilherme Alexandre Monteiro Reinaldo Recife

2 Contatos Prof. Guilherme Alexandre Monteiro Reinaldo
Apelido: Alexandre Cordel /gtalk: Site: Celular: (81)

3 Qualidade em software via MPS.BR / Gerenciamento de Projetos

4 Qualidade em software via MPS.BR / Gerenciamento de Projetos
Qualidade do produto de software É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

5 Qualidade em software via MPS.BR / Gerenciamento de Projetos
[ Qualidade do produto de software É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

6 O bom e velho triângulo mágico...
Qualidade do produto x Qualidade do processo Porque processo é importante? O bom e velho triângulo mágico...

7 O processo é a ponta do triângulo que unifica os outros aspectos
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

8 Sem processos claros e eficientes, uma empresa não é escalável.
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.

9 Qualidade em software via MPS.BR / Gerenciamento de Projetos
Qualidade do produto de software [ É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

10 Qualidade do processo x Modelos de maturidade
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.

11 Qualidade do processo x Modelos de maturidade
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

12 Mas atenção: Não se deve encarar o uso
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 processos e das organizações como um todo!

13 Qualidade em software via MPS.BR / Gerenciamento de Projetos
Qualidade do produto de software [ É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em O que é MPS.BR? Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

14 MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS)
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)

15 MR-MPS A B C D E F G 5 Em Otimização 4 Gerenciado Quantitativamente
2 3 4 5 Em Otimização B Gerenciado Quantitativamente C Definido D Largamente Definido E Parcialmente Definido F Gerenciado G Parcialmente Gerenciado Relacionamento com o CMMI MR-MPS

16 MN-MPS: Modelo de Negócio
II-MPS.BR & IA-MPS.BR Programa MPS.BR (SOFTEX) Convênio Contrato Contrato MNC MNE 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)

17 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.

18 Qualidade em software via MPS.BR / Gerenciamento de Projetos
Qualidade do produto de software É obtida por meio de Qualidade do processo de desenvolvimento de software [ É alcançada mais facilmente se baseada em Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

19 O que GP tem a ver com tudo isto?

20 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.

21 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

22 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

23 MPS.BR Melhoria de processos Qualidade em software Gerenciamento de projetos

24 MPS. BR x Gerenciamento de projetos
MPS.BR x Gerenciamento de projetos Processos 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)

25 MPS. BR x Gerenciamento de projetos
MPS.BR x Gerenciamento de projetos Requisitos 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.

26 MPS. BR x Gerenciamento de projetos
MPS.BR x Gerenciamento de projetos Requisitos 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

27 MPS. BR x Gerenciamento de projetos
MPS.BR x Gerenciamento de projetos Requisitos 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.

28 MPS.BR no Brasil e na América Latina

29 Meta 1 Guias do MPS.BR Cursos, Provas e Workshops MPS.BR
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)

30 Meta 1 - Resultados 1600 participantes de cursos
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)

31 Meta 2 Implementação e Avaliação MPS em Empresas no Brasil : 120 empresas com MR-MPS implementado, seguido da avaliação MA-MPS de no mínimo 50% das mesmas : empresas com MR-MPS implementado, seguido da avaliação MA-MPS de no mínimo 50% das mesmas

32 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.

33 Meta 3 Disseminação Regional do Modelo MPS em 2 Países da América Latina

34 Meta 3 - Resultados Argentina (MPS.AR) Chile (MPS.CL) Peru (MPS.PE)
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)

35 MPS.BR em Minas Gerais

36 MPS.BR em Minas Gerais CCOMP-MG (FUMSOFT) é uma Instituição Implementadora credenciada oficialmente junto ao Softex.

37 MPS.BR em Minas Gerais Treinamentos para consultores e empresas (40 h)
Iniciativas CCOMP: Treinamentos para consultores e empresas (40 h) Realização de workshop para organizadores de grupos de empresas Criação de 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

38 Projeto 2006-01 NÍVEL F: NÍVEL G: INICIADO EM 25/04/2006 10 EMPRESAS
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

39 Projeto 2006-01 TREINAMENTO DIAGNÓSTICO INICIAL
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

40 Projeto 2006 - 02 TÉRMINO EM OUTUBRO/2007 AVALIAÇÃO INÍCIO DE 2008
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

41 Implementação do MPS.BR em uma empresa mineira (TTY2000)
Boa noite a todos. Fico muito feliz de estar aqui hoje, relatando a minha experiência na implementação dos processos exigidos pelo nível G do MPS.BR.

42 Roteiro Preparação Formação do SEPG Definição dos processos
Apresentar TTY2000 Implementação do MPS.BR na TTY2000 Preparação Formação do SEPG Definição dos processos Gerência de projetos Este é roteiro da apresentação, Inicialmente vou falar um pouco sobre a TTY2000, E sobre a implementação do MPSBR na TTY2000. Eu dividi em 4 partes: Preparação - Como foi a preparação da TTY2000 para a implementação do MPSBR Depois vou falar como foi montado o SEPG e o que é Logo em seguida como o SEPG está definindo os processos necessários para atender o Nivel G Por último falo como o MPSBR está ajudando a disseminação da gerência de projetos

43 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) Hoje a TTY tem em torno de 75 colaboradores e atua no mercado há 10 anos, principalmente no desenvolvimento de soluções de intranet e internet,desenvolvimento e manutenção de sistemas, consultoria em informática,disponibilização de profissionais, fabrica de softwares e comercialização do GAMA, software para a gestão da indústria.

44 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 A TTY2000 foi uma das primeiras empresas interessadas em participar do MPSBR, a nossa preparação começou em 2004. Alguns colaboradores participaram do primeiro curso “introdutório ao MPSBR”, isso aconteceu em dezembro de 2004. Houve alto investimento em treinamento, + 10 de colaboradores treinados no Curso “Introdução ao MPSBR”, sendo 3 certificados como implementadores e 1 certificado como avaliador. Houve uma auto-análise dos processos de desenvolvimento de software da TTY2000, e optamos começar no nível G. Esta opção por iniciar pelo nível G ajudou a assimilação gradual de novos conceitos, na implementação dos processos, que são somente dois: gerência de requisitos e gerência de projetos. Optamos por fazer um passo de cada vez.

45 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. -       O que seria o   SEPG (Software Engineering Process Group) ? Vamos entender o que seria o SEPG, seria o grupo de colaboradores responsável em mapear, definir, descrever e avaliar os processos que atendam as áreas exigidas pelo nível, no nosso caso, G. Quanto mais coeso e menor, mais fácil para trabalhar. No início, a tendência é tentar envolver muitas pessoas para participar, mas com o tempo, percebemos que quanto maior o grupo, mais difícil fica o consenso e nem os integrantes estavam comprometidos. Mas é importante ter participações pontuais de profissionais na definição de uma fase ou processos. Por exemplo, na fase de proposta, tivemos a participação da área comercial, que nos ajudou a definir os processos. Atualmente, o SEPG da TTY2000 é formado por 4 pessoas, um analista com experiência em plataforma alta outro em experiência em plataforma baixa, eu, que tenho experiência em mapear e definir processos e o gerente do projeto do MPSBR.

46 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 -    Aqui,é relato a experiência que nós tivemos ao definir os processos e fases. Ótimo é inimigo do bom - Temos que aplicar o que é possível na realidade da empresa. A dica é ser simples,definir o processo de maneira simples, objetiva e prática. Definir o processo, de maneira que possa ser implementado na empresa,quanto antes melhor. O processo é melhorado continuamente - Os processos serão ajustados e melhorados continuamente. Sempre falo que o processo é vivo, ele sempre muda. Processo que não muda em 6 meses, ou não está sendo utilizado ou não está atualizado.  Padronização do conceitos - Quando se reúne pessoas com vivências diferentes é muito importante entender o que outro está dizendo. Exemplos: projeto para o analista é o projeto lógico de um sistema, para um gerente de projeto,é completamente diferente. Por isso a padronização de conceitos é importante e não perder o referencial que é o guia geral do MPSBR Conhecer processos de outras empresas – A troca de informações e de experiência é muito enriquecedor e válido,mas cuidado, não tente copiá-los, coloca-los na empresa,porque cada empresa tem suas particulares. Ferramentas X Processos – há várias ferramentas no mercado, escolha as ferramentas que a empresa já trabalha, porque? O tempo é muito curto para definir processos e escolher ferramentas. A escolha da ferramenta é um processo demorado,podendo deixar isso para outro momento.A outra dica aqui é não defina os processos baseando-se nas ferramentas. Os processos são independentes da ferramenta. Validação dos processos com a prática – depois que definimos o processo e tentamos colocá-lo em prática quanto antes,assim desta forma podemos ajustá-lo rapidamente.

47 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 Finalizando, achei interessante mostrar como o MPSBR está ajudando a disseminar os fundamentos da gerência de projetos para a área de TI. O Guia Geral do MPSBR coloca como referencial o PMBOK quando fala sobre a gerência de projetos E a gerência de projetos é uma área exigida já na fase inicial, nível G, que é parcialmente gerenciado. Participando desta implementação do MPSBR, percebi que algumas pessoas da área de TI, principalmente, os analistas não tinham conhecimento das fases de um projeto o que era iniciação, planejamento, execução, controle e encerramento. Acreditavam que planejar um projeto era apenas elaborar um cronograma. Então, acredito que com o MPSBR, haverá maior entendimento e compressão sobre a gerência de projetos. Gostaria de agradecer a todos pela atenção e estou a disposição.

48 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)

49 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 CMU/SEI-2002-TR-001, Dec CMMI Product Development Team, CMMI for Systems Engineering and Software Engineering – Staged Representation, Version CMU/SEI-2002-TR-001, Dec 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.