Introduction to Software Engineering

Dr. Shailesh Kulkarni

[email protected]
Department of E&TC

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48

(An Autonomous Institute affiliated to Savitribai Phule Pune University)
(NBA and NAAC accredited, ISO 9001:2015 certified)
 Objective/s of this session
1. To understand nature of software
2. To learn software engineering principles and software
processes.
3. To discuss myths about software
Learning Outcome/Course Outcome
1. To understand software engineering principles and
software processes
2. To know nature and myths of software

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 2

 Content

Nature of Software
Software Engineering Principles
Software Process
Software Myths

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48

3
 Software Engineering

The economies of ALL developed nations are dependent on

software
More and more systems are software controlled
Software engineering is concerned with theories, methods and
tools for professional software development.
Expenditure on software represents a significant fraction of GDP
in all developed countries

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 4

 FAQs about software engineering

• What is software?
• What is software engineering?
• What is the difference between software engineering and
computer science?
• What is the difference between software engineering and
system engineering?
• What is a software process?
• What is a software process model?

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 5

 FAQs about software engineering

• What are the costs of software engineering?

• What are software engineering methods?
• What is CASE (Computer-Aided Software Engineering)
• What are the attributes of good software?
• What are the key challenges facing software engineering?

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 6

 What is software?
• Computer programs and associated documentation such as
requirements, design models and user manuals.
• Software products may be developed for a particular customer or
may be developed for a general market.
• Software products may be
Generic - developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
Custom - developed for a single customer according to their
specification.
• New software can be created by developing new programs,
configuring generic software systems or reusing existing software.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 7

 What is Software?
Software is a set of items or objects that form a “configuration” that
includes
 programs
 documents
 data

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 8

 Software’s Dual Role

• Software is a product
Delivers computing potential
Produces, manages, acquires, modifies, displays, or transmits
information
• Software is a vehicle for delivering a product
Supports or directly provides system functionality
Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 9

 Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time
BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 10
 What is software engineering?

• Software engineering is an engineering discipline that is concerned with

all aspects of software production.
• Software engineers should adopt a systematic and organised approach
to their work and use appropriate tools and techniques depending on
the problem to be solved, the development constraints and the
resources available.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 11

 Software Engineering Vs Computer Science?

• Computer science is concerned with theory and fundamentals; software

engineering is concerned with the practicalities of developing and
delivering useful software.
• Computer science theories are still insufficient to act as a complete
foundation for software engineering (unlike e.g. physics and electrical
engineering).

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 12

 Software Engineering Vs System Engineering?

• System engineering is concerned with all aspects of

computer-based systems development including hardware,
software and process engineering. 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.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 13

 What is a software process?

• A set of activities whose goal is the development or evolution of

software.
• Generic activities in all software processes are:
Specification - what the system should do and 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.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 14

 What is a software process model?

• A simplified representation of a software 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.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 15

 What are software engineering methods?

• Structured approaches to software development which include

system models, notations, rules, design advice and process
guidance.
• Model descriptions
Descriptions of graphical models which should be produced;
• Rules
Constraints applied to system models;
• Recommendations
Advice on good design practice;
• Process guidance
What activities to follow.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 16

 Attributes of good software

• The software should deliver the required functionality and performance

to the user and should be maintainable, dependable and acceptable.
• Maintainability
Software must evolve to meet changing needs;
• Dependability
Software must be trustworthy;
• Efficiency
Software should not make wasteful use of system resources;
• Acceptability
Software must accepted by the users for which it was designed. This
means it must be understandable, usable and compatible with other
systems.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 17

 Key challenges facing software engineering

• Heterogeneity, delivery and trust.

• Heterogeneity
Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
• Delivery
Developing techniques that lead to faster delivery of software;
• Trust
Developing techniques that demonstrate that software can be
trusted by its users.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 18

 Software Applications

• system software
• application software
• engineering/scientific software
• embedded software
• product-line software
• WebApps (Web applications)
• AI software

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 19

 Software—New Categories

• Ubiquitous computing—wireless networks

