1ation DSS और COCOMO II विधि द्वारा परियोजनाओं की लागत और लागत का आकलन

लेख COCOII विधि का उपयोग करके परियोजनाओं की अवधि और लागत का आकलन करने के लिए 1C DSS (एप्लीकेशन डिज़ाइन सिस्टम) का उपयोग करने की विधि पर चर्चा करता है।

ग्राहक को कैसे औचित्य दें कि परियोजना के समय का आपका मूल्यांकन उद्देश्यपूर्ण है?

प्रेजेल स्टेज पर शुरू होने से पहले किसी प्रोजेक्ट के मार्जिन को कैसे मापें?

नुकसान को रोकने के लिए परियोजना मूल्य पर ट्रेडिंग रेंज का मूल्यांकन कैसे करें?

टीम के सदस्यों के लिए एक परियोजना की आवश्यकता को जानबूझकर कैसे गणना की जाए, जो डेवलपर्स (व्यापार विश्लेषक, कार्यप्रणाली, तकनीकी लेखक, आदि) नहीं हैं, सबसे सरल और सस्ती तरीके से अपने काम के परिणाम को कैसे औपचारिक रूप दें?

सामग्री की तालिका

• परिचय।
• वर्तमान समय में 1C DSS का उपयोग करने की मुख्य समस्या है।
• COCOMOII क्यों?
• क्यों 1C DSS?
• COCOMOII सबसे छोटा कोर्स
• विश्लेषकों और श्रमिकों के श्रमिकों के श्रम मूल्यांकन के लिए डेवलपर्स के श्रम मूल्यांकन से संक्रमण
• छद्म कोड।
• 1se DSS और छद्म कोड।
• सारांश

प्रविष्टि

1C एप्लीकेशन डिज़ाइन सिस्टम को 6 साल पहले बाजार में लॉन्च किया गया था और जुलाई 2019 में यह 2 संस्करण तक बढ़ गया। SADT प्रौद्योगिकियों और एक कैस्केडिंग विकास मॉडल पर आधारित। हालाँकि, यह आपको व्यक्तिगत चरणों में स्क्रम / एजाइल विकास का नेतृत्व करने की अनुमति देता है।

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

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

वर्तमान में 1C DSS का उपयोग करने की मुख्य समस्या

वर्तमान में 1C DSSR का उपयोग करने की मुख्य समस्या (संस्करण 1 मुख्य रूप से उपयोग की जाती है) प्रौद्योगिकी के रूप में 1C DSS का अत्यंत गलत उपयोग है।

1 सी डीएसएस का उपयोग अक्सर डेवलपर्स के लिए कार्यक्षमता के स्तर पर किया जाता है, आर्किटेक्ट के लिए सबसे अच्छा है। इसकी भूमिका अक्सर सिस्टम के "कार्यों" और प्रोग्रामर के लिए कार्यों के गठन के विवरण और विकास के लिए नीचे आती है। यह DSS के साथ काम करने के दृष्टिकोण की गलती है।

बाजार पर मौजूदा सिस्टम (JIRA, आदि) प्रोग्रामर के लिए कार्य स्थापित करने और उपयोगकर्ता टिकटों को संसाधित करने का एक बड़ा काम कर रहे हैं। इस उपयोग के साथ, डीएसएस डेवलपर्स के पास अभी तक एक और समय लेने वाली नौकरशाही ऐड-इन है, जो "शुद्ध" कोडिंग से समय लेता है।

डेवलपर मेटाडेटा ऑब्जेक्ट्स ("आम भाषा" के रूप में अपने कार्य "ऑब्जेक्ट-ओरिएंटेड डिज़ाइन (DDD) जटिल सॉफ़्टवेयर सिस्टम की संरचना") के लिंक के साथ प्रोग्रामर के लिए कार्यों की स्थापना सुनिश्चित करने के लिए कार्यान्वित / अंतिम रूप से लागू प्रणाली की कार्यक्षमता का वर्णन करने के लिए बाध्य हो जाता है।

इसी समय, परियोजना टीम के अन्य आधे के कार्यों - परियोजना प्रबंधकों, व्यापार विश्लेषकों, कार्यप्रणाली को लगभग पूरी तरह से अनदेखा कर दिया जाता है। दुर्भाग्य से, हम यह कह सकते हैं कि DSS के संस्करण 2.0 में भी 1C ही प्रतिभागियों की इस श्रेणी के लिए कार्यक्षमता को काफी कम कर देता है, डेवलपर्स और परीक्षकों की ओर संस्करण 1.0 की तुलना में DSS मॉडल को काफी बदल रहा है (उदाहरण के लिए: आवश्यकताओं और डेटा ऑब्जेक्ट्स को स्पष्ट रूप से हटा दिया गया था)।

