III CSE II Semester

SOFTWARE ENGINEERING (22CS307)

2025-26 II Semester
INTRODUCTION TO SOFTWARE: MODULE 1

Introduction to Software Engineering :

Definition:
Software Engineering is the application of a systematic, disciplined, scientific approach to the
development, operation and maintenance of software.
OR
Software Engineering is a discipline whose aim is the production of fault free software that
satisfies the user’s needs and that is delivered on time and within budget.
Software Engineering involves the study of the principles and practices that guide the design,
development, maintenance, and management of software systems. This field combines computer
science, engineering principles, and project management to create reliable, efficient, and high-
quality software products.

Evolution Of Software Engineering Methodology

A software engineering methodology is a set of procedures followed from the beginning to the
completion of the development process.

1. The cost and impact of proposed changes are evaluated to understand their effect on the
system and implementation cost.
2. If the changes are approved, a new software release is planned.
3. During release planning, all changes such as bug fixes, adaptations, and new features are
reviewed.
4. Decisions are made on which changes will be included in the next version.
5. The approved changes are then designed, implemented, and tested in an iterative
development cycle.

Goals of Software Engineering:

The primary goals of Software Engineering is
1. To improve the quality, reliability of software.
2. To increase productivity.
3. To increase the job satisfaction of software engineers, etc.
The Changing Nature of Software
1. System Software – Manages hardware and provides a platform for applications.
2. Personal Computer Software – Software designed for individual users to perform daily
tasks.
3. Business Software – Software that supports business operations and management.
4. Real-Time Software – Software that responds to inputs within strict time limits
5. Engineering & Scientific Software – Solves complex scientific and engineering
problems.
6. Embedded Software – Controls hardware devices and systems.
7. Web based Software – Software that runs through web browsers over the internet.
8. Artificial Intelligence Software – Uses intelligence to learn, reason, and make decisions.
 MODULE 1

Characteristics Of Software:

 Functionality – The software provides all required features and performs its intended
tasks correctly according to user requirements.

 Usability – The software is easy to learn, understand, and use, improving user
satisfaction and productivity.

 Efficiency – The software delivers good performance while using minimum system
resources such as memory, CPU, and time.

 Flexibility – The software can be easily adapted to changes in requirements or

environment without major rework.
  Reliability – The software operates correctly and consistently without failure under
specified conditions.

 Maintainability – The software can be easily modified to fix bugs, improve

performance, or add new features.

 Portability –The software can be transferred and run on different hardware or operating
systems with little or no modification.

 Integrity – The software ensures data accuracy and prevents unauthorized access or
manipulation.

Additional Characteristics
If you’re dealing with enterprise-level software or highly regulated environments, you may also
consider these:
 Interoperability – Ability to work with other systems.
 Security – Protection against threats and vulnerabilities.
 Testability – Ease with which software can be tested.
 Reusability – Ability to reuse components across different systems.

Summary About Characteristics:

In the field of software engineering, a deep understanding of the characteristics of software

requirements, along with the core software characteristics, is essential for building effective and
reliable systems.

From functionality and usability to efficiency and integrity, these characteristics define the
overall quality and success of a software product. By prioritizing these attributes, software
engineers can create future-ready solutions that meet both technical and user-centric goals

The software provides all required features and performs its intended tasks correctly according to
user requirements.
 MODULE 1

What is software project management?

Project management is the discipline of defining and achieving project goals while optimizing for
any resource constraints during the lifecycle of a project.
A subset of project management, Software Project Management is the practice of planning and
delivering software development projects within variables such as:

 Time
 Quality
 Cost
 The wider scope

The software project follows the end-to-end Software Development Lifecycle (SDLC), which
encompasses many steps from gathering requirements to developing and testing to releasing the
product and, finally, ongoing maintenance.
(See how product management supports the IT organization.)
Now, let’s turn to the four phases.
Phase 1: Inception (Scoping & Justifying a Project)

 Identify project goals and objectives

 Analyze feasibility and business value
 Define project scope and constraints
 Estimate cost, time, and resources
 Get approval to start the project

Phase 2: Elaboration (Defining Project Needs)

 Gather and analyze detailed requirements

 Identify risks and plan mitigation strategies
 Design system architecture and workflow
 Refine project schedule and budget
 Prepare a detailed project plan

Phase 3: Construction (Managing Resources)

 Develop and code the software

 Allocate and manage team resources
 Perform testing and debugging
 Monitor progress and control changes
 Ensure quality standards are met

Phase 4: Transition (Releasing the Product)

 Deploy the software to users

 Conduct final testing and validation
 Provide user training and documentation
 Fix post-release issues and bugs
 Hand over the system for maintenance

The main goal of a software project is to deliver a reliable, high-quality software product that
meets user requirements within time and cost constraints.
 MODULE 1

Software Myths:
Most, experienced experts have seen myths or superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates major problems for management and technical
people.
The types of software-related myths are listed below:

1) Management Myths:
Managers in charge of developing high-quality software are frequently under pressure to stick
to budgets, meet deadlines, and improve overall quality.
Myth1: A book of standards is enough.
Reality: Standards are rarely used, often incomplete, and may be outdated.

Myth2: Latest hardware ensures better software.

Reality: Proper methods and CASE tools matter more than hardware.

Myth3: Adding more programmers speeds up delivery.

Reality: New staff increase coordination effort and may delay the project.

Myth4: Outsourcing means no internal management needed.

Reality: Poor internal control leads to failure even when outsourcing.

2) Customer Myths
The customer may be users, technical staff, marketing/sales, or another company, and their
myths create false expectations that lead to dissatisfaction with the developer.
Myth1: General goals are enough to start development.
Reality: Clear, detailed requirements and documentation are essential.

Myth2: Changes are easy because software is flexible.

Reality: Late changes greatly increase cost and effort.

3) Practitioners’ Myths
Developers believe their work is finished once the software runs, but in reality ongoing testing,
feedback, and maintenance are required.
Myth1: Work ends once the software runs.
Reality: Maintenance, feedback, and updates take most of the effort.

Myth2: Quality can be judged only after execution.

Reality: Reviews and testing can ensure quality from early stages.
A successful project is only possible when such myths are dispelled in a timely and effective
manner. If these myths are not dispelled, it can lead to a waste of time and effort for everyone
involved.
 MODULE 1

Introduction To Software Project Planning

Software Project Planning – Definition

Software project planning is the process of deciding what work needs to be done, how it will
be done, who will do it, and how long it will take to successfully develop a software project.

Where We Use Software Project Planning?

Software project planning is used in software development projects such as web applications,
mobile apps, enterprise systems, and embedded software, starting from the initial idea stage and
continuing throughout the project lifecycle.

Why We Use Software Project Planning?

We use software project planning to organize tasks, estimate time and cost, allocate
resources, reduce risks, and ensure the project is completed on time, within budget, and
meets customer requirements.

Some guidelines are followed when designing a project. These guidelines are outlined
below.

 Planning: Before starting a project, clear objectives and timelines are defined for smooth
execution.
 Risk Analysis: Possible risks like changing requirements are identified, and their impact
on time and cost is estimated.
 Monitoring Progress: The project plan is regularly tracked and updated when required.
 Quality Assurance: The plan includes methods to ensure software quality within
planned time and cost.
  Flexibility: The project plan allows changes to be made as the project evolves.

Project Planning Process

The project planning process consists of interrelated steps performed in a logical order to convert user
requirements into software. It defines planning activities and the people responsible for them and
includes the following steps.

 Identification of Project Requirements – Determine what the project needs and its
objectives.

 Identification of Cost Estimates – Assess the expected costs to complete the project.

 Identification of Risks – Identify potential issues or challenges that may affect the project.

 Identification of Critical Success Factors – Determine key elements that will make the
project successful.

 Preparation of Project Charter – Create a formal document authorizing the project.

 Preparation of Project Plan – Develop a detailed plan outlining how the project will be
executed.

 Commencement of the Project – Officially start the project based on planning and
preparation.
 MODULE 1

Scheduling and Management in Software Engineering

Scheduling and management involve planning, tracking, and controlling project time, tasks, and
resources to deliver quality software on time and within budget.

Core Management Components

 Project Planning: Define scope, objectives, and deliverables.

 Risk Management: Identify and reduce potential project risks.
 Resource Management: Allocate people, tools, and hardware effectively.
  Configuration & Change Management: Control changes in software and documents.
 Measurement & Metrics: Use data to monitor progress and quality.

Project Scheduling Process

 WBS: Break the project into small manageable tasks.

 Activity Sequencing: Identify task dependencies.
 Estimation: Predict effort and time required.
 Schedule Development: Create timelines and identify the critical path.
 Monitoring: Track progress and adjust schedules as needed.

Scheduling Techniques

 Gantt Charts: Visualize task timelines.

 PERT: Handle uncertainty using time estimates.
 Agile Scheduling: Plan work in short iterations (sprints).
 Duration Compression: Reduce schedule using crashing or fast-tracking.

Tools Used

 Project Management: MS Project, Jira, Smartsheet.

 Collaboration: Trello, Asana, [Link].
 Tracking: ClickUp, GanttPRO.
 MODULE 1

What is Software Layered Technology?

Software layered technology is a structured approach organizing systems into distinct
functional layers (like User Interface, Business Logic, Data Access) for separation of concerns,
maintainability, and reusability, with quality as the foundation. In software engineering, this
concept applies to the process itself, comprising Quality Focus, Process, Methods, and Tools,
where each layer builds on the one below, ensuring systematic, high-quality software creation.

Where Software Layered Technology is Used?

Software layered technology is used in:

 Software development projects to build reliable and high-quality applications

 System analysis and design to follow structured methods
 Large and complex systems like banking, healthcare, and enterprise software
 Team-based development to manage process, quality, and tools effectively
 Maintenance and upgrades to control changes and ensure quality

Core Concept: Layered Architecture in Systems

 Abstraction: Higher layers use services from lower layers without needing to know
implementation details, simplifying complexity.
 Separation of Concerns: Each layer handles specific tasks (e.g., presentation, data
management, business rules).
 Examples: OS kernels (hardware, drivers, user programs), or web applications (UI,
backend logic, database).
The Four Layers of Software Engineering (Process-Focused):

1. Quality Focus (Foundation): The bedrock, emphasizing principles like integrity,

maintainability, and usability across all activities.
2. Process (The Recipe): Defines the framework, activities (Communication, Planning,
Modeling, Construction, Deployment), and tasks for development.
3. Methods (The "How-To"): Provides guidance and techniques for performing tasks
within the process (e.g., design patterns, coding standards, testing strategies).
4. Tools (Automation): Software that automates or supports methods and processes (e.g.,
IDEs, compilers, testing tools).

Benefits of Layered Technology

 Modularity: Easier to understand, develop, and maintain individual components.
 Reusability: Layers or components can be reused in different projects.
 Scalability & Flexibility: Allows for independent upgrades and scaling of specific parts.
 Manageability: Clear structure enhances project management and team collaboration.
 MODULE 1

Software Process Framework

Framework is a Standard way to build and deploy applications. Software Process Framework is a
foundation of complete software engineering [Link] process framework includes all
set of umbrella activities. It also includes number of framework activities that are applicable to
all software projects.
What is a Software Process Framework?
Software Process includes:
 Tasks: They focus on a small, specific objective.
 Action: It is a set of tasks that produce a major work product.
 Activities: Activities are groups of related tasks and actions for a major objective.

What Is a Software Development Framework?

A software development framework is a structured set of tools, libraries, best practices, and
guidelines that help developers build software applications. Think of it as a template or
foundation that provides the basic structure and components needed for a software project.
Key points:

 Foundation: Provides a basic structure for software development.

 Components & Tools: Offers ready-made components to speed up development.
  Best Practices: Ensures organized and efficient development.
 Customization: Allows developers to modify and extend features as needed.

Software process frame work activities

A generic process framework encompasses five activities which are given below one by
one:

 Communication:
Interaction with customers and stakeholders to gather requirements.
 Planning:
Decide tasks, schedule, risks, and required resources.
 Modeling:
Create models to understand requirements and system design.
 Construction:
Develop code and test the software to build the product.
 Deployment:
Deliver the software to customers, collect feedback, and make improvements.

Umberalla activities

Umbrella activities support and manage the software process across all development phases.

Umbrella Activities are as follows:

 Project Tracking & Control: Monitor progress and schedules.

 Risk Management: Identify and reduce risks.
 SQA: Maintain software quality.
 Technical Reviews: Detect errors early.
 Measurement: Assess productivity and quality.
 Configuration Management: Manage and control changes.
 MODULE 1

The Software Development Cycle (SDLC):

 The Software Development Life Cycle (SDLC) is a structured framework used by
software organizations to design, develop, and test high-quality software. It defines the
entire process of software production, from the initial idea to the final deployment and
maintenance.

Stages of the Software Development Life Cycle

Stage 1 : Planning
In this stage, the team first decides what the project is about and what the software should include.
Then, they clearly define the goals the software needs to achieve. Finally, they plan the required
time, money, and people needed to complete the project successfully.

Stage 2 : Defining Requirments

In the requirement definition stage, the team clearly identifies what the software should do by
listing functional requirements. Technical requirements are then specified to explain how the
system should work. Finally, the requirements are reviewed and approved to ensure they are
clear, correct, and agreed upon by all stakeholders.

Stage 3 : Designing Architecture

In the design stage, the system structure is planned by creating low-level design details such as
modules and data flow. This is followed by high-level design, which defines the overall system
architecture and how different components interact.

Stage 4 : Development(Coding)
In the development stage, programmers write code by following coding standards to ensure
consistency. The code is made scalable so it can handle future growth, managed using version
control, and regularly reviewed to improve quality and reduce errors.

Stage 5 : Testing
In the system testing stage, the software is tested manually to find errors in functionality and
behavior, and then automated testing is used to repeatedly verify performance, accuracy, and
reliability.
Stage 6 : Deployment
In the deployment and maintenance stage, the software is released using proper planning and
automated deployment methods. After release, the system is maintained to fix issues and
improve performance, and user feedback is collected for future updates.

Stage 7 : Maintenance
The software life cycle does not end after deployment; it continues with maintenance to keep the
system useful and reliable. During this phase, bugs are fixed, libraries are upgraded, performance
is improved, and new features are added. The main outputs of this stage are patches, updates, and
new software versions, handled by support engineers and developers.

Software Development Life Cycle Models

Software Development Models are structured frameworks that guide the planning, execution,
and delivery of software projects. They define the sequence of development stages, such as
requirements, design, coding, testing, and deployment.

Common Models
 Waterfall Model
 Agile Model
 V-Model
 Spiral Model
 Incremental Model
 RAD Model

The goal of the SDLC is to produce high-quality software that meets or exceeds customer
expectations, reaches completion within time and cost estimates, and is efficient to maintain.
INTRODUCTION TO SOFE:
MODULE 1

Capability Maturity Model Integration (CMMI)

What is Capability Maturity Model Integration (CMMI)
 Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more
evolved model that incorporates best components of individual disciplines of CMM like
Software CMM, Systems Engineering CMM, People CMM, etc.
 Since CMM is a reference model of matured practices in a specific discipline, so it becomes
difficult to integrate these disciplines as per the requirements.
 This is why CMMI is used as it allows the integration of multiple disciplines as and when
needed.
Objectives of CMMI
 Fulfilling customer needs and expectations.
 Value creation for investors/stockholders.
 Market growth is increased.
 Improved quality of products and services.
 Enhanced reputation in Industry.
CMMI Representation - Staged and Continuous
A representation allows an organization to pursue a different set of improvement objectives. There
are two representations for CMM:
Staged Representation:
 uses a pre-defined set of process areas to define improvement path.
 provides a sequence of improvements, where each part in the sequence serves as a
foundation for the next.
 an improved path is defined by maturity level.
 maturity level describes the maturity of processes in organization.
 Staged CMMI representation allows comparison between different organizations for
multiple maturity levels.
Continuous Representation :
 allows selection of specific process areas.
 uses capability levels that measures improvement of an individual process area.
 Continuous CMMI representation allows comparison between different organizations on a
process-area-by-process-area basis.
 allows organizations to select processes which require more improvement.
CMMI Model - Maturity Levels
[Link] level 1 : Initial
 processes are poorly managed or controlled.
 unpredictable outcomes of processes involved.
 ad hoc and chaotic approach used.
 No KPAs (Key Process Areas) defined.
 Lowest quality and highest risk.
[Link] level 2 : Managed
 requirements are managed.
 processes are planned and controlled.
 projects are managed and implemented according to their documented plans.
 This risk involved is lower than Initial level, but still exists.
 Quality is better than Initial level.
[Link] level 3 : Defined
 processes are well characterized and described using standards, proper procedures, and
methods, tools, etc.
 Medium quality and medium risk involved.
 Focus is process standardization.
[Link] level 4 : Quantitatively managed
 quantitative objectives for process performance and quality are set.
 quantitative objectives are based on customer requirements, organization needs, etc.
 process performance measures are analyzed quantitatively.
 higher quality of processes is achieved.
 lower risk
