उत्पाद-परिवार इंजीनियरिंग
This article needs additional citations for verification. (September 2018) (Learn how and when to remove this template message) |
उत्पाद-परिवार इंजीनियरिंग (PFE), जिसे उत्पाद-लाइन इंजीनियरिंग के रूप में भी जाना जाता है, सॉफ्टवेयर इंजीनियरिंग संस्थान द्वारा बनाए गए डोमेन इंजीनियरिंग के विचारों पर आधारित है, जिसे जेम्स नेबर्स ने 1980 के शोध प्रबंध में गढ़ा था।[1] कैलिफोर्निया विश्वविद्यालय, इरविन में। सॉफ्टवेयर उत्पाद श्रृंखला हमारे दैनिक जीवन में काफी सामान्य है, लेकिन किसी उत्पाद श्रृंखला को सफलतापूर्वक स्थापित करने से पहले, एक व्यापक प्रक्रिया का पालन करना पड़ता है। इस प्रक्रिया को उत्पाद-परिवार इंजीनियरिंग के रूप में जाना जाता है।
उत्पाद-पारिवारिक इंजीनियरिंग को एक ऐसी विधि के रूप में परिभाषित किया जा सकता है जो किसी संगठन के उत्पाद कंप्यूटिंग प्लेटफॉर्म के लिए एक अंतर्निहित सॉफ्टवेयर आर्किटेक्चर बनाता है। यह एक वास्तुकला प्रदान करता है जो समानता के साथ-साथ नियोजित परिवर्तनशीलता पर आधारित है। विभिन्न उत्पाद प्रकार मूल उत्पाद परिवार से प्राप्त किए जा सकते हैं, जो परिवार में उत्पादों पर पुन: उपयोग और अंतर करने का अवसर पैदा करता है। उत्पाद-पारिवारिक इंजीनियरिंग वैचारिक रूप से मोटर वाहन उद्योग में कार प्लेटफॉर्म के व्यापक उपयोग के समान है।
उत्पाद-परिवार इंजीनियरिंग नए उत्पादों के निर्माण के लिए एक अपेक्षाकृत नया दृष्टिकोण है। यह इंजीनियरिंग नए उत्पादों की प्रक्रिया पर इस तरह से ध्यान केंद्रित करता है कि उत्पाद घटकों का पुन: उपयोग करना और कम लागत और समय के साथ परिवर्तनशीलता को लागू करना संभव है। उत्पाद-पारिवारिक इंजीनियरिंग जितना संभव हो सके घटकों और संरचनाओं का पुन: उपयोग करने के बारे में है।
कई अध्ययनों ने साबित किया है कि उत्पाद विकास के लिए उत्पाद-परिवार इंजीनियरिंग दृष्टिकोण का उपयोग करने से कई लाभ हो सकते हैं (कार्नेगी मेलॉन (एसईआई), 2003)। उनमें से कुछ की सूची यहां दी गई है:
- उच्चतर उत्पादकता
- उच्च गुणवत्ता
- तेज़ समय-टू-मार्केट
- कम श्रम की जरूरत है
नीचे उल्लिखित Nokia केस भी इन लाभों को दिखाता है।
समग्र प्रक्रिया
उत्पाद परिवार इंजीनियरिंग प्रक्रिया में कई चरण होते हैं। तीन मुख्य चरण हैं:
- चरण 1: उत्पाद प्रबंधन
- चरण 2: डोमेन इंजीनियरिंग
- चरण 3: उत्पाद इंजीनियरिंग
प्रक्रिया को एक उच्च अमूर्त स्तर पर तैयार किया गया है। इसका यह लाभ है कि इसे केवल सॉफ्टवेयर ही नहीं, बल्कि सभी प्रकार की उत्पाद लाइनों और परिवारों पर लागू किया जा सकता है। मॉडल को किसी भी उत्पाद परिवार पर लागू किया जा सकता है। चित्रा 1 (नीचे) पूरी प्रक्रिया का एक मॉडल दिखाता है। नीचे, प्रक्रिया को विस्तार से वर्णित किया गया है। प्रक्रिया विवरण में गतिविधियों का विस्तार और उपयोग की जाने वाली महत्वपूर्ण अवधारणाएँ शामिल हैं। इटैलिक में छपी सभी अवधारणाओं को तालिका 1 में समझाया गया है।
चरण 1: उत्पाद प्रबंधन
पहला चरण पूरी प्रक्रिया की शुरुआत है। इस चरण में कुछ महत्वपूर्ण पहलुओं को विशेष रूप से आर्थिक पहलुओं के संबंध में परिभाषित किया गया है। यह चरण बाजार की रणनीतियों को रेखांकित करने और एक कार्यक्षेत्र (परियोजना प्रबंधन) को परिभाषित करने के लिए जिम्मेदार है, जो बताता है कि उत्पाद परिवार के अंदर क्या होना चाहिए और क्या नहीं होना चाहिए।
व्यवसाय दृष्टि का मूल्यांकन करें
इस पहली गतिविधि के दौरान उत्पाद लाइन के दायरे को परिभाषित करने के लिए प्रासंगिक सभी संदर्भ जानकारी एकत्र और मूल्यांकन की जाती है। एक स्पष्ट बाजार रणनीति को परिभाषित करना और बाहरी बाजार की जानकारी को ध्यान में रखना महत्वपूर्ण है, जैसे कि उपभोक्ता मांगें। गतिविधि को एक संदर्भ दस्तावेज़ प्रदान करना चाहिए जिसमें उत्पाद सॉफ़्टवेयर के लिए दिशानिर्देश, प्रतिबंध (डिज़ाइन) और विपणन रणनीतियाँ शामिल हों।
उत्पाद लाइन का दायरा परिभाषित करें
स्कोपिंग तकनीकों को यह परिभाषित करने के लिए लागू किया जाता है कि कौन से पहलू दायरे में हैं। यह प्रक्रिया के पिछले चरण पर आधारित है, जहां बाहरी कारकों को ध्यान में रखा गया है। आउटपुट एक उत्पाद पोर्टफोलियो विवरण है, जिसमें वर्तमान और भविष्य के उत्पादों की सूची और उत्पाद रोडमैप भी शामिल है।
यह तर्क दिया जा सकता है कि चरण 1, उत्पाद प्रबंधन, उत्पाद-परिवार-इंजीनियरिंग प्रक्रिया का हिस्सा है, क्योंकि इसे एक व्यक्तिगत व्यवसाय प्रक्रिया के रूप में देखा जा सकता है जो उत्पाद पहलू के बजाय प्रबंधन पहलुओं पर अधिक केंद्रित है। हालाँकि चरण 2 को इस चरण से कुछ महत्वपूर्ण इनपुट की आवश्यकता है, क्योंकि इस चरण में दायरे का एक बड़ा हिस्सा परिभाषित किया गया है। इसलिए इस दृष्टिकोण से डोमेन-इंजीनियरिंग प्रक्रिया के आधार के रूप में पूरी प्रक्रिया में उत्पाद-प्रबंधन चरण (चरण 1) को शामिल करना महत्वपूर्ण है।
चरण 2: डोमेन इंजीनियरिंग
डोमेन-इंजीनियरिंग चरणों के दौरान, संपूर्ण उत्पाद लाइन के लिए चर और सामान्य आवश्यकताओं को इकट्ठा किया जाता है। लक्ष्य एक पुन: प्रयोज्य मंच स्थापित करना है। इस चरण का आउटपुट उत्पाद लाइन में सभी उत्पादों के लिए सामान्य और परिवर्तनीय आवश्यकताओं का एक सेट है।
डोमेन आवश्यकताओं का विश्लेषण करें
इस गतिविधि में अवधारणा आवश्यकताओं के संबंध में डोमेन का विश्लेषण करने के लिए सभी गतिविधियां शामिल हैं। आवश्यकताओं को वर्गीकृत किया गया है और दो नई गतिविधियों में विभाजित किया गया है। आउटपुट डोमेन विश्लेषण वाला एक दस्तावेज़ है।
जैसा कि चित्र 1 में देखा जा सकता है कि सामान्य आवश्यकताओं को परिभाषित करने की प्रक्रिया परिवर्तनशील आवश्यकताओं को परिभाषित करने वाली एक समानांतर प्रक्रिया है। दोनों गतिविधियां एक ही समय में होती हैं।
सामान्य आवश्यकताओं को परिभाषित करें
उत्पाद लाइन की सामान्य आवश्यकताओं को पूरा करने और दस्तावेजीकरण के लिए सभी गतिविधियों को शामिल करता है, जिसके परिणामस्वरूप पुन: प्रयोज्य सामान्य आवश्यकताओं के साथ एक दस्तावेज़ होता है।
चर आवश्यकताओं को परिभाषित करें
उत्पाद लाइन की परिवर्तनीय आवश्यकताओं को पूरा करने और दस्तावेज़ीकरण करने के लिए सभी गतिविधियों को शामिल करता है, जिसके परिणामस्वरूप परिवर्तनीय आवश्यकताओं वाला एक दस्तावेज़ होता है।
डिज़ाइन डोमेन
इस प्रक्रिया चरण में उत्पाद लाइन की संदर्भ संरचना को परिभाषित करने के लिए गतिविधियाँ शामिल हैं। यह उत्पाद लाइन में सभी उत्पादों के लिए एक सार संरचना उत्पन्न करता है।
डोमेन लागू करें
इस चरण के दौरान पुन: प्रयोज्य घटकों का एक विस्तृत डिज़ाइन और इन घटकों के कार्यान्वयन का निर्माण किया जाता है।
टेस्ट डोमेन
घटकों की पुन: प्रयोज्यता को मान्य और सत्यापित करता है। घटकों का उनके विनिर्देशों के विरुद्ध परीक्षण किया जाता है। विभिन्न उपयोग मामलों और परिदृश्यों में सभी घटकों के सफल परीक्षण के बाद, डोमेन इंजीनियरिंग चरण पूरा हो गया है।
चरण 3: उत्पाद इंजीनियरिंग
अंतिम चरण में एक उत्पाद एक्स को इंजीनियर किया जा रहा है। यह उत्पाद एक्स डोमेन इंजीनियरिंग चरण से समानताओं और परिवर्तनशीलता का उपयोग करता है, इसलिए उत्पाद एक्स को डोमेन इंजीनियरिंग चरण में स्थापित मंच से प्राप्त किया जा रहा है। यह मूल रूप से पिछले चरण से सभी सामान्य आवश्यकताओं और समानताओं को लेता है और साथ ही अपनी स्वयं की परिवर्तनशील आवश्यकताओं को भी लेता है। डोमेन इंजीनियरिंग चरण से आधार और उत्पाद इंजीनियरिंग चरण की व्यक्तिगत आवश्यकताओं का उपयोग करके एक पूर्ण और नया उत्पाद बनाया जा सकता है। उसके बाद उत्पाद का पूरी तरह से परीक्षण और अनुमोदन हो जाने के बाद, उत्पाद एक्स को डिलीवर किया जा सकता है।
उत्पाद आवश्यकताओं को परिभाषित करें
व्यक्तिगत उत्पाद के लिए उत्पाद आवश्यकताओं का विश्लेषण विकसित करना और पिछले चरण से आवश्यकताओं का पुन: उपयोग करना।
डिजाइन उत्पाद
उत्पाद सॉफ्टवेयर आर्किटेक्चर के निर्माण के लिए सभी गतिविधियां। चरण डिजाइन डोमेन से संदर्भ वास्तुकला का उपयोग करता है, यह संदर्भ वास्तुकला के आवश्यक भागों को चुनता है और कॉन्फ़िगर करता है और उत्पाद विशिष्ट अनुकूलन को शामिल करता है।
उत्पाद बनाएँ
इस प्रक्रिया के दौरान पुन: प्रयोज्य घटकों के चयन और विन्यास का उपयोग करके उत्पाद का निर्माण किया जाता है।
परीक्षण उत्पाद
इस चरण के दौरान उत्पाद को उसके विनिर्देशों के विरुद्ध सत्यापित और मान्य किया जाता है। एक परीक्षण रिपोर्ट उन सभी परीक्षणों के बारे में जानकारी देती है जो किए गए थे, इससे उत्पाद में संभावित त्रुटियों का अवलोकन होता है। यदि अगले चरण में उत्पाद स्वीकार नहीं किया जाता है, तो प्रक्रिया उत्पाद बनाने के लिए वापस आ जाएगी, चित्र 1 में इसे [असंतुष्ट] के रूप में दर्शाया गया है।
वितरण और समर्थन उत्पाद
अंतिम चरण अंतिम उत्पाद की स्वीकृति है। यदि इसका सफलतापूर्वक परीक्षण किया गया है और पूर्ण होने के लिए अनुमोदित किया गया है, तो इसे वितरित किया जा सकता है। यदि उत्पाद विनिर्देशों को पूरा नहीं करता है, तो इसे फिर से बनाना और परीक्षण करना होगा।
अगला आंकड़ा ऊपर वर्णित उत्पाद-परिवार इंजीनियरिंग की समग्र प्रक्रिया को दर्शाता है। यह विभिन्न चरणों से जुड़ी सभी अवधारणाओं के साथ एक पूर्ण प्रक्रिया अवलोकन है।
प्रक्रिया डेटा आरेख
बाईं ओर ऊपर से नीचे तक की पूरी प्रक्रिया खींची गई है। बाईं ओर की सभी गतिविधियाँ डॉटेड रेखाओं के माध्यम से दाईं ओर की अवधारणाओं से जुड़ी हुई हैं। प्रत्येक अवधारणा की एक संख्या होती है, जो अन्य अवधारणाओं के साथ जुड़ाव को दर्शाती है।
अवधारणाओं की सूची
अवधारणाओं के साथ सूची के नीचे समझाया जाएगा। अधिकांश अवधारणा परिभाषाएँ पोहल, बॉकल और लिंडेन (2005) से निकाली गई हैं और कुछ नई परिभाषाएँ भी जोड़ी गई हैं।
Concept | Definition |
---|---|
Domain analysis |
Document contains an analysis of the domain through which common and variable requirements can be split up. |
Reusable common requirements |
Document contains requirements that are common to all products in the product line. |
Variable requirements |
Document contains derivation of customised requirements for different products. |
Reference Architecture |
Determines the static and dynamic decomposition that is valid for all products of the product line. Also the collection of common rules guiding the design, realisation of the parts, and how they are combined to form products. |
Variability model |
Defines the variability of the product line. |
Design & implementation assets of reusable components |
The major components for the design and implementation aspects, which are relevant for the whole product family. |
Test results |
The output of the tests performed in domain testing. |
Reusable test artifacts |
Test artifacts include the domain test plan, the domain test cases, and the domain test case scenarios. |
Requirements specifications |
The requirements for a particular product. |
Product architecture |
Comparable to reference architecture, but this contains the product specific architecture. |
Running application |
A working application that can be tested later on. |
Detailed design artifacts |
These include the different kinds of models that capture the static and dynamic structure of each component. |
Test report |
Document with all test results of the product. |
Problem report |
Document, which lists all problems encountered while testing the product. |
Final product |
The delivery of the completed product. |
Family model |
The overlapping concept of all family members with all sub products. |
Family member |
The concept of the individual product. |
Context document |
Document containing important information for determining the scope; containing guidelines, constraints and production strategy. |
Guidelines |
Market/business/product guidelines |
Constraints |
Market/business/product constraints |
Product strategy |
Product strategy with regard to markets |
Product portfolio description |
Portfolio containing all available products, with important properties. |
List of current & future products |
A list of all current products and the products that will be produced in the future. |
Product roadmap |
Describes the features of all products of the product line and categorises the feature into common features that are part of each product and variable features that are only part of some products. |
तालिका 1: अवधारणाओं की सूची
उदाहरण
उत्पाद परिवार इंजीनियरिंग के उपयोग के कुछ अच्छे उदाहरण हैं, जो काफी सफल रहे। उत्पाद परिवार इंजीनियरिंग का सार मॉडल विभिन्न प्रकार के उपयोगों की अनुमति देता है, उनमें से अधिकांश उपभोक्ता इलेक्ट्रॉनिक्स बाजार से संबंधित हैं। नोकिया के वास्तविक अनुभव के आधार पर उत्पाद लाइन इंजीनियरिंग प्रक्रिया के अनुप्रयोग का एक उदाहरण नीचे दिया गया है।
नोकिया विभिन्न प्रकार के उत्पाद बनाती है। उनमें से एक मोबाइल फोन उत्पाद परिवार है, जिसमें वर्तमान में हर साल 25 से 30 नए उत्पाद शामिल हैं। ये उत्पाद पूरी दुनिया में बेचे जाते हैं, जिससे कई अलग-अलग भाषाओं और उपयोगकर्ता इंटरफ़ेस का समर्थन करना आवश्यक हो जाता है। यहां एक मुख्य समस्या यह है कि कई अलग-अलग यूजर इंटरफेस का समर्थन किया जाना चाहिए, और क्योंकि नए उत्पाद एक-दूसरे को बहुत जल्दी सफल करते हैं, इसे यथासंभव कुशलता से किया जाना चाहिए। उत्पाद परिवार इंजीनियरिंग विभिन्न उत्पादों के लिए सॉफ्टवेयर बनाना और प्रत्येक अलग मोबाइल फोन के लिए सॉफ्टवेयर को अनुकूलित करने के लिए परिवर्तनशीलता का उपयोग करना संभव बनाता है।
Nokia केस की तुलना सामान्य सॉफ़्टवेयर उत्पाद श्रृंखला से की जा सकती है। पहले चरण के दौरान, उत्पाद प्रबंधन, विभिन्न मोबाइल फोन श्रृंखला के दायरे को परिभाषित करना संभव है। दूसरे चरण के दौरान, डोमेन इंजीनियरिंग, आवश्यकताओं को परिवार के लिए परिभाषित किया गया है, और अलग-अलग प्रकार के फोन के लिए, उदाहरण के लिए, 6100/8300 श्रृंखला। इस चरण में, सॉफ़्टवेयर आवश्यकताएँ बनाई जाती हैं, जो पूरे उत्पाद परिवार के लिए आधार के रूप में काम कर सकती हैं। यह सॉफ्टवेयर के लिए समग्र विकास प्रक्रिया को गति देता है। अंतिम चरण, उत्पाद इंजीनियरिंग, व्यक्तिगत प्रकार के फोन पर अधिक केंद्रित है। पूर्ववर्ती चरण की आवश्यकताओं का उपयोग तब विकसित किए जा रहे फोन के प्रकार के लिए अलग-अलग सॉफ़्टवेयर बनाने के लिए किया जाता है।
एक उत्पाद श्रृंखला के उपयोग ने नोकिया को अपने नए मोबाइल-फोन मॉडलों के उत्पादन को 5-10 से बढ़ाकर लगभग 30 करने का अवसर दिया। कार्नेगी मेलन (एसईआई), 2006, क्लेमेंट्स एंड नॉर्थ्रॉप (2003)।
यह भी देखें
- स्वचालित प्रोग्रामिंग
- डोमेन विश्लेषण
- फ़ीचर मॉडल
- फ़ीचर-उन्मुख प्रोग्रामिंग
- मल्टीएजेंट सिस्टम उत्पाद लाइनें
- सिस्टम इंजीनियरिंग
- संस्करण नियंत्रण
संदर्भ
- ↑ https://escholarship.org/uc/item/5687j6g6 Software construction using components, Retrieved 2021-01-09
- Jan Bosch, Design and use of software architectures: adopting and evolving a product-line approach, ACM Press/Addison-Wesley Publishing Co., New York, NY, 2000 ISBN 978-0201674941 https://www.amazon.com/Design-Use-Software-Architectures-Bosch/dp/0201674947
- Carnegie Mellon Software Engineering Institute (SEI). Software Product Lines. Retrieved February 17, 2006, from: https://web.archive.org/web/20171005173029/http://www.sei.cmu.edu/productlines/
- Clements P. & Northrop L.M. (2003). Software Product Lines. Presentation Carnegie Mellon Software Engineering Institute. Retrieved March 26, 2006, from: http://www.sei.cmu.edu/
- European Software Institute (ESI). Retrieved February 17, 2006, from: https://web.archive.org/web/20070203151901/http://www.esi.es/Families/famResults.html
- Pohl K., Bockle G., & Linden F. van der (2005). Software Product Line Engineering. Berlin, Heidelberg, New York: Springer-Verlag. ISBN 978-3-540-28901-2 https://www.amazon.com/Software-Product-Line-Engineering-Foundations-dp-3540243720/dp/3540243720