ITIL

ITIL
1. LIVROS DA ITIL V2
2. LIVROS DA ITIL V3
3. PORQUE ITIL É IMPORTANTE?
4. POSSÍVEIS RESULTADOS NA ADOÇÃO DO ITIL
5. POSSÍVEIS PROBLEMAS




ITIL (Information Technology Infrastructure Library) é o modelo de referência para gerenciamento de processos de TI mais aceito mundialmente. A metodologia foi criada pela secretaria de comércio (Office of Government Commerce, OGC) do governo Inglês, a partir de pesquisas realizadas por Consultores, Especialistas e Doutores, para desenvolver as melhores práticas para a gestão da área de TI nas empresas privadas e públicas.
Atualmente se tornou a norma BS-15000, sendo esta um anexo da ISO 9000/2000. O foco deste modelo é descrever os processos necessários para gerenciar a infra-estrutura de TI eficientemente e eficazmente de modo a garantir os níveis de serviço acordados com os clientes internos e externos.

A ITIL V2 é uma série de livros. Os livros oficiais do OGC estão disponíveis para compra em algumas livrarias. Para comprar estes livros, consultar o site http://www.itsmf.com.br/.
A utilização destas práticas na empresa é de domínio público, entretanto todo o material da ITIL possui direitos de cópia da coroa inglesa. Cada um dos livros da ITIL faz parte da framework completa da ITIL. A ITIL na verdade é uma biblioteca de muitos livros. Esta apostila é focada na entrega do serviço e nos livros de Suporte a Serviços e Entrega de Serviços. Nós descrevemos a ITIL conforme estes dois livros durante o texto.

A ITIL define os objetivos e atividades, as entradas e saídas de cada um dos processos encontrados em uma organização de TI. Entretanto, a ITIL não dá uma descrição específica de como estas atividades devem ser executadas, pois em cada organização estas são diferentes, ou seja, não existe receita pronta. A ênfase está em sugestões que foram provadas na prática, mas que dependendo das circunstâncias podem ser implementada de várias formas. A ITIL não oferece um método de implementação, ao invés disto oferece uma framework para planejar os processos mais comuns, papéis e atividades, indicando as ligações entre elas e que linhas de comunicação são necessárias.

A ITIL é baseada na necessidade de fornecer serviços de alta qualidade, com ênfase no serviço e no relacionamento com o cliente. A organização tem que cumprir exigências do cliente, o que significa um bom relacionamento com ele, com os parceiros e com os fornecedores. Parte da filosofia da ITIL é baseada nos sistemas de qualidade, tais como a série ISO9000.

A ITIL suporta tais sistemas de qualidade com uma descrição clara dos processos e das melhores práticas em Gerenciamento de Serviços de TI. Isto pode significativamente reduzir o tempo necessário para obter a certificação ISO. Originalmente, a ITIL V1 era consistida por um grande conjunto de livros. Cada um deles descrevia uma área específica de manutenção e operação da infra-estrutura de TI. Os dez livros que descreviam o Suporte de Serviços e Entrega de Serviços eram 14.

O núcleo dos livros da ITIL V2 foi revisado e publicado apenas como dois livros:
Suporte a Serviços e Entrega de Serviços. Isto eliminou sobreposições e inconsistências da série anterior. O quebra-cabeça da ITIL V2 mostra os principais elementos localizados nos seus livros. Cada um destes elementos se relaciona entre si, e se sobrepõem em alguns tópicos.

1. LIVROS DA ITIL V2

Os sete livros principais da ITIL V2 são:

⇒ Perspectiva de Negócio
⇒ Entrega de Serviço
⇒ Suporte a Serviço
⇒ Gerenciamento da Segurança
⇒ Gerenciamento da Infra-estrutura
⇒ Gerenciamento de Aplicações
⇒ Planejamento da Implementação do Gerenciamento de Serviços



Estes sete módulos constituem o corpo da ITIL V2. A descrição desses módulos está listada abaixo:

Suporte a Serviços: descreve os processos associados ao suporte do dia a dia e atividades de manutenção associadas com a provisão de serviços de TI.

Entrega de Serviços: cobre os processos necessários para o planejamento e entrega de serviços de TI com qualidade, e se preocupa ao longo do tempo com o aperfeiçoamento desta qualidade.

ICT Gerenciamento da Infra-estrutura: cobre todos os aspectos do Gerenciamento da Infra-estrutura como a identificação dos requisitos do negócio, testes, instalação, entrega e otimização das operações normais dos componentes que fazem parte dos serviços de TI.

Planejamento para Implementação do Gerenciamento de Serviços: examina questões e tarefas envolvidas no planejamento, implementação e aperfeiçoamento dos processos do Gerenciamento de Serviços dentro de uma organização. Também foca questões relacionadas à cultura e mudança organizacional.

Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir das necessidades iniciais dos negócios, passando por todos os estágios do ciclo de vida de uma aplicação, incluindo sua saída do ambiente de produção (quando o sistema é aposentado).
Este processo dá ênfase a assegurar que os projetos de TI e as estratégias estejam corretamente alinhados com o ciclo de vida da aplicação, assegurando que o negócio consiga obter o retorno do valor investido.

Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de TI a entender como eles podem contribuir para os objetivos do negócio e como suas funções e serviços podem estar mais bem alinhados e aproveitados para maximizar sua contribuição para a organização.

Gerenciamento da Segurança: detalha o processo de planejamento e gerenciamento em um nível mais detalhado da segurança da informação e serviços de TI, incluindo todos os aspectos associados com a reação da segurança dos incidentes. Também inclui uma avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de custos justificáveis para a implementação de contra-recursos (estratégia de segurança).


2. LIVROS DA ITIL V3

A framework da ITIL V2 é um conjunto de livros com alguns problemas de consistência – não há uma conexão bem elaborada entre os processos pelo fato de os livros terem sido escritos em momentos diferentes. A ITIL foca basicamente a eficiência e eficácia dos serviços em produção. O grande público de TI lia apenas os dois livros principais: Suporte ao Serviço e Entrega do Serviço. Mas somente pensar nisto não bastava.
Pois o não planejamento, a não antecipação das demandas, provocava uma TI muito reativa.
Foram vários os motivadores para que os livros fossem reescritos e uma nova versão da ITIL fosse lançada. Então, em meados de 2007 foi lançado a ITIL V3. A estrutura passou de sete para cinco livros principais. Agora os livros da nova versão fazem parte do ciclo de vida do serviço. Esta é a grande mudança estrutural na ITIL V3.



A abordagem do ciclo de vida do serviço é algo novo para a TI, mas não é algo novo em outras áreas do negócio. Temos que entender que um serviço nasce, se desenvolve, vai para a operação e um dia ele morre ou é aposentado, e é necessário gerenciar o serviço não só durante a sua fase adulta, mas sim desde a sua fase embrionária para que gere valor para o negócio.

O ciclo de vida do serviço tem um eixo central, que é a estratégia do serviço – é também a fase inicial deste ciclo. Esta estratégia vai guiar todas as outras fases: Desenho de Serviço, seguida da Transição de Serviço e Operação de Serviço. E envolvendo todas as fases do ciclo de vida vem a Melhoria de Serviço Continuada. Processos e funções agora estão distribuídos ao longo do ciclo de vida.

