सॉफ्टवेयर विकास के लिए जोखिम प्रबंधन

जोखिम प्रबंधन एक प्रणाली है जो लागत, समय सारिणी या प्रोजेक्ट के तकनीकी सफलता या प्रोजेक्ट टीम के मनोबल के लिए हानिकारक हो सकने वाले मुद्दों की पहचान, संबोधन और उन्हें दूर करने के लिए है।

“कल के मुद्दे आज के जोखिम हैं।” इसलिए, “जोखिम” को स्पष्ट रूप से एक मुद्दे के रूप में परिभाषित किया गया है जो किसी क्षति का कारण बन सकता है या प्रोजेक्ट के शेड्यूल को खतरा दे सकता है, लेकिन अभी तक घटित नहीं हुआ है।

यदि आप जोखिमों के प्रबंधन के लिए पहल करने के लिए नहीं लेते हैं, तो आप जोखिमों का सामना करेंगे।

सॉफ्टवेयर विकासयह एक उच्च जोखिम वाली गतिविधि है, और प्रोजेक्ट विकास प्रक्रिया के किसी भी चरण में जोखिम हो सकते हैं। एक सक्रिय जोखिम प्रबंधन विधि अपनाने से प्रोजेक्ट प्रक्रिया अधिक स्थिर हो सकती है, प्रोजेक्ट को ट्रैक और नियंत्रित करने की उच्च क्षमता प्राप्त हो सकती है, और जोखिमों को बचाने या स्थानांतरित करने या जोखिमों के नकारात्मक प्रभावों को कम करने में सक्षम हो सकती है।

जोखिम प्रबंधन प्रोजेक्ट जोखिमों की पहचान, विश्लेषण, प्रतिक्रिया और मॉनिटरिंग की प्रक्रिया है। यह प्रोजेक्ट प्रबंधन में एक बहुत महत्वपूर्ण प्रबंधन गतिविधि है। सॉफ्टवेयर जोखिम प्रबंधन के प्रभावी कार्यान्वयन सॉफ्टवेयर प्रोजेक्ट विकास के सुचारू समाप्ति की गारंटी है।

जोखिम प्रबंधन की सफलता में तीन तत्वों को शामिल करना आवश्यक है:

• प्रोजेक्ट विकास योजना में एक जोखिम प्रबंधन योजना का निर्माण किया जाना चाहिए;
• प्रोजेक्ट बजट में जोखिम को हल करने के लिए आवश्यक धनराशि शामिल होनी चाहिए;
• जब जोखिम का आकलन किया जाता है, तो जोखिम के प्रभाव को प्रोजेक्ट योजना में भी शामिल किया जाना चाहिए।

चलिए चर्चा करें कि हम सॉफ्टवेयर विकास के दौरान अक्सर होने वाले जोखिमों को कम करने के लिए कैसे रोकथाम कार्रवाई कर सकते हैं।

1. अस्पष्ट आवश्यकताएं— अस्पष्ट आवश्यकताएं सॉफ्टवेयर विकास प्रक्रिया में अक्सर आने वाली समस्याएं हैं। ऐसी समस्याएं आवश्यकताओं के अपरिभाषित दायरे, अपरिष्कृत आवश्यकताएं, अस्पष्ट आवश्यकता विवरण, गायब आवश्यकताएं और एक दूसरे के विरोधी आवश्यकताओं जैसे कई पहलुओं में प्रकट होती हैं। सॉफ्टवेयर विकास प्रक्रिया के जीवन चक्र में अस्पष्ट आवश्यकताओं के कारण उत्पन्न बर्बादी सबसे बड़ी है और जल्द से जल्द निपटाया जाना चाहिए। उपयोगकर्ता की आवश्यकताओं को निर्धारित करना बहुत कठिन है।

रोकथाम कार्रवाई

• छोटे और अधिक बार चर्चाओं और बैठकों के माध्यम से उपयोगकर्ताओं को विकास में भागीदार बनाएं
• वायरफ्रेम / उपयोगकर्ता इंटरफेस प्रोटोटाइप का उपयोग करके स्टेकहोल्डर्स के साथ विकास और संचार करें

2. उपयोगकर्ताओं के व्यापक वितरण और बड़ी संख्या में उपयोगकर्ताओं वाले प्रोजेक्टों के लिए, उपयोगकर्ता आवश्यकताओं को व्यापक रूप से एकत्र करना आमतौर पर कठिन होता है, और आवश्यकताओं की पुष्टि के लिए आवश्यकता अनुसंधान बैठकों का उपयोग किया जाता है।

रोकथाम कार्रवाई

बैठक से कुछ हफ्ते पहले, हमने विभिन्न क्षेत्रों और विभागों में उपयोगकर्ताओं की आवश्यकताओं का जांच किया, और फिर सभी क्षेत्रों या विभागों से उपयोगकर्ता प्रतिनिधियों को एकत्र किया और आवश्यकताओं को बैठक के माध्यम से एकत्र करने के लिए आवश्यकता सेमिनार आयोजित किया। यह विधि उन उपयोगकर्ताओं के लिए उपयुक्त है जिनके पास कुछ आईटी अनुभव है।

