Bài giảng Công nghệ phần mềm - Phần I: Giới thiệu chung về công nghệ phần mềm

9/6/2011
1
PHẦN I: GIỚI THIỆU CHUNG
VỀ CÔNG NGHỆ PHẦN MỀM
I. Bản chất phần mềm
1. Định nghĩa chung về phần mềm
2. Kiến trúc phần mềm
3. Các khái niệm
4. Đặc tính chung của phần mềm
5. Thế nào là phần mềm tốt ?
6. Các ứng dụng phần mềm
II. Những vấn đề trong phát triển phần mềm
III. Quy trình phát triển phần mềm
1
1. Định nghĩa chung về phần mềm
• Phần mềm (Software - SW) như một khái niệm
đối nghĩa với phần cứng (Hardware - HW), tuy
nhiên, đây là 2 khái niệm tương đối
• Từ xưa, SW như thứ được cho không hoặc bán
kèm theo máy (HW)
• Dần dần, giá thành SW ngày càng cao và nay cao
hơn HW
2
9/6/2011
2
Các đặc tính của SW và HW
Hardware
• Vật “cứng”
• Kim loại
• Vật chất
• Hữu hình
• Sản xuất công nghiệp
bởi máy móc là chính
• Định lượng là chính
• Hỏng hóc, hao mòn
Software
• Vật “mềm”
• Kỹ thuật sử dụng
• Trừu tượng
• Vô hình
• Sản xuất bởi con 
người là chính
• Định tính là chính
• Không hao mòn
3
Định nghĩa 1
• Phần mềm là
– Các lệnh (chương trình máy tính) khi được thực hiện thì
cung cấp những chức năng và kết quả mong muốn
– Các cấu trúc dữ liệu làm cho chương trình thao tác thông
tin thích hợp
– Các tư liệu mô tả thao tác và cách sử dụng chương trình
4
9/6/2011
3
Định nghĩa 2
• Trong một hệ thống máy tính, nếu trừ bỏ đi các
thiết bị và các loại phụ kiện thì phần còn lại chính
là phần mềm (SW)
• Nghĩa hẹp: SW là dịch vụ chương trình để tăng
khả năng xử lý của phần cứng của máy tính (như
hệ điều hành - OS)
• Nghĩa rộng: SW là tất cả các kỹ thuật ứng dụng
để thực hiện những dịch vụ chức năng cho mục
đích nào đó bằng phần cứng
5
SW theo nghĩa rộng
• Không chỉ SW cơ bản và SW ứng dụng
• Phải gồm cả khả năng, kinh nghiệm thực tiễn và 
kỹ năng của kỹ sư (người chế ra phần mềm): 
Know-how of Software Engineer
• Là tất cả các kỹ thuật làm cho sử dụng phần 
cứng máy tính đạt hiệu quả cao 
6
9/6/2011
4
Phần mềm là gì ?
7
Nhóm các
Kỹ thuật,
Phương pháp
luận
Nhóm các
chương trình
Nhóm các
tư liệu
Kinh nghiệm kỹ sư, 
know-how
• Các khái niệm và trình tự
cụ thể hóa một hệ thống
• Các phương pháp tiếp cận
giải quyết vấn đề
• Các trình tự thiết kế và
phát triển được chuẩn hóa
• Các phương pháp đặc tả
yêu cầu, thiết kế hệ
thống, thiết kế chương
trình, kiểm thử, toàn bộ
quy trình quản lý phát
triển phần mềm
Phần mềm là gì ?
8
Nhóm các
Kỹ thuật,
Phương pháp
luận
Nhóm các
chương trình
Nhóm các
tư liệu
Kinh nghiệm kỹ sư, 
know-how
• Là phần giao diện với
phần cứng, tạo thành từ
các nhóm lệnh chỉ thị cho
máy tính biết trình tự thao
tác xử lý dữ liệu
• Phần mềm cơ bản: với
chức năng cung cấp môi
trường thao tác dễ dàng
cho người sử dụng nhằm
tăng hiệu năng xử lý của
phần cứng (ví dụ như OS 
là chương trình hệ thống) 
• Phần mềm ứng dụng: 
dùng để xử lý nghiệp vụ
thích hợp nào đó (quản lý, 
kế toán, . . .), phần mềm
đóng gói, phần mềm của
người dùng, . . .
9/6/2011
5
Phần mềm là gì ?
9
Nhóm các
Kỹ thuật,
Phương pháp
luận
Nhóm các
chương trình
Nhóm các
tư liệu
Kinh nghiệm kỹ sư, 
know-how
• Những tư liệu hữu ích, có
giá trị cao và rất cần thiết
để phát triển, vận hành và
bảo trì phần mềm
• Để chế ra phần mềm với
độ tin cậy cao cần tạo ra
các tư liệu chất lượng cao: 
đặc tả yêu cầu, mô tả
thiết kế từng loại, điều
kiện kiểm thử, thủ tục vận
hành, hướng dẫn thao tác
Phần mềm là gì ?
10
Nhóm các
Kỹ thuật,
Phương pháp
luận
Nhóm các
chương trình
Nhóm các
tư liệu
Kinh nghiệm kỹ sư, 
know-how
• Phần mềm phụ thuộc 
nhiều vào ý tưởng (idea) 
và kỹ năng (know-how) 
của người/nhóm tác giả
• Khả năng hệ thống 
hóa trừu tượng
• Khả năng lập trình
• Kỹ năng công nghệ
• Kinh nghiệm làm việc
• Tầm bao quát
• . . .
9/6/2011
6
2. Kiến trúc phần mềm
• Phân cấp System
Subsystem Subsystem
Program Program
Module Module Subroutine
Master files
Temporary
files
Arguments Arguments
Job unit
Jobstep unit
Member unit
Common Module
Phần mềm
Nhìn từ phương diện cấu trúc
• Cấu trúc phần
mềm: 
– kiến trúc các
chức năng
mà phần
mềm đó có
– điều kiện
phân cấp các
chức năng
• Thiết kế chức
năng
– Theo chiều
đứng: càng
sâu càng
phức tạp
– Theo chiều
ngang: càng
rộng càng
nhiều chức
năng, qui mô
càng lớn
System
Subsystem Subsystem
Program Program
Module Module Subroutine
Fuction A
Function B F nction C
Fuction D
Function F
Function E
Function G Functi n H
Cấu trúc chiều ngang
(Horizontal structure)
C
ấ
u
 trú
