SOFTWARE ENGIEERING

DISCLAIMER: THIS IS AS PER SYLLABUS BOOK

UNIT – 1
1. The evolving role of software
The software evolution process includes fundamental activities of change analysis, release
planning, system implementation, and releasing a system to customers.
1. The cost and impact of these changes are accessed to see how much the system is
affected by the change and how much it might cost to implement the change.
2. If the proposed changes are accepted, a new release of the software system is planned.
3. During release planning, all the proposed changes (fault repair, adaptation, and new
functionality) are considered.
4. A design is then made on which changes to implement in the next version of the system.
5. The process of change implementation is an iteration of the development process where
the revisions to the system are designed, implemented, and tested.
Necessity of Software evolution:

1. Change Identification Process:

 Systematic approach to identifying necessary modifications in software.
 Involves analyzing user feedback, technological advancements, and business
requirements.
 Aims to pinpoint areas needing improvement or enhancement.

2. Change Proposal:
  Formal document proposing modifications or enhancements to software.
 Includes rationale, expected benefits, resource estimates, and potential risks.
 Used to communicate proposed changes to stakeholders for evaluation and approval.

3. Software Evolution Process:

 Continuous improvement and adaptation of software throughout its lifecycle.
 Responds to changing requirements, technologies, and user needs.
 Includes change identification, implementation, and maintenance phases.

4. New System:
 Significantly revised version of existing software.
 May involve rewriting code, adopting new technologies, or rearchitecting.
 Developed to address substantial changes in business processes or technological
advancements.

2. Changing nature of software

Software is defined as computer programs and documents that are designed by software
engineers.
1. System Software:
 Collection of programs that service other programs.
 Involves complex, determinate information structures.
 Interacts heavily with hardware, managing scheduling, resource sharing, and process
management.

2. Application Software:
 Solves specific business needs or facilitates technical decision-making.
 Processes business or technical data to support operations or management.
 Includes real-time control of business functions.

3. Engineering and Scientific Software:

 Facilitates engineering tasks and functions.
 Includes modern applications like computer-aided design and system simulation.
 Moving towards real-time and system software-like characteristics.

4. Embedded Software:
  Resides within systems or products to implement and control features.
 Can perform specialized functions or provide extensive control capabilities.

5. Product-line Software:
 Designed to provide specific capabilities for widespread use.
 Targets niche or mass consumer markets with tailored functionalities.

6. Web Application:
 Client-server programs run on web browsers.
 Evolving from simple hypertext to sophisticated computing environments.
 Supports e-commerce, B2B applications, and standalone computing functions.

7. Artificial Intelligence Software:

 Uses nonnumerical algorithms to solve complex, non-computational problems.
 Includes robotics, expert systems, pattern recognition, neural networks, theorem
proving, and game playing applications.

3. 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 and Realities:

Myth 1:
 Manuals with detailed procedures, principles, and standards are necessary for software
development.
 Reality: Strict adherence to outdated and incomplete standards can hinder productivity
and delay projects.

Myth 2:

 Adding more programmers to a delayed project speeds up completion.

 Reality: Additional team members can lead to increased issues and delays due to
onboarding and productivity challenges.

Myth 3:
 Outsourcing a project ensures success if there is clear communication and feedback.
 Reality: Internal issues within the company can still affect the outsourced project,
leading to complications and potential failures.

2. Customer Myths and Realities:

Myth 1:
 Starting software development with vague goals is sufficient.
 Reality: Ambiguous objectives often result in software that fails to meet customer
expectations and can lead to project failures.

Myth 2:
 Software is flexible and can easily accommodate new requirements during
development.
 Reality: Changes become increasingly costly and complex as development progresses,
impacting timelines and budgets.

3. Practitioner Myths and Realities:

Myth 1:
 Developer’s job ends once software is delivered.
 Reality: Post-delivery tasks such as maintenance, updates, and bug fixes are crucial and
can consume a significant portion of developers’ efforts.

Myth 2:
  Testing software is only feasible when it is operational.
 Reality: Quality Assurance (QA) can be implemented throughout development to
evaluate software performance and ensure it meets standards.

Myth 3:
 Excessive documentation impedes software development.
 Reality: Balancing documentation with coding and problem-solving tasks is essential
for efficient development processes.

4. Software engineering – A layered technology

Software engineering is a fully layered technology, to develop software we need to go from
one layer to another. All the layers are connected and each layer demands the fulfillment of the
previous layer.

Layer 1 — Tools:
 Involves selecting semi-automated and automated tools for the project.
 Examples include choosing Microsoft Publisher for web design, Selenium for cross-
platform testing, and an IDE for app development.
 Tools should integrate effectively with the chosen operating system and with each other.

Layer 2 — Method:
 Establishes the methods and technical knowledge for software development.
 Tasks include selecting methods for communication, analysis, modeling, program
construction, testing, and support.
 Emphasizes how tools chosen in the first layer will be utilized effectively.

Layer 3 — Process:
  Focuses on the framework needed to deliver software effectively.
 Includes sub-layers:
 Communication: Essential for understanding client needs and ensuring team alignment.
 Planning: Mapping out development processes, goals, milestones, and plans.
 Modeling: Creating visual representations of the final product for client visualization.
 Construction: Coding and testing the software product.
 Deployment: Releasing the actual software for testing, evaluation, and feedback.

Layer 4 — A Quality Focus:

 Ensures the developed software meets client specifications through rigorous quality
control.
 Involves end product testing, real-world testing for efficiency and usability, and
assessing maintenance requirements.
 Important for replacing older software or platforms to ensure the new software meets
current needs effectively.

5. Process Framework in Software engineering

