साइट के लिए संदर्भ की शर्तें

UPD: संदर्भ की शर्तों के उदाहरण के साथ लेख की निरंतरता

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

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

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

1. टीके की आवश्यकता का औचित्य

और आपको साइट पर टीके की आवश्यकता क्यों है? ग्राहक कहता है: "हमें निम्न साइट की आवश्यकता है: उत्पाद सूची, टोकरी, ऑर्डर फॉर्म, वितरण, हम मानचित्र पर हैं, हमारे बारे में, प्रतिक्रिया"। क्या स्पष्ट नहीं है? कुछ भी असामान्य नहीं है, सब कुछ सामान्य और नियमित है।

डेवलपर स्पष्ट रूप से समझता है कि उसकी समझ में क्या किया जाना चाहिए और किया जाना चाहिए, इस तरह की आवश्यकता है:




काम के अंत में ग्राहक से डिजाइन आता है, और जब इसे देखते हैं, तो यह स्पष्ट हो जाता है कि ग्राहक कुछ हद तक कार्य को समझता है। और बस ऐसे ही:



और फिर यह पता चलता है कि काम की मात्रा का प्रारंभिक मूल्यांकन (और, तदनुसार, परियोजना का समय और लागत), जिसे डेवलपर ने अपने निष्कर्षों के आधार पर बनाया और ग्राहक को सार्वजनिक किया, जो ग्राहक वास्तव में चाहता है, उससे भिन्न है।

यदि हम एक तस्वीर को दूसरे से "घटाते" हैं, और बोलते हैं, तो बात करें, तो हमें ग्राहक की उम्मीदों और डेवलपर की योजनाओं में अंतर मिलता है। और यह अंतर बहुत महत्वपूर्ण हो सकता है:



और यहां एक संघर्ष है, जहां कानून के लिए प्रत्येक पक्ष: ग्राहक को वह नहीं मिला है जो उसने सहमत मूल्य के लिए अपेक्षित था, वे उसे "फेंक" करने की कोशिश कर रहे हैं; ठेकेदार का मानना ​​है कि उसने आदेश के साथ सबकुछ ठीक किया, और बाकी "विशलिस्ट" इसे "फेंक" करने का एक प्रयास है। इस संघर्ष को विभिन्न तरीकों से हल किया जा सकता है: या तो ग्राहक स्वीकार करेगा कि क्या है, या डेवलपर मुफ्त में सब कुछ खत्म कर देगा, या दोनों पक्ष आपसी रियायतें करेंगे। लेकिन किसी भी मामले में, पीड़ित होंगे।

इसलिए, तकनीकी कार्य का कार्य दोनों पक्षों के अभ्यावेदन के बीच अंतर को कम करना है: ग्राहक और ठेकेदार। अच्छा टीके थोड़ा अलग देता है, बुरा टीके बड़ा देता है।

हालांकि, एक बहुत महत्वपूर्ण बिंदु है: वे। कार्य को शून्य तक कम नहीं करना चाहिए और न ही करना चाहिए! मैं समझाऊंगा क्यों।

दोनों अंतर और टीके का अपना मूल्य है, और मूल्य को केवल पैसे की तुलना में अधिक मोटे तौर पर समझने की आवश्यकता है। यह पैसा, समय, खर्च की गई नसें, टूटे हुए रिश्ते आदि हैं।
अंतर की लागत शुरू में बिना शर्त सुधार की लागत है, टीके की लागत, वास्तव में, टीके की लागत है। संदर्भ की अधिक विस्तृत और विस्तृत शर्तें, इसकी लागत जितनी अधिक होगी, लेकिन कम परिमाण और अंतर की लागत, और इसके विपरीत।

यदि हम दो चरम सीमाओं पर विचार करते हैं। बस कोई काम नहीं है, बिल्कुल नहीं, अर्थात्। सामान्य तौर पर, और हमने फोटो होस्टिंग की, और ग्राहक एक ऑनलाइन स्टोर चाहता था, फिर अंतर पूरी परियोजना के बराबर होगा, और इसकी लागत परियोजना की लागत के बराबर होगी (हमें अपनी फोटो होस्टिंग को फेंकना होगा और एक स्टोर बनाना होगा)। इसके अलावा, टीके की लागत शून्य है। दूसरा चरम तब होता है जब तकनीकी कार्य स्वयं पूर्ण परियोजना है, अर्थात्। यह पूरी तरह से विस्तृत है, अर्थात् कोड, चर और सीएसएस शैलियों की लाइनों के लिए। इस मामले में, अंतर शून्य है, और टीके की लागत परियोजना की लागत के बराबर है (क्योंकि टीके पहले से ही एक कार्यान्वयन है)। और इन चरम सीमाओं के बीच वास्तविकता है, जो इस ग्राफ में परिलक्षित होती है:



