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
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)
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.
Focando somente no produto são perdidos: O conhecimento de como executar da melhor forma. A ideia 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).
Modelo é uma representação simplificada do mundo real.
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)
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.
Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma sequencia de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma sequencia de atividades. Às vezes essa sequencia não é fixa. Às vezes essa sequencia não segue uma ordem lógica. Às vezes essa sequencia provoca algum retrabalho. Mas perceba que sempre existirá uma sequencia. Às vezes essa sequencia já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.
CMM
CMM 2- Repetível 1- Inicial 3- Definido 5- Otimizado 4- Gerenciado Processo continuamente melhorado Processo previsível e controlado Processo consistente e padronizado Processo disciplinado Processo imprevisível e sem controle
CMM
CMMI
CMM
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.
Micro e Pequenas Empresas (MPEs) Tipo Receita Bruta Anual Microempresa Igual ou inferior a R$ 240.000,00 (duzentos e quarenta mil reais) Empresa de Pequeno Porte Superior a R$ 240.000,00 (duzentos e quarenta mil reais) e igual ou inferior a R$ 2.400.000,00 (dois milhões e quatrocentos mil reais). Reajuste em 10/11/2011 Valerá em 01/01/2012 Tipo Microempresa Empresa de Pequeno Porte Receita Bruta Anual Igual ou inferior a R$ 360.000,00 (trezentos e sessenta mil reais) Superior a R$ 360.000,00 (trezentos e sessenta mil reais) e igual ou inferior a R$ 3.600.000,00 (três milhões e seiscentos mil reais).
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 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.
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 Cada AP está detalhado em termos dos resultados para alcance completo do atributo (RAP) Processo Capacidade Propósito Resultados Práticas Atributo de Processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC 15504- Atributo de Processo AP Resultados 1, 2003] RAP Resultado do Atributo do Processo
5 A Em Otimização 4 B Gerenciado Quantitativamente 3 C D Definido Largamente Definido 2 E Parcialmente Definido F Gerenciado Relacionamento com o CMMI G MR-MPS Parcialmente Gerenciado
Processos básicos de gerenciamento de projetos são estabelecidos para monitoramento de custo, prazo e funcionalidade. É necessário uma disciplina do processo que seja 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
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. Envolve: 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-versa) Identificar inconsistência entre produtos de trabalho e requisitos.
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.
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.
O processo é executado Medida do quanto o processo atinge seu propósito. Resultado esperado: RAP 1. O processo atinge seus resultados definidos.
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 (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.