Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture no. 5
Software Engineering Processes
1 of 3

6. Quality Product
• For a quality software product, both the
quality of product itself and quality of
software process are important.
• The cost of error recovery in the later phases
of software is many times more than in earlier
phases, so more attention should be paid in
the earlier phases, and these should be made
error-free.

7. Boehm 1987 - ‘Industrial Sw Metrics Top 10 List’
1. Finding and fixing a Sw problem after delivery, costs 100 times more than
finding and fixing the problem in early design phases
2. You can compress Sw development schedule 25% of nominal, but no more
3. For every $1 you spend on development, you will spend $2 on
maintenance
4. Sw Development and maintenance costs are primarily a function of the
number of SLOC or DLOC – Delivered Lines of Code
5. Variations among people account for the biggest differences in Sw
productivity
6. The overall ratio of Sw : Hw costs is still growing, in 1955 it was 15:85, in
1985, 85:15 {and in 2011 it is almost 95:5}
7. Only 1/6th or about 15 -16% of sw development effort is devoted to
programming
8. Sw products typically cost 3 times as much per SLOC as individual Sw
programs, Sw systems (i.e. system of systems) cost 9 times as much Sw
programs (Sw pgm : Sw Product : Sw Sys :: 1:3:9)
9. Walkthroughs catch 60% of the errors
10. 80% of the contribution comes from 20% of the contributors – Corollary
of Pareto Law

8. Pareto Analysis or Principle
In any series of elements to be controlled, a
selected, small fraction, in terms of the
numbers of elements, always accounts for a
large fraction in terms of effect.
– Vilfredo Pareto (1848-1923) – an
economist and sociologist

9. Pareto Analysis or Principle implies
• Focus on the problem and try to identify “the vital or
significant few versus the trivial many”
• Few examples
– Only a small percentage of the thousands of inventory items in a
department store account for 80% of the dollar sales (large stores
capitalize on this)
– Less than10% of employees in an organization will account for most of
the absenteeism
– A few percent of the kinds of illnesses are the cause of admission for a
great majority of hospital patients
– Steve M Erickson (1981); Management Tools for Everyone: Twenty Analytical
Techniques That Are Easy to Learn and Valuable to Know; Petrocelli Books Inc.
New York, USA

10. – A detailed analysis of patients revealed that 80% of common diseases,
like fever, cough, cold etc are ‘minor’ diseases and can be cured by
educating masses about hygiene
– Dr Ijaz Bashir, Chairman, Decent Welfare Society, Gujrat, Pakistan – Sept 2010
– Some figures from Proceedings of the Seminar on CORPORATE
AGRICULTURE: ISSUES & OPTIONS; UAAR (2001)
• 93% people own 37% of the land whereas the rest 7% own 63% of the land
• Over 80% of the farmers either own less than 2 hectors of land or are landless
tenants
• Over 70% of the land holdings are below 12.5 acres
• Less than 6% own over 60 hectors of land
• 1 Hectare = 10,000 m2 and 1 acre = 4840 Yards2 = 4047 m2

11. Maintenance Aspects
– 1970s Development-then-Maintenance Model
+ Well defined two stages
- Changing Application Environments
- Every product developed from Scratch - No reuse
– Maintenance is a process that occurs when
‘Software undergoes modifications to code and associated
documentation due to a problem or the need of improvement
or adaptation’ [ISO/IEC ‘95]

12. • For every 1$ spent on development, 2$s are spent on
maintenance
• In 1992, 60%-80% of R & D staff at HP was involved in
Maintenance, and Maintenance constituted 40-60% of
the total cost of Software [Colman et al 1994]
• Organizations devote upto 80% of their time and effort
to maintenance [Yourdon 1996]
• Maintenance is an extreme phase, so techniques
efficient for Maintenance result in overall saving
Maintenance Aspects (Contd.)

13. Failure Curve for Hardware
Software doesn’t wear out but it deteriorates

14. Idealized and Actual Failure
Curve for Software
Increased Failure rate due to side effects and corrections or bug fixes made
Software Engineering methods strive to reduce the magnitude of the spikes
and the slope of the actual curve

15. Software Process
Is a set of activities and associated results which produce a
Software Product. These activities are carried out (mostly) by
humans, using different tools (including CASE tools) and
predefined methods.
The main four fundamental activities which are common to all Sw
processes are:
Specification, Development, Validation and Evolution.
There exist a number of Sw Processes, initiated by different
individuals and organizations. Different processes can be used to
develop the same product, but they do have their own
specificities.
Software Processes

