Introduction to Software

Engineering

N. L. Sarda
I.I.T. Bombay

1
Outline
• Nature of software projects
• Engineering approaches
• Software process
• A process step
• Characteristics of a good process
• Waterfall model for development
• Other models
• Project planning

2
Software Systems

• Ubiquitous, used in variety of

applications
– Business, engineering, scientific
applications
• Simple to complex, internal to public,
single function to enterprise-wide, one
location to distributed, batch or real-
time, informational to mission-critical,
….

3
Challenge in large projects
• Developing large/complex software
application is very challenging
– Effort intensive
– High cost
– Long development time
– Changing needs for users
– High risk of failure, user acceptance,
performance, maintainability, …
• Quite different from one-time
programs where author and user are
same ! 4
Successful software system
• Software development projects have
not always been successful
• When do we consider a software
application successful?
– Development completed
– It is useful
– It is usable, and
– It is used
• Cost-effectiveness, maintainability
implied
5
Reasons for failure
• Schedule slippage
• Cost over-runs
• Does not solve user’s problem
• Poor quality of software
• Poor maintainability

6
Reasons for failure ….
• Ad hoc software development results
in such problems
– No planning of development work (e.g.
no milestones defined)
– Deliverables to user not identified
– Poor understanding of user
requirements
– No control or review
– Technical incompetence of developers
– Poor understanding of cost and effort by
both developer and user
7
Engineering: other disciplines
• Large projects common and
successfully done
– Buildings bridges, dams
– Power plants
– Aircrafts, missiles, …
• “engineering” a solution:
– To design, develop (build, fabricate) an
artifact that meets specifications
efficiently, cost-effectively and ensuring
quality
– Using scientific principles.
8
Engineering …
• Requires well-defined approach :
repeatable, predictable
• Large projects requires managing the
project itself
– Manage people, money (cost),
equipment, schedule
– Scale makes big difference: compare
building a hut, 2–storeyed house, or 50-
storeyed apartment building
• Quality extremely important : relates
to failures, efficiency, usability, ….
– People willing to pay for quality !
9
Large Projects

• Involve different types of people

– Large building : architect, civil engineer,
electrical engineer, workers (masons,
carpenters), ….
• Continuous supervision for quality
assurance
– On site supervisors (check cement/steel
quality, ensuring proper mix of sand &
cement, ….)

10
Large projects …
• Many deliverables : architecture plan,
model, structure diagrams, electrical
cabling layouts, …
• Standards, regulations, conventions
need to be followed
• Steps, milestones defined and reviews
are carried out; progress is visible
• Project planning and project
management essential

11
Software projects

• Software is different from other

products
– Cost of production concentrated in
development
– Maintenance consists of making
corrections and enhancing or adding
functions
– Progress in development is difficult to
measure

12
Apply Engineering Approach
• Hence planning and control even more
important in software development 
engineering approach:
– Attempt to estimate cost/effort
– Plan and schedule work
– Involve user in defining requirements
– Identify stages in development
– Define clear milestones so that progress can be
measured
– Schedule reviews both for control and quality
– Define deliverables
– Plan extensive testing

13
Job of Software Developer is
difficult
•Dealing with users
– Ill-defined requirements
– Concern with ease-of-use and response time
•Dealing with technical people
– Concerned with coding, databases, file
structures, etc.
•Dealing with management
– Concerned with return on their investment
– Cost-benefit analysis
– Schedule

14
Software Process
• Process consists of activities/steps to
be carried out in a particular order
• Software process deals with both
technical and management issues
• Consists of different types of process
• Process for software development:
produces software as end-result
– multiple such processes may exist
– a project follows a particular process

15
Process Types …
• Process for managing the project
– defines project planning and control
– effort estimations made and schedule
prepared
– resources are provided
– feedback taken for quality assurance
– monitoring done.

16
Process Types …
• Process for change and configuration
mgmt.
– Resolving requests for changes
– Defining versions, their compositions
– Release control
• Process for managing the above
processes themselves
– Improving the processes based on new
techniques, tools, etc.
– Standardizations and certifications (ISO,
CMM)
17
Multiple processes
• A large software development
company may have multiple
development processes
A. For client-server based conventional
applications (sales processing, payroll)
B. For enterprise-level (ERP) projects based on
packages and customization
C. For web-based e-commerce type
D. For data-warehousing/decision-support type
• The company may have many
projects in each category
18
Step in a Process
• Each step has a well-defined
objective
• Requires people with specific skills
• Takes specific inputs and produces
well-defined outputs
• Step defines when it may begin
(entry criteria) and when it ends (exit
criteria)
• Uses specific techniques, tools,
guidelines, conventions.
19
Process step …
•Step must be executed as per project plan
that gives duration, effort, resources,
constraints, etc.
•It must produce information for
management so that corrective actions
can be taken
– E.g., adding more resources
•A step ends in a review (V&V)
– Verification: check consistency of outputs
with inputs (of the step)
– Validation: check consistency with user needs
20
Process step
(entry criteria) (exit criteria)

