क्या एक परियोजना बड़ा बनाता है? [बन्द है]

Question

बस जिज्ञासा से बाहर एक छोटे, मध्यम और बड़े आकार की परियोजना के बीच अंतर क्या है? क्या इसे कोड या जटिलता की रेखाओं से मापा जाता है या क्या?

Im एक बार्टरिंग सिस्टम का निर्माण और अब तक लॉगिन / पंजीकरण के लिए कोड की लगभग 1000 लाइनें हैं। भले ही बहुत सारे LOC हैं, लेकिन मैं इसे एक बड़ी परियोजना नहीं मानूंगा क्योंकि यह उतना जटिल नहीं है, हालांकि यह मेरी पहली परियोजना है इसलिए सुनिश्चित नहीं है। यह कैसे मापा जाता है?

Comments

हां ............ अधिक जटिलता का अर्थ है कोड की अधिक लाइनें।

— रॉबर्ट हार्वे

पहला KLOC सबसे कठिन ...

आगे आपको पूछना है "क्या एक परियोजना को जटिल बनाता है? कोड की लाइनें? अमूर्त की परतें?"

— स्टीवन एवर्स

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

— TMarshall

मैं कहूंगा कि एक परियोजना का "गरिमा" 1 से अधिक कारक पर निर्भर करता है ...

— किवज़

Answer 1

जटिलता।

अधिक जटिलता, परियोजना में सब कुछ सीखना कठिन है।

Comments

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

— हेनरिक

... या स्वाभाविक रूप से जटिलता का कोई अन्य उपाय।

— हेनरिक

@ हेनरिक, "जटिल प्रणाली" "बड़ी प्रणाली" के बराबर नहीं है।

नहीं, यह एक पर्यायवाची है।

— हेनरिक

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

Answer 2

मोटे तौर पर मैं चीजों को कैसे समझूंगा - ध्यान रखें कि यह कमोबेश मनमाना है। जटिलता के अन्य कारकों जैसे कोड की "आकार", कोड की स्रोत रेखाएं, सुविधाओं की संख्या / व्यापार मूल्य, आदि। एक बहुत छोटा उत्पाद बड़ी मात्रा में मूल्य वितरित कर सकता है, आदि जो कहा जा रहा है:

• 2 मीटर + ढलान एक बड़ी से बड़ी परियोजना है। ये आम तौर पर इतने जटिल होते हैं कि कुछ लोग पूरे सिस्टम में 'धाराप्रवाह' होते हैं; बल्कि जिम्मेदारी कोड की संरचना के साथ संशोधित किया जा सकता है। ये परियोजनाएं अक्सर भारी व्यावसायिक मूल्य प्रदान करती हैं और मिशन महत्वपूर्ण हो सकती हैं। वे कभी-कभी तकनीकी ऋण और अन्य विरासत चिंताओं के भारी दबाव में भी होते हैं।

• 100k - 2 मीटर ढलान एक मध्यम आकार की परियोजना है। यह मेरी मध्य जमीन है: परियोजना कुछ विशेषज्ञ ज्ञान की आवश्यकता के लिए पर्याप्त जटिल है, और तकनीकी ऋण के कुछ डिग्री की संभावना है; यह संभवत: कुछ हद तक व्यावसायिक मूल्य प्रदान कर रहा है।

• 10k - 100k एक छोटी परियोजना है, लेकिन इतनी छोटी भी नहीं है कि इसमें इतनी जटिलता हो कि आप विशेषज्ञ विचार करें; यदि आप खुले स्रोत हैं, तो उन लोगों पर विचार करें, जिन पर आप अपने कमिट की समीक्षा करने के लिए भरोसा करते हैं।

• 10k से कम कुछ भी शोर करना वास्तव में छोटा है। इसका मतलब यह नहीं है कि यह किसी भी मूल्य को वितरित नहीं कर सकता है, और कई बहुत ही दिलचस्प परियोजनाओं में बहुत छोटी छाप है (जैसे कैम्पिंग, जिसका स्रोत ~ 2 केबी (!)) है। गैर-विशेषज्ञ आम तौर पर मूल्य चिंताओं को ड्राइव कर सकते हैं - बग को ठीक कर सकते हैं और सुविधाओं को जोड़ सकते हैं - डोमेन के बारे में बहुत अधिक जानने के बिना।

