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

g 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