 Mô hình RUP (Rational Unified Process).

 Mô hình chữ V (V-model).

 Mô hình tiến hóa (Evolutionary).

A. ĐÔI NÉT VỀ RUP

RUP (Rational Unified Process) là framework qui trình phát triển phần mềm
mang tính lặp được tạo bởi Công ty Rational Software (được IBM mua năm
2003). IBM Rational Method Composer (RMC) được tích hợp vào RUP với
mục đích có thể chỉnh sửa qui trình theo mục đích riêng (customization).

Dựa trên 6 kinh nghiệm thực tiễn của công nghệ phần mềm hiện đại:
1) Phát triển lặp với “rủi ro” là nhân tố dẫn dắt chính.
2) Quản lý yêu cầu
3) Sử dụng kiến trúc thành phần (component)
4) Mô hình phần mềm một cách trực quan
5) Kiểm tra chất lượng liên tục
6) Kiểm soát sự thay đổi

Các Giai đoạn và các vòng lặp trong vòng đời phát triển (Phases and
Iterations)
Mỗi vòng đời phần mềm được chia thành nhiều vòng (cycles), mỗi vòng
(cycle) làm việc trên một phiên bản mới của sản phẩm. RUP chia 1 vòng
phát triền (development cycle) thành 4 giai đoạn (phase) liên tiếp: Inception
phase, Elaboration phase, Construction phase, Transition phase.

Khởi động (inception)

Trong pha khởi động cần đưa ra tình huống về mặt nghiệp vụ có thể có đối
với hệ thống và xác định phạm vi của dự án. Các tình huống nghiệp vụ gồm:
tiêu thức đánh giá sự thành công, đánh giá rủi ro, xác định các nguồn lực cần
thiết cho dự án và một bản kế hoạch tóm tắt chỉ ra lịch trình của các điểm
mốc chủ yếu của dự án. Cuối pha này cần kiểm tra các mục tiêu của quá
trình phát triển của dự án và quyết định có tiếp tục quá trình phát triển hay
không.
Phác thảo (Elaboration)
Mục tiêu của pha này là phân tích các vấn đề nghiệp vụ, xác định kiến trúc
hợp lý, xây dựng kế hoạch cho dự án, giới hạn các yếu tố rủi ro cao nhất.
Những quyết định về mặt kiến trúc cần được đưa ra cho toàn bộ hệ thống,
đồng thời cần mô tả hầu hết các yêu cầu của hệ thống. Cuối pha này cần
kiểm tra các mục tiêu và phạm vi chi tiết của hệ thống, sự lựa chọn về kiến
trúc và cách xử lý các rủi ro có thể đồng thời quyết định có tiếp tục chuyển
sang pha xây dựng hay không.

Xây dựng (Contruction)

Trong pha này bạn phát triển một cách tái lập và tăng dần toàn bộ sản phẩm
đầy đủ, sẵn sàng chuyển giao tới cộng đồng người sử dụng. Pha này bao
gồm việc mô tả các yêu cầu còn lại chưa được xác định, xác định các “tiêu
thức chấp nhận”, làm mịn thiết kế và hoàn thành việc lập trình ứng dụng.
Cuối pha này cần xác định liệu hệ thống phần mềm, các điểm triển khai và
người dùng đã sẵn sàng đi vào hoạt động chưa.

Chuyển giao (Deployment)

Trong pha này, cần đưa hệ thống phần mềm tới cộng đồng người sử dụng.
Khi hệ thống đã tới tay người sử dụng thì các vấn đề thường phát sinh đòi
hỏi những bước tiếp theo là căn chỉnh hệ thống, xác định các vấn đề chưa
được phát hiện trước đó hay hoàn thiện các chức năng trước đó bị trì hoãn.
Pha này thường bắt đầu với việc tung ra phiên bản Beta và sau đó là thay thế
bởi bản chương trình đầy đủ.

B. CHI TIẾT VỀ RUP

Cấu trúc tĩnh của qui trình
Một qui trình mô tả ai (who) đang làm gì (what), làm như thế nào (how) và
làm khi nào (when). RUP sử dụng 4 yếu tố chính trong mô hình.
Workers – Who
Activities – How
Artifacts – What
Workflows – When

