Bài giảng Nhập môn công nghệ phần mềm - Trương Minh Thái - Chương 2: Các mô hình về tiến trình phần mềm

 Phù hợp với những bài toán ñược hiểu kỹ có ít 
hay không có các thay ñổi về yêu cầu
ðơn giản và dễ giải thích với khách hàng
10



 Nó biểu diễn

 Một tổng quan mức rất cao của tiến trình phát triển

 Một chuỗi tuần tự các hoạt ñộng của tiến trình
Mô hình thác nước
11
Mô hình thác nước
Xác ñịnh yêu cầu-ñặc tả hệ thống
Requirements engineering
V&V
Thiết kế (design)
V & V
• V & V:

 - Verification (kiểm tra): hệ 
thống thỏa mãn ñặc tả (Build 
the system right)
- Validation (kiểm tra-xác 
nhận): hệ thống thỏa mãn yêu 
cầu người dùng (Build the right 
12
Cài ñặt (implementation)
V & V
Kiểm thử (testing)
V&V
Bảo trì (maintenance)
V&V
system)
- ðặc ñiểm:
- Hướng tài liệu
- Phân tích kỹ trước khi xây dựng 
hệ thống
- kiểm tra từng buớc
- Kiểm tra chuyển tiếp giữa các 
bước
Mô hình thác nước

 ðặc tính: 

 Các lỗi ở một số giai ñoạn trước ñược phản hồi bởi các giai ñoạn sau

 Mỗi giai ñoạn chỉ ñược xem là hoàn thành sau khi ñã có ñầy ñủ tài liệu cho giai 
ñoạn ñó và ñược nhóm SQA chấp thuận 

 Các bước tiến hành chính:

 Các yêu cầu ñược xác ñịnh và kiểm chứng bởi khách hàng và nhóm SQA

 Các ñặc tả ñược kiểm chứng bởi nhóm SQA và gửi cho khách hàng 

 Giai ñoạn thiết kế bắt ñầu sau khi khách hàng ñồng ý về giá thành và thời gian 
thực hiện; thực hiện cài ñặt và tích hợp
Khách hàng cho hoạt ñộng thử 
13



 Chấp nhận sản phẩm 

 Chuyển sang giai ñoạn bảo trì 

 Ưu ñiểm: 
Kỷ luật cao; quy ñịnh tốt về tài liệu cho mỗi giai ñoạn; kiểm chứng 
cẩn thận bởi nhóm SQA; ñược ứng dụng rộng rãi 

 Khuyết ñiểm: 

 Quá nhiều kiểm thử, kiểm tra-xác nhận và tài liệu 

 Hướng tài liệu: khó hình dung và khó hiểu ñối với khách hàng 
Mô hình thác nước

 Hạn chế của mô hình thác nước

 Không cung cấp các hướng dẫn về cách thức xử lý 
những thay ñổi ñối về sản phẩm và hoạt ñộng trong 
suốt sự phát triển 
14

 Xem sự phát triển phần mềm như một tiến trình sản 
xuất hơn là tiến trình sáng tạo

 Không có các hoạt ñộng lặp mà chúng ñưa ñến việc 
tạo ra sản phẩm cuối cùng

 Phải chờ ñợi lâu trước khi có sản phẩm cuối
Mô hình chữ V (V Model)

 Một sự biến ñổi của mô hình thác nước

 Sử dụng kiểm thử ñơn vị ñể kiểm chứng thiết kế thủ tục

 Sử dụng kiểm thử tích hợp ñể kiểm chứng thiết kế hệ 
thống
15

 Sử dụng kiểm thử chấp nhận ñể xác nhận tính hợp lệ các 
yêu cầu

 Nếu các vấn ñề ñược tìm thấy trong suốt sự kiểm chứng 
và sự xác nhận tính hợp lệ, phần bên trái của mô hình chữ 
V có thể ñược tái thực hiện trước khi việc kiểm thử phần 
bên phải ñược tái thực hiện
Mô hình chữ V
16
Mô hình bản mẫu (Prototyping 
Model)

 Khó khăn ñể có 1 nhận thức
ñầy ñủ về hệ thống làm bản
mẫu.

 Một mô hình vềmột phần
của hệ thống

 Nhấn mạnh vào một vài khía
cạnh nào ñó
17
Bản mẫu là công cụ ñể 
ñặc tả yêu cầu

 Tạo ra một bản mẫu # làm “bản
thật”

 Làm nhanh

 Rẻ

 Thể hiện ñược ý tưởng trước
khi ñầu tư lớn
 Dùng ngôn ngữ cấp cao
 Phát triển một hệ thống với
ít chức năng
Mô hình bản mẫu

 Cho phép sự nghiên cứu về các yêu cầu và thiết 
