आईटी परियोजना आवश्यकताओं का प्रबंधन

शुभ दोपहर, प्रिय आवास!

मैं लंबे समय से इस अद्भुत संसाधन का पाठक रहा हूं, और अब, आखिरकार, मैंने अपना हाथ आजमाने का फैसला किया। मैंने देखा कि हैबर पर परियोजना प्रबंधन का विषय संबंधित ब्लॉग में काफी व्यापक रूप से कवर किया गया है, लेकिन प्रबंध आवश्यकताओं के बारे में कुछ भी नहीं मिला। खैर, इस अंतराल को भरने का समय आ गया है!

परिचय

आज की अर्थव्यवस्था में, विजेता वह है जो कम के साथ अधिक उत्पादन करता है। सस्ती कच्चे माल और सामग्री, सस्ते श्रम, प्रक्रिया अनुकूलन और उनके स्वचालन के उपयोग के साथ लागत में कमी संभव है। स्वचालन से लागतों में एक-सौ-प्रतिशत की कमी नहीं होती है, लेकिन आपको कम लागत के साथ अधिक जानकारी संसाधित करने की अनुमति मिलती है।

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



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

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

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

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

आईटी क्षेत्र में आईबीएम के एक अध्ययन के अनुसार, सॉफ्टवेयर विकास संगठन आवश्यकताओं के प्रबंधन के लिए अप्रभावी दृष्टिकोण के परिणामस्वरूप 60% समय व्यतीत करते हैं। उन संगठनों में जिनके पास पर्याप्त व्यावसायिक विश्लेषण क्षमता नहीं है, परियोजनाएं सफल होने की तुलना में तीन गुना अधिक असफल होती हैं। आवश्यकताओं और उनके प्रबंधन की सही परिभाषा के साथ, गलत और अपूर्ण आवश्यकताओं की संख्या को कम करके प्रोजेक्ट ओवररन को 20% तक कम किया जा सकता है।

आवश्यकताएँ प्रबंधन

आवश्यकताओं को प्रबंधित करने से पहले, हम यह समझेंगे कि आवश्यकता क्या है और आवश्यकताओं का प्रबंधन क्या है और इसकी आवश्यकता क्यों है।

आवश्यकताएँ प्रबंधन - एक ऐसी प्रक्रिया जिसमें पहचान, पहचान, प्रलेखन, विश्लेषण, ट्रैकिंग, आवश्यकताओं का प्राथमिकताकरण, आवश्यकताओं पर समझौता और फिर परिवर्तन का प्रबंधन और इच्छुक पार्टियों को सूचित करना शामिल है। आवश्यकताएँ प्रबंधन पूरे उत्पाद जीवन चक्र के दौरान एक सतत प्रक्रिया है।

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

सॉफ्टवेयर इंजीनियरिंग की शर्तों के IEEE शब्दावली के अनुसार, जो आमतौर पर स्वीकृत अंतर्राष्ट्रीय मानक शब्दावली है, आवश्यकता है:

1. समस्याओं को हल करने या लक्ष्यों को प्राप्त करने के लिए उपयोगकर्ता के लिए आवश्यक शर्तें या क्षमताएं;
2. एक सिस्टम या सिस्टम घटक की शर्तों या क्षमताओं को अनुबंध को पूरा करने या मानकों, विनिर्देशों, या अन्य औपचारिक दस्तावेजों को पूरा करने के लिए होना चाहिए;
3. अनुच्छेद 1 और 2 के लिए शर्तों या संभावनाओं की एक प्रलेखित प्रस्तुति।

आईएसओ / आईईसी 29148 के अनुसार, आवश्यकता विकास मानक, एक आवश्यकता एक बयान है जो किसी उत्पाद या प्रक्रिया डिजाइन के परिचालन, कार्यात्मक मापदंडों, विशेषताओं, या सीमाओं की पहचान करता है जो कि असंदिग्ध, सत्यापन योग्य और औसत दर्जे का है। उत्पाद या प्रक्रिया स्वीकृति के लिए आवश्यक (ग्राहक या आंतरिक गुणवत्ता आश्वासन दिशानिर्देश द्वारा)
ITILv3 शब्दावली भी आवश्यकताओं के एक सेट के रूप में इस तरह की अवधारणा को परिभाषित करती है - एक दस्तावेज जिसमें किसी उत्पाद के लिए सभी आवश्यकताएं होती हैं, साथ ही एक नई या परिवर्तित आईटी सेवा भी होती है।

