COMP 3111

SOFTWARE ENGINEERING

LECTURE 5
SOFTWARE DEVELOPMENT

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 1
 14, 15

SOFTWARE DEVELOPMENT OUTLINE

 Overview of Software Development
– Nature and Types of Software
– Types of Software Development Projects
– Software Development Life Cycle (SDLC)
– The Four P's in Software Development

 Software Development Processes

– Monolithic
 Waterfall
– Iterative and Incremental
 Code-and-Fix
 Prototyping
 Spiral
 Phased-release
 Agile
 Unified Process (UP)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 2
 SOFTWARE DEVELOPMENT PROCESSES STAGES
 Most software development processes share the following
stages:
– gathering the system requirements
– analyzing and designing the system
– implementing the system
– testing the system

 They mainly differ in how these stages are:

1. combined 2. emphasized 3. carried out

We want to understand the strengths and weaknesses

of different software development processes.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 3
 15

SOFTWARE DEVELOPMENT OUTLINE

 Overview of Software Development
– Nature and Types of Software
– Types of Software Development Projects
– Software Development Life Cycle
– The Four P's in Software Development

 Survey of Software Development Processes

Monolithic
 Waterfall
– Iterative and Incremental
 Code-and-Fix
 Prototyping
 Spiral
 Phased-release
 Agile
 Unified Process (UP)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 5
 15.4.1

WATERFALL PROCESS
Should be used only when
Produces a requirements
Requirements specification document requirements are well under-
stood and unlikely to change.
Analysis & Produces a design
Design specification document

Produces an implemented
Implementation collection of modules
Produces a
tested
Testing assembly
of modules

Maintenance
Keeps the
system
Plus: reviews (for correctness, standards), deliverables working and
up-to-date
(documentation, code, training material, …), …
COMP 3111 1 September
©2018 L5: SOFTWARE DEVELOPMENT 6
 WATERFALL PROCESS: PROS & CONS
Pros Cons

 Imposes needed discipline  Assumes linear, sequential

(rigor and formality). development is possible.

 Keeps development  Rigid assuming results of

predictable and easy to each phase can be frozen
monitor. before proceeding to the next
phase.

 Enforces documentation
standards and approval of  Different languages/notations
documents before proceeding. often used in each phase.

 Fits well with other  Makes little provision or

engineering process models opportunity for user feedback,
(e.g., hardware development). which is a source of high risk.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 7
 15

SOFTWARE DEVELOPMENT OUTLINE

 Overview of Software Development
– Nature and Types of Software
– Types of Software Development Projects
– Software Development Life Cycle
– The Four P's in Software Development

 Survey of Software Development Processes

– Monolithic
 Waterfall
Iterative and Incremental
 Code-and-Fix
 Prototyping
 Spiral
 Phased-release
 Agile
 Unified Process (UP)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 8
 CODE-AND-FIX PROCESS
 Many changes
☞ code structure often Requirements Implementation Testing
becomes messy

Requirements Source
Specification Code
 Unsuitable for large systems:
– turnover of personnel Usually does not exist
(except in the
– difficult to understand/fix code developer’s mind)!

– requirements can easily be unmatched

 The software development process becomes:

– unpredictable and uncontrollable
– over schedule, over budget and fails to meet expectations

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 9
 2.3.6

PROTOTYPING PROCESS
Start  Basically a code-and-fix
process, BUT includes
Stop Gather client evaluation and
Requirements enforces some discipline.
& Refine
Engineer Quick  Useful when
Product Design requirements are vague
or unknown as it allows
exploration of
Refine Build
– functionality needed
Prototype Prototype
– user interface
Client
Evaluation of
What to do with the
Prototype
final prototype?
(80/20 rule)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 10
 PROTOTYPING PROCESS: PROS & CONS
Pros Cons

 Allows requirements to be  It is not really a complete

quickly explored. software development
process.

 Allows user feedback and

approval to be obtained.  The process is not visible
making progress hard to
measure.
 Allows different solutions to be
explored.
 Documentation is often sparse
or completely absent.

 The final “product” is not a

complete system.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 11
 15.4.2

SPIRAL PROCESS
Planning Risk analysis

Go, no-go
decision

Toward a
completed
system

Client evaluation Engineering

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 12
 SPIRAL PROCESS: PROS & CONS
Pros Cons

 Risk evaluation can help  Relies on expertise in risk