actions to
Review
be carried
inputs V&V outputs
out

info for
Project management
Control info

21
Characteristics of a Good
Process
•Should be precisely defined – no
ambiguity about what is to be done,
when, how, etc.
•It must be predictable – can be repeated
in other projects with confidence about
its outcome
– Predictable with respect to effort, cost:
Project A: Web-based library applications done by
3 persons in 4 months
⇒ another project B (guest house bookings),
similar in complexity should also take about 12
person months.
22
A Good Process …
– Predictable for quality: with respect to number and
type of defects, performance, …
• Predictable process is said to be ‘under
statistical control’ , where actual values are
close to expected values
• It supports testing and maintainability
– Maintenance by third party
– Follow standards, provide necessary documentation
– This characteristic differentiates between prototype
and product

23
A Good Process …
• Facilitates early detection of and
removal of defects
– Defects add to project cost
– Late detection/correction is costly
• It should facilitate monitoring and
improvement
– Based on feedback
– Permit use of new tools, technologies
– Permit measurements

24
Waterfall Model for
Development
• Here, steps (phases) are arranged in
linear order
– A step take inputs from previous step,
gives output to next step (if any)
– Exit criteria of a step must match with
entry criteria of the succeeding step
• It follows ‘specify, design, build’
sequence that is intuitively obvious
and appears natural

25
Waterfall Model …
• Produces many intermediate
deliverables, usually documents
– Standard formats defined
– Act as ‘baseline’ used as reference (for
contractual obligations, for
maintenance)
– Important for quality assurance, project
management, etc.
• It is widely used (with minor
variations) when requirements are
well understood
26
 Waterfall Model
system -software part of some larger system
engineering -establish requirements for all elements of the system; assign some
to software
Analysis -understand information domain, functions, performance
Project planning and interfacing. Project plans made

-translate requirements into s/w architecture, data structures

design and procedural details. A ‘detailed design’ step can be
added

code -programming

testing & -test logic and function interfaces

integration

-deployment; make changes for

Installation &
-Errors, performance
maintenance
-changes in requirement 27
Deliverables in Waterfall
Model
• Project plan and feasibility report
• Requirements document (SRS :
Software Requirement Specifications)
• System design document
• Detailed design document
• Test plans and test reports
• Source code
• Software manuals (user manual,
installation manual)
• Review reports
28
 Cost/Effort Distribution
Total accumulated
cost

Problem Feasibili Analysis System Detailed Impleme Mainten

definitio ty study design design n- -
n tation ance
• Accumulated cost increases dramatically as
programmers, operators, technical writers and
computer time is committed.
• Cost of discovering and fixing errors also increases with
steps
29
Shortcomings of Waterfall
Model
• Requirements may not be clearly
known, especially for applications not
having existing (manual) counterpart

– Railway reservation: manual system

existes, so SRS can be defined
– On-line container management for
railways - new
– Knowledge management for a central
bank – new

30
Shortcomings …
• Requirements change with time
during project life cycle itself
– Users may find solution of little use
– Better to develop in parts in smaller
increments; this is common for
packages, system software
• Considered documentation-heavy: so
much documentation may not be
required for all types of projects.

31
Prototyping Model
• When customer or developer is not
sure
– Of requirements (inputs, outputs)
– Of algorithms, efficiency, human-machine
interaction
• A throwaway prototype built from
currently known user needs
• Working or even ‘paper’ prototype

32
Prototyping …

• Quick design focuses on aspects

visible to user; features clearly
understood need not be implemented
• Prototype is tuned to satisfy customer
needs
– Many iterations may be required to
incorporate changes and new
requirements
• Final product follows usual define-
design-build-test life cycle
33
Prototyping
Requirements
gathering
‘Quick’
design
build
prototype
evaluate &
refine
Engineer
product

34
Limitations of Prototyping
• Customer may want prototype itself !
• Developer may continue with
implementation choices made during
prototyping
– may not give required quality,
performance, ….
• Good tools need to be acquired for
quick development
• May increase project cost

35
Iterative Development
•Useful for product development where
developers define scope, features to
serve many customers
•Early version with limited feature
important to establish market and get
customer feedback
•Initial version may follow any method
•A list of features for future versions
maintained
•Each version is analyzed to decide
feature list for next iteration
36
• Evolutionary Development model [SE-7, Fig
4.2]
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version

37
 Evolutionary Development..
• Main characteristics:
– The phases of the software construction are
interleaved
– Feedback from the user is used throughout the
entire process
– The software product is refined through many
versions
• Types of evolutionary development:
– Exploratory development
– Throw-away prototyping

