यूनिट टेस्ट कितने हैं?

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

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

लागत क्या है

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

$$

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

वास्तव में, यह कुछ हद तक सरलीकृत सूत्र है। कड़ाई से बोलते हुए, दर वर्ष दर वर्ष बदल जाएगी, इसलिए WACC1 * WACC2 * WACC3, आदि को हर में इस्तेमाल किया जाना चाहिए, लेकिन व्यवहार में भी पेशेवर मूल्यांकनकर्ता इसकी उपेक्षा करते हैं, क्योंकि WACC गणना पद्धति के आधार पर, भविष्य की दरों के बारे में बाजार की उम्मीदों को पहले ही आज की दरों में शामिल कर लिया गया है और इस बारे में धारणा बनाना अनुत्पादक है।

विभिन्न प्रकार के नकदी प्रवाह हैं, लेकिन मैंने कंपनी के लिए हमारे उद्देश्यों के लिए सबसे सुविधाजनक नकदी प्रवाह लिया, जो न केवल मालिकों के लिए बकाया पैसे को ध्यान में रखता है, बल्कि लेनदारों को भी देता है। बेशक, अधिकांश आईटी कंपनियों के पास ध्यान देने योग्य ऋण नहीं है, क्योंकि कोई भी उन्हें संपार्श्विक के बिना उधार नहीं देता है, और उनके पास गिरवी रखने के लिए कुछ भी नहीं है, लेकिन अपवाद हैं, उदाहरण के लिए, यह दृष्टिकोण सुविधाजनक हो सकता है जब एक ऋण प्राप्त विनिर्माण कंपनी के घर में एक परियोजना का मूल्यांकन करते हैं। । एफसीएफएफ की गणना की सादगी के कारण एफसीएफएफ की हमारे लिए विशेष रुचि है दूसरा कारण, एफसीएफएफ केवल परिचालन लाभ कम कर, शुद्ध पूंजी लागत और कार्यशील पूंजी में परिवर्तन है।

चूंकि एफसीएफएफ एक ही समय में मालिकों और उधारदाताओं दोनों के लिए एक नकदी प्रवाह है, इसलिए इसे पूंजी की लागत के भारित दर पर छूट दी जाती है, दोनों ही और उधार।

बड़ी कंपनियों में, पूंजी की लागत की निगरानी वित्तीय विभाग द्वारा की जाती है, इसलिए आप इसे केवल पूछ सकते हैं, लेकिन सामान्य मामले के लिए, हमें अभी भी WACC की गणना के लिए एक सूत्र की आवश्यकता है:

$$

यहाँ Re इक्विटी की लागत है, Rd उधार ली गई पूंजी की लागत है (अर्थात, कंपनी के ऋण पर प्रभावी दर), P इक्विटी का बाजार मूल्य है, EV उद्यम की कुल लागत (EV = P + D, जहाँ D ऋण है) है।

अगला हमें Re निर्धारित करने की आवश्यकता है, इसके लिए अलग-अलग मॉडल हैं, लेकिन सबसे आसान तरीका CAPM मॉडल है, जहां Re = Rb + R * प्रीमियम, जहां Rb जोखिम-मुक्त दर है, प्रीमियम इक्विटी में निवेश पर रिटर्न पर प्रीमियम है, और नहीं उधार लिया गया, और ed एक जोखिम कारक है जो दिखाता है कि एक निश्चित औसत कंपनी के व्यवसाय के संबंध में हमारी परियोजना कितनी अधिक जोखिम भरी है।

गुणवत्ता कैसे सुनिश्चित की जाती है और इकाई परीक्षण क्या होते हैं

अब हमें यह तय करने की आवश्यकता है कि इकाई परीक्षण क्या हैं। अजीब तरह से, बहुत से लोग, यहां तक ​​कि विकास के करीब, अक्सर किसी भी स्वचालित परीक्षण इकाई परीक्षणों को बुलाते हैं, लेकिन यह निश्चित रूप से ऐसा नहीं है।

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

गुणवत्ता सुनिश्चित करने के लिए पहली चीज जो होनी चाहिए वह है डेवलपर्स से नियंत्रण कार्य लेना और उस व्यक्ति को किराए पर लेना जो इसके लिए जिम्मेदार होगा। तो टीम में एक परीक्षक दिखाई देता है, जो मैनुअल परीक्षण में लगा हुआ है। मैन्युअल परीक्षण के बिना कोई भी गंभीर परियोजना बस समझ से बाहर नहीं है; यह नींव है कि परियोजना को आम तौर पर ज़रूरत है और समस्याओं की विशाल बहुमत की खोज की जाएगी और समय पर सही किया जाएगा जो परीक्षकों की योग्यता होगी। इस स्तर पर, सब कुछ सरल दिखता है: यदि आप गुणवत्ता चाहते हैं, तो गुणवत्ता विशेषज्ञ को किराए पर लें।

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

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

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