नीली रेखा टीके की लागत है, यह बढ़ती विस्तार के साथ बढ़ती है, लाल रेखा अंतर की लागत है, और इसके मूल्य, इसके विपरीत, बढ़ती विस्तार के साथ घट जाती है।

नीली रेखा टीके की कुल लागत और कार्य के अंत में आने वाले परिवर्तनों को चिह्नित करती है। जैसा कि ग्राफ से देखा जा सकता है, इस कुल लागत का न्यूनतम मूल्य है। यानी कुछ बिंदु से, सही TK की तुलना में काम के अंत में ग्राहक की विशलिस्ट को ठीक करना सस्ता हो जाता है।

इसलिए एक महत्वपूर्ण निष्कर्ष: टीके को परियोजना का अच्छी तरह से वर्णन करना चाहिए, लेकिन इससे ज्यादा कुछ नहीं ।

नीचे वर्णित दृष्टिकोण सिर्फ टीके के लिए दावा करेगा कि इष्टतम के करीब विस्तार का स्तर होगा।

2. इसमें क्या होना चाहिए और क्या नहीं। भाषा

संदर्भ की शर्तें एक दस्तावेज, एक समझौते का एक हिस्सा है (यह मायने नहीं रखता है कि क्या यह मुहरों और हस्ताक्षरों के साथ एक समझौता है, या सिर्फ एक मौखिक समझौता है) जो यह दर्शाता है कि किस कार्य को किया जाना चाहिए। ToR में वर्णित सब कुछ एक उद्देश्य मूल्यांकन की संभावना के लिए अनुमति देना चाहिए। यानी इसमें वस्तुनिष्ठ मानदंड होने चाहिए जिससे यह निर्धारित किया जा सके कि कोई विशेष कार्य किया गया है या नहीं।

इसके आधार पर, यह पता चला है कि तकनीकी कार्य में डिजाइन के बारे में कोई बात नहीं होनी चाहिए। वैसे भी, कार्य तकनीकी है, कलात्मक नहीं। डिज़ाइन अपने आप को उस चीज़ के एक वस्तुनिष्ठ मूल्यांकन के लिए उधार नहीं देता है, जो दूसरा पसंद नहीं करता है, और कोई भी ऐसा मानदंड नहीं है जिसके द्वारा कोई कह सके कि कोई डिज़ाइन अच्छा है या नहीं।

कार्य के विवरण के साथ डिजाइन का कार्यान्वयन "हरे रंग में, और वह एक पेड़ होगा", एक बुरा काम और एक उत्कृष्ट कृति (और क्या विशेष रूप से दुख की बात है, दोनों विकल्प ग्राहक के लिए सुखद नहीं हो सकते हैं) हो सकते हैं। संक्षेप में, डिजाइन का वर्णन करने वाले उद्देश्य मानदंडों की पूर्ति खराब परिणाम का कारण बन सकती है।

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

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

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

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

3. टीके की धारा

3.1 सामान्य शब्द

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

3.2 परिचालन। नियुक्ति

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

3.3 कार्यशीलता

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

बहुत बार, गर्व शीर्षक के साथ दस्तावेज़ "संदर्भ की शर्तें" फ्रीलांस साइटों पर प्रकाशित किए जाते हैं, जिनमें उपरोक्त तीन बिंदु होते हैं। हालांकि, वास्तव में, यह केवल टीके का परिचय है।

३.४ नियम और परिभाषाएँ

यह खंड विश्वास दिलाता है कि ग्राहक और ठेकेदार एक ही बात कर रहे हैं।
शर्तें दो पक्षों से "दर्ज" की जा सकती हैं: ग्राहक से, उदाहरण के लिए, आप उसे समझाते हैं कि होस्टिंग और एसएमटीपी सर्वर क्या हैं, और ग्राहक से आपके लिए।

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

3.5 डेटा और सूची

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

डेटा

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

