GKPAD.COM

ONLINE HINDI EDUCATION PORTAL

IGNOU BCS-051 Solved Question Paper PDF Download

The IGNOU BCS-051 Solved Question Paper PDF Download page is designed to help students access high-quality exam resources in one place. Here, you can find ignou solved question paper IGNOU Previous Year Question paper solved PDF that covers all important questions with detailed answers. This page provides IGNOU all Previous year Question Papers in one PDF format, making it easier for students to prepare effectively.

Whether you are looking for IGNOU Previous Year Question paper solved in English or ignou previous year question paper solved in hindi, this page offers both options to suit your learning needs. These solved papers help you understand exam patterns, improve answer writing skills, and boost confidence for upcoming exams.

IGNOU BCS-051 Solved Question Paper PDF

IGNOU Previous Year Solved Question Papers

This section provides IGNOU BCS-051 Solved Question Paper PDF in both Hindi and English. These ignou solved question paper IGNOU Previous Year Question paper solved PDF include detailed answers to help you understand exam patterns and improve your preparation. You can also access IGNOU all Previous year Question Papers in one PDF for quick and effective revision before exams.

IGNOU BCS-051 Previous Year Solved Question Paper in Hindi

Q1. (a) एक विश्वविद्यालय के लिए ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली के लिए SRS विकसित करें। SRS के लिए IEEE प्रारूप का उपयोग करें। आवश्यक धारणाएं बनाएं। (20)

Ans.

सॉफ्टवेयर रिक्वायरमेंट स्पेसिफिकेशन (SRS) – ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली

संस्करण 1.0

1. परिचय (Introduction) 1.1 उद्देश्य (Purpose) इस दस्तावेज़ का उद्देश्य एक विश्वविद्यालय के लिए ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली (Online Assignment Submission and Evaluation System) के लिए कार्यात्मक (functional) और गैर-कार्यात्मक (non-functional) आवश्यकताओं को परिभाषित करना है। यह प्रणाली छात्रों को ऑनलाइन असाइनमेंट जमा करने और संकाय (faculty) को उनका मूल्यांकन करने और ग्रेड देने की प्रक्रिया को स्वचालित और सुव्यवस्थित करेगी।

1.2 कार्यक्षेत्र (Scope) यह प्रणाली छात्रों, संकाय सदस्यों और प्रशासकों के लिए एक वेब-आधारित इंटरफ़ेस प्रदान करेगी। इसमें निम्नलिखित शामिल होंगे:

  • उपयोगकर्ता पंजीकरण और प्रमाणीकरण।
  • संकाय द्वारा असाइनमेंट बनाना और अपलोड करना।
  • छात्रों द्वारा असाइनमेंट डाउनलोड करना और समाधान अपलोड करना।
  • समय सीमा (due date) का प्रबंधन।
  • संकाय द्वारा ऑनलाइन मूल्यांकन और फीडबैक।
  • ग्रेड का स्वचालित प्रकाशन।
  • सूचनाएं (Notifications) और रिपोर्ट तैयार करना।

1.3 परिभाषाएं, परिवर्णी शब्द और संक्षिप्ताक्षर (Definitions, Acronyms, and Abbreviations)

  • SRS: सॉफ्टवेयर रिक्वायरमेंट स्पेसिफिकेशन
  • OASES: ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली
  • व्यवस्थापक (Admin): सिस्टम का प्रबंधन करने वाला उपयोगकर्ता।
  • संकाय (Faculty): पाठ्यक्रम प्रशिक्षक जो असाइनमेंट बनाते और ग्रेड देते हैं।
  • छात्र (Student): पाठ्यक्रम में नामांकित उपयोगकर्ता जो असाइनमेंट जमा करते हैं।

2. समग्र विवरण (Overall Description) 2.1 उत्पाद परिप्रेक्ष्य (Product Perspective) OASES एक स्टैंड-अलोन प्रणाली होगी जिसे विश्वविद्यालय के मौजूदा छात्र सूचना प्रणाली (Student Information System) के साथ एकीकृत किया जा सकता है ताकि उपयोगकर्ता डेटा को सिंक किया जा सके। यह एक वेब-आधारित एप्लिकेशन होगा जो किसी भी मानक वेब ब्राउज़र से पहुंच योग्य होगा।

2.2 उत्पाद कार्य (Product Functions) प्रणाली के मुख्य कार्य हैं:

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

2.3 उपयोगकर्ता विशेषताएँ (User Characteristics)

  • छात्र: कंप्यूटर और वेब ब्राउज़र का बुनियादी ज्ञान।
  • संकाय: छात्रों के समान, साथ ही फ़ाइल अपलोडिंग और टेक्स्ट एडिटिंग का अनुभव।
  • व्यवस्थापक: तकनीकी रूप से कुशल और सिस्टम प्रबंधन में अनुभवी।

2.4 धारणाएं और निर्भरताएँ (Assumptions and Dependencies)

  • उपयोगकर्ताओं के पास इंटरनेट कनेक्शन और एक संगत वेब ब्राउज़र होगा।
  • सिस्टम को एक सुरक्षित सर्वर पर होस्ट किया जाएगा।
  • उपयोगकर्ता डेटा (नाम, रोल नंबर, पाठ्यक्रम) विश्वविद्यालय के डेटाबेस से उपलब्ध होगा।

3. विशिष्ट आवश्यकताएँ (Specific Requirements) 3.1 कार्यात्मक आवश्यकताएँ (Functional Requirements) FR1: उपयोगकर्ता प्रमाणीकरण

  • सिस्टम को सभी उपयोगकर्ताओं (छात्र, संकाय, व्यवस्थापक) को एक अद्वितीय आईडी और पासवर्ड के माध्यम से प्रमाणित करना होगा।
  • एक “पासवर्ड भूल गए” सुविधा होनी चाहिए।

FR2: असाइनमेंट निर्माण

  • संकाय सदस्यों को शीर्षक, विवरण, अधिकतम अंक और समय सीमा के साथ नए असाइनमेंट बनाने में सक्षम होना चाहिए।
  • वे असाइनमेंट से संबंधित फाइलें (जैसे, प्रश्न पत्र) संलग्न कर सकते हैं।

FR3: असाइनमेंट सबमिशन

  • छात्रों को अपने डैशबोर्ड पर सभी सक्रिय असाइनमेंट देखने में सक्षम होना चाहिए।
  • छात्रों को समय सीमा से पहले अपने समाधान (जैसे, .pdf, .docx फ़ाइलें) अपलोड करने में सक्षम होना चाहिए।
  • देर से सबमिशन को सिस्टम द्वारा चिह्नित किया जाना चाहिए।

FR4: असाइनमेंट मूल्यांकन

  • संकाय को जमा किए गए असाइनमेंट को ऑनलाइन देखने/डाउनलोड करने में सक्षम होना चाहिए।
  • संकाय को प्रत्येक सबमिशन के लिए अंक देने और टेक्स्ट-आधारित फीडबैक प्रदान करने के लिए एक इंटरफ़ेस होना चाहिए।

3.2 गैर-कार्यात्मक आवश्यकताएँ (Non-Functional Requirements)

  • प्रदर्शन (Performance): पेज लोड समय 3 सेकंड से कम होना चाहिए। सिस्टम को एक ही समय में 500 उपयोगकर्ताओं को संभालने में सक्षम होना चाहिए।
  • सुरक्षा (Security): सभी डेटा ट्रांसमिशन को SSL/TLS का उपयोग करके एन्क्रिप्ट किया जाना चाहिए। SQL इंजेक्शन और क्रॉस-साइट स्क्रिप्टिंग जैसे सामान्य हमलों के खिलाफ सिस्टम को सुरक्षित किया जाना चाहिए।
  • उपयोगिता (Usability): इंटरफ़ेस सहज और उपयोगकर्ता के अनुकूल होना चाहिए, जिसके लिए न्यूनतम प्रशिक्षण की आवश्यकता हो।
  • विश्वसनीयता (Reliability): सिस्टम 99.5% समय उपलब्ध होना चाहिए।

3.3 बाहरी इंटरफ़ेस आवश्यकताएँ (External Interface Requirements)

  • सॉफ़्टवेयर इंटरफ़ेस: सिस्टम विश्वविद्यालय के छात्र सूचना प्रणाली (SIS) के साथ छात्र और पाठ्यक्रम डेटा को सिंक करने के लिए एक API प्रदान कर सकता है।
  • हार्डवेयर इंटरफ़ेस: कोई विशेष हार्डवेयर इंटरफ़ेस आवश्यक नहीं है।
  • संचार इंटरफ़ेस: सिस्टम HTTP/HTTPS प्रोटोकॉल पर संचार करेगा।

(b) ऑब्जेक्ट क्या है? एक उदाहरण के साथ एप्लिकेशन लॉजिक ऑब्जेक्ट की व्याख्या करें। स्टैटिक ऑब्जेक्ट के विनिर्देशों की भी व्याख्या करें। (10)

Ans.

ऑब्जेक्ट (Object):

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (OOP) में, एक ऑब्जेक्ट एक मौलिक इकाई है जो वास्तविक दुनिया की किसी वस्तु का प्रतिनिधित्व करती है। यह दो मुख्य विशेषताओं का एक संयोजन है:

  • स्टेट (State): इसे विशेषताओं (attributes) या गुणों (properties) द्वारा दर्शाया जाता है। यह ऑब्जेक्ट के डेटा को संग्रहीत करता है। उदाहरण के लिए, एक ‘Car’ ऑब्जेक्ट का स्टेट ‘color’, ‘model’ और ‘speed’ हो सकता है।
  • बिहेवियर (Behavior): इसे विधियों (methods) या कार्यों (functions) द्वारा दर्शाया जाता है। यह परिभाषित करता है कि ऑब्जेक्ट क्या कर सकता है और उसके डेटा पर कैसे काम कर सकता है। उदाहरण के लिए, एक ‘Car’ ऑब्जेक्ट का बिहेवियर ‘startEngine()’, ‘accelerate()’ और ‘brake()’ हो सकता है।