c
 c
h
iề
u
 đ
ứ
n
g
(V
e
rtic
a
l s
tru
c
tu
re
)
9/6/2011
7
Phần mềm
Nhìn từ phương diện thủ tục
• Quan hệ thứ tự
giữa các thành
phần cấu thành
phần mềm
• Thuật toán với
những phép lặp, 
rẽ nhánh, điều
khiển luồng xử lý
(quay lui hay bỏ
qua)
• Cấu trúc lôgic
biểu thị từng chức
năng có trong
phần mềm và
trình tự thực hiện
chúng
• Thiết kế cấu trúc
trước rồi sang 
chức năng
13
System
Subsystem Subsystem
Program Program
Module Module Subroutine
Master files
Temporary
files
Arguments Arguments
Common Module
Từ phương pháp luận phần 
mềm sang kỹ thuật phần mềm
• Khi chế tác phần mềm cần nhiều
phương pháp:
– Phương pháp luận (Methodology): những
chuẩn mực cơ bản để chế tạo phần mềm
với các chỉ tiêu định tính
– Các phương pháp kỹ thuật (Techniques): 
những trình tự cụ thể để chế tạo phần mềm
và là cách tiếp cận khoa học mang tính
định lượng
14
9/6/2011
8
Từ phương pháp luận phần mềm sang 
kỹ thuật phần mềm
Môđun
Tinh chỉnh từng
bước
Trừu tượng hóa
Che giấu t.tin
Phân tích cấu trúc
Thiết kế cấu trúc
Lập trình cấu trúc
Dữ liệu trừu tượng
Hướng đối tượng
Khái niệm phần mềm
15
3.1 Tính môđun
(Modularity)
• Là khả năng phân chia phần
mềm thành các môđun ứng
với các chức năng, đồng thời
cho phép quản lý tổng thể: 
khái niệm phân chia và trộn
(partion and merge)
• Hai phương pháp phân chia
môđun theo chiều
– Theo chiều sâu
– Theo chiều rộng
• Quan hệ giữa các môđun ?
qua các đối số (arguments)
Tính độc
lập kém
dần
Điều khiển 
phức tạp
dần
SW
Phân chia chiều rộng
P
h
â
n
c
h
ia
c
h
iề
u
s
â
u
Cấu trúc rộng chiều ngang
C
ấ
u
trú
c
s
â
u
c
h
iề
u
đ
ứ
n
g
16
9/6/2011
9
3.2 Tinh chỉnh từng bước
(Step refinement)
• Cách tiếp cận từ trên xuống (top-down approach)
Ngôn ngữ
chương trình
Chi
tiết
hóa
dần
từng
bước
Thế giới bên ngoài
Đặc tả yêu cầu
Trừu tượng hóa mức cao:
Thế giới bên ngoài, 
trạng thái chưa rõ ràng
Trừu tượng hóa mức trung gian:
Xác định yêu cầu và đặc tả 
những định nghĩa yêu cầu
Trừu tượng hóa mức thấp:
Từng lệnh của chương trình được 
viết bởi ngôn ngữ thủ tục nào đó
17
Ví dụ: Trình tự giải quyết vấn đề từ mức
thiết kế chương trình đến mức lập trình
• Bài toán: từ một nhóm N số khác nhau tăng dần, 
hãy tìm số có giá trị bằng K (nhập từ ngoài vào) 
và in ra vị trí của nó
• Giải từng bước từ khái niệm đến chi tiết hóa từng
câu lệnh bởi ngôn ngữ lập trình nào đó
• Chọn giải thuật tìm kiếm nhị phân (pp nhị phân)
18
9/6/2011
10
Cụ thể hóa thủ tục qua các chức năng
19
Bài toán đã cho Nhập giá trị K
Nhận giá trị nhóm N số
Tìm kiếm giá trị (pp nhị phân)
In ra vị trí (nếu có)
Cụ thể hóa bước tiếp theo
20
Tìm kiếm giá trị
(pp nhị phân)
Xác lập phạm vi mảng số
Lặp lại xử lý tìm kiếm giá trị K trong
phạm vi tìm kiếm
Tìm vị trí giữa phân đôi mảng
So sánh K với giá trị giữa
Đặt lại phạm vi tìm kiếm
Lặp lại tìm kiếm K
trong phạm vi tìmkiếm
9/6/2011
11
Mức mô tả chương trình (bằng PDL)
BắtĐầu
Đọc K
Nhận giá trị cho mảng 1 chiều A(I), (I =1, 2, . . . ,.N)
MIN = 1
MAX = N
DO WHILE (Có giá trị bằng K không, cho đến khi MIN > MAX)
Lấy MID = (MIN + MAX) / 2
IF A(MID) > K THEN
MAX = MID - 1
ELSE
IF A(MID) < K THEN
MIN = MID + 1
ELSE 
In giá trị MID
ENDIF
ENDIF
ENDDO
KếtThúc 21
Câu hỏi
Làm thế nào để định
nghĩa cấu trúc của một
hệ thống được thiết kế
dựa trên các module?
Đâu là các đặc tính cần
có của cấu trúc này? 
System
M2
M1
Mn
Mn-1
9/6/2011
12
3.3. Che giấu thông tin 
(Information hiding) [Parnas72]
• Các môđun nên được đặc trưng bởi những quyết
định thiết kế (design decision) sao cho mỗi
môđun đều là bí mật đối với các môđun khác
• Rất hữu ích cho kiểm thử và bảo trì phần mềm
23
3.3. Che giấu thông tin 
(Information hiding) [Parnas72]
Cố định tất cả các quyết
định thiết kế (design 
decision) có khả năng bị
thay đổi
Gán mỗi quyết định thiết
kế vào một module mới; 
lúc này quyết định thiết kế
sẽ là phần bí mật của
module (module secret)
Thiết kế giao diện của
module (module 
interface), giao diện này
sẽ không thay đổi khi
phần bí mật của module 
thay đổi
System
design 
decision
design 
decision
design 
decision
design 
decision
design 
decision
design 
decision
design 
decision
design 
decisionM1
Mn
Mn-1
M2
9/6/2011
13
Giao
diện
Module
Các tài nguyên cần xuất ra: 
kiểu dữ liệu, biến, thuộc tính, 
hàm, sự kiện, ngoại lệ, v.v..
Người
dùng
3.3. Che giấu thông tin 
(Information hiding) [Parnas72]
Secret
Cài đặt các tài
nguyên cần xuất ra
interface Bicycle { 
void changeCadence (int newValue); 
void changeGear(int newValue); 
void speedUp(int increment); 
void applyBrakes(int decrement); 
}
class Bike implements Bicycle {
}
class Motor-Bike implements Bicycle {
}
3.4. Trừu tượng hóa
(Abstraction)
• Cho phép tập trung xem xét vấn đề ở mức tổng
quát, gạt đi những chi tiết mức thấp ít liên quan
• 3 mức trừu tượng
– Trừu tượng thủ tục: dãy các chỉ thị với chức năng đặc
thù và giới hạn nào đó
– Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dữ
liệu nào đó
– Trừu tượng điều khiển: Cơ chế điều khiển chương trình
không cần đặc tả những chi tiết bên trong
• Ví dụ: Mở cửa. Thủ tục: Mở gồm . . .; Dữ liệu: 
Cửa là . . .
26
9/6/2011
14
• Là hàng hóa vô hình, không nhìn thấy 
được
• Chất lượng phần mềm: không mòn đi 
mà có xu hướng tốt lên sau mỗi lần có 
lỗi (error/bug) được phát hiện và sửa
• Phần mềm vốn chứa lỗi tiềm tàng, 
theo quy mô càng lớn thì khả năng 
chứa lỗi càng cao
• Lỗi phần mềm dễ được phát hiện bởi 
người ngoài
27
4. Đặc tính chung của phần mềm
• Chức năng của phần mềm thường biến hóa, thay 
đổi theo thời gian (theo nơi sử dụng)
• Hiệu ứng làn sóng trong thay đổi phần mềm
• Phần mềm vốn chứa ý tưởng và sáng tạo của tác 
giả/nhóm làm ra nó
• Cần khả năng “tư duy nhị phân” trong xây dựng, 
phát triển phần mềm
• Có thể sao chép rất đơn giản
28
9/6/2011
15
5. Thế nào là phần mềm tốt ?
29
Hiệu suất xử lý
Các chỉ tiêu cơ bản
Tính dễ hiểu
Thời gian
(Phần cứng phát triển)
Yếu
tố
khái
niệm
phần
mềm
tốt
Đặc
trưng
gần
đây
5.1. Các chỉ tiêu cơ bản
• Phản ánh đúng yêu cầu người dùng 
(tính hiệu quả - effectiveness)
• Chứa ít lỗi tiềm tàng
• Giá thành không vượt quá giá ước 
lượng ban đầu
• Dễ vận hành, sử dụng
• Tính an toàn và độ tin cậy cao
30
9/6/2011
16
5.2. Hiệu suất xử lý cao
• Hiệu suất thời gian tốt (efficiency): 
– Độ phức tạp tính toán thấp (Time complexity)
– Thời gian quay vòng ngắn (Turn Around Time: TAT)
– Thời gian hồi đáp nhanh (Response time)
• Sử dụng tài nguyên hữu hiệu: CPU, RAM, HDD, 
Internet resources, . . . 
31
5.3. Dễ hiểu
• Kiến trúc và cấu trúc thiết kế dễ hiểu
• Dễ kiểm tra, kiểm thử, kiểm chứng
• Dễ bảo trì
• Có tài liệu (mô tả yêu cầu, điều kiện kiểm thử, 
vận hành, bảo trì, FAQ, . . .) với chất lượng cao
Tính dễ hiểu: chỉ tiêu ngày càng quan trọng
32
9/6/2011
17
Ví dụ cụ thể ???
• Phần mềm hệ thống (System SW)
• Phần mềm thời gian thực (Real-time SW)
• Phần mềm nghiệp vụ (Business SW)
• Phần mềm tính toán KH&KT (Eng.&Scie. 
SW)
• Phần mềm nhúng (Embedded SW)
• Phần mềm máy cá nhân (Personal 
computer SW)
• Phần mềm trên Web (Web-based SW)
• Phần mềm trí tuệ nhân tạo (AI SW)
33
Bài tập về nhà: 
Phân biệt các khái niệm sau
• Hệ thống, phần mềm, ứng dụng
• Lập trình, phát triển phần mềm
• Lập trình viên và kỹ sư phần mềm
34
9/6/2011
18
PHẦN I: GIỚI THIỆU CHUNG
VỀ CÔNG NGHỆ PHẦN MỀM
I. Bản chất phần mềm
II. Những vấn đề trong phát triển phần
mềm
1. Khủng hoảng phần mềm là gì ?
2. Những khó khăn trong sản xuất phần 
mềm
III. Quy trình phát triển phần mềm (CNPM) 
35
1. Khủng hoảng phần mềm
(Software crisis)
• Là sự day dứt kinh niên (kéo dài theo thời gian hoặc
thường tái diễn, liên tục không kết thúc) gặp phải và
tạo bước ngoặt trong phát triển phần mềm máy tính, 
như:
– Phải làm thế nào với việc giảm chất lượng vì những lỗi tiềm
tàng có trong phần mềm ?
– Phải xử lý ra sao khi bảo dưỡng phần mềm đã có ?
– Phải giải quyết thế nào khi thiếu kỹ thuật viên phần mềm?
– Phải chế tác phần mềm ra sao khi có yêu cầu phát triển
theo qui cách mới xuất hiện ? 
– Phải xử lý ra sao khi sự cố phần mềm gây ra những vấn đề
xã hội ?
36
9/6/2011
19
Một số yếu tố
• Phần mềm càng lớn sẽ kéo theo phức tạp hóa và 
tăng chi phí phát triển
• Đổi vai trò giá thành SW vs. HW 
• Công sức cho bảo trì càng tăng thì chi phí cho 
Backlog càng lớn 
• Nhân lực chưa đáp ứng được nhu cầu phần mềm
• Những phiền hà của phần mềm gây ra những vấn 
đề xã hội
37
2. Những khó khăn trong sản xuất 
phần mềm
• Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người
dùng (khách hàng)
 Sau khi bàn giao sản phẩm dễ phát sinh những trục trặc
