Chapter 2

The Process
Reference text books:
- Software Engineering
A Practitioner’s Approach
Roger S. Pressman
Fifth Edition, 2001
- Software Engineering, Ian Sommerville,
6th Edition, 2000
- Software Project Management, Bob Hughes
and Mike Cotterell, 2001
- Software System Development: A Gentle Introduction,
Carol Britton & Jill Doake, Third Edition, 2003
2.1. A Layered Technology

a) Process, Methods, and Tools

Tools
Methods
Process

A quality focus

 The foundation for SE is the process layer. SE process is the glue

that holds the technology layers together and enables rational and
timely development of computer SW.
 SE method provide the technical how-to’s for building SW
(Communication, Requirements, Design, Code, Testing,
Deployment, support)
 SE tools provide automated or semi-automated support for the
process and the methods
2.1. A Layered Technology
b) A Generic View of SE
 The work associated with SE can be categorized three generic
phases:
 The definition phase focus on what
 What information is to be processed
 What function and performance are desired
 What system behavior can be expected
 What interfaces are to be established
 What design constraints exist
 What validation criteria are required to define a successful system
* Three major tasks will occur in some form:
▪ System or information engineering (Chapter 10 of [2])
▪ SW project planning (Chapter 3, 5, 6, and 7 of [2])
▪ Requirements analysis (Chapter 11, 12, and 21 of [2])
2.1. A Layered Technology

b) A Generic View of SE
 The development phase focus on how
 How data are to be structured
 How function is to be implemented with a SW
architecture
 How procedural details are to be implemented
 How interfaces are to be characterized
 How the design will be translated into programming
language
 How testing will be perform
* Three specific technical tasks should always occur:
▪ SW design (Chapter 13-16, and 22 of [2])
▪ Code generation and SW testing (Chapter 17, 18, and
23 of [2])
2.1. A Layered Technology

b) A Generic View of SE
 The support(maintenance) phase focus on Change
associated with error correction, adaptation,
enhancement, prevention. Four types of change are
encountered during the support phase:
 Correction  Corrective maintenance
 Adaptation  Adaptive maintenance
 Enhancement  Perfective maintenance
 Prevention  Preventive maintenance
2.2. Software Life-Cycle

 SW Life-Cycle គជាដ
ឺ ណំ ំ ់កាលគតចាប
ក ិ ់ពីពពលដដល SW ត្តូវ

បានបព្ើត
ក ព ើ្រហូតដល់ពពលពគដល្ពត្បើ (ពីពពលចាប់កពកត
ើ ព្យ
ើល

តបពៅនឹ្តត្រូវការ Operate, maintenance រហូតដល់ពពល

ពបាោះប្់ពចាលដល្ពត្បើ)។

 ំ ន់ៗគឺ Analysis,
SW Life-Cycle ត្តូវបានដែកជា Phase សខា

Design, Coding, Testing, maintenance។ ការសដរ្

ែ ជា

ំ
phase ទ្ឡាយមានភាពខុសគ្នាពៅតាររនុសសមាាក់ៗ។
2.2. Software Life-Cycle

● Primary functions of a software

process model
 Determine the order of the stages involved in
software development and evolution.
2.2. Software Life-Cycle

● Why are software process models

important?
They provide guidance on the order in
which a software development project
should carry out its major tasks
2.2. Software Life-Cycle
1) The Waterfall Model Life Cycle

 ត្តូវបានបព្ើត
ក ព ើ ្កុ ្ឆ្
ា ំ
ា ១៩៧០ ពោយពោក Winston W.

Royce

 ឹ ែាស់ោស់នូវតត្រូវការ
ពគពត្បើ model ពនោះពៅពពលពគដ្

ំ
ទ្ឡាយជារុ នសិន។
2.2. Software Life-Cycle
1) The Waterfall Model Life Cycle
Define System
requirements
Verify

Define SW
requirements
Verify

Basic design
Verify

Detailed design
Verify

Coding
Debug
Retire
Testing

Trial running

Operation
Maintenance
Review
2.2. Software Life-Cycle
* The New Additional of SW Life-Cycle
ំ
(1) Requirements definition and Design phase មានតួនាទីកណ ត់ពៅពលើ
គុណភាព SW ដដលពត្បកមា ើ ំ
ល ្អស់រួយភាគធពំ បពត្បៀបពៅន
ើ ឹ ្ការសរពសរ
Code ការពធពតស
ើវ ែ និ្ដែកចាយ SW ។
ើវ Structure របស់ SW កាន់ដតមានភាពជាក់ដស្
(2) ជា Phase ដដលពធឲ្យ ែ ពៅ
តាររពបៀប Top-down។

ឺ តាររពបៀប
(3) Design, Coding phase គពធ ើវ Top-down រឯ
ី Testing phase
តាររពបៀប Bottom-up។
(4) រុនពពលឈានពៅដល់ Phase បនពែ ទៀតត្តូវធានាថា Phase ដដលកព
ំ ុ្
អនុវតបា
ែ នពធពតស
ើវ រែ ួែពហើយ ពោយពុំមានពៅសល់កហ
ំ ុ សពទៀតព ើយ។
ំ
(5) ចាបាែ់ត្តូវមានយនកា ែ រត្តួតពិនិតយគុណភាព ពិនិតយពរលព ើ ើ្វញរវា្
ិ
Phaseនីរួយៗ ពដរ ើ បធានាក
ី ំ យប្ក
ុ ឲ្ ំ ុ សដល់ Phaseពត្កាយៗពទៀត។
ក ហ
(6) ឯកសារនន Phaseនីរួយៗរនត្ត
ិ រដតពត្ប
ឹ សត្មាប
ើ ់ Phaseពត្កាយៗបុ ពណណោះ
ំ
ពទ ដែរទ្សត្មាប ់ពគ្នលពៅសខា
ំ ន់ៗដល់ការត្តួតពិនិតយ និ្ធានាគុណភាព
នន Process នីរួយៗ និ្សត្មាប់ SW ខួ នឯ្ពទៀតផ្។
ល
2) Linear Sequential Model

Also known as:

 Classic life cycle model or
 System development life cycle (SDLC) model
* This is a good model to use when requirements
are well understood
2) Linear Sequential Model

Analysis Design Code Test

System/information
engineering
3) The Prototyping Model (Throw away Model)

Listen to Build/Revise
customer mock-up

Customer test
drives
mock-up
• Objective is to understand the system requirements
• Should start with poorly understood requirements to
clarify what is really needed.
3) The Prototyping Model (Throw away Model)

 You use this model when the client is not

clear about the requirements of the
proposed system or when there is a
conflict in client requirements
 To resolve the conflict, the development team
develops a working model so that the
requirements of the client become defined
3) The Prototyping Model (Throw away Model)

Requirement
Analysis
Design Code Test Implementation
Design
Coding
Testing
3) The Prototyping Model (Throw away Model)

តរើត្រូវត្វើ Prototyping model តៅតេលណា?

 ំ
ពៅពពលពទើបដឹ្នូវពគ្នលបណ ្ត្តួសៗនន SW រិនទន់ែាស់ពសែកីលរ
ែ ិតន
តន ូ វអីជា
វ

ែ ឬរិនទន់ែាស់នូវអីជាតត្រូ
Input ឬ Process យ្ដូែពរែ វ វការសត្មាប់ output

ពៅព ើយពទ។

 ពត្បើ “The first system” ពដើរបត្បរ

ី ា ពត្បើត្បាស់តាររយៈ design
ូ លតត្រូវការពីអក

ពលឿន។

 Algorithm បពែក
េ ពទសពត្បើពដើរបពធ
ី ើវ Prototype អាែរិនទន់ពលឿន រិនទន់ល តន
នលយ្ណឲ្យដតបានពធើជាគត្រូ
វ ពដរ
ើ បព ែ ់ ជាតត្រូវការននអក
ី ិ ភាកា ផល ា ពត្បើត្បាស់។
4) The RAD (Rapid Application Development) Model

Team #3
Business
Modeling
Data
Team #2
Modeling
Business Process
Modeling Modeling
Data Application
Team #1 Generation
Modeling
Business Process Testing &
Turnover
Modeling Modeling
Data Application
Generation
Modeling
Testing &
Process Turnover
Modeling
Application
Generation
Testing &
Turnover
60 - 90 days
4) The RAD (Rapid Application Development) Model

The RAD Model is a high-speed adaptation of

the linear sequential model
Project requirements must be well understood
and the project scope tightly constrained
Developers are often able to use component-
based construction techniques to build a fully
functional system in a short time period
4) The RAD (Rapid Application Development) Model

RAD Model មានលកណ

ខ ៈ

 ដពំ ណើរការអភិវឌ្ឍន៍ SWតារដបបបដនរ

ែ (Incremental software development) គឺ

ពកើនព ំ នៗ ដដលជុអ
ើ្ជាជហា ំ ភិវឌ្ឍន៍នីរួយៗមានរយៈពពលខី(៦០
ល ពៅ ៩០ នែ)ៃ ។

 Component-based construction ធ ពពត្បើត្បាស់ព

ពោយលទភា ើ្វញ
ិ

(reusability)។

 រួរមាន Team ំ ួ ន ដដល

រួយែន Team នីរួយៗអនុវតែ 1 RAD ពៅតារ Phase:

Business modeling, Data modeling, Process modeling, Application

Generation, Testing and turnover។

4) The RAD (Rapid Application Development) Model

1. Teams should consist of about 6 people,

including both developers and full-time users of
the system plus anyone else who has a stake
in the requirements.
2. Developers chosen for RAD teams should be
multi-talented "renaissance" people who are
analysts, designers and programmers all rolled
into one)
4) The RAD (Rapid Application Development) Model

* Business modeling

Information flow ត្តូវបានបព្តើក ជា model ពដរើ បព្

ី យន
ើល ំ ួ រ:
ូ វសណ

- What information drives the business process?

- What information is generated?
- Who generates it?
- Where does the information go?

- Who processes it?

4) The RAD (Rapid Application Development) Model

* Data modeling:
ំ
Data objects ចាបាែ ់ពដើរបជាជ
ី ំ ួ យដល់កែ
ន ិ កា
េ រ business ត្តូវបានបព្ើត
ក ព ើ្។

ទនឹ រន
ទ ឹ ្ពនាោះ attribute នន object នីរួយៗក៏ដូែជាទនា
ំ កទ
់ ន
ំ ្រវា្ object

ំ
ទ្ឡាយ ក៏ត្តូវបានកណ
ំ ត់ពៅកុ ្ពពលពនាោះដដរ។
ា

* Process modeling:
The data objects ត្តូវបានបដរ្ ំ
ល ពៅជា information flow ចាបាែ ់ ពហើយអនុវតែ

នូវរុខងារ business។ ទនឹ រន

ទ ឹ ្ពនោះ Processing descriptions ក៏ត្តូវបានបព្ើត
ក

ពដើរបបដន
ី រ
ែ ដកតត្រូវ លុប សាែរព ើ្វញនន
ិ data objectនីរួយៗ។
4) The RAD (Rapid Application Development) Model

* Application Generation:
ពត្បើបពែក ំ ន់ទី៤ពដើរបបព្
េ ពទសជនា ី ក SW ពី Component ដដលមានត្សាប់ ឬបព្ើត
ើត ក
ពែញជា Component ដដលអាែពត្បើត្បាស់ព ើ្វញបានពៅពពលពត្កាយពទៀត។
ិ ពត្បើ

Tool ពោយស័យ
វ ត្បវតិែ ពដើរបបព្
ី ើត
ក SW ។
 CASE is SW to support SW development and evolution processes
 Activity automation

 Graphical editors for system model development

 Data dictionary to manage design entities

 Graphical UI builder for user interface construction

 Debuggers to support program fault finding

 Automated translators to generate new version of a program

4) The RAD (Rapid Application Development) Model

* Testing and Turnover:

ពធពតស
ើវ ស
ែ មាសភាពែីម និ្ពិនិតយពរលត្គប
ើ ់ interface (សមាសភាពចាស់
ត្តូវបានពធពតស
ើវ ែ និ្ពត្បពើ ើ្វញ)។
ិ
* RAD: Drawback ?

 ត្តូវការត្បភពធនធានរនុសសត្គប់ត្គ្នន់ពដើរបបព្
ី ក Team សត្មាប់រុខងារសខា
ើត ំ ន់ៗ។

 ំ ី រ (Developers and customers) ែុោះកិែស

តត្រូវឲ្យភាគីទ្ព េ នាកុ ្រយៈពពលខ
ា ី ល ត្តូវដត

មាន SW ឲ្យបានត្គប់ត្គ្នន់។ ខោះ

វ ការទទួលខុសត្តូវពីភាគីមាខ្ ងាយនឹ្ពធើឲ្យគពត្មា្
វ
ខូែការ។

 RAD ពុំមានភាពត្បពសើរសត្មាប់ត្គប់ Applications ព ើយ ពិពសសែពំ ោះ Application

ដដលរិនអាែបដំ បកពៅជា Module ឬទរទរ performance ខស

ព ់។

 ពបើ Risk ខា្ដផក

ា បពែក ព ់ គឺរិនត្តូវពត្បើ RADព
េ ពទសមានកត្រិតខស ើយ។
5) Evolutionary Software Process Model

a) Incremental Model
Increment 1

Analysis Design Code Test Delivery 1

System/info.
Engineering

Increment 2 Analysis Design Code Test Delivery 2

Increment 3 Analysis Design Code Test Delivery 3

Increment 4 Analysis Design Code Test Delivery 4

Calendar time
5) Evolutionary Software Process Model

b) The Spiral Model(1988)

 The spiral model may be applicable to projects where:
the projects requirements are very difficult (for large,
expensive and complicated projects) and the new
technologies are used
5) Evolutionary Software Process Model

b) The Spiral Model

Planning
Risk analysis

Customer
communication

Concept development Engineering

projects

New Product
development projects

Product enhancement projects

Customer
evaluation Construction and
Product maintenance projects Release
5) Evolutionary Software Process Model

b) The Spiral Model

 Customer communication: គឺជាដណ ំ ក់កាលដដល Developer និ្

ំ ក់ទន
Customer ពធើទវ នា ំ ្ជារួយគ្នា ពដើរបដស វ យល់តត្រូវការ និ្គន
ី ្ ំ ិ តពផស្ៗ។

 ំ
Planning :កណ ត់ឲ្យបានែាស់ោស់នូវត្បភពធនធាន រយៈពពល ែវកា
ិ និ្ព័ត៌មាន
ពផស្ៗពទៀត។

 Risk analysis: វភាគពរ

ិ ំ Technical risk និ្ management risk។
ើលទ្

 Engineering : Build one or more representations of the

application
 Construction and release: Construct, test, install, and provide
user support (Documentation and training).
 Customer evaluation: ទទួលយកត្បតិករព
ម ី អតិែជ
ិ នត្ត ប់រកវញន
ិ ូ វ SW

representations កុ ្ដ
ា ំ
ណ ់ ល Engineering និ្ Installation។
កកា
5) Evolutionary Software Process Model

b) The Spiral Model

 Advantages
 High amount of risk analysis
 Good for large and mission-critical projects.
 Software is produced early in the software life
cycle.
5) Evolutionary Software Process Model

b) The Spiral Model

 Disadvantages
 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.
5) Evolutionary Software Process Model

c) The Winwin Spiral Model(1994)

The WinWin spiral model, which extends the
spiral software development model by adding
Theory W activities to the front of each cycle.
 WinWin, a groupware tool that makes it easier for
