एक प्रोटोटाइप और एक उत्पादन स्तर समाधान के बीच अंतर क्या है?

Question

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

मैंने अतीत में .Net में कई डेमो समाधान बनाए। मुझे अब आर्किटेक्ट को सौंपा गया है और एक प्रोडक्शन लेवल वेब सॉल्यूशन लागू किया गया है, इसलिए मैं पूछना चाहता था - बहुत उच्च स्तर पर, डेमो को प्रोडक्शन लेवल सॉल्यूशन में बदलने के लिए क्या आवश्यक है। मेरी समझ से, इसके लिए (कार्यात्मक रूप से ग्राहकों की आवश्यकताओं को लागू करने के अलावा) की आवश्यकता होगी:

1. इकाई परीक्षण हर विधि
2. सुनिश्चित करना ~ 100% कोड कवरेज हासिल किया जाता है
3. सभी अपवादों और संभावित बिंदुओं को लॉग करना - एओपी के साथ संभव
4. इंटरफ़ेस डिज़ाइन पैटर्न का उपयोग करना, निर्भरता इंजेक्शन, संभवतः एक फ्रेमवर्क का उपयोग करके जैसे कि spring.net
5. इंस्ट्रूमेंटेशन के लिए प्रदर्शन काउंटर और प्रोफाइलरों का उपयोग करना
6. उपयुक्त सुरक्षा को लागू करना - अर्थात विंडोज़ प्रमाणीकरण (यदि ग्राहक द्वारा आवश्यक व्हाट्सएप है)।
7. हर एक विधि पर लेनदेन प्रबंधन
8. समाधान की नई तैनाती से पहले वेब एप्लिकेशन फ़ाइलों का बैकअप लें

और क्या?

मेरा प्रश्न कार्यात्मक / प्रलेखन के बजाय तकनीकी पक्ष से अधिक संबंधित है क्योंकि अन्यथा हम दूसरे रास्ते में जाएंगे :-)

धन्यवाद।

Comments

निंदक का जवाब होगा "आपका प्रबंधक इसे देखकर"।

— पीटर टेलर

Answer 1

मुझे लगता है कि सबसे महत्वपूर्ण अंतर यह है कि एक प्रोटोटाइप का उद्देश्य है:
1. यह साबित करने के लिए कि किसी समस्या को एक निश्चित तरीके से हल किया जा सकता है या
2. ग्राहक / प्रबंधन को यह महसूस कराएं कि उत्पाद कैसा दिखेगा और कैसा महसूस होगा

जबकि एक लाइव सिस्टम का उद्देश्य है:
1. एक निश्चित समस्या को हल करने के लिए / एक समस्या का समाधान।

ध्यान दें कि दोनों के उद्देश्य पूरी तरह से अलग हैं ।
इसलिए, मेरी राय में एक लाइव सिस्टम विकसित करने से पहले एक प्रोटोटाइप को फेंक दिया जाना चाहिए ।

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

Comments

के माध्यम से मुख्य बिंदु प्राप्त करने के लिए +1: प्रोटोटाइप को फेंकने के लिए बनाया जाता है। एक प्रोडक्शन रिलीज़ में एक प्रोटोटाइप को बदलने की कोशिश करना शुरू से ही किसी प्रोजेक्ट को सही साबित कर सकता है।

— पेटर तोर्क

मुझे लगता है कि यह संभव है लेकिन इस बात पर निर्भर करता है कि मूल प्रोटोटाइप को कैसे विकसित किया गया था। एक व्यावसायिक दृष्टिकोण से जो कि प्रोटोटाइप के प्रयास और व्यवहार्यता के आधार पर बनाने का एक भयानक निर्णय हो सकता है।

— कीरेन जॉनस्टोन

@Kieren, मैं एक परियोजना पर रहा हूँ जहाँ प्रबंधन ने उत्पादन ऐप बनाने के लिए GUI प्रोटोटाइप के पुन: उपयोग का "समझदार" निर्णय लिया। हम वर्षों बाद उस निर्णय से पीड़ित थे। मूल निर्णय के कारण, ऐप में व्यावहारिक रूप से कोई डिज़ाइन और वास्तुकला नहीं था, और बाद में इसे बदलना बहुत मुश्किल था।

— पेटर तोर्क

मैं दूसरा @Kieren। प्रोटोटाइप को संभावित उत्पादन एप्लिकेशन का

— संक्षिप्त

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

— टोबी

Answer 2

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

