Bài giảng Kỹ nghệ phần mềm - Bài 3: Tiến trình phần mềm - Nguyễn Văn Vỵ

Bộ môn Công nghệ phần mềm- Khoa CNTT- ĐHCN
Email: vynv@coltech.vnu.vn
Kỹ nghệ phần mềm
Software Engeneering
Nguyễn Văn Vỵ
Bộ mụn Cụng nghệ phần mềm – ĐHCN 2
NguyễnVănVỵ
Nội dung 
„ Tiến trình vμ mô hình tiến trình
„ Các giai đoạn của tiến trình
„ Tiến trình vμ vấn đề liên quan
Bài 3: Tiến trỡnh phần mềm
Bộ mụn Cụng nghệ phần mềm – ĐHCN 3
NguyễnVănVỵ
TÀI LiỆU THAM KHẢO
1. Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giỏo trỡnh kỹ nghệ phần 
mềm. Nhà xuất bản Đại học Quốc gia Hà nội, 2008
2. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified 
Modeling language User Guid. Addison-Wesley, 1998.
3. M. Ould. Managing Software Quality and Business Risk, John 
Wiley and Sons, 1999.
4. Roger S.Pressman, Software Engineering, a Practitioner’s 
Approach. Fifth Edition, McGraw Hill, 2001.
5. Ian Sommerville, Software Engineering. Sixth Edition, Addison-
Wasley, 2001.
6. Nguyễn Văn Vỵ. Phõn tớch thiết kế hệ thống thụng tin hiện đại. 
Hướng cấu trỳc và hướng đối tượng, NXB Thống kờ, 2002, Hà
Nội.
Bộ mụn Cụng nghệ phần mềm – ĐHCN 4
NguyễnVănVỵ
Các loại mô hình tiến trình
ƒ Mô hình thác n−ớc 
ƒ Các mô hình phát triển tiến hóa
ƒ Các mô hình phát triển hình thức
ƒ Phát triển dựa trên sử dụng lại
ƒ Khác
5 loại mô hình tiến trình phần mềm tiêu biểu:
Mỗi loại bao gồm một số các mô hình tiến trình.
Bộ mụn Cụng nghệ phần mềm – ĐHCN 5
NguyễnVănVỵ
Mô hình vòng đời truyền thống
Mô hình thác n−ớc – waterfall model
phân tích yêu 
cầu& đặc tả
thiết kế HT & 
phẩn mềm
Mã hoá &kiểm 
thử đơn vị
kiểm thử tích 
hợp & HT
Vận hμnh 
& bảo trì
Ngiên cứu 
lập KHDA
Bộ mụn Cụng nghệ phần mềm – ĐHCN 6
NguyễnVănVỵ
Mô hình thác n−ớc: đặc điểm
■ Tách biệt giữa các pha, tiến hμnh tuần tự
 Khó tuân thủ tuần t−: dự án lớn th−ờng phải quay lại
 Khó đáp ứng yêu cầu th−ờng thay đổi của khách
■ Chậm có phiên bản thực hiện đ−ợc
 đòi hỏi khách hμng phải kiên nhẫn
 sai sót phát hiện muộn có thể lμ thảm họa
■ Đặc tả kỹ, phân công chuyên trách, h−ớng tμi liệu
 Tμi liệu quá nhiều, tốn sức ng−ời, thời gian dμi
™ Có sớm vμ đ−ợc sử dụng rộng rãi (tốt > tự nhiên)
™ Thích hợp khi yêu cầu hiểu tốt, hệ lớn & phức tạp
™ Bảo trì thuận lợi
Bộ mụn Cụng nghệ phần mềm – ĐHCN 7
NguyễnVănVỵ
Phiên bản
cuối cùng
Đặc tả Phiên bản 
khởi đầu
tl e
s ri o
Đặc tả
khái quát
Phiên bản 
trung gian
Phát triển
Thẩm định
Mô hình phát triển tiến hóa
b1. L−ợc đồ chung nhất
Bộ mụn Cụng nghệ phần mềm – ĐHCN 8
NguyễnVănVỵ
L−ợc đồ chung nhất
■ Phát triển ban đầu
ƒ Lμm việc với khách, đặc tả khái quát hệ thống (bắt 
đầu với hiểu biết có thể ch−a đầy đủ)
■ Thực hiện phát triển bằng cách lμm mẫu
ƒ Mục tiêu lμ để hiểu hệ thống. Bản mẫu ban đầu có 
thể còn sơ sμi.
■ Thẩm định phiên bản có đ−ợc, lặp lại các b−ớc 
cho đến khi có phiên bản cuối cùng
Bộ mụn Cụng nghệ phần mềm – ĐHCN 9
NguyễnVănVỵ
L−ợc đồ chung
„ Hạn chế
 Không trực quan
 Hệ thống th−ờng có cấu trúc nghèo nμn
 Đòi hỏi có kỹ năng đặc tả (ngôn ngữ lμm mẫu)
