CodeGym University
सीखने की प्रक्रिया
कोर्स
टास्क्स
सर्वेक्षण और क्विज़
गेम
मदद
रिमाइंडिंग शेड्यूल
समुदाय
उपयोगकर्ता
फोरम
चैट करें
लेख
सफलता की कहानियां
गतिविधि
समीक्षाएं
सब्सक्रिप्शन
लाइट थीम
सबक
समीक्षाएं
परिचय
शुरू करें
सीखना शुरू करें
अभी सीखना शुरू करें
क्वेस्ट मैप
सबक
सभी क्वेस्ट
सभी स्तर
अच्छे सॉफ्टवेयर आर्किटेक्चर के लिए मानदंड
मॉड्यूल 3
स्तर 14,
सबक 3
क्षमता अनुभवी प्रोग्रामर एक अच्छे आर्किटेक्चर को खराब आर्किटेक्चर से आसानी से बता सकते हैं, लेकिन अगर उन्हें कुछ शब्दों में इसका वर्णन करने के लिए कहा जाए, तो वे ऐसा करने में सक्षम होने की संभावना नहीं रखते हैं। अच्छी वास्तुकला और एक परिभाष
खराब सॉफ्टवेयर आर्किटेक्चर के लिए मानदंड
मॉड्यूल 3
स्तर 14,
सबक 4
खराब डिजाइन के लिए मानदंड जीवन काफी सरलता से काम करता है: अक्सर, स्मार्ट होने के लिए, आपको बस बेवकूफी करने की ज़रूरत नहीं है। यह सॉफ्टवेयर विकास पर भी लागू होता है: ज्यादातर मामलों में, कुछ अच्छा करने के लिए, आपको इसे बुरी तरह से नहीं करना
मॉड्यूलर सॉफ्टवेयर आर्किटेक्चर
मॉड्यूल 3
स्तर 14,
सबक 5
6.1 अपघटन मानदंडों की विविधता के बावजूद, बड़ी प्रणालियों के विकास में मुख्य कार्य प्रणाली की जटिलता को कम करने का कार्य है । जटिलता को कम करने के लिए, भागों में विभाजन के अलावा और कुछ भी आविष्कार नहीं किया गया है। कभी-कभी, सादगी के लिए, इसे
सही सॉफ्टवेयर अपघटन
मॉड्यूल 3
स्तर 14,
सबक 6
पदानुक्रमित अपघटन आपको कभी भी अपने आवेदन के लिए कक्षाएं लिखना तुरंत शुरू नहीं करना चाहिए। पहले इसे डिजाइन करने की जरूरत है। डिजाइन एक विचारशील वास्तुकला के साथ समाप्त होना चाहिए। और इस आर्किटेक्चर को प्राप्त करने के लिए, आपको सिस्टम को लगात
सॉफ्टवेयर मॉड्यूल के बीच कपलिंग को कैसे ढीला करें
मॉड्यूल 3
स्तर 14,
सबक 7
8.1 अपघटन ही सब कुछ है स्पष्टता के लिए, एक अच्छे लेख "ऑब्जेक्ट-ओरिएंटेड सिस्टम्स का डिकूप्लिंग" से एक तस्वीर, जिसमें मुख्य बिंदुओं पर चर्चा की जाएगी। क्या आपको अभी भी लगता है कि एप्लिकेशन आर्किटेक्चर डिजाइन करना आसान है? 8.2 इंटरफेस, कार्या
निर्भरता उलटा
मॉड्यूल 3
स्तर 14,
सबक 8
9.1 निर्भरता उलटा याद रखें, हमने एक बार कहा था कि सर्वर एप्लिकेशन में आप केवल स्ट्रीम नहीं बना सकते हैं new Thread().start()? केवल कंटेनर को धागे बनाना चाहिए। अब हम इस विचार को और भी विकसित करेंगे। सभी वस्तुओं को भी केवल कंटेनर द्वारा ही बन
सॉफ्टवेयर मॉड्यूल को जोड़ने के वैकल्पिक तरीके
मॉड्यूल 3
स्तर 14,
सबक 9
संदेश के साथ प्रत्यक्ष निर्भरता को बदलना कभी-कभी एक मॉड्यूल को केवल दूसरों को सूचित करने की आवश्यकता होती है कि इसमें कुछ घटनाएँ/परिवर्तन हुए हैं, और इससे कोई फर्क नहीं पड़ता कि बाद में इस जानकारी का क्या होता है। इस मामले में, मॉड्यूल को "
सॉफ्टवेयर जीवन चक्र
मॉड्यूल 3
स्तर 15,
सबक 0
एक सॉफ्टवेयर उत्पाद के जीवन चक्र के चरण उच्च-गुणवत्ता वाले सॉफ़्टवेयर के विकास के लिए कई कारकों की आवश्यकता होती है: एक योग्य टीम, कार्यप्रवाह योजना, ग्राहकों की अपेक्षाओं के साथ उत्पाद अनुपालन, समय सीमा को पूरा करना। 1. आवश्यकता विश्लेषण इ
झरना - झरना मॉडल
मॉड्यूल 3
स्तर 15,
सबक 1
कैस्केड मॉडल डिवाइस जलप्रपात मॉडल, जिसे जलप्रपात के रूप में भी जाना जाता है, सॉफ्टवेयर विकास के लिए सबसे प्रसिद्ध दृष्टिकोणों में से एक है। मॉडल के लेखक विंस्टन रॉयस हैं। 1970 में, उन्होंने एक लेख में इसके फायदे और नुकसान का विवरण देते हुए
फुर्तीली विकास पद्धति - फुर्तीली
मॉड्यूल 3
स्तर 15,
सबक 2
चंचल मॉडल लचीली (फुर्तीली) कार्यप्रणाली वर्कफ़्लो को कई छोटे चक्रों में स्थानांतरित करके सॉफ़्टवेयर विकास में जोखिम को कम करने में मदद करती है। इन चक्रों को पुनरावृत्ति कहा जाता है और आमतौर पर दो से तीन सप्ताह तक रहता है। एक पुनरावृति एक छो
स्क्रम का परिचय
मॉड्यूल 3
स्तर 15,
सबक 3
स्क्रम का इतिहास 1970 में विंस्टन रॉयस की "मैनेजिंग द डेवलपमेंट ऑफ लार्ज सॉफ्टवेयर सिस्टम्स" रिपोर्ट के प्रकाशन के बाद से, कई लोगों ने ऐसी पद्धति खोजने की कोशिश की है जो जलप्रपात विकास मॉडल के नुकसान को खत्म कर सके। "झरना" का एक विकल्प स्क्
स्क्रम के साथ काम करना
मॉड्यूल 3
स्तर 15,
सबक 4
प्रयोक्ता कहानी विकास में सॉफ्टवेयर के लिए आवश्यकताओं को बताने के लिए उपयोगकर्ता कहानियां एक प्रभावी तरीका हैं। ऐसी कहानियों में सॉफ़्टवेयर के उपयोगकर्ता की ओर से संक्षिप्त सलाह होती है। चूँकि स्क्रम कार्यप्रणाली में, लक्ष्य निर्धारित करना
और दिखाएं
1
...
30
31
32
33
34
35
Please enable JavaScript to continue using this application.