संक्षेप में, एक ऑब्जेक्ट एक क्लास का एक उदाहरण (instance) है, जहाँ क्लास एक ब्लूप्रिंट है जो ऑब्जेक्ट की संरचना और व्यवहार को परिभाषित करता है। एप्लिकेशन लॉजिक ऑब्जेक्ट (Application Logic Object):

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

एक “ऑनलाइन बैंकिंग सिस्टम” पर विचार करें। इसमें एक `Account` ऑब्जेक्ट एक एप्लिकेशन लॉजिक ऑब्जेक्ट हो सकता है।

  • स्टेट: `accountNumber`, `accountHolderName`, `balance`।
  • बिहेवियर: `deposit(amount)`, `withdraw(amount)`, `checkBalance()`।

यहाँ, `withdraw(amount)` विधि में व्यावसायिक तर्क शामिल होगा, जैसे कि यह जांचना कि क्या खाते में पर्याप्त शेष राशि है (`balance >= amount`) और क्या निकासी सीमा पार नहीं हुई है। यह तर्क UI या डेटाबेस से स्वतंत्र है, जिससे कोड अधिक मॉड्यूलर और रखरखाव योग्य (maintainable) हो जाता है। स्टैटिक ऑब्जेक्ट के विनिर्देश (Specifications of Static Object):

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

  1. एकल प्रति (Single Copy): एक स्टैटिक सदस्य की केवल एक प्रति होती है, चाहे क्लास के कितने भी ऑब्जेक्ट बनाए जाएं। यह सभी ऑब्जेक्ट्स के बीच साझा किया जाता है। उदाहरण के लिए, यदि किसी `Student` क्लास में एक स्टैटिक वेरिएबल `totalStudents` है, तो यह सभी `Student` ऑब्जेक्ट्स के लिए समान होगा।
  2. क्लास-लेवल एक्सेस (Class-Level Access): स्टैटिक सदस्यों को क्लास के नाम का उपयोग करके सीधे एक्सेस किया जा सकता है, बिना कोई ऑब्जेक्ट बनाए। उदाहरण के लिए, `Student.totalStudents`।
  3. मेमोरी आवंटन (Memory Allocation): स्टैटिक सदस्यों के लिए मेमोरी तब आवंटित की जाती है जब प्रोग्राम शुरू होता है (या जब क्लास लोड होती है), और यह प्रोग्राम के अंत तक बनी रहती है। यह ऑब्जेक्ट्स की तरह हीप (heap) पर नहीं, बल्कि एक अलग मेमोरी क्षेत्र में संग्रहीत होती है।
  4. उपयोग: स्टैटिक सदस्यों का उपयोग आमतौर पर उन गुणों या विधियों के लिए किया जाता है जो सभी उदाहरणों के लिए सामान्य होते हैं, जैसे काउंटर (जैसे, बनाए गए ऑब्जेक्ट्स की संख्या गिनना), स्थिरांक (constants), या यूटिलिटी फ़ंक्शंस।

(c) स्ट्रक्चर्ड एनालिसिस क्या है? व्याख्या करें। (5)

Ans.

स्ट्रक्चर्ड एनालिसिस (Structured Analysis) एक सॉफ्टवेयर डेवलपमेंट तकनीक है जिसका उपयोग सॉफ्टवेयर आवश्यकताओं को समझने और परिभाषित करने के लिए किया जाता है। यह एक टॉप-डाउन दृष्टिकोण का अनुसरण करता है, जिसका अर्थ है कि यह एक जटिल प्रणाली को छोटे, अधिक प्रबंधनीय भागों में विघटित (decompose) करता है। इसका मुख्य ध्यान प्रणाली के माध्यम से डेटा के प्रवाह (flow of data) और डेटा पर किए जाने वाले परिवर्तनों (transformations) पर होता है।

स्ट्रक्चर्ड एनालिसिस का लक्ष्य एक स्पष्ट, सटीक और आसानी से समझने योग्य मॉडल बनाना है कि सिस्टम को क्या करना चाहिए, इससे पहले कि यह कैसे किया जाएगा (डिजाइन चरण) पर विचार किया जाए। यह “क्या” (what) पर ध्यान केंद्रित करता है, न कि “कैसे” (how) पर। स्ट्रक्चर्ड एनालिसिस की मुख्य विशेषताएं और उपकरण:

  • ग्राफिकल निरूपण (Graphical Representation): यह सिस्टम को मॉडल करने के लिए ग्राफिकल टूल का भारी उपयोग करता है। यह पाठ्य विवरणों पर निर्भरता को कम करता है, जिससे गलतफहमी की संभावना कम हो जाती है।
  • डेटा फ्लो डायग्राम (Data Flow Diagram – DFD): यह स्ट्रक्चर्ड एनालिसिस का सबसे महत्वपूर्ण उपकरण है। DFD दिखाता है कि डेटा सिस्टम में कैसे प्रवेश करता है, सिस्टम के भीतर कैसे प्रवाहित होता है, कहाँ संग्रहीत होता है, और सिस्टम से कैसे बाहर निकलता है।
  • डेटा डिक्शनरी (Data Dictionary): यह एक भंडार (repository) है जो DFD में उपयोग किए गए सभी डेटा आइटम, डेटा स्टोर और डेटा फ्लो का विस्तृत विवरण संग्रहीत करता है। यह डेटा के लिए मेटाडेटा प्रदान करता है।
  • प्रोसेस स्पेसिफिकेशन (Process Specification): इन्हें “मिनी-स्पेक्स” भी कहा जाता है। ये DFD में सबसे निचले स्तर की प्रक्रियाओं (processes) के तर्क का वर्णन करते हैं। इन्हें स्ट्रक्चर्ड इंग्लिश, डिसीजन ट्री या डिसीजन टेबल का उपयोग करके लिखा जा सकता है।
  • टॉप-डाउन दृष्टिकोण (Top-Down Approach): विश्लेषण एक उच्च-स्तरीय, सारगर्भित दृष्टिकोण (संदर्भ आरेख या लेवल 0 DFD) से शुरू होता है और फिर धीरे-धीरे अधिक विस्तृत स्तरों में विघटित होता है।

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

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

मुख्य सॉफ्टवेयर टेस्टिंग सिद्धांत निम्नलिखित हैं:

  1. टेस्टिंग दोषों की उपस्थिति दर्शाती है, अनुपस्थिति नहीं (Testing shows presence of defects, not absence): टेस्टिंग यह साबित कर सकती है कि सॉफ्टवेयर में दोष हैं, लेकिन यह कभी साबित नहीं कर सकती कि इसमें कोई दोष नहीं है। यदि टेस्टिंग के दौरान कोई दोष नहीं मिलता है, तो इसका मतलब यह नहीं है कि सॉफ्टवेयर 100% बग-मुक्त है।
  2. संपूर्ण टेस्टिंग असंभव है (Exhaustive testing is impossible): एक गैर-तुच्छ (non-trivial) सॉफ्टवेयर के लिए सभी संभव इनपुट, संयोजन और पथों का परीक्षण करना संभव नहीं है। इसके बजाय, हमें जोखिम विश्लेषण और प्राथमिकताओं के आधार पर अपने टेस्टिंग प्रयासों पर ध्यान केंद्रित करना चाहिए।
  3. प्रारंभिक टेस्टिंग (Early testing): टेस्टिंग को सॉफ्टवेयर विकास जीवनचक्र (SDLC) में जितनी जल्दी हो सके शुरू कर देना चाहिए। आवश्यकताओं और डिजाइन चरणों में दोषों को ढूंढना और ठीक करना कोडिंग के बाद उन्हें ठीक करने की तुलना में बहुत सस्ता होता है।
  4. दोष क्लस्टरिंग (Defect clustering): यह सिद्धांत बताता है कि अधिकांश दोष सॉफ्टवेयर के कुछ ही मॉड्यूलों में केंद्रित होते हैं। पारेतो सिद्धांत (80/20 नियम) यहाँ लागू होता है: लगभग 80% समस्याएँ 20% मॉड्यूलों के कारण होती हैं। यह परीक्षकों को अपने प्रयासों को इन संभावित समस्याग्रस्त क्षेत्रों पर केंद्रित करने में मदद करता है।
  5. कीटनाशक विरोधाभास (Pesticide paradox): यदि आप बार-बार एक ही सेट के टेस्ट केस चलाते हैं, तो वे अंततः नए दोषों को खोजने में अप्रभावी हो जाएंगे। जैसे कीटनाशक कीड़ों के लिए अपनी प्रभावशीलता खो देते हैं, वैसे ही टेस्ट केसों को भी नए दोषों को उजागर करने के लिए नियमित रूप से समीक्षा और संशोधित करने की आवश्यकता होती है।
  6. टेस्टिंग संदर्भ-निर्भर है (Testing is context-dependent): टेस्टिंग करने का तरीका विकसित किए जा रहे सॉफ्टवेयर के प्रकार और संदर्भ पर निर्भर करता है। एक ई-कॉमर्स साइट की टेस्टिंग एक विमानन नियंत्रण प्रणाली की टेस्टिंग से बहुत अलग होती है।
  7. त्रुटि-मुक्ति की भ्रांति (Absence-of-errors fallacy): यदि बनाया गया सिस्टम अनुपयोगी है और उपयोगकर्ता की जरूरतों और अपेक्षाओं को पूरा नहीं करता है, तो दोषों को ढूंढना और ठीक करना कोई मायने नहीं रखता। 99% बग-मुक्त होना बेकार है अगर सिस्टम गलत आवश्यकताओं के लिए बनाया गया है।

Q2. (a) एक उपयुक्त आरेख की सहायता से वॉटरफॉल मॉडल की व्याख्या करें। इस मॉडल के फायदे और नुकसान सूचीबद्ध करें। (10)

Ans.

वॉटरफॉल मॉडल (Waterfall Model) सॉफ्टवेयर विकास जीवनचक्र (SDLC) का सबसे पुराना और सबसे सीधा मॉडल है। इसे एक रैखिक-अनुक्रमिक (linear-sequential) जीवनचक्र मॉडल के रूप में भी जाना जाता है। इस मॉडल में, विकास प्रक्रिया को विभिन्न चरणों में विभाजित किया जाता है, और प्रत्येक चरण को अगले चरण पर जाने से पहले पूरी तरह से पूरा किया जाना चाहिए। यह एक झरने (waterfall) की तरह नीचे की ओर बहता है, जिसमें एक चरण का आउटपुट अगले चरण के लिए इनपुट बन जाता है।

