कार्ल विगर्स और जॉय बीट्टी द्वारा सॉफ्टवेयर डेवलपमेंट पर बुक रिव्यू

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

आकर्षण आते हैं

सब कुछ चित्रित है

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

जानकारी पाना आसान

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

आईटी में सभी के लिए

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

शर्तों की व्याख्या

आदत से बाहर मैनुअल पढ़ना मुश्किल है, लेकिन 700 वें पृष्ठ के बाद यह आसान हो जाता है :) प्रस्तुति के दौरान, प्रत्येक अवधारणा को अंग्रेजी में मूल में कोष्ठक में दिया जाता है। यह सुविधाजनक है क्योंकि अनुवादक हमेशा सटीक नहीं होता है और आप विकिपीडिया को अंग्रेजी में खोल सकते हैं। पुस्तक के अंत में स्पष्टीकरण के साथ शब्दों की शब्दावली है। सच है, मैनुअल में पाए जाने वाले सभी अवधारणाएं नहीं हैं। सूची को पूरक करने के लिए, मुझे हाथ से 50 नए वाक्यांशों और पृष्ठ संख्याओं को जोड़ना पड़ा।

विपक्ष

wordiness

लेखक लंबे वाक्यों और अनावश्यक जानकारी का दुरुपयोग करते हैं। इस वजह से, अर्थ को पकड़ना अधिक कठिन है।

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

लियो टॉल्स्टॉय, क्या आप हैं?

"... संचार विधियां टीम के भीतर समय और स्थान में प्रभावी सिंक्रनाइज़ेशन प्रदान कर सकती हैं।"

और चक्का पर लिखा है कि यह एक मैनुअल है, न कि एक दार्शनिक ग्रंथ।

"खाद्य आदेशों की स्थिति के लिए राज्य आरेख।"

लेखक दो बार दोहराते नहीं हैं, दोहराते नहीं हैं।

"स्टीफन विठ्ठल (2007) डेटा का सही दस्तावेजीकरण (जिसे जानकारी भी कहा जाता है) के लिए कई योजनाओं का वर्णन करता है।"

डेटा = सूचना। और इसमें कुछ है!

और पूरी किताब में ऐसा शब्दार्थ शोर। एक संदेह है कि लेखकों को लाइनों के लिए भुगतान किया गया था।

व्याकरण की त्रुटियां

पढ़ने के दौरान, मैंने उन्हें 160 से अधिक गिना। स्कूल पाठ्यक्रम के भीतर सभी त्रुटियां। उदाहरण के लिए: शब्दों को छोड़ दिया जाता है, "-tya" का प्रयोग "-tat" के बजाय किया जाता है, वाक्यों को एक पैराग्राफ में दोहराया जाता है, सामान्य टाइपो का सामना किया जाता है, अल्पविरामों को छोड़ दिया जाता है, एक समान तरीके से लिखी जाने वाली अवधारणाओं को भ्रमित किया जाता है।

किताब खोलते ही पहली गलती होती है। क्रिस के पास मेगालोमैनिया नहीं है, उन्होंने उसे केवल कार्ल के साथ भ्रमित किया, जिसने उसे एक पुस्तक समर्पित की। वे जीवनसाथी हैं।



आपको वह वाक्यांश कैसा लगा?

"अस्थिर व्यावसायिक नियमों के बेहतर प्रसंस्करण के लिए प्रणाली को फिर से डिज़ाइन करें जो जटिल परियोजना समर्थन थे।"

उत्पाद प्लेसमेंट

प्रस्तुति के दौरान, लेखक बार-बार Microsoft उत्पादों का उल्लेख करते हैं। वे इतने प्रसिद्ध हैं कि उनके बारे में लिखने का कोई मतलब नहीं है। और जब आवश्यकताओं प्रबंधन प्रणालियों (SUT) का नाम देना आवश्यक होता है, तो लेखक उनके बारे में चुप हो जाते हैं। मैंने केवल उनकी खातिर इस अध्याय को पढ़ा। पुस्तक सिर्फ Microsoft प्रेस द्वारा जारी की गई थी, जबकि "नरम वाले" के पास पूर्ण रूप से SUT नहीं है। कंपनी की निष्ठा पेशेवर ऋण से आगे निकल गई।

इन्युएन्दो

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

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

शेष चरणों को कुछ विस्तार से आवेदन में लिखा गया है। इस पृष्ठभूमि के खिलाफ, विकल्पों की श्रृंखला में लापता लिंक कम करके आंका जा सकता है। यह स्पष्ट है कि आवेदन एक उदाहरण के रूप में दिए गए हैं, लेकिन फिर भी।

रूस के लिए क्या प्रासंगिक है?

पढ़ने से पहले, मैंने कुछ इस तरह सोचा: “एक अमेरिकी हमें क्या सलाह दे सकता है? उनके पास संख्या में सब कुछ है, और कोई समस्या नहीं है। ” यह पता चला कि समस्याएं उसी के बारे में हैं।

आवश्यकताओं के लिए सम्मान की कोई संस्कृति नहीं

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

कोई व्यावसायिक आवश्यकताएं नहीं

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

"संलग्न" डिजाइन करने के लिए

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

विश्लेषक की बारीकियों की समझ नहीं

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

कोई उपकरण का उपयोग नहीं किया

एक बॉस चाहता था कि टीके के साथ काम करने वाले लोग उन्हें पाठ के करीब जान सकें। यह अवास्तविक है। कंपनी के पास कई दसियों टीके हैं, और उनकी संख्या बढ़ रही है। यदि आपने खुद को एक महीने पहले TK का मसौदा तैयार किया है, तो आप अभी भी इसे भूल जाते हैं, क्योंकि तब आप अपने आप को 2-3 नए लोगों में डुबो देते हैं। यह समस्या स्मृति के कारण नहीं, बल्कि आवश्यकताओं के प्रबंधन प्रणालियों (SUT) के कार्यान्वयन के कारण हल की गई है। वे आवश्यकताओं की पहचान, प्रबंधन, ट्रैकिंग और वापसी का समर्थन करते हैं। लेकिन आपको उनके लिए भुगतान करना होगा, और नियोक्ता पुराने ढंग से काम करना पसंद करेंगे, जैसा कि एक कहावत है:

निर्माण बटालियन के दो सैनिक खुदाई करने वाले की जगह लेते हैं।
और हवाई बलों में से एक उन्हें दोगुना बदल देता है।

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

निष्कर्ष

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