Processos Baseados em Planejamento - PUC-Rioinf2135/docs/INF2135-Modulo07... · – PMBOK –Project Management Book of Knowledge – ITIL –Information Technology Infrastructure

1

Processos Baseados em Planejamento

Arndt von Staa

Departamento de Informática

PUC-Rio

Maio 2014

Mai 2014 2Arndt von Staa © LES/DI/PUC-Rio

O que realmente interessa

We should not be debating

process versus commitment;

we should be debating

competence versus incompetence.

Steve McConnell; Cargo Cult Software Engineering;

IEEE Software 17(2); March/April 2000; pags 11-13

2


Princípio “rigoroso”

“SAY1 WHAT YOU DO;

DO WHAT YOU SAY”

1 – leia-se: document


Terminologia – 1 / 4

• CMM - Capability maturity model

– modelo da maturidade da capacitação

• Organização

– empresa, divisão, ou mesmo um grupo que desenvolve sistemas (ou artefatos) intensivos em software

• Projeto

– empreendimento com início e fim, que visa disponibilizar ou realizar uma mudança em um artefato, e que consome recursos limitados

– um projeto nunca é recorrente

3



• Artefato (work product)

– item disponível e que satisfaz requisitos de qualidade de serviço e de engenharia estabelecidos

• Produto

– artefato a ser entregue ao cliente ou usuário

• Cliente

– pessoa ou organização que tem interesse em dispor de um sistema (produto) e disponibiliza recursos para tal

• Usuário

– pessoa (ou artefato) que utiliza, opera, desenvolve, mantém, ou instala um artefato (produto), esperando receber um serviço que atenda (adequado, fidedigno) às necessidades e expectativas desta pessoa (ou artefato)

• exemplo de artefato usuário: sistema de software embarcado



• Processo

– conjunto de atividades (práticas) que visam atingir uma ou mais metas estabelecidas

• Área (chave) de processo

– é um conjunto de práticas que, quando realizadas coletivamente, conduzem ao alcance de um ou mais objetivos (meta, goal) desejados

– uma área de processo pode ser entendida como um subprocesso

• Práticas (chave) da área do processo

– descrições de atividades, estabelecendo as pré e pós condições (insumos e resultados) para a sua realização, bem como as condições de disparo (trigger) de seu início

– vinculadas a áreas de processo

4



• Institucionalização, atuar para que

– as práticas estejam claramente documentadas

– sejam realizadas regularmente tal como escritas

– sejam efetivas – resolvem o problema em questão

– sejam duradouras

• desenvolvedores podem ser treinados

• ninguém cai na tentação de voltar a um status quo anterior

• Gerência do processo

– estabelecer, institucionalizar, observar, aprimorar os processos

• Gerência do projeto (desenvolvimento)

– planejar segundo as diretrizes do processo

– desenvolver e acompanhar segundo o plano e as diretrizes do processo

– observar pontos fracos do processo e das ferramentas


Resultados esperados – 1 / 5

• Melhoria da previsibilidade

– à medida que aumenta a capacitação, diminui a divergência entre o planejado (esperado) e o realizado

• custo

• tempo

• qualidade do serviço entregue– satisfação do usuário e do cliente

• qualidade de engenharia

5



• Melhoria do controle de execução do projeto

– a entrega de artefatos aprovados passa a ser o indicador confiável de progresso

• reduz o risco da síndrome do “prazo de entrega”– i.e. o trabalho é realizado com o devido afinco somente na proximidade

do prazo de entrega

• desaparece a síndrome dos “90% pronto” ou do “só falta testar”

• combate a síndrome da corrida contra o tempo pouco antes do prazo de entrega – síndrome do aluno ☺

tempo

esforço

instantâneo

prazo

limite da capacidade

realizado???

viável, entre 80 e 90%



• Melhoria da competência individual (wwwwwh ou 5wh)

– cada um – papel – (who) sabe

• (what) o que deve fazer

• (why) por que deve fazer

• (when) quando deve fazer

• (where) onde deve fazer e guardar

• (how) como deve fazer

– com que instrumentos deve fazer

– como será (deverá ser) controlada a qualidade

6



• Melhoria da eficiência dos processos

– à medida que aumenta a capacitação, reduzem-se os custos e tempos em virtude da diminuição de retrabalho inútil

• mas custos totais podem aumentar!

– treinamento, ferramentas, plataformas etc. precisam ser adquiridos

– overhead administrativo tende a crescer

– deve-se sempre considerar o custo total de propriedade (TCO – total cost of ownership)



