SOFTWARE ENGINEERING

BOOKS
Books :--
1 . Software Engineering by Sommerville - Pearson
2. Software Engineering- a Practitioner Approach
by Rodger Pressman – Mc Graw Hill
3. Object Oriented approach of Software Engineering by Jacobson
4. Software Engineering concepts and application by Subhajit Datta
5. Modern Structured Analysis by Edward Yourdan - PHI
6. Fundamentals of Software Engineering by Carlo Ghezzi - PHI
 OBJECTIVES

❖ To introduce software engineering and to

explain its importance

❖ Key Concepts of Software engineering

❖ To introduce ethical and professional issues

and to explain why they are of concern to
software engineers
HISTORY OF SOFTWARE ENGINEERING
NOTION OF SOFTWARE ENGINEERING:
The notion “Software Engineering” was
proposed in 1969 at a NATO conference to
discuss software development problems which
is also known as the “Software Crises”-

• Late delivery
• Did not incorporate the required
functionality
• Cost more than expected
• Were not reliable
PROGRESS OF SOFTWARE ENGINEERING
Software engineering has made remarkable
progress in last 40 years with the coming up of :
New techniques such as structured and object
oriented programming
Variety of software engineering methodologies
and software tools
Recent technologies for development and
deployment of large enterprise applications are:
• J2EE
• .NET
• Saas
• SAP
SOFTWARE ENGINEERING
ACHIEVEMENTS
Controlling national utilities and infrastructure-
⚫ Industrial Production
⚫ Financial sector
⚫ Energy,
⚫ Communications,
⚫ Entertainments and
⚫ Transport

Exploring space

Creating World Wide Web-

The most significant Info System in the history of mankind.
 KEY CHALLENGES
Development of new methods and technologies
• Incorporate diversity of applications
• Reduced delivery time
• Develop quality software
• Heterogeneity

The web has led to

•Availability of software services
• Possibility of developing highly distributed
service-based systems
 KEY CHALLENGES
Incorporate diversity of applications
Determine which software engineering methodology is
suitable for which application

Reduced delivery time

Due to business and social changes and economic
development, change the existing software with new
technology.
 KEY CHALLENGES
Develop dependable and secure software
Software are now associated with all aspects of our life in sectors
like banking, transport, hospital, industrial production. Malacious
actor cannot attack our system and information security is
maintained.
Heterogeneity
Developing techniques for building software that can run on
distributed system across network of computer and mobiles
devices, integrate new system with old legacy system
VERY RECENT CHALLENGES
• World is now faced with a new set of challenges:
• Climate change and extreme weather
• Declining natural resources
• Increasing world population to be fed and housed
• International terrorism
• Need to help elderly people lead satisfying and
fulfilled lives

• Need for :
New software technologies to address these problems
 WHAT IS SOFTWARE ENGINEERING ?
Engineering discipline that is concerned with all aspects of
software production.

Engineering : Getting good quality product using systematic

and organised approach to their work & use appropriate tools
and methods for the development meeting the financial
constraints and the resources available.

Good quality product: maintainability, dependability and

security, efficiency, acceptability.

All aspect: It also include software project management and

developments of tools methods and theory
COMPUTER SCIENCE VS SOFTWARE
ENGINEERING
Computer science is concerned with theory and
fundamentals whereas

Software engineering is concerned with the practicalities

of developing and delivering useful software.

Computer science theories are still insufficient to act as a

complete underpinning for software engineering (unlike
e.g. physics and electrical engineering).
 SOFTWARE ENGINEERING VS. SYSTEM
ENGINEERING:
System engineering is concerned with all aspects of
computer-based systems development including hardware,
software and process engineering. whereas ;

Software engineering is part of this process concerned with

developing the software infrastructure, control, applications
and databases in the system.

System engineers are involved in system specification,

architectural design, integration and deployment.
 WHAT IS A SOFTWARE PRODUCT ?
PROGRAMS +
SOFTWARE DOCUMENTATION +
OPERATING
PROCEDURES

1.) PROGRAM
-- It is a subset of software & it becomes software only if documentation
and operating procedure manuals are prepared.
-- It is a combination of source code and object code.

2.) DOCUMENTATION
-- It consists of different types of manuals like analysis specification
manual ,design manual, implementation manual & testing manual.

3.) OPERATING PROCEDURES

-- Installation Manual : instructions to setup the software system and
instructions on how to react to system failure
-- User Manuals: Operating procedure instruction to use software for
functionality
SOFTWARE PRODUCT
Software products are divided in two categories:

1.) Generic Products : These products are developed for

anonymous customers. E.g. infrastructure software like
operating systems, compliers, word processors, CASE tools
etc.

2.) Customized Products : These products are developed for

a particular customer as per his requirements.
 WHAT IS A SOFTWARE PROCESS