वॉटरफॉल मॉडल के चरण: वॉटरफॉल मॉडल में निम्नलिखित चरण शामिल हैं, जो एक सख्त अनुक्रम में निष्पादित होते हैं:

1. आवश्यकता विश्लेषण और परिभाषा (Requirement Analysis and Definition): इस चरण में, सिस्टम की सभी संभावित आवश्यकताओं को एकत्र, समझा और प्रलेखित किया जाता है। एक सॉफ्टवेयर रिक्वायरमेंट स्पेसिफिकेशन (SRS) दस्तावेज़ बनाया जाता है। 2. सिस्टम और सॉफ्टवेयर डिजाइन (System and Software Design): SRS के आधार पर, सिस्टम डिजाइन तैयार किया जाता है। यह चरण हार्डवेयर और सिस्टम आवश्यकताओं को निर्दिष्ट करता है और समग्र सिस्टम आर्किटेक्चर को परिभाषित करने में मदद करता है। 3. कार्यान्वयन और यूनिट टेस्टिंग (Implementation and Unit Testing): सिस्टम डिजाइन को छोटे प्रोग्रामों में विभाजित किया जाता है जिन्हें “यूनिट” कहा जाता है। प्रत्येक यूनिट को व्यक्तिगत रूप से विकसित और कोड किया जाता है, और फिर इसकी कार्यक्षमता के लिए परीक्षण किया जाता है (यूनिट टेस्टिंग)। 4. एकीकरण और सिस्टम टेस्टिंग (Integration and System Testing): इस चरण में, सभी विकसित इकाइयों को एक पूर्ण सिस्टम में एकीकृत किया जाता है। फिर पूरे सिस्टम का परीक्षण यह सुनिश्चित करने के लिए किया जाता है कि यह सभी आवश्यकताओं को पूरा करता है। 5. संचालन और रखरखाव (Operation and Maintenance): एक बार जब सिस्टम का सफलतापूर्वक परीक्षण कर लिया जाता है, तो उसे ग्राहक के वातावरण में तैनात (deploy) कर दिया जाता है। रखरखाव चरण में बग्स को ठीक करना, सिस्टम को अपग्रेड करना और नई सुविधाओं को जोड़ना शामिल है।

आरेख (Diagram):

(आवश्यकताएँ) → (डिजाइन) → (कार्यान्वयन) → (टेस्टिंग) → (तैनाती) → (रखरखाव)

[एक आरेख जिसमें तीर ऊपर से नीचे की ओर चरणों के माध्यम से एक रैखिक प्रवाह दिखाते हैं, यहाँ दर्शाया जाना चाहिए।] वॉटरफॉल मॉडल

[ आवश्यकता विश्लेषण ] ↓ [ सिस्टम डिजाइन ] ↓ [ कार्यान्वयन ] ↓ [ टेस्टिंग ] ↓ [ तैनाती ] ↓ [ रखरखाव ] वॉटरफॉल मॉडल के लाभ (Advantages):

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

वॉटरफॉल मॉडल के नुकसान (Disadvantages):

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

(b) एक ऑनलाइन परीक्षा प्रणाली के लिए एक नमूना गैंट चार्ट बनाएं। आवश्यक धारणाएं बनाएं। (10)

Ans.

गैंट चार्ट (Gantt Chart) एक प्रकार का बार चार्ट है जो एक प्रोजेक्ट शेड्यूल को दिखाता है। यह प्रोजेक्ट प्रबंधन में एक बहुत ही उपयोगी उपकरण है। यह प्रोजेक्ट के कार्यों (tasks) को ऊर्ध्वाधर अक्ष (vertical axis) पर और समय अंतराल को क्षैतिज अक्ष (horizontal axis) पर सूचीबद्ध करता है। प्रत्येक कार्य की अवधि को एक क्षैतिज पट्टी द्वारा दर्शाया जाता है, जिसकी स्थिति और लंबाई कार्य की शुरुआत की तारीख, अंत की तारीख और अवधि का प्रतिनिधित्व करती है।

ऑनलाइन परीक्षा प्रणाली के लिए धारणाएं:

  • प्रोजेक्ट की कुल अवधि लगभग 14 सप्ताह है।
  • टीम में एक प्रोजेक्ट मैनेजर, दो डेवलपर और एक टेस्टर शामिल हैं।
  • कुछ कार्य समानांतर में किए जा सकते हैं, जबकि अन्य अनुक्रमिक हैं।
  • प्रत्येक सप्ताह 5 कार्य दिवसों का होता है।

ऑनलाइन परीक्षा प्रणाली के लिए नमूना गैंट चार्ट: नीचे एक ऑनलाइन परीक्षा प्रणाली परियोजना के लिए एक सरलीकृत गैंट चार्ट का प्रतिनिधित्व है। ‘X’ एक सप्ताह की अवधि का प्रतिनिधित्व करता है।

कार्य (Task)

निर्भरता (Dependency)

सप्ताह 1-2

सप्ताह 3-4

सप्ताह 5-6

सप्ताह 7-8

सप्ताह 9-10

सप्ताह 11-12

सप्ताह 13-14

1. आवश्यकता विश्लेषण

—

XX

2. सिस्टम डिजाइन और आर्किटेक्चर

1

XX

3. डेटाबेस डिजाइन

2

X

4. मॉड्यूल विकास: उपयोगकर्ता प्रबंधन

3

X

X

5. मॉड्यूल विकास: प्रश्न बैंक प्रबंधन

3

XX

X

6. मॉड्यूल विकास: परीक्षा संचालन

3

XX

X

7. मॉड्यूल एकीकरण

4, 5, 6

X

8. सिस्टम टेस्टिंग

7

XX

X

9. उपयोगकर्ता स्वीकृति परीक्षण (UAT)

8

X

10. तैनाती और गो-लाइव

9

X

चार्ट का स्पष्टीकरण:

  • कार्य (Task): परियोजना को छोटे, प्रबंधनीय कार्यों में तोड़ा गया है।
  • निर्भरता (Dependency): यह दर्शाता है कि किसी कार्य को शुरू करने से पहले कौन सा कार्य पूरा होना चाहिए। उदाहरण के लिए, ‘सिस्टम डिजाइन’ (कार्य 2) ‘आवश्यकता विश्लेषण’ (कार्य 1) के पूरा होने के बाद ही शुरू हो सकता है।
  • समयरेखा (Timeline): चार्ट सप्ताहों में समयरेखा दिखाता है। रंगीन पट्टियाँ (colored bars) प्रत्येक कार्य की अनुमानित शुरुआत और अंत का प्रतिनिधित्व करती हैं।
  • मील के पत्थर (Milestones): ‘तैनाती और गो-लाइव’ (Deployment and Go-Live) जैसी घटनाओं को मील के पत्थर के रूप में माना जा सकता है, जो परियोजना के एक प्रमुख चरण के अंत का प्रतीक है।

यह गैंट चार्ट परियोजना की प्रगति को ट्रैक करने, संसाधनों का प्रबंधन करने और सभी हितधारकों को परियोजना की स्थिति के बारे में सूचित रखने में मदद करता है।

Q3. (a) सिस्टम टेस्टिंग और रिग्रेशन टेस्टिंग की व्याख्या करें। (10)

Ans.

सिस्टम टेस्टिंग (System Testing):

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

सिस्टम टेस्टिंग का फोकस सॉफ्टवेयर के कार्यात्मक (functional) और गैर-कार्यात्मक (non-functional) दोनों पहलुओं पर होता है। यह एंड-यूज़र के दृष्टिकोण से किया जाता है ताकि यह सुनिश्चित हो सके कि सिस्टम वास्तविक दुनिया के परिदृश्यों में अपेक्षा के अनुरूप व्यवहार करता है। सिस्टम टेस्टिंग के प्रमुख पहलू:

  • उद्देश्य: यह सत्यापित करना कि सिस्टम समग्र रूप से व्यावसायिक और तकनीकी आवश्यकताओं को पूरा करता है।
  • कब किया जाता है: यूनिट टेस्टिंग और इंटीग्रेशन टेस्टिंग के बाद, लेकिन उपयोगकर्ता स्वीकृति परीक्षण (User Acceptance Testing – UAT) से पहले।
  • कौन करता है: यह आमतौर पर एक स्वतंत्र टेस्टिंग टीम द्वारा किया जाता है, न कि डेवलपर्स द्वारा, ताकि एक निष्पक्ष मूल्यांकन सुनिश्चित हो सके।
  • परीक्षण का दायरा: इसमें प्रदर्शन (performance), सुरक्षा (security), प्रयोज्यता (usability), विश्वसनीयता (reliability), और रिकवरी (recovery) जैसे विभिन्न प्रकार के परीक्षण शामिल हो सकते हैं।
  • उदाहरण: एक ई-कॉमर्स वेबसाइट के लिए, सिस्टम टेस्टिंग में एक उत्पाद खोजने, उसे कार्ट में जोड़ने, चेकआउट करने, भुगतान करने और ऑर्डर की पुष्टि प्राप्त करने की पूरी प्रक्रिया का परीक्षण करना शामिल होगा।

रिग्रेशन टेस्टिंग (Regression Testing):

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

  • उद्देश्य: यह सत्यापित करना कि मौजूदा कार्यक्षमता कोड परिवर्तनों के बाद भी सही ढंग से काम कर रही है।
  • कब किया जाता है: हर बार जब कोई नया मॉड्यूल जोड़ा जाता है, कोई मौजूदा मॉड्यूल संशोधित किया जाता है, या कोई बग ठीक किया जाता है।
  • परीक्षण का दायरा: इसमें संपूर्ण मौजूदा टेस्ट सूट को फिर से चलाना या प्रभावित क्षेत्रों को लक्षित करने वाले टेस्ट केस का एक सबसेट चुनना शामिल हो सकता है।
  • तकनीक: तकनीकों में “सब कुछ फिर से परीक्षण करें” (Retest All), “चयनित परीक्षण” (Selective Testing), और “प्राथमिकता वाले परीक्षण” (Prioritized Testing) शामिल हैं।
  • उदाहरण: यदि एक बैंकिंग एप्लिकेशन में ‘फंड ट्रांसफर’ सुविधा को संशोधित किया जाता है, तो रिग्रेशन टेस्टिंग यह सुनिश्चित करेगी कि ‘बैलेंस चेक’, ‘खाता विवरण’ और ‘बिल भुगतान’ जैसी अन्य मौजूदा सुविधाएँ अभी भी ठीक से काम कर रही हैं।

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