• Melhoria da eficácia dos processos

– mais qualidade e produtividade a cada novo desenvolvimento

• do serviço

– adequação ao uso

– fidedignidade

• da engenharia

7


Modelos

• Um modelo é uma abstração a partir da qual podem-se avaliar, de forma racional, as propriedades ou o comportamento futuro de reificações (instanciações) em conformidade com o modelo

• Modelos dirigem as reificações

– estabelecem critérios para verificar a adequação e corretude da reificação

• Modelos de processos podem ser entendidos como:

– meta-processos

– frameworks


Visão macro da estrutura de processos

adição das características do artefatoe dos recursos a utilizar

adição da tecnologia e das característicasdo ambiente a utilizar

Meta-processopadrão

Tecnologiaa ser utilizada

Natureza daaplicação

Processodefinido

Especificaçãode requisitos

Recursosdisponíveis

Plano dedesenvolvimento

Desenvolvimentodisciplinado

Insumos Artefatos

Ambiente dedesenvolvimento

Estabelecerambiente

execução segundo o plano

8


Processos baseados em planos

• Lista dos processos baseados em planos mais conhecidos:

– SW-CMM

– CMMI-DEV

– MPS.BR

– ISO/IEC-15504 - SPICE

– Team Software Process

– Personal Software Process

– RUP - Rational Unified Process

– ISO 9000 / 2000



• Outros

– SSE-CMM – Secure Software Engineering CMM

– ITS-CMM – Information Technology Service CMM

– SMMM – Software Maintenance Maturity Model

– TMM – Test Maturity Model

– TMMi – Test Maturity Model Integrated

9



• Outros tipos de abordagem

– PMBOK – Project Management Book of Knowledge

– ITIL – Information Technology Infrastructure Library

– COBIT – Control Objectives for Information and Related Technology

• ISACA - Information Systems Audit and Control Association -international professional association focused on IT Governance

Estrutura geral COBIT


10


Metas de área de processo, exemplo

• Planejar as atividades de gerência de configuração de software

• Identificar, controlar e tornar disponíveis os artefatos de software selecionados (itens de configuração)

• Controlar as alterações nos artefatos de software identificados

• Informar pessoas e grupos envolvidos acerca do estado e do conteúdo das baselines de software.

• (adição minha) Acompanhar a solução dos problemas relacionados com o artefato até a sua conclusão

– relatos de falha, não conformidades, dívidas técnicas

– solicitações de adaptação, melhoria ou evolução

– solicitação de novos artefatos


Exemplo: Prática chave SW-CMM

Exemplo (Área de processo: gerência de configuração)• Prática 1 - Preparar plano de GCS.

• Prática 2 - Executar as atividades de GCS de acordo com o plano de GCS.

• Prática 3 - Estabelecer um repositório para baselines.

• Prática 4 - Identificar itens de configuração.

• Prática 5 - Gerenciar as solicitações de mudanças e os relatórios de problemas para todos os itens de configuração

• Prática 6 - Controlar alterações nas baselines.

• Prática 7 - Controlar a liberação de produtos.

• Prática 8 - Registrar o estado dos itens de configuração.

• Prática 9 - Divulgar as atividades de GCS e o conteúdo das baselines.

• Prática 10 - Conduzir auditorias nas baselines de software.

11


Exemplo: Prática CMMI-DEV

• SP 1.1-1 Identify Configuration Items

• SP 1.2-1 Establish a Configuration Management System

• SP 1.3-1 Create or Release Baselines

• SP 2.1-1 Track Change Requests

• SP 2.2-1 Control Configuration Items

• SP 3.1-1 Establish Configuration Management Records

• SP 3.2-1 Perform Configuration Audits


Clausulas ISO 9001

• Exemplo de cláusula:

• 10 - Inspeção e ensaios (testes)• Estabelecer e manter procedimentos documentados para atividades de ensaio e inspeção, de maneira a verificar se o produto está de acordo com os requisitos publicados.

• Ensaios e inspeções e devem ser realizados tanto para mercadorias recebidas quanto para produtos finais.

• Detalhar no plano da qualidade ou em procedimentos documentados, os testes e inspeções requeridos e os registros a serem feitos.

12


Níveis de maturidade

• Os “CMM like” propõem níveis de maturidade

– a estrutura geral é essencialmente a mesma para todos eles

– cada nível define um conjunto de áreas de processo correlatas– KPA - key process area (CMM)

– PA - process area (todos os outros)

– cada área do processo corresponde a um conjunto de práticas fortemente correlatas