It is a set of activities and ordering amongst them to
reach the desired software product. An efficient process is
required to produce a good quality product.

Generic activities in all software processes are:

⚫ Specification - what the system should do & its
development constraints
⚫ Development - production of the software system
⚫ Validation - checking that the software is what the
customer wants
⚫ Evolution - changing the software in response to
changing demands
 SOFTWARE PROCESS
A process model is an abstract representation of the
development process presented from a specific perspective.

Examples of process perspectives are

⚫ Workflow perspective - sequence of activities
⚫ Data-flow perspective - information flow
⚫ Role/action perspective - who does what

Generic process models

⚫ Waterfall;
⚫ Iterative development;
⚫ Component-based software engineering.
 DIVERSITY OF APPLICATIONS
Stand-alone Applications
Eg.: CAD programs
Interactive Transaction-based Applications
Eg.: Web applications such as e-Commerce applications
Embedded Control Systems
Eg.: Software in a mobile phone
Real Time Systems
Entertainment systems

Data Collection Systems

Eg.: Software interacts with sensors installed in hostile
environment like inside an engine.
System of Systems
Eg.: Generic software products (spreadsheet program)
 SOFTWARE COSTS
Software costs often dominate computer system costs. The
costs of software on a PC are often greater than the
hardware cost.

Software costs more to maintain than it does to develop.

For systems with a long life, maintenance costs may be
several times development costs.

Software engineering is concerned with cost-effective

software development.
 COST OF SOFTWARE ENGINEERING
Roughly 60% of costs are development costs, 40% are testing
costs
⚫ Costs vary depending on the type of system being developed & the
requirements of system attributes such as performance & system
reliability.
⚫ Distribution of costs depends on the development model that is used.

Measurements of Software:
Software measurement is done by-- Metrices
⚫ Product Metric, Process Metrics , Project Metrics
⚫ Product Metric: size( LOC, Function point), reliability, efficiency
⚫ Process Metric: Effort (person per months), time , maturity of the
process, effectiveness of defect removal
⚫ Project Metric: cost, schedule, productivity
 SOFTWARE COMPONENT

An independent deliverable piece of functionality

providing access to its functionality through well
defined interface .It is a module that is
⚫ Deployable

⚫ Replaceable

It is apart of the system that encapsulate

implementation and exposes set of inferences
 SOFTWARE CHARACTERISTICS

It does not wear out

It is not manufactured

It is reusable in the form of component

It is flexible.
 PRINCIPLES of Software Engineering

Rigor & Formality: Creativity and well defined

steps
Separation of concern: Decisions should be
unrelated
Modularity
Abstraction
Anticipation of change
Generality
Incrementallity
 SOFTWARE ENGINEERING METHODOLOGY
Methodology (Method) : Systematic way of developing
product using techniques, tools and strategies and
guideline. It consists of 4 tuple:

i. Model descriptions - Descriptions of graphical models which

should be produced.
ii. Model Constraint - Constraints applied to system models
such as completeness, conformity, fidelity, consistency
iii. Set of steps - Set of activities that can follow or Set of steps
that can be prefigure.
iv. Process guidance - Advice on good design practice or
Transition criteria between steps.
 CASE-Computer Aided Software Engineering
These are the software systems that are intended to provide
automated support for software process activities.

They are often used for method support.

They are of two types:

⚫ Upper CASE - Tools to support the early process
activities of requirements and design
⚫ Lower CASE - Tools to support later activities such as
programming, debugging and testing.
 SOFTWARE ENGINEERING METHODOLOGY
Methodologies can be defined for:
Entire life cycle
Partial life cycle
Tools
Methodology

Process models
Principles
 ROLE OF MANAGEMENT IN SOFTWARE
DEVELOPMENT
The management of software development is heavily
dependent on four factors : People, Product, Process, Project
1.) People: Software development requires good managers who
can understand the psychology of people & provide good
leadership. Manager selection is most crucial and critical for
success of the project. It is the responsibility of a manager to
manage, motivate, encourage , guide and control the people of
his team.
2) Project: In order to manage a successful project, we must
understand what can go wrong and how to do it right. We
should define concrete requirements.
 PROFESSIONAL AND ETHICAL
RESPONSIBILITY
Software engineering involves wider responsibilities than
simply the application of technical skills.

Software engineers must behave in an honest and ethically

responsible way if they are to be respected as professionals.

Ethical behaviour is more than simply upholding the law.

 ISSUES OF PROFESSIONAL
RESPONSIBILITY
Confidentiality: Maintain the confidentiality of your employers or
clients irrespective of whether or not a formal confidentiality
agreement has been signed.

Competence: Should not misrepresent competence and accept work

that is beyond your competence.

Intellectual Property Rights: Aware of local laws governing the

