Chương 2 trình bày các mô hình phát triển phần mềm, bao gồm vòng đời phát triển, hoạt động và các kiểu mô hình như mô hình thác nước, mô hình v, và mô hình bản mẫu. Vòng đời phần mềm được chia thành nhiều pha, từ xác định yêu cầu đến bảo trì, phản ánh sự phức tạp của phát triển phần mềm. Các mô hình phát triển này có những đặc điểm riêng, ưu nhược điểm phù hợp với từng loại dự án và yêu cầu cụ thể của khách hàng.

1. CHƯƠNG 2. CÁC MÔ HÌNH
PHÁT TRIỂN PHẦN MỀM
Bộ môn Công nghệ thông tin
Trường Đại học Thương mại
1

2. Nội dung
2.1. Vòng đời phát triển phần mềm
2.2. Các hoạt động phát triển phần mềm
2.3. Các mô hình phát triển phần mềm
2.3.1. Mô hình thác nước (Water Fall Model)
2.3.2. Mô hình V
2.3.3. Mô hình bản mẫu
2.3.4. Mô hình phát triển ứng dụng nhanh
2.3.5. Các mô hình tiến hóa
2.3.5.1. Mô hình gia tăng
2.3.5.2. Mô hình xoắn ốc
2.3.5.3. Mô hình xoắn ốc WINWIN
2.3.6. Mô hình phát triển đồng thời
2.3.7. Mô hình hướng thành phần
2.3.7. Mô hình hướng sử dụng lại
2.3.8. Mô hình hợp nhất
2.4. Một số lưu ý
2

3. 2.1. Vòng đời phát triển PM
Là khoảng thời gian tính từ khi phần mềm
được đề xuất cho đến khi bỏ đi: cụ thể là
từ khi được đặt hàng, phát triển, sử dụng
đến khi bị loại bỏ.
Vòng đời phần mềm được phân chia thành
các pha chính như xác định yêu cầu, triển
khai, kiểm thử, bảo trì (vận hành)... Phạm
vi, thứ tự các pha khác nhau tùy theo từng
mô hình, dự án cụ thể
3

4. 2.1. Vòng đời phát triển PM(2)
Tùy mô hình áp dụng mà việc phân chia các
pha, các bước có thể có sự khác nhau: từ 3
đến 20 pha.
Xác định yêu cầu Triển khai Kiểm thử
(VËn hµnh) Bảo trì
Vòng đời phần mềm
4

5. 2.2. Các hoạt động phát triển PM
Phân tích tính khả thi
Phân tích và đặc tả yêu cầu
Thiết kế
Mã hóa
Kiểm thử
Bảo trì
5

6. Phân tích tính khả thi
Phân tích tính khả thi
– Xác định vấn đề cần giải quyết
– Xem xét các giải pháp và kỹ thuật khác nhau (đánh
giá ưu nhược điểm của từng giải pháp)
– Đánh giá về thời gian, giá thành, nguồn tài nguyên
cần thiết
– Sản phẩm: tài liệu phân tích
6

7. Phân tích và đặc tả yêu cầu
Phân tích và đặc tả yêu cầu
7

8. Phân tích và đặc tả yêu cầu
Đặc tả yêu cầu (hay còn gọi là kỹ thuật xác định yêu cầu) là quy
trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu và
các ràng buộc trong quá trình vận hành và xây dựng hệ thống.
Quy trình xác định yêu cầu bao gồm bốn pha chính:
1. Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định những yêu
cầu của người sử dụng có thoả mãn những công nghệ hiện tại hay
không. Về góc độ kinh doanh, nghiên cứu khả thi nhằm xác định hệ
thống đưa ra có mang lại lợi nhuận không. Việc nghiên cứu khả thi
nên được thực hiện một cách nhanh chóng và không quá tốn kém.
Kết quả của việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây
dựng hệ thống nữa hay không.
2. Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các yêu cầu
hệ thống thông qua một số phương pháp như: quan sát hệ thống
hiện tại, phỏng vấn và thảo luận với người sử dụng, phân tích
nhiệm vụ, phân tích tài liệu hoặc hệ thống cũ … Trong pha này,
chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống và
các mẫu thử.
8

