⛽️ 🏛️ ☘️ एक सॉफ्टवेयर विकास परियोजना के श्रम लागत का मूल्यांकन: यूक्रेनी वास्तविकता में अभ्यास 👩🏽‍🤝‍👨🏾 ⛏️ 👨‍🎨

प्रविष्टि

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

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

लेख में निम्नलिखित भाग हैं:

परियोजना के कार्यान्वयन में यूक्रेनी वास्तविकताओं
समस्याओं और समाधान
मूल्यांकन की तैयारी
मूल्यांकन के लिए कार्यों की सूची
कोड लेखन मूल्यांकन
अभ्यास से आंकड़े और गुणांक
गणना उदाहरण

परियोजना के कार्यान्वयन में यूक्रेनी वास्तविकताओं

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

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

असफल परियोजना प्रबंधन (यदि टीम ग्राहक के अनुरोध का पालन करती है) के मामले में, टीम आसानी से समय और बजट से अधिक हो जाती है, क्योंकि अनुबंध पर हस्ताक्षर किए जाते हैं और बजट पर सहमति होती है, फिर नुकसान काम करता है।
यह स्पष्ट है कि हर चीज के लिए केवल ग्राहक को दोष देना गलत है। आपको यह समझने की आवश्यकता है कि परियोजना मूल्यांकन अक्सर आवश्यकताओं के पर्याप्त विश्लेषण के बिना किया जाता है, कार्यों को पर्याप्त रूप से और गलत तरीके से नहीं लिखा जाता है, और बहुत बार, केवल प्रोग्रामिंग को मूल्यांकन में शामिल किया जाता है, परीक्षण और प्रबंधन को अपर्याप्त मात्रा में ध्यान में रखा जाता है। जब एक अनुबंध पर हस्ताक्षर किए जाते हैं, तो विक्रेता ग्राहक की ओर जाते हैं, कीमत कम करते हैं, और परियोजना के दौरान टीम दृढ़ता से अपनी स्थिति का बचाव नहीं करती है (परियोजना प्रबंधक पहले और सबसे महत्वपूर्ण है, लेकिन इस मामले में यह "टीम" कहने के लायक है, क्योंकि सभी प्रतिभागियों को परिणाम पर ध्यान केंद्रित करना चाहिए और यदि प्रतिभागी समस्या को देखता / अनुमान करता है, तो उसे मुखिया को सूचित किया जाना चाहिए)।
इसके अलावा, एक और कारक है - परियोजनाओं, प्रणालियों और प्रौद्योगिकियों की विविधता, और योग्य विशेषज्ञों की कमी। इसका मतलब यह है कि एक परियोजना की योजना बनाते समय, वास्तुकार या परियोजना प्रबंधक इस बात को ध्यान में नहीं रख सकते हैं कि उन्हें टीम में एक विशेषज्ञ मिल सकता है, जिन्होंने पहले ऐसे कार्य नहीं किए हैं या अपर्याप्त योग्यता वाले किसी विशेषज्ञ से। यह स्पष्ट है कि इस मामले में प्रदर्शन उम्मीद से कम होगा।
इस स्थिति में क्या किया जा सकता है? परियोजना का मूल्यांकन कैसे करें ताकि अनुमानित श्रम लागत पर्याप्त सटीक हो?
सबसे पहले, समस्याओं पर विचार करें और एक समाधान खोजने की कोशिश करें।

समस्याओं और समाधान

1. ग्राहक अनुबंध पर हस्ताक्षर करने से पहले परियोजना की लागत और शर्तों के सटीक आंकड़े जानना चाहता है