16. Software Process ..
To introduce visibility in the process different graphical
notations are used to produce different design documents.
Since different methods have different origins, so these are
different and have different notations for their deliverable
documents. Now effort is being made to unify them.
Different metrics have been devised to control and optimize
the software process to produce ‘Quality’ product.
Paradigm or Methodology
Is collection of consistent methods used to support all
activities or phases of software development life cycle. Each
phase being the part of the process, has its own inputs and
deliverables, so these need to conform, semantically and as
well as in notations.

17. Software Process and Its Components
Software Process
Product
Engineering
Processes
Process
Management
Process
Development
Process
Project
Management
Process
Software
Configuration
Process

18. Characteristics of Software Process
• Process should be
– Predictable
– Support Testability and Maintainability
– Support Change
– Early Error or Defect Removal
– Process Improvement and Feedback

19. SE-381
Software Engineering
BEIT-V
Lecture no. 6
Software Engineering Processes
2 of 3

20. Software Paradigms
• Classical or Structured Paradigm
• Data Structures and Behavior is loosely connected
• Data Structures are identified using Entity Relationship and
Attribute Analysis
• Behavior of the system is understood by analyzing the data flow
with in the system, among different data structures. Data Flow
Diagrams are used to portray this transition of data
• Functions performed by the system are resolved into different
strongly-cohesive and loosely-coupled modules
• Modules and their interaction are presented in Structure Charts,
and their functionality is written in un-ambiguous ‘structured
English’
• The system is considered as a whole – one lump.

21. • Object Oriented Paradigm
• Is a new way of thinking about problems using models organized
around real-world concepts
• Fundamental construct is Object, which combines Data structure
and behavior in one entity (Encapsulation)
• Software is collection of discrete objects
• OO approach exploits the four characteristics – Identity,
Classification, Polymorphism and Inheritance
• Users functional requirements are represented thru Use Case
Diagrams, Classification of objects represented using Class
Diagrams, interaction of different objects and Classes is shown
using Sequence Diagrams, all activities are shown using Activity
Diagrams, etc.
• There are different methodologies which support OO paradigm for
all/some phases of software development
• Object Modeling Technique (OMT) is one such methodology which
supports from Requirement phase thru Design and
Implementation phases to Maintenance phase of the SDLC
Software Paradigms .

22. Client, User & Developer
• Client
Who initiates and pays for the product and effort
incurred therein, can be a person or an organization
• User
Person(s) who will be using the product, on Client’s
behalf
• Developer
Person(s) involved in any of the phases of software
development, from Analysis to Implementation and
Testing

23. Personal / Groups Involved in SD
• Developers
Software Analysts, Architects, Designers,
Programmers or Coders, Testers, Document
Writers etc
• Project Managers
Looking after the execution of software project, it
includes planning, monitoring and control and
termination phases
• Configuration Controllers
Involved in Configuration Control or Sw
Configuration Management Process

24. • SQA Division or Section
Solely responsible for assuring quality of the produced
products, directly reporting to CEO. Has qualified members
having expertise in all Software development areas
• SQA Group
Software Quality Assurance group will be responsible for
assuring quality of the product at a particular phase or
stage. Depending upon product size, its composition (and
size) could vary for each phase, must of at least 4-5
members, representatives from Client, previous stage,
current stage and next stage, should be headed by an
experienced person from SQA division
• Software Engineering Process Group (SEPG)
Involved in managing the managing the Process
Management Process activities

25. Re-Cap
• For efficiency and cost effectiveness
– Software should be developed using a phased process
– Testing and Maintenance being two very costly phases, so to
benefit for maximum saving these two phases should be
focused
– Errors introduced in early stages, if not identified and
eradicated early then these cost a lot
Hence
Integrated Approach to Software Development should
be adopted, according to this at each stage testing
should be carried out [Jalote05] calls it ETVX Approach,
whereas [Schach96] specifies What needs to be tested
at each stage!!!

26. Desired Process Properties
• Provide high Quality and Productivity (Q&P)
– Support testability as testing is the most expensive
task; testing can consume 30 to 50% of total
development effort
– Support maintainability as maintenance can be
more expensive than development; over the life of
the product, up to 80% of total cost
– Remove defects early, as cost of removing defects
increases with latency

27. ETVX Specification
• ETVX approach is to specify at each phase or
step
– Entry criteria: what conditions must be satisfied
for initiating this phase
– Task: what is to be done in this phase
– Verification: the checks done on the outputs of
this phase
– eXit criteria: when can this phase be considered
done successfully
• A phase also produces information for
management

28. ETVX approach

