आखिर अस्पताल क्यों?

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

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

अंदर कार्यक्रम कोड (लेकिन कोई भी इसे देखता है)

यदि हम सॉफ्टवेयर विकसित करते हैं तो अस्पताल को इससे क्या लेना-देना है?

और यहाँ यह है, प्रिय डेवलपर्स, अधिकारियों, विश्लेषकों, परीक्षकों।

नहीं सॉफ्टवेयर आप विकसित कर रहे हैं ... Android ले लो, यह सॉफ्टवेयर है। और अगर, उदाहरण के लिए, आपके पास एक लेखा प्रणाली है, तो आप पहले से ही न केवल सॉफ्टवेयर के साथ काम कर रहे हैं, बल्कि एक सूचना प्रणाली के साथ भी।

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

सूचना प्रणाली (क्या यह सिर्फ सॉफ्टवेयर है?)

और अंत में, हम 90 के दशक की एक प्रणाली की परिभाषा को याद करते हैं, जिसे किसी ने रद्द नहीं किया है:

स्वचालित प्रणाली: कर्मियों से युक्त एक प्रणाली और इसकी गतिविधियों के लिए स्वचालन उपकरण का एक सेट जो स्थापित कार्यों को करने के लिए सूचना प्रौद्योगिकी को लागू करता है।

GOST 34.003-90। सूचना प्रौद्योगिकी। स्वचालित प्रणालियों के लिए मानकों का एक सेट। स्वचालित प्रणाली। नियम और परिभाषाएँ।

यही है, पहली जगह में आईपी लोग हैं, प्लस टेक्नोलॉजी जो उनकी गतिविधियों को स्वचालित करने में मदद करती है, न कि इसके विपरीत।

अस्पताल कैसे डिजाइन करें

कल्पना करें कि आप एक निर्माण संगठन हैं, एक ग्राहक आपके पास आता है और ऐसी जगह एक अस्पताल बनाने के लिए कहता है। आप तुरंत ईंटें चलाने के लिए दौड़ते हैं या ...? यदि आप देखते हैं कि सूचना प्रणाली कितनी बार बनाई गई है, तो यह है: कलाकार तुरंत "कंक्रीट और खरीद ग्लास पैकेट के साथ हस्तक्षेप करना" शुरू करते हैं। जैसे, यह उस तरह से काम नहीं करेगा - हम पुनर्निर्माण करेंगे! हम तब तक पुनर्निर्माण करेंगे जब तक हम वांछित परिणाम प्राप्त नहीं करते हैं।

हालांकि, यदि आप एक गंभीर संगठन हैं, तो पहले ग्राहक को निर्माण के लिए एक डिज़ाइन प्रदान करें। क्या आप सहमत हैं? और यह सूचना प्रणाली के साथ गलत क्यों है? शायद यह निर्माण और सॉफ्टवेयर विकास के बीच अंतर नहीं है, लेकिन यह कि एक ही अस्पताल के मामले में, वे बहुत सोचते हैं, योजना बनाते हैं, और फिर निर्माण करते हैं, और वे पहले सॉफ्टवेयर का विकास करते हैं और फिर सोचते हैं। ऐसा नहीं है कि क्यों आप एक निर्माण स्थल पर एक ही प्रवासी श्रमिकों के बारे में krivoruky प्रोग्रामर के बारे में बहुत कुछ सुनते हैं? डेवलपर्स के विपरीत, बिल्डर्स प्रोजेक्ट पर काम करते हैं।

यह हमेशा एक परियोजना के बिना ऐसा है, भले ही यह दिखाई न दे

अब हम डिजाइन प्रक्रिया पर अधिक विस्तार से विचार करते हैं। इसके कई चरण होते हैं। हमें कई चरणों से गुजरने की आवश्यकता क्यों है, एक बार में क्यों नहीं? स्पष्टता के लिए, मैं एक स्कूल का उदाहरण दूंगा ... स्कूल में कितने वर्षों से गुणन के संचालन का अध्ययन किया गया है? आप एक या दो महीने कहते हैं, और आप मौलिक रूप से गलत होंगे। हां, 5 को 6 से कैसे गुणा करें, एक सप्ताह में पास करें। एक निश्चित समय को गुणा तालिका सिखाई जाती है। और अंशों का गुणन, एक डिग्री के साथ संख्या, लघुगणक, कोष्ठक में अभिव्यक्तियाँ, जटिल संख्याएँ, एक डिग्री तक बढ़ कर कितने लोग अध्ययन करते हैं? लगभग सभी स्कूल वर्ष! यह पता चला है कि हम हर साल अलग-अलग कोणों से एक ही गुणन का अध्ययन करते हैं।

