NHẬP MÔN CNPM

Nội dung / Chương 2, 3:

Vòng đời phần mềm

tuannm@soict.hust.edu.vn
1. Sự tiến triển của các phương pháp thiết kế phần mềm

Ít quan tâm tới

phần mềm
Tập trung nâng cao Phát triển hệ điều hành như phần mềm lớn (IBM OS/360, EC OS). Xuất hiện nhu cầu về
tính năng và độ tin quy trình phát triển phần mềm lớn và quy trình gỡ lỗi, kiểm thử trong phạm vi giới hạn
cậy của phần cứng

Chính sách phân biệt giá cả giữa phần cứng và phần mềm (IBM).
Nghiên cứu cơ bản về phương pháp luận lập trình
Xuất hiện khái niệm “Software Engineering” (1968).
Bắt đầu bàn luận về khủng khoảng phần mềm và xu hướng hình thành
CNHPM như một chuyên môn riêng

1960 1970 1980 1990 2000 3

1. Sự tiến triển của các phương pháp thiết kế phần mềm
Nghiên cứu về lập trình,
kiểm thử, đảm bảo tính
tin cậy trong quy trình sản
xuất phần mềm.
Kỹ thuật: lập trình cấu
trúc hóa, lập trình môđun,
thiết kế cấu trúc hóa, vv
1960
Hội nghị quốc tế đầu tiên về
CNHPM được tổ chức (1975):
International Conference on SE
(ICSE)
Quan tâm đến mọi pha trong quy trình phát triển phần mềm,
nhưng tập trung chính ở những pha đầu.
ICSE tổ chức lần 2, 3 và 4 vào 1976, 1978 và 1979
Nhật Bản có “Kế hoạch phát triển kỹ thuật sản xuất phần
mềm” từ năm 1981
Cuộc “cách tân sản xuất phần mềm” đã bắt đầu trên phạm vi
các nước công nghiệp
1970 1980 1990 2000 4
1. Sự tiến triển của các phương pháp thiết kế phần mềm
Trình độ học vấn và ứng dụng
CNHPM được nâng cao, các
công nghệ được chuyển vào
thực tế. Xuất hiện các sản
phẩm phần mềm và các công
cụ khác nhau làm tăng năng
suất sản xuất phần mềm đáng
kể
ICSE tổ chức lần 5 và 6 năm
1981 và 1982 với trên 1000
người tham dự mỗi năm
Nhật Bản sang “Kế hoạch
phát triển các kỹ thuật bảo trì
phần mềm” (1981-1985)
1960 1970
Từ học vấn sang nghiệp vụ!
Chất lượng phần mềm tập trung chủ yếu ở tính năng suất, độ tin cậy
và tính bảo trì. Nghiên cứa hỗ trợ tự động hóa sản xuất phần mềm
Nhật Bản: SIGMA: Software Industrialized Generator & Maintenance
Aids, 1985-1990
Nhiều trung tâm, viện nghiên cứu CNHPM ra đời. Các trường đưa
vào giảng dạy SE
Công nghiệp hóa sản xuất phần mềm bằng cách đưa
những kỹ thuật công nghệ học (Engineering
techniques) thành cơ sở khoa học của CNHPM
Thể chế hóa lý luận trong sản xuất phần mềm và
ứng dụng những phương pháp luận một cách nhất
quán
Tăng cường nghiên cứu và tạo công cụ trợ giúp sản
xuất phần mềm
1980 1990 2000 5
 Hình thái sản xuất Phần mềm

Đưa ra các kỹ thuật, phương pháp luận

ứng dụng thực tế vào từng quy trình

Cải biên, biến đổi vào từng sản phẩm và

công cụ phần mềm (máy tính hóa từng phần)

Tổng hợp, hệ thống hóa cho từng loại công cụ

(Máy tính hóa toàn bộ quy trình sản xuất phần mềm)

Hướng tới sản xuất phần mềm tự động

6
 Vòng đời phần mềm

• Vòng đời phần mềm là thời kỳ tính từ khi phần

mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc
hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng
cho đến khi loại bỏ không đâu dùng)
• Quy trình phần mềm (vòng đời phần mềm) được
phân chia thành các pha chính: phân tích, thiết kế,
chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có
khác nhau theo từng người

