Log in

 <!doctype html>

Demix Update

Demix Update August 2016
View this email in your browser

Articles - RD/TS/PI

*Requirements Development / Technical Solution / Product Integration
Article: (RD/TS/PI)  Software Product Engineering Key Process Area Mapping by Ron Lachell
www.demix.org - Purpose and Usage
The purpose of this document is to enable the user to understand, and be familiar with the common feature details within the Software Product Engineering KPA, and to determine organizational adherence or deficiency.
Article: (PI)  How to do Product Integration by Rajendra Khare        

www.demix.org - Product Integration (PI) Implementation Steps
Product Integration helps in integrating the product components and ensuring the behaviour of the products. Product Integration is conducted using the following steps:
  1. Plan for Product Integration: First step in Product Integration is to prepare an Integration plan or strategy. Integration Plan includes details of Product components to be integrated, with details of the verifications to be performed. It also includes establishing the product environment, defining integration process and steps. And details of tools required for integration (if any).
Article: (PI/TS) Inter Relationships between Technical Solution and Product Integration by Hitesh Sanghavi 
www.demix.org - Objectives of TS and PI: The objective of TS is to design (developing architecture, high level and low level/detail design), develop (coding or data conversion activity for Data migration), and implement (successful deployment at the customer’s site) solutions as per agreed and documented requirements (as per the requirements management and development activities/phase). This includes products, PCs (programs or modules), and product-related life-cycle processes (user manual, design manuals etc). The objective of PI is to ensure planned successful assembling of the complete product (or services) from one or more, simple or complex PCs (or service components), ensuring that the product (or services), as integrated, functions properly as intended by design, and deliver/deploy the product (or services) at the end user/customer site.   

(Read more)

Article: (RD) Requirements Development (RD) (CMMI-DEV) by Wibas  

www.demix.org - Summary
The purpose of Requirements Development (RD) (CMMI-DEV) is to elicit, analyze, and establish customer, product, and product component requirements.

Introductory Notes

This process area describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including needs pertinent to various product life-cycle phases (e.g., acceptance testing criteria) and product attributes (e.g., responsiveness, safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products, use of a particular architecture pattern). 
Article: (PI)  CMMI V1.3: The CMMI Product and Product Integration roadmaps by Ben Linders

www.demix.org - In a first posting on the CMMI roadmaps for CMMI V1.3, I described how the project roadmap has been improved to deliver an even better result. In this posting I’m covering the product and the product integration roadmap.

The CMMI Product roadmap consists of Requirements Development, Requirements Management, Technical Solution, Configuration Management, Verification and Process and Product Quality Assurance. The Configuration Management (CM) process area has been extended with product lines and agile practices, like frequent builds, workspaces for teams and individuals, and automation. The definition of quality attributes (often called non-functional requirements) and architectural requirements has been clarified in the process area Requirements Development (RD), making very clear that this process are is not only about how to handle the functional requirements.                                               
Article: (PI/TS/RD)  Engineering (CMMI-DEV) by Wibas 
www.demix.org - Summary
The Engineering (CMMI-DEV) process areas cover the development and maintenance activities that are shared across engineering disciplines. The Engineering process areas were written using general engineering terminology so that any technical discipline involved in the product development process (e.g., software engineering, mechanical engineering) can use them for process improvement.

The Engineering (CMMI-DEV) process areas also integrate the processes associated with different engineering disciplines into a single product development process, supporting a product oriented process improvement strategy. Such a strategy targets essential business objectives rather than specific technical disciplines. This approach to processes effectively avoids the tendency toward an organizational “stovepipe” mentality.                                                  
RD Self assessment - (Login to view)   
TS Self assessment - (Login to view)
PI Self assessment - (Login to view)
Self assessment - (Login to view)


Appraisal services

This email address is being protected from spambots. You need JavaScript enabled to view it.


(Login to view all)
Related Articles 
Other Articles  


Comments powered by CComment