आवश्यकता और परियोजना की सफलता और विकास के समय पर इसके प्रभाव पर खर्च किया गया समय

Question

क्या इस बात का कोई सबूत है कि लिखने में खर्च किया गया समय, या आवश्यकताओं के बारे में सोचने से विकास के समय पर कोई प्रभाव पड़ेगा? स्टैंडिश (1995) द्वारा किए गए अध्ययन से पता चलता है कि आंशिक रूप से अपूर्ण आवश्यकताओं (13.1%) ने परियोजनाओं की विफलता में योगदान दिया। क्या कोई अध्ययन किया गया है जो दर्शाता है कि आवश्यकता विश्लेषण पर खर्च किए गए समय का किसी परियोजना के विकास समय पर कोई प्रभाव पड़ेगा, या परियोजना कितनी सफल होगी।

Comments

चुस्त मॉडल यहाँ कैसे फिट होते हैं? कोई यह तर्क दे सकता है कि वे आवश्यकताओं का समय (पर और बंद) बिताते हैं लेकिन कोई आवश्यकता नहीं है "चरण" जैसे।

— राफेल

@ राफेल से सहमत। क्या हम सॉफ्टवेयर इंजीनियरिंग पर सवाल उठाने जा रहे हैं? या साइट की आधिकारिक नीति है कि इस समय "कंप्यूटर विज्ञान" और "सॉफ्टवेयर इंजीनियरिंग" के बीच अंतर करना उचित नहीं है?

— पैट्रिक87

@ पैट्रिक87 आइए इसे मेटा में स्थानांतरित करें ।

— राफेल

यह मुझे लगता है कि यह प्रश्न मौजूदा सॉफ्टवेयर इंजीनियरिंग और परियोजना प्रबंधन साइटों के लिए बेहतर होगा ।

— एडम लेअर

Answer 1

कोड को पूरा देखें, स्टीव मैककोनेल द्वारा, तालिका 3-1। वह दोषों को ठीक करने की औसत लागत की तुलना करता है, जब वे परिचय और पता लगाए जाते हैं। निर्माण के समय का पता लगाने की आवश्यकता समय पर पता लगाने की तुलना में 5-10 गुना अधिक होती है, और 10-100 गुना अधिक रिलीज के बाद।

तालिका निम्नलिखित स्रोतों पर आधारित है:

1. "डिजाइन और कोड निरीक्षण कार्यक्रम में त्रुटियों को कम करने के लिए निरीक्षण" (फगन 1976)

2. सॉफ्टवेयर दोष हटाने (दून 1984)

3. "ह्यूजेस एयरक्राफ्ट में सॉफ्टवेयर प्रोसेस इम्प्रूवमेंट" (हम्फ्री, स्नाइडर और वाइलीस 1991)

और कई और अधिक

Comments

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

— राफेल

यह सच है। हमें यह मानना ​​होगा कि आवश्यकताओं पर जल्दबाज़ी न करने का मतलब है कि आवश्यकताओं में कम त्रुटियाँ हैं, लेकिन यह बहुत अधिक खिंचाव की तरह प्रतीत नहीं होती है।

— जो

Answer 2

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

ग्लास 'कानून: आवश्यकता की कमियाँ परियोजना विफलताओं का मुख्य स्रोत हैं।

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

यह बताता है कि आवश्यकताओं की गुणवत्ता और परियोजना के परिणाम के बीच एक संबंध है।

बोहम का पहला कानून: त्रुटियां आवश्यकताओं और डिजाइन गतिविधियों के दौरान सबसे अधिक होती हैं और बाद में उन्हें हटाए जाने के बाद अधिक महंगी होती हैं।

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

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

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

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

इन कानूनों के संदर्भ हैं:

ग्लास 'कानून: ग्लास, आरएल: सॉफ्टवेयर रूनावेज। बड़े पैमाने पर सॉफ्टवेयर प्रोजेक्ट विफलताओं से सबक लिया। अपर सैडल नदी, एनजे: अप्रेंटिस हॉल 1998

बोहम का पहला कानून: बोहेम, BW, McClean, RK, Urfrig, DB: लार्ज-स्केल विश्वसनीय सॉफ्टवेयर के डिजाइन के लिए स्वचालित एड्स के साथ कुछ अनुभव। सॉफ्टवेयर इंजीनियरिंग 1, 1 (1975), 125–133 पर IEEE ट्रांस

बोहम का दूसरा नियम: बोहम, बब्लू, ग्रे, टीई, सीवल्ड, टी .: प्रोटोटाइप वर्सस निर्दिष्ट करना: एक मल्टीप्रोजेक्ट प्रयोग। सॉफ्टवेयर इंजीनियरिंग पर IEEE ट्रांस 10, 3 (1984), 290-302

इसके अलावा, निम्नलिखित संदर्भ रुचि के हो सकते हैं: एंड्रेस, ए और रोम्बच, डी। ए हैंडबुक ऑफ सॉफ्टवेयर एंड सिस्टम्स इंजीनियरिंग। अनुभवजन्य अवलोकन, कानून और सिद्धांत। सॉफ्टवेयर इंजीनियरिंग पर Fraunhofer IESE श्रृंखला। एडिसन वेस्ले, 2003।