A fase de Estratégia de Serviço é a grande sacada na ITIL V3. É aqui que a TI vai se integrar com o negócio. Nós já estamos acostumados a ver a TI como sendo apenas um departamento de tecnologia que é comunicado sobre as decisões da empresa. E quando o comunicado chega a TI tem que se virar para atender às demandas e aí começam os conflitos: falta de recursos e falta de tempo. Nesta fase de estratégia a TI tem que buscar entender quais são as demandas dos seus clientes, identificar oportunidades e riscos, decidir por terceirizar ou não determinados serviços e pensar no retorno para o negócio.

Nesta fase a TI vai gerenciar o seu portfolio de serviço, e este portfolio vai conter o pipeline, o funil de serviços que é um termo que o pessoal de vendas conhece muito bem.

Todos nós sabemos que a TI sempre tem mais demanda que a sua capacidade, só que ela vai ter que priorizar o que vai desenvolver. Nem toda demanda vira serviço, por isto ela precisa fazer a gestão do seu portfolio. Com a Estratégia de Serviço da ITIL V3 é possível agora ter a visão da razão de se ter um serviço no portfolio.

Na fase do Desenho de Serviço tudo que foi levantado na Estratégia de Serviço será usado para projetar um novo serviço: custos, mercado e como o serviço será utilizado. O serviço vai ser definido com base nesta estratégia, já pensando no valor que ele vai gerar para os clientes. Se todas as informações forem levantadas já durante a fase de estratégia, a TI conseguirá projetar o serviço conforme esperado. Nesta fase já se deve pensar em qual será o SLA (Acordo de Nível de Serviço), quais os riscos envolvidos e os fornecedores necessários, e qual a capacidade da infraestrutura para suportar o serviço.

A próxima fase é a Transição de Serviço. Então se na fase anterior empacotam-se todas as informações do desenho para colocar o serviço em operação, nesta fase o foco é no Gerenciamento de Mudança. Ela se preocupará com todos os detalhes para que o serviço seja colocado em produção com o menor impacto possível para a organização.

A outra fase é a Operação de Serviço: é só manter o serviço, é o dia a dia.

Basicamente os processos de suporte do livro da V2 estão aqui nesta fase. Então aqui vem o gerenciamento de incidentes, problemas e solicitações. Também as funções de TI foram incluídas aqui, como Service Desk (Central de Serviços), manutenção de data centers, instalações técnicas e aplicações.

E envolvendo todas as fases do ciclo de vida vem a Melhoria de Serviço Continuada, que tem um foco na qualidade, avaliando tanto o serviço como os processos de gerenciamento das fases. Outro foco é que um serviço que foi entregue não é estático: ele pode ser bom hoje, mas amanhã não mais, pois a demanda do usuário vai aumentando.

Então esta fase vai procurar avaliar os serviços, vai procurar obter o feedback, e nada impede que este ciclo de vida do serviço gire várias vezes pois pode ser necessário repensar a estratégia do serviço.

Como vocês podem perceber, se a TI executar todas as fases ao criar um novo serviço ou alterar um serviço existente, ela vai errar menos. Se os serviços forem desenhados conforme os requisitos dos clientes e projetados devidamente, o pessoal de produção irá ter menos estresse para manter o serviço. Em resumo, teremos menos retrabalho e maior controle sobre os custos.

O conteúdo que estamos apresentando nesta apostila é baseado na ITIL V2, e este ainda se aplica às organizações. Os processos de suporte e entrega da versão anterior praticamente são os mesmos na nova estrutura de livros. O mercado vai continuar adotando a ITIL V2 por um bom tempo. Muitas organizações estão preferindo iniciar seus projetos de ITIL na versão 2 e depois evoluir para a versão 3, pelo fato de acharem que a versão anterior está mais simples. Por isto, tudo o que você vai aprender aqui nesta apostila será de grande valia. Se você tiver interesse em conhecer mais a ITIL V3, faça o nosso curso elearning de migração. Ao fazer o nosso curso de migração você estará habilitado para prestar o novo exame ITIL V3 Foundation.


3. PORQUE ITIL É IMPORTANTE?

Como visto no capítulo Introdução ao Cenário, a área de TI tem ganhado grande importância dentro do negócio e tem servido como meio para alcançar os objetivos da organização. Em virtude da necessidade de um Gerenciamento de Serviço de TI mais robusto, a biblioteca da ITIL tem ganhado destaque no mercado, servindo como apoio para melhorar os processos de TI.

Entre os principais objetivos da adoção da melhores práticas da ITIL podemos destacar os seguintes:

⇒ Alinhar os serviços de TI com as necessidades atuais e futuras do negócio e seus clientes. Todos os processos da ITIL falam que a TI precisa entender os requisitos de negócio da empresa para poder planejar e prover seus serviços para atender expectativas.

⇒ Melhorar a qualidade dos serviços de TI. Através de um programa de melhoria contínua, deve-se buscar a consistência na entrega dos serviços atendendo às necessidades de negócio.

⇒ Reduzir custos na provisão de serviços. Este é um dos motivos chave que levam os gestores de TI a adotarem as melhores práticas. Já existem vários casos de sucesso onde houve grande redução dos custos operacionais e investimentos em TI.

⇒ Processos mais eficientes e eficazes, buscando rapidez e resultados nos processos.

⇒ Adoção das boas práticas, evitando reinventar a roda.


4. POSSÍVEIS RESULTADOS NA ADOÇÃO DO ITIL

⇒ Falhas: 30% quantidade, 50% tempo de resolução
⇒ Mudanças: 25% tempo de conclusão, 50% mudanças urgentes e caras
⇒ Capacidade: 15% capacidade ociosa
⇒ CTP (TCO): 10%
⇒ Disponibilidade: 10%
⇒ Alta Confiabilidade
⇒ Baixo tempo de lançamento no mercado

Fonte: ITIL Forum 2003


Abaixo estão alguns exemplos de resultados alcançados em algumas empresas e setores de TI que foram pesquisados.

⇒ Redução do custo total até 48% - Gartner
⇒ 68% de redução de custos operacionais, $ 125 milhões de economia (10% do budget) - Procter e Gamble
⇒ Aumento da satisfação do cliente
⇒ Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de conhecimento - IS Organizations
⇒ Redução de 50% no tempo médio de resolução, redução de 30% no tempo para realizar novas mudanças, redução de 50% dos recursos - Utility Provider


5. POSSÍVEIS PROBLEMAS

Um projeto de implementação dos processos da ITIL pode ter vários problemas. É importante que você esteja ciente e busque contornar alguns obstáculos já conhecidos:

⇒ Falta de patrocínio, comprometimento e entendimento. É importante que todas as pessoas relacionadas com o projeto estejam conscientes das melhorias que a mudança poderá trazer. O comprometimento de todos é fundamental para fazer com que os processos sejam implementados. É necessário que este projeto tenha um patrocinador com poder dentro da organização. Mudar a cultura da organização e alterar a forma de trabalho das pessoas exige sempre que alguém com maior influência na organização apóie estas mudanças.

⇒ Cultura da empresa. Se a organização não tiver cultura para a gestão de serviços, torna-se muito complicado a TI obter a colaboração dos demais departamentos.
Foco no cliente e busca por serviços de qualidade é primordial para sustentar um projeto de ITIL.

⇒ Excesso de expectativa. Tenha em mente que a adoção das melhores práticas não se faz em dias. É necessário planejamento, insistência, acompanhamento e adaptações ao longo do projeto.

