बहुत जल्द, 17 दिसंबर को, क्षमता के लिए सॉफ्टवेयर की क्षमता परिपक्वता मॉडल के सह-लेखक मार्क पॉल द्वारा एक मास्टर क्लास , लक्सॉफ्ट ट्रेनिंग में आयोजित किया जाएगा।
मार्क पॉलक सॉफ्टवेयर डेवलपमेंट (सीएमएम और सीएमएमआई), प्रक्रिया परिपक्वता, चुस्त कार्यप्रणाली, सॉफ्टवेयर विकास और सांख्यिकीय विश्लेषण के लिए परियोजना प्रबंधन में सुधार, सॉफ्टवेयर विकास पर पाठ्यक्रम विकसित और सिखाता है।
हमारा सुझाव है कि आप सॉफ्टवेयर विकास प्रक्रिया, सॉफ्टवेयर गुणवत्ता और व्यक्तिगत उत्पादकता के संगठन के बीच संबंधों पर अपने लेख से परिचित हों।

कार्यक्रमों की गुणवत्ता और व्यक्तिगत विकास प्रक्रिया में व्यक्तिगत उत्पादकता पर सॉफ्टवेयर विकास प्रक्रिया के संगठन का प्रभाव

मार्क पॉलक, कार्नेगी मेलन विश्वविद्यालय

परिचय

सॉफ्टवेयर विकास प्रक्रियाओं के आधुनिक सिद्धांत में एक मूल सिद्धांत यह है कि प्रक्रियाओं की भूमिका को मजबूत करना, या "सर्वोत्तम प्रथाओं" का पालन करना, डेवलपर्स की उत्पादकता को बढ़ाता है और उनके द्वारा बनाए जाने वाले उत्पादों में सुधार करता है। व्यवहार में, किसी एक को दूसरे से अलग करना मुश्किल है, क्योंकि जटिल कारण संबंधों का एक नेटवर्क दो श्रेणियों के बीच बनाया गया है, हालांकि, इस तरह के अलगाव अभी भी काफी सामान्य है, क्योंकि इनमें से प्रत्येक अवधारणा जटिल है और इसमें कई आयाम शामिल हैं। और यद्यपि विकास प्रक्रिया का संगठन परियोजना के सफल समापन की गारंटी नहीं देता है, फिर भी यह इस संभावना को बढ़ाता है।
यह धारणा कि एक सुव्यवस्थित सॉफ्टवेयर विकास प्रक्रिया मूल्य जोड़ती है, सॉफ्टवेयर विकास प्रक्रिया परिपक्वता मॉडल (CMM) और CMM एकीकरण (CMMI) जैसे मॉडल और मानकों के मूल में है। सुधारों की प्रकृति व्यवसाय प्रक्रिया पर निर्भर करती है, लेकिन, एक नियम के रूप में, वे उत्पादकता और गुणवत्ता को प्रभावित करते हैं। प्रदर्शन और गुणवत्ता पर व्यक्तिगत सॉफ्टवेयर प्रक्रिया (पीएसपी) के प्रभाव को प्रदर्शित करने के लिए, विश्लेषण के आंकड़ों का उपयोग किया जा सकता है। PSP एक सुव्यवस्थित विकास प्रक्रिया को अपनाने के बाद उत्पादकता और गुणवत्ता वृद्धि को प्रदर्शित करता है, लेकिन यह इन अवधारणाओं को परिभाषित करने में कुछ कठिनाइयों का भी चित्रण करता है। वाट्स हम्फ्रे ने सॉफ्टवेयर विकास के संगठन के सिद्धांतों को सफलतापूर्वक सीएमएम, टीम सॉफ्टवेयर प्रोसेस (टीएसपी) और पीएसपी पर लागू किया। कई अध्ययन क्रमशः, एक संगठन, टीम (परियोजना) और व्यक्ति की गुणवत्ता और उत्पादकता पर इन सिद्धांतों के प्रभाव को दिखाते हैं।
सीखने के माहौल में डेवलपर के काम के लिए PSP कदम दर कदम विकास की प्रक्रिया और मात्रात्मक प्रबंधन की अवधारणाओं को लागू करता है। PSP में 4 मुख्य प्रक्रियाएं हैं: PSP0, PSP1, PSP2 और PSP3। प्रत्येक प्रक्रिया को इंजीनियरिंग या प्रबंधकीय कार्यों को जोड़कर पिछले एक पर बनाया गया है। कार्यों का चरण-दर-चरण जोड़ डेवलपर को उस प्रभाव का विश्लेषण करने की अनुमति देता है जो नई तकनीकों का उसके व्यक्तिगत प्रभाव पर है। आमतौर पर 10 कार्य दिए गए। PSP डेटा अनुसंधान के लिए अच्छी तरह से अनुकूल है, क्योंकि कई कारक जो परियोजना के प्रदर्शन को प्रभावित करते हैं और अनुसंधान डेटा के साथ हस्तक्षेप करते हैं, जैसे कि आवश्यकताओं की परिवर्तनशीलता और टीम वर्क की कठिनाइयों, या तो PSP में प्रतिबंधित या पूरी तरह से समाप्त हो जाते हैं। PSP पर छात्र प्रोग्रामिंग भाषाओं की एक विस्तृत विविधता का उपयोग करते हैं, हालांकि, केवल 2435 की कुल संख्या के साथ C में लिखे गए प्रोग्राम (जब तक कि अन्यथा निर्दिष्ट नहीं किए गए) नमूने में शामिल किए गए थे।

