CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Subject Name : Object Oriented Software Engineering

Subject code : CCS 356
Regulation : 2021
Department : Computer Science Engineering
Year / Semester : III / VI

UNIT – I - NOTES
SOFTWARE PROCESS AND AGILE DEVELOPMENT
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models –Introduction to Agility - Agile Process-Extreme programming-XP
Process-Case Study.

INTRODUCTION TO SOFTWARE ENGINEERING

“Software Engineering is a discipline in which theories, methods and tools are applied to develop
professional software product”
In software engineering the systematic and organized approach is adopted. Based on the nature
of the problem and development constraints various tools and techniques are applied in order to
develop quality software.
The definition of software engineering is based on two terms:
Discipline: For finding the solution to the problem an Engineer applies appropriate theories,
methods and tools. While finding the solutions, Engineers must think of the organizational and
financial constraints. Within these constraints only, he/she has to find the solution.
Product: The software product gets developed after following systematic theories, methods and
tools along with the appropriate management activities.

Defining Software
1. What is the impact of reusability of software development process? (Nov/Dec 2017)
Write short notes on unique characters of software. (Nov/Dec 2017)
Software is nothing but a collection of computer programs and related documents that are
intended to provide desired features, functionalities and better performance.
Software products may be
1. Generic - That means developed to be sold to a range of different customers.
2. Custom-That means developed for a single customer according to their specification.
Page 1
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Software Characteristics
Software development is a logical activity and therefore it is important to understand basic
characteristics of software. Some important characteristics of software are:
(i) Software is engineered, not manufactured
Software development and hardware development are two different activities.
A good design is a backbone for both the activities.

Quality problems that occur in hardware manufacturing phase cannot be

removed easily. On the other hand, during software development process such
problems can be rectified.
In both the activities, developers are responsible for producing qualitative product.

(ii) Software does not ware out

In early stage of hardware development process the failure rate is very high because of
manufacturing defects. But after correcting such defects the failure rate gets reduced,
The failure rate remains constant for some period of time and again it starts increasing because of
environmental maladies (extreme temperature, dusts, and vibrations).
On the other hand software does not get affected from such environmental maladies. Hence ideally
it should have an "idealized curve". But due to some undiscovered errors the failure rate is high
and drops down as soon as the errors get corrected.
Hence in failure rating of software the "actual curve" is as shown below

Failure Curves for Hardware and Software

Page 2
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

During the life of software if any change is made, some defects may get introduced.

This causes failure rate to be high. Before the curve can return to original steady state another
change is requested and again the failure rate becomes high.
Thus the failure curve looks like a spike. Thus frequent changes in software cause it to deteriorate.
Another issue with software is that there are no spare parts for software.
If hardware component wears out it can be replaced by another component but it is not possible
in case of software.
Therefore, software maintenance is more difficult than the hardware maintenance.

(iii) Most software is custom built rather than being assembled from components
While developing any hardware product firstly the circuit design with desired functioning
properties is created.
Then required hardware components such as ICs; capacitors and registers are assembled
according to the design, but this is not done while developing software product.
Most of the software is custom built.
However, now the software development approach is getting changed and we look for reusability
of software components.
It is practiced to reuse algorithms and data structures.
Today software industry is trying to make library of reusable components.
For example: In today's software, GUI is built using the reusable components such as
message windows pull down menus and many more such components. The approach is
getting developed to use in-built components in the software. This stream of software is popularly
known as component engineering.

Categories of Software
Software can be applied in a situation for which a predefined set of procedural steps (algorithm)
exists. Based on a complex growth of software it can be classified into following categories
(i) System software - It is collection of programs written to service other programs. Typical programs in
this category are compiler, editor and assemblers. The purpose of the system software is to
establish a communication with the hardware.
(ii) Application software - It consists of standalone programs that are developed for specific business
need. This software may be supported by database systems.
(iii) Engineering/Scientific software - This software category has a wide range of programs from
astronomy to volcanology, from automative stress analysis to space shuttle orbital dynamics and from
molecular biology to automated manufacturing. This software is based on complex numeric

Page 3
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

computations.
(iv) Embedded software - This category consists of program that can reside within a product or
system. Such software can be used to implement and control features and functions for the end-user and
for the system itself.
(v) Web applications - Web application software consists of various web pages that can be retrieved by
a browser. The web pages can be developed using programming languages like JAVA, PERL, CGI, HTML,
and DHTML.
(vi) Artificial Intelligence software - This kind of software is based on knowledge based expert
systems. Typically, this software is useful in robotics, expert systems, image and voice recognition,
artificial neural networks, theorem proving and game playing.
Goals and Objectives of Software
While developing software following are common objectives.
(i) Satisfy users requirements - Many programmers simply don’t do what the end user wants because
they do not understand user requirements. Hence it becomes necessary to understand the demand of
end user and accordingly software should be developed.
(ii) High reliability - Mistakes or bugs in a program can be expensive in terms of human lives, money,
and customer relation. For instance, Microsoft has faced many problems because earlier release of
windows has many problems. Thus, software should be delivered only if high reliability is achieved.
(iii) Low maintenance costs - Maintenance of software is an activity that can be done only after
delivering the software to the customer. Any small change in software should not cause restructuring of
whole software. This indicates that the design of software has poor quality.

(iv) Delivery on time - It is very difficult to predict the exact time on which the software can be
completed. But a systematic development of software can lead to meet the given deadline.
(v) Low production costs - The software product should be cost effective.
(vi) High performance - The high-performance software is expected to achieve optimization in speed
and memory usage.
(vii) Ease of reuse - Use same software in different systems and software.
Environments reduce development costs and also improve the reliability. Hence reusability of
developed software is an important property.

Page 4
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Difference between Software Product and Program

Sl.
PROGRAM SOFTWARE PRODUCT
No.
Programs are developed by individual Software product is developed by multiple users and
a.
users and it is used for personal use. it is used by large number of people or customers
Software product consists of multiple program codes,
Programs are small in size and processing
b. related documents such as SRS, design documents
limited functionality.
user manuals, test cases and so on.
Generally, only one person uses the
Good graphical user interface is most required by
c. program hence there is lack of user
any software product.
interface.
Software product is developed by software engineers
Program is generally developed by who are large in number and work in a team.
d.
programmer. Therefore systematic approach of developing
software product must be applied.
e. Ex: Program of sorting n elements Ex: A Word Processing software

LAYERED TECHNOLOGY
2. Draw the layered architecture of software engineering. (Nov/Dec 2018)
Software engineering is a layered technology. Any software can be developed using these layered
approaches. Various layers on which the technology is based are quality focus layer, process layer,
methods layer, tools layer.
A disciplined quality management is a backbone of software engineering technology.
Process layer is a foundation of software engineering. Basically, process defines the framework
for timely delivery of software.

Figure 03: Layered technology

In method layer the actual method of implementation is carried out with the help of requirement
analysis, designing, coding using desired programming constructs and testing.

Page 5
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
Software tools are used to bring automation in software development process.
Thus software engineering is a combination of process, methods, and tools for development of
quality software.

SOFTWARE PROCESS
3. Explain the CMMI model to access the organization level. (Nov/Dec 2017)
Software process can be defined as the structured set of activities that are required to develop the
software system.
The fundamental activities are:
(i) Specification
(ii) Validation
(iii) Design and implementation
(iv) Evolution
A software process model is an abstract representation of a process. It presents a description of a
process from some particular perspective.

Common Process Framework

The process framework is required for representing the common process activities.

Figure 04: A Software process framework

Process framework activities
Communication
By communicating customer requirement gathering is done.
Planning - Establishes engineering work plan, describes technical risks, lists resource requirements,
work products produced and defines work schedule.
Modeling - The software model is prepared by:
Analysis of requirements
Design
Construction - The software design is mapped into a code by:
Page 6
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
Code generation
Testing
Deployment - The software delivered for customer evaluation and feedback is obtained.
Task sets - The task set defines the actual work done in order to achieve the software objective. The task
set is used to adopt the framework activities and project team requirements using:
Collection of software engineering work tasks
Project milestones
Software quality assurance points
Umbrella activities - The umbrella activities occur throughout the process. They focus on project
management, tracking and control. The umbrella activities are
(i) Software project tracking and control - This is an activity in which software team can assess
progress and take corrective action to maintain schedule.
(ii) Risk management - The risks that may affect project outcomes or quality can be analyzed.