Comments

अगर मैं कर सकता हूं तो मैं इसे दो बार वोट करूंगा। संख्याएँ निश्चित रूप से एक प्रकार की मनमानी हैं, लेकिन मुझे लगता है कि "बिग्नेस" के विभिन्न अंशों का वर्णन स्पॉट-ऑन है।

— एरिक एंडरसन 3

@ एरिकसनसन ढलान के माप की तुलना में विवरण के संदर्भ में यह सोचना आसान है। एक 100k SLOC Erlang कार्यक्रम आसानी से परिमाण एक 100k SLOC सी ++ कार्यक्रम की तुलना में "बड़े" के एक आदेश के लिए, बस पर यह क्या आधारित है करता है , भले ही कितना आसान कोड एक उच्च स्तर पर पढ़ने के लिए है। एक निश्चित बिंदु पर कोड पढ़ना उतना मुश्किल भी नहीं है, जितना कि याद रखना कि उच्च स्तर पर सिस्टम के अंदर क्या चल रहा है क्योंकि इसमें बहुत सारे फीचर्स और लॉजिक सेंटर हैं।

— zxq9

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

— योंगवेई वू

Answer 3

एक परियोजना का आकार अचूकता की डिग्री से मापा जाता है।

Comments

यह निराशावादी है: D

— हेनरिक

.... और वह माप है?

— केसी पैटन

@ कैसी पैटन माप वस्तुतः रखरखाव की लागत है।

— मोज़ुबा

Answer 4

जटिलता जिसका कुछ तरीकों से अनुमान लगाया जा सकता है:

1. बजट। $ 10,000,000 + के बजट के साथ एक परियोजना संभवतः एक से काफी अलग है जो उदाहरण के लिए $ 10,000 से कम है। इसमें एक प्रोजेक्ट करने में लगने वाला श्रम, सॉफ्टवेयर, हार्डवेयर और अन्य लागत शामिल हो सकते हैं।
2. परियोजना को पूरा करने के लिए व्यक्ति के काम के घंटे। एक लाख घंटे लगेंगे या कुछ और? इसे एक टाइम लाइन फैक्टर के रूप में भी देखा जा सकता है जहाँ कुछ परियोजनाओं में वर्षों लग सकते हैं जो मैं कहता हूँ कि वे दूसरों की तुलना में बड़े थे जिन्हें एक सप्ताह से भी कम समय लग सकता है। ध्यान दें कि व्यक्ति के घंटे भ्रामक हो सकते हैं क्योंकि कोई व्यक्ति कर्मचारियों को दोगुना करने के बारे में सोच सकता है इसलिए परियोजना पर दो बार काम कर रहे हैं तो अनुसूची को आधे में कटा हुआ हो सकता है जो शायद ही कभी मेरे दिमाग में काम करेगा।
3. हार्डवेयर, अन्य सिस्टम और प्रोजेक्ट का निर्माण कर रहे लोगों का उपयोग करना। यदि कोई चीज 101 प्रणालियों में बांध रही है, तो यह अधिक जटिल होने की संभावना है कि अगर वह अकेले खड़ी हो और किसी और चीज में न बंधे।

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

Answer 5

सिस्टम की आवश्यकताओं की संख्या से एक परियोजना का आकार शायद सबसे अच्छा मापा जाता है, जहां आवश्यकताओं को और कम नहीं किया जा सकता है।

बेशक, अधिक आवश्यकताओं ज्यादातर अधिक जटिलता का मतलब है, लेकिन यह हमेशा ऐसा नहीं है।

Comments

यह एक अच्छा उपाय नहीं हो सकता है: अन्य प्रकार के उत्पादों की तुलना में संकलक और ओएस कर्नेल की आवश्यकताएं बहुत बड़ी हो सकती हैं।

— मोजुबा

@mojuba: "बिग" काफी व्यापक शब्द है, मुझे लगता है कि कंपाइलर या ओएस लिखना एक "बड़ा" प्रोजेक्ट होगा

— David_001