9. 3. Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập
được. Có hai loại yêu cầu cần được xác định:
* Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự
nhiên bổ sung thêm cho các biểu đồ của các dịch vụ mà hệ thống
cung cấp và các ràng buộc vận hành của nó. Kiểu yêu cầu này
được viết bởi người sử dụng.
* Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các
chức năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu
cầu hệ thống sẽ định nghĩa những gì cần phải xây dựng, cho nên
nó có thể trở thành bản hợp đồng giữa khách hàng và nhà thầu.
4. Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem
chúng có đúng thực tế hay không, có thống nhất không, có đầy
đủ không. Nếu phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này.
9

10. Phân tích và đặc tả yêu cầu
Phân tích và đặc tả yêu cầu
– Xác định nhu cầu của khách hàng/người sử dụng
Xác định bài toán, chứ không phải là giải pháp
– Khó khăn
Khách hàng không biết rõ cái họ cần
Khách hàng không trình bày rõ cái họ muốn thay đổi
– Sản phẩm: tài liệu đặc tả yêu cầu
10

11. Phân tích và đặc tả yêu cầu
Phân tích và đặc tả yêu cầu
11

12. Thiết kế phần mềm
Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa
trên những tài liệu đặc tả. Hoạt động thiết kế bao gồm những
công việc chính sau:
– Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây
dựng và mối quan hệ giữa chúng được xác định và tư liệu hoá.
– Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về
các dịch vụ của nó và những ràng buộc khi nó vận hành.
– Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với
những hệ thống con khác phải được thiết kế và tư liệu hoá.
– Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác
và các giao diện tương tác với chúng phải được thiết kế.
– Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt
hệ thống phải được thiết kế một cách chi tiết và cụ thể.
– Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các
dịch vụ phải được thiết kế chi tiết và chính xác.
12

13. Thiết kế phần mềm
Các công việc trong thiết kế phần mềm
13

14. Thiết kế phần mềm
Các phương pháp thiết kế
Hướng chức năng
Hướng đối tượng
14

15. Mã hóa và gỡ rối
Mã hóa và gỡ rối
– Mã hóa: cài đặt các thiết kế bằng ngôn ngữ lập
trình không đơn thuần chỉ là lập trình
Viết tài liệu
Chuẩn lập trình
Lập trình theo cấp
Công cụ
Quản lý phiên bản
– Gỡ rối: phát hiện các lỗi trong quá trình lập trình
– Sản phẩm: chương trình
15

16. Kiểm thử
Kiểm thử - Đánh giá phần mềm hay còn gọi là
thẩm tra và đánh giá (V&V - Verification and
validation) được sử dụng để chỉ ra rằng hệ
thống đã thực hiện theo đúng các đặc tả và
thoả mãn mọi yêu cầu của khách hàng.
Kiểm thử bao gồm các công đoạn: kiểm tra,
xem xét lại, và kiểm thử hệ thống. Kiểm thử
hệ thống tức là cho hệ thống thực hiện trên
những trường hợp có dữ liệu thật được lấy từ
tài liệu đặc tả hệ thống. Quy trình kiểm thử
gồm các pha sau:
16

17. – Kiểm thử thành phần (đơn vị): các thành phần
được kiểm thử một cách độc lập, thành phần có
thể là một chức năng hoặc một đối tượng hoặc
một nhóm các thực thể gắn kết với nhau.
– Kiểm thử hệ thống: kiểm thử toàn bộ hệ thống.
– Kiểm thử chấp thuận: kiểm thử trên dữ liệu của
khách hàng để kiểm tra hệ thống có đáp ứng tất
cả các yêu cầu của khách hàng hay không.
17

18. Kiểm thử
– Khi chuyển giao hệ thống cho khách hàng thì quy
trình kiểm thử beta sẽ được thực hiện. Khách
hàng sẽ thông báo các lỗi cho đội dự án. Những lỗi
này sẽ được chỉnh sửa và tiếp tục kiểm thử beta
hoặc chuyển giao thực sự cho khách hàng.
– Các công việc cần làm trong quá trình kiểm thử
Phát hiện lỗi trong chương trình
Lập kế hoạch thực hiện kiểm thử
– Tạo các trường hợp kiểm thử
– Tiêu chuẩn kiểm thử
– Nguồn tài nguyên kiểm thử
Mã nguồn được kiểm thử theo tài liệu thiết kế
Sản phẩm: báo cáo kiểm thử
18

19. Kiểm thử
Các phương pháp kiểm thử
– Kiểm thử tĩnh
– Kiểm thử động
Kiểm thử hộp đen
Kiểm thử hộp trắng
19

