CS23631 Object Oriented Software Engineering

I Basics of software engineering: Definition, scope and evolution

Definition

Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.
Software engineering encompasses a process, methods for managing and engineering software,
and tools.

Software engineering is the It involves using programming languages, frameworks, and tools to
create reliable and efficient software systems. Software engineers work to solve real-world
problems by building software that meets user needs and performs well. This field ensure
quality through structured processes like planning, analysis, coding , and debugging. As
technology advances, software engineering plays a crucial role in industries such as healthcare,
education, finance, and entertainment. It combines creativity, logic, and precision to create
innovative digital solutions.

The scope is vast and expanding rapidly. India is a global IT hub with numerous opportunities in
software development, testing, maintenance, and research. Emerging technologies like AI, cloud
computing, and cybersecurity further widen career options.

The Evolving Role of Software:

Software can be considered in a dual role. It is a product and, a vehicle for delivering a product.
As a product, it delivers the computing potential in material form of computer hardware.
Example
A network of computers accessible by local hardware, whether it resides within a cellular phone
or operates inside a mainframe computer.
i) As the vehicle, used to deliver the product. Software delivers the most important product of
our time- Information.
ii) Software transforms personal data, it manages business information to enhance
competitiveness, it provides a gateway to worldwide information networks (e.g., Internet) and
provides the means for acquiring information in all of its forms.
iii) Software acts as the basis for operating systems, networks, software tools and environments

Fig 1 shows the evolution of software engineering.

 Fig 1 Evolution of software engineering

Software Characteristics

Software is a logical rather than a physical system element. Therefore, software has
characteristics that are considerably different than those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware manufacture, the
two activities are fundamentally different.
In both activities, high quality is achieved through good design, but the manufacturing phase for
hardware can introduce quality problems that are non-existent (or easily corrected) for
software.
2. Software doesn't "wear out."

Fig 2 Failure curve for hardware

Fig 2 depicts failure rate as a function of time for hardware.

The relationship, often called the "bathtub curve", indicates that hardware exhibits relatively
high failure rates early in its life (these failures are often attributable to design or manufacturing
defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite
low) for some period of time.

As time passes, however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature extremes, and many other
environmental maladies. Stated simply, the hardware begins to wear out.

Fig 3 Idealized and actual failure curves for software

The failure rate curve for software should take the form of the ―idealized curve ‖ shown in Fig 3.
Undiscovered defects will cause high failure rates early in the life of a program. However, these
are corrected (ideally, without introducing other errors) and the curve flattens as
shown. The idealized curve is a gross oversimplification of actual failure models the implication
is clear— software doesn't wear out. During its life, software will undergo change
(maintenance). As changes are made, it is likely that some new defects will be introduced,
causing the failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the
original steady-state failure rate, another change is requested, causing the curve to spike again.
Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to
change.

3. Although the industry is moving toward component-based assembly, most software

Continues to be custom built. Software component should be designed and implemented so that
it can be reused in many different programs. For example, today's graphical user interfaces are
built using reusable components that enable the creation of graphics windows, pull-down
menus, and a wide variety of interaction mechanisms. The data structure and processing detail
required to build the interface are contained with a library
.
Software Application Domains
The following categories of computer software present continuing challenges for software
engineers.
a) System software:
System software is a collection of programs written to service other programs.
Example: compilers, editors, and file management utilities, operating system components,
drivers, telecommunications processors, process largely indeterminate data.
b) Real-time software:
Elements of real-time software includes a data gathering component that collects and formats
information from an external environment an analysis component that transforms information
as required by the application a control/output component that responds to the external
environment a monitoring component that coordinates all other components so that real-time
response (typically ranging from 1 millisecond to 1 second) can be maintained.
c) Business software:
Business information processing is the largest single software application area.
Example: payroll, accounts receivable/payable, inventory. Applications in this area restructure
existing data in a way that facilitates business operations or management decision making. In
addition to conventional data processing application, business
software applications also encompass interactive computing.
Example: point of-sale transaction processing.
d) Engineering and scientific software:
This is the software using ―number crunching" algorithms. Example: System simulation,
computer-aided design.
e) Embedded software:
Embedded software resides in read-only memory and is used to control products and systems
for the consumer and industrial markets.
Example: keypad control for a microwave oven. It provides significant function and control
capability
Example: Digital functions in an automobile such as fuel control, dashboard displays, and
braking
systems.
f) Personal computer software:
Word processing, spreadsheets, computer graphics, multimedia, entertainment, database
management, personal and business financial applications, external network, and database
access
are only a few of hundreds of applications.
g) Web-based software:
The Web pages retrieved by a browser are software that incorporates executable instructions
(Ex: CGI, HTML, Perl, or Java), and data (EX: hypertext and a variety of visual and audio formats).
Expert systems, also called knowledgebase systems, pattern recognition (image and voice),
artificial neural networks, theorem proving, and game playing are representative of applications
within this category