और यह पहली कक्षा में क्यों नहीं पढ़ा जा रहा है?

तो, सीखने और डिजाइन करने की कोई भी प्रक्रिया चक्रीय है। सबसे पहले, हमें संख्याओं के बारे में सामान्य अवधारणाएं मिलीं, फिर हमने सीखा कि उनके साथ सरल क्रियाएं कैसे की जाती हैं, फिर हमने अंशों के बारे में सीखा और सीखा कि उनके साथ कैसे काम किया जाए, और इसी तरह।

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

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

यह अच्छी तरह से देखा जा सकता है, लेकिन केवल एक छोटा सा हिस्सा है

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

अब अंत में डिजाइन चरणों पर जाएं।

1. सामान्य आवश्यकताओं को आकर्षित करना

तो, चलिए बताते हैं कि आप एक डिजाइनर हैं। एक ग्राहक आपके पास आता है, जिम्मेदार बिल्डरों द्वारा "भेजा गया"। ग्राहक स्वाभाविक रूप से आपको एक अस्पताल परियोजना विकसित करने के लिए कहता है। आप कुहल्मन के पास दौड़ें और ... खैर, यह पुरातनता है - अर्चिच्ड लॉन्च करें और ड्रा करें।

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

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

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

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

2. सिस्टम कॉन्सेप्ट चुनना

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

3. संदर्भ की शर्तों का विकास

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

सूचना प्रणाली के लिए, TOR ( संदर्भ की शर्तें ) का विकास परियोजना का केंद्रीय हिस्सा है। संदर्भ की शर्तों का वर्णन:

1. सिस्टम को क्या करना चाहिए।
2. सिस्टम की समग्र संरचना क्या होनी चाहिए।
3. कैसे एक प्रणाली बनाने के लिए।

अर्थात्, टीओआर में कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं हैं, साथ ही साथ विकास चरणों, वितरण, स्वीकृति, प्रलेखन के लिए आवश्यकताएं हैं। टीओआर में भी उन प्रक्रियाओं का संक्षेप में वर्णन किया जाना चाहिए जिन्हें हम वास्तव में स्वचालित करते हैं।

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

मैं तकनीकी विशिष्टताओं के विकास से संबंधित कई मिथकों को समाप्त करना चाहूंगा।

मिथक एक: TK में केवल ठेकेदार के लिए आवश्यकताएं हैं।

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

मिथक दो: संदर्भ की शर्तों में अक्सर "पानी" का एक बहुत कुछ होता है।

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

मिथक तीन: स्टाफ, सर्वर, कम्युनिकेशन चैनल, ऑपरेटिंग मोड के लिए संचालन की आवश्यकताएं बहुत कम हैं, क्योंकि वे ग्राहक की जिम्मेदारी के क्षेत्र में हैं।

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

हम एक अलग लेख में अधिक विस्तार से टीके की तैयारी पर विचार करते हैं। GOST 34 के अनुसार संदर्भ की शर्तों का विकास आसान और सरल है ।

4. एक तकनीकी परियोजना का विकास

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

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

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

मुझे उम्मीद है कि निम्नलिखित लेखों में हम अधिक विस्तार से जांच करेंगे कि उच्च-गुणवत्ता वाले तरीके से तकनीकी डिजाइन का प्रदर्शन कैसे किया जाए, मॉक-अप, परिदृश्यों को कैसे विकसित किया जाए, और किन दस्तावेजों को तैयार करने की आवश्यकता है।

5. कामकाजी प्रलेखन का विकास

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

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

और फुर्तीली के लिए जगह कहाँ है?

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

, Agile, , , , ? नहीं? , , ? , Agile? , Agile , . . — (, , , ).

: ?

-, Agile , , , , . , - . — - - . , , , . , , . , . ? -. — .

-, , , Agile . . , : . — , — . !

, , «» Agile, ( , ). : . , . () , - , , . .

?

. . — . , . — . , , , , -. ? , . , , . -, , . , , () , . .

, 34- . , . ( ) . .

, . .

: .

:

• 34 .
• .
• .