COCOMO मॉडल समझाया गया: सूत्र, प्रकार, और सॉफ्टवेयर लागत अनुमान

क्या आपसे कभी पूछा गया है कि किसी सॉफ्टवेयर प्रोजेक्ट में कितना समय लगेगा और आपको अहसास हुआ हो कि आपका सबसे अच्छा जवाब मूलतः एक अनुमान ही है?

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

COCOMO इसी को ठीक करने के लिए बनाया गया था। इसका पूरा नाम है COnstructive COst MOdel। Barry W. Boehm ने इसे 1981 की अपनी पुस्तक Software Engineering Economics में प्रस्तुत किया, जहाँ सूत्रों को सहज अनुमान के बजाय वास्तविक प्रोजेक्ट डेटा पर आधारित किया गया। यह क्षेत्र के सबसे अधिक पढ़ाए जाने वाले एल्गोरिथ्मिक अनुमान मॉडलों में से एक बन गया। Boehm, जिनका अगस्त 2022 में निधन हुआ, ने इसके पीछे के विचारों को दशकों तक निखारा।

इस ट्यूटोरियल में, मैं आपको मॉडल कैसे काम करता है, इसके विभिन्न प्रकार और स्तरों का अर्थ क्या है, यह समझाऊंगा और संख्याएँ व्यवहार में समझ आएँ इसके लिए एक पूरा संख्यात्मक उदाहरण चलाऊंगा।

सॉफ्टवेयर इंजीनियरिंग में COCOMO मॉडल क्या है?

COCOMO एक पैरामीट्रिक सॉफ्टवेयर लागत अनुमान मॉडल है। यह एक प्राथमिक इनपुट लेता है—विशेष रूप से किसी सॉफ्टवेयर प्रोजेक्ट का अनुमानित आकार, जिसे Thousands of Lines of Code (KLOC) में मापा जाता है—और उसके आधार पर तीन बातें अनुमानित करता है: कुल प्रयास (person-months, PM), विकास समय (महीनों में), और आवश्यक लोगों की संख्या।

मॉडल मानता है कि प्रयास का प्रमुख भविष्यवक्ता प्रोजेक्ट का आकार है। Boehm ने वास्तविक ऐतिहासिक प्रोजेक्ट डेटा पर प्रतिगमन विश्लेषण चलाकर मॉडल के स्थिरांक निकाले।

यह कहा जाना चाहिए कि COCOMO सीधे मौद्रिक लागत का अनुमान नहीं लगाता। यह प्रयास का अनुमान देता है। person-months को डॉलर में बदलने के लिए, आप इसे अपने संगठन में प्रति person-month औसत श्रम लागत से गुणा करते हैं। मॉडल आपको प्रयास देता है; दर आपको देनी होती है।

COCOMO मॉडल क्यों विकसित किया गया

Boehm TRW Aerospace में Director of Software Research and Technology के रूप में काम कर रहे थे, और समस्या तत्काल और व्यवहारिक थी। National Academy of Engineering द्वारा बाद में प्रकाशित एक श्रद्धांजलि के अनुसार, TRW के एक उपाध्यक्ष ने एक प्रतिस्पर्धी सॉफ्टवेयर बोली की समीक्षा के बाद Boehm से कहा: "मैं फिर कभी किसी सॉफ्टवेयर बोली पर सिर्फ भरोसे के आधार पर हस्ताक्षर नहीं करना चाहता। जाइए और एक ऐसा तरीका ईजाद कीजिए जो सॉफ्टवेयर उत्पाद विकसित करने की लागत का विश्वसनीय अनुमान दे सके।"

वही अनुरोध COCOMO बना। Boehm ने TRW के 63 पूर्ण प्रोजेक्टों का अध्ययन किया, जो 2,000 से 100,000 लाइनों के सॉफ्टवेयर तक फैले थे, असेंबली से लेकर PL/I तक की भाषाओं में लिखे गए, और सभी वॉटरफॉल मॉडल के तहत बने थे। उस डेटासेट पर किए गए प्रतिगमन विश्लेषण ने COCOMO I में उपयोग हुए स्थिरांक दिए, और मॉडल 1981 में सार्वजनिक हुआ।

