Object Oriented Software Engineering

MODULE – I
Introduction
Syllabus

MODULE –I: INTRODUCTION TO SOFTWARE ENGINEERING

(09) Introduction to software engineering, software
development process models, agile development, project
and process, project management, process and project
metrics, object-oriented concepts, principles and
methodologies

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
INTRODUCTION TO SOFTWARE ENGINEERING

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Software

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Definition

 Software engineering is the establishment and

use of sound engineering principles in order to
obtain economically software that is reliable
and works efficiently on real machines.
 Software Engineering is defined as Multi Person
construction of Multi version Software
 Software Engineering is a
systematic, disciplined, quantifiable
DON’T WRITE
study and approach to the design, OR PLACE ANY IMAGE IN
development, operation, and THIS AREA.
.
maintenance of a software system. .
 Dual Role of Software

As a Product:
•It delivers the computing potential across
networks of Hardware.
•It enables the Hardware to deliver the
expected functionality.
•It acts as an information transformer
because it produces, manages, acquires,
modifies, displays, or transmits
information.

As a vehicle to deliver the Product: DON’T WRITE

•It provides system functionality (e.g., OR PLACE ANY IMAGE IN
THIS AREA.
payroll system) .
•It controls other software (e.g., an .
operating system)
•It helps build other software (e.g.,
 Objectives of Software Engineering

1.Maintainability
It should be feasible for the software to
evolve to meet changing requirements.
2.Efficiency
The software should not make wasteful
use of computing devices such as
memory, processor cycles, etc.
3.Correctness
A software product is correct if the
different requirements as specified in DON’T WRITE
the SRS document have been correctly OR PLACE ANY IMAGE IN
implemented. THIS AREA.
.
4.Reusability .
A software product has good reusability
if the different modules of the product
 Objectives of Software Engineering

5. Testability
Here software facilitates both the establishment of
test criteria and the evaluation of the software with
respect to those criteria.
6. Reliability
It is an attribute of software quality. The extent to
which a program can be expected to perform its
desired function, over an arbitrary time period.
7.Portability
In this case, the software can be transferred from one
computer system or environment to another. DON’T WRITE
8.Adaptability OR PLACE ANY IMAGE IN
THIS AREA.
In this case, the software allows differing system .
constraints and the user needs to be satisfied by .
making changes to the software.
9.Interoperability
 Characteristics of Software

Software has characteristics that differ considerably

from those of hardware.

 Software is developed or engineered, it is not

manufactured in the classical sense

 Software doesn’t “wear out”

 Most software is custom-built, rather than being

assembled from existing components. DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Changing Nature of Software

1.System software:
Infrastructure software come under this category like compilers,
operating systems, editors, drivers, etc. Basically system
software is a collection of programs to provide service to other
programs. Ex Operating System
2. Real time software:
These software are used to monitor, control and analyze real
world events as they occur. An example may be software
required for weather forecasting. Such software will gather and
process the status of temperature, humidity and other
environmental parameters to forecast the weather.
3. Embedded software:
DON’T WRITE
This type of software is placed in “Read-Only- Memory OR PLACE ANY IMAGE IN
(ROM)”of the product and control the various functions of the THIS AREA.
product. The product could be an aircraft, automobile, security .
system, signalling system, control unit of power plants, etc. The .
embedded software handles hardware components and is also
termed as intelligent software .
 Changing Nature of Software

4. Business software :
This is the largest application area. The software designed to
process business applications is called business software.
Business software could be payroll, file monitoring system,
employee management, account management. It may also be a
data warehousing tool which helps us to take decisions based
on available data. Management information system, enterprise
resource planning (ERP) and such other software are popular
examples of business software.

5. Personal computer software :

The software used in personal computers are covered in this DON’T WRITE
category. Examples are word processors, computer graphics, OR PLACE ANY IMAGE IN
multimedia and animating tools, database management, THIS AREA.
computer games etc. This is a very upcoming area and many big .
organizations are concentrating their effort here due to large .
customer base.
 Changing Nature of Software

6. Artificial intelligence software:

Artificial Intelligence software makes use of non
numerical algorithms to solve complex problems
that are not amenable to computation or straight
forward analysis. Examples are expert systems,
artificial neural network, signal
processing software etc.

7. Web based software:

The software related to web applications come DON’T WRITE
under this category. Examples are CGI, HTML, OR PLACE ANY IMAGE IN
Java, Perl, DHTML etc. THIS AREA.
.
.
 Software Myths

Software myths are the beliefs that people

consider are true but are not, regarding software
and its development process.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Management Myths

Myth: We already have a book that’s full of

standards and procedures for building software,
won’t that provide my people with everything they
need to know?

Reality: The book of standards may very well exist,

but isn’t used. Most software practitioners aren’t
aware of its existence. Also, it doesn’t reflect modern
software engineering practices and is also complete.

Myth: My people have state-of-the-art software

development tools, after all, we buy them the
newest computers. DON’T WRITE
OR PLACE ANY IMAGE IN
Reality: It takes much more than the latest model THIS AREA.
mainframe, workstation, or PC to do high-quality .
software development. Computer-aided software .
engineering (CASE) tools
are more important than hardware for achieving
 Management Myths

Myth: If we get behind schedule, we can add more

programmers and catch up (sometimes called the
Mongolian horde concept).

Reality: Software development is not a

mechanistic process like manufacturing. As new
people are added, people who were working must
spend time educating the newcomers, thereby
reducing the amount of time spent on productive
development effort. People can be added but only
in a planned and well-coordinated manner.

Myth: If I decide to outsource the software project DON’T WRITE

to a third party, I can just relax and let that firm OR PLACE ANY IMAGE IN
build it. THIS AREA.
.
.
Reality: If an organization does not understand
how to manage and control software projects
internally, it will invariably struggle when it
 Customer Myths

Myth: A general statement of objectives is sufficient

to begin writing programs-we can fill in the details
later.

Reality: A poor up-front definition is the major

cause of failed software efforts. A formal and
detailed description of the functions, behavior,
performance, interfaces, design constraints, and
validation criteria is essential.

Myth: Project requirements continually change, but

change can be easily accommodated because
software is flexible. DON’T WRITE
OR PLACE ANY IMAGE IN
Reality: It is true that software requirements THIS AREA.
change, but the impact of change varies with the .
time at which it is introduced. When changes are .
requested during software design, the cost impact
grows rapidly. Resources have been committed and
 Practitioner's Myths

Myth: Once we write the program and get it to

work, our job is done.

Reality: Industry data indicate that between 60

and 80 percent of all effort expended on
software will be expended after it is delivered to
the customer for the first time.

Myth: Until I get the program “running” I have

no way of assessing its quality.

Reality: One of the most effective software DON’T WRITE

quality assurance mechanisms can be applied OR PLACE ANY IMAGE IN
from the inception of a project—the formal THIS AREA.
technical review. .
.
 SE—A Layered Technology

•Software engineering is a fully layered technology.

•To develop a software, we need to go from one
layer to another.
•All these layers are related to each other and each
layer demands the fulfillment of the previous layer.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 SE—A Layered Technology

1. Quality focus
Correctness of the functions required to be
performed by the software.
•Maintainability of the software
•Integrity i.e. providing security so that the
unauthorized user cannot access information or
data.
•Usability i.e. the efforts required to use or operate
the software.
2. Process
It is the base layer or foundation layer for the
software engineering.
•The software process is the key to keep all levels DON’T WRITE
together. OR PLACE ANY IMAGE IN
•It defines a framework that includes different THIS AREA.
activities and tasks. .
•In short, it covers all activities, actions and tasks .
required to be carried out for software
development.
 SE—A Layered Technology

3. Methods
•The method provides the answers of all 'how-to'
that are asked during the process.
•It provides the technical way to implement the
software.
•It includes collection of tasks starting from
communication, requirement analysis, analysis and
design modelling, program construction, testing
and support.
4. Tools
The software engineering tool is an automated
support for the software development.
•The tools are integrated i.e the information DON’T WRITE
created by one tool can be used by the other tool. OR PLACE ANY IMAGE IN
•For example: The Microsoft publisher can be THIS AREA.
used as a web designing tool. .
.
 Object Oriented Software Engineering
Module 1
Introduction- Software Process Framework

21
 Software Process Framework

Software Process Framework is an abstraction

of the software development process. It details the
steps and chronological order of a process.
Software process includes:
•Tasks – focus on a small, specific objective.
•Action – set of tasks that produce a major work
product.
•Activities – group of related tasks and actions for a
major objective.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Software Process Framework

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Process Framework Activities

•Communication: By communication, customer

requirement gathering is done. Communication with
consumers and stakeholders to determine the system’s
objectives and the software’s requirements.
•Planning: Establish engineering work plan, describes
technical risk, lists resources requirements, work
produced and defines work schedule.
•Modeling: Architectural models and design to better
understand the problem and for work towards the best
solution. The software model is prepared by:
o Analysis of requirements
o Design
•Construction: Creating code, testing the system, fixing
bugs, and confirming that all criteria are met. The DON’T WRITE
software design is mapped into a code by: OR PLACE ANY IMAGE IN
o Code generation THIS AREA.
o Testing .
•Deployment: In this activity, a complete or non- .
complete product or software is represented to the
customers to evaluate and give feedback. On the basis of
 Umbrella Activities

1.Software project tracking and control: This

is an activity in which the team can assess
progress and take corrective action to maintain
the schedule. Take action to keep the project on
time by comparing the project’s progress against
the plan.
2.Risk management: The risks that may affect
project outcomes or quality can be analyzed.
Analyze potential risks that may have an impact
on the software product’s quality and outcome.
3.Software quality assurance: These are
activities required to maintain software quality.
DON’T WRITE
Perform actions to ensure the product’s quality. OR PLACE ANY IMAGE IN
4.Formal technical reviews: It is required to THIS AREA.
assess engineering work products to uncover and .
remove errors before they propagate to the next .
activity. At each level of the process, errors are
evaluated and fixed.
 Umbrella Activities

5. Software configuration
management: Managing of configuration
process when any change in the software occurs.
6. Work product preparation and
production: The activities to create models,
documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria
for work product reuse. Reusable work items
should be backed up, and reusable software
components should be achieved.
8. Measurement: In this activity, the process
can be defined and collected. Also, project and
DON’T WRITE
product measures are used to assist the software OR PLACE ANY IMAGE IN
team in delivering the required software. THIS AREA.
.
.
Object Oriented Software Engineering
Module 1
Software Process Models

27
 Software Process Models

Every software engineering organization should describe a

unique set of framework activities for the software process it
adopts.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Types of Software Development Process Models

1. Waterfall model
2. V model
3. Incremental model
Incremental model
RAD model
4. Iterative model
Spiral model
Prototype model
DON’T WRITE
5. Unified Model OR PLACE ANY IMAGE IN
6. Hybrid Model THIS AREA.
.
.
 Waterfall Model

 It is called classic life cycle or Linear model.

 Requirements are well defined and stable.
 It suggests a systematic, sequential approach
to software development.
 It begins with customer specification of
requirements and progresses.
• Planning. DON’T WRITE
• Modeling. OR PLACE ANY IMAGE IN
THIS AREA.
• Construction and .
.
• Deployment.
Waterfall Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Advantages & Disadvantages

Advantages  Easy to understand, easy to use

 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost or
schedule
Disadvantages
 All projects cannot follow linear process
 All requirements must be known upfront
 Few business systems have stable
requirements. DON’T WRITE
 The customer must have patience. A working version of OR PLACE ANY IMAGE IN
the program will not be available until late in the project THIS AREA.
time-span .
 Leads to ‘blocking states’ .
 Inappropriate to changes
 V Model

 The V-model is an SDLC model where execution of processes

happens in a sequential manner in a V-shape.
 It is also known as Verification and Validation model.
 The V-Model is an extension of the waterfall model and is
based on the association of a testing phase for each
corresponding development stage.
 This means that for every single phase in the development
cycle, there is a directly associated testing phase.
 This is a highly-disciplined model and the next phase starts
DON’T WRITE
only after completion of the previous phase.
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
V Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Pros & Cons of V Model

1. This is a highly-disciplined model and Phases are completed one

at a time.
2. Works well for smaller projects where requirements are very
well understood.
3. Simple and easy to understand and use.
4. Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Pros & Cons of V Model

1. High risk and uncertainty.

2. Not a good model for complex and object-oriented projects.

3. Poor model for long and ongoing projects.

4.Not suitable for the projects where requirements are at a

moderate to high risk of changing.

5. Once an application is in the testing stage, it is difficult to go DON’T WRITE

back and change a functionality. OR PLACE ANY IMAGE IN
THIS AREA.
.
6. No working software is produced until late during the life cycle. .
 The Increment Model

 Combines the elements of waterfall model in an

iterative fashion
 Construct a partial implementation of a total
system
 Then slowly add increased functionality
 User requirements are prioritized and the highest
priority requirements are included in early
increments.
 Each subsequent release of the system adds
function to the previous release, until all designed DON’T WRITE
functionality has been implemented. OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Incremental Process Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
When to Use Incremental Process Model

 When staffing is not available by deadline

 Most of the requirements are known up-front but are
expected to evolve over time
 When the software can be broken into increments
and each increment represent a solution
 A need to get basic functionality to the market early
 On projects which have lengthy development
schedules
 On a project with new technology

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Disadvantages of Incremental Process Model

 Requires good planning and design

 Requires early definition of a complete and fully
functional system to allow for the definition of
increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not lower

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
RAD Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 RAD Model

The RAD (Rapid Application

Development) model is based on prototyping
and iterative development with no specific
planning involved.
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.
Business Modelling
A complete business analysis is performed to find
the vital information for business, how it can be
obtained,
Data Modelling DON’T WRITE
The information gathered in the Business OR PLACE ANY IMAGE IN
Modelling phase is reviewed and analyzed to form THIS AREA.
sets of data objects vital for the business. .
.
Process Modelling
The data object sets defined in the Data Modelling
phase are converted to establish the business
 RAD Model

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.

•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 DON’T WRITE
automated code generating tools. OR PLACE ANY IMAGE IN
•RAD SDLC model should be chosen only if domain THIS AREA.
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.
Disadvantages of RAD Model

 For large projects, RAD requires sufficient

human resources to create the right number
of RAD teams.
 If developers & customers are not committed to rapid-
fire
activities, RAD projects will fail.
 If the system cannot be properly modularized, building
the
components will be problematic
 If high-performance is an issue, RAD may not work.
 RAD may be inappropriate when technical risks are
high DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Evolutionary Process Models/Iterative Process Models

 These models produce an increasingly more complete

version of the software with each iteration
 When to use
– Tight market deadlines
– Well defined system requirements
– No details about system definition

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Prototype Process Models

 A prototype is a partially developed product

that enables customers and developers to
examine some aspects of the proposed system
and decide if it is suitable or appropriate for the
finished product
– Start with what is known about requirements.
– Do a quick design.
– Build the prototype by focusing on what
will be seen by the user. DON’T WRITE
– Use the prototype to show the user and OR PLACE ANY IMAGE IN
THIS AREA.
help refining .
requirements .
PROTOTYPING MODEL
 Spiral Model
 It couples the iterative nature of prototyping with the controlled and systematic
aspects of the waterfall model Process
 Adapted to complete life cycle
 Process is represented as a spiral rather than as a sequence
of activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design - loops in the spiral are chosen
depending on what is required.
• The first circuit in the clockwise direction might result in the 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 results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjustedDON’T by WRITE
project manager.
OR PLACE ANY IMAGE IN
• Good to develop large-scale system as software evolves as the process progressesTHIS AREA.
.
and risk should be understood and properly reacted to. Prototyping is used to reduce
risk. .

• However, it may be difficult to convince customers that it is controllable as it

demands considerable risk assessment expertise.
SPIRAL MODEL
Advantages & Disadvantages of Spiral Model

Advantages:
• Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software
Development.
Disadvantages:

 It may be difficult to convince customers that the

evolutionary approach is controllable. DON’T WRITE
 It demands risk assessment expertise and OR PLACE ANY IMAGE IN
relies on this expertise for success. THIS AREA.
.
 If a major risk is uncovered and managed,
.
problems will occur.
 Win-Win Spiral Model

The customer wins by getting the system satisfying most of

their requirements and developers wins by working on
achievable budgets and deadlines.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
WIN-WIN SPIRAL MODEL
Advantages & Disadvantages of Win-Win Spiral Model

Advantages:

• Light weight methods suit small-medium size

project.
• Produces good team.
• Test based approach to requirements and quality
assurance
Disadvantages:

 Programming pairs is costly.

DON’T WRITE
 Difficult to scale up to large projects where OR PLACE ANY IMAGE IN
documentation. THIS AREA.
.
.
 Unified Process Model

Unified process (UP) is an architecture centric, use case

driven, iterative and incremental development process. UP
is also referred to as the unified
software development process.

•Inception
•Elaboration
•Conception
•Transition
•Production

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Unified Process Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Advantages & Disadvantages of Unified Process Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Hybrid Process Models

 The hybrid model is the combination of two

or more primary (traditional) models and
modifies them as per the business
requirements.
 This model is dependent on the other SDLC
models, such as spiral, V and V, and
prototype models.
 The hybrid model is mainly used for small,
medium, and large projects. It focuses on the DON’T WRITE
risk management of the product. OR PLACE ANY IMAGE IN
 Most Common Models are: THIS AREA.
.
•Spiral and prototype .
•V & V and Prototype
Spiral and prototype Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
V & V and prototype Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Object Oriented Software Engineering
Module 1
Agile Software Development

60
 Agile Software Development

 The meaning of Agile is swift or versatile.

 "Agile process model" refers to a software
development approach based on iterative
development.
 Agile methods break tasks into smaller iterations,
or parts do not directly involve long term
planning.
 The project scope and requirements are laid
down at the beginning of the development DON’T WRITE
process. OR PLACE ANY IMAGE IN
THIS AREA.
 Plans regarding the number of iterations, the .
duration and the scope of each iteration are .
clearly defined in advance.
Agile Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Phases of Agile Model

Following are the phases in the Agile model are

as follows:

1.Requirements gathering
2.Design the requirements
3.Construction/ iteration
4.Testing/ Quality assurance
5.Deployment
6.Feedback
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Agile Methodology

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Agile Model
 When to Use Agile Model?

•When frequent changes are required.

•When a highly qualified and experienced team is

available.

•When a customer is ready to have a meeting with

a software team all the time.

•When project size is small.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Advantages of Agile Model

 Frequent Delivery

 Face-to-Face Communication with clients.

 Efficient design and fulfils the business

requirement.

 Anytime changes are acceptable.

 It reduces total development time. DON’T WRITE

OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Features of Agile Software Development

Agile software development is more than practices

such as

 pair programming
 test-driven development
 stand-ups
 planning sessions
 sprints.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Agile Software Development Process Models

•eXtreme Programming(XP)
•Scrum
•Crystal
•Dynamic Software Development
Method(DSDM)
•Feature Driven Development(FDD)

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Extreme programming

A popular form of Agile

Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only accepted if tests
run successfully.
Customer involvement means full-time customer engagement with the
team. - Specifications through user stories broken into tasks
People not process : pair programming, collective ownership and a
process that avoids long working hours.
Regular system releases. - release set of user stories
Maintaining simplicity through constant refactoring of code. DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

70
The extreme programming release cycle

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

71
The Parts and the Whole

• Iteration Plan
• Daily Stand-Up

Set
Adapt Controller
Target

• Clean Design & Code & Inspect

Refactor
• User Stories - Late Elaboration
• Shared Code Ownership • Pair Programming DON’T WRITE
• Test Driven Development….. • Customer Reviews &OR PLACE ANY IMAGE IN
Feedback THIS AREA.
• Retrospectives .
Sustainable pace • AutoTest….. .
Collective Ownership with users
Minimal documentation for sprint
The Life of an Iteration

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
Examples of task cards for prescribing medication

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

74
Scrum

The Scrum approach - manage the iterations

There are three phases in Scrum.
 outline planning phase - general picture and architecture
 Sprint cycles releasing increments of the system.
 The project closure phase - final delivery, documentation and
review of lessons learned.

There are 3 roles:

• Scrum Master: The scrum can set up the master team,
arrange the meeting and remove obstacles for the process
• Product owner: The product owner makes the product DON’T WRITE
backlog, prioritizes the delay and is responsible for the OR PLACE ANY IMAGE IN
distribution of functionality on each repetition. THIS AREA.
.
• Scrum Team: The team manages its work and organizes .
the work to complete the sprint or cycle.
75
The Scrum process

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

76
The Sprint cycle

Every 2–4 weeks (a fixed length).

1) Project team with customer: Look at product backlog - select stories to implement
2) implement with all customer communication through scrum master (protecting pgmr
at this point)
Scrum master has project manager role during sprint
Daily 15 min meetings
Stand up often
Team presents progress and impediments
Scrum master tasked with removing impediments
3) Review system release with user

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