Ans.

सॉफ्टवेयर मेंटेनेंस की आवश्यकता (Need for Software Maintenance): सॉफ्टवेयर मेंटेनेंस एक बार सॉफ्टवेयर उत्पाद को ग्राहक को सौंपने के बाद उसमें किए जाने वाले संशोधनों और अपडेट की प्रक्रिया है। यह सॉफ्टवेयर विकास जीवनचक्र (SDLC) का एक अभिन्न और महत्वपूर्ण हिस्सा है, जो अक्सर कुल लागत का 50% से 75% तक होता है। सॉफ्टवेयर मेंटेनेंस की आवश्यकता कई कारणों से उत्पन्न होती है:

  1. त्रुटियों को ठीक करना (Correcting Faults): कोई भी सॉफ्टवेयर पूरी तरह से बग-मुक्त नहीं होता है। विकास के दौरान अनदेखे रह गए दोष या त्रुटियाँ उत्पादन (production) में सामने आ सकती हैं, जिन्हें ठीक करने की आवश्यकता होती है।
  2. बदलते परिवेश के अनुकूल होना (Adapting to a Changing Environment): सॉफ्टवेयर एक गतिशील वातावरण में काम करता है। ऑपरेटिंग सिस्टम, हार्डवेयर, सरकारी नियमों या व्यावसायिक नीतियों में परिवर्तन के लिए सॉफ्टवेयर में संशोधन की आवश्यकता हो सकती है।
  3. प्रदर्शन या कार्यक्षमता में सुधार (Improving Performance or Functionality): समय के साथ, उपयोगकर्ता नई सुविधाओं की मांग कर सकते हैं या मौजूदा सुविधाओं में सुधार की उम्मीद कर सकते हैं। प्रदर्शन, दक्षता और प्रयोज्यता को बढ़ाने के लिए रखरखाव आवश्यक है।
  4. भविष्य की समस्याओं को रोकना (Preventing Future Problems): कोड की जटिलता को कम करने, पठनीयता में सुधार करने और भविष्य में रखरखाव को आसान बनाने के लिए सॉफ्टवेयर की संरचना को संशोधित करने के लिए सक्रिय रखरखाव किया जाता है।

संक्षेप में, रखरखाव सॉफ्टवेयर को उपयोगी, प्रासंगिक और लंबे समय तक चालू रखने के लिए आवश्यक है। सॉफ्टवेयर मेंटेनेंस के प्रकार (Types of Software Maintenance): सॉफ्टवेयर मेंटेनेंस को मुख्य रूप से चार श्रेणियों में बांटा गया है:

1. करेक्टिव मेंटेनेंस (Corrective Maintenance): यह रखरखाव का सबसे पारंपरिक रूप है। इसका मुख्य उद्देश्य सॉफ्टवेयर में खोजे गए दोषों (bugs), त्रुटियों और दोषों का निदान और समाधान करना है। यह एक प्रतिक्रियाशील (reactive) गतिविधि है जो तब होती है जब उपयोगकर्ता किसी समस्या की रिपोर्ट करता है। उदाहरण के लिए, एक गणना में एक त्रुटि को ठीक करना या एक अप्रत्याशित सिस्टम क्रैश के कारण को दूर करना।

2. एडेप्टिव मेंटेनेंस (Adaptive Maintenance): इस प्रकार का रखरखाव सॉफ्टवेयर को बदलते बाहरी वातावरण के अनुकूल बनाने के लिए किया जाता है। इसमें हार्डवेयर, ऑपरेटिंग सिस्टम, डेटाबेस, या अन्य बाहरी सॉफ़्टवेयर में परिवर्तन के लिए सॉफ़्टवेयर को संशोधित करना शामिल है। उदाहरण के लिए, सॉफ़्टवेयर को विंडोज 10 से विंडोज 11 पर चलने के लिए अपडेट करना, या एक नए टैक्स कानून का पालन करने के लिए पेरोल सिस्टम को संशोधित करना।

3. परफेक्टिव मेंटेनेंस (Perfective Maintenance): परफेक्टिव मेंटेनेंस उपयोगकर्ता की नई या बदलती आवश्यकताओं के जवाब में सॉफ्टवेयर की कार्यक्षमता और प्रदर्शन में सुधार पर केंद्रित है। यह कुल रखरखाव प्रयासों का सबसे बड़ा हिस्सा (लगभग 50-60%) बनाता है। इसमें नई सुविधाएँ जोड़ना, मौजूदा सुविधाओं को बढ़ाना, कोड को अनुकूलित करके प्रदर्शन में सुधार करना और प्रयोज्यता को बेहतर बनाना शामिल है। उदाहरण के लिए, एक रिपोर्टिंग टूल में एक नया निर्यात-से-एक्सेल (Export-to-Excel) फ़ंक्शन जोड़ना।

4. प्रीवेंटिव मेंटेनेंस (Preventive Maintenance): इस प्रकार का रखरखाव भविष्य में संभावित समस्याओं को होने से रोकने के लिए किया जाता है। इसमें कोड को फिर से इंजीनियर (re-engineering) करना, पठनीयता और रखरखाव में सुधार के लिए कोड को रीफैक्टर (refactoring) करना और प्रलेखन (documentation) को अपडेट करना शामिल है। इसका लक्ष्य सॉफ्टवेयर को समय के साथ खराब होने से बचाना और भविष्य के रखरखाव को आसान और कम खर्चीला बनाना है।

Q4. (a) सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट (SCM) क्या है? SCM गतिविधियों की संक्षेप में व्याख्या करें। (10)

Ans.

सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट (SCM): सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट (SCM) एक प्रक्रिया है जो सॉफ्टवेयर विकास जीवनचक्र के दौरान सॉफ्टवेयर उत्पाद में किए गए परिवर्तनों को व्यवस्थित, प्रबंधित और नियंत्रित करती है। यह एक अनुशासन है जो यह सुनिश्चित करता है कि सॉफ्टवेयर सिस्टम की अखंडता (integrity) और संगति (consistency) समय के साथ बनी रहे। SCM उन सभी कलाकृतियों (artifacts) को प्रबंधित करता है जो एक सॉफ्टवेयर प्रोजेक्ट का हिस्सा हैं, जैसे कि सोर्स कोड, आवश्यकता दस्तावेज, डिजाइन दस्तावेज, टेस्ट केस, और उपयोगकर्ता मैनुअल।

SCM का मुख्य लक्ष्य भ्रम को कम करना और त्रुटियों को नियंत्रित करना है जो तब हो सकती हैं जब कई लोग एक ही समय में एक जटिल प्रणाली पर काम कर रहे हों। यह “कौन, क्या, कब और क्यों” बदला गया, इसका एक स्पष्ट रिकॉर्ड प्रदान करता है। SCM की गतिविधियाँ (SCM Activities): SCM प्रक्रिया में चार मुख्य गतिविधियाँ शामिल हैं:

1. कॉन्फ़िगरेशन पहचान (Configuration Identification): यह SCM की पहली और मूलभूत गतिविधि है। इसमें उन सभी आइटम्स की पहचान करना शामिल है जिन्हें कॉन्फ़िगरेशन नियंत्रण में रखने की आवश्यकता है। इन आइटम्स को कॉन्फ़िगरेशन आइटम (Configuration Items – CIs) कहा जाता है। प्रत्येक CI को एक अद्वितीय पहचानकर्ता दिया जाता है और उसकी विशेषताओं का वर्णन किया जाता है। उदाहरण के लिए, `main.c संस्करण 1.2` या `SRS_document_v2.1`। यह एक आधार रेखा (baseline) स्थापित करने में मदद करता है, जो विकास के एक बिंदु पर एक स्थिर, औपचारिक रूप से स्वीकृत विनिर्देश या उत्पाद है।

2. संस्करण नियंत्रण (Version Control): संस्करण नियंत्रण (या स्रोत नियंत्रण) विभिन्न संस्करणों में किए गए परिवर्तनों को प्रबंधित करने की प्रक्रिया है। जब भी कोई CI संशोधित किया जाता है, तो एक नया संस्करण बनाया जाता है। संस्करण नियंत्रण प्रणालियाँ (जैसे Git, SVN) डेवलपर्स को परिवर्तनों को ट्रैक करने, पुराने संस्करणों पर वापस जाने और विभिन्न डेवलपर्स द्वारा किए गए परिवर्तनों को मर्ज करने की अनुमति देती हैं। यह सुनिश्चित करता है कि समानांतर विकास के दौरान परिवर्तन एक-दूसरे को ओवरराइट न करें।

3. परिवर्तन नियंत्रण (Change Control): यह किसी भी CI में परिवर्तन करने के लिए एक औपचारिक प्रक्रिया है। जब भी किसी आधारभूत CI में बदलाव की आवश्यकता होती है, तो एक परिवर्तन अनुरोध (Change Request – CR) प्रस्तुत किया जाता है। इस अनुरोध का मूल्यांकन एक परिवर्तन नियंत्रण बोर्ड (Change Control Board – CCB) द्वारा किया जाता है, जो परिवर्तन के प्रभाव, लागत और लाभों का विश्लेषण करता है। CCB या तो अनुरोध को स्वीकार करता है, अस्वीकार करता है, या स्थगित करता है। यह प्रक्रिया सुनिश्चित करती है कि केवल अधिकृत और मूल्यांकित परिवर्तन ही सिस्टम में किए जाते हैं, जिससे अराजकता को रोका जा सके।

