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

Syntactic domains:

औपचारिक विनिर्देश भाषा के वाक्य-विन्यास क्षेत्र में प्रतीकों की एक वर्णमाला और वर्णमाला से अच्छी तरह से गठित सूत्रों का निर्माण करने के लिए गठन नियमों का एक सेट होता है। एक प्रणाली को निर्दिष्ट करने के लिए अच्छी तरह से गठित सूत्रों का उपयोग किया जाता है।

Semantic domains:

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

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

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

GANTT chart in Hindi

गैंट चार्ट एक क्षैतिज बार चार्ट है जिसका उपयोग परियोजना प्रबंधन में समय के साथ एक परियोजना योजना का दृश्य रूप से प्रतिनिधित्व करने के लिए किया जाता है। आधुनिक गैंट चार्ट आमतौर पर आपको समयरेखा और स्थिति दिखाते हैं - साथ ही परियोजना में प्रत्येक कार्य के लिए कौन जिम्मेदार है।

यहाँ विवरण पर एक त्वरित नज़र है एक गैंट चार्ट आपको एक नज़र में कैप्चर करने में सक्षम बनाता है:

• कैसे एक परियोजना कार्यों में टूट जाती है
• जब प्रत्येक कार्य प्रारंभ और समाप्त होगा
• प्रत्येक कार्य में कितना समय लगेगा
• प्रत्येक कार्य को किसे सौंपा गया है
• कार्य कैसे संबंधित हैं और एक दूसरे पर निर्भर हैं
• जब महत्वपूर्ण बैठकें, अनुमोदन या समय सीमा होने की आवश्यकता हो
• किसी प्रोजेक्ट में काम कैसे आगे बढ़ रहा है
• शुरू से अंत तक पूरा प्रोजेक्ट शेड्यूल

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

gantt chart Kaise Padhe

गैंट चार्ट पहली बार में जटिल लग सकता है। लेकिन एक बार जब आप मूल बातें सीख लेते हैं, तो आप आसानी से गैंट चार्ट को पढ़ और बना पाएंगे और बता पाएंगे कि आपकी परियोजनाएं कहां हैं और उन्हें सफलता के लिए मार्गदर्शन करने के लिए क्या करने की आवश्यकता है।

Elements of a gantt chart in Hindi

गैंट चार्ट को पढ़ना वास्तव में यह समझने के लिए नीचे आता है कि गैंट चार्ट को काम करने के लिए विभिन्न तत्व एक साथ कैसे आते हैं।

आइए कुछ बुनियादी शब्दावली की समीक्षा करें ताकि आप गैंट चार्ट के प्रमुख हिस्सों को समझ सकें और वे एक परियोजना योजना में कैसे कार्य करते हैं:

Task list: परियोजना कार्य का वर्णन करने के लिए गैंट चार्ट के बाईं ओर लंबवत चलती है और इसे समूहों और उपसमूहों में व्यवस्थित किया जा सकता है

Timeline:  गैंट चार्ट के शीर्ष पर क्षैतिज रूप से चलती है और महीनों, सप्ताहों, दिनों और वर्षों को दिखाती है

Dateline: एक लंबवत रेखा जो गैंट चार्ट पर वर्तमान तिथि को हाइलाइट करती है

Bars: गैंट चार्ट के दाईं ओर क्षैतिज मार्कर जो कार्यों का प्रतिनिधित्व करते हैं और प्रगति, अवधि, और प्रारंभ और समाप्ति तिथियां दिखाते हैं

Milestones: पीले हीरे जो प्रमुख घटनाओं, तिथियों, निर्णयों और डिलिवरेबल्स को बुलाते हैं

Dependencies: हल्के भूरे रंग की रेखाएँ जो एक निश्चित क्रम में होने वाले कार्यों को जोड़ती हैं

Progress: दिखाता है कि काम कितना दूर है और प्रतिशत पूर्ण और/या बार छायांकन द्वारा इंगित किया जा सकता है

Resource assigned: किसी कार्य को पूरा करने के लिए जिम्मेदार व्यक्ति या टीम को इंगित करता है

USE of gantt chart in Hindi

तो आप कैसे जानते हैं कि अपने प्रोजेक्ट को प्रबंधित करने के लिए गैंट चार्ट का उपयोग कब करना है? हमें लगता है कि एक योजना के साथ किसी भी परियोजना के लिए एक गैंट चार्ट आसान है! लेकिन यहां कुछ निश्चित संकेत दिए गए हैं कि काम पूरा करने के लिए आपको एक गैंट चार्ट की आवश्यकता होगी।