[Link] level 5 : Optimizing
 continuous improvement in processes and their performance.
 improvement has to be both incremental and innovative.
 highest quality of processes.
 lowest risk in processes and their performance.
 MODULE 1

Conventional Models
What is Conventional Models
 Conventional Models in Software Engineering (also called traditional process models) are
structured, plan-driven approaches used to guide software development.
 They emphasize thorough documentation, well-defined phases, and sequential progress.
Key Characteristics
 Linear Progression: Each phase must be completed before the next begins.
 Extensive Upfront Planning: Detailed requirements and design are established early.
 Defined Phases & Deliverables: Clear milestones and outputs for each stage.
 Documentation-Heavy: Significant emphasis on producing detailed documents.
 Less Flexibility: Changes are difficult and costly to incorporate once a phase is complete.
Common Conventional Models
1. Waterfall Model
2. V-Model
3. Spiral Model
4. Incremental Model (can be seen as a hybrid)
5. Iterative Model
6. Prototyping Model

1. Waterfall Model
 The Waterfall Model is a conventional and sequential software development model in
which development progresses through a fixed set of phases, with each phase completed
before the next one begins.
 The typical phases include requirements analysis, system design, implementation (coding),
testing, deployment, and maintenance.
 In this model, requirements are gathered and documented at the beginning, and there is
little scope for change once development starts.
 The Waterfall Model is easy to understand and manage because of its structured approach
and clear documentation at every stage.
 However, testing is performed only after implementation, so errors discovered late can be
costly to fix.
 Due to its rigid nature, the Waterfall Model is best suited for small projects with well-
defined, stable requirements and minimal expected changes.

Advantages
 Simple and easy to understand and manage.
 Clear stages and defined deliverables for each phase.
 Ideal for projects with very stable and well-understood requirements.
Disadvantages
 Highly inflexible; difficult and costly to accommodate changes after a phase is completed.
 Testing happens late in the cycle, making defect discovery expensive.
 High risk if requirements are not fully understood or change during development.
2. V-Model
 The V-Model (Verification and Validation Model) is a traditional software development
model that extends the Waterfall approach by emphasizing testing at every stage of
development.
 It is called the V-Model because its structure forms a “V” shape, where the left side
represents verification activities such as requirement analysis and system design, and the
right side represents corresponding validation activities through testing.
 In this model, each development phase has a directly related testing phase: requirements
are validated through acceptance testing, system design through system testing, high-level
design through integration testing, and low-level design through unit testing.
 Coding is performed at the bottom of the V, after which testing activities are carried out in
sequence.
 The main advantage of the V-Model is early test planning, which helps detect defects at an
early stage and improves software quality.
 However, it is rigid and does not handle changes easily, making it most suitable for projects
with clear, stable requirements and for safety-critical systems where reliability is essential.

Advantages
 Early test planning leads to better quality.
 Clear definition of testing activities for each development phase.
 Improved defect detection likelihood due to early test case design.
Disadvantages
 Still relatively inflexible to requirement changes.
 Can be complex to manage if not well-defined from the start.
 Not ideal for projects with evolving or uncertain requirements.
3. Spiral Model
 The Spiral Model is a risk-driven software development model that combines iterative
development with systematic planning and control.
 In this model, the software is developed through a series of loops or spirals, where each
loop represents a development phase.
 Every spiral consists of four main activities: planning, risk analysis, engineering (design
and implementation), and evaluation by the customer.
 The key strength of the Spiral Model is its strong focus on identifying and reducing risks
early in the development process, making it well suited for large, complex, and high-risk
projects.
 It also allows for continuous user feedback and gradual refinement of requirements.
However, the model is expensive, requires skilled risk analysis, and is not suitable for small
or low-risk projects.

Advantages
 Excellent for large, complex, and high-risk projects.
 Risk management is integrated throughout the lifecycle.
 Allows for changes and feedback throughout iterations.
Disadvantages
 Can be complex and expensive to manage.
 Requires significant expertise in risk analysis.
 Not suitable for small or low-risk projects.
4. Incremental Model
 The Incremental Model is a software development approach in which the system is
designed, implemented, and tested in small, manageable increments, with each increment
adding new functionality to the existing system.
 Instead of delivering the complete product at once, a basic working version is released first,
followed by successive versions that enhance features and performance.
 This model allows early delivery of usable software, continuous user feedback, and easier
identification of defects.
 It reduces overall project risk and supports changes more effectively than purely sequential
models. However, it requires careful planning and a well-defined overall architecture from
the beginning.
 The Incremental Model is best suited for projects where requirements can be divided into
independent modules and early delivery is important.

Advantages
 Early delivery of working software
 More flexible than waterfall
 Easier to test and debug
Disadvantages
 Higher costs
 More time spent on testing
 Difficulty in tracking progress
5. Iterative Model
 The Iterative Model is a software development approach in which the system is developed
through repeated cycles (iterations), with each iteration producing an improved and more
complete version of the software.
 Instead of building the entire system at once, development begins with a basic version that
addresses core requirements, and additional features are added and refined in subsequent
iterations based on user feedback and evaluation.
 Each iteration involves planning, design, implementation, and testing, allowing issues to
be identified and resolved early.
 The Iterative Model is flexible, supports changing requirements, and improves overall
quality through continuous testing and refinement. However, it requires effective
management and may lead to scope creep if not properly controlled.

Advantages
 Handles changing requirements
 Customer involvement is high
Disadvantages
 Less Predictable Timeline and Budget
 May Not Suit Small or Simple Projects
[Link] Model
 The Prototyping Model is a software development approach in which a preliminary version
of the system (prototype) is built to better understand and clarify user requirements.
 This prototype allows users to interact with the system and provide feedback, helping
developers identify missing, unclear, or incorrect requirements at an early stage. Based on
user feedback, the prototype is refined or discarded before developing the final system.
 Prototyping is especially useful when requirements are not well defined or when user
interaction plays a major role.
 The model improves user satisfaction and reduces misunderstandings, but it may lead to
poor design or inadequate documentation if the prototype is mistakenly evolved into the
final product without proper planning.

Advantages
 Suitable for large systems.
 Customer communication is available.
 Quality of software is good.
 It helps to identifying the requirements.
Disadvantages
 It is very difficult to predict how the system will work after development.
 This model is time consuming.
 MODULE 1

Agile Process Model

What is Agile Model
 The Agile Model was primarily designed to help a project adapt quickly to change requests.
So, the main aim of the Agile model is to facilitate quick project completion.
 To accomplish this task, it's important that agility is required. Agility is achieved by fitting
the process to the project and removing activities that may not be essential for a specific
project.
 Also, anything that is a waste of time and effort is avoided. The Agile Model refers to a
group of development processes.
 These processes share some basic characteristics but do have certain subtle differences
among themselves.

Steps in the Agile Model

The Agile Model is a combination of iterative and incremental process models.
1. Requirement Gathering
2. Design the Requirements
3. Construction / Iteration
4. Testing / Quality Assurance
5. Deployment
6. Feedback
[Link] Gathering
 In this step, the development team must gather the requirements, by interaction with the
customer.
 Development team should plan the time and effort needed to build the [Link] on
this information you can evaluate technical and economical feasibility.
[Link] the Requirements
 In this step, the development team will use user-flow-diagram or high-level UML
diagrams to show the working of the new features and show how they will apply to the
existing software.
 Wireframing and designing user interfaces are done in this phase.
[Link] / Iteration
 In this step, development team members start working on their project, which aims to
deploy a working product.
 Each cycle typically consist between 1-4 weeks, and at the end, the team delivers a working
version of the software.
[Link] / Quality Assurance
Testing involves Unit Testing, Integration Testing, and System Testing, Which help in the agile
development models:
 Unit testing

 Integration testing

 System testing

[Link]
 In this step, the development team will deploy the working project to end users.

 Once an iteration is finished and fully tested, the software is ready to be released to the end
users. In Agile, deployment isn't a one-time event—it's an ongoing process. Updates and
improvements are rolled out regularly, making sure the software keeps evolving and getting
better with each release.
[Link]
 This is the last step of the Agile Model. In this, the team receives feedback about the
product and works on correcting bugs based on feedback provided by the customer.
 Take feedback from customers, users, and stakeholders after each iteration.

 Understand how well the product meets user needs and identify areas for improvement.

 Check for bugs or issues that need fixing.

 Make adjustments to the development plan based on feedback to improve the product
further.
Agile Methodologies
 Scrum: A framework for managing complex projects, emphasizing teamwork,
accountability, and iterative progress.

 Kanban: A method for visualizing workflow, limiting work in progress (WIP), and
maximizing efficiency.
 Extreme Programming (XP): Focuses on engineering practices and team collaboration for
high-quality software.
 Lean Software Development: Applies lean manufacturing principles to software
development, focusing on eliminating waste.

Principles of the Agile models

 Our highest priority is to satisfy the client through early and continuous delivery of
valuable computer software.
 Welcome dynamic necessities, even late in development. Agile processes harness
modification for the customer’s competitive advantage.
 Deliver operating computer software often, from a pair of weeks to a couple of months,
with a preference to the shorter timescale.
 Business individuals and developers should work along daily throughout the project.
  The build comes around actuated people. offer them the setting and support they have, and
trust them to urge the task done.
 the foremost economical and effective methodology of conveyancing info to and among a
development team is face-to-face speech.
 Working with computer software is the primary life of progress.
 Agile processes promote property development. The sponsors, developers, and users will
be able to maintain a relentless pace indefinitely.
 Continuous attention to technical excellence and smart style enhances nimbleness.
 Simplicity—the art of maximizing the number of work not done—is essential.
 the most effective architectures, necessities, and styles emerge from self–organizing
groups.
 At regular intervals, the team reflects on a way to become simpler, then tunes and adjusts
its behavior consequently.

When To Use the Agile Model?

 New changes can be implemented at a very low cost due to the frequency of new
increments.
 Implementing a new feature requires developers to lose only a few days or even just hours
of work to get it back and implemented.
 In the Agile model, unlike the Waterfall model, very limited planning is required to start a
project.
 Agile believes that the needs of end users are always changing in the dynamic business and
IT world.
 Changes can be discussed and features can be redesigned or removed based on feedback.

Advantages
 Improved Quality
 Flexibility & Adaptability
Disadvantages
 Less Predictability
 Depends on Team Experience
 MODULE 1

Unified Process Model

What is Unified Process Model
 The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a software
development methodology that emphasizes iterative development, collaboration, and
flexibility.
 It is based on the Unified Modeling Language (UML) and is characterized by its use of use
cases to drive development, its focus on architecture-centric development, and its emphasis
on risk management and incremental delivery.
 UP is a flexible and adaptable process that can be tailored to meet the specific needs of a
project or organization, making it a popular choice for many software development teams.

Importance of Unified Process

 Complex software projects are made more manageable by Unified Process. It breaks them
into smaller, iterative chunks.
 Clear guidelines and workflows from Unified Process boost communication. It ensures
stakeholder collaboration is seamless.
 Continuous feedback is emphasized by UP's approach. High-quality software meeting
requirements are the result.
Key Principles of Unified Process
Below are the key principles of the Unified Process:
 Iterative and Incremental: Unified Process divides the development process into multiple
iterations, with each iteration adding new functionality incrementally.
 Use Case Driven: The Unified Process focuses on identifying and prioritizing use cases
that represent the system's functionality from the user's perspective.
 Architecture-Centric: The Unified Process emphasizes defining and refining the system
architecture throughout the development process.
 Risk Management: Unified Process identifies and manages project risks proactively to
minimize their impact on the project's success.
 Continuous Validation: Unified Process ensures continuous validation of the system's
requirements, design, and implementation through reviews, testing, and feedback.
Phases of Unified Process
 Unified Process (UP) is characterized by its iterative and incremental approach to software
development.
 The phases in Unified Process provide a structured framework for managing the various
activities and tasks involved in building a software system.
 Here's an in-depth look at each phase:

1. Inception
 This is the initial phase where the project's scope, objectives, and feasibility are determined.
 Key activities in this phase include identifying stakeholders, defining the initial
requirements, outlining the project plan, and assessing risks.
 The goal of this phase is to establish a solid foundation for the project and ensure that it is
worth pursuing.
2. Elaboration
 In this phase, the project requirements are analyzed in more detail, and the architecture of
the system is defined.
 Key activities include developing use cases, creating the architectural baseline, identifying
key components, and refining the project plan.
 The goal of this phase is to mitigate major risks and establish a solid architectural
foundation for the project.

3. Construction
 This is the phase where the actual implementation of the system takes place.
 Key activities include developing, testing, and integrating the system components, as well
as continuously verifying that the system meets the requirements.
 The goal of this phase is to build a complete, high-quality software product that is ready
for deployment.
4. Transition
 In this final phase, the software is deployed to end users. Key activities include user
training, final system testing, and transitioning the system to the operations and
maintenance team.
 The goal of this phase is to ensure a smooth transition from development to production and
to address any issues that arise during deployment.
 These phases are iterative, meaning that they may be revisited multiple times throughout
the project to incorporate feedback, make improvements, and address changes in
requirements.
 This iterative approach allows for flexibility and adaptability, making the Unified Process
well-suited for complex and evolving software projects.

Unified Process Iterations

 The UP lifecycle is structured into a series of iterations.
 Each iteration produces a working, tested, and integrated system increment.
 Iterations can vary in length and may span across phases.
 The goal is to deliver value incrementally and manage risks.
Unified Process Workflows

 UP defines a set of core workflows (disciplines) that are performed throughout the
project.
 These include: Business Modeling, Requirements, Analysis & Design, Implementation,
Test, Deployment, Configuration & Change Management, Project Management,
Environment.

Advantages
 Improved Quality
 Iterative and Incremental Development
Disadvantages
 Complex to Understand and Implement
 Tool Dependency
 MODULE 1

Extreme Programming
What is Extreme Programming (XP)?
 Extreme Programming (XP) is an Agile software development methodology that focuses
on delivering high-quality software through frequent and continuous feedback,
collaboration, and adaptation.
 XP emphasizes a close working relationship between the development team, the customer,
and stakeholders, with an emphasis on rapid, iterative development and deployment.

Agile principles
 Working software is the key measure of progress in a project.
 For progress in a project, therefore software should be developed and delivered rapidly in
small increments.
 Even late changes in the requirements should be entertained.
 Face-to-face communication is preferred over documentation.
 Continuous feedback and involvement of customers are necessary for developing good-
quality software.
 A simple design that involves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
 The delivery dates are decided by empowered teams of talented individuals
Good practices in extreme programming
Some of the good practices that have been recognized in the extreme programming model and
suggested to maximize their use are given below:

 Small projects: The XP model is very useful in small projects consisting of small teams as
face-to-face meeting is easier to achieve.
 Projects involving new technology or Research projects: This type of project faces
changing requirements rapidly and technical problems. So XP model is used to complete
this type of project.
 Web development projects: The XP model is well-suited for web development projects as
the development process is iterative and requires frequent testing to ensure the system
meets the requirements.
 Collaborative projects: The XP model is useful for collaborative projects that require close
collaboration between the development team and the customer.
 Projects with tight deadlines: The XP model can be used in projects that have a tight
deadline, as it emphasizes simplicity and iterative development.
 Projects with rapidly changing requirements: The XP model is designed to handle rapidly
changing requirements, making it suitable for projects where requirements may change
frequently.
 Projects where quality is a high priority: The XP model places a strong emphasis on testing
and quality assurance, making it a suitable approach for projects where quality is a high
priority.
Life Cycle of Extreme Programming (XP)

 Planning: The first stage of Extreme Programming is planning. During this phase, clients
define their needs in concise descriptions known as user stories. The team calculates the
effort required for each story and schedules releases according to priority and effort.
 Design: The team creates only the essential design needed for current user stories, using a
common analogy or story to help everyone understand the overall system architecture and
keep the design straightforward and clear.
 Coding: Extreme Programming (XP) promotes pair programming i.e. wo developers work
together at one workstation, enhancing code quality and knowledge sharing. They write
tests before coding to ensure functionality from the start (TDD), and frequently integrate
their code into a shared repository with automated tests to catch issues early.
 Testing: Extreme Programming (XP) gives more importance to testing that consist of both
unit tests and acceptance test. Unit tests, which are automated, check if specific features
work correctly. Acceptance tests, conducted by customers, ensure that the overall system
meets initial requirements. This continuous testing ensures the software's quality and
alignment with customer needs.
 Listening: In the listening phase regular feedback from customers to ensure the product
meets their needs and to adapt to any changes.
Values of Extreme Programming (XP)
 Communication: The essence of communication is for information and ideas to be
exchanged amongst development team members so that everyone has an understanding of
the system requirements and goals. Extreme Programming (XP) supports this by allowing
open and frequent communication between members of a team.
 Simplicity: Keeping things as simple as possible helps reduce complexity and makes it