• pode ser entendido como um sub-processo – com um escopo bem delimitado

– focado em um aspecto específico do processo de desenvolvimento


Níveis de maturidade SW-CMM

Gerência de configuração de software

Garantia de qualidade de software

Gerência de contrato de software

Supervisão e acompanhamento de projeto

Planejamento do projeto de software

Gerência de Requisitos

Nível 2 - REPETITÍVEL

Revisão por parceiros

Coordenação entre grupos

Engenharia do produto de software

Gerenciamento integrado de software

Programa de treinamento

Definição do processo organizacional

Foco no processo da organização

Nível 3 - DEFINIDO

Gerência da qualidade de software

Gerência de processos quantitativosNível 4 - GERENCIADO

Gerência de alteração de processo

Gerência de alteração de tecnologia

Prevenção de defeitos

Nível 5 - OTIMIZADO

Nível 1 - INICIAL

13


Níveis de maturidade, expectativa

Nível 1

Nível 2

Nível 3

Nível 4

Nível 5

Estimativa feita

Distribuiçõesda realização


• Um nível somente estará atingido quando todas as áreas do processo deste nível e dos níveis inferiores estiverem implementadas e em uso rotineiro

– Exemplo: Se satisfizer todas as APs de todos os níveis, menos a de gerência de configuração, continua no nível 1!

• Ter atingido um determinado nível de maturidade

– não é por si só um atestado de qualidade

– é somente um indicador da capacitação (habilitação) em atingir metas de qualidade e produtividade

Níveis de maturidade

14


• Pode-se implementar as APs em qualquer ordem

– mas somente evolui de nível em nível à medida que todas as APs do nível tiverem institucionalizadas

• Podem ser adicionadas APs não previstas

– ex.: as cláusulas ISO 9000 não atendidas pelo CMM

• O importante é cada AP estar documentada e em uso rotineiro

Institucionalização – modelo em estágios


Ativos (assets) do processo

• Os PSDP – Processo de Software Definido do Projeto –precisam ser adaptados ao domínio do problema e da tecnologia usada

• Recomenda-se criar ativos do processo reutilizáveis

– descrições de subprocessos

– descrições de ciclos de vida

– descrições de práticas institucionalizadas

• como é praticada

• que ferramentas utiliza

• como inter-relaciona com o resto

– base de dados de processos

– biblioteca de documentação de processos

– base de padrões

– base de ferramentas

15


Organização SW-CMM

Níveis de Maturidade

Áreas chave do processo

Características comuns

Práticas chave

Capacitaçãodo Processo

Metas

Implementação ouInstitucionalização

Infra-estrutura ouAtividades

contêm

organizadas por

contêmdescrevem

indicam

visam

endereçam


SW-CMM - características comuns

• Cada área chave do processo é subdividida nas seguintes características comuns:

– Compromissos

– Habilitações

– Atividades (práticas)

– Medição e análise

– Verificação da implementação

16


• Compromisso, exemplo:

– C1: O projeto segue uma política organizacional documentada para desempenhar as tarefas de engenharia de software



• Habilitações, exemplos:

– H1: Estão disponíveis os recursos e os fundos adequados para desempenhar as tarefas de engenharia de software.

– H2: Os membros do corpo técnico de engenharia de software têm o treinamento necessário para desempenhar suas atribuições.


17


• Atividades, exemplos:

– A1: Integrar métodos e ferramentas de engenharia de software adequados ao PSDP – Processo de Software Definido do Projeto

– A3: Desenvolver, manter, documentar e verificar o design do software, de acordo com o processo de software definido do projeto, de maneira a satisfazer os requisitos do software e estabelecer a estrutura de codificação.



• Medição, exemplos:

– M1: Desenvolver e usar medições para determinar a funcionalidade e qualidade dos artefatos de software

– M2: Desenvolver e usar medições para determinar o estado das atividades de engenharia do artefato de software


18


• Verificação, exemplos:

– V2: Revisar, periodicamente e quando da ocorrência de eventos significativos, as atividades de engenharia do produto de software junto ao gerente de projeto

– V3: O grupo de garantia da qualidade de software revê ou audita as atividades e artefatos, bem como relata seus resultados.




• Produtos Gerenciados e Controlados

– Ferramentas usadas para desenvolver e manter os produtos de software

– Documentação de requisitos de software

– Documentação do design de software

– Código

– Documentação externa

– Planos, procedimentos e casos teste

– Resultados dos testes

– Documentação de rastreamento dos requisitos de software, do design, do código, da documentação externa e dos casos de teste