लागत, जटिलता समायोजन और पौराणिक व्यक्ति-महीना

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

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



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

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

यदि हम टीम शेड्यूल के विकास के द्वारा इस अनुसूची की अशुद्धता को पूरी तरह से समझाते हैं, तो इसके साथ जुड़े खर्चों का अनुमान कार्य समूह के आकार पर संचार पर खोए गए समय की निर्भरता की निम्न तालिका से लगाया जा सकता है:



उदाहरण के लिए, यदि किसी टीम में पांच डेवलपर्स हैं, और आप मानते हैं कि आपको दो को किराए पर लेने की आवश्यकता है, ताकि हर कोई यूनिट परीक्षणों पर अपने समय का अतिरिक्त 40% खर्च कर सके, इस तथ्य के लिए तैयार रहें कि विकास लागत 40% से अधिक बढ़ सकती है। टीम उत्पादकता के 5 * 0.625 = 3.125 पारंपरिक इकाइयों के बजाय कम प्रभावी और विकसित होगी, इसमें 7 * 0.539 = 3.77 इकाइयाँ होंगी, और कार्य की मात्रा क्रमशः 1 से 1.4 पारंपरिक इकाइयों की वृद्धि होगी, क्रमशः, विकास के लिए आवश्यक समय 16% की वृद्धि होगी।

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

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

यूनिट टेस्ट के लाभ

लागत के अलावा, यूनिट परीक्षण भी लाभ लाते हैं। बेशक, अधिकांश मामलों में, एक बग जिसे इकाई परीक्षणों द्वारा पकड़ा जा सकता है, गुणवत्ता नियंत्रण के अन्य स्तरों पर पकड़ा जाएगा, लेकिन हमेशा एक तकनीकी विफलता की संभावना होती है और सैद्धांतिक रूप से इकाई परीक्षण इसे कम कर सकते हैं। व्यक्तिगत रूप से, मुझे इस तरह के मामलों का पता नहीं है, सौभाग्य से, मेरे साथ काम करने वाले सभी परीक्षक बेहद जिम्मेदार लोग थे, लेकिन जब ऐसी कम संभावनाओं की बात आती है, तो व्यक्तिगत अनुभव अप्रमाणिक हो सकते हैं। विफलता के अलग-अलग परिणाम हो सकते हैं, उदाहरण के लिए, एक कंपनी में एक SLA हो सकता है, जिसका उल्लंघन करने पर कुछ वित्तीय नुकसान होंगे, उदाहरण के लिए, कंपनी को अपनी सेवाओं का एक महीने का मुफ्त उपयोग मुआवजे के रूप में करने के लिए मजबूर किया जाएगा, जिससे राजस्व का 1/12 नुकसान होगा। इस मामले में, सख्त गुणवत्ता नियंत्रण, जो वर्ष के दौरान SLA के उल्लंघन की संभावना को 10% से 8% तक कम कर देता है, औसत वार्षिक नुकसान को लगभग 0.17% राजस्व कम कर देगा। यह धन नकदी प्रवाह का सकारात्मक घटक होगा जिसे मॉडल में जोड़ने की आवश्यकता है।

कृपया ध्यान दें कि इस तरह की एक सरल गणना केवल तभी लागू होती है जब नुकसान की संभावना कम होती है, यदि संभावना 15-20% से अधिक हो और कंपनी दिवालिया हो सकती है या परिसमापन हो सकती है, उदाहरण के लिए, वैकल्पिक निर्णय मॉडल का उपयोग करना उचित है, जैसे कि एक निर्णय वृक्ष। सौभाग्य से, ज्यादातर मामलों में, कुछ प्रकार के बेवकूफ बग कुछ ऐसा नहीं है जो एक कंपनी को दिवालिया कर सकता है और हमें विकल्पों की लागत की गणना करने के डर में नहीं करना चाहिए।

उदाहरण एक: बाइसन

