SE 3140

SYSTEM DESIGN AND

MODELING

Prepared by: Dams Gabriel Fall 2021

ICT University
 CHAPTER 2:
Software Engineering
Overview

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 2

 Topics Overview
• What is a Software System?
• What is a Engineering?
• What is Software Engineering?
• Software Processes
– Framework Activities
– Umbrella Activities
• Process Flow
• Adapting a process flow
• Prescriptive Vs Agile Process Model

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 3

 What is a Software System?
• More than just program and code
– Set of Computer Instructions
– It can be a set of data structures in addition to the
language structures.

• Documentation
• Commonly, models are becoming part of
software.
• Anything that directs the underlying execution
of software on our computer and describes
that software is considered all part of what we
control in software
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 4
 What is a Software System?
• A Typical Program
– Typically 50-500 lines of code
– Developed by one person

• Software System (composed of many

programs)
– Much larger, typically consisting of many
programs working together (millions LOC)

– Needs a team of software engineers instead

of single programmer

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 5

 What is a Software System?
– Need project management and organizational
structure

– Need a software life cycle plan (what work

are we going to do, how are we going to do it,
when are we going to do it? What are our
milestones? Etc..)
• Phased approach to software development

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 6

 What is a Software System?
• Software is developed or engineered
– Not manufactured in the classical sense that the
hardware is manufactured.

– It is not made up of physical pieces.

– Software doesn’t “wear out”

– Rather the more patches you tend to apply, the

slower it gets, the buggier it tends to get also.

• Software is typically not mass produced

– Lots of custom-built software
• At least at the feature level
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 7
 Wear Vs Deterioration?
– Failure rate Versus Time for large scale
system

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 8

 What is Engineering?
• The application of scientific principles
and methods to the construction of
useful structures and machines

• Examples
– Mechanical engineering (design parts and tools)
– Civil engineering – design structures, roads and
bridges
– Chemical engineering
– Electrical engineering
– Nuclear engineering
– Aeronautical engineering
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 9
 What is Software Engineering?
• Engineering
– Applied Science

• Electrical engineering
– Applied Physics

• Software Engineering
– Applied Computer Science

• Computer science provides you with

those low level tools
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 10
 What is Software Engineering?
• Teaches you the science of computing –
– how the underlying computer works
– how data structures works
– How algorithms work
– Exposes you to various programming language

• Applying those computer science

principles to build large complex
software systems is where software
engineering comes to play.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 11

 What is Software Engineering?
• The term is over 40 years old
– NATO Conference on “Software Crisis”
– Garmisch, Germany, October 7-11, 1968

• Software Crisis
– Software development projects were
delivered late
– Software was full of errors
– Software did not satisfy requirements
– Software was difficult to maintain

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 12

 What is Software Engineering?
• IEEE (Institute of Electrical and
Electronics Engineers) definition
– The application of a systematic disciplined,
quantifiable approach to the development,
operation and maintenance of software, that
is, the application of engineering to software
• OR
– The establishment and use of sound
engineering principles in order to obtain
economically developed software that is
reliable and works efficiently on real
machines.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 13
 Why Are There Difficulties?
• Computer Science has given software
engineering the fundamentals she needs
as a discipline.

• Software engineering has been tackled

for over 40 years

• Why are there still problems in SE

domain that seem to overshadow the
problems compared to that exist other
engineering disciplines?
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 14
 Why Are There Difficulties?
• Software Engineering is a unique branch
of engineering compared to other
hardware engineering
– You can’t see software in action but you can
see the result (intangible)
– Software is easy to change
– Software construction is human-intensive
– Software is having no weight or impact to size
with the exception of just processor, power
and memory
– Software problems are very complex (root of
the problem)
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 15
 Why Are There Difficulties?
– You can build things in software that you
cannot dream of doing it in hardware.
– Software directly depends upon the hardware

• How do we deal with the complexity of

software and tackle the problem of
engineering large scale software?

• We need organized processes on how to

go about the development of the
software
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 16
 Software Processes
• Also known as Software Life Cycles
– Phased approach to software development
– Provide guidance on what must be created
– And (importantly) guidance on how to create and
evaluate artifacts

• Provides a framework for planning and

executing your software projects.

• Consist of (can be seen in terms) of two set of

activities
– Framework activities
– Umbrella activities
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 17
 Framework Activities
• Specific phases of the software
development life cycle can be described in
terms of:
– Communication
– Planning
– Modeling
• Analysis of requirements
• Design
– Construction
• Code generation
• Testing
– Deployment

• This framework is in its generic form

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 18
 Framework Activities
• Almost any software development
process/life cycle can be described in
terms of these framework activities.

• NOTE:
– All framework activities of a software
process uses the generic activities.
– No single off-the-shelf software exist that
you can apply and use.
– The generic framework is tailored to suit a
specific software project which is the ideal
situation.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 19
 Umbrella Activities
• Umbrella activities are performed throughout
the life cycle phases regardless of the
framework activity an organization are using.
– Software project management
– Formal technical reviews
– Software quality assurance
– Software configuration management
– Work product preparation and production
– Reusability management
– Measurement
– Risk management

• Umbrella activities focus on management and

quality assurance of the software project
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 20
 Process Flow
• Knowing the set of framework and
umbrella activities to use in a software
project is incomplete without
understanding how they should flow.

• Life cycle activities must be paired with

a flow model

a. Linear process flow

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 21
 Process Flow

b. Iterative process flow

c. Evolutionary process flow

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 22
 Process Flow

d. Parallel process flow

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 23
 Adapting a Process Model
• Each software development effort must
define the process to be used

• Often start with an “off the shelf” process

and then tailor it to meet specific project
needs

• Final, specific version to be applied is

defined in the Software Development Plan
(SDP)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 24

 Adapting a Process Model
• Factors for choosing and tailoring a process
model include:
1. the criticality and nature of the system to be developed

2. the overall flow of activities, actions, and tasks

3. the degree to which work products are identified and

required

4. the manner in which quality assurance activities are

applied

5. the manner in which project tracking and control

activities are applied
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 25
 Adapting a Process Model
• Factors for choosing and tailoring a process
model include:
6. the overall degree of detail and rigor with which
the process is described

7. the degree to which the customer and other

stakeholders are involved with the project

8. the level of autonomy given to the software

team

9. the degree to which team organization and roles

are prescribed
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 26
 Process Model Approaches
• Prescriptive
– Describes how to do
– Provides Direction
– Follow some laws or rules
– Use guidelines or framework to organize
structure in an order
– It defines how software should be developed.

• Agile
– Implies swift or flexible.
– Approach based on iterative development.
– It break tasks into smaller iterations, or parts
Do not directly involve long term planning.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 27
 Prescriptive vs. Agile Process Models
• Prescriptive process models advocate an
orderly approach to software
engineering.

• A lot of documentation with defined

checkpoint, milestones, review points etc.
– Waterfall
– Incremental
– Evolutionary/Spiral
– Unified Process"

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 28

 Prescriptive vs. Agile Process Models
• Agile process models advocate flexibility and
speed". Two popularly used are:
• XP (Extreme Programming)
• Scrum

• Both types of process models have their

place in software engineering (no one is
considered the best).

• It all depends on the nature of the product

you are producing and the culture of your
organization.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 29
 The Waterfall Model
• Each phase must be completed fully
before the next phase can begin.

• This type of model is basically used for

the project which is small and there are
no uncertain requirements.

• In this model the testing starts only

after the development is complete.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 30

 The Waterfall Model

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 31

 The Waterfall Model – Advantages
1. Simple and easy to understand and use.

2. Phases are processed and completed one

at a time, therefore phases do not
overlap.

3. Model works well for projects where

requirements are very well understood –
usually smaller projects

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 32

 The Waterfall Model – Disadvantages
1. Difficultly to go back and change something
that was not well-thought out in the previous
stage.

2. High amounts of risk and uncertainty.

3. Not a good model for complex and object-

oriented projects.

4. Poor model for long and ongoing projects.

5. Not suitable for the projects where

requirements are at a moderate to high risk of
changing.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 33
 The Incremental Model
• The whole requirement is divided into
various builds.

• It can be referred to a “multi-waterfall

cycle because multiple development cycles
take place here.

• Cycles are divided up into smaller, more

easily managed modules. Each module passes
through the requirements, design,
implementation and testing phases.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 34
 The Incremental Model
• A working version of software is produced
during the first module, so you have working
software early on during the software life
cycle.

