क्या विकास के बाद सॉफ़्टवेयर डिज़ाइन दस्तावेज़ बनाना उचित हो सकता है?


11

मैं वर्तमान में अपने "सॉफ़्टवेयर डेवलपमेंट" अध्ययन के लिए अपने स्नातक स्तर पर काम कर रहा हूं, जिसमें मुझे किसी बाहरी कंपनी में व्यक्तिगत रूप से जटिल सॉफ़्टवेयर विकसित करना है। यह सभी संरचित तरीके से किए जाने की जरूरत है, सभी संबंधित दस्तावेजों को बनाते हुए।

इस परियोजना के लिए मैंने IEEE मानक दस्तावेजों के साथ काम करने के लिए चुना है: सॉफ़्टवेयर आवश्यकताएँ दस्तावेज़ (SRS), सॉफ़्टवेयर आर्किटेक्चर दस्तावेज़ (SAD) और सॉफ़्टवेयर डिज़ाइन दस्तावेज़ (SDD)। हालांकि स्कूल में अन्यथा सिखाया जाता है, इस परियोजना के लिए मैंने विकास के बाद एसडीडी बनाने के लिए चुना है (पहले के बजाय)। मेरा तर्क है:

जिस कंपनी में मैं अपनी इंटर्नशिप करता हूं, उसने मुझे प्रायोगिक तरीके से, आवश्यकताओं के एक निश्चित सेट को संतुष्ट करते हुए, एक जटिल सॉफ्टवेयर बनाने का निर्देश दिया है। स्वतंत्रता की मात्रा के कारण जो उन्होंने मुझे परियोजना की परिभाषा में दिया है, लगभग कुछ भी पहले से निश्चित नहीं है, और विकास प्रक्रिया में प्रयोग करते समय सबसे अच्छा सामना किया जा सकता है। इसके अतिरिक्त, मैं एक व्यक्तिगत तरीके से सॉफ्टवेयर बना रहा हूं , इससे कंपनी के किसी और को पहले से इस सॉफ्टवेयर डिजाइन को बनाने का मुझे कोई लाभ नहीं होगा। पहले से इसे करने में मुझे बाद में इसे बदलने के लिए बहुत समय लगेगा, क्योंकि मैं निश्चित हो सकता हूं कि परियोजना में अनिश्चितताओं के साथ, जो डिजाइन मैं पहले से बनाता हूं उसे बहुत बदलना होगा । यह मुझे उल्टा लगता है।

क्या विकास के बाद एसडीडी बनाने का यह अच्छा औचित्य है? यदि नहीं, तो क्या इसके लिए कोई अच्छा औचित्य होगा?

संपादित करें: बाद में एसडीडी बनाने का कारण भविष्य के डेवलपर्स के लिए परियोजना पर जारी रहेगा। मैं अपनी स्नातक अवधि में पूरी परियोजना को समाप्त करने में सक्षम नहीं होने जा रहा हूं, इसलिए अन्य डेवलपर्स को वर्तमान कोडबेस पर जारी रखना होगा।


2
यदि आपको विकास के दौरान / बाद में अपने एसडीडी को "बहुत" बदलना है, तो संभवतः इसका बहुत अधिक विवरण है।
आजादी-एम


अंडा या चिकन - जो पहले आया था कुछ दार्शनिकों पर प्रयास खर्च करते हैं। एसडीडी और पूर्ण (जटिल) सॉफ्टवेयर समान होना चाहिए, वे एक साथ विकसित होते हैं।
मटनज़

मेरे लिए यह बाद में दस्तावेज़ के लिए काम नहीं करता है। यह मेरे लिए बहुत उबाऊ है। मुझे डिज़ाइन करते समय लिखना होगा। एक SDD का मसौदा तैयार करना भी एक प्रकार का रबर डकिंग है: आपको डिज़ाइन की व्याख्या करने की आवश्यकता है और इससे समस्याओं का पता चल जाएगा।
जोस

जवाबों:


17

IEEE Std 1016 खंड 3.1 सॉफ्टवेयर डिज़ाइन के संदर्भ में, आप इस अनुच्छेद को पा सकते हैं:

एक एसडीडी को विभिन्न डिजाइन स्थितियों में तैयार और उपयोग किया जा सकता है। आमतौर पर, किसी समस्या को हल करने के लिए एक सॉफ़्टवेयर आइटम के विकास का समर्थन करने के लिए एक एसडीडी तैयार किया जाता है, जहां आवश्यकताओं के एक सेट के संदर्भ में यह समस्या व्यक्त की गई है। एसडीडी की सामग्री को इन आवश्यकताओं का पता लगाया जा सकता है। अन्य मामलों में, एक SDD एक मौजूदा सिस्टम है जिसमें डिज़ाइन प्रलेखन की कमी है। ऐसे मामलों में, एक एसडीडी इस तरह तैयार की जाती है कि ब्याज की जानकारी सभी इच्छुक पार्टियों को कब्जा, संगठित, प्रस्तुत और प्रसारित की जाती है। ब्याज की इस जानकारी का उपयोग सॉफ्टवेयर सिस्टम की योजना, विश्लेषण, कार्यान्वयन और विकास के लिए किया जा सकता है, आवश्यक डिजाइन चिंताओं को पहचानने और संबोधित करके।

IEEE Std 1016 के लेखक मानते हैं कि एक SDD को फ्रंट-अप नहीं बनाया जा सकता है। इच्छुक पार्टियों के लिए जानकारी कैप्चर करने के लिए सॉफ़्टवेयर सिस्टम मौजूद होने के बाद एक बनाया जा सकता है।

धारा 1.1 स्कोप कुछ रोचक जानकारी भी प्रदान करता है:

यह मानक डिज़ाइन, कॉन्फ़िगरेशन प्रबंधन या गुणवत्ता आश्वासन के लिए विशिष्ट कार्यप्रणालियों को निर्धारित नहीं करता है।

इस प्रश्न के संदर्भ में, मुख्य शब्द "कॉन्फ़िगरेशन प्रबंधन" हैं। कॉन्फ़िगरेशन प्रबंधन न केवल बनाए जा रहे सॉफ़्टवेयर सिस्टम पर लागू होता है, बल्कि कोई भी संबद्ध दस्तावेज़।

आपकी व्यक्तिगत स्थिति में, और कई स्थितियों में, SDD अप फ्रंट बनाना एक बेकार है। डेविड अर्नो का उत्तर यह होने के करीब है कि मैं सही उत्तर पर क्या विचार करूंगा। आपके सॉफ़्टवेयर सिस्टम का असली डिज़ाइन कोड है। हालाँकि, आप "पहले SDD बनाएँ" या "बाद SDD बनाएँ" आपके एकमात्र विकल्प नहीं हैं। आपके पास एक तीसरा विकल्प है - सॉफ्टवेयर सिस्टम के साथ एसडीडी विकसित करना।

यदि आप IEEE Std 1016 जैसे मानक का पालन कर रहे हैं, तो आपके पास SDD की आवश्यकताएं हैं। विशेष रूप से, इस मानक की धारा 4 आपके पास मौजूद सामग्री को परिभाषित करती है। जब आप डिज़ाइन निर्णयों के माध्यम से काम करते हैं, तो अलग-अलग दृष्टिकोण, विचार और ओवरले बनाना शुरू करें। जैसा कि आप निर्णय लेते हैं, उनके लिए डिज़ाइन तर्क को कैप्चर करें।

यह इच्छुक पार्टियों को कोड में खुदाई करने की आवश्यकता के बिना सॉफ़्टवेयर डिज़ाइन के विकास का पालन करने की अनुमति देगा। बेशक, लोगों की टिप्पणियां या सुझाव हो सकते हैं। यदि आप एसडीडी को अपडेट कर रहे हैं, तो वे आपकी प्रगति को ट्रैक कर सकते हैं और दृष्टिकोण पर प्रतिक्रिया दे सकते हैं, जिसे आप उत्पाद के साथ-साथ एसडीडी में भी शामिल कर सकते हैं। जब आप प्रोजेक्ट से संक्रमण करते हैं, यदि सॉफ़्टवेयर कोड और एसडीडी सिंक में हैं, तो किसी को आसानी से जहाज पर चढ़ने और काम करने में सक्षम होना चाहिए।


मैं वास्तव में आईएसओ और IEEE को भ्रमित करता हूं, यह वास्तव में IEEE होना चाहिए। IEEE एसटीडी लेखकों के कुछ टिप्पणियों को स्वयं उद्धृत करने के लिए धन्यवाद। यह "तीसरा" विकल्प वास्तव में सबसे अच्छा है। बहुत बुरा हम इस तरह से कभी नहीं सिखाया जाता है।
साइमन बार्स

