इंटरनेट-गति विकास: Difference between revisions
From Vigyanwiki
No edit summary |
|||
| (7 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
'''इंटरनेट-गति विकास''' एक ऐसी [[चंचल सॉफ्टवेयर विकास|सॉफ्टवेयर विकास]] पद्धति है जिसमें उच्च गति वाले उत्पाद को विकसित करने के उद्देश्य से दैनिक निर्माण के साथ एक संयुक्त [[सर्पिल मॉडल]]/[[झरना मॉडल|वाटरफॉल मॉडल]] का उपयोग किया जाता है। | '''इंटरनेट-गति विकास''' एक ऐसी [[चंचल सॉफ्टवेयर विकास|सॉफ्टवेयर विकास]] पद्धति है जिसमें उच्च गति वाले उत्पाद को विकसित करने के उद्देश्य से दैनिक निर्माण के साथ एक संयुक्त [[सर्पिल मॉडल]]/[[झरना मॉडल|वाटरफॉल मॉडल]] का उपयोग किया जाता है। | ||
इसे 1990 के दशक के अंत में विकसित किया गया था क्योंकि सॉफ्टवेयर का विकास तीव्रता से परिवर्तित हो रहा था। कंपनियों को परियोजना के लिए निर्धारित समय के भीतर पूर्ण आवश्यकताओं के साथ उत्पादों को वितरित करने में समस्या हो रही थी और इस प्रकार वे अधिक सॉफ्टवेयर विकास पद्धति में परिवर्तित हो रहे थे। इब्राहीमसन के पेपर में विकासवादी मानचित्र में इंटरनेट-गति पद्धति को कैसे विकसित किया गया था | इसे 1990 के दशक के अंत में विकसित किया गया था क्योंकि सॉफ्टवेयर का विकास तीव्रता से परिवर्तित हो रहा था। कंपनियों को परियोजना के लिए निर्धारित समय के भीतर पूर्ण आवश्यकताओं के साथ उत्पादों को वितरित करने में समस्या हो रही थी और इस प्रकार वे अधिक सॉफ्टवेयर विकास पद्धति में परिवर्तित हो रहे थे। इब्राहीमसन के पेपर में विकासवादी मानचित्र में इंटरनेट-गति पद्धति को कैसे विकसित किया गया था इसके विषय में अधिक विवरण देखा जा सकता है।<ref>Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003</ref> | ||
== इंटरनेट-गति विकास के पीछे मुख्य विचार == | == इंटरनेट-गति विकास के पीछे मुख्य विचार == | ||
सॉफ्टवेयर इंजीनियरिंग में प्रायः सबसे बड़ी समस्याओं में से एक यह है कि आवश्यकताओं में तेजी से परिवर्तन होता है और इस स्थिति के अनुकूल होने के लिए इंटरनेट-गति विकास पद्धति बनाई गई थी। यह विचार सॉफ्टवेयर इंजीनियरिंग मॉडल में दो मुख्य मानकों को जोड़ने का है | सॉफ्टवेयर इंजीनियरिंग में प्रायः सबसे बड़ी समस्याओं में से एक यह है कि आवश्यकताओं में तेजी से परिवर्तन होता है और इस स्थिति के अनुकूल होने के लिए इंटरनेट-गति विकास पद्धति बनाई गई थी। यह विचार सॉफ्टवेयर इंजीनियरिंग मॉडल में दो मुख्य मानकों को जोड़ने का है अर्थात् सर्पिल मॉडल और वॉटरफॉल मॉडल को एक नए मॉडल में और इस नए मॉडल पर एक नई सॉफ्टवेयर इंजीनियरिंग पद्धति को आधार बनाना है। वॉटरफॉल मॉडल की मुख्य कमी यह थी कि जब आवश्यकताओं में परिवर्तन मे होता है तो यह बहुत कठोर और बहुत नम्य नहीं होता है जबकि सर्पिल मॉडल की कमी यह थी कि यह बहुत संरचनात्मक नहीं था। इंटरनेट-गति के विकास के पीछे विचार यह है कि इन मॉडलों के संयोजन का परिणाम एक ऐसी पद्धति के रूप में होगा जिसमें ये कमी नहीं हैं और उन स्थितियों में उपयोग करने के लिए एक अपेक्षाकृत अच्छा तरीका है जहां आवश्यकताएं तीव्रता से परिवर्तित हो सकती हैं लेकिन परियोजना को संरचनात्मक तरीके से क्रियान्वित किया जाना आवश्यक होता है। | ||
== | == इंटरनेट-गति विकास पद्धति का लक्ष्य == | ||
इंटरनेट-गति विकास पद्धति का लक्ष्य सॉफ्टवेयर | इंटरनेट-गति विकास पद्धति का लक्ष्य सॉफ्टवेयर विकासक को एक संरचनात्मक तरीके से एक परियोजना को पूर्ण करने की स्वीकृति देना है लेकिन ग्राहक की आवश्यकताओ को पूर्ण करने में सक्षम होना है। इसका उद्देश्य विकास के माध्यम से कम समय में एक सॉफ्टवेयर उत्पाद प्रदान करना है। यह पद्धति पूरी तरह से कार्यान्वित प्रणाली प्रदान करने का एक साधन प्रदान करती है और मील के पत्थर के उपयोग के माध्यम से किसी परियोजना में प्रगति निर्धारित करने के लिए भी आवश्यक हैं। इस पद्धति के मुख्य संस्करणों में से एक माइक्रोसॉफ्ट द्वारा बनाया गया है इसीलिए इसे माइक्रोसॉफ्ट फ्रेमवर्क भी कहा जाता है। | ||
== इंटरनेट-गति विकास पद्धति के पीछे की अवधारणा == | == इंटरनेट-गति विकास पद्धति के पीछे की अवधारणा == | ||
पहली अवधारणा जो इंटरनेट की गति के विकास के लिए बहुत महत्वपूर्ण है | पहली अवधारणा जो इंटरनेट की गति के विकास के लिए बहुत महत्वपूर्ण है एक कार्यक्षेत्र और परियोजना प्रबंधन का निर्माण है। इसका अर्थ यह है कि परियोजना के प्रारम्भ में सिस्टम की एक वैश्विक परिभाषा बनाई जाती है जो यह प्रदर्शित करती है कि सिस्टम का लक्ष्य क्या है और इसकी स्थिति क्या है और क्या नहीं है। यह मौलिक प्रकारों में से एक है क्योंकि यह विकासक को कुछ दिशानिर्देश देता है कि कार्यक्षेत्र को एक [[लक्ष्यों का विवरण|विजन सारणी]] में संक्षिप्त किया जा सकता है। इस पद्धति के भीतर एक और बहुत महत्वपूर्ण अवधारणा कार्यक्षेत्र प्रबंधन है। कार्यक्षेत्र विकास को स्थगित करने के लिए कार्यक्षेत्र को परियोजना में प्रबंधित करने की आवश्यकता होती है जिसके परिणामस्वरूप रुकावट उत्पन्न होती है। यदि कार्यक्षेत्र को तीव्रता से निर्धारित किया जाएगा और कार्यक्षेत्र में परिवर्तन (जैसे अतिरिक्त सुविधाओं को जोड़ना जो पहले परियोजना के कार्यक्षेत्र से बाहर माने जाते थे) का मूल्यांकन किया जाएगा या तो स्वीकृत या अस्वीकृत कर दिया जाएगा। कार्यक्षेत्र में परिवर्तन किए जा सकते हैं लेकिन यह सदैव सुविधाओं, संसाधनों और समय के बीच व्यापार विणपन से प्रभावित होगा। लेकिन इंटरनेट-गति विकास पद्धति पारंपरिक तरीकों से बहुत अलग है और इसलिए सॉफ्टवेयर विकास पद्धति सिद्धांतों का उपयोग करती है। यह आवश्यकताओं के अनुकूलन पर ध्यान केंद्रित करता है और जैसे कि एजाइल सॉफ्टवेयर विकास के मूल सिद्धांतों पर आधारित है। | ||
इंटरनेट-गति विकास भी एक निश्चित माइक्रोसॉफ्ट फ्रेमवर्क संरचना का उपयोग करने पर ध्यान केंद्रित करता है जिससे उत्पाद बनाया जाता है और विकास की गति को विस्तृत करने के लिए उपकरणों पर अत्यधिक निर्भर करता है। इंटरनेट की गति विकास की एक और मूलभूत अवधारणा यह है कि यह छोटे समूह का उपयोग करने पर भी ध्यान केंद्रित करता है। विचार यह है कि सभी परियोजनाओं को छोटी-छोटी गतिविधियों में विभाजित किया जा सकता है जिन्हें प्रायः समानांतर में किया जा सकता है। छोटी समूहें प्रायः अपने कार्य पर अधिक ध्यान केंद्रित कर सकती हैं जिससे परियोजना के भीतर उत्तरदायित्व निर्धारित करना और प्रगति का संरक्षण करना आसान होता है। | |||
इंटरनेट-गति विकास | इंटरनेट-गति विकास की इस प्रविष्टि में चर्चा की गई अंतिम अवधारणा समानांतर विकास की अवधारणा है। इस अवधारणा का मूल रूप से तात्पर्य यह है कि सभी सॉफ्टवेयर विकास जितनी बार संभव हो समानांतर में किया जाता है। यह बहुत तीव्रता से विकास की स्वीकृति देगा और यह छोटी समूहों को जितना संभव हो सके अपनी सुविधा पर ध्यान केंद्रित करने की स्वीकृति देगा, जिसका गुणवत्ता पर अच्छा परिणाम होता है। यह सुनिश्चित करने के लिए कि अंतिम प्रणाली बनाने के लिए छोटी समूहें एक साथ कार्य करती हैं, हालांकि उनके विकास को प्रायः समकालिक करने की आवश्यकता होती है। यह दैनिक निर्माण का उपयोग करके किया जा सकता है जिसका अर्थ है कि सभी विकासक दिन के अंत में अपने कोड का परीक्षण करते हैं जिसके बाद इसको निर्मित किया जाता है जिसका मूल्यांकन और प्रगति की संरक्षण के लिए परीक्षण किया जा सकता है। निर्माण में एक विशेषता के पूर्ण होने के बाद इसे परीक्षण और परिष्कृत करने की आवश्यकता होती है जिसको कभी-कभी समकालीन और स्थिर प्रक्रिया कहा जाता है। विकसित सुविधाओं को निर्माण और परीक्षण के साथ समकालिक किया गया है। इन परीक्षणों के बाद किसी भी बग को संशोधित कर दिया जाएगा जो स्थिरीकरण भाग है। और विशेषता को अपेक्षाकृत कार्य करने के लिए परिष्कृत किया जा सकता है। | ||
इंटरनेट-गति विकास भी एक | इंटरनेट-गति का विकास विद्युत सिद्धांतों पर आधारित है और इस प्रकार इसमें [[चरम कार्यक्रम|अधिकतम प्रोग्रामिंग]], तर्कसंगत एकीकृत प्रक्रिया, गतिशील प्रणाली विकास पद्धति और [[फीचर संचालित विकास|विशिष्ट संचालित विकास]] के साथ अत्यधिक समानताएं हैं। इंटरनेट- गति का विकास हालांकि इन तरीकों से अलग है क्योंकि इसमें एक अधिक व्यापक जोखिम प्रबंधन योजना भी सम्मिलित होती है और इस परियोजना के एक बहुत ही महत्वपूर्ण उद्देश्य के रूप में गुणवत्ता है।<ref>As shown in the paper of Zuser, Heil and Grechening.</ref> इंटरनेट-गति विकास का विकास चरण भी [[खुला स्रोत सॉफ्टवेयर|मुक्त स्रोत सॉफ्टवेयर]] विकास मॉडल के साथ कुछ समानताएं प्रदर्शित करता है क्योंकि इंटरनेट के माध्यम से संचार, कोड और दस्तावेज़ीकरण को संग्रहीत करने के लिए भंडारण के उपयोग के कारण विश्व के कई विकासक इस विकास प्रक्रिया का एक भाग हो सकते हैं। . | ||
इंटरनेट | ==इंटरनेट-गति विकास के चरण== | ||
इस पद्धति के पीछे का मॉडल इस प्रकार प्रदर्शित होता है जो मॉडल विधि के पांच संरचनात्मक चरणों को दर्शाता है। इस प्रविष्टि के निम्नलिखित खंडों में इन चरणों की व्याख्या की जा सकती है जैसे परिकल्पना करना, योजना बनाना, विकास करना, स्थिर करना और परिनियोजित करना आदि मुख्य चरण है। इस चक्र के पूर्ण होने के बाद प्रणाली का एक संस्करण तैयार होता है और एक नया चक्र नया संस्करण बनाने के लिए प्रारम्भ होता है। चरणों को निम्नलिखित खंडों में समझाया गया है और एक [[मेटा-मॉडलिंग]] तकनीक के माध्यम से प्रदर्शित किया गया है। एक परियोजना के संदर्भ में बहुलता और अवधारणाओं के विषय में अधिक जानकारी बाद में समग्र डेटा मॉडल में देखी जा सकती है। | |||
== | === परिकल्पना चरण === | ||
परिकल्पना चरण को निम्नानुसार प्रदर्शित किया जा सकता है: | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 38: | Line 32: | ||
|- | |- | ||
|आवश्यकताओं का विश्लेषण करें। | |आवश्यकताओं का विश्लेषण करें। | ||
|परिकल्पना के चरण के | |परिकल्पना के चरण के समय, व्यावसायिक आवश्यकताओं की पहचान और विश्लेषण किया जाना चाहिए। | ||
“नियोजन चरण के | “नियोजन चरण के समय इन्हें और अधिक जटिलता से परिष्कृत किया जाता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA">Microsoft Solutions White Paper June 2002</ref> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA">Microsoft Solutions White Paper June 2002</ref> | ||
|- | |- | ||
|लक्ष्यों और अवरोधो को परिभाषित करें | |लक्ष्यों और अवरोधो को परिभाषित करें | ||
|"परियोजना के लक्ष्यों और | |"परियोजना के लक्ष्यों और अवरोधो के विषय में एक उच्च-स्तरीय दृष्टिकोण बनाकर परिकल्पना करना।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|फॉर्म समूह | |फॉर्म समूह | ||
|मुख्य | |मुख्य समूह का गठन। | ||
|- | |- | ||
|विजन/कार्यक्षेत्र बनाएं | |विजन/कार्यक्षेत्र बनाएं | ||
| "एक विजन/कार्यक्षेत्र दस्तावेज़ | | "एक विजन/कार्यक्षेत्र के दस्तावेज़ और वितरण।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|जोखिम निर्धारण करे। | |जोखिम निर्धारण करे। | ||
| " | | "परिकल्पना चरण के समय, समूह एक जोखिम दस्तावेज़ तैयार करता है और शीर्ष जोखिम प्रस्तुत करता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|} | |} | ||
तालिका 1: गतिविधियों की | तालिका 1: गतिविधियों की परिकल्पना करना | ||
परिकल्पना चरण में की गई | परिकल्पना चरण में की गई संरचनात्मक गतिविधियाँ आवश्यकताओं का विश्लेषण करती हैं और परियोजना के लिए एक समूह का गठन कर करती हैं जो जोखिमों का निर्धारण कर सकती हैं और परियोजना का कार्यक्षेत्र निर्धारित कर सकती हैं। परियोजना की आवश्यकताओं और लक्ष्यों से एक विजन/कार्यक्षेत्र दस्तावेज़ बनाया जाता है। यह दस्तावेज़ प्रदर्शित करता है कि जब उत्पाद वितरित किया जाता है तो उसे क्या होना चाहिए। इसमें उत्पाद की बहुत विस्तृत कार्यप्रणाली सम्मिलित नहीं होती है। | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 66: | Line 60: | ||
!परिभाषा (स्रोत) | !परिभाषा (स्रोत) | ||
|- | |- | ||
|विजन/ | |विजन/कार्यक्षेत्र दस्तावेज़ | ||
| "विजन और | | "विजन और कार्यक्षेत्र को परिभाषित करने वाला दस्तावेज़।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|दृष्टि | |विजन (दृष्टि) | ||
| " | | "विजन हल क्या हो सकता है इसका एक असीम दृष्टिकोण है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|विस्तार | |विस्तार | ||
| " | | "कार्यक्षेत्र पहचानता है कि विजन के भाग (ओं) को परियोजना को अवरोधों के भीतर पूर्ण किया जा सकता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|जोखिम मूल्यांकन दस्तावेज़ | |जोखिम मूल्यांकन दस्तावेज़ | ||
| "जोखिम मूल्यांकन के लिए मानकीकृत | | "जोखिम मूल्यांकन के लिए मानकीकृत दस्तावेज़।" | ||
(एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB">Microsoft Risk Management Discipline White Paper</ref> | (एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB">Microsoft Risk Management Discipline White Paper</ref> | ||
|- | |- | ||
|प्राथमिकता | |प्राथमिकता जोखिम सूची | ||
| "परियोजना की स्थिति, संदर्भ, मूल कारण और प्राथमिकता के लिए उपयोग किए जाने वाले | | "परियोजना की स्थिति, संदर्भ, मूल कारण और प्राथमिकता के लिए उपयोग किए जाने वाले मापन विज्ञान (संभावना, प्रभाव, जोखिम) सहित विस्तृत जोखिम की जानकारी प्रायः जोखिम विवरण फॉर्म में प्रत्येक जोखिम के लिए प्रस्तुत की जाती है।" | ||
(एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB"/> | (एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB"/> | ||
|- | |- | ||
|जोखिम योजना | |जोखिम योजना | ||
| "कार्य योजनाओं में प्राथमिकता वाली जोखिम सूची का | | "कार्य योजनाओं में प्राथमिकता वाली जोखिम सूची का अनुप्रयोग।" | ||
(एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB" /> | (एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB" /> | ||
|- | |- | ||
|परियोजना संरचना दस्तावेज़ | |परियोजना संरचना दस्तावेज़ | ||
| "परियोजना संरचना दस्तावेज़ में यह जानकारी सम्मिलित है कि | | "परियोजना संरचना दस्तावेज़ में यह जानकारी सम्मिलित है कि समूह कैसे संगठित होता है और कौन कौन सी भूमिकाएँ निभाता है और उनका विशिष्ट उत्तरदायित्व क्या होता हैं। परियोजना संरचना दस्तावेज़ ग्राहक के प्रति उत्तरदायित्व की श्रृंखला और संपर्क के नामित बिंदुओं को भी स्पष्ट करता है जो परियोजना समूह ग्राहक के साथ संरक्षित होते है। और ये परियोजना की परिस्थितियों के आधार पर भिन्न हो सकते हैं।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
| | |समूह संगठन | ||
| " | | "समूह का आयोजन कैसे किया जाता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
| | |परियोजना निर्देश | ||
| " | | "परियोजना समूह के ग्राहक के साथ परियोजना के नामित बिंदु।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
|- | |- | ||
| | |समूह भूमिकाएँ | ||
| "कौन कौन सी भूमिका निभाता है | | "एक समूह कौन कौन सी भूमिका निभाता है उनका विशिष्ट उत्तरदायित्व क्या होता हैं।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
| Line 128: | Line 122: | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
| colspan=2 | आवश्यकताओं को परिभाषित करें। | | colspan=2 | आवश्यकताओं को परिभाषित करें। | ||
| नियोजन चरण के | | "नियोजन चरण के प्रारम्भ में, समूह एक सूची या उपकरण में आवश्यकताओं का विश्लेषण करता है और उनका दस्तावेजीकरण करता है। आवश्यकताएँ चार व्यापक श्रेणियों व्यावसायिक आवश्यकताएँ, उपयोगकर्ता आवश्यकताएँ, परिचालन आवश्यकताएँ और प्रणाली आवश्यकताओ में होती हैं।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
| colspan=2 |सुविधाओं के लिए आवश्यकताएँ नियंत्रित करें। | | colspan=2 |सुविधाओं के लिए आवश्यकताएँ नियंत्रित करें। | ||
| "जैसा कि | | "जैसा कि समूह समाधान को डिजाइन करने और कार्यात्मक विनिर्देशों को बनाने के लिए आगे बढ़ती है, आवश्यकताओं और सुविधाओं के बीच यह पता लगाने की क्षमता बनाए रखना महत्वपूर्ण है। यह पता लगाने की क्षमता का एक निश्चित आधार पर होना आवश्यक नहीं है। पता लगाने की क्षमता बनाए रखना डिजाइन की शुद्धता की जांच करने और यह सत्यापित करने का एक तरीका है कि यह डिजाइन समाधान के लक्ष्यों और आवश्यकताओं को पूर्ण करता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
| colspan=2 | कार्यात्मक विशिष्टता को परिभाषित करें। | | colspan=2 | कार्यात्मक विशिष्टता को परिभाषित करें। | ||
| " | | "समूह कार्यात्मक विनिर्देश तैयार करता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
| Line 143: | Line 137: | ||
| rowspan=4 | योजना बनाएँ | | rowspan=4 | योजना बनाएँ | ||
|जोखिमों का अनुमान लगाएं | |जोखिमों का अनुमान लगाएं | ||
|एक समूह जोखिम अनुमान लगाए | |एक समूह जोखिम का अनुमान लगाए | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
|लागत का अनुमान लगाएं | |लागत का अनुमान लगाएं | ||
| Line 156: | Line 150: | ||
| rowspan=5 |डिज़ाइन बनाएँ | | rowspan=5 |डिज़ाइन बनाएँ | ||
|केस मॉडल का उपयोग करें | |केस मॉडल का उपयोग करें | ||
| "यह उपयोगकर्ता | | "यह उपयोगकर्ता (जिसे "व्यक्ति" भी कहा जाता है) के एक व्यवस्थित विश्लेषण से प्रारम्भ होता है, जो विभिन्न प्रकार के उपयोगकर्ताओं और उनके कार्य कार्यों का वर्णन करता है (संचालन कर्मचारी भी उपयोगकर्ता हैं।) इनमें से अधिकांश प्रायः परिकल्पना चरण के समय किया जाता है। ये उपयोग परिदृश्यों की एक श्रृंखला में विभाजित होते हैं जहां एक विशेष प्रकार का उपयोगकर्ता एक प्रकार की गतिविधि को पूर्ण करने का प्रयास कर रहा है, जैसे किसी होटल में फ्रंट डेस्क पंजीकरण या प्रणाली प्रशासक के लिए उपयोगकर्ता पासवर्ड का प्रबंध करना और अंत में, प्रत्येक उपयोग परिदृश्य को कार्यों के एक विशिष्ट अनुक्रम में विभाजित किया जाता है, जिसे उपयोग स्थिति के रूप में जाना जाता है जिसे उपयोगकर्ता उस गतिविधि को पूर्ण करने के लिए करता है। इस प्रक्रिया को "विवरण-बोर्डिंग या एमएसएफ प्रक्रिया मॉडल" कहा जाता है।<ref name="ReferenceA" /> | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
|वैचारिक डिजाइन बनाएँ | |वैचारिक डिजाइन बनाएँ | ||
| Line 170: | Line 164: | ||
|उत्पाद के लिए मूल संरचना का निर्माण। | |उत्पाद के लिए मूल संरचना का निर्माण। | ||
|} | |} | ||
तालिका 3: | तालिका 3: योजना गतिविधियां: योजना चरण में आवश्यकताओं से एक कार्यात्मक विनिर्देश बनाया जाता है। चयनित सुविधाओं को इस विनिर्देश में सम्मिलित किया गया है एक [[MoSCoW विधि|मास्को विधि]] प्रायः सुविधाओं के लिए उपयोग की जाती है ताकि उन्हें अधिक आसानी से प्राथमिकता दी जा सके। साथ ही, इस चरण में मूल डिजाइन और योजना बनाई जाती है। हालांकि डिजाइन इस चरण में स्थिर नहीं है क्योंकि इसमे विकास के चरण में परिवर्तन किए जा सकते हैं। | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 179: | Line 171: | ||
|- valign="TOP" | |- valign="TOP" | ||
| आवश्यकताओ की सूची | | आवश्यकताओ की सूची | ||
| सूची या उपकरण में आवश्यकताओं का दस्तावेज़ीकरण। | | "सूची या उपकरण में आवश्यकताओं का दस्तावेज़ीकरण।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
| | | | ||
जोखिम प्रबंधन की योजना | जोखिम प्रबंधन की योजना | ||
| परियोजना के संदर्भ में जोखिम प्रबंधन प्रक्रिया को इस पर दस्तावेज़ प्रयुक्त करने के लिए | | "परियोजना के संदर्भ में जोखिम प्रबंधन प्रक्रिया को इस पर दस्तावेज़ प्रयुक्त करने के लिए समूह की योजना है।" | ||
(एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB" /> | (एमएसएफ जोखिम प्रबंधन अनुशासन)<ref name="ReferenceB" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
| मूल परियोजना | | मूल परियोजना | ||
| सभी योजनाओं को | | "सभी योजनाओं को समकालिक किया जाता है और मूल परियोजना के रूप में एक साथ प्रस्तुत किया जाता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
|कार्य योजना | |कार्य योजना | ||
| | | "परिदेय के लिए एक योजना या योजना जो भूमिका से संबंधित है और समूह नियोजन सत्रों में भाग लेती है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
| Line 199: | Line 191: | ||
|- valign="TOP" | |- valign="TOP" | ||
|अनुसूची | |अनुसूची | ||
| | | परिदेय के लिए समय अनुमान और कार्यक्रम। | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
|मूल परियोजना अनुसूची | |मूल परियोजना अनुसूची | ||
| विभिन्न अनुसूचियों को तब | | "विभिन्न अनुसूचियों को तब समकालिक किया जाता है और एक मूल परियोजना अनुसूची में एकीकृत किया जाता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- valign="TOP" | |- valign="TOP" | ||
|कार्यात्मक विनिर्देश | |कार्यात्मक विनिर्देश | ||
| कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और | | कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और प्रयुक्त करना है। यह सभी सुविधाओं के लिए वास्तुकला और डिजाइन का भी वर्णन करता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|} | |} | ||
तालिका 4: | तालिका 4: योजना चरण में अवधारणाएँ | ||
===विकास चरण=== | ===विकास चरण=== | ||
| Line 221: | Line 213: | ||
|- | |- | ||
|सुविधाएँ विकसित करें | |सुविधाएँ विकसित करें | ||
| | | मुख्य घटकों का निर्माण (दस्तावेज़ीकरण और साथ ही कोड) एमएसएफ प्रक्रिया मॉडल में दैनिक निर्माण, बग निर्धारण और सुविधाओं का मूल्यांकन करने के बाद परीक्षण भी सम्मिलित होता है।<ref name="ReferenceA" /> | ||
|- | |- | ||
|दैनिक | |दैनिक योजना बनाएँ | ||
|एक कार्य दिवस के बाद एक निर्माण | |एक कार्य दिवस के बाद एक निर्माण कि योजना। | ||
|- | |- | ||
|कार्यक्षेत्र को अंतिम रूप दें | |कार्यक्षेत्र को अंतिम रूप दें | ||
| इस मील के पत्थर पर, सभी सुविधाएँ पूर्ण हैं और समाधान बाहरी परीक्षण और स्थिरीकरण के लिए तैयार है। | | इस मील के पत्थर पर, सभी सुविधाएँ पूर्ण हैं और समाधान बाहरी परीक्षण और स्थिरीकरण के लिए तैयार किए गए है। | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
|- | |- | ||
|आधारिक संरचना विकसित करें | |आधारिक संरचना विकसित करें | ||
| एमएसएफ प्रक्रिया मॉडल की आधारिक संरचना विकसित किया गया है।<ref name="ReferenceA" /> | | एमएसएफ प्रक्रिया मॉडल की आधारिक संरचना को विकसित किया गया है।<ref name="ReferenceA" /> | ||
|} | |} | ||
तालिका 5: विकासशील गतिविधियाँ | तालिका 5: विकासशील गतिविधियाँ | ||
विकासशील चरण में सबसे महत्वपूर्ण गतिविधि सुविधाओं का विकास है। इन सुविधाओं के कार्यान्वयन के | विकासशील चरण में सबसे महत्वपूर्ण गतिविधि सुविधाओं का विकास है। इन सुविधाओं के कार्यान्वयन के अतिरिक्त इस चरण में कार्यक्षेत्र को भी अंतिम रूप दिया गया है। विकास के समय उत्पाद में नई विशेषताएं जोड़ी जा सकती हैं, लेकिन एक बार कार्यक्षेत्र को अंतिम रूप देने के बाद विशेषताएं स्थिर हो जाती हैं परीक्षण और स्थिरीकरण के लिए तैयार हो जाती हैं। इस चरण में आधारभूत संरचना भी विकसित की जाती है जिसका अर्थ है कि नेटवर्क संरचनाओं की पहचान की जाती है और उदाहरण के लिए डेटाबेस जैसे सर्वर परिभाषित किए जाते हैं। | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 244: | Line 234: | ||
!परिभाषा (स्रोत) | !परिभाषा (स्रोत) | ||
|- | |- | ||
| स्थापना | | स्थापना आलेख और परियोजना के लिए कॉन्फ़िगरेशन सेटिंग्स | ||
|उत्पाद को स्थापित/ | |उत्पाद को स्थापित/सक्रिय करने के लिए आवश्यक आलेख और सेटिंग्स का संग्रह। | ||
|- | |- | ||
| स्थापना | | स्थापना आलेख | ||
|उत्पाद को स्थापित करने के लिए आवश्यक | |उत्पाद को स्थापित करने के लिए आवश्यक आलेख। | ||
|- | |- | ||
| कॉन्फ़िगरेशन सेटिंग्स | | कॉन्फ़िगरेशन सेटिंग्स | ||
| Line 254: | Line 244: | ||
|- | |- | ||
| प्रदर्शन समर्थन तत्व | | प्रदर्शन समर्थन तत्व | ||
|उत्पाद के प्रदर्शन का समर्थन करने वाले तत्व | |उत्पाद के प्रदर्शन का समर्थन करने वाले तत्व अतिरिक्त डेटाबेस, सर्वर आदि। | ||
|- | |- | ||
| परीक्षण विनिर्देश और परीक्षण स्थिति | | परीक्षण विनिर्देश और परीक्षण स्थिति | ||
|उत्पाद को | |उत्पाद को स्वीकृत करने के लिए उपयोग किए जाने वाले परीक्षणों और परीक्षण स्थितियों की विशिष्टता। | ||
|- | |- | ||
|कार्यात्मक विनिर्देश | |कार्यात्मक विनिर्देश | ||
| कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और | | कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और प्रयुक्त करना है। यह सभी सुविधाओं के लिए वास्तुकला और डिजाइन का भी वर्णन करता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
|- | |- | ||
| Line 270: | Line 260: | ||
|- | |- | ||
| निष्पादन | | निष्पादन | ||
|निष्पादन योग्य स्रोत कोड द्वारा बनाया | |निष्पादन योग्य स्रोत कोड द्वारा बनाया गया है। | ||
|} | |} | ||
तालिका 5: विकासशील चरण में अवधारणाएँ | तालिका 5: विकासशील चरण में अवधारणाएँ | ||
=== स्थिरीकरण चरण === | === स्थिरीकरण चरण === | ||
चित्रा 5: स्थिरीकरण चरण प्रक्रिया/डेटा मॉडल | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 282: | Line 273: | ||
|- | |- | ||
|परीक्षण | |परीक्षण | ||
| इस चरण के | | इस चरण के समय परीक्षण यथार्थवादी पर्यावरणीय परिस्थितियों मे एमएसएफ प्रक्रिया मॉडल के अंतर्गत उपयोग और संचालन पर महत्व देता है।<ref name="ReferenceA" /> | ||
|- | |- | ||
| बग्स संशोधन | | बग्स संशोधन | ||
| | | समूह बग्स को हल करने और प्रयाश करने (प्राथमिकता देने) पर ध्यान केंद्रित करती है और एमएसएफ प्रक्रिया मॉडल को प्रकाशित करने के लिए हल तैयार करती है।<ref name="ReferenceA" /> | ||
|- | |- | ||
| पायलट प्रसारण | | पायलट प्रसारण | ||
| एक | | एक गठन को एक प्रकाशित समूह के लिए पर्याप्त रूप से स्थिर माना जाता है और पायलट समूह एमएसएफ प्रक्रिया मॉडल में सक्रिय किया जाता है।<ref name="ReferenceA" /> | ||
|- | |- | ||
| समीक्षा | | समीक्षा | ||
| एक बार समीक्षा और अनुमोदन | | एक बार समीक्षा और अनुमोदन को समाधान लाइव उत्पादन परिवेश एमएसएफ प्रक्रिया मॉडल में पूर्ण परिनियोजन के लिए किया जाता है।<ref name="ReferenceA" /> | ||
|} | |} | ||
तालिका 6: स्थिरीकरण गतिविधियाँ | तालिका 6: स्थिरीकरण गतिविधियाँ | ||
मुख्य गतिविधियाँ | मुख्य गतिविधियाँ बग परीक्षण और परिवर्तन हैं। एक बार एक पायलट संस्करण को पायलट के लिए पर्याप्त स्थिर माना जाता है, एक पायलट संस्करण बनाया और सक्रिय किया जाता है। | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 334: | Line 325: | ||
=== परिनियोजन चरण === | === परिनियोजन चरण === | ||
चित्र 6: परिनियोजन चरण प्रक्रिया/डेटा मॉडल | चित्र 6: परिनियोजन चरण प्रक्रिया/डेटा मॉडल | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 340: | Line 332: | ||
!परिभाषा (स्रोत) | !परिभाषा (स्रोत) | ||
|- | |- | ||
| | |मुख्य घटक परियोजना | ||
|उत्पाद | |"उत्पाद के लिए आवश्यक सभी परियोजना घटक जैसे डेटाबेस सर्वर, मेल सर्वर आदि।" | ||
|- | |- | ||
|साइट | |साइट हल परियोजना | ||
| दर्जी-निर्मित प्रणालियों के लिए उत्पाद का | | दर्जी-निर्मित प्रणालियों के लिए उत्पाद का परिनियोजना को सॉफ्टवेयर उत्पादों के लिए छोड़ा जा सकता है। | ||
|- | |- | ||
| | |स्थिर परियोजना | ||
|टैकिंग, | |टैकिंग, संरक्षण और परियोजना घटकों में सुधार। | ||
|- | |- | ||
|परियोजना को संचालन और समर्थन में स्थानांतरित करें | |परियोजना को संचालन और समर्थन में स्थानांतरित करें | ||
|संचालन और सहायता | |संचालन और सहायता समूह को सभी दस्तावेज़ और कोड स्थानांतरित करना। | ||
|- | |- | ||
|ग्राहक से अंतिम स्वीकृति प्राप्त करें | |ग्राहक से अंतिम स्वीकृति प्राप्त करें | ||
| समाधान के उत्पादन में | | समाधान के उत्पादन में और परियोजना को स्थगित करने की घोषणा करने से पहले ग्राहक को इस विषय पर सहमत होना चाहिए कि समूह ने अपने उद्देश्यों को पूर्ण कर लिया है। इसके लिए एक स्थिर समाधान, साथ ही स्पष्ट रूप से बताए गए सफलता मानदंड की आवश्यकता है। समाधान को स्थिर माने जाने के लिए, उपयुक्त संचालन और समर्थन प्रणाली का होना आवश्यक है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
|- | |- | ||
|परियोजना की समीक्षा करें | |परियोजना की समीक्षा करें | ||
|परियोजना की अंतिम समीक्षा। | |परियोजना की अंतिम समीक्षा। | ||
|} | |} | ||
तालिका 8: | तालिका 8: परियोजना गतिविधियां: परिनियोजन चरण में मुख्य गतिविधि उत्पाद को सक्रिय करने के लिए आवश्यक आधारिक संरचना की स्थापना सर्वर आदि है। साथ ही, दस्तावेजों को अंतिम रूप दिया जाता है संचालन और सहायता विभाग को हस्तांतरित किया जाता है एक ज्ञानकोष का आधार बनाया जाता है और ग्राहक (यदि प्रयुक्त हो) और परियोजना समूह द्वारा उत्पाद और परियोजना की समीक्षा की जाती है। | ||
परिनियोजन चरण में मुख्य गतिविधि उत्पाद को | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 396: | Line 386: | ||
|- | |- | ||
|संचालन और समर्थन सूचना प्रणाली | |संचालन और समर्थन सूचना प्रणाली | ||
|उत्पाद से जुड़ी संचालन और समर्थन | |उत्पाद से जुड़ी संचालन और समर्थन समूहों द्वारा उपयोग की जाने वाली प्रणालियाँ। | ||
|- | |- | ||
|ग्राहक/उपयोगकर्ता प्रमाणित डेटा | |ग्राहक/उपयोगकर्ता प्रमाणित डेटा | ||
| Line 405: | Line 395: | ||
|- | |- | ||
|परियोजना स्थानांतरण विवरण। | |परियोजना स्थानांतरण विवरण। | ||
|उत्पाद, परियोजना और संचालन और समर्थन के हस्तांतरण पर अंतिम | |उत्पाद, परियोजना और संचालन और समर्थन के हस्तांतरण पर अंतिम विवरण। | ||
|} | |} | ||
तालिका 9: | तालिका 9: परिनियोजना चरण की अवधारणाएँ | ||
=== समग्र डेटा मॉडल === | === समग्र डेटा मॉडल === | ||
चित्र 7: समग्र डेटा मॉडल | चित्र 7: समग्र डेटा मॉडल: यह डेटा मॉडल एक पूर्ण परियोजना संदर्भ में सभी अवधारणाओं को बहुलता और संबंधों के साथ प्रदर्शित करता है। | ||
यह डेटा मॉडल एक पूर्ण परियोजना संदर्भ में सभी अवधारणाओं को | |||
[[Category:Created On 17/02/2023]] | |||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with broken file links]] | |||
[[Category:सॉफ़्टवेयर वास्तुशिल्प]] | |||
== इंटरनेट-गति विकास के साथ प्रयोग के लिए उपकरण == | == इंटरनेट-गति विकास के साथ प्रयोग के लिए उपकरण == | ||
* आरेखण उपकरण (उदाहरण: माइक्रोसॉफ्ट विज़ियो, रेशनलरोज, डीआईए) आरेख बनाने के लिए। | * आरेखण उपकरण (उदाहरण: माइक्रोसॉफ्ट विज़ियो, रेशनलरोज, डीआईए) आरेख बनाने के लिए। | ||
* वर्ड प्रोसेसर (उदाहरण: माइक्रोसॉफ्ट वर्ड, OpenOffice.org राइटर, [[AbiWord|एबीवर्ड]], [[Calligra Words|कैलीग्रावर्ड]]) विजन स्टेटमेंट या | * वर्ड प्रोसेसर (उदाहरण: माइक्रोसॉफ्ट वर्ड, OpenOffice.org राइटर, [[AbiWord|एबीवर्ड]], [[Calligra Words|कैलीग्रावर्ड]]) विजन स्टेटमेंट या कार्यक्षेत्र-दस्तावेज़ जैसे टेक्स्ट दस्तावेज़ बनाने के लिए। | ||
* स्प्रेडशीट (उदाहरण: माइक्रोसॉफ्ट एक्सेल, OpenOffice.org कैल्क, [[Gnumeric|ग्नुमेरिक]], [[Calligra Sheets|कैलीग्राशीट]]) प्राथमिकता वाली जोखिम सूची बनाने और लागत गणना करने के लिए। | * स्प्रेडशीट (उदाहरण: माइक्रोसॉफ्ट एक्सेल, OpenOffice.org कैल्क, [[Gnumeric|ग्नुमेरिक]], [[Calligra Sheets|कैलीग्राशीट]]) प्राथमिकता वाली जोखिम सूची बनाने और लागत गणना करने के लिए। | ||
*परियोजना उपकरण (उदाहरण: माइक्रोसॉफ्ट प्रोजेक्ट, [[ओपनप्रोज]], गनोम प्लानर, [[कैलीग्रा योजना]]) परियोजना गतिविधियों की योजना बनाने के लिए। | *परियोजना उपकरण (उदाहरण: माइक्रोसॉफ्ट प्रोजेक्ट, [[ओपनप्रोज]], गनोम प्लानर, [[कैलीग्रा योजना]]) परियोजना गतिविधियों की योजना बनाने के लिए। | ||
| Line 437: | Line 431: | ||
*Michael A. Cusumano, David B. Yoffie 1999 Software Development on Internet Time 32 IEEE | *Michael A. Cusumano, David B. Yoffie 1999 Software Development on Internet Time 32 IEEE | ||
*Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internet Software Engineering: A Different Class of Processes Annals of Software Engineering 14 169–195 | *Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internet Software Engineering: A Different Class of Processes Annals of Software Engineering 14 169–195 | ||
[[Category:Created On 17/02/2023]] | [[Category:Created On 17/02/2023]] | ||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with broken file links]] | |||
[[Category:सॉफ़्टवेयर वास्तुशिल्प]] | |||
Latest revision as of 16:55, 28 August 2023
इंटरनेट-गति विकास एक ऐसी सॉफ्टवेयर विकास पद्धति है जिसमें उच्च गति वाले उत्पाद को विकसित करने के उद्देश्य से दैनिक निर्माण के साथ एक संयुक्त सर्पिल मॉडल/वाटरफॉल मॉडल का उपयोग किया जाता है।
इसे 1990 के दशक के अंत में विकसित किया गया था क्योंकि सॉफ्टवेयर का विकास तीव्रता से परिवर्तित हो रहा था। कंपनियों को परियोजना के लिए निर्धारित समय के भीतर पूर्ण आवश्यकताओं के साथ उत्पादों को वितरित करने में समस्या हो रही थी और इस प्रकार वे अधिक सॉफ्टवेयर विकास पद्धति में परिवर्तित हो रहे थे। इब्राहीमसन के पेपर में विकासवादी मानचित्र में इंटरनेट-गति पद्धति को कैसे विकसित किया गया था इसके विषय में अधिक विवरण देखा जा सकता है।[1]
इंटरनेट-गति विकास के पीछे मुख्य विचार
सॉफ्टवेयर इंजीनियरिंग में प्रायः सबसे बड़ी समस्याओं में से एक यह है कि आवश्यकताओं में तेजी से परिवर्तन होता है और इस स्थिति के अनुकूल होने के लिए इंटरनेट-गति विकास पद्धति बनाई गई थी। यह विचार सॉफ्टवेयर इंजीनियरिंग मॉडल में दो मुख्य मानकों को जोड़ने का है अर्थात् सर्पिल मॉडल और वॉटरफॉल मॉडल को एक नए मॉडल में और इस नए मॉडल पर एक नई सॉफ्टवेयर इंजीनियरिंग पद्धति को आधार बनाना है। वॉटरफॉल मॉडल की मुख्य कमी यह थी कि जब आवश्यकताओं में परिवर्तन मे होता है तो यह बहुत कठोर और बहुत नम्य नहीं होता है जबकि सर्पिल मॉडल की कमी यह थी कि यह बहुत संरचनात्मक नहीं था। इंटरनेट-गति के विकास के पीछे विचार यह है कि इन मॉडलों के संयोजन का परिणाम एक ऐसी पद्धति के रूप में होगा जिसमें ये कमी नहीं हैं और उन स्थितियों में उपयोग करने के लिए एक अपेक्षाकृत अच्छा तरीका है जहां आवश्यकताएं तीव्रता से परिवर्तित हो सकती हैं लेकिन परियोजना को संरचनात्मक तरीके से क्रियान्वित किया जाना आवश्यक होता है।
इंटरनेट-गति विकास पद्धति का लक्ष्य
इंटरनेट-गति विकास पद्धति का लक्ष्य सॉफ्टवेयर विकासक को एक संरचनात्मक तरीके से एक परियोजना को पूर्ण करने की स्वीकृति देना है लेकिन ग्राहक की आवश्यकताओ को पूर्ण करने में सक्षम होना है। इसका उद्देश्य विकास के माध्यम से कम समय में एक सॉफ्टवेयर उत्पाद प्रदान करना है। यह पद्धति पूरी तरह से कार्यान्वित प्रणाली प्रदान करने का एक साधन प्रदान करती है और मील के पत्थर के उपयोग के माध्यम से किसी परियोजना में प्रगति निर्धारित करने के लिए भी आवश्यक हैं। इस पद्धति के मुख्य संस्करणों में से एक माइक्रोसॉफ्ट द्वारा बनाया गया है इसीलिए इसे माइक्रोसॉफ्ट फ्रेमवर्क भी कहा जाता है।
इंटरनेट-गति विकास पद्धति के पीछे की अवधारणा
पहली अवधारणा जो इंटरनेट की गति के विकास के लिए बहुत महत्वपूर्ण है एक कार्यक्षेत्र और परियोजना प्रबंधन का निर्माण है। इसका अर्थ यह है कि परियोजना के प्रारम्भ में सिस्टम की एक वैश्विक परिभाषा बनाई जाती है जो यह प्रदर्शित करती है कि सिस्टम का लक्ष्य क्या है और इसकी स्थिति क्या है और क्या नहीं है। यह मौलिक प्रकारों में से एक है क्योंकि यह विकासक को कुछ दिशानिर्देश देता है कि कार्यक्षेत्र को एक विजन सारणी में संक्षिप्त किया जा सकता है। इस पद्धति के भीतर एक और बहुत महत्वपूर्ण अवधारणा कार्यक्षेत्र प्रबंधन है। कार्यक्षेत्र विकास को स्थगित करने के लिए कार्यक्षेत्र को परियोजना में प्रबंधित करने की आवश्यकता होती है जिसके परिणामस्वरूप रुकावट उत्पन्न होती है। यदि कार्यक्षेत्र को तीव्रता से निर्धारित किया जाएगा और कार्यक्षेत्र में परिवर्तन (जैसे अतिरिक्त सुविधाओं को जोड़ना जो पहले परियोजना के कार्यक्षेत्र से बाहर माने जाते थे) का मूल्यांकन किया जाएगा या तो स्वीकृत या अस्वीकृत कर दिया जाएगा। कार्यक्षेत्र में परिवर्तन किए जा सकते हैं लेकिन यह सदैव सुविधाओं, संसाधनों और समय के बीच व्यापार विणपन से प्रभावित होगा। लेकिन इंटरनेट-गति विकास पद्धति पारंपरिक तरीकों से बहुत अलग है और इसलिए सॉफ्टवेयर विकास पद्धति सिद्धांतों का उपयोग करती है। यह आवश्यकताओं के अनुकूलन पर ध्यान केंद्रित करता है और जैसे कि एजाइल सॉफ्टवेयर विकास के मूल सिद्धांतों पर आधारित है।
इंटरनेट-गति विकास भी एक निश्चित माइक्रोसॉफ्ट फ्रेमवर्क संरचना का उपयोग करने पर ध्यान केंद्रित करता है जिससे उत्पाद बनाया जाता है और विकास की गति को विस्तृत करने के लिए उपकरणों पर अत्यधिक निर्भर करता है। इंटरनेट की गति विकास की एक और मूलभूत अवधारणा यह है कि यह छोटे समूह का उपयोग करने पर भी ध्यान केंद्रित करता है। विचार यह है कि सभी परियोजनाओं को छोटी-छोटी गतिविधियों में विभाजित किया जा सकता है जिन्हें प्रायः समानांतर में किया जा सकता है। छोटी समूहें प्रायः अपने कार्य पर अधिक ध्यान केंद्रित कर सकती हैं जिससे परियोजना के भीतर उत्तरदायित्व निर्धारित करना और प्रगति का संरक्षण करना आसान होता है।
इंटरनेट-गति विकास की इस प्रविष्टि में चर्चा की गई अंतिम अवधारणा समानांतर विकास की अवधारणा है। इस अवधारणा का मूल रूप से तात्पर्य यह है कि सभी सॉफ्टवेयर विकास जितनी बार संभव हो समानांतर में किया जाता है। यह बहुत तीव्रता से विकास की स्वीकृति देगा और यह छोटी समूहों को जितना संभव हो सके अपनी सुविधा पर ध्यान केंद्रित करने की स्वीकृति देगा, जिसका गुणवत्ता पर अच्छा परिणाम होता है। यह सुनिश्चित करने के लिए कि अंतिम प्रणाली बनाने के लिए छोटी समूहें एक साथ कार्य करती हैं, हालांकि उनके विकास को प्रायः समकालिक करने की आवश्यकता होती है। यह दैनिक निर्माण का उपयोग करके किया जा सकता है जिसका अर्थ है कि सभी विकासक दिन के अंत में अपने कोड का परीक्षण करते हैं जिसके बाद इसको निर्मित किया जाता है जिसका मूल्यांकन और प्रगति की संरक्षण के लिए परीक्षण किया जा सकता है। निर्माण में एक विशेषता के पूर्ण होने के बाद इसे परीक्षण और परिष्कृत करने की आवश्यकता होती है जिसको कभी-कभी समकालीन और स्थिर प्रक्रिया कहा जाता है। विकसित सुविधाओं को निर्माण और परीक्षण के साथ समकालिक किया गया है। इन परीक्षणों के बाद किसी भी बग को संशोधित कर दिया जाएगा जो स्थिरीकरण भाग है। और विशेषता को अपेक्षाकृत कार्य करने के लिए परिष्कृत किया जा सकता है।
इंटरनेट-गति का विकास विद्युत सिद्धांतों पर आधारित है और इस प्रकार इसमें अधिकतम प्रोग्रामिंग, तर्कसंगत एकीकृत प्रक्रिया, गतिशील प्रणाली विकास पद्धति और विशिष्ट संचालित विकास के साथ अत्यधिक समानताएं हैं। इंटरनेट- गति का विकास हालांकि इन तरीकों से अलग है क्योंकि इसमें एक अधिक व्यापक जोखिम प्रबंधन योजना भी सम्मिलित होती है और इस परियोजना के एक बहुत ही महत्वपूर्ण उद्देश्य के रूप में गुणवत्ता है।[2] इंटरनेट-गति विकास का विकास चरण भी मुक्त स्रोत सॉफ्टवेयर विकास मॉडल के साथ कुछ समानताएं प्रदर्शित करता है क्योंकि इंटरनेट के माध्यम से संचार, कोड और दस्तावेज़ीकरण को संग्रहीत करने के लिए भंडारण के उपयोग के कारण विश्व के कई विकासक इस विकास प्रक्रिया का एक भाग हो सकते हैं। .
इंटरनेट-गति विकास के चरण
इस पद्धति के पीछे का मॉडल इस प्रकार प्रदर्शित होता है जो मॉडल विधि के पांच संरचनात्मक चरणों को दर्शाता है। इस प्रविष्टि के निम्नलिखित खंडों में इन चरणों की व्याख्या की जा सकती है जैसे परिकल्पना करना, योजना बनाना, विकास करना, स्थिर करना और परिनियोजित करना आदि मुख्य चरण है। इस चक्र के पूर्ण होने के बाद प्रणाली का एक संस्करण तैयार होता है और एक नया चक्र नया संस्करण बनाने के लिए प्रारम्भ होता है। चरणों को निम्नलिखित खंडों में समझाया गया है और एक मेटा-मॉडलिंग तकनीक के माध्यम से प्रदर्शित किया गया है। एक परियोजना के संदर्भ में बहुलता और अवधारणाओं के विषय में अधिक जानकारी बाद में समग्र डेटा मॉडल में देखी जा सकती है।
परिकल्पना चरण
परिकल्पना चरण को निम्नानुसार प्रदर्शित किया जा सकता है:
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| आवश्यकताओं का विश्लेषण करें। | परिकल्पना के चरण के समय, व्यावसायिक आवश्यकताओं की पहचान और विश्लेषण किया जाना चाहिए।
“नियोजन चरण के समय इन्हें और अधिक जटिलता से परिष्कृत किया जाता है।" (एमएसएफ प्रक्रिया मॉडल)[3] |
| लक्ष्यों और अवरोधो को परिभाषित करें | "परियोजना के लक्ष्यों और अवरोधो के विषय में एक उच्च-स्तरीय दृष्टिकोण बनाकर परिकल्पना करना।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| फॉर्म समूह | मुख्य समूह का गठन। |
| विजन/कार्यक्षेत्र बनाएं | "एक विजन/कार्यक्षेत्र के दस्तावेज़ और वितरण।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| जोखिम निर्धारण करे। | "परिकल्पना चरण के समय, समूह एक जोखिम दस्तावेज़ तैयार करता है और शीर्ष जोखिम प्रस्तुत करता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
तालिका 1: गतिविधियों की परिकल्पना करना
परिकल्पना चरण में की गई संरचनात्मक गतिविधियाँ आवश्यकताओं का विश्लेषण करती हैं और परियोजना के लिए एक समूह का गठन कर करती हैं जो जोखिमों का निर्धारण कर सकती हैं और परियोजना का कार्यक्षेत्र निर्धारित कर सकती हैं। परियोजना की आवश्यकताओं और लक्ष्यों से एक विजन/कार्यक्षेत्र दस्तावेज़ बनाया जाता है। यह दस्तावेज़ प्रदर्शित करता है कि जब उत्पाद वितरित किया जाता है तो उसे क्या होना चाहिए। इसमें उत्पाद की बहुत विस्तृत कार्यप्रणाली सम्मिलित नहीं होती है।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| विजन/कार्यक्षेत्र दस्तावेज़ | "विजन और कार्यक्षेत्र को परिभाषित करने वाला दस्तावेज़।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| विजन (दृष्टि) | "विजन हल क्या हो सकता है इसका एक असीम दृष्टिकोण है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| विस्तार | "कार्यक्षेत्र पहचानता है कि विजन के भाग (ओं) को परियोजना को अवरोधों के भीतर पूर्ण किया जा सकता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| जोखिम मूल्यांकन दस्तावेज़ | "जोखिम मूल्यांकन के लिए मानकीकृत दस्तावेज़।"
(एमएसएफ जोखिम प्रबंधन अनुशासन)[4] |
| प्राथमिकता जोखिम सूची | "परियोजना की स्थिति, संदर्भ, मूल कारण और प्राथमिकता के लिए उपयोग किए जाने वाले मापन विज्ञान (संभावना, प्रभाव, जोखिम) सहित विस्तृत जोखिम की जानकारी प्रायः जोखिम विवरण फॉर्म में प्रत्येक जोखिम के लिए प्रस्तुत की जाती है।"
(एमएसएफ जोखिम प्रबंधन अनुशासन)[4] |
| जोखिम योजना | "कार्य योजनाओं में प्राथमिकता वाली जोखिम सूची का अनुप्रयोग।"
(एमएसएफ जोखिम प्रबंधन अनुशासन)[4] |
| परियोजना संरचना दस्तावेज़ | "परियोजना संरचना दस्तावेज़ में यह जानकारी सम्मिलित है कि समूह कैसे संगठित होता है और कौन कौन सी भूमिकाएँ निभाता है और उनका विशिष्ट उत्तरदायित्व क्या होता हैं। परियोजना संरचना दस्तावेज़ ग्राहक के प्रति उत्तरदायित्व की श्रृंखला और संपर्क के नामित बिंदुओं को भी स्पष्ट करता है जो परियोजना समूह ग्राहक के साथ संरक्षित होते है। और ये परियोजना की परिस्थितियों के आधार पर भिन्न हो सकते हैं।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| समूह संगठन | "समूह का आयोजन कैसे किया जाता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| परियोजना निर्देश | "परियोजना समूह के ग्राहक के साथ परियोजना के नामित बिंदु।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| समूह भूमिकाएँ | "एक समूह कौन कौन सी भूमिका निभाता है उनका विशिष्ट उत्तरदायित्व क्या होता हैं।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
तालिका 2: परिकल्पना चरण में अवधारणाएँ
योजना चरण
चित्र 3: योजना चरण प्रक्रिया/डेटा मॉडल
| कार्यकलाप | परिभाषा (स्रोत) | |
|---|---|---|
| आवश्यकताओं को परिभाषित करें। | "नियोजन चरण के प्रारम्भ में, समूह एक सूची या उपकरण में आवश्यकताओं का विश्लेषण करता है और उनका दस्तावेजीकरण करता है। आवश्यकताएँ चार व्यापक श्रेणियों व्यावसायिक आवश्यकताएँ, उपयोगकर्ता आवश्यकताएँ, परिचालन आवश्यकताएँ और प्रणाली आवश्यकताओ में होती हैं।"
(एमएसएफ प्रक्रिया मॉडल)[3] | |
| सुविधाओं के लिए आवश्यकताएँ नियंत्रित करें। | "जैसा कि समूह समाधान को डिजाइन करने और कार्यात्मक विनिर्देशों को बनाने के लिए आगे बढ़ती है, आवश्यकताओं और सुविधाओं के बीच यह पता लगाने की क्षमता बनाए रखना महत्वपूर्ण है। यह पता लगाने की क्षमता का एक निश्चित आधार पर होना आवश्यक नहीं है। पता लगाने की क्षमता बनाए रखना डिजाइन की शुद्धता की जांच करने और यह सत्यापित करने का एक तरीका है कि यह डिजाइन समाधान के लक्ष्यों और आवश्यकताओं को पूर्ण करता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] | |
| कार्यात्मक विशिष्टता को परिभाषित करें। | "समूह कार्यात्मक विनिर्देश तैयार करता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] | |
| योजना बनाएँ | जोखिमों का अनुमान लगाएं | एक समूह जोखिम का अनुमान लगाए |
| लागत का अनुमान लगाएं | समूह लागत का अनुमान लगाए | |
| कार्य योजना बनाएं | समूह कार्य योजना बनाएं | |
| अनुसूचियां बनाएं | समूह अनुसूचियां बनाएं | |
| डिज़ाइन बनाएँ | केस मॉडल का उपयोग करें | "यह उपयोगकर्ता (जिसे "व्यक्ति" भी कहा जाता है) के एक व्यवस्थित विश्लेषण से प्रारम्भ होता है, जो विभिन्न प्रकार के उपयोगकर्ताओं और उनके कार्य कार्यों का वर्णन करता है (संचालन कर्मचारी भी उपयोगकर्ता हैं।) इनमें से अधिकांश प्रायः परिकल्पना चरण के समय किया जाता है। ये उपयोग परिदृश्यों की एक श्रृंखला में विभाजित होते हैं जहां एक विशेष प्रकार का उपयोगकर्ता एक प्रकार की गतिविधि को पूर्ण करने का प्रयास कर रहा है, जैसे किसी होटल में फ्रंट डेस्क पंजीकरण या प्रणाली प्रशासक के लिए उपयोगकर्ता पासवर्ड का प्रबंध करना और अंत में, प्रत्येक उपयोग परिदृश्य को कार्यों के एक विशिष्ट अनुक्रम में विभाजित किया जाता है, जिसे उपयोग स्थिति के रूप में जाना जाता है जिसे उपयोगकर्ता उस गतिविधि को पूर्ण करने के लिए करता है। इस प्रक्रिया को "विवरण-बोर्डिंग या एमएसएफ प्रक्रिया मॉडल" कहा जाता है।[3] |
| वैचारिक डिजाइन बनाएँ | एक वैचारिक डिजाइन का निर्माण। | |
| तार्किक डिजाइन बनाएँ | एक तार्किक डिजाइन का निर्माण। | |
| भौतिक डिजाइन बनाएं | एक भौतिक डिजाइन का निर्माण। | |
| मूल संरचना बनाएँ | उत्पाद के लिए मूल संरचना का निर्माण। | |
तालिका 3: योजना गतिविधियां: योजना चरण में आवश्यकताओं से एक कार्यात्मक विनिर्देश बनाया जाता है। चयनित सुविधाओं को इस विनिर्देश में सम्मिलित किया गया है एक मास्को विधि प्रायः सुविधाओं के लिए उपयोग की जाती है ताकि उन्हें अधिक आसानी से प्राथमिकता दी जा सके। साथ ही, इस चरण में मूल डिजाइन और योजना बनाई जाती है। हालांकि डिजाइन इस चरण में स्थिर नहीं है क्योंकि इसमे विकास के चरण में परिवर्तन किए जा सकते हैं।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| आवश्यकताओ की सूची | "सूची या उपकरण में आवश्यकताओं का दस्तावेज़ीकरण।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
|
जोखिम प्रबंधन की योजना |
"परियोजना के संदर्भ में जोखिम प्रबंधन प्रक्रिया को इस पर दस्तावेज़ प्रयुक्त करने के लिए समूह की योजना है।"
(एमएसएफ जोखिम प्रबंधन अनुशासन)[4] |
| मूल परियोजना | "सभी योजनाओं को समकालिक किया जाता है और मूल परियोजना के रूप में एक साथ प्रस्तुत किया जाता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| कार्य योजना | "परिदेय के लिए एक योजना या योजना जो भूमिका से संबंधित है और समूह नियोजन सत्रों में भाग लेती है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| लागत का अनुमान | परियोजना की लागत का अनुमान। |
| अनुसूची | परिदेय के लिए समय अनुमान और कार्यक्रम।
(एमएसएफ प्रक्रिया मॉडल)[3] |
| मूल परियोजना अनुसूची | "विभिन्न अनुसूचियों को तब समकालिक किया जाता है और एक मूल परियोजना अनुसूची में एकीकृत किया जाता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| कार्यात्मक विनिर्देश | कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और प्रयुक्त करना है। यह सभी सुविधाओं के लिए वास्तुकला और डिजाइन का भी वर्णन करता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
तालिका 4: योजना चरण में अवधारणाएँ
विकास चरण
चित्र 4: चरण प्रक्रिया/डेटा मॉडल का विकास करना
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| सुविधाएँ विकसित करें | मुख्य घटकों का निर्माण (दस्तावेज़ीकरण और साथ ही कोड) एमएसएफ प्रक्रिया मॉडल में दैनिक निर्माण, बग निर्धारण और सुविधाओं का मूल्यांकन करने के बाद परीक्षण भी सम्मिलित होता है।[3] |
| दैनिक योजना बनाएँ | एक कार्य दिवस के बाद एक निर्माण कि योजना। |
| कार्यक्षेत्र को अंतिम रूप दें | इस मील के पत्थर पर, सभी सुविधाएँ पूर्ण हैं और समाधान बाहरी परीक्षण और स्थिरीकरण के लिए तैयार किए गए है।
(एमएसएफ प्रक्रिया मॉडल)[3] |
| आधारिक संरचना विकसित करें | एमएसएफ प्रक्रिया मॉडल की आधारिक संरचना को विकसित किया गया है।[3] |
तालिका 5: विकासशील गतिविधियाँ
विकासशील चरण में सबसे महत्वपूर्ण गतिविधि सुविधाओं का विकास है। इन सुविधाओं के कार्यान्वयन के अतिरिक्त इस चरण में कार्यक्षेत्र को भी अंतिम रूप दिया गया है। विकास के समय उत्पाद में नई विशेषताएं जोड़ी जा सकती हैं, लेकिन एक बार कार्यक्षेत्र को अंतिम रूप देने के बाद विशेषताएं स्थिर हो जाती हैं परीक्षण और स्थिरीकरण के लिए तैयार हो जाती हैं। इस चरण में आधारभूत संरचना भी विकसित की जाती है जिसका अर्थ है कि नेटवर्क संरचनाओं की पहचान की जाती है और उदाहरण के लिए डेटाबेस जैसे सर्वर परिभाषित किए जाते हैं।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| स्थापना आलेख और परियोजना के लिए कॉन्फ़िगरेशन सेटिंग्स | उत्पाद को स्थापित/सक्रिय करने के लिए आवश्यक आलेख और सेटिंग्स का संग्रह। |
| स्थापना आलेख | उत्पाद को स्थापित करने के लिए आवश्यक आलेख। |
| कॉन्फ़िगरेशन सेटिंग्स | उत्पाद के विन्यास गुण। |
| प्रदर्शन समर्थन तत्व | उत्पाद के प्रदर्शन का समर्थन करने वाले तत्व अतिरिक्त डेटाबेस, सर्वर आदि। |
| परीक्षण विनिर्देश और परीक्षण स्थिति | उत्पाद को स्वीकृत करने के लिए उपयोग किए जाने वाले परीक्षणों और परीक्षण स्थितियों की विशिष्टता। |
| कार्यात्मक विनिर्देश | कार्यात्मक विनिर्देश विस्तार से वर्णन करता है कि प्रत्येक सुविधा को कैसे दिखना और प्रयुक्त करना है। यह सभी सुविधाओं के लिए वास्तुकला और डिजाइन का भी वर्णन करता है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| स्रोत कोड और निष्पादन योग्य | स्रोत कोड/निष्पादन योग्य संयोजन। |
| स्रोत कोड | उत्पाद का स्रोत कोड। |
| निष्पादन | निष्पादन योग्य स्रोत कोड द्वारा बनाया गया है। |
तालिका 5: विकासशील चरण में अवधारणाएँ
स्थिरीकरण चरण
चित्रा 5: स्थिरीकरण चरण प्रक्रिया/डेटा मॉडल
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| परीक्षण | इस चरण के समय परीक्षण यथार्थवादी पर्यावरणीय परिस्थितियों मे एमएसएफ प्रक्रिया मॉडल के अंतर्गत उपयोग और संचालन पर महत्व देता है।[3] |
| बग्स संशोधन | समूह बग्स को हल करने और प्रयाश करने (प्राथमिकता देने) पर ध्यान केंद्रित करती है और एमएसएफ प्रक्रिया मॉडल को प्रकाशित करने के लिए हल तैयार करती है।[3] |
| पायलट प्रसारण | एक गठन को एक प्रकाशित समूह के लिए पर्याप्त रूप से स्थिर माना जाता है और पायलट समूह एमएसएफ प्रक्रिया मॉडल में सक्रिय किया जाता है।[3] |
| समीक्षा | एक बार समीक्षा और अनुमोदन को समाधान लाइव उत्पादन परिवेश एमएसएफ प्रक्रिया मॉडल में पूर्ण परिनियोजन के लिए किया जाता है।[3] |
तालिका 6: स्थिरीकरण गतिविधियाँ
मुख्य गतिविधियाँ बग परीक्षण और परिवर्तन हैं। एक बार एक पायलट संस्करण को पायलट के लिए पर्याप्त स्थिर माना जाता है, एक पायलट संस्करण बनाया और सक्रिय किया जाता है।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| परीक्षा परिणाम और परीक्षण उपकरण | परीक्षण के परिणाम और परीक्षण के लिए उपयोग किए जाने वाले उपकरणों का संग्रह। |
| परीक्षा के परिणाम | निष्पादित परीक्षणों के परिणाम। |
| परीक्षण उपकरण | परीक्षण के लिए प्रयुक्त उपकरण। |
| गोल्डन रिलीज | अंतिम समीक्षा के लिए प्रयुक्त संस्करण। |
| रिलीज नोट्स | रिलीज़ संस्करण के लिए नोट्स। |
| स्रोत कोड और निष्पादन योग्य | स्रोत कोड/निष्पादन योग्य संयोजन। |
| स्रोत कोड | उत्पाद का स्रोत कोड। |
| निष्पादन | निष्पादन योग्य स्रोत कोड द्वारा बनाया गया। |
| मील का पत्थर समीक्षा | अंतिम संस्करण और परियोजना दस्तावेजों की समीक्षा। |
| परियोजना दस्तावेज | सभी परियोजना दस्तावेजों का संग्रह। |
तालिका 7: स्थिरीकरण चरण में अवधारणाएँ
परिनियोजन चरण
चित्र 6: परिनियोजन चरण प्रक्रिया/डेटा मॉडल
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| मुख्य घटक परियोजना | "उत्पाद के लिए आवश्यक सभी परियोजना घटक जैसे डेटाबेस सर्वर, मेल सर्वर आदि।" |
| साइट हल परियोजना | दर्जी-निर्मित प्रणालियों के लिए उत्पाद का परिनियोजना को सॉफ्टवेयर उत्पादों के लिए छोड़ा जा सकता है। |
| स्थिर परियोजना | टैकिंग, संरक्षण और परियोजना घटकों में सुधार। |
| परियोजना को संचालन और समर्थन में स्थानांतरित करें | संचालन और सहायता समूह को सभी दस्तावेज़ और कोड स्थानांतरित करना। |
| ग्राहक से अंतिम स्वीकृति प्राप्त करें | समाधान के उत्पादन में और परियोजना को स्थगित करने की घोषणा करने से पहले ग्राहक को इस विषय पर सहमत होना चाहिए कि समूह ने अपने उद्देश्यों को पूर्ण कर लिया है। इसके लिए एक स्थिर समाधान, साथ ही स्पष्ट रूप से बताए गए सफलता मानदंड की आवश्यकता है। समाधान को स्थिर माने जाने के लिए, उपयुक्त संचालन और समर्थन प्रणाली का होना आवश्यक है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| परियोजना की समीक्षा करें | परियोजना की अंतिम समीक्षा। |
तालिका 8: परियोजना गतिविधियां: परिनियोजन चरण में मुख्य गतिविधि उत्पाद को सक्रिय करने के लिए आवश्यक आधारिक संरचना की स्थापना सर्वर आदि है। साथ ही, दस्तावेजों को अंतिम रूप दिया जाता है संचालन और सहायता विभाग को हस्तांतरित किया जाता है एक ज्ञानकोष का आधार बनाया जाता है और ग्राहक (यदि प्रयुक्त हो) और परियोजना समूह द्वारा उत्पाद और परियोजना की समीक्षा की जाती है।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| कार्यविधि और प्रक्रियाएं | कार्यविधि और प्रक्रियाओं का संग्रह। |
| प्रक्रिया | उत्पाद की स्थापना और संचालन के लिए उपयोग की जाने वाली प्रक्रियाओं का संग्रह। |
| कार्यविधि | उत्पाद की स्थापना और संचालन के लिए उपयोग की जाने वाली प्रक्रियाओं का संग्रह। |
| ज्ञानकोष, विवरण, लॉगबुक | ज्ञानकोष, रिपोर्ट और लॉगबुक का संग्रह। |
| ज्ञानकोष | उत्पाद से संबद्ध ज्ञानकोष |
| विवरण | उत्पाद से संबंधित विवरण |
| लॉगबुक | उत्पाद से संबद्ध लॉगबुक |
| दस्तावेज़ भंडार | सभी दस्तावेजों का भंडार। |
| सभी परियोजना दस्तावेजों का अंतिम संस्करण | परियोजना दस्तावेजों के अंतिम संस्करण। |
| संचालन और समर्थन सूचना प्रणाली | उत्पाद से जुड़ी संचालन और समर्थन समूहों द्वारा उपयोग की जाने वाली प्रणालियाँ। |
| ग्राहक/उपयोगकर्ता प्रमाणित डेटा | ग्राहक/उपयोगकर्ता से उत्पाद के साथ प्रमाणित डेटा का संग्रह। |
| अगले चरणों की परिभाषा | उत्पाद विकसित करने के लिए उठाए जाने वाले अगले चरणों का विवरण। |
| परियोजना स्थानांतरण विवरण। | उत्पाद, परियोजना और संचालन और समर्थन के हस्तांतरण पर अंतिम विवरण। |
तालिका 9: परिनियोजना चरण की अवधारणाएँ
समग्र डेटा मॉडल
चित्र 7: समग्र डेटा मॉडल: यह डेटा मॉडल एक पूर्ण परियोजना संदर्भ में सभी अवधारणाओं को बहुलता और संबंधों के साथ प्रदर्शित करता है।
इंटरनेट-गति विकास के साथ प्रयोग के लिए उपकरण
- आरेखण उपकरण (उदाहरण: माइक्रोसॉफ्ट विज़ियो, रेशनलरोज, डीआईए) आरेख बनाने के लिए।
- वर्ड प्रोसेसर (उदाहरण: माइक्रोसॉफ्ट वर्ड, OpenOffice.org राइटर, एबीवर्ड, कैलीग्रावर्ड) विजन स्टेटमेंट या कार्यक्षेत्र-दस्तावेज़ जैसे टेक्स्ट दस्तावेज़ बनाने के लिए।
- स्प्रेडशीट (उदाहरण: माइक्रोसॉफ्ट एक्सेल, OpenOffice.org कैल्क, ग्नुमेरिक, कैलीग्राशीट) प्राथमिकता वाली जोखिम सूची बनाने और लागत गणना करने के लिए।
- परियोजना उपकरण (उदाहरण: माइक्रोसॉफ्ट प्रोजेक्ट, ओपनप्रोज, गनोम प्लानर, कैलीग्रा योजना) परियोजना गतिविधियों की योजना बनाने के लिए।
- डेटाबेस और डेटाबेस प्रबंधन उपकरण (उदाहरण: एमएस एसक्यूएल सर्वर, माईएसक्यूएल, ओरेकल, पोस्टग्रेएसक्यूएल) ज्ञानकोष बनाने के लिए।
- स्वचालित परीक्षण उपकरण (उदाहरण: परीक्षण स्क्रिप्ट) प्रत्येक दैनिक निर्माण के बाद परीक्षण निष्पादित करने के लिए।
यह भी देखें
- सॉफ्टवेयर विकास
- विकास और पुनरावृत्त विकास
- माइक्रोसॉफ्ट फ्रेमवर्क
- डीएसडीएम
- मास्को विधि
टिप्पणियाँ
- ↑ Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003
- ↑ As shown in the paper of Zuser, Heil and Grechening.
- ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 Microsoft Solutions White Paper June 2002
- ↑ 4.0 4.1 4.2 4.3 Microsoft Risk Management Discipline White Paper
संदर्भ
- माइक्रोसॉफ्ट June 2002 माइक्रोसॉफ्ट Solutions Framework (White Paper) माइक्रोसॉफ्ट Press
- माइक्रोसॉफ्ट June 2002 MSF Risk Management Discipline v.1.1 (White Paper) माइक्रोसॉफ्ट Press
- Wolfgang Zuser, Stefan Heil, Thomas Grechenig 2005 Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study Proceedings of the 2005 workshop on Software quality
- Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003 New Directions on Agile Methods: A Comparative Analysis ICSE
- Michael A. Cusumano, David B. Yoffie 1999 Software Development on Internet Time 32 IEEE
- Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internet Software Engineering: A Different Class of Processes Annals of Software Engineering 14 169–195
