### *UNIT - I: Introduction to Software Engineering*

- *Software Crisis* – Challenges in software development, such as high cost, low reliability,
and delayed delivery.
- The *software crisis* refers to challenges faced in software development due to rapidly
increasing complexity, demand, and technology changes.
- Major symptoms include *high development costs, frequent delays, and unreliable software
products*.
### *Causes of the Software Crisis:*
1. *Poor project planning* – Inefficient resource allocation leads to wasted effort and time.
2. *Changing requirements* – Frequent modifications cause instability in software design.
3. *Lack of standardized development methodologies* – Inconsistent approaches result in
low-quality software.
4. *Complexity in large-scale software systems* – Difficult to maintain and debug.
5. *Limited understanding of user needs* – Mismatch between actual requirements and
implementation.
### *Impact of Software Crisis:*
- Cost overruns, Missed deadlines, Software failures leading to business losses, Difficulty in
maintaining older systems.
----
- *Software Life Cycle Models*
## *1. Waterfall Model*
- *Sequential approach* where each phase must be completed before moving to the next.
Sequential development with distinct phases: Requirement, Design, Implementation, Testing,
Deployment.
- *Phases:*
1. *Requirement Analysis 2. *System Design 3. *Implementation (Coding)* 4. *Testing*
5. *Deployment* 6. *Maintenance*
- *Advantages:* - Simple, easy to manage. And Works well for well-defined projects with
stable requirements.
- *Disadvantages:*
- Cannot handle changing requirements. and Late testing phase may expose major errors.
## *2. Prototype Model*- An initial prototype is built, tested, and refined.
- *Build an initial prototype* to gather user feedback before full-scale development.
- *Steps:*
1. *Initial Requirement Gathering* – Basic specifications are collected.
2. *Prototype Development* – A simplified model is created.
3. *User Feedback & Refinement* – Users suggest improvements.
4. *Final System Development* – The refined system is implemented.
- *Advantages:*
- Useful for unclear or evolving requirements.
- Helps refine software based on user expectations.
- *Disadvantages:*
- Requires extensive user interaction.
- Prototype development adds extra cost.

## *3. Spiral Model*- Combines iterative development with risk assessment.

- *Iterative process* combining risk assessment and repeated refinement.
- *Phases in each cycle:*
1. *Planning*
2. *Risk Analysis*
3. *Engineering (Development & Testing)*
4. *Evaluation*
- *Advantages:*
- Ideal for complex projects.
- Strong risk-handling capability.
- *Disadvantages:*
- Requires high expertise in risk analysis.
- Expensive for small projects.

## *4. Agile Model*

- *Iterative and incremental approach* focusing on adaptability and collaboration.
Incremental development with continuous feedback.
- *Key principles:*
 - Continuous interaction with customers.
- Small, frequent updates.
- Flexible responses to changing requirements.
- *Advantages:*
- Faster time-to-market.
- Higher customer satisfaction.
- *Disadvantages:*
- Requires strong teamwork and constant collaboration.

#### *Software Requirements Analysis & Specifications*

- *Requirement Engineering* – The process of- gathering and defining software
requirements.
1. *Requirement Elicitation* – Gathering information from stakeholders.
2. *Requirement Analysis* – Refining and prioritizing collected data.
3. *Requirement Specification* – Writing formal Software Requirement Specification (SRS).
4. *Requirement Validation* – Ensuring correctness and consistency before implementation.

- *Requirement Elicitation Techniques*

- *FAST* (Functional Analysis System Technique) – Prioritizing requirements. and
Structured approach to functional design.
- *QFD* (Quality Function Deployment) – Mapping user needs to design. Or Mapping
customer needs to system functionality.
- *Analysis Tools* – Data Flow Diagrams (DFD), Use-Case diagrams, ER Diagrams.
*Requirements Documentation (SRS)*
- *Structure of an SRS Document:*
- *Introduction* – Defines the system’s purpose and constraints.
- *Functional Requirements* – System operations and expected outputs.
- *Non-functional Requirements* – Performance constraints, security, etc.
- *Design Constraints* – Limitations of hardware or software.
- *Assumptions & Dependencies* – Factors affecting implementation.
### *UNIT - II: Software Project Planning*
- *Software Metrics*
- *Definition:* Quantitative measures used to evaluate software quality and development
productivity.
- *Categories:*
- *Product Metrics* – Quality of the software (e.g., complexity, readability). Software size
- *Process Metrics* – Efficiency of development processes. Efficiency, defect rate, resource
utilization.
- *Project Metrics* – – Cost estimation, Progress and performance tracking.
- *Size Estimation Techniques*
- *Lines of Code (LOC)* – Measures software size. Or Basic measure of system length.
- *Function Count* – Evaluates functional components. Or counts functional components
for accurate effort estimation.
- *Halstead Software Science* – Calculates complexity using operators and operands. and
uses operators/operands to analyze complexity.

