प्रलेखन के महत्व के बारे में

हम में से कई अनुप्रयोग सॉफ्टवेयर विकसित करने के लिए पहले से ही स्थापित प्रक्रियाओं के साथ कंपनियों में काम करते हैं, और दस्तावेजों की एक विस्तृत विविधता इन प्रक्रियाओं का एक अभिन्न अंग है। हालांकि, ऐसी कंपनियां हैं जिनमें तकनीकी दस्तावेज लिखने के लिए कोई परंपराएं और प्रक्रियाएं नहीं हैं, और सभी जानकारी लोगों के प्रमुखों और कॉर्पोरेट ईमेल में है। यदि आप पहले प्रकार की कंपनी से दूसरे प्रकार की कंपनी से आते हैं, तो आप बहुत जल्दी पाते हैं कि काम करने वाले दस्तावेज को हवा की तरह जरूरत है। क्यों? आइए सॉफ्टवेयर विकास में मुख्य प्रकार के कामकाजी दस्तावेज देखें, और उनके बिना जीवन की कल्पना करने का प्रयास करें।

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

2. एचएलए (उच्च स्तरीय वास्तुकला)। यह दस्तावेज़ वास्तुकला स्तर पर वर्णन करता है कि हम टीओआर में वर्णित क्या लागू करेंगे। यह वर्णन करता है कि परिवर्तन करना कहाँ आवश्यक होगा, परिवर्तनों का सार वर्णन किया गया है, और यह बहुत ही दस्तावेज़ ऐसे महत्वपूर्ण भाग का वर्णन करता है जैसे मॉड्यूल / सबसिस्टम के बीच का इंटरफेस। यदि मैं गलत नहीं हूँ, तो यह DeMarco और लिस्टर द्वारा बहुत ही सही ढंग से नोट किया गया था कि सिस्टम और इंटरफेस के बीच बातचीत के दौरान सबसे अधिक "खराब" (जिसे ढूंढना और समाप्त करना मुश्किल है) कीड़े होते हैं। चूंकि एचएलए विकास टीमों के साथ संगत है, वास्तव में, यह दस्तावेज एक ऐसा स्थान है जिसमें विकास दल इस बात पर सहमत होते हैं कि उनके उत्पाद एक-दूसरे के साथ कैसे बातचीत करेंगे। यदि आप इन दस्तावेजों को नहीं लिखते हैं, तो आप कभी नहीं पाएंगे कि किसने इंटरफ़ेस को गलत तरीके से लागू किया, जो अंत में निश्चित रूप से वास्तुकला में त्रुटियों को जन्म देगा, जो भविष्य में बहुत महंगा हो सकता है। कोड की गुणवत्ता में नाटकीय रूप से गिरावट आएगी, और बहुत से कठिन-से-स्थानीय त्रुटियां होंगी। इसके अलावा, भविष्य में, यह समझने के लिए कि दो मॉड्यूल के बीच बातचीत कैसे काम करती है, नए व्यक्ति को फिर से दर्जनों लोगों के साथ संवाद करना होगा और महीनों के पत्राचार को बढ़ाना होगा।

3. एलएलडी (निम्न स्तर अपघटन)। यह एक दस्तावेज है जो विकास टीम के भीतर बनाया गया है। यह विस्तार से लागू करने के लिए आवश्यक सभी तरीकों और एपीआई का वर्णन करता है। वास्तव में, इस दस्तावेज़ को लिखने के बाद, यह केवल वर्णित एन्कोड करने के लिए बना हुआ है। इस दस्तावेज़ के बिना, प्रोग्रामर को इस बात की स्पष्ट समझ नहीं होगी कि क्या किया जाना चाहिए, जो भविष्य में बग की संख्या में वृद्धि की ओर ले जाएगा (अर्थात, कोड की गुणवत्ता में कमी)।

4. पीएमआई (कार्यक्रम और परीक्षण प्रक्रिया)। यह परीक्षण के क्षेत्र से संभवतया मुख्य दस्तावेज है, कदम से कदम यह बताते हुए कि व्यापार के लिए क्या करने की आवश्यकता है ताकि यह तय किया जा सके कि कार्यान्वित कार्यक्षमता सही ढंग से और ToR के अनुसार काम करती है। इस तरह के एक दस्तावेज के बिना, आप त्रुटियों के लिए कार्यक्षमता की जांच नहीं कर पाएंगे (टीके बेमेल भी एक बग है), जो अंततः जोखिम को बहुत बढ़ा देगा कि उत्पादन मंच पर कीड़े का एक गुच्छा सामने आएगा, कार्यात्मक के पूर्ण निष्क्रियता तक। इसके अलावा, इस दस्तावेज़ के बिना, व्यवसाय द्वारा कार्यात्मक की स्वीकृति सभी आगामी परिणामों के साथ एक अनौपचारिक प्रक्रिया में बदल जाती है, जैसे कि व्यवसाय द्वारा विकास के लिए निराधार दावे।

5. उपयोगकर्ता मैनुअल। आपके सॉफ़्टवेयर का उपयोग करके एक निश्चित व्यावसायिक प्रक्रिया को करने के लिए उपयोगकर्ता को क्या करने की आवश्यकता है। कई स्क्रीनशॉट, कुछ शब्द। इस दस्तावेज़ के बिना, उपयोगकर्ता नियमित रूप से प्रत्येक छींक के लिए समर्थन और (विशेष रूप से उन्नत मामलों में) विकास के लिए कॉल करेंगे। कहने की जरूरत नहीं है, इस दस्तावेज़ के बिना एक नए कर्मचारी के लिए, एंटरप्राइज़ एप्लिकेशन सॉफ़्टवेयर को समझना बेहद मुश्किल होगा, जो, एक नियम के रूप में, लपट और सहज ज्ञान युक्त इंटरफेस द्वारा प्रतिष्ठित नहीं है?

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

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

दस्तावेज लिखें!