विश्लेषक दिन: इरीना सुरोवा - अभ्यास में निशान का उपयोग करना

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









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





रिपोर्ट की प्रस्तुति:

www.slideshare.net/VLDCORP/ss-21934265



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

मेरे बारे में

• आईटी में 10 से अधिक वर्षों के लिए, जिनमें से
• सिस्टम विश्लेषण में 5 साल
• विश्लेषकों की एक टीम के प्रबंधन का अनुभव
• विकास प्रक्रियाओं को बनाने और समर्थन करने में अनुभव
• Stratoplan.ru परियोजना के लागू सिस्टम विश्लेषण के क्लब के सह-लेखक
• एनालिटिक्स समुदाय के सदस्य uml2.ru
• मैं विश्लेषण विभाग में उपकरणों के लिए जिम्मेदार हूं

।

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



सामान्य तौर पर, स्लाइड पर आप देख सकते हैं कि मैं क्या कर रहा हूं, मुझे किस बात पर गर्व है और मैं किन सवालों से संपर्क कर सकता हूं।

विषय के बारे में

• पाठ्यपुस्तकों में निशान - चांदी की गोली

• व्यवहार में अनुरेखण - कठिन और कठिन

• अनुसंधान में निशान - चुनौतियाँ और आशाएँ (देखें ollygotel.com/requirements-traceability )

• मैं एक पूर्णतावादी और अभ्यासी हूँ

• प्रयोगात्मक डेटा है - मैं साझा करना चाहता हूं



संक्षेप में परिभाषा के बारे में:

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

[गोटेल और फिन्केलस्टीन 1994]



या रूसी में बोलना:

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

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



मेरे पास 3 रिलीज़: रिलीज़ 1 पर आधारित प्रायोगिक डेटा है, जो बिना निशान के चला गया, रिलीज़ 2, जो निशान के साथ चला गया, और अब हमने रिलीज़ 3 की योजना बनाई है, जो बेहतर निशान के साथ जाएगा।

रिलीज़ 1. प्रसंग

• Kaspersky Lab उत्पादों में से 1

• 3 रिलीज़ (अतीत, वर्तमान, भविष्य)

• व्यावसायिक आवश्यकताओं का प्रभाव

• वास्तुकला का प्रभाव

• पर्यावरणीय प्रभाव (उपकरण, अभ्यास, आदि)



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

डिजाइन कलाकृतियों

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



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



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



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



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



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



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



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

पहचानी गई कठिनाइयाँ:

हमें कॉल (चुनौतियों) की एक सूची मिली - ये वे प्रश्न हैं जो मुझसे पूछे गए थे और मैं उनका उत्तर नहीं दे सका।

• यह निर्धारित करना मुश्किल है कि यह व्यावसायिक आवश्यकता रिलीज़ स्कोप में शामिल है या नहीं (C1)

• यह निर्धारित करना मुश्किल है कि व्यावसायिक आवश्यकता को जोड़ने से रिलीज़ गुंजाइश (C2) कैसे प्रभावित होगी

• रिलीज की स्थिति (क्या किया जाना बाकी है, पहले ही हो चुका है) (C3) निर्धारित करना मुश्किल है