77
Scrum benefits

The product is broken down into a set of

manageable and understandable chunks.
Unstable requirements do not hold up progress.
The whole team have visibility of everything and
consequently team communication is improved.
Customers see on-time delivery of increments and
gain feedback on how the product works.
Trust between customers and developers is
established and a positive culture is created in which DON’T WRITE
everyone expects the project to succeed. OR PLACE ANY IMAGE IN
THIS AREA.
.
.

78
Crystal

• There are three concepts of this method-

1.Chartering: Multi activities are involved in this
phase such as making a development team,
performing feasibility analysis, developing
plans, etc.
2.Cyclic delivery: under this, two more cycles
consist, these are:
1. Team updates the release plan.
2. Integrated product delivers to the users.
DON’T WRITE
3.Wrap up: According to the user environment, OR PLACE ANY IMAGE IN
this phase performs deployment, post- THIS AREA.
deployment. .
.

79
Crystal

Moreover, it is made up of several agile

processes, including Clear, Crystal Yellow,
Crystal Orange, and other uniquely
characterized methods.
Suitability of the Crystal method depends on three
dimensions:
First, Team size
Second, Criticality
Third, the priority of the project
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

80
Crystal

Crystal methods focus on:-

People involved
Interaction between the teams
Community
Skills of people involved
Their Talents
Communication between all the teams
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