⇒ Problemas na gestão do projeto. A implementação de um programa de gerenciamentos de TI deve ser encarado como um projeto, com responsáveis por cada etapa, prazos para implementação e recursos necessários. Para que você possa implementar as práticas da ITIL é recomendável passar por um treinamento como ITIL Manager. O treinamento de fundamentos não é o suficiente para conduzir um projeto como este.

⇒ Falhas de comunicação. A estrutura de departamentos dentro da TI pode dificultar o trabalho em equipe e o fluxo de informações.

⇒ Objetivos não alcançados: melhoria de qualidade, redução de custo, satisfação do usuário, alinhamento de TI com a estratégia de negócio. Muitos implementam a ITIL para alcançar estes objetivos, e quando não obtém sucesso em pouco tempo acabam abandonando o uso da ITIL. O não sucesso do projeto pode estar associado à forma como a organização resolveu implementar as práticas da ITIL.

É preciso ter bom senso do que é realmente necessário na organização. É importante saber adaptar as práticas.

BIBLIOGRAFIA RECOMENDADA
http://www.itsmf.com.br/

QABI Consultoria e Oz InSite - Desenvolvimento Web
Compartilhar no Facebook:
Compartilhar no Linkedin:

MPS.BR - DESCRIÇÃO DETALHADA DOS PROCESSOS

1. NÍVEL G – Parcialmente Gerenciado





Os processos estão descritos e ordenados pelo nível de maturidade de forma crescente, sendo que cada nível inclui os processos do nível anterior. Os níveis são:
G - Parcialmente Gerenciado;
F - Gerenciado;
E - Parcialmente Definido;
D - Largamente Definido;
C - Definido;
B - Gerenciado Quantitativamente, e;
A - Em Otimização.



O nível de maturidade G é composto pelos processos Gerência do Projeto e Gerência de Requisitos. Neste nível os processos devem satisfazer os atributos de processo AP 1.1 (o processo é executado) e AP 2.1 (o processo é gerenciado).

1.1. Processo: Gerência do Projeto – GPR

Nível MR-MPS: G – Parcialmente Gerenciado
 Propósito:
O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, no contexto dos requisitos e restrições do projeto.

Resultados esperados:
GPR 1. O escopo do trabalho para o projeto está definido;
GPR 2. O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados;
GPR 3. As fases do ciclo de vida do projeto são definidas;
GPR 4. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário ajustes são realizados;
GPR 5. As tarefas, os recursos e a infra-estrutura necessários para completar o trabalho são planejados;
GPR 6. O cronograma e o orçamento do projeto são estabelecidos e mantidos;
GPR 7. Os riscos do projeto são identificados e o seu impacto, probabilidadede ocorrência e prioridades de tratamento são determinados e documentados;
GPR 7. Os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-los, incluindo (se pertinente) questões de privacidade e segurança;
GPR 9. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;
GPR 10. O esforço e o custo para os produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências técnicas;
GPR 11. O envolvimento dos interessados no projeto é planejado;
GPR 12. O planejamento do projeto é revisado com todos os interessados e ocompromisso com o mesmo é obtido;
GPR 13. O planejamento do projeto é monitorado no que se refere a cronograma, custos, recursos, riscos, envolvimento dos interessados e dados;
GPR 14. Revisões são realizadas em marcos do projeto conforme estabelecido no planejamento;
GPR 15. Registros e análise dos problemas identificados nas monitorações são estabelecidos;
GPR 16. Ações corretivas são estabelecidas quando necessário e gerenciadas até a sua conclusão.

1.2. Processo: Gerência de Requisitos – GRE

Nível MR-MPS: G – Parcialmente Gerenciado
Propósito:
O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre
esses requisitos e os planos e produtos de trabalho do projeto.

Resultados esperados:
GRE 1. Uma comunicação contínua com os fornecedores de requisitos é estabelecida;
GRE 2. O entendimento dos requisitos é obtido;
GRE 3. A aceitação dos requisitos é estabelecida por meio de critérios objetivos;
GRE 4. O comprometimento com os requisitos é estabelecido e mantido;
GRE 5. A rastreabilidade entre os requisitos, os planos do projeto e os produtos de trabalho é estabelecida e mantida;
GRE 6. Inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos são identificadas e corrigidas;
GRE 7. Mudanças nos requisitos são gerenciadas ao longo do projeto.



O nível de maturidade F é composto pelos processos do nível de maturidade anterior (G) acrescidos dos processos Aquisição, Gerência de Configuração, Garantia da Qualidade e Medição. Todos estes processos devem satisfazer os atributos de processo AP 1.1, AP 2.1 e AP 2.2.

2.1. Processo: Aquisição – AQU

Nível MR-MPS: F - Gerenciado
Propósito:
O propósito do processo de Aquisição é se obter um produto e/ou serviço que satisfaça a necessidade expressa pelo cliente.

Resultados esperados:
AQU 1. As necessidades de aquisição, as metas, os critérios de aceitação do produto e/ou serviço, os tipos e estratégia de aquisição são definidos;
AQU 2. Os critérios de seleção do fornecedor são estabelecidos e usados para avaliar os potenciais fornecedores;
AQU 3. O fornecedor é selecionado com base na avaliação das propostas e dos critérios estabelecidos;
AQU 4. Um acordo que expresse claramente a expectativa, as responsabilidades e as obrigações de ambos (cliente e fornecedor) é estabelecido e negociado entre o cliente e o fornecedor;
AQU 5. Um produto e/ou serviço que satisfaz a necessidade expressa pelo cliente é adquirido baseado na análise dos potenciais candidatos;
AQU 6. A aquisição é monitorada de forma que as condições especificadas são atendidas, tais como: custo, cronograma e qualidade e, se necessário, ações corretivas são conduzidas;
AQU 7. O produto e/ou serviço de software entregue é avaliado em relação ao acordado e os resultados da aceitação são documentados.
AQU 8. O produto adquirido (caso pertinente) é incorporado ao projeto.

2.2. Processo: Gerência de configuração – GCO

Nível MR-MPS: F - Gerenciado
Propósito:
O propósito do processo de Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.

Resultados esperados:
GCO 1. Os itens de configuração são identificados;
GCO 2. Os itens de configuração gerados pelo projeto são definidos e colocados sob uma linha base;
GCO 3. É estabelecido e mantido um Sistema de Gerência de Configuração;
GCO 4. As modificações e liberações dos itens de configuração são controladas;
GCO 5. As modificações e liberações são disponibilizadas para todos os envolvidos;
GCO 6. A situação dos itens de configuração e as solicitações de mudanças são registradas, relatadas e o seu impacto é analisado;
GCO 7. A completeza e a consistência dos itens de configuração são asseguradas;
GCO 8. O armazenamento, o manuseio e a entrega dos produtos de traballho são controlados;
GCO 9. A integridade das linhas bases (baselines) é estabelecida e mantida, através de auditoria da configuração e de registros da Gerência de Configuração.

2.3. Processo: Garantia da Qualidade – GQA

Nível MR-MPS: F - Gerenciado
Propósito:
O propósito do processo Garantia da Qualidade é garantir que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos.

Resultados esperados:
GQA 1. A aderência dos produtos aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente;
GQA 2. A aderência dos processos executados aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente;
GQA 3. Os produtos de trabalho são avaliados antes de serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto;
GQA 4. Os problemas e as não-conformidades são identificados, registrados e comunicados;
GQA 5. Ações corretivas para não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões;
GQA 6. O escalonamento das ações corretivas para níveis superiores é realizado, quando necessário, de forma a garantir a solução das mesmas;
GQA 7. A aderência ao processo de Garantia da Qualidade e de seus produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente.