„ Khả năng ứng dụng
 Cho các hệ t−ơng tác vừa, nhỏ
 Cho những phần của hệ lớn 
 Hệ có vòng đời ngắn
Bộ mụn Cụng nghệ phần mềm – ĐHCN 10
NguyễnVănVỵ
sản phẩm
cuối cùng
lμm mịn
bản mẫu
xây dựng 
bản mẫu
thiết kế 
nhanh
đánh giá
của khách
xác yêu cầu-
thu thập tt. 
sơ bộ
Mô hình làm bản mẫu - Prototyping model
Bắt đầu
Kết thúc
Mô hình lμm bản mẫu
Bộ mụn Cụng nghệ phần mềm – ĐHCN 11
NguyễnVănVỵ
Mô hình lμm bản mẫu
Loại mẫu:
 mẫu trên giấy
 mẫu mô tả một phần chức năng
 mẫu giao diện
 mẫu h−ớng tới sản phẩm
Mức độ mẫu:
 mẫu dùng xong bỏ đi (throw-away approach) 
 mẫu dùng tiếp cho b−ớc sau (CASE chuyên dụng)
 mẫu lμ phần hệ thống vận hμnh đ−ợc (dựa trên 
thμnh phần dùng lại)
Bộ mụn Cụng nghệ phần mềm – ĐHCN 12
NguyễnVănVỵ
−u thế:
 nhanh chóng xác định đ−ợc yêu cầu, tốt
 tạo cơ sở ký kết hợp đồng
 giúp đμo tạo huấn luyện ng−ới sử dụng
Nh−ợc điểm: 
Thích hợp:
ƒ các yêu cầu ch−a rõ rμng
ƒ input/output ch−a rõ rμng
ƒ khó đánh giá tính hiệu quả thuật toán
ƒ tính cấu trúc không cao
ƒ khách hμng ít tin t−ởng
Mô hình lμm bản mẫu
Bộ mụn Cụng nghệ phần mềm – ĐHCN 13
NguyễnVănVỵ
Mô hình xoắn ốc (spiral model)
„ Cải tiến của mô hình tuần tự vμ lμm mẫu
„ Thêm phân tích rủi ro
„ Lμ quá trình lặp h−ớng mở rộng, hoμn thiện dần
 Lập kế hoạch: xác lập vấn đề, tμi nguyên, thời hạn.
 Phân tích rủi ro: xem xét mạo hiểm, tìm giải pháp
 Kỹ nghệ: phát triển một phiên bản của phần mềm 
(chọn mô hình thích hợp: lμm mẫu, thác n−ớc,..)
 Đánh giá của khách: khách đánh giá phiên bản phát 
