La complexification croissante des
systèmes d’information est telle que la typologie des contraintes mute pour
intégrer davantage la nécessité d’arbitrage, de pilotage, de priorisation,
d’amoindrissement des risques, de décloisonnement, de standardisation et
d’alignement face au foisonnement des lancements de chantiers et à l’explosion
du nombre de projets à gérer simultanément.
La conséquence immédiate est simple : l’émergence de nouveaux concepts pour
justifier économiquement les dépenses lors de toute mise en place de nouveaux
projets, produits ou services : le PPM (Portfolio Project Management) ou GPP
(Gestion de Portefeuille de Projets) répond à cette demande.
Conserver ou obtenir le leadership dans un marché concurrentiel accru, faire
face à la mondialisation et aux perpétuelles contraintes environnementales,
c’est « se benchmarker », se différencier continuellement, innover avec une
forte réactivité et améliorer en permanence le triptyque performance /
management / technologie ; impulser ce développement et faire en sorte qu’il
soit durable est fonction de la pertinence de la prise de décision laquelle est
fondée sur la connaissance, résultante du traitement de l’information et d’une
analyse SWOT ; pour aboutir à cette information, il aura fallu consolider et
structurer les données d’entreprise qualifiées de données opérationnelles :
c’est donc un processus complexe qui permet de partir d’une donnée élémentaire
et d’aboutir à la politique stratégique de toute entreprise privée.
Simple introduction à l’enjeu du Datawarehousing, en tant que processus
sous-jacent à la Business Intelligence en ce sens qu’il permet avec la
collaboration de l’EAI (interopérabilité de systèmes disparates) et des
solutions décisionnelles de « business transformer » les fameuses données de
production (puisées principalement à partir des SGBD, ERP et solutions
spécifiques OLTP) en connaissances supports aux processus stratégiques.
L’évolution aussi bien de l’infrastructure que des méthodes et outils implique
une révision permanente des démarches d’approche pour piloter avec efficience
et de manière pertinente le système d’information.
La nouvelle orientation prise ces dernières années consiste en une approche par
processus métiers en se dotant d’un cadre architectural souple et pérenne.
La gestion de la complexité induit l’émergence de méthodologies de planification
de plus en plus sophistiquées comme le témoigne d’une part le processus de
développement OO RUP (processus itératif et incrémental, centré sur
l’architecture et piloté par les risques) ainsi que la part croissante accordée
à l’accompagnement et au coach entrepris parallèlement à la rédaction des
spécifications.
La répartition des rôles et des responsabilités des parties prenantes se doit
dès lors de s'affiner davantage et de se structurer pour mieux définir les
implications stratégiques et opérationnelles, de la MOA, de la MOE, des
utilisateurs et des partenaires.
La stratégie de mise en œuvre d’outils
pour élaborer une interopérabilité optimale et universelle entre applications
sur des plates-formes hétérogènes et disparates est le challenge par excellence
que doivent relever les grandes structures pour s’engager dans la voie de
l’amélioration continue et de la réduction du TCO donc par déduction pour
accroître le ROI.
Cette « Business Transformation » en WebServices doit s’opérer en maintenant
une qualité de service, une intégrité des données, une fiabilité et une
évolutivité des systèmes tout en gardant à l’esprit l’enjeu sécurité.
La démarche de sélection de solutions et d’identification des critères de choix
au regard de la typologie des besoins est une étape majeure en amont du cycle
qui ne doit en aucun cas être sous-estimée sous peine d’engager des dépenses
excessives pour aboutir à un résultat sous-dimensionné ou alors
sur-dimensionné.
L ‘accompagnement dans la conduite du changement est une démarche récurrente
depuis plus d’une décennie mais il n’est pas inutile de rappeler la nécessité
de mobilisation et de sensibilisation par le partage d’une vision commune
vis-à-vis des décideurs, l’adhésion des managers opérationnels et la fourniture
d’outils et de méthodes aux utilisateurs : l’organisation, la communication
(coach), la formation, la documentation et la facilitation sont les mots
d’ordre à retenir.
Le marché des ERP et des solutions de CRM
(qui constituent le Back Office) étant arrivé à maturité, il s’agira de
composer avec les solutions phares qui se sont imposées au cours de la dernière
décennie, à savoir principalement SAP, ORACLE, PEOPLESOFT, JD Edwards et BAAN;
on pourra mettre en exergue les critères de détermination d’une solution
décisionnelle (pour un accès simplifié à l'information agrégée et un suivi des
indicateurs clés) parmi les fleurons du marché que sont SAS, BO, COGNOS,
HYPERION, MicroStrategy et OE, s’intéresser aux outils d’EAI et proposer
d’opter pour des plate-formes phares que sont CrossWorlds, webMethods, TIBCO,
GXS, BEA, SeeBeyond, Vitria, Mercator, iPlanet ou Biztalk (IONA ou Kabira pour
compléter avec les webservices).
En ce qui concerne la méthodologie de
conduite de projet qui prend le lead, il s’agit de RUP racheté par IBM GS.
CMMI (utilisée chez IBM GS certifié niveau
5) devient une référence internationale en tant que meilleures pratiques
appliquée sur des milliers de projets
pour l’évaluation, le développement et la maintenance de système avec
plus de 400 pratiques référencées.
ISO avec notamment SPICE ou encore 15504
(utilisé chez FT et ORANGE) est l’équivalent de CMMI et peut aussi nous guider
dans l’évaluation de processus logiciels.
Mon objectif constant est celui d’insuffler,
d’impulser, de promouvoir et de contrôler les meilleures pratiques encore
qualifiées de « best of breed » ; l’harmonisation qui en résulte est le
résultat d’une multitude d’intrants que sont les variables :
- performance,
- management,
- les 4P,
- influences macro-environnementales selon le
modèle PESTEL.
Mon principal souci et objectif majeur est
la recherche de la qualité et de la satisfaction durable de vos besoins
(formulés et/ou implicites, présents et futurs) à travers l’approche d’un
urbaniste qui aurait à l’esprit la « mutualisation de briques applicatives par
approche composants », « l’orchestration par encapsulation de fonctions
logicielles»
Personne de méthodologie, garante de la bonne
exécution des projets d'envergure et fort d'une quinzaine d'années
d'expériences en maîtrise d'ouvrage, maîtrise d’œuvre, conseil et audit auprès
des plus grands comptes, je suis rompu à presque toutes les problématiques.
Fédérateur d'énergies, mobilisateur, la
multitude de projets traités me confère une grande facilité à identifier les
processus clés de votre entreprise (ou ceux de vos clients) ainsi que leurs
interactions pour impulser le plan d'action.
Conseil et/ou management des moyens sur tous les cycles
d'abstraction, de vie et de décision du projet depuis le schéma directeur et la
planification stratégique jusqu’au transfert de compétences et à la
présentation du retour d’expérience en passant par les étapes classiques de
mise en place ou d’implantation (souvent mise en avant par les SSII et cabinets
de conseil comme la justification du respect d’une méthodologie, source de
réconfort pour les directions achats) :
- étude préalable d’opportunité et
d'orientation,
- périmètre et macro-planning,
- qualification des besoins (business model),
- cahier des charges,
- dossier d’architecture,
- cycles itératifs et incrémentaux d'analyse,
de conception et de validation,
- implémentation ou mise en oeuvre,
- déploiement,
- sensibilisation.
La cartographie de mes compétences
fonctionnelles est très large puisqu’elle couvre les ERP (PGI), le CRM (GRC),
la SCM (Logistique), le PLM (Produit), le SLM (Services), l’EAI, le BTO, le
BPM, le KM et la BI ; je peux mettre en facteur des activités connexes
concernant la qualité, la sécurité, l’urbanisme, l’architecture, les normes et
standards (OMG, W3C, ISO, SEI, IETF, UIT, ...), la VS, l’IES et le PPM.
@ Stratégie :
· Analyse de portefeuille d’activités,
Diagnostic, Plan d’action, Benchmark, Veille
@ Organisation :
· Etudes, Audit, BPR, Optimisation,
@ Assistance à maîtrise d’ouvrage :
· Recommandations, Cahier des charges, Choix
@ Accompagnement dans la conduite du
changement :
· Préconisations, Coach, Anticipation,
Validation
@ Direction de Projets :
· Planning, Organisation, Analyse des risques, Gestion des ressources,
Communication, Suivi budgétaire, Reporting, Arbitrages, Animation, Supervision, Délégation, Coordination,
Validation, Respect des engagements (contraintes de délai, coût, performance,
qualité, sécurité, fiabilité, … )
@ Urbanisme :
· Cohérence et pertinence de l’existant /
architecture cible
@ Qualité :
· Optimisation des processus, Complétude des
procédures, Validation de la mise en œuvre des normes et standards
@@ Domaines :
· Business Intelligence, KM, EIP, ERP, BTO,
EAI.
Très bonne présentation,
Excellent communiquant,
Ouverture d'esprit,
Réactivité,
Professionnalisme,
Transparence,
Vision,
Dynamisme,
Adaptabilité,
Force de proposition,
Démarche méthodologique et outillée,
Respect des engagements.
Banque :
CREDIT LYONNAIS
Télécoms :
FTM/ORANGE
SFR/CEGETEL
ALCATEL
Administration & Ministères :
DGI
DF
MFP
DEMSAT
Distribution :
ECS
GROUPEMENT DES MOUSQUETAIRES
Industrie :
AMD-BA
SSII, Cabinets et Editeurs :
IBM GS EMEA, THALES IS, MERANT, KEYRUS,
KYRIBA,
CORAUD, IACP, ATA, SQL plus,
PARTNERS INFORMATIQUE
CREDIT LYONNAIS
Choix d'outils, Architecture Cible.
KYRIBA
Planification Stratégique, Gestion de
projets complexes. (RUP)
FTM / ORANGE
Gestion de portefeuille de projets (GED, KM,
portails, …) ; Plan
d’action.
IBM GS EMEA
Business Transformation Outsourcing,
Informational Warehouse,
EAI,
Arbitrage, Pilotage et Coordination.
ALCATEL
Audit,
Organisation,
Expression des besoins,
Maîtrise d’œuvre,
Mise en place de solutions ERP,
Hébergement,
BPR
Tarifs HT / J : pondération (jusqu'à 100%
en sus) en fonction des paramètres suivants :
taille, CA, Bn, secteur d'activité, niveau
d'intervention, intermédiaire ou client final.
15000 € pour un crédit de 20 J
30000 € pour un crédit de 50 J
50000 € pour un crédit de 100 J
95000 € pour un crédit de 200 J
Si hors Idf, + 3000 € / mois frais.
Aparté
L’entreprise performante du futur ne survivra
que si elle saura être accompagnée de consultants externes dans
l’identification des axes d’amélioration, l’élaboration et la mise en oeuvre de
son schéma directeur informatique et la DSI considérée auparavant comme un
support pour l’automatisation des tâches répétitives de facturation, de
logistique, de gestion des achats et des stocks, de RH, de comptabilité et de
contrôle de gestion, puis de gestion du marketing, est plus que jamais, surtout
suite à la mise en place des ERP et des solutions décisionnelles, un outil
indispensable de prise de décision pour la Direction Générale.
Une intervention de qualité doit
inéluctablement être accompagnée d’une parfaite connaissance de l’évolution
technologique et la nécessité de veille est un critère que je considère comme
déterminant dans le choix du prestataire.
Ainsi la meilleure façon de pousser une réflexion
à ses limites pour aboutir à une efficience extrême et pour être en concordance
avec le modèle d'entreprise en alignant les systèmes d’information à la «
politique stratégique » de la direction générale est de se « sourcer » en
permanence dans tous les domaines liés aux problématiques d’une DSI.
Pour conclure dans la formulation de ma vision
des orientations à suivre dans le présent et dans le futur, je propose quelques
acceptions qui ne prétendent pas constituer la recette miracle mais y
contribuer :
- au-delà de la traduction de la perception des
besoins et attentes des clients, les processus de transformation et de
définition de standards prévalent en tant que facteur de création de valeurs ;
- Le benchmark et le partenariat sont certes
indispensables mais cette quête de recherche de la forme de réseau idéal ne
doit pas se limiter aux entreprises privées mais aussi et surtout s’élargir à
la coopération avec les universités, centres de recherche, organisations de
normalisation, consortiums, associations et forums ;
- Les actions en faveur de la capitalisation de
la connaissance doivent s’étendre à la veille et à l’intelligence économique et
stratégique ;
- L’environnement turbulent qui caractérise
notre société implique un levier fondamental : le management permanent de la
transition et un positionnement pertinent nonobstant la gestion de projet
traditionnelle guidée par la réduction des risques, la priorisation et
l’optimisation de l’allocation des ressources ;
- Repenser, reconfigurer et réorganiser
l’entreprise du futur par l’essaimage de nouvelles unités est une nécessité
indispensable à la survie dans notre ère de l’économie numérique caractérisée
par la voie de l’amélioration continue (selon le principe de la roue de Deming)
à travers les axes suivants (factorisés par le contexte politique, économique,
social, écologique, technologique et légal) :
° Personne (dynamisme, mobilité, disponibilité,
réactivité, adaptabilité),
° Produit (technologie, innovation, ergonomie,
convivialité, disponibilité, simplicité, standardisation, universalité,
modularité, flexibilité, interopérabilité, évolutivité, extensibilité,
performance, fiabilité),
° Projet (management, architecture, urbanisme,
cohésion, priorisation, intégration, efficience, qualité, sécurité, intégrité),
° Processus (stratégie, opérationnel, support),
Une analogie avec la vue 4+1 de la notation UML
et l’impossibilité de rattacher certaines caractéristiques aux fameuses 4P me
laisserait entrevoir un pilier primordial et fondamental constituant la colonne
vertébrale de l’ensemble :
° L’entreprise : Compétitivité, rentabilité,
réactivité, performance, pérennité, partenariats.
Je me tiens donc à votre entière disposition
pour vous faire profiter de la somme de compétences acquises durant près de
deux décennies et de la méthodologie appropriée qui s’est façonnée et affinée
au fil de l’eau à travers la multiplication des interventions portant sur les
systèmes d’information.
Jean-Gabriel DIAN
06 09 47 92 49
Présentation
du RUP et de CMMI
Jean-Gabriel DIAN BAC + 4 / 15 ans d’expériences38 ans |
4, rue isabeau de bavière 94240 L’HAY-LES-ROSES |
|
CONSULTANT - DIRECTEUR DE
PROJETS
|
||
Expériences
|
||
|
Depuis juin 2002 |
CREDIT LYONNAIS - Cadre de cohérence et plan d'urbanisation. - Architecture applicative de référence. |
|
|
Octobre 2001 |
KYRIBA Mission:
- Planification, coordination, tableaux de bord, suivi budgétaire,
instructions et recommandations auprès des managers ayant en charge le
développement d'un projet e-business de gestion sécurisée des flux
financiers. Autre suivi par itération des sous projets. |
|
|
Juillet 2000 |
FTM / ORANGE - Plan
d'action des nouveaux axes d’amélioration, - Complétude des procédures et contrats de service, - Mise en place pilote d'une GED, - Mise en place d'un portail qualité et de
traçabilité des projets, - Proposition de refonte de la structure
décisionnelle. |
|
|
Juillet 1998 |
IBM Global Services EMEA - Prise en charge de l'évolution de
l'Informational Warehouse à l'échelle internationale. - Validation des packages, - Intégration des releases, - Rédaction des dossiers d'architecture
technique. |
|
|
Mars 1998 |
SFR CEGETEL prise en charge de nouveaux développements liés
au marketing de l'offre. - Rattaché à la DSI, planification de la remise
des lots et mise en place des outils pour le projet Y2K. - Chaînes de traitements relative aux offres
marketing, - Lotissement des applications. |
|
|
Juillet 1997 |
GROUPEMENT DES MOUSQUETAIRES - STIME - Scénarii de tests, - Livraison de la solution. |
|
Février 1997 |
Mutualité de la Fonction Publique (MFP) - Suivi sous assurance qualité de l'évolution
du forfait "OPTIMUT2", - Animation des comités. |
|
Juillet 1996 |
ALCATEL TELECOM - Mise en correspondance des référentiels. |
|
Janvier 1996 |
ALCATEL CIT / Direction Industrielle (DI) |
|
Juin 1995 |
ALCATEL CIT / Direction des Réalisations (DR) |
|
Octobre 1994 |
ALCATEL CIT / Etudes et Développements (SED) (Outils : CONVERT et Platinum) - Plan de développement, - Dossier des tests de non-régression, - Dossier de fiches de validation / module, - PV de recette et de livraison, - Applications. |
|
Janvier 1994 |
ALCATEL RADIOTELEPHONE / DSI - Hébergement des applications. |
|
Octobre 1992 |
ALCATEL CIT / Service Informatique
Administratif et Financier (SIAF) |
|
Janvier 1992 |
ALCATEL CIT / Service Informatique Financière
(SIF) -
Intégration du référentiel et des écritures comptables, - Détermination/affectation des écarts. |
|
Septembre 1991 |
Direction Générale des Impôts / Service de
l'Organisation et de l'Informatique II° sous-bureau (DGI SOI) - Définition en relation avec le quai de Bercy
du pré-imprimé de taxation, - Mise en place des statistiques et préparation
de la campagne suivante. Cette taxation a rapporté pour la région Idf +
de 1 milliard FF. |
|
Mai 1991 |
ALCATEL CIT Direction des Services Economiques
et Financiers (DSEF) proposition d'une organisation de travail et
d'une solution de mise en harmonie des affaires pour l'intégration des prises
de commandes sur le système en place Ethernet, Unix Informix SQL avec
interopérabilité sécurisée possible |
|
Janvier 1991 |
ALCATEL CIT / Informatique Financière (SIF) - Intégration du budget dans le progiciel
financier TOLAS. |
|
Mai 1990 |
Europe Computer System (ECS) - Prise en compte de l'évolution du système
d'information sur l'ensemble des sources, - Tests de non-régression, - Validation de la livraison. |
|
Décembre 1989 |
Avions Marcel Dassault - Breguet Aviation
(AMD-BA) Résultats:
- Dispatching des tâches aux différents intervenants, - Optimisation du traitement des lots avec
préparation des jeux d'essais pour la phase de tests unitaires, TI et TV. |
|
Décembre 1988 |
Défense Nationale - DEMSAT - Direction de
l'Enseignement Militaire Supérieur Scientifique et Technique (DEMSST) - Initiation d'officiers stagiaires aux
méthodes de conception et aux langages de programmation. - Elaboration des modèles conceptuels de
données, - Cahier des charges, - Grille d'évaluation des réponses à l'AOR. |
|
Mars 1988 |
COGITEL FORUM |
|
Mai 1986 |
TYM INFORMATIQUE |
Formations
|
|||
|
Mai 2002 |
AFOGEC Architectures NT, firewalls, IDS, Antivirus,
Routeurs, VPN, PKI (SSL, DES, RSA), sniffers, scanners, normes ISO, AMDEC,
CMM, SPICE, Audit interne, SMQ, Méthodes d'Analyse de Risque. |
||
|
Septembre 1987 |
CNAM Paris Méthodologie, réseaux, bases de données,
statistiques, recherche opérationnelle, organisation. |
||
|
Septembre 1985 |
Institut Universitaire Privé d'Informatique Spécialité: Petits Systèmes d'Information |
||
Informatique
|
|||
|
Logiciels: |
PMW, MSProject,
Word, Excel, PowerPoint, Visio, MEGA, AMC designor, Access, FrontPage,
Dreamweaver, Smartsuite Lotus, Docs Open, Rational Rose. |
||
|
OS, SGBD, Standards, Langages: |
WINDOWS, UNIX,
LINUX, MVS, AIX, SUN, DB2, ORACLE, ISO, J2EE, SQL, HTML, XML |
||
|
Informations complémentaires: |
CMM, SPICE, ISO, Méthodologies MERISE, Notation
UML, Processus Unifié, RUP. |
||
Langues
|
|||
|
Anglais |
Oral: Professionnel |
Ecrit: Courant |
|
|
Espagnol |
Oral: Moyen |
Ecrit: Moyen |
|
Jean-Gabriel DIAN
06 09 47 92 49
Présentation du RUP et de CMMI
|
Jean-Gabriel DIAN French
nationality University (4
years) 15 year
experience 38 years old |
4, rue isabeau de bavière 94240 L’HAY-LES-ROSES |
QUALITY ASSURANCE MANAGER
|
|
Experience
|
||
|
Since 2002, Jun |
CREDIT LYONNAIS |
|
|
Position |
Senior
Consultant |
|
|
Mission |
Clarify
the choice of target architecture for the new decisional projects Define
& elaborate architectural patterns |
|
|
Resources |
DSAT,
DED/BA, DSP & DPI entities |
|
|
Results |
Criteria
of choice of target architecture Reference
architecture |
|
|
2001, Oct |
KYRIBA |
|
|
Position |
Senior
Consultant / deputy CIO |
|
|
Mission |
Planning
for a financial portal setting up dedicated to corporations with
Commerzbank A.G. according to Rational Unified Process; it includes the
following activities: Project
Management (Planning, Monitoring & Control, Risk, budget) Configuration
and Change Management Environment Business
Modeling Requirements Analyze
& design Implementation
Test Deployment |
|
|
Resources |
2
teams including together near one hundred of engineers, HP, BEA, CITRIX,
ORACLE and RATIONAL consultants + the
pilot team (about 20 persons). |
|
|
Results |
Planning
: one for the whole project and
another by iteration to drive and
guide the construction phase. |
|
|
2000, Jul |
FTM / ORANGE |
|
|
Position |
Quality
/ Consultant Manager |
|
|
Mission |
According
to SPICE (ISO 15504) and the following process categories (CUS)
Customer – Supplier, (ORG)
Organization, (MAN)
Management, (SUP)
Support, (ENG)
Engineering, Action
Plan IT
improvements (EDM pilot implementation, setting up quality portal,
Traceability project, KM solution), Change
Process (procedures, committees reorganization). |
|
|
Resources |
Team
consultants in charge of accompanying projects, dashboard & metrics,
quality of service |
|
|
Results |
Action
Plan for the new improvements SLA
validation Change
process (Portal publication, …) Procedures
verification |
|
|
1998, Jul |
IBM Global
Services EMEA (BTO) |
|
|
Position |
Project
Manager |
|
|
Mission |
According
to CMM/CMMI : Requirements
Management, Project Planning, Monitoring & Control Causal
analysis and resolution Organizational
Innovation and deployment Organizational
Process Performance Quantitative
Project Management & Measurement Integrated
Project Management Technical
Solution Product
Integration Verification
& Validation Decision
analysis & Resolution Product
& Process Quality Assurance Configuration
Management |
|
|
Reporting Ensure
smooth cooperation in test, delivery and support for applications Provide
test and release support Prepare
and agree a product schedule with Service Delivery and Application Owner Open,
follow, ensure resolution of any issues regarding the needs Support
tools and processes for applications release from test servers to production
servers to ensure complete and quality packages Provide
support to EMEA SD for build of applications on various platforms Follow
EMEA problems and change process (CPMA) Deliver
services and integrated solutions to solve problems Identify,
pursue and assist core team directors in the closing of consulting
engagements Provide
a measurement framework for process capability according to international
standards and best practices in order to verify compliance with requirements Issue
recommendations to ease production implementation Liaise
with development labs Control
Point Process and measurement |
||
|
Resources |
Laboratories
of development (Oceania, United States, Germany), Production units (UK) More
than 200 PM, PL and experts. |
|
|
Results |
Release
Integration with guidelines Package
verification and validation Reporting |
|
|
1998, Mar |
SFR CEGETEL |
|
|
Position |
Project
Manager |
|
|
Mission |
Scope
of the Y2K project, planning delivery for impact analysis Requirements
Management, Project Planning, Monitoring & Control Configuration Management |
|
|
Resources |
Autonomous |
|
|
Results |
Planning
and Tools |
|
|
1997, Jul |
GROUPEMENT DES MOUSQUETAIRES – STIME |
|
|
Position |
Project
Manager |
|
|
Mission |
Close/Open
flows Management on the databases (specification, test scenarios, coding and
production integration) Requirements
development Configuration
Management |
|
|
Resources |
Autonomous
for analyze and development phase, accompanied by production team at the end |
|
|
Results |
Scenarios
of test Solution
delivery |
|
|
1997, Feb |
Mutualité de la Fonction Publique (MFP) |
|
|
Position |
Project
Manager |
|
|
Mission |
OPTIMUT
2 migration (BPR) Commercial
proposition after ROI study Planning,
organization & coordination Project
committee & piloting committee Reporting
and dashboard, Verification
and validation test Requirements
Management, Project Planning, Monitoring & Control Process
Quality Assurance Configuration
Management |
|
|
Resources |
About
thirty resources for the whole project
- Team (5 to 7 persons) + 5 internal resources allocated to my part of
job. |
|
|
Results |
Applications
delivery |
|
|
1996, Jul |
ALCATEL TELECOM |
|
|
Position |
Project
Manager |
|
|
Mission |
Pilot implantation of SAP R/3 (MM, SD, PP) in
Malaysia Coordination
to find the data from the ALCATEL
referential to SAP files Setting
up control interfaces (OLAP) between specific application and SAP R/3 Requirements
development Verification
& Validation |
|
|
Resources |
Team
of about fifty persons (around thirty form CIMAD (IBM’s subsidiary) |
|
|
Results |
Solution
delivery |
|
|
1996, Jan |
ALCATEL CIT /
Direction Industrielle (DI) |
|
|
Position |
Project
Manager |
|
|
Mission |
Purchase
Management Business Process Reengineering Project Organizational
Process Performance Quantitative
Project Management Requirements
development Verification
& Validation Product
& Process Quality Assurance Configuration
Management Environment :
CASE IDEAL (Computer Associates) DB2, Platinum |
|
|
Resources |
5
persons |
|
|
Results |
Application
delivery with guidelines |
|
|
1995, Jun |
ALCATEL CIT / Direction des Réalisations (DR) |
|
|
Position |
Project
Manager |
|
|
Mission |
SCM Business Process Reengineering Project Organizational
Process Performance Quantitative
Project Management Requirements
development Verification
& Validation Product
& Process Quality Assurance Configuration
Management Environment :
CASE IDEAL (Computer Associates) DB2, Platinum |
|
|
Resources |
8
persons |
|
|
Results |
Application
delivery with guidelines |
|
|
1994, Oct |
ALCATEL CIT / Etudes et Développements (SED) |
|
|
Position |
Project
Manager |
|
|
Mission |
Migration
from a IDMS environment to a Relational environment Requirements
Management, Project Planning, Monitoring & Control Organizational
Process Performance Quantitative
Project Management Requirements
development Verification
& Validation Product
& Process Quality Assurance Configuration
Management Measurement According
to ASMODEE (ALCATEL ISO certified Method) Quality
Plan Development
plan Non
regression test Milestone
verbalization Application
delivery |
|
|
Resources |
12
engineers |
|
|
Results |
Service
delivery |
|
|
1994, Jan |
ALCATEL
RADIOTELEPHONE / DSI |
|
|
Position |
Project
Manager |
|
|
Mission |
Analysis
axis setting up in ERP TOLAS Finance (OSCIRCO : business grouping) Assist
accounting services and financial direction Requirements
development Verification
& Validation Configuration
Management |
|
|
Resources |
Autonomous |
|
|
Results |
New
OSCIRCO axis in the ERP |
|
|
1992, Oct |
ALCATEL CIT / Service Informatique
Administratif et Financier (SIAF) |
|
|
Position |
Project
Manager |
|
|
Mission |
ALCATEL Referential of Analytics Imputations - BPR Requirements
development, Verification & Validation, Configuration Management Environment :
CASE IDEAL (Computer Associates) DB2, Platinum |
|
|
Resources |
Autonomous |
|
|
Results |
Solution
delivery |
|
|
1992, Jan |
ALCATEL CIT / Service Informatique Financière
(SIF) |
|
|
Position |
Project
Manager |
|
|
Mission |
Subsidiary
(CONVERTERS) integration in ERP TOLAS FINANCE Requirements development, Verification &
Validation, Configuration Management |
|
|
Resources |
Autonomous |
|
|
Results |
Service delivery |
|
|
1991, Sep |
Direction Générale des Impôts / Service de
l'Organisation et de l'Informatique II° ss-bur (DGI SOI) |
|
|
Position |
Project
Manager |
|
|
Mission |
Setting
up a taxation application for offices In
coordination with the headquarter (Quai de Bercy), define taxation pre
printed Prepare
next campaign Define
statistics and indicators Requirements
development Verification
& Validation Configuration
Management |
|
|
Resources |
5
persons |
|
|
Results |
Solution
delivery |
|
|
1991, May |
ALCATEL CIT Direction
des Services Economiques et Financiers (DSEF) |
|
|
Position |
External
Auditor |
|
|
Mission |
To
refine the financial policy of the group, organizational audit (Export
contracts analyse, contractual links with COFACE, data processing) |
|
|
Resources |
Autonomous |
|
|
Results |
Audit
report and proposition |
|
|
1991, Jan |
ALCATEL CIT /
Informatique Financière (SIF) |
|
|
Position |
Analyst Engineer |
|
|
Mission |
Requirements
development Verification
& Validation Environment : ERP TOLAS Finance (GSI) |
|
|
Resources |
Autonomous |
|
|
Results |
Budget
integration |
|
|
1990, May |
Europe Computer
System (ECS) |
|
|
Position |
Analyst
Engineer |
|
|
Mission |
GENCOD
settlement (OLAP & Batchs LOGISTICS programs) Configuration
Management, Verification & Validation, Measurement Environment :
CASE PRINCIPIA (SEMA METRA) IDMS DB2 |
|
|
Resources |
Autonomous |
|
|
Results |
Impact
analysis Non
regression test Solution
Delivery |
|
|
1989, Dec |
Avions Marcel Dassault - Breguet Aviation
(AMD-BA) |
|
|
Position |
Analyst
Engineer |
|
|
Mission |
OLAP
information system evolution (propositions management, versioning management) Allocation
and tasks dispatching Integration
Test and Validation Test according to the waterfall cycle Organizational
Process Performance Configuration
Management Measurement Environment :
CASE TELON IMS DB/DC DL1/PL1 |
|
|
Resources |
10
engineers |
|
|
Results |
Solution
delivery |
|
|
1988, Dec |
Défense Nationale - DEMSAT - Direction de
l'Enseignement Militaire Supérieur Scientifique et Technique (DEMSST) |
|
|
Position |
Teacher,
Analyst |
|
|
Mission |
Training
trainees officers to languages Call
for tender Business
Modeling for SAGES project (administrative and financial management of the
staff, follow up of trainees officers) |
|
|
Resources |
Team
reduced to 4 persons |
|
|
Results |
Conceptual
Models |
|
|
1988, Mar |
COGITEL FORUM |
|
|
Position |
Telematic
Conceptor |
|
|
Mission |
Telematic service « le centre de danse des marais » |
|
|
Results |
Minitel
service |
|
Education
|
|
|
1987, Sep |
CNAM Paris |
|
1985, Sep |
Institut Universitaire Privé d'Informatique |
Professional
Training
|
|
|
2002, May |
AFOGEC institute |
|
1992 |
ALCATEL training center ASMODEE quality method, project management |
Skills
ability
|
|
|
|
Adaptability,
flexibility, ability to work with deadlines and to prioritise, team spirit,
dynamism, perfectionism |
Technical
skills
|
|
|
Software: |
PMW, MSProject,
Word, Excel, PowerPoint, Visio, MEGA, AMC designor, Access, FrontPage,
Dreamweaver, Smartsuite Lotus, Docs Open, Rational Rose. |
|
OS, DBMS, Standards: |
WINDOWS, UNIX,
LINUX, MVS, AIX, SUN, DB2, ORACLE, ISO, J2EE, SQL, HTML, XML |
|
Best Practices, Norms, Methods: |
CMM, CMMI,
SPICE, ISO, MERISE, UML, UP, RUP. |
Languages
|
|
|
French English |
Native speaker Fluent written,
operational spoken |
Jean-Gabriel DIAN
06 09 47 92 49
PRINCIPES CLES, FACTEURS CLES DE SUCCES, AVANTAGES
CMMI OVERVIEW PRACTICES
ORIENTED
CMMI PROCESS AREA
INTERACTIONS
Ma démarche d’accompagnement dans l’orchestration et la conduite de projet est basée sur une expérience d’une quinzaine d’années d’adoption des meilleures pratiques et de l’application de méthodologies et processus de pointe.
Après les cycles en cascade qui s’adaptaient aux projets de type relationnel avec notamment la méthode MERISE, c’est le processus unifié et son extension traduite par le RUP (Rational Unified Process) qui convient davantage aux développements orientés objets et donc à l’évolution technologique basée sur une approche intégrée, itérative et incrémentale, pilotée et orientée métier, fondée sur une architecture en brique à base de composants, et axée sur l’amoindrissement des risques.
RUP est donc ma référence en processus avancés et celle que je préconise pour l’avoir utilisé en tant que membre de l’équipe dirigeante sur un projet e-business complexe mobilisant plus d’une centaine d’ingénieurs.
La présentation ci-dessous a été rédigée principalement à partir de la prise de connaissance et de la restitution d’éléments fondamentaux d’ouvrages de référence élaborés par les gourous du RUP (Philippe KRUCHTEN), mais aussi du processus unifié (Ivar JACOBSON, Grady BOOCH, James RUMBAUGH) et de la richesse d’informations puisée sur le net en guise de compléments : on y retrouvera donc les points essentiels pour assurer une planification efficace et efficiente d’un projet itératif quel que soit son degré de formalisme.
Pour la partie liée au CMMI, l’information synthétisée sous forme de vues et de tableaux a été puisée sur le site du Software Engineering Institute et plus précisément des Rapports Techniques ; de manière à respecter le fond, j’ai volontairement conserver la langue d’origine des documents..
Cette page web vous rassurera si vous êtes à la recherche d’un profil très expérimenté pour assurer la direction ou la co-direction d’un projet d’évolution du système d’information ou tout simplement pour garantir une planification basée sur RUP exercée par un expert ; de la même manière, il m’est possible d’assurer des séminaires de présentation.
Le RUP est :
une méthode de développement logiciel, itérative & incrémentale, centrée sur l’architecture, pilotée par les cas d’utilisation et axée sur la réduction des risques,
un processus de génie logiciel décrivant les rôles et responsabilités, les tâches, les façons de procéder et le planning des activités en articulant les jalons essentiels et les artefacts à produire,
un produit fournissant un processus générique personnalisable permettant d’assembler une vaste gamme de configurations adaptables aux méthodes de développement, à la complexité du projet et à son degré de formalisme.

Le Cycle de RUP et son phasage
Inception
o 1.1. Compréhension du système à construire
o 1.2. Identification de la fonctionnalité essentielle du système
o 1.3. Détermination d’une solution possible
o 1.4. Compréhension des coûts, délais et risques associés au projet
o 1.5. Choix du processus à appliquer et sélection des outils
Elaboration
o 1.1. Compréhension des exigences
o 1.2. Conception, implémentation, validation de l’architecture de référence
o 1.3. Réduction des risques essentiels et estimation des coûts et délais
o 1.4. Raffinement du plan de développement et mise en place de l’environnement
Construction
o 1.1. Minimisation des coûts de développement et obtention d’un degré de parallélisme
o 1.2. Développement itératif d’un produit complet
Transition
o 1.1. Exécution des bêta tests
o 1.2. Formation des utilisateurs
o 1.3. Préparation du site de déploiement et conversion des bases de données opérationnelles
o 1.4. Préparation du lancement
o 1.5. Adhésion des parties prenantes
o 1.6. Amélioration des performances
Principes clés, Facteurs clés de succès, avantages
Principes clés
S’attaquer aux risques le plus tôt possible puis de manière continue,
L’assurance de la valeur de ce que l’on livre au client,
L’orientation résultats avec une forte concentration sur les logiciels exécutables,
La prise en considération du changement en amont du cycle de vie ou d’évolution du projet,
La construction d’une architecture de référence exécutable,
La construction d’un système à base de composants donc flexible, évolutif et simplifiant la réutilisabilité,
Le travail en mode projet,
La qualité en tant que système sous-jacent.
Facteurs clés de succès
L’objectif visé n’et pas de produire un certain nombre d’artefacts ou de réaliser un certain nombre d’activités : il s’agit avant toute chose de se laisser guider par cet esprit et de ne choisir que les éléments qui nous permettront d’adhérer aux principes recommandés dans notre projet en portant une attention toute particulière au degré de formalisme nécessaire.
Avantages
L’approche itérative s’adapte à l’évolution des besoins plus facilement qu’avec la méthode en cascade car l’équipe se concentre sur la production et le test de programmes exécutables dès les premières semaines afin de s’attacher aux besoins essentiels.
L’approche itérative décompose un projet en itérations plus réduites, chacune d’elles se terminant par une phase au cours de laquelle les briques sont intégrées de manière progressive et continue, ce qui facilite l’intégration.
Les risques sont généralement décelés ou traités lors des premières intégrations au moment ou tous les composants des processus sont testés.
Un gain de réactivité et management tactique par la mise sur le marché d’un produit pour contrer le concurrent (le développement itératif permettant d’obtenir rapidement une architecture exécutable.)
Concepts & schéma récapitulatif
Vocabulaire
|
Acteur |
Entité (personne ou autre système) extérieure au système (ou à
l'entreprise) qui interagit avec lui (ou elle.) |
|
Activité |
Unité de travail du RUP que l'on peut demander à un rôle
d'exécuter. Les activités peuvent être composées d'étapes ; elles produisent
ou modifient des artefacts. |
|
Artefact |
Terme général qui désigne toute chose produite ou consommée par
une étape du processus ; en d'autres termes, c'est un élément d'information
qui est produit, modifié ou utilisé par un processus ; il définit un domaine
de responsabilité et est sujet à un contrôle de version. Il peut s'agir d'un
modèle ou d'un document. |
|
Cas d'utilisation |
Représente un ensemble de séquences d'actions qui sont réalisées
par le système et qui produisent un résultat observable intéressant pour un
acteur particulier. |
|
Centré sur l'architecture |
Tout système complexe doit être décomposé en parties modulaires
afin d'en faciliter la maintenance et l'évolution ; cette architecture
(fonctionnelle, logique, matérielle,
…) doit être modélisée et pas seulement documentée en texte. |
|
Cycle |
succession des 4 phases du RUP dont le résultat est une version
externe du produit |
|
Guidé par les cas d'utilisation |
Le projet est mené en tenant compte des besoins et des exigences
des utilisateurs. Les cas d'utilisation du futur système sont identifiés,
décrits avec précision et classés par priorité. |
|
Itératif et incrémental |
Le projet est découpé en
itérations ou étapes de courte durée (de 2 à 4 semaines) qui permettent de
mieux suivre l'avancement global : à la fin de chaque itération, une partie
exécutable du système final est produite de façon incrémentale (par ajout) |
|
Itération |
Séquence distincte d'activités pour laquelle un plan et des
critères d'évalutation ont été définis et produisant une version. |
|
Jalon |
Repère temporel marquant de façon formelle la fin d'une itération
ou d'une phase et correspondant à une version |
|
Maquette |
produit jetable permettant aux utilisateurs d'avoir une vue
concrète mais non définitive de la future interface de l'application ; par la
suite, la maquette pourra intégrer des fonctionnalités de navigation
permettant à l'utilisateur de tester l'enchaînement des écrans (analogie avec
la maquette d'avion qui passe en soufflerie mais qui ne pourra pas voler). |
|
Package |
Mécanisme général de regroupement d'éléments qui peut être
utilisé par ex. pour regrouper des cas d'utilisation, mais aussi des acteurs,
des classes. |
|
Phase |
Intervalle entre 2 jalons majeurs du projet, pendant lequel un
ensemble bien défini d'objectifs est atteint, des artefacts sont produits, et
des décisions sont prises pour passer ou non à la phase suivante |
|
Piloté par les risques |
Les risques majeurs du projet doivent être identifiés au plus tôt
mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce
cadre déterminent les itérations. |
|
Processus de développement |
Définit une séquence d'étapes, partiellement ordonnées, qui
concourent à l'obtention d'un système logiciel ou à l'évolution d'un système
existant |
|
Version |
Sous-ensemble du produit final qui fait l'objet d'une évaluation
lors d'un jalon majeur. Il s'agit d'une version stable et exécutable du
produit, qui s'accompagne des artefacts nécessaires à son utilisation, tels
que des notes de mise à jour ou des instructions d'installation. |
Définition du
cadre du projet Elaboration des
cas d’utilisation critiques Réalisation d’un
ou plusieurs prototypes Estimation de la
charge de travail et des risques Consensus sur
la compréhension commune des besoins Compréhension
du besoin général et détermination de l’effort
Environ 10% de l’effort total


Schéma récapitulatif
Définition,
validation et arrêté de l’architecture Stabilité
de la vision du produit final et de l’architecture Prise en
charge des risques principaux Consensus
sur la réactualisation de la planification, des coûts et de la définition
de projet Spécifications
et élaboration d’une première version exécutable afin de diminuer
certains risques Minimisation
des coûts de développement par l’optimisation des ressources Maintien de la
qualité Réalisation
des versions exécutables Préparation
des parties prenantes Stabilité
et qualité des exécutables Conception et
version Bêta Déploiement
dans l’environnement d’exploitation Atteinte d’un
niveau de stabilité / qualité pour les parties prenantes Satisfaction
des utilisateurs Situation
financière du projet en regard du budget initial Vérification
afin de déterminer si le niveau
de qualité requis par les utilisateurs est atteint 





Environ 30% de l’effort total
Environ 50% de l’effort total
Les derniers 10% de l’effort total
Jean Gabriel DIAN mailto:[email protected] Temps
consacré Attention portée Objectifs Critères
d’évaluation Phase Activités Jalons Livrables
CMMI OVERVIEW
– GOALS ORIENTED
|
|
|
|
|
|
|
|
Level |
PA |
Process Area
Description |
Purpose |
Generic and Specific
Goals |
|
|
2 |
MANAGED |
Requirement Management |
The purpose of RM is to manage the requirements of
the project's products and product components and to identify inconsistencies
between those requirements and the project's plans and work products. |
||
|
Project Planning |
Establish and maintain plans that define project
activities |
||||
|
Project Monitoring and
control |
Provide an understanding of the project’s progress
so that appropriate corrective actions can be taken when the project’s
performance deviates significantly from the plan. |
||||
|
Supplier Agreement
Management |
Manage the acquisition of products from suppliers
for which there exists a formal agreement. |
||||
|
Measurement and
Analysis |
Develop and sustain a measurement capability that is
used to support management information needs. |
||||
|
Process and Product
Quality Assurance |
Provide staff and management with objective insight
into processes and associated work products.
|
||||
|
Configuration
Management |
Establish and maintain the integrity of work
products using configuration identification, configuration control,
configuration status accounting, and configuration audits. |
||||
|
3 |
DEFINED |
Requirements
Development |
Produce and analyze customer, product, and
product-component requirements. |
||
|
Technical Solution |
Design, develop, and implement solutions to
requirements. Solutions, designs, and implementations encompass products,
product components, and product-related life-cycle processes either singly or
in combinations as appropriate. |
||||
|
Product Integration |
Assemble the product from the product components,
ensure that the product, as integrated, functions properly, and deliver the
product. |
||||
|
Verification |
Ensure that selected work products meet their
specified requirements. |
||||
|
Validation |
Demonstrate that a product or product component
fulfills its intended use when placed in its intended environment. |
||||
|
Organizational Process
Focus |
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. |
||||
|
Organizational Process
Definition |
Establish and maintain a usable set of
organizational process assets. |
||||
|
Organizational Training |
Develop the skills and knowledge of people so they
can perform their roles effectively and efficiently. |
||||
|
Integrated Project
Management |
Establish and manage the project and the involvement
of the relevant stakeholders according to an integrated and defined process
that is tailored from the organization's set of standard processes. |
||||
|
Risk Management |
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. |
||||
|
Integrated Teaming |
Form and sustain an integrated team for the
development of work products. |
||||
|
Integrated Supplier
Management |
Proactively identify sources of products that may be
used to satisfy the project’s requirements and to manage selected suppliers
while maintaining a cooperative project-supplier relationship. |
||||
|
Decision Analysis and
Resolution |
Analyze possible decisions using a formal evaluation
process that evaluates identified alternatives against established
criteria. |
||||
|
Organizational
Environment for Integration |
Provide an Integrated Product and Process
Development (IPPD) infrastructure and manage people for integration. |
||||
|
4 |
QUANTATIVELY MANAGED |
Organizational Process
Performance |
Establish and maintain a quantitative understanding
of the performance of the organization’s set of standard processes in support
of quality and process-performance objectives, and to provide the process
performance data, baselines, and models to quantitatively manage the
organization’s projects. |
||
|
Quantitative Project Management |
Quantitatively manage the project’s defined process
to achieve the project’s established quality and process-performance
objectives. |
||||
|
5 |
OPTIMIZING |
Organizational Innovation
and Deployment |
Select and deploy incremental and innovative
improvements that measurably improve the organization's processes and
technologies. The improvements support the organization's quality and
process-performance objectives as derived from the organization's business
objectives. |
||
|
Causal Analysis and
Resolution |
Identify causes of defects and other problems and
take action to prevent them from occurring in the future. |
||||
|
|
|
|
|
|
|
|
|
Categories |
|
Project Management |
|
|
|
|
|
Process Management |
Generic Goals |
||
|
|
|
Engineering |
IPPD specifically |
||
|
|
|
Support |
SS specifically |
||
|
|
|
|
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Obtain an Understanding of Requirements |
|
|
|
DIAN JG |
SP 1.2 |
Obtain Commitment to Requirements |
|
|
|
DIAN JG |
SP 1.3 |
Manage Requirements Changes |
|
|
|
DIAN JG |
SP 1.4 |
Maintain Bidirectional Traceability of Requirements |
|
|
|
DIAN JG |
SP 1.5 |
Identify Inconsistencies between Project Work and Requirements |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Estimate the Scope of the Project |
|
|
|
DIAN JG |
SP 1.2 |
Establish Estimates of Work Product and Task Attributes |
|
|
|
DIAN JG |
SP 1.3 |
Define Project Life Cycle |
|
|
|
DIAN JG |
SP 1.4 |
Determine Estimates of Effort and Cost |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Establish the Budget and Schedule |
|
|
|
DIAN JG |
SP 2.2 |
Identify Project Risks |
|
|
|
DIAN JG |
SP 2.3 |
Plan for Data Management |
|
|
|
DIAN JG |
SP 2.4 |
Plan for Project Resources |
|
|
|
DIAN JG |
SP 2.5 |
Plan for Needed Knowledge and Skills |
|
|
|
DIAN JG |
SP 2.6 |
Plan Stakeholder Involvement |
|
|
|
DIAN JG |
SP 2.7 |
Establish the Project Plan |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Review Plans that Affect the Project |
|
|
|
DIAN JG |
SP 3.2 |
Reconcile Work and Resource Levels |
|
|
|
DIAN JG |
SP 3.3 |
Obtain Plan Commitment |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Monitor Project Planning Parameters |
|
|
|
DIAN JG |
SP 1.2 |
Monitor Commitments |
|
|
|
DIAN JG |
SP 1.3 |
Monitor Project Risks |
|
|
|
DIAN JG |
SP 1.4 |
Monitor Data Management |
|
|
|
DIAN JG |
SP 1.5 |
Monitor Stakeholder Involvement |
|
|
|
DIAN JG |
SP 1.6 |
Conduct Progress Reviews |
|
|
|
DIAN JG |
SP 1.7 |
Conduct Milestone Reviews |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Analyze Issues |
|
|
|
DIAN JG |
SP 2.2 |
Take Corrective Action |
|
|
|
DIAN JG |
SP 2.3 |
Manage Corrective Action |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Determine Acquisition
Type |
|
|
|
DIAN JG |
SP 1.2 |
Select Suppliers |
|
|
|
DIAN JG |
SP 1.3 |
Establish Supplier Agreements |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Review COTS Products |
|
|
|
DIAN JG |
SP 2.2 |
Execute the Supplier Agreement |
|
|
|
DIAN JG |
SP 2.3 |
Accept the Acquired Product |
|
|
|
DIAN JG |
SP 2.4 |
Transition Products |
|
|
|
DIAN JG |
SG 1 Align Measurement and Analysis
Activities [PA154.IG101] |
|
||
|
DIAN JG |
SP 1.1 |
Establish Measurement Objectives |
|
|
|
DIAN JG |
SP 1.2 |
Specify Measures |
|
|
|
DIAN JG |
SP 1.3 |
Specify Data Collection and Storage Procedures |
|
|
|
DIAN JG |
SP 1.4 |
Specify Analysis Procedures |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Collect Measurement Data |
|
|
|
DIAN JG |
SP 2.2 |
Analyze Measurement Data |
|
|
|
DIAN JG |
SP 2.3 |
Store Data and Results |
|
|
|
DIAN JG |
Communicate Results |
|
||
|
DIAN JG |
SG 1 Objectively Evaluate
Processes and Work Products
[PA145.IG101] |
|
||
|
DIAN JG |
SP 1.1 |
Objectively Evaluate Processes |
|
|
|
DIAN JG |
SP 1.2 |
Objectively Evaluate Work Products and Services |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Communicate and Ensure Resolution of Non compliance Issues |
|
|
|
DIAN JG |
SP 2.2 |
Establish Records |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Identify Configuration Items |
|
|
|
DIAN JG |
SP 1.2 |
Establish a Configuration Management System |
|
|
|
DIAN JG |
SP 1.3 |
Create or Release Baselines |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Track Change Requests |
|
|
|
DIAN JG |
SP 2.2 |
Control Configuration Items |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Establish Configuration Management Records |
|
|
|
DIAN JG |
SP 3.2 |
Perform Configuration Audits |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Elicit Needs |
|
|
|
DIAN JG |
SP 1.2 |
Develop the Customer Requirements |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Establish Product and Product-Component Requirements |
|
|
|
DIAN JG |
SP 2.2 |
Allocate Product-Component Requirements |
|
|
|
DIAN JG |
SP 2.3 |
Identify Interface Requirements |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Establish Operational Concepts and Scenarios |
|
|
|
DIAN JG |
SP 3.2 |
Establish a Definition of Required Functionality |
|
|
|
DIAN JG |
SP 3.3 |
Analyze Requirements |
|
|
|
DIAN JG |
SP 3.4 |
Analyze Requirements to Achieve Balance |
|
|
|
DIAN JG |
SP 3.5 |
Validate Requirements with Comprehensive Methods |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Develop Detailed Alternative Solutions and Selection Criteria |
|
|
|
DIAN JG |
SP 1.2 |
Evolve Operational Concepts and Scenarios |
|
|
|
DIAN JG |
SP 1.3 |
Select Product-Component Solutions |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Design the Product or Product Component |
|
|
|
DIAN JG |
SP 2.2 |
Establish a Technical Data Package |
|
|
|
DIAN JG |
SP 2.3 |
Design Interfaces Using Criteria |
|
|
|
DIAN JG |
SP 2.4 |
Perform Make, Buy, or Reuse Analyses |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Implement the Design |
|
|
|
DIAN JG |
SP 3.2 |
Develop Product Support Documentation |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Determine Integration Sequence |
|
|
|
DIAN JG |
SP 1.2 |
Establish the Product Integration Environment |
|
|
|
DIAN JG |
SP 1.3 |
Establish Product Integration Procedures and Criteria |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Review Interface Descriptions for Completeness |
|
|
|
DIAN JG |
SP 2.2 |
Manage Interfaces |
|
|
|
DIAN JG |
SG 3 Assemble Product Components and
Deliver the Product [PA147.IG103] |
|
||
|
DIAN JG |
SP 3.1 |
Confirm Readiness of Product Components for Integration |
|
|
|
DIAN JG |
SP 3.2 |
Assemble Product Components |
|
|
|
DIAN JG |
SP 3.3 |
Evaluate Assembled Product Components |
|
|
|
DIAN JG |
SP 3.4 |
Package and Deliver the Product or Product Component |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Select Work Products for Verification |
|
|
|
DIAN JG |
SP 1.2 |
Establish the Verification Environment |
|
|
|
DIAN JG |
SP 1.3 |
Establish Verification Procedures and Criteria |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Prepare for Peer Reviews |
|
|
|
DIAN JG |
SP 2.2 |
Conduct Peer Reviews |
|
|
|
DIAN JG |
SP 2.3 |
Analyze Peer Review Data |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Perform Verification |
|
|
|
DIAN JG |
SP 3.2 |
Analyze Verification Results and Identify Corrective Action |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Select Products for Validation |
|
|
|
DIAN JG |
SP 1.2 |
Establish the Validation Environment |
|
|
|
DIAN JG |
SP 1.3 |
Establish Validation Procedures and Criteria |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Perform Validation |
|
|
|
DIAN JG |
SP 2.2 |
Analyze Validation Results |
|
|
|
DIAN JG |
SG 1 Determine Process-Improvement
Opportunities [PA152.IG101] |
|
||
|
DIAN JG |
SP 1.1 |
Establish Organizational Process Needs |
|
|
|
DIAN JG |
SP 1.2 |
Appraise the Organization’s Processes |
|
|
|
DIAN JG |
SP 1.3 |
Identify the Organization's Process Improvements |
|
|
|
DIAN JG |
SG 2 Plan and Implement
Process-Improvement Activities
[PA152.IG102] |
|
||
|
DIAN JG |
SP 2.1 |
Establish Process Action Plans |
|
|
|
DIAN JG |
SP 2.2 |
Implement Process Action Plans |
|
|
|
DIAN JG |
SP 2.3 |
Deploy Organizational Process Assets |
|
|
|
DIAN JG |
SP 2.4 |
Incorporate Process-Related Experiences into the Organizational
Process Assets |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Establish Standard Processes |
|
|
|
DIAN JG |
SP 1.2 |
Establish Life-Cycle Model Descriptions |
|
|
|
DIAN JG |
SP 1.3 |
Establish Tailoring Criteria and Guidelines |
|
|
|
DIAN JG |
SP 1.4 |
Establish the Organization’s Measurement Repository |
|
|
|
DIAN JG |
SP 1.5 |
Establish the Organization’s Process Asset Library |
|
|
|
DIAN JG |
SG 1 Establish an Organizational
Training Capability [PA158.IG101] |
|
||
|
DIAN JG |
SP 1.1 |
Establish the Strategic Training Needs |
|
|
|
DIAN JG |
SP 1.2 |
Determine Which Training Needs Are the Responsibility of the
Organization |
|
|
|
DIAN JG |
SP 1.3 |
Establish an Organizational Training Tactical Plan |
|
|
|
DIAN JG |
Establish Training Capability |
|
||
|
DIAN JG |
SG 2 Provide Necessary
Training [PA158.IG102] |
|
||
|
DIAN JG |
SP 2.1 |
Deliver Training |
|
|
|
DIAN JG |
SP 2.2 |
Establish Training Records |
|
|
|
DIAN JG |
SP 2.3 |
Assess Training Effectiveness |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Establish the Project’s Defined Process |
|
|
|
DIAN JG |
SP 1.2 |
Use Organizational Process Assets for Planning Project Activities |
|
|
|
DIAN JG |
SP 1.3 |
Integrate Plans |
|
|
|
DIAN JG |
SP 1.4 |
Manage the Project Using the Integrated Plans |
|
|
|
DIAN JG |
SP 1.5 |
Contribute to the Organizational Process Assets |
|
|
|
DIAN JG |
SG 2 Coordinate and Collaborate with
Relevant Stakeholders [PA167.IG102] |
|
||
|
DIAN JG |
SP 2.1 |
Manage Stakeholder Involvement |
|
|
|
DIAN JG |
SP 2.2 |
Manage Dependencies |
|
|
|
DIAN JG |
SP 2.3 |
Resolve Coordination Issues |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Determine Risk Sources and Categories |
|
|
|
DIAN JG |
SP 1.2 |
Define Risk Parameters |
|
|
|
DIAN JG |
SP 1.3 |
Establish a Risk Management Strategy |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Identify Risks |
|
|
|
DIAN JG |
SP 2.2 |
Evaluate, Categorize, and Prioritize Risks |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 3.1 |
Develop Risk Mitigation Plans |
|
|
|
DIAN JG |
SP 3.2 |
Implement Risk Mitigation Plans |
|
|
|
|
|
|||
|
|
SP 1.1 |
Identify Team Tasks |
|
|
|
|
SP 1.2 |
Identify Needed Knowledge and Skills |
|
|
|
|
SP 1.3 |
Assign Appropriate Team Members |
|
|
|
|
|
|||
|
|
SP 2.1 |
Establish a Shared Vision |
|
|
|
|
SP 2.2 |
Establish a Team Charter |
|
|
|
|
SP 2.3 |
Define Roles and Responsibilities |
|
|
|
|
SP 2.4 |
Establish Operating Procedures |
|
|
|
|
SP 2.5 |
Collaborate among Interfacing Teams |
|
|
|
|
|
|||
|
|
SP 1.1 |
Analyze Potential Sources of Products |
|
|
|
|
SP 1.2 |
Evaluate and Determine Sources of Products |
|
|
|
|
|
|||
|
|
SP 2.1 |
Monitor Selected Supplier Processes |
|
|
|
|
SP 2.2 |
Evaluate Selected Supplier Work Products |
|
|
|
|
SP 2.3 |
Revise the Supplier Agreement or Relationship |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Establish Guidelines for Decision Analysis |
|
|
|
DIAN JG |
SP 1.2 |
Establish Evaluation Criteria |
|
|
|
DIAN JG |
SP 1.3 |
Identify Alternative Solutions |
|
|
|
DIAN JG |
SP 1.4 |
Select Evaluation Methods |
|
|
|
DIAN JG |
SP 1.5 |
Evaluate Alternatives |
|
|
|
DIAN JG |
SP 1.6 |
Select Solutions |
|
|
|
|
|
|||
|
|
SP 1.1 |
Establish the Organization’s Shared Vision |
|
|
|
|
SP 1.2 |
Establish an Integrated Work Environment |
|
|
|
|
SP 1.3 |
Identify IPPD-Unique Skill Requirements |
|
|
|
|
|
|||
|
|
SP 2.1 |
Establish Leadership Mechanisms |
|
|
|
|
SP 2.2 |
Establish Incentives for Integration |
|
|
|
|
SP 2.3 |
Establish Mechanisms to Balance Team and Home Organization
Responsibilities |
|
|
|
DIAN JG |
SG 1 Establish Performance Baselines and
Models [PA164.IG101] |
|
||
|
DIAN JG |
SP 1.1 |
Select Processes |
|
|
|
DIAN JG |
SP 1.2 |
Establish Process Performance Measures |
|
|
|
DIAN JG |
SP 1.3 |
Establish Quality and Process-Performance Objectives |
|
|
|
DIAN JG |
SP 1.4 |
Establish Process Performance Baselines |
|
|
|
DIAN JG |
SP 1.5 |
Establish Process Performance Models |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Establish the Project’s Objectives |
|
|
|
DIAN JG |
SP 1.2 |
Compose the Defined Process |
|
|
|
DIAN JG |
SP 1.3 |
Select the Subprocesses that Will Be Statistically Managed |
|
|
|
DIAN JG |
SP 1.4 |
Manage Project Performance |
|
|
|
DIAN JG |
SG 2 Statistically Manage Subprocess
Performance [PA165.IG102] |
|
||
|
DIAN JG |
SP 2.1 |
Select Measures and Analytic Techniques |
|
|
|
DIAN JG |
SP 2.2 |
Apply Statistical Methods to Understand Variation |
|
|
|
DIAN JG |
SP 2.3 |
Monitor Performance of the Selected Subprocesses |
|
|
|
DIAN JG |
SP 2.4 |
Record Statistical Management Data |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Collect and Analyze Improvement Proposals |
|
|
|
DIAN JG |
SP 1.2 |
Identify and Analyze Innovations |
|
|
|
DIAN JG |
SP 1.3 |
Pilot Improvements |
|
|
|
DIAN JG |
SP 1.4 |
Select Improvements for Deployment |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Plan the Deployment |
|
|
|
DIAN JG |
SP 2.2 |
Manage the Deployment |
|
|
|
DIAN JG |
SP 2.3 |
Measure Improvement Effects |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 1.1 |
Select Defect Data for Analysis |
|
|
|
DIAN JG |
SP 1.2 |
Analyze Causes |
|
|
|
DIAN JG |
|
|||
|
DIAN JG |
SP 2.1 |
Implement the Action Proposals |
|
|
|
DIAN JG |
SP 2.2 |
Evaluate the Effect of Changes |
|
|
|
DIAN JG |
SP 2.3 |
Record Data |
|
|
|
|
|
|
|
|
|
|
All PAs |
GG 2 Institutionalize a Managed / Defined Process [CL103/104.GL101] |
|
|
|
|
GP 2.1 |
Establish an Organizational Policy |
(CO 1) |
|
|
|
GP 2.2 |
Plan the Process |
(AB 1) |
|
|
|
GP 2.3 |
Provide Resources |
(AB 2) |
|
|
|
GP 2.4 |
Assign Responsibility |
(AB 3) |
|
|
|
GP 2.5 |
Train People |
(AB 4) |
|
|
|
GP 2.6 |
Manage Configurations |
(DI 1) |
|
|
|
GP 2.7 |
Identify and Involve Relevant Stakeholders |
(DI 2) |
|
|
|
GP 2.8 |
Monitor and Control the Process |
(DI 3) |
|
|
|
GP 2.9 |
Objectively Evaluate Adherence |
(VE 1) |
|
|
|
GP 2.10 |
Review Status with Higher Level Management |
(VE 2) |
|
|
|
GG 3 Institutionalize a Defined Process [CL104.GL101] |
|
||
|
|
GP 3.1 |
Establish a Defined Process |
|
|
|
|
GP 3.2 |
Collect Improvement Information |
|
|
CMMI
PROCESS AREA INTERACTIONS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PAs |
OPF |
OPD |
OT |
OPP |
OID |
PP |
PMC |
SAM |
IPM |
RSKM |
IT |
ISM |
QPM |
RD |
RM |
TS |
PI |
VER |
VAL |
CM |
PPQA |
MA |
OEI |
DAR |
CAR |
|
|
OPF |
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OPD |
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OT |
|
X |
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
OPP |
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
OID |
X |
X |
X |
X |
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
X |
|
|
|
PP |
|
|
|
|
|
|
|
|
|
X |
|
|
|
X |
X |
X |
|
|
|
|
|
|
|
|
|
|
|
PMC |
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
SAM |
|
|
|
|
|
|
X |
|
|
|
|
|
|
X |
X |
X |
|
|
|
|
|
|
|
|
|
|
|
IPM |
|
X |
|
|
|
X |
X |
|
|
|
X |
|
|
|
|
|
|
X |
|
|
|
X |
X |
|
|
|
|
RSKM |
|
|
|
|
|
X |
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
IT |
|
|
|
|
|
X |
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
ISM |
|
|
|
|
|
X |
|
X |
X |
X |
|
|
|
X |
X |
|
|
|
|
|
|
|
|
|
|
|
|
QPM |
|
X |
|
X |
X |
|
X |
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
X |
|
|
RD |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
X |
X |
X |
X |
X |
X |
|
|
|
|
|
|
|
RM |
|
|
|
|
|
X |
X |
|
|
X |
|
|
|
X |
|
X |
|
|
|
X |
|
|
|
|
|
|
|
TS |
|
|
|
|
X |
|
|
|
|
|
|
|
|
X |
X |
|
|
X |
|
|
|
|
|
X |
|
|
|
PI |
|
|
|
|
|
|
|
X |
|
X |
|
|
|
X |
|
X |
|
X |
X |
X |
|
|
|
X |
|
|
|
VER |
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
X |
|
|
|
X |
|
|
|
|
|
|
|
|
VAL |
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
X |
|
X |
|
|
|
|
|
|
|
|
|
CM |
|
|
|
|
|
X |
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
PPQA |
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
MA |
|
X |
|
|
|
X |
X |
|
|
|
|
|
X |
X |
X |
|
|
|
|
X |
|
|
|
|
|
|
|
OEI |
|
X |
X |
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DAR |
|
|
|
|
|
X |
|
|
X |
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CAR |
|
|
|
|
X |
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adequate,
Appropriate, As Needed
|
These words are
used so that you can interpret goals and practices in light of your
organization’s business objectives. When using any CMMI model, you must
interpret the practices so that they work for your organization. These terms
are used in goals and practices where certain activities may not be done all
of the time. |
|
Establish and
Maintain |
When using a
CMMI model, you will encounter goals and practices that include the phrase
“establish and maintain.” This phrase connotes a meaning beyond the component
terms; it includes documentation and usage. For example, “Establish and
maintain an organizational policy for planning and performing the
organizational process focus process” means that not only must a policy be
formulated, but it also must be documented and it must be used throughout the
organization. |
|
Customer |
A “customer” is
the party (individual, project, or organization) responsible for accepting
the product or for authorizing payment. The customer is external to the
project, but not necessarily external to the organization. The customer may
be a higher level project. Customers are a subset of stakeholders. |
|
Stakeholder |
A “stakeholder”
is a group or individual that is affected by or in some way accountable for the
outcome of an undertaking. Stakeholders may include project members,
suppliers, customers, end users, and others.
|
|
Relevant
Stakeholder |
The term
“relevant stakeholder” is used to designate a stakeholder that is identified
for involvement in specified activities and is included in an appropriate
plan. (See the Plan Stakeholder Involvement specific practice in the Project
Planning process area and the Identify and Involve Relevant Stakeholders
generic practice.) |
|
Manager |
Within the scope
of CMMI models, the word “manager” refers to a person who provides technical
and administrative direction and control to those performing tasks or
activities within the manager’s area of responsibility. The traditional
functions of a manager include planning, organizing, directing, and
controlling work within an area of responsibility. |
|
Project
Manager |
Person
responsible for planning, directing, controlling, structuring, and motivating
the project. The project manager is responsible for satisfying the customer. |
|
Senior
Manager |
The term “senior
manager,” when used in a CMMI model, refers to a management role at a high
enough level in an organization that the primary focus of the person filling the
role is the long-term vitality of the organization, rather than short-term
project and contractual concerns and pressures. A senior manager has
authority to direct the allocation or reallocation of resources in support of
organizational process-improvement effectiveness. A senior manager can be any manager who satisfies this
description, including the head of the organization. Synonyms for “senior
manager” include “executive” and “top-level manager.” However, these synonyms
are not used in CMMI models to ensure consistency and usability. |
|
Shared Vision |
Common
understanding of guiding principles including mission, objectives, expected
behavior, values, and final outcomes, which are developed and used by a
group, such as an organization, project, or team. Creating a shared vision
requires that all people in the group have an opportunity to speak and be
heard about what really matters to them.
|
|
Organization |
An organization
is typically an administrative structure in which people collectively manage
one or more projects as a whole, and whose projects share a senior manager
and operate under the same policies. However, the word “organization” as used
throughout CMMI models can apply to one person who performs a function in a
small organization that might be performed by a group of people in a large
organization. See the definition of “organizational unit” in Appendix C, the
glossary. |
|
Enterprise |
When CMMI models
refer to an “enterprise,” they illustrate the larger entity not always reached
by the word “organization.” Companies may consist of many organizations in
many different locations with different customers. The word “enterprise”
refers to the full composition of companies. |
|
Development |
The word “development,”
when used in the CMMI Product Suite, implies not only development activities,
but also maintenance activities. Projects that benefit from the best
practices of CMMI can focus on maintenance, development, or both. |
|
Discipline |
The word “discipline,”
when used in the CMMI Product Suite, refers to the bodies of knowledge
available to you when selecting a CMMI model (e.g., systems engineering). The
CMMI Product Team envisions that other bodies of knowledge will be integrated
into the CMMI Framework. |
|
Project |
Managed
set of interrelated resources that delivers one or more products to a
customer or end user. This set of resources has a definite beginning and end
and typically operates according to a plan. Such a plan is frequently
documented and specifies the product to be delivered or implemented, the
resources and funds used, the work to be done, and a schedule for doing the
work. A project can be composed of projects.
|
|
Product |
Used throughout the
CMMI Product Suite to mean any tangible output or service that is a result of
a process and that is intended for delivery to a customer or end user. A
product is a work product that is delivered to the customer |
|
Work Product |
The term
“work product” is used throughout the CMMI Product Suite to mean any artifact
produced by a process. These artifacts can include files, documents, parts of
the product, services, processes, specifications, and invoices. Examples of
processes to be considered as work products include a manufacturing process,
a training process, and a disposal process for the product. A key distinction
between a work product and a product component is that a work product need
not be engineered or part of the end product. In various places
in CMMI models, you will see the phrase “work products and services.” Even
though the definition of work product includes services, this phrase is used
to emphasize the inclusion of services in the discussion. |
|
Product
Component |
The term
“product component” is used as a relative term in CMMI models. In CMMI,
product components are lower level components of the product; product
components are integrated to “build” the product. There may be multiple
levels of product components. A product component is any work product that
must be engineered (requirements defined and designs developed and
implemented) to achieve the intended use of the product throughout its life. Product
components are parts of the product delivered to the customer and may serve
in the manufacture or use of the product. A car engine and a piston are
examples of product components of a car (the product). The manufacturing
process to machine the piston, if delivered to the customer, is a product
component. However, if the manufacturing process is used to machine the
piston delivered to the customer, the manufacturing process is a work
product, not a product component. The repair process used to remove the
engine from the car for repair and the process used to train the mechanic to
repair the engine are typically examples of product components because they
are delivered to the customer. |
|
Appraisal |
In the CMMI
Product Suite, an “appraisal” is an examination of one or more processes by a
trained team of professionals using an appraisal reference model as the basis
for determining strengths and weaknesses.
|
|
Assessment |
In the CMMI
Product Suite, an “assessment” is an appraisal that an organization does to
and for itself for the purposes of process improvement. The word “assessment”
is also used in the CMMI Product Suite in an everyday English sense (e.g.,
risk assessment). |
|
Tailoring
Guidelines |
Tailoring
a process makes, alters, or adapts the process description for a particular end.
For example, a project establishes its defined process by tailoring from the
organization’s set of standard processes to meet the objectives, constraints,
and environment of the project. “Tailoring
guidelines” are used in CMMI models to enable organizations to implement
standard processes appropriately in their projects. The organization’s set of
standard processes is described at a general level that may not be directly
usable to perform a process. Tailoring
guidelines aid those who establish the defined processes for projects.
Tailoring guidelines cover (1) selecting a standard process, (2) selecting an
approved life-cycle model, and (3) tailoring the selected standard process
and life-cycle model to fit project needs. Tailoring guidelines describe what
can and cannot be modified and identify process components that are
candidates for modification. |
|
Verification |
Although
“verification” and “validation” at first seem quite similar in CMMI models,
on closer inspection you can see that each addresses different issues.
Verification confirms that work products properly reflect the requirements
specified for them. In other words, verification ensures that “you built it
right.” |
|
Validation |
Validation confirms
that the product, as provided, will fulfill its intended use. In other words,
validation ensures that “you built the right thing.” |
|
Goal |
A “goal” is a
required CMMI component that can be either a generic goal or a specific goal.
When you see the word “goal” in a CMMI model, it always refers to model
components (for example, generic goal, specific goal). (In Chapter 2, see the
definitions of “specific goal” and “generic goal” and descriptions of how
these terms are used in the CMMI Product Suite.) |
|
Objective |
When used as a
noun in the CMMI Product Suite, the term “objective” replaces the word “goal”
as used in its common everyday sense, since the word “goal” is reserved for
use when referring to the CMMI model components called “specific goals” and
“generic goals.” |
|
Quality and
Process-Performance Objectives |
The phrase
“quality and process-performance objectives” covers objectives and
requirements for product quality, service quality, and process performance.
Process performance objectives include product quality; however, to emphasize
the importance of product quality, the phrase “quality and
process-performance objectives” is used in the CMMI Product Suite rather than
just “process performance objectives.”
|
|
Standard |
When you see the
word “standard” used as a noun in a CMMI model, it refers to the formal
mandatory requirements developed and used to prescribe consistent approaches
to development (for example, ISO standards, IEEE standards, organizational
standards). Instead of using “standard” in its common everyday sense, we
chose another term that means the same thing (for example, typical,
traditional, usual, customary). |