Software Process Framework details the steps and chronological order of a process. Since it
serves as a foundation for them, it is utilized in most applications. Task sets, umbrella activities,
and process framework activities all define the characteristics of the software development
process. Software Process includes:
a. Tasks: They focus on a small, specific objective.
b. Action: It is a set of tasks that produce a major work product.
c. Activities: Activities are groups of related tasks and actions for a major objective.

6. CMMI in Software engineering

The Capability Maturity Model Integration (CMMI) is a process and behavioral model that
helps organizations streamline process improvement and encourage productive, efficient
behaviours that decrease risks in software, product, and service development.Levels:
A capability level includes relevant specific and generic practices for a specific process area
that can improve the organization’s processes associated with that process area. For CMMI
models with continuous representation, there are six capability levels as described below :
Capability level 0 : Incomplete
 incomplete process – partially or not performed.
 one or more specific goals of process area are not met.
 No generic goals are specified for this level.
 this capability level is same as maturity level 1.
Capability level 1 : Performed
  process performance may not be stable.
 objectives of quality, cost and schedule may not be met.
 a capability level 1 process is expected to perform all specific and generic
practices for this level.
 only a start-step for process improvement.
Capability level 2 : Managed
 process is planned, monitored and controlled.
 managing the process by ensuring that objectives are achieved.
 objectives are both model and other including cost, quality, schedule.
 actively managing processing with the help of metrics.
Capability level 3 : Defined
 a defined process is managed and meets the organization’s set of guidelines and
standards.
 focus is process standardization.
Capability level 4 : Quantitatively Managed
 process is controlled using statistical and quantitative techniques.
 process performance and quality is understood in statistical terms and metrics.
 quantitative objectives for process quality and performance are established.
Capability level 5 : Optimizing
 focuses on continually improving process performance.
 performance is improved in both ways – incremental and innovation.
 emphasizes on studying the performance results across the organization to
ensure that common causes or issues are identified and fixed.
 7. Process models in Software engineering
1. Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic representation resembles a
cascade of waterfalls.
Phases of the Waterfall Model:

1. Requirements Analysis and Specification Phase:

 Objective: Understand and document customer requirements.
 Collaboration: Customer and developers work together to detail functions,
performance, and interfaces.
 Output: Software Requirement Specification (SRS) document outlining system
functionalities without delving into implementation specifics.

2. Design Phase:
 Objective: Transform SRS into a blueprint for software development.
 Activities: Define software architecture, high-level and detailed design.
 Document: Software Design Document (SDD) captures design decisions and rationale.

3. Implementation and Unit Testing:

 Objective: Translate design into code (implementation) and verify individual units.
 Process: Code development follows SDD guidelines.
 Testing: Unit testing ensures individual modules function correctly in isolation before
integration.
4. Integration and System Testing:
 Objective: Combine units into a complete system and verify its functionality.
 Testing Scope: Test modules interact with each other and with the overall system.
 Quality Focus: Ensures the software meets requirements and functions as expected in
an integrated environment.

5. Operation and Maintenance Phase:

 Objective: Ensure the software remains operational and effective post-deployment.
 Activities: User support, bug fixes, updates, and enhancements as needed.
 Maintenance: Routine tasks to sustain software functionality and address user feedback
or issues.
The Waterfall Model provides a structured approach to software development, ensuring
systematic progression through defined stages from initial concept to operational deployment
and maintenance.

2. Incremental process models

Incremental Model is a process of software development where requirements divided into
multiple standalone modules of the software development cycle. In this model, each module
goes through the requirements, design, implementation and testing phases. Every subsequent
release of the module adds function to the previous release. The process continues until the
complete system achieved.

The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model, the product
analysis expertise identifies the requirements. And the system functional requirements
are understood by the requirement analysis team. To develop the software under the
incremental model, this phase performs a crucial role.
 2. Design & Development: In this phase of the Incremental model of SDLC, the design
of the system functionality and the development method are finished with success.
When software develops new practicality, the incremental model uses style and
development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various
methods are used to test the behaviour of each task.

4. Implementation: Implementation phase enables the coding phase of the

development system. It involves the final coding that design in the designing and
development phase and tests the functionality in the testing phase. After completion of
this phase, the number of the product working is enhanced and upgraded up to the final
system product.

Types of Incremental Model

1. Staged Delivery Model

Construction of only one part of the project at a time.

2. Parallel Development Model

Different subsystems are developed at the same time. It can decrease the calendar time
needed for the development, i.e. TTM (Time to Market) if enough resources are
available.

3. Evolutionary process models

The evolutionary model is based on the concept of making an initial product and then evolving
the software product over time with iterative and incremental approaches with proper feedback.
In this type of model, the product will go through several iterations and come up when the final
product is built through multiple iterations. The development is carried out simultaneously with
the feedback during the development. This model has a number of advantages such as customer
involvement, taking feedback from the customer during development, and building the exact
product that the user wants. Because of the multiple iterations, the chances of errors get reduced
and the reliability and efficiency will increase.
Types of Evolutionary Process Models
1. Iterative Model:
 Process: Begins with initial requirements and enhances the product through
multiple iterations.
 Iterations: Each iteration includes design modifications and additions to
functional requirements.
 Objective: Develops the final product progressively, refining it with each
iteration.
Advantages:

 Alignment with User Needs: Results in a final product closely matching user
requirements.
 Error Reduction: Iterative refinement reduces errors over successive iterations.
 High Performance and Quality: Focus on continuous improvement leads to
higher performance and quality of the final product.

2. Incremental Model
In the incremental model, we first build the project with basic features and then evolve
the project in every iteration, it is mainly used for large projects. The first step is to
gather the requirements and then perform analysis, design, code, and test and this
process goes the same over and over again until our final project is ready.
 3. Spiral Model
The spiral model is a combination of waterfall and iterative models and in this, we focused
on risk handling along with developing the project with the incremental and iterative
approach, producing the output quickly as well as it is good for big projects. The software
is created through multiple iterations using a spiral approach. Later on, after successive
development the final product will develop, and the customer interaction is there so the
chances of error get reduced.