COCOMO मॉडल का सूत्र और यह कैसे काम करता है

Basic COCOMO I के पीछे का गणित सरल है, बशर्ते आप समझ लें कि प्रत्येक पद क्या दर्शाता है।

प्रयास का सूत्र है:

यहाँ प्रयास person-months में मापा जाता है, KLOC सॉफ्टवेयर का अनुमानित आकार (हज़ार लाइनों में), और a और b वे स्थिरांक हैं जो आपके प्रोजेक्ट के प्रकार पर निर्भर करते हैं।

विकास समय का सूत्र प्रयास के अनुमान से निकाला जाता है:

स्थिरांक d मोड के अनुसार बदलता है, जबकि c तीनों में 2.5 पर स्थिर है। कई ट्यूटोरियल इसे गलत बताते हैं और मान लेते हैं कि चारों स्थिरांक बदलते हैं। Effort और दोनों होने पर, आप आवश्यक लोगों की औसत संख्या का अनुमान लगा सकते हैं:

नीचे दी गई तालिका Basic COCOMO I के सत्यापित स्थिरांकों को दर्शाती है:

यहाँ प्रमुख चर b है। Organic प्रोजेक्ट्स के लिए b = 1.05 है, जिसका मतलब है कि प्रयास प्रोजेक्ट आकार के साथ लगभग रैखिक रूप से बढ़ता है। Embedded प्रोजेक्ट्स के लिए b = 1.20 है, जो एक महत्वपूर्ण असार्थकता-आकार (diseconomy of scale) पैदा करता है: किसी embedded प्रोजेक्ट का आकार दोगुना करने पर आवश्यक प्रयास दोगुने से अधिक हो जाता है।

COCOMO मॉडल के प्रकार (COCOMO I)

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

ध्यान देने योग्य बात: ये तीन मोड केवल COCOMO I पर लागू होते हैं। COCOMO II, जो 2000 का अपडेट है, ने इन्हें एक अलग दृष्टिकोण से प्रतिस्थापित किया।

तीन COCOMO I मोड का दृश्य तुलना। चित्र: लेखक द्वारा।

ये तीनों मोड बढ़ती जटिलता और बाधाओं के पैमाने पर स्थित हैं। आपका प्रोजेक्ट प्रकार और टीम संदर्भ आमतौर पर स्पष्ट कर देता है कि कौन-सा लागू होता है।

Organic मोड

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

क्योंकि टीम अनुभवी है और डोमेन परिचित, इसलिए जैसे-जैसे प्रोजेक्ट बढ़ता है संचार का ओवरहेड कम रहता है। इसी वजह से b घातांक तीनों मोड में सबसे छोटा है।

Semi-detached मोड

Semi-detached मोड बीच का है। इस श्रेणी की टीमों का अनुभव मिश्रित होता है: कुछ सदस्य डोमेन को अच्छी तरह जानते हैं, कुछ कम। प्रोजेक्ट की जटिलता मध्यम है, और नए हार्डवेयर या बाहरी सिस्टम के साथ कुछ इंटरैक्शन हो सकता है।

कंपाइलर विकास, ट्रांजैक्शन प्रोसेसिंग सिस्टम, और मिड-टियर बिज़नेस एप्लिकेशन आम उदाहरण हैं। यहाँ आकार-आधारित असार्थकता अधिक स्पष्ट है, जहाँ b = 1.12 है।

Embedded मोड

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

यहाँ b = 1.20 होने से embedded प्रोजेक्ट्स में तीनों मोड में सबसे तीव्र असार्थकता-आकार दिखती है। Embedded मोड प्रोजेक्ट के आकार पर निर्भर नहीं है—यदि कोई अपेक्षाकृत छोटा embedded सिस्टम भी कड़े प्रतिबंधों के तहत काम करता है, तो वह भी इसी में आएगा।