use of patents and copyright, protect IPR of client and employee.

Computer Misuse: Should not use your technical skills to misuse

other people’s computers. Computer misuse ranges from trivial to
extremely serious (dissemination of viruses or other malware).
 ACM/ IEEE CODE OF ETHICS
TheEthical standards have been set up by professional
societies like ACM, IEEE, British Computer Society.

⚫ Members of these organisations sign up to the code of

practice when they join.

⚫ The Code contains eighteen Principles related to the

behaviour of and decisions made by professional software
engineers, including practitioners, educators, managers,
supervisors and policy makers, as well as trainees and
students of the profession.
 CODE OF ETHICS - PRINCIPLES
Public
⚫ Software engineers shall act consistently with the public
interest.

Client and Employer

⚫ Software engineers shall act in a manner that is in the
best interests of their client and employer consistent
with the public interest.

Product
⚫ Software engineers shall ensure that their products and
related modifications meet the highest professional
standards possible.
 CODE OF ETHICS - PRINCIPLES
Judgment
⚫ Software engineers shall maintain integrity and independence in
their professional judgment.

Management
⚫ Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software
development and maintenance.

Profession
⚫ Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
 CODE OF ETHICS - PRINCIPLES
Colleagues
⚫ Software engineers shall be fair to and supportive of their
colleagues.

Self
⚫ Software engineers shall participate in lifelong learning
regarding the practice of their profession and shall promote
an ethical approach to the practice of the profession.
 ETHICAL DILEMMAS
Disagreement in principle with the policies of senior
management.

Your employer acts in an unethical way and releases a

safety-critical system without finishing the testing of the
system.

Participation in the development of military weapons systems

or nuclear systems.
SOFTWARE ENGINEERING
PROCESS MODEL
 SOFTWARE ENGINEERING DEVELOPMENT
ACTIVITIES

1. Requirement analysis & specification

2. Software Design
3. Coding
4. Integration /Testing
5. Installation
6. Delivery & maintenance
 SED ACTIVITIES
1) Requirement Analysis and specifications

⚫ Identify & document exact requirement of the system,

study is performed by customer, developer &
marketing organization.

⚫ Much integration is required between user &

developer

⚫ Software methodology to perform this.

 SED ACTIVITIES
2) System Design:

⚫ Architectural design or high level design

⚫ Overall module structure and organization
⚫ Software detailed design
⚫ Design each module in detail.
 SED ACTIVITIES
3) Coding: Producing the actual code that is deliverable to
customer.

4) Integration /Testing: All the model that were developed

individually are tested & then integrated as a whole
system & then system is tested.

5) Installation: System is installed at customer site.

6) Delivery & maintenance : Any modification made to the

system after the initial delivery
 PROCESS MODELS
A development process is:
set of activities + ordering among them
to reach the desired product

Desired Product
• Conceptual schema
• Logical schema
• Data flow diagram
• Modular structure of programs
Process model
An abstract representation of the development process
presented from a specific perspective
 WHY PROCESS MODELS?
Management Viewpoint
⚫ Control the progress of projects

⚫ Identify milestones and stages

⚫ Monitor the project

⚫ Identify problem points

⚫ Reschedule the project when needed

⚫ Cost, time, and manpower estimates

 WHY PROCESS MODELS?
Technical Viewpoint
⚫ Develop the product and display its structure

⚫ Verify the product

⚫ Improve the process

⚫ Document

⚫ Prototype
 GENERIC PROCESS MODELS
Waterfall Model
Prototype model
Incremental Process Model
Evolutionary Process Model
Rapid application development model

Spiral model
 WATERFALL MODEL
This model is named “waterfall model” because its
diagrammatic representation resembles a cascade of
waterfalls.
 WATERFALL MODEL (Contd…)
Reinforces the notion of “define before design” and
“design before code”.
Easy to understand.

Problems of waterfall model:

Real projects are not sequential

Customers cannot state requirements completely at the

start
•Customer inability to articulate
•Requirements may not be known
High lead times to deliver a working system
Incremental development not possible
 WATERFALL MODEL (Contd…)
High cost of undetected omission/error

Customer dissatisfaction
⚫ No feel for what shall be obtained
⚫ Emphasis on “freezing’
Evolution management is difficult
⚫ Reverse Engineering difficulties
⚫ Requirements modification difficulties
⚫ User sign-off necessary to proceed
Heavily document driven
Analyst may write poorly understood interfaces.
Customer must have patience.
 PROTOTYPING MODEL
1) Initial Requirements
2) Rapid design
3) Develop the prototype
4) Evaluation of prototype by customer
5) Refine requirements and go to step 2

The prototype may be a usable program but is not suitable

