गैर-आईटी प्रबंधक को आवश्यक विरासत सॉफ्टवेयर के दीर्घकालिक रखरखाव और विकास को कैसे सुरक्षित करना चाहिए?

Question

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

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

हार्डवेयर कोई समस्या नहीं है - हम आधुनिक सर्वर पर बहुत प्रभावी ढंग से अनुकरण करने में सक्षम हैं। यदि COBOL और BASIC आधुनिक भाषाएं थीं, तो हम वह जोखिम उठाने के लिए तैयार होंगे, जिसे हम अपने वर्तमान सलाहकारों के लिए प्रतिस्थापन प्राप्त कर सकते हैं।

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

संक्षेप में, गैर-आईटी प्रबंधकों के रूप में, हम इस परिवर्तन का सबसे अच्छा प्रबंधन कैसे कर सकते हैं?

Comments

आउच! बेसिक और कॉबोल?!? मैं रिटायरमेंट होम की कोशिश करूंगा। क्या आपने अपने सॉफ़्टवेयर को "आधुनिकीकरण" करने के बारे में सोचा है?

— B12овиЈ

बस जोड़ने के लिए: उत्पादक, पुरस्कृत कैरियर, बेसिक जैसी एक पुरानी, ​​गैर-सेक्सी भाषा में। - बुनियादी और उत्पादक, पुरस्कृत कैरियर एक वाक्य में साथ नहीं चलते हैं

— BЈови

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

— निमचम्पस्की

मैं इस पर @ BЈовић से सहमत होने जा रहा हूं। कम से कम भविष्य के प्रमाण के लिए आपको अपने सॉफ़्टवेयर को आधुनिकीकरण करने पर विचार करना चाहिए, जैसे कि प्राचीन और कोबोल के रूप में प्राचीन के लिए जीवन समर्थन खोजने की कोशिश करना। अभी के लिए आपको कुछ पुराने या हिपस्टर बच्चे मिल सकते हैं, जो आपके लिए कोड कर सकते हैं, लेकिन जैसे-जैसे साल बीतते जाएंगे और प्रतिमान बदलते जाएंगे, ये प्रतिभाएं लुप्तप्राय प्रजातियां बन जाएंगी, जो आपके सिस्टम के धीमे और स्थिर निधन का कारण बनेंगी। मात्र तथ्य यह है कि आप मुश्किल से प्रोग्रामर पा सकते हैं अब एक लाल झंडा होना चाहिए कि इसके बदलाव के बारे में समय हो।

— मारू

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

— रामहुंड

Answer 1

ऐसा लग सकता है कि "आईटी सपोर्ट फर्म के लिए एक बिजनेस मॉडल होना चाहिए जो इस तरह से विरासत प्लेटफार्मों पर ध्यान केंद्रित करता है", लेकिन व्यक्तिगत रूप से मुझे लगता है कि आपके हिस्से में सिर्फ इच्छाधारी सोच है क्योंकि यह उन चुनौतियों का "हल" करेगा जो आप एक में सामना करते हैं। एक तीव्र वार में।

पुराने वातावरण में डटे रहना आगे बढ़ने का रास्ता नहीं है। और मैं किसी भी कंपनी के जीवन को दांव पर लगाने की कोशिश करने पर किसी भी कंपनी के जीवन को दांव पर नहीं लगाऊंगा, जो कि अभी के लिए, आप वह कर सकते हैं जो आप स्पष्ट रूप से नहीं कर सकते।

इसलिए आपके द्वारा पूछे गए वास्तविक प्रश्न का उत्तर नहीं है, लेकिन न्यूनतम प्रवासन के जोखिमों को कम करते हुए आप कैसे आगे बढ़ सकते हैं, इस बारे में ईमानदार सलाह।

"कैसे अपनी पवित्रता खोने के लिए एक जमीन को फिर से लिखना फिर से लिखना जीवित रहने के लिए"

लंबे समय तक बिना किसी वास्तविक परिणाम के एक लंबी माइग्रेशन परियोजना की त्रुटि न करें। पढ़ें "कैसे अपने विवेक खोने wihtout एक जमीन-अप पुनर्लेखन जीवित रहने के लिए"

मैं इस बात पर जोर नहीं दे सकता कि उस लेख में किस तरह की सलाह ने मुझे इस तरह की परियोजनाओं को "पुराने" तरीके से जलाने के बाद इसी तरह की समस्याओं से निपटने / संपर्क करने में मदद की है।