2.4. Processo: Medição – MED

Nível MR-MPS: F - Gerenciado
Propósito:
O propósito do processo Medição é coletar e analisar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.

Resultados esperados:
MED 1. Objetivos e atividades de medição são estabelecidos a partir das necessidades de informação e objetivos da organização;
MED 2. Um conjunto adequado de medidas, orientado pelas necessidades de informação e objetivos de medição, é identificado e/ou desenvolvido, priorizado, documentado, revisado e atualizado;
MED 3. As atividades coleta e armazenamento são especificadas, incluindo-se métodos e ferramentas;
MED 4. As atividades de análise são especificadas, incluindo-se métodos e ferramentas;
MED 5. Os dados requeridos são coletados e analisados;
MED 6. Os dados e os resultados são armazenados;
MED 7. As informações produzidas são usadas para apoiar decisões e para fornecer uma base objetiva para comunicação aos interessados.



O nível de maturidade E é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos Adaptação do Processo para Gerência do Projeto, Avaliação e Melhoria do Processo Organizacional, Definição do Processo Organizacional, e Treinamento. Todos os processos devem satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.

3.1. Processo: Adaptação do Processo para Gerência do Projeto – APG

Nível MR-MPS: E – Parcialmente Definido
Propósito:
O propósito do processo Adaptação do Processo para Gerência do Projeto é estabelecer e gerenciar o projeto e envolver os interessados de acordo com o processo definido e integrado que é adaptado do conjunto de processos-padrão da organização.

Resultados esperados:
APG 1. Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação de processo da organização. ;
APG 2. O planejamento e as estimativas das atividades do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processos organizacionais;
APG 3. O Plano do Projeto e outros planos que afetam o projeto são integrados;
APG 4. O projeto é gerenciado utilizando-se o Plano do Projeto, outros planos que afetam o projeto e o processo definido para o projeto;
APG 5. Os produtos de trabalho, medições e experiências documentadas contribuem para os ativos de processos organizacionais;
APG 6. O envolvimento dos interessados no projeto é gerenciado;
APG 7. Dependências críticas são identificadas, negociadas e acompanhadas com os interessados ;
APG 8. Questões pertinentes são resolvidas com os interessados

3.2. Processo: Avaliação e Melhoria do Processo Organizacional – AMP

Nível MR-MPS: E – Parcialmente Definido
Propósito:
O propósito do processo Avaliação e Melhoria do Processo Organizacional é determinar o quanto os processos-padrão da organização contribuem para a
organização a planejar e implementar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos.

Resultados esperados:
AMP 1. A descrição das necessidades e os objetivos dos processos da organização estão estabelecidos e mantidos;
AMP 2. As informações e os dados relacionados ao uso dos processos padrão para projetos específicos existem e são mantidos em repositório específico;
AMP 3. Revisões dos processos-padrão da organização são realizadas em intervalos adequados para assegurar sua adequação e efetividade e manter o entendimento de seus pontos fortes e fracos;
AMP 4. Registros precisos das avaliações realizadas são obtidos e mantidos acessíveis;
AMP 5. Os objetivos de melhoria são identificados e priorizados e as conseqüentes mudanças nos processos são planejadas e implementadas de forma controlada e com resultados previsíveis;
AMP 6. A implantação de ativos do processo organizacional ou de alterações nestes ativos são implementadas de forma controlada na organização;
AMP 7. Experiências relacionadas aos processos são incorporadas nos ativos do processo organizacional;
AMP 8. Dados técnicos, históricos e resultantes das avaliações são analisados e usados para melhorar os processos, recomendar mudanças nos projetos e determinar necessidades de mudanças tecnológicas.

3.3. Processo: Definição do Processo Organizacional – DFP

Nível MR-MPS: E – Parcialmente Definido
Propósito:
O propósito do processo Definição do Processo Organizacional é estabelecer e manter um conjunto de ativos dos processos organizacionais usável e aplicável às necessidades de negócio da organização.

Resultados esperados:
DFP 1. Um conjunto de processos-padrão da organização é definido e documentado, juntamente com a indicação da aplicabilidade de cada processo;

DFP 2. O conjunto de processos definido é mantido em uma biblioteca de ativos de processos da organização com mecanismos de consulta e recuperação;
DFP 3. Tarefas, atividades e produtos de trabalho associados aos processos padrão são identificados e detalhados, juntamente com as características de desempenho esperadas;
DFP 4. As descrições dos modelos de ciclo de vida a serem utilizados nos projetos da organização são estabelecidas e mantidas;
DFP 5. São desenvolvidas estratégias para adaptação do processo-padrão de acordo com as necessidades dos projetos;
DFP 6. O repositório de medidas da organização é estabelecido e mantido.

3.4. Processo: Treinamento – TRE

Nível MR-MPS: E – Parcialmente Definido
Propósito:
O propósito do processo Treinamento é prover a organização e os projetos com profissionais que possuam os conhecimentos e as habilidades necessárias para executar suas funções de forma efetiva.

Resultados esperados:
TRE 1. Uma estratégia de treinamento é planejada e implementada com o objetivo de atender as necessidades de treinamento dos projetos e da organização;
TRE 2. As necessidades de treinamento que são responsabilidade da organização são identificadas;
TRE 3. Para garantir que todos os indivíduos tenham o conhecimento e habilidades requeridas para executar suas atividades, é estabelecida uma estratégia para treinamento que contemple mecanismos, materiais e instrutores qualificados;
TRE 4. O treinamento é conduzido e registrado;
TRE 5. A efetividade do treinamento é avaliada.