यदि इनमें से कोई भी आपके प्रोजेक्ट के बारे में सही है, तो गैंट चार्ट का उपयोग करें:

• आपकी परियोजना की एक कठिन समय सीमा है।

• परियोजना में कई लोग या टीमें शामिल हैं और उन्हें समन्वित करने की आवश्यकता है।

• एक बॉस, क्लाइंट या टीम का सदस्य परियोजना की शुरुआत से अंत तक एक दृश्य समयरेखा देखना चाहता है।

• आपकी परियोजना में थोड़ी जटिलता भी शामिल है, जैसे कि ऐसे कार्य जिन्हें एक विशिष्ट क्रम में करने की आवश्यकता होती है।

• टीम के सदस्य एक समय में कई परियोजनाओं पर काम करते हैं, और आपको उनके कार्यभार को प्रबंधित करने की आवश्यकता होती है।

• आपके पास मोटे तौर पर इस बात का अच्छा अंदाजा है कि प्रत्येक कार्य में कितना समय लगना चाहिए या इसमें लग सकता है।

limitations Of gantt Chart

कुछ लोगों को लगता है कि गैंट चार्ट बनाने, पढ़ने और अपडेट करने के लिए बहुत जटिल हैं। जबकि पारंपरिक डेस्कटॉप ऐप की अपनी सीमाएँ होती हैं, गैंट चार्ट से जुड़े अधिकांश लोग ऑनलाइन गैंट चार्ट सॉफ़्टवेयर पर लागू नहीं होते हैं जो आपको आज मिलेंगे।

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

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

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

Check also :- software design in software engineering in Hindi

object oriented design in software engineering in Hindi

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

• Classes: एक वर्ग किसी वस्तु का सामान्यीकृत विवरण होता है। एक वस्तु एक वर्ग का एक उदाहरण है। एक वर्ग उन सभी विशेषताओं को परिभाषित करता है, जो एक वस्तु में हो सकती हैं और विधियाँ, जो वस्तु की कार्यक्षमता का प्रतिनिधित्व करती हैं।

• Messages: वस्तुएँ संदेश पास करके संचार करती हैं। संदेशों में लक्ष्य वस्तु की अखंडता, अनुरोधित संचालन का नाम और कार्य करने के लिए आवश्यक कोई अन्य क्रिया शामिल होती है। संदेशों को अक्सर प्रक्रिया या फ़ंक्शन कॉल के रूप में लागू किया जाता है।

• Abstraction  object-oriented design, में, अमूर्तता का उपयोग करके जटिलता को नियंत्रित किया जाता है। अमूर्तता अप्रासंगिक को हटाने और आवश्यक का प्रवर्धन है।

• Encapsulation: एनकैप्सुलेशन को सूचना छिपाने की अवधारणा भी कहा जाता है। डेटा और संचालन एक इकाई से जुड़े हुए हैं। एनकैप्सुलेशन न केवल किसी वस्तु की आवश्यक जानकारी को एक साथ बंडल करता है, बल्कि बाहरी दुनिया से डेटा और विधियों तक पहुंच को भी प्रतिबंधित करता है।

• Inheritance: OOD समान वर्गों को एक पदानुक्रमित तरीके से स्टैक करने की अनुमति देता है जहाँ निम्न या उप-वर्ग अपने तत्काल सुपरक्लास से अनुमत चर और कार्यों को आयात, कार्यान्वित और पुन: उपयोग कर सकते हैं। OOD की इस संपत्ति को एक विरासत कहा जाता है। इससे विशिष्ट वर्ग को परिभाषित करना और विशिष्ट वर्ग से सामान्यीकृत वर्ग बनाना आसान हो जाता है।

• Polymorphism: OOD भाषाएँ एक ऐसा तंत्र प्रदान करती हैं जहाँ समान कार्य करने वाली विधियाँ लेकिन तर्कों में भिन्न होती हैं, उन्हें एक ही नाम दिया जा सकता है। इसे बहुरूपता के रूप में जाना जाता है, जो एक एकल इंटरफ़ेस को विभिन्न प्रकारों के लिए कार्य करने की अनुमति देता है। सेवा कैसे लागू की जाती है, इस पर निर्भर करते हुए, कोड के संबंधित भाग को निष्पादित किया जाता है।

