इंटरनेट-गति विकास: Difference between revisions
No edit summary |
No edit summary |
||
| 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> इंटरनेट-गति विकास का विकास चरण भी [[खुला स्रोत सॉफ्टवेयर]] विकास मॉडल के साथ कुछ समानताएं दिखाता है क्योंकि इंटरनेट के माध्यम से संचार और कोड और दस्तावेज़ीकरण को संग्रहीत करने के लिए रिपॉजिटरी के उपयोग के कारण दुनिया भर के कई डेवलपर विकास प्रक्रिया का भाग हो सकते हैं। . | ||
इंटरनेट | ==इंटरनेट-गति विकास के चरण== | ||
इस पद्धति के पीछे का मॉडल इस तरह दिखता है यह मॉडल विधि के पांच बुनियादी चरणों को दर्शाता है। इस प्रविष्टि के निम्नलिखित खंडों में इन चरणों की व्याख्या की जाएगी। चरण हैं: कल्पना करना, योजना बनाना, विकास करना, स्थिर करना और तैनाती करना। इस चक्र के पूर्ण होने के बाद सिस्टम का एक संस्करण तैयार होता है और एक नया चक्र एक नया संस्करण बनाने के लिए शुरू होता है। चरणों को निम्नलिखित खंडों में समझाया गया है और एक [[मेटा-मॉडलिंग]] तकनीक के माध्यम से दिखाया गया है। एक परियोजना के संदर्भ में बहुलताओं और अवधारणाओं के बारे में अधिक जानकारी बाद में समग्र डेटा मॉडल में देखी जा सकती है। | |||
चित्रा 1: चरण मॉडल | |||
[[File:PhaseModel.jpg]] | |||
[[File:PhaseModel.jpg]] | |||
=== कल्पना चरण === | === कल्पना चरण === | ||
परिकल्पना चरण को निम्नानुसार प्रतिरूपित किया जा सकता है: | परिकल्पना चरण को निम्नानुसार प्रतिरूपित किया जा सकता है: | ||
[[File:Envisioning.jpg]] | चित्र 2: कल्पना चरण प्रक्रिया/डेटा मॉडल[[File:Envisioning.jpg]] | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 77: | Line 73: | ||
|- | |- | ||
|विस्तार | |विस्तार | ||
| "स्कोप पहचानता है कि दृष्टि के भाग (ओं) को परियोजना की बाधाओं के भीतर | | "स्कोप पहचानता है कि दृष्टि के भाग (ओं) को परियोजना की बाधाओं के भीतर पूर्ण किया जा सकता है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA" /> | ||
| Line 132: | Line 128: | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
| colspan=2 |सुविधाओं के लिए आवश्यकताएँ नियंत्रित करें। | | colspan=2 |सुविधाओं के लिए आवश्यकताएँ नियंत्रित करें। | ||
| "जैसा कि टीम समाधान को डिजाइन करने और कार्यात्मक विनिर्देशों को बनाने के लिए आगे बढ़ती है, आवश्यकताओं और सुविधाओं के बीच पता लगाने की क्षमता बनाए रखना महत्वपूर्ण है। पता लगाने की क्षमता का एक-से-एक आधार पर होना आवश्यक नहीं है। ट्रेसबिलिटी बनाए रखना डिजाइन की शुद्धता की जांच करने और यह सत्यापित करने का एक तरीका है कि डिजाइन समाधान के लक्ष्यों और आवश्यकताओं को | | "जैसा कि टीम समाधान को डिजाइन करने और कार्यात्मक विनिर्देशों को बनाने के लिए आगे बढ़ती है, आवश्यकताओं और सुविधाओं के बीच पता लगाने की क्षमता बनाए रखना महत्वपूर्ण है। पता लगाने की क्षमता का एक-से-एक आधार पर होना आवश्यक नहीं है। ट्रेसबिलिटी बनाए रखना डिजाइन की शुद्धता की जांच करने और यह सत्यापित करने का एक तरीका है कि डिजाइन समाधान के लक्ष्यों और आवश्यकताओं को पूर्ण करता है। | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
| Line 156: | Line 152: | ||
| rowspan=5 |डिज़ाइन बनाएँ | | rowspan=5 |डिज़ाइन बनाएँ | ||
|केस मॉडल का उपयोग करें | |केस मॉडल का उपयोग करें | ||
| "यह उपयोगकर्ता प्रोफाइल (जिसे "व्यक्ति" भी कहा जाता है) के एक व्यवस्थित विश्लेषण से शुरू होता है, जो विभिन्न प्रकार के उपयोगकर्ताओं और उनके कार्य कार्यों का वर्णन करता है (संचालन कर्मचारी भी उपयोगकर्ता हैं)। इनमें से अधिकतर प्रायः कल्पना चरण के दौरान किया जाता है। ये उपयोग परिदृश्यों की एक श्रृंखला में विभाजित हैं, जहां एक विशेष प्रकार का उपयोगकर्ता एक प्रकार की गतिविधि को | | "यह उपयोगकर्ता प्रोफाइल (जिसे "व्यक्ति" भी कहा जाता है) के एक व्यवस्थित विश्लेषण से शुरू होता है, जो विभिन्न प्रकार के उपयोगकर्ताओं और उनके कार्य कार्यों का वर्णन करता है (संचालन कर्मचारी भी उपयोगकर्ता हैं)। इनमें से अधिकतर प्रायः कल्पना चरण के दौरान किया जाता है। ये उपयोग परिदृश्यों की एक श्रृंखला में विभाजित हैं, जहां एक विशेष प्रकार का उपयोगकर्ता एक प्रकार की गतिविधि को पूर्ण करने का प्रयास कर रहा है, जैसे किसी होटल में फ्रंट डेस्क पंजीकरण या सिस्टम प्रशासक के लिए उपयोगकर्ता पासवर्ड का प्रबंध करना। अंत में, प्रत्येक उपयोग परिदृश्य को कार्यों के एक विशिष्ट अनुक्रम में विभाजित किया जाता है, जिसे उपयोग मामलों के रूप में जाना जाता है, जिसे उपयोगकर्ता उस गतिविधि को पूर्ण करने के लिए करता है। इसे "स्टोरी-बोर्डिंग या एमएसएफ प्रोसेस मॉडल" कहा जाता है।<ref name="ReferenceA" /> | ||
|- VALIGN=TOP | |- VALIGN=TOP | ||
|वैचारिक डिजाइन बनाएँ | |वैचारिक डिजाइन बनाएँ | ||
| Line 275: | Line 271: | ||
=== स्थिरीकरण चरण === | === स्थिरीकरण चरण === | ||
[[File:Stabilizing.jpg]] | चित्रा 5: स्थिरीकरण चरण प्रक्रिया/डेटा मॉडल[[File:Stabilizing.jpg]] | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Line 347: | Line 343: | ||
|- | |- | ||
|तैनाती को स्थिर करें | |तैनाती को स्थिर करें | ||
|टैकिंग, | |टैकिंग, संरक्षण और तैनात घटकों में सुधार। | ||
|- | |- | ||
|परियोजना को संचालन और समर्थन में स्थानांतरित करें | |परियोजना को संचालन और समर्थन में स्थानांतरित करें | ||
| Line 353: | Line 349: | ||
|- | |- | ||
|ग्राहक से अंतिम स्वीकृति प्राप्त करें | |ग्राहक से अंतिम स्वीकृति प्राप्त करें | ||
| समाधान के उत्पादन में होने और परियोजना को बंद करने की घोषणा करने से पहले ग्राहक को इस बात से सहमत होना चाहिए कि टीम ने अपने उद्देश्यों को | | समाधान के उत्पादन में होने और परियोजना को बंद करने की घोषणा करने से पहले ग्राहक को इस बात से सहमत होना चाहिए कि टीम ने अपने उद्देश्यों को पूर्ण कर लिया है। इसके लिए एक स्थिर समाधान, साथ ही स्पष्ट रूप से बताए गए सफलता मानदंड की आवश्यकता है। समाधान को स्थिर माने जाने के लिए, उपयुक्त संचालन और समर्थन प्रणाली का होना आवश्यक है।" | ||
(एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | (एमएसएफ प्रक्रिया मॉडल)<ref name="ReferenceA"/> | ||
Revision as of 16:25, 24 February 2023
इंटरनेट-गति विकास एक ऐसी सॉफ्टवेयर विकास पद्धति है जिसमें उच्च गति वाले उत्पाद को विकसित करने के उद्देश्य से दैनिक निर्माण के साथ एक संयुक्त सर्पिल मॉडल/वाटरफॉल मॉडल का उपयोग किया जाता है।
इसे 1990 के दशक के अंत में विकसित किया गया था क्योंकि सॉफ्टवेयर का विकास तीव्रता से परिवर्तित हो रहा था। कंपनियों को परियोजना के लिए निर्धारित समय के भीतर पूर्ण आवश्यकताओं के साथ उत्पादों को वितरित करने में समस्या हो रही थी और इस प्रकार वे अधिक सॉफ्टवेयर विकास पद्धति में परिवर्तित हो रहे थे। इब्राहीमसन के पेपर में विकासवादी मानचित्र में इंटरनेट-गति पद्धति को कैसे विकसित किया गया था इसके विषय में अधिक विवरण देखा जा सकता है।[1]
इंटरनेट-गति विकास के पीछे मुख्य विचार
सॉफ्टवेयर इंजीनियरिंग में प्रायः सबसे बड़ी समस्याओं में से एक यह है कि आवश्यकताओं में तेजी से परिवर्तन होता है और इस स्थिति के अनुकूल होने के लिए इंटरनेट-गति विकास पद्धति बनाई गई थी। यह विचार सॉफ्टवेयर इंजीनियरिंग मॉडल में दो मुख्य मानकों को जोड़ने का है अर्थात् सर्पिल मॉडल और वॉटरफॉल मॉडल को एक नए मॉडल में और इस नए मॉडल पर एक नई सॉफ्टवेयर इंजीनियरिंग पद्धति को आधार बनाना है। वॉटरफॉल मॉडल की मुख्य कमी यह थी कि जब आवश्यकताओं में परिवर्तन मे होता है तो यह बहुत कठोर और बहुत नम्य नहीं होता है जबकि सर्पिल मॉडल की कमी यह थी कि यह बहुत संरचनात्मक नहीं था। इंटरनेट-गति के विकास के पीछे विचार यह है कि इन मॉडलों के संयोजन का परिणाम एक ऐसी पद्धति के रूप में होगा जिसमें ये कमी नहीं हैं और उन स्थितियों में उपयोग करने के लिए एक अपेक्षाकृत तरीका है जहां आवश्यकताएं तीव्रता से परिवर्तित हो सकती हैं लेकिन परियोजना को संरचनात्मक तरीके से क्रियान्वित किया जाना है।
इंटरनेट-गति विकास पद्धति का लक्ष्य
इंटरनेट-गति विकास पद्धति का लक्ष्य सॉफ्टवेयर विकासक को एक संरचनात्मक तरीके से एक परियोजना को पूर्ण करने की स्वीकृति देना है लेकिन ग्राहक की आवश्यकताओ को पूर्ण करने में सक्षम होना है। इसका उद्देश्य विकास के माध्यम से कम समय में एक सॉफ्टवेयर उत्पाद प्रदान करना है। यह पद्धति पूरी तरह से कार्यान्वित प्रणाली प्रदान करने का एक साधन प्रदान करती है और मील के पत्थर के उपयोग के माध्यम से किसी परियोजना में प्रगति निर्धारित करने के लिए भी आवश्यक हैं। इस पद्धति के मुख्य संस्करणों में से एक माइक्रोसॉफ्ट द्वारा बनाया गया है और इसे माइक्रोसॉफ्ट फ्रेमवर्क कहा जाता है।
इंटरनेट-गति विकास पद्धति के पीछे की अवधारणा
पहली अवधारणा जो इंटरनेट की गति के विकास के लिए बहुत महत्वपूर्ण है एक कार्यक्षेत्र और परियोजना प्रबंधन का निर्माण है। इसका अर्थ यह है कि परियोजना के प्रारम्भ में सिस्टम की एक वैश्विक परिभाषा बनाई जाती है जो यह प्रदर्शित करती है कि सिस्टम का लक्ष्य क्या है और इसकी स्थिति क्या है और क्या नहीं है। यह मौलिक प्रकारों में से एक है क्योंकि यह विकासक को कुछ दिशानिर्देश देता है कि कार्यक्षेत्र को एक विजन सारणी में संक्षिप्त किया जा सकता है। इस पद्धति के भीतर एक और बहुत महत्वपूर्ण अवधारणा स्कोप प्रबंधन है। स्कोप विकास को स्थगित करने के लिए स्कोप को परियोजना में प्रबंधित करने की आवश्यकता होती है जिसके परिणामस्वरूप रुकावट उत्पन्न होती है। यदि कार्यक्षेत्र को तीव्रता से निर्धारित किया जाएगा और कार्यक्षेत्र में परिवर्तन (जैसे अतिरिक्त सुविधाओं को जोड़ना जो पहले परियोजना के कार्यक्षेत्र से बाहर माने जाते थे) का मूल्यांकन किया जाएगा या तो स्वीकृत या अस्वीकृत कर दिया जाएगा। कार्यक्षेत्र में परिवर्तन किए जा सकते हैं लेकिन यह सदैव सुविधाओं, संसाधनों और समय के बीच व्यापार विणपन से प्रभावित होगा। लेकिन इंटरनेट-गति विकास पद्धति पारंपरिक तरीकों से बहुत अलग है और इसलिए सॉफ्टवेयर विकास पद्धति सिद्धांतों का उपयोग करती है। यह आवश्यकताओं के अनुकूलन पर ध्यान केंद्रित करता है और जैसे कि एजाइल सॉफ्टवेयर विकास के मूल सिद्धांतों पर आधारित है।
इंटरनेट-गति विकास भी एक निश्चित माइक्रोसॉफ्ट फ्रेमवर्क संरचना का उपयोग करने पर ध्यान केंद्रित करता है जिससे उत्पाद बनाया जाता है और विकास की गति को विस्तृत करने के लिए उपकरणों पर बहुत अधिक निर्भर करता है। इंटरनेट की गति के विकास की एक और मूलभूत अवधारणा यह है कि यह छोटी टीमों का उपयोग करने पर भी ध्यान केंद्रित करता है। विचार यह है कि सभी परियोजनाओं को छोटी-छोटी गतिविधियों में विभाजित किया जा सकता है जिन्हें प्रायः समानांतर में किया जा सकता है। छोटी टीमें प्रायः अपने कार्य पर अधिक ध्यान केंद्रित कर सकती हैं और परियोजना के भीतर उत्तरदायित्व निर्धारित करना और प्रगति की संरक्षण करना आसान होता है।
इंटरनेट-गति विकास की इस प्रविष्टि में चर्चा की गई अंतिम अवधारणा समानांतर विकास की अवधारणा है। इस अवधारणा का मूल रूप से तात्पर्य यह है कि सभी सॉफ्टवेयर विकास जितनी बार संभव हो समानांतर में किया जाता है। यह बहुत तेजी से विकास की स्वीकृति देगा और यह छोटी टीमों को जितना संभव हो सके अपनी सुविधा पर ध्यान केंद्रित करने की स्वीकृति देगा, जिसका गुणवत्ता पर अच्छा परिणाम है। यह सुनिश्चित करने के लिए कि अंतिम प्रणाली बनाने के लिए छोटी टीमें एक साथ काम करती हैं, हालांकि उनके विकास को प्रायः सिंक्रनाइज़ करने की आवश्यकता होती है। यह दैनिक बिल्ड का उपयोग करके किया जा सकता है जिसका अर्थ है कि सभी डेवलपर दिन के अंत में अपने कोड की जांच करते हैं जिसके बाद एक बिल्ड बनाया जाता है जिसका मूल्यांकन और प्रगति की संरक्षण के लिए परीक्षण किया जा सकता है। निर्माण में एक फीचर के पूर्ण होने के बाद इसे परीक्षण और परिष्कृत करने की आवश्यकता होती है जिसे कभी-कभी सिंक-एंड-स्टेबिलाइज प्रक्रिया कहा जाता है। विकसित सुविधाओं को निर्माण और परीक्षण के साथ सिंक्रनाइज़ किया गया है। इन परीक्षणों के बाद किसी भी बग को ठीक कर दिया जाएगा और फीचर को बेहतर काम करने के लिए परिष्कृत किया जा सकता है (जो स्थिरीकरण भाग है)।
इंटरनेट-गति का विकास चुस्त सिद्धांतों पर आधारित है और इस तरह इसमें चरम कार्यक्रम, तर्कसंगत एकीकृत प्रक्रिया, गतिशील प्रणाली विकास पद्धति और फीचर संचालित विकास के साथ बहुत समानताएं हैं। इंटरनेट की गति का विकास हालांकि इन तरीकों से अलग है क्योंकि इसमें एक अधिक व्यापक जोखिम प्रबंधन योजना भी सम्मिलित है और एक परियोजना के एक बहुत ही महत्वपूर्ण उद्देश्य के रूप में गुणवत्ता है।[2] इंटरनेट-गति विकास का विकास चरण भी खुला स्रोत सॉफ्टवेयर विकास मॉडल के साथ कुछ समानताएं दिखाता है क्योंकि इंटरनेट के माध्यम से संचार और कोड और दस्तावेज़ीकरण को संग्रहीत करने के लिए रिपॉजिटरी के उपयोग के कारण दुनिया भर के कई डेवलपर विकास प्रक्रिया का भाग हो सकते हैं। .
इंटरनेट-गति विकास के चरण
इस पद्धति के पीछे का मॉडल इस तरह दिखता है यह मॉडल विधि के पांच बुनियादी चरणों को दर्शाता है। इस प्रविष्टि के निम्नलिखित खंडों में इन चरणों की व्याख्या की जाएगी। चरण हैं: कल्पना करना, योजना बनाना, विकास करना, स्थिर करना और तैनाती करना। इस चक्र के पूर्ण होने के बाद सिस्टम का एक संस्करण तैयार होता है और एक नया चक्र एक नया संस्करण बनाने के लिए शुरू होता है। चरणों को निम्नलिखित खंडों में समझाया गया है और एक मेटा-मॉडलिंग तकनीक के माध्यम से दिखाया गया है। एक परियोजना के संदर्भ में बहुलताओं और अवधारणाओं के बारे में अधिक जानकारी बाद में समग्र डेटा मॉडल में देखी जा सकती है।
चित्रा 1: चरण मॉडल
कल्पना चरण
परिकल्पना चरण को निम्नानुसार प्रतिरूपित किया जा सकता है:
चित्र 2: कल्पना चरण प्रक्रिया/डेटा मॉडलFile:Envisioning.jpg
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| आवश्यकताओं का विश्लेषण करें। | परिकल्पना के चरण के दौरान, व्यावसायिक आवश्यकताओं की पहचान और विश्लेषण किया जाना चाहिए।
“नियोजन चरण के दौरान इन्हें और अधिक सख्ती से परिष्कृत किया जाता है।" (एमएसएफ प्रक्रिया मॉडल)[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: स्थिरीकरण चरण प्रक्रिया/डेटा मॉडलFile:Stabilizing.jpg
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| परीक्षण | इस चरण के दौरान परीक्षण यथार्थवादी पर्यावरणीय परिस्थितियों मे एमएसएफ प्रक्रिया मॉडल के तहत उपयोग और संचालन पर जोर देता है।[3] |
| बग्स संशोधन | टीम बग्स को हल करने और ट्राई करने (प्राथमिकता देने) पर ध्यान केंद्रित करती है और एमएसएफ प्रोसेस मॉडल को रिलीज़ करने के लिए समाधान तैयार करती है।[3] |
| पायलट प्रसारण | एक बार एक बिल्ड को एक रिलीज उम्मीदवार होने के लिए पर्याप्त रूप से स्थिर माना जाता है, तो समाधान को पायलट समूह एमएसएफ प्रोसेस मॉडल में तैनात किया जाता है।[3] |
| समीक्षा | एक बार समीक्षा और अनुमोदन के बाद, समाधान लाइव उत्पादन परिवेश एमएसएफ प्रक्रिया मॉडल में पूर्ण परिनियोजन के लिए तैयार है।[3] |
तालिका 6: स्थिरीकरण गतिविधियाँ
मुख्य गतिविधियाँ बगों का परीक्षण और समाधान हैं। एक बार एक पायलट संस्करण को एक पायलट के लिए पर्याप्त स्थिर माना जाता है, एक पायलट संस्करण बनाया और तैनात किया जाता है। इस पायलट से यह या तो परीक्षण/स्थिरीकरण लूप में वापस जाएगा या इसे अनुमोदित और समीक्षा की जाएगी।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| परीक्षा परिणाम और परीक्षण उपकरण | परीक्षण के परिणाम और परीक्षण के लिए उपयोग किए जाने वाले उपकरणों का संग्रह। |
| परीक्षा के परिणाम | निष्पादित परीक्षणों के परिणाम। |
| परीक्षण उपकरण | परीक्षण के लिए प्रयुक्त उपकरण। |
| गोल्डन रिलीज | अंतिम समीक्षा के लिए प्रयुक्त संस्करण। |
| रिलीज नोट्स | रिलीज़ संस्करण के लिए नोट्स। |
| स्रोत कोड और निष्पादन योग्य | स्रोत कोड/निष्पादन योग्य संयोजन। |
| स्रोत कोड | उत्पाद का स्रोत कोड। |
| निष्पादन | निष्पादन योग्य स्रोत कोड द्वारा बनाया गया। |
| मील का पत्थर समीक्षा | अंतिम संस्करण और परियोजना दस्तावेजों की समीक्षा। |
| परियोजना दस्तावेज | सभी परियोजना दस्तावेजों का संग्रह। |
तालिका 7: स्थिरीकरण चरण में अवधारणाएँ
परिनियोजन चरण
चित्र 6: परिनियोजन चरण प्रक्रिया/डेटा मॉडल File:Deploying.jpg
| कार्यकलाप | परिभाषा (स्रोत) |
|---|---|
| कोर घटकों को तैनात करें | उत्पाद द्वारा आवश्यक सभी घटकों की तैनाती (जैसे डेटाबेस सर्वर, मेल सर्वर आदि) |
| साइट पर समाधान तैनात करें | दर्जी-निर्मित प्रणालियों के लिए उत्पाद का परिनियोजन यहां होता है (सॉफ्टवेयर उत्पादों के लिए छोड़ा जा सकता है)। |
| तैनाती को स्थिर करें | टैकिंग, संरक्षण और तैनात घटकों में सुधार। |
| परियोजना को संचालन और समर्थन में स्थानांतरित करें | संचालन और सहायता टीम को सभी दस्तावेज़ और कोड स्थानांतरित करना। |
| ग्राहक से अंतिम स्वीकृति प्राप्त करें | समाधान के उत्पादन में होने और परियोजना को बंद करने की घोषणा करने से पहले ग्राहक को इस बात से सहमत होना चाहिए कि टीम ने अपने उद्देश्यों को पूर्ण कर लिया है। इसके लिए एक स्थिर समाधान, साथ ही स्पष्ट रूप से बताए गए सफलता मानदंड की आवश्यकता है। समाधान को स्थिर माने जाने के लिए, उपयुक्त संचालन और समर्थन प्रणाली का होना आवश्यक है।"
(एमएसएफ प्रक्रिया मॉडल)[3] |
| परियोजना की समीक्षा करें | परियोजना की अंतिम समीक्षा। |
तालिका 8: गतिविधियों की तैनाती
परिनियोजन चरण में मुख्य गतिविधि उत्पाद को चलाने के लिए आवश्यक बुनियादी ढाँचे की स्थापना (सर्वर आदि की तैनाती) है। साथ ही, दस्तावेजों को अंतिम रूप दिया जाता है और संचालन और सहायता विभाग को हस्तांतरित किया जाता है, एक ज्ञान का आधार बनाया जाता है और ग्राहक (यदि प्रयुक्त हो) और परियोजना टीम द्वारा उत्पाद और परियोजना की समीक्षा की जाती है।
| अवधारणा | परिभाषा (स्रोत) |
|---|---|
| कार्यविधि और प्रक्रियाएं | कार्यविधि और प्रक्रियाओं का संग्रह। |
| प्रक्रिया | उत्पाद की स्थापना और संचालन के लिए उपयोग की जाने वाली प्रक्रियाओं का संग्रह। |
| कार्यविधि | उत्पाद की स्थापना और संचालन के लिए उपयोग की जाने वाली प्रक्रियाओं का संग्रह। |
| ज्ञानकोष, विवरण, लॉगबुक | ज्ञानकोष, रिपोर्ट और लॉगबुक का संग्रह। |
| ज्ञानकोष | उत्पाद से संबद्ध ज्ञानकोष |
| विवरण | उत्पाद से संबंधित विवरण |
| लॉगबुक | उत्पाद से संबद्ध लॉगबुक |
| दस्तावेज़ भंडार | सभी दस्तावेजों का भंडार। |
| सभी परियोजना दस्तावेजों का अंतिम संस्करण | परियोजना दस्तावेजों के अंतिम संस्करण। |
| संचालन और समर्थन सूचना प्रणाली | उत्पाद से जुड़ी संचालन और समर्थन टीमों द्वारा उपयोग की जाने वाली प्रणालियाँ। |
| ग्राहक/उपयोगकर्ता प्रमाणित डेटा | ग्राहक/उपयोगकर्ता से उत्पाद के साथ प्रमाणित डेटा का संग्रह। |
| अगले चरणों की परिभाषा | उत्पाद विकसित करने के लिए उठाए जाने वाले अगले चरणों का विवरण। |
| परियोजना स्थानांतरण विवरण। | उत्पाद, परियोजना और संचालन और समर्थन के हस्तांतरण पर अंतिम विवरण।। |
तालिका 9: परिनियोजन चरण में अवधारणाएँ
समग्र डेटा मॉडल
चित्र 7: समग्र डेटा मॉडल यह डेटा मॉडल एक पूर्ण परियोजना संदर्भ में सभी अवधारणाओं को बहुलताओं और संबंधों के साथ दिखाता है।File:Datamodel.jpg
इंटरनेट-गति विकास के साथ प्रयोग के लिए उपकरण
- आरेखण उपकरण (उदाहरण: माइक्रोसॉफ्ट विज़ियो, रेशनलरोज, डीआईए) आरेख बनाने के लिए।
- वर्ड प्रोसेसर (उदाहरण: माइक्रोसॉफ्ट वर्ड, 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
