software engineering

1. PRINCIPLES OF SOFTWARE
ENGINEERING
Dr. Abdul Karim ABED
Software Process Models

2. OUTLINE
2
 Definition
 Software Life Cycle Activities
 Generic software process models
• Build and Fix
• Waterfall
• V- shaped
• Rapid Prototyping
• The Spiral
• The Unified Process
• Component-based software engineering
• Agile Process
 Extreme programming

3. Definition
 Software products go through several stages
as they mature from initial concept to finished
product
 The sequence of stages is called a process
model or life cycle
 A process is a sequence of steps performed
for a given purpose
3

4. Definition
Definition:
A software model also (Life-cycle model and
process model) is a description of the
sequence of activities carried out in an
Software Engineering project, and the relative
order of these activities.
4

5. Definition
 It provides a fixed generic framework that
can be tailored to a specific project
 A process model for software engineering is
chosen based on the nature of the project and
application, the methods and tools to be used,
and the controls and deliverables that are
required
5

6. Software Life Cycle Activities
The main activates in software project are:
 Requirements Specification
 System analyst works with software users to
clarify the detailed system requirements
 Questions include format of input data, desired
form of any output screens, and data validation
6

7. Software Life Cycle Activities
 Analysis
 Make sure you completely understand the
problem before starting the design or program a
solution
 Evaluate different approaches to the design
7

8. Software Life Cycle Activities
 Design
 Top-down approach: breaking a system into a set
of smaller subsystems
 Object-oriented approach: identification of a set of
objects and specification of their interactions
 UML diagrams are a design tool to illustrate the
interactions between
 Classes
 Classes and external entities
8

9. Software Life Cycle Activities
 Code generation (Implementation).
The design must be translated into a machine-
readable form.
 The code generation step performs this task. If
design is performed in a detailed manner,
 code generation can be accomplished
mechanistically.
9

10. Software Life Cycle Activities
 Testing.
Once code has been generated, program
testing begins. The testing process
 Focuses on the logical internals of the
software, ensuring that all statements have
been tested, and on the functional externals;
that is, conducting tests to uncover errors and
ensure that defined input will produce actual
results that agree with required results.
10

11. Software Life Cycle Activities
 Support (maintenance).
Software will undoubtedly undergo change after it is
delivered to the customer
(a possible exception is embedded software).
Change will occur because errors have been
encountered, because the software must be
adapted to accommodate changes in its external
environment (e.g., a change required because of
a new operating system or peripheral device), or
because the customer requires functional or
performance enhancements. Software
support/maintenance reapplies each of the
preceding phases to an existing program rather
than a new one.
11

12. Generic software process models
 Build and Fix
 Waterfall
 V- shaped
 Rapid Prototyping
 The Spiral
 The Unified Process
 Component-based software engineering
12

13. Build and Fix
 In this most simple model of software
development, the product is constructed with
minimal requirements, and generally no
specifications nor any attempt at design, and
testing is most often neglected. This is a
representation of what is happening in many
software development projects.
13

14. Build and Fix
14

15. Build and Fix
 This model starts with an informal general
product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.
15

16. Build and Fix
Advantages
• No administrative overhead
• Signs of progress (code) early.
• Low expertise, anyone can use it!
• Useful for small “proof of concept” projects.
16

17. Build and Fix
Disadvantages
1. Dangerous
No visibility/control
No resource planning
No deadlines
Mistakes hard to detect/correct
2. Impossible for large projects.
3. Often results in a product of overall low quality
4. Maintenance can be extremely difficult without
specification and design document.
17

18. Waterfall Model
 The waterfall model is the classic lifecycle model – it
is widely known, understood and commonly used.
 In some respect, waterfall is the ”common sense”
approach.
 Document-oriented
 The output of one phase constitutes the input to next
(Liner).
18

19. Waterfall Model
19

20. Waterfall Model
Advantage
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
20

21. Waterfall Model
Disadvantages
 All requirements must be known upfront
 Deliverables created for each phase are
considered frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of
software development – iterations of phases
 Little opportunity for customer to preview the
system (until it may be too late)
21

22. Waterfall Model
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
22