triển; ặ lμm mịn, sửa đổi 
Bộ mụn Cụng nghệ phần mềm – ĐHCN 14
NguyễnVănVỵ
Mô hình xoắn ốc
spiral model
lập kế hoạch phân tích rủi ro
đánh giá kỹ nghệ
tập hợp yêu 
cầu ban đầu, 
lập kế 
hoạch dự án
kế hoạch 
dựa trên yêu 
cầu của 
khách 
đánh giá
của khách, 
sửa đổi, 
hoμn thiện
phân tích rủi ro, 
tim giai pháp 
bản mẫu / áp
dụng p.pháp phát
triển thích hợp
tiếp tuc hay 
không?
phân tích rủi ro,
lây ý kiến 
khách hμng
Bộ mụn Cụng nghệ phần mềm – ĐHCN 15
NguyễnVănVỵ
Mô hình xoắn ốc: đặc điểm
„ Hợp với hệ lớn có thể phân chia phần cốt lõi ặ
thứ yếu
„ Có thể kiểm soát rủi ro ở từng mức tiến hóa
„ Khó thuyết phục khách lμ kiểm soát đ−ợc sự tiến 
hóa linh hoạt (đòi hỏi năng lực quản lý, năng lực 
phân tích rủi ro -> chi phi chuyên gia lớn)
„ Ch−a đ−ợc dùng rộng rãi nh− mô hình thác n−ớc 
hoặc lμm mẫu
Bộ mụn Cụng nghệ phần mềm – ĐHCN 16
NguyễnVănVỵ
Mô hình phát triển ứng dụng nhanh
Rapid Application Development- RAD
đội 2
Tạo sinh 
ứng dụng
Mô hình 
dữ liệu
Kiểm thử
chuyển 
giao
Mô hình 
nghiệp 
vụ
Mô hình 
xử lý
đội 1
60-90 ngμy
Tạo sinh 
ứng dụng
Mô hình 
dữ liệu
Kiểm thử
chuyển giao
Mô hình 
nghiệp 
vụ
Mô hình 
xử lý
đội 3
Tạo sinh 
ứng dụng
Mô
hình dữ
liệu
Kiểm thử
chuyển 
giao
Mô hình 
nghiệp 
vụ
Mô
hình xử
lý
Bộ mụn Cụng nghệ phần mềm – ĐHCN 17
NguyễnVănVỵ
RAD - đặc điểm
„ Hợp với các hệ thống có khả năng môđun hóa cao
„ h−ớng thμnh phần, tái sử dụng
„ sử dụng công cụ tự động
„ Thời gian phát triển sản phẩm ngắn (60~90 ngμy)
„ Không phù hợp với sản phẩm:
„ khó phân chia thμnh các thμnh phần
„ đòi hỏi hiệu năng cao
Bộ mụn Cụng nghệ phần mềm – ĐHCN 18
NguyễnVănVỵ
Mô hình tăng tr−ởng (incremental model)
Phân 
tích
Thiết 
kế
M∙
hoá
Kiểm 
thử
System/information
engineering
Phân 
tích
Thiết 
kế
M∙
hoá
Kiểm 
thử
Bản tăng 2
Chuyền 
giao bản 
tăng 4
Thời gian
Bản tăng 3
Bản tăng 1
Bản tăng 4
Chuyền 
giao bản 
tăng 1
Chuyền 
giao bản 
tăng 2
Chuyền 
giao bản 
tăng 3
Phân 
tích
Thiết 
kế
M∙
hoá
Kiểm 
thử
Phân 
tích
Thiết 
kế
M∙
hoá
Kiểm 
thử
Bộ mụn Cụng nghệ phần mềm – ĐHCN 19
NguyễnVănVỵ
Mô hình tăng tr−ởng
„ Chuyển giao dần từng phần của hệ thống
ƒ Sản phẩm chia thμnh từng phần tăng theo yêu cầu 
chức năng 
ƒ Yêu cầu ng−ời dùng −u tiên theo thứ tự phần tăng
„ Cho sản phẩm dùng trong thời gian ngắn
 đáp ứng nhanh yêu cầu của khách
 chiếm lĩnh thị tr−ờng
 khác với bản mẫu
„ Công ty phát triển phải có tiềm lực cao (công 
nghệ, tμi sản phần mềm) 
Bộ mụn Cụng nghệ phần mềm – ĐHCN 20
NguyễnVănVỵ
Lập trình cực đoan (Extreme Programming-XP)
„ Cách tiếp cận dựa trên việc phát triển, chuyển 
giao dần từng phần nhỏ chức năng
„ Tạo các ca thử nghiệm tr−ớc khi lập trình
ƒ đòi hỏi phải nắm vững yêu cầu; giao diện tr−ớc khi 
bắt tay vμo mã hóa
„ Lập trình đội
ƒ tránh lỗi, nâng cao chất l−ợng
ƒ đảm bảo sự tuân theo các chuẩn XP đã đề ra
„ Viết lại khi có thể
ƒ chủ động tấn công lỗi
Bộ mụn Cụng nghệ phần mềm – ĐHCN 21
NguyễnVănVỵ
Kỹ thuật thế hệ thứ 4
Fourth generation technology - 4GT
„ Các kỹ thuật xác định đặc tr−ng phần mềm ở
mức cao:
 h−ớng mục đích (chức năng)
 tự động sinh mã ch−ơng trình theo đặc tả
„ Các công cụ/ứng dụng điển hình
 truy vấn CSDL (SQL)
 tạo báo cáo, bảng tính 
 sinh giao diện (giao diện Web)