20. Bảo trì hệ thống
Bảo trì hệ thống:
– Bảo đảm chương trình vận hành tốt
– Cài đặt các thay đổi
– Cài đặt các yêu cầu mới
– Xử lý các lỗi khi vận hành
– Sản phẩm: chương trình
20

21. Cải tiến phần mềm
Cải tiến phần mềm
– Khi các yêu cầu hệ thống thay đổi theo sự thay đổi
của các yêu cầu nghiệp vụ thì phần mềm phải cải
tiến và thay đổi để hỗ trợ khách hàng. Thông
thường chi phí để bảo trì và cải tiến thường đắt
hơn nhiều so với chi phí xây dựng phần mềm.
21

22. 2.3. Các mô hình phát triển PM
Hiện nay có rất nhiều mô hình phát triển phần
mềm, và thường được phân thành 2 loại: mô
hình tuyến tính và mô hình lặp.
– Mô hình tuyến tính: các bước được thực hiện tuần
tự, không lặp lại.
Mô hình thác nước
Mô hình V…
– Mô hình lặp: các bước có thể thực hiện song song,
có thể lặp lại một số bước.
Mô hình tiến hóa
Mô hình xoắn ốc
Mô hình hợp nhất…
22

23. 2.3.2. Mô hình Thác nước
Mô hình thác nước (Water Fall Model)
23

24. Các pha của mô hình thác nước bao gồm:
– Phân tích và xác định các yêu cầu
– Thiết kế hệ thống và phần mềm
– Cài đặt và kiểm thử đơn vị
– Tích hợp và kiểm thử hệ thống
– Vận hành và bảo trì.
24

25. 2.3.1. Mô hình Thác nước
Là mô hình cổ điển
Phương pháp áp dụng 1 lần
Điều khiển hiệu quả
Phạm vi giới hạn của vòng lặp
Vòng đời dài
Không thích hợp với các hệ thống không rõ
ràng
25

26. Trong mô hình thác nước, năm pha trên phải được
thực hiện một cách tuần tự; kết thúc pha trước, rồi
mới được thực hiện pha tiếp theo. Do đó, nhược
điểm chính của mô hình thác nước là rất khó khăn
trong việc thay đổi các pha đã được thực hiện. Giả
sử, pha phân tích và xác định yêu cầu đã hoàn tất và
chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay
đổi yêu cầu của người sử dụng; thì chỉ còn cách là
phải thực hiện lại từ đầu.
Mô hình này chỉ thích hợp khi các yêu cầu đã được
tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn
một cách rõ ràng trong suốt quá trình thiết kế. Tuy
nhiên, trong thực tế có rất ít những hệ thống nghiệp
vụ có các yêu cầu ổn định.
26

27. Ưu điểm:
– Chỉ phù hợp với các dự án nhỏ hoặc
– Yêu cầu xác định
Nhược điểm:
– Không phù hợp với dự án lớn
– Thời gian thực hiện lâu
27

28. 2.3.2. Mô hình V
Bảo trì
Phân tích yêu Kiểm thử chấp
cầu nhận
Thiết kế hệ Kiểm thử hệ
thống thống
Thiết kế Kiểm thử đơn vị và
chương trình tích hợp
Lập trình
28

29. 2.3.2. Mô hình V
Trong mô hình V:
– Các tiến trình kiểm thử được thêm vào
– Kết nối kiểm thử với phân tích và thiết kế
– Thích hợp với những trường hợp bài toán không
nhất quán
29

30. 2.3.3. Mô hình bản mẫu
Nghe Khách Tạo / sửa
trình bày bản mẫu
Khách kiểm tra
bản mẫu
Mô hình bản mẫu (Prototyping model)
30

31. 2.3.3. Mô hình bản mẫu
Mục đích
– Xem xét yêu cầu người sử dụng ở giai đoạn ban
đầu
– Giảm bớt rủi ro và không chắc chắn
– Kiểm chứng thiết kế và thực thi
Nên thường xuyên trả lời các câu hỏi chuyên
biệt; mục đích phải được xác định
31

32. Lợi ích của bản mẫu
Học bằng cách làm việc
Tăng cường giao tiếp
Tăng sự tham gia của người dùng vào dự án
Làm rõ các yêu cầu chỉ biết một phần
32

33. Tuần tự làm bản mẫu
Tập hợp yêu cầu
Thiết kế nhanh
Xây dựng bản mẫu
Đánh giá của khách hàng
Làm mịn
Quay lại thiết kế nhanh để điều chỉnh
Xây dựng sản phẩm
33