Basic बनाम Intermediate बनाम Detailed COCOMO

तीन प्रोजेक्ट मोड के अलावा, COCOMO I में अनुमान की विस्तृतता के तीन स्तर हैं। मोड बताते हैं कि कौन-से स्थिरांक उपयोग करने हैं; स्तर बताते हैं कि प्रोजेक्ट को कितनी गहराई से मॉडल करना है। हर स्तर पिछले पर अतिरिक्त कारक जोड़ता है, जिससे सटीकता बढ़ती है लेकिन इनपुट डेटा की ज़रूरत भी।

इसे एक स्पेक्ट्रम की तरह समझें: Basic COCOMO आपको तेज़ी से एक मोटा अनुमान देता है, जबकि Detailed COCOMO चरण-स्तरीय सटीक योजना बनाने देता है।

अनुमान की गहराई के आधार पर COCOMO I के स्तर। चित्र: लेखक द्वारा।

पिरामिड में नीचे जाने पर गणना में अधिक कारक जुड़ते हैं, जो सटीकता बढ़ाते हैं लेकिन आरंभ करने के लिए अधिक इनपुट डेटा भी माँगते हैं।

Basic COCOMO

Basic COCOMO केवल KLOC में प्रोजेक्ट आकार और प्रोजेक्ट मोड का उपयोग करता है। आप KLOC डालते हैं, चुने गए मोड के स्थिरांक लगाते हैं, और प्रयास का अनुमान प्राप्त करते हैं। यह शुरुआती व्यवहार्यता आकलन के लिए उपयोगी है, जब आपके पास अभी टीम और विकास परिवेश के बारे में विस्तृत जानकारी नहीं होती।

Intermediate COCOMO

Intermediate COCOMO एक Effort Adjustment Factor पेश करता है, जिसे आमतौर पर EAF लिखा जाता है। लागत चालक (cost driver) गुणकों की पूरी सूची COCOMO II Model Definition Manual में दर्ज है। प्रयास का सूत्र बनता है:

यहाँ EAF 15 लागत चालकों का गुणनफल है, जिन्हें Very Low से Extra High पैमाने पर आँका जाता है। चालक चार श्रेणियों में विभाजित हैं: उत्पाद गुण (विश्वसनीयता, जटिलता, डेटाबेस आकार), हार्डवेयर गुण (निष्पादन समय और स्टोरेज बाधाएँ), कार्मिक गुण (टीम का अनुभव और क्षमता), और प्रोजेक्ट गुण (टूलिंग, समय-सारणी दबाव, और विकास पद्धतियाँ)।

Intermediate COCOMO के बारे में एक बात: a स्थिरांक अपने Basic मानों से बदलता है। Organic मोड के लिए a 3.2 (2.4 नहीं) हो जाता है। Semi-detached मोड के लिए यह 3.0 पर रहता है। Embedded मोड के लिए यह 2.8 तक घटता है। b, c, और d के घातांक Basic और Intermediate दोनों स्तरों में समान रहते हैं।

कार्मिक लागत चालक उल्टे काम करते हैं: उच्च क्षमता का मतलब छोटा गुणक, जो प्रयास के अनुमान को कम करता है। अनुभवी प्रोग्रामरों की टीम को किसी प्रोजेक्ट को पूरा करने में शुरुआती टीम की तुलना में कम person-months लगते हैं।

Detailed COCOMO

Detailed COCOMO, जिसे कभी-कभी Advanced COCOMO भी कहा जाता है, प्रयास गुणकों को पूरे प्रोजेक्ट के बजाय व्यक्तिगत चरणों के स्तर पर लागू करता है। इसका मतलब है कि आवश्यकताओं का विश्लेषण, विस्तृत डिज़ाइन, कोडिंग, और एकीकरण व परीक्षण के लागत चालक अलग-अलग आँके जाते हैं।