kế ñược lặp lại 

 Giảm sự rủi ro và sự không chắc chắn trong phát 
triển
18

 Sử dụng mô hình bản mẫu khi các yêu cầu không 
rõ ràng. 

 Mô hình có thể lấy một trong 3 dạng:

 Bản mẫu trên giấy hay PC.

 Bản mẫu là việc cài ñặt tập con các chức năng.

 Bản mẫu là chương trình ñã có.
Mô hình bản mẫu

 Ưu ñiểm

 Hệ thống thật là dễ dùng hơn

 Dễ thỏa mãn yêu cầu người
dùng

 Các vấn ñề dễ ñược phát hiện
sớm

 Thiết kế có chất lượng cao hơn

 Nhược ñiểm

 Hệ thống thật có nhiều chức
năng hơn

 ðòi hỏi ñội ngũ phát triển
nhiều kinh nghiệm hơn.
19

 Hệ thống thật dễ bảo trì hơn

 Tiết kiệm công sức phát triển
hệ thống. 
Mô hình bản mẫu
Khuyến cáo cho việc dùng mô hình bảng mẫu

 Yêu cầu của người dùng không rõ ràng

 Cần minh họa cao về giao diện người dùng

 Người dùng phải ý thức về sự thay ñổi yêu cầu là rất khó khăn. 
Bản mẫu không làm nâng cao chất lượng hệ thống.

 Việc làm bản mẫu phải có kế hoạch và ñược kiểm soát tiến ñộ
20
Mô hình tăng trưởng
(Incremental Development model)

 Chức năng của hệ thống 
ñược xây dựng và chuyển 
giao dần dần cho người 
dùng. Bắt ñầu từ trạng thái 
hiện tại dần ñến trạng thái 
mong muốn: từng bước nhỏ.

 Mô hình tăng trưởng

 Tránh “dư thừa chức năng” 
(overfunctionality)

 Yêu cầu quá nhiều

 Quá dư thừa chức năng sẽ làm
hệ thống phức tạp và khó sử
dụng

 Người phân tích dễ dàng
21

 Tránh bị “big bang”: một thời 
gian dài chẳng có gì, ñùng một 
cái, cả một hệ thống mới. 

 Người dùng tham gia tích cực 
vào việc lập kế hoạch cho 
bước tiếp theo 
ước lượng thời gian, công
sức xây dựng một chức
năng, ñặc tính nào ñó của
phần mềm.

 Cách tiếp cận tăng trưởng
giúp tập trung vào các ñiểm
cốt lõi và các chức năng cần
thiết ñáp ứng yêu cầu thực
tiễn.
Mô hình ñịnh khung nhanh 
(Rapid Application Development: RAD)

 Là tiến trình phát triển phần mềm gia tăng, tăng dần 
từng bước với mỗi chu kỳ phát triển rất ngắn (60-90 
ngày)

 Xây dựng dựa trên hướng thành phần với khả năng tái 
22
sử dụng

 Gồm một số nhóm, mỗi nhóm làm 1 RAD theo các 
pha: Mô hình hóa nghiệp vụ, Mô hình hóa dữ liệu, Mô 
hình hóa xử lý, Tạo ứng dụng, Kiểm thử và ñánh giá 
(Business, Data, Process, Appl. Generation, Testing)
Mô hình 
ñịnh khung 
nhanh
Business
Modeling
Data
Modeling
Team #1
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Team #2
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
Team #3
23
60 - 90 days
Process
Modeling
Application
Generation
Testing &
Turnover
Turnover
Mô hình ñịnh khung nhanh

 Cần nguồn nhân lực dồi dào ñể tạo các nhóm cho các 
chức năng chính

 Yêu cầu hai bên cam kết trong thời gian ngắn phải có 
phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên 
24
dễ làm dự án ñổ vỡ

 RAD không phải tốt cho mọi ứng dụng, nhất là với 
ứng dụng không thể module hóa hoặc ñòi hỏi tính 
năng cao
Mô hình xoắn ốc (Spiral Model)

 ðược ñề nghị bởi Boehm (1988)

 Kết hợp các hoạt ñộng phát triển với sự quản lý rủi ro ñể 
giảm ñến mức tối thiểu và kiểm soát các rủi ro

 Mô hình ñược trình bày ở dạng xoắn ốc trong ñó mỗi lần 
25
lặp ñược biểu diễn bởi một ñường vòng quanh.

 Bốn hoạt ñộng chính:

 Lập kế hoạch(xác ñịnh các mục tiêu, các lựa chọn và các ràng buộc)

 Phân tích rủi ro (phân tích các phương án và xác ñịnh/giải quyết rủi 
ro)

 Kỹ Nghệ (phát triển sản phẩm)

 ðánh giá của khách hàng(khẳng ñịnh kết quả của kỹ nghệ)