29. Testing at Different Phases of
Software Development
• Main Testing Types
Testing could be of Two Types; Non-executable
and Executable
• Phases
Requirements Phase , Specification Phase, Planning Phase,
Design Phase
Implementation Phase, Integration Phase, Maintenance Phase
and Retirement Phase
Ref: Stephen R. Schach (2007); Software Engineering, 7th Edition, Tata McGraw-
Hill Publishing Company Limited, New Delhi

31. Requirements Phase
• Input
– Clients (and Users) tell what
they want
– Client’s description of project
– Meetings to understand
‘what they want’
– Client believes the Sw will
help him
– Find out the ‘constraints’
• Problems
– Client don’t know what
he wants
– Description is vague,
ambiguous,
contradictory or simply
impossible to achieve
– Clarify the time and
budget constraints

32. Requirements Phase
• Do
– Clarify the constraints, refine
‘What Client wants’ and ‘what
is needed’
– Meetings with development
team to address constraints
– Analyze the possible problem
areas
– Rapid Prototyping helps
– Requirements Document
finalized
• Testing
– SQA group should
ensure the Clients needs
are satisfied
– Confirm the final version
of Rapid Prototype is
acceptable to
Client/User and meets
their needs
– Safeguard ‘moving
target problem’

33. Specification Phase
• Input
– Requirements Doc
• Goal
– Specification Doc should
explicitly describe
• Functionality
• Constraints and
• Input/Output of the
product
• Problems
– Specification Doc is the basis
for the Contract, so must be
• Precise
• Unambiguous
• Clear
• No Contradictory or multi-
meaning statements
– In case of lawsuits it works as
an evidence

34. Specification Phase
• Do
– Consult Client whenever
needed to clarify the
requirements
– Write clearly avoiding
mentioned problems
– Validate errors in the input
data and ensure all cases are
covered
– Specification (Software
Requirements Specification –
SRS) Document finalized
• Testing
– SQA group should ensure
Specification Doc is
• Complete
• Unambiguous
• Non-contradictory
– Ascertain that the
promised functionality can
be delivered and it’s true
reflection of clients
requirements
• Review of joint team from
Client and Developer and
SQA group helps

35. SE-381
Software Engineering
BEIT-V
Lecture no. 7
Software Engineering Processes
3 of 3

36. Planning Phase
• Input
– Specification Doc
– Resources Available
– Organizational structure
– SDLC,CASE Tool, Detailed
Schedule for Budget
• Purpose
– Exact Time and Budget
Estimates
– Erroneous estimates may
lead to loss of contract or
financial penalty to Company.
• How to Do:
– All Specification
Document functions
are addressed and
estimated
– Task Assignments to
personnel
– Time estimates, Costs
incurred, detailed
schedules

37. Planning Phase
• Outputs
– Major Components of the
product,
• Milestones / Gantt Charts
• Time & Cost Budget
• Deliverables and their
timelines
– Software Project
Management Plan
• With who is doing what and
when information
• Testing
– Validate that Time and
Budget estimates are
correct
– A good way to do it,
obtain two alternate
plans from different
teams and note the
differences and
reconcile
– Formal Review is
another good
technique to test

38. Design Phase
The Most Important Phase
– Specification describes
‘What’ and Design tells
‘How’ the functionality can
be provided
– Design is a CREATIVE
activity
• Input
– Specification / SRS
Document
• How Done
– Determine the Internal
Structure of the product
– Decide for Algorithms and
Data Structures
– Determine I/O of the product
from SRS Doc
– Analyze Internal Data Flows
– Decompose Product into
‘Modules’
– Specify ‘functionality’ and
‘Interface’ to each module
– Record all design decisions
explicitly

39. Design Phase
• Design has 2 or 3 Parts
– Architectural Design
• Break Down of System into
Subsystems, Components and
modules of the product
• Structure Charts to represent
– Detailed Design
• Functionality and Interface of
all modules is developed
• Algorithms and Data
Structures of each module
identified
• Testing
– Re-trace – That every
function in Spec (SRS)
Doc have a module
supporting it and the vice
versa
– Test Cases written for all
modules be validated
with the Spec Doc i.e.
they conform to specs.

40. Implementation Phase
• Input
– Detailed Design for all the
modules
– Test Cases for the
respective modules
• How to Do
– Consider language and
platform dependencies
here, if any
– Code the modules with
sufficient comments
– Provide extra
documentation like
decision trees/tables, flow-
charts etc for maintenance
• Testing
– Test all the modules
using already prepared
test cases
• Output
– Code for Modules

41. Integration Phase
• Input
– Specifications of
Modules, Subsystems,
and System; Test Cases,
Structure Chart(s),
Modules’ Code
• How to Do
– Top-Down, Bottom-up or
incremental integration
• Testing
– Module, sub-systems and system
all perform according to the
specifications,
– Product testing
– Acceptance testing at Clients
site,
– Shrink-wrapped products –
alpha, beta testing
Test Cases Results with
Used/produced I/O, Source
Code, Acceptance Test proof

42. Maintenance Phase
• Maintenance starts after
delivery!!
• But
– Maintenance must be kept in
focus while Designing/Coding
…
– Should be integral part of
Software Development
process
• Testing
– Ensure proper documentation
– Careful change insertion and
Regression Testing i.e. after
making a change run all test
cases to ensure that no
further error has been
introduced.
Up-to-Date ‘Change
Document’, Regression Test
results

43. Retirement Phase
• When to Retire?
– Further Maintenance is not
Cost-effective
– Write-Only code
– The documentation has
rendered Obsolete
– Hardware Advancement
• Like a ‘record in sports’ new
record improves the old one
• True retirement is Rare in
Sw domain, it is always a
replacement, with
improved version
• Testing / Utility
– A complete review of
functionality and
operations the Sw
performed
– Incorporation of keynote
functions into the
replacement

