भूल गया डिजाइन चरण

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



इससे बचने और आधे साल की योजना नहीं बनाने के लिए क्या किया जा सकता है?



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



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



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



अपने प्रोजेक्ट को कम से कम न्यूनतम करने के लिए दस्तावेज़ करने का प्रयास करें और मुझे लगता है कि आप खुद ही बेहतर समझने लगेंगे कि आप क्या कर रहे हैं



वर्णन में पर्याप्त, चलो अभ्यास करने के लिए मिलता है। पूरी परियोजना को कई भागों में विभाजित करें।



आरंभिकता - यहाँ आप चर्चा करते हैं कि आप मोटे तौर पर क्या प्राप्त करना चाहते हैं, विचारों का आदान-प्रदान करें।

डिजाइन - यहां वह मंच है जिसे भुला दिया जाता है। इसके बारे में और नीचे।

कोडिंग - मुझे आशा है कि सब कुछ स्पष्ट है :)

परीक्षण - लेकिन यह चरण डिजाइन के बिना नहीं होता है, यदि आप नहीं जानते कि आप क्या प्राप्त करना चाहते हैं, तो आप कैसे जांचते हैं कि आपको क्या मिला?

एकीकरण - हम परियोजना का शुभारंभ करते हैं।



अब डिजाइन के बारे में अधिक।

एक छोटी टीम के मामले में, मैं किसी प्रकार के सुपर परिष्कृत सॉफ्टवेयर का उपयोग करने का प्रस्ताव नहीं करता हूं। चलो बस विकी। मैंने अपने लिए DokuWiki को चुना, आप किसी अन्य का उपयोग कर सकते हैं। हम परियोजना प्रबंधन के लिए IEEE मानकों का उपयोग करेंगे, हालांकि हम इसे शब्दशः पालन नहीं करेंगे।

पहला दस्तावेज जो हमें चाहिए वह है SPMP (सॉफ्टवेयर प्रोजेक्ट मैनेजमेंट प्लान) उर्फ ​​"सॉफ्टवेयर प्रोजेक्ट मैनेजमेंट प्लान"। यहां हम इंगित करते हैं कि परियोजना में क्या जिम्मेदार है, प्रबंधन कैसे होगा, आप किन तरीकों का उपयोग करेंगे। उन लोगों के लिए जिन्हें विशिष्ट उदाहरणों की आवश्यकता है, मैं आपको अंत में कुछ लिंक दूंगा।

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

अब हम SCMP (सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट प्लान), उर्फ़ “सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट प्लान” पर चलते हैं। यहां मैं शायद ही कभी मानक का पालन करता हूं, लेकिन अभी भी एक दस्तावेज की आवश्यकता है। यह वर्णन करता है कि आप किस तरह के सॉफ़्टवेयर का उपयोग करते हैं, कैसे संस्करणों का आदेश दिया जाता है। विधानसभाएं कैसी हैं, आदि।

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



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



अब कुछ लिंक:

ओपन सोर्स एमओओआरपीजीपीजीसी प्रलेखन कुछ दस्तावेजों को भरने का एक व्यावहारिक उदाहरण है।

SPMP (संलग्न) यहाँ



मूल



यदि वांछित है, तो सभी मानक Google हैं।