Mô hình xoắn ốc 
Risk
analysis
Risk
analysis
Risk
analysis
Evaluate alternatives, 
identify, resolve risks
Determine objectives,
alternatives, constraints
Cumulative cost
Progress through steps
26
Review
partition
Commitment
Requirements plan
Life-cycle plan
Simulations, models, benchmarmks
Implementation
Accep-
tance
test
Inte-
gration
test
Unit
test
Code
Detailed 
design
Plan next phase
Concetp of
operation
Development 
plan
Integration and 
test plan
Design validation
and verification
Requirements
validation
Software 
requirements
Risk
analysis
Prototype 1 Prototype 2
Prototype 3 Operational
prototype
Develop, verify next-level product
Mô hình xoắn ốc 

 Hướng rủi ro (risk-driven); giảm thiểu rủi ro

 Các công việc luân phiên và chịu các ràng buộc ñã hỗ trợ cho việc tái sử
dụng phần mềm hiện có

 ðánh giá mức ñộ rủi ro

 Mục tiêu quan trọng luôn là chất lượng phần mềm

 Giảm nhẹ kiểm thử và nhanh chóng sửa chữa những lỗi xảy ra
27

 Bảo trì ñơn giản chỉ là một vòng tròn trong xoắn ốc, như vậy không có
sự phân biệt giữa phát triển và bảo trì

 Dành riêng cho các phần mềm nội bộ có kích thước lớn

 Có thể chấm dứt do các ñánh giá về rủi ro, do ñó sẽ rất không
hay khi ñã ký kết các hợp ñồng, rắc rối về mặt luật pháp

 Kích thước sản phẩm ảnh hưởng ñến giá thành việc phân tích
rủi ro
Mô hình hướng ñối tượng
(object-oriented life-cycle model) 
Bảo trì
Tích hợp
ðưa vào hoạt ñộng
Phát triển thêm
28
Mô hình vòi phun nước
Thiết kế HðT
Phân tích hướng ñối tượng
Xác ñịnh yêu cầu
Cài ñặt
Mô hình hướng ñối tượng
(object-oriented life-cycle model) 

 ðặc tính quan trọng nhất là lặp:

 giữa các giai ñoạn

 một phần trong giai ñoạn 

 Mô hình vòi phun nước thể hiện các giai ñoạn gối 
lên nhau
29

 Giảm bớt nhân lực cho công tác bảo trì 
RUP – Rational Unified Process

 Bổ sung cho UML

 Cách tiếp cận lặp cho các hệ thống hướng ñối tượng, bao 
gồm các use case ñể mô hình hóa các yêu cầu

 Các giai ñoạn của RUP
30

 Bắt ñầu: thiết lập phạm vi, giới hạn, các use case quan 
trọng, các kiến trúc ứng viên, các dự ñoán về chi phí và 
kế hoạch làm việc

 Sửa soạn: cơ sở của kiến trúc, thiết lập sự hỗ trợ công cụ

 Xây dựng: sản xuất tiến trình, một hay nhiều sự phát hành

 Chuyển tiếp: phát hành ra cộng ñồng người dùng, thường 
là một số phát hành
RUP
31
So sánh các mô hình
Mô hình ðiểm mạnh ðiểm yếu
Mô hình xây dựng và hiệu 
chỉnh 
Tốt ñối với các chương trình ngắn không
yêu cầu về bảo trì
Không ñáp ứng ñược các chương 
trình tương ñối lớn trở ñi 
Mô hình thác nước Tiếp cận có kỷ luật
Hướng tài liệu 
Sản phẩm chuyển giao có thể 
không theo những gì khách 
hàng cần 
Mô hình ñịnh khung 
nhanh
ðảm bảo sản phẩm ñược chuyển giao có 
ñược những gì khách hàng cần 
Xem nhẹ tài liệu, khó bảo trì
32
Mô hình xoắn ốc Kết hợp nhiều ñặc ñiểm của tất cả các mô 
hình phía trên 
Chỉ có thể sử dụng cho các sản 
phẩm có kích thước lớn hay 
cho các tổ chức 
Các nhà phát triển phải có khả năng 
phân tích rủi ro và giải quyết 
rủi ro 
Các mô hình hướng ñối 
tượng 
Hỗ trợ việc lặp lại bên trong các giai ñoạn, 
song song hóa giữa các giai ñoạn 
Có thể suy thoái thành CABTAB 
(thuật ngữ về sự thiếu kỷ luật 
trong công việc: trình tự thực 
hiện các công việc lung tung, 
bừa bãi)
So sánh giữa các mô hình tiến trình phần mềm
Bài tập

 Tìm hiểu về các phương pháp ước lượng phần 
mềm.
33