मुझे लगता है कि आप तकनीकी पक्ष को देख रहे हैं, लेकिन उम्मीद है कि आप मेरी बात को समझेंगे, यह गैर-तकनीकी पक्ष पर निर्भर करता है। या कम से कम, यह चाहिए।

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

यहां जो आप याद कर रहे हैं, वह परियोजना के संदर्भ, गुंजाइश और व्यावसायिक आवश्यकताओं के लिए विफल है।

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

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

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

Answer 3

दिलचस्प बात यह है मुझे लगता है कि अंक 1, 2, 4 और 7 पहले से ही अपने प्रोटोटाइप की अवधारणा के दौरान किया जाना चाहिए, सिवाय इसके कि मुझे नहीं लगता कि आप परीक्षण करना चाहिए कि हर में विधि हर वर्ग। महत्वपूर्ण कोड का परीक्षण करें, न कि प्राप्त / निर्धारित विधियों को सही तरीके से व्यवहार करें।

आपके आवेदन के उद्देश्य पर निर्भर करता है, जहां सुरक्षा एक बड़ी समस्या है, बिंदु 6 महत्वपूर्ण रूप से महत्वपूर्ण हो सकता है कि आपको इसे प्रोटोटाइप में प्राप्त करने की आवश्यकता है। आपके आवेदन के उद्देश्य के आधार पर, जहां प्रदर्शन की कुंजी है, बिंदु 5 महत्वपूर्ण हो सकता है ... आप जानते हैं कि मेरा क्या मतलब है। मेरी राय है कि प्रोटोटाइप में अंक 3, 5, और 6 आवश्यक हो सकते हैं यदि उन्हें महत्वपूर्ण माना जाता है (बिंदु 8 वास्तव में उत्पादन के लिए वैध है)

संपादित करें: ऐसा लगता है कि मेरी राय sJhonny से पूरी तरह से भिन्न है क्योंकि मैं इसका मतलब है कि मैं प्रोटोटाइप को आपके भविष्य के विकास का आधार / शेल / कंकाल मानता हूं, इसलिए मेरे लिए प्रोटोटाइप को फेंकना नहीं है।

Answer 4

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

0-एक कार्यान्वयन पद्धति चुनें

1-प्रमुख आवश्यकताओं (उपयोग मामलों आदि सहित) को अंतिम रूप दें और प्रकाशित करें

2-आर्किटेक्चर का अधिकार प्राप्त करें

3-सही टूल्स का चयन करें

4-प्रदर्शन के लिए डिज़ाइन डेटाबेस

5-अपने वर्ग के डिजाइन और वर्कफ़्लो डिज़ाइन का निर्माण करें

6-निर्धारित डेटाबेस / डेटा स्रोतों / फ़ीड को एकीकृत करने के लिए एक रणनीति निर्धारित करना और लागू करना

7-सुरक्षा आवश्यकताओं को परिभाषित और कार्यान्वित करना

8-शारीरिक कार्यान्वयन के लिए व्यवस्था (सर्वर, कनेक्टिविटी, लाइसेंस आदि)

9-भंडारण आवश्यकताओं के लिए योजना और प्रदर्शन के उपायों का निर्धारण

10-सभी कलाकृतियों का निर्माण करें और उत्पादन वातावरण में स्थापित करें

11 टेस्ट मैचों की

12-अंतिम समाधान वितरित करें और प्रतिक्रिया लागू करें

Answer 5

उत्पादन गुणवत्ता समाधान की सबसे महत्वपूर्ण विशेषता है - मेरी राय में - मजबूती ।

चाहे जो कुछ भी हो, समाधान स्थिति को समझदारी से संभालता है, उन लोगों को जानने की आवश्यकता को सूचित करता है, और अगर त्रुटि ठीक हो जाती है तो वह चलता रहता है।

Comments

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

— Kwebble

Answer 6

दो प्रकार के प्रोटोटाइप हैं:

• त्वरित और गंदे "अवधारणा का प्रमाण" अनुप्रयोग जो "साफ हो जाते हैं" और उत्पादन कोड बन जाते हैं। "क्लीन अप" चरण या तो एक दुःस्वप्न बन जाता है, या यह वास्तव में "गलीचा के नीचे समस्याओं को स्वीप" करता है, जिसके परिणामस्वरूप बड़े पैमाने पर तकनीकी ऋण होता है।

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

मैं दूसरी तरह को पसंद करता हूं। वे बाहर फेंक दिए जाते हैं, क्योंकि वास्तव में कोई विकल्प नहीं है।

Answer 7

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

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

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