81
Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy

for software development and gives an agile project
distribution structure.

The essential features of DSDM are that users must

be actively connected, and teams have been given
the right to make decisions.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

82
Dynamic Software Development Method(DSDM):

The DSDM project contains seven stages:

Pre-project
Feasibility Study
Business Study
Functional Model Iteration
Design and build Iteration
Implementation
DON’T WRITE
Post-project OR PLACE ANY IMAGE IN
THIS AREA.
.
.

83
Feature Driven Development

This method focuses on "Designing and Building" features. In contrast to

other smart methods, FDD describes the small steps of the work that
should be obtained separately per function.
Feature-driven development defines five steps in two phases: planning and
construction.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

84
Planning Phase

Step 1: Develop an Initial Model

Step 2: Develop a Feature List
Step 3: Plan by Feature

• Which features your customer’s users need

most urgently.
• Which features will deliver the most value
soonest.
• Development time estimates.
• Technical dependencies between features. DON’T WRITE
OR PLACE ANY IMAGE IN
• Risks involved with features. THIS AREA.
• Available people, their skills and expertise. .
.
• Workload.
85
Construction Phase

Step 4: Design by Feature

Step 5: Build by Feature

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

86
FDD Pitfalls

FDD relies heavily on experienced

people, like the project and development
managers and the chief architect and
programmer.
In that respect FDD is rather top-heavy
and smaller shops with only a few teams
may find it hard to use it effectively.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.