(iii) Software quality assurance - These are activities required to maintain software quality.
(iv) Formal technical reviews - It is required to assess engineering work products to uncover
and remove errors before they propagate to next activity.
(v) Software configuration management - Managing of configuration process when any change in
the software occurs.
(vi) Work product preparation and production - The activities to create models, documents,
logs, forms and lists are carried out.
(vii) Reusability management - It defines criteria for work product reuse.
(viii) Measurement - In this activity, the process can be defined and collected. Also, project and
product measures are used to assist the software team in delivering the required software.

Capability Maturity Model (CMM)

4. Explain the CMMI model to assess the organizational level. (Nov/Dec 2018)
The Software Engineering Institute (SEI) has developed a comprehensive process meta-model emphasizing
process maturity. It is predicated on a set of system and software capabilities that should be
present when organizations reach different levels of process capability and maturity.
The Capability Maturity Model (CMM) is used in assessing how well an organization's processes
allow to complete and manage new software projects.
Various process maturity levels are:
Level 1: Initial - Few processes are defined and individual efforts are taken.
Level 2: Repeatable - To, track cost schedule and functionality basic project management processes are
established. Depending on earlier successes of projects with similar applications necessary process
Page 7
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
discipline can be repeated.
Level 3: Defined - The process is standardized, documented and followed. All the projects use
documented and approved version of software process which is useful in developing and supporting
software.
Level 4: Managed - Both the software process and product are quantitatively understood and controlled
using detailed measures
Level 5: Optimizing - Establish mechanisms to plan and implement change. Innovative ideas and
technologies can be tested.
Thus, CMM is used for improving the software project.

PRESCRIPTIVE PROCESS MODELS

5. Neatly explain the following process model and write their advantages and disadvantages.
i) Spiral Model ii) Rapid application development model. (Apr/May 2015)
Discuss the prototyping model. What is the effect of designing a prototype on the overall cost of the
software project? (Apr/May 2016)
Which process model is best suited for risk management? Discuss in detail with an example. Give the
advantages and disadvantages of the model. (Nov/Dec 2016)
What is the significance of spiral model when compared with other model? (Nov/Dec 2017)
Which software process model is good for risk management? Explain the model. Describe how the
model is used to layout the objectives, risks and plans for quality improvement. (Apr/May 2018)
Definition of Process Model: The process 'model can be defined as the abstract representation of
process. The appropriate process model can be chosen based on abstract representation of process.
The software process model is also known as Software Development Life Cycle (SDLC) Model
or software paradigm.
These models are called prescriptive process models because they are following some rules for
correct usage.
In this model various activities are carried out in some specific sequence to make the desired
software product.
Figure 05: Various prescriptive process models

Page 8
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
Need for Process Model
The software development team must decide the process model that is to be used for software
product development and then the entire team must adhere to it. This is necessary because the software
product development can then be done systematically. Each team member will understand what the
next activity is and how to do it. Thus process model will bring the definiteness and discipline in
overall development process.
Every process model consists of definite entry and exit criteria for each phase. Hence the
transition of the product through various phases is definite. If the process model is not followed for
software development then any team member can perform any software development activity, this will
ultimately cause a chaos and software project will definitely fail without using process model, it is
difficult to monitor the progress of software product. Let us discuss various process models one by one.
Waterfall Model
The waterfall model is also called as 'linear-sequential model' or 'classic life cycle model'. It is
the oldest software paradigm. This model suggests a systematic, sequential approach to
software development.
The software development starts with requirements gathering phase. Then progresses through
analysis, design, coding, testing and maintenance. Following
In requirement gathering and specification / analysis phase the basic requirements of the system
Figure 06: Phases of Waterfall Model

must be understood by software engineer, who is also called Analyst. The information domain functions,
behavioral requirements of the system are understood. All these requirements are then well documented
and discussed further with the customer, for reviewing.
Waterfall model
The design is an intermediate step between requirements analysis and coding. Design focuses on
program attributes such as -
 Data structure
 Software architecture
Page 9
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

 Interface representation

 Algorithmic details
The requirements are translated in some easy to represent form using which coding can be done
effectively and efficiently. The design needs to be documented for further use.
Coding is a step in which design is translated into machine-readable form. If design is done in
sufficient detail then coding can be done effectively. Programs are created in this phase.
Testing begins when coding is done. While performing testing the major focus is on logical
internals of the software. The testing ensures execution of all the paths, functional behaviors. The
purpose of testing is to uncover errors, fix the bugs and meet the customer requirements.
Maintenance is the longest life cycle phase. When the system is installed and put in practical use
then error may get introduced, correcting such errors and putting it in use is the major purpose
of maintenance activity. Similarly, enhancing system's services as new requirements are
discovered is again maintenance of the system.
This model is widely used model, although it has many drawbacks. Let us discuss benefits and
drawbacks.
Benefits of waterfall model
(i) The waterfall model is simple to implement.
(ii) For implementation of small systems waterfall model is useful.

Drawbacks of waterfall model

There are some problems that are encountered if we apply the waterfall model and those are:
a. It is difficult to follow the sequential flow in software development process. If some changes are
made at some phases then it may cause some confusion.
b. The requirement analysis is done initially and sometimes it is not possible to state all the
requirements explicitly in the beginning. This causes difficulty in the project.
c. The customer can see the working model of the project only at the end. After reviewing of the
working model. If the customer gets dissatisfied then it causes serious problems.
d. Linear nature of waterfall model induces blocking states, because certain tasks may be
dependent on some previous tasks. Hence it is necessary to accomplish all the dependant tasks first.
It may cause long waiting time.

EXAMPLE
6. Explain how waterfall model is applicable for the development of the following systems:
a) University accounting system
b) Interactive system that allows railway passengers to find time and other information for the
terminals installed in the station.
Page 10
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Provide three examples of software projects that would be amenable to the waterfall model,
prototyping and incremental. Be specific. (Nov/Dec 2024)
a) University accounting system: If the software developers who have the experience in developing
the account systems then building university account system based on existing design could be easily
managed with water-fall model.
b) Interactive system that allows railway passengers to find time and other information from the
terminals installed in the station.
For developing such interactive system, all the requirements must be correctly identified and
analyzed before the designing of the project. The requirements of end-users must be correctly and un-
ambiguously understood by the developers prior to design phase. Once the requirements are well
defined then using disciplined design, coding and testing phases the required system can be built
using water-fall model.
Incremental Process Model
In this model, the initial model with limited functionality is created for user’s understanding about the
software product and then this model is refined and expanded in later releases.
Incremental Model
The incremental model has same phases that are in waterfall model. But it is iterative in nature.
The incremental model has following phases.
1. Analysis 2. Design 3. Code 4. Test
The incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.

Figure 07: The Incremental Model

The first increment is called core product. In this release the basic requirements are
implemented and then in subsequent increments new requirements are added.
The word processing software package can be considered as an example of incremental model. In the
first increment only, the document processing facilities are available. In the second increment, more
Page 11
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
sophisticated document producing and processing facilities, file management functionalities are
given. In the next increment spelling and grammar checking facilities can be given. Thus, in

incremental model progressive functionalities are obtained with each release.

Why to choose it?
1. When requirements are reasonably well-defined.
2. When overall scope of the development effort suggests a purely linear effort.
3. When limited set of software functionality needed quickly.
Merits of incremental model
1. The incremental model can be adopted when there are a smaller number of people involved in
the project.
2. Technical risks can be managed with each increment.
3. For a very small-time span, at least core product can be delivered to the customer.

