Analysis model में application domain का पता लगाने के लिए ग्राहको के साथ काम कर रहे तकनीकी कर्मचारियों को शामिल किया जाता है साथ ही End user, manager, maintenance engineer, domain विशेषज्ञों एवं trade union के कर्मयारियों को भी शामिल किया जा सकता है जिन्हें stakeholder (हितधारक) कहा जाता है।
What is Building the Analysis Model?
सीधे शब्दों में कहें, एक Analysis Model एक विशिष्ट Process को पूरा करने के लिए एक व्यवसाय द्वारा उठाए जाने वाले कदमों की रूपरेखा तैयार करता है, जैसे कि किसी product को order करना या एक नया किराया लेना। process modeling (या Maping) प्रक्रिया दक्षता, प्रशिक्षण और यहां तक कि उद्योग के नियमों का पालन करने में सुधार करने के लिए महत्वपूर्ण है।
What are the four element of analysis model?
Analysis model में निम्न 4 तत्व होते हैं:
Analysis Model Diagam |
i) Scenario based element:
इस element में उपयोगकर्ता की stories और case diagram सम्मिलित होते हैं। साथ ही इस प्रकार के तत्व में system user, system को किस प्रकार देखता है इसे दर्शाया जाता है अर्थात् उपयोगकर्ता के परिप्रेक्ष्य से system का वर्णन किया जाता है।
Read Also - REQUIREMENTS ENGINEERING PROCESS IN SOFTWARE ENGINEERING | ITS TYPES AND ELICIATATION
ii) Class based element:
इस element में collaboration, classes के बीच होता है,इसमें class diagram और collaboration diagram सम्मिलित होते हैं। इसमें object, attributes और relationship परिभाषित होते हैं। इस प्रकार के elements का मुख्य उद्देश्य system के द्वारा manipulate किया जाना होता है। इसमें गुणो को class के रूप में दर्शाया जाता है।
iii) Behavioral based element:
इस Element में state stories और sequence diagram सम्मिलित होते हैं। यह system की स्थिति को प्रस्तुत करने का कार्य करता है साथ ही बाहरी वातावरण के प्रभाव से इसे कैसे बदल जा सकता है इसका निर्धारण किया जाता है।
iv) Flow oriented element:
इस element में data flow diagram और control flow diagram सम्मिलित होते हैं। यह element दर्शाता है कि system के माध्यम से जानकारी कैसे flow होता है और वह कैसे बदल जाता है।
दूसरे शब्दों में कह सकते हैं कि जब किसी computer अधारित system के माध्यम से जानकारियों का प्रवाह होती है तो वह बदल जाती है। इसके द्वारा यह दर्शाया जाता है कि data और object कैसे बदलते हैं जब विभिन्न system के बीच flow चलते रहता है।
What is the analysis model?
यह वास्तविक software के कार्यान्वयन को न दर्शाकर उसके व्यवसायिक प्रक्रियाओ के वैचारिक ढ़ाचे को दर्शाता है। Fowler के अनुसार pattern जो practically जब यह उपयोगी है तो यह अन्य लोगो के लिए भी उपयोगी होगा | Software analysis pattern एक वैचारिक model होता जो अक्सर एक model के रूप में सामने आ सकता है।
Analysis Pattern निम्न तत्व होते हैं -
i) Analysis pattern एक design pattern और सामान्य pattem के लिए विश्वशनिय समाधान के रूप में होता है जिसके द्वारा सामान्य model को analysis model में प्ररिवर्तन कर सकते हैं।
ii) इसके द्वारा सामान्य analysis model को reusable analysis model में बदला जा सकता है जो development प्रक्रिया में तेजी लाने का कार्य करता है।
iii) Analysis patter के द्वारा समाधान प्राप्त होता है जिसे भविष्य में modeling के दौरान पुनः उपयोग में लाया जा सकता है।
Software Requirements Negotiation
किसी system को जब तैयार किया जा रहा हो तब उसमें आने वाले conflict को हल करने और पहचान करने के लिए negotiating requirement की आवश्यकता होती है। इसी प्रकार हितधारको की जरूरतो को ध्यान में रखकर project plan तैयार करने के लिए negotiating (बातचीत) करने के आवश्यकता होती है।
Negotiation activities बातचीत की गतिविधियाँ निम्नलिखित होती है
- System के मुख्य हितधारको की पहचान करना।
- हितधारको के पहचान हो जाने के पश्चात् उनका निर्धारण करना।
- सभी developer सहीत सभी हितधारक से बातचीत करना ताकी project को चालाने में किसी प्रकार की कोई समस्या ना हो। अंत में software engineer के द्वारा आगे के गतिविधियों के लिए अंतिम परिणाम पेश किया जाता है।
What is validation requirements?
निर्धारित आवश्यकताओं को वास्तव में ग्राहक चाहता है इसे परिभाषित करना अत्यन्त आवश्यक होता है। इसकी मुख्य वजह आवश्कताओं की त्रुटि को दूर करने की लागत का बहुत अधिक होना होता है।
कई बार software deliver करने के बाद उसमें त्रुटि आती है तो उसमें बदलान बहुत ही कठीन कार्य हो जाता है इसलिए इसकी लागत भी बहुत अधिक होती है। इस प्रकार के समस्या से बचने के लिए validation की आवश्यकता होती है।
किस validating requirement की समीक्षा की जाती है जिसके लिए निम्न प्रकार प्रश्न तैयार किये जाते हैं:
- क्या प्रत्येक requirement समस्त project और system के उद्देश्य के अनुरूप है?
- क्या प्रत्येक requirement निर्धारित सीमा में और स्पष्ट रूप में है?
- क्या requirement किसी अन्य के साथ conflict हो रहा है?
- क्या आपको प्रत्येक requirement के श्रोत के विषय में जानकारी है?
- क्या तैयार सभी आवश्यकताओं का pattern मान्य है और वे सभी customer के आवश्यकताओं के अनुरूप है?
- क्या निर्धारित आवश्यकताएं ग्राहक के सभी जरूरतो को पूरा करते हैं यदि नहीं करते तो add-on सुविधा दिया जाए या नहीं?
Requirement Checking:
आवश्यकताओं की जाच निम्न बिंदुओ के अधार पर किय जाता है:
i) Validity:
Validity में यह जॉच किया जाता है कि जो system के द्वारा ग्राहक को सुविधा प्रदान किया जा रहा है वह क्या उसके इच्छ के अनुरूप है या नहीं।
ii) Consistency:
इसमें यह देखा जाता है कि ग्राहक के किसी आवश्यकता में conflicts तो नहीं है।
iii) Realism:
इसमें यह देखा जाता है कि आवश्यकताओं को निर्धारि budget और उपलब्ध technology में पूरा किया जा सकता है नहीं।
iv) Completeness:
इसमें यह देखा जाता है कि ग्राहक द्वारा सम्मिलित स function project में मौजूद है या नहीं।
v) Verifiability:
इसमें यह देखा जाता है कि आवश्यकताओं की जॉच किया सकता है या नहीं।
0 Comments