@SimonBaars मुझे आश्चर्य नहीं है। यदि आपको IEEE और ISO जैसे मानकों के बारे में पढ़ाया जाता है, तो यह लगभग हमेशा योजना-संचालित / झरने के संदर्भ में होता है। जब आप पुनरावृत्ति और वृद्धिशील विकास के तरीकों के बारे में सीखते हैं, तो आप इन मानकों के बारे में नहीं सीखते हैं। हालांकि, IEEE मानकों के नए संस्करण पुनरावृत्त और वृद्धिशील (चुस्त) तरीकों पर विचार करते हैं और वे अक्सर इन वातावरणों में भी लागू किए जा सकते हैं।
थॉमस ओवेन्स

8

यदि आप एसडीडी से सभी की तलाश कर रहे हैं, तो डिजाइन को दूसरों के साथ संवाद करना है, तो हाँ, आप इसे विकास के बाद बना सकते हैं। केवल बात यह है, यह तो प्रलेखन कहा जाता है।

हालांकि, मैं यह बताना चाहूंगा कि एक एसडीडी दूसरे उद्देश्य को भी पूरा कर सकता है। यह आपको डिजाइन के बारे में तर्क करने और यह सुनिश्चित करने में भी मदद कर सकता है कि आप "तेजी से असफल" हैं। यह एक अच्छी बात है, खासकर अगर बहुत सारी चीजें पहले से अनिश्चित हैं क्योंकि आप उन तरीकों को त्याग सकते हैं जो पूरे कार्यान्वयन के दौरान जल्दी काम नहीं करेंगे। यह आपको तकनीकी विवरणों पर जल्द ही ध्यान केंद्रित करने से भी रोक सकता है, जब तक कि आपने डिज़ाइन का पता नहीं लगा लिया हो।

मैं आपको कम से कम पहले एसडीडी पर एक प्रयास करने की सलाह दूंगा। यदि आप उन चीजों में भाग लेते हैं जहां आपको यकीन नहीं है कि चीजें कैसे काम करेंगी, तो आप उन समस्याओं के छोटे प्रोटोटाइप बना सकते हैं जिन्हें आप हल करने की कोशिश कर रहे हैं। यह आपको अपनी परियोजना के लिए विशिष्ट समस्याओं को हल करने में अनुभव देगा जो लंबे समय में पूर्ण समाधान की गुणवत्ता को लाभ देगा।


परियोजना के दौरान बनाए जाने और बनाए रखने के बाद एसडीडी को क्या कहा जाएगा?
साइमन बार्स


क्या आप पर्यवेक्षकों द्वारा गलतफहमी से बचने के लिए इसका नाम बदलने का सुझाव देंगे?
शमौन बारस

आप किस तरह की गलतफहमी होने की उम्मीद कर रहे हैं?
जोनाथन वैन डे वीन

8
@SimonBaars: वहाँ वास्तव में "सॉफ्टवेयर डिजाइन दस्तावेज़" या "सॉफ्टवेयर डिजाइन दस्तावेज़ के बीच इस तरह के एक बड़ा अंतर है समझना "?
डॉक ब्राउन

2

एक सच्चा विस्तृत डिज़ाइन दस्तावेज़ जो आप बनाएंगे वह कोड है। यह ठीक से संकलक को बताता है कि आपके आवेदन का निर्माण कैसे किया जाए। इस तरह, आपका डिज़ाइन शिपिंग से पहले एक अंतिम निर्माण तक पूरा नहीं हो सकता है।

आपके द्वारा बनाया गया कोई भी अन्य डिज़ाइन दस्तावेज़, जैसे कि SDD, आपको अपना डिज़ाइन (कोड) पूरा करने के बाद अपडेट करने की आवश्यकता होगी। इसलिए, एसडीडी को बाद में लिखने के लिए एक सम्मोहक कारण है: आपको केवल एक बार करना होगा।

इस के लिए स्पष्ट काउंटर है, "कितनी बार आप वास्तव में घटना के बाद एसडीडी लिखते हैं "? एप्लिकेशन को भेज दिया गया है, इसलिए आप उस स्तर पर दस्तावेजीकरण के लिए समय बिताना नहीं चाहते हैं। लेकिन यह किसी मौजूदा को अपडेट करने के लिए समान रूप से लागू होता है। जो बदतर है, कोई SDD या SDD जो गलत है और जिस पर भरोसा नहीं किया जा सकता है?