गुणवत्ता पर प्रभाव

सरल गुणवत्ता विश्लेषण के लिए, पीएसपी उपलब्ध दोष घनत्व डेटा का उपयोग करता है। सॉफ्टवेयर विकास में, पहले वर्ष में (या पहले छह महीने या किसी अन्य अवधि में) दोषों की संख्या पर डेटा अक्सर गुणवत्ता की माप के रूप में उपयोग किया जाता है। चूंकि पीएसपी प्रशिक्षण कक्षा में होता है, इसलिए उत्पाद "फील्ड ट्रायल" पास नहीं करते हैं। एक उचित विकल्प परीक्षण के दौरान पाए जाने वाले दोष घनत्व मीट्रिक का उपयोग करना है। बॉक्स आरेख (छवि 1) सॉफ्टवेयर गुणवत्ता में औसत दर्जे का और सांख्यिकीय रूप से महत्वपूर्ण सुधार दिखाता है जो 4 पीएसपी प्रक्रियाओं पर हुआ था। गुणवत्ता में 79 प्रतिशत की सुधार हुआ और अस्थिरता में 81 प्रतिशत की कमी आई।
हालांकि, एक आरक्षण होना चाहिए: इस तथ्य के बावजूद कि गुणवत्ता को मापने के लिए दोषों के घनत्व का उपयोग किया जा सकता है, ग्राहकों का दोषों के साथ संबंध नहीं है, लेकिन विफलताओं के साथ। उत्पाद के सामान्य उपयोग को प्रभावित किए बिना दोष वर्षों तक किसी का ध्यान नहीं जा सकता है। यहां तक ​​कि विफलताओं के बीच औसत समय के रूप में ऐसी गुणवत्ता माप सही नहीं है, क्योंकि सॉफ्टवेयर उत्पादों के कई पहलू ग्राहकों के लिए मायने रखते हैं (और ग्राहक गुणवत्ता का मुख्य मूल्यांकनकर्ता है)। उदाहरण के लिए, गारविन गुणवत्ता (प्रदर्शन, कार्यक्षमता, कार्यक्षमता, सुरक्षा, मानक, विश्वसनीयता, स्थायित्व, सेवाक्षमता और सौंदर्यशास्त्र) के नौ आयामों की पहचान करता है, जो "समग्र गुणवत्ता" की अवधारणा की जटिलता को दर्शाता है। आईएसओ 9126 में सूचीबद्ध सॉफ्टवेयर गुणवत्ता विनिर्देशों में कार्यक्षमता, विश्वसनीयता, प्रयोज्य, प्रदर्शन, रखरखाव और पोर्टेबिलिटी शामिल हैं। दुर्भाग्य से, पीएसपी के संदर्भ में, केवल एक बड़े संदर्भ को ध्यान में रखते हुए दोषों के घनत्व का विश्लेषण संभव है। हालांकि, यहां कठिनाइयां बहुत गंभीर हो सकती हैं।



अंजीर। 1. PSP की गुणवत्ता में सुधार