RAD Model
The RAD Model is a type of incremental process model in which there is extremely short
development cycle.
When the requirements are fully understood and the component basedconstruction approach
is adopted then the RAD model is used.
Using the RAD model, the fully functional system can be developed within 60 to 90 days.
Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or
Construction and finally Deployment.
Multiple teams work on developing the software system using RAD model parallel.
In the requirements gathering phase the developers communicate with the users of the system
and understand the business process and requirements of the software system.
During analysis and planning phase, the analysis on the gathered requirements is made and a
planning for various software development activities is done.
During the design phase various models are created. Those models are Business model, data
model and process model.

The build is an activity in which using the existing software components and automatic code
generation tool the implementation code is created for the software system. This code is well
tested by its team. The functionalities developed by all the teams are integrated to form a whole.
Finally, the deployment of all the software components (created by various teams working on the
project is carried out.

Page 12
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Figure 08: Rapid application

Development Drawbacks of rapid application development
a) It requires multiple teams or large number of people to work on the scalable projects.
b) This model requires heavily committed developer and customers. If commitment is lacking then RAD
projects will fail.
c) The projects using RAD model requires heavy resources.
d) If there is no appropriate modularization then RAD projects fail performance can be problem to such
projects.
e) The projects using RAD model find it difficult to adopt new technologies.

EXAMPLE
(i). Which type of applications suit for RAD model? Justify your answer.
Solution: The RAD model is suitable for information system applications, business applications and for
the systems that can be modularized because of following reasons -
a) This model is similar, to waterfall model but it uses very short development cycle.
b) It uses component-based construction and emphasizes reuse and code generation
c) This model uses multiple teams on scalable projects.
d) The RAD model is suitable for the projects where technical risks are not high:
e) The RAD model requires heavy resources.
(ii). Provide three examples of software projects that would be amenable to incremental model.
Be specific.
Solution: There can various examples of software projects that would be amenable to incremental
model. For instance -

Page 13
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
a) Banking software service: This service can be personal service. That means for personal banking
system the incremental model can be used. In later state of increments, this system can implement
insurance service, home loans and some other features of banking services.
b) Web browser application: The base application can be developed and distributed. This is the basic
increment of the application. In the later increments the plugins can be provided to enhance the
experience of web browser applications.
c) Operating system software: The operating system software providing the basic system handling
functionalities is the first increment. After the release of the basic versions then updates or security
patches are provided to the customer in the form of increments. Various distribution package in the form
of versions such as basic home edition, premium, ultimate and so on can be the increments of operating
system software.

Evolutionary Process Model

While developing the software systems, it is often needed to make modifications in earlier
development phases or the tasks sets. If the development process is linear or in a straight line (from
requirements gathering to deployment then the end product will be unrealistic. In such cases, the
iterative approach needs to be adopted. The evolutionary process model is iterative model.
Prototyping
In prototyping model initially, the requirement gathering is done.
Developer and customer define overall objectives; identify areas needing more requirement
gathering.
Then a quick design is prepared. This design represents what will be visible to user in input and
output format.
From the quick design a prototype is prepared. Customer or user evaluates the prototype in order
to refine the requirements. Iteratively prototype is tuned for satisfying customer requirements.
Thus prototype is important to identify the software requirements.

Figure 09: Prototyping

Page 14
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
When working prototype is built, developer use existing program fragments or program
generators to throw away the prototype and rebuild the system to high quality.
Certain classes of mathematical algorithms, subset of command driven systems and other
applications where results can be easily examined without real time interaction can be developed
using prototyping paradigm.
When to choose it?
Software applications that are relatively easy to prototype almost always involve Human-machine
Interaction (HCI) the prototyping model is suggested.
A general objective of software is defined but not detailed input, processing or output
requirements. Then in such a case prototyping model is useful.

When the developer is unsure of the efficiency of an algorithm or the adaptability of an operating
system then prototype serves as a better choice.
Drawbacks of prototyping
a) In the first version itself, customer often wants "few fixes" rather than rebuilding of the system
whereas rebuilding of new system maintains high level of quality.
b) The first version may have some compromises.
c) Sometimes developer may make implementation compromises to get prototype working quickly. Later
on developer may become comfortable with compromises and forget why they are inappropriate.
Comparison between prototyping and incremental process model
Sl.
Prototyping Incremental process model
No.
Some requirements are gathered initially, The requirements are precisely defined and there is
but there may be change in requirements no confusion about the final product of the software.
(i)
when the working prototype is shown to
the customer.
The development team has adequate The development team with less domain knowledge
domain knowledge. Similarly they can can be accommodated due to iterative nature of this
(ii)
adopt the mew technologies is product model. The change in technology in the later phase
demands. cannot be tolerated.
All the end users are involved in all phases All the end users need not be involved in all the
(iii)
of development. phases of development.
There can be use of reusable software There is no use of reusable components in
(iv) components in project development development process.
process.

Page 15
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Spiral Model
8. Assume that you are the technical manager of a software development organization. A client
approached you for a software solution. The problems stated by the client have uncertainties which
lead to loss if it not planned and solved. Which software development model you will suggest for this
project – justify. Explain that model with its pros and cons with neat sketch. (Nov/Dec 2018)
Outline the spiral life cycle model with a diagram. (Nov/Dec 2019)
This model possesses the iterative nature of prototyping model and controlled and systematic
approaches of the linear sequential model.
This model gives efficient development of incremental versions of software. In this model, the
software is developed in series of increments.
The spiral model is divided into a number of framework activities. These framework activities
are denoted by task regions.
Usually there are six tasks regions.
Spiral model is realistic approach to development of large-scale systems and software. Because
customer and developer better understand the problem statement at each evolutionary level
Also risks can be identified or rectified at each such level.
In the initial pass, product specification is built and in subsequent passes around the spiral the
prototype gets developed and then more improved versions of software gets developed.
During planning phase, the cost and schedule of software can be planned and adjusted based on
feedback obtained from customer evaluation.
In spiral model, project entry point axis is defined. This axis represents starting point for
different types of projects.

Figure 10: Spiral Model

Page 16
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

For instance, concept development project will start at core of spiral and will continue along the
spiral path. If the concept has to be developed into actual project then at entry point 2 the product
development process starts. Hence entry point 2 is called product development project entry
point. The development of the project can be carried out in iterations.
The task regions can be described as:
i) Customer communication - In this region, it is suggested to establish customer communication.
ii) Planning - All planning activities are carried out in order to define resources time line and other
project related activities.
iii) Risk analysis - The tasks required calculating technical and management risks are carried out.
iv) Engineering - In this task region, tasks required to build one or more representations of
applications are carried out.
v) Construct and release - All the necessary tasks required constructing, testing, install the application
are conducted, some tasks that are required to provide user support are also carried out in this task
region.
vi) Customer evaluation - Customer’s feedback is obtained and based on customer evaluation required
tasks are performed and implemented at installation stage.
In each region, number of work tasks is carried out depending upon the characteristics of project.
For a small project relatively small numbers of work tasks are adopted but for a complex project
large number of work tasks can be carried out.
In spiral model, the software engineering team moves around the spiral in a clockwise
direction beginning at the core.
Advantages of spiral model
a) Requirement changes can be made at every stage.
b) Risks can be identified and rectified before they get problematic.
Drawbacks of spiral model
a) It is based on customer communication. If the communication is not proper then the software
product that gets developed will not be up to the mark.
b) It demands considerable risk assessment. If the risk assessment is done properly then only the
successful product can be obtained.
When to choose it?
a) When the prototypes for the software functionality are needed.
b) When requirements are not very clearly defined or complex.
c) When the large or high budget projects need to be developed.
d) When the risk assessment is very critical and essential

Page 17
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

e) When project is not expected within a specific limited time span.

