मैं स्पष्ट करना चाहता हूं कि विकास की अवधि के दौरान विनिर्देश क्यों नहीं बदलना चाहिए

11

मैं यह समझाना चाहता हूं कि नए नियोजन विभाग के कर्मचारी को विकास की अवधि के दौरान विनिर्देश क्यों नहीं बदलना चाहिए।

requirements specifications requirements-management

4

एक चलती लक्ष्य के खिलाफ प्रोग्रामिंग आधा मजेदार है!

— एंथनी पेग्राम

1

मैं कहता हूँ कि एक शब्द बहुत मजबूत होना चाहिए । एक विनिर्देश एक खाका है, लेकिन कभी-कभी परिवर्तन करने के लिए बहुत अच्छे कारण होते हैं।

7

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

— जेसन हॉल

1

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

— जॉनी क्वेस्ट

1

यदि विनिर्देश को बदलने की आवश्यकता है, या तो क्योंकि आवश्यकताएँ बदल गई हैं या क्योंकि यह गलत पाया गया है, तो विनिर्देश को बदल दिया जाना चाहिए और जितनी जल्दी हो सके। बस यह सुनिश्चित करें कि परिवर्तन की लागत सभी दलों को पता है।

— user16764

18

एक विनिर्देश लगभग हमेशा किसी भी लेकिन सबसे सरल परियोजनाओं के विकास के दौरान बदलता है।

कारण हैं:

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

जैसा कि कल्पना में परिवर्तन का प्रतिकूल प्रभाव पड़ता है (आप कह सकते हैं "ऐसा नहीं होना चाहिए" क्योंकि आप देख सकते हैं कि बहुत सारे कारण हैं जो वे करते हैं, लगभग सभी आपके नियंत्रण से बाहर हैं और कई अच्छे कारण से हैं) -

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

ये सभी राशि निश्चित रूप से परियोजना की डिलीवरी की तारीख (कभी-कभी उल्लेखनीय रूप से) की है और संभावित रूप से दोषों की संभावना बढ़ गई है।

इस बात के सर्वोत्तम उदाहरण के लिए कि कल्पना में मामूली परिवर्तन कैसे चरम समस्याएँ पैदा कर सकता है, मेरे पास आपके लिए 3 पत्र हैं:

Y2K ।

उन्होंने कहा कि " वर्ष 2000 के बाद काम करना चाहिए " कहने का इरादा बदल दिया गया था ।

इसके अलावा, कुछ स्थितियों में यह वास्तव में मामला है कि विनिर्देश है MUST ( "के रूप में अच्छे कारण के बिना परिवर्तन नहीं होना चाहिए" के खिलाफ) में परिवर्तन नहीं:

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

— DVK
स्रोत

ठीक है; मैंने इसे वापस अंदर ले लिया।

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

— jwenting

9

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

महत्वपूर्ण बात यह है कि परिवर्तनों के परिणामों को स्पष्ट रूप से संवाद करना है ताकि सभी को डिजाइन प्रक्रिया की यथार्थवादी अपेक्षाएं हों।

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

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

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

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

— tylerl
स्रोत

6

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

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

— लैरी वतनबे
स्रोत

3

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

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

जहाँ भी मैंने कहा या नहीं का मतलब है या तो परियोजना नए बदलाव के बिना चल रही है। बेशक नई योजनाओं और अनुमान के साथ आने का समय और सामग्री हमेशा होती है।

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

— केविन क्लाइन