Introduction to Software Engineering: Characteristics, Emergence of Software Engineering, Software Metrics & Models, Process & Product Metrics. Software Life Cycle Models: Waterfall, Prototype and Spiral Models and their Comparison.
👨💻 Software Engineering का परिचय (Introduction to Software Engineering)
Software Engineering एक ऐसी शाखा है जो संगठित, योजनाबद्ध और अनुशासित तरीके से सॉफ्टवेयर का निर्माण, रखरखाव और मैनेजमेंट करने से संबंधित है।
🧩 1. सॉफ्टवेयर की विशेषताएँ (Characteristics of Software)
- Intangible (अदृश्य) – छू नहीं सकते
- Developed, not manufactured – यह बनाया जाता है, न कि फैक्ट्री में तैयार
- Evolves over time – समय के साथ अपडेट होता है
- Customizable – ज़रूरत के अनुसार बदला जा सकता है
- Complex – बहुत सारे मॉड्यूल और प्रक्रियाएँ होती हैं
- No Wear and Tear – समय से खराब नहीं होता, लेकिन bugs आ सकते हैं
🌟 2. Software Engineering का उदय (Emergence of Software Engineering)
🔁 क्यों ज़रूरी हुआ Software Engineering?
- 1960-70 के दशक में “Software Crisis” आया:
- प्रोजेक्ट्स समय पर पूरे नहीं हो रहे थे
- बजट से ज़्यादा खर्च
- गुणवत्ता (quality) खराब
- मेंटेन करना मुश्किल
इसलिए एक नियमित, व्यवस्थित और प्रोफेशनल तरीका जरूरी हुआ — और यहीं से Software Engineering का विकास हुआ।
📊 3. Software Metrics & Models
📏 Software Metrics (मापदंड)
Software की गुणवत्ता, प्रगति और प्रदर्शन को मापने के लिए जो मानक अपनाए जाते हैं, उन्हें Software Metrics कहते हैं।
उदाहरण:
- LOC (Lines of Code)
- Cyclomatic Complexity
- Defect Density
- Productivity = Output / Effort
🧮 Software Models (मॉडल)
Software का विकास कैसे किया जाए — उसके लिए बनाए गए नियम या ढांचे।
जैसे: Waterfall, Spiral, Agile, V-Model आदि।
⚖️ 4. Process & Product Metrics
🔄 Process Metrics
Software Development Process को मापते हैं।
उदाहरण:
- Time to deliver
- Cost per phase
- Defects per phase
📦 Product Metrics
Software प्रोडक्ट की गुणवत्ता और performance को मापते हैं।
उदाहरण:
- Size (LOC, Function Points)
- Reliability
- Maintainability
- Usability
🧬 5. Software Life Cycle Models (SDLC Models)
1. Waterfall Model (वॉटरफॉल मॉडल)
📌 स्टेप-बाय-स्टेप मॉडल, एक स्टेज पूरी हो जाने के बाद ही अगली शुरू होती है।
| चरण |
|---|
| 1. Requirement Gathering |
| 2. System Design |
| 3. Implementation |
| 4. Testing |
| 5. Deployment |
| 6. Maintenance |
✅ लाभ: सरल और समझने में आसान
❌ नुकसान: बदलाव करना मुश्किल, फ्लेक्सिबल नहीं
2. Prototype Model (प्रोटोटाइप मॉडल)
📌 पहले एक प्रोटोटाइप (डेमो वर्जन) बनाया जाता है, जिसे यूज़र से फीडबैक लेकर बेहतर किया जाता है।
✅ लाभ: यूज़र की जरूरतों को जल्दी समझा जाता है
❌ नुकसान: फाइनल प्रोडक्ट में देरी हो सकती है
3. Spiral Model (स्पाइरल मॉडल)
Spiral Model एक सॉफ्टवेयर डेवलपमेंट मॉडल है जो Waterfall Model और Prototyping Model का मिश्रण है। इसमें विकास प्रक्रिया को चरणों (phases) में विभाजित किया जाता है और हर चरण को बार-बार (स्पाइरल के रूप में) दोहराया जाता है।
📌 यह एक रिस्क आधारित मॉडल है। हर चक्र में 4 चरण होते हैं:
- Planning
- Risk Analysis
- Development
- Evaluation
मुख्य विचार (Key Idea):
“हर फेज में रिस्क एनालिसिस (Risk Analysis) जरूरी है और हर बार सिस्टम को थोड़ा-थोड़ा विकसित किया जाता है।”
📚 मुख्य चरण (Phases of Spiral Model):
- Planning (योजना बनाना):
- आवश्यकताओं (Requirements) को इकट्ठा किया जाता है।
- उद्देश्य (objectives), constraints, और विकल्पों को पहचाना जाता है।
- Risk Analysis (जोखिम विश्लेषण):
- संभावित जोखिमों को पहचाना जाता है।
- उनके समाधान (solutions) खोजे जाते हैं।
- प्रोटोटाइप (Prototype) तैयार किया जा सकता है।
- Engineering (वास्तविक विकास):
- कोडिंग, टेस्टिंग और विकास का कार्य होता है।
- एक संस्करण (version) तैयार किया जाता है।
- Evaluation (मूल्यांकन):
- ग्राहक से फीडबैक लिया जाता है।
- यदि आवश्यक हो तो परिवर्तन किया जाता है।
➡️ फिर अगला चक्र (next spiral) शुरू होता है, जिसमें और ज्यादा refinement किया जाता है।
✅ लाभ: बड़ा और जटिल प्रोजेक्ट के लिए उपयुक्त
❌ नुकसान: महंगा और कठिन प्रबंधन
📋 6. तीनों मॉडल की तुलना (Comparison)
| विशेषता | Waterfall | Prototype | Spiral |
|---|---|---|---|
| लचीलापन (Flexibility) | कम | ज़्यादा | बहुत ज़्यादा |
| यूज़र फीडबैक | नहीं | हाँ | हाँ |
| रिस्क हैंडलिंग | नहीं | कम | अच्छा |
| जटिलता के लिए उपयुक्त | नहीं | सीमित | हाँ |
| लागत | कम | मध्यम | ज़्यादा |
| उपयुक्तता | छोटे प्रोजेक्ट | UI-आधारित | बड़े/जटिल प्रोजेक्ट्स |
📚 निष्कर्ष:
| टॉपिक | सार |
|---|---|
| Software Engineering | सॉफ्टवेयर के निर्माण और रखरखाव की वैज्ञानिक प्रक्रिया |
| Metrics | Software की प्रगति और गुणवत्ता को मापने के तरीके |
| Models | Software बनाने के लिए प्रक्रिया का खाका |
| Waterfall | Step-by-step, rigid |
| Prototype | User feedback आधारित |
| Spiral | Risk analysis पर केंद्रित |
Software Project Management: Size Estimation- LOC and FP Metrics, Cost Estimation-Delphi and Basic COCOMO, Introduction to Halstead’s Software Science, Staffing Level Estimation- Putnam’s Model. Software Requirements Specification: SRS Documents, their Characteristics and Organization.
👨💼 Software Project Management (सॉफ्टवेयर परियोजना प्रबंधन)
Software Project Management एक ऐसी प्रक्रिया है जिसमें हम सॉफ्टवेयर प्रोजेक्ट को योजना बनाते हैं, अनुमान लगाते हैं, उसका विकास करते हैं और उसका ट्रैक रखते हैं, ताकि प्रोजेक्ट समय, बजट और गुणवत्ता के साथ पूरा हो।
📏 1. Size Estimation (आकार का अनुमान)
Software का “Size” मापना ज़रूरी है ताकि हम समय, लागत, और संसाधनों का पूर्वानुमान लगा सकें।
🔹 (a) LOC – Lines of Code
- सॉफ्टवेयर का आकार उसके कुल कोड की लाइनों से मापा जाता है।
- सरल लेकिन भाषा (language)-dependent होता है।
🔸 उदाहरण:
अगर सॉफ्टवेयर में 5000 लाइन्स हैं → LOC = 5000
🔹 (b) FP – Function Point Metrics
- यह सिस्टम के फंक्शनल साइज को मापता है — कि सिस्टम क्या करता है, न कि कितना कोड है।
- ज्यादा सटीक और language-independent
🔸 Function Point की गणना में ये शामिल होते हैं:
- Inputs
- Outputs
- User Inquiries
- Files
- External Interfaces
💰 2. Cost Estimation (लागत का अनुमान)
🔹 (a) Delphi Technique
- यह एक expert-based estimation तरीका है।
- कई अनुभवी लोग अनुमान देते हैं, फिर उनका औसत लिया जाता है।
✅ लाभ: Collective knowledge
❌ नुकसान: Subjetive (व्यक्तिगत राय पर आधारित)
🔹 (b) COCOMO Model (Constructive Cost Model)
COCOMO एक mathematical model है जो सॉफ्टवेयर प्रोजेक्ट की लागत का अनुमान लगाता है।
🔸 Basic COCOMO Formula:
- PM = Person-Months
- KLOC = Thousands of Lines of Code
- a और b = constants (प्रोजेक्ट टाइप पर आधारित)
COCOMO के प्रकार:
- Basic
- Intermediate
- Detailed
🔸 उदाहरण:
एक साधारण (organic) प्रोजेक्ट के लिए:
🧠 3. Halstead’s Software Science
Halstead ने software size, effort और difficulty मापने के लिए निम्नलिखित मेट्रिक्स दिए:
| Metric | Description |
|---|---|
| n1 | Operators की संख्या |
| n2 | Operands की संख्या |
| N1 | Operators की कुल occurrence |
| N2 | Operands की कुल occurrence |
🔸 Derived Metrics:
- Program Length (N) = N1 + N2
- Vocabulary (n) = n1 + n2
- Volume (V) = N × log₂(n)
- Effort (E) = V × Difficulty
✅ उपयोग: Productivity, Bugs और Maintenance का अनुमान लगाना
👥 4. Staffing Level Estimation (कर्मचारी अनुमान)
🔹 Putnam’s Model (Software Equation)
यह मॉडल बताता है कि प्रोजेक्ट के लिए कितने लोग, कितने समय तक लगेंगे।
Putnam’s Formula:
✅ इस मॉडल से staffing curves बनती हैं — जिससे पता चलता है कि किस समय कितने लोग चाहिए।
📃 5. Software Requirements Specification (SRS)
🔸 SRS Document क्या होता है?
SRS यानी Software Requirements Specification एक औपचारिक डॉक्यूमेंट है जिसमें सॉफ्टवेयर से जुड़ी सभी आवश्यकताएं (functional और non-functional) लिखी जाती हैं।
📑 SRS की विशेषताएँ (Characteristics)
- Correct (सही)
- Complete (पूर्ण)
- Unambiguous (स्पष्ट)
- Consistent (संगत)
- Verifiable (जाँच योग्य)
- Modifiable (बदलने योग्य)
- Traceable (ट्रेस किया जा सके)
📂 SRS का संगठन (Organization of SRS Document)
एक सामान्य SRS डॉक्यूमेंट में ये भाग होते हैं:
- Introduction
- Purpose
- Scope
- Definitions
- Overall Description
- Product Perspective
- Product Features
- User Characteristics
- Specific Requirements
- Functional Requirements
- Non-functional Requirements
- Performance, Security, etc.
- Appendix & Glossary
📚 संक्षेप में सारांश:
| टॉपिक | सार |
|---|---|
| LOC | कोड की लाइनों से सॉफ्टवेयर का साइज मापना |
| FP | फंक्शन के आधार पर साइज मापना |
| Delphi | Expert से अनुमान लेना |
| COCOMO | गणितीय तरीका से लागत निकालना |
| Halstead Metrics | ऑपरेटर-ऑपरेन्ड के आधार पर effort निकालना |
| Putnam Model | Time और Staffing का अनुमान |
| SRS | यूज़र की जरूरतों को डॉक्यूमेंट करना |
Software DesignF: Classification, Software Design Approaches, Function Oriented Software Design, Structured Analysis- Data flow Diagrams and Structured Design, Introduction to Object Oriented Design.
🛠️ Software Design (सॉफ्टवेयर डिज़ाइन)
Software Design वह प्रक्रिया है जिसमें हम सॉफ्टवेयर की रचना, उसकी संरचना और इंटरफेस को तय करते हैं, ताकि प्रोग्रामिंग चरण में उसे आसानी से बनाया जा सके।
📂 1. Classification of Software Design (सॉफ्टवेयर डिज़ाइन के प्रकार)
सॉफ्टवेयर डिज़ाइन को मुख्य रूप से दो भागों में बांटा जाता है:
- High-Level Design (HLD):
पूरे सिस्टम का खाका (architecture) और प्रमुख मॉड्यूल तय करना। - Low-Level Design (LLD):
मॉड्यूल के अंदर की डिटेल डिजाइन, जैसे data structures, algorithms आदि।
🧭 2. Software Design Approaches (डिज़ाइन के तरीके)
मुख्य दो तरीके होते हैं:
(a) Function-Oriented Design (कार्य-केंद्रित डिज़ाइन)
- सॉफ्टवेयर को छोटे-छोटे कार्यों या फंक्शन्स में बाँटना।
- डेटा और फंक्शन को अलग-अलग माना जाता है।
- अधिकतर procedural programming के लिए उपयोगी।
(b) Object-Oriented Design (ऑब्जेक्ट-ओरिएंटेड डिज़ाइन)
- डेटा और फंक्शन दोनों को एक इकाई (object) में मिलाकर डिज़ाइन करना।
- Classes, Objects, Inheritance, Polymorphism आदि concepts पर आधारित।
- बड़े और जटिल सिस्टम के लिए बेहतर।
🛠️ 3. Function Oriented Software Design
- यह डिजाइन software को functions में विभाजित करता है।
- हर function किसी विशेष काम को पूरा करता है।
- Flowcharts और Data Flow Diagrams (DFDs) का उपयोग होता है।
📈 4. Structured Analysis and Design
(a) Data Flow Diagrams (DFD)
- यह एक graphical tool है जो सिस्टम में डेटा के फ्लो को दिखाता है।
- DFD में मुख्य रूप से ये तत्व होते हैं:
- Process (प्रक्रिया)
- Data Store (डेटा संग्रह)
- Data Flow (डेटा प्रवाह)
- External Entity (बाहरी इकाई)
(b) Structured Design
- यह modular और hierarchical design approach है।
- मॉड्यूल के बीच इंटरफेस और डेटा फ्लो को परिभाषित करता है।
- Top-down design approach अपनाई जाती है।
📦 5. Introduction to Object-Oriented Design (OOD)
- OOD में सॉफ्टवेयर को objects में डिजाइन किया जाता है, जो data और उस data पर काम करने वाले methods को एक साथ रखते हैं।
- इसमें मुख्य तत्व होते हैं:
- Class: Object का blue-print
- Object: Class का instance
- Inheritance: Classes के बीच गुण और व्यवहार साझा करना
- Encapsulation: डेटा और methods को एक इकाई में छुपाना
- Polymorphism: एक interface के जरिए अलग-अलग implementations
📚 संक्षेप में सारांश:
| टॉपिक | विवरण |
|---|---|
| Software Design | सॉफ्टवेयर की योजना बनाना और संरचना तय करना |
| Function-Oriented Design | कार्यों पर आधारित डिज़ाइन |
| Data Flow Diagram (DFD) | डेटा के प्रवाह का चित्रण |
| Structured Design | मॉड्यूलर और hierarchical design |
| Object-Oriented Design (OOD) | डेटा और फंक्शन को एक साथ रखने वाली डिज़ाइन |
Coding and Testing of Software: Unit Testing, Block Box Testing, White Box Testing, Debugging, Program Analysis Tools, System Testing. Software Reliability and Quality Assurance: Reliability Metric- Musa’s Basic Model.
👨💻 Coding and Testing of Software (सॉफ्टवेयर का कोडिंग और टेस्टिंग)
1. Unit Testing (यूनिट टेस्टिंग)
- यह सबसे छोटी टेस्टिंग होती है।
- इसमें सॉफ्टवेयर के एक-एक हिस्से (unit/module) को टेस्ट किया जाता है।
- उद्देश्य: यह सुनिश्चित करना कि हर unit सही काम कर रहा है।
2. Black Box Testing (ब्लैक बॉक्स टेस्टिंग)
- इसमें कोड के अंदर का ज्ञान नहीं होता।
- tester केवल इनपुट और आउटपुट को देखता है।
- यह फंक्शनैलिटी और यूजर की जरूरतों पर आधारित टेस्टिंग है।
- आमतौर पर इसे functional testing भी कहते हैं।
3. White Box Testing (व्हाइट बॉक्स टेस्टिंग)
- इसे glass box या structural testing भी कहते हैं।
- इसमें कोड की आंतरिक संरचना और लॉजिक को समझकर टेस्टिंग की जाती है।
- जैसे: condition coverage, path coverage आदि।
4. Debugging (डिबगिंग)
- जब कोई error या bug मिलता है, तो उसे ढूँढना और ठीक करना डिबगिंग कहलाता है।
- Debuggers जैसे tools का उपयोग होता है।
5. Program Analysis Tools (प्रोग्राम विश्लेषण उपकरण)
- ये tools कोड की गुणवत्ता और बग खोजने में मदद करते हैं।
- Examples:
- Static Analyzers (कोड बिना रन किए जांचते हैं)
- Dynamic Analyzers (कोड रन करते समय जांचते हैं)
6. System Testing (सिस्टम टेस्टिंग)
- पूरा सॉफ्टवेयर सिस्टम एक साथ टेस्ट किया जाता है।
- यह सुनिश्चित करता है कि सभी modules मिलकर सही काम करें।
- इसमें performance, security, load testing शामिल हो सकते हैं।
📈 Software Reliability and Quality Assurance (सॉफ्टवेयर विश्वसनीयता और गुणवत्ता आश्वासन)
🔹 Software Reliability (सॉफ्टवेयर विश्वसनीयता)
- यह मापता है कि सॉफ्टवेयर बिना फेल हुए कितनी देर तक सही काम करता है।
- ज्यादा विश्वसनीय सॉफ्टवेयर कम error करता है।
🔹 Reliability Metric – Musa’s Basic Model
- Musa का मॉडल reliability को मापने के लिए प्रयोग होता है।
- इस मॉडल के अनुसार, reliability को समय के साथ failure rate से जोड़ा जाता है।
- सरल फॉर्मूला:
जहाँ,
- R(t)= reliability at time t
- λ = failure rate
- t = समय
🔹 Quality Assurance (गुणवत्ता आश्वासन)
- यह एक systematic प्रक्रिया है जो सॉफ्टवेयर के सभी पहलुओं में गुणवत्ता सुनिश्चित करती है।
- इसमें reviews, audits, testing आदि शामिल हैं।
📚 संक्षेप में सारांश:
| टॉपिक | विवरण |
|---|---|
| Unit Testing | सॉफ्टवेयर के छोटे हिस्सों की टेस्टिंग |
| Black Box Testing | फंक्शनल टेस्टिंग, बिना कोड देखे |
| White Box Testing | कोड के अंदर के लॉजिक को देखकर टेस्टिंग |
| Debugging | bugs को ढूँढना और ठीक करना |
| Program Analysis Tools | कोड की गुणवत्ता जांचने वाले उपकरण |
| System Testing | पूरा सिस्टम एक साथ टेस्ट करना |
| Software Reliability | सॉफ्टवेयर की विश्वसनीयता |
| Musa’s Model | reliability को failure rate से जोड़ना |
| Quality Assurance | सॉफ्टवेयर की गुणवत्ता सुनिश्चित करना |
Software Quality Assurance: ISO 9000 and SEI CMM and their Comparison.
Software Maintenance: Maintenance Process Models and Reverse Engineering, Estimation of Maintenance Costs.
✅ Software Quality Assurance (सॉफ्टवेयर गुणवत्ता आश्वासन)
सॉफ्टवेयर की गुणवत्ता सुनिश्चित करने के लिए विभिन्न मानक और फ्रेमवर्क बनाए गए हैं। इसमें सबसे प्रसिद्ध हैं:
1. ISO 9000
- ISO 9000 एक अंतरराष्ट्रीय मानक (standard) है जो गुणवत्ता प्रबंधन (Quality Management) के लिए है।
- यह सुनिश्चित करता है कि कंपनी के पास अच्छी प्रक्रियाएँ और सिस्टम हैं ताकि ग्राहकों को बेहतर उत्पाद मिले।
- सॉफ्टवेयर के लिए ISO 9000 यह बताता है कि डॉक्यूमेंटेशन, प्रक्रिया नियंत्रण और सुधार कैसे हो।
2. SEI CMM (Capability Maturity Model)
Capability Maturity Model (CMM) एक ऐसा फ्रेमवर्क है जो सॉफ़्टवेयर विकास प्रक्रियाओं की परिपक्वता (maturity) को मापता है।
यह बताता है कि कोई संगठन कितनी प्रभावी, मापनीय और नियंत्रित प्रक्रिया के साथ सॉफ्टवेयर बनाता है।
- SEI (Software Engineering Institute) द्वारा विकसित यह मॉडल सॉफ्टवेयर प्रक्रिया की परिपक्वता (maturity) मापता है।
- इसमें 5 लेवल होते हैं:
- Initial (प्रारंभिक)
- Repeatable (दोहराने योग्य)
- Defined (परिभाषित)
- Managed (प्रबंधित)
- Optimizing (सुधारात्मक)
- इसका उद्देश्य है कि कंपनियाँ अपने सॉफ्टवेयर विकास की प्रक्रियाओं को बेहतर बनाएं।
🧭 मुख्य उद्देश्य:
- सॉफ़्टवेयर प्रक्रिया में निरंतर सुधार (continuous improvement) को बढ़ावा देना
- बेहतर गुणवत्ता (quality), पूर्वानुमान (predictability) और प्रदर्शन (performance) प्राप्त करना
📶 CMM के 5 स्तर (Levels of CMM):
| 📊 Level | 📝 नाम (Name) | 🔍 विवरण (Explanation) |
|---|---|---|
| Level 1 | Initial (प्रारंभिक) | प्रक्रिया अनियमित और अव्यवस्थित होती है। सफलता व्यक्ति पर निर्भर होती है। |
| Level 2 | Repeatable (दोहराने योग्य) | बुनियादी प्रक्रियाएँ स्थापित होती हैं, जैसे प्रोजेक्ट मैनेजमेंट। कुछ हद तक योजना और ट्रैकिंग संभव होती है। |
| Level 3 | Defined (परिभाषित) | सारी प्रक्रियाएँ दस्तावेज़ीकृत और मानकीकृत होती हैं। पूरी संस्था में एक जैसा पालन होता है। |
| Level 4 | Managed (प्रबंधित) | प्रक्रिया का मापन और नियंत्रण डेटा के आधार पर किया जाता है। गुणवत्ता और प्रदर्शन को मापा जाता है। |
| Level 5 | Optimizing (सुधार हेतु तत्पर) | निरंतर सुधार पर ज़ोर। नई तकनीकों और प्रक्रियाओं को अपनाया जाता है। |
🔄 ISO 9000 और SEI CMM की तुलना
| पहलू (Aspect) | ISO 9000 | SEI CMM |
|---|---|---|
| उद्देश्य | गुणवत्ता प्रबंधन सिस्टम बनाना | सॉफ्टवेयर प्रक्रिया की परिपक्वता बढ़ाना |
| फोकस | प्रक्रिया नियंत्रण और दस्तावेज़ीकरण | प्रक्रिया सुधार और परिपक्वता स्तर |
| स्तर | मानक (Standard) | maturity levels (5 स्तर) |
| व्यापकता | कई उद्योगों में लागू | मुख्य रूप से सॉफ्टवेयर उद्योग के लिए |
| अनिवार्यता | कुछ जगहों पर अनिवार्य | वैकल्पिक लेकिन उपयोगी |
🔧 Software Maintenance (सॉफ्टवेयर रखरखाव)
सॉफ्टवेयर का विकास पूरा होने के बाद भी उसका रखरखाव ज़रूरी होता है ताकि वह नए परिवर्तनों, बग्स, और आवश्यकताओं के अनुसार काम करता रहे।
1. Maintenance Process Models
- Corrective Maintenance: बग ठीक करना
- Adaptive Maintenance: नए हार्डवेयर या सॉफ्टवेयर के लिए बदलाव
- Perfective Maintenance: सिस्टम में सुधार और नया फीचर जोड़ना
- Preventive Maintenance: संभावित बग्स को रोकना
2. Reverse Engineering
- किसी मौजूदा सॉफ्टवेयर को समझने और उसके डॉक्यूमेंटेशन बनाने की प्रक्रिया।
- इसका उपयोग तब होता है जब सॉफ्टवेयर का मूल डिजाइन उपलब्ध नहीं होता।
3. Estimation of Maintenance Costs
- रखरखाव की लागत का अनुमान लगाना जरूरी होता है।
- ये लागत होती है:
- बग फिक्सिंग में लगने वाला समय और मेहनत
- नए हार्डवेयर या सॉफ्टवेयर के कारण बदलाव
- अपडेट और सुधार के लिए संसाधन
📚 संक्षेप सारांश:
| टॉपिक | विवरण |
|---|---|
| ISO 9000 | गुणवत्ता प्रबंधन के लिए अंतरराष्ट्रीय मानक |
| SEI CMM | सॉफ्टवेयर प्रक्रिया की परिपक्वता मापने वाला मॉडल |
| Maintenance Types | Corrective, Adaptive, Perfective, Preventive |
| Reverse Engineering | मौजूदा सॉफ्टवेयर से डिजाइन समझना |
| Maintenance Cost | रखरखाव पर आने वाली लागत का अनुमान |