Unit 8: Software Engineering

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 लेवल होते हैं:
1. Initial (प्रारंभिक)
2. Repeatable (दोहराने योग्य)
3. Defined (परिभाषित)
4. Managed (प्रबंधित)
5. 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	रखरखाव पर आने वाली लागत का अनुमान

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)

🧩 1. सॉफ्टवेयर की विशेषताएँ (Characteristics of Software)

🌟 2. Software Engineering का उदय (Emergence of Software Engineering)

🔁 क्यों ज़रूरी हुआ Software Engineering?

📊 3. Software Metrics & Models

📏 Software Metrics (मापदंड)

उदाहरण:

🧮 Software Models (मॉडल)

⚖️ 4. Process & Product Metrics

🔄 Process Metrics

📦 Product Metrics

🧬 5. Software Life Cycle Models (SDLC Models)

1. Waterfall Model (वॉटरफॉल मॉडल)

2. Prototype Model (प्रोटोटाइप मॉडल)

3. Spiral Model (स्पाइरल मॉडल)

मुख्य विचार (Key Idea):

📚 मुख्य चरण (Phases of Spiral Model):

📋 6. तीनों मॉडल की तुलना (Comparison)

📚 निष्कर्ष:

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 (सॉफ्टवेयर परियोजना प्रबंधन)

📏 1. Size Estimation (आकार का अनुमान)

🔹 (a) LOC – Lines of Code

🔹 (b) FP – Function Point Metrics

💰 2. Cost Estimation (लागत का अनुमान)

🔹 (a) Delphi Technique

🔹 (b) COCOMO Model (Constructive Cost Model)

🔸 Basic COCOMO Formula:

COCOMO के प्रकार:

🧠 3. Halstead’s Software Science

👥 4. Staffing Level Estimation (कर्मचारी अनुमान)

🔹 Putnam’s Model (Software Equation)

Putnam’s Formula:

📃 5. Software Requirements Specification (SRS)

🔸 SRS Document क्या होता है?

📑 SRS की विशेषताएँ (Characteristics)

📂 SRS का संगठन (Organization of SRS Document)

एक सामान्य 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 (सॉफ्टवेयर डिज़ाइन)

📂 1. Classification of Software Design (सॉफ्टवेयर डिज़ाइन के प्रकार)

🧭 2. Software Design Approaches (डिज़ाइन के तरीके)

(a) Function-Oriented Design (कार्य-केंद्रित डिज़ाइन)

(b) Object-Oriented Design (ऑब्जेक्ट-ओरिएंटेड डिज़ाइन)

🛠️ 3. Function Oriented Software Design

📈 4. Structured Analysis and Design

(a) Data Flow Diagrams (DFD)

(b) Structured Design

📦 5. Introduction to 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 (यूनिट टेस्टिंग)

2. Black Box Testing (ब्लैक बॉक्स टेस्टिंग)

3. White Box Testing (व्हाइट बॉक्स टेस्टिंग)

4. Debugging (डिबगिंग)

5. Program Analysis Tools (प्रोग्राम विश्लेषण उपकरण)

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

📈 Software Reliability and Quality Assurance (सॉफ्टवेयर विश्वसनीयता और गुणवत्ता आश्वासन)

🔹 Software Reliability (सॉफ्टवेयर विश्वसनीयता)

🔹 Reliability Metric – Musa’s Basic Model

🔹 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

2. SEI CMM (Capability Maturity Model)

🧭 मुख्य उद्देश्य:

📶 CMM के 5 स्तर (Levels of CMM):

🔄 ISO 9000 और SEI CMM की तुलना

🔧 Software Maintenance (सॉफ्टवेयर रखरखाव)

1. Maintenance Process Models

2. Reverse Engineering

3. Estimation of Maintenance Costs

📚 संक्षेप सारांश:

Software Quality Assurance: ISO 9000 and SEI CMM and their Comparison.
Software Maintenance: Maintenance Process Models and Reverse Engineering, Estimation of Maintenance Costs.