O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores ( G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Solução Técnica, Validação, e Verificação. Todos os processos devem satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.

4.1. Processo: Desenvolvimento de Requisitos – DRE

Nível MR-MPS: D – Largamente Definido
Propósito:
O propósito do processo Desenvolvimento de Requisitos é estabelecer os requisitos dos componentes do produto, do produto e do cliente.



Resultados esperados:
DRE 1. As necessidades e expectativas, restrições e requisitos de interface do cliente são identificadas;
DRE 2. Um conjunto definido de requisitos funcionais e não-funcionais que descrevem a solução do problema a ser resolvido é estabelecido a partir das necessidades, expectativas, restrições e requisitos do cliente e da interface ;
DRE 3. Os requisitos do cliente são refinados, elaborados e alocados para o desenvolvimento dos requisitos do produto e dos componentes do produto;
DRE 4. Conceitos operacionais e cenários são desenvolvidos;
DRE 5. A definição das funcionalidades requeridas é desenvolvida e mantida;
DRE 6. Os requisitos são analisados para assegurar que são necessários e suficientes e para balancear as necessidades dos interessados com as restrições existentes;
DRE 7. Os requisitos são validados.

4.2. Processo: Integração do Produto – ITP

Nível MR-MPS: D - Largamente Definido
Propósito:
O propósito do processo Integração do Produto é compor os componentes do produto, produzindo um produto integrado consistente com o projeto (design), demonstrar que os requisitos funcionais e não-funcionais são satisfeitos para o ambiente alvo ou equivalente.



Resultados esperados:
ITP 1. Uma estratégia de integração, consistente com o projeto (design) e com os requisitos do produto, é desenvolvida para os componentes do produto. Esta estratégia deve determinar os componentes do produto que serão integrados e a seqüência de integração dos componentes;
ITP 2. Um ambiente para integração dos componentes do produto é estabelecido e mantido;
ITP 3. A compatibilidade das interfaces internas e externas dos componentes do produto é assegurada;
ITP 4. As definições, projeto e mudanças nas interfaces internas e externas são gerenciados para os componentes dos produtos e produtos;
ITP 5. Cada componente do produto é verificado, utilizando-se critérios definidos, para confirmar que os mesmos estão prontos para a integração;
ITP 6. Os componentes do produto são integrados, de acordo com a seqüência determinada e seguindo os procedimentos e critérios para integração;
ITP 7. Os componentes do produto integrados são avaliados e os resultados da integração são registrados;
ITP 8. Uma estratégia de regressão é desenvolvida e aplicada para uma nova verificação do produto quando ocorre uma mudança nos componentes do produto (incluindo requisitos, projeto e códigos associados);
ITP 9. O produto e a documentação relacionada são preparados e entregues ao cliente.

4.3. Processo: Solução Técnica – STE

Nível MR-MPS: D – Largamente Definido
Propósito:
O propósito do processo Solução Técnica é projetar, desenvolver e implementar soluções para atender aos requisitos.



Resultados esperados:
STE 1. Alternativas de solução para atender aos requisitos definidos são desenvolvidas de acordo com critérios identificados;
STE 2. Soluções são selecionadas para o produto ou componentes do produto com base em cenários definidos e em critérios identificados;
STE 3. O produto ou componente do produto é projetado e documentado;
STE 4. As interfaces entre os componentes do produto são projetadas com base em critérios predefinidos;
STE 5. Uma análise dos componentes do produto é conduzida para decidir sobre sua construção, compra ou reuso;
STE 6. Os componentes do produto e a sua documentação associada são implementados e verificados de acordo com o projeto;
STE 7. A documentação é identificada, desenvolvida e disponibilizada de acordo com os padrões identificados;
STE 8. A documentação é mantida de acordo com os critérios definidos.

4.4. Processo: Validação – VAL

Nível MR-MPS: D - Largamente Definido
Propósito:
O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.
Resultados esperados:
VAL 1. Produtos de trabalho a serem validados são identificados;
VAL 2. Uma estratégia de validação é desenvolvida e implementada estabelecendo cronograma, participantes envolvidos, métodos para validação e qualquer material a ser utilizado na validação;
VAL 3. Critérios para validação dos produtos de trabalho a serem validados são identificados e um ambiente para validação é estabelecido;
VAL 5. Problemas são identificados, registrados e ações corretivas são realizadas;
VAL 6. Evidências de que os produtos de software desenvolvidos estão prontos para o uso pretendido são fornecidas;
VAL 7. Resultados de atividades de validação são analisados e disponibilizados para os interessados.

4.5. Processo: Verificação – VER

Nível MR-MPS: D - Largamente Definido
Propósito:
O propósito do processo Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto reflete apropriadamente os requisitos especificados.



Resultados esperados:
VER 1. Produtos de trabalho a serem verificados são identificados;
VER 2. Uma estratégia de verificação é desenvolvida e implementada estabelecendo cronograma, revisores envolvidos, métodos para verificação e qualquer material a ser utilizado na verificação;
VER 3. Critérios para verificação dos produtos de trabalho a serem verificados são identificados e um ambiente para verificação é estabelecido;
VER 4. Atividades de verificação, incluindo testes e revisões por pares, são executadas;
VER 5. Defeitos são identificados, registrados e ações corretivas são realizadas.
VER 6. Resultados de atividades de verificação são analisados e disponibilizados para os interessados.



O nível de maturidade C é composto pelos processos dos níveis - de maturidade anteriores (G ao D), acrescidos dos processos Análise de Decisão e Resolução e Gerência de Riscos. Todos os processos devem satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.

5.1. Processo: Análise de Decisão e Resolução – ADR

Nível MR-MPS: C - Definido
Propósito:
O propósito do processo Análise de Decisão e Resolução é analisar possíveis decisões usando um processo formal da avaliação das alternativas identificadas em relação a critérios estabelecidos.



Resultados esperados:
ADR 1. O problema ou questão a ser objeto de um processo formal de tomada de decisão é definido;
ADR 2. Guias para a análise de decisão são estabelecidos e mantidos;
ADR 3. Alternativas de solução aceitáveis para o problema ou questão são identificadas;
ADR 4. Critérios para avaliação das alternativas de solução são estabelecidos e mantidos em ordem de importância de forma que os critérios mais importantes exerçam mais influência na avaliação;
ADR 5. Os métodos de avaliação das alternativas de solução são selecionados de acordo com sua viabilidade de aplicação;
ADR 6. Soluções alternativas são avaliadas usando os critérios e métodos estabelecidos;
ADR 7. Decisões são baseadas na avaliação das alternativas utilizando os critérios de avaliação estabelecidos.

5.2. Processo: Gerência de Riscos – GRI

Nível MR-MPS: C - Definido
Propósito:
O propósito do processo Gerência de Riscos é identificar, gerenciar e reduzir continuamente os riscos em nível organizacional e de projeto.



Resultados esperados:
GRI 1. O escopo da gerência de riscos é determinado;
GRI 2. As origens e as categorias de riscos são determinadas, os parâmetros usados para quantificação da probabilidade e severidade são definidos e as ameaças e suas fronteiras para cada categoria de risco são definidas;
GRI 3. Estratégias apropriadas para a gerência de riscos são definidas e implementadas;
GRI 4. Os riscos do projeto são identificados e documentados incluindo seu contexto, condições e possíveis conseqüências para o projeto e as partes que serão afetadas;
GRI 5. Os riscos são priorizados, estimados e classificados de acordo com as categorias e os parâmetros definidos;
GRI 6. Planos para a mitigação de riscos são desenvolvidos.
GRI 7. Os riscos são analisados e a prioridade de aplicação dos recursos para o monitoramento desses riscos é determinada;
GRI 8. A situação de cada risco é periodicamente monitorada e o plano de mitigação de riscos é implementado quando apropriado;
GRI 9. As medições de desempenho nas atividades de tratamento de risco são coletadas;
GRI 10. Ações apropriadas são executadas para corrigir ou evitar o impacto dos riscos.



Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C), acrescidos dos processos Desempenho do Processo Organizacional e Gerência Quantitativa do Projeto. Todos os processos devem satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.

6.1. Processo: Desempenho do Processo Organizacional – DEP

Nível MR-MPS: B – Gerenciado Quantitativamente
Propósito:
O propósito do processo Desempenho do Processo Organizacional é estabelecer e manter um entendimento quantitativo do desempenho dos processos-padrão da organização para apoiar os objetivos para qualidade e para o desempenho dos processos. Também é propósito deste processo fornecer dados, linhas básicas
(baselines) e modelos para gerenciar quantitativamente os projetos da organização.



Resultados esperados:
DEP 1. A partir do conjunto de processos-padrão da organização, são selecionados os processos e/ou elementos de processos que serão objeto de análise de desempenho;
DEP 2. Medidas para análise do desempenho dos processos da organização são estabelecidas e mantidas;
DEP 3. Objetivos quantitativos para qualidade e para o desempenho dos processos da organização são definidos e mantidos;
DEP 4. Linhas bases (baselines) de desempenho dos processos da organização são estabelecidas;
DEP 5. Modelos de desempenho do processo para o conjunto do processos padrão da organização são estabelecidos e mantidos.