7
Các phương pháp luận và kỹ thuật cho từng pha

Tên pha Nội dung nghiệp vụ Phương pháp, kỹ thuật

Xác định Đặc tả yêu cầu người dùng
Phân tích cấu trúc hóa
yêu cầu Xác định yêu cầu phần mềm
Thiết kế Thiết kế cơ bản phần mềm
Thiết kế cấu trúc hóa
hệ thống Thiết kế cấu trúc ngoài của phần mềm
Thiết kế Là thiết kế chi tiết: Thiết kế cấu trúc bên Lập trình cấu trúc
chương trong của phần mềm (đơn vị chương trình Phương pháp Jackson
trình hoặc môđun) Phương pháp Warnier
Lập trình Mã hóa bởi ngôn ngữ lập trình Mã hóa cấu trúc hóa
Đảm bảo Kiểm tra chất lượng phần mềm đã phát Phương pháp kiểm thử
chất lượng triển chương trình
Sử dụng, vận hành phần mềm đã phát
Vận hành
triển. Chưa cụ thể
Bảo trì
Biến đổi, điều chỉnh phần mềm

8
Quy trình phát triển phần mềm

Khung quy trình chung (Common process framework)

Hoạt động khung (Framework activities)

Tập tác vụ (Task sets)

Tác vụ (Tasks)
Điểm quan trọng (milestones),sản
phẩm chuyển giao (deliverables)

Điểm Kiểm Tra Chất Lượng

(SQA points)

Các hoạt động giám sát, đánh giá kỹ thuật, đảm bảo chất
lượng phần mềm, quản lý cấu hình, quản lý rủi ro, ...
(Umbrella activities)
9
Ví dụ về mô hình sinh tiến trình

http://bit.ly/2ihOLB4 Slides copyright 2009 by Roger Pressman.

10
Luồng
tiến
trình

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

Giới thiệu chung 11

 Xác định tập các tác vụ

• Một công việc thực tế được định nghĩa bởi một tổ hợp các
tác vụ, nhằm hoàn thành mục tiêu, đối tượng đề ra của một
hành động thiết kế phần mềm nào đó.
– Một tập hợp các tác vụ phải hoàn thành.

– Một tập hợp các sản phẩm cần được sản xuất

– Một tập hợp các bộ lọc đảm bảo chất lượng cần được áp
dụng

12
 Mô hình hóa hệ thống

▪ Mô hình hoá một hệ thống phải thực hiện theo cả bốn

hướng
Kiến trúc (các thành phần) vật lý