समाधान:
1.1। स्वीकृति मानदंड पहचानें और तैयार करें। यह कैसे करना है? देखें [१]। लब्बोलुआब यह है कि ग्राहक को सही प्रश्न पूछने की आवश्यकता है: "आप कैसे जानते हैं कि परियोजना सफल है?" और "कौन, किसको और कैसे सिस्टम को सौंपेगा?", साथ ही उस व्यक्ति को जो सवाल का जवाब पाने का फैसला करेगा "क्या आवश्यक है?" परियोजना को स्वीकार करें ”
1.2। कई आवश्यकताओं के रूप में पहचानें और सबसे महत्वपूर्ण बात यह है कि परियोजना पर प्रतिबंध संभव है (यानी, न केवल कार्यात्मक, बल्कि कार्यात्मक आवश्यकताएं भी नहीं हैं)
1.3। आवश्यकताओं का परीक्षण करें। सरल शब्दों में, यह सत्यापित करना आवश्यक है कि लिखित आवश्यकताएं यथार्थवादी, सुसंगत और तैयार की गई हैं ताकि यह स्पष्ट रूप से सत्यापित हो सके कि समाधान उनसे मेल खाता है या नहीं। फिर से, मैं देखने की सलाह देता हूं [1]
1.4। इसके आधार पर, यथासंभव कार्यों की सूची पेंट करें (लेख में आगे देखें)

2. ग्राहक कार्यों की अधिक या कम विस्तृत सूची देखना चाहता है, जो कि परियोजना की लागत का समन्वय करते समय, सबसे अनुचित तरीकों से पहले अवसर में कटौती करता है।

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

सभी रिकॉर्ड देखने की क्षमता - 8 घंटे
क्षेत्र 1 - 8 घंटे तक छानने की संभावना
क्षेत्र 2 - 8 घंटे तक छानने की संभावना
फ़ील्ड 1 - 8 घंटे के आधार पर छंटनी
क्षेत्र 2 - 8 घंटे द्वारा छँटाई
फ़ील्ड 1 - 8 घंटे द्वारा समूहीकृत करना
फ़ील्ड 2 - 8 घंटे द्वारा समूहीकृत करना

लेकिन वास्तव में, इन कार्यों के तहत बुनियादी कार्यक्षमता होती है - डेटाबेस में तालिकाओं का निर्माण, संग्रहीत प्रक्रियाओं या विचारों को लाने के लिए, व्यावसायिक वस्तुओं का निर्माण, उन्हें सुरक्षा मॉड्यूल से जोड़ना, लॉगिंग मॉड्यूल, कॉन्फ़िगरेशन से कनेक्ट करना, और इसी तरह।
यदि ग्राहक कहता है कि क्या होगा: नहीं यह बहुत लंबा है। आइए समूहीकरण और छंटाई (शून्य से 32 घंटे) के कार्यों को कम करें और निकालें। उसी समय, विक्रेता, जो परियोजना पर काम करने के लिए चर्चा कर रहा है “के पास कुछ भी नहीं है। और दूसरी ओर, 24 घंटों में, पूरी मात्रा, सिद्धांत रूप में, समय नहीं होता है।
इसलिए, मैं बुनियादी कार्यक्षमता को उजागर करने की सलाह देता हूं, जिसे केवल संपूर्ण कार्य को हटाकर हटाया जा सकता है। इस उदाहरण में, यह कार्य "डेटाबेस से डेटा पुनर्प्राप्त करना", कहता है, 28 घंटे, और बाकी कार्यों में प्रत्येक 4 घंटे लगते हैं।
यह एक ही टीम को प्रतिस्थापित किए बिना, विक्रेता को बोली के दौरान अधिक सही ढंग से व्यवहार करने की अनुमति देगा। अनावश्यक विशेषताओं को हटाकर, आपके पास अभी भी विकास के लिए पर्याप्त समय है।

3. अनुबंधों पर हस्ताक्षर करने के बाद आवश्यकताओं का एक विस्तृत विश्लेषण, तकनीकी विशिष्टताओं का लेखन और परियोजना पर काम का अधिक या कम स्पष्ट क्षेत्र होता है

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

4. लगभग परियोजना के मध्य तक, ग्राहक खुद नहीं जानता कि वह क्या चाहता है (एकत्रित आवश्यकताओं के चरण का उल्लेख नहीं करना)

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