87
 Project and Process

Project & Process

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Process

 A process is an established, repeatable

procedure used for internal business purposes.
 It involves a series of tasks that are related to
one another and are required to be carried out
in order to achieve a result.

 Ex: HR Process

 The purpose of a process is to serve business

objectives that provide customer value. DON’T WRITE
 They should be regularly evaluated and OR PLACE ANY IMAGE IN
THIS AREA.
improved so that business standards can be .
refined. .
 Software Process Framework

Software Process Framework is an abstraction

of the software development process. It details the
steps and chronological order of a process.
Software process includes:
•Tasks – focus on a small, specific objective.
•Action – set of tasks that produce a major work
product.
•Activities – group of related tasks and actions for a
major objective.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Process Framework Activities

•Communication: By communication, customer

requirement gathering is done. Communication with
consumers and stakeholders to determine the system’s
objectives and the software’s requirements.
•Planning: Establish engineering work plan, describes
technical risk, lists resources requirements, work
produced and defines work schedule.
•Modeling: Architectural models and design to better
understand the problem and for work towards the best
solution. The software model is prepared by:
o Analysis of requirements
o Design
•Construction: Creating code, testing the system, fixing
bugs, and confirming that all criteria are met. The DON’T WRITE
software design is mapped into a code by: OR PLACE ANY IMAGE IN
o Code generation THIS AREA.
o Testing .
•Deployment: In this activity, a complete or non- .
complete product or software is represented to the
customers to evaluate and give feedback. On the basis of
 Umbrella Activities