easier to understand and maintain the code.
 Feedback: Feedback loops which are constant are among testing as well as customer
involvements which helps in detecting problems earlier during development.
 Courage: Team members are encouraged to take risks, speak up about problems, and adapt
to change without fear of repercussions.
 Respect: Every member's input or opinion is appreciated which promotes a collective way
of working among people who are supportive within a certain group.
 MODULE 1

Scrum
What is a scrum
 Scrum is a management framework that teams use to self-organize tasks and work towards
a common goal.
 It is a framework within which people can address complex adaptive problems while the
productivity and creativity of delivering products are at the highest possible value.
 Scrum is a management framework that teams use to self-organize and work towards a
common goal.
 Scrum allows us to develop products of the highest value while making sure that
we maintain creativity and productivity.
 The iterative and incremental approach used in scrum allows the teams to adapt to
the changing requirements.

 Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately after
the completion of the previous Sprint.
 Release: When the product is completed, it goes to the Release stage.
 Sprint Review: If the product still has some non-achievable features, it will be checked in
this stage and then passed to the Sprint Retrospective stage.
 Sprint Retrospective: In this stage quality or status of the product is checked.
 Product Backlog: According to the prioritize features the product is organized.
 Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to sprint
and Sprint planning meeting.
The Scrum Flow: Visualizing the Cycle
 Scrum operates on an iterative and incremental cycle, allowing for continuous delivery and
adaptation.
 Imagine a circular flow: Sprint Planning initiates the Sprint, followed by Daily Scrums
guiding the ongoing development.
 At the end of the Sprint, the Sprint Review showcases the Increment and gathers feedback,
leading into the Sprint Retrospective to refine processes.
 This cycle repeats, ensuring the product evolves based on feedback and changing needs.

Features of Scrum

 Scrum is a light-weighted framework

 Scrum emphasizes self-organization

 Scrum is simple to understand

 Scrum framework helps the team to work together

Advantage of Scrum framework

 Scrum framework is fast moving and money efficient.

 Scrum framework works by dividing the large product into small sub-products. It's like a
divide and conquer strategy
 In Scrum customer satisfaction is very important.

Disadvantage of Scrum framework

 Scrum framework do not allow changes into their sprint.

 It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear
definition.
 MODULE 1

Functional and Non Functional Requirements

Functional and Non Functional Requirements
 Requirements analysis is an essential process in software development. It helps to
determine whether a system or project will meet its objectives and achieve success.
 To make this analysis effective, requirements are generally divided into two categories:

Functional Requirements
 Functional requirements define the specific features and operations a system must perform
to meet business and user needs.
 They describe what the system should do and how it should interact with users or other
systems.
 Focus on system behavior and functionality.
 Represent the features that can be directly observed and tested in the final product.
 Common examples include user authentication, data processing, search, payment
handling, and report generation.
Non-Functional Requirements
 Non-functional requirements (NFRs) define how a system should operate, focusing on
performance, reliability, and user experience rather than specific features.
 They ensure the system is efficient, secure, and maintainable over time.
 Performance – speed and responsiveness
 Security – protection against unauthorized access
 Usability – ease of use
 Reliability – system stability and availability
 Scalability – ability to handle growth
 Maintainability – ease of updates and fixes
 Portability – ability to run in different environments
 MODULE 1

User Requirements
What is User Requirements
 User requirements in software engineering define what end-users need and expect from a
system, described in simple, non-technical language to guide development, focusing on
high-level goals, features, and user interactions rather than how the system works
technically, forming the foundation for detailed system requirements.
 They are gathered via interviews, surveys, and feedback, and documents like User
Requirements Specifications (URS) detail these needs for stakeholders, ensuring the final
product aligns with business goals and user tasks.
Key Characteristics
 User-Focused: Written from the end-user's perspective, explaining what they want the
software to do, not how.
 Natural Language: Uses simple, clear language, avoiding jargon, often expressed in user
stories or high-level statements.
 High-Level: Describes goals, features, and desired outcomes (e.g., "The user shall be able
to upload photos").
 Smart: Should be Specific, Measurable, Achievable, Relevant, and Time-bound (SMART)
where possible.
Types of User Requirements
1. Functional Requirements: What the system must do (e.g., user registration, search, payment
processing).
2. Non-Functional Requirements (Quality Attributes): How the system should perform (e.g.,
security, performance, usability, reliability).
Users Requirements of Document
Purpose in Software Development
 Foundation: Serves as the basis for detailed system requirements, design, and testing.
 Communication: Bridges the gap between non-technical users/stakeholders and the
technical development team.
 Reduces Misunderstandings: Clearly defining needs early prevents costly changes later.
Examples
 The system must allow customers to create an account with their email and
password."(Functional)
 The application must load the user's dashboard in under 2 seconds. (Non-
Functional/Performance)
 The production manager needs to view daily sales reports in PDF format."(Functional)
 MODULE 1

System Requirements
What is System Requirements
 System requirements describe what a software system should do and the constraints under
which it must operate.
 They act as a formal agreement between stakeholders and the development team, clearly
defining the system’s functionality, performance, and limitations.
 System requirements are usually documented in a Software Requirements Specification
(SRS) document.

Importance of System Requirements

 Define clear system goals
 Avoid misunderstandings between stakeholders
 Help in accurate planning and cost estimation
 Reduce rework and project risks
 Ensure the system meets user needs

Characteristics of Good System Requirements

 Clear and Unambiguous: Each requirement should have only one meaning and be easy to
understand.
 Complete and Consistent: All necessary requirements are included and do not conflict with
each other.
 Verifiable and Testable: Every requirement can be checked through testing or inspection.
 Feasible and Realistic: Requirements can be implemented within given time, budget, and
resources.
 Traceable: Each requirement can be tracked throughout the entire software development
life cycle.
Key Types of Requirements
1. Functional Requirements: Describe specific actions or functions the system must perform
(e.g., "The system shall allow users to log in with a username and password").
2. Non-Functional Requirements (Quality Attributes): Define system quality, performance, and
constraints.
 Performance: Response time, throughput (e.g., 1000 transactions/sec).
 Security: Authentication, authorization, encryption.
 Usability: Ease of use, user interface.
 Reliability: Uptime, error handling.
 Maintainability: Ease of updates and fixes.
 Portability/Compatibility: Ability to run on different environments/hardware.
Role of System Requirements in Software Development

Examples of System Requirements

 The system shall allow users to log in using a username and password
 The system shall process transactions within 2 seconds
 The system shall support at least 500 concurrent users
 The system shall comply with data security standards
 III CSE II Semester

SOFTWARE ENGINEERING (22CS307)

2025-26 II Semester
INTRODUCTION TO SOFTWARE: MODULE 1

Requirement Engineering
Requirement Engineering (RE) is a systematic and disciplined process of identifying, analyzing,
documenting, validating, and managing the requirements of a software system. It plays a critical
role in the success of software projects because requirements form the foundation for design,
development, testing, and maintenance.

Objectives of Requirement Engineering

 To clearly understand user needs and expectations.
 To define system functionality and constraints precisely.
 To serve as a baseline for all subsequent SDLC activities.
Requirement Engineering Tasks
The requirements engineering process consists of a set of well-defined tasks carried out
iteratively throughout the project lifecycle.
Inception
 Identify the problem to be solved and the need for the system.
 Determine key stakeholders, users, and customers.
 Establish system objectives, high-level requirements, and project scope.
Elicitation
 Gather functional and non-functional requirements using interviews, workshops,
observation, and questionnaires.
 Understand user workflows, business processes, and expectations.
 Identify constraints, assumptions, and dependencies.
Elaboration
 Refine requirements into structured models, use cases, and scenarios.
 Identify domain classes, attributes, and relationships.
 Clarify functional, informational, and behavioral requirements.
Negotiation
 Resolve conflicts among stakeholders and prioritize requirements.
 Evaluate requirements against cost, time, and resource constraints.
 Identify trade-offs and agree on a realistic set of requirements.
Specification
 Document finalized requirements formally in the Software Requirements Specification
(SRS).
 Include textual descriptions, models, and diagrams.
 Serve as a reference for design, coding, testing, and a contractual agreement.
Validation
 Ensure requirements are correct, complete, consistent, and feasible.
 Identify missing, ambiguous, or unrealistic requirements.
 Use reviews, walkthroughs, inspections, and prototyping to prevent rework.
Requirements Management
 Track and control requirement changes with unique identifiers.
 Maintain traceability between requirements, design, and implementation.
Software Requirements Specification (SRS)
A Software Requirements Specification (SRS) is a comprehensive written description of the
software requirements to be developed. It serves as a vital guide throughout the project to ensure
clarity, reduce misunderstandings, and provide a common understanding between stakeholders
and development teams.

Components of an SRS
An SRS document typically includes the following types of requirements:
 Functional Requirements: Defines system behavior, processing logic, and expected
outputs, including calculations and validation rules.
 Interface Requirements: Describes interactions with users, hardware, or other systems
via APIs, communication formats, and data streams.
 Performance Requirements: Specifies system efficiency, such as response times,
memory usage, and error limits.
 Non-Functional Requirements: Outlines quality parameters like usability, reliability,
scalability, security, and maintainability.
 Design Constraints: Lists technical restrictions, such as specific algorithms, technology
standards, or resource limitations.
 Appendices: Contains supporting information, including definitions, abbreviations,
diagrams, and tables.
Uses of the SRS Document
The SRS document is used by various project stakeholders:
 Development Team: To build the product according to specific needs.
 Testing Group: To generate test plans based on described external behavior.
 Maintenance Staff: To understand the intended functions of the software.
 Project Managers: To create plans and estimates for schedules and resources.
 Customers: To understand what product they can expect and as a formal contract with
the developer.
Requirements Verification
Requirements verification is the process of confirming that requirements contain all necessary
elements of a well-written specification. It is a critical step that should be performed early and
often to prevent expensive rework later in development.

Importance of Verification
 Ensures Quality: Guarantees specifications are complete, correct, and consistent.
 Reduces Costs: Fixes errors in the documentation phase rather than in the final code.
 Early Detection: Uncovers ambiguous or missing requirements to avoid cascading
issues.
 Minimizes Risk: Reduces the likelihood of system failure during critical phases.
Verification Techniques
 Inspection: A systematic, formal review by experts to find errors or omissions.
 Testing: Executing tests (unit, integration, or acceptance) to verify functionality.
 Walkthrough: A less formal review where stakeholders provide feedback.
 Prototyping: Building a simplified version of the software to validate needs.
Feasibility Study
A feasibility study is a systematic analysis conducted to evaluate the practicality, costs, benefits,
and overall viability of a proposed system or project. It helps in deciding whether the project
should be approved, modified, postponed, or rejected. The study examines various aspects such
as technical, economic, operational, legal, and scheduling feasibility to ensure that the project
can be successfully completed within the given constraints and available resources.

Needs of Feasibility Study

 Identifies problems and limitations of the existing system.
 Determines system goals and possible solutions.
 Selects suitable technology and user-friendly solutions.
Importance of Feasibility Study
 Analyzes costs and benefits to justify investment.
 Checks technical, financial, and operational viability.
 Supports informed and confident decision-making.
Types of Feasibility Study

Technical Feasibility
 Evaluates availability of required technology and tools.
 Checks technical skills and infrastructure readiness.
  Ensures the system can be developed successfully.
Economic Feasibility
 Estimates total project cost and expected benefits.
 Performs cost-benefit analysis and ROI calculation.
Operational Feasibility
 Examines compatibility with existing workflows.
 Ensures smooth integration into daily operations.
Social Feasibility
 Evaluates impact on society and stakeholders.
 Measures social acceptance and cultural suitability.

Steps to Conduct a Feasibility Study

Step 1: Define Goals & Scope
Define the project purpose, objectives, and boundaries.
Step 2: Gather Required Data
Collect financial, technical, market, legal, and operational data.
Step 3: Market Analysis
Analyze market demand, customers, trends, and competitors.
Step 4: Technical Feasibility
Check availability of technology, infrastructure, and skills.
Step 5: Financial Feasibility
Evaluate costs, revenues, ROI, NPV, and payback period.
Step 6: Operational & Organizational Feasibility
Assess manpower, processes, and organizational readiness.
Step 7: Compile Results & Recommend
Summarize findings and give a final project recommendation.
Data modeling
Data modelling in analysis is the process of creating a visual representation, abstraction of data
structures, relationships and rules within a system or organization.

Data Model
 Represents data elements and their relationships visually.
 Helps organize, store, access, and manage data efficiently.
 Enables collaboration between business and technical teams.
Types of Data Models
Used to represent data at different levels of abstraction. It consists of
Conceptual Data Model
 Represents high-level business concepts and relationships.
 Focuses on understanding business requirements.
 Used by stakeholders and analysts in early stages.
Logical Data Model
 Defines entities, attributes, tables, and relationships.
 Independent of any specific DBMS.
 Used by data architects and analysts for design.
Physical Data Model
 Represents actual database implementation.
  Includes tables, columns, keys, and constraints.
 Used by developers and database administrators.
Data Modeling Process
Data modelers work closely with stakeholders such as developers, database administrators and
business users at each stage to define entities and attributes, establish relationships and create
models that accurately represent data in a format usable by applications.

1. Identifying data sources: The first step is to identify and examine data sources, both internal
and external to the organization.

2. Defining Entities and Attributes: At this stage, data modelers identify entities (objects or
concepts) and their attributes (characteristics).

3. Mapping Relationships: Relationships define the associations between entities.

4. Choosing a model Type: Selecting the appropriate data model type is crucial and depends on
project requirements and data characteristics.

5. Implementing and Maintaining: Implementation involves converting a logical or physical

data model into a database schema.
Data Objects
• An object is a specific instance of a data type.

• Each object has three key characteristics:

• Identity: Unique memory address.

• Type: Defines the operations an object supports (e.g., int, str, list).

• Value: The data the object holds.

Built-in Data Objects: Core Types

• Numeric Types:
• Integers (`int`): Whole numbers.
• Floating-point (`float`): Numbers with decimal points.
• Complex (`complex`): Numbers with real and imaginary parts.
• Boolean (`bool`): `True` or `False`.
• Strings (`str`): Immutable sequences of characters.
• NoneType (`None`): Represents the absence of a value.

Built-in Data Objects: Collections

• Lists (`list`): Mutable, ordered sequences of items.
• Tuples (`tuple`): Immutable, ordered sequences of items.
• Dictionaries (`dict`): Mutable, unordered collections of key-value pairs.
• Sets (`set`): Mutable, unordered collections of unique items.

Custom Data Objects: Classes

 Classes act as blueprints for objects.
 Define attributes and methods.
 Enable object-oriented programming.
Instantiating Objects
 Objects are created by calling the class.
 __init__ method initializes attributes.
 Each object is a separate instance.
Attributes
 Represent characteristics of an object.
 Store data related to the object.
 Can be instance-level or class-level.

 Nominal Attributes: Represent categories or labels with no inherent order.

 Binary Attributes: Have only two possible values such as yes/no or 0/1.
 Ordinal Attributes: Represent data with a meaningful order or ranking.
 Numeric Attributes: Represent measurable quantitative values.
 Interval-Scaled Attributes: Have equal intervals between values but no true zero.
 Ratio-Scaled Attributes: Have equal intervals with an absolute zero point.
 Discrete Attributes: Contain countable and distinct values only.
 Continuous Attributes: Can take any value within a given range.
Relationships
 Describe how classes, objects, and components interact.
 Help visualize system structure and dependencies.
 Commonly represented using UML diagrams.
Types of relationship
 There are various types of relationships in software [Link] are

Association
 Represents a connection between two or more classes.
 Can be binary or multi-class association.
 Shown using a solid line in UML.
Aggregation
 A special association representing a “has-a” relationship.
 Parts can exist independently of the whole.
 Represents whole–part or container–content relation.
Composition
 Stronger form of aggregation.
 Parts cannot exist without the whole.
 Parts are destroyed when the whole is destroyed.
Generalization
 Represents inheritance between classes.
 Child class inherits properties of parent class.
 Shown with a solid line and arrow toward parent class.
Dependency
 Indicates a weak relationship between classes.
 Change in one class may affect another.
 Represented using a dashed arrow line.
Realization
 Represents implementation of an interface by a class.
 Similar to inheritance but with interfaces.
 Shown using a dashed line with arrow.
Cardinality
 Represents how many times an entity participates in a relationship.
 Defines how data in different tables are connected.
 Helps identify number of possible relationship instances.
Mapping Cardinality
 Specifies how many entities of one set relate to another.
 Mainly used for binary relationships in ER models.
 Helps in proper table linking and normalization.
Types of Cardinality
Types of cardinality in between tables are:

One-to-One Relationship
 One entity in A relates to only one entity in B.
 Relationship is unique and exclusive.
 Used when entities are tightly linked.

One-to-Many Relationship
 One entity in A relates to many entities in B.
 Each entity in B relates to only one entity in A.
 Commonly used in parent–child relationships.