फिर भी, डीएसएस के पूर्ण और पूर्ण उपयोग का मुद्दा तीव्र है। इस लेख में, विशेष रूप से, हम विचार करेंगे कि कैसे COCOMOII विधि का उपयोग करके परियोजनाओं की शर्तों और लागत का आकलन करने के लिए प्रौद्योगिकी का उपयोग 1C DSS में किया जा सकता है।

हर कोई जानना चाहता है कि कोई परियोजना कब तक पूरी हो सकती है, जिसके बारे में ग्राहक स्वयं यह नहीं कह सकता कि वह आखिर चाहता क्या है, और ग्राहक के साथ सौदेबाजी करना किस हद तक उचित है?
और ग्राहक को कैसे विश्वास दिलाया जाए कि प्रस्तावित समय और लागत उचित है? हालांकि, उत्तरार्द्ध खुद के लिए जानना हानिकारक नहीं है।

और सबसे महत्वपूर्ण बात यह है कि टीम के सदस्यों के लिए प्रोजेक्ट की आवश्यकता की गणना कैसे की जाए, जो डेवलपर्स (व्यवसाय विश्लेषक, कार्यप्रणाली, तकनीकी लेखक आदि) नहीं हैं, सबसे सरल और सस्ती तरीके से अपने काम के परिणाम को कैसे औपचारिक रूप दिया जाए?

COCOMOII क्यों?

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

सूचना के अभाव में प्रेस् टेल चरण में समय और लागत का मूल्यांकन कैसे करें? और परियोजना के पाठ्यक्रम में, खाते में परिवर्तन (सभी परियोजनाओं के संकट) को ले रहा है?

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

क्यों 1C DSS?

बात यह है कि 1C DSS SADT और "सामान्य भाषा" प्रौद्योगिकियों पर आधारित है (यह मेरी पहचान में अधिक विवरण में वर्णित है)। यह SADT है जो "सामान्य भाषा" पर आधारित विकास प्रक्रिया के साथ मॉडलिंग प्रक्रिया को एकीकृत करता है। एक "आम भाषा" आपको शर्तों के अनुमानित संकेतकों की गणना करने के लिए एक आधार देती है।

COCOMOII सबसे छोटा कोर्स

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

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

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

विश्लेषकों और श्रमिकों के श्रमिकों के श्रम मूल्यांकन के लिए डेवलपर्स के श्रम मूल्यांकन से संक्रमण

चौकस और अनुभवी पाठकों को प्राप्त होगा:
“ठीक है! COCOMO विधि के सभी पेशेवरों और विपक्षों के साथ, यह सॉफ्टवेयर परियोजनाओं का मूल्यांकन करने के लिए डिज़ाइन किया गया है। डेवलपर्स, प्रोग्रामर के काम को सशर्त KSLOC में डिजिटल किया जा सकता है। लेकिन विश्लेषकों और पद्धतिविदों, परियोजना प्रबंधकों और प्रबंधकों के बारे में क्या? और 1C DSS का इससे क्या लेना-देना है? ”

यह सही है!

तो, कार्य सूचीबद्ध टीम के सदस्यों के लिए एक समान आधार का चयन करना है जो आपको COCOMOII तकनीक का उपयोग करने की अनुमति देगा। यहाँ वह मंच पर जाता है।

छद्म कोड

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

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

यदि परियोजना को GOST आवश्यकताओं के अनुसार प्रस्तुत किया जाता है, तो परियोजना दस्तावेजों की संरचना को इन मानकों द्वारा परिभाषित किया जाता है, अन्यथा, यह ठेकेदार के विवेक पर या ग्राहक के साथ अनुबंध की आवश्यकताओं के अनुसार बनाया जाता है।

एक दिलचस्प बात यह है कि यदि प्रोजेक्ट टीम और ग्राहक समय के साथ बने रहने का निर्णय लेते हैं और पेपरलेस तकनीक का उपयोग करते हुए विशेष रूप से प्रोजेक्ट परिणाम तैयार करेंगे, तो 1C DSS को इससे कैसे जोड़ा जाएगा?