Comparison between spiral model and prototyping model
Sl.No. Spiral Model Prototyping Model
The development team with less domain The development team has adequate
knowledge can be accommodated due to iterative domain knowledge. Similarly they can
(i)
nature of this model. The change in technology in adopt the new technologies if product
the later phase cannot be tolerated. demands.
All the end users need not be involved in all the All the end users are involved in all phases
(ii)
phases of development. of development.
Funding is not stable for the projects that can be Funding is stable for these types of projects.
(iii)
developed using spiral model.
The requirements that are gathered and analyzed Some requirements are gathered initially
are high reliability requirements. but there may be change in requirements
(iv)
when the working prototyping is shown to
the customer.
Difference between waterfall model and spiral model
Sl.No. Waterfall Model Spiral Model
It requires well understanding of It is developed in iterations. Hence the
(i)
requirements and familiar technology requirements can be identified at new iterations
Difficult to accommodate changes after the The required changes can be made at every
(ii)
process has started stage of new version
(iii) Can accommodate iteration but indirectly It is iterative model
Risk can be identified at the end which may Risks can be identified and reduced before they
(iv)
cause failure to the product get problematic
The customer can see the working model of The customer can see the working product at
the project only at the end. After reviewing the certain stages of iterations
(v)
working model. If the customer gets
dissatisfied it causes serious problem
(vi) Customers prefer this model Developers prefer this model
(vii) This model is good for small systems This model is good for large model
(viii) It is sequential nature It has evolutionary nature

Page 18
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Concurrent Development Model

The concurrent development model is also called as concurrent engineering.
In this model, the framework activities or software development tasks are represented as states.
The modeling or designing phase of software development can- be in one of the states like under
development, waiting for modification, under revision or under review and so on.

Figure 11: Concurrent development model

All the software development activities exist concurrently in this model but these activities can be
in various states.
These states make transitions. That is during modeling, the transition from under development
state to waiting for modification state occurs.
This model basically defines the series of events due to which the transition from one state to
another state occurs. This is called triggering. These series of events occur for every software
development activity, action or task.
This model defines various activities that occur concurrently and a network, of activities is
defined.
Advantages
a) All types of software development can be done using concurrent development model.
b) This model provides accurate picture of current state of project.
c) Each activity or task can be carried out concurrently. Hence this model is an efficient process model.

Page 19
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

COMPARE LIFE CYCLE MODEL

9. Compare the water fall, prototyping and spiral model. List the features of each model.
Advantagesand disadvantages and a type of applications where the model will be acceptable.
(Apr/May 2019)
Water fall model Spiral model Prototyping model Incremental model
Requirements must The requirement Requirement analysis Requirement analysis
be clearly understood analysis and gathering can be made in the later can be made in the later
and defined at the can be done in stages of the stages of the development
beginning only. iterations because development cycle cycle.
requirements get requirements get
changed quite often. changed quite often.
The development The development The development team The development team
team having the team having less having less experience of having the adequate
adequate experience of experience of working working on the similar experience of working on
working on the similar on the similar projects projects is allowed in the similar project is
project is chosen to is allowed in this this process model. chosen to work on this
work on this type of process model. type of process model.
process model.
There is no user There is no user There is user There is user
involvement in all the involvement in all the involvement in all the involvement in all the
phases of the phases of the phases of the phases of the
development process. development process. development process. development process.
When the Due to iterative nature When developer is When the requirements
requirements are of the model the risk ensure about the are reasonably well
reasonably well identification and efficiency of an defined and the
defined and the rectification is done algorithm or the development effort
development effort before they get adaptability of an suggests purely linear
suggests a purely problematic. Hence the operating system then effort. When limited set
linear effort then the handling real time the prototyping model is function is need quickly
waterfall model is problems the spiral chosen. then incremental model
chosen. model is chosen. chosen.

Page 20
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

EXAMPLE
10. For the scenario describe below, which life cycle model would choose? Give the reason why
you choose this model.
You are interacting with the MIS department of a very large oil company with multiple
departments. They have a complex legacy system. Migrating the data from this legacy system is
not easy task and would take a considerable time. The oil company is very particular about
processes, acceptance criteria and legal contracts. (Nov/Dec 2011)
Solution:
Legacy applications are database management systems. The software companies normally
migrate these applications to some relational databases. For data migrating projects a cohesive method
that enables the developer to cycle or spiral through the migration process is required. In this
migrating process following steps need to be followed -
a) Analyze the data.
b) Extract the data which is to be transformed.
c) Transform the extracted data.
d) Validate the transformed data.
e) Load the validated data to the target system.
These above mentioned steps are repeated until the migration is successfully completed. The risk
management must be done properly. All these factors suggest that the spiral model is suitable for the
given project.
11. Describe at least one scenario where. (Nov/Dec 2011)
a) RAD model would be applicable and not the water fall model.
b) Waterfall model is preferable to all other models.
Solution:
a) RAD model would be applicable and not the waterfall model:
Following are some scenario where RAD model would be applicable and not the waterfall
model.
A) The projects in which users are involved in all phases.
B) The projects in which users are experts of problem domain.
C) The project is enhancement of existing system.
b) Waterfall model is preferable to all other models:
In- the following scenario waterfall model is preferable to all other models. The project for which
requirements are easily understandable and defiled.

Page 21
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Specialized Model
The specialized models are used when only collection of specialized technique or methods
are expected for developing the specific software.
Various types of specialized models are -
1. Component based development
2. Formal methods model
3. Aspect oriented software development
Component Based Development
The commercial off-the-shelves components that are developed by the .vendors are used during
the software built.
These components have specialized targeted functionalities and well defined interfaces. Hence it is
easy to integrate these components into the existing software.
The component based development model makes use of various characteristics of spiral model.
This model is evolutionary in nature. That means the necessary changes can be made in the
software during the each iteration of software development cycle.
Before beginning the modeling and construction activity of software development the candidate
component must be searched and analyzed. The components can be simple functions or can be
object oriented classes or methods.
Following steps are applied for component-based development -
Identify the component- b a s e d products and analyze them for fitting in the existing application
domain.
Analyze the component integration issues.
Design the software architecture to accommodate the components
Integrate the components into the software architecture.
Conduct comprehensive testing for the developed software.
Software reusability is the major advantage of component-based Development.
The reusability reduces the development cycle time and overall cost.
Formal Methods Model
What are the merits and demerits of using formal methods for developing software? (Nov/Dec 2018)
This model consists of the set of activities in which the formal mathematical specification is
used.
The software engineers specify, develop and test the computer based systems using the
mathematical notations. The notations are specified within the formal methods.

Page 22
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Cleanroom software engineering makes use of the formal method approach.

The advantage of using formal methods model is that it overcomes many problems that we
encounter in traditional software process models. Ambiguity, incompleteness and
inconsistency are those problems that can be overcome if we use formal methods model.

The formal methods model offers defect-free software. However, there are some drawbacks of
this model which resists it from getting used widely. These drawbacks are
 The formal methods model is time consuming and expensive.
 For using this model, the developers need the strong mathematical background or
some extensive training.
 If this model is chosen for development then the communication with customer becomes
very difficult.

Aspect Oriented Software Development

In traditional software development process, the system is decomposed into multiple units of
primary functionality but there are other issues of concern that do not fit into these primary
functionalities. Later on, this becomes programmers’ duty to code modules corresponding to the
primary functionality and to incorporate all other concerned issues wherever appropriate.
Programmers need to keep in mind all the things that need to be done, how to deal with each
issue, the problems associated with them and the correct execution. Due to these concerns there
are chances of appearing serious problems during application development and maintenance.
The coding process for realizing a concern becomes very critical.
Aspect-Oriented Software Development focuses on the identification, specification and
representation of cross-cutting concerns and their modularization into separate functional
units as well as their automated composition into a working system.
Aspectual requirements define these cross-cutting concerns that have impact on the software
architecture.
Aspect Oriented Software Development (AOSD) is often referred as Aspect oriented
programming.
It is a relatively new software engineering paradigm and is not matured enough. But is likely that
it will adopt the characteristics of both the spiral and concurrent process models.

Page 23
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

EXAMPLE
12. What are the pros and cons of using mathematical approach for software development?
( Nov/Dec 2015)
Solution:
Pros:
 The mathematical approach is useful in building scientific model, critical systems or simulation of real
time systems. '
 The ambiguity or inconsistency problems can be eliminated if mathematical approach is adopted.
 Developers are exceptionally committed to the project.
 The controlled and optimized system can’ be developed using mathematical approach.