Các chức năng, nhiệm Cấu trúc tĩnh (dữ liệu,

vụ hoặc quá trình xử lý thông tin được lưu trữ,
các nhiệm vụ của hệ xử lý và các yếu tố tạo
thống. nên hệ thống.

Cách ứng xử (hành vi),

Các phản ứng tức thời
Các tiến hoá trong thời gian dài

13
 Mô hình hóa hệ thống

• Bốn yếu tố quan trọng ảnh hưởng tới hiệu quả của dự án
phát triển phần mềm:
– 1. Con người. Yếu tố quan trọng nhất hiển nhiên là số lượng và
trình độ chuyên nghiệp của những người tham gia phát triển phần
mềm, những người có khả năng nắm bắt, làm chủ được những công
nghệ mới, có khả năng hiểu được bài toán của lĩnh vực ứng dụng.
– 2. Bài toán (lĩnh vực ứng dụng). Hiệu quả của dự án phụ thuộc
nhiều vào độ phức tạp của bài toán với những yêu cầu thường
xuyên thay đổi, những đòi hỏi phức tạp với các ràng buộc về dữ liệu,
thời gian và tài nguyên của hệ thống.
– 3. Công nghệ: các kỹ thuật, công cụ hỗ trợ để phát triển phần mềm,
– 4. Các tài nguyên: bao gồm cả các phần cứng như máy tính, thiết bị
phụ trợ, phần mềm ứng dụng và tài chính, ngân sách đầu tư cho dự
án phát triển phần mềm.

14
 Mô hình hóa hệ thống

• Quá trình phát triển hệ thống luôn gặp rủi ro (Risks)

1. Rủi ro từ các yêu cầu (Requirements risks) Build the right system
• Các yêu cầu của hệ thống là gì?
• Tránh hiểu lầm các ưu tiên và không làm ra những hệ thống kém, thực hiện những
cái mà khác hàng không muốn. Xây dựng đúng hệ thống
2. Rủi ro từ công nghệ (Technological risks)
• Có thể sử dụng công nghệ thiết kế tiên tiến? (OOD) Build the system right
• Làm thế nào để thực hiện tốt CN lựa chọn? Xây dựng hệ thống đúng

3. Rủi ro từ kỹ năng (Skill risks) Choose the right system builders

• Có được đội ngũ nhân viên có kỹ năng và kinh nghiệm? Chọn đúng đội ngũ
4. Rủi ro từ chính sách (Political risks)
• Có những chế độ, chính sách ảnh hưởng đến dự án?
Xem ai cần hệ thống sẽ xây dựng

Consider who wants the system (not) to be built

Mọi rủi ro phải được nhận dạng! 15

 Mẫu tiến trình

• Một mẫu tiến trình:

– Xác định một vấn đề liên quan đến tiến trình làm việc mà

đã xảy ra trong quá trình thiết kế phần mềm,

– xác định môi trường mà vấn đề đã xảy ra,

– gợi ý một hoặc nhiều lời giải đã được chứng minh cho vấn

đề.
• Được biểu diễn bởi các thành phần mang tính tổng quát, một
mẫu tiến trình cung cấp cho bạn một template [Amb98] - một
phương pháp nhất quán để mô tả các lời giải của vấn đề từ bên
trong nội dung của quá trình thiết kế phần mềm.

16
 Các kiểu mẫu tiến trình

• Mẫu trạng thái - Xác định một vấn đề cùng với một hoạt động
nền tảng cho tiến trình.
• Mẫu tác vụ - Xác định một vấn đề cùng với một hành động
thiết kế phần mềm hoặc một tác vụ công việc thích hợp với
thực tế.
• Mẫu pha - Xác định một chuỗi các hoạt động nền tảng xảy ra
cùng với tiến trình, thậm chí khi các luồng hoạt động tổng thể
được lặp đi lặp lại trong thực tế.

17
 Các phương pháp đánh giá và cải tiến cho tiến trình

• Standard CMMI Assessment Method for Process Improvement

(SCAMPI) - cung cấp một mô hình đánh giá theo 5 bước chặt chẽ: chuẩn bị,
chuẩn đoán, thiết lập, hành động và học hỏi.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI) -
cung cấp một kĩ thuật chuẩn đoán để đánh giá chất lượng của một tổ chức
phần mềm; sử dụng SEI CMM là nền tảng cho sự đánh giá [Dun01].
• SPICE - Chuẩn SPICE (ISO/IEC15504) định nghĩa một tập các yêu cầu co
việc đánh giá tiến trình phần mềm. Mục đích của chuẩn này là giúp đỡ các tổ
chức trong việc phát triển một đối tượng ước lượng cho sự hiệu quả của bất kì
tiến trình định nghĩa phần mềm [ISO08].
• ISO 9001:2000 cho phần mềm - Một tiêu chuẩn tổng quát áp dụng cho bất
kỳ tổ chức nào muốn cải thiện chất lượng tổng thể của sản phẩm, hệ thống
hoặc dịch vụ nào đó mà họ cung cấp. Vì vậy, chuẩn này có thể dùng được trực
tiếp cho các tổ chức và công ty phần mềm [Ant06].
18
 Các Mô hình quy ước

• Mô hình quy ước ủng hộ cách tiếp cận theo trật tự trong việc thiết
kế phần mềm.
Việc này dẫn đến một số câu hỏi:
• Nếu mô hình quy ước phấn đấu cho cấu trúc và trật tự, liệu nó có
thích hợp cho một thế giới phần mềm biến động mạnh mẽ ?
• Hơn nữa, nếu chúng ta loại bỏ mô hình tiến trình cổ điển, và thay
thế chúng bởi cái gì đó ít tính cấu trúc hơn, có phải chúng ta không
thể đạt được sự phối kết hợp trong công việc phần mềm ?

19
 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

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

20
 Mô hình tuyến tính

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

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

21
 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

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