• Netsourcing—the Web as a computing engine
• Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 20

 Legacy Software

• Software must be adapted to meet the needs of new

computing environments or technology.
• Software must be enhanced to implement new business
requirements.
• Software must be extended to make it interoperable with
other more modern systems or databases.
• Software must be re-architected to make it viable within a
network environment.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 21

 Software Myths

• It affects managers, customers (and other non-technical

stakeholders) and practitioners
• These are believable because they often have elements of truth,
but invariably lead to bad decisions,
• Therefore, it insists on reality as you navigate your way through
software engineering

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 22

 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 is it used ? Are
software practitioners aware of its existence ? Does it reflect modern
software development practice ? Is it complete ? In many cases, the
answer to all of these questions is "no".

• Myth : My people do have state-of-the-art software development tools,

after all, we buy them from the newest computers.
• Reality : It takes much more than the latest model mainframe,
workstation, or PC to do high quality software development.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 23

 Management Myths

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

and catch up.
• Reality : Software development is not a mechanistic process like
manufacturing. However, 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.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 24

 Customer Myths

• Myth : A general statement of objectives is sufficient to begin writing

programs.
• Reality : Poor-up-front definition is the major cause of failed software
efforts. A formal and detailed description of information domain,
function, performance, interfaces, design constraints, and validation
criteria is essential.

• Myth : Project requirements continuously change, but change can be

easily accommodated because software is flexible.
• Reality : It is true that software requirements do change, but the impact
of change varies with the time at which it is introduced.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 25

 Practitioner Myths

• Myth: Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.
• Reality: Software engineering is not about creating documents. It is
about creating a quality product. Better quality leads to reduced rework.
And reduced rework results in faster delivery times.

• Myth : Once the program is written and running, my job is done.

• Reality : Someone once said that “the sooner you begin ‘writing code,’
the longer it’ll take you to get done.” 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.

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 26

 References

•Roger Pressman, “Software Engineering: A Practitioner’s

Approach”, Mcgraw Hill
•Ian Sommerville, “ Software Engineering”, Addision and Wesley

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 27

 Contents
• Generic Process Model
• Prescriptive Process Model
• Waterfall Model
• Incremental Process (RAD) Model
• Evolutionary Process Model
• Unified Process Model
• Concurrent Model

BRACT’S, Vishwakarma Institute of Information Technology, Pune-48 28

A Layered
Technology
Software Engineering

tools
methods
process model
a “quality” focus
 Quality Focus
• TQM, Six Sigma gives continuous process improvement culture.
• Leads to the development of increasingly more effective approaches to
software engineering

30
 Process
• Glue that holds the technology layers together.
• Enables rational & timely development of computer software.
• Defines framework that must be established for effective delivery of
software engineering technology.
• Forms the basis for management control of software projects.
• Establishes the context in which technical methods are applied, work
products are produced, milestones are established, quality is ensured,
change is properly managed.

31
 Methods
• Provide the technical “how to’s “ for building software.
• Encompass a broad array of tasks that include communication,
requirement analysis, design modeling, construction, testing, support.

32
 Tools
• Provide automated or semi-automated support for the process and
the methods.
• Integration of tools
• Information is shared

33
 A Process Framework
• Process framework
Framework activities
work tasks
work products
milestones &
deliverables
QA checkpoints
Umbrella Activities

34
 Framework Activities
• Communication
• Planning
• Modeling
Analysis of requirements
Design
• Construction
Code generation
Testing
• Deployment

35
 Umbrella Activities

• Software project management

• Formal technical reviews
• Software quality assurance
• Software configuration management
• Work product preparation and production
• Reusability management
• Measurement
• Risk management

36
 The Process Model: Adaptability

• the framework activities will always be applied on every project

but the tasks for each activity will vary based on:
the type of project
characteristics of the project
common sense judgment; concurrence of the project team

37
 Process Patterns

• Process patterns define a set of activities, actions, work tasks,

work products and/or related behaviors
• A template is used to define a pattern
• Typical examples:
 Customer communication (a process activity)
 Analysis (an action)
 Requirements gathering (a process task)
 Reviewing a work product (a process task)
 Design model (a work product)