Bộ mụn Cụng nghệ phần mềm – ĐHCN 22
NguyễnVănVỵ
4GT: đặc điểm
„ Phân tích/thiết kế vẫn lμ b−ớc quan trọng
„ 4GT chỉ trợ giúp (tự động hóa) việc sinh mã
ch−ơng trình đối với từng chức năng cụ thể
„ ứng dụng còn hạn chế; không phải mọi 
4GTcũng dễ dùng
„ Tíết kiệm công sức cho phát triển phần mềm nhỏ
„ Không hiệu quả với phần mềm lớn: mã hóa chỉ
chiếm một tỷ lệ nhỏ so với phân tích thiết kế
Bộ mụn Cụng nghệ phần mềm – ĐHCN 23
NguyễnVănVỵ
Phát triển hệ thống hình thức hóa
formal systems development
Các b−ớc của tiến trình phát triển
(đặc tả yêu cầu 1 cách hình thức bằng 
các công cụ toán học trừu t−ợng)
Xác định 
yêu cầu
Kiểm thử tích hợp 
& hệ thống
Biến đổi 
hình thức
Bán tự động tự động
Đặc tả
hình thức
Bộ mụn Cụng nghệ phần mềm – ĐHCN 24
NguyễnVănVỵ
Biến đổi hình thức
Các phép biến đổi hìmh thức
Các chứng minh tính đúng đắn của phép biến đổi
R2Đặc tả
hình thức
R3 Ch−ơng trình thực hiện đ−ợc
P2 P3 P4
T1 T2 T3 T4
R1
P1
Bộ mụn Cụng nghệ phần mềm – ĐHCN 25
NguyễnVănVỵ
Hạn chế phát triển hình thức hóa
„ Hạn chế
 Cần có kỹ năng đặc tả vμ sử dụng kỹ thuật tiên tiến
 Khó đặc tả đ−ợc mọi khía cạnh của hệ thống, chẳng 
hạn nh− giao diện
„ Khả năng ứng dụng
 Những hệ thống quan trọng cần phảI đảm bảo độ an 
toμn, bảo mật tr−ớc khi đ−a vμo sử dụng, xử lý 
nhiều, t−ơng tác hạn chế.
 ít nhμ phát triển có thể sử dụng.
Bộ mụn Cụng nghệ phần mềm – ĐHCN 26
NguyễnVănVỵ
Phát triển h−ớng sử dụng lại 
„ H−ớng sử dụng lại dựa trên nền tảng của 
phát triển hệ thống h−ớng đối t−ợng
„ ý t−ởng hướng đối tượng: 
Mô hình cấu trúc của hệ thống
 Hệ thống cấu thμnh 
từ các đối t−ợng 
 Đối t−ợng bao gói cả
dữ liệu vμ xử lý
 Liên kết với nhau 
bằng truyền thông
Bộ mụn Cụng nghệ phần mềm – ĐHCN 27
NguyễnVănVỵ
Phát triển h−ớng đối t−ợng 
„ bao gói, che dấu thông tin:
tác động cục bộ, dễ bảo trì, dễ dùng lại
Do bao gói cả dữ liệu vμ xử lý nên độc lập t−ơng đối, cho 
một chức năng xác định, che thông tin với bên ngoμi
„ tính kế thừa:
 xây dựng đ−ợc các lớp cơ sở (chung)
 khi thêm các chi tiết dùng cho tr−ờng hợp cụ thể
nâng cao khả năng dùng lại
„ liên kết tự do, yếu
mở rộng đơn giản, không hạn chế
Bộ mụn Cụng nghệ phần mềm – ĐHCN 28
NguyễnVănVỵ
Các h−ớng sử dụng lại
„ Các h−ớng sử dụng lại:
 Định h−ớng thμnh phần (component - mã nguồn)
 Định h−ớng mẫu (pattern - phân tích, thiết kế)
 Phát triển khung lμm việc (framworks: lớp ứng dụng)
„ Các giai đoạn của tiến trình
 Phân tích hệ thống thμnh các phần yêu cầu nhỏ
 Cải biên các yêu cầu h−ớng (thμnh phần, mẫu, khung)
 Thiết kế hệ thống h−ớng tới tμi sản sử dụng lại
 Phát triển vμ tích hợp
„ Quan trọng, cần kinh nghiệm, công cụ còn hạn chế
Bộ mụn Cụng nghệ phần mềm – ĐHCN 29
NguyễnVănVỵ
Tiến trình h−ớng sử dụng lại
đặc tả
yêu cầu
phát triển và
tích hợp
cải biên 
yêu cầu
thẩm định 
hệ thống
phân tích 
thành phần
thíết kế HT 
dùng lại
Tiến trình phát triển
Tham chiếu 
Sử dụng 
Khung
lμm việc
Th− viện 
thμnh phần
Th− viện 
thμnh phần Th− viện mẫu
Th− viện 
mẫu
Bộ mụn Cụng nghệ phần mềm – ĐHCN 30
NguyễnVănVỵ
Kỹ nghệ h−ớng thμnh phần
Component-based software engineering
Nội dung
 Thμnh phần lμ mô đun chức năng mã đóng
 Lắp ráp các thμnh phần đúng với yêu cầu
 Dùng lại thμnh phần độc lập với ngôn ngữ
 Thay thế thμnh phần lμ động (không cần dịch), 