(troubles)
• Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian
dài
 Khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp
thời trong thời gian đó
• Phương pháp luận thiết kế không nhất quán
 Thiết kế theo cách riêng (của công ty, nhóm), thì sẽ dẫn đến
suy giảm chất lượng phần mềm (do phụ thuộc quá nhiều vào
con người) 
• Không có chuẩn về việc tạo tư liệu quy trình sản xuất phần mềm
 Đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm
38
9/6/2011
20
2. Những khó khăn trong sản xuất 
phần mềm
• Không kiểm thử tính đúng đắn của phần mềm ở từng giai
đoạn mà chỉ kiểm ở giai đoạn cuối và phát hiện ra lỗi
 thường bàn giao sản phẩm không đúng hạn
• Coi trọng việc lập trình hơn khâu thiết kế
 giảm chất lượng phần mềm
• Coi thường việc tái sử dụng phần mềm (software reuse)
 giảm năng suất lao động
• Phần lớn các thao tác trong quy trình phát triển phần mềm
do con người thực hiện
 giảm năng suất lao động
• Không chứng minh được tính đúng đắn của phần mềm
 giảm độ tin cậy của phần mềm
39
Những vấn đề trong sản xuất phần 
mềm (tiếp)
• Chuẩn về một phần mềm tốt không thể đo được một cách định lượng
 Không thể đánh giá được một hệ thống đúng đắn hay không