reduce development assessment.
problems.

 Needs more elaboration of the

 Planning and client evaluation phases (i.e., specific activities
phases help the product better that should be performed).
meet client expectations.

 More appropriate for internal

 Iterative and incremental development than contract
planning, engineering and development.
evaluation facilitates project
management.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 13
 PHASED-RELEASE PROCESS

Premise: Change is inevitable, so plan for it!

Developers

Development
Build release 1 Build release 2 Build release 3 ... releases

Time
Users

Production
Use release 1 Use release 2 Use release 3 ... releases

Releases are developed and used in parallel.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 14
 PHASED-RELEASE PROCESS (cont’d)

incremental development → partial system; full functionality

iterative development → full system; partial functionality

time
Many organizations use a combination of iterative and incremental.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 15
 PHASED-RELEASE PROCESS: PROS & CONS
Pros Cons

 Reduces the risk of project  The system pieces need to be

failure. relatively small.

 Promotes system modularity.  It may be hard to identify

common facilities needed by
all pieces.
 Allows frequent releases.

 Allows appropriate expertise

to be applied.

 Allows early training and

feedback.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 16
 16.4.2

AGILE PROCESS
 Any phased (incremental) approach where the emphasis is
more towards the items on the left.

⟵ more important less important ⟶

individuals and interactions processes and tools

working software comprehensive documentation

client involvement/collaboration contract negotiation

responsiveness to change following a plan

☞ This does not imply that there is no value

in the items on the right!

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 17
 AGILE PROCESS (cont’d)
 Methods
– Extreme Programming (XP)
– Continuous Integration
– Scrum

 Practices