không cần đ−ờng dẫn, chỉ cần định danh.
Ưu, nh−ợc
™ Nhanh, ổn định, hiệu quả
™ Cần có các thμnh phần đ−ợc mô tả, 
hiểu về nó, có cách tìm kiếm tốt
file.com
file.exe
file.exe
file.com
file.exe
file.com file.exe
file.comfile.exe
Bộ mụn Cụng nghệ phần mềm – ĐHCN 31
NguyễnVănVỵ
Phân tích thiết kế h−ớng mẫu
pattern oriented analysis & design - POAD
Nội dung
 Phân tích yêu cầu h−ớng theo mẫu
 Xem xét các mẫu đã có (từ th− viện)
 Tìm, lựa chon mẫu thích hợp cho 
phần đ−ợc phân tích 
 Chuyển thiết kế thμnh ch−ơng trình 
(tự động, bán tự động) 
Ưu, nh−ợc
™ Bắt đầu ứng dụng rộng rãi
™ Cần có khả năng phân tích tốt
™ Có hiểu biết thμnh thạo về mẫu
AbstractFigure
Draw()
Figures()
Include()
Decompose()
Add()
Remove()
AttributeFigure
Draw()
Draw()
Figures()
Include()
Decompose()
Add()
Remove()
CompositeFigure
PertFigure
Start()
notifyPostTask()
updateDuration()
late()
notifyPreTask()
updateLate()
.
Bộ mụn Cụng nghệ phần mềm – ĐHCN 32
NguyễnVănVỵ
Phát triển khung lμm việc
Framework development
Xây d−ng khung làm việc
Xác định lớp bμi toán cần giải quyết
Xây dựng khung bμi toán (dựa trên patterns)
 Lμm sẵn các tiêu bản mẫu (dùng ngay đ−ợc) 
Triển khai
™Phân tích bμi toán theo khung
™Xác định tiêu bản thích hợp
™Lắp ghép hay tìm phần thay thế
Bộ mụn Cụng nghệ phần mềm – ĐHCN 33
NguyễnVănVỵ
Phát triển khung lμm việc
Framework development
Điểm cắm
Mô hình frameworrk
Quản lý khách sạn Thanh toán
quản lý phòng
lế tân
tiền phòng
dịch vụ
Khung chính
Tiêu bản làm sẵn
Bộ mụn Cụng nghệ phần mềm – ĐHCN 34
NguyễnVănVỵ
Phát triển phần mềm mã nguồn mở
„ Công khai thiết kế, công khai mã nguồn, 
dùng chung
y chất l−ợng tăng, chuẩn hóa cao?
„ Phát triển phân tán, nhiều ng−ời tham gia
„ Xuất phát từ các mối quan tâm chung
„ Nhiều vấn đề đ−ợc giải quyết
• Lý do, lợi ích, động lực ch−a rõ
„ Ví dụ: GNU, Linux
Bộ mụn Cụng nghệ phần mềm – ĐHCN 35
NguyễnVănVỵ
Lựa chọn mô hình
„ Phụ thuộc vμo bμi toán, vμo môi tr−ờng cụ thể
„ Yêu cầu rõ rμng: Mô hình thác n−ớc thích hợp
„ Hệ phức tạp, điều khiển: H−ớng sử dụng lại
„ Khác:
 Yêu cầu ch−a rõ rμng, độ phức tạp cao
 Yêu cầu có khả năng thay đổi 
 Không chắc chắn về tính hiệu quả, tính khả thi
Sử dụng: Lμm bản mẫu, mô hình xoắn ốc
Bộ mụn Cụng nghệ phần mềm – ĐHCN 36
NguyễnVănVỵ
„ Lμ quá trình thiết lập các chức năng, dịch vụ mμ
hệ thống cần có vμ các rμng buộc lên sự phát 
triển vμ vận hμnh hệ thống
„ Tiến trình kỹ nghệ yêu cầu bao gồm:
 Nghiên cứu khả thi
 Phân tích vμ xác định yêu cầu
 Đặc tả yêu cầu
 Thẩm định yêu cầu