34. Ưu điểm: phù hợp với
– Hệ thống rủi ro cao
– Yêu cầu không chắc chắn
– Giao diện chưa rõ ràng
– Chiến lược cài đặt chưa rõ ràng
34

35. Hạn chế:
– Khách hàng có thể cho rằng nguyên mẫu là hệ
thống thực
Mong đợi không thực tế về tiến triển của dự án
– Người phát triển có sự chọn lựa không tốt
Phù hợp cho nguyên mẫu, nhưng không phù hợp cho hệ
thống thực
– Nguyên mẫu không giống hoàn toàn hệ thống cuối
cùng
Khách hàng sẽ có các phản ứng khác nhau
35

36. 2.3.3. Mô hình bản mẫu
Mô hình bản mẫu thường được sử dụng khi:
– 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
36

37. 2.3.4. Mô hình phát triển ứng dụng nhanh
Mô hình phát triển ứng dụng nhanh (Rapid Application
Development: RAD) là mô hì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)
37

38. 2.3.4. Mô hình phát triển ứng dụng nhanh
Team #3
Business
Business
Modeling
Modeling
Team #2 Data
Data
Modeling
Modeling
Business
Business Process
Process
Modeling
Modeling Modeling
Modeling
Team #1 Data
Data Application
Application
Modeling Generation
Generation
Business Modeling
Business Process
Process
Testing &
Testing &
Turnover
Modeling
Modeling Modeling
Modeling
Turnover
Data Application
Application
Data Generation
Modeling
Modeling Generation
Testing &
Testing &
Process
Process Turnover
Turnover
Modeling
Modeling
Application
Application
Generation
Generation
Testing &
Testing &
Turnover
Turnover
60 - 90 days 38

39. RAD: Mô hình nghiệp vụ
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 ?
39

40. RAD: Mô hình tiến trình và dữ liệu
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
40

41. RAD: Tự sinh ứng dụng và kiểm thử
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)
41

42. 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
42

43. 2.3.5. Mô hình tiến hóa
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: gia tăng (incremental), xoắn ốc
(spiral), xoắn WINWIN (WINWIN spiral) mô hình
phát triển đồng thời (concurrent development model)
43

44. Mô hình tiến hóa
44

45. 2.3.5. Mô hình tiến hóa
Ưu điểm: phù hợp với
– Dự án vừa và nhỏ
– Các phần của dự án phức tạp
– Các hệ thống có thời gian sống ngắn
Hạn chế
– Cấu trúc hệ thống tồi
– Tiến trình không rõ ràng
45

46. 2.3.5.1. Mô hình gia tăng
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
46

47. 2.3.5.1. Mô hình gia tăng
Gia tăng 1
Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 1
System/info.
Engineering
Gia tăng 2 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 2
Gia tăng 3 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö Xuất xưởng 3
Gia tăng 4 Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö
XX 4
Calendar time
47

48. Mô hình này được đề xuất dựa trên ý tưởng
thay vì phải xây dựng và chuyển giao hệ
thống một lần thì sẽ được chia thành nhiều
giai đoạn, tăng dần. Mỗi giai đoạn là một phần
kết quả của một chức năng được yêu cầu.
Các yêu cầu của người sử dụng được đánh
thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên
càng cao thì càng ở trong những giai đoạn
phát triển sớm hơn.
48

49. Mô hình gia tăng
49

50. Ưu điểm của mô hình phát triển gia tăng:
– Sau mỗi lần tăng vòng thì có thể chuyển giao kết
quả thực hiện được cho khách hành nên các chức
năng của hệ thống có thể nhìn thấy sớm hơn.
– Các vòng trước đóng vai trò là mẫu thử để giúp
tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.
– Những chức năng của hệ thống có thứ tự ưu tiên
càng cao thì sẽ được kiểm thử càng kỹ.
50

51. 2.3.5.2. Mô hình xoắn ốc
Lập kế hoạch
Phân tích rủi ro
Giao tiếp
khách hàng
Khái niệm Thiết kế
Làm mới
Nâng cấp
Khách hàng Xây dựng &
đánh giá Xuất xưởng
Bảo trì
Mô hình xoắn ốc (spiral)
51

