सॉफ़्टवेयर क्राइसिस

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

इतिहास
सॉफ़्टवेयर क्राइसिसशब्द 1968 में जर्मनी के गार्मिश में पहले नाटो सॉफ्टवेयर इंजीनियरिंग सम्मेलन में उपस्थित कुछ लोगों द्वारा लिखा गया था। एडवर्ड डिज्क्स्ट्रा का 1972 ट्यूरिंग पुरस्कार व्याख्यान इसी समस्या का संदर्भ देता है:

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

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

यह भी देखें

 * एआई विंटर
 * विफल और अधिक बजट वाले कस्टम सॉफ़्टवेयर प्रोजेक्टों की सूची
 * फ्रेड ब्रूक्स
 * सिस्टम दुर्घटना
 * प्रौद्योगिकी विलक्षणता

बाहरी संबंध

 * Edsger Dijkstra: The Humble Programmer (PDF file, 473kB)
 * Brian Randell: The NATO Software Engineering Conferences
 * Markus Bautsch: Cycles of Software Crises in: ENISA Quarterly on Secure Software (PDF file; 1,86MB)
 * Hoare 1996, "How Did Software Get So Reliable Without Proof?"