44. References / Reading Assignment
[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach
to Software Engineering; 2nd /3rd Edition, Narosa Publishing
House, New Delhi – Ch 2 Software Processes pp:21-66
[Sch96] Stephen R Schach (1996);Classical and OO Software
Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-
Cycle Models
[Bel05] Douglas Bell (2005); Software Engineering for Students,
4th Edition, Pearson Education, New Delhi – Ch 21 The
Waterfall Model and Ch 23 Prototyping
The relevant parts of the above chapters to be read at home.

45. SE-381
Software Engineering
BEIT-V
Lecture no. 8
Software Process Models
1 of 3

46. Software Process Models
– Software Development
• Needs to be performed in a series of well-defined steps, so
that the process could be managed to develop fault-free
software product in the given budgetary and time
constraints
– Software Process Model
• is a way or the order in which these steps/stages or phases of
software development are executed,
• is a framework for portraying the specific sequence of these
phases
There are a number of Software Process Models

47. Some Software Process Models
– Build-n-Fix Model
– Classical Waterfall Model and its variants
– Prototyping Models
• Rapid or Throwaway Prototyping Model
• Evolutionary Prototyping Model
– Incremental Model
– Risk Based Models
• Spiral Model
– eXtreme Programming
– Synchronise and Stabilize Model
– Object Oriented Life Cycle Models
• Fountain Model
• Agile Model
• Unified Process Model

48. Build and Fix Model

49. • Pros
– Simplest
– Used by students for
classroom assignments
– Build-use-modify-use-modify
cycle continues until client is
satisfied
• Cons
– No specification or design
stages
– Works for very small (<300-
400 LOCs) codes
– Unreliable product
– Very high cost of the
produced product
– Maintenance is in fact not
possible without specification
and design documents
Build and Fix Model
A Software Development Life Cycle Model must be
chosen before the work on the product is initiated

50. Waterfall Model
• Pros
– Oldest, Since 1970s
– Found by Winston Royce in
1970
– Most Widely used (in
Aerospace Industry, even
today)
– Divides complex task into
smaller, more manageable
tasks and executes them in
Linear order
– Each task/stage is well
defined has deliverables
and well specified inputs
and outputs
– Iterations accommodated
in Modified version
– ‘Something is better than
nothing’ - at least a systematic
method then a haphazard
approach
– Project Management Possible

51. Waterfall Model
Many organizations still cling to the waterfall model because, even
with its shortfalls, it provides the most fully elaborated
management guidelines on how to proceed in a given software
situation.
Barry Boehm, April 1998
Although 20 years back problems in WF model approach were
highlighted but still 40% of companies using this approach –
IEEE Software 2003 survey
[Som04]

52. Classical Waterfall Model

53. Stage-wise Inputs / Outputs

54. Waterfall Model with Inter-stage
Feedback

55. Jal97 – Waterfall Model

56. Waterfall Model

57. Waterfall Model .
• Problems
– Real-life systems don’t
work in a simple sequential
mode (so Iterations
implemented)
– Problems CROP UP in the
later stages effecting earlier
stages
– Uncertainty in user
specification CANNOT be
specified at the outset
– Design errors are numerous
and persistent
– Software delayed, user has
to wait for long time
– Specifications frozen at
early stages, so the product
may NOT conform to what
user wanted

58. Waterfall Model ..
Thus limitations of WF model are:
– Requirements of a system are frozen before design begins; could
work for automation of a legacy system but not for new systems
– Freezing of Requirements may include the choice of HW, so on
completion the new system may be dependent on a obsolete
technology, as technology is ever improving
– WF Model stipulates that the requirements are completely
specified before the SD can proceed. In reality, for many systems
including COTs a part of the system is fully developed and sold to
customers, and then functionality is added to the system and it
is redeveloped
– Early freezing of specifications and absence of not many
iterations, can not guarantee Users Satisfaction
– The ‘Document Driven’ nature of Waterfall Model has its own
Pros & Cons

59. Prototyping Model
• Can be used to clarify Requirements, to design Use
Interface, demonstrate feasibility, verify the new
technology will work, or to provide a training
system
• Cannot be used for embedded software, real-time
control software or scientific or Engineering
numerical computational software
• Tools for developing good quick prototypes are
scarce, some HLLs are providing routine libraries,
whereas systems like Smalltalk could not survive or
capture markete

60. Prototyping Model
• Ensures that customer gets what s/he wanted
• Customer is provided a working version of software i.e.
prototype at a very early stage
• Customer plays with it and suggests needed
amendments and developer incorporates them into the
prototype
• User/customer needs/requirements are thus refined
and defined, and the software could be developed
using these requirements

61. Prototyping Model
Prototyping Model could be of two types:
• Rapid or Throwaway prototype Model
• Evolutionary Prototype Model
Rapid or Throwaway Prototyping Model
Uses rapid techniques to construct prototypes that are
thrown away once users’ requirements have been
established
Evolutionary Prototyping Model
Evolves the initial prototype into the final software as the
requirements are clarified

62. Prototyping Model
Pressman (1992) –

63. Prototyping Model
• Problems & Real-life
– Prototyping is a historical
technique of Engineering
Discipline, Chemical Engg,
Aerodynamics
– User not aware what he
wants
– Developer not sure how
good his Algorithms or
Code would perform
– Client ignorant of expected
output. Changes to come
by use of the Sw Product
• Different Types
– Paper Prototype
– PC Based Screen layouts
– Software developed to
initiate User Interaction
with the system
• How Done
– Client & Developer meet
and sort out Requirements
– A quick design
– Implementation
– User Feedback
accommodation

64. Prototyping Model .
• Cons
• The developed Prototype should not be taken as Product
• According to Brooks 1975, it should be a ‘Throwaway Version’ of
the product but is it possible?
• Customer Pressure to take Prototype as Product, and Developer
Shortcuts to get the Prototype working
• Should be used as a tool for Requirement Phase
• Client be explained at the outset that after getting
Prototype accepted the ‘Product’ will be re-
engineered.

65. Rapid Prototyping Model

66. Jal97 – Prototyping Model

67. [Bel05] Throwaway Prototype Model

68. Rapid Prototyping Model
• Pros
– A new model, using
the developed
Prototype as a Front-
end to your SD
process, to gather
– User
Requirements,
– Clients’
experience with
the Sw (Prototype)
– Insight to the
Algorithms used
and how efficient
these are
– A tool/guide for all
who are involved in
SD of the product to
improve their area
• Prototype used as
– A tool for Requirements
phase
• Rest Follow the
remaining phases
linearly
• Iteration introduced by
– Maintenance phase, for
– Corrective
– Adaptive and
– Perfective changes

69. [Bel05] Evolutionary Prototype Model

70. Evolutionary Versus Rapid Prototypes
– Rapid Prototypes start from incomplete specifications,
go through a ‘quick’ design and development and these
are improved on users’ or clients’ response. The final
output is the clarified Requirements. These are used to
develop the system
– Evolutionary Prototypes start from initial
specifications, designed thoroughly and incorporate
the users’/clients’ response. The evolved system turns
out to be the final system

71. Prototyping Model – An Example
Problem Statement
Write a software program that can check the
general knowledge of a user, specifically his/her
knowledge about geography and history of
Pakistan and its neighbors.
This is to be used by general public, so its
implementation in national language will be
preferred.

72. References
[Bel05] Douglas Bell (2005); Software Engineering for Students,
4th Edition, Pearson Education, New Delhi – Ch 21 The
Waterfall Model and Ch 23 Prototyping
[Jal97] Pankaj Jalote (1997); An Integrated Approach to
Software Engineering; 2nd Edition, Narosa Publishing House,
New Delhi – Ch 2 Software Processes
[Sch96] Stephen R Schach (1996);Classical and OO Software
Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-
Cycle Models
The relevant parts of the above chapters to be read at home.