उत्तर - सबसे सीधे तरीके से - डीएसएस और परियोजना द्वारा भरी गई इसकी निर्देशिका की सामग्री एक संरचित डेटा ऑब्जेक्ट और कार्य का परिणाम होगा। जो ग्राहक को हस्तांतरित करने के लिए बहुत सुविधाजनक है। परियोजना के दौरान बनाए गए सभी दस्तावेज़ डीएसएस कॉन्फ़िगरेशन ऑब्जेक्ट्स से जुड़े दस्तावेज़ होंगे।

सरलीकृत उत्पादन परियोजना दस्तावेज निम्नलिखित छद्म कोड के समूहों में विभाजित हैं:

1. दस्तावेज़ की संरचना (सामग्री की तालिका);
2. दस्तावेज़ परीक्षण;
3. दस्तावेज़ तालिका पंक्ति (तालिका);
4. रेखाचित्र (ग्राफिक ऑब्जेक्ट)।

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

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

1se DSS और छद्म कोड

सवाल उठता है कि 1 सी डीएस में छद्म कोड कैसे रखा जाए।

यह "डेटा ऑब्जेक्ट्स" निर्देशिका के माध्यम से किया जा सकता है। एक अलग समूह "OUTPUT DOCUMENTS" बनाया जाता है, इसके भीतर प्रत्येक प्रकार के दस्तावेज़ के लिए उपसमूह होते हैं, फिर प्रत्येक अलग दस्तावेज़ के लिए एक और उपसमूह, और परियोजना दस्तावेज़ की सामग्री की तालिका की निर्देशिका के तत्वों के रूप में इन उपसमूहों के अंदर।

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

प्रोजेक्ट डॉक्यूमेंट के टेक्स्ट को पैराग्राफ में डायरेक्टरी एलिमेंट "डेटा ऑब्जेक्ट्स" के टेक्स्ट फील्ड के रूप में टाइप किया जा सकता है।

"डेटा ऑब्जेक्ट्स" संदर्भ पुस्तक में आउटपुट प्रोजेक्ट दस्तावेजों की संरचना का वर्णन करते समय किसी को क्या प्रयास करना चाहिए?

यह सुनिश्चित करने के लिए प्रयास करना आवश्यक है कि "डेटा ऑब्जेक्ट्स" निर्देशिका के प्रत्येक तत्व में एक मेटाडेटा ऑब्जेक्ट और / या एक डेटा ऑब्जेक्ट ("डेटा ऑब्जेक्ट्स" निर्देशिका के अन्य समूहों से लिंक हो सकता है जो आउटपुट दस्तावेजों के अन्य संरचनाओं का वर्णन नहीं करते हैं, लेकिन कई प्रकार पर बनाए गए हैं। डेटा परियोजना, उदाहरण के लिए: विश्लेषक सूची)।

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

निर्देशिका के प्रत्येक तत्व या समूह को आवश्यकताओं के साथ "डेटा ऑब्जेक्ट्स" को जोड़ना (ग्राहक और परियोजना टीम के सदस्यों द्वारा तैयार दोनों, मेटाडेटा के लिए विस्तृत), आप अंत में एंड-टू-एंड लिंक आवश्यकताएं प्राप्त कर सकते हैं - मेटाडेटा ऑब्जेक्ट - आउटपुट प्रोजेक्ट दस्तावेज़। DSS 2.0 में, "विचार" "आवश्यकताओं" के बराबर हैं।
1 सी डीएसएस में परियोजनाओं के कार्यान्वयन में अनुभव के संचय के साथ, ऐसी निर्देशिका संरचना क्रिस्टलीकृत होगी जो सभी समान परियोजनाओं पर समान होगी। इसलिए, एक नई परियोजना के लिए, बस इसे कॉपी करने के लिए पर्याप्त है। और आउटपुट परिणामों में समान परियोजनाओं के लिए, आप पाठ (तालिका) की प्रतिलिपि बना सकते हैं।

सारांश

इंटीग्रेटर्स और संगठन परियोजनाओं के एक अच्छी तरह से विकसित डेटाबेस के साथ, पिछली परियोजनाओं की सामग्री का ऑडिट कर रहे हैं, अपने निपटान में योजनाबद्ध और चल रही परियोजनाओं की समय और लागत का एक उद्देश्य मूल्यांकन प्राप्त कर सकते हैं।

इससे ग्राहक बी के साथ सौदेबाजी की उम्मीद की गई है) अपेक्षित मुनाफे का आकलन करना चाहिए।