Many-to-One Relationship
 Many entities in A relate to a single entity in B.
 B can be associated with multiple A entities.
 Reverse form of one-to-many.

Many-to-Many Relationship
 Entities in A relate to multiple entities in B.
 Entities in B also relate to multiple entities in A.
 Usually resolved using a junction table.

Modality
 Also called participation constraint.
 Defines whether relationship participation is optional or mandatory.
 Uses values 0 (optional) and 1 (mandatory).
Optional Participation (Modality = 0)
 Entity may or may not participate in the relationship.
 Relationship occurrence is not compulsory.
 Entity can exist independently.
Mandatory Participation (Modality = 1)
 Entity must participate in the relationship.
 Relationship occurrence is compulsory.
 Entity cannot exist without the relationship.
Class-Based Modeling
 Represents system structure using classes, objects, attributes, and relationships.
 Helps visualize real-world concepts in an object-oriented manner.
 Forms the foundation for UML class diagrams and OOP design.
Key Elements of Class-Based Modeling
Class
 Acts as a blueprint for creating objects.
 Ensures all objects share a common structure and behavior.
Objects
 Instances of a class with actual values.
 Maintain their own state and behavior.
 Represent real-world entities like Student, Car, or Book.

Attributes
 Define properties or data members of a class.
 Store values with specific data types.
 Help differentiate one object from another.
Operations (Methods)
 Define actions or behaviors of a class.
 Access or modify attribute values.
 Support encapsulation and reusability.
Relationships between classes
In class diagrams, relationships between classes describe how classes are connected or interact
with each other within a system.

 Inheritance (Generalization): Represents an “is-a” relationship where a child class

inherits properties of a parent class.
 Association: Represents a basic connection or interaction between two classes.
 Simple Association: A direct structural link between two peer classes without
ownership.
 Cardinality: Specifies the number of class instances involved in a relationship.

 Aggregation: Represents a weak “part-of” relationship where parts can exist

independently.
 Composition: Represents a strong “part-of” relationship where parts cannot exist without
the whole.

 Dependency: Indicates that one class temporarily depends on another class.

 Realization: Represents a class implementing an interface.
Analysis Classes
 Represent key problem-domain concepts before system design.
 Focus on understanding requirements, not implementation.
 Identify entities, attributes, and relationships in the system.
Characteristics of Analysis Classes
 Focus on requirements and problem understanding.
 Represent abstract entities and relationships.
 Avoid technical and implementation details.
Usage of Analysis Classes
 Used as the first step in system design.
 Improve communication between stakeholders and developers.
 Serve as a base for design and development.
Types of Analysis Classes
Analysis classes are usually categorized into the following

Entity Classes
 Represent real-world business objects.
 Store persistent data and attributes.
 Contain business rules.
Boundary Classes
 Handle interaction between users and the system.
 Manage input and output interfaces.
  Represent screens, forms, or APIs.
Control Classes
 Manage system logic and workflows.
 Coordinate between entity and boundary classes.
 Handle validations and process flow.
Steps in Identifying Analysis Classes
Step 1: Study Requirements- Understand the domain, actors, and scenarios.
Step 2: Extract Nouns and Verbs
• Nouns → possible classes
• Verbs → possible operations/relationships
Step 3: Categorize Classes- Entity, boundary, and control.
Step 4: Eliminate Irrelevant Terms- Remove abstract, vague, or non-technical nouns.
Step 5: Validate with Stakeholders- Ensure completeness and correctness.
Step 6: Define Attributes & Responsibilities- Assign attributes, operations, and constraints.
Step 7: Create Initial Class Diagrams- Represent relationships among identified classes.
INTRODUCTION TO SOFTWARE: MODULE 2

specify attributes and Define operations in Software Engineering

In software engineering, attributes refer to the quality characteristics and data properties of a
system, while operations define the behaviors, functions, and lifecycle processes involved in
developing and managing that software.
 Attributes in Software Engineering
Attributes describe the essential qualities and characteristics of a software product or system.
They can be generally categorized into product attributes (quality) and data attributes
(properties of an object).
1 . Product/Quality Attributes
These attributes, often referred to as non-functional requirements, define "how well" the software
performs its functions.

1. Maintainability: Ease of updating, fixing, or improving the software.

2. Reliability: Ability to work correctly without failures over time.
3. Efficiency/Performance: Uses system resources effectively with fast response.
4. Usability: Easy for users to learn and use.
5. Scalability: Handles growth in users or data without performance loss.
6. Security: Protects data from unauthorized access and attacks.
7. Portability: Works on different systems with minimal changes.
2 . Data Attributes
Attributes are data members that describe an object or entity.
Definition: A property that stores data for an object (e.g., Student has Name, Roll Number, Age).
Types:
1. Simple: Cannot be divided (Roll Number)
2. Composite: Can be divided (Address → Street, City, State)
3. Single-valued: One value only
4. Multi-valued: Multiple values
5. Derived: Calculated from other data (Age from Date of Birth)
 Operations in Software Engineering
Operations in Software Engineering refer to the actions or tasks performed during the software
life cycle.
1. Operations in Programming/Design
Operations (methods/functions) define what an object can do.
Definition: Procedures that manipulate object data or interact with the system.
Examples: Login(), Calculate_Sales_Tax(), Save_Record(), Generate_Report().Operations as
Processes (DevOps/Ops)
2 . In DevOps/Operations:
Operations include deploying, managing, monitoring, and supporting software in a live
(production) [Link] Activities:
 Deployment Automation: Automating the release and installation of software into various
environments.
 Monitoring and Observability: Tracks system health and performance.
 Incident Response: Quickly detects and fixes failures.
 Maintenance: Updates, fixes bugs, and improves the system.
 Backup and Recovery: Protects data and restores systems after failures
In essence, attributes define the qualities and state of the software system, while operations
define the functions and activities that make the system work and keep it running effectively
 MODULE 2

Software Design Process – Software Engineering

The Software Design Phase converts customer requirements from the SRS document into a form
that can be implemented using a programming language. It acts as a blueprint for software
development.
 What is Software Design Process?
The Software Design Process is the phase where developers plan how to build the system by
breaking requirements into smaller parts, designing architecture, and defining component
interactions before coding.

 Levels of Software Design

1. Interface Design
Defines interaction between the system and users, devices, and other [Link] on inputs,
outputs, data formats, and message flow while treating the system as a black box.
2. Architectural Design
Defines the overall structure of the [Link] major components, their responsibilities,
interfaces, and interactions.
3. Detailed Design
Specifies internal details of [Link] algorithms, data structures, module
decomposition, and unit interactions.
 Software Design Phases

1. Understanding Requirements: Analyze user needs and business goals.

2. Research & Planning: Gather user data and plan the design approach.
3. Designing Software: Create wireframes, flow diagrams, and user stories.
4. Technical Design: Prepare detailed technical documentation.
5. UI Design: Design user-friendly interfaces.
6. Prototyping: Build models to test and validate design ideas.

 Elements of Software Design

1. Architecture: Overall system structure.
2. Modules: Small units handling specific tasks.
3. Components: Groups of related modules.
4. Interfaces: Communication boundaries between components.
5. Data: Storage, access, and flow of information.

 Tools for Software Design

Figma, Balsamiq, Axure RP, Sketch, InVision Studio

 Conclusion
Software Design is a crucial stage in SDLC that ensures a well-structured, maintainable, and
efficient software system before development begins.
 MODULE 2

Software Design – Overview

Software design is the process of planning the structure, components, methods, and interactions
of a software system so that it meets user requirements. A well-thought-out design helps identify
issues early and reduces changes after coding begins.
 What is Software Design?
Software design converts user requirements from the SRS (Software Requirement Specification)
into a form suitable for coding and implementation. It bridges the gap between problem
understanding and solution development.
In SDLC, software design is the phase where focus shifts from what the system should do to how
it will do it.
 Objectives of Software Design

1. Correctness: Properly implements all required features

2. Efficiency: Optimizes time, cost, and resources
3. Understandability: Easy to read and manage through modular design
4. Completeness: Covers all components, data, and interfaces
5. Maintainability: Easy to modify and enhance in the future
 Levels of Software Design

1. Architectural Design
Defines the overall structure of the system and identifies major components and their
relationships.
2. High-Level Design
Breaks the system into subsystems and modules and explains their interaction.
3. Detailed Design
Specifies internal logic of each module including algorithms and data structures.
 Software Design Concepts
 Abstraction: Hides complexity and shows only essential features.
 Information Hiding: Restricts access to internal module details.
 Refactoring: Improves code structure without changing functionality.
 Modularity: Divides system into smaller, manageable modules.
 Design Patterns: Reusable solutions to common design problems.
 Architecture: Blueprint of system structure and behavior.
 Refinement: Gradual detailing of the system design.

 Conclusion
Software design transforms requirements into a structured solution for implementation. It plays a
crucial role in SDLC by ensuring correctness, efficiency, maintainability, and clarity before
coding begins.
 MODULE 2

Creating an Architectural Design Software Architecture

Creating the architectural design for a software system is the process of defining its high-
level structure, including components, their relationships, and how they interact to meet
functional and non-functional requirements.

 Steps to Design Software Architecture

1. Analyze Requirements: Identify both functional (what the system does) and non-functional
(performance, security, scalability) requirements.
2. Define System Structure: Break the system down into manageable modules or services
using a "divide and conquer" approach.
3. Choose Architectural Styles/Patterns: Select a proven pattern that fits your needs, such as
Layered, Microservices, or Event-Driven architecture.
4. Establish Component Interfaces: Define how various parts of the system will
communicate, such as through REST APIs, message queues, or direct calls.
5. Visualize and Document: Create diagrams (e.g., using the C4 model or UML) to provide a
clear blueprint for stakeholders and developers.
6. Prototype and Iterate: Build a small-scale version to validate your design decisions early
and refine them based on feedback.

 Common Architectural Patterns

1. Layered (N-Tier): Organizes code into tiers (e.g., Presentation, Business, Data) to separate
concerns.
2. Event-Driven: Uses events to trigger and communicate between decoupled services.
3. Microkernel: Features a core system with minimal functionality and plug-ins for extended
features.
4. Microservices: Structures an application as a collection of small, independently deployable
services.
5. Client-Server: Separates the provider of a resource (server) from the requester (client).

 Essential Tools for Software Architects

 Diagramming: Use Lucidchart, Miro, or [Link] for collaborative visual mapping.

 Modeling: Tools like PlantUML or Microsoft Visio allow for more structured system
modeling.
 Cloud Architecture: Platforms like Cloudcraft help visualize infrastructure on AWS, Azure,
or Google Cloud.
INTRODUCTION TO SOFTWARE:
MODULE 2

Architectural Styles and Patterns in Software Engineering

When designing the fundamental structure of a software system, architects often rely on proven
solutions to recurring problems. These well-established approaches are known as architectural
styles and architectural patterns. They provide a vocabulary and a set of best practices that help create
robust, scalable, and maintainable software.

Think of architectural styles as the overall structural organization of a software system, defining the
types of components and their relationships. Architectural patterns, on the other hand, are reusable
solutions to common problems within a specific architectural style or even across different styles.
Patterns offer a more detailed design solution for particular aspects of the architecture.

Architectural Styles

Architectural styles represent a family of systems conforming to a common set of characteristics. They
define a vocabulary of components and connectors, along with constraints on how they can be
combined. Choosing the right architectural style early on significantly influences the quality attributes of
the software.

1. Monolithic Architecture: In a monolithic architecture, all functionalities of the application are

packaged and deployed as a single unit. All components run in the same process space.
Characteristics:

• Single codebase and deployment unit.

• Easier initial development and deployment for simpler applications.

2. Layered Architecture

Organizes the system into a hierarchy of layers, where each layer performs a specific role and
communicates only with the layers immediately above and below it. Common layers include
presentation, business logic, and data access.

Characteristics:

• Separation of concerns, making it easier to understand and modify layers independently.

• Improved testability.

3. Client-Server Architecture :

Distributes tasks between service providers (servers) and service requesters (clients). Clients initiate
requests, and servers respond with the requested information or service.

Characteristics:

• Centralized resource management.

• Scalability challenges on the server side.

4. Microservices Architecture

Structures an application as a collection of small, independent services, each running in its own process
and communicating through lightweight mechanisms, often HTTP APIs.

Characteristics:

• High scalability and resilience due to the independent nature of services.

• Enables technology diversity for different services.

5. Event-Driven Architecture

Components communicate through asynchronous events. Producers emit events without knowing who
the consumers are, and consumers subscribe to the events they are interested in.

Characteristics:

• Highly scalable and responsive.

• Loose coupling between components.

Architectural Patterns

Architectural patterns provide reusable solutions to common problems within a given context. They
offer a proven template for solving a specific design challenge.

1. Model-View-Controller (MVC): A popular pattern for designing user interfaces, particularly in web
applications. It separates the application into three interconnected parts:

• Model: Manages the application’s data and business logic.

• View: Presents the data to the user.

• Controller: Handles user input and updates the model and/or view.

2. Repository Pattern: Abstracts the data access layer, providing a consistent way to retrieve and persist
data without exposing the underlying data storage mechanism.

3. Service-Oriented Architecture (SOA): While often considered an architectural style, SOA can also be
viewed as a pattern that structures an application as a collection of loosely coupled services that
communicate through well-defined interfaces (often using protocols like SOAP).

4. Observer Pattern: Defines a one-to-many dependency between objects so that when one object (the
subject) changes state, all its dependents (observers) are notified and updated automatically.
 MODULE 2

Golden Rules
Golden Rules of Software Engineering are fundamental principles that guide developers to build
high-quality, reliable, and maintainable software. These rules are often asked in exams and are
useful in real projects too.

1. Understand the Purpose of Your Software

Great developers never consider the purpose of software showing off how clever they are in writing
the code for a project. You will be building a complex system or a bad application if you don't
understand the purpose of the software. A bad application doesn't help people that much.
[Link] The Goals of Software Design
The goal of software design is to make the developer's job as easy as possible. This way, developers
will be able to focus on other important things that matter in an application. Understanding the aim
of your software design will help you to create an application that helps users and it will be
continued for a long time.
3. Understanding Your System and Your Work
Before you start working on a project make sure that you fully understand your system, its
behavior, functionality, features, and tools you're working with. If you don't understand your
system and it's working properly then you will be making your job more difficult and you will be
heading towards building a complex system.
4. Follow Simplicity
Being a developer your aim should be to reduce the complexity of the system not to create it, not
to increase it. If you think that writing complex code makes you a smart and intelligent developer
then you're totally wrong. It's a wrong mindset and you should never do this mistake in software
development. A good developer always keeps the code as simple as possible so that other
developers can understand it and work on it.
5. Controlling The Complexity
In software development, most of the projects get failed due to the complexity of the system. You
start with a simple project but as time goes on you keep adding features to it and after a couple of
months when you look back at your own code you realize that you have written a lot of unnecessary
code and you have built a much more complex system. You realize that you have expanded a few
things in your software for no reason.
6. Maintenance
Most of the time developers do not pay attention to the maintenance of the code. They focus on
quick coding and fast shipping of the product and ignore the importance of code maintenance. No
matter how small or large applications you build, you will always have to implement a few changes
in your application.
7. Be Consistent
The simplicity of your system depends a lot on consistency. Inconsistent code is always hard to
understand and developers need to put more effort into learning and understanding it.
8. Prioritizing
In your programming journey, you will have many options for a certain thing or a specific problem.
There you will have to make a decision about choosing the best option. Now the question is... how
to make a decision about your software? How to prioritize the things and what are some factors
you need to consider making a better decision.
9. Solving Problems
To solve the problem you need to first understand the problem. You should know what exactly is
being asked and make sure that you clear all the confusion. You can follow the Feynman
technique to understand a hard problem. In this technique, you need to explain your problem to
someone else in simple terms.
10. Do Not Chase Too Much Perfection
One of the common mistakes most developers make is that they want to make everything too
perfect in an application. Each and every feature they want to build with perfection and because
of this, they tend to plan everything in detail from the beginning. Most of the time their focus gets
shifted to making things perfect only instead of solving the problem and helping people with their
software.
11. Predictions
Thinking from the future perspective we write a lot of unnecessary code and we become too
generic in our application which is not good. In software development, you can't predict the future,
so no matter how generic your solution is, you won't be able to fulfill the actual future
requirements.
12. Don’t Reinvent The Wheel.
Do not implement something, if it already exists.
A lot of developers spend their time building or creating something which already exists on the
portal. This is one of the common mistakes and it just consumes the developer's valuable time.
Instead of reinventing the wheel, they can spend their time on something else which is more
important.
13. Resistance
Say no to changing requests until or unless it's not important. You will be making mistake if you
will say 'yes' to each and every request and if you will start working on each one of them.
14. Automate the Repetitive Tasks
One of the most frustrating things in software development is working on some repetitive tasks.
The repetitive task just consumes your additional time and it's a foolish thing to work on it again
and again. When you realize that you are doing something, again and again, set them up, automate
it and forget about them. If you can automate something and if it's saving your valuable time then
automate it.
15. Productivity
Your goal shouldn't be writing more code and increasing complexity. You should think about
removing unnecessary code and making things as simple as possible. This golden rule is not just
going to increase your productivity, but also it will increase the productivity of other developers.
 MODULE 2