38
 Personal Software Process (PSP)

• Recommends five framework activities:

Planning
High-level design
High-level design review
Development
Postmortem
• Stresses the need for each software engineer to identify errors early
and as important, to understand the types of errors

39
 Purpose

• To build computer software.

• Process may be haphazard, ad-hoc, may change on daily basis, may
not be efficient, effective.
• Emphasizes personal measurement of both the work product that is
produced and resultant quality of the work product.
• Makes practitioner’s responsible for project planning (estimating &
scheduling)
• Empowers that practitioner to control the quality of all software
work products are developed.

40
 Disadvantage

• Not widely adopted throughout the industry.

• Have more to do with human nature and organizational inertia than
strengths & weaknesses of PSP approach.
• Intellectually challenging & demands a level of commitment that is not
always possible to obtain.
• Training is lengthy, training cost is high,
• The required level of measurement is culturally difficult for many
software people.

41
 Team Software Process (TSP)

• Each project is “launched” using a “script” that defines the tasks to be

accomplished
• Teams are self-directed
• Measurement is encouraged
• Measures are analyzed with the intent of improving the team process

42
 Purpose

• Build a self-directed project team that organizes itself to produce high

quality software.
• A self directed team has a consistent understanding of its overall goals &
objectives.
• It defines roles & responsibilities for each team member; tracks
quantitative project data; identify a team process that is appropriate for
project & a strategy for implementing the process; defines local
standards; assesses risk; tracks, manages, reports project status.

43
 The Waterfall Model

Co m m u n ic a t io n
p ro je c t in it ia t io n Planning
re q u ire m e n t g a t h e rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De p lo y m e n t
c ode
t es t d e liv e ry
s u p p o rt
f e e dba c k

44
 Theory

• Systematic and sequential approach to software development.

• Classic life cycle model
• Model mandates that each phase will be executed after completion of the
previous phase

45
 Advantages

• Simplicity
• Logical structuring of the different activities in a software
project
• Model is perfect for projects where requirements are very
well defined.

46
 Disadvantages

• It is strict about moving only one step at a time. This is to ensure that the
complete project is moving together.
• Customer has difficulty expressing requirements in their entirely.
• Has difficulty accommodating natural uncertainty that exists at the
beginning of the cycle.
• Model does not allow capturing potential risk in the project.
• A working version of the software is not available until late in the
process.

47
 The Incremental Model

incre m e n t # n
Co m m u n i c a t i o n
P l a n n i n g

M o d e l i n g
a n a ly s is Co n s t ru c t i o n
d e s ig n
c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k

d e liv e ry o f
in cre m e n t # 2 n t h in cre me n t

Co m m u n i c a t i o n
P l a n n i n g

M o d e l i n g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
in cre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
P l a n n i n g
M o d e l i n g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
d e liv e ry o f
De p l o y m e n t
t est d e l i v e ry
fe e d b a c k

1 s t in cre m e n t

project calendar t ime

48
 Theory

• Combines elements of the waterfall model applied in iterative manner.

• Applies linear sequences in a staggered fashion as calendar time
progresses.
• Each linear sequence produces deliverable increments of the software.
E.g. word processing software.
• Focuses on the delivery of an operational product with each increment.

49
 Advantages

• Useful when staffing is unavailable.

50
 The RAD Model
Te am # n
Mo d e lin g
bus in e s s m od e ling
da t a m od e ling
proc e s s m od e ling

C o n s t ru c t io n
c om p one nt re u s e
Te am # 2 a ut om a t ic c od e
Co m m u n ic at io n ge ne ra t ion
t e s t in g
Mo d e li ng
b u s in e s s m o d e lin g
d a t a m o d e lin g
p ro ce s s m o d e lin g

Plan n in g
Co ns t ruc t io n De p lo ym e n t
Te am # 1 co m p o n e n t re u s e
in t e g rat io n
a u t o m a t ic co d e
g e n e ra t io n d e liv e ry
Mo d e lin g t e s t in g fe e d b ack
b u s in e s s mo d e lin g
d at a mo d e lin g
p ro ce s s mo d e lin g