बॉक्स आरेख में, "बॉक्स" डेटा सेट के 25 वें और 75 वें प्रतिशत पर दिखाए जाते हैं, और मध्य केंद्र रेखा है। बॉक्स आरेख के इस संस्करण में, "संपर्क" को डेढ़ अंतर-चतुर्थक श्रेणी द्वारा दर्शाया जाता है और इसका उपयोग उत्सर्जन निर्धारित करने के लिए किया जा सकता है। पूरे चार्ट के माध्यम से एक पंक्ति पूरे डेटा सेट के लिए कुल औसत का प्रतिनिधित्व करती है। प्रत्येक जोड़े के लिए छात्र टी-टेस्ट (प्रत्येक जोड़ी छात्र की टी) और कई टुकड़ी-क्रेमर समूहों के सभी जोड़े की तुलना (सभी जोड़े तुके-क्रेमर) क्रमशः उदार और रूढ़िवादी तुलना मानदंड देते हैं; यदि तुलनात्मक मंडल ओवरलैप नहीं होते हैं या चौराहे का बाहरी कोण 90 डिग्री से कम है, तो हम यह निष्कर्ष निकाल सकते हैं कि विभिन्न समूहों के औसत मान किसी दिए गए विश्वास स्तर (α = 0.05) में काफी भिन्न होते हैं।



अंजीर। 2. असाइनमेंट की गुणवत्ता में सुधार

एक और वाजिब सवाल यह हो सकता है: क्या दोषों की संख्या का अध्ययन उनके घनत्व के विश्लेषण से अधिक जानकारी प्रदान नहीं करेगा, यह देखते हुए कि कार्यों का आकार लगभग समान है? जैसा कि अंजीर में देखा जा सकता है। 3, पिछले पांच नौकरियों का आकार पहले पांच से बड़ा है, लेकिन आकार की परिवर्तनशीलता एक परियोजना के आकार को निर्धारित करने के लिए एक उपाय के रूप में कोड (एलओसी) की पंक्तियों की संख्या का उपयोग करने की अनुपयुक्तता पर जोर देती है। चूंकि सभी छात्रों को समान कार्य दिए गए थे और समान प्रोग्रामिंग भाषा का उपयोग किया गया था, इसलिए प्रत्येक व्यक्तिगत प्रोग्रामर द्वारा किए गए निर्णयों से मतभेदों को समझाया जाना चाहिए।



अंजीर। 3. PSP नौकरियों के विभिन्न आकार (कोड की लाइनों की संख्या)

दोषों की संख्या को सामान्य करने के लिए प्रोग्राम आयाम के एक उपाय के रूप में कोड की लाइनों का उपयोग करने के बारे में संदेह के बावजूद, अंजीर। 4 आप देख सकते हैं कि PSP नौकरियों में दोषों की संख्या मुख्य रूप से कम हो गई है, इस तथ्य के बावजूद कि कोड की लाइनों की संख्या बढ़ रही है। यह परिकल्पना की पुष्टि करता है कि PSP में विकास प्रक्रिया का संगठन गुणवत्ता में सुधार करता है।



अंजीर। 4. PSP में परीक्षण के दौरान पाए गए दोषों की संख्या

सवाल उठ सकता है, प्रक्रिया के अलावा कौन से कारक सॉफ्टवेयर की गुणवत्ता को प्रभावित करते हैं। संभावित विकल्पों में, एक प्रोग्रामर के अनुभव और शिक्षा जैसे कारकों का सुझाव दिया जा सकता है, हालांकि, न तो एक और न ही दूसरे, जैसा कि अध्ययन से पता चला है, गुणवत्ता को प्रभावित करता है। विभिन्न प्रोग्रामिंग भाषाओं को ध्यान में रखने वाले डेटा की एक बड़ी सरणी पर विचार करने से पता चलता है कि प्रोग्रामिंग भाषा प्रोग्रामर की व्यक्तिगत क्षमताओं के विपरीत ऐसा कारक नहीं है, जैसा कि अंजीर में दिखाया गया है। 5।
प्रोग्रामर को चार स्तरों पर पहले तीन कार्यों के परिणामों के आधार पर क्षमता से विभाजित किया गया था। जैसा कि अंजीर से देखा जा सकता है। 5, बार-बार डेटा परिवर्तन के मॉडल के आधार पर संकलित, नेता (TQ) उन पिछड़ने (बीक्यू) (बी 2 और टी 2 के रूप में नामित उनके बीच दो समूहों को भी अपने सापेक्ष पदों को बनाए रखते हैं) की तुलना में बेहतर ढंग से कार्यों का सामना करते हैं। ऊपरी चतुर्थांश से छात्रों की सॉफ्टवेयर गुणवत्ता दोगुनी से अधिक हो गई है, और निचले चतुर्थांश के छात्रों की संख्या चौगुनी से अधिक हो गई है।
यह ध्यान दिया जाना चाहिए कि प्रोग्रामर की क्षमता को कई अन्य तरीकों से मापा जा सकता है। हमने जो तरीका चुना, वह परीक्षण में पहचाने गए सॉफ़्टवेयर की गुणवत्ता पर केंद्रित है, जो कई दोषों (उच्च गुणवत्ता वाले विकास) और उनकी प्रभावी पहचान और उन्मूलन (उच्च-गुणवत्ता की समीक्षा) की धारणा से प्रभावित है। विश्लेषण में, इन दो कारणों को अलग नहीं किया गया है।