In order to build software that is ready to meet the challenges and it must recognize a few
simple realities:
• It follows that a concerted effort should be made to understand the problem
before a software solution is developed.
• It follows that design becomes a pivotal activity.
• It follows that software should exhibit high quality.
• It follows that software should be maintainable.
•
These simple realities lead to one conclusion: software in all of its forms and across all of its
application domains should be engineered.

Software Engineering: A Layered Technology

Software engineering is a layered technology as shown in below Fig 4..

 Figure4 Layered Technology

The foundation for software engineering is the process layer. The software engineering process
is the glue that holds the technology layers together and enables rational and timely
development of computer software. Process defines a framework that must be established for
effective delivery of software engineering technology.

Software process:
The software process forms the basis for management control of software projects and
establishes the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.
Software engineering methods:
Software engineering methods provide the technical how-to‘s for building software. Software
engineering methods rely on a set of basic principles that govern each area of the
technology and include modelling activities and other descriptive techniques.

Software engineering tools:

Software engineering tools provide automated or semi-automated support for the process and
the methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established.

II Overview of Object-Oriented Concepts- Classes, Objects, encapsulation,

inheritance, polymorphism

Object-Oriented Programming (OOP) Concepts:

Object-Oriented Programming (OOP) is a programming paradigm that models real-world

entities as "objects," combining data and functions into a single unit. OOPS programs are based
on objects rather than functions and logic. C++ is one of the most well-known programming
languages that support OOPs, with robust features to implement this paradigm efficiently.

Object-oriented programming is a popular programming method used in software development.

Its main building blocks are classes and objects. Classes are the blueprints that define attributes
(data) and methods (functions or actions that need to be performed on the data). Objects are
instances of classes but can have different attributes and use the same methods from classes.

However, classes and objects alone will not help a program run as the developer desires. To
make this happen, we need to understand and apply the core principles to execute different
functionalities and ensure a program in an OOP language works according to project
requirements. The 4 core principles of OOP are:

Polymorphism
Encapsulation
Inheritance
Abstraction

These 4 principles make it easier to create flexible and scalable software solutions in object-
oriented programming

The core concepts of OOP are:

 Class
 Object
 Inheritance
 Encapsulation
 Abstraction
 Polymorphism
 Message passing and
 Dynamic Binding

Class
A class is a user-defined data type. It is a blueprint that defines the structure and behavior of its
objects, ensuring abstraction and modularity. It encapsulates data members (data members i.e.
variables or attributes) and member functions (methods or member functions) in a single unit.

Class in Java
To create (declare) a class, you need to use access modifiers followed by class keyword and
class_name.

// Creating a Java class

class Dog {
// Declaring and initializing the attributes
String breed;
int age;
String color;

// methods to set breed, age, and color of the dog

public void setBreed(String breed) {
[Link] = breed;
}
public void setAge(int age) {
[Link] = age;
}
public void setColor(String color) {
[Link] = color;
}

// method to print all three values

 public void printDetails() {
[Link]("Dog detials:");
[Link]([Link]);
[Link]([Link]);
[Link]([Link]);
}
}

public class Main {

public static void main(String[] args) {
// Creating an object of the class Dog
Dog obj = new Dog();

// setting the attributes

[Link]("Golden Retriever");
[Link](2);
[Link]("Golden");

// Printing values
[Link]();
}
}

Object

