Software Crisis:

Software crisis refers to the difficulties encountered in software development, including cost overruns, schedule delays, and low-quality products. It arose due to the rapid
advancement of hardware without corresponding improvements in software development techniques.
Software Myths:
Some common software myths include:
• More programmers mean faster project completion.
• Once software is written, it works forever.
• Adding more people to a late project helps.
• Software maintenance is easy.
Principles of Software Engineering:
1. Abstraction – Focusing on essential details while ignoring the rest.
2. Modularity – Dividing software into smaller, manageable modules.
3. Encapsulation – Hiding implementation details from the user.
• Scalability – Ensuring the software can handle increasing demands.
1. Maintainability – Making software easy to modify and update.
2. Testing – Verifying that the software meets requirements.
Goals of Studying Software Engineering
1. Develop high-quality, reliable, and maintainable software.
2. Improve efficiency in software development.
3. Reduce development costs and time.
4. Ensure software meets user requirements.
5. Provide systematic approaches to software development.
Software Crisis & Its Impact
• Definition: The software crisis refers to challenges in software development, such as delays, cost overruns, and poor quality.
• Causes:
1. Rapid increase in hardware capabilities without matching software advancements.
2. Lack of structured methodologies.
3. Increasing complexity of software.
4. High failure rates of large software projects.
• Impact:
o Led to the evolution of software engineering as a discipline.
o Encouraged process models like Waterfall and Agile.
o Promoted structured programming and object-oriented design.

Measures vs. Metrics in Software Engineering

Feature Measures Metrics

Definition A single quantitative value obtained by direct measurement. A derived or calculated value based on multiple measures.

Nature Raw data (basic unit of measurement). Processed or analyzed data.

- Number of lines of code (LOC) - Defect density (Defects per LOC)

Example
- Number of defects found - Code efficiency (LOC per function)

Purpose Captures basic properties of a software component. Provides insights for decision-making and improvement.

Computation Directly measurable. Requires analysis and computation.

Usage Used as input for calculating metrics. Used for evaluating software quality and performance.

• Need for Software Quality Metrics:

1. Helps in assessing software performance.
2. Improves software maintainability.
3. Ensures reliability and security.
4. Identifies defects early in development.
5. Provides a standard for comparing different projects.
Role of Software Metrics in Project Management
1. Helps in resource allocation and scheduling.
2. Improves software quality assessment.
3. Measures progress and performance.
4. Aids in risk assessment.
5. Facilitates decision-making in software development.
Challenges in Collecting & Interpreting Software Metrics
1. Lack of Standardization – Different projects require different metrics.
2. Data Accuracy Issues – Difficulties in obtaining precise values.
3. Misinterpretation – Poor understanding of metric implications.
4. High Cost of Collection – Requires additional effort and tools.
5. Resistance from Teams – Developers may resist monitoring.
• Objectives of Software Project Planning:
1. Define project scope and goals.
2. Estimate cost, time, and resources.
3. Identify risks and mitigation strategies.
4. Allocate tasks to teams.
5. Establish a project schedule.
• Risk Identification & Handling:
Risk Management Strategies

• Risk Identification
1. Technical Risks: Lack of stakeholder support, funding issues.
2. External Risks: Market changes, regulatory requirements.
• Risk Projection
1. Likelihood Analysis: Determine the probability of risks occurring
2. Impact Assessment: Evaluate the severity of risks on the project.
• Risk Mitigation Strategies (handling)
1. Avoidance: change the project plan to estimate risks.
2. Transfer: Outsource or insure to shift the risk.
3. Reduction: Take preventive measures to minimize risks.
4. Acceptance: Acknowledge and monitor the risk if unavoidable.
SQA (Software Quality Assurance) Plan: It is a document that outlines the approach, activities, resources, and schedules for ensuring the quality of a software product

throughout its development lifecycle. It serves as a roadmap for the SQA process, guiding the team on how to achieve quality objectives and meet customer expectations.A
structured plan to ensure software quality, covering processes like defect prevention, testing, and auditing.
Importance:

• Prevents defects and reduces costs.

• Ensures compliance with standards.
• Improves reliability and security.
• Increases customer satisfaction.