22
 Đ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!

23
 Mô hình thác nước

Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

24
 Mô hình thác nước
(Waterfall model)

• Các pha trong mô hình thác nước

– Phân tích và định nghĩa 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ì

Nhược điểm chính của mô hình thác nước là khó khăn

của việc sửa đổi sau khi quy trình đã vào guồng. Pha
này phải được hoàn tất trước khi bước vào pha tiếp
theo.

25
 Mô hình thác nước
(Waterfall model)

• Các vấn đề của mô hình thác nước

– Khó đáp ứng việc khách hàng thay đổi yêu cầu.
• do việc phân dự án thành các giai đoạn tách biệt
– Chỉ thích hợp khi các yêu cầu được hiểu rõ và ít
có thay đổi trong quy trình phát triển.
• Ít hệ thống doanh nghiệp có các yêu cầu ổn định ít
thay đổi theo thời gian.

26
Mô hình chữ V

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.
27
 Mô hình tăng dần

increment # n
Co m m u n i c a t i o n
Pla nning

M odeling
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

delivery of
increment # 2 nt h increment

Co m m u n i c a t i o n
Pla nning

M odeling
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
delivery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nning
M odeling
analy s is Co n s t ru c t i o n
des ign c ode
delivery of
De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

1st increment

project calendar time

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

28
Mô hình mang tính cách mạng: Prototyping

Qu ick p lan
Quick
Communicat ion plan
communication
Mo d e lin g
Modeling
Qu ick d e sig n
Quick design

Deployment
Deployment
De live ry
delivery &
& Fe e dback Const ruct ion
feedback Construction
of
ofprot
prototype
ot ype

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

29
 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 30
 Mô hình mang tính cách mạng: Prototyping
Paper Prototype 3D print

Digital Prototype Scale Model

31
 Mô hình mang tính cách mạng: Prototyping
Web design

32
 Các 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 tiêu biểu:
– Gia tăng (Incremental)
– Xoắn ốc (Spiral)
– Xoắn ốc WINWIN (WINWIN spiral)
– Phát triển đồng thời (Concurrent development)

33
 Các mô hình tiến hóa

• Phát triển thăm dò (exploratory development)

– Mục đích là làm việc với khách hàng và từng bước phát
triển (evolve) từ một đặc tả sơ lược ban đầu tới một hệ
thống là sản phẩm cuối cùng.
• nên bắt đầu từ một bộ yêu cầu được hiểu rõ và bổ sung các tính
năng mới khi khách hàng đề xuất.
• Các phiên bản thử nghiệm dùng tạm (throw-away
prototyping)
– Mục đích để hiểu các yêu cầu hệ thống.
• nên bắt đầu từ bộ yêu cầu không được hiểu rõ để có thể làm rõ đâu
là cái thực sự được yêu cầu.

34
 Các mô hình tiến hóa

Phiên bản
đầu tiên
Đặc tả

Phát triển Phiên bản

trung gian

Hợp thức hóa

Phiên bản
cuối cùng

35
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

36
 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

Công nghệ hệ
thống/thông tin

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

Thời gian/lịch

37
Mô hình gia tăng (The incremental model)

• Một casestudy của mô hình gia tăng:

– Giả sử chúng ta muốn phát triển một mạng xã
hội dựa trên web với các chức năng sau:
• Người dùng đăng ký tài khoản hệ thống.
• Người dùng đăng nhập vào hệ thống và có thể gửi hoặc chấp
nhận yêu cầu kết bạn.
– Làm thế nào có thể sử dụng mô hình gia tăng trong
kịch bản này?

38
Mô hình gia tăng (The incremental model)

• Giải pháp:
– Chúng ta cần chuyển đổi hệ thống này thành
các thành phần riêng biệt;
– Hợp phần 1: Đăng ký và đăng nhập
– Hợp phần 2: Gửi yêu cầu kết bạn
– Hợp phần 3: Chấp nhận yêu cầu kết bạn

39
Mô hình gia tăng (The incremental model)

• Giải pháp:

40
 Mô hình gia tăng (The incremental model)