यह सबसे सटीक स्तर है और उपयोग में सबसे समय लेने वाला भी। यह बड़े प्रोजेक्ट्स के लिए उपयुक्त है, जहाँ अलग-अलग टीमें अलग-अलग चरणों की मालिक होती हैं और जहाँ चरणों के बीच प्रयास का वितरण योजना के लिए मायने रखता है।

COCOMO II: आधुनिक संस्करण

1990 के दशक के मध्य तक COCOMO I पुराना लगने लगा था। सॉफ्टवेयर विकास मेनफ्रेम पर वॉटरफॉल प्रोजेक्ट्स से वस्तु-उन्मुख प्रोग्रामिंग, पुन: प्रयोज्य कंपोनेंट लाइब्रेरियों, रैपिड प्रोटोटाइपिंग, और वितरित डेस्कटॉप सिस्टम की ओर शिफ्ट हो चुका था। 1970 के दशक के प्रोजेक्ट डेटा को 1990 के दशक के सॉफ्टवेयर वातावरण पर लागू करने से अविश्वसनीय अनुमान मिल रहे थे।

Boehm और उनके सहयोगियों ने USC Center for Software Engineering में कई साल लगाकर मॉडल को शून्य से फिर बनाया। परिणाम था COCOMO II, जो 2000 में पुस्तक Software Cost Estimation with COCOMO II में प्रकाशित हुआ, और 161 प्रोजेक्ट्स के डेटासेट पर कैलिब्रेट किया गया—मूल मॉडल के 63 का दोगुने से अधिक।

COCOMO II के पीछे की प्रेरणाएँ थीं ऑब्जेक्ट-ओरिएंटेड और कंपोनेंट-आधारित विकास, सॉफ्टवेयर री-यूज़ और कमर्शियल ऑफ-द-शेल्फ एकीकरण, आवर्ती और स्पाइरल विकास मॉडल, और आधुनिक टूलिंग। एक आम गलतफ़हमी स्पष्ट कर लें: COCOMO II Agile विकास के लिए नहीं बनाया गया था। 1995 से 2000 के बीच जब मॉडल विकसित हो रहा था, आज जैसा Agile तब मुश्किल से अस्तित्व में था।

COCOMO II के तीन उप-मॉडल

COCOMO II तीन उप-मॉडल देता है, जिनमें से हर एक प्रोजेक्ट के अलग चरण के लिए उपयुक्त है।

Application Composition Model आरंभिक प्रोटोटाइपिंग के लिए डिज़ाइन किया गया है, खासकर जब टीमें GUI बिल्डर और कंपोनेंट लाइब्रेरी का उपयोग कर रही हों। यह KLOC के बजाय Object Points का उपयोग करता है: स्क्रीन, रिपोर्ट, और थर्ड-जनरेशन लैंग्वेज कंपोनेंट, जिन्हें जटिलता के अनुसार वेट किया जाता है और अपेक्षित री-यूज़ के अनुसार समायोजित किया जाता है। यह एक रैखिक मॉडल है जिसमें न स्केल फैक्टर हैं न घातांकीय समायोजन।

Early Design Model आर्किटेक्चर स्थापित होने से पहले उपयोग किया जाता है। यह Unadjusted Function Points को इनपुट के रूप में लेता है, उन्हें भाषा-विशिष्ट तालिकाओं की मदद से समकक्ष सोर्स लाइनों में बदलता है, और सात लागत चालक लागू करता है। जब आप जानते हैं कि सिस्टम क्या करेगा, पर अभी यह नहीं कि इसे कैसे बनाया जाएगा, तब यह एक उचित अनुमान देता है।

Post-Architecture Model तीनों में सबसे सख्त है। इसे सॉफ्टवेयर आर्किटेक्चर तय होने के बाद तैनात किया जाता है, और यह इनपुट के रूप में Thousands of Source Lines of Code (KSLOC) या फंक्शन पॉइंट्स, 17 लागत चालक, और पाँच स्केल फैक्टर उपयोग करता है। प्रयास का सूत्र है:

जहाँ E एक गतिशील घातांक है, जिसकी गणना इस प्रकार होती है:

और समय-सारणी का सूत्र है:

जहाँ:

2.94, 0.91, 3.67, और 0.28 के स्थिरांक COCOMO II.2000 कैलिब्रेशन से आते हैं। कुछ पुराने स्रोत 2.94 की जगह 2.5 उद्धृत करते हैं; वह 2000-पूर्व कैलिब्रेशन मान है और मौजूदा मॉडल के साथ उपयोग नहीं किया जाना चाहिए। USC COCOMO II Web Tool softwarecost.org पर Post-Architecture मॉडल का एक निःशुल्क, लाइव इम्प्लीमेंटेशन है, यदि आप बिना हाथों से गणना किए अनुमान चलाना चाहें।

COCOMO में लागत चालक और स्केल फैक्टर

दो तंत्र COCOMO II को COCOMO I से अलग तरह से काम कराते हैं: स्केल फैक्टर और लागत चालक। ये क्या करते हैं, यह रहा।

COCOMO I में घातांक b मोड के अनुसार तय होता है: आप Organic, Semi-detached, या Embedded चुनते हैं, और आपको एक पूर्व-निर्धारित संख्या मिलती है। COCOMO II इसे पाँच सतत रेटेड स्केल फैक्टर से प्रतिस्थापित करता है, जो इस पर आधारित घातांक की गणना करते हैं कि आप हर एक को कैसे आँकते हैं।

COCOMO II में पाँच स्केल फैक्टर हैं: पूर्ववृत्तता (PREC), विकास लचीलापन (FLEX), आर्किटेक्चर और जोखिम समाधान (RESL), टीम एकजुटता (TEAM), और प्रक्रिया परिपक्वता (PMAT)। हर एक को Very Low से Extra High पैमाने पर आँका जाता है, और इनका संयुक्त योग प्रयास सूत्र में E निर्धारित करता है। अधिक योग का मतलब है कम परिपक्व, कम परिचित, अधिक जोखिम वाला प्रोजेक्ट—जो उच्च घातांक और अधिक प्रयास का द्योतक है।

स्केल फैक्टर प्रयास वक्र के आकार को प्रभावित करते हैं। इसके विपरीत, लागत चालक आधारभूत प्रयास पर गुणात्मक समायोजन हैं। COCOMO II के Post-Architecture मॉडल में 17 लागत चालक हैं, जबकि Intermediate COCOMO I में 15 थे। COCOMO II में जो जोड़ हुए, उनमें आवश्यक पुन: प्रयोज्यता (RUSE), प्रलेखन आवश्यकताएँ (DOCU), प्लेटफ़ॉर्म अस्थिरता (PVOL), कार्मिक निरंतरता (PCON), एप्लिकेशन अनुभव (APEX), प्लेटफ़ॉर्म अनुभव (PLEX), भाषा और टूल अनुभव (LTEX), और मल्टीसाइट विकास (SITE) शामिल हैं।

एक लागत चालक विशेष रूप से उल्लेखनीय है SCED, जो आवश्यक विकास समय-सारणी को कवर करता है। यदि आप समय-सारणी को काफी संकुचित करते हैं, तो प्रयास गुणक 1.0 से ऊपर चला जाता है—अर्थात तेज़ी से समाप्त करने के लिए वास्तव में अधिक person-months की ज़रूरत होगी। यह उस अनुभव से मेल खाता है जो अधिकांश इंजीनियर पहले से जानते हैं: टीम को लगातार दौड़ाने से समन्वय का ओवरहेड, त्रुटियाँ, और रीवर्क बढ़ता है—जो अक्सर बचाए गए समय से अधिक लागत ले आता है।

COCOMO मॉडल के लाभ

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

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

तीन-स्तरीय संरचना (Basic → Intermediate → Detailed) एक और व्यावहारिक लाभ है। प्रोजेक्ट के शुरुआती चरण में, जब कम ज्ञात होता है, आप मोटे अनुमान के लिए Basic का उपयोग करते हैं। जैसे-जैसे प्रोजेक्ट परिपक्व होता है और टीम व परिवेश के बारे में अधिक समझ बनती है, आप अधिक परिष्कृत योजना के लिए Intermediate या Detailed पर जाते हैं।