An object is an instance of a class, it specifies data members and member functions of that
object. Real-world entities are modeled using objects, which encapsulate data and functions.
For example, if you have a class Student, objects like s1 and s2 represent specific students with
their own skills, such as subject expertise, sports achievements, star performers, etc.

Encapsulation

Encapsulation binds the data members and member functions that operate on the data together
in one class. Data security and modularity as well as data integrity can be achieved by defining
access specifiers such as private, protected, and public control the visibility of these members
with OOP concept encapsulation. It gives the developer control over which parts of the class are
exposed and accessible.

Encapsulation is one of the four fundamental OOP concepts. The other three are inheritance,
polymorphism, and abstraction. Encapsulation in Java is a mechanism of wrapping the data
(variables) and code acting on the data (methods) together as a single unit. In encapsulation, the
variables of a class will be hidden from other classes, and can be accessed only through the
methods of their current class. Therefore, it is also known as data hiding. To achieve
encapsulation in Java −
 Declare the variables of a class as private.
 Provide public setter and getter methods to modify and view the variables values.

* File name : [Link] */

public class EncapTest {
private String name;
private String idNum;
private int age;

public int getAge() {

return age;
 }

public String getName() {

return name;
}

public String getIdNum() {

return idNum;
}

public void setAge( int newAge) {

age = newAge;
}

public void setName(String newName) {

name = newName;
}

public void setIdNum( String newId) {

idNum = newId;
}
}

/* File name : [Link] */

public class RunEncap {

public static void main(String args[]) {

EncapTest encap = new EncapTest();
[Link]("James");
[Link](20);
[Link]("12343ms");

[Link]("Name : " + [Link]() + " Age : " + [Link]());

}
}

public class EncapTest {

private String name;
private String idNum;
private int age;

public int getAge() {

return age;
}

public String getName() {

return name;
}

public String getIdNum() {

return idNum;
}

public void setAge( int newAge) {

age = newAge;
}
 public void setName(String newName) {
name = newName;
}

public void setIdNum( String newId) {

idNum = newId;
}
}

Output: Name: James Age: 20

Benefits of Encapsulation

• The fields of a class can be made read-only or write-only.

• A class can have total control over what is stored in its fields.

Inheritance

Inheritance is the programming design mechanism that allows one class (child class) to inherit
the properties and behavior of another class (parent/superclass). This helps your code become
reusable and makes your application more scalable. It essentially provides a workaround for
writing the same code over and over again for different classes.

Let’s say, for example, you have specific classes like bike, car, truck, etc. These classes would have
similar functionality and methods that you may want to call. You can create a parent class called
vehicle to hold these methods, such as openTrunk() for a car or loadCargo() for trucks, etc.,
instead of rewriting the code for each class.

Real-Life Examples of Inheritance

Let’s explore some real-life examples of inheritance in OOP, which is the best way to learn any
programming concept.

Family Tree Example

Think of a family tree where:

Grandparent has certain traits (e.g., eye color, blood type)

Parent inherits those traits and add some of their own
A child inherits from their parents and can still access their grandparents’ traits

In OOP terms:

Grandparent is the base class

Parent is the intermediate subclass
Child is a derived subclass that inherits all features up the chain

This is an example of multilevel inheritance.

UI Components Example

In GUI libraries or frontend frameworks:

A base class like Component defines core behavior like rendering or updating the screen.
Specialized classes like Button, Checkbox, or Dropdown inherit from Component and add
specific behavior. This real-world use of inheritance helps maintain a consistent interface and
behavior across all UI elements.

Types of Inheritance in OOP

The inheritance types in OOP are based on the relationship between the parent and child
classes.

1. Single Inheritance

In single inheritance, the child class only has access to the methods and behaviour of one parent
class.

Inheritance in Java

In Java, you use the extends keyword to inherit from a class.

// Base class
class Animal {
void eat() {
[Link]("This animal eats food.");
}
}

// Derived class
class Dog extends Animal {
void bark() {
[Link]("The dog barks.");
}
}

// Main class to test the behavior

public class Main {
public static void main(String[] args) {
Dog dog = new Dog();

// Call inherited and specific methods

[Link](); // Inherited from Animal
[Link](); // Defined in Dog
}
}