• Software Review: Software reviews are evaluations or assessments of software applications conducted by users, experts, or organizations to provide insights into the
quality, features, usability, performance, and overall value of the software. These reviews can help potential users make informed decisions when choosing software
for their needs. A formal evaluation process to check software correctness, involving walkthroughs, inspections, and peer reviews.
• ISO 9000 Software Quality Standards:
ISO 9000 is a set of international standards for quality management systems (QMS), ensuring that organizations consistently meet customer and regulatory requirements.
Key Features of ISO 9000 in Software Quality:
• International Quality Standard – Provides a globally recognized framework for quality management.
• Customer Satisfaction & Continuous Improvement – Emphasizes meeting customer expectations and improving processes over time.
• Process-Oriented Approach – Focuses on defining, managing, and optimizing software development processes.
• Documentation & Compliance – Requires proper documentation of development, testing, and maintenance processes to ensure traceability.
• Risk-Based Thinking – Encourages identifying and mitigating risks in software development.
• Audits & Certification – Organizations can undergo audits to receive ISO 9001 certification, demonstrating compliance.
•
 o Defines international quality management standards.
o Focuses on customer satisfaction and continuous improvement.
o Ensures documentation of development processes.
• SCM (Software Configuration Management): The process of tracking and controlling software changes to maintain integrity and traceability.
• SQA Plan is a document defining quality objectives, testing strategies, and defect management.
• SQA (Software Quality Assurance): A systematic approach to ensuring software quality through standards, reviews, and testing.
• Software Configuration Management Process:
1. Identification – Defining configuration items.
2. Version Control – Managing changes to software versions.
3. Change Control – Approving or rejecting software modifications.
4. Configuration Auditing – Ensuring compliance with standards.
5. Status Reporting – Documenting changes.
Requirement Analysis: The process of gathering, analyzing, and documenting software requirements.
Steps in Requirement Analysis:
1. Feasibility Study
2. Requirement Gathering
3. Requirement Specification
4. Requirement Validation
5. Requirement Management
Data Modeling
Definition:
Data Modeling defines and analyzes the data requirements needed to support the system. It focuses on the structure, relationships, and constraints of data.

Key Components:

1. Entities: Objects or concepts (e.g., Customer, Product).

2. Attributes: Properties of entities (e.g., Customer Name, Product ID).
3. Relationships: Associations between entities (e.g., Customer places Order).Uses Entity-Relationship Diagrams (ERD) to model data structures.
4. Functional Modeling:
• Focuses on the system's functions and processes.
• Describes what the system does and how it transforms inputs into outputs.
• Tools:
• Data Flow Diagrams (DFDs): Show how data flows through the system.

• Use Case Diagrams: Describe interactions between users and the system.
Software Analysis & Its Importance
The process of gathering, refining, and documenting software requirements.
Importance:
1. Ensures software meets user needs.
2. Identifies potential issues early.
3. Reduces development costs and risks.
• Functional vs. Non-Functional Requirements

Feature Functional Requirements Non-Functional Requirements

Definition Defines what the software should do Defines how the software should behave

Examples Login authentication, report generation Performance, security, usability

Data Modeling
• Represents data relationships and flow within a system using ER Diagrams, DFDs, etc.
Importance of Design Concepts & Principles in Software Quality
1. Modularity – Improves maintainability.
2. Encapsulation – Enhances security.
3. Abstraction – Reduces complexity.
Architectural & Component-Level Design
• Architectural Design: Defines the system structure and communication flow.
• Component-Level Design: Focuses on module-level development, ensuring reusability.
Object-Oriented Paradigm: A programming approach that organizes software into objects containing data and behaviors. Object-Oriented Programming (OOP) is a programming
paradigm that organizes software design around objects rather than functions and logic. An object is an instance of a class, and a class is a blueprint that defines the properties (data)
and behaviors (methods) that the objects created from it will have.
Object-Oriented Concepts:

• Encapsulation – Hiding internal details.