COCOMO मॉडल की सीमाएँ

सबसे बड़ी सीमा COCOMO की KLOC पर निर्भरता है। COCOMO उपयोग करने के लिए, आपको कोड लिखने से पहले ही लाइनों में प्रोजेक्ट आकार का अनुमान लगाना होता है। प्रोजेक्ट के शुरुआती चरणों में—ठीक जब अनुमान सबसे अहम होता है—इसे सटीकता से करना कुख्यात रूप से कठिन है।

भले ही KLOC का अनुमान लगाया जा सके, COCOMO I के स्थिरांक 1968 से 1979 के बीच वॉटरफॉल मॉडल के तहत बने 63 प्रोजेक्ट्स से आए हैं। COCOMO II के स्थिरांक 1990 के दशक के 161 प्रोजेक्ट्स से हैं। न तो किसी डेटासेट में क्लाउड-नेटिव सिस्टम, मोबाइल एप्लिकेशन, माइक्रोसर्विस आर्किटेक्चर, या आधुनिक DevOps पाइपलाइंस शामिल हैं। बिना स्थानीय कैलिब्रेशन के इन स्थिरांकों को सीधे किसी आधुनिक प्रोजेक्ट पर लागू करना अविश्वसनीय अनुमान देता है।

2025 के एक अध्ययन ने इसे संख्याओं में दिखाया। NASA प्रोजेक्ट डेटासेट पर लागू एक बिना-कैलिब्रेटेड Basic COCOMO ने लगभग 100% औसत सापेक्ष त्रुटि दी, और कोई भी भविष्यवाणी वास्तविक प्रयास के 25% के भीतर नहीं थी। यह त्रुटि की छोटी सीमा नहीं है; यह उस स्थिति को दर्शाता है जहाँ मॉडल को उन शर्तों के बाहर उपयोग किया जा रहा है जिनके लिए यह बनाया गया था।

मॉडल आवर्ती (iterative) विकास को भी ठीक से नहीं संभालता। COCOMO एक पर्याप्त रूप से अनुक्रमिक जीवनचक्र मानता है। Agile टीमें जो छोटे स्प्रिंट्स में बदलती बैकलॉग के साथ काम करती हैं, वे COCOMO की संरचना में निहित वॉटरफॉल मान्यताओं में फिट नहीं बैठतीं।

एक गहरी समस्या भी है। Frontiers in Artificial Intelligence में मार्च 2026 में प्रकाशित एक पेपर ने तर्क दिया कि COCOMO II एआई-सहायतित सॉफ्टवेयर विकास के साथ मूल रूप से असंगत है—सिर्फ कैलिब्रेशन का मसला नहीं, संरचनात्मक रूप से। जब एआई कोडिंग टूल्स कोडबेस का बड़ा हिस्सा जनरेट करते हैं, तो मानवीय प्रयास के प्रतिनिधि के रूप में KLOC भ्रामक हो जाता है। अब प्रयास का केंद्र सत्यापन, आर्किटेक्चरल गवर्नेंस, और सुरक्षा समीक्षा पर है—जिन्हें कैप्चर करने के लिए COCOMO के लागत चालक ढाँचे को डिज़ाइन नहीं किया गया था।

COCOMO मॉडल बनाम अन्य अनुमान तकनीकें

COCOMO अकेला विकल्प नहीं है। विकल्पों को जानना आपको स्थिति के अनुसार सही दृष्टिकोण चुनने में मदद करता है।

Function Point Analysis (FPA) सिस्टम जटिलता को उपयोगकर्ता-उन्मुख इनपुट और आउटपुट से मापता है, प्रोग्रामिंग भाषा से स्वतंत्र। जब आपके पास ठोस आवश्यकताएँ हों लेकिन अभी KLOC अनुमान न हो, तब यह अच्छा काम करता है। COCOMO II का Early Design मॉडल फंक्शन पॉइंट्स को इनपुट के रूप में स्वीकार करता है, इसलिए दोनों साथ उपयोग हो सकते हैं।