अंजीर। 5. प्रोग्रामर की क्षमता में गुणात्मक रुझान

उत्पादकता पर प्रभाव

एक समान विश्लेषण प्रदर्शन के लिए किया जा सकता है (व्यय संसाधनों के परिणाम का अनुपात), प्रति घंटे कोड की लाइनों की संख्या के रूप में मापा जाता है। जैसा कि अंजीर में दिखाया गया है। 6, पीएसपी प्रक्रियाओं में उत्पादकता 12 प्रतिशत बढ़ी और परिवर्तनशीलता 11 प्रतिशत (साथ ही पीएसपी 0 और पीएसपी 3 के बीच सांख्यिकीय रूप से महत्वपूर्ण अंतर) में कमी आई। पाठक के विवेक पर इस तरह की वृद्धि महत्वपूर्ण है या नहीं। कई वातावरणों में, आवश्यकताओं में परिवर्तनशीलता जैसे कारक इस छोटी वृद्धि की भरपाई करने की संभावना रखते हैं, लेकिन PSP सीखने वाले दर्शकों के नियंत्रित वातावरण में, प्रभाव स्पष्ट है।



अंजीर। 6. PSP प्रदर्शन में सुधार

इस विश्लेषण के नुकसान भी गुणात्मक विश्लेषण की खामियों को पार करते हैं। प्रदर्शन को मापने के लिए प्रति घंटे कोड की लाइनों की संख्या की गणना करना बहुत खराब तरीका है। हालांकि, यह कहना असंभव है कि क्या विकल्प जैसे कार्यात्मक बिंदुओं, आवश्यकताओं का विश्लेषण, या प्रति घंटे उपयोगकर्ता कहानियों की संख्या सबसे अच्छा विकल्प है, हालांकि इनमें से सभी चार विश्लेषण (और अन्य) सॉफ्टवेयर विकास परियोजनाओं में उपयोग किए जाते हैं। एक विकल्प एक कार्य पर खर्च किए गए घंटों की संख्या का विश्लेषण करना होगा, जैसा कि अंजीर में दिखाया गया है। 7. यह विश्लेषण प्रत्येक व्यक्तिगत कार्य के लिए प्रदर्शन को मापता है, लेकिन प्रत्येक प्रोग्रामर द्वारा किए गए निर्णयों में अंतर को ध्यान में नहीं रखता है (जैसा कि चित्र 3 में दिखाया गया है)।



अंजीर। 7. असाइनमेंट पर खर्च किया गया प्रयास

विश्लेषण से शिक्षा के प्रभाव और उत्पादकता पर वर्षों के अनुभव की संख्या का पता नहीं चला। पूरे पीएसपी डेटासेट के लिए, C ++ और Java ने प्रति घंटे कोड की लाइनों की संख्या को मापने पर C और Visual Basic से "अधिक प्रदर्शन" दिखाया। हालांकि, यदि आप समस्याओं को हल करने में खर्च किए गए प्रयास की मात्रा को देखते हैं (जैसा कि कार्य संख्या 10 के लिए चित्र 8 में दिखाया गया है), तो प्रोग्रामिंग भाषाओं के बीच कोई अंतर नहीं था।


अंजीर। 8. विभिन्न भाषाओं का उपयोग करते समय प्रयास में अंतर (कार्य संख्या 10)

प्रति घंटे कोड की लाइनों की संख्या के रूप में प्रदर्शन को मापते समय, एक प्रोग्रामर की क्षमता प्रदर्शन को प्रभावित करती है। इसके अलावा, यह पता चला था कि उत्पादकता गुणवत्ता के साथ बढ़ रही है (उम्मीद के मुताबिक)।

निष्कर्ष