User interface analysis and design

User Interface Design
The user interface is the front-end application view to which the user interacts to use the software.
The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens

Types of User Interface

1. Command Line Interface: The Command Line Interface provides a command prompt,
where the user types the command and feeds it to the system. The user needs to remember
the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive interface
to interact with the system. GUI can be a combination of both hardware and software.
Using GUI, the user interprets the software.
User Interface Design Process
The analysis and design process of a user interface is iterative and can be represented by a spiral
model. The analysis and design process of user interface consists of four framework activities.

1. User, Task, Environmental Analysis, and Modeling

Initially, the focus is based on the profile of users who will interact with the system, i.e.,
understanding, skill and knowledge, type of user, etc., based on the user's profile users are made
into categories. From each category requirements are gathered. Based on the requirement's
developer understand how to develop the interface.
2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control mechanisms
that enable the user to perform desired tasks. Indicate how these control mechanisms affect the
system. Specify the action sequence of tasks and subtasks, also called a user scenario. Indicate the
state of the system when the user performs a particular task. Always follow the three golden rules
stated by Theo Mandel. Design issues such as response time, command and action structure, error
handling, and help facilities are considered as the design model is refined. This phase serves as the
foundation for the implementation phase.
3. Interface Construction and Implementation
The implementation activity begins with the creation of a prototype (model) that enables usage
scenarios to be evaluated. As iterative design process continues a User Interface toolkit that allows
the creation of windows, menus, device interaction, error messages, commands, and many other
elements of an interactive environment can be used for completing the construction of an interface.
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that it should be
able to perform tasks correctly, and it should be able to handle a variety of tasks. It should achieve
all the user's requirements. It should be easy to use and easy to learn. Users should accept the
interface as a useful one in their work.

User Interface Design Golden Rules

The following are the golden rules stated by Theo Mandel that must be followed during the design
of the interface. Place the user in control:
1. Define the interaction modes in such a way that does not force the user into unnecessary or
undesired actions: The user should be able to easily enter and exit the mode with little or
no effort.
2. Provide for flexible interaction: Different people will use different interaction mechanisms,
some might use keyboard commands, some might use mouse, some might use touch screen,
etc., Hence all interaction mechanisms should be provided.
3. Allow user interaction to be interruptible and undoable: When a user is doing a sequence
of actions the user must be able to interrupt the sequence to do some other work without
losing the work that had been done. The user should also be able to do undo operation.
4. Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to customize the
interface as user wants which allows different interaction mechanisms so that user doesn't
feel bored while using the same interaction mechanism.
 MODULE 2

A strategic approach to software testing

Software Testing
Software testing is the process of evaluating software to detect defects and verify whether it
meets specified requirements. The main goal is to improve software quality and reliability.

Common Software Testing Strategies

• Black Box Testing: Tests software functionality without knowing internal code.
• White Box Testing: Tests internal code structure and logic.
• Unit Testing: Tests individual components or units.
• Integration Testing: Tests interaction between integrated modules.
• Functional Testing: Verifies functional requirements.
• System Testing: Tests the complete integrated system.
• Acceptance Testing: Ensures software meets user or customer expectations.
 • Regression Testing: Ensures changes do not introduce new defects.
• Performance Testing: Evaluates speed, scalability, and stability.
• Security Testing: Identifies vulnerabilities and security risks.

Objectives of Software Testing

• Testing is the process of finding errors and verifying requirements.

• A good test case is one that finds undiscovered defects.
• A high number of detected errors indicates effective testing.

Software Testing Strategy – Key Points

• Clearly define software requirements and quality attributes such as maintainability,
usability, and risk.
• Specify testing objectives like effectiveness, failure detection, and defect cost.
• Identify user categories and develop use cases for realistic testing.
• Prepare a test plan to support rapid cycle testing.
• Design robust software that supports automated and regression testing.
• Conduct formal technical reviews before testing to reduce errors.
• Evaluate the quality of test strategy and test cases through reviews.
• Apply continuous testing and quality control during development.
Advantages of Software Testing
• Improves software quality and reliability
• Enhances user experience
• Increases confidence in the software
• Simplifies maintenance
• Reduces overall development cost
Disadvantages of Software Testing
• Time-consuming process
• Requires skilled resources
• Limited test coverage
• Unpredictable defect behavior
• May delay software delivery
 MODULE 2

Unit Testing - Software Testing

Unit testing is the process of testing the smallest parts of your code, like it is a method in
which we verify the code's correctness by running one by one. It's a key part of software
development that improves code quality by testing each unit in isolation.
You write unit tests for these code units and run them automatically every time you make
changes. If a test fails, it helps you quickly find and fix the issue. Unit testing promotes
modular code, ensures better test coverage, and saves time by allowing developers to focus
more on coding than manual testing.
What is a Unit Test?

A unit test is a small piece of code that checks if a specific function or method in is an
application works correctly. It will work as the function inputs and verifying the outputs.
These tests check that the code work as expected based on the logic the developer intended.

In these multiple tests are written for a single function to cover different possible scenarios
and these are called test cases. While it is ideal to cover all expected behaviours, it is not
always necessary to test every scenario. Unit tests should run one by one, it means that they
do not depend on other system parts like databases or networks. Instead, data stubs can be
used to simulate these dependencies. Writing unit tests is easiest for simple, self-contained
code blocks.
Unit testing strategies
To create effective unit tests, follow these basic techniques to ensure all scenarios are
covered:
 Logic checks: Verify if the system performs correct calculations and follows the expected
path with valid inputs. Check all possible paths through the code are tested.
 Boundary checks: Test how the system handles typical, edge case, and invalid inputs.
For example, if an integer between 3 and 7 is expected, check how the system reacts to a
5 (normal), a 3 (edge case), and a 9 (invalid input).
 Error handling: Check the system properly handles errors. Does it prompt for a new
input, or does it crash when something goes wrong?

Integration Testing - Software Engineering

Integration Testing is a Software Testing Technique that focuses on verifying the interactions
and data exchange between different components or modules of a Software Application. The
goal of Integration Testing is to identify any problems or bugs that arise when different
components are combined and interact with each other.
 It mainly tests interface between two software units or modules. It focuses on
determining the correctness of the interface. Once all the modules have been unit-tested,
integration testing is performed.

Integration Testing is important because it ensures that individual modules work together
correctly, detects interface or communication issues early, and improves the overall reliability,
performance, and quality of the software.

Types of Integration Testing

There are four main strategies for executing integration testing: big-bang, top-down, bottom-
up, and sandwich (or hybrid) testing. Each of these methods comes with its own set of
advantages and challenges, so it's important to choose the right one based on the specific
needs of your project. Those approaches are the following:
 MODULE 2

Validation testing

The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product actually meets the client's needs. It can also be
defined as to demonstrate that the product fulfils its intended use when deployed on appropriate
environment.

Activities:

 Unit Testing
 Integration Testing
 System Testing
 User Acceptance Testing
Purpose

 Ensure software satisfies the specified requirements

 Confirm the product works as intended for the end-user
 Improve customer satisfaction

Types of Validation Testing

There are various types of validation testing that software teams can perform throughout the
development process to ensure the software meets user needs:

1. Functional Testing: Ensures the software's features work according to the specified
requirements. It involves testing individual functionalities of the application to ensure
the software behaves as expected.
2. Non-Functional Testing: Assesses aspects like performance, security, and usability
to ensure the software can handle real-world conditions. Accessibility testing, for
example, ensures the product is accessible to all users, including those with
disabilities.
3. User Acceptance Testing (UAT): In this phase, real users test the software to verify
that it meets their needs and expectations before release.
4. System Testing: Involves evaluating the software as a whole to ensure all
components work together correctly. This includes end-to-end testing of the entire
system.
5. Regression Testing: Ensures that new updates or changes to the software don’t
negatively impact existing functionality. Validation can help confirm that the software
update doesn't introduce new bugs.
6. Beta Testing: Performed in a real-world environment by end users, beta testing helps
identify any issues that may have been overlooked during earlier testing phases.

Validation Testing Techniques

Various testing techniques can be applied to validation testing in software development.

These include:

 Black Box Testing: Focuses on testing the software without looking at the underlying
code. The tester inputs data and examines the outputs, verifying whether the software
behaves as expected.
 White Box Testing: Involves testing the internal structures of the application, with a
focus on understanding the code and how it functions.
 Test Automation: Tools can be employed to automate repetitive tasks in validation
testing, ensuring consistency and efficiency. Automation testing is particularly useful
for running large sets of test cases during regression

Example of Validation Testing

Let’s consider an e-commerce website that allows users to purchase products

online. Validation testing would involve checking whether the checkout process works
smoothly, whether payment methods are functioning, and whether the final product meets the
user’s needs. This might include UAT, where real customers simulate purchases to verify the
system is user-friendly and performs as expected.
 MODULE 2

System testing
System Testing is a type of software testing that is performed on a completely integrated
system to evaluate the compliance of the system with the corresponding requirements. In
system testing, integration testing passed components are taken as input.
 The goal of integration testing is to detect any irregularity between the units that are
integrated. System testing detects defects within both the integrated units and the whole
system. The result of system testing is the observed behaviour of a component or a system
when it is tested.
 System Testing is carried out on the whole system in the context of either system
requirement specifications or functional requirement specifications or the context of both.
System testing tests the design and behaviour of the system and also the expectations of
the customer.
 It is performed to test the system beyond the bounds mentioned in the software
requirements specification (SRS). System Testing is performed by a testing team that is
independent of the development team and helps to test the quality of the system impartial.
 It has both functional and non-functional testing. System Testing is performed after the
integration testing and before the acceptance testing.

System Testing Process

 Test Environment Setup: Create testing environment for the better quality testing.
 Create Test Case: Generate test case for the testing process.
 Create Test Data: Generate the data that is to be tested.
 Execute Test Case: After the generation of the test case and the test data, test cases are
executed.
 Defect Reporting: Defects in the system are detected.
 Regression Testing: It is carried out to test the side effects of the testing process.
 Log Defects: Defects are fixed in this step.
 Retest: If the test is not successful then again test is performed.

Types of testing

 Functional Testing: This checks if the system’s features work as expected and meet the
defined requirements.
 Performance Testing: This tests how the system performs under different conditions,
like high traffic or heavy use, to ensure it can handle the expected load.
 Security Testing: This ensures the system’s security measures protect sensitive data from
unauthorized access or attacks.
 Compatibility Testing: This makes sure the system works well across different
hardware, software, and network environments.
 Usability Testing: This evaluates how easy and user-friendly the system is, making sure
it provides a good experience for users.
 MODULE 2

Black-Box testing
Black-box testing is a Type of Software Testing in which the tester is not concerned with the
software’s internal knowledge or implementation details but rather focuses on validating
the functionality based on the provided specifications or requirements.

Types Of Black Box Testing

The testing of application without knowing the internal code or structure, following are the
various Types of Black Box Testing:
1. Functional Testing

Functional Testing is a type of Software Testing in which the system is tested against the
functional requirements and specifications. Functional testing ensures that the requirements
or specifications are properly satisfied by the application.

 This testing is not concerned with the source code of the application. Each functionality
of the software application is tested by providing appropriate test input, expecting the
output, and comparing the actual output with the expected output.
 This testing focuses on checking the user interface, APIs, database, security, client or
server application, and functionality of the Application Under Test. Functional testing
can be manual or automated. It determines the system’s software functional requirements.
2. Regression Testing

Regression Testing is like a Software Quality check-up after any changes are made. It
involves running tests to make sure that everything still works as it should, even after updates
or tweaks to the code. This ensures that the software remains reliable and functions properly,
maintaining its integrity throughout its development lifecycle.

 Regression means the return of something and in the software field, it refers to the return
of a bug. It ensures that the newly added code is compatible with the existing code.
 In other words, a new software update has no impact on the functionality of the software.
This is carried out after a system maintenance operation and upgrades.
3. Non-functional Testing

Non-functional Testing is a type of Software Testing that is performed to verify the non-
functional requirements of the application. It verifies whether the behaviour of the system is
as per the requirement or not. It tests all the aspects that are not tested in functional testing.

 It is designed to test the readiness of a system as per non-functional parameters which are
never addressed by functional testing.
 It is as important as functional testing.
 It is also known as NFT. This testing is not functional testing of software. It focuses on
the software’s performance, usability, and scalability.
Advantages of Black Box Testing

 The tester does not need to have more functional knowledge or programming skills to
implement the Black Box Testing.
 It is efficient for implementing the tests in the larger system.
Disadvantages of Black Box Testing

 There is a possibility of repeating the same tests while implementing the testing
process.
 Without clear functional specifications, test cases are difficult to implement.
 MODULE - 2

White box Testing:

White box testing is a Software Testing Technique that involves testing the internal structure and
workings of a Software Application.
 The tester has access to the source code and uses this knowledge to design test cases that can verify
the correctness of the software at the code level.
 White box testing is also known as Structural Testing or Code-based Testing, and it is used to test the
software’s internal logic, flow, and structure.
 The tester creates test cases to examine the code paths and logic flows to ensure they meet the
specified requirements.

Types of White Box Testing

White box testing can be done for different purposes at different places. There are three main types of
White Box testing which is follows:-
Path Testing: White box testing will be checks all possible execution paths in the program to surabout
the each one of the function behaves as expected.
Loop testing: It will be check that loops (for or while loops) in the program operate correctly and
efficiently
Unit Testing: Unit Testing checks if each part or function of the application works correctly. It will
check the application meets design requirements during development.
Mutation Testing: It is a type of Software Testing that is performed to design new software tests and
also evaluate the quality of already existing software tests.
Integration Testing: Integration Testing Examines how different parts of the application work
together. After unit testing to make sure components work well both alone and together.
Penetration testing: Penetration testing, or pen testing, is like a practice cyber attack conducted on
your computer systems to find and fix any weak spots before real attackers can exploit them.
Process of White Box Testing
White box testing include verify the internal workings of a software application. It checks that every
aspect of the code is tested, basically is focusing on the logic, structure, and flow of the software.
Here’s a breakdown of how this process works:

Input: Gathering Essential Documents

The process begins by collecting key documents to understand the application:
 Requirements: These outline what the application is supposed to do and its expected behaviour.
 Functional Specifications: These describe how the software should perform under specific
conditions.
Processing: Planning and Prioritizing
With inputs gathered, testers prepare for thorough testing:
 Risk Analysis: This step identifies potential risks in the code. By analyzing the application’s
functionality and dependencies, testers can identify areas where errors are more likely to occur and
prioritize testing those areas.
Test Execution: Running and Refining
Tests are executed to validate the code’s behaviour:
 Execute the Tests: The test cases are run to check the behaviour of the application. During execution,
the application’s internal logic is verified during the same. This includes testing individual functions,
loops, and conditions to check that they work as expected.

Output: Delivering Results

The process concludes with a comprehensive summary:
 Final Report: A detailed report is prepared that includes all findings, test case results, error logs, and
improvements made in the proper format which is easily understandable. This report documented as a
record of the testing process and provides a complete overview of the software’s quality. It is typically
shared with the development team and other related stakeholders and members.

Conclusion
White box testing checks the internal code and logic of software to re-sure it to works properly and is
optimized. It includes unit testing, integration testing, and regression testing, using methods like statement
and branch coverage. While it helps catch defects early and improve performance, it requires knowledge
of programming to understand issues related to the software's external behaviour.
 MODULE -2

ART_OF_DEBUGGING:
Debugging in Software Engineering is the process of identifying and resolving errors or bugs in a
software system. It's a critical aspect of software development, ensuring quality, performance, and user
satisfaction. Despite being time-consuming, effective debugging is essential for reliable and competitive
software products.
Here are we discussing the points related to Debugging in detail:
What is Debugging?
In the context of software engineering, debugging is the process of fixing a bug in the software. When
there's a problem with software, programmers analyze the code to figure out why things aren't working
correctly. They use different debugging tools to carefully go through the code, step by step, find the issue,
and make the necessary corrections.

Process of Debugging
Debugging is a crucial skill in programming. Here’s a simple, step-by-step explanation to help you
understand and execute the debugging process effectively:
Step 1: Reproduce the Bug
 To start, you need to recreate the conditions that caused the bug. This means making the error
happen again so you can see it firsthand.
 Seeing the bug in action helps you understand the problem better and gather important details for
fixing it.
Step 2: Locate the Bug
 Next, find where the bug is in your code. This involves looking closely at your code and checking
any error messages or logs.
 Developers often use debugging tools to help with this step.
Step 3: Identify the Root Cause
 Now, figure out why the bug happened. Examine the logic and flow of your code and see how