Co n s t ru c t io n
co mp o n e n t re u s e
au t o mat ic co d e
g e n e rat io n
t e s t in g

6 0 - 9 0 d ays

51
 Theory

• Rapid Application Development

• It is recommended where there are tight deadlines and high pressure from
customer
• Emphasizes on short development cycle
• Each major function can be addressed by a separate RAD team followed
by the integration of the separately developed functionalities
• Necessitates the involvement of users throughout the development life
cycle

52
 Advantages

• Provides quick time to market.

• Fully functional system is expected within a short time of say 60 to 90
days.

53
 Disadvantages

• It requires sufficient human resources to create the right number of RAD

teams.

54
Evolutionary Models: Prototyping

Q u i c k p la n

Co m m u n ic a t io n

Mo d e lin g
Q u ic k d e s i g n

De p loym e n t
De liv e ry
& Fe e d b a c k Co n s t ru c t io n
of
p ro t o t y p e

55
 Theory

• Iterative approach to software development

• Useful when either the customer or the developer is unsure of the exact
requirements of the software.
• Throw-way Model: Discard the model once all requirements are
understood.
• Evolving Model: Refine the model every time when the requirements are
clearer.

56
 Advantages

• Minimizing technical risks.

57
 Disadvantages

• It may lead to indiscipline of development

58
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

59
 Theory

• Meta Model for software development processes.

• Model couples the iterative nature of the prototyping model and the
controlled, systematic aspect of the waterfall model.
• It is evolutionary software process model.

60
 Advantages

• Introduces the element of risk analysis.

• It is more realistic because real world engineering requires considerable
iteration.

61
 Disadvantages

• It requires considerable expertise in terms of risk assessment and project

management.

62
Evolutionary Models: Concurrent

none

Mode ling a c t ivit y

rep res ent s t he s t at e

Unde r o f a s o ft ware eng ineering
act ivit y o r t as k
de ve lopm e nt

Awa it ing
c ha nge s

Unde r re vie w

Unde r
re vis ion

Ba s e line d

Done

63
 The Rational Unified Process (RUP)
• A modern generic process derived from the work on the
UML and associated process.
• Brings together aspects of the 3 generic process models
discussed previously.
• Normally described from 3 perspectives
- A dynamic perspective that shows phases over time;
– A static perspective that shows process activities;
– A practice perspective that suggests good practice.

64
Phases in the Rational Unified Process

65
 RUP phases
• Inception
- Establish the business case for the system.
• Elaboration
- Develop an understanding of the problem domain and the system
architecture.
• Construction
- System design, programming and testing.
• Transition
- Deploy the system in its operating environment.

66
 RUP iterations
• In-phase iteration
- Each phase is iterative with results
developed incrementally.
• Cross-phase iteration
- As shown by the loop in the RUP model, the
whole set of phases may be enacted
incrementally.

67
Static workflows in the Rational Unified Process

68
Static workflows in the Rational Unified Process

69
RUP overview
 RUP good practices
• Develop software iteratively
- Plan increments based on customer priorities and deliver
highest priority increments first.
• Manage requirements
- Explicitly document customer requirements and keep
track of changes to these requirements.
• Use component-based architectures
- Organize the system architecture as a set of reusable
components.
71
 RUP good practices
• Visually model software
- Use graphical UML models to present static and dynamic views
of the software.
• Verify software quality
- Ensure that the software meet’s organizational quality standards.
• Control changes to software
- Manage software changes using a change management system
and configuration management tools.

72
 Key points
• Processes should include activities to cope with change. This
may involve a prototyping phase that helps avoid poor
decisions on requirements and design.
• Processes may be structured for iterative development and
delivery so that changes may be made without disrupting the
system as a whole.
• The Rational Unified Process is a modern generic process
model that is organized into phases (inception, elaboration,
construction and transition) but separates activities
(requirements, analysis and design, etc.) from these phases.
73
Thank You

74