כיצד להשתמש ב-CMMI להנדסת מערכות
CMMI as an organisational model was created at Carnegie Mellon University by a group of specialists from the Software Engineering Institute.
Systems Engineering is one of the 4 areas supported in the Capability Maturity Model Integration (CMMI). The domain covers designing and developing complete systems that may or may not include software and focuses on translating the initial requirements into product solutions and makes sure that these solutions are supported throughout the whole development process.
The following 6 process areas are used for Engineering, including Systems Engineering.
1. ניהול דרישות
If there are any inconsistencies in between the product requirements and the project workflow and roadmap, these can be reassessed and settled at the Requirements Management stage. This includes both technical and non-technical requirements.
This stage is not a one-off activity – with the requirements changing throughout the product development process, it may be necessary to regularly check how they interact with other elements of the project and adjust them accordingly.
The process area of CMMI also has one specific goal and a few generic goals as follows:
SG 1: ניהול דרישות
‘Requirements are managed and inconsistencies with project plans and work products are identified.’
GG 1: השגת מטרות ספציפיות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
‘The process is institutionalized as a quantitatively managed process.’
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
The CMMI then lists steps for achieving all of these goals – check ספר אלקטרוני זה למידע נוסף.
2. פיתוח דרישות
Here’s where the requirements collected in the previous phase are analysed and developed. There are 3 groups of practices focused on these activities.
The first group will be used as a basis for product design and is as follows:
- collection and coordination of stakeholder needs,
- development of the life-cycle requirements of the product,
- ביסוס דרישות הלקוח,
- establishment of initial product and product component requirements consistent with customer requirements,
- elicitation, analysis, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders.
Then there’s the second group centred around analysing the requirements, especially the customer requirements. This list of actions includes:
- ניתוח צרכים ודרישות,
- פיתוח של תפיסה תפעולית,
- הגדרת הפונקציונליות הנדרשת,
-
development of manufacturing and support concepts to address
עלות ונגישות כלכלית.
This segment of activities is strongly connected with the third group where results of the analysis are presented as a list of:
- אילוצים מסוגים שונים,
- מגבלות טכנולוגיות,
- עלות וגורמי עלות,
- אילוצי זמן ומניעי לוח זמנים,
- סיכונים,
-
consideration of issues implied but not explicitly stated by the
לקוח או משתמש קצה, -
factors introduced by the developer’s unique business
שיקולים, תקנות וחוקים.
The Requirements Development phase also has its list of 3 specific goals and generic goals with step-by-step descriptions on how to achieve these. These lists of goals include:
SG 1: פיתוח דרישות לקוח
‘Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.’
SG 2: פיתוח דרישות מוצר
‘Customer requirements are refined and elaborated to develop product and product component requirements for the product life cycle.’
SG 3: ניתוח ואימות דרישות
‘The requirements are analyzed and validated, and a definition of required functionality is developed.’
GG1: השגת מטרות מוגדרות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
‘The process is institutionalized as a quantitatively managed process.’
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
>> גלו עוד על CMMI 2.0 במגזר הרכב
3. פתרון טכני
Next stage of the process is all about designing, developing and implementing solutions to the requirements established in the last 2 phases. It’s important to remember that the design, development and implementation are connected, and they may impact each other directly or indirectly. On an organisational level, the requirements may change over time – this will also mean that further iterations of the already implemented solutions may be necessary.
Thanks to the traceability of the requirements established in the previous stage, any of these iterations will be easy to track and document.
As it was with the last two stages, this stage also has specific and generic goals and step-by-step instructions on how to achieve these תחומי תהליך CMMI.
SG 1: בחר פתרונות לרכיבי מוצר
‘Product or product component solutions, including applicable product related processes, are selected from alternative solutions.’
SG 2: פיתוח התכן
‘Product or product component designs are developed.’
SG 3: יישום עיצוב המוצר
‘Product components, and associated support documentation, are implemented from their designs.’
GG 1: השגת מטרות ספציפיות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
4. אינטגרציית מוצר
After the designs and solutions are ready, it’s time to assembly the product from the existing components and fill any gaps that have not been covered by the requirements and the solutions. This is also where the product is tested and assessed as integrated and fully functional. With these steps completed, the product can be then delivered to any stakeholders, including the customers.
If you operate in the Systems Engineering domain, your final product will be a system, with all of its elements included, tested and released. Your responsibility will also be ensuring the consistency of all designs.
Please note that the product integration stage can be completed iteratively and is not – in any case – a one-off process of assembling all assets. Work with prototypes and make sure that they get more advanced as you approach the release.
As always, in the CMMI this stage is also completed with 2 list of goals (ספציפי וגנרי).
SG 1: היערכות לאינטגרציה של המוצר
‘The strategy for conducting product integration is established and maintained.’
SG 2: הבטחת תאימות ממשקים
‘The product component interfaces, both internal and external, are compatible.’
SG 3: Assemble Product Components and Deliver the Product
‘Verified product components are assembled and integrated, verified, and validated product is delivered.’
GG 1: השגת מטרות ספציפיות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
‘The process is institutionalized as a quantitatively managed process.’
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
5. אימות
Once the product or system is deployed, you need to move to the verification stage. The purpose of this phase is to ensure that the final result meets the specified requirements from both project and customer side. You may also need to take any corrective actions if the verification turns out to be unsatisfactory.
While on the surface, verification and validation (see the next stage) may seem similar, there are – in fact – two different activities. Verifying the product assess whether it’s viable and complete from the requirements point of view. Validating it is all about ensuring that the product will fullfil its function and is in fact, what was necessary for a particular task.
Check below for a list of specific and general goals and follow הקישור למידע נוסף על איך ליצור איתם קשר.
SG 1: Assemble Product Components and Deliver the Product
‘Verified product components are assembled and the integrated, verified, and
מוצר מאומת נמסר'.
GG 1: השגת מטרות ספציפיות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
‘The process is institutionalized as a quantitatively managed process.’
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
6. אימות
As mentioned above, the validation process focuses on whether the product can address its intended use – in short, whether it will do what it was created to do. What is important in this phase is that this full functionality needs to be achieved in the intended environment.
As it is with the verification, the validation also follows through on i.a. testing, analysis and simulation, so these two processes may be using the same environment or even be conducted in parallel, at the same time. Any issues that will be discovered at this stage need to be addressed accordingly with corrective actions taken immediately.
Here’s a list of specific and generic goals for this stage below:
SG 1: היערכות לאימות
‘Preparation for verification is conducted.’
SG 2: ביצוע סקירות עמיתים
‘Peer reviews are performed on selected work products.’
SG 3: אימות תוצרי עבודה נבחרים
‘Selected work products are verified against their specified requirements.’
GG 1: השגת מטרות ספציפיות
‘The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.’
GG 2: מוסד תהליך מנוהל
‘The process is institutionalized as a managed process.’
GG 3: מוסד תהליך מוגדר
‘The process is institutionalized as a defined process.’
GG 4: Institutionalize a Quantitatively Managed Process
‘The process is institutionalized as a quantitatively managed process.’
GG 5: Institutionalize an Optimizing Process
‘The process is institutionalized as an optimizing process.’
קראו את הספר האלקטרוני הזה על תחומי תהליך CMMI למידע נוסף.
Using the CMMI model for systems engineering
Traditionally, the systems engineering domain is heavily based on the V-model with certain processes grouped into 3 categories:
- Primary Life Cycle Processes (Acquisition Process Group, Supply Process Group, System Engineering Process Group, Software Engineering Process Group, Cybersecurity Engineering Process Group),
- Organisational Life Cycle Processes (Management Process Group, Reuse Process Group, Process Improvement Process Group),
- Supporting Life Cycle Processes (Supporting Process Group).
While this model of work is still viable when using CMMI, the workflow itself is managed differently and on an organisational rather than a process level. Where in the V-model includes elements such as ‘system architecture’, ‘system requirements’, ‘structure architecture’ and ‘structure requirements’, in the CMMI there’s ‘high-level design’ and ‘low-level design’.
This will be especially important if you need to combine the CMMI with any other processes and model that your organisation may already be using, including the V-model mentioned above and ASPICE.
>> Check this article to find out how V-model and ASPICE can be used in conjunction to strengthen the cybersecurity efforts: סייברס�キュリティ כתוסף ל-ASPICE ולמודל V
תורך
Need some support when introducing the CMMI model/workflow to your organisation? Please don’t hesitate to contact our Automotive team for more information: בטיחות רכב ב-Spyrosoft.
שאלות נפוצות: הנדסת מערכות CMMI
Capability Maturity Model Integration (CMMI) is an organisational improvement model created at Carnegie Mellon University by specialists from the Software Engineering Institute. It provides structured best practices that help organisations improve performance, quality, and predictability across engineering and management domains.
Systems Engineering is one of the key domains supported by CMMI. It focuses on designing and developing complete systems, which may include hardware, software, and integrated components. The goal is to translate stakeholder and business requirements into working product solutions and ensure those solutions are supported and controlled throughout the entire lifecycle.
Within the Engineering domain, six core process areas are particularly relevant to Systems Engineering: Requirements Management, Requirements Development, Technical Solution, Product Integration, Verification, and Validation. Together, they guide the organisation from capturing requirements through design, integration, testing, and confirmation that the final system works as intended.
Although often mentioned together, verification and validation serve different purposes.
Verification checks whether the product has been built correctly according to specified requirements. It confirms that deliverables meet documented criteria.
Validation, on the other hand, determines whether the product fulfils its intended use in its real or intended environment. In short, verification answers “Did we build it right?”, while validation answers “Did we build the right thing?”
Both activities may use similar techniques such as testing, analysis, simulation, and peer reviews, and they can sometimes be conducted in parallel.
Yes. CMMI can be integrated with models such as Automotive SPICE (ASPICE). When combining frameworks, organisations must ensure consistent terminology, aligned responsibilities, and harmonised process structures. This is particularly relevant in regulated industries such as automotive, where multiple standards may apply simultaneously.
arrow_circle_rightצרו קשר
אנחנו נעזור לכם ליישם תקני בטיחות לרכב
arrow_circle_right המאמרים שלנו