• Những lợi thế của một mô hình gia tăng là gì?
– Phản hồi của khách hàng được nhận sau khi giao từng bộ phận.
– Rủi ro thay đổi yêu cầu giảm
– Linh hoạt hơn
– Dễ dàng kiểm tra và gỡ lỗi
– Cho kết quả nhanh
• Những nhược điểm của một mô hình gia tăng là gì?
– Cần một kế hoạch thích hợp để tích hợp các thành phần
– Cần một thiết kế phù hợp để tích hợp các thành phần
– Mở rộng hơn so với mô hình thác nước.
• Khi nào nên sử dụng mô hình gia tăng?
– Khi các yêu cầu chính được xác định nhưng một số yêu cầu có thể phát triển
trong thời gian tiếp theo.
– Khi sản phẩm ra mắt trên thị trường là muộn.
– Khi một khách hàng không có vấn đề gì với ngân sách nhưng anh ta đòi hỏi
ngày càng chất lượng hơn về phần mềm.
41
Mô hình xoắn ốc (spiral model)

• Quy trình được biểu diễn dưới dạng xoắn ốc thay vì

một chuỗi các hoạt động với các bước quay lui.
• Mỗi vòng trong đường xoắn ốc đại diện cho một pha
trong quy trình.
• Không có các pha cố định như pha đặc tả hay pha
thiết kế - các vòng xoắn được lựa chọn tùy theo nhu
cầu.
• Các rủi ro được đánh giá một cách tường minh và
được giải quyết trong suốt quy trình.

42
Mô hình mang tính cách mạng: Mô hình xoắn ốc
planning
estimation
scheduling
risk analy sis

communication

modeling
analy sis
design
start

deployment
construction
deliv ery code
http://bit.ly/2ihOLB4 Slides copyright 2009 by feedback test
43
Roger Pressman.
 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
44
 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

45
 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ử

46
 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

47
 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ỏ

48
Mô hình mang tính cách mạng: Mô hình đồng thời

none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.
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
50
 Một số mô hình khác

• Component based development—tiến trình được áp dụng khi

sử dụng lại là một đối tượng phát triển.
• Formal methods—nhấn mạnh đặc điểm toán học của yêu cầu.
• AOSD-Aspect Oriented Componet Development—cung cấp
một tiến trình và phương pháp luận để tiếp cận việc định
nghĩa, đặc biệt hóa, thiết kế và xây dựng các khía cạnh.
• Unified Process—Một tiến trình phần mềm có đặc tính
“hướng hành động (use-case), kiến trúc trung tâm, lặp và tăng
dần” gần với ngôn ngữ UML (Unified Modeling Language)

51
 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, chỉ số sản xuất 26.2/16.9
• Với UML như chuẩn công nghiệp đang triển
khai

52
 Mô hình dựa 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ó

53
The Unified Process (UP)

Elaborat ion
elaboration

Incept ion
inception

const ruct ion

Release
t ransit ion
soft ware increment

product ion

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

54
 MH hợp nhất
(unified model)

• Góc nhìn quản lý

Đặt vấn đề Giải quyết vấn đề Thực hiện
Vấn đề Giải pháp

Khởi đầu Soạn thảo Xây dựng Chuyển giao

Inception Elaboration Construction Transition

Thời gian

55
 MH hợp nhất
(unified model)

• Góc nhìn kỹ thuật

Bước lặp Kết quả
Bước lặp chuẩn bị Mẫu thử (maquette)
Thời gian

Bước lặp kiến trúc Nguyên mẫu kiến trúc

Bước lặp kiến trúc Nguyên mẫu kiến trúc

Bước lặp phát triển Nguyên mẫu phát triển

Bước lặp phát triển Nguyên mẫu phát triển

Bước lặp phát triển Phiên bản 

Bước lặp chuyển giao Phiên bản 

Bước lặp chuyển giao Phiên bản chính thức

56
 MH hợp nhất
(unified model)

• Kết hợp 2 góc nhìn

Bước lặp Kết quả
Bước lặp chuẩn bị Mẫu thử (maquette) Khởi đầu
Thời gian

Bước lặp kiến trúc Nguyên mẫu kiến trúc

Soạn thảo
Bước lặp kiến trúc Nguyên mẫu kiến trúc

Bước lặp phát triển Nguyên mẫu phát triển

Xây dựng
Bước lặp phát triển Nguyên mẫu phát triển