Các giai đoạn của tiến trình
Đặc tả yêu cầu phần mềm
Bộ mụn Cụng nghệ phần mềm – ĐHCN 37
NguyễnVănVỵ
Tiến trình kỹ nghệ yêu cầu
Báo cáo 
khả thi
Mô hình hệ
thống
Yêu cầu ng−ơi 
dùng, hệ thống
Tμi liệu yêu 
cầu
Nghiên cứu 
khả thi
Xác đinh, phân 
tích yêu cầu
đặc tả
yêu cầu
Thẩm định
yêu cầu
Bộ mụn Cụng nghệ phần mềm – ĐHCN 38
NguyễnVănVỵ
Thiết kế phần mềm
„ Chuyển yêu cầu thμnh đặc tả thμnh hệ thống nh−
nó tồn tại trong thế giới thực với các giải pháp công 
nghệ thích hợp để ng−ời lập trình có thể chuyển 
thμnh ch−ơng trình vận hμnh trên máy 
„ Chiến l−ợc thiết kế phù hợp với phân tích
„ Lμ quá trình lặp: có thể quay lại hoμn thiện phân 
tíchặ rồi lại thiết kế
„ Hai giai đoạn thiết kế: logicặthiết kế vật lý
Bộ mụn Cụng nghệ phần mềm – ĐHCN 39
NguyễnVănVỵ
Tiến trình thiết kế phần mềm
thiết kế 
kiến trúc 
Đặc tả
Yêu cầu 
đặc tả
Trừu t−ợng 
thiết kế 
Giao diện 
thiết kế 
thành phần 
thiết kế 
dữ liệu 
thiết kế 
hủ tục 
Kiến trúc 
hệ thống
Sản phẩm thiết kế
đặc tả
phần mềm
đặc tả giao 
diện
đặc tả
thành phần
đặc tả cấu 
trúc dữ liệu
đặc tả
thủ tục
Hoạt động thiết kê
Bộ mụn Cụng nghệ phần mềm – ĐHCN 40
NguyễnVănVỵ
Các ph−ơng pháp thiết kế 
„ Cách tiếp cận mang tính hệ thống, có ph−ơng pháp 
„ Tμi liệu thiết kế ở dạng một tập các mô hình đồ họa vμ
chú giải đi kèm
„ Các mô hình th−ờng gặp:
 Mô hình kiến trúc theo nhiều khung nhìn
 Mô hình luồng dữ liệu (xử lý)
 Mô hình Thực thể – mối quan hê/ MH Quan hệ (dữ liệu)
 Mô hình cấu trúc mô đun (cấu trúc)
 Các mô hình lớp đối t−ợng (kiến trúc, thực thi)
Bộ mụn Cụng nghệ phần mềm – ĐHCN 41
NguyễnVănVỵ
Lập trình vμ gỡ rối
„ Lμ chuyển thiết kế thμnh ch−ơng trình, bắt lỗi vμ sửa lỗi 
„ Lμ một hoạt động cá nhân không có một tiến trình 
chung cho mọi ng−ời
„ Ng−ời lập trình phải tiến hμnh kiểm thử để gỡ lỗi ch−ơng 
trình. Gỡ lỗi lμ hoạt động của lập trình
„ Lập trình đòi hỏi chọn ngôn ngữ thích hợp vμ có kinh 
nghiệm  phong cách lập trình tốt
„ Để đảm bảo độ tin cây, cần biết lập trình tránh lỗi, thứ
lỗi vμ ném ngoại lệ
Bộ mụn Cụng nghệ phần mềm – ĐHCN 42
NguyễnVănVỵ
Thẩm định phần mềm
„ Thẩm định vμ xác minh nhằm đảm bảo hệ thống phù
hợp với đặc tả vμ đáp ứng yêu cầu ng−ời dùng
„ Nội dung bao gồm việc thanh tra, xét duyệt vμ kiểm thử
hệ thống. Kiểm thử lμ quan trọng nhất 
„ Có nhiều mức: 
• Xác minh: kiểm thử đợn vị, tích hợp, hệ thống
• Thẩm định: lμm mẫu yêu cầu, kiểm thử chấp nhận
„ Có nhiều ph−ơng pháp kiểm thử. Mỗi ph−ơng pháp áp 
dụng ở mức xác định, vμ sử dụng kỹ thuật nhất định
„ Mục tiêu kiểm thử lμ tìm ra lỗi với chi phí ít nhất có thể
Bộ mụn Cụng nghệ phần mềm – ĐHCN 43
NguyễnVănVỵ
Tiến trình kiểm thử
Kiểm thử
đơn vị
Kiểm thử
mô đun
Kiểm thử
Hệ con
Kiểm thử
hệ thống Kiểm thử
Chấp nhận
lập trình viên
chuyên viên 
ng−ời dùng
Bộ mụn Cụng nghệ phần mềm – ĐHCN 44
NguyễnVănVỵ
Tiến hoá phần mềm
„ Phần mềm phải mềm dẻo vì nó cần phải thay đổi.
„ Môi tr−ờng nghiệp vụ vμ kỹ thuật luôn thay đổi: 
Phần mềm cần thay đổi để phù hợp với chúng ặ
tiến hóa lμ tất yếu
„ Phân định phát triển vμ tiến hoá lμ t−ơng đối: giữa 
chúng có quan hệ chặt chẽ với nhau. Phát triển lμ
lμm mới, tiến hóa trên cơ sở hệ đã có.
Bộ mụn Cụng nghệ phần mềm – ĐHCN 45
NguyễnVănVỵ
Tiến trình tiến hoá
Hệ thống 
mới
Xác định yêu 
cầu hệ thống
Hệ thống 
hiện tại
đánh giá hệ
thống hiện tại
đề xuất thay 
đổi hệ thống
Cải biên hệ
thống
Bộ mụn Cụng nghệ phần mềm – ĐHCN 46
NguyễnVănVỵ
Trợ giúp tự động hoá phát triển
„ Computer-aided software engineering:CASE lμ các 
phần mềm trợ giúp phát triển vμ tiến hoá hệ thống
„ Các công cụ th−ờng gặp:
 Bộ soạn thảo đồ thị: để phát triển mô hình hệ thống
 Từ điển dữ liệu: để quản lý các thực thể thiết kế
 Bộ xây dựng giao diện: để thiết kế giao diện 
 Bộ gỡ rối: trợ giúp tìm lỗi trong ch−ơng trình
 Bộ chuyển đổi tự động: tạo sinh các phiên bản mới từ 