different parts interact under the conditions that caused the bug.
 This helps you understand what went wrong.
Step 4: Fix the Bug
 Once you know the cause, fix the code. This involves making changes and then testing the program to
ensure the bug is gone.
 Sometimes, you might need to try several times, as initial fixes might not work or could create new
issues.
 Using a version control system helps track changes and undo any that don't solve the problem.
Step 5: Test the Fix
After fixing the bug, run tests to ensure everything works correctly. These tests include:
 Unit Tests: Check the specific part of the code that was changed.
 Integration Tests: Verify the entire module where the bug was found.
 System Tests: Test the whole system to ensure overall functionality.
 Regression Tests: Make sure the fix didn’t cause any new problems elsewhere in the application.
Step 6: Document the Process
 Finally, record what you did. Write down what caused the bug, how you fixed it, and any other
important details.
 This documentation is helpful if similar issues occur in the future.

Advantage of Debugging:
Improved system quality: By identifying and resolving bugs, a software system can be made more
reliable and efficient, resulting in improved overall quality.
Reduced system downtime: By identifying and resolving bugs, a software system can be made more
stable and less likely to experience downtime, which can result in improved availability for users.

Disadvantages of Debugging:
Time-consuming: Debugging can be a time-consuming process, especially if the bug is difficult to find or
reproduce. This can cause delays in the development process and add to the overall cost of the project.
Can be difficult to reproduce: Some bugs may be difficult to reproduce, which can make it challenging
to identify and resolve them.

Conclusion
In conclusion, debugging is an important part of software engineering, focused on finding and fixing
bugs in software systems. It helps improve system quality, reduce downtime, increase user satisfaction,
lower development costs, enhance security, and support system changes and testing.
 MODULE-2

Introduction to Metrics for Analysis Model

During the early stages of software development, particularly within the analysis phase, it is crucial to
measure and assess the quality and complexity of the requirements and initial system
understanding. Metrics for the analysis model are quantitative measures applied at this foundational
stage. These metrics serve as early indicators of project size, effort, and potential challenges. By
gathering these insights, teams can make informed decisions, identify ambiguities, and address
complexities before they become more expensive to resolve in later phases of the software development
lifecycle.

Importance of Analysis Model Metrics: Applying metrics at the analysis model stage offers several
significant benefits:

 Early Estimation: Provides a basis for estimating project size, cost, and effort, even before
design or coding begins.
 Risk Identification: Helps in identifying potential risks associated with unclear or complex
requirements.
 Improved Planning: Facilitates better project planning and resource allocation.
 Enhanced Communication: Offers a common, quantitative language for discussing
requirements and their implications among stakeholders.
 Quality Assessment: Assesses the quality and completeness of the requirements document itself.
Key Metrics for the Analysis Model
Various metrics can be employed to evaluate the analysis model, each providing unique insights into the
software system’s characteristics and the quality of its requirements.

Function Point (FP) Metric

The Function Point (FP) metric is a widely recognized and commonly used metric in the analysis
model. It quantifies the functionality delivered by a software system from the user’s perspective, without
considering the programming language or internal technical design. The core idea is t o measure the
amount of business functionality an information system provides.

How Function Points are Derived:

Function points are calculated by identifying and counting five major components of the software’s
information domain, then adjusting for general system characteristics:

1. External Inputs (EIs): Data or control information that enters the system from outside sources.
2. External Outputs (EOs): Data or control information that leaves the system and goes to external
destinations.
3. External Inquiries (EQs): Inputs that result in an immediate output, typically a query to retrieve
data.
4. Internal Logical Files (ILFs): User-identifiable logical files within the system’s boundary.
5. External Interface Files (EIFs): User-identifiable logical files external to the system but
referenced by it.
Each of these components is then weighted based on its complexity (simple, average, or complex). The
unadjusted function point count is further refined by considering 14 “Value Adjustment Factors” (VAFs)
that account for various processing complexity characteristics, resulting in the final adjusted Function
Point count.

Advantages of Function Point Analysis:

 Language Independent: Measures functionality regardless of the technology used for
implementation.
 Early Estimation: Can be applied early in the software lifecycle, directly from the requirements
specification.
Disadvantages of Function Point Analysis:
 Subjectivity: The weighting of components and adjustment factors can sometimes be subjective,
depending on the interpreter.
 Requires Training: Proper application requires knowledge and experience in Function Point
counting rules.
Data Structure Metrics
Data structure metrics are used to assess the complexity, clarity, and relationships of data elements
within the proposed system’s data model or schema. In the analysis phase, this might involve evaluating
entity-relationship diagrams or data dictionaries. These metrics can help ensure that the data model is
well-organized, consistent, and robust, which is foundational for reliable software. For instance,
analyzing the number of relationships between entities or the depth of data hierarchies can provide
insights into potential complexities.

Conclusion
Metrics for the analysis model, particularly Function Point analysis, are indispensable tools for managing
software development effectively from its earliest stages. They provide quantitative insights into the
software’s functional size and the characteristics of its requirements, enabling better estimation,
planning, and risk management. By focusing on these early metrics, development teams can build a solid
foundation, leading to more predictable and successful software projects.
 MODULE-2

Metrics for design model:

Metrics measures quantitative assessment that focuses on countable values most commonly used for
comparing and tracking the performance of a system. Metrics are used in different scenarios like
analyzing models, designing models, source code, testing, and maintenance. This article focuses on
discussing metrics for the design model of the product.
What are Metrics?
Metrics for the design model of the product focus on evaluating various aspects of the design process and
the resulting model.
1. These are essential for evaluating the design model's quality, efficiency, maintainability, and overall
effectiveness.
2. Metrics for design modeling allow developers or software engineers to evaluate or estimate the design
quality and include various architecture and component-level designs.

Quality Metrics
Quality metrics for the design model focus on evaluating aspects that contribute to the overall quality,
maintainability, and effectiveness of the design. They help to ensure that the design meets requirements,
easy to understand, and is maintainable. Here are some commonly used quality metrics:
1. Modularity: This measures how well the design can be divided into cohesive and loosely coupled
modules,
2. Complexity: Evaluate the complexity of the design model using metrics like cyclomatic complexity or
the number of classes/ interfaces per package/ module.
3. Abstraction: Assess the level of abstraction in the design, indicating how well the design captures the
essential aspects while hiding the unnecessary details.
4. Coupling: Measures the degree of interdependence between the modules.
5. Cohesion: This evaluates how well elements within a module belong together. High cohesion means
that the elements within the module are closely related.

Performance Metrics
Performance metrics focus on evaluating how well the design supports the expected performance
characteristics of the software system. These help in assessing the efficiency, scalability, responsiveness,
and resource utilization of the design. Here are some commonly used performance metrics:
1. Scalability: It measures how well the design model accommodates the increase in workload. This
includes evaluating the ability to handle large datasets, higher user loads, or increased complexity
without significant degradation in performance.
2. Response Time: The time taken by the design model to respond to a user request. This metric is
important for assessing the responsiveness of the product.
3. Throughput: Measure of the rate at which the design model can process tasks within a given time
frame. This metric is important for systems handling large volumes of transactions.
4. Resource Utilization: Evaluation of the resources such as CPU, memory, and network bandwidth
consumed by the design model during the operation. Efficient resource utilization ensures optimal
performance.
5. Latency: The time taken for a request to travel from the source to the destination and back. Low
latency is critical for real-time applications where timely responses are important.
Usability Metrics
Usability metrics for the design model of the product focus on evaluating how user-friendly and effective
is the design in meeting user expectations. It helps to ensure that the design model supports efficient
navigation and overall user satisfaction. Here are some key usability metrics for the design model of the
product:
1. Efficiency: Evaluates how quickly a user can complete the tasks once they are familiar with the design
model. This includes metrics like task completion time and number of steps required to complete
common actions.
2. Effectiveness: Evaluate the accuracy with which the users can achieve their goals using the design
model. It includes metrics like error rates and task success rates.
3. Learnability: This measures how easy it is for first-time users to understand and navigate the design
model. This can be assessed through the time taken to complete basic tasks and ease of understanding
navigation pathways.

Reliability Metrics
Reliability metrics of the design model assess the ability to consistently perform as expected under various
conditions over time. These metrics help stakeholders assess the robustness and dependability of the
design model. Here are some common reliability metrics:
1. Fault Tolerance: Measures the design model's ability to continue operating properly in the presence
of faults and failures. This includes assessing how well the design model handles unexpected inputs,
errors in data, or component failures.
2. Failure Rate: Measures the frequency of failures encountered during operation. This involves
evaluating the number of failures per unit of time.
3. Mean Time Between Failure (MTBF): Calculates the average time interval between consecutive
failures of the design model. A higher MTBF indicates better reliability.

Cost Metrics
Cost metrics for the design model of the product are important for evaluating the financial implications
associated with developing and maintaining the product. This helps stakeholders understand and manage
costs effectively throughout the product lifecycle. Here are key cost metrics relevant to the design model:
1. Development Cost: Measures the total expenses incurred during the design phase. This includes
salaries of designers, software tools and licenses, and other development expenses.
2. Equipment Costs: This includes the costs associated with specialized tools, equipment, and software
used in the design process.
3. Testing Costs: Measures the expenses related to building prototypes, conducting testing, and
validating the design model. This includes material costs and labor costs for testing.

Conclusion
In conclusion, the metrics for the design model of the product are essential for guiding development
towards our goals. Tracking factors such as usability, scalability, and maintainability helps to ensure that
the design meets the customer's requirements. These metrics serve as a benchmark for success and enable
us to innovate effectively and deliver a product that stands out in both performance and user satisfaction.
 MODULE 2

Metrics for Source Code

Metrics for source code are quantitative measures used to assess the quality, complexity, size,
and maintainability of software programs. These metrics help software engineers understand
how good or bad the code is and identify modules that may cause problems in future. Source
code metrics are mainly applied during the coding, testing, and maintenance phases of the
Software Development Life Cycle (SDLC).
Types of Metrics
In Software Engineering, metrics are quantitative measures used to assess, control, and improve
the software product, development process, and project management. Metrics provide
numerical data that helps developers and managers make accurate decisions, monitor progress,
and improve software quality.
They are three types:

1. Product Metrics: Product metrics are used to evaluate the state of the product, tracing
risks and undercover prospective problem areas. The ability of the team to control quality
is evaluated. Examples include lines of code, cyclomatic complexity, code coverage,
defect density, and code maintainability index.

What they measure:

 Size of the software

 Complexity of code
 Quality and reliability

Examples:

 Lines of Code (LOC)

  Cyclomatic Complexity

2. Process Metrics: The team or organization. These metrics are used to optimize the
development process and maintenance activities of software. Examples include effort
variance, schedule variance, defect injection rate, and lead time.

What they measure:

 Quality of SDLC phases

 Defect detection capability
 Productivity of the team

Examples:

 Defect Removal Efficiency (DRE)

 Defects found per phase

3. Project Metrics: The project metrics describes the characteristic and execution of a
project. Examples include effort estimation accuracy, schedule deviation, cost variance,
and productivity.

What they measure:

 Project progress
 Cost and schedule status
 Resource utilization

Examples:

 Productivity
 Risk Exposure

Usually measures-

 Number of software developer

 Staffing patterns over the life cycle of software
 Cost and schedule
 Productivity

Advantages of Software Metrics:

1. Reduction in cost or budget.

2. It helps to identify the particular area for improvising.

Disadvantages of Software Metrics:

1. It is expensive and difficult to implement the metrics in some cases.

2. Measuring the incorrect data leads to make wrong decision making.
 MODULE 2

Introduction to Metrics for Testing

During the software development lifecycle, particularly in the quality assurance phase, it
is vital to assess how effectively testing activities are uncovering and preventing
defects. Metrics for testing are quantitative measures used to evaluate the efficiency and
effectiveness of the software testing process itself, as well as the quality of the software
from a testing perspective. These metrics provide objective data that helps teams
understand the progress of testing, the thoroughness of test coverage, and the overall
reliability of the software before its release. Ultimately, leveraging testing metrics enables
data-driven decisions to optimize the testing process and enhance product quality.

Importance of Testing Metrics

Applying metrics to the testing phase offers several significant benefits:

 Process Improvement: Provides insights into the effectiveness of current testing

strategies and methodologies, facilitating continuous improvement.
 Quality Indicators: Offers concrete data about the quality status of the software
under test, helping to gauge readiness for release.
 Resource Management: Aids in better allocation of testing resources and effort
by highlighting areas requiring more attention.
 Risk Management: Helps in identifying high-risk areas in the software based on
defect trends and test coverage.
 Decision Support: Provides objective data for management decisions regarding
release schedules, retesting, and bug prioritization.

Key Metrics for Testing

Various types of metrics are used to evaluate the testing process and its outcomes. Each
metric offers a unique perspective on the efficiency and effectiveness of the quality
assurance efforts.

1. Defect Density: Defect density is a crucial metric for testing that measures the number
of defects found per unit of code. It is commonly expressed as defects per thousand lines
of code (KLOC) or defects per function point. A lower defect density generally indicates
higher software quality and more effective development and testing processes. This metric
helps in identifying modules or components that are particularly prone to bugs, allowing
teams to focus retesting or refactoring efforts. Furthermore, it serves as an important
indicator for gauging the cleanliness of the codebase.
2. Defect Removal Efficiency (DRE): It is a powerful metric for assessing the
effectiveness of the defect detection process. It calculates the percentage of defects found
before software release compared to the total number of defects found (both before and
after release). The formula for DRE is:

Number of Defects Found Before Release

𝐷𝑅𝐸 = × 100%
(Number of Defects Found Before Release + Number of Defects Found After Release)

Higher DRE indicates a more efficient testing process that successfully identifies and
removes a large proportion of defects before the software reaches end -users. This metric
is a direct measure of effectiveness.

Testing metrics are used to measure how well software testing is done. They help us understand
the quality of the software and the effectiveness of testing. Test coverage tells us how much of
the program code is tested. Higher coverage means better testing and fewer chances of hidden
defects. The number of bugs found shows how many errors are detected during testing. By
studying bug severity, priority, and trends, we can understand software stability. The test case
execution rate shows how many test cases are executed in a given time. It helps measure testing
speed and efficiency. The retest pass rate shows how many failed test cases pass after bugs are
fixed. A high pass rate means bug fixes are effective.

Overall, testing metrics help teams track progress, improve quality, and deliver reliable
software.
 MODULE 2

Introduction to Metrics for Maintenance

After software deployment, the product enters its maintenance phase, which can extend
for many years. Metrics for maintenance are crucial quantitative measures used to evaluate
the effort, cost, and overall effectiveness of maintaining the software. These metrics
provide vital insights into the long-term viability and cost of ownership of the software
product. By tracking how effectively defects are resolved, how efficiently changes are
implemented, and the resources consumed, organizations can optimize their maintenance
strategies, improve software longevity, and ensure continued user satisfaction.

Importance of Maintenance Metrics

Applying metrics specifically to the maintenance phase offers several significant benefits:
 Cost Management: Provides data on the actual cost of supporting and evolving
the software, aiding in budgeting and resource allocation.
 Predictability: Helps in forecasting future maintenance efforts and identifying
trends in software stability.
 Process Improvement: Reveals inefficiencies in defect resolution or change
implementation processes, leading to improvements.
 Software Health Assessment: Offers insights into the underlying quality of the
software as it ages and undergoes modifications.

Key Metrics for Maintenance

Various types of metrics are used to evaluate the different aspects of software
maintenance, from bug fixes to enhancements and adaptations.

Mean Time to Change: It measures the average time taken to implement a change request
from its initiation to its successful deployment. A change request could be a bug fix, an
enhancement, or an adaptation to a new environment. A shorter MTTC generally indicates
better maintainability and a more efficient maintenance process. This metric helps teams
understand their agility in responding to evolving needs and issues.

Number of Change Requests: It is a straightforward count of all modification requests

received from users or stakeholders for a software product post-deployment. These
requests can include bug reports, requests for new features, or adaptations to new operating
environments. A high number of CRs might indicate:

 Underlying instability in the software.

 Evolving or poorly defined initial requirements.
Analysing CRs by type (e.g., corrective, adaptive, perfective) provides deeper insights into
the nature of maintenance work.

Cost of Maintenance: quantifies the financial resources spent on all maintenance

activities over a defined period (e.g., a quarter or a year). This includes labour costs, tool
costs, infrastructure, and any other expenses related to keeping the software operational
and up-to-date. Understanding this cost is critical for budgeting, assessing the total cost of
ownership (TCO), and making informed decisions about whether to invest further in
existing software or replace it. This metric is a key indicator of long-term software
expense.

Number of Production Defects: It refers to bugs reported by actual end-users or detected

in the live production environment after the software has been released. This metric is
extremely important because it directly reflects the quality of the software as experienced
by the users and the effectiveness of the pre-release quality assurance processes. A high
number of production defects suggests that the quality assurance process was not fully
effective before release, potentially leading to user dissatisfaction and increased
emergency maintenance efforts.