function oriented design in software engineering की एक विधि है जहाँ मॉडल को परस्पर क्रिया करने वाली इकाइयों या मॉड्यूल के एक सेट में विघटित किया जाता है जहाँ प्रत्येक इकाई या मॉड्यूल में एक स्पष्ट रूप से परिभाषित फ़ंक्शन होता है। इस प्रकार, सिस्टम को एक कार्यात्मक दृष्टिकोण से डिज़ाइन किया गया है।

Design Notations

डिज़ाइन नोटेशन मुख्य रूप से डिज़ाइन की प्रक्रिया के दौरान उपयोग किए जाने के लिए होते हैं और डिज़ाइन या डिज़ाइन निर्णयों का प्रतिनिधित्व करने के लिए उपयोग किए जाते हैं। फ़ंक्शन-ओरिएंटेड डिज़ाइन के लिए, डिज़ाइन को ग्राफ़िक या गणितीय रूप से निम्नलिखित द्वारा दर्शाया जा सकता है:

Data Flow Diagram for function oriented design in software engineering in Hindi

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

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

डेटा-प्रवाह डिज़ाइन कई डिज़ाइन विधियों का एक अभिन्न अंग है, और अधिकांश CASE उपकरण डेटा-प्रवाह आरेख निर्माण का समर्थन करते हैं। डेटा-प्रवाह आरेख निकायों का प्रतिनिधित्व करने के लिए अलग-अलग तरीके अलग-अलग आइकन का उपयोग कर सकते हैं, लेकिन उनके अर्थ समान हैं।

symbols for function oriented design in software engineering

function oriented design in software engineering in hindi

function oriented design in software engineering

रिपोर्ट जेनरेटर एक रिपोर्ट तैयार करता है जो डेटा-फ्लो आरेख में सभी नामित इकाइयों का वर्णन करता है। उपयोगकर्ता आरेख द्वारा दर्शाए गए डिज़ाइन का नाम इनपुट करता है। रिपोर्ट जनरेटर तब डेटा-फ्लो आरेख में उपयोग किए गए सभी नामों को ढूंढता है। यह एक डेटा डिक्शनरी को देखता है और प्रत्येक नाम के बारे में जानकारी प्राप्त करता है। इसके बाद इसे एक रिपोर्ट में मिलाया जाता है जो सिस्टम द्वारा आउटपुट होता है।

Data Dictionaries

डेटा डिक्शनरी सिस्टम के DFD मॉडल में प्रदर्शित होने वाले सभी डेटा तत्वों को सूचीबद्ध करता है। सूचीबद्ध डेटा आइटम में सभी डेटा प्रवाह और सिस्टम के DFD मॉडल में DFD को देखने वाले सभी डेटा स्टोर की सामग्री शामिल होती है।

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

                      grossPay = regularPay + overtimePay

डेटा तत्वों की सबसे छोटी इकाइयों के लिए, डेटा डिक्शनरी उनके नाम और उनके प्रकार को सूचीबद्ध करती है।

डेटा डिक्शनरी किसी भी सॉफ्टवेयर विकास प्रक्रिया में निम्नलिखित कारणों से महत्वपूर्ण भूमिका निभाती है:

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

• डेटा डिक्शनरी विश्लेषक को उनके घटक तत्वों के संदर्भ में विभिन्न डेटा संरचनाओं की परिभाषा निर्धारित करने का साधन प्रदान करती है।

Structured Charts for function oriented design in software engineering in Hindi        

यह एक सिस्टम को ब्लॉक बॉक्स में विभाजित करता है। एक ब्लैक बॉक्स सिस्टम जिसकी कार्यक्षमता आंतरिक डिज़ाइन के ज्ञान के बिना उपयोगकर्ता को ज्ञात होती है।

Structured Charts

संरचित चार्ट एक ग्राफिकल प्रतिनिधित्व है जो दिखाता है:

मॉड्यूल में सिस्टम विभाजन

घटक मॉड्यूल का पदानुक्रम

प्रसंस्करण मॉड्यूल के बीच संबंध

मॉड्यूल के बीच बातचीत

मॉड्यूल के बीच पारित जानकारी

संरचित चार्ट में निम्नलिखित नोटेशन का उपयोग किया जाता है:

Function oriented design in software engineering

Pseudo-code

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

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

Check also ;- small business ideas Hindi

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

 इसलिए व्यवसाय के मालिकों को संभावित जोखिमों को दूर करने और इसे लागू करने के लिए अपने कर्मचारियों को प्रशिक्षित करने के लिए एक आंतरिक नीति विकसित करनी चाहिए। ई-कॉमर्स लेनदेन में जोखिम प्रबंधन के लिए सबसे महत्वपूर्ण प्रक्रियाएं निम्नलिखित हैं।

