सॉफ्टवेयर विकास के लिए सामान्य, पारंपरिक कदम/चरण, या अधिक विशेष रूप से, विनिर्देश लेखन क्या हैं?एक परियोजना के लिए विशिष्ट विनिर्देश, पारंपरिक मार्ग
मुझे जलप्रपात विधि, विनिर्देशों को इकट्ठा करने, मामलों का उपयोग इत्यादि जैसी अवधारणाओं के बारे में पता है, लेकिन मैं इसे और अधिक औपचारिक स्पष्टीकरण चाहता हूं।
मैं कंपनियों को आम तौर पर पाया या तो:
चश्मा मत करो।
एक विशिष्ट टेम्पलेट है। प्रत्येक spec सभी दूसरों की तरह दिखता है (यानी "मानक") - वे सभी एक ही वर्ग हैं।
मुझे या तो पसंद नहीं है। प्रत्येक कल्पना अलग है। इसे एक कठोर टेम्पलेट में फिट करने की कोशिश करना एक पुस्तक को एक टेम्पलेट में लिखना है - एक बच्चों की किताब एक वयस्क पुस्तक के लिए अलग है, एक खाना पकाने की किताब के लिए अलग है ....
कुछ चश्मा में जाने की आवश्यकता है तकनीकी विवरण (फ़ाइल स्वरूपों की तरह), लेकिन उपयोगकर्ताओं के दृष्टिकोण से प्रस्तुत किए जाने पर अन्य ठीक होते हैं (एक बटन जिसे क्लिक किया जाता है x)।
मैंने जो सबसे अच्छा चश्मा देखा है वह वे हैं जिन्हें मैं ले सकता हूं और ऐसा कर सकता हूं जो बिना किसी प्रश्न के लेखक से पूछता है। अगर मुझे प्रश्न पूछना है तो मैं कल्पना करता हूं कि यह असफल रहा है। कल्पना मेरे सभी सवालों का जवाब देना चाहिए।
जब मैं एक spec लिख रहा हूं, तो मैं हमेशा इसे प्रिंट करता हूं और इसे पढ़ता हूं (जब इसे मुद्रित किया जाता है तो मुझे और त्रुटियां मिलती हैं)। तब मैं इसे एक दिन के लिए छोड़ देता हूं और इसे फिर से पढ़ता हूं। अगर मुझे कोई गलती मिलती है या किसी चीज के बारे में सोचती है तो यह याद आती है कि मैं spec को अपडेट करता हूं, इसे प्रिंट करता हूं और इसे पढ़ता हूं और इसे एक दिन के लिए छोड़ देता हूं। मैं तब तक ऐसा करता रहता हूं जब तक मुझे इसके साथ कुछ भी गलत न लगे।
एक स्पेक पढ़ने के लिए आसान होना चाहिए। मुझे एक बार 120 पृष्ठ का नमूना दिया गया था जिसमें सामग्री की कोई तालिका नहीं थी और कोई पृष्ठ संख्या नहीं थी। मैंने spec लेखक से सामग्री की एक तालिका डालने के लिए कहा और उसका जवाब "नहीं, मैं चाहता हूं कि लोगों को यह पता लगाने के लिए कि वे क्या खोज रहे हैं, उन्हें पढ़ने के लिए पढ़ना चाहते हैं, तो वे इसे और अधिक पढ़ेंगे"। मैंने सामान की तलाश में उस स्पेक को देखकर बहुत समय बर्बाद कर दिया। वह एक बुरा नमूना था।
spec लिखने के लिए आप जिस भी विधि का उपयोग करते हैं, इससे कोई फर्क नहीं पड़ता - परिणाम महत्वपूर्ण बात है। Spec सभी सवालों को पढ़ने और जवाब देने के लिए आसान होना चाहिए।
हम अपने चश्मे के लिए एक बुनियादी टेम्पलेट का उपयोग करते हैं, लेकिन हमारे पास कुछ लचीलापन है कि सभी भागों को शामिल करने की आवश्यकता है या नहीं। मैं आमतौर पर सामग्री की एक तालिका शामिल करता हूं और यदि आंकड़ों की एक तालिका की आवश्यकता होती है (स्क्रीन शॉट्स, त्रुटि संदेश आदि के लिए)।
कभी-कभी हम एक सुविधा या वृद्धि के साथ शुरू करते हैं, एक पूर्ण कल्पना लिखते हैं, फिर कोडिंग करते हैं। अन्य बार हम इसे कोडिंग शुरू कर देंगे, फिर वापस जाएं और तथ्य के बाद एक spec बाहर मांस। दोनों दृष्टिकोण हमारे लिए काम करते हैं। अक्सर हमारे चश्मा वर्णन करते हैं कि सुविधा उपयोगकर्ता के परिप्रेक्ष्य से कैसे काम करेगी, हालांकि हम कभी-कभी तकनीकी विवरण जैसे नई तालिका परिभाषाएं या मौजूदा कक्षाओं/मॉड्यूल/रूपों में परिवर्तन शामिल करते हैं।
मैं दान से सहमत हूं, यदि अंतिम परिणाम उन लोगों के लिए उपयोगी है जो इसे पढ़ते हैं तो यह एक अच्छा नमूना है। मुझे लगता है कि किसी प्रकार का सहमत प्रारूप होना अच्छा है, इसलिए आप कई चश्मे को देखते समय तुरंत कुछ प्रकार की जानकारी पा सकते हैं।
जोएल इस topic पर लेखों की एक श्रृंखला है, उसकी सलाह, जिसे मैं मानता हूं, महत्वपूर्ण सुविधाओं के लिए संक्षिप्त स्पष्ट चश्मा लिखना और उन्हें काम करने के लिए देवताओं को पास करना है।
आप जो करना नहीं चाहते हैं, वह पूरे प्रोजेक्ट में सबकुछ तैयार करने का प्रयास कर रहा है जब आप शुरू कर रहे हैं। उच्च स्तरीय चश्मे के साथ चिपके रहें, और जब आप किसी सुविधा को लागू करने के लिए तैयार हों तो अधिक जानकारी के लिए अपना रास्ता कम करें। इस तरह आपके पास उतना अधिक दस्तावेज़ ओवरहेड नहीं होना चाहिए, और विकास से पहले आपके स्पेस अप्रचलित होने की संभावना उतनी ही अधिक नहीं है (यदि आपने इसे समय से पहले सप्ताह या महीने पहले किया था)।
आपका किस प्रकार का चश्मा मतलब है? आपके उपयोग के लिए सही नमूना आपकी टीम पर निर्भर करेगा, जो spec और किसी भी परियोजना प्रलेखन आवश्यकताओं का उपयोग करेगा।
चश्मा लक्षित दर्शकों के अनुरूप बनाया जाना चाहिए और दस्तावेज़ के अपेक्षित जीवनकाल पर विचार करना चाहिए। मैंने कार्यात्मक स्पेक और तकनीकी चश्मा का उपयोग किया है। एक कार्यात्मक स्पेक के लिए मुख्य लक्षित दर्शक ग्राहक थे और तकनीकी स्पेक के लिए लक्षित दर्शक डेवलपर थे, और आईटी टीम (तैनाती के लिए)।
कार्यान्वयन के बाद कार्यात्मक स्पेक को आमतौर पर बनाए रखा नहीं जाता था। आम तौर पर प्रोजेक्ट शुरू होने से पहले कार्यात्मक spec बनाया गया था और परियोजना के आकार का आकलन करने के लिए इस्तेमाल किया गया था। मैंने जिस वास्तुकार के साथ काम किया वह पावर प्वाइंट में एक प्रकार का कार्यात्मक स्पेक लिखा था। वह इसे अपनी सभी बैठकों, तकनीकी और गैर तकनीकी में ले गया। यह डॉट पॉइंट वाले चित्रों और पृष्ठों को पढ़ने में आसान था जिसे हमने परियोजना के लिए मिशन कथन की तरह इस्तेमाल किया था।
तकनीकी स्पेक कभी-कभी पूरे प्रोजेक्ट में बनाए रखा गया था। यदि अद्यतित रखा जाता है तो इसे रखरखाव के संदर्भ में उपयोग किया जा सकता है।
मैं @Dan से सहमत हूं कि प्रत्येक spec अलग है, और बहुत अलग दिख सकता है। मेरे लिए महत्वपूर्ण बात यह है कि एक सतत प्रक्रिया है कि आपके हितधारकों को सभी खुश हैं, और किसी भी उपकरण (जैसे बीआरएस टेम्पलेट्स) जो उनके जीवन को आसान बना देगा।
निम्नलिखित similar question का हैक का थोड़ा सा है।
जैसा कि मैंने इसे देखा है;
बीआरएस को शामिल किया गया क्या व्यापार की समस्याओं कर रहे हैं, और आवश्यकताओं के समाधान, परीक्षण, सुरक्षा, विश्वसनीयता चारों ओर क्या कर रहे हैं और वितरण। यह परिभाषित करता है कि एक सफल समाधान क्या होगा।
कार्यात्मक कल्पना विवरण क्या जरूरत है, यह कैसे दिखना चाहिए, कब तक खेतों होना चाहिए, आदि
तकनीकी कल्पना विवरण माध्यम से डेटा प्राप्त, किसी भी मुश्किल कोड विचार करने की आवश्यकता हो सकती है कि आता है।
ग्राहक की आवश्यकताओं का मालिक है। डेवलपर्स तकनीकी चश्मा के मालिक हैं .. और कार्यात्मक कल्पना एक मध्यम जमीन है। तकनीकी चश्मा (आमतौर पर इकाई परीक्षण) के खिलाफ परीक्षण किया जाता है, फिर कार्यात्मक चश्मे (आमतौर पर सिस्टम परीक्षण) और फिर आवश्यकताओं (यूएटी) के खिलाफ।
इसका महत्वपूर्ण हिस्सा यह है कि डेवलपर्स को अभी भी कार्यात्मक spec, और सबसे महत्वपूर्ण रूप से मूल व्यावसायिक आवश्यकताओं को वितरित करने की आवश्यकता है। हकीकत में बीआरएस इस सब में ईश्वर है और कार्यात्मक और तकनीकी कल्पना सिर्फ स्पष्टता के लिए हैं।
जोएल का लेख इस संबंध में बहुत उपयोगी था, हालांकि हमेशा की तरह, मुझे कभी-कभी अपने सभी चरणों का पालन करना मुश्किल लगता है, लेकिन यह निश्चित रूप से मेरी असफलता है। :) – kaybenleroll
मुझे लगता है कि अच्छा ओएल जोएल कुछ अच्छे पुराने यूआरएल पुनर्लेखन से भी लाभ उठा सकता है: पी – melaos
हाँ, एक सुंदर लिंक नहीं। –