मैं आवश्यकताओं से विकास उपकरण क्या चाहता हूँ। गैग्स, बैसाखी और रेक SUT

हमने पिछले एनालिस्ट डेज़ 2013 सम्मेलन से Pechenkin Grigory की एक रिपोर्ट प्रकाशित की है।

सार:

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

रिपोर्ट वीडियो:

प्रस्तुति:

www.slideshare.net/VLDCORP/ss-21934097

प्रविष्टि

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

पिछले साल, REQ लैब्स सम्मेलन कीव में आयोजित किया गया था, जहां विचार पूरी तरह से महसूस किया गया था: विश्लेषणात्मक झगड़े। सम्मेलन में तीन विशेषज्ञों ने भाग लिया, जो मेरे विपरीत, SUT को अच्छी तरह से जानते हैं, क्योंकि वे लगातार उनका उपयोग करते हैं और प्रशिक्षण आयोजित करते हैं। सम्मेलन की प्रक्रिया में, विशेषज्ञों को आवश्यकताओं के साथ काम करने का वास्तविक कार्य दिया गया था, और उन्होंने प्रदर्शित किया कि यह विभिन्न प्रणालियों में कैसे किया जाता है। यह तीन प्रणालियों के साथ काम करने का प्रस्ताव था: RequisitePro, Enterprise Architect, Sybase PowerDesigner। यदि यह प्रश्न किसी के लिए दिलचस्पी का है, तो वीडियो आरईक्यू लैब्स की वेबसाइट (http://www.req-labs.ru/conf2012/agenda/530/) पर है।



दूसरी घोषणा (प्रस्तुति का स्क्रीनशॉट 2 देखें) पहले से ही उस घोषणा को संदर्भित करता है जिसे मैंने कार्यक्रम में मुद्रित किया था।



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



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

दृश्य मॉडलिंग उपकरण

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

विकास या प्रबंधन

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

परिभाषित

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



प्लग क्या हैं? गैग्स उन मामलों में होते हैं जहां कार्यक्रम को स्वयं कुछ क्रियाएं करनी चाहिए, लेकिन इन क्रियाओं को आप तक पहुंचाते हैं। एक बहुत ही सामान्य घटना। सभी प्रयोज्य प्लग से बना है। यहां तक ​​कि "उज़्बेक वायरस" के बारे में एक मजाक है।

एक चुटकुला। एक ई-मेल आपके पास आता है जिसमें लिखा है: "हैलो, मैं उज़्बेक वायरस हूं।" मेरे डेवलपर के पास मुझे लिखने का समय नहीं है, इसलिए कृपया मुझे पूरी पता पुस्तिका और प्रारूप ड्राइव सी भेजें। धन्यवाद। "

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

अब आवश्यकताओं को कैसे विकसित किया जाता है

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



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



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

आवश्यकताओं प्रबंधन प्रक्रियाओं में भागीदार

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

1. विश्लेषक पाठ के रूप में आवश्यकताओं को दर्ज करना चाहता है

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

2. डेवलपर संदर्भ को समझना चाहता है

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

पाठ या डेटाबेस?

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



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

संवाद बक्से

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

3. विश्लेषक अतिरिक्त कुछ भी नहीं करना चाहता है

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



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

4. विश्लेषक आवश्यकताओं में दृश्य मॉडल और छवियों को शामिल करना चाहता है

एक और उदाहरण। मैं आवश्यकताओं को प्रस्तुत करने का सबसे शक्तिशाली साधन मानता हूं - दृश्य आरेख। इसके बिना, यह सिर्फ काम नहीं करता है।



इस मामले में, मेरी आवश्यकताओं में ऊपर दिया गया उदाहरण मॉकअप है - उपयोगकर्ता इंटरफ़ेस लेआउट (पेंसिल प्रोग्राम में विकसित)।



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

5. विश्लेषक: मैं jpg-png-bmp-itp को मॉडल निर्यात नहीं करना चाहता

वह अपने संपादकों को अपने हाथों से चलाना नहीं चाहता और अलग-अलग फाइलों में मॉडल स्टोर करता है।



और अगर आप विकी के साथ काम करते हैं, तो आपको इस फॉर्म में चित्र डालने होंगे। यह एक बहुत बड़ी समस्या है। मैं इसे एक विश्लेषक के रूप में नहीं करना चाहता। मैं अन्य संपादकों को नहीं चलाना चाहता। मुझे समझ में नहीं आता कि आवश्यकताओं के विकास के माहौल में इसे क्यों लागू नहीं किया गया है। यह पूरी तरह से MS Office में लागू किया जाता है, जब आप Visio में आरेख खींचते हैं, और फिर इसे MS Office में सम्मिलित करते हैं, जिसके बाद आप इसे Word को छोड़ कर तुरंत संपादित कर सकते हैं।
दूसरे शब्दों में, यह एक बैसाखी है।

6. विश्लेषक - एक प्रोग्रामर नहीं है और कोड के रूप में चित्रों का वर्णन नहीं करना चाहता है

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



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



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

क्या किसी को याद है कि OLE क्या है?

जब Windows 3.0 या Windows 95 दिखाई दिया और OLE को Microsoft द्वारा ठीक एक दस्तावेज़ को दूसरे में एम्बेड करने के अवसर के रूप में प्रचारित किया गया: जैसा कि मैंने कहा, Visio में आरेख बनाएँ, फिर इसे Word में डालें और फिर Word में पहले से ही इसे संपादित करें। मुझे अभी भी समझ नहीं आया है कि WEB के पास ऐसा कोई मानक क्यों नहीं है। कुछ वर्ड में है, कुछ फ्लैश में है, लेकिन एक भी तरीका नहीं है। क्या आप समझते हैं कि मैं किस बारे में बात कर रहा हूं? आप वेब पेज पर जाते हैं और सीधे उस पर संपादित करते हैं और कुछ आकर्षित करते हैं। मुझे एचटीएमएल 5 के लिए उच्च उम्मीदें हैं, क्योंकि कुछ पहले से ही वहां दिखाई दिया था, लेकिन फिर से मुझे समझ नहीं आया कि यह अभी तक मुख्यधारा क्यों नहीं बन पाया है।



एक draw.io सेवा है जो आपको इसे बहुत आसानी से और खूबसूरती से करने की अनुमति देती है, लेकिन साथ ही, आरेखों को उनके सर्वर पर संग्रहीत किया जाता है, आप उन्हें अपने पृष्ठों में सम्मिलित कर सकते हैं, लेकिन घर पर नहीं। शायद यह जल्द ही बदल जाएगा। यही कारण है कि अब माइक्रोसॉफ्ट ऑफिस इतना लोकप्रिय है - वहां इन सभी एकीकरण समस्याओं को बहुत पहले और आसानी से हल किया गया था, और, इसके अलावा, कई विकास हैं।

7. विश्लेषक यह जानना चाहते हैं कि आवश्यकताओं और मॉडलों में क्या बदलाव आया है

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



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



चित्रों के साथ सब कुछ बुरा है। यदि आपको दो चित्रों की तुलना करने की आवश्यकता है, तो आपको समस्या को हल करने की आवश्यकता है "10 अंतर खोजें" - अर्थात्। तुलनात्मक दृष्टि से करें। और कोई उपाय नहीं है।

8. विश्लेषक आवश्यकताओं पर चर्चा करना चाहता है ताकि चर्चा के परिणाम हमेशा हाथ में रहे

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



यह सुविधा विकी द्वारा प्रदान की गई है।

9. विश्लेषक अपने साथ पेपर के पैकेट नहीं ले जाना चाहता और न ही कहीं जाना चाहता है

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



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



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

10. विश्लेषक आवश्यकताओं को एक दूसरे से जोड़ना चाहते हैं

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

मॉडलों में पदानुक्रम

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

ट्रेस मैट्रिक्स

निम्नलिखित स्क्रीनशॉट पर एक नज़र डालें। क्या कोई इसके साथ काम करता है? हां, परीक्षण की योजना बनाने के लिए, परिवर्तनों को ट्रैक करना।



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

11. डेवलपर जानना चाहता है कि उसे किन आवश्यकताओं को लागू करने की आवश्यकता है, और परियोजना प्रबंधक - क्या आवश्यकताओं को अभी तक लागू नहीं किया गया है

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

12. परीक्षक यह जानना चाहता है कि किन आवश्यकताओं का परीक्षण नहीं किया गया है।

और परीक्षक को उन परीक्षण मामलों को जानना होगा जिन्हें उसे पूरा करने की आवश्यकता है।



यह SUT का सार है: सभी प्रक्रियाएं आवश्यकताओं के प्रबंधन के आसपास बनाई जाती हैं, जब कलाकृतियों के बीच बहुत कनेक्शन को ट्रैक करना आवश्यक होता है।
यह टीएफएस में सबसे अच्छा किया जाता है, जो आपको किसी भी चीज़ से, किसी भी चीज़ से, किसी भी तरह से कनेक्ट करने की अनुमति देता है, लेकिन इंटरफ़ेस इस तरह दिखता है।

कलाकृतियों के बीच लिंक

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

13. ग्राहक चाहता है कि उसकी आवश्यकताओं को सही ढंग से समझा जाए।

वह जानना चाहता है कि उसकी आवश्यकताओं का क्या किया गया है।



हम पहले ही सामंजस्यपूर्ण आवश्यकताओं के बारे में बात कर चुके हैं।



मैं इसे दोहराता रहता हूं।



ग्राहक के साथ संवाद करने के लिए, हम लगातार एमएस ऑफिस को निर्यात का उपयोग करते हैं, क्योंकि हमारा मानना ​​है कि ग्राहक एक मूर्ख है (हालांकि कभी-कभी यह सच है), लेकिन सामान्य तौर पर, यह समस्याओं का कारण बनता है। यह एक संकेत है जो प्लग का उपयोग करना बंद कर देता है।

निचला रेखा: किस उपकरण का उपयोग करना है?

सामान्य तौर पर, मैंने उपरोक्त सभी को बातचीत के विषय को संक्षेप में प्रस्तुत करने के लिए SUT का उपयोग करने के विकल्पों के एक आरेख के रूप में प्रस्तुत किया। वास्तव में, कई और विकल्प हो सकते हैं।



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



हम विकल्पों को देखते हैं।



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



समस्या को संक्षेप में प्रस्तुत करना।

टीम विश्लेषक खिलौने का उपयोग नहीं करना चाहती

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



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

सपने

नतीजतन, मैं सपने देखना चाहता हूं। सभी उपकरणों का सबसे अच्छा लेना और एक उपकरण में सब कुछ एक साथ लाना अच्छा होगा।



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



हालाँकि, अपनी रिपोर्ट पर काम करने की प्रक्रिया में, मैंने इन आवश्यकताओं को ठीक किया।
विकास और आवश्यकताओं के प्रबंधन के लिए एक प्रणाली के लिए आवश्यकताएँ
• विभिन्न स्वरूपों में दस्तावेजों का सृजन। सभी के लिए आवश्यकताओं की सुविधाजनक प्रस्तुति।
• ग्राहकों के साथ सहयोगात्मक दूरस्थ कार्य
• प्रभाव लेखा और अनुरेखण। मॉडल और कला संबंधीता।
• संस्करण नियंत्रण परिवर्तन ट्रैकिंग
• मॉडलिंग उपकरण के साथ एकीकरण निर्मित मॉडलिंग उपकरण
• बाहरी ऐड-ऑन बॉक्स से बाहर का उपयोग करने के लिए तैयार



और जो कुछ हुआ उसे मैं दिखाना चाहता हूं।
1. आवश्यकताओं का प्रवेश
यहाँ मैं Confluence में पाठ दर्ज करता हूँ। मुझे किसी रूप में डेटा क्यों दर्ज करना चाहिए? आप इस कार को कर सकते हैं।



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

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

3. चार्टिंग
मैं चाहता हूं कि कनेक्शन इस तरह दिखें। मैं चार्ट को बदलना चाहता हूं, इसे वेब पर मुझे बनाना।



क्यों वेब?

4. परिवर्तनों का प्रदर्शन
यदि हम पहले से ही आरेख को डेटाबेस में रिकॉर्ड के रूप में संग्रहीत करते हैं, तो एक नियम के रूप में, रिकॉर्ड एक्सएमएल में संग्रहीत किया जाता है। XML वह पाठ है जहाँ हम हमेशा सभी परिवर्तनों को अलग कर सकते हैं। यह आरेख में क्यों नहीं दिखाया जा सकता है, मुझे समझ में नहीं आता है। उदाहरण: स्क्रीनशॉट आरेख के दो संस्करणों को दिखाता है, जहां मैं तुरंत दिखा सकता हूं कि पिछले संस्करणों की तुलना में नवीनतम मॉडल में क्या बदलाव आया है।



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

6. प्रबंधकों के लिए उपकरण

आप पाठ के साथ कुछ भी कर सकते हैं। यह स्पष्ट है कि आप जो देख रहे हैं उसके आधार पर आप दृश्य को अनुकूलित कर सकते हैं। उदाहरण के लिए, परियोजना प्रबंधकों के लिए।



सबसे पहले, वह नियुक्त करता है जो इस आवश्यकता को जारी करता है, उसके पास जाएगा और फिर वह स्थिति परिवर्तन पर नज़र रखता है। ऐसे कई उदाहरण हैं।

7. लिंक बनाना।

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

8. संचार दृश्य


मैंने ये तस्वीर इंटरनेट से ली थी। इसका अर्थ यह है: अपने हाथों से सभी संबंधों को बंद करने के बजाय, जैसा कि टीएफएस में, नेत्रहीन कनेक्शन दिखाते हैं।



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



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

वह सब है। सभी को धन्यवाद।

आप 24 मई को मॉस्को में अगले विश्लेषक दिवस सम्मेलन में ग्रेगरी से मिल सकते हैं।