e business risk management issues in Hindi

1. जोखिमों को समझें और अपने कर्मचारियों को प्रशिक्षित करें

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

2. सूचना सुरक्षा सुनिश्चित करें

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

3. सही अधिग्रहण करने वाले बैंक और मर्चेंट सेवा प्रदाता का चयन करें।

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

4. प्रभावी नीतियां बनाएं और प्रदर्शित करें

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

5. नुकसान को कम करने के लिए संग्रह प्रयासों का प्रयोग करें

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

इसलिए, ई-कॉमर्स लेनदेन में जोखिम को सीमित करने के लिए उपरोक्त सभी विधियां बहुत सी विधियों में से कुछ हैं। अपने ऑनलाइन स्टोर को अधिक प्रभावी ढंग से विकसित करने के लिए आपको इन सुझावों का पालन करना चाहिए।

Risk in software engineering

"कल की समस्याएं आज का जोखिम हैं।" इसलिए, "जोखिम" की एक स्पष्ट परिभाषा एक ऐसी समस्या है जो कुछ नुकसान का कारण बन सकती है या परियोजना की प्रगति को खतरा पैदा कर सकती है, लेकिन जो अभी तक नहीं हुआ है।

ये संभावित मुद्दे परियोजना की लागत, समय-सारणी या तकनीकी सफलता और हमारे सॉफ्टवेयर उपकरण की गुणवत्ता, या परियोजना टीम के मनोबल को नुकसान पहुंचा सकते हैं।

Check also :- Function oriented design in software engineering in Hindi     

जोखिम प्रबंधन परियोजना को नुकसान पहुंचाने से पहले इन समस्याओं को संबोधित करने और उन्हें समाप्त करने की प्रणाली है।

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

इन दो प्रकार के मुद्दों को हल करने के लिए विभिन्न तरीकों की आवश्यकता होती है।

उदाहरण के लिए, कर्मचारियों का भंडारण, क्योंकि हम सही तकनीकी कौशल वाले लोगों का चयन करने में सक्षम नहीं हैं, यह एक मौजूदा समस्या है, लेकिन प्रतिस्पर्धा से हमारे तकनीकी व्यक्तियों को काम पर रखने का खतरा एक जोखिम है।

Risk Management in software engineering in Hindi

एक सॉफ्टवेयर प्रोजेक्ट कई तरह के जोखिमों से संबंधित हो सकता है। एक सॉफ्टवेयर प्रोजेक्ट को प्रभावित करने वाले महत्वपूर्ण जोखिमों को व्यवस्थित रूप से पहचानने के लिए, जोखिमों को विभिन्न वर्गों में वर्गीकृत करना आवश्यक है। परियोजना प्रबंधक तब जांच कर सकता है कि प्रत्येक वर्ग से कौन से जोखिम परियोजना के लिए प्रासंगिक हैं।

जोखिम के तीन मुख्य वर्गीकरण हैं जो एक सॉफ्टवेयर परियोजना को प्रभावित कर सकते हैं:

• परियोजना जोखिम (Project risks)
• तकनीकी जोखिम (Technical risks)
• व्यापार जोखिम (Business risks)

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

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

3. व्यापार जोखिम (Business risks): इस प्रकार के जोखिमों में एक उत्कृष्ट उत्पाद बनाने का जोखिम होता है जिसकी किसी को आवश्यकता नहीं होती है, बजटीय या कार्मिक प्रतिबद्धताओं को खोना आदि।

Other categories of Risk Management in software engineering in Hindi 

1. ज्ञात जोखिम (Known risks): वे जोखिम जिन्हें परियोजना कार्यक्रम के सावधानीपूर्वक मूल्यांकन के बाद उजागर किया जा सकता है, व्यवसाय और तकनीकी वातावरण जिसमें योजना विकसित की जा रही है, और अधिक विश्वसनीय डेटा स्रोत (जैसे, अवास्तविक वितरण तिथि)

2. पूर्वानुमेय जोखिम (Predictable risks): वे जोखिम जो पिछले परियोजना अनुभव (जैसे, पिछले कारोबार) से परिकल्पित हैं

3. अप्रत्याशित जोखिम (Unpredictable risks): वे जोखिम जो हो सकते हैं और हो सकते हैं, लेकिन पहले से पहचानना बेहद कठिन है।