6.2. Processo: Gerência Quantitativa do Projeto – GQP

Nível MR-MPS: B – Gerenciado Quantitativamente
Propósito:
O propósito do processo Gerência Quantitativa do Projeto é gerenciar quantitativamente o processo definido para o projeto de forma a alcançar os objetivos para qualidade e para o desempenho do processo estabelecidos para o projeto.

Resultados esperados:
GQP 1. Os objetivos para qualidade e para o desempenho do processo para o projeto são estabelecidos e mantidos;
GQP 2. Os sub-processos mais adequados para compor o processo definido para o projeto são selecionados com base na estabilidade histórica, em dados de capacidade e em critérios previamente estabelecidos;
GQP 3. Sub-processos do processo definido para o projeto e que serão gerenciados estatisticamente são escolhidos a partir de critérios previamente estabelecidos;
GQP 4. O projeto é monitorado para determinar se seus objetivos para qualidade e para o desempenho do processo serão atingidos e ações corretivas são identificadas quando necessário;
GQP 5. Medidas e técnicas de análise para gerenciar estatisticamente os subprocessos escolhidos são selecionadas;
GQP 6. O entendimento da variação dos sub-processos escolhidos para gerência quantitativa , utilizando as medidas e técnicas de análise selecionadas, é estabelecido e mantido;
GQP 7. O desempenho dos sub-processos escolhidos para gerência quantitativa é monitorado para determinar a sua capacidade de satisfazer os seus objetivos para qualidade e para o desempenho e ações são identificadas quando for necessário tratar deficiências dos sub-processos;
GQP 8. Dados estatísticos e de gerência da qualidade são incorporados ao repositório de medidas da organização.



Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B), acrescidos dos processos Implantação de Inovações na Organização e Análise e Resolução de Causas. Todos os processos devem satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2.

7.1. Processo: Implantação de Inovações na Organização – IIO

Nível MR-MPS: A – Em Otimização
Propósito:
O propósito do processo Implantação de Inovações na Organização é selecionar e implantar melhorias incrementais e inovadoras que, de forma mensurada, melhorem os processos e as tecnologias da organização. As melhorias implantadas apóiam os objetivos de qualidade e de desempenho dos processos da organização, que são derivados de seus objetivos de negócio.

Resultados esperados:
IIO 1. Propostas de melhoria do processo e de melhoria tecnológica são coletadas e analisadas;
IIO 2. As melhorias inovadoras que aumentem a qualidade da organização e o desempenho do seu processo são identificadas e analisadas;
IIO 3. Projetos-piloto são planejados e realizados para identificar as melhorias no processo e as melhorias tecnológicas que serão implementadas;
IIO 4. As propostas de melhoria no processo e de melhorias tecnológicas são selecionadas com base em critérios quantificáveis definidos a partir dos objetivos de qualidade e de desempenho do processo da organização;
IIO 5. Os planos para a implantação das melhorias no processo e das melhorias tecnológicas selecionadas são estabelecidos e mantidos;
IIO 6. A implantação das melhorias no processo e das melhorias tecnológicas é realizada e gerenciada a partir dos planos;
IIO 7. Os efeitos resultantes da implantação das melhorias no processo e das melhorias tecnológicas são medidos e documentados.

7.2. Processo: Análise de Causas e Resolução – ARC

Nível MR-MPS: A – Em Otimização
Propósito:
O propósito do processo Análise de Causas e Resolução é identificar causas de defeitos e de outros problemas e tomar ações para prevenir suas ocorrências no futuro.

Resultados esperados:
ARC 1. Dados de defeitos e de outros problemas são selecionados para análise;
ARC 2. A análise da causa de defeitos e de outros problemas selecionados é realizada com as pessoas responsáveis por realizar a tarefa para identificar a sua raiz;
ARC 3. Ações necessárias para evitar a ocorrência futura de defeitos e outros problemas similares aos selecionados são propostas e documentadas;
ARC 4. Ações propostas e documentadas que foram desenvolvidas durante a análise da causa e que possuem uma relação custo/benefício satisfatória são implementadas para remover as causas dos defeitos e dos problemas analisados e evitar ocorrências futuras;
ARC 5. O efeito das mudanças no desempenho dos processos é medido e avaliado para obter evidência de que as mudanças nos processos corrigiram o problema e melhoraram o desempenho;
ARC 6. Dados da análise de causas e resolução são armazenados para que outros projetos e organizações possam realizar mudanças apropriadas nos processos e alcançar resultados similares.


INSTITUIÇÕES IMPLEMENTADORAS (II)

Uma implementação do MR-MPS pode ser conduzida por uma Instituição Implementadora (II) credenciada pela SOFTEX conforme parecer do Fórum de Credenciamento e Controle (FCC).
Para solicitar o seu credenciamento, as instituições proponentes devem cumprir os seguintes requisitos institucionais:




⇒possuir uma estratégia de implementação do Modelo de Referência MRMPS;
⇒possuir uma estratégia de seleção, capacitação e manutenção da competência dos membros da equipe de Implementação do MPS.BR; e,
⇒ter vinculados à mesma, no mínimo, 3 (três) profissionais aprovados na Prova de Introdução (P1-MPS.BR) e Prova para Implementadores (P2- MPS.BR), sendo que um deve ser o coordenador da equipe.
Após análise do documento e parecer favorável do Fórum de Credenciamento e Controle (FCC), a SOFTEX assina um Termo de Convênio com a Instituição Implementadora (II) para seu credenciamento por um período de 2 anos.



BIBLIOGRAFIA BÁSICA
⇒KOSCIANSKI, André. Qualidade de Software. São Paulo: Novatec Editora, 2007.
⇒PRESSMAN,  Roger S.. Engenharia de software. São Paulo: Makron Books, 2006.
⇒SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2007

BIBLIOGRAFIA COMPLEMENTAR
⇒PALADINI, Edson Pacheco. Gestão da qualidade: Teoria e casos. Campus, 2006.

BIBLIOGRAFIA RECOMENDADA
[ABNT, 1998] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS.
NBR ISO/IEC 12207 – Tecnologia de informação - Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998, 35 p.

[ABNT, 2000] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS.
NBR ISO 9000:2000 – Sistemas de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2000.

[BUSH e DUNAWAY, 2005] Bush, Marilyn and Dunaway, Donna. CMMI Assessments: Motivating Positive Change. The SEI Series in Software Engineering. Pearson Education, Inc. 2005.

[ISO/IEC 12207:1995/Amd 1:2002] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 1 to ISO/IEC 12207, Geneve: ISO, 2001.