1.Software project tracking and control: This

is an activity in which the team can assess
progress and take corrective action to maintain
the schedule. Take action to keep the project on
time by comparing the project’s progress against
the plan.
2.Risk management: The risks that may affect
project outcomes or quality can be analyzed.
Analyze potential risks that may have an impact
on the software product’s quality and outcome.
3.Software quality assurance: These are
activities required to maintain software quality.
DON’T WRITE
Perform actions to ensure the product’s quality. OR PLACE ANY IMAGE IN
4.Formal technical reviews: It is required to THIS AREA.
assess engineering work products to uncover and .
remove errors before they propagate to the next .
activity. At each level of the process, errors are
evaluated and fixed.
 Umbrella Activities

5. Software configuration
management: Managing of configuration
process when any change in the software occurs.
6. Work product preparation and
production: The activities to create models,
documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria
for work product reuse. Reusable work items
should be backed up, and reusable software
components should be achieved.
8. Measurement: In this activity, the process
can be defined and collected. Also, project and
DON’T WRITE
product measures are used to assist the software OR PLACE ANY IMAGE IN
team in delivering the required software. THIS AREA.
.
.
Object Oriented Software Engineering
Module 1
Software Project management

94
 Software Project

A Software Project is the complete procedure of

software development from requirement gathering
to testing and maintenance, carried out according
to the execution methodologies, in a specified
period of time to achieve intended software
product.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
4 P’s (Project & Process)

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Software Project Management