Cons:
 The developers need the strong mathematical background or some extensive training.
 The methods of software development are time consuming and expensive.
 Many times-if mathematical approach is adopted for software development, then communication with
customer becomes very difficult.

13. Compare the following life cycle model based on their distinguish factors, strength and weakness
– waterfall model, RAD model, spiral model and formal method model. (Nov/Dec 2013), (Nov/Dec
2014), Elucidate the key features of the software process model with suitable example. (Apr/May
2016)
Water fall model RAD model Spiral model Formal methods
model
Requirements must be Requirements must be The requirement Requirements must be
clearly understood and clearly understood and analysis and gathering clearly understood and
defined at the beginning defined at the beginning can be done in iterations defined at the beginning
only only because requirements only
gets changed quite often
The development The development The development team The development
team having the team having less having less experience of team having the
adequate experience of experience of working working on the similar adequate experience of
working on the similar on the similar projects projects is allowed in this working on the similar
project is chosen to is allowed in this process model project is chosen to
work on this type of process model work on this type of
process model process model

Page 24
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
If the development team If the development If the development team If the development
has less domain team has less domain has less domain team has less domain
knowledge or if it new knowledge or if it new knowledge or if it new to knowledge or if it new
to the technology then to the technology then the technology then such to the technology then
such a team is allowed such a team is not a team is allowed for this such a team is not
for this kind of process allowed for this kind of kind of process model allowed for this kind of
model process model process model
There is no user There is user There is no user Limited community
involvement in all the involvement in all the involvement in all the makes the formal
phases of the phases of the phases of the methods for their
development process development process development process projects because this
method is based on
mathematical theorem,
formal methods and
automata theory
Type of projects: When there is tight Due to iterative nature of Whenever there is a
When the project schedule or the model the risk need to build the
requirements are project is identification and scientific model based
reasonably well enhancement of the rectification is done on mathematical
defined and the existing projects or if before they get techniques or
development effort there is use of reusable problematic. Hence the simulation of some real
suggests a purely linear components in the handling real time time systems or when
effort then the waterfall project then for problems the spiral there is a need to build
model is chosen developing such model is chosen the systems that can
projects this process contribute to the
model is suitable reliability and
robustness (normally
critical systems) then
the formal method
model are used.

Page 25
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

INTRODUCTION TO AGILITY
14. List the principles of agile software development. (Nov/Dec 2016)Define agility. List the five
principles of agility.( Apr/May 2019) What is agility? Elaborate agility principles. (Nov/Dec 2019)
The Agile Manifesto, also called the Manifesto for Agile Software Development, is a formal
declaration of four key values and 12 principles to guide an iterative and people-centric
approach to software development.
The agile methods were developed to overcome the weakness of conventional software
engineering.

Figure 12: Agile manifesto

Agile Process
In 1980's the heavy weight, plait-based software development approach was used to develop
any software product.
In this approach too many thing are done which were not directly related to software product
being produced.
This approach was rigid. That means if requirements get changed, then rework was essential.
Hence new methods were proposed in 1990's which are known as agile processes.
The agile processes are the light-weight methods are people-based rather than plan-based
methods.
The agile process forces the development team to focus on software itself rather than design and
documentation.
The agile process believes in iterative method.
The aim of agile process is to deliver the working model of software quickly to the customer.
For example: Extreme programming is the best known of agile process.

Page 26
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Conventional Software Development Methodology

As the software project makes the progress, the cost of the changes increases non linearly.
It is easy to accommodate changes during the requirement gathering stag. At this stage to
accommodate the changes - usage scenarios are modified, list of functions can be extended, or
written specification be edited.
As the progresses and if the customer suggests the changes during the testing phase of the
software development life cycle then to accommodate these changes the architectural design
needs to be modified and ultimately these changes will affect other phases of software
development cycle. These changes are actually costly to execute.
Agile Methodology
The agile method proponents claim that if the software development is carried out using the agile
approach then it will allow the software team to accommodate changes late in a software project
without dramatic cost and time impact.
In other words, if the incremental delivery is combined with agile practices such as continuous
unit testing and pair programming then the cost of changes can be controlled.
The following graph represents the how the software development approach has a strong
influence on the development cost due to changes suggested.

Figure 13: Influence of software development approach on

agile process AGILE PRINCIPLES
There are famous 12 principles used as agility principles -
a) Satisfy the customer by early and continuous delivery of valuable software.
b) The changes in the requirements must be accommodated. Even though the changes occur late in
the software development process, the agile process should help to accommodate them.
c) Deliver working software quite often within the shorter time span deliver the working unit.
d) Business people and developers must work together throughput the project.

Page 27
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

e) Motivate the people who are building the projects. Provide the environment and support to the
development team and trust them for the job to be done.
f) The working software is the primary measure of the progress of the software development.
g) The agile software development approach promotes the constant project development. The
constant speed for the development of the product must be maintained.
h) To enhance the agility there should be continuous technical excellence.
i) The proper attention to be given to technical excellence and good design,
j) The simplicity must be maintained while developing the project using this approach.

k) The teams must be the self-organizing team for getting best architecture, requirements and
design.
l) At regular intervals the team thinks over the issue of becoming effective. After the careful review
the team members adjusts their behavior accordingly.

Extreme Programming
15. Explain the phases of XP. (or) Name two core values of Extreme Programming. (Apr/May
9)(APR/MAY 2024) (Nov/Dec 2024)

Extreme Programming (XP) is one of the best-known agile processes. It is suggested by Kent Beck
in 2000.
XP Values
Beck defined the set of five values that serve as a basis for the work performed in XP. These values
are -
a) Communication: The effective communication must be established between software developers and
stakeholders in order to convey the important concepts and to get the important feedback.
b) Simplicity: XP focuses on the current needs instead of futures needs to incorporate in the design.
Hence the XP believes that the Software design should be simple.
c) Feedback: The feedback for the software product can be obtained from the developers of the software,
customers, and other software team members.
d) Courage: The strict adherences to certain XP practices require courage. The agile XP team must be
disciplined to design the system today, recognize the future requirements and make the changes
dramatically as per the demand.
e) Respect: By following the above states XP values the agile team can win the respect of stakeholders.

Page 28
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Process: Define “test driven development” (TDD) and its role in XP. (Nov/Dec 2024)
The extreme programming process is explained as follows -
Customer specifies and priorities the system requirements. Customer becomes one of the
important members of development team. The developer and customer together prepare a story-
card in which customer needs are mentioned.
The developer team then aims to implement the scenarios in the story-card.
After developing the story-card the development team breaks down the total work in small tasks.
The efforts and the estimated resources required for these tasks are estimated.
The customer priorities the stories for implementation. If the requirement changes then
sometimes unimplemented stories have to be discarded. Then release the complete software in
small and frequent releases.
For accommodating new changes, new story-card must be developed.
Evaluate the system along with the customer.

Figure 14: XP Process

XP Principles Description
Instead of creating a large requirement document
User story cards user stories are written by the customer in which,
what they need is mentioned.
A release plan for overall project is prepared
Release planning from which the iteration plan can be prepared for
Planning
individual iteration
The developer breaks down the user stories into
Small release small release and a plan for releasing the small
functionalities is prepared
Iterative process Divide the development work into small

Page 29
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

iterations. Keep the iteration of nearly constant

length. Iterative development helps in quick or
agile development
The stand up meeting must be conducted for the
Stand up meetings
current outcomes of the project
Simple design always takes less time than
Simple design complex design. It always good to keep the things
simple to meet the current requirements
For answering the tough technical problems
Spike solution create the spike solutions. The goal of these
Designing
solutions should be reduced te technical risks
Refactoring means reductions in the redundancy
eliminating of unused functionalities redesign the
Refactoring
obsolete designs. This will improve the quality of
the project
The most essential requirement of the XP is
availability of the customer. In extreme
Customer availability programming the customer not only helps the
developer team but it should be the part of the
project
All the code be included in the project must be
coded by groups of two people working at the
Coding Paired programming
same computer. This will increase the quality of
the coding.
By having collective code ownership approach
the everyone contributes new ideas and not any
Collective code
single person becomes the bottle neck of the
ownership
project. Anyone can change any line of the code to
fix a bug or to refactor
The test first – development is done in XP. The
Testing test framework that contains the automated test
Unit testing
case suite is used to test the code. All the code
must be tested using unit testing before release