Java supports single, multilevel, and hierarchical inheritance. Multiple inheritance is not
supported with classes; interfaces are used for that purpose.

Different Types of Inheritance

OOP supports six different types of inheritance, as given below:
 1. Single Inheritance
2. Multi-level Inheritance
3. Multiple Inheritance
4. Multipath Inheritance
5. Hierarchical Inheritance
6. Hybrid Inheritance

Table 1 Summary of Types of Inheritance in OOP

Type Description Supported In

Single One class inherits from another All OOP languages

Multiple One class inherits from multiple classes Python, C++

Multilevel Chain of inheritance All OOP languages

Hierarchical One base class, many child classes All OOP languages

Hybrid Combination of multiple types of inheritance Python, C++

The Table1 shows the summary of the various types of inheritances.

Polymorphism

Polymorphism is one of the core concepts of object-oriented programming (OOP) that describes
situations in which something occurs in several different forms. In computer science,
polymorphism describes the concept that you can access objects of different types through the
same interface. Each type can provide its own independent implementation of this interface.

Different Types of Polymorphism

Java supports 2 types of polymorphism:

[Link] or compile-time

[Link]

Static Polymorphism

Like many other OOP languages, Java allows you to implement multiple methods within the
same class that use the same name. But Java uses a different set of parameters called method
overloading and represents a static form of polymorphism.

The parameter sets have to differ in at least one of the following three criteria:

-They need to have a different number of parameters, one method accepting 2 and another one
accepting 3 parameters

-The types of parameters need to be different, with one method accepting a String and another
one accepting a Long
-They need to expect the parameters in a different order. For example, one method accepts a
String and a Long, and another one accepts a Long and a String. This kind of overloading is not
advisable because it makes the API difficult to understand

In most cases, these overloaded methods provide a different but very similar functionality. Like
many other OOP languages, Java allows you to implement multiple methods within the same
class that use the same name.

Example for static polymorphism:

public class BasicCoffeeMachine {

// ...

public Coffee brewCoffee(CoffeeSelection selection) throws CoffeeException {

switch (selection) {

case FILTER_COFFEE:

return brewFilterCoffee();

default:

throw new CoffeeException(

"CoffeeSelection ["+selection+"] not supported!");

public List brewCoffee(CoffeeSelection selection, int number) throws CoffeeException {

List coffees = new ArrayList(number);

for (int i=0; i<number; i++) {

[Link](brewCoffee(selection));

return coffees;

// ...

When you call one of these methods, the provided set of parameters identifies the method which
has to be called. In the following code snippet, we’ll call the method only with a CoffeeSelection
object. At compile time, the Java compiler binds this method call to the

brewCoffee(CoffeeSelection selection) method.

BasicCoffeeMachine coffeeMachine = createCoffeeMachine();
[Link](CoffeeSelection.FILTER_COFFEE);
If we change this code and call the brewCoffee method with a CoffeeSelection object and an int,
the compiler binds the method call to the other brewCofe(CoffeeSelection selection, int number)
method.

BasicCoffeeMachine coffeeMachine = createCoffeeMachine();

List coffees = [Link]([Link], 2);

Dynamic Polymorphism

This form of polymorphism doesn’t allow the compiler to determine the executed method. The
JVM needs to do that at runtime. Within an inheritance hierarchy, a subclass can override a
method of its superclass, enabling the developer of the subclass to customize or completely
replace the behaviour of that method. The example is show in Fig 5.

Fig 5 Example for polymorphism

Doing so also creates a form of polymorphism. Both methods implemented by the super- and
subclasses share the same name and parameters. However, they provide different functionality.

III Procedural Vs Object-Oriented Paradigms

Table 2 and Table 3 shows the comparison and differences between procedures and
object oriented programming paradigms

Table 2 Comparison of Procedural and Object oriented programming

 Table 3 Procedural oriented Vs Object -oriented programming

Below are some of the differences between procedural and object-oriented programming:

Procedural Oriented Programming Object-Oriented Programming

In object-oriented programming, the

In procedural programming, the program is
program is divided into small parts
divided into small parts called functions.
called objects.

Procedural programming follows a top-down Object-oriented programming follows

approach. a bottom-up approach.

There is no access specifier in procedural Object-oriented programming has access

programming. specifiers like private, public, protected, etc.

Adding new data and functions is not easy. Adding new data and function is easy.

Procedural programming does not have any Object-oriented programming provides data
proper way of hiding data so it is less secure. hiding so it is more secure.

In procedural programming, overloading is Overloading is possible in object-oriented

not possible. programming.

In procedural programming, there is no In object-oriented programming, the concept

concept of data hiding and inheritance. of data hiding and inheritance is used.

In procedural programming, the function is In object-oriented programming, data is

more important than the data. more important than function.

Procedural programming is based on Object-oriented programming is based on

the unreal world. the real world.

Procedural programming is used for designing Object-oriented programming is used for

medium-sized programs. designing large and complex programs.

Procedural programming uses the concept of Object-oriented programming uses the

procedure abstraction. concept of data abstraction.

Code reusability absent in procedural Code reusability present in object-oriented

programming, programming.

Examples: C, FORTRAN, Pascal, Basic, etc. Examples: C++, Java, Python, C#, etc.
IV Software Development Life Cycle

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.
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.
The software development life cycle is shown Fig 6.

Fig 6 Software Development Life cycle

Why is SDLC Important?

Without a structured SDLC, software development becomes chaotic. Teams may miss
requirements, blow budgets, or deliver buggy code that doesn't solve the user's problem. SDLC
provides:
Visibility: Stakeholders know exactly what is happening at every stage.
Quality Control: Testing is integrated into the process, not an afterthought.
Risk Management: Potential pitfalls are identified during the planning phase.
Cost Estimation: Helps in predicting timelines and budgets accurately.
The Six Stages of the Software Development Life Cycle are shown in Fig 7

Fig 7 Stages of Software Development Life Cycle

The Software Process

A process is a collection of activities, actions, and tasks that are performed when some work
product is to be created. An activity strives to achieve a broad objective and is applied regardless
of the application domain, size of the project, complexity of the effort, or degree of rigor with
which software engineering is to be applied. An action (e.g., architectural design) encompasses a
set of tasks that produce a major work product
(e.g., an architectural design model).

A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a
tangible outcome. A process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities that are applicable to
all software projects, regardless of their size or complexity.
In addition, the process framework encompasses a set of umbrella activities that are applicable
across the entire software process. A generic process framework for software engineering
encompasses five activities:

The five generic process framework activities:

a) Communication:
The intent is to understand stakeholders‘ objectives for the project and to gather requirements
that help define software features and functions.
b) Planning:
Software project plan—defines the software engineering work by describing the technical tasks
to be conducted, the risks that are likely, the resources that will be required, the work products
to be produced, and a work schedule.
c) Modelling:
A software engineer does by creating models to better understand software requirements and
the design that will achieve those requirements.
d) Construction:
This activity combines code generation (either manual or automated) and the testing that is
required to uncover errors in the code.
e) Deployment:
Software engineering process framework activities are complemented by a number of umbrella
activity. Fig 8 and Fig 9 shows the process framework and the activities of the framework.

Fig 8 Generic Process Framework

In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk.

Typical umbrella activities include:

i) Software project tracking and control—allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.
ii) Risk management—assesses risks that may affect the outcome of the project or the quality of
the product.
iii) Software quality assurance—defines and conducts the activities required to ensure software
quality.
iv) Technical reviews—access software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
v) Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders‘ needs; can be used in conjunction with all
other framework and umbrella activities.
vi) Software configuration management—manages the effects of change throughout the
software process.
vii) Reusability management—defines criteria for work product reuse(including software
components) and establishes mechanisms to achieve reusable components.
viii) Work product preparation and production—encompasses the activities required to create
work products such as models, documents, logs, forms, and lists.
 Fig 9 Software generic process framework activities

Software Engineering Practice

A basic understanding of the generic concepts and principles that apply to framework activities
The essence of problem solving, and consequently, the essence of software engineering practice:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

Software engineering paradigm:

• The framework activities will always be applied on every project ... BUT the tasks (and
degree of rigor) for each activity will vary based on:
– the type of project
– characteristics of the project
– common sense judgment; concurrence of the project team

The software process:

• A structured set of activities required to develop a software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective.
• Systems Engineering
– Software as part of larger system, determine requirements for all system
elements, allocate requirements to software.
 • Software Requirements Analysis
– Develop understanding of problem domain, user needs, function, performance,
interfaces, ...
– Software Design
–Multi-step process to determine architecture, interfaces, data structures,
functional detail. Produces (high-level) form that can be checked for quality,
conformance before coding.
• Coding
– Produce machine readable and executable form, match HW, OS and design needs.

• Testing

– Confirm that components, subsystems and complete products meet requirements,

specifications and quality, find and fix defects.
• Maintenance
–Incrementally, evolve software to fix defects, add features, adapt to new
condition. Often 80% of effort spent here!

V Perspective and specialized process models

1. Waterfall model phases:

• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
•
The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway. One phase has to be complete before moving onto the next phase. Each
phase terminates only when the documents are complete and approved by the SQA group.
Maintenance begins when the client reports an error after having accepted the product. It could
also begin due to a change in requirements after the client has accepted the product.

Waterfall model: Advantages:

• Disciplined approach
• Careful checking by the Software Quality Assurance Group at the end of each phase.
• Testing in each phase.
• Documentation available at the end of each phase.
Waterfall model problems:
• It is difficult to respond to changing customer requirements.
• Therefore, this model is only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a
system is developed at several sites.
• The customer must have patience. A working version of the program will not be
available
until late in the project time-span
• Feedback from one phase to another might be too late and hence expensive.
 Fig 10 Waterfall Model

2. The Prototyping Models:

Often, a customer defines a set of general objectives for software but does not identify detailed
input, processing, or output requirements. In other cases, the developer may be unsure of the
efficiency of an algorithm, the adaptability of an operating system, or the form that human
machine interaction should take. In this case prototyping paradigm may offer the best approach

• Requirements gathering
• Quick design
• Prototype building
• Prototype evaluation by customers
• Prototype may be refined

Prototype thrown away and software developed using formal process. It is used to define the
requirement Prototyping
Strengths:
• Requirements can be set earlier and more reliably
• Customer sees results very quickly.
• Customer is educated in what is possible helping to refine requirements.
• Requirements can be communicated more clearly and completely
• Between developers and clients Requirements and design
options can be investigated quickly and Cheaply
Weaknesses:
–Requires a rapid prototyping tool and expertise in using it–a cost for
the development organisation
– Smoke and mirrors - looks like a working version, but it is not.

[Link] RAD Model:

• Rapid Application Development is a linear sequential software
development process model that emphasizes an extremely short
development cycle
• Rapid application achieved by using a component-based construction approach
• If requirements are well understood and project scope is constrained the RAD
process enables a development team to create a ―fully functional

• What information drives the business process?

• What information is generated?
Data Modeling:
• The information flow defined as part of the business modelling phase is
refined into a set of data objects that are needed to support the business.
• The characteristics (called attributes) of each object are identified and
the relationships between these objects are defined
Process modelling:
• The data modelling phase are transformed to achieve the information flow
necessary to implement a business function.
• Processing descriptions are created for adding, modifying, deleting, or retrieving
a data object
Application generation:
• RAD assumes the use of 4 generation techniques.
• Rather than creating software using conventional 3 generation
programming languages, the RAD process works to reuse existing program
components (when possible) or created reusable components (when
necessary)
Testing and Turnover:
• Since the RAD process emphasizes reuse, many of the program components
have already been testing.
• This reduces over all testing time.
• However, new components must be tested and all interfaces must be fully exercised

Advantages &Disadvantages of RAD:

Advantages
• Extremely short development time.
• Uses component-based construction and emphasizes reuse and code generation
Disadvantages
• Large human resource requirements (to create all of the teams).
• Requires strong commitment between developers and customers for “rapid-fire”
activities.
• High performance requirements maybe can’t be met

The Fig 11 and Fig 12 shows the RAD model and its demerits

Fig 11 RAD Model

 Fig 12 Disadvantages of RAD

4 Incremental Model