Principle of Risk Management in software engineering in Hindi

• वैश्विक परिप्रेक्ष्य (Global Perspective): इसमें हम बड़े सिस्टम विवरण, डिजाइन और कार्यान्वयन की समीक्षा करते हैं। हम मौके और जोखिम के प्रभाव को देखते हैं।

• एक दूरंदेशी दृष्टिकोण लें (Take a forward-looking view): भविष्य में आने वाले खतरे पर विचार करें और अगली घटनाओं को निर्देशित करने के लिए भविष्य की योजना बनाएं।

• खुला संचार (Open Communication): यह क्लाइंट और टीम के सदस्यों के बीच संचार के मुक्त प्रवाह की अनुमति देने के लिए है ताकि उन्हें जोखिमों के बारे में निश्चितता हो।

• एकीकृत प्रबंधन (Integrated management): इस पद्धति में जोखिम प्रबंधन को परियोजना प्रबंधन का एक अभिन्न अंग बना दिया जाता है।

• सतत प्रक्रिया (Continuous process): इस चरण में, जोखिम प्रबंधन प्रतिमान में जोखिमों को लगातार ट्रैक किया जाता है।

LOC Metrics

यह कंप्यूटर प्रोग्राम के आकार की गणना के लिए सबसे शुरुआती और सरल मेट्रिक्स में से एक है। यह आमतौर पर प्रोग्रामर की उत्पादकता की गणना और तुलना करने में उपयोग किया जाता है। ये मीट्रिक उत्पाद के आकार को मीट्रिक मानकर गुणवत्ता और उत्पादकता उपायों को सामान्य करके प्राप्त किए जाते हैं।

Important points for size oriented metrics in software engineering in Hindi

एलओसी उपायों के संबंध में निम्नलिखित बिंदु हैं:

• आकार-उन्मुख मेट्रिक्स में, LOC को सामान्यीकरण मान माना जाता है।

• यह एक पुरानी विधि है जिसे विकसित किया गया था जब फोरट्रान और कोबोल प्रोग्रामिंग बहुत लोकप्रिय थे।

• उत्पादकता को KLOC / EFFORT के रूप में परिभाषित किया गया है, जहाँ प्रयास को व्यक्ति-महीनों में मापा जाता है।

• आकार-उन्मुख मीट्रिक उपयोग की जाने वाली प्रोग्रामिंग भाषा पर निर्भर करते हैं।

• चूंकि उत्पादकता केएलओसी पर निर्भर करती है, इसलिए असेंबली भाषा कोड में अधिक उत्पादकता होगी।

• LOC उपाय के लिए एक स्तर के विवरण की आवश्यकता होती है जो व्यावहारिक रूप से प्राप्त करने योग्य नहीं हो सकता है।

• प्रोग्रामिंग भाषा जितनी अधिक अभिव्यंजक होती है, उत्पादकता उतनी ही कम होती है।

• माप की एलओसी पद्धति उन परियोजनाओं पर लागू नहीं होती है जो दृश्य (जीयूआई-आधारित) प्रोग्रामिंग से संबंधित हैं। जैसा कि पहले ही बताया जा चुका है, ग्राफिकल यूजर इंटरफेस (जीयूआई) मूल रूप से फॉर्म का उपयोग करते हैं। एलओसी मीट्रिक यहां लागू नहीं है।

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

• ये मीट्रिक सार्वभौमिक रूप से स्वीकार नहीं किए जाते हैं।

सॉफ्टवेयर की एलओसी/केएलओसी गणना के आधार पर, कई अन्य मेट्रिक्स की गणना की जा सकती है [Based on the LOC/KLOC count of software] :- 

• Errors/KLOC.
• $/ KLOC.
• Defects/KLOC.
• Pages of documentation/KLOC.
• Errors/PM.
• Productivity = KLOC/PM (effort is measured in person-months).
• $/ Page of documentation.

Advantages and disadvantages for size oriented metrics in software engineering in Hindi

Advantages of LOC

मापने में आसान

Disadvantage of LOC

इसे कोड पर परिभाषित किया गया है। उदाहरण के लिए, यह विनिर्देश के आकार को माप नहीं सकता है।

यह आकार के केवल एक विशिष्ट दृश्य की विशेषता है, अर्थात् लंबाई, यह कार्यक्षमता या जटिलता का कोई हिसाब नहीं लेता है

