डायनेमिक सिस्टम डेवलपमेंट मेथड: Difference between revisions
m (Deepak moved page गतिशील सिस्टम विकास विधि to डायनेमिक सिस्टम डेवलपमेंट मेथड without leaving a redirect) |
No edit summary |
||
| Line 1: | Line 1: | ||
[[File:DSDM Atern Project Phases.png|thumb|320px|डीएसडीएम परियोजना प्रबंधन पद्धति का मॉडल।]] | [[File:DSDM Atern Project Phases.png|thumb|320px|डीएसडीएम परियोजना प्रबंधन पद्धति का मॉडल।]] | ||
{{Software development process}} | {{Software development process}} | ||
डायनेमिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम) एक एजाइल मैनेजमेंट प्रोजेक्ट डिलीवरी फ्रेमवर्क है, जिसे शुरुआत में [[ सॉफ्टवेयर विकास पद्धति ]] के रूप में उपयोग किया जाता है।<ref>[https://agilekrc.com/about-us Keith Richards], ''Agile project management: running PRINCE2 projects with DSDM Atern.'' OGC – Office of Government Commerce. The Stationery Office, 31 jul. 2007.</ref><ref>Plonka, Laura, et al. "UX Design in Agile: A DSDM Case Study." ''Agile Processes in Software Engineering and Extreme Programming.'' Springer International Publishing, 2014. 1-15.</ref> पहली बार 1994 में जारी किया गया, डीएसडीएम ने मूल रूप से तीव्र अनुप्रयोग विकास (आरएडी) पद्धति में कुछ अनुशासन प्रदान करने की मांग की थी।<ref>Abrahamsson, Pekka, et al. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_03_ART_06_ARTICLE_ABRAHAMSSON_New_Directions_Agile_Methods.pdf New directions on agile methods: a comparative analysis]." Software Engineering, 2003. Proceedings. 25th International Conference on. Ieee, 2003.</ref> बाद के संस्करणों में डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क को संशोधित किया गया और यह सॉफ्टवेयर विकास और कोड निर्माण पर विशेष रूप से ध्यान केंद्रित करने के बजाय परियोजना प्रबंधन और समाधान वितरण के लिए एक सामान्य दृष्टिकोण बन गया। | डायनेमिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम) एक एजाइल मैनेजमेंट प्रोजेक्ट डिलीवरी फ्रेमवर्क है, जिसे शुरुआत में [[ सॉफ्टवेयर विकास पद्धति ]] के रूप में उपयोग किया जाता है।<ref>[https://agilekrc.com/about-us Keith Richards], ''Agile project management: running PRINCE2 projects with DSDM Atern.'' OGC – Office of Government Commerce. The Stationery Office, 31 jul. 2007.</ref><ref>Plonka, Laura, et al. "UX Design in Agile: A DSDM Case Study." ''Agile Processes in Software Engineering and Extreme Programming.'' Springer International Publishing, 2014. 1-15.</ref> पहली बार 1994 में जारी किया गया, डीएसडीएम ने मूल रूप से तीव्र अनुप्रयोग विकास (आरएडी) पद्धति में कुछ अनुशासन प्रदान करने की मांग की थी।<ref>Abrahamsson, Pekka, et al. "[http://secure.com.sg/courses/ICT353/Session_Collateral/TOP_03_ART_06_ARTICLE_ABRAHAMSSON_New_Directions_Agile_Methods.pdf New directions on agile methods: a comparative analysis]." Software Engineering, 2003. Proceedings. 25th International Conference on. Ieee, 2003.</ref> बाद के संस्करणों में डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क को संशोधित किया गया और यह सॉफ्टवेयर विकास और कोड निर्माण पर विशेष रूप से ध्यान केंद्रित करने के बजाय परियोजना प्रबंधन और समाधान वितरण के लिए एक सामान्य दृष्टिकोण बन गया। और इसका उपयोग गैर-आईटी परियोजनाओं के लिए किया जा सकता है।<ref>{{cite book|last1=Stapleton|first1=Jennifer|title=व्यवसाय केंद्रित विकास|date=January 2003|publisher=Pearson Education|isbn=9780321112248|page=113}}</ref> डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क पूरे प्रोजेक्ट जीवनचक्र में गतिविधियों की एक विस्तृत श्रृंखला को शामिल करता है और इसमें मजबूत नींव और शासन शामिल है, जो इसे कुछ अन्य एजाइल तरीकों से अलग करता है।<ref name=Moran2015>{{cite book|last1=Moran|first1=Alan|title=चंचल प्रबंधन|date=March 2015|publisher=Springer|isbn=9783319162614|pages=21–24}}</ref> डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क एक पुनरावृत्त और वृद्धिशील विकास दृष्टिकोण है जो निरंतर उपयोगकर्ता/ग्राहक भागीदारी सहित एजाइल विकास के सिद्धांतों को अपनाता है। | ||
डीएसडीएम शुरुआत में लागत, गुणवत्ता और समय तय करता है और बताए गए समय की कमी को पूरा करने के लिए परियोजना को वितरित करने योग्य समायोजित करने के लिए MoSCoW के दायरे की प्राथमिकताओं को जरूरी, जरूरी, जरूरी और जरूरी नहीं में उपयोग करता है। डीएसडीएम सॉफ्टवेयर और गैर-आईटी समाधान विकसित करने के लिए कई एजाइल सॉफ्टवेयर विकासों में से एक है, और यह एजाइल एलायंस का एक हिस्सा है। | डीएसडीएम शुरुआत में लागत, गुणवत्ता और समय तय करता है और बताए गए समय की कमी को पूरा करने के लिए परियोजना को वितरित करने योग्य समायोजित करने के लिए MoSCoW के दायरे की प्राथमिकताओं को जरूरी, जरूरी, जरूरी और जरूरी नहीं में उपयोग करता है। डीएसडीएम सॉफ्टवेयर और गैर-आईटी समाधान विकसित करने के लिए कई एजाइल सॉफ्टवेयर विकासों में से एक है, और यह एजाइल एलायंस का एक हिस्सा है। | ||
| Line 42: | Line 39: | ||
=== मुख्य तकनीकें === | === मुख्य तकनीकें === | ||
* [[टाइमबॉक्सिंग]]: प्रोजेक्ट को भागों में विभाजित करके, प्रत्येक को एक निश्चित बजट और डिलीवरी की तारीख के साथ, क्रमिक रूप से पूरा करने का दृष्टिकोण है। प्रत्येक भाग के लिए कई आवश्यकताओं को प्राथमिकता दी जाती है और चुना जाता है। चूँकि समय और बजट निश्चित हैं, केवल शेष चर आवश्यकताएँ हैं। इसलिए यदि किसी परियोजना में समय या धन की कमी हो रही है तो सबसे कम प्राथमिकता वाली आवश्यकताओं को छोड़ दिया जाता है। इसका मतलब यह नहीं है कि एक अधूरा उत्पाद वितरित किया जाता है, क्योंकि [[पेरेटो सिद्धांत]] के अनुसार परियोजना का 80% हिस्सा सिस्टम आवश्यकताओं के 20% से आता है, इसलिए जब तक सिस्टम में उन सबसे महत्वपूर्ण 20% आवश्यकताओं को लागू किया जाता है, तब तक सिस्टम इसलिए यह व्यावसायिक आवश्यकताओं को पूरा करता है और कोई भी सिस्टम पहली कोशिश में पूरी तरह से तैयार नहीं होता है। | * [[टाइमबॉक्सिंग]]: प्रोजेक्ट को भागों में विभाजित करके, प्रत्येक को एक निश्चित बजट और डिलीवरी की तारीख के साथ, क्रमिक रूप से पूरा करने का दृष्टिकोण है। प्रत्येक भाग के लिए कई आवश्यकताओं को प्राथमिकता दी जाती है और चुना जाता है। चूँकि समय और बजट निश्चित हैं, केवल शेष चर आवश्यकताएँ हैं। इसलिए यदि किसी परियोजना में समय या धन की कमी हो रही है तो सबसे कम प्राथमिकता वाली आवश्यकताओं को छोड़ दिया जाता है। इसका मतलब यह नहीं है कि एक अधूरा उत्पाद वितरित किया जाता है, क्योंकि [[पेरेटो सिद्धांत]] के अनुसार परियोजना का 80% हिस्सा सिस्टम आवश्यकताओं के 20% से आता है, इसलिए जब तक सिस्टम में उन सबसे महत्वपूर्ण 20% आवश्यकताओं को लागू किया जाता है, तब तक सिस्टम इसलिए यह व्यावसायिक आवश्यकताओं को पूरा करता है और कोई भी सिस्टम पहली कोशिश में पूरी तरह से तैयार नहीं होता है। | ||
* [[MoSCoW विधि]]: कार्य वस्तुओं या आवश्यकताओं को प्राथमिकता देने की एक तकनीक है। यह एक संक्षिप्त शब्द है जिसका अर्थ है: | * [[MoSCoW विधि]]: कार्य वस्तुओं या आवश्यकताओं को प्राथमिकता देने की एक तकनीक है। यह एक संक्षिप्त शब्द है जिसका अर्थ है: | ||
| Line 57: | Line 53: | ||
=== भूमिकाएँ === | === भूमिकाएँ === | ||
डीएसडीएम परिवेश में कुछ भूमिकाएँ प्रस्तुत की गई हैं। यह महत्वपूर्ण है कि परियोजना शुरू करने से पहले परियोजना सदस्यों को विभिन्न भूमिकाओं में नियुक्त किया जाना चाहिए। प्रत्येक भूमिका की अपनी जिम्मेदारी होती है। भूमिकाएँ हैं: | डीएसडीएम परिवेश में कुछ भूमिकाएँ प्रस्तुत की गई हैं। यह महत्वपूर्ण है कि परियोजना शुरू करने से पहले परियोजना सदस्यों को विभिन्न भूमिकाओं में नियुक्त किया जाना चाहिए। प्रत्येक भूमिका की अपनी जिम्मेदारी होती है। भूमिकाएँ हैं: | ||
* कार्यकारी प्रायोजक: तथाकथित ''प्रोजेक्ट चैंपियन''। उपयोगकर्ता संगठन की एक महत्वपूर्ण भूमिका जिसके पास उचित धन और संसाधन देने की क्षमता और जिम्मेदारी है। इस भूमिका में निर्णय लेने की परम शक्ति होती है। | * कार्यकारी प्रायोजक: तथाकथित ''प्रोजेक्ट चैंपियन''। उपयोगकर्ता संगठन की एक महत्वपूर्ण भूमिका जिसके पास उचित धन और संसाधन देने की क्षमता और जिम्मेदारी है। इस भूमिका में निर्णय लेने की परम शक्ति होती है। | ||
| Line 69: | Line 64: | ||
* समाधान परीक्षक: कुछ परीक्षण करके तकनीकी सीमा तक शुद्धता की जांच करता है, जहां आवश्यक हो वहां दोष उठाता है और एक बार ठीक हो जाने पर दोबारा परीक्षण करता है। परीक्षक को कुछ टिप्पणी और दस्तावेज़ उपलब्ध कराने होंगे. | * समाधान परीक्षक: कुछ परीक्षण करके तकनीकी सीमा तक शुद्धता की जांच करता है, जहां आवश्यक हो वहां दोष उठाता है और एक बार ठीक हो जाने पर दोबारा परीक्षण करता है। परीक्षक को कुछ टिप्पणी और दस्तावेज़ उपलब्ध कराने होंगे. | ||
* लेखक: प्रत्येक कार्यशाला में की गई आवश्यकताओं, समझौतों और निर्णयों को इकट्ठा करने और रिकॉर्ड करने के लिए जिम्मेदार। | * लेखक: प्रत्येक कार्यशाला में की गई आवश्यकताओं, समझौतों और निर्णयों को इकट्ठा करने और रिकॉर्ड करने के लिए जिम्मेदार। | ||
* फैसिलिटेटर: कार्यशालाओं की प्रगति के प्रबंधन के लिए जिम्मेदार, एक प्रेरक के रूप में कार्य करता है | * फैसिलिटेटर: कार्यशालाओं की प्रगति के प्रबंधन के लिए जिम्मेदार, एक प्रेरक के रूप में कार्य करता है तैयारी और संचार के लिए. | ||
* विशेषज्ञ भूमिकाएँ: बिजनेस आर्किटेक्ट, गुणवत्ता प्रबंधक, सिस्टम इंटीग्रेटर, आदि। | * विशेषज्ञ भूमिकाएँ: बिजनेस आर्किटेक्ट, गुणवत्ता प्रबंधक, सिस्टम इंटीग्रेटर, आदि। | ||
Revision as of 21:39, 5 July 2023
| Part of a series on |
| Software development |
|---|
डायनेमिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम) एक एजाइल मैनेजमेंट प्रोजेक्ट डिलीवरी फ्रेमवर्क है, जिसे शुरुआत में सॉफ्टवेयर विकास पद्धति के रूप में उपयोग किया जाता है।[1][2] पहली बार 1994 में जारी किया गया, डीएसडीएम ने मूल रूप से तीव्र अनुप्रयोग विकास (आरएडी) पद्धति में कुछ अनुशासन प्रदान करने की मांग की थी।[3] बाद के संस्करणों में डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क को संशोधित किया गया और यह सॉफ्टवेयर विकास और कोड निर्माण पर विशेष रूप से ध्यान केंद्रित करने के बजाय परियोजना प्रबंधन और समाधान वितरण के लिए एक सामान्य दृष्टिकोण बन गया। और इसका उपयोग गैर-आईटी परियोजनाओं के लिए किया जा सकता है।[4] डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क पूरे प्रोजेक्ट जीवनचक्र में गतिविधियों की एक विस्तृत श्रृंखला को शामिल करता है और इसमें मजबूत नींव और शासन शामिल है, जो इसे कुछ अन्य एजाइल तरीकों से अलग करता है।[5] डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क एक पुनरावृत्त और वृद्धिशील विकास दृष्टिकोण है जो निरंतर उपयोगकर्ता/ग्राहक भागीदारी सहित एजाइल विकास के सिद्धांतों को अपनाता है।
डीएसडीएम शुरुआत में लागत, गुणवत्ता और समय तय करता है और बताए गए समय की कमी को पूरा करने के लिए परियोजना को वितरित करने योग्य समायोजित करने के लिए MoSCoW के दायरे की प्राथमिकताओं को जरूरी, जरूरी, जरूरी और जरूरी नहीं में उपयोग करता है। डीएसडीएम सॉफ्टवेयर और गैर-आईटी समाधान विकसित करने के लिए कई एजाइल सॉफ्टवेयर विकासों में से एक है, और यह एजाइल एलायंस का एक हिस्सा है।
2014 में, डीएसडीएम ने 'डीएसडीएम एजाइल प्रोजेक्ट फ्रेमवर्क' में विधि का नवीनतम संस्करण जारी किया। साथ ही नए डीएसडीएम मैनुअल ने सेवा वितरण (विशेष रूप से आईटीआईएल) राजकुमार2, सफल कार्यक्रमों के प्रबंधन और पीएमआई के लिए अन्य ढांचे के साथ काम करने की आवश्यकता को पहचाना।[6] पिछले संस्करण (डीएसडीएम 4.2) में केवल चरम कार्यक्रम के साथ डीएसडीएम का उपयोग करने के बारे में मार्गदर्शन शामिल था।
डीएसडीएम का इतिहास
1990 के दशक की शुरुआत में, तीव्र अनुप्रयोग विकास (आरएडी) पूरे आईटी उद्योग में फैल रहा था। सॉफ़्टवेयर अनुप्रयोगों के लिए उपयोगकर्ता इंटरफ़ेस पुरानी हरी स्क्रीन से ग्राफ़िकल उपयोगकर्ता इंटरफ़ेस की ओर बढ़ रहे थे जो आज उपयोग किए जाते हैं। बाज़ार में नए एप्लिकेशन डेवलपमेंट टूल आ रहे थे, जैसे पॉवरबिल्डर। इनसे डेवलपर्स को अपने प्रस्तावित समाधानों को अपने ग्राहकों के साथ अधिक आसानी से साझा करने में सक्षम बनाया गया - प्रोटोटाइप एक वास्तविकता बन गया और शास्त्रीय, अनुक्रमिक (झरना मॉडल ) विकास विधियों की निराशा को एक तरफ रखा जा सका।
हालाँकि, आरएडी आंदोलन बहुत असंरचित था: उपयुक्त प्रक्रिया की कोई आम सहमति वाली परिभाषा नहीं थी और कई संगठन अपनी परिभाषा और दृष्टिकोण के साथ आए थे। कई प्रमुख निगम संभावनाओं में बहुत रुचि रखते थे, लेकिन वे इस बात से भी चिंतित थे कि वे अंतिम डिलिवरेबल्स में गुणवत्ता के स्तर को न खो दें, जिससे मुक्त-प्रवाह विकास को बढ़ावा मिल सकता है।
डीएसडीएम कंसोर्टियम की स्थापना 1994 में सॉफ्टवेयर इंजीनियरिंग के क्षेत्र में विक्रेताओं और विशेषज्ञों के एक संघ द्वारा की गई थी और उनके सर्वोत्तम अभ्यास अनुभवों को मिलाकर एक स्वतंत्र आरएडी ढांचे को संयुक्त रूप से विकसित करने और बढ़ावा देने के उद्देश्य से बनाया गया था। इसकी शुरुआत लंदन में बटलर ग्रुप द्वारा आयोजित एक कार्यक्रम से हुई। उस बैठक में सभी लोग ब्लू चिप (शेयर बाजार) |ब्लू-चिप संगठनों जैसे ब्रिटिश एयरवेज, अमेरिकन एक्सप्रेस, ओरेकल और लॉजिका (डेटा साइंसेज और एलाइड डोमेक जैसी अन्य कंपनियों को तब से अन्य संगठनों द्वारा अवशोषित कर लिया गया है) के लिए काम करते थे।
जुलाई 2006 में, डीएसडीएम सार्वजनिक संस्करण 4.2[7] व्यक्तियों को देखने और उपयोग करने के लिए उपलब्ध कराया गया था; हालाँकि, डीएसडीएम को दोबारा बेचने वाले किसी भी व्यक्ति को अभी भी गैर-लाभकारी संघ का सदस्य होना चाहिए।
2014 में, डीएसडीएम हैंडबुक ऑनलाइन और सार्वजनिक उपलब्ध कराई गई थी।[8] इसके अतिरिक्त, डीएसडीएम के लिए टेम्पलेट डाउनलोड किए जा सकते हैं।[9] अक्टूबर 2016 में डीएसडीएम कंसोर्टियम को एजाइल बिजनेस कंसोर्टियम (एबीसी) के रूप में पुनः ब्रांडेड किया गया।[10] एजाइल बिजनेस कंसोर्टियम एक गैर-लाभकारी, विक्रेता-स्वतंत्र संगठन है जो डीएसडीएम ढांचे का मालिक है और उसका प्रबंधन करता है।[11]
डीएसडीएम
डीएसडीएम एक विक्रेता-स्वतंत्र दृष्टिकोण है जो मानता है कि प्रौद्योगिकी की तुलना में लोगों की समस्याओं के कारण अधिक परियोजनाएं विफल हो जाती हैं। डीएसडीएम का ध्यान व्यावसायिक लक्ष्यों को प्राप्त करने के लिए लोगों को एक साथ प्रभावी ढंग से काम करने में मदद करने पर है। डीएसडीएम उपकरणों और तकनीकों से भी स्वतंत्र है, जो व्यवसाय को किसी विशेष विक्रेता से जोड़े बिना किसी भी व्यावसायिक और तकनीकी वातावरण में उपयोग करने में सक्षम बनाता है।[8]
सिद्धांत
डीएसडीएम को रेखांकित करने वाले आठ सिद्धांत हैं।[12] ये सिद्धांत टीम को उस रवैये के बारे में निर्देशित करते हैं जो उन्हें अपनाना चाहिए और जिस मानसिकता को उन्हें लगातार अच्छा प्रदर्शन करने के लिए अपनाना चाहिए।
- बिजनेस की जरूरत पर ध्यान दें
- समय पर पहुंचाएं
- सहयोग करें
- गुणवत्ता से कभी समझौता न करें
- दृढ़ नींव से क्रमिक रूप से निर्माण करें
- पुनरावृत्तीय रूप से विकास करें
- लगातार और स्पष्ट रूप से संवाद करें
- नियंत्रण प्रदर्शित करें
मुख्य तकनीकें
- टाइमबॉक्सिंग: प्रोजेक्ट को भागों में विभाजित करके, प्रत्येक को एक निश्चित बजट और डिलीवरी की तारीख के साथ, क्रमिक रूप से पूरा करने का दृष्टिकोण है। प्रत्येक भाग के लिए कई आवश्यकताओं को प्राथमिकता दी जाती है और चुना जाता है। चूँकि समय और बजट निश्चित हैं, केवल शेष चर आवश्यकताएँ हैं। इसलिए यदि किसी परियोजना में समय या धन की कमी हो रही है तो सबसे कम प्राथमिकता वाली आवश्यकताओं को छोड़ दिया जाता है। इसका मतलब यह नहीं है कि एक अधूरा उत्पाद वितरित किया जाता है, क्योंकि पेरेटो सिद्धांत के अनुसार परियोजना का 80% हिस्सा सिस्टम आवश्यकताओं के 20% से आता है, इसलिए जब तक सिस्टम में उन सबसे महत्वपूर्ण 20% आवश्यकताओं को लागू किया जाता है, तब तक सिस्टम इसलिए यह व्यावसायिक आवश्यकताओं को पूरा करता है और कोई भी सिस्टम पहली कोशिश में पूरी तरह से तैयार नहीं होता है।
- MoSCoW विधि: कार्य वस्तुओं या आवश्यकताओं को प्राथमिकता देने की एक तकनीक है। यह एक संक्षिप्त शब्द है जिसका अर्थ है:
- होना आवश्यक है
- होना चाहिए
- हो सकता था
- नहीं होगा
- प्रोटोटाइपिंग: परियोजना के प्रारंभिक चरण में विकास के तहत सिस्टम के प्रोटोटाइप के निर्माण को संदर्भित करता है। यह सिस्टम में कमियों का शीघ्र पता लगाने में सक्षम बनाता है और भविष्य के उपयोगकर्ताओं को सिस्टम को 'टेस्ट-ड्राइव' करने की अनुमति देता है। इस तरह अच्छी उपयोगकर्ता भागीदारी का एहसास होता है, जो डीएसडीएम या उस मामले के लिए किसी भी सिस्टम विकास परियोजना के प्रमुख सफलता कारकों में से एक है।
- परीक्षण: अच्छी गुणवत्ता का समाधान सुनिश्चित करने में मदद करता है, डीएसडीएम प्रत्येक पुनरावृत्ति के दौरान परीक्षण की वकालत करता है। चूंकि डीएसडीएम एक उपकरण और तकनीक स्वतंत्र विधि है, इसलिए प्रोजेक्ट टीम अपनी स्वयं की परीक्षण प्रबंधन विधि चुनने के लिए स्वतंत्र है।
- कार्यशाला: आवश्यकताओं, कार्यात्मकताओं और आपसी समझ पर चर्चा करने के लिए परियोजना हितधारकों को एक साथ लाती है।
- सिस्टम मॉडलिंग: एक व्यावसायिक डोमेन की कल्पना करने और समझ में सुधार करने में मदद करता है। विकसित किए जा रहे सिस्टम या व्यावसायिक क्षेत्र के विशिष्ट पहलुओं का एक आरेखीय प्रतिनिधित्व तैयार करता है।
- कॉन्फ़िगरेशन प्रबंधन: एक ही समय में विकास के तहत कई डिलिवरेबल्स और प्रत्येक टाइम-बॉक्स के अंत में वृद्धिशील रूप से वितरित किए जाने के साथ, डिलिवरेबल्स को पूरा होने की दिशा में अच्छी तरह से प्रबंधित करने की आवश्यकता होती है।
भूमिकाएँ
डीएसडीएम परिवेश में कुछ भूमिकाएँ प्रस्तुत की गई हैं। यह महत्वपूर्ण है कि परियोजना शुरू करने से पहले परियोजना सदस्यों को विभिन्न भूमिकाओं में नियुक्त किया जाना चाहिए। प्रत्येक भूमिका की अपनी जिम्मेदारी होती है। भूमिकाएँ हैं:
- कार्यकारी प्रायोजक: तथाकथित प्रोजेक्ट चैंपियन। उपयोगकर्ता संगठन की एक महत्वपूर्ण भूमिका जिसके पास उचित धन और संसाधन देने की क्षमता और जिम्मेदारी है। इस भूमिका में निर्णय लेने की परम शक्ति होती है।
- दूरदर्शी: वह जिसके पास यह सुनिश्चित करके परियोजना को आरंभ करने की जिम्मेदारी है कि आवश्यक आवश्यकताओं को शीघ्र पूरा किया जाए। दूरदर्शी के पास सिस्टम और परियोजना के व्यावसायिक उद्देश्यों की सबसे सटीक धारणा होती है। एक अन्य कार्य विकास प्रक्रिया की निगरानी करना और उसे सही रास्ते पर रखना है।
- राजदूत उपयोगकर्ता: परियोजना में उपयोगकर्ता समुदाय का ज्ञान लाता है, यह सुनिश्चित करता है कि डेवलपर्स को विकास प्रक्रिया के दौरान पर्याप्त उपयोगकर्ता प्रतिक्रिया प्राप्त हो।
- सलाहकार उपयोगकर्ता: कोई भी उपयोगकर्ता हो सकता है जो एक महत्वपूर्ण दृष्टिकोण का प्रतिनिधित्व करता है और परियोजना का दैनिक ज्ञान लाता है।
- परियोजना प्रबंधक: उपयोगकर्ता समुदाय या आईटी स्टाफ में से कोई भी हो सकता है जो सामान्य रूप से परियोजना का प्रबंधन करता है।
- तकनीकी समन्वयक: सिस्टम आर्किटेक्चर को डिजाइन करने और परियोजना की तकनीकी गुणवत्ता को नियंत्रित करने के लिए जिम्मेदार।
- टीम लीडर: अपनी टीम का नेतृत्व करता है और यह सुनिश्चित करता है कि टीम समग्र रूप से प्रभावी ढंग से काम करे।
- समाधान डेवलपर: सिस्टम आवश्यकताओं की व्याख्या करें और वितरण योग्य कोड विकसित करने और प्रोटोटाइप बनाने सहित इसे मॉडल करें।
- समाधान परीक्षक: कुछ परीक्षण करके तकनीकी सीमा तक शुद्धता की जांच करता है, जहां आवश्यक हो वहां दोष उठाता है और एक बार ठीक हो जाने पर दोबारा परीक्षण करता है। परीक्षक को कुछ टिप्पणी और दस्तावेज़ उपलब्ध कराने होंगे.
- लेखक: प्रत्येक कार्यशाला में की गई आवश्यकताओं, समझौतों और निर्णयों को इकट्ठा करने और रिकॉर्ड करने के लिए जिम्मेदार।
- फैसिलिटेटर: कार्यशालाओं की प्रगति के प्रबंधन के लिए जिम्मेदार, एक प्रेरक के रूप में कार्य करता है तैयारी और संचार के लिए.
- विशेषज्ञ भूमिकाएँ: बिजनेस आर्किटेक्ट, गुणवत्ता प्रबंधक, सिस्टम इंटीग्रेटर, आदि।
महत्वपूर्ण सफलता कारक
डीएसडीएम के भीतर कई कारकों की पहचान की गई है जो सफल परियोजनाओं को सुनिश्चित करने के लिए बहुत महत्वपूर्ण हैं।
- कारक 1: सबसे पहले वरिष्ठ प्रबंधन और अन्य कर्मचारियों द्वारा डीएसडीएम की स्वीकृति है। यह सुनिश्चित करता है कि प्रोजेक्ट के विभिन्न कलाकार शुरू से ही प्रेरित हों और पूरे प्रोजेक्ट में शामिल रहें।
- कारक 2: सीधे कारक 1 से प्राप्त: अंतिम-उपयोगकर्ता की भागीदारी सुनिश्चित करने के लिए प्रबंधन की प्रतिबद्धता। प्रोटोटाइपिंग दृष्टिकोण को कार्यात्मक प्रोटोटाइप का परीक्षण और मूल्यांकन करने के लिए अंतिम उपयोगकर्ताओं द्वारा एक मजबूत और समर्पित भागीदारी की आवश्यकता होती है।
- कारक 3: प्रोजेक्ट टीम में कुशल सदस्य शामिल होने चाहिए जो एक स्थिर संघ बनाते हैं। एक महत्वपूर्ण मुद्दा प्रोजेक्ट टीम का सशक्तिकरण है। इसका मतलब यह है कि टीम (या उसके एक या अधिक सदस्यों) के पास उच्च प्रबंधन को औपचारिक प्रस्ताव लिखे बिना परियोजना के संबंध में महत्वपूर्ण निर्णय लेने की शक्ति और संभावना होनी चाहिए, जो बहुत समय लेने वाली हो सकती है। प्रोजेक्ट टीम को एक सफल प्रोजेक्ट चलाने में सक्षम बनाने के लिए, उन्हें प्रोजेक्ट को संचालित करने के लिए उपयुक्त तकनीक की भी आवश्यकता होती है। इसका मतलब है एक विकास वातावरण, परियोजना प्रबंधन उपकरण इत्यादि।
- कारक 4: अंत में, डीएसडीएम यह भी बताता है कि ग्राहक और विक्रेता के बीच एक सहायक संबंध आवश्यक है। यह उन दोनों परियोजनाओं पर लागू होता है जो कंपनियों के भीतर आंतरिक रूप से या बाहरी ठेकेदारों द्वारा साकार की जाती हैं। सहायक संबंध सुनिश्चित करने में सहायता वगैरह हो सकती है।
अन्य विकास ढाँचों की तुलना
डीएसडीएम को पुनरावृत्त और वृद्धिशील विकास ढांचे की एक विस्तृत श्रृंखला का हिस्सा माना जा सकता है, विशेष रूप से एजाइल सॉफ्टवेयर विकास और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट-ओरिएंटेड तरीकों का समर्थन करने वाले। इनमें स्क्रम (सॉफ़्टवेयर विकास) , एक्सट्रीम प्रोग्रामिंग|एक्सट्रीम प्रोग्रामिंग (एक्सपी), अनुशासित एजाइल डिलीवरी|अनुशासित एजाइल डिलीवरी (डीएडी), और रैशनल यूनीफाइड प्रोसेस |रेशनल यूनिफाइड प्रोसेस (आरयूपी) शामिल हैं (लेकिन इन्हीं तक सीमित नहीं हैं)।
डीएसडीएम की तरह, इनमें निम्नलिखित विशेषताएं हैं:
- वे सभी आवश्यकताओं को प्राथमिकता देते हैं और उनके अनुसार क्रमिक रूप से काम करते हैं, एक सिस्टम या उत्पाद का निर्माण करते हैं।
- वे उपकरण-स्वतंत्र ढाँचे हैं। यह उपयोगकर्ताओं को प्रक्रिया के विशिष्ट चरणों को अपनी तकनीकों से भरने की अनुमति देता है[5]और पसंद की सॉफ़्टवेयर सहायता।
- विकास में चर समय/संसाधन नहीं, बल्कि आवश्यकताएं हैं। यह दृष्टिकोण डीएसडीएम के मुख्य लक्ष्यों को सुनिश्चित करता है, अर्थात् समय सीमा और बजट के भीतर रहना।
- सिस्टम में सभी हितधारकों के बीच संचार और उनकी भागीदारी पर एक मजबूत फोकस। यद्यपि इसे अन्य तरीकों से संबोधित किया जाता है, डीएसडीएम एक सफल परिणाम सुनिश्चित करने के लिए परियोजना के प्रति प्रतिबद्धता में दृढ़ता से विश्वास करता है।
यह भी देखें
- लीन सॉफ्टवेयर विकास
- चंचल सॉफ्टवेयर विकास
संदर्भ
- ↑ Keith Richards, Agile project management: running PRINCE2 projects with DSDM Atern. OGC – Office of Government Commerce. The Stationery Office, 31 jul. 2007.
- ↑ Plonka, Laura, et al. "UX Design in Agile: A DSDM Case Study." Agile Processes in Software Engineering and Extreme Programming. Springer International Publishing, 2014. 1-15.
- ↑ Abrahamsson, Pekka, et al. "New directions on agile methods: a comparative analysis." Software Engineering, 2003. Proceedings. 25th International Conference on. Ieee, 2003.
- ↑ Stapleton, Jennifer (January 2003). व्यवसाय केंद्रित विकास. Pearson Education. p. 113. ISBN 9780321112248.
- ↑ 5.0 5.1 Moran, Alan (March 2015). चंचल प्रबंधन. Springer. pp. 21–24. ISBN 9783319162614.
- ↑ The DSDM Agile Project Framework manual, 2014 pages 4, 16
- ↑ (www.dsdm.org Archived 2016-10-02 at the Wayback Machine)
- ↑ 8.0 8.1 "The DSDM Agile Project Framework (2014 Onwards)". Agile Business Consortium. February 4, 2016.
- ↑ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set.
{{cite web}}: Missing or empty|title=(help) - ↑ "एजाइल का डीएसडीएम कंसोर्टियम एजाइल बिजनेस कंसोर्टियम में विकसित हुआ है". Press Dispensary.
- ↑ "सामुदायिक सदस्यता के नियम और शर्तें" (PDF). DSDM Consortium. Retrieved 7 March 2013.
- ↑ Agile Business Consortium. The DSDM Agile Project Framework (2014 Onwards) Handbook - Principles.
अग्रिम पठन
- Coleman and Verbruggen: A quality software process for rapid application development, Software Quality Journal 7, p. 107-1222 (1998)
- Beynon-Davies and Williams: The diffusion of information systems development methods, Journal of Strategic Information Systems 12 p. 29-46 (2003)
- Sjaak Brinkkemper, Saeki and Harmsen: Assembly Techniques for Method Engineering, Advanced Information Systems Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
- Abrahamsson, Salo, Ronkainen, Warsta Agile Software Development Methods: Review and Analysis, VTT Publications 478, p. 61-68 (2002)
- Tuffs, Stapleton, West, Eason: Inter-operability of DSDM with the Rational Unified Process, DSDM Consortium, Issue 1, p. 1-29 (1999)
- Rietmann: DSDM in a bird’s eye view, DSDM Consortium, p. 3-8 (2001)
- Chris Barry, Kieran Conboy, Michael Lang, Gregory Wojtkowski and Wita Wojtkowski: Information Systems Development: Challenges in Practice, Theory, and Education, Volume 1
- Keith Richards: Agile Project Management: running PRINCE2 projects with DSDM Atern, TSO (2007)
- The DSDM Agile Project Framework (2014)
- DSDM Agile Project Management Framework (v6, 2014) interactive mind map
बाहरी संबंध
