सॉफ़्टवेयर परियोजनाओं के समय का अनुमान लगाने में त्रुटियाँ (मेरे अपने अनुभव के आधार पर) कहाँ से आती हैं?

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

फ़ाइलों और फ़ोल्डरों को हटाने का इतिहास

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

प्रक्रिया और एंटीवायरस में कार्यान्वयन का इतिहास

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

फाइल डायलॉग स्टोरी

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

"ठीक है, आप अभी नहीं जानते कि कैसे प्रोग्राम करना है!"

पाठक कुछ भी कह सकता है और गलत होगा। सिस्टम घटकों के बीच बातचीत अक्सर इतनी जटिल होती है कि अप्रत्याशित स्थानों में त्रुटियां और समस्याएं होती हैं। विश्वास नहीं होता? यहाँ चौथी कहानी है।

टूटी हुई OpenGL अनुप्रयोगों की कहानी

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

ये सारी कहानियाँ क्यों?

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

क्या यह हमेशा ऐसा ही रहेगा?

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



टिप्पणियों में, कृपया अपनी कहानियों को साझा करें जब विकास के दौरान कुछ अप्रत्याशित रूप से सामने आया।