खराब सॉफ़्टवेयर डिज़ाइन कोड की अत्यधिक लाइन का कारण बन सकता है

यह भाषा पर निर्भर है

उपयोगकर्ता इसे आसानी से नहीं समझ सकते हैं

मॉड्यूल का सीधा सा मतलब है सॉफ्टवेयर घटक जो सॉफ्टवेयर को विभाजित करके बनाए जाते हैं। सॉफ्टवेयर को विभिन्न घटकों में विभाजित किया जाता है जो एक एकल कार्यशील वस्तु बनाने के लिए एक साथ काम करते हैं लेकिन कभी-कभी वे एक दूसरे से जुड़े नहीं होने पर एक पूर्ण कार्य के रूप में प्रदर्शन कर सकते हैं। सॉफ्टवेयर मॉड्यूल बनाने की इस प्रक्रिया को Modularity in software engineering के रूप में जाना जाता है।

यह केवल उस डिग्री को मापता है जिससे इन घटकों को जोड़ा जा सकता है। कुछ प्रोजेक्ट या सॉफ़्टवेयर डिज़ाइन बहुत जटिल हैं कि इसके कार्य और कार्यप्रणाली को समझना आसान नहीं है। ऐसे मामलों में, प्रतिरूपकता एक प्रमुख हथियार है जो ऐसे सॉफ़्टवेयर या परियोजनाओं की जटिलता को कम करने में मदद करता है।

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

ये मानदंड मेयर द्वारा परिभाषित किए गए हैं। उनमें से कुछ नीचे दिए गए हैं:

Modularity in software engineering in Hindi

• Modular Decomposability –

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

• Modular Composability –

कंपोज़िबिलिटी का सीधा मतलब है कि बनाए गए मॉड्यूल को संयोजित करने की क्षमता। यह वास्तव में सिस्टम डिज़ाइन का सिद्धांत है जो उस तरीके से संबंधित है जिसमें दो या दो से अधिक घटक एक दूसरे से संबंधित या जुड़े हुए हैं। मॉड्यूलर कंपोज़िबिलिटी का अर्थ है मॉड्यूल को एक नई प्रणाली में इकट्ठा करना जिसका अर्थ है कि घटकों को एक नई प्रणाली में जोड़ना।

• Modular Understandability –

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

• Modular Continuity –

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

• Modular Protection –

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

evolutionary model को क्रमिक संस्करण मॉडल और कभी-कभी  successive versions model के रूप में भी जाना जाता है। evolutionary modelमें, सॉफ़्टवेयर की आवश्यकता को पहले कई मॉड्यूल (या कार्यात्मक इकाइयों) में विभाजित किया जाता है, जिन्हें वृद्धिशील रूप से निर्मित और वितरित किया जा सकता है ।

development पहले सिस्टम के मुख्य मॉड्यूल विकसित करता है। कोर मॉड्यूल वे हैं जिन्हें अन्य मॉड्यूल से सेवाओं की आवश्यकता नहीं है। प्रारंभिक उत्पाद कंकाल को क्रमिक संस्करणों में नई कार्यक्षमताओं को जोड़कर क्षमता के बढ़ते स्तरों में refined किया जाता है। प्रत्येक evolutionary model को developmentके एक  iterative waterfall model का उपयोग करके विकसित किया जा सकता है।

evolutionary model चित्र 6 में दिखाया गया है। उत्पाद का प्रत्येक क्रमिक संस्करण/मॉडल पूरी तरह से कार्य करने वाला सॉफ़्टवेयर है जो पिछले संस्करणों/मॉडल की तुलना में अधिक कार्य करने में सक्षम है।

evolutionary model in software engineering in Hindi

विकासवादी मॉडल आम तौर पर बहुत बड़े उत्पादों के लिए उपयोगी होता है, जहां वृद्धिशील कार्यान्वयन के लिए मॉड्यूल ढूंढना आसान होता है।

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

 Advantages of evolutionary model in software engineering in Hindi

• बड़ी परियोजना: evolutionary model आमतौर पर बहुत बड़े उत्पादों के लिए उपयोगी होता है।

• उपयोगकर्ता को सिस्टम के पूर्ण संस्करण के जारी होने से बहुत पहले आंशिक रूप से विकसित सॉफ़्टवेयर के साथ प्रयोग करने का मौका मिलता है।

• विकासवादी मॉडल सॉफ्टवेयर के विभिन्न संस्करणों के वितरण के दौरान उपयोगकर्ता की आवश्यकताओं को सटीक रूप से प्राप्त करने में मदद करता है।