Bước lặp phát triển Phiên bản 

Bước lặp chuyển giao Phiên bản 

Chuyển giao
Bước lặp chuyển giao Phiên bản chính thức

57
MH hợp nhất và UML

58
 Pha UP

UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analy sis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

http://bit.ly/2ihOLB4 Slides copyright 2009 by

Roger Pressman.

59
 UP Work Products
Inception phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary.
One or more prot ot ypes
I nc e pt i o
n Preliminary design model
http://bit.ly/2ihOLB4 Slides copyright 2009 by
Elaboration phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analysis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot ype.
Revised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
Roger Pressman.
Construction phase
Transition phase
Design model
Soft ware component s
Delivered soft ware increment
Int egrat ed soft ware
increment Bet a t est report s
General user feedback
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
60
 Tiến trình phần mềm cá nhân (PSP)
• Lập kế hoạch. Hành động này song song với yêu cầu và phát triển cả kích cỡ
và dự đoán tài nguyên. Mặt khác, một dự đoán sai sót được tạo ra. Tất cả các
metrics được ghi lại. Các tác vụ phát triển được xác định và lịch công việc
được tạo ra.
• Thiết kế bậc cao. Các đặc điểm bên ngoài của mỗi thành phần được xây
dựng và phát triển, thiết kế cho mỗi thành phần cũng được tạo ra. Các bản
mẫu được xây dựng khi có thể và các vấn đề gặp phải được theo dõi và ghi lại.
• Review thiết kế bậc cao. Các phương pháp xác minh hình thức (Chapter 21)
được áp dụng để phát hiện các lỗi trong thiết kế. Các metrics được bảo trì cho
các tác vụ quan trọng và kết quả công việc.
• Phát triển. Thiết kế mức thành phần được tinh lọc và kiểm tra. Code được
sinh, kiểm tra, biên dịch và test. Các metrics cho tất cả các tác vụ quan trọng
và kết quả công việc.
• Mổ xẻ phân tích. Sử dụng các định lượng và metrics đã thu thập được (đây
là lượng dữ liệu thực tế đã được phân tích thống kê), hiệu quả của tiến trình
được xác định. Các định lượng và metrics cần được cung cấp và điều khiển để
sửa đổi tiến trình sao cho hiệu quả hơn.
61
 Tiến trình phần mềm theo nhóm (TSP)

• Xây dựng nhóm tự định hướng kế hoạch và theo dõi công việc của họ,
thiết lập mục tiêu, tiến trình và kế hoạch của họ. Nhóm ở đây có thể là một
nhóm hoặc một nhóm tích hợp sản phẩm từ 3 đến 20 kĩ sư.
• Cần phải cho các quản lý biết làm thế nào để huấn luyện và thúc đẩy động
lực cho nhóm của họ, và làm thế nào để giúp họ giữ vững được đỉnh cao
hiệu suất.
• Tăng tốc quá trình cải tiến phần mềm bằng việc sử dụng mô hình CMM
mức 5 cho hành vi bình thường và kì vọng.
– Mô hình năng lực trưởng thành (CMM) là thang đo sự hiệu quả của

tiến trình phần mềm, được thảo luận ở chương 30.

• Cung cấp sự hướng dẫn để trở thành tổ chức có tính trưởng thành cao.
• Tạo điều kiện cho các trường đại học giảng dạy về kĩ năng làm việc theo
nhóm.

62
 Tiến trình RUP
RUP (Rational Unified Process) là một
tiến trình mô hình hoá với UML.

63
 Các nguyên tắc cơ bản

• Lặp và tăng trưởng

– Dự án được chia thành những vòng lặp
hoặc giai đoạn ngắn để dễ dàng kiểm soát.
Cuối mỗi vòng lặp, phần thi hành được
của HT được sản sinh theo cách thêm vào
dần dần.
• Tập trung vào kiến trúc
– HT phức tạp được chia thành các modul
để dễ dàng triển khai và bảo trì. Kiến trúc
này được trình bày theo 5 góc nhìn khác
nhau. 64
 Các nguyên tắc cơ bản

• Dẫn dắt theo các ca sử dụng