Software Project Management

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Software Project

A Software Project is the complete procedure of

software development from requirement gathering
to testing and maintenance, carried out according
to the execution methodologies, in a specified
period of time to achieve intended software
product.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Software Project Management

 Software project management is an art and

discipline of planning and supervising
software projects.

 It is a sub-discipline of software project

management in which software projects
planned, implemented, monitored and
controlled.
DON’T WRITE
OR PLACE ANY IMAGE IN
 It is a procedure of managing, allocating THIS AREA.
and timing resources to develop computer .
.
software that fulfills requirements.
Software Project Planning

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Manager

A software project manager is a person who

undertakes the responsibility of executing
the software project.
Software project manager is thoroughly
aware of all the phases of SDLC that the
software would go through.

Managing Project
•Defining and setting up project scope
•Managing project management activities
DON’T WRITE
•Monitoring progress and performance OR PLACE ANY IMAGE IN
•Risk analysis at every phase THIS AREA.
•Take necessary step to avoid or come out .
.
of problems
•Act as project spokesperson
 Project management Activities

•Project Planning
•Scope Management
•Project Estimation
•Resource Management
•Project Risk Management
•Software Configuration Management

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Software Project Planning

 Software planning process include steps to estimate the

size of the software work products and the resources
needed produces a schedule identify and access
software risks.

 During planning a project is split into several activities :

• How much efforts is required to complete each activities?

DON’T WRITE
• How much calendar time is needed? OR PLACE ANY IMAGE IN
• How much will the completed activity cost THIS AREA.
.
.
 Software Project Planning

 Planning Objectives:
• Understand the scope of the problem.
• Make use of past historical data.
• Estimate effort or function or size.
• Define a project schedule.

 Characteristics of software project planning:

•Scope.
DON’T WRITE
• Resource. OR PLACE ANY IMAGE IN
•Time. THIS AREA.
.
•Quality. .
• Risk.
Software Project Planning

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Plan

 The biggest single problem that afflicts software developing

is that of underestimating resources required for a project.

 According to the project management body of knowledge.

 According to PRINCE(PRojects IN Controlled Environments).

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Types of Project Plan

 Software development plan.

 Quality Assurance Plan.
 Validation Plan.
 Configuration Management Plan
 Maintenance Plan
 Staff development plan
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Scope Management

 Scope Management includes all the activities, process need

to be done in order to make a deliverable software product.

 Scope management is essential because it creates

boundaries of the project by clearly defining what would be
done in the project and what would not be done.

 This makes project to contain limited and quantifiable tasks,

which can easily be documented and in turn avoids cost and
time overrun.
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Scope Management

During Project Scope management, it is necessary

to

•Define the scope

•Decide its verification and control
•Divide the project into various smaller parts for
ease of management.
•Verify the scope
•Control the scope by incorporating changes to DON’T WRITE
OR PLACE ANY IMAGE IN
the scope THIS AREA.
.
.
 Project Estimation

 For an effective management accurate

estimation of various measures is a must.

 With correct estimation managers can

manage and control the project more
efficiently and effectively.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Estimation Activities

•Software size estimation

KLOC (Kilo Line of Code)
FP Function points
•Effort estimation
The managers estimate efforts in terms of personnel requirement
and man-hour required to produce the software.
Time estimation
The time required to produce the software can be estimated.
Work Breakthrough Structure (WBS).
The tasks are scheduled on day-to-day basis or in calendar months.
•Cost estimation
• Size of software
• Software quality
• Hardware DON’T WRITE
• Additional software or tools, licenses etc. OR PLACE ANY IMAGE IN
• Skilled personnel with task-specific skills THIS AREA.
• Travel involved .
• Communication .
• Training and support
 Resource Management

•Defining proper organization project by

creating a project team and allocating
responsibilities to each team member

•Determining resources required at a particular

stage and their availability

•Manage Resources by generating resource

DON’T WRITE
request when they are required and de- OR PLACE ANY IMAGE IN
allocating them when they are no more THIS AREA.
.
needed. .
 Project Risk Management

•Experienced staff leaving the project and

new staff coming in.

•Change in organizational management.

•Requirement change or misinterpreting