• कोर मॉड्यूल का पूरी तरह से परीक्षण किया जाता है, जिससे अंतिम उत्पादों के मुख्य मॉड्यूल में त्रुटियों की संभावना कम हो जाती है।

• विकासवादी मॉडल प्रणाली के विकास के लिए एक बार में बड़े संसाधन देने की आवश्यकता से बचा जाता है।

Disadvantages of evolutionary model in software engineering in Hindi

समस्या को कई संस्करणों (several versions) में विभाजित करना मुश्किल है जो ग्राहक को स्वीकार्य होगा और जिसे क्रमिक रूप से कार्यान्वित और वितरित किया जा सकता है।

 स्क्रम एजाइल फ्रेमवर्क का प्रकार है। यह एक ऐसा ढांचा है जिसके भीतर लोग जटिल अनुकूली समस्या का समाधान कर सकते हैं जबकि उत्पाद देने की उत्पादकता और रचनात्मकता उच्चतम संभव मूल्यों पर है। स्क्रम पुनरावृत्त प्रक्रिया का उपयोग करता है।

scrum in software engineering in Hindi

scrum in software engineering in Hindi

features of Scrum in software engineering

• स्क्रम  light-weighted framework है

• स्क्रम  emphasizes self-organization देता है

• स्क्रम को समझना आसान है

• स्क्रम फ्रेमवर्क टीम को एक साथ काम करने में मदद करता है

Lifecycle of Scrum

Check also :- software engineering notes for BCA

• Sprint:

एक स्प्रिंट एक महीने या उससे कम समय का टाइम-बॉक्स है। पिछले स्प्रिंट के पूरा होने के तुरंत बाद एक नया स्प्रिंट शुरू होता है।

• Release:

जब उत्पाद पूरा हो जाता है तो यह रिलीज चरण में जाता है।

• Sprint Review:

यदि उत्पाद में अभी भी कुछ गैर-प्राप्त करने योग्य विशेषताएं हैं तो इस चरण में इसकी जांच की जाएगी और फिर उत्पाद को स्प्रिंट रेट्रोस्पेक्टिव चरण में भेज दिया जाएगा।

• Sprint Retrospective:

इस चरण में उत्पाद की गुणवत्ता या स्थिति की जाँच की जाती है।

• Product Backlog:

प्राथमिकता सुविधाओं के अनुसार उत्पाद को व्यवस्थित किया जाता है।

• Sprint Backlog:

स्प्रिंट बैकलॉग को दो भागों में विभाजित किया गया है स्प्रिंट और स्प्रिंट प्लानिंग मीटिंग के लिए उत्पाद असाइन की गई सुविधाएँ।

Advantage of scrum in software engineering in Hindi

• स्क्रम ढांचा तेजी से आगे बढ़ रहा है और पैसा कुशल है।

• स्क्रम फ्रेमवर्क बड़े उत्पाद को छोटे उप-उत्पादों में विभाजित करके काम करता है। यह फूट डालो और जीतो की रणनीति की तरह है

• स्क्रम में ग्राहकों की संतुष्टि बहुत महत्वपूर्ण है।

• स्क्रम प्रकृति में अनुकूली है क्योंकि इसमें लघु स्प्रिंट है।

• चूंकि स्क्रम फ्रेमवर्क निरंतर प्रतिक्रिया पर निर्भर करता है इसलिए उत्पाद की गुणवत्ता कम समय में बढ़ जाती है

Disadvantage of scrum in software engineering in Hindi

• स्क्रम फ्रेमवर्क उनके स्प्रिंट में परिवर्तन की अनुमति नहीं देता है।

• स्क्रम फ्रेमवर्क पूरी तरह से वर्णित मॉडल नहीं है। यदि आप इसे अपनाना चाहते हैं तो आपको अपने स्वयं के विवरण जैसे एक्सट्रीम प्रोग्रामिंग (एक्सपी), कानबन, डीएसडीएम के साथ ढांचे को भरना होगा।

• स्क्रम के लिए ऐसी परियोजना की योजना बनाना, संरचना करना और व्यवस्थित करना मुश्किल हो सकता है जिसमें स्पष्ट परिभाषा का अभाव हो।

