आप अपने समाधान/सिस्टम का वर्णन कैसे करते हैं?

Question

मैं कुछ मानकों/दिशानिर्देशों और टेम्पलेट्स लिखने वाला हूं जो परियोजना प्रबंधक, डेवलपर्स और व्यावसायिक विश्लेषकों का उपयोग करेंगे। लक्ष्य उस समाधान को बेहतर ढंग से समझना होगा जो विकसित किया गया था या विकसित किया गया था।

इसका एक हिस्सा समाधान को दस्तावेज करने पर मानक/दिशानिर्देश प्रदान कर रहा है। जैसे सॉफ़्टवेयर के टुकड़े को दस्तावेज करना जो व्यवसाय-मामले/उपयोगकर्ता-आवश्यकताओं को हल/पूरा करता है।

अब, अपने आप को एक प्रोग्रामर जा रहा है मैं देख सकता हूँ कि यह हुक्म और कहते हैं कि "प्रत्येक समाधान Y का उपयोग कर एक्स और यह पेश जेड के अनुसार परिभाषित करना होगा" असंभव है, के रूप में XYZ हमेशा लागू आदि नहीं है

हालांकि, मैं अपने शौक परियोजनाओं के लिए भी जानता हूं, मैं हमेशा अपने समाधानों को एक तरह से या दूसरे, मॉड्यूल/घटकों, स्रोत कोड टिप्पणियों, एपीआई, डेटाबेस मॉडल, कुछ वर्गीकरण का उपयोग, जर्नल-लॉग, एक्सएमएल प्रारूप इत्यादि का वर्णन करता हूं ..

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

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

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

Answer 1

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

यह भी निर्भर करता है कि आप किस स्तर के दस्तावेज के बारे में बात कर रहे हैं: आवेदन के आधार पर वास्तुशिल्प मार्गदर्शन के लिए, Microsoft Application Architecture Guide 2.0 (हाल ही में जारी) पर एक नज़र डालें।

अगर उससे अधिक निचले स्तर है, SandCastle की तरह कुछ के साथ शुरू और सिर्फ यह क्या पैदा करता है पर तार्किक विस्तार।

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

अगर यह उच्च स्तर की जरूरत है, मेरे पहले पोस्ट पर एक नज़र डालें: जब तक यह लोगों की है कि इसे पढ़ने के लिए तार्किक समझ में आता है Enterprise, Systems and Application Architecture (best Practise)

दिन के अंत में, है, और यह उपयोगी है (के रूप में उस चीज़ का विरोध किया जिसे आपको अभी देना है और कभी भी इसका उपयोग नहीं करेगा) आपने इसे सही किया है।

बड़ी समस्या अक्सर दस्तावेज़ीकरण को अद्यतित रखती है। यह आपको बहुत जल्दी प्रक्रिया और प्रक्रिया निर्माण/कार्यों में सुधार लाने के लिए लाएगा।

Answer 2

प्रलेखन हमेशा किसी भी प्रोजेक्ट का सबसे कठिन हिस्सा है। यदि आप फिर से शुरू करना चाहते हैं, तो आप Domain Driven Design देखें।

यदि आपके पास सही टेम्पलेट है तो कहानी टेम्पलेट का उपयोग करना बहुत फायदेमंद हो सकता है।

के रूप में एक [X]
मैं [Y]
तो चाहते हैं कि [Z]

एक समान नस में आप Use Cases

Answer 3

बहुत कम को देखने के लिए चाहते हो सकता है दुर्भाग्य!

