डिजाइन कार्यप्रणाली के विकास का इतिहास (सॉफ्टवेयर इंजीनियरिंग)

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

यह सब कैसे शुरू हुआ

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

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

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

एक नए अनुशासन का उदय

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

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

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

सॉफ्टवेयर इंजीनियरिंग में तरीके

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

• पारंपरिक (कैस्केडिंग, झरना) मॉडल;
• सर्पिल मॉडल;
• पुनरावृत्त और वृद्धिशील मॉडल (विकासवादी दृष्टिकोण)।

कार्यप्रणाली पर अधिक

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

• प्रक्रिया अनुशासन, ध्वनि नियोजन और प्रबंधन के अधीन होनी चाहिए;
• इस कार्यान्वयन के लक्ष्यों की पूरी समझ तक उत्पाद की बिक्री को स्थगित कर दिया जाना चाहिए।

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

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

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

कार्यप्रणाली के विकास की वर्तमान अवस्था

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

विनिर्मित आईटी उत्पादों की गुणवत्ता में तेजी से गिरावट के साथ, कार्यप्रणाली दिखाई देने लगी है कि इस गुणवत्ता में सुधार करना चाहते हैं। यह कार्यप्रणाली DEvOps बन गई है।
"Devops" शब्द को 2009 में बेल्जियम में DevOps Days सम्मेलन में लोकप्रिय बनाया गया था। तब से, इस तरह की कार्यप्रणाली अधिक से अधिक लोकप्रियता प्राप्त कर रही है। यह आंशिक रूप से इस तथ्य के कारण है कि देवोप के सिद्धांत संगठन में वर्तमान कार्यप्रणाली को छोड़ने की वकालत नहीं करते हैं, लेकिन इसके साथ एक संयोजन है। DevOps की समग्र अवधारणा एक ही संगठन के भीतर विकास टीमों (DEVelopments) और संचालन (OPerations) के बीच सहयोग को मजबूत करना है, जो सॉफ्टवेयर विकास के लिए जिम्मेदार है। यह पद्धति, अतिशयोक्ति के बिना, विकास के तरीकों के विकास में एक नया दौर है, क्योंकि यह न केवल तंग समय सीमा के भीतर ग्राहकों की आवश्यकताओं को पूरा करने पर केंद्रित है, बल्कि उत्पाद की गुणवत्ता और स्थिरता में सुधार भी है।

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

सूत्रों का कहना है

परियोजना प्रबंधन सॉफ्टवेयर विकास। अनुशासन "लचीले सॉफ्टवेयर विकास प्रौद्योगिकियों" लेखक: डी.जी. Shopyrin
devopswiki.net/index.php/DevOps
ivanpesin.info/blog/2012/02/building-a-devops-team/ ब्राउन हेनरी द्वारा एक लेख का अनुवाद करना । DevOps टीम बनाना।
“लचीले विकास के तरीके। संस्करण 1.2 »लेखक: वोल्फसन बोरिस
www.ibm.com/developerworks/library/a-devops1 पॉल ड्यूवल का एक लेख का अनुवाद। "फुर्तीली DevOps - चुस्त सॉफ्टवेयर विकास और संचालन: सॉफ्टवेयर रिलीज प्रक्रिया संरेखित करना"
www.sibinfo.ru/archive/news/03_10_14/iid_history.html Iterative और वृद्धिशील विकास: एक संक्षिप्त इतिहास। पोस्ट करनेवाले: क्रेग लर्मन
swbok.sorlik.ru/software_engineering.html SWEBOK सेरी ऑर्लिक द्वारा यूरी बुलुई की भागीदारी के साथ अनुवाद।
www.cossa.ru/articles/234/33622 सफल आईटी परियोजनाओं के आंकड़े।
ndo.sibsutis.ru/magistr/courses_work/tspo_work/lectures_index.htm व्याख्यान नोट: सॉफ्टवेयर तकनीक
"डिजाइनिंग सूचना प्रणाली" लेखक: Sapozhkova T.E.
परियोजना प्रबंधन: एक ट्यूटोरियल लेखक: डलज़ोन एए
Devopshub.net/top-3-mifa-o-devops-chem-vse-taki-devops-ne-yavlyaetsya DevOps के बारे में तीन मिथक
"सॉफ्टवेयर इंजीनियरिंग का परिचय।" लेखक: एस.एन. Karpenko
"स्क्रैम और एक्सपी: एक उन्नत नोट।" हेनरिक नाइबेरग द्वारा पोस्ट किया गया
"सॉफ्टवेयर डेवलपमेंट टेक्नोलॉजीज: एक पाठ्यपुस्तक।" लेखक: एस। ओरलोव।
habrahabr.ru/company/scrumtrek/blog/166039 DevOPs
विकिपीडिया। उसके बिना कहाँ।