38
Evolutionary Development…
• Advantages:
– Deals constantly with changes
– Provides quickly an initial version of the system
– Involves all development teams
• Disadvantages:
– Quick fixes may be involved
– “Invisible” process, not well-supported by
documentation
– The system’s structure can be corrupted by
continuous change

39
Evolutionary Development …
• Disadvantages [cont’d]:
– Special tools and techniques may be
necessary
– The client may have the impression the first
version is very close to the final product and
thus be less patient
• Applicability:
– When requirements are not well understood
– When the client and the developer agree on
a “rapid prototype” that will be thrown away
– Good for small and medium-sized software
systems
40
 Component-based Software
Engineering

Requirem ents Com ponent Requirem ents Systemdesign

specification analysis m odification withreuse

Developm ent System

andintegration validation

41
Component-based Software
Engineering..
• Main characteristics:
– Makes intensive use of existing reusable
components
– The focus is on integrating the
components rather than on creating
them from the scratch

42
Component-based Software
Engineering.
• Advantages:
– Reduces considerably the software to be
developed “in-house”
– Allows faster delivery
– In principle, more reliable systems, due
to using previously tested components

43
Component-based Software
Engineering
• Disadvantages:
– Compromises in requirements are needed
– Less control over the system’s evolution
• Applicability:
– When there is a pool of existing
components that could satisfy the
requirements of the new product
– Emerging trend: integration of web
services from a range of suppliers

44
Spiral Model
• Activities are organized in a spiral having
many cycles
• Four quadrants in each cycle

1. Determine objectives, 2. Evaluate alternatives,

Alternatives, constraints identify and handle risks

4. Plan next step 3. Develop the software

45
Spiral Model …
• Prototyping, simulations, benchmarking
may be done to resolve uncertainties/risks
• Development step depends on remaining
risks; e.g.,
– Do prototype for user interface risks
– Use basic waterfall model when user interface
and performance issues are understood but only
development risk remains
• Risk driven : allows us mix of specification-
oriented, prototype-oriented, simulation
based or any other approach.

46
The Spiral Model

47
 Spiral Model
• Main characteristics:
– Also a hybrid model that support process
iteration
– The process is represented as a spiral, each
loop in the spiral representing a process phase
– Four sectors per loop: objective setting, risk
assessment and reduction, development and
validation, planning
– Risk is explicitly taken into consideration

48
Spiral Model
• Advantages:
– Risk reduction mechanisms are in place
– Supports iteration and reflects real-world practices
– Systematic approach
• Disadvantages:
– Requires expertise in risk evaluation and reduction
– Complex, relatively difficult to follow strictly
– Applicable only to large systems
• Applicability:
– Internal development of large systems

49
 The Rational Unified Process

P h as e i t erat i o n

In cep t i o n E l ab o rat i o n C o n s t ru ct i o n Tran s i t i o n

50
Major work products in UP phases
• Inception phase
– Vision doc, early use cases, feasibility, project
plans
• Elaboration phase
– Detailed use cases, analysis, architecture
design, detailed plan, preliminary user manual
• Construction phase
– Detailed design, components, test plans/cases,
implementation, detailed manuals
• Transition phase
– Delivery, beta/acceptance, user feedback

51
What is CASE (Computer-Aided
Software Engineering)

• Software systems that are intended to

provide automated support for software
process activities.
• CASE systems are often used for method
support.
• 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.
52
 • Classification of CASE technology [SE-7, Fig 4.14]
CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches

53
Project Management Process
•Runs in parallel to development process
•Project planning, monitoring and control
are the basic goals
•Project plan indicates how project will be
executed successfully
– Without plan, there is no management
– Without measurement, not much planning
possible
– Plan allows progress to be measured
– Plan produced before development begins
and constantly updated

54
Project Planning
• Prepare cost/effort estimation
– Based on project complexity, scope, productivity
levels, other historical data
– Many models available
• Select development process, define
milestones and prepare schedule
– Know how effort is distributed over phases from
historical data
• Decide project staffing
• Make quality control plans: define reviews,
inspections, testing strategies to
detect/remove defects
55
Project Monitoring and
Control
• Plan defines various activities: many
ways to represent: Gantt chart, time
bar chart, PERT/CPM project activity
network
– Show activities, expected durations,
resources allocated
– Critical paths can be identified

56
Project monitoring …

• Each development step gives

information for tracking progress for
identifying delays, bottlenecks, etc.
– Allows corrective action: add more
resources reduce scope, re-negotiate
cost/schedule, etc.

57
Summary
• Challenges in software development and
need for ‘engineering’ approach
– Step-by-step methodology with specific
deliverables
• Types of software processes
– For development, for project management, …
• Precise definition of a step
• Waterfall model : natural, widely followed
in spite of its limitations
•Project management – for planning,
monitoring and control

58