UNIT – 2
1. Agile Principles
There are 12 agile principles mentioned in the Agile Manifesto. Agile principles are guidelines
for flexible and efficient software development. They emphasize frequent delivery, embracing
change, collaboration, and continuous improvement. The focus is on delivering value,
maintaining a sustainable work pace, and ensuring technical excellence.

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

2. Extreme Programming
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.
 3. Dynamic System Development Methods [DSDM]
The Dynamic Systems Development technique (DSDM) is an associate degree agile code
development approach that provides a framework for building and maintaining systems. The
DSDM philosophy is borrowed from a modified version of the sociologist principle—80 % of
An application is often delivered in twenty percent of the time it’d desire deliver the entire (100
percent) application.
DSDM is An iterative code method within which every iteration follows the 80% rule that
simply enough work is needed for every increment to facilitate movement to the following
increment. The remaining detail is often completed later once a lot of business necessities are
noted or changes are requested and accommodated.
DSDM Lifecycle:

1. Feasibility Study:
It establishes the essential business necessities and constraints related to the applying to be
designed then assesses whether or not the application could be a viable candidate for the
DSDM method.
2. Business Study:
It establishes the use and knowledge necessities that may permit the applying to supply
business value; additionally, it is the essential application design and identifies the
maintainability necessities for the applying.
3. Functional Model Iteration:
It produces a collection of progressive prototypes that demonstrate practicality for the client.
(Note: All DSDM prototypes are supposed to evolve into the deliverable application.) The
intent throughout this unvarying cycle is to collect further necessities by eliciting feedback
from users as they exercise the paradigm.
4. Design and Build Iteration:
It revisits prototypes designed throughout useful model iteration to make sure that everyone
has been designed during a manner that may alter it to supply operational business price for
finish users. In some cases, useful model iteration and style and build iteration occur at the
same time.
5. Implementation:
It places the newest code increment (an “operationalized” prototype) into the operational
surroundings. It ought to be noted that:
(a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed into place. In either case, DSDM
development work continues by returning to the useful model iteration activity.

4. Scrum Framework
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.
Silent 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
 Lifecycle of Scrum
  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.

5. Scrum Master
A Scrum master is the facilitator of scrum, a lightweight agile framework focusing on time-
boxed iterations called sprints. Scrum masters act as coaches to the rest of the team,
or servant leaders, as the Scrum Guide puts it.
Good scrum masters are committed to the foundational elements of scrum but remain
flexible and open to opportunities for the team to improve their workflows.

6. Roles of Scrum Master

The role and responsibility include:
 Clearing obstacles.
 Addressing team dynamics.
 Meeting facilitations.
 Internal consulting and reporting.
 Making an environment where the team can be productive.
 Guarantee a good relationship between the product owner and team along with others
outside the team.
 Coaching the team about cross functionality.
 Protecting the team from outside distractions.

7. Functional & Non – Functional Requirements

Functional Requirements Non - Functional Requirements
 A functional requirement defines a  A non-functional requirement defines the
system or its component. quality attribute of a software system.

 It specifies “What should the software  It places constraints on “How should the
system do?” software system fulfill the functional
requirements?”
 Functional requirement is specified by  Non-functional requirement is specified by
User. technical peoples e.g. Architect, Technical
leaders and software developers.

 It is mandatory.  It is not mandatory.

 It is captured in use case.  It is captured as a quality attribute.
 Defined at a component level.  Applied to a system as a whole.
 Helps you verify the functionality of the  Helps you to verify the performance of the
software. software.
 Functional Testing like System,  Non-Functional Testing like Performance,
Integration, End to End, API testing, etc Stress, Usability, Security testing, etc are
are done. done.
 Usually easy to define.  Usually more difficult to define.
 Example  Example
1) Authentication of user whenever 1) Emails should be sent with a latency of
he/she logs into the system. no greater than 12 hours from such an
2) System shutdown in case of a cyber activity.
attack. 2) The processing of each request should
3) A Verification email is sent to user be done within 10 seconds
whenever he/she registers for the first 3) The site should load in 3 seconds when
time on some software system. the number of simultaneous users are >
10000

8. The Software Requirement Document

Software Requirements Document (SRD): The foundation of requirement
documentation, the SRD outlines functional requirements, non-functional requirements,
and external components necessary for the software's functionality and performance.
1. Introduction:
 Overview: Provides an introduction to the software project, its purpose, and its
scope.
  Document Purpose: Describes the objective of the SRS document and its intended
audience.

2. Functional Requirements:

 Functional Description: Describes the functionality of the software system in detail,

often using use cases, scenarios, or user stories.
 Requirements: Lists specific features and functions the software must provide.
 Dependencies: Any dependencies on external systems or software.
 Performance Requirements: Specifies performance criteria such as response times,
throughput, etc.

3. Non-Functional Requirements:
 Performance: Describes criteria related to system performance under certain
conditions (e.g., response time, throughput, etc.).
 Reliability: Specifies requirements related to the reliability and availability of the
software system.
 Usability: Describes requirements related to the usability and user interface of the
software.
 Security: Specifies requirements related to data security, access control, etc.
 Compatibility: Specifies requirements related to compatibility with other systems
or platforms.
 Legal and Regulatory Requirements: Specifies any legal or regulatory requirements
that the software must adhere to.

4. External Interface Requirements:

 User Interfaces: Describes the interfaces through which users interact with the
system.
 Hardware Interfaces: Describes requirements related to hardware connections or
interfaces.
 Software Interfaces: Describes requirements related to interfaces with other
software systems.

5. System Features:
 Describes the different features of the software system in detail.

6. Other Requirements:
  Documentation Requirements: Describes the documentation that needs to be
