Software Engineering

An Introduction

Fakhar Lodhi

1
 Engineering
z The science concerned with putting
scientific knowledge to practical use.
Webster’s Dictionary

z Physics versus Electrical Engineering

2
 Software Engineering
z The science concerned with putting
computer science knowledge to practical
use.

z Computer Science versus Software

Engineering

3
 Software Engineering - IEEE
1. The application of a systematic,
disciplined, quantifiable approach to the
development, operation, and maintenance
of software; that is, the application of
engineering to software.
2. The study of approaches as in 1.
One of the largest efforts in
Software Engineering has been
the design of
Ada Programming Language!
4
 Breakdown of Effort Cost - Software Cost
Estimation by Capers Jones

No. Activity Effort 13 Configuration Mgt. 0.41%

1 Requirements 3.84% 14 Integration 2.71%
2 Prototyping 4.50% 15 User Documentation 9.67%
3 Architecture 2.25% 16 Unit Testing 4.50%
4 Project Plans 1.33% 17 Function Testing 4.50%
5 Initial Design 3.84% 18 Integration Testing 3.84%
6 Detailed Design 4.50% 19 System Testing 3.38%
7 Design Reviews 3.02% 20 Beta Testing 3.02%
8 Coding 13.50% 21 Acceptance Testing 1.94%
9 Reuse acquisition 1.13% 22 Independent Testing 3.38%
10 Package Purchase 1.69% 23 Quality Assurance 4.50%
11 Code Inspection 4.50% 24 Installation and Training 1.94%
12 Independent V&V 5.42% 25 Project Management 6.75%

5
 Effort Breakdown of ~10000
Projects - Capers Jones

z Project Management 8.08%

z Requirements 14.43%
z Design 11.36%
z Coding 13.50%
z SQA 30.64%
z SCM 13.02%
z Integration 6.54%
z Misc. ~3%

6
 Software Development
project planning and
management
Management configuration
management
quality assurance
installation and training
Construction etc.

Requirements
Design
Coding
Testing
Maintenance
7 etc.
 Basic Activities of Software Engineering
• defining the software development process to be
used
• managing the development project
• describing the intended software product
• designing the product
• implementing the product
• testing the parts of the product
• integrating the parts and testing them as a whole
• maintaining the product

8
 The Four P’s of Software Engineering
z Project – the task at hand
z People – by whom it is done
z Process – the manner it is done
z Product – the artifacts produced

9
 Well-Engineered Software
• Provides the required functionality
• Maintainable
• Reliable
• Efficient
• User-friendly
• Cost-effective

10
 Well-Engineered Software - contd.
• These requirements may be conflicting:
• Cost vs. Efficiency
• Cost vs. Reliability
• Efficiency vs. User-interface
• Law of diminishing returns.
• Challenge is to balance these requirements.

11
 Software Life-Cycle Models
z The way you organize your activities
z The steps through which the product
progresses
– Requirements phase
– Specification phase
– Design phase
– Implementation phase
– Integration phase
– Maintenance phase
– Retirement

12
 Software Processes
z Build-and-fix model
z Waterfall model
z Rapid prototyping model
z Incremental model
z Extreme programming
z Synchronize-and-stabilize model
z Spiral model
z Object-oriented life-cycle models
z Comparison of life-cycle models
13
 Build and Fix Model
z Problems
– No specifications
– No design
z Totally unsatisfactory
z Need life-cycle model
– “Game plan”
– Phases
– Milestones

14
 Waterfall Model (contd)
z Characterized by
– With or without feedback
loops
– Documentation-driven
z Advantages
– Documentation
– Maintenance easier
z Disadvantages
– Client feedback

15
 Rapid Prototyping Model

z Linear model
z “Rapid”
z Horizontal versus vertical prototyping

16
 Three Key Points
z Do not turn into product
z Rapid prototyping may replace
specification phase—never the design
phase
z Comparison:
– Waterfall model—try to get it right first time
– Rapid prototyping—frequent change, then
discard

17
 Waterfall and Rapid Prototyping Models
z Waterfall model
– Many successes
– Client needs
z Rapid prototyping model
– Cannot be used for robust
applications
z Solution
– Rapid prototyping for
requirements phase
– Waterfall for rest of life
cycle

18
 Incremental Model
z Divide project
into builds

19
 Incremental Model (contd)
z Waterfall, rapid prototyping models
– Operational quality complete product at end
z Incremental model
– Operational quality portion of product within weeks
z Less traumatic
z Smaller capital outlay, rapid return on
investment
z Need open architecture—maintenance
implications
z Variations used in object-oriented life cycle
20
 Incremental Model (contd)
z Problems
– Build-and-fix danger
– Contradiction in terms

21
 Incremental Model (contd)
z More risky version—pieces may
not fit
– CABTAB and its dangers

22
 Code a bit, test a bit – CABTAB
z Haphazard undisciplined approach

23
 Extreme Programming
z Somewhat controversial new approach
z Stories (features client wants)
z Estimate duration and cost of each story
z Select stories for next build
z Each build is divided into tasks
z Test cases for task are drawn up first
z Pair programming
z Continuous integration of tasks

24
 Extreme Programming

25
 Unusual Features of XP
z Computers are put in center of large
room lined with cubicles
z Pair programming with shared computers
z Client representative is always present
z Cannot work overtime for 2 successive
weeks
z No specialization
z Refactoring

26
 Evaluating XP
z XP has had some successes
z Good when requirements are vague or
changing
z Too soon to evaluate XP

27
 Dilbert on eXtreme Programming

28
 Synchronize-and Stabilize Model
z Microsoft’s life-cycle model
z Requirements analysis—interview potential
customers
z Draw up specifications
z Divide project into 3 or 4 builds
z Each build is carried out by small teams
working in parallel

29
 Synchronize-and Stabilize Model (contd)
z At the end of the day—synchronize (test and
debug)
z At the end of the build—stabilize (freeze build)
z Components always work together
– Get early insights into operation of product

30
 Spiral Model
z Simplified form
– Waterfall model plus risk
analysis
z Precede each phase by
– Alternatives
– Risk analysis
z Follow each phase by
– Evaluation
– Planning of next phase

31
 Simplified Spiral Model
z If risks
cannot be
resolved,
project is
immediately
terminated

32
 Full Spiral Model
z Radial dimension: cumulative cost to date
z Angular dimension: progress through the
spiral

33
 Full Spiral Model (contd)

34
 Analysis of Spiral Model
z Strengths
– Easy to judge how much to test
– No distinction between development,
maintenance

z Weaknesses
– For large-scale software only
– For internal (in-house) software only

35
 Object-Oriented Life-Cycle Models
z Need for iteration within and between phases
– Fountain model
– Recursive/parallel life cycle
– Round-trip gestalt
– Unified software development process
z All incorporate some form of
– Iteration
– Parallelism
– Incremental development
z Danger
– CABTAB
36
 Conclusions
z Different life-cycle models
z Each with own strengths
z Each with own weaknesses
z Criteria for deciding on a model
include
– The organization
– Its management
– Skills of the employees
– The nature of the product
z Best suggestion
37 – “Mix-and-match” life-cycle model
 Quality Assurance?
z There is NO QA phase
z QA is an activity performed throughout software
production
z Verification
– Performed at the end of each phase
z Validation
– Performed before delivering the product to the client

38
 Documentation Phase?
z There is NO documentation phase
z Every phase must be fully documented before
starting the next phase
– Postponed documentation may never be completed
– The responsible individual may leave
– The product is constantly changing—we need the
documentation to do this
– The design (for example) will be modified during
development, but the original designers may not be
available to document it

39
 Phase Documents QA
Requirement z Rapid prototype, or z Rapid prototype
Definition z Requirements z Reviews
document
Functional z Specification document z Traceability
Specification (specifications) z FS Review
z Software Product z Check the SPMP
Management Plan
Design z Architectural Design z Traceability
z Detailed Design z Review
Coding z Source code z Traceability
z Test cases z Review
z Testing
Integration z Source code z Integration testing
z Test cases z Acceptance testing
Maintenance z Change record z Regression testing
40 z Regression test cases
 Traceability matrix
Requirement Use Case UID Class/ Test
ID ID function Case ID

41
 Questions?

42
 Thank you!

43