Page 30
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

As soon as one task is finished integrate into the

Continuous
whole system. Again after such integration unit
integration
testing must be conducted
Workings overtime lose the sprit and motivation
of the team. Conduct the release planning
No overtime
meeting to changes the project scope or to
reschedule the project

As mentioned earlier in Extreme Programming instead of creating large requirement documents

the user story-card is prepared. For example: If a project is for creating a banking software then
the sample story card can be prepared as follows -
1. .Customer makes the balance enquiry.
2. Customer withdraws some amount.
3. Customer deposits some amount.

Tests and XP

Communication : Test talk to teams.

Simplicity : Tests should be well structured and readable to ensure simplicity

Feedback: Tests turn red to green with feedback about the code

Courage: Tests give courage to refactor

Respect: Tests should be treated with the same respect as code

Example
16. What is spike solution in XP?
The Extreme Programming (XP) is one of the known agile processes. In this process, to answer complex
and difficult technical or design problems spike solution is created.
The spike solution is very simple program to explore potential solution. The spike is builds to only
address the problem under examination and all other things can be overlooked.
The spike solution reduces the risk of technical problem and increases the reliability of user story's
estimate.
Industrial XP
The industrial XP (IXP) can be defined as the organic evolution of XP. It is customer centric. It has
expanded role for customers and advanced technical practices.
Various new practices that are appended to XP to create IXP are as follows –

Page 31
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

a) Readiness Assessment: In this assessment, following issues are assessed -

i. Proper environment must be available to support XP.
ii. Team should contain appropriate and skilled stakeholder
iii. The organization should support quality programs and continuous improvement.
iv. The organizational culture should support new values of agile team.

b) Project Community: Skilled and efficient people must be chosen as the agile team members for the
success of the project. The team is referred as the community when extreme programming approach is
considered. The project community consists of technologies, customers, and other stakeholders who play
the vital role for the success of the project. The role of the community members must be explicitly
defined.
c) Project Chartering: Project chartering means assessing the justification for the project as a business
application. That means, the IXP team assess whether the project satisfies the goals and objectives 'of the
organization.
d) Test Driven management: For assessing the state of the project and its progress the industrial XP
needs some measurable criteria. In test driven management the project is tested with the help of these
measurable criteria.
e) Retrospectives: After delivering the software increment, the specialized review is conducted which is
called as retrospective. The intention of retrospectives is to improve the industrial XP process.
f) Continuous learning: The team members are inspired and. encouraged to learn new methods and
techniques that can improve the quality of the product.

CASE STUDY: AUTOMATIC A LAW OFFICE

The Leaders of a software company realized that law offices such as title companies were poorly
automated. At most, these offices used general-purpose word processors and possibly, some package for
computing invoices or the payroll.
Legal documents could be prepared much more efficiently with such a tool because this can follow
some standard rules. Many sales agreements could be expressed tentatively in the following terms:

a) Write the standard header of the document.

b) Write the relevant data about the seller. (Data necessary to identify the person)

c) If the seller is married, the data about the spouse should also be included. This action should be
done automatically.

Page 32
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE
d) The same procedure must be followed for the buyer.

e) Some particular data should be typed explicitly, filled in automatically from files, and computed
automatically on the basis of other data.
The analysis of riles of this type, combined with the fact that the company had a strong experience
in sophisticated word-processing tools and with the facts that potential customers were generally
wealthy and no strong competitors existed yet in the market, convinced the leaders of the company
that developing a tool for automating law offices could be good business.
Thus, the company’s first decision was to contact a sample of potential customers to see whether
they would be interested in such a product and which features would be desirable.
The company’s behavior seems quite natural, but it contains a first, serious mistake: see later that
the selected sample of potential customers was biased. In both cases of contact, the people were
already familiar with and fairly supportive of the benefits of automation. There is no evidence, this
attitude is representative of the whole profession.
The interaction between technical and nontechnical knowledge in the feasibly study of software
projects. This early analysis of the potential market for the software product was conducted
nonscientifically for probably two kinds of reasons.
Reason (i): Market analysis techniques have difficulty dealing with ill-defined markets. It is
difficult or even impossible to plan a software product on the basis of the same considerations.
One uses when examining a project to build a new car or a new washing machine
model. In this case, “the planned software product was intended to create a new market “and
required analysis of a nonexistent market.
Reason (ii): The marketing analysis was performed by “pure software engineers” who had little
or no background in the marketing field, but who exhibited a “pioneering” attitude.
While innovation and pioneering in the places, cannot form the basis of a discipline
and certainly not the basis of a product development schedule.
Economic and Financial Planning

 Economic and financial planning is another area in which strong interaction between
engineering and nonengineering skills is needed in the planning of a product.

 Economic and financial planning requires both the ability to forecast future sales.

 The design phase of any product, what sets apart is that the “design phase” for software is
not a relatively short period at the beginning of development, but seems to go on
throughout the entire development process.

 The person making the cost estimates who is usually not an engineer.

Page 33
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

 In this case study, the difficulties of making estimates in both areas are well known, the
major error and very common error was the lack of risk analysis.

 All original estimates were terribly wrong, nobody suggested a plan of action. Need to
spend much more money than originally planned.

 The result was that in a short time, the company was in serious financial trouble.

 This management mistake is a very common one. It is naturally explained by the fact that
short-term decisions overcome long term planning.

Technical Planning and Management

 At the start of the project, it would have been wise to write clear and precise documents
stating the requirements for the new product.

 These documents should have been based on a careful and organized interaction with
potential users, paying close attention to choosing a representative sample of the user
population.

 A limited effort into the development of a system that would act as a prototype. The prototype
system would then help assess the most critical issues and derive firm requirements by
observing users’ reactions when using the system.

 Unfortunately, the designers did not even realize that a problem existed, and therefore, they
did not even consciously choose between the first alternative-specifying requirements
carefully-and the second-developing a fast, exploratory prototype.

 Similarly, careful planning of resource allocation should have started, both from the point of
view of work assignment to designers and programmers and from the point of view of physical
resource management (e.g., hardware acquisition and office space). But instead, just the
opposite happened.

 An amusing but dangerous “game” started between the designers and the very few
representative clients. In this case, of course the designers included the company leaders, since
they were technical people and they had originated the idea of the product in the first place.

 In fact, everybody was excited with the innovative and challenging features of the product, but
nobody paid much attention to fairly obvious but critical details.

 For a long time, nobody paid attention to the definition of suitable user interfaces to facilitate
the interaction of nontechnical people-a lawyer or a secretary-with the system.
Page 34
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

 Similarly, sophisticated features for the automatic computation of invoices on the basis of
input data (people time, service value, travel expenses, etc.), were designed, but no attention
was paid to standard office operations such as the filing of large numbers of documents (e.g.,
records of automobile sales-in some offices, several hundreds of such documents are produced
every day).
 From a management point of view, all of the designers of the system were attracted by the
most interesting features of the new product, so that a lot of work was done in the early phases
to find and to compare clever solutions to marginal problems, and no structure was arranged
for the design team.
From a technical viewpoint, many typical mistakes were made:

 No analysis was performed to determine whether all the product features were needed by all
users, or whether it would be better to restructure the functionality of the product based on

different classes of users. More generally, no effort was put into determining which qualities of
the product were most critical for its success.

 For instance, in the choice of the hardware and of the development software (the operating
system, programming language, etc.), little or no attention was paid to their evolution, and no
effort was made to prepare for possible changes to them.

 No “design for change” was done, i.e., no design decision was influenced by any analysis of
which parts of the product were likely to change during the product’s lifetime (e.g., how might
possible changes in the law affect product requirements?).

 Strong pressure was applied to have some (any) code running as early as possible.

 No precautions were taken to minimize damages due to personnel turnover.