produced alongside the software.
 Quality Assurance: Describes requirements related to testing, quality assurance, and
validation.
 Maintenance and Support: Describes requirements related to maintenance and
support of the software after deployment.

9. Requirements engineering process

A systematic and strict approach to the definition, creation, and verification of requirements
for a software system is known as requirements engineering.
Requirements Engineering Process:

1. Feasibility Study:
 It focuses on Economic Feasibility as the most crucial aspect.
 Legal Feasibility is considered less important.
2. Requirements Elicitation:
 Sources of domain knowledge include customers, business manuals, existing
software, standards, and stakeholders.
 Techniques include interviews, brainstorming, task analysis, Delphi technique, and
prototyping.
3. Requirements Specification:

 Involves documenting functional and non-functional requirements, constraints, and

acceptance criteria.
 Uses models like ER diagrams, data flow diagrams (DFDs), and function
decomposition diagrams (FDDs).
4. Requirements Verification and Validation:
 Verification ensures requirements are complete, consistent, and accurate.
 Validation ensures requirements meet stakeholder needs and expectations.
  Methods include reviews, buddy checks, and creating test cases.
5. Requirements Management:
 Involves analysing, documenting, tracking, prioritizing, and controlling
requirements.
 Manages changes systematically and ensures SRS (Software Requirements
Specification) is modifiable.

UNIT – 3
1. System Models
System model is a procedure of creating abstract models to understand the system to be
developed. It is an important step while creating software because, with the help of an abstract
model, software developers can easily explain the system's structure and behaviour to
customers.

1. Context Model:
The external perspective model represents how the system that must be built will interact
with other systems within its environment. It shows the boundaries of a system that includes
various automated systems in an environment. The requirements of employees and
stakeholders are discussed while creating the context model to decide the system's
functionality that needs to be developed. It shows the relationships between the system to
be created and other systems.
It is used to explain developers, stakeholders, or customers. Some factors need to be kept
in mind while creating the context model. The factors can be the overall cost of the system,
the time required to analyse the system, etc.
Examples of the Context Model: ATM
The main system is connected to actors in an environment. The actors can be users and
other systems.
The Bank ATM System is used to dispense cash and permit to make other banking
transactions. The Local Branch Accounting System contains the accounts of the local
branch users. The Bank ATM System interacts with the Local Branch Accounting System
to get the user account details. The Account Database allows user to access their
information. The Hardware/ Software Maintenance Staff tests and maintains the ATM. The
Security System is used to protect the ATM from hackers. The Cash Counter Staff is used
to count the cash.
2. Behavioural Model:
The behavioural model is used to illustrate the dynamic behaviour of the system at the time
when the model is executing. The behavioural model depicts what occurs or what should
occur when a system reacts to a stimulus from its environment.
Two kinds of behavioural models explain the system's behaviour in software engineering.
The two models are the data processing model and the state machine model.
o Data Processing Model: In this model, Data Flow Diagrams (DFDs) represent the
system's data processing.
o State Machine Model: In this model, state diagrams represent the system's response
to external events.
 2. Object Models
The object model visualizes the elements in a software application in terms of objects. In
this chapter, we will look into the basic concepts and terminologies of object–oriented
systems.
Key Concepts in Object Models:

1. Objects:
 Objects represent the fundamental entities or things within the system. They
encapsulate both data (attributes or properties) and behaviour (methods or
functions) that operate on the data.
 Example: In a banking application, objects could include Customer, Account,
Transaction, etc.
2. Classes:
 Classes define the blueprint for creating objects. They specify the properties
(attributes) and behaviours (methods) that objects of the class will exhibit.
 Example: A Customer class would define attributes like name, address, and methods
like depositMoney, withdrawMoney.
3. Attributes and Methods:
 Attributes: These are the properties or data fields that characterize an object's state.
 Methods: These are functions or procedures that define the behaviors or actions that
objects can perform.
 Example: For a Customer object, attributes could be name and address, while
methods could be depositMoney and withdrawMoney.
4. Relationships:
 Relationships describe how objects interact or collaborate with each other within
the system.
 Types of relationships include association (a simple relationship between objects),
aggregation (a part-whole relationship), and inheritance (a mechanism where one
class inherits the properties and behaviours of another).
5. Interfaces:
 Interfaces define a contract specifying the methods that a class must implement.
They provide a way to achieve abstraction and polymorphism in object-oriented
design.
 Example: An interface for a PaymentProcessor could define methods like
processPayment and refundPayment.
 3. Structured Methods
Structured methods in software engineering refer to systematic approaches for analysing,
designing, and documenting software systems. These methods emphasize a disciplined and
organized way of developing software, typically characterized by the following principles:
1. Modularity: Breaking down the software system into manageable modules or components,
each responsible for specific functionality. This promotes easier development, testing, and
maintenance.
2. Hierarchy: Structuring the software design in a hierarchical manner, where higher-level
modules encapsulate lower-level ones. This hierarchical structure helps in managing
complexity and promoting reusability.
3. Top-down Design: Starting the design process from high-level modules and progressively
refining the design to lower levels of detail. This approach ensures that the overall system
architecture is well-defined before diving into specific implementation details.
4. Abstraction: Using abstraction to hide unnecessary details and focus on essential aspects of
the software system. Abstraction helps in managing complexity and improving clarity in
design.
5. Clear Documentation: Emphasizing clear and structured documentation throughout the
software development lifecycle. This includes documenting requirements, design decisions,
module interfaces, and testing procedures, ensuring transparency and facilitating collaboration
among team members.
6. Standardization: Following standardized notations and practices for diagrams,
documentation, and methodologies. This promotes consistency and clarity across different
phases of software development.

4. Design process & Design Quality

