CS383 - Software Engineering

Software Process Models (II)

Semester: 432

Lecture: 4
Outline

● Software process models in practice

○ Coping with changes

● Agile software development

● IEEE documentations

2
Software Process Models in Practice

● Software organisations may combine aspects

of generic process models to meet the
specific needs of their projects

● The choice of process model is also

constrained by a range of other factors:
○ Contractual or regulatory requirements
○ Experience and familiarity with the process
model
○ Process models used by related projects

3
Example 1: Spiral model

4
Example 2: The Rational Unified Process

5
Rapid Methodology and overhead problems

● Nowadays software are developed very rapidly

○ Very fast changing of requirements (not stable software!)

○ Software to be evolve quickly to business needs

● Specification, design and implementation are interleaved (combined)

● Systems are developed in series of iterations

● Change user interface using toolset and IDE

● May have overheads software process and documentation

6
Agile Methodology

● Focus on the code rather than design or documentation

● Same as rapid process models, iterative approach
● Software evolves at same speed but maybe with stable versions

7
Principles of Agile Methodology

8
Agile Methodology Drawbacks

● Sometimes, practicing agile methods is difficult

○ Difficult to keep the interest of customers

○ Team members may be unsuited to the intense involvement

○ Prioritising changes can be difficult because of multiple

stakeholders

○ Maintaining simplicity requires extra work

○ Large companies defined processes and wanted to be followed

■ The idea that development team lead the team who may

not follow formally the defined processes

9
Plan-Driven and Agile Development

10
Plan-Driven and Agile Development (cont.)

Concern Plan Agile

Driven

- Very detailed specification and design before implementation X

- Deliver software to customers and get rapid realistic feedback X
- Large systems development X
- Systems require a lot of analysis before implementation X
- Long-lifetime systems that require more design documentation X
- Development may require up-to-date technologies for support X
- Development team are distributed (outsourced) X

11
Agile Method: Extreme Programming

● An ‘extreme’ approach to iterative development

12
Agile Method: Extreme Programming
● Incremental planning:
○ requirements recorded on story cards and then prioritize accordingly
(user involved) for implementation
○ tasks become the basis of scheduling and cost estimation
● Small releases:
○ frequently and incrementally releases (2 weeks window)
● Simple design:
○ just enough design to continue meetings get requirements
● Test-first development:
○ automated unit test is used for each functionality added (regression
testing)
○ tests are developed before execution of components
○ users involved early in the validation
13
Agile Method: Extreme Programming

● Refactoring:
○ improve code by refactoring more oftenly
● Pair Programming:
○ developers checking each others code for improvement and chance
(understandability)
○ tidy up the code and make it clear (informal review and checks)
○ Helps to make refactoring much easier
○ risk to need architecture refactoring for improvement
● Continuous integration:
○ integrate new completed task or functionality into the system
● Sustainable pace:
○ overtime is not acceptable as they affect code quality and
productivity
● On-site customer:
○ customer should be available full time.

14
User Stories

● Project owners do user stories, each story contains

○ Who (user role): customer, employee, admin, etc
○ What (goal): what functionality must be developed
○ Why (reason): why does this functionality needed

● Examples:
○ As a user, I want a cascade action warning, because I
want to avoid dependency problem
○ As a developer, I need a graphical hierarchy model of
the developed components updated automatically, so
that I better understanding of components
dependency.

15
Agile Method: Scrum

● Focuses on managing iterative development (not agile practices)

● Three phases:
1. The initial phase:
○ Establish general objectives and design the software
architecture
2. Sprint Cycles (2-4 weeks):
○ Each cycle is an increment of the system (features are
selected, developed and assessed)
3. Closure phase:
○ Wrap up the project including documentations

16
Sprint Cycle

17
Example of Product Backlog

Backlog item Estimate

3 (story
Allow a guest to make a reservation
points)
As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports
8
(revenue-per-available-room)
Improve exception handling 8

... 30

... 50

18
Example of Sprint Backlog

19
Summary: Software Process Model

Waterfall Incremental Reuse-oriente Agile

model development d methods
development

Requirements Low Medium Low Hight

Volatility

Project Size Large Medium Any Small

Customer Low Medium Low Hight

Involvement

Technical Risk Low High Medium High

Release Long Medium Short Very Short

Schedule

20
IEEE Documentations

● Documentation plays a good part in software engineering process

● There are a list of documentation for each software life cycle:
○ SQA – Software quality assurance
○ SCM – Software configuration management
○ STD – Software test documentation
○ SRS – Software requirements specification (required in your project)
○ V&V – Software verification and validation
○ SDD – Software design description (required in your project)
○ SPM – Software project management
○ SUD – Software user documentation (required in your project)
○ SRA – Software reviews and audit

21
SRS – Software requirements specification

1. A

1. Introduction
2. B
3. C

4. External User Interface

1.1. Purpose
4.1. User Interface
1.2. Scope
4.2. Hardware Interface
1.3. References
4.3. Software Interface
1.4. Structure
4.4. Communication Interface
1.5. Constraints
5. Non-functional Requirements
2. System Overview 5.1. Performance Requirements
2.1. Product Perspective 5.2. Safety Requirements
2.2. Product Features 5.3. Security Requirements
2.3. User Roles and Characteristics 5.4. Software Quality Attributes
2.4. Operating Environment 6. Other Requirements
2.5. User Documentation 6.1. ...
2.6. Assumptions and Dependencies
3. System Features
3.1. Feature 1
3.2. Feature 2
3.3. ...

22
SDD – Software design description

1. A

1. Introduction
2. B
3. C

4. Data Design
1.1. Purpose
4.1. Database Description
1.2. Scope
4.2. Data Structure
1.3. References
5. Design Details
1.4. Structure
5.1. Class Diagram
1.5. Constraints 5.2. State Diagram
2. System Overview 5.3. Interaction Diagrams
3. System Architecture and Components 6. Human Interface Design
Design 6.1. Overview of the User Interface
6.2. Detail Design of User Interface
3.1. Architecture Description
3.2. Component Decomposition Description
3.3. Detail Component Description
3.4. Design Rationale

23