as the final software product.
The code for the prototype is thrown away. However
experience gathered helps in developing the actual system.
The development of a prototype might involve extra cost,
but overall cost might turnout to be lower than that
of an equivalent system developed using the waterfall
model.
 INCREMENTAL MODEL
Combining linear Sequential Model to Prototyping Model with
actual product deliverables.
Effective in situations where requirements are defined precisely and
there is no confusion about the functionality of the final product.
The model releases the product with prioritized requirements in the
beginning.
Over the time new functionalities are added and existing
functionalities are enhanced.
Advantages:
It is useful when staff is unavailable or some hardware is yet arriving.
User gets operational product early.
Cost is decreased( less manpower )
Testing is easy.
Disadvantages:
Co-ordination of various modules.
Project Planning & Coordination.
 EVOLUTIONARY PROCESS MODEL
Resembles iterative enhancement model, but differs in the sense that
this does not require a useable product at the end of each cycle.

The same phases as defined for the waterfall model occur here in a
cyclical fashion.

Requirements are implemented by category rather than by priority.

Useful for projects using new technology that is not well understood.

Used for complex projects where all functionality must be delivered

at one time, but the requirements are not well understood at the
beginning.
EVOLUTIONARY PROCESS MODEL
 THE RAPID APPLICATION DEVELOPMENT
(RAD) MODEL

Developed by IBM in 1980

User participation is essential

Build a rapid prototype

Give it to user for evaluation & obtain feedback

Prototype is refined

Reusable components are required to reduce development time.

Highly specialized & skilled developers are required

THE RAPID APPLICATION DEVELOPMENT (RAD)
MODEL
 SPIRAL MODEL
▪Models do not deal with uncertainly which is inherent to
software projects.

▪Important software projects have failed because project

risks were neglected & nobody was prepared when
something unforeseen happened.

▪Barry Boehm recognized this and tired to incorporate the

“project risk” factor into a life cycle model.

▪The result is the spiral model, which was presented in

1986.
SPIRAL MODEL
⚫ 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.
⚫ Risks are explicitly assessed and resolved throughout
the process.
Spiral Model
SPIRAL MODEL
The radial dimension of the model represents the cumulative
costs. Each path around the spiral is indicative of
increased costs.
The angular dimension represents the progress made in
completing each cycle. Each loop of the spiral from X-axis
clockwise through 360o represents one phase.
One phase is split roughly into four sectors of major activities
• Planning: Determination of objectives, alternatives of product
development & constraints on product are identified.
• Risk Analysis: Strategy to identify risks involved and resolve them
• Engineering the Product: design, detailed design, coding and testing
• Customer evaluation: evaluation of product and refining requirements.
 SPIRAL MODEL (contd…)
•An important feature
Each phase is completed with a review by the people
concerned with the project (designers and programmers)
•Advantages
i. The wide range of options to accommodate the good features
of other life cycle models.
ii. It becomes equivalent to another life cycle model in
appropriate situations.

The spiral model has some difficulties that need to be resolved

before it can be a universally applied life cycle model.

▪Lack of explicit process guidance in determining objectives

▪Constraints
▪Alternatives
▪Depends on risk assessment expertise; and
▪Provides more flexibility than required for many applications.
 SELECTION OF LIFECYCLE MODEL
The selection of the model is based on the
following characteristics:
Requirements characteristics
Experience of the development team
User involvement
Project type and associated risk
 SELECTION OF MODEL FOR REQUIREMENTS
REQUIREMENTS WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT

Are requirements YES NO NO NO NO YES

easily
understandable
and defined?
Do we change NO YES NO NO YES NO
requirements quite
often?
Can we define YES NO YES YES NO YES
requirements early
in the cycle?
Requirements are NO YES YES YES YES NO
indicating a
complex system to
be built
 BASED ON STATUS OF DEVELOPMENT TEAM
DEVELOPMENT TEAM WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT

Less experience on NO YES NO NO YES NO

similar projects
Less domain YES NO YES YES YES NO
knowledge
Less experience on YES NO NO NO YES NO
tools to be used
Availability of NO NO YES YES NO YES
training required
 BASED ON USER’s PARTICIPATION
INVOLVEMENT OF USERS WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT

Involved in all NO YES NO NO NO YES

phases
Limited phases YES NO YES YES YES NO
No previous NO YES YES YES YES NO
experience of
similar projects
Expert of domain NO YES YES YES NO YES
 TYPE OF PROJECT WITH ASSOCIATED RISK
PROJECT TYPE AND RISK WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT

Enhancement of NO NO YES YES NO YES

the existing system
Funding is stable YES YES NO NO NO YES
High reliability NO NO YES YES YES NO
requirements
Tight project NO YES YES YES YES YES
schedule
Use of reusable NO YES NO NO YES YES
components
Resources(Time, NO YES NO NO YES NO
Money, people)
scarce