## *Cost Estimation Models*

- *COCOMO (Constructive Cost Model)*
1. *Basic Model* – Uses LOC to estimate effort. AND Estimates effort and time.
2. *Intermediate Model* – Includes factors like project complexity and team skills.
And Includes additional factors like team experience.

#### *Risk Management*

- *- *Risk Management Activities*
- *Risk Assessment* – Identifying risks.
- *Risk Control* – Implementing mitigation strategies.
## *Software Risks*
- *Categories:*
1. *Technical Risks* – Design flaws, complexity issues.
2. *Managerial Risks* – Budget overruns, schedule delays.
3. *External Risks* – Market changes, legal constraints.
## *Risk Management Process*
1. *Risk Identification* – Recognizing threats to project success.
2. *Risk Analysis* – Assessing likelihood and impact.
3. *Risk Mitigation* – Implementing strategies to reduce risk.

---
### *UNIT - III: Software Design & Implementation*
#### *Cohesion & Coupling*
- *Definition:* Cohesion refers to the degree to which elements of a module are functionally
related. – Degree to which elements within a module are related.
- *Types of Cohesion (from weakest to strongest):*
1. *Coincidental Cohesion:* Elements grouped arbitrarily.
2. *Logical Cohesion:* Grouped based on similar tasks.
3. *Temporal Cohesion:* Executed at the same time.
4. *Procedural Cohesion:* Elements operate in sequence.
5. *Communicational Cohesion:* Share input/output data.
6. *Sequential Cohesion:* Output from one element is used by another.
7. *Functional Cohesion:* Strongest type—elements are directly related to a single function.
### *Coupling*
- *Definition:* Coupling refers to the degree of dependency between modules.
Interdependence between modules (low coupling is preferred).
- *Types of Coupling (from strongest to weakest):
1. *Content Coupling:* One module modifies another.
2. *Common Coupling:* Shared global data.
3. *Control Coupling:* Passing control info (flags, switches).
4. *Stamp Coupling:* Passing complex data structures.
5. *Data Coupling:* Modules communicate by passing simple data (best practice).
- *Best Practice:* *High cohesion, low coupling* results in modular, maintainable software.
-----
# *Quality Management*
## *2. Software Quality Concept*
### *Definition of Software Quality*
- A measure of *how well software meets specified requirements* and *functions reliably*
under expected conditions. And - Measures for reliability, efficiency, and maintainability.
- Key attributes: *Correctness, reliability, efficiency, maintainability, usability*.

### *3. Software Quality Assurance (SQA)*

- *Definition:* Ensures that development processes result in high-quality software. And
Ensuring software meets requirements
- *SQA Activities:*
1. *Process Monitoring*
2. *Software Reviews*
3. *Testing & Debugging*
4. *Standard Compliance Checking*
5. *Continuous Improvement*

### *4. Total Quality Management (TQM)*

- *Definition:* A customer-focused approach ensuring *continuous improvement* in product
quality. And - Continuous quality improvement.

- *Principles:*
1. *Customer Focus* 2. *Process Improvement* 3. *Employee Involvement* 4. *Fact-
Based Decision Making*

### *5. Software Reviews*

- *Formal inspection of design/code to find defects early.*
- Types: 1. *Peer Reviews* (Informal code inspections)
2. *Walkthroughs* (Discussion-based reviews)
3. *Technical Reviews* (Formal analysis by experts)

### *6. Software Inspection*

- *Definition:* Structured review process identifying defects without executing code.
- *Key Focus:* *Static analysis, **fault detection, **adherence to coding standards*.
---
# *Software Implementation*
## *7. Structured Coding Techniques*
### *Coding Standards*
- Set of predefined *rules for code formatting, commenting, and naming conventions*.
- Improves *readability, maintainability, and reduces errors*.