• Inheritance – Reusing existing code.
• Polymorphism – Allowing different behaviors for the same function.
• Abstraction – Simplifying complex reality.
Domain Analysis: Domain Analysis is the initial phase of the software development lifecycle. It involves understanding the problem domain and the requirements of the system to
be developed. By analyzing the domain, we gain insights into the entities, relationships, and behaviors that exist within it. This knowledge forms the foundation for building an
effective object-oriented solution. Identifies common elements across similar projects to improve reuse.
Components of Object-Oriented Model:
• Class Diagram – Shows relationships between classes.
• Use Case Diagram – Represents user interactions.
• Sequence Diagram – Depicts object interactions.
• State Diagram – Represents object states.
Software Testing: The process of verifying and validating software to ensure it meets requirements.
White-Box vs. Black-Box Testing:

Feature White-Box Testing Black-Box Testing

Focus Internal code structure External behavior

Tester Needs Knowledge of code No code knowledge required

Methods Code coverage, Path testing Functional, UI testing

Tools Unit testing frameworks Automated UI testing tools

Software Cost Estimation Using Function Point & Object-Oriented Approach

• Function Point-Based Estimation:
o Measures functionality based on user inputs, outputs, queries, files, and interfaces.
o Helps estimate development effort and cost.
o Common formula:
FP=(Input×Weight)+(Output×Weight)+(Queries×Weight)+(Files×Weight)+(Interfaces×Weight)FP = (Input \times Weight) + (Output \times Weight) +
(Queries \times Weight) + (Files \times Weight) + (Interfaces \times
Weight)FP=(Input×Weight)+(Output×Weight)+(Queries×Weight)+(Files×Weight)+(Interfaces×Weight)
• Object-Oriented Estimation:
o Uses object classes, methods, and interactions to estimate cost.
o Considers factors like class complexity, method count, and object interactions.
o Often used in modern software development environments.

Object-Oriented Analysis vs. Traditional Structured Analysis

Feature Object-Oriented Analysis Traditional Structured Analysis

Approach Uses objects and classes Uses functions and data flow

Focus Real-world modeling Process-oriented design

Diagrams Used Use Case, Class Diagram DFDs, ER Models

Management of Object-Oriented Projects

1. Requirement Gathering – Define use cases and object interactions.
2. Design & Modeling – Create class diagrams and relationships.
 3. Development – Implement classes and inheritance.
4. Testing & Maintenance – Conduct unit tests and system integration.
(a) Software Verification & Validation
Software Verification and Validation (V&V) ensures that a software product meets its specified requirements and functions correctly before deployment.

1. Verification ("Are we building the product right?")

o Ensures that the software follows specified requirements, design, and coding standards.
o Focuses on process quality.
o Conducted through:
▪ Reviews (Requirement Reviews, Code Reviews)
▪ Walkthroughs
▪ Inspections
2. Validation ("Are we building the right product?")
o Ensures that the software fulfills user needs and expectations.
o Focuses on product quality.
o Conducted through:
▪ Unit Testing
▪ Integration Testing
▪ System Testing
▪ Acceptance Testing
(b) Software Configuration Management (SCM) Standards
SCM standards define rules and procedures for managing software changes, version control, and releases.

Key Components of SCM Standards:

1. Configuration Identification – Assigns unique identifiers to software components.

2. Version Control – Manages different versions of the software.
3. Change Control – Tracks and approves software modifications.
4. Configuration Auditing – Ensures that changes comply with standards.
5. Status Accounting – Keeps records of changes and versions.

(c) System Design Process for Object-Oriented Software

Object-oriented system design follows a structured approach to software development using objects, classes, and UML diagrams.

Steps in the Object-Oriented System Design Process:

1. Requirement Analysis – Identify use cases and system needs.

2. Conceptual Design – Create class diagrams, object interactions.
3. Architectural Design – Define system structure and data flow.
4. Component-Level Design – Develop individual classes and methods.
5. Implementation – Write code using an object-oriented language (e.g., Java, C++).
6. Testing – Conduct unit, integration, and system testing.
7. Maintenance – Update and optimize the system.

(d) Configuration Audit

A configuration audit verifies whether the software product meets its defined requirements and follows approved changes.

Types of Configuration Audits:

1. Functional Configuration Audit (FCA):

o Ensures that the software meets its functional requirements.
o Conducted through testing and requirement validation.
2. Physical Configuration Audit (PCA):
o Verifies that the software product matches its design documentation.
o Ensures correct versioning and documentation.