thiết kế / hay ch−ơng trình
Bộ mụn Cụng nghệ phần mềm – ĐHCN 47
NguyễnVănVỵ
Công nghệ CASE (CASE technology)
„ CASE góp phần đáng kể hoμn thiện tiến trình phần 
mềm cả về trình tự, tiến độ vμ chất l−ợng: tự động 
hóa một phần hoạt động mô hình hóa vμ quản lý
„ Những hoạt động không thể tự động hóa:
 Sự suy nghĩ sáng tạo trong SE 
 Lựa chọn giải pháp công nghệ
 Giao tiếp khi lμm việc nhóm
 Thực hiện việc quản lý
Bộ mụn Cụng nghệ phần mềm – ĐHCN 48
NguyễnVănVỵ
Công nghệ CASSE
Các công cụ đơn 
bộ sửa 
lỗi
Môi tr−ờng 
tiến trình
Bàn thợ
Lập trình gỡ
lỗi
Phân tích vμ
thiết kế
Bộ soạn 
thảo
Môi tr−ờng
Môi tr−ờng 
tích hợp
Kiểm thử các 
loại
Bμn thợ đơn 
ph−ơng pháp
Ch.trình 
dịch
Bμn thợ đa 
ph−ơng pháp
Bμn thợ ngôn 
ngữ cụ thể
Công nghệ CASE 
Bμn thợ mục 
tiêu chung
Bộ mụn Cụng nghệ phần mềm – ĐHCN 49
NguyễnVănVỵ
Phân loại CASE
„ Phân loại CASE giúp hiểu vμ sử dụng chúng trong 
phát triển
„ Có thể phân loại CASE theo:
 H−ớng chức năng: Công cụ cho các chức năng cụ 
thể: soạn thảo, lập kế hoạch, lμm mẫu,..
 H−ớng tiến trình: Công cụ cho hoạt động của tiến 
trình đ−ợc trợ giúp: mô hình nghiệp vụ, E-R
 H−ớng tích hợp: Công cụ trợ giúp tổ chức việc tích 
hợp các đơn vị các mức trong hệ thống
 Dựa trên loại hoạt động: Đặc tả, thiết kế, triển khai, 
thẩm định vμ xác minh
Bộ mụn Cụng nghệ phần mềm – ĐHCN 50
NguyễnVănVỵ
CASE tích hợp
„ Các công cụ đơn (Tools) : trợ giúp những 
nhiệm vụ riêng rẽ của tiến trình: kiếm tra sự
nhất quán, soạn thảo, tạo mô hình
„ Bàn thợ (Workbenches): trợ giúp 1 pha của 
tiến trình phát triển, nh− đặc tả, thiết kê,..
„ Môi tr−ờng phát triển (Environments): trợ
giúp toμn bộ hay một phần của toμn tiến trình 
phần mềm (có thể bao gồm một số bμn thợ)
Bộ mụn Cụng nghệ phần mềm – ĐHCN 51
NguyễnVănVỵ
Các vấn đề liên quan
„ Xác định yêu cầu vμ thiết kế có vai trò quyết định đến 
chất l−ợng phần mềm, chiếm phần lớn công sức so 
với phát triển
„ Khi chuyển tiếp giữa các pha phát triển phải thẩm 
định tốt để đảm bảo lỗi không ảnh h−ởng đến pha sau
„ Tμi liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế 
tiếp mμ còn dùng để đảm bảo chất l−ợng của phần 
mềm vμ bảo trì
„ Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tμi 
liệu nhằm đảm bảo chất l−ợng phần mềm
Bộ mụn Cụng nghệ phần mềm – ĐHCN 52
NguyễnVănVỵ
Tính khả thi của tiến trình phát triển 
Phần tử logic, khó kiểm soát
 tạo ra các tμi liệu
 xét duyệt tμi liệu mỗi b−ớc 