requirement.
DON’T WRITE
•Under-estimation of required time and OR PLACE ANY IMAGE IN
resources. THIS AREA.
.
.
•Technological changes, environmental
changes, business competition.
 Project Risk Management Process

•Identification - Make note of all possible risks,

which may occur in the project.
•Categorize - Categorize known risks into high,
medium and low risk intensity as per their possible
impact on the project.
•Manage - Analyze the probability of occurrence of
risks at various phases. Make plan to avoid or face
risks. Attempt to minimize their side-effects.
•Monitor - Closely monitor the potential risks and
DON’T WRITE
their early symptoms. Also monitor the effects of OR PLACE ANY IMAGE IN
steps taken to mitigate or avoid them. THIS AREA.
.
.
Software Configuration Management (SCM)

Configuration management is a process of

tracking and controlling the changes in
software in terms of the requirements,
design, functions and development of the
product.
1. Baseline
2. Change Control

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Management Tools

Gantt Chart
Gantt charts was devised by Henry Gantt
(1917). It represents project schedule with
respect to time periods. It is a horizontal bar
chart with bars representing activities and
time scheduled for the project activities.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Management Tools

PERT Chart
PERT (Program Evaluation & Review Technique) chart
is a tool that depicts project as network diagram. It is
capable of graphically representing main events of
project in both parallel and consecutive way. Events,
which occur one after another, show dependency of
the later event over the previous one.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Project Management Tools

Resource Histogram
This is a graphical tool that contains bar or chart
representing number of resources (usually skilled
staff) required over time for a project event (or
phase). Resource Histogram is an effective tool for
staff planning and coordination.

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Critical Path Analysis

This tools is useful in recognizing interdependent

tasks in the project. It also helps to find out the
shortest path or critical path to complete the project
successfully. Like PERT diagram, each event is
allotted a specific time frame.
This tool shows dependency of event assuming an
event can proceed to next only if the previous one is
completed.
The events are arranged according to their earliest
possible start time.
Path between start and end node is critical path DON’T WRITE
which cannot be further reduced and all events OR PLACE ANY IMAGE IN
THIS AREA.
require to be executed in same order. .
.
Object Oriented Software Engineering
Module 1
Process & Project Metrics

120
 Software Metrics

 A software metric is a measure of software characteristics

which are measurable or countable.
 Software metrics are valuable for many reasons, including
measuring software performance, planning work items,
measuring productivity, and many other uses.
 They are a management tool.
 They offer insight into the effectiveness of the software
process and the projects that are conducted using the
process as a framework.
 Basic quality and productivity data are collected.
 These data are analyzed, compared against past averages,
and assessed.
 The goal is to determine whether quality and productivity DON’T WRITE
improvements have occurred. OR PLACE ANY IMAGE IN
 The data can also be used to pinpoint problem areas. THIS AREA.
.
 Remedies can then be developed and the software
.
process can be improved.
 Need for Software Metrics

To characterize in order to
•Gain an understanding of processes, products,
resources, and environments.
•Establish baselines for comparisons with future
assessments
To evaluate in order to
•Determine status with respect to plans
To predict in order to
•Gain understanding of relationships among
processes and products.
•Build models of these relationships DON’T WRITE
OR PLACE ANY IMAGE IN
To improve in order to THIS AREA.
•Identify roadblocks, root causes, inefficiencies, .
and other opportunities for improving product .
quality and process performance.
Types of Software Metrics

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Process Metrics

Process metrics are collected across all projects and

over long periods of time.
•They are used for making strategic decisions.
•The intent is to provide a set of process indicators
that lead to long-term software process
improvement.

The only way to know how/where to improve any

process is to

1.Measure specific attributes of the process. DON’T WRITE

OR PLACE ANY IMAGE IN
2.Develop a set of meaningful metrics based on THIS AREA.
these attributes. .
3.Use the metrics to provide indicators that will lead .
to a strategy for improvement.
Process Metrics

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Measure Effectiveness of Process

Measure the effectiveness of a process by deriving

a set of metrics based on outcomes of the process
such as:

•Errors uncovered before release of the software.

•Defects delivered to and reported by the end
users.
•Work products delivered.
•Human effort expended.
•Calendar time expended. DON’T WRITE
OR PLACE ANY IMAGE IN
•Conformance to the schedule. THIS AREA.
•Time and effort to complete each generic activity. .
.
 Product Metrics

They focus on the quality of deliverables. Product

metrics are combined across several projects to
produce process metrics.

Metrics for the product:

•Measures of the Analysis Model.

•Complexity of the Design Model
•Code metrics.
Furthermore, Complexity of the Design Model is
DON’T WRITE
classified as- OR PLACE ANY IMAGE IN
1.Internal algorithmic complexity. THIS AREA.
2.Architectural complexity. .
.
3.Data flow complexity.
 Project Metrics

Size oriented : lines of code approach

•Thousand lines of code (KLOC) are

often chosen as the normalization value.
•Metrics include
1. Errors per KLOC- Errors per person-
month.
2. Defects per KLOC- KLOC per
person-month.
3. Rs per KLOC- Rs per page of
DON’T WRITE
documentation. OR PLACE ANY IMAGE IN
4. Pages of documentation per KLOC. THIS AREA.
.
.
2. Function oriented: function point
approach
Object Oriented Concepts and
Principles

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Software Engineering

 object oriented software engineering can be