52. 2.3.5.2. Mô hình xoắn ốc (Boehm
1987)
Chi phí tăng thêm
Xác định mục đích, Đánh giá lựa chọn;
lựa chọn và ràng Phân tích
xác định và giải
buộc rủi ro quyết rủi ro
Phân tích
rủi ro
Phân tích
rủi ro Bản mẫu
Bản mẫu
Bản mẫu
Lập kế hoạch Chức năng Yêu cầu phần Thiết kế Thiết kế
yêu cầu mềm hệ chi tiết
thống
Lập kế hoạch Kiểm thử yêu
phát triển cầu Lập
Kế hoạch kiểm trình
thử và tích hợp Kiểm thử
thiết kế Kiểm
thử Phát triển và kiểm
Kế hoạch cho giai đoạn tiếp Tích hợp và đơn vị chứng sản phẩm
Kiểm thử kiểm thử
chấp nhận mức tiếp theo
52

53. Trong mô hình xoắn ốc, quy trình phát triển phần
mềm được biểu diễn như một vòng xoắn ốc. Các pha
trong quy trình phát triển xoắn ốc bao gồm:
– Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự
án.
– Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực
hiện các hành động để giảm thiểu rủi ro.
– Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình
xây dựng hệ thống sẽ được lựa chọn từ những mô hình
chung.
– Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình
xoắn ốc sẽ được lập kế hoạch.
53

54. 2.3.5.2. Mô hình xoắn ốc
Nhấn mạnh việc đánh giá các rủi ro
Phần mềm được xây dựng theo nhiều chu kỳ.
Mỗi chu kỳ tương ứng với một sản phẩm của
1 giai đọan phát triển
– Xác định các mục tiêu, giải pháp, ràng buộc
– Đánh giá các giải pháp, xác định các nguy cơ và
tìm cách giải quyết chúng
– Phát triển và kiểm thử sản phẩm của chu kỳ này
– Lập kế hoạch cho chu kỳ tiếp theo
54

55. 2.3.5.2. 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ý
Thiết kế: Xây dựng một hay một số biểu diễn của ứng
dụng
55

56. 2.3.5.2. 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
56

57. 2.3.5.2. Mô hình xoắn ốc (tiếp)
Ưu điểm
– Hạn chế rủi ro sớm
– Nhận được phản hồi (feedbacks) từ khách hàng
sớm
– Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa
Hạn chế
– 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ử.
57

58. 2.3.5.2. Mô hình xoắn ốc
Mô hình xoắn ốc phù hợp với
– Các hệ phần mềm quy mô lớn, các dự án lớn,
phức tạp
– Hệ thống cần phát triển nhiều phiên bản
– Các hệ thống có yêu cầu chưa xác định rõ ràng
58

59. 2.3.5.3. Mô hình xoắn ốc WINWIN
Là mô hình xoắn ốc 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 việc 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
59

60. 2.3.5.3. Mô hình xoắn ốc WINWIN
2. Xác định điều kiện 3a. Hòa hợp điều kiện thắng
thắng của cổ đông 3b. Thiết lập mục tiêu mức tiếp
và các ràng buộc, dự kiến
1. Xác định mức
tiếp của cổ đông
4. Đánh giá tiến trình và
dự kiến sản phẩm,
giải quyết rủi ro
7. Xét duyệt và đánh giá
6. Kiểm định sản phẩm 5. Xác định mức tiếp của
và quy trình sản phâm và quy trình,
kể cả phân chia nhỏ
60

61. 2.3.6. Mô hình phát triển đồng thời
Mô hình phát triển đồng thời (The concurrent
development model):
– 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
(componets) trong hệ thống được phát triển đồng thời.
61