• Đầu tư nhân lực lớn vào bảo trì
 giảm hiệu suất lao động của nhân viên
• Công việc bảo trì kéo dài
 giảm chất lượng của tư liệu và ảnh hưởng xấu đến những
việc khác
• Quản lý dự án lỏng lẻo
 quản lý lịch trình sản xuất phần mềm không rõ ràng
• Không có tiêu chuẩn để ước lượng nhân lực và dự toán
 làm kéo dài thời hạn và vượt kinh phí của dự án
40
9/6/2011
21
PHẦN I: GIỚI THIỆU CHUNG
VỀ CÔNG NGHỆ PHẦN MỀM
I. Bản chất phần mềm
II. Những vấn đề trong phát triển phần
mềm
III.Quy trình phát triển phần mềm
1. Sự tiến triển của các phương pháp
thiết kế phần mềm
2. Định nghĩa Công nghệ học phần mềm
 ... ết quả thực
tế thường không phản ánh đầy đủ khả
năng tiến trình của một công ty.
63
Độ thuần thục của tiến trình
phần mềm
(Software process maturity)
• Chỉ rõ một tiến trình phần mềm được
xác định, quản lý, đánh giá, điều
khiển, đạt hiệu quả một cách rõ ràng. 
• Cho biết khả năng phát triển, chỉ ra
giá trị của tiến trình phần mềm, tính
vững chắc của dự án.
64
9/6/2011
33
c. Mô hình chi tiết các thành phần
trong cấu trúc CMM.
65
Maturity
Levels
Key Process
Areas
Common
Features
Key 
Practices
Khả năng
tiến trình
Các mục tiêu
Thực thi hoặc
thể chế hoá
Cơ sỏ hạ tầng hoặc 
các hoạt động
nhận được từ
tổ chức bởi
nhận được từ
chỉ ra
đạt được
ánh xạ
mô tả
d. Mô hình 5 mức của CMM
66
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,consistent
process
Predictable
process
Continuously improving
process
Quá trình vận hành phụ thuộc vào khả năng của
từng cá nhân riêng lẻ, và thường xuyên thay đổi
do phụ thuộc vào kỹ năng, trình độ hiểu biết và
các hoạt động của từng thành viên trong dự án.
Tiến trình phần mềm mang
tính chất tuỳ tiện, lộn xộn, 
có ít tiến trình được xác định
trước, hiệu quả của công việc
mang tính riêng lẻ. 
Khó có được một môi trường
làm việc ổn định. Kế hoạch và
ngân sách, chất lượng sản
phẩm và vận hành không thể
dự đoán trước được. 
9/6/2011
34
d. Mô hình 5 mức của CMM
67
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,consistent
process
Predictable
process
Continuously improving
process
Kết quả là đưa được những hiệu quả quản lý tiến
trình của một dự án nµy vào một dự án khác. 
Điều này cho phép lặp lại (repeatable) những
thành công đối với một dự án tương tự mặc dù
có thể các dự án này cũng có những điểm khác
biệt.
Có sự cải tiến hơn, chiến
lược quản lý dự án vµ thủ
tục để thực thi chiến lược
ấy được thiết lập. Các kế
hoạch và quản lý dự án
mới được dựa trên những
kinh nghiệm của dự án cũ. 
d. Mô hình 5 mức của CMM
68
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,consistent
process
Predictable
process
Continuously improving
process
Một tiến trình được định nghĩa tốt gồm có các
tính chất như có tiêu chuẩn, đầu vào, tiêu chuẩn
và thủ tục rõ ràng để tiến hành công việc, kiểm
tra các đầu ra.
Lập được tài liệu tiến trình
tiêu chuẩn đối với việc phát
triển và bảo trì phần mềm
có tổ chức, bao gồm cả
công nghệ phần mềm, các
tiến trình quản lý, và các
tiến trình tích hợp với nhau
(nghĩa rằng đầu ra của một
tiến trình sẽ là đầu vào của
tiến trình tiếp theo ). 
9/6/2011
35
d. Mô hình 5 mức của CMM
69
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,consistent
process
Predictable
process
Continuously improving
process
Do các tiến trình ổn định và được đánh giá đúng
nên khi có các trường hợp ngoại lệ, sẽ xác định
và chỉ rõ những nguyên nhân gây ra biến đổi.
Mục tiêu là điều khiển tiến
trình. Các tiến trình phần
mềm được quản lý để vận
hành ổn định, an toàn. Có
những đánh giá phần mềm
và chất lượng, hiệu quả các
hoạt động trong tiến trình. 
d. Mô hình 5 mức của CMM
70
Repeatable
(2)
Defined
(3)
Managed
(4)
Optimizing
(5)
Initial
(1)
Disciplined
process
Standard,consistent
process
Predictable
process
Continuously improving
process
Tiếp tục cải tiến tiến trình, 
có thể xác định được
những điểm mạnh và điểm
yếu của tiến trình, có khả
năng phân tích các khiếm
khuyết, xác định các
nguyên nhân gây ra để
tránh các khiếm khuyết
này.
9/6/2011
36
18 KPA (Key Process Area)
71
LEVEL 2: Repeatable
1. SW configuration 
management
2. SW quality 
assurance
3. SW subcontract 
management
4. SW project tracking
and oversight
5. SW project 
planning
6. Requirements 
management
7. Peer reviews
8. Intergroup 
coordination
9. SW product
engineering
10. IntegratedSW
management
11. Training program
12. Organization
process definition
13. Organization 
process focus 
LEVEL 3: Defined 
14. 
SW quality
Management
15. 
Quantitative
process
management
LEVEL 4: Managed
LEVEL 5: Optimizing
16.
Process
change
management
17. 
Technology
change
management
18.
Defect
prevention
Khả năng nhìn nhận tại mỗi mức thuần
thục
72
9/6/2011
37
Khả năng tiến trình và dự đoán theo
các mức của CMM
• Khi mức độ thuần thục tăng, sự sai khác giữa kết 
quả đạt được và kết quả dự tính giảm xuống. 
• Khi mức độ thuần thục tăng, độ biến động của 
kết quả thực tế so với kết quả đề ra giảm xuống. 
• Khi mức độ thuần thục tăng thì các kết quả sẽ 
được cải thiện. Đó là, chi phí giảm, thời gian phát 
triển ngắn hơn, chất lượng và năng suất tăng. 
73
e. Cách thức sử dụng mô hình CMM
• Định giá tiến trình phần mềm (Software process 
assessments ) xác định trạng thái của tiến trình 
phần mềm hiện tại của tổ chức, xác định mức độ 
ưu tiên đối với các vấn đề có liên quan tới tiến 
trình phần mềm khi xử lý chúng và xây dựng hệ 
thống hỗ trợ phát triển tiến trình phần mềm.
• Đánh giá khả năng phần mềm (Software 
capability evaluations) xác định các nhà thầu có 
đủ tư cách triển khai một dự án phần mềm hoặc 
quản lý hiện trạng của một hệ thống phần mềm 
đã có sẵn.
74
9/6/2011
38
Những điểm chung của 2 phương thức
sử dụng CMM
75
4.2. Mô hình tuyến tính
• Công nghệ học Hệ thống / Thông tin và mô hình
hóa (System / Information engineering and 
modeling): thiết lập các yêu cầu, ánh xạ một số
tập con các yêu cầu sang phần mềm trong quá
trình tương tác giữa phần cứng, người và CSDL
Công nghệ học
Hệ thống / Thông tin
76
Phân tích Thiết kế Lập trình Kiểm thử
9/6/2011
39
4.2. Mô hình tuyến tính
77
Phân tích Thiết kế Lập trình Kiểm thử
Công nghệ học
Hệ thống / Thông tin
Tạo mã / lập trình (Code generation / 
programming): Chuyển thiết kế thành
chương trình máy tính bởi ngôn ngữ nào
đó. Nếu thiết kế đã được chi tiết hóa thì
lập trình có thể chỉ thuần túy cơ học
Kiểm thử (Testing): Kiểm tra
các chương trình và môđun cả
về lôgic bên trong và chức năng
bên ngoài, nhằm phát hiện ra
lỗi và đảm bảo với đầu vào xác
định thì cho kết quả mong
muốn
4.2. Mô hình tuyến tính
• Hỗ trợ / Bảo trì (Support / Maintenance): Đáp
ứng những thay đổi, nâng cấp phần mềm đã phát
triển do sự thay đổi của môi trường, nhu cầu
78
Phân tích Thiết kế Lập trình Kiểm thử
Công nghệ học
Hệ thống / Thông tin
9/6/2011
40
Điểm yếu của Mô hình tuyến tính
• Thực tế các dự án ít khi tuân theo dòng tuần tự 
của mô hình, mà thường có lặp lại (như mô hình 
của Boehm)
• Khách hàng ít khi tuyên bố rõ ràng khi nào xong 
hết các yêu cầu
• Khách hàng phải có lòng kiên nhẫn chờ đợi thời 
gian nhất định mới có sản phẩm. Nếu phát hiện 
ra lỗi nặng thì là một thảm họa!
79
4.3. Mô hình chế thử (Prototyping 
model)
80
Nghe Khách
trình bày
Tạo / sửa
bản mẫu
Khách kiểm tra
bản mẫu
9/6/2011
41
Mô hình chế thử: Khi nào ?
• Khi mới rõ mục đích chung chung của phần mềm, 
chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc 
chưa rõ yêu cầu đầu ra
• Dùng như “Hệ sơ khai” để thu thập yêu cầu người 
dùng qua các thiết kế nhanh
• Các giải thuật, kỹ thuật dùng làm bản mẫu có thể 
chưa nhanh, chưa tốt, miễn là có mẫu để thảo 
luận gợi yêu cầu của người dùng
81
4.4. Mô hình phát triển ứng dụng nhanh
(Rapid Application Development: RAD)
• Là quy trình phát triển phần mềm gia tăng, tăng dần 
từng bước (Incrimental software development) với 
mỗi chu trình 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 (Component-
based construction) với khả năng tái sử dụng (reuse)
• Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD 
theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô 
hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá 
(Business, Data, Process, Appl. Generation, Test)
82
9/6/2011
42
Mô hình phát triển ứng dụng nhanh
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
60 - 90 days
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
Business
Modeling
Data
Modeling
Process
Modeling
Application
Generation
Testing &
Turnover
Team #1
Team #2
Team #3
RAD: Business modeling
• Luồng thông tin được mô hình hóa để trả lời các 
câu hỏi: 
– Thông tin nào điều khiển xử lý nghiệp vụ ?
– Thông tin gì được sinh ra?
– Ai sinh ra nó ?
– Thông tin đi đến đâu ?
– Ai xử lý chúng ?
84
9/6/2011
43
RAD: Data and Process modeling
• Data modeling: các đối tượng dữ liệu cần để hỗ 
trợ nghiệp vụ (business). Định nghĩa các thuộc 
tính của từng đối tượng và xác lập quan hệ giữa 
các đối tượng
• Process modeling: Các đối tượng dữ liệu được 
chuyển sang luồng thông tin thực hiện chức năng 
nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, 
sửa, xóa, khôi phục) từng đối tượng dữ liệu 
85
RAD: Appl. Generation and Testing
• Application Generation: Dùng các kỹ thuật thế hệ 
4 để tạo phần mềm từ các thành phần có sẵn 
hoặc tạo ra các thành phần có thể tái dụng lại 
sau này. Dùng các công cụ tự động để xây dựng 
phần mềm
• Testing and Turnover: Kiểm thử các thành phần 
mới và kiểm chứng mọi giao diện (các thành 
phần cũ đã được kiểm thử và dùng lại)
86
9/6/2011
44
RAD: Hạn chế ?
• 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 giao kèo 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 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ể môđun hóa hoặc đòi hỏi 
tính năng cao
• Mạo hiểm kỹ thuật cao thì không nên dùng RAD
87
Mở đầu
• Phần lớn các hệ phần mềm phức tạp đều
tiến hóa theo thời gian: môi trường thay
đổi, yêu cầu phát sinh thêm, hoàn thiện
thêm chức năng, tính năng
• Các mô hình tiến hóa (evolutionary 
models) có tính lặp lại. Kỹ sư phần mềm
tạo ra các phiên bản (versions) ngày càng
hoàn thiện hơn, phức tạp hơn
• Các mô hình tiêu biểu: 
– Incremental
– Spiral
– WINWIN spiral
– Concurrent development model
88
9/6/2011
45
Mô hình gia tăng
(The incremental model)
• Kết hợp mô hình tuần tự và ý tưởng lặp lại của 
chế bản mẫu
• Sản phẩm lõi với những yêu cầu cơ bản nhất của 
hệ thống được phát triển
• Các chức năng với những yêu cầu khác được phát 
triển thêm sau (gia tăng)
• Lặp lại quy trình để hoàn thiện dần
89
Mô hình gia tăng
90
Phân tích Thiết kế Lập trình Kiểm thử
System/info.
Engineering
Calendar time
Gia tăng 1
Gia tăng 2
Gia tăng 3
Gia tăng 4
Xuất xưởng 2
Xuất xưởng 1
Xuất xưởng 3
XX 4
Phân tích Thiết kế Lập trình Kiểm thử
Phân tích Thiết kế Lập trình Kiểm thử
Phân tích Thiết kế Lập trình Kiểm thử
9/6/2011
46
Mô hình xoắn ốc (spiral)
91
Giao tiếp
khách hàng
Lập kế hoạch
Phân tích rủi ro
Kỹ nghệ
Xây dựng & 
Xuất xưởng
Khách hàng
đánh giá
Bảo trì
Nâng cấp
Làm mới
Khái niệm
Mô hình xoắn ốc (tiếp)
• Giao tiếp khách hàng: giữa người phát triển và 
khách hàng để tìm hiểu yêu cầu, ý kiến
• Lập kế hoạch: Xác lập tài nguyên, thời hạn và 
những thông tin khác
• Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và 
mạo hiểm quản lý
• Kỹ nghệ: Xây dựng một hay một số biểu diễn của 
ứng dụng
92
9/6/2011
47
Mô hình xoắn ốc (tiếp)
• Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài 
đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn 
luyện, . . .)
• Đánh giá của khách hàng: Nhận các phản hồi của 
người sử dụng về biểu diễn phần mềm trong giai 
đoạn kỹ nghệ và cài đặt 
93
Mô hình xoắn ốc: Mạnh và yếu?
• Tốt cho các hệ phần mềm quy mô lớn
• Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa
• Khó thuyết phục khách hàng là phương pháp tiến 
hóa xoắn ốc có thể kiểm soát được
• Chưa được dùng rộng rãi như các mô hình tuyến 
tính hoặc chế thử
94
9/6/2011
48
Mô hình xoắn ốc WINWIN
• Nhằm thỏa hiệp giữa người phát triển và khách 
hàng, cả hai cùng “Thắng” (win-win) 
– Khách thì có phần mềm thỏa mãn yêu cầu chính
– Người phát triển thì có kinh phí thỏa đáng và thời gian 
hợp lý
• Các hoạt động chính trong xác định hệ thống:
– Xác định cổ đông (stakeholders)
– Xác định điều kiện thắng của cổ đông
– Thỏa hiệp điều kiện thắng của các bên liên quan
95
Mô hình xoắn ốc WINWIN
96
1. Xác định mức
tiếp của cổ đông
2. Xác định điều kiện
thắng của cổ đông
3a. Hòa hợp điều kiện thắng
3b. Thiết lập mục tiêu mức tiếp
và các ràng buộc, dự kiến
4. Đánh giá tiến trình và
dự kiến sản phẩm,
giải quyết rủi ro
5. Xác định mức tiếp của
sản phâm và quy trình,
kể cả phân chia nhỏ
7. Xét duyệt và đánh giá
6. Kiểm định sản phẩm
và quy trình
9/6/2011
49
Mô hình phát triển đồng thời
(concurrent development)
• Xác định mạng lưới những hoạt động đồng thời
(Network of concurrent activities)
• Các sự kiện (events) xuất hiện theo điều kiện vận
động trạng thái trong từng hoạt động
• Dùng cho mọi loại ứng dụng và cho hình ảnh khá
chính xác về trạng thái hiện trạng của dự án
• Thường dùng trong phát triển các ứng dụng
khách/chủ (client/server applications): hệ thống
và các thành phần cấu thành hệ thống được phát
triển đồng thời
97
Component-based model
• Gắn với những công nghệ hướng đối tượng
(Object-oriented technologies) qua việc
tạo các lớp (classes) có chứa cả dữ liệu và
giải thuật xử lý dữ liệu
• Có nhiều tương đồng với mô hình xoắn ốc
• Với ưu điểm tái sử dụng các thành phần
qua Thư viện / kho các lớp: tiết kiệm 70% 
thời gian, 80% giá thành, chỉ số sản xuất
26.2/16.9
• Với UML như chuẩn công nghiệp đang
triển khai
98
9/6/2011
50
Mô hình dựa thành phần
99
Giao tiếp
khách hàng
Lập kế hoạch
Phân tích rủi ro
Kỹ nghệ
Xây dựng & 
Xuất xưởng
Khách hàng
đánh giá
Xác định
thành phần
ứng viên
Tìm
thành phần
từ thư viện
Lấy
thành phần
nếu có
Xây dựng
thành phần
nếu kh.có
Đặt
thành phần
vào thư viện
Xây dựng
bước lặp thứ n
của hệ thống
4.7. Mô hình RUP
(Rational Unified Process)
• SV tự nghiên cứu
100
9/6/2011
51
4.8. Các kỹ thuật thế hệ 4
(Fourth generation techniques)
• Tập hợp các công cụ cho phép xác 
định đặc tính phần mềm ở mức cao, 
sau đó sinh tự động mã nguồn dựa 
theo đặc tả đó
• Các công cụ 4GT điển hình: ngôn ngữ 
phi thủ tục cho truy vấn CSDL; tạo 
báo cáo; xử lý dữ liệu; tương tác màn 
hình; tạo mã nguồn; khả năng đồ họa 
bậc cao; khả năng bảng tính; khả 
năng giao diện Web; vv
101
4GT: Tại sao ?
• Từ thu thập yêu cầu cho đến sản phẩm: đối thoại 
giữa khách và người phát triển là quan trọng
• Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng 
để triển khai thiết kế qua 4GL
• Mạnh: giảm thời gian phát triển và tăng năng 
suất
• Yếu: 4GT khó dùng hơn ngôn ngữ lập trình, mã 
khó tối ưu và khó bảo trì cho hệ thống lớn cần 
kỹ năng của kỹ sư phần mềm
• Tương lai: 4GT với mô hình theo thành phần
102
9/6/2011
52
5. Sản phẩm và quy trình
(Product and process)
• Quy trình yếu thì sản phẩm khó mà tốt, song 
không nên coi trọng quá mức vào quy trình hoặc
quá mức vào sản phẩm
• Sản phẩm và quy trình cần được coi trọng như
nhau
103