Design Process:
 Requirements Analysis: Gather and prioritize stakeholder needs and define scope.
 System Design: Define architecture, modules, and allocate responsibilities.
 Detailed Design: Specify data structures, algorithms, and interfaces.
 Implementation: Translate design into executable code
 Testing and Validation: Verify and validate software against requirements.
 Deployment and Maintenance: Release, maintain, and support the software.
Design Quality:
 Correctness: Meets specified requirements accurately.
 Modularity: Divided into independent, manageable modules.
 Flexibility: Allows for changes and extensions without major rework.
 Performance: Efficient in response time and resource use.
 Usability: User-friendly and intuitive.
  Maintainability: Easy to understand, update, and enhance.
 Reliability: Operates consistently and correctly under different conditions.
 Scalability: Accommodates increasing loads and data volumes.

5. Design Concepts
Design concepts in software engineering encompass fundamental principles and ideas that
guide the process of designing software systems. These concepts are crucial for creating
software that is efficient, maintainable, scalable, and meets user requirements. Here are some
key design concepts:
1. Abstraction:
 Definition: Abstraction focuses on hiding complex implementation details and
emphasizing only the essential features of an object or system.
 Purpose: Simplifies design, reduces complexity, and improves clarity by focusing on
what an object does rather than how it does it.
2. Modularity:
 Definition: Modularity involves dividing a software system into separate, independent
modules or components.
 Purpose: Enhances maintainability, reusability, and scalability by allowing changes to
one module without impacting others.
3. Encapsulation:
 Definition: Encapsulation bundles data (attributes) and methods (functions) that operate
on the data into a single unit (object).
 Purpose: Promotes data security, hides implementation details, and ensures controlled
access to data through well-defined interfaces.
4. Inheritance:
 Definition: Inheritance allows one class (subclass or derived class) to inherit properties
and behaviours from another class (superclass or base class).
 Purpose: Facilitates code reuse, promotes hierarchical classification, and supports
polymorphism.
5. Polymorphism:
 Definition: Polymorphism allows objects of different classes to be treated as objects of
a common superclass.
 Purpose: Enables flexibility and extensibility by allowing methods to be called on
objects of different types, facilitating dynamic binding and method overriding.
6. Coupling and Cohesion:
 Coupling: Refers to the degree of dependency between modules or components within
a system.
  Cohesion: Refers to the degree to which elements within a module or component are
related.
 Purpose: Loose coupling and high cohesion are desired to minimize dependencies and
improve modularity, making systems easier to understand, maintain, and extend.

6. Design Model

1. Data Design:
Transforms information domain model into data structures required to implement software.
2. Architectural Design:
Defines relationship among the major structural elements of a program
3. Interface Design:
Describes how the software communicates with itself, to systems that interact with it and with
humans.
4. Procedural Design:
Also Component Level.
Transforms structural elements of the architecture into a procedural description of software
construction.

7. Design class – based components

When an object-oriented software engineering approach is chosen, component-level design
focuses on the elaboration of problem domain specific classes and the definition and refinement
of infrastructure classes contained in the requirements model. The detailed description of the
attributes, operations, and interfaces used by these classes is the design detail required as a
precursor to the construction activity.
Basic Design Principles :
 The Open-Closed Principle (OCP). “A module [component] should be open for
extension but closed for modification.(if it is extended there are no internal
modifications performed to the components)
 The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their
base classes.
 Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on
concretions.” (The higher level modules and lower level modules must abstraction
dependent i.e the modules of higher level should not rely on the modules of lower level.)
 The Interface Segregation Principle (ISP). “Many client-specific interfaces are better
than one general purpose interface.(the dependency relation ship that exists between
the classes must rely on the smallest possible interface)
 The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule
of release.” (The components released by a monitoring system are the one’s that have
the capability of being reused efficiently)
 The Common Closure Principle (CCP). “Classes that change together belong together.”
(changes made to one class result in changing all the other classes)
 The Common Reuse Principle (CRP). “Classes that aren’t reused together should not