62. 2.3.7. Mô hình hướng thành phần
Mô hình hướng thành phần (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.
Mô hình hướng thành phần sử dụng UML như một
chuẩn công nghiệp
62

63. 2.3.7. Mô hình hướng thành phần
Lập kế hoạch
Phân tích rủi ro Xác định
thành phần
ứng viên
Giao tiếp
khách hàng
Xây dựng Tìm
bước lặp thứ n thành phần
của hệ thống từ thư viện
Đặt Lấy
thành phần thành phần
vào thư viện nếu có
Kỹ nghệ
Khách hàng Xây dựng & Xây dựng
đánh giá Xuất xưởng thành phần
nếu kh.có
63

64. 2.3.7. Mô hình hướng sử dụng lại
Mô hình này phát triển định hướng sử dụng lại
(Reuse)
Hệ thống được tích hợp từ các thành phần
đã tồn tại hay hệ thống phi thương mại
Các giai đoạn của tiến trình
– Phân tích thành phần
– Cải biến các yêu cầu
– Thiết kế hệ thống hướng sử dụng lại
– Phát triển và tích hợp
64

65. 2.3.7. Mô hình hướng sử dụng lại
Phát triển định hướng sử dụng lại (2)
Đặc tả yêu Phân tích Thay đổi Thiết kế HT
thành phần yêu cầu dùng lại
cầu
Phát triển và Thẩm định
tích hợp hệ thống
Hướng phát triển này rất quan trọng nhưng
kinh nghiệm và công cụ còn hạn chế
65

66. 2.3.8. Mô hình hợp nhất
Mô hình hợp nhất sử dụng 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 đó tự động sinh 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.
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
66

67. 2.3.8. Mô hình hợp nhất
Tiến trình hợp nhất có thể được nhìn dưới hai
góc nhìn khác nhau
– Góc nhìn quả lý: quan tâm đến lĩnh vực kinh tế,
chiến thuật, con người.
Tiến trình gồm 4 giai đoạn.
– Góc nhìn kỹ thuật: quan tâm đến công nghệ, kiểm
tra chất lượng, phương pháp.
Tiến trình gồm nhiều bước lặp.
67

68. 2.3.8. Mô hình hợp nhất
Góc nhìn quản lý
68

69. 2.3.8. Mô hình hợp nhất
Góc nhìn kỹ thuật: các bước lặp
– Mỗi bước lặp gồm các hoạt động
Đặc tả
Phân tích
Thiết kế
Mã hóa
Kiểm thử
Cài đặt
– Mỗi bước lặp là một tiến trình thác đổ
69

70. 2.3.8. Mô hình hợp nhất
Góc nhìn kỹ thuật
70

71. 2.3.8. Mô hình hợp nhất
Kết hợp hai góc nhìn
71

72. 2.3.8. Mô hình hợp nhất
Mô hình hợp nhất và UML
72

73. 2.3.8. Mô hình hợp nhất
Ưu điểm: giảm thời gian phát triển và tăng
năng suất lao động.
Nhược điểm: 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
Trong tương lai: kết hợp 4GT với mô hình
hướng thành phần.
73

74. Kết luận
Trong thực tế, người ta thường kết hợp
nhiều mô hình cho một dự án
– Đối với Hệ thống phức tạp, cần chia dự án thành
các hệ thống con
– Áp dụng mô hình xoắn ốc hay mô hình hợp nhất
cho toàn bộ dự án.
– Mỗi hệ thống con có thể áp dụng một mô hình
khác nhau
Áp dụng mô hình nguyên mẫu cho các hệ thống con
phức tạp
Áp dụng mô hình thác nước cho các hệ thống con khác
74

75. 2.4. Một số lưu ý
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
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
=> Làm bản mẫu, mô hình xoắn ốc
75

76. 2.4. Một số lưu ý
Tổ hợp các mô hình:
Có thể tổ hợp các mô hình để đem lại hiệu quả
76

77. 2.4. Một số lưu ý
Lặp tiến trình:
Mỗi phần của tiến trình được lặp theo 2
cách tiếp cận
• Phát triển tăng
• Phát triển xoắn ốc
77

78. 2.4. Một số lưu ý
Chuẩn hóa tiến trình:
Tăng năng lực của tổ chức phát triển phần
mềm
ISO 9000-03 (International Standards Organization )
• CMM (Software Engineering Institute)
78

79. 2.4. Một số lưu ý
Giảm chi phí phát triển:
Sử dụng các phương pháp, công cụ tiên tiến
• 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
79

80. 2.4. Một số lưu ý
Thực hiện các pha phát triển:
Pha 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 mã hóa, kiểm thử
Khi chuyển tiếp giữa các pha phát triển phải thẩm
định để đả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à dùng trong khâu 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.
80

81. CÂU HỎI ÔN TẬP
1. Phân biệt các mô hình tiến trình
2. Khi có yêu cầu phát triển một hệ thống:
– Cần lưu ý gì trong việc lựa chọn mô hình tiến trình
– Lựa chọn mô hình phù hợp bằng cách nào
– Có những chỉ dẫn gì trong việc lựa chọn mô hình
3. Xác định tiến trình phát triển như thế nào?
4. Vấn đề chuẩn hóa tiến trình
– Tìm hiểu và viết báo cáo, trình bày về mô hình phát
triển phần mềm (mỗi nhóm 1 mô hình)
81