2. 80/20 का फंदा— जब कोई प्रोजेक्ट मैनेजर या डेवलपर कहता है कि कार्य का 80% पूरा हो गया है, तो आपको सावधान रहना चाहिए। क्योंकि शेष 20% को 80% समय लग सकता है, या यह कभी पूरा नहीं हो सकता है।

सॉफ्टवेयर विकास प्रोजेक्ट आमतौर पर प्रोजेक्ट प्रगति और सॉफ्टवेयर गुणवत्ता के मामले में दृश्यता की कमी का शिकार होते हैं। जितनी कम दृश्यता प्रोजेक्ट में होती है, उतना ही उसे नियंत्रित करना कठिन होता है, और असफल होने की संभावना बढ़ जाती है। हम आवर्धित विकास, तकनीकी समीक्षा और निरंतर एकीकरण के माध्यम से प्रोजेक्ट दृश्यता में सुधार कर सकते हैं।

रोकथाम कार्रवाई:

• आवर्धित विकास: आवर्धित विकास मॉडल का उपयोग करके, उत्पाद डिलीवरी प्रक्रिया को कई चरणों में बांटा जाता है और कार्यों के अनुसार बढ़ते हुए डिलीवर किया जाता है।
• तकनीकी समीक्षा सॉफ्टवेयर गुणवत्ता सुनिश्चित करने का एक महत्वपूर्ण हिस्सा है। तकनीकी समीक्षा में कोड ड्रिल, मीटिंग रिव्यू और पीयर रिव्यू शामिल हैं। कोड समीक्षा डेवलपर्स के बीच एक आपसी समीक्षा हो सकती है या सीनियर डेवलपर्स द्वारा सामान्य डेवलपर्स की समीक्षा हो सकती है; मीटिंग रिव्यू को आमतौर पर प्रत्येक दो हफ्ते में कम से कम एक बार किया जाता है, और प्रत्येक समीक्षा का समय बहुत लंबा नहीं होना चाहिए, जो प्रोजेक्ट के सफलता के लिए एक महत्वपूर्ण गारंटी है।
• निरंतर एकीकरण अंतिम बड़े पैमाने पर एकीकरण और आयोजन प्रक्रिया को प्रोजेक्ट के साप्ताहिक और दैनिक विकास प्रगति में फैला सकता है। इस प्रकार प्रोजेक्ट के हर व्यक्ति को किसी भी समय वर्तमान समग्र प्रगति को समझने में सक्षम होगा, और एकीकरण प्रक्रिया में समस्याओं को त्वरित रूप से पहचान और हल कर सकता है।

3. तकनीकी नवाचारएक अन्वेषणात्मक और रचनात्मक तकनीकी और आर्थिक गतिविधि है। विकास प्रक्रिया में, नई तकनीकों को लागू करने में निश्चित रूप से विभिन्न जोखिमों का सामना करना पड़ता है। T-आकृति वाले सॉफ्टवेयर विकास और स्पाइक उपयोगकर्ता कहानियों के साथ नई तकनीक के प्रोटोटाइपिंग जैसे उपाय।

4. प्रदर्शन की समस्याएं—सॉफ्टवेयर डिजाइन की गहराई की कमी के कारण, प्रदर्शन की समस्याएं आमतौर पर सिस्टम के डेप्लॉय करने के बाद या एक नए सिस्टम के उपयोग के कुछ समय बाद प्रकट होती हैं। प्रदर्शन की समस्याओं को आमतौर पर बहुत अधिक अनुकूलन कार्य की आवश्यकता होती है, या फिर आंशिक या सम्पूर्ण डिजाइन पुनर्निर्माण की आवश्यकता होती है। उपयोगकर्ता या डेवलपर्स दोनों को प्रदर्शन की समस्याएं नहीं चाहिए। टीम को इस समस्या के बारे में जागरूक होना चाहिए, विकास प्रक्रिया के दौरान प्रदर्शन योजना और परीक्षण को लागू करना चाहिए, और गैर-कार्यात्मक आवश्यकताओं में प्रदर्शन आवश्यकताओं को शामिल करना चाहिए।

5. उपयोगकर्ता अनुकूलता की समस्याएं —सॉफ्टवेयर की उपयोगकर्ता अनुकूलता में बहुत सारे कारक शामिल हैं, जैसे कि क्या सॉफ्टवेयर कार्यक्षम है, सीखने में आसान है, याद रखने में आसान है, सुखद है, और गलतियां करने में कठिन है। अक्सर सॉफ्टवेयर की खराब उपयोगकर्ता अनुकूलता के कारण उपयोगकर्ता असंतुष्ट होते हैं और बाजार से हटा दिए जाते हैं। प्रोजेक्ट विकास में उपयोगकर्ता अनुकूलता की समस्याओं पर ध्यान देना चाहिए ताकि सॉफ्टवेयर उपयोगकर्ता अनुकूलता के जोखिमों से बचा जा सके।

निष्कर्ष

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