be grouped together.” (if a class defined in a package is reused then all the other classes
within the same package must also be reused.

8. Conducting Component Level Design

Component level design refers to the process of breaking down a system into its constituent
parts to better understand how they interact and connect. In software engineering, it is the phase
that focuses on defining and developing the software components that will be used to build the
overall system architecture.
1. Identify Design Classes: Recognize the core classes responsible for specific
functionalities in your software system.
2. Recognize Infrastructure Classes: These handle cross-cutting concerns like logging,
security, and database access.
3. Elaborate on Non-Reusable Design Classes: Document details of project-specific
classes.
4. Consider Reusability and Modularity: Break down the system into smaller, reusable
components.
5. Design Interfaces and Collaborations: Define how classes communicate and share
information.
6. Review and Refine: Iterate, seek feedback, and improve your design.
 9. Performing User Interface Design: Golden Rules
8 Golden Rules of User Interface Design proposed by Ben Schneiderman:
1. Strive for consistency:
 Use consistent design patterns, colors, typography, and terminology.
 Consistency helps users complete tasks more easily.
2. Enable frequent users to use shortcuts:
 Implement shortcuts like abbreviations, function keys, and hidden commands.
 Enhances efficiency for expert users who perform tasks frequently.
3. Offer informative feedback:
 Provide feedback for every user action, varying in intensity based on the action's
significance.
 Visual changes in the interface inform users about the outcomes of their actions.
4. Design dialogs to yield closure:
 Organize actions into logical groups with a clear beginning, middle, and end.
 Feedback at the end of each action group provides users with a sense of accomplishment
and prepares them for the next steps.
5. Offer simple error handling:
 Design interfaces to prevent errors where possible.
 When errors occur, provide clear notifications and hints to assist users in resolving
issues effectively.
6. Permit easy reversal of actions:
 Allow users to undo actions easily, reducing anxiety and encouraging exploration.
 Supports reversibility at different levels, from single actions to entire tasks.
7. Keep users in control:
 Ensure users feel in charge of the interface.
 Avoid unexpected changes in behavior and minimize tedious tasks to enhance user
satisfaction.
8. Reduce short-term memory load:
 Design interfaces that minimize the need for users to remember information.
 Keep relevant information visible and avoid forcing users to recall details across
different screens or tasks.
These principles aim to create user-friendly interfaces that promote productivity, mastery, and
user satisfaction by simplifying interactions and minimizing cognitive load. They provide a
foundation for designing intuitive, predictable, and forgiving interfaces across various
platforms.
 UNIT – 4
1. A Strategic approach to Software Testing
A testing strategy defines software quality assurance approaches based on project goals. The
strategy is a key planning tool, as it allows you to determine what specific actions should be
taken and at what time.
Software testing strategies ensure the transparency of development for all project participants,
giving an understanding of how testing affects product quality. A strategic vision of quality
assurance brings many benefits, not only to the product, but also to its development process.
Due to the testing strategy, you can succeed in improving development, mitigating risks, and
reducing costs.

2. Testing Strategies for conventional software

1. Unit Testing:
The unit test focuses on the internal processing logic and data structures within the boundaries
of a component. This type of testing can be conducted in parallel for multiple components.
2. Integration Testing:
Integration testing is the second level of the software testing process comes after unit testing.
In this testing, units or individual components of the software are tested in a group. The focus
of the integration testing level is to expose defects at the time of interaction between integrated
components or units.

Once all the components or modules are working independently, then we need to check the
data flow between the dependent modules is known as integration testing.
3. Validation Testing:
Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System
Testing (ST), and non-functional testing includes User acceptance testing (UAT).
Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business needs
of the client.
4. System Testing:
To check the end-to-end flow of an application or the software as a user is known as System
testing. In this, we navigate (go through) all the necessary modules of an application and check
if the end features or the end business works fine, and test the product as a whole system.
It is end-to-end testing where the testing environment is similar to the production
environment.
3. Black – Box & White Box Testing
 4. Software Quality
Software Quality shows how good and reliable a product is. To convey an associate degree
example, think about functionally correct software. It performs all functions as laid out in
the SRS document. But, it has an associate degree virtually unusable program. even though it
should be functionally correct, we tend not to think about it to be a high-quality product.

5. Metrics for Analysis Model – function based metrics

Function-based metrics in software engineering are crucial for assessing the characteristics and
complexity of software functions or methods. These metrics help in understanding the size,
complexity, and maintainability of individual functions, which are fundamental units of
software development. Here are some key function-based metrics commonly used for analysis:
1. Lines of Code (LOC):
 Measures the number of executable lines in a function.
 Provides a basic measure of the size of a function.
 Example: int calculateSum(int a, int b) { return a + b; } has 1 line of code.
2. Cyclomatic Complexity (CC):
 Measures the complexity of a function based on the number of linearly independent
paths through its control flow.
 Helps identify the number of decision points and potential paths.
 Example: A function with multiple if statements or loops would have higher cyclomatic
complexity.
3. Halstead Metrics:
 Based on the number of operators and operands in a function.
 Measures program size and complexity.
 Includes metrics such as program length (N), vocabulary size (n), program volume (V),
and difficulty (D).
4. Depth of Inheritance Tree (DIT):
 Measures how deep a function is within the inheritance hierarchy.
 Helps assess the potential complexity and dependency of a function on inherited
methods and properties.
5. Number of Parameters:
 Counts the number of parameters accepted by a function.
 Affects readability, complexity, and potential for errors.
 Example: void processData(int x, int y) has 2 parameters.
6. Number of Local Variables:
 Counts the number of variables declared locally within a function.
 Indicates the complexity and potential scope of a function.
 Example: void processArray(int[] array) may declare a local variable int sum = 0;.

6. Metrics for Design Model – Object Oriented metrics

Metrics for object-oriented design models in software engineering help assess various aspects
of the design's quality, complexity, and maintainability. Here are some commonly used metrics:
1. Number of Classes (NOC):
 Total number of classes in the design.
 Indicates the size of the system.
2. Depth of Inheritance Tree (DIT):
 Maximum depth of inheritance for classes.
 Shows the complexity due to inheritance.
3. Coupling Between Objects (CBO):
 Number of classes directly coupled to a class.
 Measures dependencies which affect maintainability.
4. Response for a Class (RFC):
 Number of methods that can be executed in response to a message.
 Indicates class complexity and interactions.
5. Weighted Methods per Class (WMC):
 Sum of complexities (e.g., cyclomatic complexities) of all methods in a class.
 Measures overall class complexity.
 These metrics help assess design complexity, maintainability, and potential issues in
object-oriented software systems.
 7.Class Oriented Metrics
Class-oriented metrics in software engineering focus specifically on assessing individual
classes within an object-oriented design. Here are some important class-oriented metrics:
1. Weighted Methods per Class (WMC):

 Measures the complexity of a class by summing the complexities of its methods.

 Indicates potential maintenance effort and class complexity.
2. Depth of Inheritance Tree (DIT):

 Measures the depth of a class within the inheritance hierarchy.

 Indicates the level of inheritance and potential complexity.
3. Coupling Between Objects (CBO):

 Counts how many other classes a class is coupled to.

 Measures dependencies, affecting class cohesion and maintainability.
4. Response for a Class (RFC):

 Counts the number of methods that can be invoked in response to a message to

the class.

 Indicates class complexity and interactions.

5. Lack of Cohesion in Methods (LCOM):
 Measures the lack of cohesion among a class's methods.
 Indicates whether methods are properly grouped.
These metrics help evaluate individual class complexity, maintainability, and potential design
issues in object-oriented software systems.

8.Component Design Metrics

Component design metrics in software engineering focus on assessing the quality,

complexity, and maintainability of software components. Here are some important
metrics:
1. Component Cohesion Metrics:
o Lack of Cohesion in Methods (LCOM):
 Measures the lack of cohesion among methods within a component.
 Indicates whether methods are properly grouped within the component.
2. Component Coupling Metrics:
o Coupling Between Objects (CBO):
 Measures the number of other components or classes a component is
coupled to.
 Indicates dependencies and potential impacts on maintenance and
flexibility.
3. Component Size Metrics:
 o Lines of Code (LOC):
 Counts the number of lines of code within a component.
 Provides a basic measure of the size of the component.
4. Component Complexity Metrics:
o Cyclomatic Complexity:
 Measures the complexity of the component's control flow.
 Indicates the number of independent paths through the component's
code.
5. Component Interface Metrics:
o Number of Parameters (NOP):
 Counts the number of parameters in the methods or functions of the
component.
 Indicates the complexity and potential coupling through method
signatures.
6. Component Cohesion at Method Level (CAM):
o Measures the degree to which methods within a component are related to each
other.
o Provides insight into the method grouping and cohesion within the component.
These metrics help software engineers evaluate the design, complexity, and potential
maintenance challenges of software components. They are crucial for ensuring that
components are well-structured, maintainable, and scalable in large software systems.

9. Metrics for Source code

Metrics for source code provide insights into various aspects of code quality, complexity,
maintainability, and potential issues. Here are some important metrics commonly used in
software engineering:
1. Lines of Code (LOC):

 Total number of executable lines in the source code files.

 Basic measure of code size.
2. Cyclomatic Complexity (CC):
 Measures the complexity of code by counting the number of independent paths
through it.
 Indicates potential bugs and maintainability challenges.
3. Code Duplication:
 Measures the amount of duplicated code within the codebase.
 Highlights areas for refactoring and potential maintenance issues.
4. Code Coverage:

 Percentage of code lines executed by automated tests.

 Indicates the reliability of testing efforts.
 5. Maintainability Index:
 Composite metric assessing code maintainability based on factors like size,
complexity, and duplication.
 Provides a single score indicating ease of maintenance.
These metrics help assess code quality, complexity, and potential maintenance challenges in
software projects.

10. Metrics for Maintenance

Metrics for maintenance in software engineering help assess the effort, quality, and efficiency
of maintaining software systems over time. Here are important metrics used for maintenance:
1. Mean Time to Repair (MTTR):
o Measures the average time taken to fix a defect or failure in the software.
2. Mean Time Between Failures (MTBF):
o Indicates the average time interval between two consecutive failures of the
software.
3. Percentage of Corrective vs. Adaptive/Perfective Maintenance:
o Ratio of time or effort spent on fixing defects versus enhancing or adapting the
software.
4. Change Request Backlog:
o Tracks the number or size of pending change requests awaiting implementation.
5. Customer Satisfaction:
o Feedback and ratings from users regarding software maintenance and support.
6. Defect Density:
o Number of defects identified per lines of code or function points.
7. Maintenance Cost:
o Total expenditure incurred for maintaining and supporting the software over a
period.
These metrics help organizations gauge the efficiency, quality, and cost-effectiveness of their
software maintenance efforts.
 UNIT – 5
1. Reactive vs. Proactive Risk Strategies
Reactive Risk Strategy Proactive Risk Strategy
 The reactive risk strategy involves  The proactive risk strategy focuses on
addressing risks after they occur or as identifying and addressing potential
they become apparent during the risks before they occur.
project execution.
 Risks are identified and managed as  Risks are anticipated and analysed
they materialize, causing the project during the project planning phase,
team to respond to unexpected and plans are put in place to mitigate
events. or avoid them.
 This strategy might involve creating  This strategy involves actively
contingency plans or making seeking out potential risks, assessing
adjustments to project plans in their impact and likelihood, and
response to identified risks. taking steps to minimize their impact
or prevent them from occurring.
 Reactive risk management can lead to  Proactive risk management can lead
higher levels of uncertainty, stress, to better risk awareness, more
and potential negative impacts on effective planning, and a higher
project outcomes. likelihood of project success.
 While it's not possible to eliminate all  The emphasis is on reducing the
risks, reactive strategies focus on overall risk exposure by addressing
dealing with risks as they arise rather risks before they become major
than preventing them in advance. issues.

2. Software Risks

3. Risk identification
Risk Identification: The project organizer needs to anticipate the risk in the project as early as
possible so that the impact of risk can be reduced by making effective risk management
planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might
affect a project. It is necessary to categories into the different risk of classes.

4. Risk Projection
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the
likelihood or probability that the risk is real and the consequences of the problems associated
with the risk, should it occur.
The project planner, along with other managers and technical staff, performs four risk
projection activities:
(1) Establish a scale that reflects the perceived likelihood of a risk.
(2) Delineate the consequences of the risk.
(3) Estimate the impact of the risk on the project and the product.
(4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

5. Risk Refinement
Risk refinement in software engineering involves continuously assessing, analysing, and
updating identified risks throughout the project lifecycle. This iterative process includes initial
risk identification, thorough analysis of impact and likelihood, development of mitigation
strategies, ongoing monitoring, and updating risk assessments based on evolving project
conditions. Effective communication and integration with project management processes
ensure proactive risk management and support project success.

6. RMMM Plan
A risk management technique is usually seen in the software Project plan. This can be divided
into Risk Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are
done as part of risk analysis. As part of the overall project plan project manager generally uses
this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information Sheet (RIS).
This RIS is controlled by using a database system for easier management of information i.e
creation, priority ordering, searching, and other analysis. After documentation of RMMM and
start of a project, risk mitigation and monitoring steps will start.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
 Finding out the risk.
 Removing causes that are the reason for risk creation.
 Controlling the corresponding documents from time to time.
  Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

 To check if predicted risks occur or not.

 To ensure proper application of risk aversion steps defined for risk.
 To collect data for future risk analysis.
 To allocate what problems are caused by which risks throughout the project.
Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project
manager when risk becomes reality and causes severe problems. If the project manager
effectively uses project mitigation to remove risks successfully then it is easier to manage the
risks. This shows that the response that will be taken for each risk by a manager. The main
objective of the risk management plan is the risk register. This risk register describes and
focuses on the predicted threats to a software project.

7. Quality Management: Quality Concepts

Software Quality Management System contains the methods that are used by the authorities to
develop products having the desired quality.
Some of the methods are:
 Managerial Structure: Quality System is responsible for managing the structure as a
whole. Every Organization has a managerial structure.
 Individual Responsibilities: Each individual present in the organization must have
some responsibilities that should be reviewed by the top management and each
individual present in the system must take this seriously.
 Quality System Activities: The activities which each quality system must have been
o Project Auditing.
o Review of the quality system.
o It helps in the development of methods and guidelines.

8. Metrics for Software Quality

Software metrics can be classified into three categories −
 Product metrics − Describes the characteristics of the product such as size,
complexity, design features, performance, and quality level.
 Process metrics − These characteristics can be used to improve the development and
maintenance activities of the software.
 Project metrics − This metrics describe the project characteristics and execution.
Examples include the number of software developers, the staffing pattern over the life
cycle of the software, cost, schedule, and productivity.
 9. Software Reviews
Software Review is a systematic inspection of software by one or more individuals who
work together to find and resolve errors and defects in the software during the early stages of
the Software Development Life Cycle (SDLC). A software review is an essential part of the
Software Development Life Cycle (SDLC) that helps software engineers in validating the
quality, functionality, and other vital features and components of the software. It is a whole
process that includes testing the software product and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, software review is used to verify various documents like
requirements, system designs, codes, test plans, and test cases.

10. Formal Technical Reviews

Formal Technical Review (FTR) is a software quality control activity performed by software
engineers. It is an organized, methodical procedure for assessing and raising the standard of
any technical paper, including software objects. Finding flaws, making sure standards are
followed, and improving the product or document under review’s overall quality are the main
objectives of a formal technical review (FTR). Although FTRs are frequently utilized in
software development, other technical fields can also employ the concept.
The Review Meeting
Each review meeting should be held considering the following constraints- Involvement of
people:
1. Between 3, 4, and 5 people should be involved in the review.
2. preparation should occur, but it should be very short that is at the most 2 hours of work
for every person.
3. The short duration of the review meeting should be less than two hours. Given these
constraints, it should be clear that an FTR focuses on specific (and small) parts of the
overall software.
At the end of the review, all attendees of FTR must decide what to do.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app needs to be
reviewed), or
3. Accept the product provisional (minor errors are encountered and should be corrected,
but no additional review will be required).
Review reporting and record-keeping:
1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is
prepared.
 3. Finally, a formal technical review summary report is prepared.
A review summary report answers three questions:
1. What was reviewed?
2. Who reviewed it?
3. What were the findings and conclusions?
Review Guidelines:
 Establish Clear Guidelines: Define and distribute review guidelines in advance for
consistency.
 Focus on the Product: Keep discussions objective and focused on improving the
software, not on personal critiques.
 Set and Stick to an Agenda: Maintain a structured agenda to stay on track and respect
time constraints.
 Limit Debate: Avoid prolonged debates during the meeting; note issues for offline
discussion if necessary.
 Identify Problem Areas: Clearly articulate identified issues without necessarily
solving them on the spot.
 Take Written Notes: Record decisions, actions, and key points to ensure clarity and
accountability.
 Keep Review Teams Small and Prepared: Limit participants to essential team
members and ensure thorough preparation.
 Use Checklists: Develop and use checklists tailored to different types of software
artifacts (e.g., requirements, design, code).
 Allocate Time and Resources: Dedicate sufficient resources and schedule time for
effective reviews.
 Provide Training: Conduct training to ensure all participants understand their roles and
the review process.
 Learn from Past Reviews: Continuously improve by reviewing and adapting based on
previous review experiences.

11. Software Reliability

Software reliability is the probability that the software will operate failure-free for a specific
period of time in a specific environment. It is measured per some unit of time.
 Software Reliability starts with many faults in the system when first created.
 After testing and debugging enter a useful life cycle.
 Useful life includes upgrades made to the system which bring about new faults.
 The system needs to then be tested to reduce faults.
 Software reliability cannot be predicted from any physical basis, since it depends
completely on the human factors in design.
 12. The ISO 9000 Quality standards
The ISO 9000 series of standards is a set of international standards that focus on quality
management systems (QMS). Here are the key points about ISO 9000 quality standards:
1. Definition and Scope:
 ISO 9000 standards provide guidelines and requirements for organizations to
implement and maintain effective quality management systems.
 They are applicable to any organization, regardless of size, industry, or sector.
2. Core Principles:
 Customer focus: Understanding and meeting customer requirements.
 Leadership: Establishing unity of purpose and direction.
 Engagement of people: Involving all employees in achieving the organization's
objectives.
 Process approach: Managing activities as processes to achieve desired
outcomes.
 Improvement: Continuously improving overall performance.
 Evidence-based decision making: Using data and information to make informed
decisions.
 Relationship management: Managing relationships with interested parties.
3. Structure of ISO 9000 Standards:
 ISO 9001: Specifies the requirements for a QMS that an organization must demonstrate
to be certified as compliant. It covers areas such as management responsibility, resource
management, product realization, and measurement, analysis, and improvement.
 ISO 9000: Provides an overview of the concepts, principles, and vocabulary used in the
ISO 9000 series.
 ISO 9004: Offers guidelines for enhancing the performance of an organization beyond
the requirements of ISO 9001, focusing on continual improvement and sustained
success