बाइसन एक बड़ा ऑनलाइन स्टोर है, वे खुद को रूस में नंबर 1 ऑनलाइन रिटेलर कहते हैं। कंपनी सार्वजनिक नहीं है, लेकिन हाल ही में पुनर्पूंजीकरण लेनदेन में, इसके कुल पूंजीकरण का अनुमान 50 अरब रूबल था, जो वार्षिक राजस्व का दोगुना है। ऑपरेटिंग घाटे के कारण अतिरिक्त पूंजीकरण की आवश्यकता थी, लेकिन शेयरधारकों को उम्मीद है कि कंपनी को एक साल के भीतर उच्च बाजार हिस्सेदारी हासिल करने और राजस्व दोगुना करने के बाद 10% के ऑपरेटिंग प्रॉफिट मार्जिन हासिल करने की उम्मीद है, जिसके बाद उसे कमाई शुरू करनी होगी, और राजस्व वृद्धि धीमी हो जाएगी। दूसरे वर्ष में 30% तक, तीसरे वर्ष में 20%, और अंत में चौथे और बाद के वर्षों में 10% पर सेट करें। हालांकि, बैंक इस बारे में बहुत सुनिश्चित नहीं हैं और Bizon को लंबी सावधानी देते हैं, कंपनी का कुल ऋण 11% की दर से केवल 10 बिलियन रूबल है। बाइसन परिचालन स्तर पर एक बल्कि अनाड़ी और खराब तरीके से प्रबंधित कंपनी है, कर्मचारियों की अनियंत्रित भर्ती ने पहले ही इस तथ्य को जन्म दिया है कि यह 600 प्रोग्रामर को रोजगार देता है, जिनका कुल पेरोल बजट प्रति वर्ष 1.5 बिलियन रूबल है और जो यूनिट परीक्षणों पर अपने काम का लगभग 30% खर्च करते हैं। कंपनी के पास ग्राहकों के लिए कोई दायित्व नहीं है और एक तकनीकी विफलता केवल बिक्री में एक अस्थायी रोक का कारण बन सकती है, और विफलता के मामले में, साइट के पुराने संस्करण में एक रोलबैक में लगभग एक घंटे लगते हैं।

बायसन में इकाई परीक्षणों का उपयोग करने से एनपीवी क्या है?

50, 65, 78 86 , , . 33%, , , . , 25% , DDOS . , 0,023% , 12 . , 11,5 , 14,8 , 17,8 19,6 .

, 450 .

, , , . , ! , - , , .

, , 10% , , -438, -480, -527 -579 , , , 10% . , , 20% , , 0.8: -351, -384, -421 -463 .

EV 50 + 10 = 60 , P 83% , D 17%, , 11% , WACC . , , 7,6%. , 4-6% , 5%, β (unlevered beta) 1,3. , , (levered beta):

$$

WACC

$$

, , , , 10% .

$$ , $$ , $$ .

10% , $$ , : $$ .
$$ .

:

– . , , . , , , 50 . . .
कार्यशाला में वसीली की यात्रा के दौरान, उत्पादन प्रभारी विशेषज्ञ ने उन्हें सामान्य शब्दों में निम्नलिखित कहा: “प्रिय सहकर्मी! कृपया इस विशाल पिघले हुए धातु की बाल्टी पर ध्यान दें। अगर कुछ गलत होता है, तो हम न केवल अत्यंत हतोत्साहित होंगे, बल्कि तकनीकी कठिनाइयों से भी जूझेंगे। तथ्य यह है कि अगर ब्लास्ट फर्नेस उगता है, तो उसके अंदर की धातु सख्त हो जाती है और दुर्घटना के परिणामों को खत्म करने में तीन महीने लगेंगे। कार्यशाला में धातु के एक विशाल टुकड़े से निपटना और इसे नए ब्लास्ट फर्नेस से बदलना आसान नहीं होगा। ” वसीली को बाद में पता चला कि ब्लास्ट फर्नेस के लिए एक आपातकालीन स्टॉप से ​​कंपनी को 8 बिलियन रूबल की लागत आ सकती है।
प्रश्न: क्या वसीली यूनिट परीक्षण लिखने के बारे में चिंतित है?
, : . , ( 50, - 10, ), , . , , - , , 100 10% * 8 = 800 .

: XSoft

XSoft एक सफल आउटसोर्सिंग कंपनी है जिसने सिर्फ एक और पश्चिमी ग्राहक के साथ एक अनुबंध पर हस्ताक्षर किए हैं। ग्राहक को 7 प्रोग्रामर किराए पर देने की योजना है, इस भाग में उसका बजट एक वर्ष में 15 मिलियन रूबल है, जिसमें से XSoft 3 मिलियन लेगा। ग्राहक एक बोझ है और विकास में कुछ भी नहीं समझता है। XSoft के दृष्टिकोण से, डेवलपर्स को यूनिट परीक्षण लिखना चाहिए?

! , , -, , - . , , , .

अंतभाषण

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