4. कॉन्फ़िगरेशन ऑडिटिंग और स्थिति लेखांकन (Configuration Auditing and Status Accounting):

  • कॉन्फ़िगरेशन ऑडिटिंग: यह एक ऐसी प्रक्रिया है जो यह सत्यापित करती है कि सॉफ्टवेयर उत्पाद आवश्यकताओं को पूरा करता है और यह कि SCM प्रक्रिया का ठीक से पालन किया गया है। यह सुनिश्चित करता है कि जो बनाया गया है वह वही है जो बनाने का इरादा था।
  • स्थिति लेखांकन (Status Accounting): यह समय के साथ सभी CIs और प्रस्तावित परिवर्तनों की स्थिति को रिकॉर्ड करने और रिपोर्ट करने की प्रक्रिया है। यह सवालों के जवाब देता है जैसे: “CI का वर्तमान संस्करण क्या है?”, “किसने परिवर्तन किया?”, “परिवर्तन अनुरोध की स्थिति क्या है?”। यह परियोजना की स्थिति में दृश्यता प्रदान करता है।

(b) DFD क्या है? DFD के घटक क्या हैं? ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली के लिए DFD के पहले दो स्तर बनाएं। आवश्यक धारणाएं बनाएं। (10)

Ans.

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

DFD के घटक (Components of DFD): DFD में चार मूल प्रतीक होते हैं:

  1. बाहरी इकाई (External Entity): एक वर्ग या आयत द्वारा दर्शाया गया, यह एक स्रोत (source) या गंतव्य (destination) है जो सिस्टम के बाहर है लेकिन सिस्टम के साथ इंटरैक्ट करता है। उदाहरण: ग्राहक, प्रबंधक, अन्य सिस्टम।
  2. प्रक्रिया (Process): एक वृत्त या गोल कोनों वाले आयत द्वारा दर्शाया गया, यह डेटा पर किए गए एक कार्य या परिवर्तन का प्रतिनिधित्व करता है। यह इनपुट डेटा को आउटपुट डेटा में बदलता है। उदाहरण: ‘भुगतान की प्रक्रिया करें’, ‘ग्रेड की गणना करें’।
  3. डेटा स्टोर (Data Store): दो समानांतर रेखाओं या एक खुली आयत द्वारा दर्शाया गया, यह डेटा के एक भंडार का प्रतिनिधित्व करता है जहाँ डेटा संग्रहीत किया जाता है। उदाहरण: ‘छात्र फ़ाइल’, ‘उत्पाद तालिका’।
  4. डेटा फ्लो (Data Flow): एक तीर वाली रेखा द्वारा दर्शाया गया, यह सिस्टम के घटकों के बीच डेटा की गति को दिखाता है। तीर डेटा के प्रवाह की दिशा को इंगित करता है।

ऑनलाइन असाइनमेंट सबमिशन और मूल्यांकन प्रणाली के लिए DFD: धारणाएं:

  • सिस्टम के तीन बाहरी उपयोगकर्ता हैं: छात्र (Student) , संकाय (Faculty) , और व्यवस्थापक (Admin) ।
  • डेटा को ‘उपयोगकर्ता’, ‘असाइनमेंट’, और ‘सबमिशन’ डेटा स्टोर में संग्रहीत किया जाता है।

स्तर 0 DFD (संदर्भ आरेख – Context Diagram): यह DFD का उच्चतम स्तर है। यह पूरे सिस्टम को एक एकल प्रक्रिया के रूप में दिखाता है और बाहरी संस्थाओं के साथ इसके इंटरैक्शन को दर्शाता है। [आरेख विवरण:]

  • केंद्र में एक प्रक्रिया वृत्त है जिसका लेबल ” 0. ऑनलाइन असाइनमेंट और मूल्यांकन प्रणाली ” है।
  • बाहरी इकाई छात्र से सिस्टम में डेटा प्रवाह: `लॉगिन क्रेडेंशियल`, `सबमिटेड असाइनमेंट`।
  • सिस्टम से बाहरी इकाई छात्र तक डेटा प्रवाह: `असाइनमेंट विवरण`, `ग्रेड/फीडबैक`।
  • बाहरी इकाई संकाय से सिस्टम में डेटा प्रवाह: `लॉगिन क्रेडेंशियल`, `नया असाइनमेंट`, `मूल्यांकन विवरण`।
  • सिस्टम से बाहरी इकाई संकाय तक डेटा प्रवाह: `सबमिटेड असाइनमेंट`, `सबमिशन रिपोर्ट`।
  • बाहरी इकाई व्यवस्थापक से सिस्टम में डेटा प्रवाह: `लॉगिन क्रेडेंशियल`, `उपयोगकर्ता प्रबंधन विवरण`।
  • सिस्टम से बाहरी इकाई व्यवस्थापक तक डेटा प्रवाह: `सिस्टम रिपोर्ट`।

स्तर 0 DFD

( व्यवस्थापक ) ↑ ↓ ( छात्र ) ↔ [ 0. ऑनलाइन असाइनमेंट और मूल्यांकन प्रणाली ] ↔ ( संकाय ) स्तर 1 DFD: यह स्तर 0 की प्रक्रिया को प्रमुख उप-प्रक्रियाओं में विघटित करता है। [आरेख विवरण:]

  • प्रक्रियाएं:
    • 1.0 उपयोगकर्ता प्रबंधित करें (Manage Users)
    • 2.0 असाइनमेंट प्रबंधित करें (Manage Assignments)
    • 3.0 सबमिशन प्रबंधित करें (Manage Submissions)
    • 4.0 मूल्यांकन प्रबंधित करें (Manage Evaluations)
  • डेटा स्टोर:
    • D1: उपयोगकर्ता डेटाबेस (User DB)
    • D2: असाइनमेंट डेटाबेस (Assignment DB)
    • D3: सबमिशन डेटाबेस (Submission DB)
  • डेटा प्रवाह:
    • व्यवस्थापक `उपयोगकर्ता प्रबंधन विवरण` 1.0 को भेजता है, जो D1: उपयोगकर्ता डीबी को अपडेट करता है।
    • संकाय `नया असाइनमेंट` 2.0 को भेजता है, जो D2: असाइनमेंट डीबी को अपडेट करता है।
    • छात्र D2: असाइनमेंट डीबी से `असाइनमेंट विवरण` का अनुरोध करता है ( 2.0 के माध्यम से)।
    • छात्र `सबमिटेड असाइनमेंट` 3.0 को भेजता है, जो D3: सबमिशन डीबी को अपडेट करता है।
    • संकाय D3: सबमिशन डीबी से `सबमिटेड असाइनमेंट` का अनुरोध करता है ( 4.0 के माध्यम से)।
    • संकाय `मूल्यांकन विवरण` 4.0 को भेजता है, जो D3: सबमिशन डीबी को अपडेट करता है।
    • छात्र को 4.0 से `ग्रेड/फीडबैक` प्राप्त होता है।

Q5. निम्नलिखित पर संक्षिप्त नोट्स लिखें: 4×5=20 (a) रिवर्स इंजीनियरिंग (b) क्षमता परिपक्वता मॉडल (CMM) (c) डिबगिंग (d) यूज़-केस डायग्राम

Ans.

(a) रिवर्स इंजीनियरिंग (Reverse Engineering):

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

इसका मुख्य उद्देश्य “यह क्या करता है?” और “यह कैसे करता है?” जैसे सवालों का जवाब देना है। उद्देश्य:

  • विरासत प्रणालियों को समझना (Understanding Legacy Systems): पुराने सिस्टम जिनका प्रलेखन खो गया है, उन्हें बनाए रखने या माइग्रेट करने के लिए समझना।
  • पुन: प्रलेखन (Re-documentation): मौजूदा सिस्टम के लिए अद्यतित प्रलेखन बनाना।
  • बग्स खोजना और सुरक्षा कमजोरियों का विश्लेषण करना: किसी एप्लिकेशन में छिपी कमजोरियों का पता लगाना।
  • संगत उत्पादों का विकास करना: यह समझना कि कोई उत्पाद किसी अन्य सिस्टम के साथ कैसे इंटरैक्ट करता है ताकि एक संगत उत्पाद बनाया जा सके।

रिवर्स इंजीनियरिंग को अक्सर फॉरवर्ड इंजीनियरिंग (एक विनिर्देश से एक सिस्टम बनाने की पारंपरिक प्रक्रिया) के विपरीत माना जाता है।

(b) क्षमता परिपक्वता मॉडल (Capability Maturity Model – CMM):

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

  1. स्तर 1: प्रारंभिक (Initial): प्रक्रियाएं अव्यवस्थित, अराजक और अक्सर तदर्थ (ad-hoc) होती हैं। सफलता व्यक्तिगत नायकों पर निर्भर करती है। कोई स्थिर वातावरण नहीं है।
  2. स्तर 2: दोहराने योग्य (Repeatable): बुनियादी परियोजना प्रबंधन प्रक्रियाएं स्थापित की जाती हैं। लागत, शेड्यूल और कार्यक्षमता को ट्रैक किया जाता है। पिछली सफलताओं को समान परियोजनाओं पर दोहराया जा सकता है।
  3. स्तर 3: परिभाषित (Defined): सॉफ्टवेयर विकास और प्रबंधन दोनों के लिए एक मानकीकृत प्रक्रिया प्रलेखित की जाती है और पूरे संगठन में उपयोग की जाती है। सभी परियोजनाएं इस अनुकूलित मानक प्रक्रिया का उपयोग करती हैं।
  4. स्तर 4: प्रबंधित (Managed): संगठन सॉफ्टवेयर प्रक्रिया और उत्पाद की गुणवत्ता दोनों के लिए विस्तृत उपाय एकत्र करता है। प्रक्रियाओं को मात्रात्मक रूप से नियंत्रित और समझा जाता है।
  5. स्तर 5: अनुकूलन (Optimizing): मात्रात्मक प्रतिक्रिया और नवीन विचारों और प्रौद्योगिकियों के परीक्षण से निरंतर प्रक्रिया में सुधार सक्षम होता है। संगठन सक्रिय रूप से प्रक्रियाओं को बेहतर बनाने के तरीकों की तलाश करता है।

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

(c) डिबगिंग (Debugging):

