UMA VISÃO GERAL DOMPS.BR – MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRODjalma Domingos da Silva

CITEF – Congresso de Inovação Tecnológica de Fernandópolis

12 de novembro de 2009, 14h

MINI-CURRÍCULO DO PALESTRANTE Possui graduação em Engenharia Civil pela

Faculdade de Engenharia de São José do Rio Preto (1983), graduação em Engenharia de Computação pelo Centro Universitário do Norte Paulista (2005), especialização em Administração de Marketing pelo Instituto Nacional de Pós-Graduação (1996), mestrado em Ciências da Computação e Matemática Computacional pelo ICMC da Universidade de São Paulo (1998) e doutorado em Engenharia Elétrica pela Escola Politécnica da Universidade de São Paulo (2005).

Docente da Fatec de São José do Rio Preto, UNIFEV e UNIRP.

Responsável de Laboratório de Engenharia de Software da Fatec-RP.

Aprovado na Prova P1 de Introdução ao MPS-BR.

OBJETIVOS DA APRESENTAÇÃO

Apresentar uma visão geral do MPS.BR, com foco no Modelo de Referência MR-MPS, publicado no Guia Geral:2009, e que possui conformidade com as Normas Internacionais ISO/IEC 12207, ISO/IEC 15504 e CMMI.

Apresentar o Método de Avaliação MA-MPS, publicado no Guia de Avaliação:2009.

SUMÁRIO

Maturidade e Capabilidade do Processo de Software: Definição

Modelo: Definição MPS.BR: O Modelo MPS.BR: Capacidade do Processo Processos do Nível G, primeiro nível do

modelo Método de Avaliação (MA-MPS) para o Nível G

MATURIDADE E CAPABILIDADE DO PROCESSO DE SOFTWAREDefinição

PROCESSO DE SOFTWARE - DEFINIÇÃO Processo – um conjunto de atividades inter-

relacionadas, que transforma entradas em saídas (ABNT, 1998)

Processo de Software – um conjunto de atividades, métodos, práticas e transformações que as pessoas utilizam para desenvolver e manter software e seus produtos relacionados (CMMI)

PREMISSA DA GESTÃO DE PROCESSOS DE SOFTWARE

A qualidade do sistema de software é altamente influenciada pela qualidade do processo ou maturidade utilizado para seu desenvolvimento e sua manutenção.

Esta premissa implica em um foco no processo, bem como no produto.

POR QUE O PROCESSO DE SOFTWARE É O FOCO CORRETO?

Focando somente no produto são perdidos: O conhecimento de como executar da melhor

forma. A idéia de tamanho e complexidade (de projeto,

de problemas, de esforços, etc).

Focando no processo são previsíveis: Repetibilidade dos resultados. Tendências dos projetos. Características do produto (custo, qualidade,

esforço e tempo).

MODELODefinição

O QUE É UM “MODELO”

Modelo é uma representação simplificada do mundo real.

Os modelos CMMI e MPS.BR não são processos.

MODELO DE MATURIDADE - BENEFÍCIOS

Estabelece uma linguagem comum. Estabelece uma visão em níveis. Provê uma estrutura para priorização de

ações. Agrega as melhores práticas de uma ampla

comunidade de software. Provê uma estrutura para desempenhar

diagnósticos (appraisals) consistentes e confiáveis.

Suporta as organizações (reativa → pró-ativa)

MODELO DE MATURIDADE - RISCOS

Modelos são simplificações do mundo real. Modelos não são completos / abrangentes. Sua interpretação e adaptação (CMMI-

tailoring) devem estar alinhadas com os objetivos (estratégia) dos negócios da organização.

Análises e Julgamentos são necessários para utilizar os modelos corretamente e com perspicácia.

O modelo não deve ser considerado como uma “bíblia”.

MPS.BRO Modelo

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

NÍVEIS DE MATURIDADE MR-MPS

NÍVEIS G E F – PARCIALMENTE GERENCIADO E GERENCIADO Processos básicos de gerenciamento de projetos são

estabelecidos para monitoramento de custo, prazo e funcionalidade.

A necessária disciplina do processo é adequada para repetir sucessos anteriores em projetos com aplicações similares.

Principais características: Garantia que os requisitos são gerenciados Processos são planejados, desempenhados, medidos e

controlados As práticas são mantidas em período de crise Projetos são desempenhados e gerenciados conforme

planos documentados O controle gerencial permite a visibilidade em ocasiões

definidas (“milestones”) Compromissos estabelecidos e revisados com

stakeholders relevantes Produtos de trabalhos apropriadamente controlados

GERÊNCIA DE REQUISITOS - GRE O propósito da GRE é gerenciar os requisitos

dos produtos do projeto e componentes do produto e identificar inconsistências entre estes requisitos e os planos de projeto e produtos de trabalho.

Envole: Obtenção e entendimento dos requisitos Obter os compromissos para atendimento dos

requisitos Gerenciar mudanças de requisitos Manter rastreabilidade bidirecional dos requisitos

(da origem dos requisitos para o nível mais baixo de detalhamento e vice-e-versa)

Identificar inconsistência entre produtos de trabalho e requisitos

GRE: PRINCIPAIS CONSIDERAÇÕES

Existência de uma gerência adequada dos conjuntos de requisitos para suportar o planejamento e necessidades de execução do projeto.

Os requisitos são analisados criticamente com o provedor dos requisitos (requirements provider) para solucionar questões e mal entendimentos antes de sua incorporação nos planos de projeto.

Obtenção dos compromissos sobre os requisitos dos participantes do projeto.

Gerência nas mudanças dos requisitos quando envolvem ou são identificadas inconsistências ocorridas nos planos, produtos de trabalho e requisitos.

GRE: DOCUMENTAÇÃO DOS REQUISITOS

Os requisitos alocados, a engenharia de software por exemplo, devem ser documentados.

A documentação, dependendo do tamanho e complexidade do projeto, pode ser de forma simples (memorando) ou elaborada (vários documentos do cliente).

Se os requisitos mudam, estas mudanças devem ser documentadas e os documentos relacionados também, devendo ser acompanhados e verificados.

ESTRUTURA DO MPS.BR

Níveis de maturidade

Processo Capacidade

Propósito

Atributo 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.BRCapacidade do Processo

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.

ATRIBUTO DE PROCESSO – AP 2.1 (CONT.)

Resultados esperados (cont.): 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.

MA-MPS: MÉTODO DE AVALIAÇÃO MPS.BR

MA-MPS

ESTIMATIVA DE TEMPO E EQUIPE DE AVALIAÇÃO

ESCALA PARA CARACTERIZAR O GRAU DE IMPLEMENTAÇÃO DE UM RESULTADO ESPERADO

CARACTERIZAÇÃO DE ATRIBUTOS DO PROCESSO PARA SATISFAZER AOS NÍVEIS MR-MPS

VELHOS PROBLEMAS “TAILORED FOR SW”

REFERÊNCIAS

ASR. MPS.BR – Visão Geral. Mini-curso ministrado no Senac Rio Preto em março de 2009.

______. Artigos para download. Disponível em: <www.arsconsultoria.com.br/artigos>. Acessado em: 28 mai 2009.

MPS.BR. Curso de Introdução ao MPS.BR (C1-MPS.BR). Realizado em 13 e 14 de agosto de 2009.

______. Para obter guias e demais informações. Disponível em: <http://www.softex.br/mpsbr>. Acessado em: 28 mai 2009.

“Falta de tempo é desculpa daqueles que perdem tempo por falta de métodos.”Albert Einstein

Contato: djalma.silva@terra.com.br