– Planning poker → used to estimate time required to implement a
feature (see [Link]
– Pair programming → used to write code for a feature
– Test Driven Development (TDD) → used to test the code

COMP 3111 15 September

©2021 L5: SOFTWARE DEVELOPMENT 18
 16.4.2

AGILE PROCESS: EXTREME PROGRAMMING (XP)

 Requirements and analysis:
– developer determines features needed
estimates time and cost for each feature
– client selects features to be included in each iteration

 Implementation (by iterations/sprints):

– the developer breaks each iteration into tasks
– for each task (where tasks can be carried out in parallel) the
developer
 designs test cases (test-driven development)
The major
 implements the task using pair programming
emphasis is here.
 integrates the task into the current product

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 19
 AGILE PROCESS: CONTINUOUS INTEGRATION (CI)
● Continuous Integration (CI) is an agile software development
process where developers integrate code into a shared
repository on a daily basis.
– allows developers to integrate and test their code early
– quickly catches/exposes any bug that breaks the build
– reduce integration conflicts by doing integration continuously
– help developers to check the progress of their development
– building and testing are done automatically with scripts

● A CI Server is required to compile the code periodically, and

reports the results to the developers.

COMP 3111 15 September

©2021 L5: SOFTWARE DEVELOPMENT 20
 CONTINUOUS INTEGRATION: ARCHITECTURE
The key to fixing problems quickly is finding them quickly.
– (Fowler, 2006)

 Developers submit work to the main repository on a daily basis

 CI Server automatically runs build/test scripts, and notifies

developers about failed build/tests

COMP 3111 15 September

©2021 L5: SOFTWARE DEVELOPMENT 21
 AGILE PROCESS: SCRUM

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 20
 AGILE PROCESS: SCRUM
● Scrum is an agile software development process that mainly
specifies what you should do to develop a software product.

● No specific software engineering practices are prescribed for

developing the product; the team needs to decide how to do it.

● The requirements are captured as items in a “product backlog”;

the product owner (client) sets the priorities for the items.

● The software product is developed in a series of iterations called

“sprints”.

● Teams self-organize to determine the best way to deliver the

product.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 21
 SCRUM: SPRINT WORKFLOW

SPRINT

 The software product is designed, coded and tested during the

sprints.

 The requirements are not allowed to change during a sprint.

COMP 3111 1 September
©2018 L5: SOFTWARE DEVELOPMENT 22
 SCRUM: FRAMEWORK

Roles
• Product owner
• ScrumMaster
• Team
Meetings
• Sprint planning
• Daily scrum meeting
• Sprint review
• Sprint retrospective
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 23
 SCRUM: ROLES
Product Owner (aka Client)
– Is the key stakeholder (represents users, client)
– Defines and prioritizes the requirements of the product.
– Adjusts requirements and priority every iteration, as needed.
– Decides on the release date and content.
– Accepts or rejects work results.

Scrum Master (aka Project Manager / Team Leader)

– Responsible for enacting Scrum values and practices.
– Ensures that the team is fully functional and productive.
– Enables close cooperation across all roles and functions.
– Removes impediments to progress and shields the team from
external interferences.
COMP 3111 1 September
©2018 L5: SOFTWARE DEVELOPMENT 24
 SCRUM: SPRINT PLANNING MEETING

Team Sprint planning meeting

capacity
Sprint prioritization
Product • Analyze and evaluate product Sprint
backlog backlog (requirements) goal
• Select sprint goal
Business
conditions Sprint planning
• Decide how to achieve sprint
Current goal Sprint
product • Create sprint backlog (tasks) backlog
from product backlog items
Techno- (requirements)
logy • Estimate time to implement
sprint backlog (tasks)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 25
 SCRUM: DAILY SCRUM MEETING
 A team meeting in which everyone answers three questions:

1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 26
 SCRUM: ARTIFACTS
Product Backlog
– Represents the requirements of the system (i.e., a list of all desired
functionality of the system).
– Ideally expressed such that each item has value to the users or
customers of the product.
– Items in the backlog are prioritized by the product owner (client) and
reprioritized at the start of each sprint.

Sprint Backlog
– Contains items selected from the product backlog based on item
priority and on how much the team thinks they can do in a sprint.
– A product backlog item may become several sprint backlog tasks.
– Team members select sprint backlog items to work on during the
sprint.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 27
 SCRUM: ARTIFACTS (cont’d)
Burndown Chart
Tasks Mon Tue Wed Thu Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40 The burndown chart
Hours

30 graphically shows the

20 total hours remaining
each day to complete
10
the sprint.
0
Mon Tue Wed Thu Fri

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 28
 AGILE PROCESS: PROS & CONS
Pros Cons

 The development is adaptable  Active user involvement and

to changing requirements close collaboration are
(flexible). required.

 Immediate feedback is  There is often a lack of

provided by the client/users. documentation.

 Results in faster speed-to-  There can be scope creep as

market. the client/users add
requirements.

 There are fewer defects in the

final product.  Daily stand-up meetings can
take a toll.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 29
 SOFTWARE DEVELOPMENT PROCESS:
PRINCIPLES
 rigor and formality (Waterfall; Spiral)

 separation of concerns and modularity (Waterfall; Spiral; Phased-

release)

 abstraction and generality (Waterfall; Spiral)

 anticipation of change (Spiral; Phased-release; Agile)

 incremental development (Prototyping; Spiral; Phased-release; Agile)

 risk assessment (Spiral)

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 30
 15.4.2

UNIFIED PROCESS (UP): LIFE CYCLE

Engineering Phases
Activities Inception Elaboration Construction Transition
Requirements
Capture

Analysis

Design

Implementation

Testing

Software Quality
Assurance
Project
Management
Management one iteration
Activities one increment
one cycle (generation)
COMP 3111 1 September
©2018 L5: SOFTWARE DEVELOPMENT 31
 UNIFIED PROCESS (UP): MAIN FEATURES
The UP selects from the best practices of previous processes to:

 provide a generic process framework

☞ It needs to be instantiated/specialized for specific application areas,
organizations, competence levels, project sizes, etc.

 define a set of activities (workflows)

☞ The workflows transform users' requirements into a software system.

 define a set of models (artifacts)

☞ Models range from abstract (user-level) to concrete (code).
☞ Models are transformed by the workflows into other models.

Each iteration results in a working product.

Each increment establishes a system baseline.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 33
 SOFTWARE DEVELOPMENT: SUMMARY
 A software development process needs to consider both
management and engineering issues.

 A software development process needs to consider the

characteristics of the:
– organization → size; access to users/client; need for formality.
– project → small/large; vague/well-defined; novel/well-known.
– people → availability of expertise; skill of developers.

 The Unified Process incorporates best practices of previous

software development processes.

The Unified Process provides a generic framework

to discuss software development activities.

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 34
 COMP 3111 SYLLABUS
 1. Introduction
 2. Modeling Software Systems using UML

 3. Software Development
4. System Requirements Capture

5. Implementation

6. Testing

7. System Analysis and Design

8. Software Quality Assurance

9. Managing Software Development

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 35
 SOFTWARE DEVELOPMENT
EXERCISE

COMP 3111 1 September

©2018 L5: SOFTWARE DEVELOPMENT 36