– Nhu cầu người dùng thể hiện bởi các ca sử dụng. Các ca
sử dụng ảnh hưởng xuyên suốt cho mọi giai đoạn phát
triển HT, là cơ sở xác định vòng lặp và tăng trưởng, là căn
cứ để phân chia công việc trong nhóm.
– Nắm bắt nhu cầu => phát hiện các ca sử dụng. Phân tích =>
đi sâu vào các ca sử dụng. Thiết kế và cài đặt => xây dựng
HT theo các ca sử dụng. Kiểm định và nghiệm thu HT =>
thực hiện theo các ca sử dụng.
• Khống chế bởi các nguy cơ
– Phát hiện sớm và loại bỏ các nguy cơ đ/v dự án.

65
 Các pha và công đoạn
của RUP

• RUP được tổ chức thành 4 pha: Khởi

đầu, triển khai, xây dựng, chuyển giao.

Một vòng lặp

trong giai
đoạn
construction

66
 Các pha và công đoạn
của RUP

• Pha khởi đầu (inception)

– Cho một cái nhìn tổng quát về HT (chức
năng, hiệu năng, công nghệ,…) và về dự
án sẽ triển khai (phạm vi, mục tiêu, tính
khả thi,…) => đưa ra kết luận nên phát
triển dự án hay loại bỏ?
• Pha triển khai (elaboration)
– Phân tích chi tiết hơn về HT (chức năng và
cấu trúc tĩnh)
– Đề xuất một kiến trúc HT (nguyên mẫu)
67
 Các pha và công đoạn
của RUP

• Pha xây dựng (construction)

– Tập trung vào thiết kế và cài đặt HT.
– Kiến trúc HT được chi tiết hóa, chỉnh sửa.
– Kết thúc khi đã cho ra được 1 HT hoàn
chỉnh với tài liệu đi kèm.
– Là pha tiêu tốn nhiều thời gian, công sức
nhất.
• Pha chuyển giao (transition)
– Chuyển HT tới tay người dùng cuối:
chuyển đổi dữ liệu, lắp đặt, kiểm tra, đào
tạo,… 68
 Tiến trình 10 bước
dựa trên RUP

2. Nhận 7. Làm
định và nguyên
đặc tả mẫu giao
các ca diện
sử người
dụng 5. MHH dùng
1. tương tác 9.
10.
Nghiên trong các Thiết
4. Xác Cài
cứu sơ ca sử kế chi
định đặt
bộ dụng tiết
lớp/đối
tượng
3. MHH tham gia 8.
lĩnh vực các ca Thiết
ứng sử dụng 6. kế HT
dụng MHH
sự ứng
xử

Khởi đầu Triển khai Xây dựng và chuyển giao

69
 Tiến trình 10 bước
dựa trên RUP

• Nghiên cứu sơ bộ
– Đưa ra cái nhìn khái quát về HT và dự án.
– Đưa ra kết luận nên/không nên triển khai dự án.
• Nhận định và đặc tả các ca sử dụng
– Nắm bắt nhu cầu của người dùng, phát hiện các ca sử dụng
– Mỗi ca sử dụng phải được đặc tả dưới dạng kịch bản
và/hoặc một biểu đồ trình tự
• MHH lĩnh vực ứng dụng
– Đưa ra 1 MH (biểu đồ lớp) phản ánh mọi khái niệm, nghiệp
vụ.
– Các lớp ở đây là các lớp lĩnh vực.

70
 Tiến trình 10 bước
dựa trên RUP

• Xác định các đối tượng/lớp tham gia ca sử dụng

– Với mỗi ca sử dụng, phát hiện các lớp lĩnh vực,lớp điều
khiển, lớp biên.
• MHH tương tác trong các ca sử dụng
– Các đối tượng tương tác bằng cách trao đổi thông điệp.
– Tạo kịch bản của ca sử dụng: biểu đồ trình tự, biểu đồ giao
tiếp.
• MHH ứng xử
– Các đối tượng điều khiển có khả năng ứng xử đ/v các sự
kiện đến từ bên ngoài để điều khiển.
– Sử dụng biểu đồ máy trạng thái để mô tả hành vi ứng xử
của các đối tượng điều khiển.

71
 Tiến trình 10 bước
dựa trên RUP

• Làm nguyên mẫu giao diện người dùng

