1

Please read this disclaimer before

proceeding:
This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document
through email in error, please notify the system manager. This document
contains proprietary information and is intended only to the respective group /
learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender
immediately by e-mail if you have received this document by mistake and delete
this document from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited.

2
22CS602- OBJECT
ORIENTED SOFTWARE
ENGINEERING

DEPARTMENT : CSE

BATCH : 2022-2026
YEAR/SEMESTER : III/06

CREATED BY : Dr.A.Thilagavathy, RMKEC

Mr.M.Vengateshwaran, RMKEC
Dr. Ponmalar A,RMKEC
Ms.B.Maheswari, RMKEC
Mrs.A.Tamizharasi, RMDEC
Mrs.D.M.Kalaiselvi, RMDEC
Ms.S.Remya Rose, RMDEC
Dr. Rejin Paul N R, RMKCET
Ms.T.Karpagam, RMKCET
Ms.Jeya Rathnam, RMCET

CREATED ON : 18.12.2024 3
 Table of Contents
S.NO Topic Page No.

1. Course Objectives 5

2. Pre-Requisites 6

3. Syllabus 7

4. Course outcomes 8

5. CO- PO/PSO Mapping 9

6. Unit -I Lecture Plan 11

7. Activity based learning 12

8. Lecture notes 13-51

9. Assignments 52

10. Part A Q&A (WITH K LEVEL AND CO) 53

11. Part B Qs (WITH K LEVEL AND CO) 59

12. Supportive online Certification courses 60

Real time Applications in

13. 61
day to day life and to
Industry
14. Contents beyond the Syllabus 62

15. Assessment Schedule 65

16. Prescribed Textbooks & Reference Books 66

17. Mini Project suggestions 67

4
 Course
Objectives

The Course will enable learners to:

• Explain software engineering principles and activities involved in

building large software programs.

• Describe the process of requirements gathering, analysis and unified

modelling

• Illustrate the object oriented design process.

• Analyse various traditional and object oriented testing methods

• Apply estimation techniques, schedule project activities and compute

pricing..

5
 Pre-Requisites

Semester VI

22CS602 - OBJECT ORIENTED SOFTWARE ENGINEERING

Semester II &
III
20CS201-DATA STRUCTURES,
20CS302-OBJECT ORIENTED PROGRAMMING

6
 SYLLABUS

LTPC
22CS602 OBJECT ORIENTED SOFTWARE
ENGINEERING(Lab 2023
Integrated)
UNIT I PRODUCT AND PROCESS 6+6
The Nature of Software – Defining the Discipline – The Software Process – Process models
– Prescriptive Process Models – Product and Process – Agility and Process – What is an
Agile Process?– Scrum– Other Agile Framework – Kanban – DevOps

UNIT II REQUIREMENTS AND UNIFIED MODELING 6+6

Requirements Engineering – Establishing the Groundwork: Non-functional Requirements –
Requirements Gathering – Developing Use Cases – Negotiating and
Validating Requirements. Unified Modeling Language – Introduction – Static and
Dynamic Models – Modelling – Introduction to the UML – UML Diagrams – UML Class
Diagrams – Use-Case Diagram – UML Dynamic Modelling.

UNIT III OBJECT ORIENTED ANALYSIS AND DESIGN 6+6

Object oriented Analysis process – Business object Analysis – Use-case driven OOA –
Business process modelling – Use case model. Design Concepts -Design Process – Design
Concepts – Design Model: Design Principles and Design Elements. Architectural Design–
Designing class- based components - Conducting Component Level Design User –-
Interface Analysis and Design – Pattern-Based Software Design

UNIT IV SOFTWARE TESTING 6+6

Component Level: A Strategic Approach to Software Testing – White-Box Testing – Black
Box Testing- Object Oriented Testing. Integration Level: Integration Testing – AI and
Regression Testing- – Integration Testing in the OO Context Specialized Testing for Mobility:
Web application Testing – Web Testing Strategies – Security Testing – Performance Testing –
Real time Testing – Testing AI Systems – Testing Virtual Environments

UNIT V SOFTWARE QUALITY AND PROJECT MANAGEMENT 6+6

Software Metrics and Analytics: Software Measurement – Product Metrics. Creating a Viable
Software Plan: The Project Planning Process – Software Scope and Feasibility –
Decomposition and Estimation Techniques – Project Scheduling. Risk Management: Reactive
Versus Proactive Risk Strategies – Risk Identification – Risk Projection – The RMMM Plan.
Software Process Improvement: The SPI Process – The CMMI.
 Course outcomes

Upon completion of the course, the students will be

able
to:

Course Level
Description in Bloom’s
Outcome
Taxonomy
s

CO1 Summarize software engineering principles and activities K2

involved in building large software programs

CO2 Describe the different phases of software development. K2

CO3 Explain the basics of OOAD and develop software using K2

object oriented design.
CO4 Illustrate the different stages of the design process with K3
a case study.

CO5 Develop miniprojects using the application of object K3

oriented analysis and design.

CO6 Apply different testing strategies to develop efficient K3

projects.

8
 CO- PO/PSO
Mapping

Program
Program Outcomes Specific
Leve Outcomes
Course
l of
OutCome
CO K3,
s
K3 K4 K4 K5 K5, A3 A2 A3 A3 A3 A3 A2 PS
K6 PS PS
O-
O-2 O-3
1
PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO-
1 2 3 4 5 6 7 8 9 10 11 12

2 1 1 1 1 - - 1 1 1 - 1 2 2 -
CO1 K2

2 1 1 1 1 - - 1 1 1 - 1 2 2 -
CO2 K2

3 2 2 1 1 - - 1 1 1 - 1 2 2 -
CO3 K2

3 2 2 1 1 - - 1 1 1 - 1 2 2 -
CO4 K3

3 2 2 1 1 - - 1 1 1 - 1 2 2 -
C05 K3

3 2 2 1 1 - - 1 1 1 - 1 2 2 -
C06 K3

9
 UNIT - I
PRODUCT
AND
PROCESS

10
 Lecture Plan –Unit- 1

UNIT – I PRODUCT AND PROCESS

S.No Proposed Topic Actual Pertaining Highest Mode of

Lecture Lecture CO(s) Cognitive Delivery
Date Level
Period
Introduction to
Software
1 1 Engineering- BB,PPT
Nature of CO1 K2
the software
Defining the BB,PPT
Discipline –
2 1 The Software CO1 K2
Process
Perspective BB,PPT
Process
Models –
Waterfall
Model,
3 1 Incremental CO1 K2,K4
Model

Evolutionary BB,PPT
4 1 Models – CO1 K2,K4
Prototyping
BB,PPT
5 1 Spiral Model CO1 K2

Concurrent BB,PPT
6 1 model- Product CO1 K2
and Process
Agility and BB,PPT
7 1 process-Agil CO1 K2
e Process
Scrum-Other BB,PPT
Agile
8 1 Frameworks CO1 K2,K3

Kanban BB,PPT
9 1 CO1 K2
–
DevOps
 Activity based learning

Online Quiz:

https://docs.google.com/forms/d/e/1FAIpQLSc2RsW2Wf1377vSmkiFAxUIpm
W 6MdxSPB9XmNAT1bvqHiLpvQ/viewform?usp=sf_link

12
 22CS602 OBJECT ORIENTED SOFTWARE ENGINEERING
UNIT I PRODUCT AND PROCESS

The Nature of Software – Defining the Discipline – The Software Process – Process models
– Prescriptive Process Models – Product and Process – Agility and Process – What is an
Agile Process?– Scrum– Other Agile Framework – Kanban – DevOps

INTRODUCTION TO SOFTWARE ENGINEERING

Engineering – Application of science, tools and methods to find a cost-
effective solution to the given problem.It uses scientific principles to design and build
machines, structures, and other things, including bridges, roads, vehicles, buildings or a
software : civil/electrical/mechanical/software engineering.
Analogy-Think of delegating a 30 storey complex building construction to a petty
contractor who lacks basic systematic principles. The failure might come in several forms—
the building might collapse during the construction stage itself due to his ignorance of the
basic theories concerning the strengths of materials; the construction might get unduly
delayed, since he may not prepare proper estimates and detailed plans regarding the types
and quantities of raw materials required, the times at which these are required, etc. In
short, to be successful in constructing a building of large magnitude, one needs a good
understanding of various civil and architectural engineering techniques such as analysis,
estimation, prototyping, planning,designing, and testing. Similar is the case with the
software development projects.
Software engineeringdiscusses the and
systematic techniques for software development. cost-effective

Why study Software Engineering?

• To acquire skills to develop large programs
o Exponential growth in complexity and difficulty level with size
• Ability to solve complex programming problems
o How to break large projects into smaller and manageable
parts?
o Learn techniques of:
o Specification, design, interface
development,
testing, project management etc.,
• To acquire skills to be a better programmer:
o Higher productivity
oBetter Quality Program
The primary goal of software engineering is to improve the quality of
Goals of Software Engineering:
software products and to increase the productivity and job satisfaction of
13
software engineers.
 THE NATURE OF SOFTWARE:
DEFINING THE SOFTWARE
SOFTWARE APPLICATION DOMAINS
▪ SYSTEM SOFTWARE
▪ APPLICATION SOFTWARE
▪ ENGINEERING/SCIENTIFIC SOFTWARE
▪ EMBEDDED SOFTWARE
▪ PRODUCT-LINE SOFTWARE
▪ WEB-APPLICATIONS
▪ARTIFICIAL INTELLIGENCE SOFTWARE
THE CHANGING NATURE OF SOFTWARE:
▪ WEB APPS
▪ MOBILE APPLICATION
▪ CLOUD COMPUTING
▪ PRODUCT LINE SOFTWARE

DEFINING THE SOFTWARE

Software encompasses:
(1) Set of computer programs to provide desired features, function,
and performance;
(2) data structures that enable the programs to adequately store and
manipulate information and
(3) documentation that describes the operation and use of the programs.
Program is a set of instructions and data to performs a specific task

❑ Steps involved-

❑ Software- plays dual role

1. As a Product Eg-Ms office,Games
2. As a vehicle or a means to extract the potential of a product
Eg-OS,drivers,networking software,video editing software,Anti
virus
14
❑ Delivers information-

• It transforms personal data (e.g., an individual’s financial transactions)

that the data can be more useful in a local context
• It manages business information to enhance competitiveness. Eg-Busines
Analytic tools-Tableau
• It provides a gateway to worldwide information networks Eg-Internet
• It also provides a vehicle that can threaten personal privacy and a
gateway that enables those with malicious intent to commit criminal
acts. Eg- virus,malware

❑ Software can be determinate or

indeterminate
• Determinate -if the order and timing of inputs, processing, and outputs
is predictable. Eg. Microsoft Excel, many filter functions in image-editing
software like Photoshop, and media players such as VLC
• Indeterminate if the order and timing of inputs, processing, and outputs
cannot be predicted in advance. Eg Multiuser application-Ticket booking app

❑ Software is a logical rather than a physical system element

❑ Hardware wears out but —software doesn’t wear out. But it does deteriorate!
❑ Figure 1.1 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 then corrected, and failure rate drops to a steady-state level
(hopefully, quite
low) for some period of time. As time passes, however, the failure rate rises again
as hardware components suffer from the cumulative affects of dust, vibration,
abuse, temperature extremes , and many other environmental maladies. Stated
simply, the hardware begins to wear out.

Figure 1.1:
15
Failure curve for
hardware
 Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, the failure rate curve for software should take the form of
the “idealized curve” shown in Figure 1.2.
Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected (hopefully, without introducing other errors), and the curve
flattens as shown. The idealized curve is a gross oversimplification of actual failure models
for software. However, the implication is clear—software doesn’t wear out. But it does
deteriorate! This seeming contradiction can best be explained by considering the “actual
curve” in Figure 1.2. During its life, software will undergo change. As changes are made,
it is likely that errors 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.

Figure 1.2: Failure curve for software

Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are no
software spare parts. Every software failure indicates an error in design or in the process
through which design was translated into machine-executable code. Therefore, software
maintenance involves considerably more complexity than hardware maintenance.

16
 Although the industry is moving toward component-based
construction,
most software continues to be custom built.
Consider the manner in which the control hardware for a computer- based product
is designed and built. The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to ensure that proper function will be
achieved, and then goes to the shelf where catalogs of digital components exist. Each
integrated circuit has a part number, a defined and validated function, a well-defined
interface, and a standard set of integration guidelines. After each component is selected,
it can be ordered off the shelf.

As an engineering discipline evolves, a collection of standard design components is

created. Standard screws and off-the-shelf integrated circuits are only two of thousands
of standard components that are used by mechanical and electrical engineers as they
design new systems.The reusable components have been created so that the
engineer can concentrate on the truly
innovative elements of a design, i.e., the parts that represent something new. In the
hardware world, component reuse is a natural part of the engineering process. In the
software world, it has only begun to be achieved on a broad scale.

A software component should be designed and implemented so that it can be reused in

many different programs. Modern reusable components encapsulate both data and the
processing that is applied to the data, enabling the software engineer to create new
applications from reusable parts. For example, today’s user interfaces are built with
reusable components that enable the creation of graphics windows, pull-down menus, and
a wide variety of interactionmechanisms. The data structures and processing detail
required to build the interface are contained within a library of reusable components for
interface, construction.

SOFTWARE APPLICATION DOMAINS:

Seven broad categories of computer software present continuing challenges for
software engineers:

System software:
System software is a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures.Other systems applications (e.g.,
operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data.

In either case, the systems software area is characterized by heavy interaction with
computer
hardware; heavy usage by multiple users; concurrent operation that requires scheduling,
resource sharing, and sophisticated process management; complex data structures;
a nd
1 7
multiple external interfaces.
Application software:
Application software consists of standalone programs that solve a specific business
need.Applications in this area process business or technical data in a way that
facilitates business operations or management/technical decision making.In
addition to conventional data processing applications, application software is used
to control business functions in real-time (e.g., point-of-sale transaction
processing, real-time manufacturing process control)
Engineering/scientific software:
This software applications range from astronomy to volcanology, from automotive
stressanalysis to space shuttle orbital dynamics, and from molecular biology to
automated manufacturing. However, modern applications within the
engineering/scientific area are moving away from conventional numerical
algorithms. Computer-aided design, system simulation, and other interactive
applications have begun to take on real-time and even system software
characteristics.

Embedded software:

Embedded software resides within a product or system and is used to implement

and control features and functions for the end-user and for the system itself.
Embedded software can perform limited and esoteric functions (e.g., keypad
control for a microwave oven) or provide significant function and control capability
(e.g., digital functions in an automobile such as fuel control, dashboard displays,
braking systems, etc.)
Product-line software:
Designed to provide a specific capability for use by many different customers, product-
line software can focus on a limited and esoteric market place (e.g., inventory control
products) or address mass consumer markets (e.g. word processing,
spreadsheets, computer graphics, multimedia, entertainment, database management,
personal and business financial applications).
Embedded software resides within a product or system and is used to implement
and control features and functions for the end-user and for the system itself.

Web-applications:
“WebApps,” can be little more than a set of linked hypertext files that present
information using text and limited graphics. However, as e-commerce and B2B
applications grow in importance, WebApps are evolving into sophisticated computing
environments that not only provide standalone features, computing functions, and
content to the end user, but also are integrated with corporate databases and
business applications.

Artificial intelligence software:

It makes use of nonnumerical algorithms to solve complex problems that are
not amenable to computation or straightforward analysis. Applications within this
area include robotics, expert systems, pattern recognition (image and voice),
artificial
neural networks, theorem proving, and game playing.
18
THE CHANGING NATURE OF THE SOTWARE:
Four broad categories of software are evolving to dominate the
industry. And yet, these categories were in their infancy little more than a decade
ago.
WebApps

In the early days of the World Wide Web (circa 1990 to 1995),
websites consisted of little more than a set of linked hypertext fi les that presented
information using text and limited graphics. As time passed, the augmentation of
HTML by development tools (e.g., XML, Java) enabled Web engineers to provide
computing capability along with informational content. Web-based systems and
applications5 (we refer to these collectively as WebApps) were born. Today,
WebApps have evolved into sophisticated computing tools that not only provide
stand-alone function to the end user, but also have been integrated with corporate
databases and business applications.
A decade ago, WebApps “involve[d] a mixture between print publishing and
software development, between marketing and computing, between internal
communications and external relations, and between art and technology.” [Pow98]
But today, they provide full computing potential in many of the application
categories.
Over the past decade, Semantic Web technologies (often referred to as Web 3.0)
have evolved into sophisticated corporate and consumer applications that
encompass “semantic databases [that] provide new functionality that requires Web
linking, flexible [data] representation, and external access APIs.” [Hen10]
Sophisticated relational data structures will lead to entirely new WebApps that
allow access to disparate information in ways never before possible.

Mobile Applications

The term app has evolved to connote software that has been
specifically designed to reside on a mobile platform (e.g., iOS, Android, or Windows
Mobile). In most instances, mobile applications encompass a user interface that
takes advantage of the unique interaction mechanisms provided by the mobile
platform, interoperability with Web-based resources that provide access to a wide
array of information that is relevant to the app, and local processing capabilities
that collect, analyze, and format information in a manner that is best suited to the
mobile platform. In addition, a mobile app provides persistent storage capabilities
within the platform.
It is important to recognize that there is a subtle distinction between mobile web
applications and mobile apps. A mobile web application (WebApp) allows a mobile
device to gain access to web-based content via a browser that has been
specifically designed to accommodate the strengths and weaknesses of the mobile
platform. A mobile app can gain direct access to the hardware characteristics of the
device (e.g., accelerometer or GPS location) and then provide the local processing
and storage capabilities noted earlier.

19
Cloud Computing

Cloud computing encompasses an infrastructure or “ecosystem”

that enables any user, anywhere, to use a computing device to share computing
resources on a broad scale. The overall logical architecture of cloud computing is
represented in Figure 1.3 .

Figure 1.3 Cloud Computing Architecture

Referring to the figure, computing devices reside outside the cloud and have
access to a variety of resources within the cloud. These resources encompass
applications, platforms, and infrastructure. In its simplest form, an external
computing device accesses the cloud via a Web browser or analogous software.
The cloud provides access to data that resides with databases and other data
structures. In addition, devices can access executable applications that can be
used in lieu of apps that reside on the computing device.

Product Line Software

Product Line Software- The Software Engineering Institute [SEI] defines a software
product line as “a set of software-intensive systems that share a common, managed
set of features satisfying the specific needs of a particular market segment or
mission and that are developed from a common set of core assets in a prescribed
way”.
The Assets ->requirements, architecture ,design patterns,reusable components,
test cases, and other software engineering work products

20
Attributes of good software
The software should deliver the required functionality and performance to the user
and should be maintainable, dependable and usable.

● Maintainability: Software should be written in such a way that it may evolve to

meet the changing needs of customers. This is a critical attribute because software
change is an inevitable consequence of a changing business environment.
● Dependability: Software dependability has a range of characteristics, including
reliability, security and safety. Dependable software should not cause physical or
economic damage in the event of system failure.
● Efficiency: Software should not make any wasteful use of system resources such as
memory
and processor cycles. Efficiency therefore includes responsiveness, processing time,
memory utilization, etc.
● Usability: Software must be usable, without undue effort, by the type of user for
whom it is designed. This means that it should have an appropriate user interface and
adequate documentation.

What are key challenges facing software engineering?

Software engineering in the 21st century faces three key challenges:

▪ The heterogeneity challenge: Systems are required to operate as distributed

systems across networks that include different types of computers and with different
kinds of support systems. It is often necessary to integrate new software with older
legacy systems written in different programminglanguages.The
challenge is the heterogeneity
challenge of developing techniques for building dependable software
that is flexible enough to cope with this heterogeneity.

▪ The delivery challenge: Many traditional software engineering techniques are

time – consuming. The time they take is required to
achieve software quality.However, business today must be responsive and
supporting
change very software must change equally rapidly.The delivery challenge is the
rapidly. Their
challenge of shortening delivery times for large and complex systems without
compromising system quality.

▪ The trust challenge: As software is intertwined with all aspects of our lives, it
is essential that we can trust that software. This is especially true for remote software
systems accessed through a web page or web service interface.

▪ The trust challenge is to develop techniques that demonstrate that software can be
trusted by its users.

DEFINING THE DISCIPLINE-SOFTWARE ENGINEERING

IEEE DEFINITION FOR SE LAYERS OF

SE
▪ L1-QUALITY
▪ L2-PROCESS
▪ L3-METHODS
21
▪ L4-TOOLS
 SE DEFINITION OF IEEE:
The IEEE [IEE93a] has developed the following definition for software
engineering (SE):
Software Engineering :
(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the
application of engineering to software.
(2) The study of approaches as in (1)

SOFTWARE ENGINEERING – A LAYERED TECHNOLOGY

• Software engineering is a layered technology.

Fig:1.3 Software Engineering Layers

• Any engineering approach (including software engineering) must rest
on an organizational commitment to quality.The bedrock that supports
software engineering is a quality focus.
• The foundation for software engineering is the process layer.
o Software engineering process is the glue that holds the technology
layers together andenables rational and timely development of computer
software.
o Process defines a framework that must be established for effective
delivery of software engineering technology.
o 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 provide the technical “how to’s” for building
software.
•Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
Software engineering methods rely on a set of basic principles that govern each
area of the technology and include modeling activities and other descriptive
techniques.

Software engineering tools provide automated or semiautomated support for the

process and
the methods. When tools are integrated so that information created by one tool
22
ca n be used by another, a system for the support of software development, called
computer- aided software engineering, is established.
 SOFTWARE PROCESS
ELEMENTS OF THE SOFTWARE PROCESS
THE GENERIC PROCESS FRAMEWORK -5 ACTIVITIES
1. COMMUNICATION
2. PLANNING
3. MODELING
4. CONSTRUCTION
5. DEPLOYMENT
UMBRELLA
ACTIVITIES
PROCESS
ADAPTATION
ELEMENTS OF THE SOFTWARE PROCESS
A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
Each framework activity is populated by a set of software engineering
actions—a collection of related tasks that produces a major software engineering
work product (e.g., design is a software engineering action).
● An activity strives to achieve a broad objective (e.g., communication with
stakeholders) 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
tests) that produces a tangible outcome.

Figure 1.4: A software process framework

A process framework establishes the foundation for a complete software process
by identifying a small number of framework activities that are applicable to all software
projects, regardless of their size or complexity.
23
 In addition, the process framework encompasses a set of umbrella activities
that are applicable across the entire software

FIVE GENERIC PROCESS FRAMEWORK ACTIVITIES:

● Communication: This framework activity involves heavy communication and
collaboration with the customer (and other stakeholders’) and encompasses
requirements gathering and other related activities.
● Planning: This activity establishes a plan for the software engineering work that
follows. It
describes 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.
● Modeling: This activity encompasses the creation of models that allow the
developer and the customer to better understand software requirements and the de
sign that will achieve those
requirements.
● Construction: This activity combines code generation (either manual or automated)
and the testing that is required to uncover errors in the code.
● Deployment: The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation.
Using an example derived from the generic process framework, the modeling activity is
composed of two software engineering actions—analysis and design.
● Analysis encompasses a set of work tasks (e.g., requirements gathering,
elaboration, negotiation, specification, and validation) that lead to
the creation of the analysis model (and/or requirements
specification).
● Design encompasses work tasks (data, design, architectural design,
interface design, and component – level design) that create a design
model (and/or a design specification).

UMBRELLA ACTIVITIES

Umbrella activities: activities that occur throughout the process, across

all framework activities.
Examples: Configuration management, measurement
The Umbrella activities are:
● Software project tracking and control - allows the software team to
assess
progress against
the project plan and take necessary action to maintain schedule.
● Risk management - assesses risks that may effect the outcome of the
project or the quality of the product. 24
● Software quality assurance - defines and conducts the activities required to ensure
software quality.

● Formal technical reviews - assesses software engineering work products in an effort to

uncover and remove errors before they are propagated to the next action or activity.
● Measurement - defines and collects process, project, and product measures that assist the
team in delivering software that meets customers’ needs; can be used in conjunction with
all other framework and umbrella activities.

● Software configuration management - manages the effects of change throughout the

software process.
● Reusability management - defines criteria for work product reuse (including
software components) and establishes mechanisms to achieve reusable components.
● Work product preparation and production - encompasses the activities required
to create work products such as models, documents, logs, forms, and lists.

PROCESS ADAPTATION
software engineering process –
A rigid prescription ? - NO
✔Should be Agile and Adaptable for a timely delivery of a quality software
development. The process adopted varies project to project
Among the differences are
• Overall flow of activities, actions, and tasks and the interdependencies among them.
• Degree to which actions and tasks are defined within each framework activity.
• Degree to which work products are identified and required.
• Manner in which quality assurance activities are applied.
• Manner in which project tracking and control activities are applied.
• Overall degree of detail and rigor with which the process is described.
• Degree to which the customer and other stakeholders are involved with the project.
• Level of autonomy given to the software team.
• Degree to which team organization and roles are prescribed.

PROCESS MODELS
• Process Flow
• Process Patterns
PRESCRIPTIVE PROCESS MODELS
• The waterfall model
• Incremental Process Models
• Evolutionary Process Models
• Prototyping Model
• Spiral Model
• Concurrent Model

25
.
PROCESS FLOW
Process flow describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time.
● A linear process flow executes each of the five framework activities
in sequence, beginning with communication and culminating with
deployment.
● An iterative process flow repeats one or more of the activities before
proceeding to the
next
● An evolutionary process flow executes the activities in a “circular” manner.
Each circuit
● A parallel process flow executes e or more activities in parallel with oth of er
through the five activities leads to a more complete version of the software.
activities (e.g., modeling for one aspect the software might be executed in paral e lel
on
with construction of another aspect of th software).

PROCESS PATTERN

o Describes the problems that is encountered during software

engineering process
o Identifies the environment in which the problem has been encountered
o Suggests one or more proven solutions to the problem.

Types:
•Stage pattern-defines problems in the
Framework Activity
Eg: Establishing Communication

•Task pattern- defines problems in the Action or

Task
set
Eg: Requirements Gathering
• Phase pattern-defines the sequence of
framework activities that occurs within the 26
process
Eg: spiral or prototyping
 PRESCRIPTIVE PROCESS MODELS

A prescriptive model prescribes how a new software system should be developed.

It strives for structure and order of the software development activities.

WATERFALL LIFE CYCLE MODEL:

Sometimes called as The Classic Life Cycle model

Suggests a systematic, sequential approach to software development
Begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing support of
the completed software.

Figure 1.8: The software life cycle

The first published model of the software development process was derived from more
general system engineering processes .This is illustrated in Figure 1.8. Because of the
cascade from one phase to another, this model is known as the waterfall model or
software life cycle. The principal stages of the model map onto fundamental
development activities: Communication,Planning,Modeling,Construction and deployment.

27
 COMMMUNICATION & PLANNING
1. Requirements analysis and definition: The system’s services, constraints
and
goals are established by consultation with system users. They are then defined in detail
and serve as a system specification.
MODELING
2. System and software design: The systems design process partitions the
requirements to either hardware or software systems. It establishes an overall system
architecture. Software design involves identifying and describing the fundamental
software system abstractions and their relationships.
CONSTRUCTION
3. Implementation and unit testing: During this stage, the software
design is realized as a set of programs or program units. Unit testing involves verifying
that each unit meets its specification.

3.Integrationandsystem testing: The individual program units or programs

are
integrated and tested as a complete system to ensure that the software requirements
have been
met. After testing, the software system is delivered to the customer.
DEPLOYMENT
5.Operation and maintenance: Normally, this is the longest life-cycle phase.
The system is installed and put into practical use. Maintenance involves correcting
errors which were not discovered in earlier stages of the life cycle, improving the
implementation of system units and enhancing the system’s services as new
requirements are discovered. In principle, the result of each phase is one or more
documents that are approved (‘signed off’). The following phase should not start until
the previous phase has finished. In practice, these stages overlap and feed information
to each other. During design, problems with requirements are identified; during coding
design problems are found and so on. The software process is not a simple linear model
but involves a sequence of iterations of the development activities.

Because of the costs of producing and approving documents, iterations are costly
and involve significant rework. Therefore, after a small number of iterations, it is normal
to freeze parts of the development, such as the specification, and to continue with the
later development stages. Problems are left for later resolution, ignored or programmed
around. This premature freezing of requirements may mean that the system won’t do
what the user wants. It may also lead to badly structured systems as design problems
are circumvented by implementation tricks.

During the final life-cycle phase (operation and maintenance), the software is put into
use.Errors and omissions in the original software requirements are discovered.
Program and design errors emerge and the need for new functionality is identified.
The system must therefore evolve to remain useful. Making these changes (software
maintenance) may involve repeating previous process stages.
28
Advantages of the waterfall model:
Simple and easy to understand and
implement Good for small projects
As requirements are known at the beginning of the project it is easy to manage.

Disadvantages of the waterfall model:

Real projects rarely follow the sequential flow that the model proposes.
It is often difficult for the customer to state all requirements explicitly that too in
the beginning of the project itself
A working version of the program(s) will not be available until late in the project
time span Not good for long, complex and object oriented projects
High risk as problems are uncovered only at the testing phase-disastrous effects.

V-MODEL
A variation in the representation of the waterfall model is called the V-
model. Fundamentally no difference b/w Waterfall and V-model

Figure 1.8.1: The

V- Model

The V-model provides a way of visualizing how verification and validation actions
are applied to earlier engineering work.

29
Represented in Figure 1.8.1 , the V-model depicts the relationship of quality
assurance actions to the actions associated with communication, modeling, and
early construction activities. As a software team moves down the left side of the
V, basic problem requirements are refi ned into progressively more detailed and
technical representations of the problem and its solution. Once code has been
generated, the team moves up the right side of the V, essentially performing a
series of tests (quality assurance actions) that validate each of the models
created as the team moves down the left side.

INCREMENTAL PROCESS MODELS:

There are many situations in which initial software requirements are reasonably
well-defined, but
the overall scope of the development effort precludes a purely linear process. In
addition, there may be a compelling need to provide a limited set of software
functionality to users quickly and then
refine and expand on that functionality in later software releases. In such cases, a
process model that is designed to produce the software in increments is chosen.
The incremental model combines elements of the waterfall model applied in an
iterative fashion. Referring to Figure 1.9, the incremental model applies linear
sequences in a staggered fashion as calendar time progresses. Each linear
sequence produces deliverable “increments” of the software.
For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing and document production
functions in the first increment more
sophisticated editing, and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced
page layout capability in the fourth increment. It should be noted that the process
flow for any increment may incorporate the
prototyping paradigm.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed, but many supplementary features
(some known, others unknown) remain undelivered. The core product is used by
the customer (or undergoes detailed evaluation). As a result of use and/or
evaluation, a plan is developed for the next increment.

30
The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality. This process is
repeated following the delivery of each increment, until the complete product is
produced.

The incremental process model, like prototyping and other evolutionary

approaches, is iterative in nature. But unlike prototyping, the incremental model
focuses on the delivery of an operational product with each increment. Early
increments are “stripped down” versions of the final product, but they do provide
capability that serves the user and also provides a platform for evaluation by the
user.

Advantages:
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the
project. Early increments

can be implemented with fewer people. If the core product is well received, additional
staff (if required) can be added to implement the next increment. In addition,

increments can be planned to manage technical risks.

For example, a major system might require the availability of new hardware that is
under development and whose delivery date is uncertain. It might be possible to plan
early increments
to beindelivered
a way that avoids
to end thewithout
users use ofinordinate
this hardware, thereby enabling partial
functionality delay.

Figure 1.9: The

incremental model

31
 Disadvantages of the incremental model:
The cost of the final product may cross the cost estimated
initially. This model requires a very clear and complete planning.
The planning of design is required before the whole system is broken into
small increments.
The demands of customer for the additional functionalities after every
increment causes problem during the system architecture.

EVOLUTIONARY PROCESS MODEL:

Software, like all complex systems, evolves over a period of time. Business and product
requirements often change as development proceeds, making a straight-line path to an
end product unrealistic; tight market deadlines make completion of a comprehensive
software product impossible, but a limited version must be introduced to meet
competitive or business pressure; a set of core product or system requirements is
well understood, but the details of product or system extensions have yet to be defined.
In these and similar situations, software engineers need a process model that has been
explicitly designed to accommodate a product that evolves over time.
Evolutionary models are iterative. They are characterized in a manner that enables
software engineers to develop increasingly more complete versions of the software.
we present two common evolutionary process models-PROTOTYPING and SPIRAL

PROTOTYPING:
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 these, and many other situations, a
prototyping paradigm may offer the best approach.
Although prototyping can be used as a standalone process model, it is more commonly
used as a technique that can be implemented within the context of any one of the
process models. Regardless of the manner in which it is applied, the prototyping
paradigm assists the software engineer and the customer to better understand what is
to be built when requirements are fuzzy.
The prototyping paradigm (Figure 1.11) begins with communication. The software
engineer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory.

32
 Advantages of Prototype model:
• Users are actively involved in the development
• Since in this methodology a working model of the system is
• provided, the users get a better understanding of the system being
• developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
Disadvantages of Prototype model:
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system
as scope of the system may expand beyond original plans.
• In a rush to provide a working model software engineers
overlook the quality
and maintainabily by sticking to the available tools and known
algorithms.

Figure 1.11 The prototyping model

Prototyping iteration is planned quickly and modeling (in the form a quick
design”) occurs.
The quick
design focuses on a representation of those aspects of the software that will be visible to
the customer/end-user (e.g., human interface layout or output display formats).
The quick design leads to the construct of a prototype. The prototype is deployed and
then evaluated by the customer/user feedback is used to refine requirements for the
software, Iteration occurs as the prototype is tuned to satisfy the needs of the customer,
while at the same time enabling the developer to better understand what needs to be
done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a
working prototype is built, the developer attempts to make use of existing program
fragments or applies tools (e.g., report generators, window manager etc.) that enable
working programs to be generated quickly.
The prototype can serve as “the first system”. Users get a feel for the actual
system, and developers get to build something immediately.

Yet, prototyping can be problematic for the following reasons:

33
1. The customer sees what appears to be a working version of the software, Unaware that
the prototype is held together “with chewing gum and baling wire,” unaware that in
the rush to get it working we haven’t considered overall software quality or
long-term maintainability. When informed that the product must be rebuilt so that
high-levels of quality can be maintained, the customer cries foul and demands that “a
few fixes” be applied to make the prototype a working product. Too often, software
development management relents.
2. The developer often makes implementation compromises in order to get a prototype
working
quickly. An inappropriate operating system or programming language may be used
simply because it is available and known; an inefficient algorithm may be implemented
simply to demonstrate capability. After a time, the developer may become comfortable
with these choices and forget all the reasons why they were inappropriate. The less-
than- ideal choice has now become an integral part of the system.

Despite the problems, prototyping can be an effective software engineering

tool
● Improves communication between stakeholders leads to fewer changes
● Developer and customer must agree up front to discard the prototype and replace
it with quality
software product

THE SPRIAL MODEL

The spiral model, originally proposed by Boehm, is evolutionary software. Process
model that
couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model. It provides the potential for rapid development of
increasingly more complete

versions of the software.

Boehmdescribes the model in the following manner:
The spiral development model is a risk-driven process model generator that is used
to guide multi- stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features.
● One is a cyclic approach for incrementally growing a system’s degree of definition
and
implementation while decreasing its degree of risk.
● The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system
solutions.

Using the spiral model, software is developed in a series of evolutionary releases.

During early
iterations, theprocess
releasebegins,
might be
thea paper model or prototype. During later
evolutionary
iterations, increasingly more complete versions of the engineered system are 34
produced.
A spiral model is divided into a set of framework activities. Each of the framework
software team performs activities that are implied by a circuit around the spiral in a clockwise
direction, beginning at the center. Risk is considered as each revolution is made.

Anchor point milestones—a combination of work products and conditions that are
attained
along the path of the spiral—are noted for each evolutionary pass.

The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then

progressively

more sophisticated versions of the software. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from

the customer after delivery. In addition, the project manager adjusts the planned number of

iterations required to complete the software.

Unlike other process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer software. Therefore, the first circuit around
the spiral might represent a “concept development project” which starts at the
core of the spiral and continues for multiple iterations until concept development is complete. If
the concept is to be developed into an actual product, the process proceeds outward on the
spiral and a “new product development project” commences. The new product
will evolve through a number of iterations around the spiral. Later, a circuit around the spiral
might be used to represent a “product enhancement project.” In essence, the
spiral, when characterized in this way, remains operative until the software is retired.
a There are
nt, but whenever a change is initiated, the process starts
times when the process is dorma t the appropriate
duct enhancement).
entry point (e.g., pro

Figure 1.12: A typical Spiral Model

The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level. The spiral model uses prototyping as a

risk reduction 35
mechanism but, more importantly, enables the developer to apply the prototyping
approach at any stage in the evolution of the product. It maintains the systematic
stepwise approach suggested by the classic life cycle but incorporates it into an iterative
framework that more realistically reflects the real world. The spiral model demands a
direct consideration of technical risks at all stages of the project and, if properly applied,
should reduce risks before they become problematic.

But like other paradigms, the spiral model is not a panacea. It may be difficult to convince
customers (particularly in contract situations) that the evolutionary approach is
controllable. It demands considerable risk assessment expertise and relies on this
expertise for success. If a major risk is not uncovered and managed, problems will
undoubtedly occur.

Note:
If the management demands fixed – budget development (generally a bad
idea), the spiral
model can be problem; as each circuit is completed, project cost is revisited and revised.

THE CONCURRENT DEVELOPMENT MODEL:

The concurrent development model, sometimes called concurrent engineering,
can
be
represented schematically as a series of framework activities, software engineering
actions
and tasks, and their associated states.
For example, the modeling activity defined for the spiral model is accomplished by
invoking the following actions: prototyping and/or analysis modeling and specification
and design.
Figure 1.13 provides a schematic representation of one software engineering task within
the
modeling activity for the concurrent process model. The activity—modeling may be in any
one of the states noted at any given time. Similarly, other activities or tasks (e.g.,
communication or construction) can be represented in an analog in manner.
For example, early in a project the communication activity has completed its first iteration
and exists in the awaitingchanges state.
The modeling activities which existed in the nonestate while initial
communication was completed, makes a transition into the under
development state.
If, however, the customer indicates that changes in requirements must be made, the
modeling activity move from the under development state into the awaitingchanges
state. The concurrent process model defines a series of events that will trigger
transitions from state to state for each of the software engineering activities, actions, or
tasks.
For example, during early stages of design, an inconsistency in the analysis model
is uncovered.
This generates the event analysis model correction which will trigger the analysis action
 Figure 1.13 One element of the concurrent process model
The concurrent process model is applicable to all types of software development
and provides an
accurate picture of the current state of a project. Rather than Confining software
engineering activities, actions, and tasks to a sequence of events, it defines a network of
activities. Each activity, action, or task on the network, exists simultaneously with other
activities, actions, or tasks. Events generated at one point in the process network trigger
transitions among the state
A FINAL COMMENT ON EVOLUTIONARY PROESSES:
The modern computer software is characterized by continual change, by very
tight timelines, and
by an emphatic need for customer/user satisfaction. In many cases, time-to-market
is the most
important management requirement. If a market window is missed, the
software project itself may be meaningless.

Evolutionary process models were conceived to address these issues, and yet, as
a general class of process models, they too have weaknesses.
These are summarized by Nogueira and his colleagues :
● The first concern is that prototyping poses a problem to project planning because
of the uncertain
number of cycles required to construct the product. Most project management
and estimation techniques are based on linear layouts of activities, so they do not
fit completely.
● Second, evolutionary software processes do not establish the maximum speed of the
evolution. If the evolutions occur too fast, without a period of relaxation, it is certain
that the process will fall into chaos. On the other hand, if the speed is too slow then
productivity could be affected. 37
● Third, software processes should be focused on flexibility and extensibility rather than on
high quality. This assertion sounds scary. However, we should prioritize the speed of
the development over zero defects. Extending the development in order to reach
high, quality could result in a late delivery of the product, when the opportunity
niche has disappeared. This paradigm shift is imposed by the competition on the edge of
chaos.

Indeed, a software process that focuses on flexibility, extensibility, and speed of

development over
high quality does sound scary.
The intent of evolutionary models is to develop high-quality software in an iterative
or incremental manner. However, it is possible to use an evolutionary process to

EMPHASIZE flexibility, extensibility, and speed of development.

PRODUCT
Sr. Key ANDProduct
PROCESS Process
No.

Concept The product is the final The process is a sequence or set

1 result of a development of steps that should be followed
cycle. to create a product.

Focus Product development The process focuses on each

2 focus is on final outcome. step to be followed during
software product development.

Life A product life cycle tends A process life cycle is

3
to be in the short term. generally long term.

Goal The main goal of product The main goal of a process is to

development is to finish the make a good quality products.
4 work and get the product
delivered successfully.

If the process is weak, the end product will undoubtedly suffer. But
an obsessive over-reliance on process is also dangerous.
About every ten years give or take five, the software community
redefines “the problem” by shifting its focus from product issues to
process issues
Duality of product and process- A creative software professional should
also
derive as much satisfaction from the process as the end product

38
AGILITY AND PROCESS

AGILITY INTRODUCTION
AGILITY AND THE COST OF CHANGE
WHAT IS AN AGILE PROCESS?
AGILITY PRINCIPLES
ADVANTAGES & DISADVANTAGES OF AGILE DEVELOPMENT

AGILITY INTRODUCTION
The main point of this section is to introduce agility in the context of software
development. Agility is more than change management. Agility means that customers and
developers need to work together as collaborators on the development team and try to
build products that can be adapted to a rapidly changing market place. Part of this
adaptation is learning when and how to streamline the production of work products and
focus on the development of incremental operational prototypes.
A manifesto is normally associated with an emerging political movement-one that
attacks
the old guard and suggests revolutionary change.
“We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
Individuals and interactions over processes and
tools Working software over comprehensive
documentation Customer collaboration over
contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items
on the
left more –Kent Beck et al.

AGILITY AND THE COST OF CHANGE

An agile process reduces the cost of change because software is released in
increments and change can be better controlled within an increment

39
AGILE PROCESS

An agile process is one that addresses following 3 assumptions

1. It is difficult to predict in advance which software requirements
will persist and which will change. It is equally difficult to predict
how customer priorities will change as the project proceeds.
2. It is difficult to predict how much design is necessary before construction
is used to prove the design
3. Analysis, design, construction, and testing are not as predictable (from
a planning point of view)

❖ To manage all these unpredictability, agile process

permits Incremental Adaptation

❖ Incremental adaptation is accomplished by Agile Team using

Customer Feedback by delivering a quick operational prototype.

Given these three assumptions, an important question arises: How do we create

a process that can manage unpredictability? The answer, as we have already
noted, lies in process adaptability (to rapidly changing project and technical
conditions).
An agile process, therefore, must be adaptable. But continual adaptation without
forward progress accomplishes little. Therefore, an agile software process must
adapt incrementally. To accomplish incremental adaptation, an agile team
requires customer feedback (so that the appropriate adaptations can be made).
An effective catalyst for customer feedback is an operational prototype or a
portion of an operational system. Hence, an incremental development strategy
should be instituted. Software increments (executable prototypes or portions of
an operational system) must be delivered in short time periods so that
adaptation keeps pace with change (unpredictability). This iterative approach
enables the customer to evaluate the software increment regularly, provide
necessary feedback to the software team, and influence the process adaptations
that are made to accommodate the feedback.

40
PRINCIPLES BEHIND THE AGILE MANIFESTO
The Agile Alliance defines 12 agility principles for those who want to achieve agility:

1. Customer satisfaction: Customers need to be satisfied with the quick delivery of

the product at the earliest.
2. Welcome change: Even if the change is late in the development process, it needs
to be addressed and handled as soon as possible.
3. Deliver frequently: The focus must be on the continuous delivery of software
in a shorter timescale.
4. Work together: Business units and developers need to work in
tandem throughout the project lifespan.
5. Motivated team: The projects need to have motivated team members. They
must also be trusted to get the work done.
6. Face-to-face: Conversations that take place face-to-face have
maximum efficiency and effectiveness.
7. Working software: The primary measure of progress is evaluated based on
the working software created.
8. Constant pace: The agile process is greatly beneficial when it comes to
sustainable development.
9. Good design: Focusing on technological excellence and good design
can significantly affect agility.
10. Simplicity: The amount of work not being done needs to be reduced

via simpler processes.

11. Self-organized: Self-organized teams end up providing the best architectures,
designs, and requirements.
12. Reflection and adjustment: At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts its behavior accordingly.

Figure 1.17
Agiity model
41
What Are the Advantages of the Agile Process?

Plenty of interaction between the team and the clients-improved

transparency.
The outputs are easily predicted, and can sometimes be delivered faster
than expected.
New changes can be implemented at very little cost because of the frequency of
new increments that are produced- developers work few hours to day to roll
back. Since the project is broken down into smaller units, development, testing,
and collaboration will be of the highest quality.
Most projects follow a rigid schedule and can incur predictable costs
The maximum project value can be ensured since the client can decide
the priorities of the features
Disadvantages of the Agile Process
In case of some software deliverables, especially the large ones, it is difficult to
assess the effort required at the beginning of the software development life
cycle. Lack of formal documents leaves scope for confusion- important decisions
taken during different phases can be misinterpreted at later points of time by
different team members.
It becomes difficult to get important project decisions such as design decisions to
be reviewed by external experts. When the project completes and the developers
disperse, maintenance can become a problem.
The project can easily get taken off track if the customer representative is not clear
what final outcome that they want.
Only senior programmers are capable of taking the kind of decisions required during
the development process. Hence it has no place for newbie programmers, unless
combined with experienced resources.

AGILE METHODOLOGIES
The following are some of the methods to implementations of agile:

Scrum

XP

Dynamic Systems Development Method(DSDD)

Agile Modeling (AM)

Agile Unified Process

(AUP) Lean

Kanban 42
SCRUM

• Scrum -the name is derived from an activity that occurs during a rugby match.
• Restarting the game-gaining possession of ball closely packed
• Most popular agile framework-concentrates particularly on how to manage
tasks within a team-based development environment.
• Scrum uses iterative and incremental development model, with shorter
duration of iterations.
• Relatively simple to implement and focuses on quick and frequent deliveries.
• Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery.
• Within each framework activity, work tasks occur within a process called a sprint.
• The No. of Sprints within a framework activity will vary depending on product
complexity and size
• The work conducted within a sprint is adapted to the problem at hand
and is defined and often modified in real time by the Scrum team

Scrum master leads the meeting

Fig 1.18 Scrum Process Flow

43
Scrum emphasizes the use of a set of software process patterns that have
proven effective for projects with tight timelines, changing requirements, and
business criticality
Each of these software patterns defines a set of development activitites:

SCRUM’S PROCESS PATTERNS

▪Backlogs
▪Sprints
▪Scrum meetings
▪Demos

Backlogs:
A prioritized list of project requirements or features that
provide business value for the customer.
Items can be added to the backlog at any time (this is how changes are
introduced). The product manager assesses the backlog and updates priorities as
required.

Sprints:
Consist of work units that are required to achieve a requirement defined in
the backlog that must be fit into a predefined time-box (typically 30 days).
Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short-term, but stable
environment

Scrum meetings:
These are short (typically 15-minute) meetings held daily by the Scrum
team.
3 questions in the fig 5.3 are asked and answered by all team
members
oScrum Master leads the meeting and assesses the responses of team
members
oUncovers potential problems as early as possible
oLead to “knowledge socialization” thereby promoting a self-organizing team
structure
Demos:
oIt deliver the software increment to the customer so that functionality that
has been implemented can be demonstrated and evaluated by the
customer. oIt is important to note that the demo may not contain all
planned functionality, but rather those functions that can be delivered within
44
the
time- box that was established.
OTHER AGILE FRAMEWORKS
The following are some of the methods to implementations of
agile: Extreme Programming(XP)
Dynamic Systems Development
Method(DSDD) Agile Modeling (AM)
Agile Unified Process
(AUP) Lean
Kanban

EXTREME PROGRAMMING (XP )

http://www.extremeprogramming.org/rules/crccards.html
The most widely used agile process, originally proposed by Kent Beck. It encompasses a set of
rules and practices that occur within the context of four framework activities: planning, design,

coding and testing.

Planning

Begins with the creation of “user stories” and then placed on an index card.
The customer assigns a value to the story based on the overall business value of
the function. Agile “XP” team assesses each story and assigns a cost “measured
in development weeks.”
If stories take more than 3 weeks to develop, the customer is asked to split the
stories into smaller ones.

Stories are grouped to form a deliverable increment “done by customer and XP team.”
Once a commitment is made on delivery date, the XP team orders the stories that
will be developed in one of three ways:

1. All stories will be implemented immediately within a few weeks.

2. The stories with the highest value will be moved up in the schedule
and implemented first.
3. The riskiest stories will be moved up in the schedule and implemented
first. After the first increment (project release), “project velocity” is
used to help define subsequent delivery dates for other increments.

Project velocity is the number of customer stories

implemented during the first release.
http://www.extremeprogramming.org/rules/velocity.ht
ml

Project velocity can be used then to:

1. Help estimate delivery dates and schedule for subsequent releases, and
2. Determine whether an over-commitment has been made for all
stories across the entire development project.
45
Design
XP Follows the KIS(S) principle. A simple design is always preferred over a
more complex representation.
Encourage the use of CRC (class-responsibility collaboration) cards which identify and organize
the O-O classes that are relevant to the current software increment.
For difficult design problems, suggests the creation of “spike solutions”—a design prototype
that is implemented and
evaluated.
http://www.ironspeed.com/articles/Evolving%20With%20Extreme%20Programmi
n
g/Article.aspx

Encourages “refactoring”—an iterative refinement of the internal program design that

controls the code modifications by suggesting small design changes that may improve the
design.

Coding
Recommends the construction of a unit test for a story before coding commences
Encourages “pair programming” where two programmers work together at one
workstation

to create code for a story. “Two heads better than one.”

Testing
All unit tests are executed daily which provides the XP team with a continual indication
of progress and also can raise warning flags early if things are going awry.
“Acceptance tests” are defined by the customer “user stories” and executed to assess
customer visible functionality

Fig 1.19 EXTREME PROGRAMMING 46

INDUSTRIAL XP

Greater inclusion of management-expanded role for

customers- and upgraded technical practices.

IXP incorporates six new practices that are designed to help

ensure that an XP project works successfully for significant projects within a
large organization
✔Readiness assessment.
✔Project community
✔Project chartering
✔Test-driven management
✔Retrospectives
✔Continuous learning

Readiness assessment: The IXP team ascertains whether all members

of the project community (e.g., stakeholders, developers, management)
are on board, have the proper environment established, and understand
the skill levels involved.

Project community: The IXP team determines whether the right

people, with the right skills and training have been staged for the project.
The “community” encompasses technologists and other stakeholders.

Project chartering: The IXP team assesses the project itself to

determine whether an appropriate business justification for the project
exists and whether the project will further the overall goals and objectives
of the organization.

Test-driven management: An IXP team establishes a series of measurable

“destinations” [Ker05] that assess progress to date and then defines
mechanisms for determining whether or not these destinations have been
reached.

Retrospectives: An IXP team conducts a specialized technical review

after a software increment is delivered. Called a retrospective, the
review examines “issues, events, and lessons-learned” [Ker05]
across a software increment and/or the entire software release.

Continuous learning: The IXP team is encouraged (and possibly,

incented) to learn new methods and techniques that can lead to a higher-
quality product.

47
Dynamic System Development Method (DSDM)

Promoted by the DSDM Consortium

Dynamic System Development Method is an agile S/W development approach

that provides a framework for building and maintaining systems which meet tight
time constraints through the use of incremental prototyping in a controlled
project environment.

Borrows Pareto principle 80-20 rule—80 % of an application can be delivered in 20%

of the time it would take to deliver the complete (100 percent) application.
only enough work is required for each increment to facilitate movement to
the next increment. Remaining- on request.

DSDM life cycle starts with - Feasibility study and Business

study. DSDM defines 3 iterative cycles-

❖ Functional Model Iteration: Produce iterative prototypes.

❖ design and build iteration: Revisit prototyping to ensure operational

business value for end users.

❖ Implementation: Places the latest prototype into the operational environment

NOTE: (1) The increment may not be 100 percent complete

(2) changes may be requested as the increment is put into
place
Agile Modeling (AM)
It is a collection of values, principles and practice for effective modeling
and documentation of software-based systems.
AM follows Agile Manifesto
The Agile modeling philosophy recognizes that an agile team must have the
courage to make decisions that may cause it to reject a design and refactor.
The team must also have the humility to recognize that technologists do not
have all the answers and that business experts and other stakeholders should be
respected and embraced.
AM suggests a wide array of “core” and “supplementary” modeling
principles that make AM unique !
Model with a purpose
Use multiple models
Travel light
Content is more important than representation
Know the models and the tools you use to create
them Adapt locally.
A major segment of the software engineering community has adopted the
Unified Modeling Language (UML) as the preferred method for representing
analysis and design models.
48
AGILE UNIFIED PROCESS

The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative
in the small” philosophy for building computer-based systems.

Serial in the Large

▪Enables a team to visualize the overall process flow for a software project.
▪The serial nature of Agile UP is captured in its four phases :
❖ Inception. The goal is to identify the initial scope of the
project, a potential architecture for your system, and to obtain
initial project funding and stakeholder acceptance.
❖ Elaboration. The goal is to prove the architecture of the system.
❖ Construction. The goal is to build working software on a
regular, incremental basis which meets the highest-priority needs
of your project stakeholders.
❖ Transition. The goal is to validate and deploy your system
into your production environment.

Iterative in the Small

Within each of the activities, the team iterates to achieve agility and
to deliver meaningful software increments to end users as rapidly as
possible.
Each AUP iteration addresses the following activities

❖ Modeling - UML representations of the business and problem domains are

created

❖ Implementation-Models are translated into source code

❖ Testing-Like XP, the team designs and executes a series of tests to uncover
errors and ensure that the source code meets its requirements.

❖ Deployment - Like the generic process activity discussed earlier

deployment in this context focuses on the delivery of a software increment
and the acquisition of feedback from end users.

❖ Configuration and project management-

configuration management -change management, risk management, and
the control of any persistent work products that are produced by the
team. Project management tracks and controls the progress of the team
and coordinates team activities

❖ Environment management. Environmental management

coordinates a process infrastructure that includes standards, tools, and
other support technology available to the team
49
Kanban definition
The Japanese word “kanban”, meaning “visual board” or a “sign”, has been
used in the sense of a process definition since the 1950s. It was first
developed and applied by Toyota as a scheduling system for just-in-time
manufacturing. On the other hand, the capitalized term “Kanban” is known
and associated with the emergence of the “Kanban Method,” which was
first defined in 2007.

Kanban is a workflow management method for defining, managing and

improving services that deliver knowledge work. It aims to help you
visualize your work, maximize efficiency, and improve continuously.

The Kanban Method

At the beginning of the 21st Century, key players in the software industry
quickly realized how Kanban could positively change the way products
and services were delivered.
With an increased focus on efficiency and by harnessing advances in
computing technology, Kanban left the automotive industry's realm and
was
successfully applied to other complex commercial sectors such as IT,
software development, R&D, and others.
The Kanban Board
A Kanban board is a tool for workflow visualization and one of the Kanban
method's key components.
Visualizing your workflow and tasks on a Kanban board helps you better
understand your processes and gain an overview of your workload. With
this new level of transparency, you will quickly identify problematic work
stages, and by improving those, your team will soon work more efficiently.
Main Components of the Kanban board
Kanban boards use Card, Column, Swimlanes, and WIP Limits to enable
teams to visualize and manage their workflows effectively. Let us introduce
you to the main components more closely:
Kanban Cards – This is the visual representation of tasks. Each card contains
information about the task and its status, such as deadline, assignee, description,
etc. Kanban Columns – Each column on the board represents a different stage of
your workflow. The cards go through the workflow until their full completion.
Work-in-Progress Limits – They restrict the maximum amount of tasks in the
different stages of the workflow. Limiting WIP allows you to finish work items
faster by helping your team focus only on current tasks.
Kanban Swimlanes – These are horizontal lanes you can use to separate
different activities, teams, classes of service, and more.
If you are new to the method, you may start with a basic Kanban board structure
and split it into three primary sections that show different workflow stages.

Kanban metrics
Kanban uses specific metrics to measure team capacity and estimate
project length.
Team velocity defines how many tasks a team can deliver in a given period of
time, for example a week or iteration.[13] Velocity is calculated periodically and
to help with accuracy of the calculated velocity, teams aim to create tasks that
are similar in size. Knowing team velocity helps better predict when a project is
going to end.
Lead and Cycle time defines the average time it takes to complete a task.
Lead time is calculated since the team gets a request from the client and cycle
time is calculated since the team starts working on a task. Lead time is used to
understand how long a client has to wait for their product and cycle time is used
to understand how fast the team produces a product.
Actionable Agile metrics use cycle time to better predict when each project
item is going to be finished. Created by Daniel S. Vacanti in 2015,actionable
Agile
metrics measure how much time it took to finish 50%, 85% and 95% of the
tasks. This information can be used to help the team better predict and control
task delivery dates.
 ASSIGNMENTS

1. Compare Waterfall Model and Incremental Model

2. Compare Waterfall Model and prototyping Model

3. Compare Concurrent Model and Incremental

Model

52
 PART-A

1. Define software engineering? (K1,CO1)

Ans: Software Engineering : (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study
of approaches as in (1)
Software engineering discusses systematic and cost-effective techniques for
software development.
2. What is Software? (K1,CO1)
Ans: Software encompasses: (1) Set of computer programs to provide
desired features, function, and performance; (2) data structures that enable
the programs to adequately store and manipulate information and (3)
documentation that describes the operation and use of the programs

Program is a set of instructions and data to performs a specific task

3. What are the characteristics of a software? (K2,CO1)
Ans: Software plays a dual role- as a product and as a mean to
extract the underlying potential of a hardware

Delivers information-
Software can be determinate or indeterminate
Software doesn’t wear out but may deteriorate if not adapted to change.
Software is a logical rather than a physical system element- It is not
manufactured but engineered.
Other characterestics
include, Usability of Software
Reusability of components
Flexibility of software
Maintainability of
software

Portability and Reliability of Software

4. What are the software layers? (K1,CO1)
Ans: Software engineering is a layered technology. The layers
include Layer 1-Quality Layer 2-
Process Layer 3-Methods `Layer

4-Tools
53
QUALITY – bedrock supporting SE-organizational primary commitment

PROCESS-The foundation for software engineering is the process laye.It holds

the technology layers together

METHODS- It compasses technical details for building software-

Software engineering tools provide automated or semi-automated support for
the process and the methods.

5. Define Software Process Framework. (K1,CO1)

Ans: A software process framework 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 (e.g., communication with

stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort.

▪An action (e.g., architectural design) encompasses a set of tasks that produce a
major work product (e.g., an architectural model).

▪A task focuses on a small, but well-defined objective (e.g., conducting a unit test)
that produces a tangible outcome.

6. What is a Generic process framework (K1,CO1)

Ans: A generic process framework for software engineering encompasses five activities:
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
Communication –understanding stakeholders’ need

Planning –Route map-Software project plan - Describes technical

tasks,risks,resources required,work products to produce, schedule

Modeling-sketch -Models are used to understand something before building it .S/W

Engr creates models to understand the requirements and the design to achieve it

Construction-What you design must be built. This activity combines code generation
(either manual or automated) and the testing that is required to uncover errors in the
code.

Deployment - The software (as a complete entity or as a partially completed increment) is

delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation.
54
7. List 5 umbrella activities in the process framework. (K1,CO1)

Ans:Typical umbrella activities include:

• Software project tracking and control
• Risk management
• Software quality assurance
• Technical Reviews
• Measurement
• Software Configuration Management
• Reusability management
• Work product preparation and production
8.Define Process flow. (K1,CO1)
Ans:Describes how the framework activities, actions, and tasks are
organized
w.r.t sequence and time.
Each of a variety of process models differs in the process
flow. Types:

a) Linear process flow

b) Iterative Process flow

c) Evolutionary Process flow

d) Parallel Process flow

9.Define Process Pattern (K1,CO1)

Ans:It describes the problems that is encountered during software
engineering process

Identifies the environment in which the problem has been encountered

It Suggests one or more proven solutions to the problem.

Types:
Stage pattern-defines problems in the Framework
Activity Eg: Establishing Communication
Task pattern- defines problems in the Action or
Task set Eg: Requirements Gathering

Phase pattern-defines the sequence of framework activities that occurs

within 55
the process Eg: spiral or prototyping
 10.What are the pitfalls of the Classic life cycle model? (K2,CO1)
Ans:Real projects rarely follow the sequential flow that the model proposes.
It is often difficult for the customer to state all requirements explicitly that too
in the beginning of the project itself
A working version of the program(s) will not be available until late in the project
time span

Not good for long, complex and object oriented projects

High risk as problems are uncovered only at the testing phase-disastrous
effects. 11.What is the principle behind the Spiral Model? (K2,CO1)
Ans:Principles of spiral model are:
Risk driven process model - Risk is analyzed on each revolution using
prototyping Anchor point milestones [work products+ conditions attained] are
noted for each

evolutionary pass-Proper Documentation

12. What is an Anchor point milestone? (K1,CO1)
Anchor point milestones—a combination of work products and conditions that
are attained along the path of the spiral in the spiral model.

It ensures stakeholder commitment to feasible and mutually

satisfactory system solutions.

are noted for each evolutionary pass.

13. What is an Agile model? (K1,CO1)
Ans: Agile model model is a combination of iterative and incremental process
models with focus on process adaptability and customer satisfaction by rapid
delivery of working software product.

Agile Methods break the product into small incremental builds.Main

principle-To remove unnecessary activities that waste time and effort.
14. When is an Agile Process used?. State 2 principles of agility. (K2,CO1)
Ans: Agile process is used when there is an
• Unpredictability on sustainable requirements
• Unpredictability on needed design before construction
• Unpredictability on Analysis, design, construction, and testing from a
planning point of view
Two Principles of Agility-
Customer satisfaction: Customers need to be satisfied with the quick delivery of
the product at the earliest.
Welcome change: Even if the change is late in the development process, it needs to

56
be addressed and handled as soon as possible.
15. What are the disadvantages of Agile methodologies (K2,CO1)
Effort required is unpredictable for large software deliverables.
Lack of formal documents leaves scope for confusion as it is not possible
to review the important design decisions
The project may turn up as an failure if customer representative is
unclear. Only senior programmers are capable of taking the kind of
decisions required during the development process disregarding the new
comers..

16. what is a spike solution? What is the need for Refactoring?

(K2,CO1)
Spike Solutions are the immediate recommendation of an operational
prototype by XP for difficult design problems encountered.
The intent is to lower risk when true implementation starts and to validate
the original estimates for the story containing the design problem.
Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code yet improves the internal
structure. It is a disciplined way to clean up code [and modify/simplify the
internal design] that minimizes the chances of introducing bugs

17. What are CRC cards? What is the use of it? (K2,CO1)
Ans: A Class Responsibility Collaborator (CRC) model is a collection of
standard index cards that have been divided into three sections-A class
represents a collection of similar objects, a responsibility is something that a
class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities.

18.What is an DSDM Agile methodology.State its principle. (K1,CO1)

Ans:Dynamic System Development Method is an agile S/W development
approach that provides a framework for building and maintaining systems which
meet tight time constraints through the use of incremental prototyping in a
controlled project environment.

DSDM borrows modified Pareto principle of 80-20 rule.

80 % of an application can be delivered in 20% of the time it would take to
deliver the complete (100 percent) application.Only enough work is required for
each increment to facilitate movement to the next increment. Remaining- on
request.
57
19. Define Sprints and Demos. (K2,CO1)
Ans: A sprint is part of the core components of the agile methodology. The term refers
to a predefined span of time (any period of length, usually shorter 1- weeks) in which a
team will work to accomplish a work product.

It consist of work units that are required to achieve a requirement defined in the
backlog that must be fi t into a predefined time-box.
Scrum meetings of 15 minute duration take place every 24 hours during the course
of sprint.
The work conducted within a sprint (the number of sprints required for each framework
activity will vary depending on product complexity and size) is adapted to the problem at
hand and is defined and often modified in real time by the Scrum team.
Demos:It deliver the software increment to the customer so that functionality that has
been implemented can be demonstrated and evaluated by the customer. It is important
to note that the demo may not contain all planned functionality, but rather those
functions that can be delivered within the time-box that was established.

20. Differentiate Product and Process. (K2,CO1)

The product is the final result of a development cycle.
The process is a sequence or set of steps that should be followed to create a
product.
Product development focus is on final outcome.
The process focuses on each step to be followed during software
product development.
A product life cycle tends to be in the short term.
A process life cycle is generally long term.
The main goal of product development is to finish the work and get the
product delivered successfully.
The main goal of a process is to make a good quality products.

21. Scrum Vs Kanban (k2,CO1)

58
 PART-B

1. Explain the prescriptive process model in detail. ( K1,CO1)

2. Explain Evolutionary models-Prototyping and Spiral. (K1,CO1)

3. Justify how Concurrent model can be used in context with any other
models. (K3,CO1)

4. Explain Scrum.(K1,CO1)
5. Explain XP in detail.(K1,CO1)
6. Compare Waterfall and Spiral model.(K2,CO1)
7. 7.Explain AUP in detail.(K2,CO1)
8. Explain Agility and substantiate with any 2 methodologies
9. Explain the Generic Process Framework activities involved in
INVENTORY MANAGEMENT problem. (K3,CO1)

10. Propose Boehm’s Model for EXAM MANAGEMENT problem.(K3,C01)

59
 Supportive online Certification
courses
NPTEL/OTHER REFERENCES / WEBSITES:

http://nptel.ac.in

Software EngineeringTutorial – javatpoint

https://www.tutorialspoint.com/software_engineering/

Software EngineeringTutorial for Beginners: Learn in 3 Days (guru99.com)

Software Engineering Tutorial | A Complete Guide for Beginners

(educba.com)

www.udemy.com
www.upgrad.com

www.simplilearn.co

60
Real time Applications in day to day life and to Industry

1. Real time Home Automation System.

2. Hospital management system

3. Exam management system

4. Online monitoring of students in with respect to Attendance,

Fees payment, assignment submission, Skill rack status,etc

5. Designing an expert system for medical diagnosis.

61
 CONTENTS BEYOND THE SYLLABUS

SDLC - RAD Model

The RAD (Rapid Application Development) model is based on prototyping

and iterative development with no specific planning involved. The process of
writing the software itself involves the planning required for developing the
product.

Rapid Application Development focuses on gathering customer requirements

through workshops or focus groups, early testing of the prototypes by the
customer using iterative concept, reuse of the existing prototypes (components),
continuous integration and rapid delivery.

What is RAD?
Rapid application development is a software development methodology that
uses minimal planning in favor of rapid prototyping. A prototype is a working
model that is functionally equivalent to a component of the product.
In the RAD model, the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for faster product
delivery. Since there is no detailed preplanning, it makes it easier to incorporate
the changes within the development process.
RAD projects follow iterative and incremental model and have smallteams
comprising of developers, domain experts, customer representatives and other
IT resources working progressively on their component or prototype.
The most important aspect for this model to be successful is to make sure that
the prototypes developed are reusable.

RAD Model Design

RAD model distributes the analysis, design, build and test phases into a series of
short, iterative development cycles.
Following are the various phases of the RAD Model −

Business Modelling
The business model for the product under development is designed in terms of
flow of information and the distribution of information between various business
channels. A complete business analysis is performed to find the vital information
for business, how it can be obtained, how and when is the information processed
and what are the factors driving successful flow of information.

62
Data Modelling
The information gathered in the Business Modelling phase is reviewed and
analyzed to form sets of data objects vital for the business. The attributes of
all data sets is identified and defined. The relation between these data
objects are established and defined in detail in relevance to the business
model.

Process Modelling
The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model. The process model for any changes or
enhancements to the data object sets is defined in this phase. Process
descriptions for adding, deleting, retrieving or modifying a data object are
given.

Application Generation
The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.

Testing and Turnover

The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration. However, the data flow and the
interfaces between all the components need to be thoroughly tested with
complete test coverage. Since most of the programming components have
already been tested, it reduces the risk of any major issues.

The following illustration describes the RAD Model in detail.

63
RAD Model Vs Traditional SDLC
The traditional SDLC follows a rigid process models with high emphasis on
requirement analysis and gathering before the coding starts. It puts pressure on
the customer to sign off the requirements before the project starts and the
customer doesn’t get the feel of the product as there is no working build
available for a long time.

The customer may need some changes after he gets to see the software.
However, the change process is quite rigid and it may not be feasible to
incorporate major changes in the product in the traditional SDLC.

The RAD model focuses on iterative and incremental delivery of working models
to the customer. This results in rapid delivery to the customer and customer
involvement during the complete development cycle of product reducing the risk
of non-conformance with the actual user requirements.

RAD Model - Application

RAD model can be applied successfully to the projects in which clear
modularization is possible. If the project cannot be broken into modules, RAD
may fail.

The following pointers describe the typical scenarios where RAD can be used −

RAD should be used only when a system can be modularized to be delivered

in an incremental manner.

It should be used if there is a high availability of designers for Modelling.

It should be used only if the budget permits use of automated code generating
tools.

RAD SDLC model should be chosen only if domain experts are available with
relevant business knowledge.

Should be used where the requirements change during the project and
working prototypes are to be presented to customer in small iterations of 2-3
months.

64
 ASSESSMENT SCHEDULE

• Tentative schedule for Even Semester 2024

First Internal Assessment : 28.01.25 - 03.02.25

Second Internal Assessment : 10.03.25 - 15.03.25

: 03.04.25- 17.04.25
Model Examination

65
 PRESCRIBED TEXTBOOKS &
REFERENCE BOOKS
TEXT BOOKS:
1. Roger S. Pressman, “Software Engineering: A Practitioner‘s Approach” , McGraw
Hill International Edition, Nineth Edition, 2020.
2. Ali Bahrami, “Object Oriented Systems Development”, McGraw Hill
International Edition,2017.

REFERENCES:

1. Micheal Blalh and James Rumbaugh, Object Oriented Modeling and Design with UML,
2nd edition Pearson 2013.
2. Ian Sommerville, “Software Engineering”, Tenth Edition, Pearson Education, 2016.
3. Ivar Jacobson, Harold Bud Lawson, Pan-Wei Ng, Paul E. McMahon, Michael Goedicke,
“The Essentials of Modern Software Engineering”, Morgan & Claypool Publishers, 2019.
4. Booch, G, Jacobson I, Rumbaugh J, “The Unified Modeling Language User Guide”,
Addison Wesley, 2008.
5. Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object Modeling
6. Language”, 3rd edition, Addison Wesley, 2003.

66
 Mini Project suggestions

1. Depict an effective prescriptive model for the problem -

online migration of a petty retail store to a departmental
store.

1. How Scrum is used to in the above scenario with sprint value 15

and velocity 5 in each sprints..

67
 Thank you

Disclaimer:

This document is confidential and intended solely for the educational purpose of RMK Group of Educational
Institutions. If you have received this document through email in error, please notify the system manager. This
document contains proprietary information and is intended only to the respective group / learning community as
intended. If you are not the addressee you should not disseminate, distribute or copy through e-mail. Please notify
the sender immediately by e-mail if you have received this document by mistake and delete this document from
your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking
any action in reliance on the contents of this information is strictly prohibited.

68