nghiên cứu khả thi; đặc tả yêu cầu;
đặc tả thiết kế
Ví dụ tμi liệu:
So sánh:  vòng đời cổ điển khả thi cao
 lμm bản mẫu kém
 4GT ??
Bộ mụn Cụng nghệ phần mềm – ĐHCN 53
NguyễnVănVỵ
Vấn đề:
„ Tạo ra chi phí phụ của phát triển
(ng−ời lập trình không thích viết tμi liệu)
„ Sử dụng các giải pháp cục bộ để tránh sửa 
đổi tμi liệu
„ Sử dụng các mẫu có sẵn
„ Sử dụng CASE trợ giúp lμm tμi liệu theo 
chuẩn
Lμm tμi liệu phần mềm
Bộ mụn Cụng nghệ phần mềm – ĐHCN 54
NguyễnVănVỵ
Sản phẩm (tμi liệu) của dự án
Mã máy, dữ liệu, tμi liệu
Mã nguồn, chú thích
Thiết kế
Yêu cầu
Phi hình thức, trừu t−ợng
Hình thức hoá,
cụ thể
Bộ mụn Cụng nghệ phần mềm – ĐHCN 55
NguyễnVănVỵ
Giảm kích cỡ, chi phí phần mềm
„ Phần mềm ngμy cμng lớn, phức tạp
„ Tổ chức lμm việc theo nhóm, tiến hμnh song song 
„ Cần phân rã chức năng; giảm kích cỡ (mã nguồn), 
tăng năng suất:
 tái sử dụng: th− viện th−ơng mại,...
 tự sinh mã: công cụ tạo giao diện,...
 h−ớng đối t−ợng: kế thừa, bảo trì
 ngôn ngữ bậc cao: năng lực biểu diễn cao
Bộ mụn Cụng nghệ phần mềm – ĐHCN 56
NguyễnVănVỵ
Quan hệ tiến trình vμ sản phẩm
Tiến trình vμ sản phẩm lμ hai mặt của phát triển:
„ Tiến trình tốt đảm bảo rμng buộc về sản phẩm 
„ Sản phẩm tốt lμ sự tổng hoμ của nhiều yếu tố:
 Tiến trình thích hợp
 Đội ngũ chuyên môn tốt
 Công cụ trợ giúp mạnh
 Năng lực quản lý tiến trinh của tổ chức cao (CMM)
5 mức CMM (Capability Maturity Model):
1. Tùy biến 3. Đ−ợc xác định 
2. Lặp lại đ−ợc 4. Đ−ợc quản lý 5. Tối −u hóa
Bộ mụn Cụng nghệ phần mềm – ĐHCN 57
NguyễnVănVỵ
Câu hỏi ôn tập
1. Có mấy loại mô hình tiến trình? Lμ loại nμo?
2. Trình bμy nội dung của các mô hình: thác n−ớc, lμm mẫu, 
xoáy ốc, tiến hoá, tăng tr−ởng, ứng dụng nhanh, hình thức 
hoá, đối t−ợng, mô hình sử dụng lại, mô hình mã nguồn mở, 
mô hình thế hệ thứ 4 theo các nội dung sau:
ƒ Nội dung? đặc tr−ng?
ƒ −u, nh−ợc điểm? 
ƒ cần yêu cầu gì? 
ƒ thích hợp khi nμo?
3. Mô tả tiến trình kỹ nghệ yêu cầu?
4. Mô tả tíên trình thiết kế phần mềm? Nêu các mô hình thiết kế 
th−ờng sử dụng?
Bộ mụn Cụng nghệ phần mềm – ĐHCN 58
NguyễnVănVỵ
Câu hỏi ôn tập (t)
5. Định nghĩa thẩm định phần mềm? Thẩm định vμ xác minh 
gồm những hoạt động gì?
6. Có những loại kiểm thử nμo? Mô tả tiến trình kiểm thử?
7. Tiến hoá phần mềm lμ gì? Lý do?
8. Mô tả tiến trình tiến hoá hệ thống?
9. CASE lμ gì? Các cách phân loại CASE?
10. CASE tích hợp gồm những loại nμo? vẽ sơ đồ cấu trúc các 
loại CASE?
11. Lμm thế nμo để đảm bảo khả thi của mô hình phát triển? So 
sánh sự khả thi giữa các mô hình, giải thích vì sao?
12. Lμm thế nμo để có thể giảm kích cỡ, chi phí của mô hình? 
Những mô hình nμo, ngôn ngữ nμo có −u thế về mặt nμy? 
Bộ mụn Cụng nghệ phần mềm – ĐHCN 59
NguyễnVănVỵ
Câu hỏi và thảo luận