इकाई के गुणों की गणना आपको उन छोटी चीजों को नोटिस करने की अनुमति देती है, जिन्हें यदि किसी ने नहीं छोड़ा है, तो जटिलताएं हो सकती हैं।

उदाहरण के लिए, वही खबर:

• हैडर
• टेक्स्ट
• प्रकाशन दिनांक

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

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

सूचियों

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

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

3.6 विवरण पृष्ठ

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

यहां यह वर्णन करना उचित होगा कि न केवल प्रदर्शित किया जाता है, बल्कि यह भी कि कैसे। इस अर्थ में नहीं कि हम डिजाइन का वर्णन कर रहे हैं: "समाचार का शीर्षक लाल अक्षरों में प्रदर्शित किया गया है," लेकिन इस अर्थ में कि यह कैसे काम करता है: "बाईं ओर, एक विंडो आपको एक उपयोगकर्ता नाम और पासवर्ड दर्ज करने के लिए संकेत देती है।" या इस तरह: "जब आप" टिप्पणी भेजें "बटन पर क्लिक करते हैं, तो AJAX का उपयोग करके पृष्ठ पर टिप्पणी पुनः लोड किए बिना दिखाई देती है।"

क्या यहां पृष्ठ की सामग्री का वर्णन करना आवश्यक है? नहीं, आवश्यक नहीं। हम एक तकनीकी कार्य लिख रहे हैं। कैटलॉग का वर्णन करते हुए, हम इसमें सभी उत्पादों का वर्णन नहीं करते हैं? हमारा कार्य उस कार्यक्षमता का वर्णन करना है जो ग्राहक को सामग्री के साथ पृष्ठ में स्वतंत्र रूप से भरने की अनुमति देगा। यदि आप निष्पादक द्वारा साइट को सामग्री से भरने की योजना बनाते हैं, तो इसे एक अलग दस्तावेज़ में रखना बेहतर है।

स्वाभाविक रूप से, प्रत्येक पृष्ठ पर इस तरह एक स्केच जोड़ना बहुत अच्छा होगा:

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

यह दस्तावेज़ के पाठ में स्पष्ट रूप से इंगित करने के लिए सार्थक हो सकता है कि पाठ प्राथमिक है, और चित्रण केवल समझने की सुविधा के लिए हैं। हालांकि यह मुद्दा विवादास्पद है।

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

3.7 विश्वसनीयता आवश्यकताओं

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

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

3.8 होस्टिंग आवश्यकताएँ

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

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

इसमें दुभाषियों, पुस्तकालयों, पैकेजों, रत्नों, डिस्क स्थान की आवश्यकताएं, मेमोरी, smtp, पॉप, ftp, बाहरी कार्यक्रमों और अन्य चीजें जो परियोजना के लिए मायने रखती हैं, के लिए आवश्यकताएं शामिल होनी चाहिए।

3.9 सामग्री भरें

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

यदि हमें, उदाहरण के लिए, 500 तस्वीरों को कैटलॉग पर अपलोड करना चाहिए, पहले से उन्हें संसाधित किया जा रहा है, तो इसे यहां वर्णित किया जाना चाहिए।

इस खंड का वर्णन हमें एक अलग समझ के लिए चेतावनी देता है कि किसे 500 तस्वीरों में भरना चाहिए और माल के साथ कैटलॉग को भरना चाहिए।

3.10 वितरण और स्वीकृति

उन शर्तों का विवरण जिस पर काम के लिए भुगतान होना चाहिए।

विकल्प संभव है, उदाहरण के लिए, 100% भुगतान के बाद ग्राहक की मेजबानी में स्थानांतरण। या ग्राहक की वेबसाइट पर स्थानांतरित होने के बाद भुगतान और रन-इन के लिए एक सप्ताह।

वैसे, 100% भुगतान, मुझे लगता है, बग फिक्स के अंत का मतलब नहीं होना चाहिए। मेरी राय में, बग्स पर एक जीवन भर की गारंटी दी जानी चाहिए, और उन्हें हमेशा नि: शुल्क तय किया जाना चाहिए। हालांकि, मुझे लगता है, इस समस्या पर अन्य विचार होंगे।

निष्कर्ष

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

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

मुझे आलोचना सुनने में खुशी होगी और विशेष रूप से ऐसे मामलों का वर्णन जब ऐसी टीके उपयुक्त नहीं हैं।