Project Monitoring

 After six months after the start of development, some mistakes became apparent, both from a
technical and from a management point of view.

 A modular architecture would have been preferable, even from the user point of view, allowing
the product to be customized for different classes of users, just as the same “skeleton” of a car
can be sold with different types of engines with different optional features, etc., or the same
personal computer can be sold with many optional features-e.g., a color monitoring or a
floating-point coprocessor.

Page 35
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

 The reaction to this situation was even worse than the problem itself: the impact of the
mistakes-both technical and nontechnical-was again underestimated.

 In general, the attitude was of the following type: “OK, we made a few mistakes, but now we
are almost done. So, let’s put in a little more effort, and we will complete the product soon and
will start earning money.”
 That is, no critical and careful analysis of the mistakes was made, nor was a serious replanning
and redesign of the whole project attempted. There was only a generic claim of an intuitive confidence
in being close to the end.
Initial Delivery

 It was decided that income could be generated as soon as the company started delivering the
first versions of the product or as soon as new contracts could be signed.

 In turn, the customers would be good references for the product, resulting in an opportunity
both to improve the product and to increase the sales of the product.
Partial Recovery

 Eventually, it was realized that the naive way the firm was managing the project was leading to
disaster.

 Thus, a real effort was made, first to define responsibilities clearly (who was responsible for
the design, who was responsible for the distribution, etc.), and second, to achieve a clear
picture of the state of the product, of its weakness, of the effort required to fix them, etc.

 This was done even at the expense of slowing down the project, increasing costs, and reducing
sales. Thus, people had to resist an initial feeling that the restructuring of the project was
impeding “real” progress.
11. (b) Illustrate an overview of Object-oriented Software Engineering Development Activities
and their products. (Apr/May 2024)
Software Engineering Development Activities
In this section, we give an overview of the technical activities associated with object-oriented
software engineering. Development activities deal with the complexity by constructing and
validating models of the application domain or the system. Development activities include
 Requirements Elicitation

 Analysis

 System Design

 Object Design
Page 36
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

 Implementation

 Testing

1. Requirements Elicitation
During requirements elicitation, the client and developers define the purpose of the system. The
result of this activity is a description of the system in terms of actors and use cases. Actors
represent the external entities that interact with the system. Actors include roles such as end

users, other computers the system needs to deal with (e.g., a central bank computer, a network),
and the environment (e.g., a chemical process). Use cases are general sequences of events that
describe all the possible actions between an actor and the system for a given piece of functionality.
2. Analysis

During analysis, developers aim to produce a model of the system that is correct, complete,
consistent, and unambiguous. Developers transform the use cases produced during requirements
elicitation into an object model that completely describes the system. During this activity,
developers discover ambiguities and inconsistencies in the use case model that they resolve with
the client. The result of analysis is a system model annotated with attributes, operations, and

3. System Design

During system design, developers define the design goals of the project and decompose the
system into smaller subsystems that can be realized by individual teams. Developers also select
strategies for building the system, such as the hardware/software platform on which the system
will run, the persistent data management strategy, the global control flow, the access control
policy, and the handling of boundary conditions. The result of system design is a clear description
of each of these strategies, a subsystem decomposition, and a deployment diagram representing
the hardware/software mapping of the system. Whereas both analysis and system design produce
models of the system under construction, only analysis deals with entities that the client can
understand. System design deals with a much more refined model that includes many entities that
are beyond the comprehension (and interest) of the client
4. Object Design

During object design, developers define solution domain objects to bridge the gap between the
analysis model and the hardware/software platform defined during system design. This includes
precisely describing object and subsystem interfaces, selecting off-the-shelf components,
restructuring the object model to attain design goals such as extensibility or understandability,
Page 37
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

and optimizing the object model for performance. The result of the object design activity is a
detailed object model annotated with constraints and precise descriptions for each element.

5. Implementation

During implementation, developers translate the solution domain model into source code. This
includes implementing the attributes and methods of each object and integrating all the objects
such that they function as a single system. The implementation activity spans the gap between the
detailed object design model and a complete set of source code files that can be compiled. We
describe the mapping of UML models to code in Chapter 10, Mapping Models to Code. We assume
the reader is already familiar with programming concepts and knows how to program data
structures and algorithms using an object-oriented language such as Java or C++.
6. Testing

During testing, developers find differences between the system and its models by executing the
system (or parts of it) with sample input data sets. During unit testing, developers compare the
object design model with each object and subsystem.

During integration testing, combinations of subsystems are integrated together and compared
with the system design model. During system testing, typical and exception cases are run through
the system and compared with the requirements model.

The goal of testing is to discover as many faults as possible such that they can be repaired before
the delivery of the system. The planning of test phases occurs in parallel to the other development
activities: System tests are planned during requirements elicitation and analysis, integration tests
are planned during system design, and unit tests are planned during object design.

Page 38
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

UNIT – I – 2 MARKS
SOFTWARE PROCESS AND AGILE DEVELOPMENT
Introduction to Software Engineering, Software Process, Perspective and Specialized
Process Models –Introduction to Agility-Agile Process-Extreme programming-XP
Process.

1. Define a system and computer-based system. (Nov/Dec 2007)

System: A system can be defined as a purposeful collection of inter-related components working
together to achieve some common objectives.
Computer based system: The computer-based system can be defined as a set or an arrangement of
elements that are organized to accomplish some predefined goal by processing information.
2. Write the IEEE definition of software engineering. (Nov/Dec 2017)
Software engineering is defined as the application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance of software.
3. What is Software Engineering? /Define software engineering. (Nov/Dec 2013), (Nov/Dec
2014), (Apr/May 2019) (APR/MAY 2024)
Software engineering is a discipline in which theories, methods and tools are applied to
develop professional software product.
4. What is Software? List the characteristics. (Nov/Dec 2009), (Apr/May 2018), (Nov/Dec 2018)
Software: Software is a collection of computer programs and related documents that are intended
to provide desired features; functionalities and better performance.
Characteristics:
 Software is engineered not manufactured.
 Software does not ware out
 Most software is custom built rather than being assembled from components.
5. What are two types of software products? (Apr/May 2012)
There are two types of software products -
 Generic - These products are developed and to be sold to the range of different customers
 Custom – These types of products are developed and sold at the specific group of customers and
developed as per their requirements
6. Mention the characteristics of software contrasting It with characteristics of hardware.
(Apr/May 2016)
 Software is engineered and not manufactured.
 Software does not ware out.
 The software is custom built rather than being assembled from components.

Page 39
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

7. Write any two software engineering challenges. (Apr/May2007)

The key challenges faced by software engineering are -
 Delivery times challenge
There is increasing pressure for faster delivery of software. When the complexity of the systems
that we develop increases, this challenge becomes harder.
 Heterogeneity challenge
Sometimes systems are distributed and include a mix of hardware and software. This implies that
software systems must cleanly integrate with other different software systems, built by different
organizations and team. This may be using different hardware and software platform.
8. Software doesn't wear out. Justify. (Nov/Dec 2013)
In early stage of hardware development process the failure rate is very high because of
manufacturing defects. But after correcting such defects the failure rate gets reduced,
The failure rate remains constant for some period of time and again it starts increasing
because of environmental maladies (extreme temperature, dusts, and vibrations).
On the other hand software does not get affected from such environmental maladies. Hence
ideally it should have an "idealized curve". But due to some undiscovered errors the failure
rate is high and drops down as soon as the errors get corrected.
Hence in failure rating of software the "actual curve"
9. List the Categories of Software.
 System software
 Application software
 Engineering/Scientific software
 Embedded software
 Web applications
 Artificial Intelligence software
10. What are the Goals and Objectives of Software?
While developing software following are common objectives.
 Satisfy users requirements
 High reliability
 Low maintenance costs
 Delivery on time
 High performance
 Ease of reuse

Page 40
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

11. What is layered technology?