19


Modelo CMMI em estágios


CMMI Áreas de processo genéricas

• Todas abordam a implementação das práticas e áreas do processo

– Commitment to perform

– Ability to perform

– Directing implementation

– Verifying implementation

20


CMMI Níveis de capacitação

• Level 0 Not-Performed

– There is general failure to perform the base practices in the process.

– There are no easily identifiable work products or outputs of the process.

– Na versão por estágios esse nível não está definido, mas é mencionado.

– Este nível também existe no SPICE: ISO/IEC 15504

• SPICE e CMMI modelo contínuo são muito parecidos



• Level 1 Initial

– processes are usually ad hoc and possibly chaotic

– the organization usually does not provide a stable environment

– success usually depends on the competence of developers

• não depende disso sempre?

21



• Level 2 Managed

– Performance of the base practices in the process is planned and tracked

– Performance according to specified procedures is verified

– Work products conform to specified standards and requirements

– The primary distinction from the Performed-Informally Level is that the performance of the process is planned and managed and progressing towards a well-defined process



• Level 2 Managed

– áreas do processo

• Requirements Management

• Project Planning

• Project Monitoring and Control

• Supplier Agreement Management

• Measurement and Analysis

• Process and Product Quality Assurance

• Configuration Management

22



• Level 3 Defined

– Base practices are performed according to a well-defined process using approved, tailored versions of standard, documented technical processes

– The primary distinction from the Planned-and-Tracked Level is that the process of the Well-Defined Level is planned and managed using an organization-wide standard process



• Level 3 Defined


• Requirements Development

• Technical Solution

• Product Integration

• Verification

• Validation

• Organizational Process Focus

• Organizational Process Definition

• Organizational Training

• Integrated Project Management

• Risk Management

• Decision Analysis and Resolution

Compare com SW-CMM

• Revisão por parceiros

• Coordenação entre grupos

• Engenharia do produto de software

• Gerenciamento integrado de software

• Programa de treinamento

• Definição do processo organizacional

• Foco no processo da organização

23



• Level 4 Quantitatively Managed

– Detailed measures of performance are collected and analyzed.

• This leads to a quantitative understanding of process capability and an improved ability to predict performance

– Performance is objectively managed

– The quality of work products is quantitatively known

– The primary distinction from the Well-Defined Level is that the defined process is quantitatively understood and controlled



• Level 4 Quantitatively Managed


• Organizational Process Performance

• Quantitative Project Management

24



• Level 5 Optimizing

– Quantitative process effectiveness and efficiency goals (targets) for performance are established, based on the business goals of the organization

– Continuous process improvement against these goals is enabled by quantitative feedback from performing the defined processes and from piloting innovative ideas and technologies



• Level 5 Optimizing


• Organizational Innovation and Deployment

• Causal Analysis and Resolution

25


Institucionalização: modelo contínuo


CMMI Contínuo - Níveis

No modelo contínuo cada área de processo pode estar em um dos níveis a seguir:

0 - Incomplete

1 - Performed

2 - Managed

3 - Defined

4 - Quantitatively Managed

5 - Optimizing

26


CMMI Contínuo - Categorias

• As áreas de processo no modelo contínuo são divididas em quatro categorias

– Process Management

• contain the cross-project activities related to defining, planning, resourcing, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes

– Project Management

• contain the project management activities related to planning, monitoring, and controlling the project

– Engineering

• contain the development and maintenance activities that are shared across systems engineering and software engineering disciplines

– Support

• contains activities that support product development and maintenance


CMMI Contínuo

• PROCESS MANAGEMENT, áreas

– Organizational Process Focus

– Organizational Process Definition

– Organizational Training

– Organizational Process Performance

– Organizational Innovation and Deployment

27


CMMI Contínuo

• PROJECT MANAGEMENT, áreas

– Project Planning

– Project Monitoring and Control

– Supplier Agreement Management

– Integrated Project Management

– Risk Management

– Quantitative Project Management


CMMI Contínuo

• ENGINEERING, áreas

– Requirements Management

– Requirements Development

– Technical Solution

– Product Integration

– Verification

– Validation

28


CMMI Contínuo

• SUPPORT, áreas

– Configuration Management

– Process and Product Quality Assurance

– Measurement and Analysis

– Decision Analysis and Resolution

– Causal Analysis and Resolution


CMMI Contínuo - Genérico

• Cada área de processo define objetivos e atividades genéricas:

– GG 1 Achieve Specific Goals

• GP 1.1 Perform Base Practices

29