डिबगिंग सॉफ्टवेयर कोड में मौजूद दोषों (defects) या बग्स (bugs) को खोजने और ठीक करने की प्रक्रिया है। यह सॉफ्टवेयर विकास का एक महत्वपूर्ण हिस्सा है। जबकि टेस्टिंग का उद्देश्य बग्स की उपस्थिति को उजागर करना है, डिबगिंग का उद्देश्य उन बग्स के मूल कारण का पता लगाना और उन्हें खत्म करना है। डिबगिंग प्रक्रिया में आम तौर पर निम्नलिखित चरण शामिल होते हैं:

  1. बग की पहचान (Identification): बग को टेस्टिंग या उपयोगकर्ता रिपोर्ट के माध्यम से पहचाना जाता है।
  2. बग का पुनरुत्पादन (Reproduction): डेवलपर बग को एक नियंत्रित वातावरण में लगातार पुन: पेश करने का प्रयास करता है।
  3. बग का अलगाव (Isolation): डेवलपर कोड के उस विशिष्ट स्थान या अनुभाग को इंगित करता है जो बग का कारण बन रहा है। इसमें विभिन्न तकनीकों का उपयोग किया जा सकता है।
  4. सुधार (Correction): एक बार जब कारण मिल जाता है, तो डेवलपर कोड को ठीक करता है।
  5. सत्यापन (Verification): डेवलपर और परीक्षक यह सत्यापित करते हैं कि फिक्स ने समस्या का समाधान कर दिया है और कोई नया बग (रिग्रेशन) पेश नहीं किया है।

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

(d) यूज़-केस डायग्राम (Use-Case Diagram):

यूज़-केस डायग्राम यूनिफाइड मॉडलिंग लैंग्वेज (UML) में एक प्रकार का व्यवहार आरेख (behavioral diagram) है। यह एक सिस्टम की कार्यात्मक आवश्यकताओं को एक उपयोगकर्ता के दृष्टिकोण से दर्शाता है। यह दिखाता है कि एक उपयोगकर्ता (जिसे एक्टर कहा जाता है) एक सिस्टम के साथ कैसे इंटरैक्ट करता है ताकि एक विशिष्ट लक्ष्य प्राप्त किया जा सके। यूज़-केस डायग्राम के मुख्य घटक:

  • एक्टर (Actor): यह एक व्यक्ति, एक संगठन, या एक बाहरी प्रणाली है जो विचाराधीन प्रणाली के साथ इंटरैक्ट करती है। इसे एक स्टिक फिगर द्वारा दर्शाया जाता है। उदाहरण: ‘छात्र’, ‘बैंक क्लर्क’, ‘पेमेंट गेटवे’।
  • यूज़ केस (Use Case): यह एक एक्टर द्वारा किए गए कार्यों या घटनाओं का एक क्रम है जो एक्टर के लिए एक देखने योग्य, मूल्यवान परिणाम देता है। इसे एक अंडाकार (oval) द्वारा दर्शाया जाता है। उदाहरण: ‘पैसे निकालना’, ‘असाइनमेंट जमा करना’।
  • सिस्टम बाउंड्री (System Boundary): यह एक आयत है जो सिस्टम के दायरे को परिभाषित करता है। यूज़ केस बाउंड्री के अंदर होते हैं, और एक्टर बाहर होते हैं।
  • संबंध (Relationships): ये एक्टर और यूज़ केस के बीच (`एसोसिएशन`) या यूज़ केस के बीच (`इनक्लूड`, `एक्सटेंड`) कनेक्शन दिखाते हैं।

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

IGNOU BCS-051 Previous Year Solved Question Paper in English

Q1. (a) Develop SRS for Online Assignment Submission and Evaluation System for a University. Use IEEE format for SRS. Make necessary assumptions. (20)

Ans. Software Requirements Specification (SRS) – Online Assignment Submission and Evaluation System Version 1.0

1. Introduction 1.1 Purpose The purpose of this document is to define the functional and non-functional requirements for an Online Assignment Submission and Evaluation System for a university. This system will automate and streamline the process of students submitting assignments online and faculty evaluating and grading them.

1.2 Scope The system will provide a web-based interface for students, faculty members, and administrators. It will cover:

  • User registration and authentication.
  • Creation and uploading of assignments by faculty.
  • Downloading of assignments and uploading of solutions by students.
  • Management of due dates.
  • Online evaluation and feedback by faculty.
  • Automatic publication of grades.
  • Notifications and report generation.

1.3 Definitions, Acronyms, and Abbreviations

  • SRS: Software Requirements Specification
  • OASES: Online Assignment Submission and Evaluation System
  • Admin: The user who manages the system.
  • Faculty: The course instructor who creates and grades assignments.
  • Student: The user enrolled in a course who submits assignments.

2. Overall Description 2.1 Product Perspective The OASES will be a stand-alone system that can be integrated with the university’s existing Student Information System (SIS) to sync user data. It will be a web-based application accessible from any standard web browser.

2.2 Product Functions The major functions of the system are:

  • User Management: The admin can add/remove/edit users (students, faculty).
  • Assignment Management: Faculty can create new assignments, set due dates, and assign them to specific courses.
  • Submission Management: Students can view their assignments, download solutions, and upload their files before the deadline.
  • Evaluation Management: Faculty can evaluate the submitted assignments, award grades, and provide feedback.
  • Reporting: Admin and faculty can view various reports, such as submission status, grade distribution, etc.

2.3 User Characteristics

  • Student: Basic knowledge of computers and web browsers.
  • Faculty: Similar to students, plus experience with file uploading and text editing.
  • Administrator: Technically proficient and experienced in system management.

2.4 Assumptions and Dependencies

  • Users will have an internet connection and a compatible web browser.
  • The system will be hosted on a secure server.
  • User data (name, roll number, course) will be available from the university’s database.

3. Specific Requirements 3.1 Functional Requirements FR1: User Authentication

  • The system must authenticate all users (student, faculty, admin) via a unique ID and password.
  • There shall be a “Forgot Password” feature.


FR2: Assignment Creation

  • Faculty members shall be able to create new assignments with a title, description, maximum marks, and a due date.
  • They can attach files related to the assignment (e.g., question paper).


FR3: Assignment Submission

  • Students shall be able to view all active assignments on their dashboard.
  • Students shall be able to upload their solutions (e.g., .pdf, .docx files) before the due date.
  • Late submissions must be flagged by the system.


FR4: Assignment Evaluation

  • Faculty must be able to view/download the submitted assignments online.
  • There shall be an interface for faculty to award marks and provide text-based feedback for each submission.

3.2 Non-Functional Requirements

  • Performance: The page load time should be less than 3 seconds. The system should be able to handle 500 concurrent users.
  • Security: All data transmission must be encrypted using SSL/TLS. The system should be secured against common attacks like SQL Injection and Cross-Site Scripting.
  • Usability: The interface should be intuitive and user-friendly, requiring minimal training.
  • Reliability: The system should be available 99.5% of the time.

3.3 External Interface Requirements

  • Software Interfaces: The system may provide an API to integrate with the university’s Student Information System (SIS) for syncing student and course data.
  • Hardware Interfaces: No special hardware interfaces are required.
  • Communications Interfaces: The system will communicate over HTTP/HTTPS protocols.

(b) What is an object? Explain application logic object with an example. Also, explain specifications of static object. (10)

Ans. Object: In Object-Oriented Programming (OOP), an object is a fundamental entity that represents a real-world entity. It is a combination of two main characteristics:

  • State: Represented by its attributes or properties. This stores the data of the object. For example, a ‘Car’ object might have a state of ‘color’, ‘model’, and ‘speed’.
  • Behavior: Represented by its methods or functions. This defines what the object can do and how it can act on its data. For example, a ‘Car’ object might have behaviors like ‘startEngine()’, ‘accelerate()’, and ‘brake()’.

In short, an object is an instance of a class, where a class is a blueprint that defines the structure and behavior of the object.

Application Logic Object: An application logic object , often called a business object , is a type of object that encapsulates the business rules and logic of an application. These objects are not directly tied to the user interface (UI) or data storage; instead, they focus on implementing the core logic of the application. They represent the entities that the business works with.

Example: Consider an “Online Banking System”. An `Account` object in this system would be an application logic object.

  • State: `accountNumber`, `accountHolderName`, `balance`.
  • Behavior: `deposit(amount)`, `withdraw(amount)`, `checkBalance()`.

Here, the `withdraw(amount)` method would contain business logic, such as checking if there is a sufficient balance (`balance >= amount`) and if the withdrawal limit is not exceeded. This logic is independent of the UI or the database, making the code more modular and maintainable.

Specifications of a Static Object: A static object, or more accurately, static members (variables and methods) of a class, are members that belong to the class itself, rather than to a specific instance (object) of the class.

The main specifications of static objects (or members) are:

  1. Single Copy: There is only one copy of a static member, no matter how many objects of the class are created. It is shared among all objects. For instance, if a `Student` class has a static variable `totalStudents`, it will be the same for all `Student` objects.
  2. Class-Level Access: Static members can be accessed directly using the class name, without creating an object. For example, `Student.totalStudents`.
  3. Memory Allocation: Memory for static members is allocated when the program starts (or when the class is loaded) and lasts for the lifetime of the program. It is stored in a separate memory area, not on the heap like objects.
  4. Usage: Static members are typically used for properties or methods that are common to all instances, such as counters (e.g., to count the number of objects created), constants, or utility functions.

(c) What is structured analysis? Explain. (5)

Ans. Structured Analysis is a software development technique used for understanding and defining software requirements. It follows a top-down approach, meaning it decomposes a complex system into smaller, more manageable parts. Its primary focus is on the flow of data through the system and the transformations performed on that data.

The goal of structured analysis is to create a clear, accurate, and easily understandable model of what the system should do, before considering how it will be done (the design phase). It focuses on the “what,” not the “how.”

Key Features and Tools of Structured Analysis:

  • Graphical Representation: It makes heavy use of graphical tools to model the system. This reduces the reliance on textual descriptions, which can lead to misinterpretations.
  • Data Flow Diagram (DFD): This is the most important tool of structured analysis. A DFD shows how data enters the system, flows within it, where it is stored, and how it exits the system.
  • Data Dictionary: This is a repository that stores detailed descriptions of all data items, data stores, and data flows used in the DFD. It provides metadata for the data.
  • Process Specification: Also known as “mini-specs.” These describe the logic of the lowest-level processes in a DFD. They can be written using Structured English, decision trees, or decision tables.
  • Top-Down Approach: The analysis starts from a high-level, abstract view (the context diagram or Level 0 DFD) and is then progressively decomposed into more detailed levels.

