सॉफ्टवेयर डेवलपमेंट: 3. गर्म और नरम

पिछले नोट में, मैंने निष्कर्ष निकाला कि सॉफ्टवेयर विकास एक ऐसा अनूठा क्षेत्र है जो मानव गतिविधि के "समान क्षेत्रों" के बारे में बात कर सकता है केवल विकास और प्रबंधन के चरणों से जुड़ी कुछ शर्तों की समझ को सरल बनाने के लिए किया जा सकता है।



अजीब बात है, लेकिन सॉफ्टवेयर विकास के क्षेत्र में सीधे पैदा हुए तरीके बाहर से आने वाले लोगों के समान नहीं हैं।

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

नहीं, प्रतीक्षा करें, लेकिन व्यवसाय प्रक्रियाओं के अपघटन और औपचारिकता के बारे में क्या है, जिसके बिना स्वचालित रूप से असंभव होगा, ठीक है, भवन डिजाइन की एक ही प्रक्रिया। लेकिन काम की योजना के बारे में क्या है, जिसके बिना इस तरह की परियोजना के लिए एक हजार तालिकाओं, तार्किक संरचनाओं और इंटरफेस बनाने के लिए संगठित तरीके से संभव नहीं होगा?

(चित्रण के रूप में, लेखक RuxxSilver की विशिष्ट सार्वभौमिक कार्यप्रणाली का चेहरा, जो पहली नज़र में बहुत आकर्षक और विश्वसनीय लगता है)



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

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

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

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

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

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

बहुमुखी प्रतिभा हमेशा अच्छी नहीं होती है, लेकिन यह हमेशा अच्छा लगता है।

यदि हम एक कुत्ते को प्रशिक्षित करना चाहते हैं, तो हम एक तरह से कार्य करेंगे। अगर हम कार से कहीं और जाना चाहते हैं - दूसरे को। और आपको इन दो समस्याओं को हल करने के लिए सामान्य सिद्धांतों के साथ नहीं आना चाहिए क्योंकि पहले और दूसरे मामलों में, कोई व्यक्ति किसी चीज़ को नियंत्रित करता है।

जब हम एक सॉफ्टवेयर उत्पाद बनाते हैं, तो हम मुख्य रूप से अमूर्त संस्थाओं के साथ काम कर रहे हैं जो इसे बनाते हैं, बाहरी इंटरफेस और हार्डवेयर और सॉफ्टवेयर वातावरण जिसमें यह मौजूद है।

जब हम वास्तविक दुनिया का मॉडल बनाते हैं, तो हम इसकी वस्तुओं, उनके औसत दर्जे के गुणों और उनके रिश्तों से निपटते हैं।

एक सॉफ्टवेयर उत्पाद यह सुझाव दे सकता है कि वास्तविक दुनिया के एक निश्चित हिस्से का एक मॉडल इसमें अंतर्निहित होगा। वास्तविक दुनिया, बदले में, इसका वर्णन किया जा सकता है ताकि इसका मॉडल कार्यक्रम में प्रवेश करना आसान हो।

जब हम इसे समान मानते हैं, तो हम गर्म और नरम को भ्रमित करना शुरू करते हैं।

कम से कम एक संघर्ष के कारण जो सूचना प्रौद्योगिकी की प्रकृति को प्रभावित करता है। एक कंप्यूटर और उसके प्रोग्राम कंप्यूटिंग सिस्टम, (विशेष रूप से सांख्यिकीय प्रसंस्करण) और एक कॉपी मशीन के एक बच्चे हैं।

उदाहरण के लिए: यदि हम पत्थरों के वर्गीकरण और प्रबंधन से निपटना चाहते हैं, तो हमें पत्थरों का वर्णन करने वाले डेटाबेस में एक पत्थर वर्ग या एक तालिका बनानी होगी।

कम से कम महंगे रूप में, पत्थर एकीकृत होंगे: पत्थर नंबर 1, पत्थर नंबर 2, पत्थर नंबर 3 ... असली दुनिया में समान पत्थर नहीं हैं। सभी पत्थरों का वर्णन करने के लिए आपको उन्हें पूरी तरह से पुन: पेश करने की आवश्यकता है। हम अपने सिस्टम में कई पत्थरों को पेश कर सकते हैं, वजन के आधार पर, और इसके दृष्टिकोण से, पत्थरों की एकरूपता बहुत कम हो जाएगी, यह निर्धारित करना हमारे लिए आसान होगा कि वास्तविक दुनिया में कौन सा समूह किसी विशेष पत्थर का है। कुछ कार्यों के लिए, पत्थरों का यह समूह एक ट्रक में फिट होगा या नहीं इसकी जानकारी उपयोगी हो सकती है। सवाल यह है कि विस्तार की कौन सी डिग्री उपयोगी होगी और लागत के साथ यह लाभ कितना होगा।

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

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

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

विभिन्न संगठनों और परियोजनाओं के लिए प्रयोज्यता के संदर्भ में सार्वभौमिकता असंभव है। ऐसी पोर्टेबिलिटी की डिग्री जितनी अधिक होती है, उतनी ही तकनीक अस्पष्ट सिफारिशों के एक कॉम्पैक्ट कोड के समान होती है।

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

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

और अगर कोई युवा आईटी प्रोजेक्ट मैनेजर या डेवलपमेंट टीम लीडर अब हमें लगता है कि वास्तव में 15 से 30 साल की उम्र के युवा हैं, तो एक युवा आर्किटेक्ट (जो इमारतों को डिजाइन करता है) 30-45 वर्ष की आयु सीमा में आता है और पहले "20 युवा आर्किटेक्ट्स" एल्बम खोलता है आपका विचार होगा: "और ये सभी पुराने farts कौन हैं?"। सिर्फ इसलिए कि 5-7 साल का अध्ययन और 10 साल का अभ्यास भी ख्रुश्चेव को अच्छी तरह से डिजाइन करने के लिए पर्याप्त नहीं है।

अगले लेख में, मैं नीचे एक स्तर नीचे जाना चाहता हूं और ऐसी अवधारणाओं के बल पर प्रयास करना चाहता हूं जो हमें ग्राहक और आवश्यकताओं के रूप में विरासत में मिली हैं।