• GG 2 Institutionalize a Managed Process

– GP 2.1 Establish an Organizational Policy

– GP 2.2 Plan the Process

– GP 2.3 Provide Resources

– GP 2.4 Assign Responsibility

– GP 2.5 Train People

– GP 2.6 Manage Configurations

– GP 2.7 Identify and Involve Relevant Stakeholders

– GP 2.8 Monitor and Control the Process

– GP 2.9 Objectively Evaluate Adherence

– GP 2.10 Review Status with Higher Level Management



• GG 3 Institutionalize a Defined Process

– GP 3.1 Establish a Defined Process

– GP 3.2 Collect Improvement Information

• GG 4 Institutionalize a Quantitatively Managed Process

– GP 4.1 Establish Quantitative Objectives for the Process

– GP 4.2 Stabilize Subprocess Performance

• GG 5 Institutionalize an Optimizing Process

– GP 5.1 Ensure Continuous Process Improvement

30


Process Management

• Organizational Process Focus

• Organizational Process Definition

• Organizational Training

• Organizational Process Performance

• Organizational Innovation and Deployment


Organizational Process Focus

• Purpose

– The purpose of Organizational Process Focus is to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.

31


Organizational process assets

• Process assets are artifacts that relate to describing, implementing, and improving processes, for example:

– policies

– measurements

– process descriptions

– process implementation support tools

• These artifacts represent investments by the organization that are expected to provide current and future business value

• Process assets: ativos do processo, recursos no domínio de processos que podem ser utilizados para produzir bens (i.e. artefatos).



• The organization's processes include

– the organization's set of standard processes

– the defined processes that are tailored from them

• The organizational process assets are used to establish, maintain, implement, and improve the defined processes

• Candidate improvements to the organizational process assets are obtained from various sources

– measurement of the processes

– lessons learned in implementing the processes

– results of process appraisals

– results of product evaluation activities

– results of benchmarking against other organizations' processes

– recommendations from other improvement initiatives in the organization

32



• Process improvement occurs within the context of the organization’s needs and is used to address the organization's objectives.

• The organization encourages participation in process-improvement activities by those who will perform the process.

• The responsibility for facilitating and managing the organization's process-improvement activities, including coordinating the participation of others, is typically assigned to a process group.

• The organization provides the long-term commitment and resources required to sponsor this group.



• Process action plans usually result from appraisals and document how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented

• In cases in which it is determined that the improvement described in the process action plan should be tested on a small group before deploying it across the organization, a pilot plan is generated

• Finally, when the improvement is to be deployed, a deployment plan is used

– describes when and how the improvement will be deployed across the organization

33



• Careful planning is required to ensure that process-improvement efforts across the organization are adequately managed and implemented.

• The organization’s planning for process-improvement results in a process-improvement plan addressing

– appraisal planning

– process action planning

– pilot planning

– and deployment planning



• Organizational process assets include the following:

– Organization’s set of standard processes,

• process architectures

• process elements

– Descriptions of life-cycle models approved for use

– Guidelines and criteria for tailoring the organization’s set of standard processes

– Organization’s measurement repository

– Organization’s process performance baselines

– Organization’s process performance models

34



• Organizational process assets include the following (contd.):

– Organization’s process asset library

• policies

• defined processes

• checklists

• lessons-learned documents

• templates

• standards

• procedures

• plans

• training materials



• Appraisal plans describe

– appraisal timeline and schedule

– scope of the appraisal

– resources required to perform the appraisal

– reference model against which the appraisal will be performed

– logistics for the appraisal

35



• Specific goals

– SG 1 Determine Process-Improvement Opportunities

• Strengths, weaknesses, and improvement opportunities for the organization's processes are identified periodically and as needed

– SG 2 Plan and Implement Process-Improvement Activities

• Improvements are planned and implemented, organizational process assets are deployed, and process-related experiences are incorporated into the organizational process assets



• Practice-to-Goal Relationship Table

– SG 1 Determine Process-Improvement Opportunities

• SP 1.1-1 Establish Organizational Process Needs

• SP 1.2-1 Appraise the Organization’s Processes

• SP 1.3-1 Identify the Organization's Process Improvements

– SG 2 Plan and Implement Process-Improvement Activities

• SP 2.1-1 Establish Process Action Plans

• SP 2.2-1 Implement Process Action Plans

• SP 2.3-1 Deploy Organizational Process Assets

• SP 2.4-1 Incorporate Process-Related Experiences into the Organizational Process Assets

36




– Typical Work Products• Analysis of candidate process improvements