### *8. Coding Style*

- *Good Practices:*
- Modular programming (break into functions/classes).
- Consistent indentation and spacing.
- Meaningful variable names.
- Proper exception handling.

### *9. Standards & Guidelines*

- *ISO/IEC 9126* – Defines software quality characteristics.
- *Coding guidelines:* Style guides ensure *readability and consistency*.
- *Example:* Java Coding Standards promote *camelCase naming, exception handling, and
modular design*.

### *10. Documentation Guidelines*

- *Why Documentation?*
- Ensures maintainability, facilitates debugging, helps new developers understand the
codebase.
- *Types:*
- *User documentation* (manuals, help guides).
- *Technical documentation* (system architecture, APIs, source code comments).

### *11. Reverse Engineering*- Analyzing a system to derive its design.

- *Definition:* Analyzing a system to *extract design information* from existing code.
- *Uses:* Recover lost documentation, security analysis, malware detection.

### *12. Software Re-engineering*- Improving existing systems

- *Definition:* Modifying existing software to improve structure and efficiency *without
changing functionality*.
- *Steps:*
1. *Analyzing existing software*
2. *Refactoring & restructuring*
3. *Migration to improved platforms*

### *13. Configuration Management*

- *Definition:* Managing changes to software artifacts systematically.
- *Key Components:*
- *Version Control* (e.g., Git)
- *Change Management*
- *Build Management*
- *Release Management*
- *Tools:* Git, SVN, Jenkins for CI/CD (Continuous Integration & Deployment).

SOFTWARE TESTING – Viva Notes

📌 1. Testing Process
 It’s the process of checking software for defects and ensuring it meets the
requirements.
 Steps:
1. Requirement Analysis
2. Test Planning
3. Test Case Design
4. Test Execution
5. Defect Reporting
6. Retesting & Regression Testing
7. Test Closure
📌 2. Levels of Testing

Level Description Done By

Unit Testing Tests individual functions/modules Developers

Integration Testing Tests module interactions Developers/Testers

System Testing Tests the whole system Testers

📌 3. Types of Testing
 Manual Testing: Test cases executed by hand, no tools.
 Automation Testing: Uses tools/scripts (e.g. Selenium, QTP) to automate tests.

📌 4. Methods of Testing

Method Description

Black Box Tester doesn't know internal code. Focus on input/output.

White Box Tester knows code logic. Focus on internal structure.

Grey Box Tester has partial knowledge of code. Mix of both above.

📌 5. Validation vs Verification

Verification Validation

Are we building it right? Are we building the right product?

Done during development Done after development

Techniques: Reviews, walkthroughs Techniques: Testing, UAT

📌 6. Alpha & Beta Testing

 Alpha Testing: Done by developers/testers in-house before release.
 Beta Testing: Done by selected users after alpha, before final release.

📌 7. Acceptance Testing
  Done by client to check if the software meets business requirements.
 Final stage before product delivery.

📌 8. Functional Testing
 Focuses on what the system does (functionality).
 Types:
o Smoke Testing: Basic checks (build is testable?)
o Sanity Testing: Small change has not broken the system.
o Regression Testing: Ensures new changes didn’t break existing features.
o UAT (User Acceptance Testing): Performed by client/end-user.

📌 9. Structural Testing
 Based on code structure and logic.
 Used in White-box testing.
 Example: Line coverage, branch coverage testing.

📌 10. Testing vs Debugging

Testing Debugging

Finds bugs Fixes bugs

Done by testers Done by developers

No code change Code is changed to fix error

✅ SOFTWARE MAINTENANCE – Viva Notes

📌 1. Maintenance Management
 Planning and controlling software updates.
 Goals: Keep system efficient, updated, and error-free.

📌 2. Maintenance Process
1. Problem Identification
 2. Analysis
3. Solution Design
4. Implementation
5. Testing
6. Documentation

📌 3. Types of Maintenance

Type Purpose

Corrective Fix bugs and errors

Adaptive Adapts to new OS, hardware, or platforms

Perfective (Perceptive) Improves performance or UI

Preventive Prevents future issues (code optimization, refactoring)

📌 4. Maintenance Tools & Techniques

 Tools: Git, JIRA, Bugzilla, IDEs, Profilers, Debuggers
 Techniques:
o Refactoring
o Documentation updates
o Automated testing
o Code review