a) Worker định nghĩa các hành vi, trách nhiệm của một cá nhân hoặc một
nhóm làm việc với nhau còn gọi là team.

b) Activity của một worker là một đơn vị công việc được giao cho một cá
nhân thực hiện. Activity có mục đích rõ ràng, thường là yêu cầu tạo mới
hoặc update một số artifacts như là model, class, hoặc plan. Mỗi một activity
được phân công cho một workder rõ ràng.

c) Artifact là một mẫu thông tin được tạo, chỉnh sửa hoặc được sử dụng bởi
qui trình. Artifact là những sản phẩm hữu hình của dự án, là vật mà dự án
tạo ra hoặc sử dụng để đạt đến sản phẩm cuối cùng. Artifact thường được
nhập bởi worker để thực hiện một activity, hoặc là kết quả của các activities.

Artifact có thể có rất nhiều dạng:

-Mô hình: use-case model, design model.
-Yếu tố mô hình: class, use-case hoặc subsystem
-Tài liệu: Business case hoặc tài liệu kiến trúc phần mềm
-Source code
-Các file thực thi (Executables)

d) Workflow :Chỉ là một bản liệt kê các workers, activities và artifact thì
không thể tạo thành qui trình. Chúng ta cần một cách mô tả tuần tự đầy ý
nghĩa các activities để tạo ra kết quả có giá trị và chỉ rõ sự tương tác giữa
các worker.
Workflow là một chuỗi các hành động diễn ra liên tiếp nhằm tạo ra kết quả
có giá trị rõ ràng.
Trong UML, workflow có thể diễn đạt bằng sequence diagram, collaboraion
diagram hoặc activity diagram.
Mô hình chữ V

Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn
với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng
nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm
thử tương ứng như được minh họa trong hình sau:
Tinh thần chủ đạo của V-model là các hoạt độngkiểm thử phải được tiến hành song song
(theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các
hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song
với các hoạt động phân tích và thiết kế hệ thống.

Ưu điểm:
• Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động
liên quan đến đặc tả yêu cầu và thiết kế. Hay nói cách khác, mô hình này khuyến
khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớm trong
chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực.
Nhược điểm:
• Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án.
Nhưng đa số dự án thực tế cho thấy yêu cầu phần mềm thường ẩn chứa không
nhiềuthì ít những điểm không chắc chắn.
• Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu
kỳ dự án. Đặc biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn,
nếu có trục trặc xảy ra doyêu cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu
hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo
đúng mô hình, nên dẫn đến bản đặc tả phần mềm cũng như một số sản phẩm trung
gian khác như bản thiết kế,cho dù có được cập nhật sau này cũng có thể không
phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.
• Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn
trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử
dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của
họ vào thời điểm cuối dự án.
 • Nói chung, mô hình này thườngẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai
đoạn cuối cùng và chi phí để sửa chữa có thể rất cao.
Ứng dụng:
• Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường
xuất phát từ sản phẩm đã đạt mức ổn định.
• Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự
án.
• Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều
kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.
• Dự án được xác định hầu như không có rủi ro.

Mô hình tiến hóa

Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt:

• mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.

• những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng
trong những phiên bản sau.

Hình 4 minh họa mô hình tiến hóa, cho thấy một số phần của hệ thống phần mềm có thể
đuợc xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế.

Ưu điểm:

Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong
các giai đoạn phân tích phát triển yêu cầu và thiết kế.

Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ
của dự án.

Nhược điểm:
Làm chậm quá trình phát triển yêu cầu và có thể ảnh hưởng sự chú ý đến các công việc
trung gian như kiểm tra mã nguồn, thực hiện kiểm thử cấp thấp...

Dễ dẫn đến kết cấu của hệ thống kém.

Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém.

Ứng dụng:

Hệ thống tương tác nhỏ và vừa; phần GUI của những hệ thống lớn; những hệ thống cần
chu kỳ phát triển ngắn.

Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án.