इस लेख में प्रस्तुत परिणाम PSP पर पिछले काम के परिणामों के साथ ओवरलैप करते हैं, लेकिन परिणामों की व्याख्या से जुड़ी कुछ कठिनाइयों पर ध्यान देते हैं। छात्रों द्वारा किए गए कार्यों के आधार पर वास्तविक परियोजनाओं के बारे में निष्कर्ष निकालने की संभावना के बारे में संदेह व्यक्त किया गया। हालांकि, पीएसपी कक्षाएं अक्सर कक्षाओं के बजाय वास्तविक परिस्थितियों में आयोजित की जाती हैं, और इस नमूने में डेवलपर्स के पास 7 साल के अनुभव के साथ 34 साल का अनुभव है। इस संबंध में, PSP का अध्ययन करने वाले छात्र कंप्यूटर विज्ञान संकाय के छात्रों की तुलना में परियोजनाओं में शामिल विशिष्ट डेवलपर्स की तरह हैं।
एक अधिक महत्वपूर्ण मुद्दा यह है कि पीएसपी प्रशिक्षण के दौरान किए गए कार्य वास्तविक डिजाइन उद्देश्यों के अनुरूप हैं। और यद्यपि प्रत्येक कार्य वास्तविक डिजाइन कार्य के ढांचे में फिट बैठता है, लेकिन PSP में कार्य अनिश्चितता और आवश्यकताओं या उत्पाद एकीकरण की उच्च परिवर्तनशीलता जैसी समस्याओं से संबंधित नहीं हैं, जो वास्तविक परियोजनाओं में सबसे बड़ी कठिनाइयों को उत्पन्न करते हैं और ऐसे क्षेत्र हैं जहां अनुभव और तैयारी एक महत्वपूर्ण भूमिका निभा सकते हैं। सफल होने के लिए। PSP ने टीम विकास प्रक्रिया (TSP) की मूल बातें सिखाईं, और यह पता चला कि TSP परियोजनाओं ने गुणवत्ता में सुधार किया और उत्पादकता में वृद्धि हुई।
इस अध्ययन द्वारा उठाया गया सबसे कठिन प्रश्न पूरे सॉफ्टवेयर विकास उद्योग की विशेषता है: हम उत्पादकता और गुणवत्ता को कैसे माप सकते हैं? जैसा कि यह काम दिखाया गया है, दोष घनत्व के सामान्य मैट्रिक्स और प्रति घंटे कोड की लाइनों की संख्या में महत्वपूर्ण कमियां हैं। संभावित रूप से अधिक विश्वसनीय मीट्रिक, जैसे कि प्रसंस्करण की मात्रा (दोषों को ठीक करने में बिताया गया समय), सभी को ज्ञात नहीं है और शायद ही कभी इसका उपयोग किया जाता है। शायद वर्णित मैट्रिक्स उपयोगी साबित होंगे, यह देखते हुए कि यह संभव नहीं है कि सर्वोत्तम विकल्पों को ढूंढना और उन्हें लागू करना संभव होगा, लेकिन इन विश्लेषणों के आधार पर किसी भी निर्णय से पहले निष्कर्षों को सावधानीपूर्वक तौला जाना चाहिए। साक्ष्य-आधारित प्रबंधन में, संदर्भ महत्वपूर्ण है।
इस लेख के एक समीक्षक ने कहा कि यह एक और सवाल पूछना उचित होगा: अगर यह इतना सफल है तो पीएसपी का उपयोग अधिक बार क्यों नहीं किया जाता है? दुर्भाग्य से, सॉफ्टवेयर इंजीनियरिंग में कई सर्वोत्तम प्रथाओं को सभी कंपनियों द्वारा स्वीकार नहीं किया जाता है, उनके उपयोग के लाभों के मजबूत सबूत के बावजूद। उदाहरण के लिए, अनुसंधान की एक बड़ी मात्रा है जो निरीक्षणों की प्रभावशीलता और दक्षता की पुष्टि करती है, लेकिन कितने संगठन व्यवस्थित रूप से मैत्रीपूर्ण मूल्यांकन के कुछ रूप का उपयोग करते हैं और यहां तक ​​कि इतनी सख्त सहकर्मी समीक्षा भी करते हैं? शोधकर्ता सूचित निर्णय लेने में मदद करने के लिए सबूत इकट्ठा कर सकते हैं और शिक्षकों और सलाहकारों की तरह, एक या दूसरे सर्वोत्तम अभ्यास को अपनाने के लिए संघर्ष कर सकते हैं, लेकिन सॉफ्टवेयर इंजीनियरिंग में प्रक्रियाओं का संगठन अभी भी अपेक्षाकृत युवा है।

क्षमता परिपक्वता मॉडल, सीएमएम और सीएमएमआई कार्नेगी मेलन विश्वविद्यालय के पंजीकृत ट्रेडमार्क हैं।

SMCMM इंटीग्रेशन, पर्सनल सॉफ्टवेयर प्रोसेस, पीएसपी और एसईआई कार्नेगी मेलन यूनिवर्सिटी के सेवा चिह्न हैं।

लक्सॉफ्ट ट्रेनिंग में 17 दिसंबर को मार्क पॉल द्वारा मास्टर क्लास के बारे में अधिक पढ़ें ।