• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
“Gerenciamento de projetos, MPS.BR e qualidade em software“
 

“Gerenciamento de projetos, MPS.BR e qualidade em software“

on

  • 1,455 views

 

Statistics

Views

Total Views
1,455
Views on SlideShare
1,453
Embed Views
2

Actions

Likes
1
Downloads
61
Comments
1

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • ESTUDO
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.    
  • 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
  • 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.
  • 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.
  • -       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.
  • -     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.
  • 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.

“Gerenciamento de projetos, MPS.BR e qualidade em software“ “Gerenciamento de projetos, MPS.BR e qualidade em software“ Presentation Transcript

  • Gerenciamento de projetos, MPS.BR e qualidade em software Andriele Ribeiro, MSc, PMP Marta Noemi, PMP, ITIL Foundation
  • Quem vos fala...
    • Andriele Ferreira Ribeiro, MSc, PMP
      • Vice-presidente de Filiação do PMI-MG
      • Implementador oficial MPS.BR (membro da equipe de consultores do CCOMP-MG)
      • Aprovado como avaliador adjunto oficial MPS.BR (ainda não ligado a uma instituição avaliadora)
      • Gerente de Modernização de Desenvolvimento de Sistemas - Prodemge
  • Quem vos fala...
    • Marta Noemi Duarte, PMP, ITIL Foundation
      • Coordenadora do Programa de Voluntariado do PMI-MG
      • Examinadora do PMQ – Prêmio Mineiro da Qualidade ciclos 2004, 2005 e 2006
      • Certificada como implementadora do MPS.BR
      • Gerente de Projetos – TTY2000
  • Agenda
    • Qualidade em software via MPS.BR / Gerenciamento de Projetos
    • MPS.BR no Brasil e na América Latina
    • MPS.BR em Minas Gerais
    • Implementação do MPS.BR em uma empresa mineira (TTY 2000)
  • 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 de desenvolvimento de software Modelo de maturidade (MPS.BR) Gerenciamento de projetos É 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 de desenvolvimento de software Modelo de maturidade (MPS.BR) Gerenciamento de projetos É 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 de desenvolvimento de software Modelo de maturidade (MPS.BR) Gerenciamento de projetos É 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 processos e das organizações como um todo!
  • Qualidade em software via MPS.BR / Gerenciamento de Projetos Qualidade do produto de software Qualidade do processo de desenvolvimento de software Modelo de maturidade (MPS.BR) Gerenciamento de projetos É obtida por meio de É alcançada mais facilmente se baseada em Tem como base O que é MPS.BR? [
  • 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ção Gerenciado Quantitativamente Definido Largamente Definido Parcialmente Definido Gerenciado Parcialmente Gerenciado A B C D E F G Relacionamento com o CMMI MR-MPS 2 3 4 5
  • MN-MPS: Modelo de Negócio Programa MPS.BR (SOFTEX) II-MPS.BR & IA-MPS.BR MNE MNC 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 em software via MPS.BR / Gerenciamento de Projetos Qualidade do produto de software Qualidade do processo de desenvolvimento de software Modelo de maturidade (MPS.BR) Gerenciamento de projetos É obtida por meio de É alcançada mais facilmente se baseada em Tem como base [
  • 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.BR Melhoria de processos Qualidade em software
  • 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)
  • 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.
  • 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
  • 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.
  • 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
  • Dúvidas Fiquem à vontade para contactar: Andriele [email_address] [email_address] Marta [email_address] [email_address]