स्वचालित परीक्षण सेट करें

यदि आपको यह पहले से ही नहीं मिला है (कभी क्यों नहीं?), तो अपने वर्तमान प्रोग्रामर से अपने अनुप्रयोगों के लिए एक स्वचालित परीक्षण हार्नेस प्राप्त करें।

स्वचालित परीक्षण सूट में आपके अनुप्रयोगों के सभी कार्यात्मक क्षेत्र शामिल होने चाहिए। यह व्यक्तिगत परीक्षण मामलों के "जब_X_then_Y" नियमों में वर्तमान कामकाजी विशिष्टताओं को दस्तावेज में बदल देगा। यह आपके मौजूदा कोड को मौजूदा कार्यक्षमता को तोड़ने से रोकने के साथ-साथ एक नए वातावरण में किसी भी प्रवास का समर्थन करने में दोनों को बदलने में मदद करेगा।

जैसा कि आप COBOL और BASIC के साथ काम कर रहे हैं, परीक्षण सूट शायद एकीकरण परीक्षणों के स्तर पर होना चाहिए: इनपुट फ़ाइलों / डेटाबेस के एक "निश्चित" सेट पर काम करना और विशिष्ट कार्यक्रमों (COBOL) और के आउटपुट फ़ाइलों / परिवर्तित डेटाबेस सामग्री की जाँच करना / या अनुप्रयोग। आपके सॉफ़्टवेयर के बुनियादी हिस्सों के लिए इसका मतलब हो सकता है कि कमांड लाइन मापदंडों को जोड़ने के बिना उन्हें (G) UI हस्तक्षेप के कुछ कार्य करने के लिए, या (G) UI आधारित स्वचालित परीक्षण उपकरण प्राप्त करना।

गणना और अन्य एल्गोरिदम को अलग करें

यहां तक ​​कि कोबोल एक मुख्य कार्यक्रम से कॉल करने योग्य उप कार्यक्रमों की धारणा का समर्थन करता है। सभी आयात गणना और अन्य एल्गोरिदम को अलग-अलग कार्यक्रमों या मॉड्यूल में अलग करें। लक्ष्य कार्यक्रमों / मॉड्यूलों का एक पुस्तकालय बनाना है / जो कुछ भी है जो इनपुट को इकट्ठा करने और आउटपुट बनाने के लिए अलग-अलग काम करता है।

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

"वर्तमान" वातावरण में अनुप्रयोगों का एक नया सेट शुरू करें

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

ऐसा करने के लिए, अपने चुने हुए वातावरण में पारंगत होने के लिए नए प्रोग्रामर प्राप्त करें। सभी महत्वपूर्ण गणनाओं और एल्गोरिदम को अलग-अलग कक्षाओं और / या पैकेजों में अलग करने और उन्हें इंटरफेस के पीछे छिपाने के लिए पहले दिन से इसे प्राथमिकता दें। अपने नए एप्लिकेशन को बताने के लिए निर्भरता इंजेक्शन (सबसे सस्ता प्रकार का DIY निर्भरता इंजेक्शन का उपयोग करें) जो गणना करने के लिए तुरंत / उपयोग करने के लिए कक्षाएं लेता है।

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

किसी भी आगे मत जाओ कि अनुप्रयोगों की स्थापना और शायद सबसे महत्वपूर्ण इनपुट / आउटपुट फ़ंक्शन सेट करें जो आपके COBOL / BASIC "पुस्तकालय" से एक गणना का उपयोग करता है।

अपने COBOL / बुनियादी "पुस्तकालय" को एकीकृत करें

अपने नए परिवेश से अपने COBOL / BASIC "पुस्तकालय" को कॉल करने का तरीका जानें। इसमें एक पैरामीटर फ़ाइल या डेटाबेस टेबल सेट करना, एक COBOL / BASIC प्रोग्राम निष्पादित करना, जो आपके द्वारा पहले स्थापित COBOL / BASIC लाइब्रेरी को लपेटता है। यदि आप भाग्यशाली हैं तो आपका संस्करण DLIC के निर्माण के लिए अनुमति दे सकता है जिसे सीधे कहा जा सकता है।

