🙋🏼 🏠 🤰 सूचना प्रणाली के डिजाइन पर कुछ नोट्स 🔦 👶 👧🏻

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

डिज़ाइन प्रोग्रामर के लिए नहीं है

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

प्रिय प्रोग्रामर, यह पता लगाने के लिए कि एक सिस्टम को क्या करना चाहिए, आपको सी # या जावा को जानने की जरूरत नहीं है, बल्कि एक विषय क्षेत्र का मालिक होना चाहिए। लॉजिस्टिक सिस्टम को डिजाइन करने के लिए, आपको एक लॉजिस्टिक होना चाहिए: इस क्षेत्र में या कई संबंधित, समान क्षेत्रों में अनुभव होना चाहिए। इसलिए, ऐसे व्यापारिक विश्लेषक हैं जिनका कार्य प्रणाली के कार्यात्मक स्वरूप को निर्धारित करना है।

सर्वोत्तम रूप से, ग्राहक 30-50% आवश्यक जानकारी देगा, बाकी को स्वतंत्र रूप से सोचा जाना चाहिए। और सोचने के लिए अत्यंत महत्वपूर्ण है। सबसे पहले, ग्राहक को यह नहीं पता कि वह क्या चाहता है! एक नियम के रूप में, एक व्यवसाय मॉडल का एक संयुक्त विकास होता है, और उसके बाद ही कार्यों की एक सूची संकलित की जाती है।

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

चंचल नोट्स

क्या चंचल एक नया धर्म है?

चर्चा विषय चंचल बनाम डिजाइन तकनीक (झरना, झरना, झरना) धार्मिक कट्टरपंथियों के बीच विवाद की तरह है! लेख एजाइल के बारे में बिल्कुल नहीं था, लेकिन सभी टिप्पणियां "लचीली" लोगों के बारे में थीं। दोस्तों! खैर, क्या वास्तव में व्यापक दिखना और यह देखना असंभव है कि दोनों तरीकों के लिए सूर्य के नीचे एक जगह है!

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

एजाइल हर जगह उपयुक्त नहीं है, जैसे डिजाइन तकनीक

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

दूसरी ओर, आप लचीले प्रौद्योगिकियों पर काम करने के लिए पर्याप्त ग्राहक कहां पाते हैं? बाजार पर 70-80% आदेश सरकारी एजेंसियां हैं जो मानक डिजाइन प्रौद्योगिकी का उपयोग करते हैं। इसके अलावा, GOST 34 के अनुसार। और वे इसके लिए अच्छा भुगतान करते हैं।
इसके अलावा, इन विधियों को एक विकास में जोड़ा जा सकता है: कोर को डिजाइन तकनीक का उपयोग करके बनाया गया है, और कुछ भागों को परीक्षण और त्रुटि (एग्री) द्वारा बनाया गया है। खैर, सब कुछ अग्रिम में सोचना संभव नहीं है। इसके अलावा, डिजाइन तकनीक में लचीलापन है: परीक्षण ऑपरेशन जैसी कोई चीज है, जिसके दौरान बहुत कुछ बदल सकता है।

चुस्त है कि डेवलपर्स कैसे सोचते हैं

मैं हर किसी के लिए वाउच नहीं कर सकता, लेकिन ऐसा लगता है कि प्रोग्रामर "लचीले ढंग से" सोचते हैं, फुर्तीली उनकी सोच की संरचना को पूरा करती है! आखिरकार, प्रोग्रामिंग सर्वश्रेष्ठ समाधानों के लिए एक निरंतर खोज है। आप कार्य पर बैठते हैं, आप अभी भी नहीं जानते हैं कि इसे कैसे हल किया जाना चाहिए। आप न तो अग्रिम अनुमान लगा सकते हैं, न ही परिणाम, और न ही समय सीमा (हाँ, आप डेवलपर्स की समय सीमा 6-10 गुना गुणा करते हैं और यह एकमात्र तरीका है जिससे आपको वास्तविक तस्वीर मिलती है, क्योंकि वे परीक्षण और सुधार के बारे में भूल गए)। यह कई प्रोग्रामर्स की सोच है, क्योंकि वे रचनात्मक व्यक्ति हैं। इसलिए, आपको रचनात्मक व्यक्तियों को प्रोजेक्ट बोरियत में शामिल होने के लिए मजबूर करने की आवश्यकता नहीं है। ऐसा करने के लिए, विश्लेषक, परियोजना प्रबंधक हैं।

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

लेकिन कभी-कभी ग्राहक को ऐसा कहना चाहिए: हम नई चीजें करते हैं, इसलिए हम समय, लागत या परिणाम की भविष्यवाणी करने के लिए तैयार नहीं हैं। क्या आप सहमत हैं? फिर हम करते हैं। यह कम से कम ईमानदार है।

हमेशा अपने सिर पर हाथ फेरें

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

किसी चीज़ की आलोचना करने के लिए, आपको उसका अध्ययन करने की आवश्यकता है।

जब या तो डिजाइन तकनीक या एजाइल की आलोचना करते हैं, तो आलोचकों को शायद ही कभी उनकी नाराजगी का विषय पता होता है। बहुत कम लोग हैं जिन्होंने वास्तव में अध्ययन किया है (मानकों सहित: GOST, आईएसओ, IEEE) और डिजाइन तकनीक को गंभीरता से लागू करने की कोशिश की। लेकिन उसके आलोचक काफी हैं। बहुत कम टीमें जो वास्तव में सफल हैं (ताकि क्लाइंट संतुष्ट हो गया!) चुस्त लागू करें, लेकिन पर्याप्त "प्रचारक" हैं।

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

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

लेखक द्वारा अन्य लेख पढ़ें:

सूचना प्रणाली के डिजाइन पर कुछ नोट्स