प्रोग्रामिंग प्रतिमान और रखरखाव डेवलपर [बंद]

Question

मैं सॉफ्टवेयर इंजीनियरिंग के तथ्य, और पतन, पढ़ रहा था, जिसमें रखरखाव का एक खंड है। चूंकि, मैं वर्षों से एक रखरखाव डेवलपर हूं, इसलिए मुझे बहुत दिलचस्प तथ्य प्रस्तुत किए गए। यहाँ तीन है।

• तथ्य 41: रखरखाव में आमतौर पर सॉफ्टवेयर लागत का 40 से 80 प्रतिशत (औसत, 60 प्रतिशत) खर्च होता है। इसलिए, यह संभवतः सॉफ्टवेयर का सबसे महत्वपूर्ण जीवन चक्र चरण है।
• तथ्य 42: लगभग 60 प्रतिशत सॉफ्टवेयर रखरखाव लागत के लिए संवर्धन जिम्मेदार है। त्रुटि सुधार लगभग 17 प्रतिशत है। इसलिए, सॉफ्टवेयर रखरखाव काफी हद तक पुराने सॉफ्टवेयर में नई क्षमता जोड़ने के बारे में है, इसे ठीक नहीं करने के लिए।
• तथ्य 45: बेहतर सॉफ्टवेयर इंजीनियरिंग विकास अधिक रखरखाव की ओर जाता है, कम नहीं।

यह एक काउंटर-सहज ज्ञान युक्त था, यह बताता है कि अच्छे सॉफ़्टवेयर का अधिक रखरखाव है, क्योंकि इसे बदलना आसान है। इसलिए, यह लंबे समय तक उपयोग में रहता है, जिससे हाँ में और अधिक परिवर्तन होते हैं।

कौन से प्रतिमान (जैसे कार्यात्मक, वस्तु-उन्मुख, प्रक्रियात्मक) में सबसे अच्छा रख-रखाव है, और क्या इसे वापस करने के लिए कोई शोध है?

Comments

मेरे पास तथ्यों और विसंगतियों की एक प्रति है, और प्रत्येक तथ्य (और पतन) के लिए, विभिन्न प्रकाशनों के उद्धरण हैं जो इसका समर्थन करते हैं। मेरे पास एक कॉपी काम नहीं है, लेकिन क्या उन उद्धरणों में से कोई भी रखरखाव पर प्रतिमान के प्रभाव पर चर्चा करता है?

— थॉमस ओवेन्स

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

— KaizenSoze

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

— थॉमस ओवेन्स

Answer 1

मुझे लगता है कि आप पाएंगे कि कार्यात्मक, OO और प्रक्रियात्मक जैसे प्रतिमान संभवतः सार्थक रूप से सॉफ़्टवेयर में स्थिरता के साथ नहीं हैं।

आपको निम्नलिखित बातें और अधिक स्पष्ट रूप से सॉफ्टवेयर में स्थिरता के साथ मिल सकती है:

• आवश्यकताओं का स्तर इकट्ठा करना और इंजीनियरिंग की आवश्यकताएं

• अच्छा विकास अभ्यास: (ढीली युग्मन, उच्च सामंजस्य, इकाई परीक्षण, YAGNI ...)

• कुशल और योग्य सॉफ्टवेयर इंजीनियर (वे एक मोरन के रूप में 10 गुना अधिक मूल्य के हैं)

• योग्य और संगठित तकनीकी क्यूए टीम

• सक्षम परियोजना प्रबंधकों के नेतृत्व में अच्छा परियोजना प्रबंधन (कुशल सॉफ्टवेयर डेवलपर्स IMHO की तुलना में कठिन भी)

• अच्छा उत्पाद स्वामी या अनुप्रयोग प्रबंधक, मजबूत नेतृत्व, लंबी अवधि की दिशा, परियोजना टीमों के लिए अच्छी प्रतिक्रिया, समग्र दृष्टि।

Comments

+1 मैं सूची में अच्छे दस्तावेज जोड़ना चाहता हूं

— treecoder

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

— मटकाव

Answer 2

यह एक काउंटर-सहज ज्ञान युक्त था, यह बताता है कि अच्छे सॉफ़्टवेयर का अधिक रखरखाव है, क्योंकि इसे बदलना आसान है। इसलिए, यह लंबे समय तक उपयोग में रहता है, जिससे हाँ में और अधिक परिवर्तन होते हैं।

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

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