23. V-Shaped Model
 A variant of the Waterfall that emphasizes
the verification and validation of the product.
 Testing of the product is planned in parallel
with a corresponding phase of development
23

24. V-Shaped Model
Project and
Requirement
s Planning
Product
Requirements
and
Specification
Analysis
Architecture or
High-Level
Design
Detailed
Design
Unit Testing
Integration
and Testing
System and
Acceptance
Testing
Coding
Production
Operation and
Maintenance
24

25. V-Shaped Model
 Project and requirements planning
Determines system requirements and allocation of
resources.
 Product requirements and specification
analysis
Analysis of software problem, concludes with
complete specification of the software.
Architecture or High-level design
 - Determines how the software functions are to
implement the design.
 Detailed Design
Defines algorithms for components that were
defined during the architecture phase.
25

26. V-Shaped Model
 Coding
Transforms the algorithms defined during the
design phase into software.
 Unit Testing
Checks each code module for errors.
 Integration and Testing
Integrate and test individual code modules.
26

27. V-Shaped Model
 System and acceptance testing
Test entire software system in its hardware
environment
 Productions, operation and maintenance
Puts software into production and provides
for enhancements and corrections.
27

28. V-Shaped Model
Advantages
 Emphasize planning for verification and
validation of the product in early stages of
product development
 Each deliverable must be testable
 Project management can track progress by
milestones
 Easy to use
28

29. V-Shaped Model
Disadvantages
 Does not easily handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
 Does not contain risk analysis activities
29

30. V-Shaped Model
When to use the V-Shaped Model
 Excellent choice for systems requiring high
reliability – hospital patient control applications
 All requirements are known up-front
30

31. Evolutionary Process Models
 Evolutionary models are iterative
 They are characterized in a manner that
enables software engineers to develop
increasingly more complete versions of the
software
 Prototyping
 Incremental
 Spiral
31

32. Prototyping Model
Some strong limitations of waterfall model is:
 It assumes that the requirements of a system
can be frozen before the design begins. This is
possible for systems designed to automate an
existing manual system. But for new systems,
determining the requirements is difficult as the
user does not even know the requirements.
Hence, having unchanging requirements is
unrealistic for such projects.
32

33. Prototyping Model
 The basic idea is that instead of freezing the
requirements before any design or coding can
proceed, a prototype is built to help understand
the requirements. This prototype is developed
based on the currently known requirements.
Development of the prototype obviously
undergoes design, coding, and testing, but each
of these phases is not done very formally or
thoroughly. By using this prototype, the client can
get an actual feel of the system, which can
enable the client to better understand the
requirements of the desired system. This results
in more stable requirements that change less
frequently.
33

34. Prototyping Model
34

35. Prototyping Model
Requirements
gathering
‘Quick’
design
build
prototype
evaluate &
refine
Engineer
product
35

36. Prototyping Model
When customer or developer is not sure
 Of requirements (inputs, outputs)
 Of algorithms, efficiency, human-machine
interaction
A prototype built from currently known user
needs
36

37. Prototyping Model
Advantages
1. It could serve as the first system.
37

38. Prototyping Model
2) The customer doesn’t need to wait long as in
the Linear Model.
3) Feedback from customers are received
periodically and the changes don’t come as a
last minute surprise
38

39. Prototyping Model
Disadvantages
 Customer could believe the prototype as the working
version.
 Developer also could make the implementation
compromises where he could make the quick fixes to
the prototype and make is as a working version.
 Often clients expect that a few minor changes to the
prototype will more than suffice their needs. They fail to
realize that no consideration was given to the overall
quality of the software in the rush to develop the
prototype
 Effort in building a prototype may be wasted
 Difficult to plan and manage
39

40. Prototyping Model
When to use prototyping model
 Requirements are unstable or have to be
clarified
 As the requirements clarification stage of
a waterfall model
 Develop user interfaces
 Short-lived demonstrations
 New, original development
40

41. Spiral Model
 Process is represented as a spiral rather than
as a sequence of activities 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.
41

42. Spiral Model
Simplified Spiral Model
 If risks cannot be
resolved, project is
immediately
terminated
 Potential risks
 Timing constraints
 Lack of personnel
 Competence of team
 Dependency on
hardware delivery
42

43. Spiral Model
 Simplified Waterfall
model plus risk analysis
 Uses rapid prototypes
 Precede each phase by
 Alternatives
 Risk analysis
 Follow each phase by
 Evaluation
 Planning of next phase
43

44. Spiral model
Full Spiral Model
44

45. Spiral model
Phase 1 : Determine objectives, alternatives and
constraints
 Objectives: functionality, performance,
hardware/software interface, critical success
factors, etc.
 Alternatives: build, reuse, buy, sub-contract,
etc.
 Constraints: cost, schedule, interface, etc.
45

46. Spiral model
Phase 2: Evaluate alternatives, identify and
resolve risks
 Study alternatives relative to objectives and
constraints
 Identify risks (lack of experience, new
technology, tight schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost
by continuing system development
46

47. Spiral model
Phase 3: develop next product
 Typical activates:
 Create a design
 Review design
 Develop code
 Inspect code
 Test product
47

48. Spiral model
Phase 4 Plan next phase
 Typical activities
 Develop project plan
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
48

49. Spiral Model
Start Axis
Customer
Communication
Planning
Risk
Analysis
Development
Integration
Customer
Evaluation
Six phases spiral model
49

50. Spiral Model
Advantages:
 Provides early indication of risks, without much
cost
 Users see the system early
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
50

51. Spiral Model
Disadvantages
 Time spent for evaluating risks too large for small or low-
risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Spiral may continue indefinitely
 Developers must be reassigned during non-development
phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
51

52. Spiral Model
When to use the Spiral Model
 If the risk evaluation and cost evaluation is
important for the project, then spiral model is the
best choice for it.
 Spiral model is suitable for medium risk projects
and high risk projects.
 Spiral model is also preferred when the project
has complex requirement or a new product line is
introduced.
 If the User is not sure of the project needs or
significant research has to be done on the project,
then spiral model is used.
52

53. Incremental Model
 Construct a partial implementation of a total system
 Then slowly add increased functionality
 The incremental model prioritizes requirements of the
system and then implements them in groups.
 Each subsequent release of the system adds function
to the previous release, until all designed functionality
has been implemented.
 Differs from Prototyping in that requirements are
fully known at the start
53

54. Incremental Model
Software
concept
Requirements
Analysis
Architectural
Design
High Priority: Detailed design, code, debug,
test
Medium-High Priority: Detailed design,
code, debug, test
Medium Priority: Detailed design, code,
debug, test
Medium-Low Priority: Detailed design,
code, debug, test
Low Priority: Detailed design, code, debug,
test
Release
run out of time/money
n
Stages prioritised
lower priority
last. Thus if
deadline or budget
is reached before
product finished
lowest priority
stages
can be omitted.
54

55. Incremental Model
Software
concept
Requirements
Analysis
Architectural
Design
Stage 1: Detailed design, code, debug, test
and delivery
Stage 2: Detailed design, code, debug, test
and delivery
Stage n: Detailed design, code, debug, test
and delivery
55

56. Incremental Model
Advantages
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
56

57. Incremental Model
Disadvantages
 Requires good planning and design
 Requires early definition of a complete and fully
functional system to allow for the definition of
increments
 Each phase of an iteration is rigid and do not
overlap each other.
 Total cost of the complete system is not lower
57

58. Incremental Model
When to use the Incremental Model
 Risk, funding, schedule, program complexity
need for early realization of benefits.
 Most of the requirements are known up-front but
are expected to evolve over time
 A need to get basic functionality to the market
early
 On projects which have lengthy development
schedules
 On a project with new technology
58

59. Component-based Model
 Component-based is an approach to software
development that relies on software reuse.
 Based on systematic reuse where systems are
integrated from existing components systems.
 This approach is becoming increasingly used
as component standards have emerged.
59

60. Component-based Model
 Component-based model incorporates many
of the iterative characteristics of the spiral
model.
 The main difference is that in this model the
emphasis is on composing solutions from
prepackaged software components or classes
60

61. Component-based Model
The component base process
61

62. Component-based Model
 Advantages:
 Management of Complexity
 Reduce Development Time
 Increased Productivity
 Improved Quality
62

63. Component-based Model
 Disadvantages:
 Development of Components
 Lack of Components
 Component Maintenance Costs
 Unsatisfied Requirements
63

64. Component-based Model
When to use Component-Based Model:
 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
64

65. An Agile Process
Agile approaches are based on some common
principles, some of which are
 Working software is the key measure of progress
in a project.
 For progress in a project, therefore, software
should be developed and delivered rapidly in small
increments.
 Even late changes in the requirements should be
entertained (small-increment model of
development helps in accommodating them).
65

66. An Agile Process
 Face-to-face communication is preferred over
documentation.
 Continuous feedback and involvement of
customer is necessary for developing good-
quality software.
 Simple design which evolves and improves
with time is a better approach than doing an
elaborate design up front for handling all
possible scenarios.
 The delivery dates are decided by empowered
teams of talented individuals
(and are not dictated).
66

67. An Agile Process
67

68. An Agile Process
Some Agile Methods
 Adaptive Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method
(DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
68

69. Extreme Programming - XP
 For small-to-medium-sized teams developing
software with vague or rapidly changing
requirements
 Coding is the key activity throughout a
software project
 Communication among teammates is done
with code
 Life cycle and behavior of complex objects
defined in test cases – again in code
69

70. Extreme Programming (XP)
 An extreme programming project starts with
user stories which are short (a few sentences)
descriptions of what scenarios the customers
and users would like the system to support.
 A user story is a short description of what the
business or customer wants the software to do,
written by the customer in the customer
terminology without techno-syntax
70

71. The XP lifecycle
71

72. Extreme Programming (XP)
Example of user story
"Tell me the story and write down the name of the story and a
paragraph or two."
License Enforcement
When run for the first time, JeraWorks puts up a license
dialog, and will not proceed until the user enters either:
•a valid non-time-limited (paid) license certificate or
•a valid time-limited (demo) license that has not yet
expired.
A valid license is stored so the user doesn't have to re-
enter it on subsequent runs.
License info is displayed on the splash screen.
When a demo license expires, the license dialog re-
appears the next time JeraWorks is run.
72

73. 73
Extreme Programming (XP)
Twelve XP Practices
 The Planning Game
 Small Releases
 Metaphor
 Simple Design
 Test-driven development
 Refactoring
 Pair Programming
 Collective Ownership
 Continuous Integration
 40-Hours a Week
 On-Site Customer
 Coding Standards

74. Extreme Programming (XP)
The planning game
 Quickly determine the scope of the next release, combining
business priorities and technical estimates.
 Business decisions (customer)
 Scope: which “stories” should be developed
 Priority of stories (features)
 Release dates
 Technical decisions (developers)
 Time estimates for features/stories
 Elaborate consequences of business decisions
 Team organization and process
 Scheduling
74

75. Extreme Programming (XP)
Small Release
 Frequent and small releases are encouraged, and
for a release, iterations are employed.
 Start with the smallest useful feature set
 Release early and often, adding a few features each time
75

76. Extreme Programming (XP)
Metaphor
 Programmers have a simple shared story that
explains the system
 Use metaphors to describe how the system should
work.
 The shape of the system is defined by a metaphor
or set of metaphors shared between the customer
and programmers.
 A set of simple metaphors defines the internal and
external structure of the system.
 it helps everyone understand the basic elements
76

77. Extreme Programming (XP)
XP Metaphor Example-Payroll system is like
an assembly line:
 A large XP project was a payroll system for
Chrysler (Car Company).
 The metaphor for this project was that the
payroll system was like an assembly line
where hour parts were converted to dollar
parts, all parts were assembled and a
paycheck was produced .
77

78. Extreme Programming (XP)
Simple design
 Do the simplest thing that could possibly
work
 Passes all the tests
 No duplicate code
 Fewest possible classes and methods
78

79. 79
Extreme Programming (XP)
Test-driven development
 Test first: before adding a feature, write a test for it!
 When the complete test suite passes 100%, the
feature is accepted
 Tests come in two basic flavors…
 Unit Tests automate testing of functionality as
developers write it
 Each unit test typically tests only a single class,
or a small cluster of classes !
 Acceptance Tests (or Functional Tests) are
specified by the customer

80. XP Metaphor Example: Test-First Programming is like a Math
Book
 Many math books have the answers to odd-numbered
problems in the back of the book. They do this because,
you don't solve math book problems to get the answer.
Rather, you solve them to learn the techniques for solving
similar problems.
 Test-first is like this: first you have the right answer -the
test. Your challenge is to write the code that provides
the answer. Usually, if your code is wrong, your test will
detect that.
 The fun part is, you act as both textbook author and
student. The author chooses a problem at just the right of
level of difficulty, just as you must do for your test.
 So, test-first is like a math book.
Extreme Programming (XP)
80

81. Extreme Programming (XP)
Refactoring
 The restructuring of software without
changing the behavior.
 Restructure the system continuously to improve
code and eliminate duplication
 Continuously improve quality of the code
81

82. Extreme Programming (XP)
Refectory Example
82

83. 83
Extreme Programming (XP)
Pair programming
 Two programmers work
together at one machine
 Driver enters code, while
navigator critiques it
 Periodically switch roles
Research results:
Pair programming increases productivity
Higher quality code (15% fewer defects) in about half the time (58%)

84. Extreme Programming (XP)
Collective code ownership
 No single person "owns" a module
 Any developer can work on any part of
the code base at any time
84

85. Extreme Programming (XP)
Continuous integration
 All changes are integrated into the
code base at least daily
 Tests have to run 100% both before
and after integration
85

86. Extreme Programming (XP)
Work no more than 40 hours per week as a
rule.
• Never work overtime two weeks in a row.
•Work only as many hours as you can be
productive and only as many hours as you
can sustain.
86

87. Extreme Programming (XP)
On-site customer
 A customer is accessible to the
programming team at all times
87

88. Extreme Programming (XP)
Coding Standards
• Everyone codes to the same standards
Coding standards keep the code consistent
and easy for the entire team to read and
refactor.
88

89. Extreme Programming (XP)
 Why Extreme ?
 If code reviews are good,
we’ll review code all the time (pair programming).
 If testing is good,
everybody will test all the time (unit testing),
even the customers (functional testing)
 If design is good,
we’ll make it part of everybody’s daily business
(refactoring)
 If simplicity is good,
we’ll always leave the system with the simplest design that
supports current functionality
(the simplest thing that could possibly work).

90. Extreme Programming (XP)
 If architecture is important,
everybody will work defining and refining the architecture all
the time (metaphor)
 If integration testing is important,
we’ll integrate and test several times a day (continuous
integration).
 If short iterations are good,
we’ll make the iterations really, really short –seconds and
minutes and hours, not weeks and months and years (the
Planning Game).

91. Extreme Programming (XP)
ADVANTAGES Of XP
 Customer focus increase the chance that the software
produced will actually meet the needs of the users
 The focus on small, incremental release decreases the
risk on your project:
 by showing that your approach works and
 by putting functionality in the hands of your users, enabling
them to provide timely feedback regarding your work.
 Continuous testing and integration helps to increase
the quality of your work
 XP is attractive to programmers who normally are
unwilling to adopt a software process, enabling your
organization to manage its software efforts better.
91

92. Extreme Programming (XP)
DISADVANTAGES of XP
 XP is geared toward a single project, developed and maintained by
a single team.
 XP is particularly vulnerable to "bad apple" developers who:
 don't work well with others
 who think they know it all, and/or
 who are not willing to share their "superior” code
 XP will not work in an environment where a customer or manager
insists on a complete specification or design before they begin
programming.
 XP will not work in an environment where programmers are
separated geographically.
 XP has not been proven to work with systems that have scalability
issues (new applications must integrate into existing systems).
92

93. Extreme Programming (XP)
When to use XP
 Extreme Programming (XP) was created in
response to problem domains whose
requirements change
 XP was also set up to address the problems of
project risk
 XP is set up for small groups of programmers.
93

94. Software Engineering Models
94

95. 95