• Combination of linear + prototype

• Rather than deliver the system as a single delivery, the development and delivery is broken
down into increments with each increment delivering part of the required functionality
• User requirements are prioritised and the highest priority requirements are included
in early increments
• Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve
Incremental development advantages:
• The customer is able to do some useful work after release
• Lower risk of overall project failure
• The highest priority system services tend to receive the most testing
The phases of the incremental model is shown in Fig13.

Fig 13 Incremental Model

[Link] model sectors:
• Customer communication
Tasks required to establish effective communication between developer and
customer
• Planning
The tasks required to define recourses, timelines, and project is reviewed and
the next phase of the spiral is planned
• Risk analysis
– Risks are assessed and activities put in place to reduce the key
• Risks engineering
– Tasks required to build one or more representations of the application

• Construction & release

– Tasks required to construct, test, install and provide user support (e.g
documentation and training)
• Customer evaluation
– Customer feedback collected every stage
Spiral Model Advantages:
• Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software Development.

• Stated in a slightly more formal manner, the world view (WV) is composed of
a set of domains (Di), which can each be a system or system of systems in its
own right. WV = {D1, D2, D3, . . . , Dn}
• Each domain is composed of specific elements (Ej) each of which serves
some role in accomplishing the objective and goals of the domain or
component: Di = {E1, E2, E3, . . . , Em}
• Finally, each element is implemented by specifying the technical
components (Ck) that achieve the necessary function for an element:
Ej = {C1, C2, C3, . . . , Ck}

The spiral model is shown in Fig 14.

Fig 14 Spiral Model

6 Iterative Model

Benefits of Iterative SDLC Models

 Faster Time-to-Market: Incremental development allows for the release of functional
components at the end of each iteration, resulting in a faster time-to-market compared
to traditional SDLC models.
 Enhanced Flexibility: The ability to adapt to changing requirements makes the Iterative
models suitable for projects with evolving needs, ensuring that the final product meets
user expectations.
 Improved Quality: Continuous evaluation and testing in each iteration contribute to
higher software quality. Bugs and issues are identified and addressed early, preventing
them from accumulating in later stages.
 Increased Stakeholder Engagement: Stakeholders are involved throughout the
development process, providing valuable feedback after each iteration. This ensures that
the final product aligns with user expectations and business goals. Fig 15 shows the
iteration model.

Fig 15 Iteration Model

Introduction to Agility and Agile process

The main aim of the Agile model is to facilitate quick project completion. To accomplish this
task, 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 meaning of Agile is swift or versatile. "Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in advance.
The agile SDLC is shown in Fig 16. Fig 17 shows the phases of the Agile model.
 Fig 16 Agile SDLC

Each iteration is considered as a short time "frame" in the Agile process model, which typically
lasts from one to four weeks. The division of the entire project into smaller parts helps to
minimize the project risk and to reduce the overall project delivery time requirements. Each
iteration involves a team working through a full software development life cycle including
planning, requirements analysis, design, coding, and testing before a working product is
demonstrated to the client.

Fig 17 Phases of Agile Model

Following are the phases in the Agile model are as follows:

1. Requirements gathering
 2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to show
the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback

When to use the Agile Model?

o When frequent changes are required.

o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time
Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different team
members.
2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.
The difference between SDLC and Agile model is shown in Fig 18.

Fig 18 SDLC Vs Agile model

Fig 19 Comparison of Traditional and Agile approach

Fig 19 shows the comparison of traditional and agile model.

Comparison of all SDLC models is shown in Table 4

Table 4 Comparison of all SDLC models

Increment
Aspect Waterfall Iterative Spiral Agile V-Models al

Develop
ment Sequential Iterative Iterative Iterative Iterative Iterative
Approach

Planning,
Design, Planning Divided
Planning, Planning,
Coding, , Risk into
Sprint, Design,
Testing, Analysis, increments,
Review, Implement
Evaluatio Engineer each with
Linear Retrospe ation,
n ing, Planning,
ctive Testing,
(Repeate Testing Implementa
(Iterative Deploymen
d (Cyclical tion,
Cycles) t (Parallel)
Iterativel ) Testing
Phases y)