एक आवश्यकता में निम्नलिखित विशेषताएं होनी चाहिए:

1. एकता - एक आवश्यकता एक और केवल एक चीज का वर्णन करती है।
2. पूर्णता - आवश्यकता पूरी तरह से एक ही स्थान पर परिभाषित है और सभी आवश्यक जानकारी मौजूद है।
3. संगति - आवश्यकता अन्य आवश्यकताओं के विपरीत नहीं है और पूरी तरह से प्रलेखन के अनुरूप है।
4. परमाणु - एक आवश्यकता को छोटे लोगों में विभाजित नहीं किया जा सकता है।
5. ट्रैसेबिलिटी - आवश्यकता पूरी तरह से या आंशिक रूप से व्यावसायिक आवश्यकताओं को पूरा करती है जैसा कि इच्छुक पार्टियों और दस्तावेज द्वारा कहा गया है।
6. प्रासंगिकता - आवश्यकता समय के साथ अप्रचलित नहीं हुई है।
7. व्यवहार्यता - एक परियोजना के एक भाग के रूप में एक आवश्यकता को लागू किया जा सकता है।
8. असंदिग्धता - आवश्यकता को तकनीकी शब्दजाल, शब्दकोष और अन्य छिपे हुए योगों का सहारा लिए बिना परिभाषित किया गया है। यह वस्तुओं और तथ्यों को व्यक्त करता है, न कि व्यक्तिपरक राय। एक और केवल एक व्याख्या संभव है। परिभाषा में फ़ज़ी वाक्यांश शामिल नहीं हैं, नकारात्मक और मिश्रित कथनों का उपयोग निषिद्ध है।
9. दायित्व - आवश्यकता इच्छुक पक्ष द्वारा परिभाषित एक विशेषता है, जिसके अभाव में निर्णय की हीनता होती है, जिसे अनदेखा नहीं किया जा सकता है। एक वैकल्पिक आवश्यकता एक आवश्यकता के बहुत अवधारणा के विपरीत है।
10. सत्यापन क्षमता - आवश्यकता की व्यवहार्यता को सत्यापित किया जा सकता है।

ITILv3 के अनुसार, परियोजना में सभी आवश्यकताओं को निम्नलिखित समूहों में विभाजित किया जा सकता है:

1. कार्यात्मक (कार्यात्मक) - व्यवसाय फ़ंक्शन को स्वयं लागू करें।
2. प्रबंधन (प्रबंधनीयता) - सस्ती और सुरक्षित सेवाओं के लिए आवश्यकताएं; सिस्टम होस्टिंग, प्रशासन और सुरक्षा से संबंधित है।
3. एर्गोनोमिक (उपयोगिता) - अंतिम उपयोगकर्ताओं की सुविधा के लिए।
4. वास्तुकला (आर्किटेक्चरल) - सिस्टम आर्किटेक्चर के लिए आवश्यकताएं।
5. इंटरैक्शन (इंटरफ़ेस) - मौजूदा एप्लिकेशन और सॉफ़्टवेयर और एक नए एप्लिकेशन के बीच संबंध के लिए।
6. सेवा स्तर (सेवा स्तर) - सेवा के व्यवहार, उसके आउटपुट डेटा की गुणवत्ता और ग्राहक द्वारा मापा जाने वाले अन्य गुणवत्ता पहलुओं का वर्णन करें।

सामान्य आवश्यकता प्रबंधन सॉफ्टवेयर

वर्तमान में, आईबीएम रैशनल रिक्विसिटप्रो, टेललॉजिक डोजर्स, सिबेस पावरडिजाइनर और बोरलैंड कैलिबर आरएम जैसी आवश्यकताओं प्रबंधन प्रणालियों का व्यापक रूप से उपयोग किया जाता है।

मैं निर्माताओं की वेबसाइटों से ली गई उपरोक्त प्रणालियों की मुख्य कार्यात्मक क्षमताओं का संक्षिप्त अनुवाद दूंगा।

आईबीएम तर्कसंगत आवश्यक प्रो

