किसी परियोजना पर विकास शुरू करने से पहले क्या योजना है? [बन्द है]

Question

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

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

मैं जो पूछ रहा हूं, उसका बेहतर विचार देने के लिए मुझे कैसे-

क) परियोजना को घटकों में विभाजित करें,

बी) उनकी बातचीत की योजना बनाएं, जैसे मुझे कक्षा आरेख, इकाई परीक्षण लिखना चाहिए, आदि?

कोई विचार?

Comments

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

— S.Lott 12

आपका क्लाइंट जल्द ही या बाद में चश्मा बदल देगा। मॉड्यूल इंटरैक्शन को इस तरह से प्लान करें कि परिवर्तन आपके पूरे कोड बेस को गड़बड़ न करें।

— रेनो

Answer 1

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

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

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

Comments

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

— S.Lott

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

— बेरिन लोरिट्स

Answer 2

मुझे लगता है कि अगर मैं ऐनक पर जाऊं तो बेहतर होगा

सही। अच्छा विचार।

योजना बनाई कि इससे पहले कि मैं इसे कैसे कोडित करूं, सिस्टम कैसे काम करेगा।

अच्छा। उससे ज्यादा करो।

मुख्य घटक क्या हैं,

अति उत्कृष्ट।

वे कैसे बातचीत करने जा रहे हैं,

सही बात।

मैं अभी निश्चित नहीं हूं कि मुझे क्या योजना बनानी चाहिए।

जब आप पहले से ही सामान का एक समूह सूचीबद्ध कर चुके हैं तो आप कैसे सुनिश्चित नहीं हो सकते हैं ? यदि वे चीजें हैं जो आपको चिंतित करती हैं, तो सिर्फ उन चीजों पर ध्यान क्यों न दें?

4 + 1 दृश्य मॉडल पर पढ़ें: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Zachman ढांचे पर पढ़ें: http://en.wikipedia.org/wiki/Zachman_Framework

यही आपको योजना बनाने की जरूरत है।

मुझे कैसे क) परियोजना को घटकों में विभाजित करना चाहिए,

अन्य, समान परियोजनाओं के लिए व्यापक रूप से अपनाया गया डिज़ाइन पैटर्न का उपयोग करें।

जब संदेह हो, तो विचारों के लिए J2EE ब्लूप्रिंट पढ़ें।

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

मुझे कैसे बी) उनके इंटरैक्शन की योजना बनानी चाहिए, जैसे मुझे क्लास डायग्राम, यूनिट टेस्ट आदि लिखना चाहिए?

हाँ। अच्छे विचार, सभी।

Answer 3

सबसे महत्वपूर्ण बात: चश्मा की समीक्षा करें, अधिक परिष्कृत चश्मा प्राप्त करने के लिए ग्राहक के साथ बातचीत करें।

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

तो, आपको चश्मे की समीक्षा करनी चाहिए, ग्राहक का साक्षात्कार करना चाहिए और पता लगाना चाहिए कि क्या वह / वह वास्तव में जरूरत है और चाहता है, और वहन कर सकता है, आदि।

ग्राहक के साथ परीक्षण / उपयोग के मामलों और समीक्षा का विकास करना। यदि कोई आवश्यकता परीक्षण योग्य नहीं है, तो उसे फेंक दें।

डिजाइन विकसित करें और सुनिश्चित करें कि सभी टुकड़े सही ढंग से कार्य करते हैं कि यह सिद्धांत रूप में वह करेगा जो आपको चाहिए।

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

Answer 4

कोडिंग शुरू करने से पहले आप निश्चित रूप से कुछ डिज़ाइन रखना चाहते हैं।

आपके पास एक बार, मैं आमतौर पर एक शुरुआती आर्किटेक्चर चरण करना पसंद करता हूं ताकि यह परिभाषित किया जा सके कि आपके ऐप की परतें एक साथ कैसे फिट होती हैं। इसमें सुरक्षा और लॉगिंग जैसे बैकबोन सामान शामिल होंगे।

फिर मैं 1 फीचर का निर्माण नीचे से ऊपर करता हूं ताकि आप पूरी तरह से कुछ लागू कर सकें।

फिर वहां से चले जाएं।

Answer 5

सब कुछ

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

Comments

-1 मुझे नहीं लगता कि उत्तर मददगार है और ज्यादातर मामलों में 'सब कुछ' निश्चित रूप से जाने का तरीका नहीं है।

— कीसडिज्क