हालांकि इसे अग्रिम में लिखने के दो कारण हैं। सबसे पहले ऐसा करने के लिए आप पर एक अनिवार्य आवश्यकता हो सकती है (अच्छा नहीं; लेकिन ऐसा होता है)। दूसरे, इस तरह के दस्तावेज़ बनाने से आपको डिज़ाइन के लिए एक समग्र रणनीति तैयार करने में मदद मिल सकती है। लेकिन यह एक अनौपचारिक तरीके से चित्र, स्क्रैबलिंग नोट आदि को समान रूप से अच्छी तरह से किया जा सकता है। और जब से इसे बाद में पुनर्लेखन की आवश्यकता होगी, उस अप-फ्रंट मैक्रो डिज़ाइन प्रक्रिया के "त्वरित और गंदे" दृष्टिकोण के बहुत सारे लाभ हैं।


The app is shipped, so you aren't likely to want to spend time documenting at that stage. इस मामले में मेरी स्नातक अवधि के भीतर ऐप को अंतिम रूप नहीं दिया जाएगा, इसलिए हमें उत्पाद के विकास पर जारी रखने में सक्षम होने के लिए अन्य डेवलपर्स के लिए प्रलेखन की आवश्यकता है।
साइमन बार्स

0

मेरे लिए, यह एक अच्छा तर्क नहीं होगा।

अगर वास्तव में जरूरत है, तो मैं एक अज्ञात समस्या डोमेन की बेहतर समझ के लिए प्रोटोटाइप विकास पर एक मजबूत फोकस के साथ बहस करूंगा। हालांकि, उन मामलों में भी, डिजाइन के कुछ टुकड़े पहले उपयोगी होंगे।


0

वैसे भी इसे सामने करने के लिए एक मामला बनाया जाना है । क्योंकि आप इस तरह से दस्तावेज़ लिखने के बारे में जानने के लिए ऐसा कर रहे हैं । इस काम को छोड़ देना क्योंकि यह 100% आवश्यक नहीं हो सकता है, इसका मतलब है कि आप अपना सीखना छोड़ दें।

कार्यान्वयन के दौरान इसे लिखने के लिए एक समझौता हो सकता है । प्रत्येक घटक / मॉड्यूल / स्क्रीन या आपके कार्यक्रम के अन्य उपखंड से पहले, आपको इसके बारे में सोचने की ज़रूरत है कि आप इसे कैसे बनाने जा रहे हैं। फिर आप अपने निर्णय अपने डिजाइन दस्तावेज में जोड़ते हैं और फिर उन्हें लागू करते हैं।

यदि बाद में कुछ भी बदलता है, तो आप दस्तावेज़ को अपडेट करते हैं।

इस तथ्य के बाद लिखने की तुलना में इसके कई फायदे हैं:

  • आवश्यकताएं बदलने, उपयोगी आदत होने पर आप डिज़ाइन दस्तावेज़ों को अपडेट रखना सीखेंगे

  • आप कार्यान्वयन से पहले डिजाइन के बारे में सोचना सीखेंगे

  • यह तथ्य के बाद डिजाइन दस्तावेज़ लिखने के रूप में दिमाग-सुन्न उबाऊ नहीं है

  • यदि आप समय से बाहर भाग जाते हैं, तो आपके पास एक डिज़ाइन दस्तावेज़ होगा जिसमें यह वर्णन किया जाएगा कि आपके पास अभी तक क्या है ताकि अन्य लोग आपके काम को जारी रख सकें

  • यह इस तरह से बहुत अतिरिक्त काम नहीं है

  • जैसे-जैसे आपकी परियोजना आगे बढ़ेगी, आपको इस बात पर बिल्कुल यकीन नहीं हो सकता है कि आपने खुद दो महीने पहले ऐसा कुछ क्यों किया था, और आपको बताने के लिए आपके पास अपने नोट्स होंगे।


-2

सिस्टम डिज़ाइन दस्तावेज़, बुनियादी आवश्यकताओं का रिकॉर्ड (नई सुविधाएँ) अपडेट करता है क्योंकि प्रोजेक्ट नई डिज़ाइन और समाधान विशेषताओं के साथ आगे बढ़ता है। परियोजना / समाधान तक पहुँचाया गया है। उपयोगी, यह सभी संबंधितों के लिए संचार करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.