Flexibilit
Low High High High Moderate High
y

Continuo
Proactive Continuo Risk Proactive
us risk
Late risk us risk manageme risk
assessm
mitigation, managem assessme nt aligned manageme
ent,
Limited ent, nt, with nt,
Proactiv
adaptabilit Adaptabil Adaptabil phases, Adaptabilit
Risk e
y ity to ity to Moderate y to
Managem mitigatio
changes changes adaptability changes
ent n

Time-to-
Longer Faster Variable Faster Moderate Faster
Market

User Limited Continuo Periodic Continuo Periodic Continuous

Involvem
 Increment
Aspect Waterfall Iterative Spiral Agile V-Models al

ent us us

Continuo Integrate
After us d After Continuous
Continuo
Implement througho through Implement throughout
us and c
ation ut out the ation increments
Testing iterations spiral

Adaptabi
Low High High High Moderate High
lity

Linear Easier to
Adaptive
Complexi approach, manage, Cyclical Traceability Adaptive
approach
ty Limited Adaptabil approac helps approach to
to
Managem adaptabilit ity to h, Risk-d manage c changes
changes
ent y changes

Benefits of Object-Oriented Software Engineering

1. Modular design: OOP encourages dividing complicated systems into reusable parts (obj
ects).

2. Code reusability: OOP enables reusing code, improving efficiency.

3. Simpler debugging: OOP practices make troubleshooting easier.

4. Enhanced security: OOP reinforces security measures.

5. Simplified code maintenance: OOP prevents data repetition and results in flexible code
.

Challenges of Object-Oriented Software Engineering

The practical challenges in object-oriented software design include the pressure from
technologies, frameworks, and architectures to make design decisions. It may not align with
ideal scenarios, the complexity of real-world problems requiring multiple models for the same
problem, and the need for quality assessment techniques to go beyond high-level metrics. These
challenges highlight the need for more reality-oriented research in the field of object-oriented
software design.
Table 5 shows the challenges and key issues in each challenge in object-oriented software
engineering. Fig 20 shows the major challenges in navigating them.

Table 5 challenges and key issues in OOSE

S.N
Challenge Key Issue
o

Staying updated with constantly changing

1 Evolving Tech Landscape
tech stacks and tools

Managing the trade-off between fast

2 Balancing Quality & Speed
delivery and high code quality

Complex Diagnosing issues in microservices and

3
System Debugging distributed systems

Handling accumulated shortcuts that

4 Managing Tech Debt
hinder future development.

Dealing with mental fatigue from high-

5 Burnout & Stress
pressure work environments

Designing systems that handle growing

6 Scaling Systems
user load efficiently

Coordinating across time zones and remote

7 Distributed Teams
communication barriers

Protecting user data from breaches and

8 Data Privacy & Security
ensuring compliance
 Working with outdated systems that are
9 Legacy Systems
hard to maintain or upgrade

Implementing and managing efficient

10 CI/CD Challenges
deployment pipelines

Cross-Functional Aligning with non-tech teams on shared

11
Collaboration goals

Transitioning between agile, scrum, or

12 Adapting to Methodologies
waterfall workflows

Writing code that's easy to read, maintain,

13 Code Maintainability
and scale

Resolving code merge issues in team

14 Version Control Conflicts
environments

Identifying and automating repetitive and

15 Implementing Automation
time-consuming tasks

Improving application speed and

16 Performance Optimization
responsiveness

Effectively adopting agile practices for

17 Agile Implementation
team efficiency

Keeping third-party libraries compatible

18 Managing Dependencies
and updated

Meeting demands for speed, features, and

19 High User Expectations
reliability
 Minimizing code clashes in collaborative
20 Git Conflicts
environments

Addressing skill or domain knowledge

21 Knowledge Gaps
deficiencies

Updating older code without modern best

22 Legacy Code Maintenance
practices

Staying productive and connected while

23 Remote Work Adaptation
working remotely

Handling integration and management of

24 Microservices Complexity
distributed services

Preventing breaches through secure coding

25 Cybersecurity Threats andpact, solutions, and useful tools to
tackle them: audits

Fig 20 Challenges in Object Oriented software engineering

BEST WISHES