@ David_001: टर्बो पास्कल संकलक, f.ex. को लें, जिसका बाइनरी आकार एक बिंदु पर 70 किलोबाइट था और फिर भी टीपी एक पूर्ण विकसित वस्तु उन्मुख प्रोग्रामिंग भाषा थी। हमने सूत्रों को कभी नहीं देखा है, लेकिन एक 70kb निष्पादन योग्य एक बड़ी परियोजना नहीं हो सकती है।

— मोज़ुबा

@ David_001: ऐसा नहीं है कि मैं आपसे पूरी तरह असहमत हूं। "बड़ी" परियोजना की कोई भी परिभाषा "बड़े" शब्द के समान अस्पष्ट होगी।

— मोजुबा

@mojuba: जब मैंने टर्बो पास्कल का इस्तेमाल किया, तो यह बिल्कुल भी ऑब्जेक्ट-ओरिएंटेड नहीं था।

— डेविड थॉर्नले 21

Answer 6

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

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

Answer 7

मनमाना उत्तर: यह प्रोजेक्ट कितना बड़ा है, आप इसे शुरू से इवेंट-सोर्सिंग और SOA के साथ कितना चाहते हैं। या यह कि सिस्टम के लेखकों ने इवान की पुस्तक "डीडीडी: टैकलिंग कॉम्प्लेक्सिटी इन द हार्ट ऑफ सॉफ्टवेयर";) पढ़ी थी;

Answer 8

समरूपता और स्कोप

जटिलता और स्कोप मेरा मानना ​​है कि यह निर्धारित करता है कि वास्तव में कितना बड़ा प्रोजेक्ट है। हालांकि, कई इंटैंगिबल्स हैं जो एक परियोजना के आकार को भी प्रभावित कर सकते हैं।

आवश्यकताएँ

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

एक CCMU का अभाव

CCMU वह है जिसे मैं "Coo Ca Moo " कहता हूं (स्पष्ट पूर्ण पारस्परिक समझ)। आपको अपने ग्राहक के साथ एक CCMU रखना होगा।

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

लक्ष्य में बदलाव

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

Answer 9

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

Answer 10

जटिलता सही उत्तर है, लेकिन इसका अनुमान कैसे लगाया जाए?

कारक हैं:

1. विस्तार बिंदुओं की गिनती
2. मॉड्यूल परतें गिनती (फ़ंक्शन, कक्षाएं, क्लास सिस्टम, लाइब्रेरी, साझा लाइब्रेरी, एप्लिकेशन, नेटवर्क एप्लिकेशन, आदि)
3. निर्भरता की गणना (प्लेटफ़ॉर्म शामिल)
4. अन्योन्याश्रितता पर निर्भर करता है।
5. आवश्यक गैर-कोड संसाधन (ग्राफिक्स / कला सहित, ड्राइविंग स्क्रिप्ट - जैसे स्तर डिजाइन स्क्रिप्ट - और अनुप्रयोग के एक संस्करण को पूरा करने के लिए आवश्यक अन्य संसाधन)।

जितना अधिक आपके पास है, उतनी ही जटिल परियोजना है।

Answer 11

एलओसी है माप का एक बहुत के लिए बेहद गलत है, लेकिन मुझे लगता है कि आप कुछ को मापने के लिए है कि वहाँ वास्तव में मापने के लिए एक सटीक तरीका नहीं है कोशिश कर रहे हैं। शायद एक विकल्प चक्रीय जटिलता हो सकता है ।

अंततः, मुझे लगता है कि किसी परियोजना की "गरिमा" को निर्धारित करना मुश्किल है। यह लगभग पूछने जैसा है कि आप कैसे निर्धारित करते हैं कि कुत्ता बड़ा है या नहीं। न केवल इसे (मास, वॉल्यूम, आदि) को मापने के कई तरीके हैं, लेकिन मैं व्यक्तिगत रूप से इसे बहुत उपयोगी नहीं मानता हूं। वास्तविकता यह है कि मेरे मानदंड शायद कुछ इस तरह के होने जा रहे हैं "अगर मैं एक अंधेरी गली में देखता हूं तो मुझे इस कुत्ते से चलने की कितनी संभावना है?"

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