WHAT IS CMMI?
is a methodology for product development from specification to maintenance. Originally
CMM was a software methodology ordered by DoD
(Department of Defence) to SEI
(Software Engineering Institute of Carnegie Mellon university) because of too
many bugs in sub-contracted software. CMM compete with the SPICE standard (ISO/CEI
TR 15 504) and was updated to CMMI,
the ‘I‘ stands for Integrated: all disciplines
are concerned and Amplifications (notes per disciplines) were added.
Structure of CMMI
CMMI is composed of 22 Process Area (PA means
methodology axis) composed of Goals (generic and specific) composed in Practices
(specific and generic activities) and expected Workproducts (output documents).
CMMI came with several models (restricted to software or not, staged or
continuous) with different levels of compliance.
In the Staged model all PA must have the same level: useful
to know the global level of a supplier. 5 Maturity levels are defined (1:
Initial/level unknown, 2: Managed, 3: Defined, 4: Quantitatively Managed, 5:
Optimizing). While level 2 to 4
are interesting for a sub-contractor evaluation, level 5 is only interesting
for the certified Organization. At each level, a set of Process Area is
In Continuous model, PA’s level is evaluated
separately: this is useful for internal methodology improvements. PA has 6
levels of Capability (0: Incomplete, 1: Performed, 2: Managed, 3: Defined, 4:
Quantitatively Managed, 5: Optimizing).
Staged Level 2
- Project Planning / Project Monitoring &
Control: Deals with the estimation
of the work (and workload) to build a detailed and charged planning. PMC
deals with the planning monitoring.
- Configuration Management: Deals with the configuration management of workproducts
and deliverables of the project. Usually needs the help of a specific
- Requirement Management: Deals with spotting requirements from
specification to design files (source code for software) and maintaining a
bi-directional dependency link in order ensure requirement coverage.
Usually needs the help of a specific tool.
- Process & Product Quality Assurance: Deals with process and workproduct audits and associated
reporting and escalation.
- Measurement & Analysis: Define measurement goals for the organisation
and refine theses into well defined and easy (automated if possible)
- Supplier Agreement Management: Manage suppliers from contract to maintenance,
this includes also buying of tools, components, test bench …
These Goals manage institutionalization of PAs: Level
2: Policy, planning, resources, responsibilities, training, configuration
management, stakeholders, monitoring, auditing, review with management; Level
3: Process definition, collect improvement. There are additional specific GG for
CMMI is not very innovative but helps to
structure methodology improvements. CMMI is not adapted to small R&D
structures (less than 50 peoples) has it requires a lot of work to establish
and maintain. For these structures, CMMI can be considered as a guide but a
need of a ‘simplified CMMI’ is still present. Reaching a new CMMI level usually
needs 1 or 2 years, 10 to 25% of increased resources, several support tools and
a budget (from 30 000€). This means that management must be fully concerned by
CMMI evaluation in order to actively support it. Trying to apply CMMI in a too
small structure can be a disaster. CMMI level 2-3 is required to master sub-contracting,
delocalization and reduce risks. Download. ▇
“+SAFE” CMMI-DEV 1.2 Add-On
SEI (with the help of Australian DoD) released
a CMMI add-on for safety-critical product development in order to evaluate
suppliers of safety-critical products. But it is also a guide for developing
and maintaining these products. People familiar to CMMI will feel at home as it
uses the same structure than CMMI.
Structure of +SAFE
+SAFE is composed of 2 Process Areas (PA) added
to continuous CMMI-DEV. As +SAFE claims to be standalone some overlapping with
CMMI exists. Safety Management is a
safety add-on to Project Management, while Safety
Engineering is an add-on of Engineering PA. As in CMMI, each PA has Specific
Goals and CMMI Generic Goals.
Safety Management (PA)
Safety Management is linked to following PA:
Project Planning, Monitoring & Control, Supplier Agreement Management, Measurement
& Analysis, Requirement Management and level 3 PA: RM, CAR, DAR, OT, RD,
VER. Goal is to plan, monitor, measure the performance and correct deviations
of safety activities including suppliers. Specific goals are:
- Develop Safety Plans: identifying
contractual, legal, regulatory, performance and requirements from hazard and
risk assessment on project. Requirements are categorized & documented with
source’s traceability. Criteria is defined depending of safety target/level. Safety
organization structure and a Safety plan are available.
- Monitor Safety Incidents: monitor &
resolve safety incidents by reviewing and updating hazard analysis and risk
assessment in safety plan.
- Manage Safety-Related Suppliers:
Supplier agreements include safety requirements with traceability and safety
assurance. Case of Off The Shelf products are taken into consideration. Suppliers
participate to organization’s system safety meetings.
Safety Engineering (PA)
Safety Engineering is linked to following
PA: Configuration Management, Product & Process Quality Assurance,
Requirement Management and level 3 PA: RD, DAR, RM, TS, VAL, VER. Its goal is to
ensure that safety is adequately addressed throughout all stages of engineering
process. Specific goals are:
- Identify Hazard,
accidents & Hazards’ sources: Product’s scope, interfaces and functionality are documented. Hazard
identification & analysis are documented. HAZOP and FFA are conducted. Team
- Analyse Hazards &
perform Risk assessment: for each hazard, possible causes, likelihood & consequences, risk
assessment are documented. FMEA and Fault Tree Analysis are done.
- Define & maintains
Safety requirements: Document Safety requirements from hazard identification & analysis
and risk assessments. For each Safety requirement, a quantitative/qualitative
target is defined. Safety requirements are allocated to components and
- Design for safety: A safety principle is selected. Solutions &
development process (+ methods & tools) based on safety principle are
defined. Safety assurance evidence (process audit reports, reviews,
traceability matrix, test reports…) are collected. Impact analysis is done for each
change to requirements or design.
- Support Safety
acceptance: An hazard log is created
& maintained. A safety case (safety argument & related evidences) is
documented. Product safety is tested and validated. Periodic independent
evaluations are conducted (product, process, safety case).
+SAFE is not really a
standalone document but a good CMMI add-on to define a safety-critical development
methodology for a CMMI-DEV level 3 company. Moreover, a level 3 is
required in order to fully benefit from this add-on. +SAFE does not replace any
safety standard but is a complement to them. Download.
Automotive software functional safety
WD26262 is an automotive industry
customization of IEC61508. Only software is detailed here. WD is applicable to
four wheels motor vehicles for passengers/goods (not hazardous) carriage and
for semi-trailers/trailers. An Automotive Safety Integrity Level (ASIL) is
defined going from A (low) to D (high). Software ASIL is the maximum ASIL of
all software components. WD has 9 parts dealing with safety management, product
conception, system, hardware and software development (mainly part 6) and
Libraries and COTS are qualified, modified
components applies WD. Bidirectional traceability is required for requirements.
Software steps are:
- Initiation: Detailed safety
activities and supporting processes are planned. Software process is
customized. Planning is synchronized between system, product, and software.
Programming language is chosen.
- Specification: Derive software safety
requirements and their ASIL from upstream safety requirements. Specify all
operating modes and dependencies with hardware. Safety requirements are
inspected and models reviewed. ASIL B: semi-formal methods are used. From ASIL
C: Formal method used and computer tool for specification are required, formal
verifications are conducted.
- Architecture: Hierarchically design all
components (as far as low-level) and interfaces, allocate safety requirements
to them. Do inspections and consistency check. Specify interfaces, static,
dynamic, dataflow control flow, sizes and timings aspects. Conduct criticality
analysis. Handle all hardware errors & critical states. Encapsulation is required.
Allocate ASIL to safety components. Protect Safety related data. Analyse impact
on technical safety of found development errors. From ASIL B: Semiformal
methods, Guidelines are available, limited components cohesion, Sw-FMEA,
SW-HAZOP, SW-FMECA are conducted. From C: Computer tools, formal methods, Fault
Tree Analysis, common cause failure analysis, plausibility check, graceful
degradation are used. For D: External monitoring facility is required.
- Design and implementation:
Specify unit design, do code, and check conformity to architecture, unit
specification, and safety requirements. Select method/tools for achieving ASIL.
Specify behaviour, data flow, data structure, and interfaces. A language
subset, naming conventions and metrics are defined, variables are initialized
and no use of unconditional jumps. From ASIL B: Semiformal specifications,
inspections of specification & code, no dynamic object, stack checking, no
variable reuse, no implicit type conversion, no recursion. From C: formal
specifications with computer tool, specification and analysis of control flow,
data flow and algorithms, limited usage of global variable, only one entry &
exit point. From D: no pointer usage.
- Unit & integration tests:
Verify software unit functions. Functional & structural tests are planned
and appropriate method for is selected. If possible, tests are done on target
environment. From C: test result comparison between model and code. From D:
resource usage tests, condition/path/MC/DC coverage.
- Safety acceptance: Verify that functions fulfils correctly and only
safety requirements. Safety acceptance test are planed. Select methods for
acceptance tests. Define test acceptance criteria. Specify test cases. Do acceptance
tests on target system.
WD document was needed for automotive industry.
WD is difficult to read because of its structure, repetitions, and lack of
details, examples, and summary. Understanding it needs skills in safety.
Software specificities are well taken into account. From B or C, WD becomes
heavy and a specific safety structure is needed. Download.
Japan quality winners: Toyota "lean"
Toyota is a well known quality and efficiency champion, what
are its secrets?
whole Quality system
Toyota method works only because this is a complete system (“Jidoka”) to avoid rubbish (“muda”):
- Technology: Reasonable use of new technology: a new technology is
introduced only if the old one is already mastered. Nevertheless creativity is encouraged and 8% of Toyota turnover is really
dedicated to R&D.
- Process: All processes in Toyota are completely written and described
in a visual way: easier to remember. Criteria for switching
steps are clearly established in a qualitative and/or quantitative way. For
example, a software development process can includes more than 70 steps and
associated criteria. Steps are detailed in guides that are always written
assuming that the user is a beginner.
Checks: It is not enough to
check that an activity is done, to eliminate the risk (always possible) of
human errors, Toyota
include systematically double checks. Checks are based on many detailed checklists.
- Specifications: The goal is to write visual specifications and limit at maximum
engineering changes by early eliminating problems.
- Design: Design’s goal is to avoid future problems. You have
to build a road crossing a railway, you can use a grade crossing to avoid
collisions, but Toyota
would prefer to build a bridge or a tunnel. This pro-active attitude
avoids a lot of future problems and is the basis of “Jidoka”'s mindset. Standardization is established.
- Tests: Products are tested early with a good coverage: you
have to activate all products' branches/functions and use an
independent test team. "Idiot" tests must be conducted: if your
product has a command panel with 6 push buttons, even if it is not
possible for a normal human to push at the same time all buttons, you have to
add some tests where all buttons are pushed simultaneously.
- People: Pay attention to people skills, knowledge and
motivation. Employees are carefully selected.
Constant “Kaizen” attitude to satisfy customer, employee and society.
Key attitude, Dissatisfaction is the
only way to constant improvement. In
takes care of employees (benefits sharing, help on personal and professional
problems). Turn-over and contractors' usage must be limited to the maximum. People are encouraged to creativity, to expertise development, expertise exchanges and communication, and to accept challenges
(do always better than requested).
- Suppliers: Sub-contracting a part of a project must be
limited and if done, monitored and mastered. Suppliers are integrated.
- Management: “Gemba”:
Managers are located in the middle of their staff to easily see problems on
field not theoretically. They must react quickly to problems that are signalled
by visual and auditive indication in production (constant problem solving).
Management must install a respect of
people and teamwork in a trusted environment.
Another example: Matsushita/Panasonic’s products
are made in Japan
in fully automated factories; a big factory hires only 15 people. Robots used
to build products are also designed by the Matsushita as well as most of
products’ components. Most Panasonic products have 10 times less quality
defects than other similar competitors.
Toyota with this system can build
a new car for half the time of its competitors with a high level of quality. If
we all agree with these principles, why do we
see so much deviation? Are we so much short-term oriented that we don't want to
invest any more in future? Toyota's
experience shows clearly our limits, going systematically to low-cost is not
necessary to build competitive winner products: Toyota is now the first car manufacturer in
the world. Download.
Japan symbols: What do
If you work with Japanese people
you may be faced in documents to geometric symbols like
circles, triangles, cross... Some people call them Playstation®
symbols because they are also used in Playstation's
buttons. What do they mean?
common knowledge in Japan
The meanings of this geometric symbols
are in fact a common knowledge in Japan like we all
understand in occident the meaning of a tick (done,
correct, passed) and a cross (not good). As all common
knowledge their meaning is evident for Japanese people
but not for us. Here is a short description of this
- Double circle ◎: Called "niju maru"
the double circle that we call bullseye means excellent,
perfect, ideal or brilliant.
- Simple circle ○: Called "maru"
the simple circle means satisfactory or good. If
in the same document the circle and bullseye is
used, circle means satisfactory else it means good.
- Triangle △: Called "sankaku"
the triangle means "weak", "average"
or "in progress". If bullseye is used
in the same document it means "weak" else
it means "good". In some cases, for tracking
progress of an action plan it can means "in
- Cross X:
Called "batsu" the cross means "bad" (Japanese people say
"No Good"). This is the easiest symbol
to understand because it has the same meaning for
- Double Cross XX:
The double cross is similar to simple cross but emphasize the "bad"
signification. So it means a very bad or severe
All these symbols are widely use in Japan
for professional documents, reviews (as film review),
at school (for teacher appreciation), etc...
Working with Japanese people implies to do a
minimum effort to understand and adapt to their way
of thinking and usages. "Playstation symbols"
is one thing you need to know. ▇
Efficient way to take notes
I propose you an efficient way to take note in meetings
by using a special template I have made.
document can be downloaded HERE. ▇
Perpetual Calendar in Excel
Here is a perpetual calendar in Excel, no need to
buy one now. Can be customized with your own messages,
informations, logo... If you want to use it in a commercial
application, please contact me for conditions.
document can be downloaded HERE. ▇