– Sử dụng các bộ tạo lập GUI để làm sớm nguyên mẫu giao
diện để việc MHH và cài đặt HT dễ dàng hơn.
• Thiết kế HT
– Thiết kế kiến trúc tổng thể của HT.
– Chia thành các HT con, chọn lựa loại hình điều khiển thích
hợp.
– Dùng biểu đồ thành phần mô tả các thành phần vật lý.
– Dùng biểu đồ bố trí mô tả bố trí các thành phần khả thi vào
các phần cứng.
– Thường lựa chọn kiến trúc khách/chủ (client/server)

72
 Tiến trình 10 bước
dựa trên RUP

• Thiết kế chi tiết

– Thiết kế các lớp, các liên kết, các thuộc tính, các
thao tác.
– Xác định các giải pháp cài đặt.
• Cài đặt
– Lập trình và kiểm định
– HT được nghiệm thu trên các ca sử dụng

73
 Tổng kết các mô hình

• Thác nước: mô hình tuyến tính

• Chế thử: mô hình lặp đi lặp lại
• Gia tăng: kết hợp giữa mô hình tuyến tính
và lặp đi lặp lại
• Xoăn ốc: kết hợp giữa mô hình tuyến tính
và lặp đi lặp lại
• Phát triển nhanh: mô hình lặp đi lặp lại

74
 Câu hỏi 1

• Mô hình thiết kế nào sau đây phải được

thực hiện tuần tự từ Phase này sang
Phase khác?
• A. Parallel
• B. Prototyping
• C. Rapid Application
• D. Waterfall

75
 Câu hỏi 2

• …… nhóm các phần tử của UML với

nhau tạo thành một cấu trúc mức cao
hơn (higher level).
• A. Package diagrams
• B. Deployment diagrams
• C. Class diagrams
• D. Sequence diagrams

76
 Câu hỏi 3

• Đề xuất hệ thống được phát triển ở

Phase nào của SDLC?
• A. implementation
• B. planning
• C. analysis
• D. system delivery

77
 Câu hỏi 4

• Lựa chọn nào sau đây là giải thích phù hợp nhất với
mô hình thác nước “WaterFall Model”?
a) Mỗi ứng dụng sẽ được chia thành các phần nhỏ (sub-
unit), sau đó, mỗi đơn vị sẽ được thiết kế và lập trình một
cách tuần tự, cái nọ sau cái kia.
b) Việc phát triển hệ thống sẽ được làm theo thứ tự tiến
trình, không kết quả của công việc nào được gửi ngược
lên tiến trình ở mức cao hơn.
c) Một hệ thống thực nghiệm đang khai thác được khởi tạo
và việc kiểm tra đặc tả, đánh giá yêu cầu người dùng đã
được làm ở giai đoạn trước.
d) Thời gian phát triển được rút ngắn lại bởi sự tham gia của
người dùng, bởi các nhà phát triển, bởi một số các kỹ sư
và bởi việc áp dụng có hiệu quả các công cụ.
78
 Câu hỏi 5

• Lý do khiến nhóm phát triển phần mềm nên

tạo nguyên mẫu (prototype)?
a) Tạo nguyên mẫu làm sơ sở cho việc viết đặc tả
cho sản phẩm
b) Tạo nguyên mẫu dùng làm bản test cho phần
mềm sau này
c) Tạo nguyên mẫu giúp hạ thấp chi phí sửa lỗi
d) Tất cả các phương án đều đúng

79
 Câu hỏi 6

• Trong các tính chất sau, tính chất nào là đặc

trưng của thiết kế hướng đối tượng?
a) Các đối tượng liên lạc với nhau thông qua các
biến dùng chung.
b) Các đối tượng liên lạc với nhau thông qua trao
đổi thông báo.
c) Các đối tượng độc lập với nhau và không liên
lạc.
d) Các đối tượng chia sẻ với nhau thông qua trạng
thái hệ thống tập trung.

80
 Tài liệu tham khảo

• Software & Software Engineering

• Slide được xây dựng theo cuốn Software Engineering: A
Practitioner’s Approach, 7/e by Roger S. Pressman
• Slides copyright © 1996, 2001, 2005, 2009 by Roger S.
Pressman
• http://bit.ly/2ihOLB4

81