दूसरा-सिस्टम प्रभाव बनाम फेंकने के लिए एक का निर्माण करें


15

एक तरफ एक सलाह है जो कहती है कि "एक को फेंक दो"। एक सॉफ्टवेयर सिस्टम को खत्म करने और अंतिम उत्पाद को देखने के बाद ही हमें पता चलता है कि डिजाइन के चरण में क्या गलत हुआ और हमें यह समझना चाहिए कि हमें वास्तव में क्या करना चाहिए था।

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

क्या इन सिद्धांतों के बीच कुछ विरोधाभास नहीं है? समस्याओं पर सही दृष्टिकोण क्या है और इन दोनों के बीच सीमा कहां है?

मेरा मानना ​​है कि इन "अच्छी प्रथाओं" को सबसे पहले फ्रेड ब्रूक्स द्वारा सेमिनल बुक द मिथिकल मैन-मंथ में प्रचारित किया गया था ।

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


3
व्यक्तिगत रूप से मुझे लगता है कि आपको समस्या की मूल बातें समझने के लिए तीन की जरूरत है, दो उन्नत सामान को समझने के लिए और तीसरा इसे सही करने के लिए।
व्याट बार्नेट

5
@Yatt: मैं अपना मामला "सही होने के लिए सही संख्या" n + 1 है, n वर्तमान पुनरावृत्ति
nnnz

जवाबों:


23

फेंकने के लिए एक का निर्माण शुरू में "न जाने क्या-क्या नहीं जानते हैं" से होता है, इसलिए आप सीखते हैं कि आप जाते हैं जो आपको शुरू में करना चाहिए था।

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

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

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


एक प्रोटोटाइप नहीं है, "पहली प्रणाली, जिसे फेंक दिया जाएगा"? यदि यह सच है, जहाँ तक मुझे पता है, प्रोटोटाइप में आमतौर पर टेंड उत्पाद की पूर्ण कार्यक्षमता नहीं होती है; या कम से कम एक थ्रो-दूर प्रोटोटाइप के संदर्भ में।
m3th0dman 6

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

@ जोरी सेब्रचेट्स रिफैक्टिंग का मतलब यह नहीं है कि पहली प्रणाली को फेंक दिया जाए; भी आप गलत आवश्यकताओं या खराब वास्तुकला का
प्रतिकार

केवल एक चीज जिसे मुझे इस उत्तर में जोड़ना है, सिर्फ स्पष्ट स्पष्टता के लिए, यह है कि दूसरी प्रणाली एक दूसरी उत्पादन प्रणाली को संदर्भित करती है।
थॉमस ओवेन्स

0

आप जिस समस्या का जिक्र कर रहे हैं, उसका मतलब है कि कई चीजें छोड़ दी गई थीं, इसलिए परिणामी प्रणाली गलत हो गई। मुझे कुछ लापता चरणों का वर्णन करें:

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

व्यवहार्यता विश्लेषण - डिस्कवर व्यापार की जरूरत है। परियोजना के लिए एक व्यावसायिक मामला बनाएं।

प्रोजेक्ट प्लान - स्पष्ट रूप से अपने प्रारंभिक दायरे को परिभाषित करें, योजना बनाएं कि समाधान कैसे वितरित किया जाएगा, एक आधार रेखा बनाएं, योजना से चिपके रहें। ऐसी किसी भी चीज़ पर समय व्यतीत न करें जो महत्वपूर्ण पथ पर न हो।

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

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

कार्यान्वयन - सॉफ्टवेयर को डिज़ाइन के अनुसार कोड करें। सभी कोड एसडी से घटकों से जुड़े होने चाहिए।

सत्यापन - यूनिट परीक्षण, एकीकरण परीक्षण, प्रदर्शन, ... (आरई से सभी उपयोग के मामलों को अब परीक्षण करने की आवश्यकता होगी)

ये एक सॉफ्टवेयर प्रक्रिया के कुछ प्रमुख पहलू हैं। उल्लेखित गतिविधियाँ सॉफ्टवेयर इंजीनियरिंग का हिस्सा हैं। यह है कि आप वास्तविक व्यवसाय की आवश्यकता के लिए सही सॉफ्टवेयर समाधान का निर्माण करते हैं, और आप इसे समय पर, बजट पर, विनिर्देशन में बनाते हैं।

बेहतर सॉफ़्टवेयर बनाने और इसे पहली बार सही करने के लिए इन शर्तों को देखें:

  • व्यवहार्यता विश्लेषण (esp। कैसे एक व्यावसायिक मामला बनाने के लिए)
  • परियोजना प्रबंधन (esp। परियोजना योजना और जोखिम शमन के साथ जोखिम रजिस्टर)
  • आवश्यकताएँ इंजीनियरिंग (elicitation, विश्लेषण, विनिर्देश, सत्यापन)
  • सॉफ़्टवेयर डिज़ाइन (UML और घटक-आधारित सॉफ़्टवेयर इंजीनियरिंग)
  • सॉफ्टवेयर निर्माण (डिजाइन पैटर्न, चौखटे, रक्षात्मक प्रोग्रामिंग)
  • सॉफ्टवेयर सत्यापन (यूनिट परीक्षण, यूएटी, आदि)

1
आवश्यकताओं में बदलाव के लिए हमेशा rework की आवश्यकता होगी। लेकिन अच्छी तरह से डिजाइन किए गए सिस्टमों में इन रिर्क्रेट्स को असंबंधित हिस्सों को प्रभावित किए बिना वृद्धिशील और सफाई से किया जा सकता है।
जेसप्रे

सपने देखते रहो। आप ग्राहक से पहले से जानना चाहते हैं कि वह क्या चाहता / चाहती है। ऐसा नहीं होता है; इसलिए हमारे पास चुस्त तरीके हैं।
मोनिका - एम। श्रोडर

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