[ISO/IEC 12207:1995/Amd 2:2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 2 to ISO/IEC 12207, Geneve: ISO, 2004.

[ISO/IEC 12207:1995] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Information technology – Software life cycle processes, Geneve: ISO, 1995.

[ISO/IEC 15504-1, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-1: Information Technology - Process Assessment – Part 1 - Concepts and Vocabulary, Geneve: ISO, 2004.

[ISO/IEC 15504-2, 2003] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-2: Information Technology - Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO, 2003.

[ISO/IEC 15504-3, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-3: Information Technology - Process Assessment - Part 3 Guidance on Performing an Assessment, Geneve: ISO, 2004.

[ISO/IEC 15504-4, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-4: Information Technology - Process Assessment – Part 4 -Guidance on use for Process Improvement and Process Capability Determination, Geneve: ISO, 2004.

[ISO/IEC 15504-5, 2006] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-5: Information Technology - Process Assessment - Part 5: An exemplar Process Assessment Model, Geneve: ISO, 2006.

[ISO/IEC 15939, 2002] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15939: Software Engineering – Software Measurement Process, Geneve: ISO, 2002.

[MPS.BR, 2006a] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Avaliação, versão 1.0, maio 2006. Disponível em: http://www.softex.br/.

[MPS.BR, 2006b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Aquisição, versão 1.1, maio 2006. Disponível em: http://www.softex.br/.

[NBR ISO/IEC 12207] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207:1998. Tecnologia da Informação – Processos de Ciclo de Vida do Software. Rio de Janeiro: ABNT, 1998.

[PMI, 2004] - PROJECT MANAGEMENT INSTITUTE - PMI. A guide to the project management body of knowledge. Syba: PMI Publishing Division, 2004. Disponível em: .

[SEI, 2002] - SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Systems Engineering/Software Engineering (CMMI-SE/SW), Staged Representation, Version 1.1, Technical report CMU/SEI-2002-TR-02.

Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.




QABI Consultoria e Oz InSite - Desenvolvimento Web
Compartilhar no Facebook:
Compartilhar no Linkedin:

MPS.BR




O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).

A coordenação do Programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Através destas estruturas, o MPS.BR obtém a participação de representantes de Universidades, Instituições Governamentais, Centros de Pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento.

O FCC tem como principais objetivos assegurar que as Instituições Implementadoras (II) e Instituições Avaliadoras (IA) sejam submetidas a um processo adequado de credenciamento e que suas atuações não se afastem dos limites éticos e de qualidade esperados, além de avaliar e atuar sobre o controle dos resultados obtidos pelo MPS.BR. Por outro lado, cabe a ETM atuar sobre os aspectos técnicos relacionados ao Modelo de Referência (MR-MPS) e Método de Avaliação (MA-MPS), tais como a concepção e evolução do modelo, elaboração e atualização dos Guias do MPS.BR, preparação de material e definição da forma de treinamento e de aplicação de provas, publicação de Relatórios Técnicos e interação com a comunidade visando a identificação e aplicação de melhores práticas.
A criação e o aprimoramento deste Guia Geral são atribuições da ETM, sendo que este guia faz parte do seguinte conjunto de documentos de apoio ao MPS.BR:

Guia Geral;
Guia de Avaliação [MPS.BR, 2006a]; e
Guia de Aquisição [MPS.BR, 2006b].

Este Guia de Geral do MPS.BR descreve de forma detalhada o Modelo de Referência MRMPS e fornece uma visão geral sobre os demais guias que apóiam os processos de avaliação e de aquisição. Este guia tem como referência a Norma Internacional ISO/IEC 12207:1995/Amd 1:2002 e Amd 2:2004, a ISO/IEC 15504 e o modelo CMMI-SE/SWSM 2 (Capability Maturity Model Integration). O detalhamento do Guia Geral envolve a definição dos níveis de maturidade, seus processos e capacidade, além dos resultados esperados provendo uma estrutura de trabalho para uma instituição que deseje implementar o MR-MPS.

Esta versão do Guia Geral contempla as seguintes modificações em relação à versão 1.0:

correção da ortografia e reestruturação do documento ;
inclusão e atualização de itens no glossário;
adequação das referências; e,
melhoria da definição de alguns resultados de processo e resultados de atributos de processo, com o intuito de facilitar o entendimento e aplicabilidade do Modelo de Referência MR-MPS.BR.




INTRODUÇÃO


As mudanças que estão ocorrendo nos ambientes de negócios têm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento de conexões nestas redes, criando elos essenciais nas cadeias produtivas. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software.Desta forma, assim como para outros setores, qualidade é fator crítico de sucesso para a indústria de software. Para que o Brasil tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando a oferta de produtos de software e serviços correlatos conforme padrões internacionais de qualidade.

Em 2003, no início da concepção do MPS.BR, dados da Secretaria de Política de Informática e Tecnologia do Ministério da Ciência e Tecnologia (MCT/SEITEC), mostravam que apenas 30 empresas no Brasil possuíam avaliação SW-CMM®3 (Capability Maturity Model): 24 no nível 2; 5 no nível 3; 1 no nível 4; e nenhuma no nível 5. Observando-se esta pirâmide pôde-se concluir que a qualidade do processo de software no Brasil podia ser dividida em dois tipos de empresas. No topo da pirâmide, normalmente, estavam as empresas exportadoras de software e outras grandes empresas que desejavam atingir níveis mais altos de maturidade (4 ou 5) do CMMI-SE/SWSM por estágio e serem formalmente avaliadas pelo SEI (Software Engineering Institute), em um esforço que pode levar de 4 a 10 anos. Na base da pirâmide, em geral, encontrava-se a grande massa de micro, pequenas e médias empresas de software brasileiras, com poucos recursos e que necessitam obter melhorarias significativas nos seus processos de software em 1 ou 2 anos.

O foco principal do MPS.BR, embora não exclusivo, está neste segundo grupo de empresas. Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também espera-se que o MPS.BR seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software.

O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Dentro desse contexto, o MPS.BR possui três componentes: Modelo de Referência (MR-MPS4), Método de Avaliação (MA-MPS4) e Modelo de Negócio (MNMPS4) descritos na seção 6 - Descrição geral do MPS.BR .

O MPS.BR está descrito através de documentos em formato de guias:

Guia Geral: contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação.
Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS.
Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líder, avaliadores adjuntos e Instituições Avaliadoras (IA).



Uma das metas do MPS.BR visa definir e aprimorar 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. O 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.

A base técnica para a construção e aprimoramento deste modelo de melhoria e avaliação de processo de software é composta pelas normas NBR ISO/IEC 12207 – Processo de Ciclo de Vida de Software, pelas emendas 1 e 2 da norma internacional ISO/IEC 12207 e pela ISO/IEC 15504 – Avaliação de Processo (também conhecida por SPICE: Software Process Improvement and Capability dEtermination), portanto, o modelo está em conformidade com essas normas. Este modelo também cobre o conteúdo do CMMI-SE/SWSM, através da inclusão de processos e resulta esperados além dos estabelecidos na Norma ISO/IEC 12207. A base técnica deste modelo é apresentada em maiores detalhes na seção 7 deste documento.

O programa mobilizador MPS.BR está dividido em três (3) componentes (Figura 1):

Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de Guias e/ou de Documentos do MPS.BR.


Figura 1 – Componentes do MPS.BR


O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MRMPS. Ele contém as definições dos níveis de maturidade, processos e atributos do processo, e está descrito neste Guia Geral, na seção 8.

Adicionalmente, o Guia de Aquisição é um documento complementar destinado a organizações que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém requisitos do MR-MPS, mas boas práticas para a aquisição de software e serviços correlatos.

O Guia de Avaliação contém o processo e o método de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA).

O processo e o método de avaliação MA-MPS está em conformidade com a norma ISO/IEC 15504-2 [ISO/IEC 15504-2, 2003].

O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de empresas para implementação do MR-MPS e avaliação MA-MPS pelas Instituições Organizadoras de Grupos de Empresas (IOGE), certificação de consultores de aquisição e programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR. Um resumo executivo dessas regras de negócio está disponível no Portal SOFTEX.



O Modelo de Referência MR-MPS define níveis de maturidade que são uma combinação entre processos e sua capacidade. A definição dos processos segue a forma apresentada na Emenda 1 da ISO/IEC 12207, declarando o propósito e os resultados esperados de sua execução. Isso permite avaliar e atribuir graus de efetividade na execução dos processos. As atividades e tarefas necessárias para atender ao propósito e aos resultados esperados não são definidas neste guia, devendo ficar a cargo dos usuários do MR-MPS.

A capacidade do processo é a caracterização da habilidade do processo para alcançar os objetivos de negócio, atuais e futuros; estando relacionada com o atendimento aos atributos de processo associados aos processos de cada nível de maturidade.


Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade:
A (Em Otimização);
B (Gerenciado Quantitativamente);
C (Definido);
D (Largamente Definido);
E (Parcialmente Definido);
F (Gerenciado); e
G (Parcialmente Gerenciado).

A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível.

A divisão em estágios, embora baseada nos níveis de maturidade do CMMISE/SWSM tem uma graduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais adequada às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos.



Os processos no MR-MPS são descritos em termos de propósito, resultados e informações adicionais e estão detalhados na seção 9. O propósito descreve o objetivo geral a ser atingido durante a execução do processo.

Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um artefato produzido ou uma mudança significativa de estado ao se executar o processo.
As informações adicionais são referências que podem ajudar na definição do processo pela organização. Normalmente, elas citam o processo ou sub-processo da NBR ISO/IEC 12207 e a área de processo do CMMI-SE/SWSM que estão relacionados ao processo do MR-MPS. Estas referências fornecem descrições de atividades, tarefas e melhores práticas que podem apoiar a definição e implementação do processo nas organizações.

Os processos são agrupados, por uma questão de organização, de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em três (3) classes de processos, que são:

Processos fundamentais - atendem o início e a execução do desenvolvimento, operação ou manutenção dos produtos de software e serviços correlatos durante o ciclo de vida de software;
Processos de apoio - auxiliam um outro processo e contribuem para o sucesso e qualidade do projeto de software;
Processos organizacionais - uma organização pode empregar estes processos em nível corporativo para estabelecer, implementar e melhorar um processo do ciclo de vida.

Os processos que compõem o MR-MPS são os descritos na Figura 2.


Figura 2 - Processos do MR-MPS



A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização. No MPS, à medida que a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização.

O atendimento aos atributos do processo (AP), através do atendimento aos resultados esperados dos atributos do processo (RAP) é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G).
Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. A capacidade do processo no MPS possui cinco (5) atributos de processos (AP) que são: AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2. Cada AP está detalhado em termos de resultados esperados do atributo de processo (RAP) para alcance completo do atributo de processo, conforme definido a seguir:


AP 1.1 O processo é executado
Este atributo é uma medida da extensão na qual o processo atinge o seu propósito.
Resultado esperado:
RAP1. O processo atinge seus resultados definidos.


AP 2.1 O processo é gerenciado
Este atributo é uma medida da extensão na qual 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 para atender aos planos;
RAP 4 (a partir do Nível F). Medidas são planejadas e coletadas para monitoração da execução do processo;
RAP 5. Os recursos necessários para a execução do processo são identificados e disponibilizados;
RAP 6. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência;
RAP 7. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto;
RAP 8. O estado, atividades e resultados do processo são revistos com os níveis adequados de gerência (incluindo a gerência de alto nível) e problemas pertinentes são tratados.

O RAP 4 tem exigências diferentes para o Nível G e para os níveis posteriores.


AP 2.2 Os produtos de trabalho do processo são gerenciados
Este atributo é uma medida da extensão na qual os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente.
Resultado esperado:
RAP 9. Os produtos de trabalho são documentados, revistos e controlados em níveis apropriados de gerência de configuração.


AP 3.1. O processo é definido
Este atributo é uma medida da extensão na qual um processo-padrão é mantido para apoiar a implementação do processo definido.
Resultados esperados:
RAP 10. Um processo padrão é definido, incluindo diretrizes para sua adaptação para o processo definido;
RAP 11. A seqüência e interação do processo-padrão com outros processos são determinadas;


AP 3.2 O processo está implementado
Este atributo é uma medida da extensão na qual o processo-padrão é efetivamente implementado como um processo definido para atingir seus resultados.
Resultado esperado:
RAP 12. Dados apropriados são coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo.
A Tabela 1 apresenta os níveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nível.

Tabela 1 - Níveis de maturidade do MR-MPS




BIBLIOGRAFIA BÁSICA
⇒ KOSCIANSKI, André. Qualidade de Software. São Paulo: Novatec Editora, 2007.
⇒ PRESSMAN, Roger S.. Engenharia de software. São Paulo: Makron Books, 2006.
⇒ SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2007



BIBLIOGRAFIA COMPLEMENTAR
⇒ PALADINI, Edson Pacheco. Gestão da qualidade: Teoria e casos. Campus, 2006.


BIBLIOGRAFIA RECOMENDADA

[ABNT, 1998] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207 – Tecnologia de informação - Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998, 35 p.

[ABNT, 2000] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000:2000 – Sistemas de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2000.

[BUSH e DUNAWAY, 2005] Bush, Marilyn and Dunaway, Donna. CMMI Assessments: Motivating Positive Change. The SEI Series in Software Engineering. Pearson Education, Inc. 2005.

[ISO/IEC 12207:1995/Amd 1:2002] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 1 to ISO/IEC 12207, Geneve: ISO, 2001.

[ISO/IEC 12207:1995/Amd 2:2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 2 to ISO/IEC 12207, Geneve: ISO, 2004.

[ISO/IEC 12207:1995] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Information technology – Software life cycle processes, Geneve: ISO, 1995.

[ISO/IEC 15504-1, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-1: Information Technology - Process Assessment – Part 1 - Concepts and Vocabulary, Geneve: ISO, 2004.

[ISO/IEC 15504-2, 2003] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-2: Information Technology - Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO, 2003.

[ISO/IEC 15504-3, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-3: Information Technology - Process Assessment - Part 3 - Guidance on Performing an Assessment, Geneve: ISO, 2004.

[ISO/IEC 15504-4, 2004] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-4: Information Technology - Process Assessment – Part 4 - Guidance on use for Process Improvement and Process Capability Determination, Geneve: ISO, 2004.

[ISO/IEC 15504-5, 2006] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15504-5: Information Technology - Process Assessment - Part 5: An exemplar Process Assessment Model, Geneve: ISO, 2006.

[ISO/IEC 15939, 2002] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 15939: Software Engineering – Software Measurement Process, Geneve: ISO, 2002.

[MPS.BR, 2006a] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Avaliação, versão 1.0, maio 2006. Disponível em: www.softex.br.

[MPS.BR, 2006b] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Aquisição, versão 1.1, maio 2006. Disponível em: www.softex.br.

[NBR ISO/IEC 12207] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207:1998. Tecnologia da Informação – Processos de Ciclo de Vida do Software. Rio de Janeiro: ABNT, 1998.

[PMI, 2004] - PROJECT MANAGEMENT INSTITUTE - PMI. A guide to the project management body of knowledge. Syba: PMI Publishing Division, 2004. Disponível em: .

[SEI, 2002] - SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Systems Engineering/Software Engineering (CMMI-SE/SW), Staged Representation, Version 1.1, Technical report CMU/SEI-2002-TR-02. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.



QABI Consultoria e Oz InSite - Desenvolvimento Web
Compartilhar no Facebook:
Compartilhar no Linkedin: