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