Maintainability Index: It is a composite metric that provides a single value indicating

how easy it is to maintain the software. It is often calculated from other code metrics, such
as cyclomatic complexity, lines of code, and lines of comments. A higher Maintainability
Index suggests better maintainability, meaning the code is easier to understand, test, and
modify. This metric is a valuable indicator for long-term code health and future
development efforts. It serves as a strong predictor of potential future maintenance
burdens.

Defect Fix Rate: It measures the speed and efficiency with which reported defects are
resolved and closed. It can be expressed as the number of defects fixed per unit of time
(e.g., per day or week) or the average time taken to fix a defect. A higher defect fix rate
reflects the responsiveness and efficiency of the maintenance team in addressing issues,
directly impacting user satisfaction and system reliability. It helps in assessing the capacity
of the team to handle incoming bug reports.
 MODULE 2

Introduction to Software Risks

In software engineering, a risk is a potential problem that may occur in the future and cause
loss or damage to a software project. Software risks arise due to uncertainty in requirements,
technology, resources, schedule, cost, or management decisions. Risk does not mean a problem
has already occurred; it indicates the possibility of a negative outcome. If risks are not identified
and managed properly, they may lead to project failure, cost overrun, schedule delay, or poor
software quality. Software risk management helps software engineers anticipate potential
problems and take preventive actions to minimize their impact. Therefore, understanding
software risks is essential for successful project execution.

Characteristics of Software Risks

Software risks have the following important characteristics:

 Risks are future events

 Risks involve uncertainty
 Risks may cause loss or damage
 Risks can be identified, analyzed, and controlled

Various Kinds of Risks in Software Development

1. Schedule Risk: Schedule related risks refers to time related risks or project delivery
related planning risks. The wrong schedule affects the project development and delivery.
These risks are mainly indicates to running behind time as a result project development
doesn't progress timely and it directly impacts to delivery of project. Finally if schedule
 risks are not managed properly it gives rise to project failure and at last it affect to
organization/company economy very badly. Some reasons for Schedule risks –

 Time is not estimated perfectly

 Improper resource allocation
 Frequent project scope expansion

2. Budget Risk: Budget related risks refers to the monetary risks mainly it occurs due to
budget overruns. Always the financial aspect for the project should be managed as per
decided but if financial aspect of project mismanaged then there budget concerns will
arise by giving rise to budget risks. So proper finance distribution and management are
required for the success of project otherwise it may lead to project failure. Some reasons
for Budget risks –

 Wrong/Improper budget estimation

 Unexpected Project Scope expansion
 Mismanagement in budget handling

3. Operational Risks: Operational risk refers to the procedural risks means these are the
risks which happen in day-to-day operational activities during project development due
to improper process implementation or some external operational risks. Some reasons for
Operational risks –

 Insufficient resources
 Conflict between tasks and employees
 Improper management of tasks

4. Technical Risks : Technical risks refers to the functional risk or performance risk which
means this technical risk mainly associated with functionality of product or performance
part of the software product. Some reasons for Technical risks –

 Frequent changes in requirement

 Less use of future technologies
 Less number of skilled employee

5. Programmatic Risks: Programmatic risks refers to the external risk or other unavoidable
risks. These are the external risks which are unavoidable in nature. These risks come from
outside and it is out of control of programs. Some reasons for Programmatic risks –

 Rapid development of market

 Running out of fund / Limited fund for project development
 Changes in Government rules/policy

More risks associated with software development

1. Communication Risks: Misunderstandings, mistakes and a general sense of confusion
can result from inadequate or absent communication.
2. Security Risks: Vulnerabilities that might compromise the privacy, reliability or
accessibility of the set are known as security risks and they have become common in a
time.
 MODULE 2

Introduction to Risk Identification

Risk Identification is the first and most critical step in software risk management. It involves
the systematic process of identifying all possible risks that may negatively affect a software
project in the future. These risks may impact the project’s cost, schedule, quality, scope, or
performance. Since risks represent uncertainty, identifying them early helps organizations
prepare suitable plans to avoid or minimize losses. In software engineering, projects often fail
due to unidentified or poorly managed risks. Therefore, risk identification plays a key role in
improving project success and reliability.

Objectives of Risk Identification

The main objectives of risk identification are:

 To identify potential problems before they occur

 To reduce uncertainty in software projects
 To support proactive risk management
 To improve planning and decision-making
 To avoid unexpected failures and losses

Sources of Risks in Software Projects

Risks in software projects can arise from multiple sources, including:

 Project environment (schedule, cost, resources)

 Technical factors (technology, tools, design)
 Human factors (skills, communication, turnover)
1. Identify Maximum Knowable: All possible known risks should be identified using
available information such as past projects, experience, documents, and expert knowledge. The
goal is to reduce uncertainty as much as possible.

2. Early Identification: Risks should be identified as early as possible in the Software

Development Life Cycle (SDLC). Early identification helps in planning preventive actions and
reduces cost and effort.

3. Evaluate Risks Comprehensively: Each identified risk should be carefully analyzed in

terms of:

 Probability of occurrence
 Impact on cost, schedule, and quality

4. Identify Opportunities: Risk management should not only focus on threats but also
identify opportunities that can positively impact the project, such as improved processes or
new technologies.

5. Allow Multiple Perspectives: Risk identification should involve different stakeholders like
developers, testers, managers, and customers. Multiple viewpoints help in identifying hidden
or overlooked risks.

6. Link to Project Objectives: Each risk should be linked to project goals such as time, cost,
quality, and performance. This helps in understanding how risks affect overall project success.

7. Detail the Risk Statements: Risks should be clearly and precisely documented. A good
risk statement includes:

 Cause of the risk

 Event that may occur
 Impact on the project.

8. Iterative Risk Management: Risk identification is not a one-time activity. It should be

repeated throughout the project lifecycle as new risks may emerge over time.

9. Processes for Emergent Risks: Projects should have proper processes to identify and
manage new or unexpected risks that arise during development.
 MODULE 2

Introduction to Risk Projection

Risk Projection, also known as Risk Estimation, is the process of evaluating the likelihood
(probability) and impact of identified risks in a software project. After risks are identified, it is
necessary to analyze how serious each risk is and how much damage it can cause. Risk
projection helps project managers prioritize risks and focus on the most critical ones. Risk
projection plays a key role in effective decision-making and resource allocation in software
projects.

Objectives of Risk Projection

The main objectives of risk projection are:

 To estimate the severity of each risk

 To prioritize risks based on importance
 To support effective risk mitigation planning
 To reduce uncertainty in project execution
 To focus attention on high-risk areas

1. Identify Risks

This is the first step in risk projection. In this step, all possible risks that may affect the software
project are identified. These risks may be related to cost, schedule, technology, resources, or
quality. The output of this step is a list of identified risks.
2. Estimate Likelihood

After identifying risks, the next step is to estimate the likelihood (probability) of each risk
occurring. Likelihood may be expressed qualitatively (high, medium, low) or quantitatively
(percentage). This step helps in understanding how often a risk may occur.

3. Estimate Impact

In this step, the impact of each risk is assessed. Impact refers to the extent of damage the risk
can cause if it occurs. It may affect project cost, schedule, quality, or performance. Higher
impact risks require more attention.

4. Prioritize Risks

Based on the estimated likelihood and impact, risks are ranked in order of importance. Risks
with high probability and high impact are given the highest priority. This step helps project
managers focus on the most critical risks.

5. Plan Risk Response

In this step, appropriate strategies are developed to handle the prioritized risks. Risk response
plans may include:

 Risk avoidance
 Risk mitigation
 Risk transfer
 Risk acceptance

These plans help reduce the probability or impact of risks.

Cyclic Nature of the Diagram

The circular flow of the diagram indicates that risk projection is an iterative process. As the
project progresses, new risks may emerge and existing risks may change. Therefore, the cycle
is repeated throughout the Software Development Life Cycle (SDLC).

Limitations of Risk Projection

 Probability estimation may be subjective

 Impact assessment may be inaccurate
 Requires experience and judgment
 Cannot predict all future risks
 MODULE 2

Introduction to Risk Refinement

Following the crucial steps of identifying and projecting potential threats, the next stage
in effective risk management is risk refinement. This process involves taking each major
risk that has been identified and breaking it down into more detailed and manageable sub -
risks. The primary purpose of risk refinement is to gain a deeper, more granular
understanding of the specific elements that contribute to a broader risk. By doing so,
project teams can develop more precise analyses, create highly focused mitigation plans,
and ultimately implement more effective strategies to address potential problems before
they become critical.

The Process of Risk Refinement

Risk refinement systematically examines each projected risk in greater detail. It moves
beyond a general understanding to pinpoint the specific factors that might cause a risk to
materialize. For example, if “High staff turnover” is identified as a major project risk
during the risk projection phase, risk refinement would delve into the specific reasons or
sub-components that could lead to staff turnover within the software project.

Example: Refining “Staff Turnover” Risk

Let’s consider the broad risk previously identified: “High staff turnover”.

Risk refinement would break this general risk down into more specific and actionable sub -
risks. This makes it easier to understand the root causes and develop targeted solutions.
Sub-risks for “High staff turnover” could include:

 Lack of Challenging Work: If team members perceive their tasks as unstimulating

or lacking opportunities for professional growth, they might seek employment
elsewhere.

 Poor Compensation: Uncompetitive salaries, inadequate benefits, or insufficient

recognition can lead talented staff to look for better financial opportunities.

 Too Many Changes: Frequent, disruptive changes to project scope, requirements,

or direction can demotivate staff and create a sense of instability.
Benefits of Risk Refinement

The process of risk refinement offers several significant advantages for managing software
projects more effectively:

 Increased Specificity: It transforms broad, general risks into precise, actionable

problems. This specificity makes risks much easier to understand and manage.
 Improved Analysis: More detailed sub-risks allow for a more accurate and in-
depth assessment of their individual probabilities and potential impacts. This
enhances the overall risk projection.
 Targeted Mitigation: It enables the creation of highly focused and effective
mitigation strategies, as the specific underlying causes of the risks are clearly
understood. This means solutions are more likely to succeed.
 Better Monitoring: Refined risks are considerably easier to monitor, as specific
indicators can be tracked for each individual sub-risk. This provides clearer signals
of potential issues.
 Enhanced Control: With a clearer and more comprehensive understanding of the
nuances of each risk, project managers can exercise better control over potential
threats and make more timely interventions.
 MODULE 2

Reactive versus Proactive Risk Strategies

In software engineering, the approach to managing potential problems can broadly be

categorized into two distinct philosophies: reactive versus proactive risk strategies. These
strategies determine how a development team addresses uncertainties and threats
throughout a project’s lifecycle. While a reactive approach waits for problems to emerge
before taking action, a proactive strategy emphasizes anticipating and preparing for risks
well in advance. Understanding the fundamental differences between these two approaches
is crucial for effective project management and for ensuring the successful delivery of
software.

Reactive Risk Strategy

A reactive risk strategy is characterized by a “wait and see” approach. In this model, the
project team only responds to risks once they have materialized into actual problems or
crises. There is little to no prior planning or anticipation of potential issues.

 Characteristics:

 No Prior Planning: Risks are not actively identified or analyzed before they
occur.
 Crisis Management: The focus is on fixing problems as they arise, often
leading to hurried and less efficient solutions.
 Unforeseen Impacts: When risks turn into problems, they can cause
significant, unexpected impacts on project schedules, budgets, and product
quality.
 Stressful Environment: This approach often creates a high-pressure and
stressful working environment due to constant “fire-fighting.”

 Analogy: Imagine a team that only calls the fire department after the building is
already ablaze, without ever having planned for fire safety.

Proactive Risk Strategy

In contrast, a proactive risk strategy involves actively anticipating and planning for
potential risks before they have a chance to affect the project. This approach is highly
recommended in software engineering due to the complex and often unpredictable nature
of development.
  Characteristics:

 Early Identification: Risks are systematically identified and analyzed at the

earliest possible stages of the project.
 Mitigation Planning: Plans are developed to either avoid the risk entirely,
reduce its probability of occurring, or minimize its impact if it does occur.
 Contingency Planning: Backup plans are put in place for risks that cannot be
entirely avoided.
 Resource Allocation: Resources are strategically allocated to risk management
activities upfront.
 Reduced Impact: By addressing risks early, their potential negative
consequences are significantly reduced, leading to smoother project execution.

 Analogy: This is like installing smoke detectors, having fire extinguishers, and
practicing evacuation drills long before any fire ever starts.

The Preferred Approach

In the realm of software engineering, a proactive risk strategy is almost universally

preferred over a reactive one. Although it requires an initial investment of time and
resources for identification, analysis, and planning, this upfront effort typically yields
substantial benefits. It significantly reduces the likelihood of major project crises, helps
maintain adherence to schedules and budgets, and ultimately contributes to the deliver y of
higher-quality software. Successful software development hinges on foresight and
preparedness rather than merely responding to unforeseen problems.
 MODULE -2

RMMM:
Typically, a risk management strategy can be found in the software project plan. Risk
mitigation, monitoring, and a management plan can be used to categorize this (RMMM). All
tasks in this plan are completed as part of a risk analysis.
Risk" refers to a situation that could result in a loss or jeopardise the project's progress but has
not yet occurred.

The Risk Mitigation, Monitoring, and Management (RMMM) plan is a document that outlines
all risk analysis activities. This document is sometimes included in the overall project plan by
the project manager.
Risk Management:
A software project can be associated with a wide range of threats. It is necessary to classify
risks into distinct classes in order to be able to systematically identify the critical risks that
may harm a software project. After that, the project manager can determine whether risks
from each category are crucial to the project.

Risk management is the process of identifying, addressing, and resolving problems before
they harm the project.

The risks can be broadly categorised into three categories, as illustrated below:
1. Project risks are those that have an impact on the project's schedule or resources.
2. Product risks affect the quality or performance of the product being developed.
3. Business risks are risks to the corporation developing or licensing the software.

Risk Management Activities: Risk management is assessing the unfavourable events that could
occur, their likelihood of occurring, and the losses that would result if they did. While
considering this, solutions can be designed to lessen the possibility of the content being a risk
or having an impact. As a result, risk management is centred on risk assessment and control.

In most cases, a risk management approach can be found in the software project plan. This can
be broken down into three sections: risk mitigation, monitoring, and management (RMMM).
All work is done as part of the risk analysis in this strategy. The project manager typically uses
this RMMM plan as part of the overall project plan.

Some development teams use a Risk Information Sheet(RIS) to document risk. For faster
information handling, such as creation, priority sorting, searching, and other analyses, this RIS
is controlled by a database system.
Risk Mitigation
Risk Mitigation is a technique for avoiding risks (Risk Avoidance).
The following are steps to take to reduce the risks:
 Identifying the risk.
 Getting rid of the causes that lead to the production of risk.
 Controlling the relevant documents regularly.
 Conducting timely reviews to accelerate the process.

Risk Monitoring
Risk monitoring is an activity used to track a project's progress.
The following are the critical goals of the task.
 To see if the risks that were anticipated actually happen.
 To verify that the risk aversion steps defined for risk are adequately implemented.
 To gather information for future risk assessments.
 To determine which risks generate which problems throughout the project.

Risk Management and Planning

Risk management and planning are based on the assumption that the mitigation effort failed
and the risk has become a reality. When a risk becomes a reality and produces serious problems,
the project manager is in charge of this responsibility. It is easier to manage risks if the project
manager successfully implements project mitigation to eliminate risks.

Drawbacks of RMMM
 It raises the cost of the project.
 Time will be needed more.
 A larger project's implementation of an RMMM could prove to be a time-consuming
process in and of itself.
 RMMM cannot guarantee a project will be risk-free; in fact, hazards could materialise
after the project has been delivered.

Conclusion
We learned about risk management activities and the RMMM plan in this article. We also infer
from this article how project managers do risk management, and the RMMM plan is one of
these techniques.
 MODULE-2
Quality Concepts
In the realm of software engineering, a clear understanding of quality concepts is
fundamental to developing successful and reliable software. These concepts lay the
groundwork for what software quality truly entails, how it is perceived, and how it can be
achieved.

Defining Software Quality

At its core, software quality can be defined in multiple ways, depending on the
perspective. However, common themes emerge:

 Conformance to Requirements: The most basic definition suggests that software

quality is achieved when the product meets its explicit functional and non-
functional requirements. This means it does what it is supposed to do, as specified.
 Fitness for Purpose: Beyond explicit requirements, quality also means the
software is suitable for its intended use and environment. It effectively solves the
problem it was designed to address.

Key Perspectives on Software Quality

Quality Factors (as per McCall’s Model)
As previously mentioned in metrics for software quality, McCall’s Quality Factors provide
a useful framework for breaking down the broad concept of quality into measurable
attributes. These factors are indeed core quality concepts:

 Product Operation: Focuses on how the software performs, including correctness,