अपने नए परिवेश में कक्षा को लागू करें जो COBOL / BASIC "लाइब्रेरी" कहलाएगी और उसी परीक्षा का उपयोग करते हुए इसमें से बिल्ली का परीक्षण करेगी जो पुराने वातावरण के टेस्ट हार्नेस में हैं, लेकिन अब नए वातावरण में यूनिट टेस्ट के रूप में ।

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

लेकिन फिर से: पिछले चरण से सबसे महत्वपूर्ण एकल द्वारा उपयोग की जाने वाली गणना (नों) के लिए इकाई परीक्षणों को जोड़ने से आगे मत जाओ।

मांस पुनरावृत्तियों में नए अनुप्रयोगों

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

पुनरावृत्तियों में मुख्य पुस्तकालय माइग्रेट करें

और अंत में अपने COBOL / BASIC "पुस्तकालय" में गणना और एल्गोरिदम को माइग्रेट करें, उन्हें अपने नए वातावरण में फिर से लागू करें। फिर, अपनी पवित्रता को बनाए रखने के तरीके के रूप में इसे (इकाई) परीक्षणों का उपयोग करके पुनरावृत्त करें।

Comments

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

— फिलिप

@Philipp: भले ही मैंने यह कहा था कि मैं उनके वास्तविक सवाल का जवाब नहीं दे रहा था। मुझे यकीन है कि ओपी जानता है कि Google का उपयोग कैसे किया जाए और ओपी के लिए मेरे जवाब में कुछ शोध शुरू करने के लिए पर्याप्त खोज शब्द हैं - या बेहतर अभी तक - वर्तमान प्रोग्रामर ऐसा करते हैं। ओपी को संबोधित करते हुए अपने स्वयं के उत्तर को जोड़ने के लिए स्वतंत्र महसूस करें क्योंकि आपको लगता है कि यह करने की आवश्यकता है। हेक, अगर आपने किया तो भी अप-डाउन कर सकते हैं ...

— मार्जन वेनमा

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

— MSalters

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

— user105977

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

— मार्जन वेनमा

Answer 2

ऐसा लगता है कि यह एप्लिकेशन आपके व्यवसाय के लिए "मूल" है। उन मामलों में जहां एक प्रणाली या प्रक्रिया वह है जो आपका व्यवसाय है जो आपके स्वयं के कस्टम समाधान के लिए एक मामला है।

आपने यह बात बताई। दुर्भाग्य से, अपनी तकनीकों को अपडेट करने के बाद आप जो लंबा समय दे चुके हैं, यह एक अत्यंत कठिन उपक्रम होगा।

मैं एक दो मार्गों की सिफारिश करूंगा।

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

सौभाग्य, आप पर काबू पाने के लिए लगभग 20 साल की विरासत है। यह सस्ता, आसान या साफ नहीं होगा।

Comments

FYI करें: सॉफ्टवेयर की दुनिया में 20 साल 2 या 3 मानव पीढ़ियों के बराबर है। बहुत लंबा समय है। तकनीकी दृष्टि से, BASIC और COBOL एक संग्रहालय में रखे जाने के लिए पर्याप्त पुराने हैं ...

— Radu Murzea

मैं वास्तव में 20 वर्षों से प्रोग्रामिंग कर रहा हूं और COBOL मेरे अनुभव को काफी कम करता है।

— बिल लीपर

Answer 3

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

हां, इस दृष्टिकोण की स्पष्ट लागत नए प्रोग्रामरों को काम पर रखने की स्पष्ट लागतों से अधिक हो सकती है, लेकिन अपने स्वयं के प्रवेश द्वारा आप एक गैर-आईटी प्रबंधक हैं और ऐसे परिदृश्यों को दूर करना आसान है जिसमें आप ऐसे निर्णय लेते हैं जो अंततः आपकी कंपनी की लागत से अधिक हो आउटसोर्सिंग की स्पष्ट लागत।

Comments

दूसरे पैराग्राफ में कहा गया है कि वे पहले ही आपके द्वारा सुझाए गए काम कर चुके हैं: उन्होंने सभी तीन फर्मों की पहचान की है जो लाभ प्रशासन सॉफ्टवेयर प्रदान करते हैं। उनमें से कोई भी योग्य नहीं था।

— एमएसल्टर्स

मैंने सुझाव दिया कि वे सॉफ्टवेयर प्रदान करने के लिए एक फर्म नहीं ढूंढते, बल्कि एक निरंतर लाभ प्रशासन प्रणाली सेवा प्रदान करते हैं ।

— उच्च प्रदर्शन मार्क