Overall, structured analysis helps in creating a robust and accurate requirements specification by improving communication between developers, stakeholders, and users.

(d) Explain the principles of software testing. (5)

Ans. Software testing is a crucial process that ensures a software product meets expectations and is free of defects. To conduct effective testing, testers must adhere to some fundamental principles. These principles guide the testing process and make it more efficient.

The key software testing principles are as follows:

  1. Testing shows the presence of defects, not absence: Testing can prove that defects exist in the software, but it can never prove that there are no defects. If no defects are found during testing, it doesn’t mean the software is 100% bug-free.
  2. Exhaustive testing is impossible: Testing all possible inputs, combinations, and paths for a non-trivial software is not feasible. Instead, we must focus our testing efforts based on risk analysis and priorities.
  3. Early testing: Testing should start as early as possible in the Software Development Life Cycle (SDLC). Finding and fixing defects in the requirements and design phases is much cheaper than fixing them after coding.
  4. Defect clustering: This principle states that a majority of defects are concentrated in a small number of modules of the software. The Pareto principle (80/20 rule) applies here: approximately 80% of the problems are caused by 20% of the modules. This helps testers focus their efforts on these likely problem areas.
  5. Pesticide paradox: If you run the same set of test cases repeatedly, they will eventually become ineffective at finding new defects. Just as pesticides lose their effectiveness on insects, test cases also need to be regularly reviewed and revised to uncover new defects.
  6. Testing is context-dependent: The way you test depends on the type and context of the software being developed. Testing an e-commerce site is very different from testing an aviation control system.
  7. Absence-of-errors fallacy: Finding and fixing defects doesn’t matter if the system built is unusable and doesn’t meet the user’s needs and expectations. Being 99% bug-free is useless if the system was built for the wrong requirements.

Q2. (a) Explain Waterfall Model with the help of a suitable diagram. List advantages and disadvantages of this model. (10)

Ans. The Waterfall Model is the oldest and most straightforward model of the Software Development Life Cycle (SDLC). It is also known as a linear-sequential life cycle model. In this model, the development process is divided into distinct phases, and each phase must be fully completed before moving on to the next. It flows downwards like a waterfall, with the output of one phase becoming the input for the next.

Phases of the Waterfall Model: The Waterfall Model consists of the following phases, executed in a strict sequence:

1. Requirement Analysis and Definition: In this phase, all possible requirements of the system are gathered, understood, and documented. A Software Requirement Specification (SRS) document is created. 2. System and Software Design: Based on the SRS, the system design is prepared. This phase specifies hardware and system requirements and helps in defining the overall system architecture. 3. Implementation and Unit Testing: The system design is broken down into small programs called “units.” Each unit is developed and coded individually, and then tested for its functionality (Unit Testing). 4. Integration and System Testing: In this phase, all the developed units are integrated into a complete system. The entire system is then tested to ensure that it meets all the requirements. 5. Operation and Maintenance: Once the system is successfully tested, it is deployed in the customer’s environment. The maintenance phase involves fixing bugs, upgrading the system, and adding new features.

Diagram: (Requirements) → (Design) → (Implementation) → (Testing) → (Deployment) → (Maintenance) [A diagram showing a linear flow through the phases from top to bottom with arrows should be depicted here.]


The Waterfall Model

[ Requirement Analysis ] ↓[ System Design ] ↓[ Implementation ] ↓[ Testing ] ↓[ Deployment ] ↓[ Maintenance ]

Advantages of the Waterfall Model:

  • Simple and easy to understand: Due to its rigid structure and clearly defined phases, this model is simple and easy to manage.
  • Enforces discipline: Each phase has a specific deliverable, which brings discipline and visibility to the process.
  • Good documentation: This model emphasizes documentation (like SRS, design docs), which helps in knowledge transfer and maintenance.
  • Suitable for small projects: It works well for smaller projects where requirements are very well understood and stable.

Disadvantages of the Waterfall Model:

  • Inflexibility: Once a phase is completed, it is very difficult and expensive to go back and make changes.
  • Lack of early feedback: The customer does not get to see a working software until late in the development cycle, so early feedback is not possible.
  • High risk and uncertainty: If requirements are misunderstood at the beginning, the entire project can fail.
  • Unsuitable for complex and long projects: It is not suitable for large, complex, and object-oriented projects where requirements are likely to change.

(b) Draw a sample Gantt chart for an online examination system. Make necessary assumptions. (10)

Ans. A Gantt chart is a type of bar chart that illustrates a project schedule. It is a highly useful tool in project management. It lists the project tasks on the vertical axis and time intervals on the horizontal axis. The duration of each task is represented by a horizontal bar, whose position and length represent the start date, end date, and duration of the task.

Assumptions for the Online Examination System:

  • The total duration of the project is approximately 14 weeks.
  • The team consists of a project manager, two developers, and one tester.
  • Some tasks can be done in parallel, while others are sequential.
  • Each week consists of 5 working days.

Sample Gantt Chart for Online Examination System:

Below is a simplified representation of a Gantt chart for an online examination system project. ‘X’ represents a duration of one week.

Task Dependency Week 1-2 Week 3-4 Week 5-6 Week 7-8 Week 9-10 Week 11-12 Week 13-14
1. Requirement Analysis — XX
2. System Design & Architecture 1 XX
3. Database Design 2 X
4. Module Dev: User Management 3 X X
5. Module Dev: Question Bank Mgt 3 XX X
6. Module Dev: Exam Conduction 3 XX X
7. Module Integration 4, 5, 6 X
8. System Testing 7 XX X
9. User Acceptance Testing (UAT) 8 X
10. Deployment & Go-Live 9 X

Explanation of the Chart:

  • Task: The project is broken down into smaller, manageable tasks.
  • Dependency: This shows which task must be completed before another can begin. For instance, ‘System Design’ (Task 2) can only start after ‘Requirement Analysis’ (Task 1) is finished.
  • Timeline: The chart shows the timeline in weeks. The colored bars represent the estimated start and end of each task.
  • Milestones: Events like ‘Deployment & Go-Live’ can be considered milestones, marking the end of a major phase of the project.

This Gantt chart helps in tracking project progress, managing resources, and keeping all stakeholders informed about the project’s status.

Q3. (a) Explain System testing and Regression testing. (10)

Ans. System Testing: System Testing is a type of black-box testing performed on a complete and integrated software system to verify that it meets the specified requirements. Its main purpose is to evaluate the system as a whole. This testing phase occurs after the integration of individual components.

The focus of system testing is on both the functional and non-functional aspects of the software. It is conducted from an end-user’s perspective to ensure that the system behaves as expected in real-world scenarios.

Key Aspects of System Testing:

  • Objective: To verify that the system as a whole meets the business and technical requirements.
  • When it’s done: After unit testing and integration testing, but before User Acceptance Testing (UAT).
  • Who does it: It is typically done by an independent testing team, not the developers, to ensure an unbiased evaluation.
  • Scope of Testing: It can include various types of testing such as performance, security, usability, reliability, and recovery testing.
  • Example: For an e-commerce website, system testing would involve testing the entire process of finding a product, adding it to the cart, checking out, making a payment, and receiving an order confirmation.

Regression Testing: Regression Testing is a type of software testing that is done to ensure that recent changes to the code, such as bug fixes or new features, have not negatively impacted the existing functionality. Its purpose is to find out if any new bugs (called “regressions”) have been introduced.

Regression testing is performed whenever there is a modification in the software. It is a repetitive process and is often done using automated testing tools to save time and effort.

Key Aspects of Regression Testing:

  • Objective: To verify that existing functionality is still working correctly after code changes.
  • When it’s done: Every time a new module is added, an existing module is modified, or a bug is fixed.
  • Scope of Testing: It can involve re-running the entire existing test suite or selecting a subset of test cases that target the affected areas.
  • Techniques: Techniques include “Retest All”, “Selective Testing”, and “Prioritized Testing”.
  • Example: If the ‘Fund Transfer’ feature in a banking application is modified, regression testing would ensure that other existing features like ‘Balance Check’, ‘Account Statement’, and ‘Bill Payment’ are still working correctly.

Key Difference: In summary, the goal of System Testing is to validate the entire system against its requirements, while the goal of Regression Testing is to ensure that changes have not broken the existing system. System testing is a specific phase, whereas regression testing is a continuous activity that occurs throughout the development and maintenance cycle.

(b) What is the need of software maintenance? Briefly explain different types of software maintenance. (10)

Ans. Need for Software Maintenance: Software maintenance is the process of modifying and updating a software product after it has been delivered to the customer. It is an integral and crucial part of the Software Development Life Cycle (SDLC), often accounting for 50% to 75% of the total cost. The need for software maintenance arises for several reasons:

  1. Correcting Faults: No software is completely bug-free. Defects or faults that were overlooked during development may surface in production, which need to be fixed.
  2. Adapting to a Changing Environment: Software operates in a dynamic environment. Changes in the operating system, hardware, government regulations, or business policies may require modifications to the software.
  3. Improving Performance or Functionality: Over time, users may demand new features or expect improvements in existing ones. Maintenance is necessary to enhance performance, efficiency, and usability.
  4. Preventing Future Problems: Proactive maintenance is done to modify the software’s structure to reduce code complexity, improve readability, and make future maintenance easier.

In essence, maintenance is essential to keep the software useful, relevant, and operational over a long period.

Types of Software Maintenance: Software maintenance is primarily divided into four categories:

1. Corrective Maintenance: This is the most traditional form of maintenance. Its main purpose is to diagnose and fix discovered defects, bugs, and faults in the software. It is a reactive activity that occurs when a user reports a problem. For example, fixing an error in a calculation or addressing the cause of an unexpected system crash.