reliability, efficiency, integrity, and usability. These concepts describe the
immediate operational excellence of the software.

 Product Revision: Addresses the ease with which software can be changed,
encompassing maintainability, flexibility, and testability. These are crucial
concepts for the long-term life of the software.

 Product Transition: Deals with the software’s ability to adapt to new

environments, including portability, reusability, and interoperability. These
concepts are vital for the software’s adaptability and integration capabilities.
Quality Control (QC)
Quality Control involves a set of activities focused on identifying and correcting defects
in the actual software product. . The primary goal is to find errors and ensure the product
conforms to specified requirements.

 Focus: Defect detection.

 When: Primarily during and after development phases (e.g., testing, inspections,
debugging).
 Example: A team testing a software module to find bugs.

Quality Assurance (QA)

Quality Assurance involves a set of activities focused on establishing and ensuring
adherence to the processes and standards used to build the software. It is a process-oriented
concept. QA activities are performed throughout the software development lifecycle, with
the aim of preventing defects from being introduced in the first place.

Conclusion

A solid grasp of quality concepts in software engineering is indispensable for any

development team aiming to deliver excellent software. By clearly defining what quality
means, understanding different quality factors, and distinguishing between quality control
and quality assurance, organizations can build a robust framework for managing quality.
These foundational concepts drive proactive defect prevention, systematic error detection,
and continuous process improvement, all contributing to the creation of reliable, user -
satisfying, and successful software products.
 MODULE -2

Introduction to Formal Technical Reviews

In software engineering, Formal Technical Reviews (FTRs) are a highly structured and
systematic type of software review. These are formal meetings involving a team of peers
who meticulously examine a software engineering work product – such as requirements
specifications, design documents, or source code – to identify defects. The primary
objective of FTRs is to uncover errors as early as possible in the development lifecycle,
preventing them from propagating to later stages where they become significantly more
costly to fix.
Objectives of Formal Technical Reviews
 Uncover Errors (Defects): The foremost objective is to find as many errors as
possible in the work product being reviewed. This includes logical errors, factual
errors, omissions, inconsistencies, and deviations from standards.
 Verify Conformance to Standards: FTRs ensure that the software artifact adheres
to predefined standards, guidelines, and specifications
 Improve Product Quality: By detecting and removing defects early, FTRs
directly contribute to a higher quality software product, reducing rework and post-
release issues.
The Formal Technical Review Process
 Planning and Preparation
 Select Participants: A small team (typically 3-5 people) is chosen, including a
moderator, the producer (author of the work product), and 1-3 reviewers. Each
participant has a defined role.
 Define Scope: The specific section of the work product to be reviewed is clearly
identified.
 Distribute Materials: All participants receive the work product, relevant
standards, and checklists well in advance of the meeting.
 Individual Preparation: Reviewers independently examine the material, noting
any potential defects or questions. This individual effort is crucial.
 The Review Meeting
 Error Identification: Reviewers present the errors they found during their
individual preparation. The team collaboratively identifies and logs additional
errors.
 No Problem Solving: It is critical that the meeting focuses solely on identifying
errors, not on debating solutions or fixing the defects. Solutions are handled offline
by the producer.
  Rework and Follow-up
 Producer’s Rework: The producer is responsible for addressing all identified
defects and making necessary corrections to the work product after the meeting.
 Verification: The moderator or a designated reviewer verifies that all defects have
been properly addressed. This is a critical step to ensure the review’s effectiveness.
 Sign-off: Once all defects are resolved and verified, the review process is formally
concluded.

 Key Roles in FTRs:

 Producer (Author): The individual who created the work product being reviewed.
Their role is to provide context and clarify points, and later to address the identified
defects.
 Moderator: The facilitator of the FTR meeting. The moderator ensures the
meeting stays on track, enforces the rules, keeps participants focused on defect
finding, and manages time.
 Reviewers: The individuals who examine the work product, identify defects, and
offer constructive feedback. They are typically peers or subject matter experts.
 Recorder (Scribe): The person responsible for documenting all defects identified
during the meeting, as well as any action items or follow-up tasks
Benefits of Formal Technical Reviews
 Early Defect Removal: FTRs are highly effective at finding errors early in the
lifecycle, before they become expensive.
 Improved Software Quality: They directly lead to more reliable, robust, and
maintainable software.
 Cost Reduction: The cost of fixing defects found in reviews is substantially lower
than fixing them in later phases like testing or after deployment.

Conclusion:

Formal Technical Reviews (FTRs) are a cornerstone of effective software quality

assurance. By employing a structured, systematic, and peer-driven approach to
examining software work products, FTRs are exceptionally effective at identifying and
removing defects early in the development lifecycle.
 MODULE -2

Statistical Software Quality Assurance (SSQA) :

In software engineering, Statistical Software Quality Assurance (SSQA) is a powerful
approach that applies statistical methods to assess and improve the quality of software
products and processes.

The Core Idea of SSQA:

The fundamental premise of Statistical Software Quality Assurance is that software
defects are not random occurrences.
 Identify Root Causes: Pinpoint the underlying reasons why defects are being
introduced.
 Predict Defect Trends: Forecast future defect rates or identify areas prone to
errors.
 Guide Process Improvement: Recommend specific changes to the development
process that will prevent similar defects from occurring in the future.

SSQA Activities and Techniques:

Statistical Software Quality Assurance involves a set of structured activities and
employs various statistical techniques to achieve its objectives:
1. Defect Data Collection and Categorization
The first step is to systematically collect data on all identified software defects. This data
typically includes:

 Type of defect: e.g., logic error, syntax error, requirements misunderstanding,

interface error.
 Origin of defect: e.g., requirements phase, design phase, coding phase.
 Severity of defect: e.g., critical, major, minor.
 Time of discovery: When the defect was found.
 Cost to fix: The effort required to correct the defect.
Defects are then categorized to allow for meaningful analysis.

2. Cause Analysis:

Once data is collected, statistical tools are used to analyze it and identify the most
significant sources of defects. Common techniques for cause analysis in SSQA include:
  Pareto Analysis (80/20 Rule): This technique helps identify the “vital few” causes
that contribute to the “trivial many” defects. For example, it might show that 80%
of defects originate from only 20% of the possible causes (e.g., unclear
requirements or specific coding practices).
 Scatter Diagrams: Used to explore the relationship between two variables, such
as lines of code and number of defects.

Process Monitoring and Control Charts:

Control charts are a key statistical tool in SSQA for monitoring the software process over
time. They help determine if a process is stable and operating within acceptable limits, or
if it is “out of control” due to a special cause variation

 Purpose: To monitor process stability and identify unusual patterns or trends in

defect rates.
 Mechanism: Data points (e.g., number of defects per module, defect density) are
plotted over time, along with upper and lower control limits.
4 .Process Improvement

Based on the insights gained from defect analysis and process monitoring, specific
recommendations for process improvement are formulated. These improvements aim to
eliminate the root causes of defects, leading to a more efficient and higher -quality
development process. Examples might include:
 Enhanced training programs.
 Refined coding standards.
 More rigorous review procedures.
 Better communication protocols.
Benefits of Statistical Software Quality Assurance:
 Data-Driven Decisions: Moves quality management from subjective opinions to
objective, measurable facts.
 Targeted Improvements: Identifies the most impactful areas for process changes,
leading to more efficient resource allocation.
 Reduced Defect Rates: By addressing root causes, SSQA helps reduce the overall
number of defects in software.

Conclusion
Statistical Software Quality Assurance (SSQA) is a vital component of modern software
quality management. By systematically applying statistical methods to defect data, SSQA
provides profound insights into the underlying causes of software problems. This data-
driven approach, utilizing tools like Pareto analysis and control charts, enables
organizations to identify key areas for process improvement, ultimately leading to reduced
defect rates, enhanced software reliability, and more efficient development cycles.
 MODULE -2

Use of appropriate CASE tools:

CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.
CASE TOOLS:
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.
Components of Case tools
CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
Central Repository:
CASE tools require a central repository, which can serve as a source of common, integrated
and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information
regarding management is stored. Central repository also serves as data dictionary.
Upper Case Tools:
Upper CASE tools are used in planning, analysis and design stages of SDLC.
Lower Case tools:
Lower CASE tools are used in implementation, testing and maintenance.
Integrated Case tools:
Integrated CASE tools are helpful in all the stages of SDLC, from Requirement gathering to
Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process activities and
capability of getting integrated with other tools.
Types of CASE tools:
Diagram tools:
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart
Maker tool for creating state-of-the-art flowcharts.
Process Modeling tools:
Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it as
per the requirement of software product. For example, EPF Composer.
Analysis tools:
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example, Accept
360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total analysis.
Configuration management tools:
An instance of software is released under one version. Configuration Management tools deal
with:
 Version and revision management.
 Baseline management configuration
 Change control management
Conclusion:
Appropriate CASE tools enhance productivity by automating repetitive tasks, reducing manual
errors, and ensuring consistency across different phases of development. They also improve
communication and collaboration among team members through proper documentation and
standardized models. Additionally, CASE tools support better project management by enabling
accurate planning, tracking progress, and maintaining version control.
 MODULE -2
Requirement Engineering Tools in Software Engineering:
Requirement Engineering (RE) tools help in eliciting, analyzing, documenting, validating,
and managing software requirements throughout the Software Development Life Cycle
(SDLC). These tools ensure that requirements are clear, consistent, traceable, and
manageable.

1. Requirement Elicitation Tools

Used to gather requirements from stakeholders.

 Interviews & Questionnaires – Collect user needs directly.

 Brainstorming Tools – Generate ideas collaboratively.
 Prototyping Tools – Help users visualize the system (e.g., Balsamiq, Figma).
 Use Case Tools – Capture functional requirements through scenarios.

2. Requirement Modeling Tools

Used to represent requirements in visual and structured form.

 UML Tools (Use Case, Class, Sequence Diagrams)

o Examples: StarUML, Enterprise Architect, Visual Paradigm
 Data Flow Diagram (DFD) Tools
 Entity Relationship (ER) Diagram Tools

3. Requirement Documentation Tools

Used to clearly document requirements.

 Software Requirement Specification (SRS) Templates

 Word Processors (MS Word, Google Docs)
 Markdown Tools
 CASE Documentation Tools

4. Requirement Analysis Tools

Used to check feasibility, conflicts, and completeness.

 Requirement Traceability Matrix (RTM) Tools

 Decision Tables & Trees
 Risk Analysis Tools
  Prioritization Tools (MoSCoW technique)

5. Requirement Validation & Verification Tools

Ensure requirements meet stakeholder needs.

 Review & Inspection Tools

 Checklist-based Validation Tools
 Prototyping & Simulation Tools
 Test Case Management Tools (to verify requirements)

6. Requirement Management Tools

Used to handle changes and maintain consistency.

 IBM DOORS
 JIRA
 Rational RequisitePro
 Helix RM
 Polarion
 Version Control Tools (Git)

7. Traceability Tools

Maintain linkage between requirements and other artifacts.

 RTM (Requirement Traceability Matrix)

 Integrated CASE Tools
 ALM (Application Lifecycle Management) Tools

Importance of Requirement Engineering Tools

 Improve requirement clarity and accuracy

 Reduce misunderstandings and rework
 Handle requirement changes effectively
 Enhance communication among stakeholders
 Improve software quality and customer satisfaction

Conclusion: Requirement Engineering Tools

Requirement engineering tools play a crucial role in the successful development of software
systems. They support the systematic process of eliciting, analyzing, documenting, validating, and
managing requirements throughout the software development life cycle. By using these tools,
organizations can reduce ambiguity, avoid misunderstandings, and minimize costly rework caused by
unclear or changing requirements.
 MODULE -2

Project Planning tools:

What is Project Planning?
A project consists of five different phases: initiation, planning, execution, monitoring and
controlling, and closure. Planning is the second phase of the project life cycle, where a plan
after the initiation phase is made so the process of execution may begin. The project plan
serves as a roadmap for the entire process of project management.
What are the 5 Phases of a Project?
Initiation: You must create a business plan and define a broad project at this stage. Ensure
the project meets business needs and that stakeholders and project teams agree. Creating the
project success criteria throughout the project life cycle is the main objective of the Initiation
Phase. Also, at this point, the feasibility of the project and its measurement are taken into
account.
Planning: To keep the project on track for the remainder of the life cycle, the project
manager attempts to manage every task and aspect of project delivery during this phase.
During this phase, the project manager also must consistently uphold productive stakeholder
collaboration. This ensures everyone is on the same page and everything goes off without a
hitch during the project.
Monitoring and Management: By working in parallel with project execution, the project
monitoring and controlling phase guarantees that goals and project deliverables are met.
Along with keeping tabs on task progress, the project manager also looks for problems or
risks, develops a plan to mitigate them with the team, and regularly communicates the
project's status to stakeholders.
Project Planning Tools: Project planning tools help everyone concerned keep track of
project requirements and deadlines. Some of the most popular project planning tools include
the following:

Gantt Chart

 Gantt charts are an industry standard that helps in tracking both time and
interdependencies between tasks
 Gantt charts are an essential tool to show different phases, jobs, and resources involved in
project management
Critical Path Method (CPM)

 Critical Path Method (CPM) is a crucial tool for determining the progress of the project to
ensure that the project is on schedule

 CPM helps in determining the essential or critical path by finding out the longest stretch of
dependent tasks

PERT Chart

 The Program Evaluation and Review Technique (PERT) helps in analyzing the tasks to
complete the project and the time required to complete those tasks

 PERT simplifies the planning and scheduling of large and complex projects

Work Breakdown Structure (WBS)

 Work Breakdown Structure (WBS) is a process of organizing the team's work into
manageable sections

 WBS is a hierarchical structure of the deliverables needed to complete the project

Project Documentation

 Project documentation is created during the project lifecycle, which involves project
scope, its schedule, and the risk analysis

 Project documents help in better understanding and risk analysis of the project

Conclusion: Project Planning Tools

Project planning tools play a crucial role in the successful execution of software projects.
They help project managers define project scope, allocate resources effectively, schedule
tasks, estimate cost and time, and identify potential risks in advance. By providing a clear
roadmap of project activities, these tools ensure better coordination and control throughout
the project lifecycle. Moreover, project planning tools support monitoring and tracking of
progress, enabling timely decision-making and corrective actions when deviations occur.
They improve communication among team members and stakeholders through visual plans,
reports, and dashboards.

In conclusion, the effective use of project planning tools leads to improved productivity,
reduced project risks, better time and cost management, and higher chances of delivering
projects on schedule with the desired quality. Hence, project planning tools are essential for
achieving successful and well-managed software projects.
 MODULE - 2

Testing Tools:
Delivering high-quality software requires powerful, efficient, and scalable testing solutions.
Software testing tools are essential for streamlining testing workflows and improving
application reliability, user satisfaction, and time-to-market.
What are Testing Tools?
Testing tools are specialized software applications designed to evaluate the functionality,
performance, and security of other software or systems. These tools are integral to the
software development process, enabling developers to verify that their code meets the
specified requirements and behaves as expected under various conditions.
Testing tools cover a range of testing types, including unit testing, integration testing, visual
testing, and accessibility testing. Each tool is specialized to handle different aspects of
testing, providing detailed diagnostics and helping to streamline the development process.
Top Software Testing Tools:
Browser Stack:
BrowserStack is a full stack cloud-based testing platform that allows users to run application
tests across 3500+ real device-browser combinations. It offers support for both manual and
automated testing, test case management, visual testing, low-code automation, and robust
reporting features via its robust tools to ensure that you have an end-to-end solution for all
your software testing needs.
Key Features:

 Cross-browser and real device test execution on the cloud

 Integration with CI/CD pipelines.

 Parallel test execution for faster results.

Browser Stack Test Management:

Browser Stack Test Management is a highly regarded tool that enhances the testing process

by efficiently handling both manual and automated test cases. It streamlines the setup,
management, and monitoring of test cases, providing integrated workflows and easy-to-use
dashboards for immediate insight into software quality.
Key Features:

 Centralized test case and test cycle management

 Create, organize, and track test cases easily

 Link test cases to execution results

Why do you need Testing Tools?

Testing tools are crucial for verifying whether a software functions as expected and
maintaining high software quality and reliability. Manual Testing is labour-intensive and
prone to errors, making it inefficient for large-scale software projects.

On the other hand, testing tools:

 Automate repetitive tasks
 Ensure consistent test coverage
 Can simulate real user conditions

Factors to consider when choosing a Software Testing Tool

 Cost: The most critical factors when choosing a testing tool are budget, cost, and end-

user requirements. Depending on the size of your team or your usage choice, you need

to opt for a solution.

 Compatibility: Your testing tools should efficiently run and execute test cases on

different cross-browser platforms, and it will save time from running test cases on

different platforms manually.

Conclusion:

Choosing the right testing tool depends on the specific requirements of the project, the

budget, and the technical expertise of the team. Employing the most apt testing tool

effectively can lead to higher quality products, improved user satisfaction, and a

stronger competitive edge in the market.