5. ग्राहक चाहता है कि टीम लचीले ढंग से उसकी इच्छाओं (परिवर्तन, परिवर्धन) के करीब पहुंचे और उन्हें परियोजना के ढांचे के भीतर लागू करे, न कि बाद के सुधारों के हिस्से के रूप में, जबकि ग्राहक बिल्कुल परियोजना बजट को बदलने के बारे में कुछ भी सुनना नहीं चाहता है।

समाधान:
5.1। हम स्पष्ट रूप से परियोजना योजना में संभावित बदलावों के लिए समय शामिल करते हैं (हम समय पर और बजट पर, जोखिमों से बाहर एक बफर डालते हैं), जो ग्राहक के अनुरोध पर, उन परिवर्तनों और सुधारों पर खर्च किया जाएगा जिनकी उन्हें आवश्यकता है। यह, सबसे पहले, परियोजना के ढांचे के भीतर बदलावों पर काम करना संभव बनाता है, और दूसरी बात, यह ग्राहक को प्रभावी उद्देश्यों पर सावधानीपूर्वक विचार करने के लिए मजबूर करता है, क्योंकि यह संसाधन पहले से ही स्पष्ट रूप से सीमित है
5.2। विकास के लिए एक पुनरावृत्त दृष्टिकोण की संभावना को ध्यान में रखें और इन पुनरावृत्तियों की योजना बनाएं। बैठकों, प्रसव, प्रदर्शनों और अधिक की संख्या को ध्यान में रखें।
5.3। जैसा कि ऊपर वर्णित है, अनुबंध में (अनुबंध के लिए एक संदर्भ के रूप में, या संदर्भ के रूप में), हम परियोजना के दायरे से परे जाने वाली हर चीज का वर्णन करने वाले एक खंड को शामिल करते हैं और जिसे ग्राहक ने स्पष्ट रूप से मना कर दिया है।

6. ग्राहक सिस्टम पर बहुत सारे दस्तावेज देखना चाहता है।

समाधान:
हम परियोजना लागत की गणना में दस्तावेज बनाने की लागत को शामिल करते हैं (जैसा कि आप नीचे देखेंगे, राशि पर्याप्त हो सकती है)

7. इस स्थिति में कि परियोजना टीम का फिर से गठन किया गया है, एक जोखिम है कि किसी विशेषज्ञ की योग्यता अपेक्षा से कम हो सकती है।

निर्णय
जब कार्यों और उनके कार्यान्वयन के लिए समय की योजना बनाते हैं, तो परियोजना में शामिल होने की अपेक्षा विशेषज्ञों से कम स्तर पर ध्यान केंद्रित करना आवश्यक है

8. आईटी प्रौद्योगिकी और कार्य तेजी से कठिन होते जा रहे हैं, जिससे परियोजना के शुरुआती चरणों में चयनित प्रौद्योगिकियों के नुकसान की पहचान करना मुश्किल हो रहा है

समाधान:
8.1। जोखिम के लिए एक निश्चित समय योजना में रखना आवश्यक है, जिसका उपयोग टीम अपने विवेक से कर सकती है

8.2। जितनी जल्दी हो सके हम जोखिम भरा प्रौद्योगिकियों से संबंधित कार्य करते हैं

कहां से शुरू करें