• Identification of improvements for the organization's processes

– Subpractices• Determine candidate process improvements. Candidate process

improvements are typically determined by doing the following– Measure the processes and analyze the measurement results

– Review the processes for effectiveness and suitability

– Review the lessons learned from tailoring the organization’s set of standard processes

– Review the lessons learned from implementing the processes

– Review process-improvement proposals submitted by the organization's managers and staff, and other relevant stakeholders

– Solicit inputs on process improvements from the senior management and leaders in the organization

– Examine the results of process appraisals and other process-related reviews

– Review results of other organization improvement initiatives




– Subpractices

• Prioritize the candidate process improvements. Prioritization criteria:

– Consider the estimated cost and effort to implement the process improvements

– Appraise the expected improvement against the organization's improvement objectives and priorities

– Determine the potential barriers to the process improvements and develop strategies for overcoming these barriers. Examples of techniques :

» A gap analysis that compares current conditions in the organization with optimal conditions

» Cause-and-effect analyses to provide information on the potential effects of different improvements that can then be compared

• Identify and document the process improvements that will be implemented

• Revise the list of planned process improvements to keep it current

37


PROJECT MANAGEMENT

• Project Planning

• Project Monitoring and Control

• Supplier Agreement Management

• Integrated Project Management

• Risk Management

• Quantitative Project Management


Risk Management

• Purpose

– The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

• Mitigar: Abrandar, amansar, suavizar, aliviar, diminuir, acalmar, atenuar (Aurélio)

38


Risk Management

• Introductory Notes

– Risk management is a continuous, forward-looking process

– A continuous risk management approach is applied to effectively anticipate and mitigate the risks that may have critical impact on the project

– Effective risk management includes early and aggressive risk identification through the collaboration and involvement of relevant stakeholders

– While technical issues are a primary concern both early on and throughout all project phases, risk management must consider both internal and external sources for cost, schedule, and technical risk.


Risk Management

• Risk management can be divided into three parts:

– defining a risk management strategy

– identifying and analyzing risks

– handling identified risks, including the implementation of risk mitigation plans when needed

39


Risk Management

• Specific Goals

– SG 1 Prepare for Risk Management

• Preparation for risk management is conducted.

– SG 2 Identify and Analyze Risks

• Risks are identified and analyzed to determine their relative importance.

– SG 3 Mitigate Risks

• Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives.


Risk Management

• Generic Goals

– GG 1 Achieve Specific Goals

• The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.

– GG 2 Institutionalize a Managed Process

• The process is institutionalized as a managed process.

– GG 3 Institutionalize a Defined Process

• The process is institutionalized as a defined process.

– GG 4 Institutionalize a Quantitatively Managed Process

• The process is institutionalized as a quantitatively managed process.

– GG 5 Institutionalize an Optimizing Process [CL106.GL101]

• The process is institutionalized as an optimizing process.

40


Risk Management


– SG 1 Prepare for Risk Management

• SP 1.1-1 Determine Risk Sources and Categories

• SP 1.2-1 Define Risk Parameters

• SP 1.3-1 Establish a Risk Management Strategy

– SG 2 Identify and Analyze Risks

• SP 2.1-1 Identify Risks

• SP 2.2-1 Evaluate, Categorize, and Prioritize Risks

– SG 3 Mitigate Risks

• SP 3.1-1 Develop Risk Mitigation Plans

• SP 3.2-1 Implement Risk Mitigation Plans


Risk Management

• GG 1 Achieve Specific Goals

– GP 1.1 Perform Base Practices

• GG 2 Institutionalize a Managed Process

– GP 2.1 Establish an Organizational Policy

– GP 2.2 Plan the Process

– GP 2.3 Provide Resources

– GP 2.4 Assign Responsibility

– GP 2.5 Train People

– GP 2.6 Manage Configurations

– GP 2.7 Identify and Involve Relevant Stakeholders

– GP 2.8 Monitor and Control the Process

– GP 2.9 Objectively Evaluate Adherence

– GP 2.10 Review Status with Higher Level Management

41


Risk Management

• GG 3 Institutionalize a Defined Process

– GP 3.1 Establish a Defined Process

– GP 3.2 Collect Improvement Information

• GG 4 Institutionalize a Quantitatively Managed Process

– GP 4.1 Establish Quantitative Objectives for the Process

– GP 4.2 Stabilize Subprocess Performance

• GG 5 Institutionalize an Optimizing Process

– GP 5.1 Ensure Continuous Process Improvement

– GP 5.2 Correct Root Causes of Problems


Risk Management

• SP 1.1-1 Determine Risk Sources and Categories

• Typical Work Products

– Risk source lists

• external

• internal

– Risk categories list

42


Risk Management

• Subpractices

– Determine risk sources • Risk sources are the drivers that cause risks within a project or organization

• Risk sources identify common areas where risks may originate.

• Typical internal and external risk sources – Uncertain requirements

– Unprecedented efforts => estimates unavailable

– Infeasible design

– Unavailable technology

– Unrealistic schedule estimates or allocation

– Inadequate staffing and skills

– Cost or funding issues

– Uncertain or inadequate subcontractor capability

– Uncertain or inadequate vendor capability

• Many of these sources of risk are often accepted without adequate planning.

• Early identification of both internal and external sources of risk can lead to early identification of risks.

• Risk mitigation plans can then be implemented early in the project – to preclude occurrence of the risks

– to reduce the consequences of their occurrence.


Risk Management

• Subpractices

– Determine risk categories

• Risk categories reflect the “bins” for collecting and organizing risks.

• A reason for identifying risk categories is to help in the future consolidation of the activities in the risk mitigation plans.

• The following factors may be considered when determining risk categories:

– The phases of the project’s life-cycle model (e.g., requirements, design, manufacturing, test and evaluation, delivery, disposal)

– The types of processes used

– The types of products used

– Program management risks (e.g., contract risks, budget/cost risks, schedule risks, resources risks, performance risks, supportability risks)

• A risk taxonomy can be used to provide a framework for determining risk sources and categories.

43


ENGINEERING

• Requirements Management

• Requirements Development

• Technical Solution

• Product Integration

• Verification

• Validation


Requirements Development

• Purpose

– The purpose of Requirements Development is to produce and analyze customer, product, and product-component requirements

44



• Specific Goals

– SG 1 Develop Customer Requirements

• Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

– SG 2 Develop Product Requirements

• Customer requirements are refined and elaborated to develop product and product-component requirements.

– SG 3 Analyze and Validate Requirements

• The requirements are analyzed and validated, and a definition of required functionality is developed.




– SG 1 Develop Customer Requirements• SP 1.1-1 Collect Stakeholder Needs

• SP 1.1-2 Elicit Needs

• SP 1.2-1 Develop the Customer Requirements

– SG 2 Develop Product Requirements • SP 2.1-1 Establish Product and Product-Component Requirements

• SP 2.2-1 Allocate Product-Component Requirements

• SP 2.3-1 Identify Interface Requirements

– SG 3 Analyze and Validate Requirements• SP 3.1-1 Establish Operational Concepts and Scenarios

• SP 3.2-1 Establish a Definition of Required Functionality

• SP 3.3-1 Analyze Requirements

• SP 3.4-3 Analyze Requirements to Achieve Balance

• SP 3.5-1 Validate Requirements

• SP 3.5-2 Validate Requirements with Comprehensive Methods

45


Technical Solution

• Purpose

– The purpose of Technical Solution is to design, develop, and implement solutions to requirements.

– Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combinations as appropriate.


Technical Solution

• Specific Goals

– SG 1 Select Product-Component Solutions

• Product or product-component solutions are selected from alternative solutions

– SG 2 Develop the Design

• Product or product-component designs are developed

– SG 3 Implement the Product Design

• Product components, and associated support documentation, are implemented from their designs

46


Technical Solution


– SG 1 Select Product-Component Solutions • SP 1.1-1 Develop Alternative Solutions and Selection Criteria

• SP 1.1-2 Develop Detailed Alternative Solutions and Selection Criteria

• SP 1.2-2 Evolve Operational Concepts and Scenarios

• SP 1.3-1 Select Product-Component Solutions

– SG 2 Develop the Design• SP 2.1-1 Design the Product or Product Component

• SP 2.2-3 Establish a Technical Data Package– A technical data package provides the developer with a comprehensive description of the product or

product component as it is developed.

• SP 2.3-1 Establish Interface Descriptions

• SP 2.3-3 Design Interfaces Using Criteria

• SP 2.4-3 Perform Make, Buy, or Reuse Analyses

– SG 3 Implement the Product Design• SP 3.1-1 Implement the Design

• SP 3.2-1 Develop Product Support Documentation


SUPPORT

• Configuration Management

• Process and Product Quality Assurance

• Measurement and Analysis

• Decision Analysis and Resolution

• Causal Analysis and Resolution

47


Measurement and Analysis

• Purpose

– The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs



• Specific goals

– SG 1 Align Measurement and Analysis Activities

• Measurement objectives and activities are aligned with identified information needs and objectives.

– SG 2 Provide Measurement Results

• Measurement results that address identified information needs and objectives are provided.

48




– SG 1 Align Measurement and Analysis Activities

• SP 1.1-1 Establish Measurement Objectives

• SP 1.2-1 Specify Measures

• SP 1.3-1 Specify Data Collection and Storage Procedures

• SP 1.4-1 Specify Analysis Procedures

– SG 2 Provide Measurement Results

• SP 2.1-1 Collect Measurement Data

• SP 2.2-1 Analyze Measurement Data

• SP 2.3-1 Store Data and Results

• SP 2.4-1 Communicate Results


MPS.BR

A• Inovação e Implantação na Organização• Análise e Resolução de Causas

B• Desempenho do Processo Organizacional• Gerência Quantitativa do Projeto

C• Análise de C Decisão e Resolução• Gerência de Riscos

D• Desenvolvimento de Requisitos• Solução Técnica• Integração do Produto• Instalação do Produto• Liberação do Produto• Verificação• Validação

49


MPS.BR

E• Treinamento• Avaliação e Melhoria do Processo Organizacional• Definição do Processo Organizacional• Adaptação do Processo para Gerência de Projeto

F• Medição• Gerência de Configuração• Aquisição• Garantia da Qualidade

G • Gerência de Requisitos• Gerência de Projeto


• Baddoo, N.; Hall, T.; “De-motivators for Software Process Improvement: an Analysis of Practicioners' Views”; The Journal of Systems and Software 66; London: Elsevier; 2003; pags 23-33

• Boehm, B.W.; Software Engineering Economics; Prentice-Hall; Englewood Cliffs; 1981

• Brodman J.G.; Johnson D.L.; The LOGOS Tailored CMMSM for Small Businesses, Small Organizations, and Small Projects; LOGOS International, Needham, MA, 1995

• Capability Maturity Model Integration (CMMI), Version 1.1; CMMI for Software Engineering (CMMI-SW, V1.1) Continuous Representation; CMU/SEI-2002-TR-028; 2002

• Capability Maturity Model Integration (CMMI), Version 1.1; CMMI for Software Engineering (CMMI-SW, V1.1) Staged Representation; CMU/SEI-2002-TR-02; 2002

• Chrissis, M.B.; Konrad, M.; Shrum, S.; CMMI: Guidelines for Process Integration and Product Improvement; New York, NY: Addison-Wesley; 2003

Bibliografia

50


• Coallier, D.; “How ISO 9001 Fits into the Software World”; IEEE Software 11(1); pp. 98-100, Jan. 1994

• Grady, R.B.; Successful Software Process Improvement; Prentice Hall; Englewood Cliffs, NJ; 1997

• Humphrey, W.S.; Managing the software process; Addison-Wesley; Reading, Mass.; 1989

• Humphrey, W.S.; A Discipline for Software Engineering; Addison-Wesley; Reading, MA 01867; 1995

• Humphrey, W.S.; Introduction to the Team Software Process; New York, NY: Addison-Wesley; 2000

• Kan, S.H.; Basili, V.R.; Shapiro, L.N.; “Software quality: An overview from the perspective of total quality management”; IBM Systems Journal 33(1); 1994; pp. 3-19

• Niessink, F.; Clerc, V.; Tijdink, T.; Vliet, H.v.; The IT Service Capability Maturity Model, Version 1.0, Release Candidate 1; CIBIT Consultants & Educators, Bilthoven, The Netherlands; 2005

Bibliografia


• Paulk, M.C.; “How ISO 9001 Compares with the CMM”; IEEE Software, Jan. 1995; pp. 74-83

• SPICE; Part 1: Concepts and introductory guide; Part 2: A model for process management; Part 3: Rating processes; Part 4: Guide to conducting assessment; Part 5: Construction, selection and use of assessment instruments and tools; Part 6: Qualification and training of assessors; Part 7 : Guide for use in process improvement; Part 8: Guide for use in determining supplier process capability; Part 9: Vocabulary; http://www-sqi.cit.gu.edu.au/spice/ ; 1995

• SSE-CMM - Systems Security Engineering Capability Maturity Model, Model Description Document, Version 3.0; SEI/CMU; 2003

Bibliografia

Documents

Processos Baseados em Planejamento - PUC-Rioinf2135/docs/INF2135-Modulo07... · – PMBOK –Project Management Book of Knowledge – ITIL –Information Technology Infrastructure