तर्कसंगत सॉफ़्टवेयर आवश्यकताओं की पहचान और प्रबंधन के लिए सर्वोत्तम अभ्यास प्रदान करता है जो निम्नलिखित समस्याओं को हल करने में आपकी सहायता करके समय और धन की बचत करते हैं:

• हितधारकों के साथ संयुक्त कार्य के माध्यम से सुधार और बाजार में तेजी लाने की मात्रा को कम करना।
• आवश्यकताओं और उनके प्रबंधन में परिवर्तन पर नियंत्रण के कारण श्रम उत्पादकता में वृद्धि।
• चल रहे परिवर्तनों के प्रभाव का आकलन करके लागत और जोखिमों को कम करना।
• आवश्यकताओं के पूर्ण पता लगाने की क्षमता के माध्यम से अनुपालन का प्रदर्शन।

परिमेय आवश्यक वस्तुएं प्रोजेक्ट टीमों को आवश्यकताओं को प्रबंधित करने, उच्च-गुणवत्ता के उपयोग परिदृश्य बनाने, ट्रैकिंग क्षमताओं का विस्तार करने, सहयोग में सुधार करने, सुधार की आवश्यकता को कम करने और गुणवत्ता में सुधार करने में मदद करती हैं।

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

आईबीएम तर्कसंगत / दूरदर्शी दरवाजे

आईबीएम तर्कसंगत / टेलीगॉनिक दरवाजे - आवश्यकताओं के प्रबंधन और जटिल उच्च-तकनीकी उत्पादों (विमान, जहाज निर्माण, रेल, मिसाइल, कार, आदि) के लिए समाधान का एक परिवार।

प्रारंभ में, डीओओआरएस केवल सॉफ्टवेयर विकास प्रक्रिया में आवश्यकताओं के प्रबंधन के साधन के रूप में विकसित किया गया था। हालांकि, डीओओआरएस में सन्निहित विचार सफल थे और फिलहाल इस प्रणाली का उपयोग ऐसे अभियानों में भी किया जाता है जो सॉफ्टवेयर विकास से संबंधित नहीं हैं, लेकिन इंजीनियरिंग प्रणालियों को विकसित करते समय, बड़ी मात्रा में परस्पर सूचनाओं को नियंत्रित करने के लिए मजबूर किया जाता है।

निम्नलिखित जानकारी टेललॉजिक डीओआरएस से प्राप्त की जा सकती है:

• प्रत्येक आवश्यकता के लिए कार्य के प्रदर्शन की स्थिति अलग-अलग, साथ ही आवश्यकताओं के समूह के लिए।
• पूरे प्रोजेक्ट पर काम की स्थिति।
• प्रत्येक आवश्यकता या आवश्यकताओं के समूह के लिए जिम्मेदार व्यक्ति।
• इतिहास की आवश्यकताओं को बदलें।
• परियोजना में लागू होने से पहले आवश्यकता को लागू करने के लिए आवश्यक संसाधन।
• ग्राहकों की आवश्यकताओं, संदर्भ की शर्तें, सत्यापन, परीक्षण कार्यक्रम और परियोजना प्रबंधन कार्यों के बीच संबंध।
• वर्ग, मॉडल या ड्राइंग जिसमें विशेष आवश्यकता को लागू किया जाता है।

बोरलैंड कैलिबर आर.एम.

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

बोरलैंड कैलिबर आरएम में निम्नलिखित विशेषताएं हैं:

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

अन्य सॉफ्टवेयर

काफी प्रसिद्ध आवश्यकताओं प्रबंधन प्रणाली, जैसे:

• साइबेस पॉवरसाइडिग्नर
• OpenSource आवश्यकताएँ प्रबंधन उपकरण
• आवश्यकताएँ और अन्य

आवश्यकताओं के प्रबंधन के लिए एक नया दृष्टिकोण

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

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

मान लें कि निम्नलिखित आवश्यकताएं क्रमशः ए और बी के उद्यमों में दस्तावेज़ मार्गों का वर्णन करती हैं:
ए - {ए, बी, सी, डी, ई}
बी - {एफ, बी, सी, डी, ई}

यहां आप देख सकते हैं कि एफ और ए से हमारा मतलब है दस्तावेज़, और बी, सी, डी, ई - उनके मार्ग।

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

आप सभी का ध्यान देने के लिए धन्यवाद, मुझे टिप्पणियों का इंतजार है।