referred to as a software design concept that is
used in object oriented programming for the
purpose of designing software models.

 Using object oriented software engineering

techniques, we design the classes (objects),
functions, methods etc that are required for the
development of any software.

 OOSE is a design technique and doesn’t include DON’T WRITE

any implementation of code OR PLACE ANY IMAGE IN
THIS AREA.
.
 It includes requirement, analysis, design, .
implementation and sometimes a testing
model.
 OOSE Principles

Class
In OOP, class can be described as a user defined
prototype or blue print of the data attributes and
methods structure. For example, a Car class may
include attributes like color, speed, engine type,
model no. etc.

Object
In OOP, objects are created from the class and
include the data structured in the same way as the
class to which it belongs. For example, a car object DON’T WRITE
named “i10” can be created from the Car class OR PLACE ANY IMAGE IN
THIS AREA.
having its own properties structured in the similar .
way like the class. .
 OOSE Concepts

Encapsulation
Encapsulation means grouping of the
data with the methods or functions that
operate on that data. Along with this, it
also hides the data or prevents the
outside world from using the data from
within the object.

Abstraction
Abstraction can be referred to as showing DON’T WRITE
essential data/working to the user and OR PLACE ANY IMAGE IN
hiding the rest of the details. Only THIS AREA.
.
necessary details are shown to the .
outside world.
 OOSE Concepts

Inheritance
Enabling programmers to share the attributes of
the existing class into new class by extending it.
The existing class is known as the base or parent
class and the class that derives the attributes is
known as the child class or derived class.

Polymorphism
Polymorphism means many forms, thus it can be
described as the same names or operators or
functions can behave in various different forms
based on the number of arguments or based on
DON’T WRITE
the type of arguments at the time of the function OR PLACE ANY IMAGE IN
call. Operators will behave differently when used THIS AREA.
along with operands of different types. .
.
Object Oriented Methodologies

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Methodologies

•Object Identification: System objects and

their characteristics and events.
•Object Organization: Shows how objects are
related via “part-of” relationships.
•Object Interfaces: Shows how objects
interact with other objects.

These activities tend to be overlapping and in

general and parallel. DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Methodology

•Design is no longer carried out independently

of the later implementation because during the
design phase we must consider which
components are available for the solution of
the problem.
•Design and implementation become more
closely associated.
•Duration of the implementation phase is
reduced. DON’T WRITE
•A new job title emerges, the class librarian, OR PLACE ANY IMAGE IN
who is responsible for ensuring the efficient THIS AREA.
.
usability of the class library. .
Object Oriented Life cycle Model

DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Analysis (OOA)

The object-oriented analysis consists of the process

where a development team evaluates the system and
organizes the requirements as objects.
OOA heavily depends on advanced data like Use
Cases and Object Models.
Use case
Use Cases are written descriptions about how users
will behave when they enter your website or
application. It comprises the goals of each user from
the point of their entry to exit.
Object Model
An object model allows the development team to
create an architectural software or system model
before implementing or programming. It helps in DON’T WRITE
defining a software/system in objects and classes. It OR PLACE ANY IMAGE IN
informs the developers about THIS AREA.
.
•Interaction between different models .
•Inheritance
•Encapsulation
•Other types of object-oriented interfaces
 Object Oriented Analysis (OOA)

The OOA starts with analyzing the problem domain

and produce a conceptual model by thoroughly
evaluating the information in the given area. There is
an abundance of data available from various sources
like:

•Formal document
•Requirement statements
•Primary data collected through stakeholders

Once the analysis is complete, the development team

prepares a conceptual model describing the system's
functionalities and requirements.
DON’T WRITE
OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Design

 The analysts design the desired system's overall

architecture.
 The system is divided into a set of interacting
subsystems.
 The analyst considers the specifications from the
system analysis.
 It all about evaluating what the end-users expect
from the new system.
 The system is considered a collection of objects,
with each object handling a specific state data.
 The philosophy behind an object-oriented design DON’T WRITE
OR PLACE ANY IMAGE IN
is to create a set of interacting objects as seen in THIS AREA.
the real world. .
 .
Instead of process-based structural
programming, developers create objects through
 Object Oriented Implementation

 This phase, developers translate the class

objects and the interrelationships of classes and
code them using a programming language.
 This is the phase to create databases and
establish functionalities for the system.
 The object-oriented methodology focuses on
identifying objects in the system.
 Developers closely observe each object to
identify characteristics and behavioral patterns.
 The developers ensure that the object
DON’T WRITE
recognizes and responds perfectly to an event. OR PLACE ANY IMAGE IN
THIS AREA.
.
.
 Object Oriented Implementation

Object Model − It describes the objects and their

interrelationships. This model observes objects as
static and discards their dynamicity.

Dynamic Model − This model focuses on the

changes in states of various objects related to
specific events.

Functional Model − This describes the changes in

the flow of data throughout the system.
DON’T WRITE
OR PLACE ANY IMAGE IN
The object model describes the essential elements THIS AREA.
of a system. When all the models are combined, it .
.
represents the complete function of the system.