फीचर-ड्रिवेन डेवलपमेंट: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|Software development process}} | {{short description|Software development process}} | ||
{{Software development process}} | {{Software development process}} | ||
'''फीचर-ड्रिवेन डेवलपमेंट'''{{ref|Palmer}} (एफडीडी) एक [[पुनरावृत्तीय और वृद्धिशील विकास|इटरेटिव और इन्क्रीमेंटल]] सॉफ़्टवेयर डेवलपमेंट प्रक्रिया है, और इसके अतिरिक्त यह [[सॉफ्टवेयर]] विकसित करने के लिए एक लाइटवेट और एजाइल विधि है। एफडीडी कई उद्योग-मान्यता प्राप्त सर्वोत्तम प्रथाओं को एक समग्र में मिश्रित करता है। ये प्रथाएँ क्लाइंट-मूल्यवान कार्यक्षमता (सुविधा) परिप्रेक्ष्य से ड्रिवेन होती हैं। इसका मुख्य उद्देश्य [[द एजाइल मेनिफेस्टो]] के पीछे के सिद्धांतों के अनुसार समयबद्ध विधि से बार-बार टेनजीबल, कार्यशील सॉफ़्टवेयर वितरित करना है।<ref>{{cite web | |||
|url= http://agilemanifesto.org/principles.html | |url= http://agilemanifesto.org/principles.html | ||
|title= Principles behind the Agile Manifesto | |title= Principles behind the Agile Manifesto | ||
|date=2019-06-11 | |date=2019-06-11 | ||
}}</ref> | }}</ref> | ||
== इतिहास == | == इतिहास == | ||
एफडीडी को | एफडीडी को प्रारंभ में जेफ डी लुका द्वारा 1997 में एक बड़े [[सिंगापुर]] बैंक में 15 महीने, 50-व्यक्ति सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट की विशिष्ट जरूरतों को पूरा करने के लिए तैयार किया गया था। इसके परिणामस्वरूप पांच प्रक्रियाओं का एक समूह तैयार किया जाता है, जिसमें एक ओवरऑल मॉडल का डेवलपमेंट और फ़ीचर्स की लिस्ट, योजना, डिज़ाइन और निर्माण सम्मलित होता है। पहली प्रक्रिया [[पीटर कॉड]] के [[वस्तु उन्मुख डिजाइन]] के दृष्टिकोण से अधिक प्रभावित है। दूसरी प्रक्रिया में कार्यात्मक आवश्यकताओं और डेवलपमेंट कार्यों को प्रबंधित करने के लिए फीचर लिस्ट का उपयोग करने के कॉड के विचार सम्मलित हैं। अन्य प्रक्रियाएँ जेफ डी लुका के अनुभव का परिणाम हैं। सिंगापुर प्रोजेक्ट में इसके सफल प्रयोग के पश्चात से एफडीडी के कई इम्प्लीमेंटेशन हुए हैं। | ||
एफडीडी का विवरण पहली बार यूएमएल के साथ कलर में जावा मॉडलिंग पुस्तक के अध्याय 6 में दुनिया के सामने | एफडीडी का विवरण पहली बार 1999 में पीटर कॉड, [[एरिक लेफेब्रे]] और जेफ डी लुका द्वारा यूएमएल{{ref|Coad}} के साथ कलर में जावा मॉडलिंग पुस्तक के अध्याय 6 में दुनिया के सामने प्रस्तुत किया गया था। इसके पश्चात में, स्टीफन पामर और [[मैक फेल्सिंग]] की पुस्तक ए प्रैक्टिकल गाइड टू फीचर-ड्रिवेन डेवलपमेंट{{ref|Palmer}} (2002 में प्रकाशित) में, एफडीडी का अधिक सामान्य विवरण जावा मॉडलिंग से भिन्न करके दिया गया था। | ||
== | == ओवरव्यू == | ||
एफडीडी एक मॉडल- | एफडीडी एक मॉडल-ड्रिवेन शार्ट-इटरेशन प्रक्रिया है जिसमें पांच बुनियादी गतिविधियां सम्मलित हैं। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट पर नज़र रखने के लिए, फ़ीचर ड्राईवेन डेवलपमेंट माइलस्टोन जो प्रत्येक फ़ीचर पर की गई प्रगति को चिह्नित करते हैं, जो परिभाषित किए गए हैं। यह अनुभाग गतिविधियों का उच्च स्तरीय ओवरव्यू देता है। दाईं ओर के चित्र में, इन गतिविधियों के लिए [[मेटा-प्रोसेस मॉडलिंग]] को प्रदर्शित किया गया है। पहली दो अनुक्रमिक गतिविधियों के समय, एक ओवरऑल मॉडल की बनावट को स्थापित किया जाता है। अंतिम तीन गतिविधियाँ प्रत्येक सुविधा के लिए इटरेशन हैं। | ||
[[Image:Fdd process diagram.png|thumb|250px|एफडीडी के लिए प्रक्रिया मॉडल]] | [[Image:Fdd process diagram.png|thumb|250px|एफडीडी के लिए प्रक्रिया मॉडल]] | ||
=== | === ओवरऑल मॉडल विकसित करें === | ||
एफडीडी | एफडीडी प्रोजेक्ट सिस्टम के दायरे और उसके संदर्भ के उच्च-स्तरीय [[सॉफ्टवेयर वॉकथ्रू]] के साथ प्रारंभ होती है। इसके पश्चात, छोटे समूहों द्वारा प्रत्येक मॉडलिंग एरिया के लिए विस्तृत डोमेन मॉडल बनाए जाते हैं और [[सहकर्मी समीक्षा]] के लिए प्रस्तुत किए जाते हैं। प्रत्येक डोमेन एरिया के मॉडल बनाने के लिए एक या अधिक प्रस्तावित मॉडल का चयन किया जाता है। डोमेन एरिया मॉडल को धीरे-धीरे एक ओवरऑल मॉडल में विलय कर दिया जाता है। | ||
=== फीचर | === फीचर लिस्ट बनाएं === | ||
प्रारंभिक मॉडलिंग के | प्रारंभिक मॉडलिंग के समय एकत्र किए गए ज्ञान का उपयोग डोमेन को सब्जैक्ट एरिया में कार्यात्मक रूप से विघटित करके फ़ीचर्स लिस्ट की पहचान करने के लिए किया जाता है। प्रत्येक सब्जैक्ट एरिया में व्यावसायिक गतिविधियाँ सम्मलित होती हैं, और प्रत्येक व्यावसायिक गतिविधि के चरण एक वर्गीकृत फीचर लिस्ट का आधार बनते हैं। इस संबंध में विशेषताएं "<एक्शन> <रिजल्ट> <ऑब्जेक्ट>" के रूप में व्यक्त किए गए क्लाइंट-मूल्यवान कार्यों के छोटे टुकड़े हैं, उदाहरण के लिए: 'बिक्री की कुल गणना करें' या 'उपयोगकर्ता के पासवर्ड को मान्य करें' सुविधाओं को पूरा होने में दो सप्ताह से अधिक नहीं लगना चाहिए, अन्यथा उन्हें छोटे टुकड़ों में तोड़ दिया जाता है। | ||
=== | === फीचर के अनुसार योजना बनाएं === | ||
फीचर | इसी प्रकार फीचर लिस्ट पूरी होने के पश्चात, अगला चरण डेवलपमेंट योजना तैयार करना और [[प्रोग्रामर]] को क्लास (कंप्यूटर विज्ञान) के रूप में फ़ीचर्स (या फीचर समूह) का स्वामित्व सौंपना है। | ||
=== फीचर द्वारा डिजाइन === | === फीचर द्वारा डिजाइन === | ||
प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर | प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर फ़ीचर्स के एक छोटे समूह का चयन करता है जिन्हें दो सप्ताह के भीतर विकसित किया जाना होता है। संबंधित वर्ग के ओनर्स के साथ मिलकर, मुख्य प्रोग्रामर प्रत्येक सुविधा के लिए विस्तृत [[अनुक्रम आरेख]] तैयार करता है और ओवरऑल मॉडल को परिष्कृत करता है। इसके पश्चात, क्लास और विधि प्रस्तावनाएं लिखी जाती हैं और अंत में एक [[सॉफ्टवेयर निरीक्षण]] आयोजित किया जाता है। | ||
=== फीचर द्वारा निर्मित === | === फीचर द्वारा निर्मित === | ||
प्रत्येक गतिविधि के लिए एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के | प्रत्येक गतिविधि के लिए तथा एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के पश्चात, क्लास के ओनर अपनी क्लासेस के लिए कोड विकसित करते हैं। इकाई परीक्षण और सफल कोड समीक्षा के पश्चात, पूर्ण सुविधा को मुख्य बिल्ड में पदोन्नत किया जाता है। | ||
== | == माइल्सटोन्स == | ||
चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। | चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट पर नज़र रखने के लिए, प्रत्येक सुविधा पर हुई प्रगति को चिह्नित करना महत्वपूर्ण है। इसलिए एफडीडी प्रति फीचर छह माइल्सटोन्स को परिभाषित करता है जिन्हें क्रमिक रूप से पूरा किया जाना है। पहले तीन माइल्सटोन्स डिजाइन बाय फीचर गतिविधि के समय पूरे होते हैं, और अंतिम तीन माइल्सटोन्स बिल्ड बाय फीचर गतिविधि के समय पूरे होते हैं। प्रगति को ट्रैक करने के लिए, प्रत्येक माइल्सटोन्स को पूर्ण प्रतिशत आवंटित किया जाता है। नीचे दी गई तालिका में माइल्सटोन्स और उनके पूरा होने का प्रतिशत दिखाया गया है। जिस बिंदु पर कोडिंग प्रारंभ होती है, (डोमेन वॉकथ्रू 1%, डिज़ाइन 40% और डिज़ाइन निरीक्षण 3% = 44%) एक सुविधा पहले से ही 44% पूर्ण होती है। | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ Table 1: | |+ Table 1: माइल्सटोन्स | ||
! | | ! | डोमेन वॉकथ्रू | ||
! | | ! | डिज़ाइन | ||
! | | ! | डिज़ाइन निरीक्षण | ||
! | | ! | कोड | ||
! | | ! | कोड निरीक्षण | ||
! | | ! | निर्माण के लिए प्रचार | ||
|- | |- | ||
| | 1% | | | 1% | ||
| Line 60: | Line 58: | ||
| | 1% | | | 1% | ||
|} | |} | ||
== सर्वोत्तम अभ्यास == | == सर्वोत्तम अभ्यास == | ||
फ़ीचर | फ़ीचर ड्राईवेन डेवलपमेंट क्लाइंट-मूल्यवान फ़ीचर परिप्रेक्ष्य के उद्देश्य से [[सॉफ्टवेयर इंजीनियरिंग]] सर्वोत्तम प्रथाओं के मुख्य समूह पर बनाया गया है। | ||
* डोमेन ऑब्जेक्ट | * '''डोमेन ऑब्जेक्ट मॉडलिंग-''' डोमेन ऑब्जेक्ट मॉडलिंग में समाधान की जाने वाली समस्या के डोमेन की खोज और व्याख्या करना सम्मलित है। परिणामी डोमेन ऑब्जेक्ट मॉडल फ़ीचर्स को जोड़ने के लिए एक ओवरऑल रूपरेखा प्रदान करता है। | ||
* फ़ीचर द्वारा | * '''फ़ीचर द्वारा डेवलपमेंट करना-''' कोई भी फ़ंक्शन जो दो सप्ताह के भीतर कार्यान्वित करने के लिए बहुत जटिल है, उसे तब तक छोटे कार्यों में विघटित किया जाता है जब तक कि प्रत्येक उप-समस्या इतनी छोटी न हो जाए कि उसे फीचर कहा जा सके, इससे सही कार्य प्रदान करना और सिस्टम का विस्तार या संशोधन करना सरल हो जाता है। | ||
* व्यक्तिगत वर्ग (कोड) | * '''व्यक्तिगत वर्ग (कोड) स्वामित्व-''' व्यक्तिगत वर्ग स्वामित्व का अर्थ है कि कोड के भिन्न-भिन्न टुकड़े या समूह एक ही ओनर को सौंपे जाते हैं। ओनर क्लास की स्थिरता, प्रदर्शन और वैचारिक अखंडता के लिए जिम्मेदार है। | ||
* फ़ीचर | * '''फ़ीचर टीमें-''' फ़ीचर टीम एक छोटी, गतिशील रूप से बनाई गई टीम है जो एक छोटी गतिविधि विकसित करती है। प्रत्येक डिज़ाइन निर्णय पर सरल लेकिन कई दिमाग लगाए जाते हैं, और किसी एक को चुनने से पहले कई डिज़ाइन विकल्पों का मूल्यांकन किया जाता है। | ||
* निरीक्षण | * '''निरीक्षण-''' सॉफ़्टवेयर निरीक्षण मुख्य रूप से दोषों का पता लगाकर अच्छी गुणवत्ता वाले डिज़ाइन और कोड को सुनिश्चित करने के लिए किया जाता है। | ||
* विन्यास | * '''विन्यास प्रबंधन-''' कॉन्फ़िगरेशन प्रबंधन उन सभी फ़ीचर्स के लिए स्रोत कोड की पहचान करने में सहायता करता है जो आज तक पूरी हो चुकी हैं और क्लासेस में परिवर्तनों का इतिहास बनाए रखने में सहायता करती है क्योंकि फीचर टीमें उन्हें बढ़ाती हैं। | ||
* नियमित | * '''नियमित निर्माण-''' नियमित निर्माण यह सुनिश्चित करता है कि सरल एक अद्यतित सिस्टम हो जिसे क्लाइंट को दिखाया जा सके और फ़ीचर्स के लिए स्रोत कोड की एकीकरण त्रुटियों को शीघ्रता से उजागर करने में सहायता मिलती है। | ||
*प्रगति और परिणाम की दृश्यता | *'''प्रगति और परिणाम की दृश्यता-''' प्रबंधक पूर्ण कार्य के आधार पर प्रोजेक्ट के अंदर और बाहर सभी स्तरों से लगातार, उचित और उपयुक्त प्रगति रिपोर्टिंग का उपयोग करके एक प्रोजेक्ट का संचालन करते हैं। | ||
== | == मेटामॉडल (मेटामॉडलिंग) == | ||
[[Image:Fdd process data diagram.png|thumb|150px|एफडीडी के लिए प्रक्रिया-डेटा मॉडल]][[मेटामॉडलिंग]] एक [[विधि (सॉफ़्टवेयर इंजीनियरिंग)]] की प्रक्रियाओं और डेटा दोनों को देखने में | [[Image:Fdd process data diagram.png|thumb|150px|एफडीडी के लिए प्रक्रिया-डेटा मॉडल]][[मेटामॉडलिंग]] एक [[विधि (सॉफ़्टवेयर इंजीनियरिंग)]] की प्रक्रियाओं और डेटा दोनों को देखने में सहायता करता है। इससे विधियों की तुलना की जा सकती है, और [[विधि इंजीनियरिंग]] प्रक्रिया में विधि के टुकड़ों का सरलता से पुन: उपयोग किया जा सकता है। इस तकनीक का उपयोग [[एकीकृत मॉडलिंग भाषा]] मानकों के अनुरूप है। | ||
मेटाडेटा मॉडल का बायाँ भाग | मेटाडेटा मॉडल का बायाँ भाग एफडीडी का उपयोग करके सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट में सम्मलित पाँच बुनियादी गतिविधियों को दर्शाता है। सभी गतिविधियों में उप-गतिविधियाँ सम्मलित हैं जो एफडीडी प्रक्रिया विवरण में उप-गतिविधियों के अनुरूप हैं। मॉडल का दाहिना भाग इसमें सम्मलित अवधारणाओं को दर्शाता है। ये अवधारणाएँ आरेख के बाईं ओर दर्शाई गई गतिविधियों से उत्पन्न हुई हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
* | * एजाइल सॉफ्टवेयर डेवलपमेंट | ||
*[[व्यवहार आधारित विकास]] | *[[व्यवहार आधारित विकास|व्यवहार आधारित डेवलपमेंट]] | ||
* [[परियोजना जीवनचक्र]] | * [[परियोजना जीवनचक्र|प्रोजेक्ट जीवनचक्र]] | ||
* [[सॉफ़्टवेयर वास्तुशिल्प]] | * [[सॉफ़्टवेयर वास्तुशिल्प]] | ||
* सॉफ्टवेयर | * सॉफ्टवेयर डेवलपमेंट प्रक्रिया | ||
* सॉफ्टवेयर इंजीनियरिंग | * सॉफ्टवेयर इंजीनियरिंग | ||
| Line 98: | Line 95: | ||
* [http://www.featuredrivendevelopment.com/ Feature Driven Development Community] | * [http://www.featuredrivendevelopment.com/ Feature Driven Development Community] | ||
* {{dmoz|Computers/Programming/Methodologies/Agile/Feature_Driven_Development}} | * {{dmoz|Computers/Programming/Methodologies/Agile/Feature_Driven_Development}} | ||
* [http://www.nebulon.com/fdd/index.html Nebulon | * [http://www.nebulon.com/fdd/index.html Nebulon एफडीडी Page] - Nebulon is the consulting practice of Jeff De Luca | ||
* [http://www.sitepoint.com/article/successful-development Successful Web Development Methodologies] - Use of | * [http://www.sitepoint.com/article/successful-development Successful Web Development Methodologies] - Use of एफडीडी for Web Development projects | ||
* [http://www.methodsandtools.com/archive/archive.php?id=19 Delivering Real Business Value using Feature Driven Development] - Article gives basic overview of | * [http://www.methodsandtools.com/archive/archive.php?id=19 Delivering Real Business Value using Feature Driven Development] - Article gives basic overview of एफडीडी | ||
* [http://www.agilemodeling.com/essays/fdd.htm | * [http://www.agilemodeling.com/essays/fdd.htm एफडीडी and Agile modelling] | ||
* [https://web.archive.org/web/20071102073447/http://www.bettersoftwarefaster.com/index.htm Better Software Faster] - Another book in the Coad Series referencing Feature Driven Development. Authors Andy Carmichael and Dan Haywood {{ISBN|0-13-008752-1}} | * [https://web.archive.org/web/20071102073447/http://www.bettersoftwarefaster.com/index.htm Better Software Faster] - Another book in the Coad Series referencing Feature Driven Development. Authors Andy Carmichael and Dan Haywood {{ISBN|0-13-008752-1}} | ||
* [http://www.se-radio.net/2008/01/episode-83-jeff-deluca-on-feature-driven-development/ Interview with | * [http://www.se-radio.net/2008/01/episode-83-jeff-deluca-on-feature-driven-development/ Interview with एफडीडी-Creator Jeff DeLuca] (Podcast) | ||
{{Software engineering}} | {{Software engineering}} | ||
[[Category: | [[Category:Articles with Curlie links]] | ||
[[Category:Collapse templates]] | |||
[[Category:Created On 23/06/2023]] | [[Category:Created On 23/06/2023]] | ||
[[Category:Lua-based templates]] | |||
[[Category:Machine Translated Page]] | |||
[[Category:Navigational boxes| ]] | |||
[[Category:Navigational boxes without horizontal lists]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Sidebars with styles needing conversion]] | |||
[[Category:Template documentation pages|Documentation/doc]] | |||
[[Category:Templates Translated in Hindi]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:Templates generating microformats]] | |||
[[Category:Templates that add a tracking category]] | |||
[[Category:Templates that are not mobile friendly]] | |||
[[Category:Templates that generate short descriptions]] | |||
[[Category:Templates using TemplateData]] | |||
[[Category:Wikipedia metatemplates]] | |||
[[Category:चुस्त सॉफ्टवेयर विकास]] | |||
[[Category:सॉफ्टवेयर परियोजना प्रबंधन]] | |||
[[Category:सॉफ्टवेयर सुविधाएँ]] | |||
Latest revision as of 07:03, 16 July 2023
| Part of a series on |
| Software development |
|---|
फीचर-ड्रिवेन डेवलपमेंट[1] (एफडीडी) एक इटरेटिव और इन्क्रीमेंटल सॉफ़्टवेयर डेवलपमेंट प्रक्रिया है, और इसके अतिरिक्त यह सॉफ्टवेयर विकसित करने के लिए एक लाइटवेट और एजाइल विधि है। एफडीडी कई उद्योग-मान्यता प्राप्त सर्वोत्तम प्रथाओं को एक समग्र में मिश्रित करता है। ये प्रथाएँ क्लाइंट-मूल्यवान कार्यक्षमता (सुविधा) परिप्रेक्ष्य से ड्रिवेन होती हैं। इसका मुख्य उद्देश्य द एजाइल मेनिफेस्टो के पीछे के सिद्धांतों के अनुसार समयबद्ध विधि से बार-बार टेनजीबल, कार्यशील सॉफ़्टवेयर वितरित करना है।[1]
इतिहास
एफडीडी को प्रारंभ में जेफ डी लुका द्वारा 1997 में एक बड़े सिंगापुर बैंक में 15 महीने, 50-व्यक्ति सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट की विशिष्ट जरूरतों को पूरा करने के लिए तैयार किया गया था। इसके परिणामस्वरूप पांच प्रक्रियाओं का एक समूह तैयार किया जाता है, जिसमें एक ओवरऑल मॉडल का डेवलपमेंट और फ़ीचर्स की लिस्ट, योजना, डिज़ाइन और निर्माण सम्मलित होता है। पहली प्रक्रिया पीटर कॉड के वस्तु उन्मुख डिजाइन के दृष्टिकोण से अधिक प्रभावित है। दूसरी प्रक्रिया में कार्यात्मक आवश्यकताओं और डेवलपमेंट कार्यों को प्रबंधित करने के लिए फीचर लिस्ट का उपयोग करने के कॉड के विचार सम्मलित हैं। अन्य प्रक्रियाएँ जेफ डी लुका के अनुभव का परिणाम हैं। सिंगापुर प्रोजेक्ट में इसके सफल प्रयोग के पश्चात से एफडीडी के कई इम्प्लीमेंटेशन हुए हैं।
एफडीडी का विवरण पहली बार 1999 में पीटर कॉड, एरिक लेफेब्रे और जेफ डी लुका द्वारा यूएमएल[2] के साथ कलर में जावा मॉडलिंग पुस्तक के अध्याय 6 में दुनिया के सामने प्रस्तुत किया गया था। इसके पश्चात में, स्टीफन पामर और मैक फेल्सिंग की पुस्तक ए प्रैक्टिकल गाइड टू फीचर-ड्रिवेन डेवलपमेंट[3] (2002 में प्रकाशित) में, एफडीडी का अधिक सामान्य विवरण जावा मॉडलिंग से भिन्न करके दिया गया था।
ओवरव्यू
एफडीडी एक मॉडल-ड्रिवेन शार्ट-इटरेशन प्रक्रिया है जिसमें पांच बुनियादी गतिविधियां सम्मलित हैं। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट पर नज़र रखने के लिए, फ़ीचर ड्राईवेन डेवलपमेंट माइलस्टोन जो प्रत्येक फ़ीचर पर की गई प्रगति को चिह्नित करते हैं, जो परिभाषित किए गए हैं। यह अनुभाग गतिविधियों का उच्च स्तरीय ओवरव्यू देता है। दाईं ओर के चित्र में, इन गतिविधियों के लिए मेटा-प्रोसेस मॉडलिंग को प्रदर्शित किया गया है। पहली दो अनुक्रमिक गतिविधियों के समय, एक ओवरऑल मॉडल की बनावट को स्थापित किया जाता है। अंतिम तीन गतिविधियाँ प्रत्येक सुविधा के लिए इटरेशन हैं।
ओवरऑल मॉडल विकसित करें
एफडीडी प्रोजेक्ट सिस्टम के दायरे और उसके संदर्भ के उच्च-स्तरीय सॉफ्टवेयर वॉकथ्रू के साथ प्रारंभ होती है। इसके पश्चात, छोटे समूहों द्वारा प्रत्येक मॉडलिंग एरिया के लिए विस्तृत डोमेन मॉडल बनाए जाते हैं और सहकर्मी समीक्षा के लिए प्रस्तुत किए जाते हैं। प्रत्येक डोमेन एरिया के मॉडल बनाने के लिए एक या अधिक प्रस्तावित मॉडल का चयन किया जाता है। डोमेन एरिया मॉडल को धीरे-धीरे एक ओवरऑल मॉडल में विलय कर दिया जाता है।
फीचर लिस्ट बनाएं
प्रारंभिक मॉडलिंग के समय एकत्र किए गए ज्ञान का उपयोग डोमेन को सब्जैक्ट एरिया में कार्यात्मक रूप से विघटित करके फ़ीचर्स लिस्ट की पहचान करने के लिए किया जाता है। प्रत्येक सब्जैक्ट एरिया में व्यावसायिक गतिविधियाँ सम्मलित होती हैं, और प्रत्येक व्यावसायिक गतिविधि के चरण एक वर्गीकृत फीचर लिस्ट का आधार बनते हैं। इस संबंध में विशेषताएं "<एक्शन> <रिजल्ट> <ऑब्जेक्ट>" के रूप में व्यक्त किए गए क्लाइंट-मूल्यवान कार्यों के छोटे टुकड़े हैं, उदाहरण के लिए: 'बिक्री की कुल गणना करें' या 'उपयोगकर्ता के पासवर्ड को मान्य करें' सुविधाओं को पूरा होने में दो सप्ताह से अधिक नहीं लगना चाहिए, अन्यथा उन्हें छोटे टुकड़ों में तोड़ दिया जाता है।
फीचर के अनुसार योजना बनाएं
इसी प्रकार फीचर लिस्ट पूरी होने के पश्चात, अगला चरण डेवलपमेंट योजना तैयार करना और प्रोग्रामर को क्लास (कंप्यूटर विज्ञान) के रूप में फ़ीचर्स (या फीचर समूह) का स्वामित्व सौंपना है।
फीचर द्वारा डिजाइन
प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर फ़ीचर्स के एक छोटे समूह का चयन करता है जिन्हें दो सप्ताह के भीतर विकसित किया जाना होता है। संबंधित वर्ग के ओनर्स के साथ मिलकर, मुख्य प्रोग्रामर प्रत्येक सुविधा के लिए विस्तृत अनुक्रम आरेख तैयार करता है और ओवरऑल मॉडल को परिष्कृत करता है। इसके पश्चात, क्लास और विधि प्रस्तावनाएं लिखी जाती हैं और अंत में एक सॉफ्टवेयर निरीक्षण आयोजित किया जाता है।
फीचर द्वारा निर्मित
प्रत्येक गतिविधि के लिए तथा एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के पश्चात, क्लास के ओनर अपनी क्लासेस के लिए कोड विकसित करते हैं। इकाई परीक्षण और सफल कोड समीक्षा के पश्चात, पूर्ण सुविधा को मुख्य बिल्ड में पदोन्नत किया जाता है।
माइल्सटोन्स
चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट पर नज़र रखने के लिए, प्रत्येक सुविधा पर हुई प्रगति को चिह्नित करना महत्वपूर्ण है। इसलिए एफडीडी प्रति फीचर छह माइल्सटोन्स को परिभाषित करता है जिन्हें क्रमिक रूप से पूरा किया जाना है। पहले तीन माइल्सटोन्स डिजाइन बाय फीचर गतिविधि के समय पूरे होते हैं, और अंतिम तीन माइल्सटोन्स बिल्ड बाय फीचर गतिविधि के समय पूरे होते हैं। प्रगति को ट्रैक करने के लिए, प्रत्येक माइल्सटोन्स को पूर्ण प्रतिशत आवंटित किया जाता है। नीचे दी गई तालिका में माइल्सटोन्स और उनके पूरा होने का प्रतिशत दिखाया गया है। जिस बिंदु पर कोडिंग प्रारंभ होती है, (डोमेन वॉकथ्रू 1%, डिज़ाइन 40% और डिज़ाइन निरीक्षण 3% = 44%) एक सुविधा पहले से ही 44% पूर्ण होती है।
| डोमेन वॉकथ्रू | डिज़ाइन | डिज़ाइन निरीक्षण | कोड | कोड निरीक्षण | निर्माण के लिए प्रचार |
|---|---|---|---|---|---|
| 1% | 40% | 3% | 45% | 10% | 1% |
सर्वोत्तम अभ्यास
फ़ीचर ड्राईवेन डेवलपमेंट क्लाइंट-मूल्यवान फ़ीचर परिप्रेक्ष्य के उद्देश्य से सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं के मुख्य समूह पर बनाया गया है।
- डोमेन ऑब्जेक्ट मॉडलिंग- डोमेन ऑब्जेक्ट मॉडलिंग में समाधान की जाने वाली समस्या के डोमेन की खोज और व्याख्या करना सम्मलित है। परिणामी डोमेन ऑब्जेक्ट मॉडल फ़ीचर्स को जोड़ने के लिए एक ओवरऑल रूपरेखा प्रदान करता है।
- फ़ीचर द्वारा डेवलपमेंट करना- कोई भी फ़ंक्शन जो दो सप्ताह के भीतर कार्यान्वित करने के लिए बहुत जटिल है, उसे तब तक छोटे कार्यों में विघटित किया जाता है जब तक कि प्रत्येक उप-समस्या इतनी छोटी न हो जाए कि उसे फीचर कहा जा सके, इससे सही कार्य प्रदान करना और सिस्टम का विस्तार या संशोधन करना सरल हो जाता है।
- व्यक्तिगत वर्ग (कोड) स्वामित्व- व्यक्तिगत वर्ग स्वामित्व का अर्थ है कि कोड के भिन्न-भिन्न टुकड़े या समूह एक ही ओनर को सौंपे जाते हैं। ओनर क्लास की स्थिरता, प्रदर्शन और वैचारिक अखंडता के लिए जिम्मेदार है।
- फ़ीचर टीमें- फ़ीचर टीम एक छोटी, गतिशील रूप से बनाई गई टीम है जो एक छोटी गतिविधि विकसित करती है। प्रत्येक डिज़ाइन निर्णय पर सरल लेकिन कई दिमाग लगाए जाते हैं, और किसी एक को चुनने से पहले कई डिज़ाइन विकल्पों का मूल्यांकन किया जाता है।
- निरीक्षण- सॉफ़्टवेयर निरीक्षण मुख्य रूप से दोषों का पता लगाकर अच्छी गुणवत्ता वाले डिज़ाइन और कोड को सुनिश्चित करने के लिए किया जाता है।
- विन्यास प्रबंधन- कॉन्फ़िगरेशन प्रबंधन उन सभी फ़ीचर्स के लिए स्रोत कोड की पहचान करने में सहायता करता है जो आज तक पूरी हो चुकी हैं और क्लासेस में परिवर्तनों का इतिहास बनाए रखने में सहायता करती है क्योंकि फीचर टीमें उन्हें बढ़ाती हैं।
- नियमित निर्माण- नियमित निर्माण यह सुनिश्चित करता है कि सरल एक अद्यतित सिस्टम हो जिसे क्लाइंट को दिखाया जा सके और फ़ीचर्स के लिए स्रोत कोड की एकीकरण त्रुटियों को शीघ्रता से उजागर करने में सहायता मिलती है।
- प्रगति और परिणाम की दृश्यता- प्रबंधक पूर्ण कार्य के आधार पर प्रोजेक्ट के अंदर और बाहर सभी स्तरों से लगातार, उचित और उपयुक्त प्रगति रिपोर्टिंग का उपयोग करके एक प्रोजेक्ट का संचालन करते हैं।
मेटामॉडल (मेटामॉडलिंग)
मेटामॉडलिंग एक विधि (सॉफ़्टवेयर इंजीनियरिंग) की प्रक्रियाओं और डेटा दोनों को देखने में सहायता करता है। इससे विधियों की तुलना की जा सकती है, और विधि इंजीनियरिंग प्रक्रिया में विधि के टुकड़ों का सरलता से पुन: उपयोग किया जा सकता है। इस तकनीक का उपयोग एकीकृत मॉडलिंग भाषा मानकों के अनुरूप है।
मेटाडेटा मॉडल का बायाँ भाग एफडीडी का उपयोग करके सॉफ़्टवेयर डेवलपमेंट प्रोजेक्ट में सम्मलित पाँच बुनियादी गतिविधियों को दर्शाता है। सभी गतिविधियों में उप-गतिविधियाँ सम्मलित हैं जो एफडीडी प्रक्रिया विवरण में उप-गतिविधियों के अनुरूप हैं। मॉडल का दाहिना भाग इसमें सम्मलित अवधारणाओं को दर्शाता है। ये अवधारणाएँ आरेख के बाईं ओर दर्शाई गई गतिविधियों से उत्पन्न हुई हैं।
यह भी देखें
- एजाइल सॉफ्टवेयर डेवलपमेंट
- व्यवहार आधारित डेवलपमेंट
- प्रोजेक्ट जीवनचक्र
- सॉफ़्टवेयर वास्तुशिल्प
- सॉफ्टवेयर डेवलपमेंट प्रक्रिया
- सॉफ्टवेयर इंजीनियरिंग
संदर्भ
- ↑ "Principles behind the Agile Manifesto". 2019-06-11.
- 1. ^ Coad, P., Lefebvre, E. & De Luca, J. (1999). Java modelling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
- 2. ^ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
बाहरी संबंध
- Feature Driven Development Community
- फीचर-ड्रिवेन डेवलपमेंट at Curlie
- Nebulon एफडीडी Page - Nebulon is the consulting practice of Jeff De Luca
- Successful Web Development Methodologies - Use of एफडीडी for Web Development projects
- Delivering Real Business Value using Feature Driven Development - Article gives basic overview of एफडीडी
- एफडीडी and Agile modelling
- Better Software Faster - Another book in the Coad Series referencing Feature Driven Development. Authors Andy Carmichael and Dan Haywood ISBN 0-13-008752-1
- Interview with एफडीडी-Creator Jeff DeLuca (Podcast)
| Fields | |||||||
|---|---|---|---|---|---|---|---|
| Concepts |
| ||||||
| Orientations | |||||||
| Models |
| ||||||
| Related fields | |||||||