2. Adaptive Maintenance: This type of maintenance is performed to adapt the software to a changing external environment. It involves modifying the software to accommodate changes in hardware, operating systems, databases, or other external software. For example, updating the software to run on Windows 11 from Windows 10, or modifying a payroll system to comply with a new tax law.

3. Perfective Maintenance: Perfective maintenance focuses on improving the functionality and performance of the software in response to new or changing user requirements. It constitutes the largest share (about 50-60%) of total maintenance efforts. It includes adding new features, enhancing existing features, improving performance by optimizing code, and enhancing usability. For example, adding a new Export-to-Excel function to a reporting tool.

4. Preventive Maintenance: This type of maintenance is performed to prevent potential problems from occurring in the future. It involves re-engineering the code, refactoring code to improve readability and maintainability, and updating documentation. The goal is to prevent the software from deteriorating over time and to make future maintenance easier and less expensive.

Q4. (a) What is Software Configuration Management (SCM)? Explain SCM activities briefly. (10)

Ans. Software Configuration Management (SCM): Software Configuration Management (SCM) is a process that organizes, manages, and controls the changes made to a software product during its development lifecycle. It is a discipline that ensures the integrity and consistency of the software system are maintained over time. SCM manages all the artifacts that are part of a software project, such as source code, requirement documents, design documents, test cases, and user manuals.

The main goal of SCM is to minimize confusion and control errors that can occur when multiple people are working on a complex system at the same time. It provides a clear record of “who changed what, when, and why.”

SCM Activities: The SCM process involves four main activities:

1. Configuration Identification: This is the first and fundamental activity of SCM. It involves identifying all the items that need to be placed under configuration control. These items are called Configuration Items (CIs) . Each CI is given a unique identifier and its characteristics are described. For example, `main.c version 1.2` or `SRS_document_v2.1`. This helps in establishing a baseline, which is a stable, formally approved specification or product at a point in development.

2. Version Control: Version control (or source control) is the process of managing changes to different versions. Whenever a CI is modified, a new version is created. Version control systems (like Git, SVN) allow developers to track changes, revert to older versions, and merge changes made by different developers. This ensures that changes do not overwrite each other during parallel development.

3. Change Control: This is a formal process for making changes to any CI. Whenever a change to a baselined CI is needed, a Change Request (CR) is submitted. This request is evaluated by a Change Control Board (CCB) , which analyzes the impact, cost, and benefits of the change. The CCB either approves, rejects, or defers the request. This process ensures that only authorized and evaluated changes are made to the system, preventing chaos.

4. Configuration Auditing and Status Accounting:

  • Configuration Auditing: This is a process that verifies that the software product meets the requirements and that the SCM process has been followed correctly. It ensures that what has been built is what was intended to be built.
  • Status Accounting: This is the process of recording and reporting the status of all CIs and proposed changes over time. It answers questions like: “What is the current version of a CI?”, “Who made a change?”, “What is the status of a change request?”. It provides visibility into the project’s status.

(b) What is a DFD? What are the components of DFD? Draw first two levels of DFDs for Online Assignment Submission and Evaluation System. Make necessary assumptions. (10)

Ans. Data Flow Diagram (DFD): A Data Flow Diagram (DFD) is a graphical representation that shows the flow of information (data) through a system. It illustrates where data comes from, how it is processed within the system, where it is stored, and where it ultimately goes. DFDs are used in structured analysis to model the requirements of a system. It focuses on what the system does (processes), not how it does it (implementation details).

Components of DFD: A DFD has four basic symbols:

  1. External Entity: Represented by a square or rectangle, it is a source or destination of data that is outside the system but interacts with it. Examples: Customer, Manager, Other System.
  2. Process: Represented by a circle or a rounded-corner rectangle, it represents an action or transformation performed on data. It transforms input data into output data. Examples: ‘Process Payment’, ‘Calculate Grade’.
  3. Data Store: Represented by two parallel lines or an open-ended rectangle, it represents a repository of data where data is stored. Examples: ‘Student File’, ‘Products Table’.
  4. Data Flow: Represented by a line with an arrow, it shows the movement of data between the components of the system. The arrow indicates the direction of data flow.

DFD for Online Assignment Submission and Evaluation System:

Assumptions:

  • The system has three external users: Student , Faculty , and Admin .
  • Data is stored in ‘User’, ‘Assignment’, and ‘Submission’ data stores.

Level 0 DFD (Context Diagram): This is the highest level of DFD. It shows the entire system as a single process and illustrates its interaction with external entities.

[Diagram Description:]

  • In the center is a process circle labeled ” 0. Online Assignment & Evaluation System “.
  • Data flows from the external entity Student to the system: `Login Credentials`, `Submitted Assignment`.
  • Data flows from the system to the external entity Student : `Assignment Details`, `Grades/Feedback`.
  • Data flows from the external entity Faculty to the system: `Login Credentials`, `New Assignment`, `Evaluation Details`.
  • Data flows from the system to the external entity Faculty : `Submitted Assignments`, `Submission Reports`.
  • Data flows from the external entity Admin to the system: `Login Credentials`, `User Management Details`.
  • Data flows from the system to the external entity Admin : `System Reports`.


Level 0 DFD

 ( Admin ) ↑ ↓( Student ) ↔ [ 0. Online Assignment & Evaluation System ] ↔ ( Faculty )

Level 1 DFD: This level decomposes the Level 0 process into its major sub-processes.

[Diagram Description:]

  • Processes:
    • 1.0 Manage Users
    • 2.0 Manage Assignments
    • 3.0 Manage Submissions
    • 4.0 Manage Evaluations
  • Data Stores:
    • D1: User DB
    • D2: Assignment DB
    • D3: Submission DB
  • Data Flows:
    • Admin sends `User Management Details` to 1.0 , which updates D1: User DB .
    • Faculty sends `New Assignment` to 2.0 , which updates D2: Assignment DB .
    • Student requests `Assignment Details` from D2: Assignment DB (via 2.0 ).
    • Student sends `Submitted Assignment` to 3.0 , which updates D3: Submission DB .
    • Faculty requests `Submitted Assignment` from D3: Submission DB (via 4.0 ).
    • Faculty sends `Evaluation Details` to 4.0 , which updates D3: Submission DB .
    • Student receives `Grades/Feedback` from 4.0 .

Q5. Write short notes on the following: 4×5=20 (a) Reverse Engineering (b) Capability Maturity Model (CMM) (c) Debugging (d) Use-case diagram

Ans. (a) Reverse Engineering: Reverse engineering is the process of analyzing an existing man-made product or system to understand its design, components, and interrelationships. In the context of software, it means analyzing a program without its source code or with incomplete documentation to recreate its functionality, structure, and design at a higher level of abstraction.

Its main purpose is to answer questions like “What does it do?” and “How does it do it?”.

Purposes:

  • Understanding Legacy Systems: To maintain or migrate old systems whose documentation has been lost.
  • Re-documentation: Creating up-to-date documentation for an existing system.
  • Finding bugs and analyzing security vulnerabilities: Discovering hidden vulnerabilities in an application.
  • Developing compatible products: Understanding how a product interacts with another system to create a compatible one.

Reverse engineering is often considered the opposite of forward engineering (the traditional process of creating a system from a specification).

(b) Capability Maturity Model (CMM): The Capability Maturity Model (CMM) is a development model created to help organizations assess and improve the effectiveness of their software development processes. It was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. CMM provides a framework for classifying an organization’s processes into one of five maturity levels.

The five levels of CMM are:

  1. Level 1: Initial: Processes are disorganized, chaotic, and often ad-hoc. Success depends on individual heroes. There is no stable environment.
  2. Level 2: Repeatable: Basic project management processes are established. Cost, schedule, and functionality are tracked. Past successes can be repeated on similar projects.
  3. Level 3: Defined: A standardized process for both software development and management is documented and used across the organization. All projects use this tailored standard process.
  4. Level 4: Managed: The organization collects detailed measures for both the software process and product quality. Processes are quantitatively controlled and understood.
  5. Level 5: Optimizing: Continuous process improvement is enabled by quantitative feedback and piloting of innovative ideas and technologies. The organization actively seeks ways to improve processes.

An organization at a higher level is more likely to produce better quality software, more predictably and within budget.

(c) Debugging: Debugging is the process of finding and fixing defects or bugs present in software code. It is a critical part of software development. While the purpose of testing is to expose the presence of bugs, the purpose of debugging is to locate the root cause of those bugs and eliminate them.

The debugging process typically involves the following steps:

  1. Bug Identification: The bug is identified through testing or user reports.
  2. Bug Reproduction: The developer tries to consistently reproduce the bug in a controlled environment.
  3. Bug Isolation: The developer pinpoints the specific location or section of the code that is causing the bug. Various techniques can be used for this.
  4. Correction: Once the cause is found, the developer fixes the code.
  5. Verification: The developer and tester verify that the fix has resolved the issue and has not introduced any new bugs (regressions).

Common techniques for debugging include using debugger tools, adding print statements to the code, analyzing the code manually (code walkthroughs), and examining log files.

(d) Use-case diagram: A use-case diagram is a type of behavioral diagram in the Unified Modeling Language (UML). It represents the functional requirements of a system from a user’s perspective. It shows how a user (called an Actor ) interacts with a system to achieve a specific goal.

The main components of a use-case diagram are:

  • Actor: This is a person, an organization, or an external system that interacts with the system under consideration. It is represented by a stick figure. Examples: ‘Student’, ‘Bank Clerk’, ‘Payment Gateway’.
  • Use Case: This is a sequence of actions or events performed by an actor that yields an observable, valuable result for the actor. It is represented by an oval. Examples: ‘Withdraw Money’, ‘Submit Assignment’.
  • System Boundary: This is a rectangle that defines the scope of the system. The use cases are inside the boundary, and the actors are outside.
  • Relationships: These show the connections between an actor and a use case (`Association`) or between use cases (`Include`, `Extend`).

Use-case diagrams are very useful for gathering and analyzing the requirements of a system. They help stakeholders understand what the system will do, without getting into the details of how it will do it.

Download IGNOU previous Year Question paper download PDFs for BCS-051 to improve your preparation. These ignou solved question paper IGNOU Previous Year Question paper solved PDF in Hindi and English help you understand the exam pattern and score better.

Thanks!

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *