फीचर-ड्रिवेन डेवलपमेंट: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| 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|एफडीडी के लिए प्रक्रिया मॉडल]] | ||
| Line 22: | Line 20: | ||
=== समग्र मॉडल विकसित करें === | === समग्र मॉडल विकसित करें === | ||
एफडीडी परियोजना | एफडीडी परियोजना प्रणाली के दायरे और उसके संदर्भ के उच्च-स्तरीय [[सॉफ्टवेयर वॉकथ्रू]] के साथ प्रारंभ होती है। इसके पश्चात, छोटे समूहों द्वारा प्रत्येक मॉडलिंग क्षेत्र के लिए विस्तृत डोमेन मॉडल बनाए जाते हैं और [[सहकर्मी समीक्षा]] के लिए प्रस्तुत किए जाते हैं। प्रत्येक डोमेन क्षेत्र के मॉडल बनने के लिए एक या अधिक प्रस्तावित मॉडल का चयन किया जाता है। डोमेन क्षेत्र मॉडल को धीरे-धीरे एक समग्र मॉडल में विलय कर दिया जाता है। | ||
=== फीचर सूची बनाएं === | === फीचर सूची बनाएं === | ||
प्रारंभिक मॉडलिंग के | प्रारंभिक मॉडलिंग के समय एकत्र किए गए ज्ञान का उपयोग डोमेन को विषय क्षेत्रों में कार्यात्मक रूप से विघटित करके फ़ीचर्स सूची की पहचान करने के लिए किया जाता है। प्रत्येक विषय क्षेत्र में व्यावसायिक गतिविधियाँ सम्मलित होती हैं, और प्रत्येक व्यावसायिक गतिविधि के चरण एक वर्गीकृत फीचर सूची का आधार बनते हैं। इस संबंध में विशेषताएं "<एक्शन> <रिजल्ट> <ऑब्जेक्ट>" के रूप में व्यक्त किए गए क्लाइंट-मूल्यवान कार्यों के छोटे टुकड़े हैं, उदाहरण के लिए: 'बिक्री की कुल गणना करें' या 'उपयोगकर्ता के पासवर्ड को मान्य करें' सुविधाओं को पूरा होने में दो सप्ताह से अधिक नहीं लगना चाहिए, अन्यथा उन्हें छोटे टुकड़ों में तोड़ दिया जाता है। | ||
=== | === फीचर के अनुसार योजना बनाएं === | ||
फीचर सूची पूरी होने के | फीचर सूची पूरी होने के पश्चात, अगला कदम डेवलपमेंट योजना तैयार करना और [[प्रोग्रामर]] को क्लास (कंप्यूटर विज्ञान) के रूप में फ़ीचर्स (या फीचर समूह) का स्वामित्व सौंपना है। | ||
=== फीचर द्वारा डिजाइन === | === फीचर द्वारा डिजाइन === | ||
प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर | प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर फ़ीचर्स के एक छोटे समूह का चयन करता है जिन्हें दो सप्ताह के भीतर विकसित किया जाना होता है। संबंधित वर्ग के ओनर्स के साथ मिलकर, मुख्य प्रोग्रामर प्रत्येक सुविधा के लिए विस्तृत [[अनुक्रम आरेख]] तैयार करता है और समग्र मॉडल को परिष्कृत करता है। इसके पश्चात, क्लास और विधि प्रस्तावनाएं लिखी जाती हैं और अंत में एक [[सॉफ्टवेयर निरीक्षण]] आयोजित किया जाता है। | ||
=== फीचर द्वारा निर्मित === | === फीचर द्वारा निर्मित === | ||
प्रत्येक गतिविधि के लिए एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के | प्रत्येक गतिविधि के लिए तथा एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के पश्चात, क्लास के ओनर अपनी क्लासेस के लिए कोड विकसित करते हैं। इकाई परीक्षण और सफल कोड समीक्षा के पश्चात, पूर्ण सुविधा को मुख्य बिल्ड में पदोन्नत किया जाता है। | ||
== | == माइल्सटोन्स == | ||
चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। | चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट परियोजना पर नज़र रखने के लिए, प्रत्येक सुविधा पर हुई प्रगति को चिह्नित करना महत्वपूर्ण है। इसलिए एफडीडी प्रति फीचर छह माइल्सटोन्स को परिभाषित करता है जिन्हें क्रमिक रूप से पूरा किया जाना है। पहले तीन माइल्सटोन्स डिजाइन बाय फीचर गतिविधि के समय पूरे होते हैं, और अंतिम तीन माइल्सटोन्स बिल्ड बाय फीचर गतिविधि के समय पूरे होते हैं। प्रगति को ट्रैक करने के लिए, प्रत्येक माइल्सटोन्स को पूर्ण प्रतिशत आवंटित किया जाता है। नीचे दी गई तालिका में माइल्सटोन्स और उनके पूरा होने का प्रतिशत दिखाया गया है। जिस बिंदु पर कोडिंग प्रारंभ होती है, (डोमेन वॉकथ्रू 1%, डिज़ाइन 40% और डिज़ाइन निरीक्षण 3% = 44%) एक सुविधा पहले से ही 44% पूर्ण होती है। | ||
{| class="wikitable" | {| class="wikitable" | ||
| 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}} | ||
Revision as of 20:54, 5 July 2023
| Part of a series on |
| Software development |
|---|
फीचर-ड्रिवेन डेवलपमेंट[1] (एफडीडी) एक पुनरावृत्तीय और वृद्धिशील डेवलपमेंट सॉफ़्टवेयर डेवलपमेंट प्रक्रिया है, और इसके अतिरिक्त यह सॉफ्टवेयर विकसित करने के लिए एक हल्का या एजाइल विधि है। एफडीडी कई उद्योग-मान्यता प्राप्त सर्वोत्तम प्रथाओं को एक समग्र में मिश्रित करता है। ये प्रथाएँ ग्राहक-मूल्यवान कार्यक्षमता (सुविधा) परिप्रेक्ष्य से ड्रिवेन होती हैं। इसका मुख्य उद्देश्य द एजाइल मेनिफेस्टो के पीछे के सिद्धांतों के अनुसार समयबद्ध विधि से बार-बार मूर्त, कार्यशील सॉफ़्टवेयर वितरित करना है।[1]
इतिहास
एफडीडी को प्रारंभ में जेफ डी लुका द्वारा 1997 में एक बड़े सिंगापुर बैंक में 15 महीने, 50-व्यक्ति सॉफ्टवेयर डेवलपमेंट परियोजना की विशिष्ट जरूरतों को पूरा करने के लिए तैयार किया गया था। इसके परिणामस्वरूप पांच प्रक्रियाओं का एक समूह तैयार हुआ, जिसमें एक समग्र मॉडल का डेवलपमेंट और फ़ीचर्स की सूची, योजना, डिज़ाइन और निर्माण सम्मलित था। पहली प्रक्रिया पीटर कॉड के वस्तु उन्मुख डिजाइन के दृष्टिकोण से काफी प्रभावित है। दूसरी प्रक्रिया में कार्यात्मक आवश्यकताओं और डेवलपमेंट कार्यों को प्रबंधित करने के लिए फीचर सूची का उपयोग करने के कॉड के विचार सम्मलित हैं। अन्य प्रक्रियाएँ जेफ डी लुका के अनुभव का परिणाम हैं। सिंगापुर परियोजना में इसके सफल प्रयोग के पश्चात से एफडीडी के कई कार्यान्वयन हुए हैं।
एफडीडी का विवरण पहली बार 1999 में पीटर कॉड, एरिक लेफेब्रे और जेफ डी लुका द्वारा यूएमएल[2] के साथ कलर में जावा मॉडलिंग पुस्तक के अध्याय 6 में दुनिया के सामने प्रस्तुत किया गया था। इसके पश्चात में, स्टीफन पामर और मैक फेल्सिंग की पुस्तक ए प्रैक्टिकल गाइड टू फीचर-ड्रिवेन डेवलपमेंट[3] (2002 में प्रकाशित) में, एफडीडी का अधिक सामान्य विवरण जावा मॉडलिंग से भिन्न करके दिया गया था।
ओवरव्यू
एफडीडी एक मॉडल-ड्रिवेन लघु-पुनरावृत्ति प्रक्रिया है जिसमें पांच बुनियादी गतिविधियां सम्मलित हैं। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट परियोजना पर नज़र रखने के लिए, फ़ीचर ड्राईवेन डेवलपमेंट माइलस्टोन जो प्रत्येक फ़ीचर पर की गई प्रगति को चिह्नित करते हैं, परिभाषित किए गए हैं। यह अनुभाग गतिविधियों का उच्च स्तरीय ओवरव्यू देता है। दाईं ओर के चित्र में, इन गतिविधियों के लिए मेटा-प्रोसेस मॉडलिंग को प्रदर्शित किया गया है। पहली दो अनुक्रमिक गतिविधियों के समय, एक समग्र मॉडल आकार स्थापित किया जाता है। अंतिम तीन गतिविधियाँ प्रत्येक सुविधा के लिए पुनरावृत्ति हैं।
समग्र मॉडल विकसित करें
एफडीडी परियोजना प्रणाली के दायरे और उसके संदर्भ के उच्च-स्तरीय सॉफ्टवेयर वॉकथ्रू के साथ प्रारंभ होती है। इसके पश्चात, छोटे समूहों द्वारा प्रत्येक मॉडलिंग क्षेत्र के लिए विस्तृत डोमेन मॉडल बनाए जाते हैं और सहकर्मी समीक्षा के लिए प्रस्तुत किए जाते हैं। प्रत्येक डोमेन क्षेत्र के मॉडल बनने के लिए एक या अधिक प्रस्तावित मॉडल का चयन किया जाता है। डोमेन क्षेत्र मॉडल को धीरे-धीरे एक समग्र मॉडल में विलय कर दिया जाता है।
फीचर सूची बनाएं
प्रारंभिक मॉडलिंग के समय एकत्र किए गए ज्ञान का उपयोग डोमेन को विषय क्षेत्रों में कार्यात्मक रूप से विघटित करके फ़ीचर्स सूची की पहचान करने के लिए किया जाता है। प्रत्येक विषय क्षेत्र में व्यावसायिक गतिविधियाँ सम्मलित होती हैं, और प्रत्येक व्यावसायिक गतिविधि के चरण एक वर्गीकृत फीचर सूची का आधार बनते हैं। इस संबंध में विशेषताएं "<एक्शन> <रिजल्ट> <ऑब्जेक्ट>" के रूप में व्यक्त किए गए क्लाइंट-मूल्यवान कार्यों के छोटे टुकड़े हैं, उदाहरण के लिए: 'बिक्री की कुल गणना करें' या 'उपयोगकर्ता के पासवर्ड को मान्य करें' सुविधाओं को पूरा होने में दो सप्ताह से अधिक नहीं लगना चाहिए, अन्यथा उन्हें छोटे टुकड़ों में तोड़ दिया जाता है।
फीचर के अनुसार योजना बनाएं
फीचर सूची पूरी होने के पश्चात, अगला कदम डेवलपमेंट योजना तैयार करना और प्रोग्रामर को क्लास (कंप्यूटर विज्ञान) के रूप में फ़ीचर्स (या फीचर समूह) का स्वामित्व सौंपना है।
फीचर द्वारा डिजाइन
प्रत्येक सुविधा के लिए एक डिज़ाइन पैकेज तैयार किया जाता है। एक मुख्य प्रोग्रामर फ़ीचर्स के एक छोटे समूह का चयन करता है जिन्हें दो सप्ताह के भीतर विकसित किया जाना होता है। संबंधित वर्ग के ओनर्स के साथ मिलकर, मुख्य प्रोग्रामर प्रत्येक सुविधा के लिए विस्तृत अनुक्रम आरेख तैयार करता है और समग्र मॉडल को परिष्कृत करता है। इसके पश्चात, क्लास और विधि प्रस्तावनाएं लिखी जाती हैं और अंत में एक सॉफ्टवेयर निरीक्षण आयोजित किया जाता है।
फीचर द्वारा निर्मित
प्रत्येक गतिविधि के लिए तथा एक फीचर तैयार करने के लिए एक सफल डिज़ाइन निरीक्षण की योजना बनाई जाने के पश्चात, क्लास के ओनर अपनी क्लासेस के लिए कोड विकसित करते हैं। इकाई परीक्षण और सफल कोड समीक्षा के पश्चात, पूर्ण सुविधा को मुख्य बिल्ड में पदोन्नत किया जाता है।
माइल्सटोन्स
चूँकि सुविधाएँ छोटी हैं, इसलिए किसी सुविधा को पूरा करना अपेक्षाकृत छोटा कार्य है। उपयुक्त स्थिति रिपोर्टिंग और सॉफ़्टवेयर डेवलपमेंट परियोजना पर नज़र रखने के लिए, प्रत्येक सुविधा पर हुई प्रगति को चिह्नित करना महत्वपूर्ण है। इसलिए एफडीडी प्रति फीचर छह माइल्सटोन्स को परिभाषित करता है जिन्हें क्रमिक रूप से पूरा किया जाना है। पहले तीन माइल्सटोन्स डिजाइन बाय फीचर गतिविधि के समय पूरे होते हैं, और अंतिम तीन माइल्सटोन्स बिल्ड बाय फीचर गतिविधि के समय पूरे होते हैं। प्रगति को ट्रैक करने के लिए, प्रत्येक माइल्सटोन्स को पूर्ण प्रतिशत आवंटित किया जाता है। नीचे दी गई तालिका में माइल्सटोन्स और उनके पूरा होने का प्रतिशत दिखाया गया है। जिस बिंदु पर कोडिंग प्रारंभ होती है, (डोमेन वॉकथ्रू 1%, डिज़ाइन 40% और डिज़ाइन निरीक्षण 3% = 44%) एक सुविधा पहले से ही 44% पूर्ण होती है।
| Domain Walkthrough | Design | Design Inspection | Code | Code Inspection | Promote To Build |
|---|---|---|---|---|---|
| 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 | |||||||