distributed stakeholders to negotiate mutually
satisfactory (win-win) system specifications.
 The study showed that the WinWin spiral model
is a good match for multimedia applications and is
likely to be useful for other applications with similar
characteristics.
5) Evolutionary Software Process Model

c) The Winwin Spiral Model(1994)

 ពដើរបសត្ររ
ី ោះសត្រួលឬែរចាររវា្ Developer ំ ី រ “ឈ្ោះ
និ្ Customer ដដលភាគីទ្ព ា ”
ដូែគ្នា។
 អតិែិជនទទួលបាន System or product ព្ើយតបពៅន
ល ឹ ្តត្រូវការជារូលោាន។
 Developerទទួលបានែវកាសរររយ
ិ ំ
តាររយៈពពលកណ ត់សរពហតុផល។

 សករភា ំ នៗ
ម ពសខា ់ កុ ្ការក
ា ណំ ់ យបានែាស់នន; system:
តឲ្

• Identification of the system or subsystem’s key

“stakeholders”
 ំ
កណ ត់លកខ ័ ឌ ឈ្ោះ
ខ ណ ា “win condition” នន stakeholder
 សត្ររោះសត្រួលលកខ ័ ឌ ឈ្ោះ
ខ ណ ា ននភាគី ក់ព័នធ ពដើរបឲ្យព
ី ួ កពគទទួលបាន win-win
condition រួយ
 5) Evolutionary Software Process Model

c) The Winwin Spiral Model(1994)

* Typical Cycle of the WinWin Spiral Model
 Identify the system or subsystem's key stakeholders (1).
 Identify the stakeholders' win conditions for the system or subsystem (2).
 Negotiate win-win reconciliations of the stakeholders' win conditions (3a).
 Elaborate the system or subsystem's product and process objectives,
constraints, and alternatives (3b).
 Evaluate the alternatives with respect to the objectives and constraints.
Identify and resolve major sources of product and process risk (4).
 Elaborate the definition of the product and process (5).
 Plan the next cycle, and update the life-cycle plan, including partition of
the system into subsystems to be addressed in parallel cycles. This can
include a plan to terminate the project if it is too risky or infeasible. Secure
the management's commitment to proceed as planned (6, 7).
5) Evolutionary Software Process Model

c) The Winwin Spiral Model(1994)

2. Identify stakeholders’ win 3a. Reconcile win conditions
conditions 3b. Establish next-level objectives,
constrains and alternatives

4. Evaluate process
1. Identify next- and product alternatives
level stakeholders and resolve risks

7. Review and comment

6. Validate product and 5. Define next level of
process definitions product and process,
including partitions
6) The Component-Based Development Model

Identify
candidate
Planning Risk components
Analysis

Construct Look up
nth iteration components
Customer of system in library
Communication

Put new Extract

components components
in library if available

Build
Customer components
evaluation if unavailable
Engineering,
Construction & Release
7) The V-process model

 Software requirements clearly defined and known

 Software development technologies and tools is well
known
Feasibility Corrections Review
study

User Corrections User

requirements acceptance

System Corrections System

design testing

Program Corrections Program

design testing

Code
2.3. How to Select the Right SDLC

 STEP 1: Learn the about SDLC Models

 STEP 2: Assess the needs of Stakeholders
 STEP 3: Define the criteria
 Is the SDLC suitable for the size of our team and
their skills?
 Is the SDLC suitable for the selected technology
we use for implementing the solution?
 Is the SDLC suitable for client and stakeholders
concerns and priorities?
 Is the SDLC suitable for the geographical
situation (distributed team)?
 Is the SDLC suitable for the size and complexity
of our software ?
2.3. How to Select the Right SDLC

 Is the SDLC suitable for the type of projects we

do?
 Is the SDLC suitable for our software
engineering capability?
 Is the SDLC suitable for the project risk and
quality insurance?
 STEP 4: Decide
 STEP 5: Optimize