The IGNOU MCS-034 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.
- IGNOU MCS-034 Solved Question Paper in Hindi
- IGNOU MCS-034 Solved Question Paper in English
- IGNOU Previous Year Solved Question Papers (All Courses)
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 MCS-034 Solved Question Paper PDF
This section provides IGNOU MCS-034 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 MCS-034 Previous Year Solved Question Paper in Hindi
Q1. (a) What are the different levels of capability maturity model ? Explain each of the levels briefly. (b) What are the steps involved in the process of debugging ? Explain these steps. (c) Define the term ‘Software Quality’. Also, discuss briefly the attributes of software quality. (d) Explain the roles and responsibilities of the following w.r.t. web-applications : (i) Web Master (ii) Application Support Team (iii) Content Development Team (iv) Web Publisher
Ans.
(a) कैपेबिलिटी मैच्योरिटी मॉडल (CMM) के विभिन्न स्तर
कैपेबिलिटी मैच्योरिटी मॉडल (CMM) एक संगठन की सॉफ्टवेयर विकास प्रक्रियाओं की परिपक्वता का आकलन करने और सुधारने के लिए एक रूपरेखा है। यह सॉफ्टवेयर इंजीनियरिंग संस्थान (SEI) द्वारा विकसित किया गया था। इसके पाँच स्तर हैं, जो नीचे दिए गए हैं:
- स्तर 1: प्रारंभिक (Initial): इस स्तर पर, प्रक्रियाएँ आमतौर पर अव्यवस्थित और अराजक होती हैं। सफलता व्यक्तिगत नायकों और संयोग पर निर्भर करती है। संगठन के पास एक स्थिर विकास वातावरण नहीं होता है, और परियोजनाएँ अक्सर बजट और समय-सीमा से अधिक हो जाती हैं।
- स्तर 2: दोहराने योग्य (Repeatable): इस स्तर पर, बुनियादी परियोजना प्रबंधन प्रक्रियाएँ स्थापित की जाती हैं। लागत, अनुसूची और कार्यक्षमता को ट्रैक किया जाता है। पिछली सफल परियोजनाओं के अनुभव को वर्तमान परियोजनाओं पर लागू किया जाता है, लेकिन प्रक्रियाएँ अभी भी प्रतिक्रियाशील होती हैं।
- स्तर 3: परिभाषित (Defined): इस स्तर पर, संगठन के लिए सॉफ्टवेयर विकास प्रक्रिया को प्रलेखित और मानकीकृत किया जाता है। सभी परियोजनाएँ एक स्वीकृत, अनुकूलित संस्करण का उपयोग करती हैं। प्रबंधन और इंजीनियरिंग दोनों गतिविधियों के लिए एक अच्छी तरह से परिभाषित प्रक्रिया होती है।
- स्तर 4: प्रबंधित (Managed): इस स्तर पर, संगठन सॉफ्टवेयर प्रक्रिया और उत्पाद की गुणवत्ता दोनों के लिए विस्तृत उपाय एकत्र करता है। प्रक्रियाओं और उत्पादों दोनों को मात्रात्मक रूप से समझा और नियंत्रित किया जाता है। सांख्यिकीय गुणवत्ता नियंत्रण का उपयोग किया जाता है।
- स्तर 5: अनुकूलन (Optimizing): इस स्तर पर, मात्रात्मक प्रतिक्रिया और नवीन विचारों और प्रौद्योगिकियों के परीक्षण के माध्यम से निरंतर प्रक्रिया में सुधार किया जाता है। संगठन सक्रिय रूप से कमजोरियों की पहचान करता है और प्रक्रिया में सुधार करके उन्हें ठीक करता है, जिससे दोषों की रोकथाम होती है।
(b) डिबगिंग प्रक्रिया में शामिल चरण
डिबगिंग एक सॉफ्टवेयर में मौजूद दोषों (बग्स) को खोजने और ठीक करने की एक व्यवस्थित प्रक्रिया है। यह परीक्षण के बाद शुरू होती है जब कोई बग रिपोर्ट किया जाता है। डिबगिंग में निम्नलिखित चरण शामिल हैं:
- दोष की पहचान और पुनरुत्पादन: पहला कदम बग को समझना है। डेवलपर को उस बग को विश्वसनीय रूप से पुन: उत्पन्न करने में सक्षम होना चाहिए। इसमें उपयोगकर्ता द्वारा रिपोर्ट किए गए सटीक चरणों का पालन करना शामिल है ताकि त्रुटि को अपनी आँखों से देखा जा सके।
- त्रुटि के स्रोत को अलग करना: एक बार बग को पुन: उत्पन्न किया जा सके, तो डेवलपर को कोड में उस स्थान को खोजना होगा जहाँ त्रुटि उत्पन्न हो रही है। इसके लिए डिबगिंग टूल, लॉग फाइलों का विश्लेषण, या कोड में प्रिंट स्टेटमेंट जोड़ने जैसी तकनीकों का उपयोग किया जा सकता है।
- त्रुटि के कारण की पहचान करें: स्रोत को अलग करने के बाद, अगला कदम यह समझना है कि त्रुटि क्यों हो रही है। इसमें कोड के तर्क का विश्लेषण करना, चर के मानों की जाँच करना और यह निर्धारित करना शामिल है कि अपेक्षित व्यवहार और वास्तविक व्यवहार में क्या अंतर है।
- सुधार का प्रस्ताव: कारण की पहचान करने के बाद, डेवलपर को बग को ठीक करने के लिए एक समाधान तैयार करना होगा। इस समाधान को न केवल वर्तमान समस्या को ठीक करना चाहिए, बल्कि सिस्टम के अन्य हिस्सों में नई समस्याएँ भी नहीं लानी चाहिए।
- सुधार को लागू करना: प्रस्तावित सुधार को कोड में लागू किया जाता है। इसमें कोड की पंक्तियों को संशोधित करना, जोड़ना या हटाना शामिल हो सकता है।
- सुधार का परीक्षण और प्रतिगमन परीक्षण (Regression Testing): सुधार लागू करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि बग वास्तव में ठीक हो गया है। इसके अतिरिक्त, प्रतिगमन परीक्षण किया जाना चाहिए ताकि यह सुनिश्चित हो सके कि इस परिवर्तन ने सॉफ्टवेयर के किसी अन्य हिस्से में कोई नया बग तो नहीं पैदा कर दिया है।
(c) सॉफ्टवेयर गुणवत्ता और उसके गुण
सॉफ्टवेयर गुणवत्ता को उस डिग्री के रूप में परिभाषित किया जाता है जिस तक एक सॉफ्टवेयर उत्पाद या सिस्टम स्पष्ट और निहित दोनों तरह की निर्दिष्ट आवश्यकताओं को पूरा करता है। यह केवल दोषों की अनुपस्थिति नहीं है, बल्कि यह भी है कि सॉफ्टवेयर उपयोगकर्ता की अपेक्षाओं और समग्र व्यावसायिक लक्ष्यों को कितनी अच्छी तरह पूरा करता है।
सॉफ्टवेयर गुणवत्ता के मुख्य गुण (Attributes), जो अक्सर ISO 9126 जैसे मानकों पर आधारित होते हैं, निम्नलिखित हैं:
- कार्यक्षमता (Functionality): यह सॉफ्टवेयर की उन कार्यों को प्रदान करने की क्षमता है जो उपयोगकर्ता की बताई गई और निहित आवश्यकताओं को पूरा करते हैं। यह सटीकता, उपयुक्तता और सुरक्षा जैसे पहलुओं को शामिल करता है।
- विश्वसनीयता (Reliability): यह सॉफ्टवेयर की निर्दिष्ट शर्तों के तहत समय की एक निर्दिष्ट अवधि के लिए अपने आवश्यक कार्यों को दोष-मुक्त रूप से करने की क्षमता है। यह परिपक्वता, दोष सहिष्णुता और पुनर्प्राप्ति-क्षमता से संबंधित है।
- प्रयोज्यता (Usability): यह वह आसानी है जिससे उपयोगकर्ता सॉफ्टवेयर को सीख सकते हैं, उपयोग कर सकते हैं और इससे संतुष्ट हो सकते हैं। इसमें समझने में आसानी, सीखने में आसानी और संचालन में आसानी जैसे गुण शामिल हैं।
- दक्षता (Efficiency): यह सॉफ्टवेयर की उपयोग किए गए संसाधनों (जैसे सीपीयू समय, मेमोरी, डिस्क स्पेस) की मात्रा के सापेक्ष अच्छा प्रदर्शन प्रदान करने की क्षमता है। यह समय व्यवहार और संसाधन उपयोग से संबंधित है।
- रखरखाव (Maintainability): यह वह आसानी है जिसके साथ सॉफ्टवेयर को संशोधित किया जा सकता है ताकि दोषों को ठीक किया जा सके, नई आवश्यकताओं को अनुकूलित किया जा सके, या प्रदर्शन में सुधार किया जा सके। इसमें विश्लेषण, परिवर्तन और परीक्षण में आसानी शामिल है।
- पोर्टेबिलिटी (Portability): यह सॉफ्टवेयर की एक वातावरण से दूसरे वातावरण में स्थानांतरित होने की क्षमता है। इसमें अनुकूलनशीलता, स्थापना में आसानी और विभिन्न हार्डवेयर या सॉफ्टवेयर कॉन्फ़िगरेशन के साथ सह-अस्तित्व की क्षमता शामिल है।
(d) वेब-एप्लीकेशन के संबंध में भूमिकाएं और जिम्मेदारियां
- (i) वेब मास्टर (Web Master): वेब मास्टर वेब-एप्लीकेशन के समग्र तकनीकी प्रबंधन और रखरखाव के लिए जिम्मेदार है। उनकी जिम्मेदारियों में शामिल हैं: सर्वर का रखरखाव, वेबसाइट का अपटाइम और प्रदर्शन सुनिश्चित करना, सुरक्षा उपायों को लागू करना, टूटे हुए लिंक की जाँच करना और बैकअप का प्रबंधन करना। वे अक्सर वेबसाइट की तकनीकी संरचना और नेविगेशन के लिए जिम्मेदार होते हैं।
- (ii) एप्लीकेशन सपोर्ट टीम (Application Support Team): यह टीम वेब-एप्लीकेशन के लॉन्च होने के बाद उपयोगकर्ताओं को सहायता प्रदान करती है। उनकी मुख्य जिम्मेदारियां हैं: अंतिम-उपयोगकर्ता की समस्याओं का निवारण, बग्स को पहचानना और उन्हें विकास टीम को रिपोर्ट करना, हेल्पडेस्क का प्रबंधन करना, उपयोगकर्ता गाइड बनाना और उपयोगकर्ता के प्रश्नों का उत्तर देना। वे उपयोगकर्ता और विकास टीम के बीच एक सेतु का काम करते हैं।
- (iii) कंटेंट डेवलपमेंट टीम (Content Development Team): यह टीम वेबसाइट पर दिखाई देने वाली सभी सामग्री बनाने के लिए जिम्मेदार है। इसमें टेक्स्ट, लेख, ब्लॉग पोस्ट लिखना, चित्र, ग्राफिक्स और वीडियो बनाना या प्राप्त करना शामिल है। वे सुनिश्चित करते हैं कि सामग्री सटीक, प्रासंगिक, आकर्षक और ब्रांड के दिशानिर्देशों के अनुरूप हो।
- (iv) वेब प्रकाशक (Web Publisher): वेब प्रकाशक कंटेंट डेवलपमेंट टीम द्वारा बनाई गई सामग्री लेता है और इसे वेबसाइट पर लाइव करता है। वे आमतौर पर एक कंटेंट मैनेजमेंट सिस्टम (CMS) का उपयोग करते हैं। उनकी जिम्मेदारियों में सामग्री को सही ढंग से प्रारूपित करना, यह सुनिश्चित करना कि यह विभिन्न उपकरणों पर सही दिखे, और सामग्री को सही समय पर प्रकाशित करना शामिल है। वे कंटेंट की अंतिम गेटकीपर होते हैं जो लाइव होने से पहले उसकी गुणवत्ता की जाँच करते हैं।
Q2. (a) What is the need of Interface design ? Explain the major elements of a good Interface design. (b) What are project-metrics ? Explain different types of project metrics with an example for each.
Ans.
(a) इंटरफ़ेस डिज़ाइन की आवश्यकता और अच्छे इंटरफ़ेस डिज़ाइन के प्रमुख तत्व
इंटरफ़ेस डिज़ाइन की आवश्यकता:
यूजर इंटरफ़ेस (UI) डिज़ाइन सॉफ्टवेयर और उपयोगकर्ता के बीच एक महत्वपूर्ण कड़ी है। एक अच्छे इंटरफ़ेस डिज़ाइन की आवश्यकता कई कारणों से होती है:
- प्रयोज्यता में सुधार (Improved Usability): एक अच्छा UI उपयोगकर्ताओं को सॉफ्टवेयर को आसानी से और कुशलता से उपयोग करने में मदद करता है। यह सीखने की अवस्था को कम करता है और उपयोगकर्ता को अपने लक्ष्यों को जल्दी प्राप्त करने में सक्षम बनाता है।
- उपयोगकर्ता संतुष्टि (User Satisfaction): जब एक इंटरफ़ेस सहज, आकर्षक और उपयोग में आसान होता है, तो उपयोगकर्ता का अनुभव सकारात्मक होता है, जिससे उत्पाद के प्रति संतुष्टि और वफादारी बढ़ती है।
- त्रुटियों में कमी (Reduced Errors): एक स्पष्ट और सुसंगत डिज़ाइन उपयोगकर्ताओं को गलतियाँ करने से रोकता है। यदि कोई त्रुटि होती भी है, तो एक अच्छा इंटरफ़ेस उसे सुधारने में मदद करता है।
- उत्पादकता में वृद्धि (Increased Productivity): एक कुशल इंटरफ़ेस उपयोगकर्ताओं को कार्यों को तेजी से पूरा करने की अनुमति देता है, जिससे उनकी उत्पादकता बढ़ती है।
- ब्रांड की पहचान (Brand Identity): इंटरफ़ेस का डिज़ाइन और अनुभव किसी ब्रांड की पहचान को मजबूत कर सकता है, जिससे यह प्रतिस्पर्धियों से अलग दिखता है।
अच्छे इंटरफ़ेस डिज़ाइन के प्रमुख तत्व:
- स्पष्टता (Clarity): इंटरफ़ेस के सभी तत्व, जैसे आइकन, लेबल और संदेश, स्पष्ट और समझने में आसान होने चाहिए। उपयोगकर्ता को यह जानने में कोई भ्रम नहीं होना चाहिए कि किसी तत्व का क्या कार्य है।
- संगति (Consistency): पूरे एप्लिकेशन में डिज़ाइन तत्वों (जैसे रंग, फ़ॉन्ट, आइकन) और इंटरैक्शन पैटर्न में संगति होनी चाहिए। यह उपयोगकर्ताओं को अनुमान लगाने और सीखने में मदद करता है कि एप्लिकेशन कैसे काम करता है।
- उपयोगकर्ता नियंत्रण और स्वतंत्रता (User Control and Freedom): उपयोगकर्ताओं को यह महसूस होना चाहिए कि वे नियंत्रण में हैं। उन्हें आसानी से कार्यों को पूर्ववत (undo) और फिर से करने (redo) में सक्षम होना चाहिए और अनपेक्षित स्थितियों से आसानी से बाहर निकलने का एक स्पष्ट तरीका होना चाहिए।
- प्रतिक्रिया (Feedback): सिस्टम को उपयोगकर्ता की हर क्रिया पर तुरंत और स्पष्ट प्रतिक्रिया देनी चाहिए। उदाहरण के लिए, जब कोई बटन क्लिक किया जाता है, तो उसे दिखना चाहिए कि उसे क्लिक किया गया है, या फ़ाइल डाउनलोड होने पर एक प्रगति बार दिखाना चाहिए।
- क्षमा (Forgiveness): एक अच्छा इंटरफ़ेस उपयोगकर्ता की छोटी-मोटी गलतियों को क्षमा कर देता है। उदाहरण के लिए, किसी महत्वपूर्ण क्रिया (जैसे खाता हटाना) से पहले एक पुष्टिकरण संवाद पूछना।
- सौंदर्य और न्यूनतम डिजाइन (Aesthetic and Minimalist Design): एक आकर्षक और साफ-सुथरा डिज़ाइन उपयोगकर्ता अनुभव को बेहतर बनाता है। इंटरफ़ेस में अप्रासंगिक जानकारी नहीं होनी चाहिए, केवल आवश्यक तत्व ही दिखाए जाने चाहिए।
(b) प्रोजेक्ट मेट्रिक्स और उनके प्रकार
प्रोजेक्ट मेट्रिक्स (Project Metrics):
प्रोजेक्ट मेट्रिक्स वे मात्रात्मक माप हैं जिनका उपयोग सॉफ्टवेयर प्रोजेक्ट की स्थिति, गुणवत्ता और स्वास्थ्य को ट्रैक और प्रबंधित करने के लिए किया जाता है। ये मेट्रिक्स प्रोजेक्ट मैनेजरों को प्रगति का मूल्यांकन करने, संभावित जोखिमों की पहचान करने और सूचित निर्णय लेने में मदद करते हैं।
प्रोजेक्ट मेट्रिक्स के विभिन्न प्रकार निम्नलिखित हैं:
- प्रक्रिया मेट्रिक्स (Process Metrics): ये मेट्रिक्स सॉफ्टवेयर विकास प्रक्रिया की दक्षता और प्रभावशीलता को मापते हैं। इनका उद्देश्य प्रक्रिया में सुधार के अवसरों की पहचान करना है। उदाहरण: दोष हटाने की दक्षता (Defect Removal Efficiency – DRE) यह मेट्रिक मापता है कि विकास टीम उत्पाद को अंतिम-उपयोगकर्ता को देने से पहले कितने दोषों को ढूंढ और ठीक कर पाती है। DRE = E / (E + D) जहाँ, E = डिलीवरी से पहले पाई गई त्रुटियों की संख्या, और D = डिलीवरी के बाद ग्राहक द्वारा पाई गई त्रुटियों की संख्या। एक उच्च DRE एक प्रभावी गुणवत्ता आश्वासन प्रक्रिया को इंगित करता है।
- उत्पाद मेट्रिक्स (Product Metrics): ये मेट्रिक्स सॉफ्टवेयर उत्पाद की विशेषताओं को मापते हैं। वे आकार, जटिलता और गुणवत्ता जैसे पहलुओं पर ध्यान केंद्रित करते हैं। उदाहरण: साइक्लोमैटिक कॉम्प्लेक्सिटी (Cyclomatic Complexity) यह कोड की तार्किक जटिलता को मापता है। यह एक मॉड्यूल का परीक्षण करने के लिए आवश्यक स्वतंत्र पथों की संख्या की गणना करता है। उच्च साइक्लोमैटिक कॉम्प्लेक्सिटी वाले मॉड्यूल का परीक्षण और रखरखाव करना अधिक कठिन होता है और उनमें दोष होने की संभावना अधिक होती है।
- परियोजना मेट्रिक्स (Project Metrics): ये मेट्रिक्स परियोजना की समग्र विशेषताओं और प्रगति का वर्णन करते हैं। वे लागत, शेड्यूल और टीम के प्रदर्शन जैसे कारकों को ट्रैक करते हैं। उदाहरण: प्रयास विचरण (Effort Variance) यह मेट्रिक नियोजित प्रयास और वास्तविक प्रयास के बीच के अंतर को मापता है। यह परियोजना के बजट और समय-सीमा पर नियंत्रण रखने में मदद करता है। Effort Variance (%) = [(Actual Effort – Planned Effort) / Planned Effort] * 100 एक सकारात्मक विचरण इंगित करता है कि परियोजना नियोजित से अधिक प्रयास ले रही है, जो एक संभावित समस्या का संकेत हो सकता है।
Q3. (a) What is prototyping model ? Explain the problems and advantages of prototyping model in detail. (b) Compare and contrast verson control with change control.
Ans.
(a) प्रोटोटाइपिंग मॉडल: समस्याएं और लाभ
प्रोटोटाइपिंग मॉडल क्या है?
प्रोटोटाइपिंग मॉडल एक सॉफ्टवेयर विकास मॉडल है जिसमें अंतिम उत्पाद का एक प्रारंभिक, अधूरा संस्करण (जिसे प्रोटोटाइप कहा जाता है) जल्दी से बनाया जाता है। यह प्रोटोटाइप फिर अंतिम उपयोगकर्ताओं द्वारा मूल्यांकन के लिए प्रस्तुत किया जाता है ताकि वे प्रतिक्रिया दे सकें। इस प्रतिक्रिया के आधार पर, प्रोटोटाइप को संशोधित किया जाता है और यह चक्र तब तक दोहराया जाता है जब तक कि उपयोगकर्ता संतुष्ट न हो जाए। एक बार जब आवश्यकताएं स्पष्ट हो जाती हैं, तो इस प्रोटोटाइप को या तो हटा दिया जाता है (थ्रोअवे प्रोटोटाइपिंग) या इसे आधार बनाकर अंतिम उत्पाद विकसित किया जाता है (इवोल्यूशनरी प्रोटोटाइपिंग)।
प्रोटोटाइपिंग मॉडल के लाभ (Advantages):
- बेहतर आवश्यकता विश्लेषण: प्रोटोटाइप उपयोगकर्ताओं को सिस्टम का एक वास्तविक अनुभव देता है, जिससे वे अपनी आवश्यकताओं को अधिक स्पष्ट रूप से बता पाते हैं। यह गलतफहमी और आवश्यकताओं में अस्पष्टता को कम करता है।
- प्रारंभिक उपयोगकर्ता प्रतिक्रिया: विकास प्रक्रिया में बहुत जल्दी उपयोगकर्ताओं से प्रतिक्रिया मिल जाती है, जिससे डिजाइन में सुधार और बाद में बड़े बदलावों से बचा जा सकता है।
- जोखिम में कमी: चूँकि उपयोगकर्ता प्रोटोटाइप के साथ इंटरैक्ट करते हैं, इसलिए इस बात का जोखिम कम हो जाता है कि अंतिम उत्पाद उपयोगकर्ता की अपेक्षाओं को पूरा नहीं करेगा।
- उपयोगकर्ता की भागीदारी में वृद्धि: यह मॉडल उपयोगकर्ता को विकास प्रक्रिया में सक्रिय रूप से शामिल करता है, जिससे अंतिम उत्पाद के प्रति उनका स्वामित्व और स्वीकृति बढ़ती है।
- जटिल और अस्पष्ट प्रणालियों के लिए उपयुक्त: जब आवश्यकताएं स्पष्ट नहीं होती हैं, विशेष रूप से यूजर इंटरफेस के लिए, प्रोटोटाइपिंग सबसे अच्छा तरीका होता है।
प्रोटोटाइपिंग मॉडल की समस्याएं (Problems):
- अपूर्ण उत्पाद की गलतफहमी: उपयोगकर्ता प्रोटोटाइप को एक लगभग तैयार उत्पाद समझ सकते हैं और उसकी प्रदर्शन, विश्वसनीयता और मजबूती के बारे में अवास्तविक उम्मीदें रख सकते हैं। वे यह नहीं समझ पाते कि यह केवल एक डमी है।
- “कोड-एंड-फिक्स” मानसिकता: प्रोटोटाइपिंग एक अनौपचारिक “कोड-और-फिक्स” दृष्टिकोण को प्रोत्साहित कर सकता है, जिसमें उचित योजना, डिजाइन और दस्तावेज़ीकरण की उपेक्षा की जाती है।
- खराब कार्यान्वयन: प्रोटोटाइप को जल्दी बनाने के लिए, डेवलपर अक्षम एल्गोरिदम या अनुपयुक्त प्रोग्रामिंग भाषाओं का उपयोग कर सकते हैं। यदि इस प्रोटोटाइप को अंतिम प्रणाली में विकसित किया जाता है, तो यह गुणवत्ता और रखरखाव की समस्याएं पैदा कर सकता है।
- समय और लागत: प्रोटोटाइप बनाने में समय और संसाधन लगते हैं। यदि प्रोटोटाइप को अंततः फेंक दिया जाता है, तो यह प्रयास व्यर्थ लग सकता है, हालांकि यह आवश्यकताओं को स्पष्ट करने में मदद करता है।
- प्रणाली का दायरा बढ़ना: उपयोगकर्ता प्रोटोटाइप को देखकर लगातार नई सुविधाओं की मांग कर सकते हैं, जिससे परियोजना का दायरा और जटिलता अनियंत्रित रूप से बढ़ सकती है।
(b) संस्करण नियंत्रण और परिवर्तन नियंत्रण की तुलना
संस्करण नियंत्रण (Version Control) और परिवर्तन नियंत्रण (Change Control) दोनों सॉफ्टवेयर विकास में महत्वपूर्ण प्रक्रियाएं हैं, लेकिन उनके उद्देश्य और दायरे अलग-अलग हैं।
पहलू
संस्करण नियंत्रण (Version Control)
परिवर्तन नियंत्रण (Change Control)
परिभाषा
यह समय के साथ सोर्स कोड, दस्तावेज़ों और अन्य फाइलों में किए गए परिवर्तनों को प्रबंधित करने की प्रक्रिया है। यह ट्रैक करता है कि किसने, क्या और कब बदला।
यह परियोजना के दायरे, आवश्यकताओं, बजट या शेड्यूल में किसी भी बदलाव को प्रबंधित करने के लिए एक औपचारिक प्रक्रिया है।
दायरा
इसका दायरा तकनीकी और संकीर्ण है। यह व्यक्तिगत फाइलों और कोडबेस पर केंद्रित है।
इसका दायरा व्यापक और प्रबंधकीय है। यह पूरी परियोजना को प्रभावित करता है।
उद्देश्य
कोड के विभिन्न संस्करणों को बनाए रखना, टीम के सदस्यों के बीच सहयोग को सक्षम करना, और पिछली अवस्थाओं में वापस जाने की क्षमता प्रदान करना।
यह सुनिश्चित करना कि किसी भी बदलाव का सावधानीपूर्वक मूल्यांकन, अनुमोदन और दस्तावेजीकरण किया जाए ताकि परियोजना पर नकारात्मक प्रभाव को कम किया जा सके।
प्रक्रिया
इसमें ‘कमिट’, ‘ब्रांच’, ‘मर्ज’ और ‘पुल’ जैसी क्रियाएं शामिल हैं। यह आमतौर पर डेवलपर्स द्वारा दैनिक रूप से उपयोग किया जाता है।
इसमें एक परिवर्तन अनुरोध (Change Request), प्रभाव विश्लेषण, चेंज कंट्रोल बोर्ड (CCB) द्वारा समीक्षा, अनुमोदन/अस्वीकृति, और संचार शामिल है।
उपकरण
Git, Subversion (SVN), Mercurial जैसे संस्करण नियंत्रण सिस्टम (VCS)।
Jira, Bugzilla जैसे इश्यू ट्रैकिंग सिस्टम, और औपचारिक दस्तावेज़ और बैठकें।
सारांश में अंतर:
संस्करण नियंत्रण इस बात से संबंधित है कि कैसे कोड में परिवर्तन किए जाते हैं और उन्हें ट्रैक किया जाता है। यह एक तकनीकी गतिविधि है।
परिवर्तन नियंत्रण इस बात से संबंधित है कि क्या और क्यों एक परिवर्तन किया जाना चाहिए। यह एक प्रबंधकीय प्रक्रिया है।
एक डेवलपर संस्करण नियंत्रण का उपयोग करके कोड की एक नई सुविधा के लिए एक ब्रांच बना सकता है। लेकिन उस सुविधा को परियोजना में जोड़ने का निर्णय परिवर्तन नियंत्रण प्रक्रिया के माध्यम से लिया जाएगा।
Q4. (a) Draw Level-0, Level-l and Level-2 DFDs for Grade-Card Generation System. Make and mention the necessary assumptions. (b) What is meant by ‘Software Reengineering’ ? Explain the phases of Software Reengineering Life Cycle.
Ans.
(a) ग्रेड-कार्ड जनरेशन सिस्टम के लिए DFD (लेवल-0, लेवल-1, और लेवल-2)
आवश्यक धारणाएं (Assumptions):
- बाहरी इकाइयां (External Entities) हैं: छात्र (Student) और व्यवस्थापक/शिक्षक (Admin/Teacher) ।
- व्यवस्थापक छात्रों का विवरण दर्ज करता है और अंक अपडेट करता है।
- छात्र अपने ग्रेड-कार्ड देखने के लिए लॉगिन करता है और अनुरोध करता है।
- सिस्टम में छात्र डेटा (Student_Data) और अंक डेटा (Marks_Data) नामक डेटा स्टोर हैं।
- ग्रेड की गणना पूर्व-परिभाषित नियमों के आधार पर की जाती है।
लेवल-0 DFD (संदर्भ आरेख – Context Diagram):
लेवल-0 DFD सिस्टम को एक एकल प्रक्रिया के रूप में दिखाता है और बाहरी इकाइयों के साथ इसके इंटरैक्शन को दर्शाता है।
(चित्र का विवरण):
- केंद्र में एक सर्कल है जिस पर लिखा है ” 0. ग्रेड-कार्ड जनरेशन सिस्टम “।
- बाईं ओर एक बॉक्स है ” व्यवस्थापक/शिक्षक “। एक तीर इस बॉक्स से सिस्टम की ओर जाता है, जिस पर “छात्र विवरण और अंक” लिखा है।
- दाईं ओर एक बॉक्स है ” छात्र “। एक तीर छात्र से सिस्टम की ओर जाता है, जिस पर “ग्रेड-कार्ड अनुरोध” लिखा है। एक और तीर सिस्टम से छात्र की ओर जाता है, जिस पर “जनरेटेड ग्रेड-कार्ड” लिखा है।
लेवल-1 DFD:
यह लेवल-0 की मुख्य प्रक्रिया को प्रमुख उप-प्रक्रियाओं में विभाजित करता है।
(चित्र का विवरण):
- 1.0 उपयोगकर्ता प्रमाणीकरण (Authenticate User): व्यवस्थापक और छात्र दोनों से “लॉगिन क्रेडेंशियल” इनपुट के रूप में लेता है। “छात्र_डेटा” स्टोर से डेटा सत्यापित करता है और “प्रमाणित उपयोगकर्ता” आउटपुट देता है।
- 2.0 डेटा प्रबंधन (Manage Data): व्यवस्थापक से “छात्र विवरण और अंक” इनपुट लेता है और D1: छात्र_डेटा और D2: अंक_डेटा स्टोर को अपडेट करता है।
- 3.0 ग्रेड की गणना करें (Calculate Grades): “प्रमाणित उपयोगकर्ता” (छात्र) से “ग्रेड-कार्ड अनुरोध” लेता है। D1 से “छात्र विवरण” और D2 से “अंक” प्राप्त करता है। यह “गणना किए गए ग्रेड और GPA” को आउटपुट करता है।
- 4.0 रिपोर्ट जेनरेट करें (Generate Report): प्रक्रिया 3.0 से “गणना किए गए ग्रेड और GPA” को इनपुट के रूप में लेता है और छात्र को “जनरेटेड ग्रेड-कार्ड” भेजता है।
लेवल-2 DFD (प्रक्रिया 3.0 “ग्रेड की गणना करें” के लिए):
यह लेवल-1 की एक प्रक्रिया (“ग्रेड की गणना करें”) को और अधिक विस्तृत करता है।
(चित्र का विवरण):
- 3.1 विषयवार अंक प्राप्त करें (Fetch Subject-wise Marks): छात्र से “ग्रेड-कार्ड अनुरोध” प्राप्त होता है और D2: अंक_डेटा स्टोर से संबंधित “अंक” प्राप्त करता है।
- 3.2 ग्रेड और ग्रेड अंक की गणना करें (Calculate Grade and Grade Points): प्रक्रिया 3.1 से “अंक” लेता है, पूर्व-परिभाषित नियमों का उपयोग करके प्रत्येक विषय के लिए ग्रेड (A, B, C) और ग्रेड अंक (10, 9, 8) की गणना करता है।
- 3.3 GPA की गणना करें (Calculate GPA): प्रक्रिया 3.2 से “ग्रेड अंक” लेता है और SGPA/CGPA की गणना करता है।
- 3.4 परिणाम संकलित करें (Compile Result): सभी गणना किए गए डेटा (“गणना किए गए ग्रेड और GPA”) को एकत्रित करता है और इसे प्रक्रिया 4.0 “रिपोर्ट जेनरेट करें” को भेजता है।
(b) सॉफ्टवेयर रीइंजीनियरिंग और उसके जीवन चक्र के चरण
सॉफ्टवेयर रीइंजीनियरिंग क्या है?
सॉफ्टवेयर रीइंजीनियरिंग एक मौजूदा सॉफ्टवेयर सिस्टम की जांच करने और उसे फिर से बनाने की प्रक्रिया है ताकि इसे एक नए रूप में पुनर्गठित किया जा सके। इसका मुख्य उद्देश्य सिस्टम की कार्यक्षमता को बदले बिना उसकी गुणवत्ता, रखरखाव क्षमता, प्रदर्शन या अन्य गैर-कार्यात्मक विशेषताओं में सुधार करना है। यह अक्सर पुराने (विरासत) सिस्टम पर लागू होता है जिन्हें समझना, संशोधित करना और बनाए रखना मुश्किल हो गया है। रीइंजीनियरिंग में आमतौर पर रिवर्स इंजीनियरिंग, कोड पुनर्गठन और फॉरवर्ड इंजीनियरिंग शामिल है।
सॉफ्टवेयर रीइंजीनियरिंग जीवन चक्र के चरण (Phases):
- इन्वेंटरी विश्लेषण (Inventory Analysis): इस चरण में, संगठन अपने सभी सॉफ्टवेयर सिस्टम का एक पोर्टफोलियो बनाता है। प्रत्येक सिस्टम का मूल्यांकन उसकी व्यावसायिक प्रासंगिकता, तकनीकी गुणवत्ता और रखरखाव की लागत के आधार पर किया जाता है। इस विश्लेषण के आधार पर, उन सिस्टम की पहचान की जाती है जो रीइंजीनियरिंग के लिए सबसे अच्छे उम्मीदवार हैं।
- दस्तावेज़ पुनर्गठन (Document Restructuring): अक्सर, पुराने सिस्टम के दस्तावेज़ या तो मौजूद नहीं होते, अधूरे होते हैं या पुराने हो चुके होते हैं। इस चरण में, मौजूदा दस्तावेज़ों का विश्लेषण किया जाता है और उन्हें अद्यतन या फिर से बनाया जाता है ताकि वे सिस्टम की वर्तमान स्थिति को सही ढंग से दर्शा सकें।
- रिवर्स इंजीनियरिंग (Reverse Engineering): यह मौजूदा सिस्टम के सोर्स कोड का विश्लेषण करके उसके डिजाइन और विनिर्देशों को समझने की प्रक्रिया है। इसका लक्ष्य सिस्टम “क्या करता है” और “कैसे करता है” को निकालना है। आउटपुट आमतौर पर डिजाइन मॉडल (जैसे क्लास डायग्राम, डेटा फ्लो डायग्राम) होते हैं। यह आगे के विश्लेषण के लिए एक आधार प्रदान करता है।
- कोड पुनर्गठन (Code Restructuring): इस चरण में, सोर्स कोड को उसकी बाहरी कार्यक्षमता को बदले बिना बेहतर बनाने के लिए संशोधित किया जाता है। इसमें कोड को फिर से स्वरूपित करना, जटिल तार्किक संरचनाओं को सरल बनाना, और कोड को अधिक मॉड्यूलर बनाना शामिल हो सकता है ताकि इसे समझना और बनाए रखना आसान हो।
- डेटा पुनर्गठन (Data Restructuring): कोड पुनर्गठन के समान, यह चरण मौजूदा डेटा संरचनाओं (जैसे डेटाबेस स्कीमा) का विश्लेषण और पुनर्गठन करता है। इसमें डेटाबेस को सामान्य बनाना (normalize), डेटा मॉडल को सरल बनाना या एक पुराने फ़ाइल सिस्टम से एक आधुनिक संबंधपरक डेटाबेस में माइग्रेट करना शामिल हो सकता है।
- फॉरवर्ड इंजीनियरिंग (Forward Engineering): यह रीइंजीनियरिंग का अंतिम चरण है। रिवर्स इंजीनियरिंग से प्राप्त जानकारी और आवश्यकताओं का उपयोग करके, सिस्टम को फिर से बनाया जाता है। डेवलपर एक बेहतर, अधिक आधुनिक वास्तुकला या प्रौद्योगिकी का उपयोग करके एप्लिकेशन को फिर से लागू करते हैं। परिणाम एक पुनर्विकसित प्रणाली है जो बनाए रखने और विस्तारित करने में आसान होती है।
Q5. (a) What is Cyclomatic Complexity ? How is it computed ? Calculate cyclomatic complexity for the program to find the greatest of three numbers. (b) What is Risk Management ? Explain any one technique of the Risk Management.
Ans.
(a) साइक्लोमैटिक कॉम्प्लेक्सिटी: परिभाषा, गणना और उदाहरण
साइक्लोमैटिक कॉम्प्लेक्सिटी क्या है?
साइक्लोमैटिक कॉम्प्लेक्सिटी (Cyclomatic Complexity) थॉमस जे. मैक्केब द्वारा विकसित एक सॉफ्टवेयर मेट्रिक है। इसका उपयोग किसी प्रोग्राम की तार्किक जटिलता को मापने के लिए किया जाता है। यह प्रोग्राम के सोर्स कोड के माध्यम से रैखिक रूप से स्वतंत्र पथों (linearly independent paths) की संख्या की गणना करता है। एक उच्च साइक्लोमैटिक कॉम्प्लेक्सिटी मान यह इंगित करता है कि कोड अधिक जटिल है, जिसे समझना, परीक्षण करना और बनाए रखना अधिक कठिन है। यह आमतौर पर प्रति मॉड्यूल या प्रति फ़ंक्शन के आधार पर मापा जाता है।
इसकी गणना कैसे की जाती है?
साइक्लोमैटिक कॉम्प्लेक्सिटी, जिसे V(G) से दर्शाया जाता है, की गणना प्रोग्राम के कंट्रोल फ्लो ग्राफ (CFG) का उपयोग करके की जा सकती है। CFG में, नोड कोड के कमांड ब्लॉक का प्रतिनिधित्व करते हैं, और एज नोड्स के बीच नियंत्रण के प्रवाह का प्रतिनिधित्व करते हैं। इसकी गणना के तीन मुख्य तरीके हैं:
- किनारों और नोड्स का उपयोग करके: V(G) = E – N + 2 जहां E कंट्रोल फ्लो ग्राफ में किनारों (edges) की संख्या है और N नोड्स (nodes) की संख्या है।
- विभाजित क्षेत्रों का उपयोग करके: V(G) = ग्राफ द्वारा विभाजित क्षेत्रों (regions) की संख्या।
- प्रिडिकेट नोड्स का उपयोग करके: V(G) = P + 1 जहां P प्रिडिकेट नोड्स (यानी, निर्णय बिंदु वाले नोड्स जैसे ‘if’, ‘while’, ‘for’, ‘case’) की संख्या है। यह सबसे सरल और सबसे आम तरीका है।
तीन संख्याओं में से सबसे बड़ी संख्या खोजने के प्रोग्राम के लिए गणना:
आइए तीन संख्याओं (a, b, c) में से सबसे बड़ी संख्या खोजने के लिए स्यूडोकोड पर विचार करें: 1. START 2. read a, b, c 3. if (a > b) then 4. if (a > c) then 5. print a 6. else 7. print c 8. endif 9. else 10. if (b > c) then 11. print b 12. else 13. print c 14. endif 15. endif 16. END हम प्रिडिकेट नोड्स (P) की गणना करके सबसे सरल विधि का उपयोग करेंगे।
- पहला निर्णय बिंदु (प्रिडिकेट) पंक्ति 3 पर है: `if (a > b)`
- दूसरा निर्णय बिंदु पंक्ति 4 पर है: `if (a > c)`
- तीसरा निर्णय बिंदु पंक्ति 10 पर है: `if (b > c)`
यहां कुल 3 प्रिडिकेट नोड्स (P) हैं।
सूत्र का उपयोग करके: V(G) = P + 1
V(G) = 3 + 1 = 4
इसलिए, इस प्रोग्राम के लिए साइक्लोमैटिक कॉम्प्लेक्सिटी 4 है । इसका मतलब है कि इस कोड का पूरी तरह से परीक्षण करने के लिए कम से कम 4 स्वतंत्र पथों को कवर करने वाले टेस्ट केस की आवश्यकता है।
(b) जोखिम प्रबंधन और उसकी एक तकनीक
जोखिम प्रबंधन (Risk Management) क्या है?
जोखिम प्रबंधन एक सॉफ्टवेयर परियोजना में संभावित समस्याओं (जोखिमों) की पहचान करने, उनका विश्लेषण करने और उन्हें नियंत्रित करने की एक सक्रिय प्रक्रिया है, इससे पहले कि वे वास्तविक समस्याएं बन जाएं। इसका उद्देश्य दुर्भाग्यपूर्ण घटनाओं की संभावना या प्रभाव को कम करना और परियोजना के लक्ष्यों को सफलतापूर्वक प्राप्त करने की संभावना को बढ़ाना है। जोखिम कुछ भी हो सकता है जो परियोजना की सफलता, जैसे कि शेड्यूल, बजट, या गुणवत्ता को नकारात्मक रूप से प्रभावित कर सकता है।
जोखिम प्रबंधन की एक तकनीक: जोखिम न्यूनीकरण, निगरानी और प्रबंधन (Risk Mitigation, Monitoring, and Management – RMMM)
RMMM एक व्यापक तकनीक है जिसका उपयोग पहचाने गए जोखिमों को प्रबंधित करने के लिए किया जाता है। यह केवल जोखिमों की सूची बनाने से आगे जाती है और प्रत्येक जोखिम के लिए एक विस्तृत कार्य योजना विकसित करती है। RMMM प्रक्रिया में निम्नलिखित चरण शामिल हैं:
- जोखिम की पहचान (Risk Identification): परियोजना की शुरुआत में, टीम संभावित जोखिमों की पहचान करने के लिए मंथन करती है। इन जोखिमों को श्रेणियों में बांटा जा सकता है, जैसे – तकनीकी जोखिम (प्रौद्योगिकी में बदलाव), परियोजना जोखिम (बजट या शेड्यूल की समस्याएं), और व्यावसायिक जोखिम (बाजार में बदलाव)।
- जोखिम विश्लेषण और प्राथमिकता (Risk Analysis and Prioritization): प्रत्येक पहचाने गए जोखिम का मूल्यांकन उसकी घटित होने की संभावना और यदि वह घटित होता है तो उसके प्रभाव के आधार पर किया जाता है। इन दो कारकों के आधार पर, जोखिमों को प्राथमिकता दी जाती है ताकि टीम सबसे महत्वपूर्ण जोखिमों पर ध्यान केंद्रित कर सके।
- जोखिम न्यूनीकरण (Risk Mitigation): यह एक सक्रिय दृष्टिकोण है। प्रत्येक महत्वपूर्ण जोखिम के लिए, टीम एक न्यूनीकरण रणनीति विकसित करती है जिसका उद्देश्य जोखिम की संभावना या प्रभाव को कम करना है।
- उदाहरण: यदि जोखिम है “एक प्रमुख डेवलपर परियोजना छोड़ सकता है,” तो न्यूनीकरण रणनीति हो सकती है: (i) विस्तृत दस्तावेज़ीकरण बनाना, (ii) ज्ञान-साझाकरण सत्र आयोजित करना, और (iii) जोड़ी प्रोग्रामिंग (pair programming) को प्रोत्साहित करना।
- जोखिम निगरानी (Risk Monitoring): परियोजना प्रबंधक नियमित रूप से जोखिमों की निगरानी करता है ताकि यह जांचा जा सके कि उनकी स्थिति में कोई बदलाव तो नहीं हुआ है। इसमें जोखिम की संभावना या प्रभाव में परिवर्तन को ट्रैक करना शामिल है।
- जोखिम प्रबंधन और आकस्मिकता योजना (Risk Management and Contingency Planning): यह एक प्रतिक्रियाशील दृष्टिकोण है। न्यूनीकरण के बावजूद, कुछ जोखिम घटित हो सकते हैं। आकस्मिकता योजना “प्लान बी” है जिसे तब लागू किया जाता है जब कोई जोखिम वास्तविकता बन जाता है।
- उदाहरण: उपरोक्त “प्रमुख डेवलपर के जाने” के जोखिम के लिए, आकस्मिकता योजना यह हो सकती है कि “यदि डेवलपर वास्तव में छोड़ देता है, तो हम तुरंत एक अनुभवी ठेकेदार को नियुक्त करेंगे और परियोजना के कम महत्वपूर्ण हिस्सों को अस्थायी रूप से रोक देंगे।”
RMMM योजना को अक्सर एक जोखिम सूचना पत्र (Risk Information Sheet) के रूप में प्रलेखित किया जाता है, जो प्रत्येक जोखिम, उसकी संभावना, प्रभाव, न्यूनीकरण और आकस्मिकता योजना का विवरण देता है। यह तकनीक सुनिश्चित करती है कि परियोजना टीम जोखिमों के प्रति तैयार है और उनके प्रभाव को प्रभावी ढंग से प्रबंधित कर सकती है।
IGNOU MCS-034 Previous Year Solved Question Paper in English
Q1. (a) What are the different levels of capability maturity model ? Explain each of the levels briefly. (b) What are the steps involved in the process of debugging ? Explain these steps. (c) Define the term ‘Software Quality’. Also, discuss briefly the attributes of software quality. (d) Explain the roles and responsibilities of the following w.r.t. web-applications : (i) Web Master (ii) Application Support Team (iii) Content Development Team (iv) Web Publisher
Ans. (a) Different Levels of Capability Maturity Model (CMM) The Capability Maturity Model (CMM) is a framework for assessing and improving an organization’s software development processes. It was developed by the Software Engineering Institute (SEI). It has five levels, as described below:
- Level 1: Initial: At this level, processes are typically ad-hoc and chaotic. Success depends on individual heroics and chance. The organization does not have a stable environment for development, and projects often exceed budget and timelines.
- Level 2: Repeatable: At this level, basic project management processes are established. Costs, schedules, and functionality are tracked. Experience from past successful projects is applied to current projects. However, processes are still reactive rather than proactive.
- Level 3: Defined: At this level, the software process for the organization is documented and standardized. All projects use an approved, tailored version of the organization’s standard software process. There is a well-defined process for both management and engineering activities.
- Level 4: Managed: At this level, the organization collects detailed measures for both the software process and product quality. Both the processes and products are quantitatively understood and controlled. Statistical quality control is used.
- Level 5: Optimizing: At this level, continuous process improvement is enabled by quantitative feedback and from piloting innovative ideas and technologies. The organization actively identifies weaknesses and rectifies them through process improvements, leading to defect prevention.
(b) Steps Involved in the Process of Debugging
Debugging is the systematic process of finding and fixing defects (bugs) in a piece of software. It begins after testing when a bug is reported. The steps involved in debugging are as follows:
- Defect Identification and Reproduction: The first step is to understand the bug. The developer must be able to reliably reproduce the bug. This involves following the exact steps reported by the user or tester to witness the error firsthand.
- Isolate the Source of the Error: Once the bug is reproducible, the developer needs to find the location in the code where the error is occurring. This can be done using techniques like using debugging tools (e.g., setting breakpoints), analyzing log files, or adding print statements to the code to trace execution.
- Identify the Cause of the Error: After isolating the source, the next step is to understand why the error is happening. This involves analyzing the logic of the code, checking the values of variables, and determining what is different between the expected behavior and the actual behavior.
- Propose a Correction: Having identified the cause, the developer must devise a solution to fix the bug. This solution should not only fix the current problem but also not introduce new problems in other parts of the system.
- Implement the Correction: The proposed correction is implemented in the code. This might involve modifying, adding, or deleting lines of code.
- Test the Fix and Perform Regression Testing: After implementing the fix, it is crucial to verify that the bug is indeed fixed. Additionally, regression testing must be performed to ensure that this change has not introduced any new bugs in other parts of the software.
(c) Software Quality and its Attributes
Software Quality
is defined as the degree to which a software product or system meets specified requirements, both explicit and implied. It is not just the absence of defects, but also how well the software meets user expectations and overall business goals.
The main attributes of software quality, often based on standards like ISO 9126, are as follows:
- Functionality: The capability of the software to provide functions that meet stated and implied user needs. This includes aspects like accuracy, suitability, and security.
- Reliability: The ability of the software to perform its required functions under stated conditions for a specified period of time without failure. It relates to maturity, fault tolerance, and recoverability.
- Efficiency: The ability of the software to provide good performance relative to the amount of resources used (e.g., CPU time, memory, disk space). It relates to time behavior and resource utilization.
- Maintainability: The ease with which the software can be modified to correct defects, adapt to new requirements, or improve performance. This includes ease of analysis, change, and testing.
- Portability: The ability of the software to be transferred from one environment to another. This includes adaptability, installability, and the ability to co-exist with other hardware or software configurations.
–
Usability:
The ease with which users can learn, operate, and be satisfied with the software. It includes attributes like understandability, learnability, and operability.
(d) Roles and Responsibilities w.r.t. Web-Applications
- (i) Web Master: The Web Master is responsible for the overall technical management and maintenance of a web application. Responsibilities include: server maintenance, ensuring website uptime and performance, implementing security measures, checking for broken links, and managing backups. They are often responsible for the technical structure and navigation of the website.
- (ii) Application Support Team: This team provides assistance to users after the web application has been deployed. Their primary responsibilities are: troubleshooting end-user issues, identifying and reporting bugs to the development team, managing helpdesks, creating user guides, and answering user queries. They act as a bridge between the user and the development team.
- (iii) Content Development Team: This team is responsible for creating all the content that appears on the website. This includes writing text, articles, blog posts, and creating or acquiring images, graphics, and videos. They ensure that the content is accurate, relevant, engaging, and aligns with the brand’s guidelines.
- (iv) Web Publisher: The Web Publisher takes the content created by the content development team and puts it live on the website, typically using a Content Management System (CMS). Their responsibilities include formatting the content correctly, ensuring it looks right on different devices, and scheduling the content to be published at the right time. They are the final gatekeepers of content quality before it goes live.
Q2. (a) What is the need of Interface design ? Explain the major elements of a good Interface design. (b) What are project-metrics ? Explain different types of project metrics with an example for each.
Ans. (a) Need for Interface Design and Major Elements of a Good Interface Design Need for Interface Design: User Interface (UI) design is a critical link between the user and the software. The need for good interface design stems from several key reasons:
- Improved Usability: A good UI helps users to operate the software easily and efficiently. It reduces the learning curve and enables the user to achieve their goals quickly.
- User Satisfaction: When an interface is intuitive, attractive, and easy to use, the user’s experience is positive, leading to greater satisfaction and loyalty towards the product.
- Reduced Errors: A clear and consistent design prevents users from making mistakes. If an error does occur, a good interface helps in correcting it.
- Increased Productivity: An efficient interface allows users to complete tasks faster, thereby increasing their productivity.
- Brand Identity: The design and feel of the interface can reinforce a brand’s identity, making it stand out from competitors.
Major Elements of a Good Interface Design:
- Clarity: All elements of the interface, such as icons, labels, and messages, should be clear and easy to understand. The user should have no confusion about what an element does.
- Consistency: There should be consistency in design elements (like colors, fonts, icons) and interaction patterns throughout the application. This helps users learn and predict how the application works.
- User Control and Freedom: Users should feel in control. They should be able to easily undo and redo actions and have a clear way to exit from unwanted situations.
- Feedback: The system should provide immediate and clear feedback for every user action. For example, a button should look clicked when pressed, or a progress bar should be shown for a file download.
- Forgiveness: A good interface is forgiving of minor user mistakes. For instance, asking for a confirmation dialog before a critical action (like deleting an account).
- Aesthetic and Minimalist Design: A clean and visually appealing design enhances the user experience. Interfaces should not contain irrelevant information; only essential elements should be displayed.
(b) Project Metrics and Their Types
Project Metrics:
Project metrics are quantifiable measures used to track and manage the status, quality, and health of a software project. These metrics help project managers to assess progress, identify potential risks, and make informed decisions.
The different types of project metrics are as follows:
- Process Metrics: These metrics measure the efficiency and effectiveness of the software development process. Their purpose is to identify opportunities for process improvement. Example: Defect Removal Efficiency (DRE) This metric measures how many defects the development team finds and fixes before the product is delivered to the end-user. DRE = E / (E + D) Where, E = Number of errors found before delivery, and D = Number of errors found by the customer after delivery. A high DRE indicates an effective quality assurance process.
- Product Metrics: These metrics measure the characteristics of the software product itself. They focus on aspects like size, complexity, and quality. Example: Cyclomatic Complexity This measures the logical complexity of the code. It calculates the number of independent paths required to test a module. Modules with high cyclomatic complexity are harder to test and maintain and are more prone to defects.
- Project Metrics: These metrics describe the overall characteristics and progress of the project. They track factors like cost, schedule, and team performance. Example: Effort Variance This metric measures the difference between the planned effort and the actual effort spent. It helps in controlling the project’s budget and timeline. Effort Variance (%) = [(Actual Effort – Planned Effort) / Planned Effort] * 100 A positive variance indicates that the project is taking more effort than planned, which could be a sign of a potential problem.
Q3. (a) What is prototyping model ? Explain the problems and advantages of prototyping model in detail. (b) Compare and contrast verson control with change control.
Ans. (a) Prototyping Model: Problems and Advantages What is the Prototyping Model? The prototyping model is a software development model in which an early, incomplete version of the final product (called a prototype) is built quickly. This prototype is then presented to the end-users for evaluation so they can provide feedback. Based on this feedback, the prototype is refined, and this cycle is repeated until the user is satisfied. Once the requirements are clear, this prototype is either discarded (throwaway prototyping) or used as a basis to develop the final product (evolutionary prototyping). Advantages of the Prototyping Model:
- Better Requirements Analysis: The prototype gives users a tangible feel of the system, allowing them to state their needs more clearly. This reduces misunderstandings and ambiguity in requirements.
- Early User Feedback: Feedback is received very early in the development process, which helps in refining the design and avoiding major changes later on.
- Reduced Risk: Since users interact with the prototype, the risk that the final product will not meet user expectations is significantly reduced.
- Increased User Involvement: This model actively involves the user in the development process, which increases their sense of ownership and acceptance of the final product.
- Suitable for Complex and Vague Systems: When requirements are not clear, especially for the user interface, prototyping is the best approach.
Problems of the Prototyping Model:
- Misunderstanding of the Incomplete Product: Users might mistake the prototype for a nearly finished product and have unrealistic expectations about its performance, reliability, and robustness. They may not understand that it is just a dummy.
- “Code-and-Fix” Mentality: Prototyping can encourage an informal “code-and-fix” approach, where proper planning, design, and documentation are neglected.
- Poor Implementation: To build the prototype quickly, developers might use inefficient algorithms or unsuitable programming languages. If this prototype is evolved into the final system, it can lead to quality and maintenance problems.
- Time and Cost: Building a prototype takes time and resources. If the prototype is eventually thrown away, this effort might seem wasted, although it helps clarify requirements.
- Scope Creep: Seeing the prototype, users might continuously demand new features, causing the project’s scope and complexity to grow uncontrollably.
(b) Comparison of Version Control and Change Control
Version Control and Change Control are both crucial processes in software development, but they have different purposes and scopes.
| Aspect | Version Control | Change Control |
|---|---|---|
Definition |
It is the process of managing changes made to source code, documents, and other files over time. It tracks who changed what, and when. | It is a formal process for managing any change to the project’s scope, requirements, budget, or schedule. |
Scope |
Its scope is technical and narrow. It focuses on individual files and the codebase. | Its scope is broad and managerial. It affects the entire project. |
Objective |
To maintain different versions of the code, enable collaboration among team members, and provide the ability to revert to previous states. | To ensure that any change is carefully evaluated, approved, and documented to minimize negative impact on the project. |
Process |
Involves actions like ‘commit’, ‘branch’, ‘merge’, and ‘pull’. It is typically used by developers on a daily basis. | Involves a Change Request, impact analysis, review by a Change Control Board (CCB), approval/rejection, and communication. |
Tools |
Version Control Systems (VCS) like Git, Subversion (SVN), Mercurial. | Issue tracking systems like Jira, Bugzilla, and formal documents and meetings. |
Difference in a Nutshell: Version control is concerned with how changes are made and tracked in the code. It is a technical activity. Change control is concerned with whether and why a change should be made. It is a managerial process. A developer might use version control to create a branch for a new feature in the code. But the decision to add that feature to the project would be made through the change control process.
Q4. (a) Draw Level-0, Level-l and Level-2 DFDs for Grade-Card Generation System. Make and mention the necessary assumptions. (b) What is meant by ‘Software Reengineering’ ? Explain the phases of Software Reengineering Life Cycle.
Ans. (a) DFDs for Grade-Card Generation System (Level-0, Level-1, and Level-2) Necessary Assumptions:
- The external entities are: Student and Admin/Teacher .
- The Admin enters student details and updates marks.
- The Student logs in and requests to view their grade-card.
- The system has data stores named Student_Data and Marks_Data .
- Grades are calculated based on pre-defined rules.
Level-0 DFD (Context Diagram): The Level-0 DFD shows the system as a single process and its interaction with external entities. (Description of the diagram):
- A circle in the center is labeled ” 0. Grade-Card Generation System “.
- A box on the left, ” Admin/Teacher ,” has an arrow pointing to the system, labeled “Student Details & Marks”.
- A box on the right, ” Student ,” has an arrow pointing to the system, labeled “Grade-Card Request,” and another arrow pointing from the system to the Student, labeled “Generated Grade-Card”.
Level-1 DFD: This level breaks down the main process of Level-0 into major sub-processes. (Description of the diagram):
- 1.0 Authenticate User: Takes “Login Credentials” as input from both Admin and Student. Verifies data from the “Student_Data” store and outputs “Authenticated User”.
- 2.0 Manage Data: Takes “Student Details & Marks” as input from the Admin and updates the D1: Student_Data and D2: Marks_Data stores.
- 3.0 Calculate Grades: Takes “Grade-Card Request” from the “Authenticated User” (Student). Fetches “Student Details” from D1 and “Marks” from D2 . It outputs “Calculated Grades & GPA”.
- 4.0 Generate Report: Takes “Calculated Grades & GPA” as input from process 3.0 and sends the “Generated Grade-Card” to the Student.
Level-2 DFD (for Process 3.0 “Calculate Grades”): This level further details one of the processes from Level-1 (“Calculate Grades”). (Description of the diagram):
- 3.1 Fetch Subject-wise Marks: Receives “Grade-Card Request” from the student and fetches the corresponding “Marks” from the D2: Marks_Data store.
- 3.2 Calculate Grade and Grade Points: Takes “Marks” from process 3.1, uses pre-defined rules to calculate the grade (A, B, C) and grade points (10, 9, 8) for each subject.
- 3.3 Calculate GPA: Takes “Grade Points” from process 3.2 and calculates the SGPA/CGPA.
- 3.4 Compile Result: Collects all calculated data (“Calculated Grades & GPA”) and sends it to process 4.0 “Generate Report”.
(b) Software Reengineering and its Life Cycle Phases
What is Software Reengineering?
Software reengineering
is the process of examining and altering an existing software system to reconstitute it in a new form. Its primary objective is to improve the quality, maintainability, performance, or other non-functional attributes of the system without changing its functionality. This is often applied to legacy systems that have become difficult to understand, modify, and maintain. Reengineering typically involves reverse engineering, code restructuring, and forward engineering.
Phases of the Software Reengineering Life Cycle:
- Inventory Analysis: In this phase, the organization creates a portfolio of all its software systems. Each system is evaluated based on its business relevance, technical quality, and maintenance cost. Based on this analysis, systems that are the best candidates for reengineering are identified.
- Document Restructuring: Often, the documentation for legacy systems is either non-existent, incomplete, or outdated. In this phase, existing documentation is analyzed and updated or re-created to accurately reflect the current state of the system.
- Reverse Engineering: This is the process of analyzing the source code of the existing system to understand its design and specifications. The goal is to extract “what” the system does and “how” it does it. The output is typically design models (like class diagrams, data flow diagrams). This provides a basis for further analysis.
- Code Restructuring: In this phase, the source code is modified to improve it without changing its external functionality. This may include reformatting the code, simplifying complex logical structures, and making the code more modular to make it easier to understand and maintain.
- Data Restructuring: Similar to code restructuring, this phase analyzes and reorganizes existing data structures (like database schemas). This may involve normalizing the database, simplifying the data model, or migrating from an old file system to a modern relational database.
- Forward Engineering: This is the final phase of reengineering. Using the information and requirements obtained from reverse engineering, the system is rebuilt. Developers re-implement the application using a better, more modern architecture or technology. The result is a redeveloped system that is easier to maintain and extend.
Q5. (a) What is Cyclomatic Complexity ? How is it computed ? Calculate cyclomatic complexity for the program to find the greatest of three numbers. (b) What is Risk Management ? Explain any one technique of the Risk Management.
Ans. (a) Cyclomatic Complexity: Definition, Computation, and Example What is Cyclomatic Complexity? Cyclomatic Complexity is a software metric developed by Thomas J. McCabe. It is used to measure the logical complexity of a program. It calculates the number of linearly independent paths through the program’s source code. A higher cyclomatic complexity value indicates that the code is more complex, which makes it harder to understand, test, and maintain. It is usually measured on a per-module or per-function basis. How is it computed? Cyclomatic Complexity, denoted as V(G), can be computed using the program’s control flow graph (CFG). In a CFG, nodes represent blocks of commands, and edges represent the flow of control between nodes. There are three main ways to calculate it:
- Using Edges and Nodes: V(G) = E – N + 2 where E is the number of edges and N is the number of nodes in the control flow graph.
- Using Bounded Regions: V(G) = Number of regions the graph is divided into.
- Using Predicate Nodes: V(G) = P + 1 where P is the number of predicate nodes (i.e., nodes with decision points like ‘if’, ‘while’, ‘for’, ‘case’). This is the simplest and most common method.
Calculation for a program to find the greatest of three numbers:
Let’s consider the pseudocode for finding the greatest of three numbers (a, b, c):
1. START2. read a, b, c3. if (a > b) then4. if (a > c) then5. print a6. else7. print c8. endif9. else10. if (b > c) then11. print b12. else13. print c14. endif15. endif16. END
We will use the simplest method by counting the predicate nodes (P).
- The first decision point (predicate) is on line 3: `if (a > b)`
- The second decision point is on line 4: `if (a > c)`
- The third decision point is on line 10: `if (b > c)`
There are a total of 3 predicate nodes (P). Using the formula: V(G) = P + 1 V(G) = 3 + 1 = 4 Therefore, the cyclomatic complexity for this program is 4 . This means that at least 4 test cases covering independent paths are needed to test this code thoroughly. (b) Risk Management and one of its Techniques What is Risk Management? Risk Management is a proactive process of identifying, analyzing, and controlling potential problems (risks) in a software project before they become actual problems. Its goal is to minimize the probability or impact of unfortunate events and to maximize the likelihood of successfully achieving the project’s goals. A risk can be anything that negatively affects the project’s success, such as its schedule, budget, or quality. One Technique of Risk Management: Risk Mitigation, Monitoring, and Management (RMMM) RMMM is a comprehensive technique used to manage identified risks. It goes beyond just listing risks and develops a detailed action plan for each risk. The RMMM process involves the following steps:
- Risk Identification: At the start of the project, the team brainstorms to identify potential risks. These risks can be categorized, for example, as technical risks (changes in technology), project risks (budget or schedule issues), and business risks (changes in the market).
- Risk Analysis and Prioritization: Each identified risk is evaluated based on its probability of occurring and its impact if it does occur. Based on these two factors, risks are prioritized so the team can focus on the most critical ones.
- Risk Mitigation: This is a proactive approach. For each significant risk, the team develops a mitigation strategy aimed at reducing the risk’s probability or impact.
- Example: If the risk is “A key developer might leave the project,” a mitigation strategy could be: (i) creating detailed documentation, (ii) holding knowledge-sharing sessions, and (iii) encouraging pair programming.
- Risk Monitoring: The project manager regularly monitors the risks to check if their status has changed. This includes tracking any change in the risk’s probability or impact.
- Risk Management and Contingency Planning: This is a reactive approach. Despite mitigation, some risks may occur. A contingency plan is the “Plan B” that is executed when a risk becomes a reality.
- Example: For the “key developer leaving” risk mentioned above, the contingency plan might be: “If the developer does leave, we will immediately hire an experienced contractor and temporarily halt work on less critical parts of the project.”
The RMMM plan is often documented in a Risk Information Sheet, which details each risk, its probability, impact, mitigation, and contingency plan. This technique ensures that the project team is prepared for risks and can manage their impact effectively.
Download IGNOU previous Year Question paper download PDFs for MCS-034 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!
Leave a Reply