INF2135 Modulo07 ProcessosPlanejados

Processos Baseados em Planejamento
Arndt von Staa

Departamento de Informtica
PUC-Rio
Maro 2010
Mar 2010 2 Arndt von Staa LES/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
Princpio rigoroso
SAY
1
WHAT YOU DO;
DO WHAT YOU SAY

1 na realidade: document

Agenda
Terminologia
Resultados esperados
Modelos
Melhoria contnua
reas chave
Clusulas ISO
Nveis de maturidade
Viso genrica CMM
Viso genrica CMMI
Viso genrica MPS.BR
Terminologia 1 / 4
CMM - Capability maturity model
modelo da maturidade da capacitao
existem vrios modelos: SW-CMM, CMMI-DEV, SPICE ou
ISO15504, SSE-CMM, ITService-CMM, TestMM, MPS.BR. . .
Organizao
empresa, diviso, ou mesmo um grupo que desenvolve
sistemas (ou artefatos) intensivos em software
Projeto
empreendimento com incio e fim, que visa disponibilizar ou
realizar uma mudana em um artefato, e que consome
recursos limitados
um projeto nunca recorrente
Terminologia 2 / 4
Artefato (work product)
item disponvel e que satisfaz requisitos de qualidade
estabelecidos, de servio e de engenharia
Produto
artefato a ser entregue ao cliente ou usurio
Cliente
pessoa ou organizao que tem interesse em dispor de um
sistema (produto) e disponibiliza recursos para tal
Usurio
pessoa (ou artefato) que utiliza, opera, desenvolve, mantm,
ou instala um artefato (produto), esperando receber um servio
que atenda (adequado, fidedigno) s necessidades e
expectativas desta pessoa (ou artefato)
exemplo de artefato usurio: sistema usurio de software
embarcado
Terminologia 3 / 4
Processo
conjunto de atividades (prticas) que visam atingir uma ou
mais metas estabelecidas
rea (chave) de processo
um conjunto de prticas que, quando realizadas
coletivamente, conduzem ao alcance de um ou mais objetivos
(meta, goal) desejados
uma rea de processo pode ser entendida como um sub-
processo
Prticas (chave) da rea do processo
descries de atividades, estabelecendo as pr e ps condies
(insumos e resultados) para a sua realizao, bem como as
condies de disparo (trigger) de seu incio
vinculadas a reas de processo
Terminologia 4 / 4
Institucionalizao, atuar para que
as prticas estejam claramente documentadas
sejam realizadas regularmente tal como escritas
sejam efetivas resolvem o problema em questo
sejam duradouras
desenvolvedores podem ser treinados
ningum cai na tentao de voltar a um status quo anterior
Gerncia do processo
estabelecer, institucionalizar, observar, aprimorar os processos
Gerncia 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 capacitao, diminui a divergncia
entre o planejado (esperado) e o realizado
custo
tempo
qualidade do servio entregue
satisfao do usurio e do cliente
qualidade de engenharia
Melhoria do controle de execuo do projeto
a entrega de artefatos aprovados passa a ser o indicador
confivel de progresso
reduz o risco da sndrome do prazo de entrega
i.e. o trabalho realizado com o devido afinco somente na proximidade
do prazo de entrega
desaparece a sndrome dos 90% pronto ou do s falta testar
tempo
esforo
instantneo
prazo
limite da capacidade
realizado
???
vivel, entre 80 e 90%
Melhoria da competncia individual (wwwwwh ou 5wh)
cada um (who) sabe
(what) o que deve fazer
(why) por que deve fazer
(when) quando deve fazer
(how) como deve fazer
com que instrumentos deve fazer
como ser (dever ser) controlada a qualidade
(where) onde deve guardar
Melhoria da eficincia dos processos
medida que aumenta a capacitao, reduzem-se os custos e
tempos em virtude da diminuio de retrabalho
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 eficcia dos processos
mais qualidade e produtividade a cada novo
desenvolvimento
do servio
adequao ao uso
fidedignidade
da engenharia
Modelos
Um modelo uma abstrao a partir da qual podem-se
avaliar, de forma racional, as propriedades ou o
comportamento futuro de reificaes (instanciaes) em
conformidade com o modelo

Modelos dirigem as reificaes
estabelecem critrios para verificar a adequao e corretude da
reificao

Modelos de processos podem ser entendidos como:
meta-processos
frameworks
Viso macro da estrutura de processos
adio das caractersticas do artefato
e dos recursos a utilizar
adio da tecnologia e das caractersticas
do ambiente a utilizar
Meta-processo
padro
Tecnologia
a ser utilizada
Natureza da
aplicao
Processo
definido
Especificao
de requisitos
Recursos
disponveis
Plano de
desenvolvimento
Desenvolvimento
disciplinado
Insumos
Artefatos
Ambiente de
desenvolvimento
Estabelecer
ambiente
execuo segundo o plano
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
Processos baseados em planos
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

Outros tipos de abordagem
PMBOK Project Management Book of Knowledge
ITIL Information Technology Infrastructure Library
Metas de rea de processo, exemplo
Planejar as atividades de gerncia de configurao de
software
Identificar, controlar e tornar disponveis os artefatos de
software selecionados (itens de configurao)
Controlar as alteraes nos artefatos de software
identificados
Informar pessoas e grupos envolvidos acerca do estado e do
contedo das baselines de software.

(adio minha) Acompanhar a soluo dos problemas relacionados
com o artefato at a sua concluso
relatos de falha, no conformidades
solicitaes de adaptao, melhoria ou evoluo
solicitao de novos artefatos
Clausulas ISO 9001
Exemplo de clusula:

10 - Inspeo e ensaios (testes)
Estabelecer e manter procedimentos documentados para
atividades de ensaio e inspeo, de maneira a verificar se o
produto est de acordo com os requisitos publicados.
Ensaios e inspees e devem ser realizados tanto para
mercadorias recebidas quanto para produtos finais.
Detalhar no plano da qualidade ou em procedimentos
documentados, os testes e inspees requeridos e os registros a
serem feitos.

Clusulas ISO 9000 - 1994
01 - Responsabilidade da administrao
02 - Sistema da qualidade
03 - Anlise crtica de contratos
04 - Controle de projeto (inclui planejamento)
05 - Controle de documentos e dados
06 - Aquisio
07 - Controle de produtos fornecidos pelo cliente
08 - Identificao e rastreabilidade de produtos
09 - Controle do processo
10 - Inspeo e ensaios (testes)
Clusulas ISO 9000
11 - Controle de equipamentos de inspeo, medio e ensaio
12 - Situao da inspeo e ensaio
13 - Controle de produto no conforme
14 - Ao corretiva e preventiva
15 - Manuseio, armazenamento, embalagem, preservao e
entrega
16 - Controle de registros da qualidade
17 - Auditoria interna da qualidade
18 - Treinamento
19 - Servios associados (ex.: assistncia tcnica)
20 - Tcnicas estatsticas
Exemplo: Prticas chave CMM
Exemplo (rea de processo: gerncia de configurao)
Prtica 1 - Preparar plano de GCS.
Prtica 2 - Executar as atividades de GCS de acordo com o plano de GCS.
Prtica 3 - Estabelecer um repositrio para baselines.
Prtica 4 - Identificar itens de configurao.
Prtica 5 - Gerenciar as solicitaes de mudanas e os relatrios de
problemas para todos os itens de configurao
Prtica 6 - Controlar alteraes nas baselines.
Prtica 7 - Controlar a liberao de produtos.
Prtica 8 - Registrar o estado dos itens de configurao.
Prtica 9 - Divulgar as atividades de GCS e o contedo das baselines.
Prtica 10 - Conduzir auditorias nas baselines de software.
Exemplo: Prticas 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
Nveis de maturidade
Os CMMs propem nveis de maturidade

cada nvel 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 prticas
fortemente correlatas
pode ser entendido como um sub-processo
com um escopo bem delimitado
focado em um aspecto especfico do processo de desenvolvimento
Nveis de maturidade SW-CMM
Gerncia de configurao de software
Garantia de qualidade de software
Gerncia de contrato de software
Superviso e acompanhamento de projeto
Planejamento do projeto de software
Gerncia de Requisitos
Nvel 2 - REPETITVEL
Reviso por parceiros
Coordenao entre grupos
Engenharia do produto de software
Gerenciamento integrado de software
Programa de treinamento
Definio do processo organizacional
Foco no processo da organizao
Nvel 3 - DEFINIDO
Gerncia da qualidade de software
Gerncia de processos quantitativos
Nvel 4 - GERENCIADO
Gerncia de alterao de processo
Gerncia de alterao de tecnologia
Preveno de defeitos
Nvel 5 - OTIMIZADO
Nvel 1 - INICIAL
Nveis de maturidade, expectativa
Nvel 1
Nvel 2
Nvel 3
Nvel 4
Nvel 5
Estimativa feita
Distribuies
da realizao
Um nvel somente estar atingido quando todas as reas
do processo deste nvel e dos nveis inferiores estiverem
implementadas e em uso rotineiro

Exemplo: Se satisfizer todas as APs de todos os nveis,
menos a de gerncia de configurao, continua no nvel 1!

Ter atingido um determinado nvel de maturidade
no por si s um atestado de qualidade
somente um indicador da capacitao (habilitao) em
atingir metas de qualidade e produtividade
Nveis de maturidade
Pode-se implementar as APs em qualquer ordem
mas somente evolui de nvel em nvel medida que todas as
APs do nvel tiverem institucionalizadas
Podem ser adicionadas APs no previstas
ex.: as clusulas ISO 9000 no atendidas pelo CMM
O importante cada AP estar documentada e em uso
rotineiro
Nveis de maturidade modelo em estgios
Organizao SW-CMM
Nveis de Maturidade
reas chave do processo
Caractersticas comuns
Prticas chave
Capacitao
do Processo
Metas
Implementao ou
Institucionalizao
Infra-estrutura ou
Atividades
contm
organizadas por
contm
descrevem
indicam
visam
endeream
Ativos (assets) do processo
descries de processos
descries de ciclos de vida
descries de prticas institucionalizadas
como praticada
que ferramentas utiliza
como interrelaciona com o resto
base de dados de processos
biblioteca de documentao de processos
base de padres
base de ferramentas
Banco de
Dados de
Processos de
Software da
organizao
Biblioteca
de Documen-
tao Relacio-
nada ao
Processo de
Software
Descries
dos
Ciclos de
Vida
Descrio do Processo de Software
Descrio dos Elementos do
Processo de Software
Arquitetura do Processo de Software
Padro da Organizao
Requisitos Externos
Requisitos de
Sistema
Requisitos do
Sistema
Alocados ao
Software
Selecionar o
Ciclo de Vida
de Software
do Projeto
Desenvolver o
Processo de
Software
Definido do
Projeto
Resultados do Projeto e artefatos de software
Atividades
Desenvolver o Processo de Software
Padro da Organizao
Etapa a Etapa b Etapa c Etapa d
Plano de Desenvolvimento
de Software do Projeto
Tarefas de Projeto
Descrio do Processo
de Software do Projeto
Descrio do Processo de Software
Definido do Projeto
{Fase a} {Fase b} {Fase c} {Fase d}
Ciclo de Vida de Software do Projeto
Arquitetura de Alto Nvel do Proc. Soft.
Diretrizes
e Critrios
para Adaptar
Software
Organizao
o Processo de
Padro da
CMM - caractersticas comuns
Cada rea chave do processo subdividida nas seguintes
caractersticas comuns:
Compromissos
Habilitaes
Atividades (prticas)
Medio e anlise
Verificao da implementao
Compromisso, exemplo:

C1: O projeto segue uma poltica organizacional documentada
para desempenhar as tarefas de engenharia de software
Habilitaes, exemplos:
H1: Esto disponveis os recursos e os fundos adequados para
desempenhar as tarefas de engenharia de software.

H2: Os membros do corpo tcnico de engenharia de software
tm o treinamento necessrio para desempenhar suas
atribuies.
Atividades, exemplos:
A1: Integrar mtodos 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 codificao.
Medio, exemplos:
M1: Desenvolver e usar medies para determinar a
funcionalidade e qualidade dos artefatos de software

M2: Desenvolver e usar medies para determinar o estado das
atividades de engenharia do artefato de software
Verificao, exemplos:
V2: Revisar, periodicamente e quando da ocorrncia 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
Documentao de requisitos de software
Documentao do design de software
Cdigo
Documentao externa
Planos, procedimentos e casos teste
Resultados dos testes
Documentao de rastreamento dos requisitos de software, do
design, do cdigo, da documentao externa e dos casos de
teste
Modelo CMMI em estgios
CMMI reas de processo genricas
Todas abordam a implementao das prticas e reas do
processo

Commitment to perform
Ability to perform
Directing implementation
Verifying implementation
CMMI Nveis de capacitao
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 verso por estgios esse nvel no est definido, mas
mencionado.
Este nvel tambm existe no SPICE: ISO/IEC 15504
SPICE e CMMI modelo contnuo so 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
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
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
reas do processo
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
Reviso por parceiros
Coordenao entre grupos
Engenharia do produto de
software
Gerenciamento integrado
de software
Programa de treinamento
Definio do processo
organizacional
Foco no processo da
organizao
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
reas do processo
Organizational Process Performance
Quantitative Project Management
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
reas do processo
Organizational Innovation and Deployment
Causal Analysis and Resolution
CMMI Contnuo
CMMI Contnuo - Nveis
No modelo contnuo cada rea de processo pode estar em um
dos nveis a seguir:

0 - Incomplete
1 - Performed
2 - Managed
3 - Defined
4 - Quantitatively Managed
5 - Optimizing
CMMI Contnuo - Categorias
As reas de processo no modelo contnuo so 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 Contnuo
PROCESS MANAGEMENT, reas

CMMI Contnuo
PROJECT MANAGEMENT, reas
Project Planning
Risk Management
CMMI Contnuo
ENGINEERING, reas
Technical Solution
Product Integration
Verification
Validation
CMMI Contnuo
SUPPORT, reas
CMMI Contnuo - Genrico
Cada rea de processo define objetivos e atividades
genricas:
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
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
Process Management
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 organizations processes and process assets.

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 domnio de processos que podem ser utilizados
para produzir bens (i.e. artefatos).
Organizational process assets include the following:
Organizations set of standard processes,
process architectures
process elements
Descriptions of life-cycle models approved for use
Guidelines and criteria for tailoring the organizations set of
standard processes
Organizations measurement repository
Organizations process performance baselines
Organizations process performance models
Organizational process assets include the following (contd.):
Organizations process asset library
policies
defined processes
checklists
lessons-learned documents
templates
standards
procedures
plans
training materials
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

Process improvement occurs within the context of the
organizations 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.
Careful planning is required to ensure that process-
improvement efforts across the organization are adequately
managed and implemented.
The organizations planning for process-improvement results
in a process-improvement plan addressing
appraisal planning
process action planning
pilot planning
and deployment planning
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
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
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 Organizations 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
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 organizations 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
PROJECT MANAGEMENT
Project Planning
Risk 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 (Aurlio)

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
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
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.
The process is institutionalized as a managed process.
The process is institutionalized as a defined 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.

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
GP 1.1 Perform Base Practices
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
Risk Management
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
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
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 projects 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.
ENGINEERING
Technical Solution
Product Integration
Verification
Validation
Purpose
The purpose of Requirements Development is to produce and
analyze customer, product, and product-component
requirements
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
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

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
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.

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
Inovao e Implantao na Organizao
Anlise e Resoluo de Causas

B
Desempenho do Processo Organizacional
Gerncia Quantitativa do Projeto

C
Anlise de C Deciso e Resoluo
Gerncia de Riscos

D
Desenvolvimento de Requisitos
Soluo Tcnica
Integrao do Produto
Instalao do Produto
Liberao do Produto
Verificao
Validao
MPS.BR
E
Treinamento
Avaliao e Melhoria do Processo Organizacional
Definio do Processo Organizacional
Adaptao do Processo para Gerncia de Projeto

F
Medio
Gerncia de Configurao
Aquisio
Garantia da Qualidade

G
Gerncia de Requisitos
Gerncia de Projeto
SSE-CMM
Visa o desenvolvimento de sistemas de elevada segurana
Areas adicionais:
Administer Security Controls
Assess Impact
Assess Security Risk
Assess Threat
Assess Vulnerability
Build Assurance Argument
Coordinate Security
Monitor Security Posture
Provide Security Input
Specify Security Needs
Verify and Validate Security
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
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

INF2135 Modulo07 ProcessosPlanejados

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

INF2135 Modulo07 ProcessosPlanejados

Uploaded by

Copyright:

Available Formats

Processos Baseados em Planejamento

Arndt von Staa

You might also like