जैसा कि मैंने पहले लिखा था, समझें कि परियोजना के लक्ष्य को प्राप्त करने और [1] पास करने के लिए क्या करने की आवश्यकता है
संभव के रूप में परियोजना पर कई आवश्यकताओं और प्रतिबंधों को पहचानें। इसके लिए आवश्यकताओं की पहचान करना याद रखें:
एक। प्रलेखन। यदि आप नहीं जानते हैं कि सॉफ़्टवेयर के लिए किस प्रकार का प्रलेखन है, तो आप उदाहरण के लिए, GOST (ESPD) 19.101-77 "प्रोग्राम्स और प्रोग्राम दस्तावेज़ों के प्रकार" [3] या अन्य कार्यप्रणाली के विनिर्देशों का उल्लेख कर सकते हैं, और इस आधार पर ग्राहक को एक सूची प्रदान करते हैं, जिसमें से वह सही का चयन करने में सक्षम होगा
ख। गैर-कार्यात्मक आवश्यकताएं [4], जो, उदाहरण के लिए, इसमें शामिल हो सकती हैं: स्थानीयकरण, बैकअप, निगरानी, लॉगिंग, सुरक्षा, डेटा प्रवास, प्रारंभिक डेटा अपलोड, स्थापना आवश्यकताएँ, कॉन्फ़िगरेशन आवश्यकताएँ।
यह जानकारी ग्राहक सहायता और सुरक्षा आईटी सेवाओं से प्राप्त की जा सकती है।
प्राप्त आवश्यकताओं का परीक्षण करें [1]
यथासंभव कार्यों की सूची का वर्णन करें, ताकि प्रत्येक कार्य में काफी समय सीमा हो। उदाहरण के लिए, परियोजना मूल्यांकन के चरण में, कार्यों को एक दिन तक तोड़ा और मूल्यांकन किया जा सकता है
मूल्यांकन में विभिन्न क्षेत्रों के विशेषज्ञ शामिल होने चाहिए: प्रोजेक्ट मैनेजर, डेवलपर, टेस्ट इंजीनियर, तैनाती और कार्यान्वयन विशेषज्ञ, प्रयोज्य विशेषज्ञ, उत्पाद प्रबंधन विशेषज्ञ (उत्पाद प्रबंधक, यह एक ही विश्लेषक हो सकता है)

मूल्यांकन के लिए कार्यों की सूची

इससे पहले कि हम विशिष्ट संख्याओं और गुणांक पर आगे बढ़ें, विचार करें कि कार्यों की सूची में शामिल करने के लिए आपको किन कार्यों को याद रखने की आवश्यकता है

विश्लेषण और आवश्यकताओं के संग्रह का चरण

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

समाधान डिजाइन

टीके लेखन
एक समाधान वास्तुकला लेखन
परीक्षण TK और समाधान वास्तुकला
विषय प्रशिक्षण
विकास और परीक्षण वातावरण स्थापित करें
एक परीक्षण योजना और सिस्टम परीक्षण विकल्प लिखना
ग्राहक के साथ बैठकें

विकास और आंतरिक परीक्षण

साप्ताहिक डेवलपर बैठकें
प्रोग्रामिंग
कोड सुधार
प्रदर्शन (तैयारी और आचरण)
परीक्षण वातावरण पर समाधान की पहली स्थापना
परीक्षण मामलों को पास करना

ग्राहक परीक्षण

ग्राहक परीक्षण वातावरण में पहली स्थापना
बीटा डिलीवरी
खराबी को अंतिम रूप देना और सुधारना

की शुरूआत

एक उत्पादन सर्वर पर स्थापना
उपयोगकर्ता प्रशिक्षण
लेखन निर्देश

इसके साथ ही

जोखिम का समय
बदलाव का समय
परियोजना प्रबंधन

पहला कदम समाधान की प्रोग्रामिंग की अवधि का मूल्यांकन करना है, जिसके बाद आप परियोजना की पूर्ण अवधि की गणना करने के लिए अतिरिक्त कारक और धारणाएं लागू कर सकते हैं।

कोड लेखन मूल्यांकन

विकास कार्यों का मूल्यांकन करने के लिए, मेरा सुझाव है कि आप इन नियमों का पालन करें:

* परियोजना के लक्ष्य को प्राप्त करने के लिए, इसे उपयोगकर्ता क्रियाओं में तोड़ दें, जो कार्यों में विभाजित हैं, जो बदले में उप-कार्य आदि हैं। और इसी तरह, जब तक कि प्रत्येक कार्य जूनियर डेवलपर स्तर पर किसी व्यक्ति के लिए समझ में नहीं आता है, और इसके कार्यान्वयन को सत्यापित करने के तरीके पर स्पष्ट मानदंड होंगे

* उन बुनियादी कार्यों को उजागर करना न भूलें जिन्हें खारिज नहीं किया जा सकता है
निम्नलिखित कार्यों पर विचार करना न भूलें:

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

