WHAT IS CMMI?

Introduction
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 assigned.
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 Process Areas

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 tool.
• 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) measurements.
• Supplier Agreement Management: Manage suppliers from contract to maintenance, this includes also buying of tools, components, test bench …

Generic Goals
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 continuous model.

Conclusion
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

Introduction
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 are trained.
• 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 products.
• 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).

Conclusion
+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. ▇

      “WD26262”, Automotive software functional safety

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

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

Conclusion
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" example

Introduction
Toyota is a well known quality and efficiency champion, what are its secrets?

A 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.
• Quality 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 exchange Toyota 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.

Conclusion
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 they mean?

Introduction
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?

A 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 meaning:

• 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 progress".
• 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 us too.
• Double Cross XX: The double cross is similar to simple cross but emphasize the "bad" signification. So it means a very bad or severe problem.

All these symbols are widely use in Japan for professional documents, reviews (as film review), at school (for teacher appreciation), etc...

Conclusion
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

Introduction
I propose you an efficient way to take note in meetings by using a special template I have made.

Screenshot
:

Download
This document can be downloaded HERE. ▇

       Perpetual Calendar in Excel

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

Screenshot

Download
This document can be downloaded HERE. ▇