• दैनिक स्क्रम मीटिंग और लगातार समीक्षा के लिए पर्याप्त संसाधनों की आवश्यकता होती है।

 एक अच्छा SRS बनाने के लिए, यहाँ आपको कुछ बिंदु दिखाई देंगे जिनका उपयोग किया जा सकता है और जिन्हें अच्छे SRS की संरचना बनाने के लिए माना जाना चाहिए। ये इस प्रकार हैं:

srs in software engineering in hindi

Check also :- cocomo model in software engineering in Hindi 

SRS in software engineering in Hindi

1 परिचय

(i) इस दस्तावेज़ का उद्देश्य (Purpose of this document)

(ii) इस दस्तावेज़ का दायरा (Scope of this document)

(iii) सिंहावलोकन ( Overview)

2. सामान्य विवरण (General description)

3. कार्यात्मक आवश्यकताएँ (Functional Requirements)

4. इंटरफ़ेस आवश्यकताएँ ( Interface Requirements)

5. प्रदर्शन आवश्यकताएँ ( Performance Requirements)

6. डिजाइन की बाधाएं ( Design Constraints)

7. गैर-कार्यात्मक गुण (Non-Functional Attributes)

8. प्रारंभिक अनुसूची और बजट (Preliminary Schedule and Budget)

9. परिशिष्ट (Appendices)

components of srs in software engineering in Hindi

Software Requirement Specification (SRS) Format जैसा कि नाम से पता चलता है, सॉफ्टवेयर सिस्टम के सफल विकास के लिए सॉफ्टवेयर की आवश्यकताओं का पूरा विनिर्देश और विवरण है जिसे पूरा करने की आवश्यकता है। आवश्यकता के प्रकार के आधार पर ये आवश्यकताएं कार्यात्मक होने के साथ-साथ गैर-आवश्यकताएं भी हो सकती हैं। विभिन्न ग्राहकों और ठेकेदार के बीच बातचीत इसलिए की जाती है क्योंकि ग्राहकों की जरूरतों को पूरी तरह से समझना आवश्यक है।

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

• परिचय :

(i) Purpose of this Document –

सबसे पहले, इस दस्तावेज़ की आवश्यकता क्यों है और दस्तावेज़ का उद्देश्य क्या है इसका मुख्य उद्देश्य समझाया और वर्णित किया गया है।

(ii)  Scope of this document –

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

(iii) Overview –

इसमें उत्पाद का विवरण समझाया गया है। यह केवल उत्पाद का सारांश या समग्र समीक्षा है।

• General description 

इसमें उत्पाद के सामान्य कार्य जिसमें उपयोगकर्ता का उद्देश्य, उपयोगकर्ता की विशेषता, सुविधाएँ, लाभ शामिल हैं, इसके महत्व का उल्लेख क्यों किया गया है। यह उपयोगकर्ता समुदाय की विशेषताओं का भी वर्णन करता है।

• Functional Requirements :

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

• Interface Requirements :

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

• Performance Requirements :

इसमें सॉफ्टवेयर सिस्टम विशिष्ट परिस्थितियों में वांछित कार्य कैसे करता है, इसके बारे में बताया गया है। यह आवश्यक समय, आवश्यक स्मृति, अधिकतम त्रुटि दर आदि की भी व्याख्या करता है।

• Design Constraints :

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

• Non-Functional Attributes :

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

• Preliminary Schedule and Budget :

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

• Appendices :

इसमें अतिरिक्त जानकारी जैसे संदर्भ जहाँ से जानकारी एकत्र की जाती है, कुछ विशिष्ट शब्दों की परिभाषाएँ, संक्षिप्तीकरण, संक्षिप्तीकरण आदि दिए जाते हैं और समझाए जाते हैं।

 इस पृष्ठ पर हमारे सभी उपयोगकर्ता जो अपने बीसीए का पीछा कर रहे हैं, वे उपयोगकर्ता  software engineering notes for BCAअच्छी तरह से पा सकते हैं, हम सॉफ्टवेयर इंजीनियरिंग के सभी विषयों को हिंदी में कवर करने का प्रयास करते हैं ताकि वे छात्र जो अंग्रेजी अच्छी तरह से बोल और पढ़ नहीं सकते हैं, वे यहां से सॉफ्टवेयर इंजीनियरिंग सीख सकते हैं।

छात्र अपनी परीक्षा की तैयारी के लिए software engineering notes in Hindiभी डाउनलोड कर सकते हैं

software engineering notes for BCA

• introduction to software engineering in Hindi

          SDLC in software engineering in Hindi

• waterfall model in Hindi
• Spiral Model 
• iterative model 
• cocomo model
• rad model