उदाहरण के लिए, क्या यह एवियनिक्स सॉफ्टवेयर के लिए ऐसा करने के लिए अविश्वसनीय रूप से खतरनाक होगा?Agile प्रोग्रामिंग भी है ... सुरक्षा-महत्वपूर्ण प्रणालियों के लिए विज्ञापन?
नोट, मैं पूरी तरह से Agile समझ नहीं आता।
मैंने अनिवार्य रूप से झरना प्रक्रिया का उपयोग कर एयर-ट्रैफिक कंट्रोल सिस्टम पर काम किया है, और उन परियोजनाओं को निश्चित रूप से चुस्त प्रथाओं से फायदा हो सकता है। मुझे इस बारे में सोचना पसंद नहीं है कि उस कोड का कितना "दुर्घटना से" काम करता है, बिना किसी प्रकार के यूनिट-स्तरीय स्वचालित रिग्रेशन परीक्षण के। और आवश्यकताओं-सामने की ओर एक लाल हेरिंग की बात है। हालांकि यह सच है कि एयरोस्पेस सिस्टम संभवतः करीब हैं क्योंकि आप सामने की पत्थर की आवश्यकताओं को आगे बढ़ा सकते हैं, आप अभी भी अस्पष्ट आवश्यकताओं के अर्थ पर तर्क हैं जो सिस्टम को स्वीकृति में होने पर ही चालू हो जाते हैं परिक्षण। या आपके पास थ्रूपूट मुद्दे हैं जो किसी ने भी नहीं देखा था कि बड़े-बड़े एकीकरण के कारण खेल में देर हो चुकी है। टेस्ट-फर्स्ट, स्पाइक सॉल्यूशंस, निरंतर एकीकरण, जोड़ी प्रोग्रामिंग - मुझे लगता है कि इनमें से सभी ने उन परियोजनाओं में सुधार किया होगा जिन पर मैंने काम किया था।
अद्यतन: इस बात का जिक्र नहीं है कि परियोजना के अंत तक "डिजाइन दस्तावेज़" कितने बार झूठ का एक पैक था, क्योंकि डिजाइन वास्तविकता के रूप में आवश्यक रूप से विकसित हुआ था। Agile उभरते डिजाइन के तथ्य को पहचानता है, जो वाटरफॉल परियोजनाओं में उतना ही वास्तविक है जितना कि किसी भी अन्य में, नाटक करने की कोशिश करने के बजाय आप कोड लिखने से पहले ही डिजाइन प्राप्त कर सकते हैं।
मेरे पास वास्तव में स्वतंत्र राय बनाने के लिए उस क्षेत्र (विमानन प्रणाली के उपयोगकर्ता के अलावा) में पर्याप्त अनुभव नहीं है। हालांकि, उन सभी चीजों को जो मैं उन महत्वपूर्ण प्रणालियों के बारे में पढ़ता रहता हूं जिनके पास सर्वश्रेष्ठ ट्रैक रिकॉर्ड है, मुझे विश्वास है कि झरना वास्तव में सबसे अच्छा तरीका है। यह संभव है क्योंकि लोग सुरक्षा को बढ़ावा देने के लिए ठंड आवश्यकताओं के अतिरिक्त अपशिष्ट की अनुमति देने के इच्छुक हैं। मुझे लगता है कि उस मामले में ट्रेड-ऑफ थोड़ा अलग हैं।
आप चुस्त दृष्टिकोण का उपयोग कर सकते हैं, लेकिन पहले पास में आपकी सुरक्षा और सुरक्षा पहलुओं को शामिल करना होगा, या कम से कम उन्हें प्रदान करना होगा, ताकि आप पैर में खुद को गोली मार न सकें और पूरी चीज को फिर से लिख सकें । लेकिन मैं ब्रायन से सहमत हूं, आप शायद ऐसी परियोजनाओं के लिए वाटरफॉल दृष्टिकोण का उपयोग कर बेहतर हैं।
Determining the Applicability of Agile Practices to Mission and Life-Critical Systems
संक्षेप में, वहाँ कोई "फुर्तीली" प्रोग्रामिंग है। प्रथाओं का एक सेट है। कुछ दूसरों से बेहतर खुद को उधार देते हैं, लेकिन सामान्य रूप से, किसी भी परियोजना को कुछ प्रथाओं से फायदा होगा।
सबसे बड़ा क्षेत्र आम तौर पर मॉडलिंग और वास्तुकला से संबंधित है। फुर्तीली प्रथाओं का उपयोग करके वहां बहुत सारी टीमें हैं - उदाहरण के लिए, मैं नासा के साथ Fun3d team के सदस्यों को जानता हूं - वे चुस्त प्रथाओं का उपयोग करते हैं और अंतरिक्ष शटल समर्थन जैसी चीजों से निपटते हैं।
इस प्रकार के काम के लिए समर्पित कई समूह हैं - इसलिए यह संभव है। आपको बस अपने जोखिमों से अवगत होना चाहिए - किसी भी अन्य पद्धति की तरह।
कुछ चुस्त घोषणापत्र हस्ताक्षरकर्ता वास्तव में काफी विरोधाभासी चीजें करते हैं: उदा। मेलर के मॉडल संचालित कोड जनरेशन दृष्टिकोण की तुलना में बेक और कनिंघम का "स्रोत कोड डिज़ाइन है" ... – daf
Agile एक अनुशासित प्रक्रिया होनी चाहिए। आपकी प्रक्रिया चाहे जो भी हो, इस मामले में सुरक्षा मुद्दों को आगे बढ़ाया जाना चाहिए। मैं नहीं देखता कि निरंतर निर्माण प्रणाली का उपयोग करते हुए पुनरावृत्तियों में कैसे पहुंचे, प्रोग्रामर जला दरों की गणना करना, बैठकें खड़े होने, ग्राहक सक्रिय रूप से व्यस्त होने आदि की सुरक्षा नकारात्मक रूप से प्रभावित होगी।
समस्या, आईएमओ, यदि आवश्यकताएं ठीक नहीं हैं, तो हो सकता है कि आप एक सुरक्षा सुविधा खो रहे हों जो स्वयं को दिखाएगी एक पुनरावृत्ति में। –
यह मानते हुए कि आप वास्तव में सामने सबकुछ खोज लेंगे, और आपकी आवश्यकताओं को रास्ते में बदलने वाला नहीं है। मैंने व्यक्तिगत रूप से कभी भी कभी नहीं देखा है। –
मैंने कभी भी जीवन-महत्वपूर्ण प्रणाली पर काम नहीं किया है, लेकिन जो मैंने पढ़ा और बताया है, उससे अधिकांश परियोजनाओं की तुलना में वे अधिक आवश्यकताओं पर खर्च करते हैं। –
मैं एयरोस्पेस (विशेष रूप से उपग्रहों) में काम करता हूं, और हम एक संकर दृष्टिकोण का उपयोग करते हैं क्योंकि हमें दो अलग-अलग चिंताओं का सामना करना पड़ता है: असली दुनिया की आवश्यकताओं और व्यावसायिक प्रक्रिया आवश्यकताओं।
हम अंतरिक्ष यान आवश्यकताओं और महत्वपूर्ण वर्गों के लिए एक झरना-आश दृष्टिकोण का उपयोग करते हैं क्योंकि उपग्रह में परिवर्तन धीमे और दुर्लभ होते हैं, और वहां खराब हो जाना खराब होता है।
लेकिन कभी-कभी बदलती व्यावसायिक प्रक्रियाओं के लिए हम एक फुर्तीली आइश दृष्टिकोण का उपयोग करते हैं क्योंकि वे वे ग्राहक की मांग के कारण अंतरिक्ष यान लगातार बदल रहे हैं। वहां स्क्रूइंग का मतलब है कि सबसे बुरे मामले में उपयोगकर्ता को अच्छे नतीजे नहीं मिलते हैं।
मुझे लगता है कि इस प्रक्रिया में सुरक्षा-मांगों को एकीकृत करने के तरीके पर निर्भर करता है। यदि वे परीक्षण का एक अतिरिक्त सेट हैं, तो ऐसा कुछ भी नहीं है जो चुस्त प्रोग्रामिंग के विरोधाभास में है। मुझे लगता है कि चुस्त विधियां आपको अधिक सुरक्षित सॉफ्टवेयर बनाने में मदद कर सकती हैं, क्योंकि फुर्तीली परियोजनाएं झरना-परियोजनाओं की तुलना में उच्च गुणवत्ता वाली होती हैं। महत्वपूर्ण होगा कि आपके द्वारा स्थापित अतिरिक्त गुणवत्ता-आश्वासन भी चुस्त विधियों के लिए उपयोग में है।
लेकिन यदि सुरक्षा-मांग भवन-प्रक्रिया पर लागू होती है, तो यह चुस्त विधियों के विरोधाभास में हो सकती है।
दरअसल, वी-मॉडल नामक झरना मॉडल का एक बदलाव है, उदाहरण के लिए आईईसी 61508 द्वारा इसका अनुकूलन किया गया है। यह झरना-प्रकार है, लेकिन मूल परियोजना चक्र के पुन: पुनरावृत्ति के प्रावधानों के साथ। इस मामले में पुन: पुनरावृत्तियों का मुख्य उद्देश्य प्रक्रिया में विभिन्न चरणों में पाए गए मुद्दों से निपटना है। मूल विचार यह है कि बाद में जिस सड़क पर आपको कोई समस्या आती है, आपकी प्रक्रिया में आगे की ओर आपको अपने परिवर्तनों के प्रभाव की देखभाल करने और समीक्षा करने के लिए जाना होगा।
तो यह वास्तव में चंचल नहीं है, लेकिन ... :-)
विचार के बहुत सारे हैं। पहला यह है कि आपकी सुरक्षा की आलोचना क्या है। यदि आपका उत्तर "ए" या "बी" (और वास्तव में "ए") है तो बिल्कुल नहीं। आप किसी भी तरह आकार या रूप में Agile करने से दूर नहीं होंगे। स्तर ए सॉफ्टवेयर (लगभग 15 वर्षों की मेरी पृष्ठभूमि) से आवश्यक बहुत सख्त कोडिंग मानकों, दस्तावेज मानकों और प्रक्रिया मानकों हैं। इसमें शामिल हैं:
तो न केवल आप अपने कोड, डिजाइन और आवश्यकताओं को प्रमाणित करने के लिए की क्या ज़रूरत है लेकिन आपको टूल सेट, कंपाइलर्स, स्वचालित परीक्षण उपकरण और बहुत कुछ प्रमाणित करना होगा।
संक्षेप में, यह वास्तव में कोई छोटी सी काम नहीं है और यह एक छोटी टीम के साथ नहीं किया जाएगा। इसी प्रकार, इंटरफेस वास्तव में ठोस और बहुत विशिष्ट और स्थिर हैं। इंटरफेस बदलने के लिए आम तौर पर 3+ कंपनियों (एयरफ्रेम निर्माण, वेंडर 1 से बात करने वाले वेंडर 2) के साथ समन्वय की आवश्यकता होती है।
सभी ईमानदारी में, एक 12 लाइन कोड परिवर्तन $ 170,000 तक बढ़ सकता है। बेशक, एक 500 लाइन कोड परिवर्तन $ 190,000 होगा। संक्षेप में, लेवल ए कोड से जुड़े एक विशाल प्रक्रिया ओवरहेड (स्तर बी के साथ बहुत कम, सी के साथ भी कम और स्तर डी के साथ बहुत कम) छोटे पुनरावृत्तियों को बहुत महंगा बनाते हैं; अर्थात। एक छोटे से बदलाव का परीक्षण करने के लिए पूरी तरह से ईंधन भरने और 777 उड़ान भरने के लिए बहुत सारे पैसे खर्च होते हैं। यहां तक कि बड़े वाणिज्यिक विमानों की सिस्टम टेस्ट लैब्स में 10,000 डॉलर/दिन की जला दर होगी।
उदाहरण के लिए: स्तर एक: HUD, थ्रस्ट reversers, पावर सिस्टम्स, FADEC (इंजन नियंत्रण) स्तर बी: माध्यमिक स्विचिंग तर्क, गायन संचार प्रणाली। स्तर सी: उड़ान डेटा लिंक में। स्तर डी: उड़ान मनोरंजन प्रणाली में।
स्तर डी और शायद स्तर सी, Agile के लिए उम्मीदवार हो सकता है।
यूरोस्टार 200 9 सम्मेलन पर गिट्टी ओटोसेन ने बात की कि वे अपनी कंपनी में चुस्त कैसे हैं। प्रभावशाली यह है कि यह कंपनी Systematic एयर-शिल्प, सैन्य आदि के लिए सॉफ्टवेयर बना रही है। वे इसे सीएमएमआई 5, आईएसओ 9 001 और एक्यूएपी 150 & 2110 के अनुपालन में करते हैं। इसलिए मुझे लगता है कि उच्च नियम वाले सिस्टम पर चुस्त लगाया जा सकता है। हो सकता है कि उस प्रस्तुति को देखने का प्रयास करें, और उससे अधिक जानकारी प्राप्त करने का प्रयास करें।
यह अन-परीक्षण कोड के लिए एक अच्छा शब्द है: "दुर्घटना से काम करना"। मैं अन-परीक्षण कोड के बारे में वैसे ही महसूस करता हूं – casademora