क्या वास्तव में किसी परियोजना को सौंपे गए लोगों और दोषों की संख्या के बीच संबंध है?


12

यहाँ SLIM और सॉफ्टवेयर आकलन के संबंध में प्रशिक्षण मैनुअल से एक उद्धरण है:

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

परियोजना के लिए प्रयास व्यक्ति-समय (व्यक्ति-वर्ष, व्यक्ति-महीने) है। दोष जीवन चक्र में किसी भी बिंदु पर पाए गए दोषों की गिनती है। आकार को उपयोग मामलों, फ़ंक्शन बिंदु या SLOC के रूप में परिभाषित किया गया है जो परियोजना की रचना करते हैं।

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

मैं पुटनाम मॉडल (एसएलआईएम द्वारा उपयोग किया जाता है) के बारे में उन लोगों से अलग किसी भी दस्तावेज को खोजने में सक्षम नहीं हुआ, जो किसी परियोजना पर दोष और प्रयास या दोष और लोगों की संख्या के बीच किसी भी प्रकार के ज्ञात संबंध का सुझाव देते हैं। क्या यह एक ज्ञात संबंध है, और यह दावा है कि "अधिक लोग = अधिक दोष" वैध हैं?


10
"एक देर सॉफ्टवेयर परियोजना के लिए मानव शक्ति को जोड़ने इसे बाद में आता है" - फ्रेड ब्रूक्स
Oded

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

@ThomasOwens - हाँ, उद्धरण वास्तव में संचार चैनलों (और इसलिए कठिनाइयों) में वृद्धि के बारे में है, इस धारणा के साथ कि यह दोषों को जन्म देगा।
Oded

मैं अब भी कहूंगा कि जब किसी परियोजना पर डेवलपर्स का भार डाला जाता है, तो यह अक्सर एक मृत्यु मार्च का संकेत होता है।
मॉर्गन हेरलॉकर

@ironcode एक परियोजना पर डेवलपर्स की संख्या को परियोजना के आकार और दायरे से तय किया जाना चाहिए, और यह कैसे आयोजित किया जाता है। बहुत अधिक डेवलपर्स होना या बहुत से डेवलपर्स को बाद में जोड़ना खराब प्रबंधन के संकेत हैं, शायद मृत्यु मार्च।
थॉमस ओवेन्स

जवाबों:


14

मेरा अंतर्ज्ञान इस प्रकार है:

दिए गए आकार की एक परियोजना को जितने अधिक लोगों को सौंपा गया है, संचार का बड़ा हिस्सा
=> उच्चतर गलतफहमी की संभावना और संचार समस्याओं के सभी प्रकार
=> परिणामी दोषों की संख्या जितनी अधिक होगी।

तथा

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

लेकिन ये सिर्फ मेरे तर्क हो सकते हैं, मेरे पास कोई समर्थन प्रमाण नहीं है।

एक साइड नोट के रूप में, आपकी मान्यताओं पर बल दिया जाना IMHO (दुख की बात है) काफी मजबूत है, हमारे पेशे की स्थिति को ध्यान में रखते हुए:

यह एक अच्छी प्रक्रिया और सक्षम इंजीनियरों की कल्पना करते हुए , काउंटरटाइनेटिव लगता है । [...] मेरे अंतर्ज्ञान से पता चलता है कि एक परियोजना पर प्रयास और दोषों के बीच बहुत कम संबंध हैं जो उचित गुणवत्ता तकनीकों का उपयोग करते हैं


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

लेकिन कम लोगों के साथ आप उन्हें अपनी ताकत से चिपके रहने की अनुमति कम देते हैं। क्या कुछ अच्छे डेवलपर्स को किराए पर लेना आसान है जो वास्तव में बेहतर हो सकते हैं यदि वे सिर्फ एक गुरु के बजाय एक क्षेत्र पर ध्यान केंद्रित कर सकते हैं जो सब कुछ कर सकता है?
जेफ़ो

@ जेफ ओ, आपके पास एक बिंदु है। OTOH यदि प्रत्येक डेवलपर केवल अपने स्वयं के मजबूत क्षेत्र पर ध्यान केंद्रित करता है, तो उन दोनों के बीच संचार और भी अधिक तकलीफदेह हो सकता है।
Péter Török

1
क्या संचार अधिक परेशान है या बस आवश्यक हो गया है?
जेएफओ

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

5

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


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

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

SLIM का बिंदु (और अन्य अनुमान उपकरण, जब ठीक से उपयोग किया जाता है) लोगों की आवश्यक संख्या, एक परियोजना की लागत, समय की आवश्यकता, और इसी तरह के आकलन में मदद करता है। हालांकि, उस उपकरण को समझने और ठीक से उपयोग करने की आवश्यकता होती है।
थॉमस ओवेन्स

3

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

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


2

यह एक अच्छी प्रक्रिया और सक्षम इंजीनियरों की कल्पना करते हुए, काउंटरटाइनेटिव लगता है।

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

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

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


यदि एक ही फ़ाइल पर काम करने वाले 4 देवों को रोकने का एकमात्र तरीका टीम आकार को 3 तक सीमित करना है, तो आपको बड़ी समस्याएं मिलीं।
जेएफओ 14

2

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

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


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

@ThomasOwens - हां, यह बिल्कुल मेरी बात थी।
डैनियल बी

प्रोजेक्ट के आकार और जटिलता के सापेक्ष त्रुटियों की तुलना क्यों नहीं की जाएगी?
जेएफओ 14

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

@ जेफ वे होंगे। लेकिन आप दोषों की तुलना आकार और जटिलता से करेंगे, न कि लोगों की संख्या से। आकार और जटिलता बढ़ने पर, दोष बढ़ जाते हैं और लोगों की संख्या बढ़ जाती है। तो हां, हालांकि लोगों की संख्या में वृद्धि होती है, कि लोगों में वृद्धि दोषों की संख्या में वृद्धि नहीं करती है।
थॉमस ओवेन्स

1

आइए एक पल के लिए लोगों की संख्या के बारे में जोर देते हैं।

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

इसलिए यदि आप मानते हैं कि एक परियोजना में जितना अधिक प्रयास किया जाता है, कोड की अधिक पंक्तियां लिखी जाती हैं, तो आप संभवतः दोषों की संख्या की भविष्यवाणी करने के लिए आकार के लिए प्रॉक्सी के रूप में प्रयास का उपयोग कर सकते हैं। आकार के बीच सहसंबंध (जैसे LOC) और दोषों की संख्या को वाट्स हम्फ्रे, कैपर्स जोन्स, और अन्य द्वारा काम में बार-बार दिखाया गया है।

मैं नहीं देखता कि लोगों की संख्या कैसे फिट होती है, अन्य लोगों की तुलना में अधिक प्रयास का अर्थ है।

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


0

मैं यह मान रहा हूं कि यह कोर प्रोग्रामिंग टीम के सदस्यों तक सीमित है, न कि ऐसी स्थिति जहां विशेषज्ञ जैसे: यूआई, यूएक्स, डीबीए, आदि।

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

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

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

वास्तविकता यह है कि, ऐसे बहुत से लोग नहीं हैं जिन्होंने कभी एक सफल परियोजना पर एक बड़ी टीम का प्रबंधन किया है। यहां तक ​​कि अगर वे सभी प्रतिभाशाली हैं, तो बड़ी टीमों के लिए आत्म-प्रबंधन करना मुश्किल है। क्या अहंकार रास्ते में मिलता है?

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.