• Each subsequent release of the module adds

function to the previous release. The
process continues till the complete system
is achieved.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 35

 The Incremental Model

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 36

 The Incremental Model - Advantages
1. Generates working software quickly and early
during the software life cycle.

2. More flexible – less costly to change scope and

requirements.

3. Easier to test and debug during a smaller

iteration.

4. Customer’s ability to respond to each built.

5. Easier to manage risk because risky pieces are

identified and handled during it’s iteration.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 37
 The Incremental Model - Disadvantages
6. Needs good planning and design.

7. Needs a clear and complete definition of the

whole system before it can be broken down and
built incrementally.

8. Total cost is higher than waterfall.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 38

 Evolutionary Models: The Spiral
• This was popular in the 1990s

• Key theory behind this model that each spiral

is supposed to be done based on risk
assessment.
– Perform a risk assessment (part of communication
and planning).
– Identify the highest risk item on the spiral and knock
that risk out first
– When you get to the next spiral, the risk is lower
than before.

• This model will help you in driving down risk

until you get to the end of the spiral.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 39
 Evolutionary Models: The Spiral
• Model is similar to the incremental
model, with more emphasis on risk
analysis.

• A software project repeatedly passes

through these phases in iterations (called
Spirals in this model).

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 40

 Evolutionary Models: The Spiral

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 41

 Evolutionary Models: The Spiral Advs
1. High amount of risk analysis hence, avoidance
of risk is enhanced.

2. Good for large and mission-critical projects.

3. Strong approval and documentation control.

4. Additional functionality can be added at a later

date.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 42

 Evolutionary Models: The Spiral Disadvs
• Can be a costly model to use.

• Risk analysis requires highly specific expertise.

• Project’s success is highly dependent on the

risk analysis phase.

• Doesn’t work well for smaller projects.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 43

 The Unified Process (UP)
• Based on the incremental model

• The first documented process to

recognize that having separate
communication, planning modeling,
construction and deployment is not
necessary.

• Blending some of them in reality was

better.

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 44

 The Unified Process (UP) Phases
• Inception: communication and planning activities
– E.g. Vision docs, initial use case model, initial business
case, project plan
• Elaboration: planning and modeling activities
– E.g. Use case model, analysis model, software
architecture description, workflow, milestone
• Construction: has only construction activity
– E.g. coding, integration, test plan, test case
• Transition: construction & deployment activities
– E.g. delivery of software increment.
• Production: part of the software release
• This will go on following the iterative model.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 45
 The Unified Process (UP)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 46

 The Unified Process (UP) Structure

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 47

 The Unified Process (UP) - Advantages
1. Provides capability to deal with changing
requirements throughout the development life
cycle, whether from customers or from within
the project itself.

2. Emphasizes the need (and proper

implementation of) accurate documentation.

3. Diffuses potential integration headaches by

forcing integration to occur throughout
development, specifically within the
construction phase where all other coding and
development is taking place.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 48
 The Unified Process (UP) - Disadvantages
1. Heavily relies on proficient and expert team
members
– since assignment of activities to individual workers
should produce tangible, pre-planned results in the
form of artifacts.

2. Emphasis on integration throughout the

development process could be detrimental
during testing or other phases.

3. It can be challenging for many organizations,

particularly for smaller teams or projects

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 49

 Agile Software Development
• Drivers:
– Faster delivery of working software to
customers without “excessive” process
burdens"
– Avoidance of things that “waste time”
– Less documentation
– Ensure that software is reusable with some
form of global framework

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 50

 Agile Software Development
• Agile methods emphasize:
– Individuals and interactions over processes
and tools.
– Working software over comprehensive
documentation
– Customer collaboration over contract
negotiation
– Responding to change over following a plan

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 51

 Extreme Programming (XP)
• Most widely used agile method originally
proposed by Kent Beck
• XP takes an extreme approach to iterative
development
– "whatever works well in some projects, why not
maximize its use?“

• New versions may be build several times per day

• Increments are delivered to customer every two
weeks
• All test must be run for every build which is
accepted if tests run successfully
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 52
 Extreme Programming (XP) Values
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 53

 Extreme Programming (XP) Values
1. Communication
– Enhance communication among team members and
with the customers
2. Simplicity
– Build something simple that will work today rather
than something that takes time and yet never used
– May not pay attention for tomorrow
3. Feedback
– System staying out of users is trouble waiting to
happen
4. Courage
– Don't hesitate to discard code
5. Respect
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 54
 Extreme Programming (XP) Activities
• XP Planning
– Begins with the creation of “user stories”
– Agile team assesses each story and assigns a “cost“
– Stories are grouped together for a “deliverable
increment“
– A “commitment” is made on delivery date
– After the first increment “project velocity” is used
to help define subsequent delivery dates for other
increments

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 55

 Extreme Programming (XP) Activities
• XP Design
– Follow the KIS principle
– Encourage the use of CRC card(class responsibility
collaboration card)
– Suggest creation of "spike solutions" - a design prototype
– Encourage refactoring

• XP Coding
– Recommends the construction of a unit test for the story
before coding
– Encourage pair programming

• XP Testing
– All unit test are executed daily
– Acceptance test are defined by the customers and
executed to assess the customer visible functionality
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 56
 Extreme Programming (XP)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 57

 Taking Good Practices to XP
1. Code review:
– Always review --- pair programming

2. Testing:
– it makes software more reliable)
– continually write and execute test cases --test-
driven development

3. Incremental development:
– (eliminates the problems of waterfall model)
– come up with new increments every few days

4. Simplicity:
– Create the simplest design that will support only
the currently required functionality.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 58
 Taking Good Practices to XP
5. Design:
– Everybody will design daily(refactoring)

6. Architecture is important
– Everybody will work at defining and refining the
architecture

7. Integration testing is important

– Build and integrate test several times a day
(continuous integration)

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 59

 Scrum
• Originally proposed by Schwaber and Beedle“

• Characteristics
– Self-organizing teams
– Product progresses in a series of month-long
sprints (increments)
– Requirements are captured as items in a list of
product backlog (continuously)
– One of the agile process

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 60

 Sprint
• Scrum projects progress in a series of
"sprints"
– Similar to XP iterations or time boxes
– Target duration is one month

• Software increment is designed, coded

and tested during the sprint

• No changes entertained during a sprint

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 61

 Scrum

Sprint
Review

Product Backlog Sprint Backlog Sprint Working increment of

the Software

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 62

 Scrum Framework
• Terms constituting the scrum framework

• Roles
– Product Owner (customer), Scrum Master(project
manager), Team (team members)

• Ceremonies:
– Sprint Planning, Sprint Review, Sprint Retrospective,
Daily Scrum Meeting

• Artifacts (Documents):
– Product Backlog (Requirements), Sprint Backlog
(Requirement per one Sprint), Burndown Chart
(captures how far the project has progress)
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 63
 Key Roles and Responsibilities in Scrum Process
• Product Owner:
– Acts on behalf of customers to represent their
interests

• Scrum Master (aka Project Manager):

– Facilitates scrum process and resolves
impediments at the team and organization level
by acting as a buffer between the team and
outside interference.

• Development Team:
– Team of 5- 9 people with cross-functional skill
sets.
SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 64
 Key Roles and Responsibilities in Scrum Process
• Product Owner:
1. Defines the features of the product
2. Decide on release date and content
3. Prioritize features according to market value
4. Adjust features and priority every iteration,
as needed
5. Accept or rejects work results

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 65

 Key Roles and Responsibilities in Scrum Process
• Scrum Master
1. Represents management of the project
2. Removes impediments
3. Ensure that the team is fully functional and
productive
4. Enable close cooperation across all roles and
functions
5. Shield the team from external interferences

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 66

 Key Roles and Responsibilities in Scrum Process
• Scrum Team
1. Typically 5-10 people

2. Cross functional
– QA, programmers, UI designers etc.

3. Teams are self-organizing (decides who can do

what best among themselves)

4. Membership can change only between sprints

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 67

 Review of Software Engineering in a Nutshell
• Development of software systems whose
size/complexity warrants team(s) of engineers
– Multi-person construction of multi-version software

• Scope
– Software process (life cycle)
– Software development principles
– Software methods and notations

• Goals
– Production of quality software,
– Delivered on time, within budget,
– Satisfying customers’ requirements and users’ needs

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 68

 Q&A

SE 3140 - System Design and Modelling Prepared by Dams G. L. Chapter 2: Slide 69