• आवश्यकताओं को समेटना मुश्किल है (एसआरएस प्रति कार्यात्मक क्षेत्र - बड़ा, सारणीबद्ध प्रारूप परिवर्तनों और टिप्पणियों के साथ काम करने के लिए सुविधाजनक नहीं है (C4 - निशान पर लागू नहीं होता है)

• टीम के काम की सही योजना बनाना मुश्किल है, जैसे कार्यात्मक क्षेत्र योजना (C5) के लिए बहुत बड़ा तत्व है।

• किसी विशेष क्षेत्र में विकास कार्य के दायरे की सही योजना बनाना मुश्किल है, जैसे आवश्यकताओं की संख्या अज्ञात है (C6)।

• एक विशिष्ट कार्यात्मक के विकास की गुणवत्ता को जल्दी से निर्धारित करना मुश्किल है, क्योंकि आवश्यकताओं और परीक्षण के मामले संबंधित नहीं हैं (C7)।

• कार्यात्मक के कार्यान्वयन की सही योजना बनाना मुश्किल है, क्योंकि यह स्पष्ट नहीं है कि आसन्न टीमों ने पहले से ही क्या निर्धारित किया है और क्या नहीं है (सी 8)।

रिलीज 1 खत्म हो गया है

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

हमें अगली रिलीज करने की जरूरत है

रिलीज़ २

भविष्य को टटोलना

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







फिर हमने विचार करना शुरू कर दिया कि किन चीजों को ध्यान में रखा जाना चाहिए, जो हमारी परियोजना को प्रभावित करती है - यहां तक ​​कि रिलीज भी नहीं, लेकिन इसकी तैयारी। हमने माना कि हमारे पास रिलीज़ के लिए आवश्यकताओं के स्रोतों के 3 समूह हैं:

गार्टनर की मैजिक क्वाड्रंट एंड अदर इंडस्ट्री एनालिटिकल रिपोर्ट्स

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



वास्तव में, बॉक्सिंग उत्पादों में, उत्पाद के लिए आवश्यकताओं का स्रोत न केवल प्रश्नावली है, बल्कि एक पूरे के रूप में उद्योग की प्रवृत्ति: आपको प्रतियोगियों और उनके नियोजित विकास को देखने की जरूरत है। हालांकि, विश्लेषणात्मक एजेंसियों की समीक्षा आवश्यकताओं का एक महत्वपूर्ण स्रोत है।



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

स्वतंत्र प्रयोगशालाओं के परीक्षणों में भागीदारी।

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

बाहरी वातावरण

आवश्यकताओं का एक और (या बल्कि दो) स्रोत विक्रेताओं और नियामकों के प्रमाणन की आवश्यकताएं हैं (उदाहरण के लिए, रूस में एफएसटीईसी, विदेश में सामान्य मानदंड, विभिन्न देशों का कानून)। यदि आप पैकेजिंग पर "विंडोज 8 के तहत काम करता है" इंगित करना चाहते हैं, तो आपके उत्पाद को Microsoft की आवश्यकताओं को पूरा करना होगा। यदि आप अपना उत्पाद सरकारी एजेंसियों तक पहुँचाना चाहते हैं, तो आपको पहले इसे FSTEC, और कभी-कभी FSB के साथ प्रमाणित करना होगा। और इन मामलों में से प्रत्येक के लिए, हमें उत्पाद में प्रारंभिक प्रमाणीकरण आवश्यकताओं के अनुपालन को ट्रैक करने के लिए भी निशान की आवश्यकता है।



इस प्रकार, हम उपभोक्ताओं को कम से कम 3 समूहों का पता लगाते हैं। यह पता चला कि हमारे उत्पादों के निशान होना महत्वपूर्ण है। हमारे पास ऐसे ग्राहक हैं, जिन्हें ट्रैक करने की आवश्यकता है कि क्या उत्पाद में कुछ विशेषताएं लागू की गई हैं। पहले पाठों में से एक: कोई उपभोक्ता नहीं है - ऐसा न करें, उन लोगों को ढूंढें जिन्हें वास्तव में इसकी आवश्यकता है।

उत्पाद वास्तुकला

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



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

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



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



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

प्रक्रिया परिवर्तन आवश्यकताएँ

• —

• —

• —

• , / —

• —



: .. . – , . , : . ().







, . , . , .



-, - SharePoint. -: : . () -, ( , 5 , 40). , SharePoint (/ , – , ..) .. scope , . (  ).

TFS -, . : Enterprise Architect , , SRS, .. EA TFS, TFS .



, EA, , TFS. , . , Word-, ( .. , Excel). TFS. , TFS. change request' , , . , , . , . . change request' TeamTrack . , , , 2.



: -- (Epic-BRQ) TFS. , (BRQ). BRQ (SR), . SR -. SR - (CR): -, (SRS).



: , , , . ' . , , : 3 400 CR. , , , . , – . , PM' , , – . - . और वह यह है। 'a : , , , CR' ( ). CR , SR.



, , , .

प्रश्न 1

: SRS, SR CR?

: , BRQ SharePoint. «»: - , . - , SRS, CR . , , .. .

प्रश्न २

: SR EA TFS? ?

: , . TFS , . . , SRS ( SharePoint), – . .



SR 2 (TFS SRS) , , () .

3

: ?

: , . , SR – : use-case, .. : SR , .

4

: Use-case ? , ? UseCase 2.0?

: , use-case . , , . . . use-case .

4

: – 1 . ?

: , . 2 : , , . active, . . TFS history . , Word. , .

5

: -?

: . -.

2

• (Time Driven Development)

•

• ,



2

• - (BRQ) SharePoint scope ( — )

• EA ( — xls-)

• SRS

• SRS — doc- - ( — xls- )

• — BRQ ( — )





• BRQ (C4, C5)

• - ( «in scope/out of scope» .) (1)

• , BRQ, ( . , ) (6)

• SRS BRQ (4)

• SR, (2, 3, 6, 8)



,

• : BRQ — SRS ( )

• /: BRQ- CR- SRS (BRQ-InfraCR-InfraSRS)

• : —





• : BRQ-SR

• : SR — DevTask

• : BRQ-CR

• : SR — CR

• BRQ () — SR (), BRQ () — CR ()

2.

, - «» . , , .. - . :

• -

•

•

3.

दूसरी रिलीज के दौरान, अन्य परियोजनाओं पर जीवन नहीं रुका, और उन्होंने भी कुछ किया। उसी समय, उन्होंने सभी आरएनडी को टीएफएस में स्थानांतरित करना शुरू कर दिया। एक समर्पित टीम दिखाई दी जिसने इसमें सुधार किया।

रिहाई की तैयारी 3. कैसे होगी

आरेख में जो कुछ भी आप देखते हैं वह टीएफएस में लागू किया जाएगा। यह "कवि का सपना" है!



पहला स्तर व्यावसायिक आवश्यकताओं का है। SharePoint से दूर। एक पड़ोसी परियोजना ने टीएफएस (हुर्रे!) पर इस योजना को बनाया और अब किसी भी तरह के गुप्त लिंक की आवश्यकता नहीं है: सभी एक ही स्थान पर।



अगले स्तर पर परिवर्तन अनुरोध हैं। अब पड़ोसी टीमें भी टीएफएस में काम करती हैं। वे समझते हैं कि कैसे काम करना है।



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



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



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

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



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

सबक सीखा

• परमाणु व्यापार आवश्यकताओं का उपयोग करने से हमें परियोजना की वर्तमान स्थिति (LL1) को जल्दी से समझने की अनुमति मिलती है

• विकास / परीक्षण के कार्यों के रूप में परमाणु प्रणाली की आवश्यकताओं का उपयोग करके उत्पाद की गुणवत्ता (एलएल 2) में सुधार होता है, लेकिन आवश्यकता के अर्थ को बदल देता है (समस्या को स्थापित करने के पक्ष में)

• आवश्यकताओं और परीक्षण कलाकृतियों (TestCase और बग) के बीच निशान की कमी से एक विशिष्ट आवश्यकता (C7, LL3) की वर्तमान स्थिति को समझना मुश्किल हो जाता है

• प्रक्रिया का समर्थन करने के लिए कई अलग-अलग उपकरणों का उपयोग करना विकास दक्षता और उत्पाद की गुणवत्ता (एलएल 4) को कम करता है

निष्कर्ष

यह योजना कहाँ और कब लागू है?

नीचे मैंने सूचीबद्ध किया है कि किन मामलों में यह योजना काम आ सकती है (ताकि फुर्तीले प्रेमी "मुझे लाठी से पीटें" नहीं)

• बाजार में उत्पाद की सफलता के लिए व्यावसायिक आवश्यकताओं की गुणवत्ता महत्वपूर्ण है।

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

• परियोजना की सफलता के लिए महत्वपूर्ण समय सीमा

• उत्पाद में जटिल संबंधों के साथ कई सबसिस्टम होते हैं जो विभिन्न टीमों द्वारा विकसित किए जाते हैं

• विभिन्न उत्पादों में उप-प्रणालियों का पुन: उपयोग किया जाता है (यह सेवाओं पर भी लागू होता है) - यहां हमें कई-से-कई रिश्तों का सामना करना पड़ता है, जो प्रबंधन और आवश्यकताओं के नियंत्रण को जटिल बनाता है

• विभिन्न परियोजनाओं में विकास प्रक्रियाएं समान हैं - यह ध्यान देने योग्य है कि संबंधित टीमों में किए गए प्रक्रिया सुधारों ने हमें अपने सुधारों को बचाने की अनुमति दी है। और यदि आप अकेले हैं, तो परिवर्तन धीमा होंगे, क्योंकि इंतजार करने के लिए कहीं से मदद।

किसी प्रक्रिया को बनाने और समर्थन करने के लिए क्या आवश्यक है

• नेतृत्व का समर्थन चाहिए!

o प्रक्रिया के विकास और समर्थन के लिए संसाधनों का आवंटन (प्रक्रिया स्वयं महंगी है और उपकरण के लिए और उन्हें समर्थन करने वाली टीम के लिए उच्च लागतों की आवश्यकता होती है; अर्थात, इसे नंगे उत्साह के साथ उठाना बहुत मुश्किल है)

o सभी भूमिकाओं के कर्मचारियों को नियमित रूप से प्रक्रिया का उपयोग करने के लिए प्रेरित करना

• अभ्यास और नियमों को सभी द्वारा अच्छी तरह से वर्णित और समझा जाना चाहिए।

• उपकरण को अभ्यास और उपयोगकर्ता के अनुकूल करने के लिए अनुकूलित किया जाना चाहिए।

• एक टूल सपोर्ट टीम को योग्य और प्रेरित होना चाहिए।

• विभिन्न परियोजना टीमों के बीच ज्ञान और प्रथाओं का आदान-प्रदान