अभ्यास से आंकड़े और गुणांक

परियोजना के लिए एक नए व्यक्ति को पेश करने और उसके लिए विकास के वातावरण को स्थापित करने के लिए, कम से कम 40 घंटे (1 सप्ताह) की योजना बनाएं
साप्ताहिक डेवलपर बैठकें - प्रत्येक डेवलपर के लिए प्रत्येक सप्ताह 4 घंटे
परीक्षण सर्वर पर समाधान की प्रारंभिक स्थापना - योजना 80 घंटे (2 सप्ताह)
प्रत्येक प्रदर्शन की तैयारी के लिए - 8 घंटे (प्रदर्शनों से पहले मॉड्यूल के निर्माण और परीक्षण के लिए समय लगता है; 8 घंटे अगर परियोजना में 3 डेवलपर्स हैं, अगर अधिक डेवलपर्स हैं, तो हम उसी तरह से वृद्धि करते हैं)
ग्राहक के साथ बैठकें (प्रदर्शन) - 4 घंटे के लिए प्रत्येक बैठक (मेरे अनुभव में तीन के लिए एक बैठक में जाना बेहतर है: परियोजना प्रबंधक, वास्तुकार, विश्लेषक या परीक्षण विशेषज्ञ)
ग्राहक के परीक्षण वातावरण में पहली स्थापना - 40 घंटे
ग्राहक के काम के माहौल में पहली स्थापना - 40 घंटे
प्रत्येक वितरण की तैयारी और प्रेषण - 8 घंटे (इसमें संकलन, पैकेजिंग, स्थापना प्रक्रिया लिखना, स्थापना सहायता शामिल है)
खराबी का अंतिम रूपकरण और सुधार (रीफैक्टरिंग) - विकास का 25%
विकास पर खर्च किए गए समय का 30-50% परीक्षण करने के लिए कार्य (एक आवश्यकताओं के दस्तावेज़ का विकास, तकनीकी विशिष्टताओं का विकास, कार्यक्षमता, आदि)
जोखिम का समय - कुल समय का कम से कम 10%
समय बदलें - कुल समय का कम से कम 10%
परियोजना प्रबंधन - कुल परियोजना समय का 15%
खराबी को अंतिम रूप देना और सुधारना - विकास के समय का 25%
एक विश्लेषक प्रति दिन अनुमोदित प्रलेखन के औसतन 3 पृष्ठ बनाता है

गणना उदाहरण

मान लीजिए, मूल्यांकन के परिणामस्वरूप, कुछ आंकड़े प्राप्त किए जाते हैं

विकास कार्यों (डिजाइन सहित) का विश्लेषण करने के बाद, हमें 1,200 मानव-घंटे मिले।
हम तय करते हैं कि 3 डेवलपर्स विकास कार्यों का संचालन करेंगे। फिर विकास कार्य में 10 सप्ताह लगेंगे।
आवश्यकताओं, संदर्भ की शर्तों, समाधान वास्तुकला, उपयोगकर्ता के निर्देशों और अधिक सहित बहुत सारे प्रलेखन को लिखना और समन्वय करना आवश्यक है। कुल शुद्ध उत्पादन मात्रा - 400 पृष्ठ
आवेदन में एक जटिल व्यावसायिक तर्क है, इसलिए बहुत परीक्षण है (इसलिए, हम विकास का 40% हिस्सा लेते हैं)
हम आवश्यकताओं की पहचान करने के लिए ग्राहक के साथ 5 बैठकें करते हैं
हम विज़न और ड्राफ्ट निर्णय के समन्वय के लिए ग्राहक के साथ 3 बैठकें करते हैं
हम विकास के स्तर पर ग्राहक के लिए 4 उत्पाद प्रदर्शनों की योजना बनाते हैं
हम ग्राहक के परीक्षण वातावरण में 10 डिलीवरी की योजना बनाते हैं

इसके आधार पर, हम तय करते हैं कि इस मूल्यांकन के लिए हम निम्नलिखित टीम संरचना पर ध्यान केंद्रित करेंगे:

3 डेवलपर्स
1 परीक्षण इंजीनियर
1 व्यापार विश्लेषक
1 प्रणाली विश्लेषक (वास्तुकार, वह बुनियादी ढांचे के कार्य भी करेगा)
1 परियोजना प्रबंधक

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

कार्य	भूमिका	लोगों की संख्या	समय	केवल
विश्लेषण और आवश्यकताओं के संग्रह का चरण
परिणामों का साक्षात्कार और रिपोर्ट करने के लिए ग्राहक के साथ बैठकें	प्रमुख, विश्लेषक, वास्तुकार	3	5 बार x 4 घंटे	60
एक आवश्यकता दस्तावेज़ लिखना	विश्लेषक, वास्तुकार
आवश्यकताओं का परीक्षण	परीक्षण इंजीनियर
अनुबंध और परियोजना शुरू करने वाले अन्य दस्तावेजों का लेखन और अनुमोदन	प्रोजेक्ट मैनेजर	1
समाधान डिजाइन
टीके लेखन	विश्लेषक, वास्तुकार
एक समाधान वास्तुकला लेखन	वास्तुकार	1	40	40
परीक्षण TK और समाधान वास्तुकला	परीक्षण इंजीनियर
विषय प्रशिक्षण	सब	7	40	280
विकास का वातावरण स्थापित करें	वास्तुकार, डेवलपर्स	4	16	64
		1	40	40
-
	, ,	3	3 4	36

	,	4	10 4	160
प्रोग्रामिंग		3	400	1200
		1	3 100	300
		1	4 8	32
	, ,	3	3 4	36
( ), 40%		1		480
		1	80	80

		1		40
		1	10 8	80
(25% )		2		300
की शुरूआत
एक उत्पादन सर्वर पर स्थापना	वास्तुकार			40
उपयोगकर्ता प्रशिक्षण (मान लीजिए कि प्रत्येक 4 घंटे के 3 प्रशिक्षण हैं)	विश्लेषक	1	3 एक्स 4	12
लेखन निर्देश	विश्लेषक
लेखन दस्तावेज	पार्ट एनालिस्ट, पार्ट आर्किटेक्ट		135 दिन, 3 पृष्ठ	1080
प्रलेखन परीक्षण	टेस्ट इंजीनियर		उसके लेखन का 30%	320
कुल मिलाकर				4680
इसके साथ ही
जोखिम का समय			10% विकास	120
बदलाव का समय			10% विकास	120
परियोजना प्रबंधन	प्रोजेक्ट मैनेजर		परियोजना का 15%	700
केवल		लगभग 5620 घंटे

प्राप्त आंकड़ों के आधार पर, विकास कार्यों का मूल्यांकन सीधे (1200 घंटे) कुल श्रम लागत (4 गुना से अधिक) से बहुत कम है।

कोड का परीक्षण और अनुकूलन करने, प्रलेखन लिखने, परियोजना में विशेषज्ञों को पेश करने (कार्य के लिए एक वातावरण स्थापित करने सहित) और परियोजना का प्रबंधन करने के लिए समय की एक बड़ी राशि खर्च की जाती है।

निष्कर्ष

, — (, ) , ,
.

, , «», .

? .

संदर्भ

1. « , » http://vimeo.com/13803733

2. «My Story: « »

3. () 19.101-77 « » http://www.rugost.com/index.php?option=com_content&task=view&id=48&Itemid=50

4. . :
akiselev87.wordpress.com/2011/07/14/---
5. . “ ” http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf

6. http://leopard.in.ua/2010/03/22/desyat-smertnyx-grexov-v-ocenke-trudoyomkosti-razrabotki-programmnogo-obespecheniya/

7. « » http://www.philosoft.ru/metrics-idea.zhtml

8. « » http://qaclub.com.ua/wp-content/uploads/d/qaclub6_19-02-10/QAClub_TestEffortsPlanning.pdf

एक सॉफ्टवेयर विकास परियोजना के श्रम लागत का मूल्यांकन: यूक्रेनी वास्तविकता में अभ्यास