हालांकि, यदि आपके दिशानिर्देश प्रबंधकों और डेवलपर्स के लिए हैं, तो आपके द्वारा उपयोग की जाने वाली भाषा उतनी ही महत्वपूर्ण है जितनी आप इसे पेश करते हैं। चर्चा शब्द और विपणन शब्दजाल का उपयोग न करें, (Here's a good list!)

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

Answer 4

वर्तमान डोमेन के शब्दों का उपयोग करें।यदि आमतौर पर उपयोग किया जाने वाला व्यवसाय डोमेन शब्द होता है, तो दस्तावेज़ और कोड में लगातार उसी शब्द का उपयोग करें। यदि आमतौर पर उपयोग किए जाने वाले प्रोग्रामिंग शब्द (उदाहरण के लिए प्रसिद्ध डिज़ाइन पैटर्न) हैं, तो कोड लिखते समय और तकनीकी विवरणों को दस्तावेज करते समय इसका उपयोग करें।

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

Answer 5

शायद क्योंकि मैंने इसे अभी पढ़ा है और यह अभी भी मेरे सिर के चारों ओर घूम रहा है, लेकिन मुझे लगता है कि यह 37signals Getting Real पढ़ने योग्य है। हालांकि यह एक परियोजना शुरू करने के बारे में है, दस्तावेज़ीकरण का दृष्टिकोण मेरे लिए (प्रोग्रामर के रूप में) के लिए बेहद स्वीकार्य है। यह हर किसी के स्वाद के लिए नहीं है, लेकिन अगर अन्य दृष्टिकोण के साथ बोर्ड पर हैं तो यह दस्तावेज़ीकरण को सुखद भी बना सकता है। मैंने ऐसा पाया।

Answer 6

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

1. डेटा संग्रह (कहाँ डाटा संग्रहित कैसे इस तक पहुंच रहा है?)
2. डाटा प्रारूप (जो प्रारूपों उपयोग किया जाता है? कोई भी नई शुरुआत की? विशिष्टता) आकार बढ़ने?
3. विन्यास
4. लाइब्रेरी/फ्रेमवर्क/पैकेज निर्भरता (विक्रेता, लाइसेंस, संस्करण)
5. समाधान बिल्ड (क्या विन्यस्त किया जा सकता है, क्या डिफ़ॉल्ट है)
(कैसे कदम का निर्माण करने से सभी फाइलों आदि और कदम प्राप्त)
6. मॉड्यूल (डिफाइंड गुंजाइश/क्यों मॉड्यूल शुरू की गई थी)
7. कक्षा/स्रोत-कोड प्रलेखन (Doxygen द्वारा उत्पन्न या समकक्ष)

रुचि की पुस्तकें भी: समाधान के 1. सुरक्षा (जो क्षेत्र मैं सुरक्षा के बीच है, passw/एन्क्रिप्टेड आदि) 2. डाटा ट्रांसफर (क्या डिस्क/नेटवर्क के बीच स्थानांतरित कर रहा है?

Answer 7

अपनी परियोजना के आउटरीच को बढ़ाने के लिए, आप संचार के लिए डोमेन शब्दों का बेहतर उपयोग करेंगे। आवश्यकताओं की खोज के लिए, prototype tools का उपयोग यूआई को तेजी से समझने के लिए किया जा सकता है ताकि यह सुनिश्चित किया जा सके कि आवश्यकताओं को अच्छी तरह से समझा जा सके। यदि आपका उद्देश्य समाधान दस्तावेज के लिए सबसे अच्छा तरीका ढूंढना है, तो मुझे लगता है कि solution architecture के साथ इसका कुछ संबंध है। मुझे लगता है कि IEEE 1471 मानक सॉफ़्टवेयर आर्किटेक्चर को दस्तावेज करने के लिए समग्र दृष्टिकोण प्रदान करता है। perspectives and viewpoints दृष्टिकोण भी देखें। बेशक आप इसे अपने अनुकूल यूएमएल उपकरण के साथ कर सकते हैं।

Answer 8

असल में परियोजनाओं के लिए दस्तावेज़ीकरण करने के कई तरीके हैं। अतीत में उपयोग किए गए 2 दृष्टिकोण 1) उपयोग-केस संचालित विकास, और 2) परीक्षण संचालित विकास। चूंकि मैंने केवल टेस्ट संचालित विकास का उपयोग किया है, इसलिए मैं सलाह देता हूं कि उपयोग-केस संचालित विकास का उपयोग कैसे करें।

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

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

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

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

इन 3 दस्तावेजों का एक साथ उपयोग पाठकों बेहतर मदद कर सकते हैं कि कैसे चीजों को प्रणाली में काम समझते हैं। प्रोग्रामर समझ सकते हैं कि तकनीकी चश्मे कहां से आते हैं, और अंततः उन्हें कैसे कार्य करने की आवश्यकता होगी। यदि आप सही काम करने के लिए प्रोग्रामर को तकनीकी कल्पना नहीं समझ सकते हैं, तो साथ ही उन्हें बताएं कि उन्हें अंततः कार्य करने की आवश्यकता कैसे होगी।

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

मैट्रिक्स उदाहरण: "व्यापार की आवश्यकता है एक" -> "कार्यात्मक युक्ति ए" और "कार्यात्मक युक्ति बी ' " कार्यात्मक युक्ति एक "->" घटक ए', 'घटक बी ", और" घटक सी' "घटक बी" -> "कक्षा ए" और "कक्षा बी"

बेशक यह हमेशा स्प्रेडशीट पर बेहतर दिखता है।

Answer 9

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

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