Story Points Agile वातावरण में मानक हैं। टीमें यूज़र स्टोरीज़ का सापेक्ष जटिलता के आधार पर मूल्यांकन करती हैं, फिर वेग (velocity) ट्रैक कर प्रगति का अनुमान लगाती हैं। ये तेज़ और टीम-विशिष्ट होते हैं, लेकिन वे कुल-लागत का वह आधार नहीं देते जो प्रोक्योरमेंट और दीर्घकालीन योजना के लिए आवश्यक होता है। COCOMO और स्टोरी पॉइंट्स अलग उद्देश्य साधते हैं।

SEER-SEM और SLIM जैसे पैरामीट्रिक टूल्स स्वामित्व वाली कैलिब्रेशन डेटाबेस और व्यापक पैरामीटर सेट्स का उपयोग करते हैं। अध्ययनों में पाया गया है कि वे बिना-कैलिब्रेटेड COCOMO II से सटीकता में बेहतर प्रदर्शन करते हैं। COCOMO का लाभ पारदर्शिता और खुली उपलब्धता है, जो शैक्षणिक या ऑडिट योग्य संदर्भों में मायने रखता है।

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

COCOMO मॉडल उदाहरण (व्यवहारिक गणना)

COCOMO अन्य विधियों के सापेक्ष कहाँ फिट बैठता है, यह जानना उपयोगी है, लेकिन वास्तव में यह कैसे काम करता है, समझने का सबसे अच्छा तरीका संख्याएँ चलाना है। आइए Organic मोड और 50 KLOC के अनुमानित प्रोजेक्ट का उपयोग करते हुए एक पूरा Basic COCOMO I कैलकुलेशन करते हैं।

Organic मोड के स्थिरांक हैं: a = 2.4, b = 1.05, c = 2.5, d = 0.38.

चरण 1: प्रयास की गणना

50^1.05 निकालने के लिए, इस तथ्य का उपयोग करें कि ।

चरण 2: विकास समय की गणना

चरण 3: आवश्यक लोगों की गणना

Summary:

दो बातें ध्यान देने योग्य हैं। Person-months और कैलेंडर महीने अलग इकाइयाँ हैं: 16.6 कैलेंडर महीनों में 145.8 person-months का मतलब लगभग 9 लोग समानांतर में काम कर रहे हैं। और चूँकि यह Basic COCOMO है, यह केवल आकार और मोड का उपयोग करता है। वास्तविक लागत चालक रेटिंग्स जोड़ने पर EAF के ज़रिए प्रयास का अनुमान वहाँ से ऊपर या नीचे शिफ्ट हो सकता है।

सॉफ्टवेयर इंजीनियरिंग इंटरव्यू में COCOMO मॉडल

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

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

निष्कर्ष: क्या COCOMO मॉडल अब भी प्रासंगिक है?

जहाँ इसकी मान्यताएँ सही बैठती हैं—अनुक्रमिक विकास, औपचारिक प्रोक्योरमेंट, और अकादमिक अध्ययन—वहाँ COCOMO उपयोगी है। जहाँ आधुनिक सॉफ्टवेयर इन शर्तों से अलग जाता है, वहाँ यह कमजोर पड़ता है।

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

COCOMO III लगभग 2015 से Boehm CSSE में विकासाधीन है, मार्च 2026 तक कोई सार्वजनिक रिलीज़ नहीं। 1981 का मूल और 2000 का अपडेट ही मानक बने हुए हैं।

सॉफ्टवेयर विकास में और आगे बढ़ना चाहते हैं? हमारे पास Software Engineering Principles in Python, Software Development with Cursor, और Software Development with GitHub Copilot पर कोर्स हैं जो यहाँ सीखी बातों को बनाने में आपकी मदद करेंगे।