Software engineering is a layered technology. Any software can be developed using these
layered approaches. Various layers on which the technology is based are quality focus layer,
process layer, methods layer, tools layer.
12. What is software processes. / Distinguish between process and methods. ( Apr/May
2004), ( A p r / M a y 2013),(Nov/Dec 2019)
Software process can be defined as the structured set of activities that are required to
develop the software system.
Various activities under software process are
 Specification
 Design and implementation
 Validation
 Evolution
13. Define the terms product and process in software engineering. (Apr/May 2007)
The product in software engineering is a standalone entity that can be produced by development
organization and sold on the open market to any customer who is able to buy them. The software
product consists of computer programs, procedures, and associated documentation (documentation
can be in hard copy form oz: it may be in visual form). Some of the examples of software product are
databases, word processors, drawing tools.
14. Why software architecture is important in software process? Apr 2005
The system architecture defines the role of hardware, software, people, database procedures and
other system elements. The architectural design of the system help the developer to understand the
system as a whole. Hence system architecture must be built before specifications are completed.
Thus, architectural design is important in software engineering.
15. Draw Common Process Framework. (Apr/May 2015)
The process framework is required for representing the common process activities.

Figure 15: A Software Process framework

Page 41
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

16. What are process framework activities?

 Communication
 Planning
 Modeling
 Construction
 Deployment
 Task sets
17. What are umbrella activities? (Nov/Dec 2018)
 Software project tracking and control
 Risk management
 Software quality assurance
 Formal technical reviews
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
18. What is capability maturity model?
The Capability Maturity Model (CMM) is used in assessing how well an organization's
processes allow to complete and manage new software projects .
19. What are Various process maturity levels?
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimizing
20. What is process model?
Definition of Process Model: The process 'model can be defined as the abstract
representation of process. The appropriate process model can be chosen based on abstract
representation of process.
The software process model is also known as Software Development Life Cycle (SDLC)

Model or software paradigm. These models are called prescriptive process models

Page 42
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

21. Depict the relationship between work product, task, activity and system. (Nov/Dec 2016)
Each framework activity under umbrella activities of software process framework consists of
various task sets.
Each task set consists of work tasks, work products, quality assurance points a project milestones.
The task sets accommodate the needs of the system getting developed.
22. Define Waterfall Model.
The waterfall model is also called as 'linear-sequential model' or 'classic life cycle model'.
It is the oldest software paradigm. This model suggests a systematic, sequential approach
to software development.
23. State the benefits and drawbacks of waterfall life cycle model for software development.
(Apr/May 2008)
Benefits of waterfall model
 The waterfall model is simple to implement.
 For implementation of small systems waterfall model is useful.
Drawbacks of waterfall model
There are some problems that are encountered if we apply the waterfall model and those are:
 It is difficult to follow the sequential flow in software development process. If some
changes are made at some phases then it may cause some confusion.
 The requirement analysis is done initially and sometimes it is not possible to state all the
requirements explicitly in the beginning. This causes difficulty in the project.
 The customer can see the working model of the project only at the end. After reviewing
of the working model. If the customer gets dissatisfied then it causes serious problems.
 Linear nature of waterfall model induces blocking states, because certain tasks may be
dependent on some previous tasks. Hence it is necessary to accomplish all the dependant tasks first.
It may cause long waiting time.
24. List two deficiencies in waterfall model. Which process model do you suggest to overcome
each efficiency? (Apr/May 2017)
i) It is difficult to define the entire requirement at the beginning of project; this model is not suitable
for accommodating any change.
To overcome this efficiency: Prototyping model.
ii) It does not scale up to large projects
To overcome this efficiency: Spiral model

Page 43
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

25. Define Iterative / Incremental Process Model.

In this model, the initial model with limited functionality is created for user’s understanding about
the software product and then this model is refined and expanded in later releases.

26. What are the pros and cons of Iterative software development models? (Nov/Dec 2006),
(Nov/Dec 2015)

Pros:
 The changes in requirements or additions of functionality are possible.
 Risks can be identified and rectified before they get problematic.
Cons:
 This model is typically based on customer communication. If the communication is not proper
the software product that gets developed will not be exactly as per the requirements.
 The development process may get continued and never finish.
27. What are the phases in incremental model?
The incremental model has following phases.
 Analysis
 Design
 Code
 Test
28. What are the Merits of incremental model?
 The incremental model can be adopted when there are less number of people
involved in the project.
 Technical risks can be managed with each increment.
 For a very small-time span, at least core product can be delivered to the customer.
29. Which process model leads to software reuse? Why? (Nov/Dec 2007)
The object oriented model is used for the software reuse because - this model is based on the
incremental development of the software product. This can be done in one or more iterations.
30. Define RAD Model.
The RAD Model is a type of incremental process model in which there is extremely short
development cycle.
When the requirements are fully understood and the component-based construction approach is
adopted then the RAD model is used.

Page 44
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

31. What are the phases encompassed in the RAD model? (Nov/Dec 2007)
Various phases in the RAD model are
 Business modeling
 Data modeling
 Process modeling
 Application generation
 Testing and turnover

32. What are the Drawbacks of rapid application development? (Apr/May 2005)

 It requires multiple teams or large number of people to work on the scalable projects
 This model requires heavily committed developer and customers. If commitment is lacking
then RAD projects will fail.
 The projects using RAD model requires heavy resources.
 If there is no appropriate modularization then RAD projects fail performance can be problem to
such projects.

 The projects using RAD model find it difficult to adopt new technologies.

33. Define Evolutionary Process Model. (Nov/Dec 2019)

1. Prototyping model 2. Spiral model 3. Concurrent development model

While developing the software systems, it is often needed to make modifications in earlier
development phases or the tasks sets. If the development process is linear or in a straight line (from
requirements gathering to deployment) then the end product will be unrealistic. In such cases, the
iterative approach needs to be adopted. The evolutionary process model is iterative model.

Define Prototyping model.

34. Define Prototyping model.
In prototyping model initially, the requirement gathering is done.
Developer and customer define overall objectives; identify areas needing more requirement gathering.
Then a quick design is prepared. This design represents what will be visible to user in input and
output format. From the quick design a prototype is prepared.

Page 45
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

35. Many modern applications change frequently before they are presented to end user and there
after the first version has been put into use. Suggest a few ways to stop deterioration due to change.
(Nov/Dec 2024)
It is fact that several modern applications and the software’s have gained the capacity to eliminate
the data or content before the presentation of the application in front of the end user. This is considered
under the deterioration due to the changes of application information.
The following are some ways which can stop the deterioration:

 The applications of software must be maintainable.

 These applications must have capacity engineered to a degree changes as this can be build easily
when the application is in growth stages.

 The chances of deterioration can be minimal through allow automatic updates to be built in.

36. Compare prototyping approaches in a software process. (Apr/May 2018)

There are two prototyping approaches in a software process -

 Evolutionary Prototyping - In this approach of system development, the initial prototype is prepared
and it is then refined through number of stages to final stage.

 Throw-away Prototyping – Using this approach a rough practical implementation of the

system is produced. The requirements problems can be identified from this implementation. It is then
discarded. System is then developed using some different engineering paradigm.
37. Name the criteria to develop an effective use case. (Nov/Dec 2024)
 An effective use case, key criteria include:
 Identifying a clear user goal
 Defining the primary actor
 Outlining the basic flow of events
 Considering alternative flows
 Specifying preconditioning and post conditions
 Using concise and understandable language
 Focusing on the user perspective
 Maintaining simplicity and avoiding unnecessary complexity
38. State few differences between traditional and Agile software development. (Apr/May 2024)

Page 46
 CCS356 –OBJECT ORIENTED SOFTWARE ENGINEERING - III YEAR CSE

Traditional Software Development Agile Software Development

It is used to develop simple software. It is used to develop complicated software.

In this methodology, testing is done once the In this methodology, testing and development
development phase is completed. processes are performed concurrently.

It follows a linear
It follows an iterative organizational structure.
organizational expectation structure.

It provides less security. It provides high security.

Client involvement is less as compared to Agile Client involvement is high as compared to

development. traditional software development.

Page 47