Tìm hiểu về Quy trình phát triển phần mềm –RUP

MỤC LỤC
LỜI NÓI ĐẦU
Trong những năm qua, việc xây dựng và triển khai các chương trình phần mềm trong
đã góp phần phục vụ ngày càng tốt hơn cho công tác quản lý và điều hành của nhiều
doanh nghiệp. Tuy nhiên, cũng không thể tránh khỏi những sai sót làm ảnh hưởng không
nhỏ đến hiệu quả công việc của cán bộ quản lý, ảnh hưởng đến tiến độ phát triển, triển
khai và bảo trì chương trình của cán bộ Tin học, trong đó một nguyên nhân nổi bật đáng
chú ý là chưa thực sự áp dụng một phương pháp luận, một quy trình chuẩn được công
nhận trong quá trình phân tích thiết kế, phát triển, thử nghiệm, triển khai chương trình
dẫn tới chất lượng của chương trình tại thời điểm tung ra triển khai thử nghiệm là hết sức
thấp; nhiều lỗi không được phát hiện sớm; cách tiếp cận phát triển ứng dụng không dựa
theo công nghệ hướng đối tượng nên khi có sự thay đổi chính sách nghiệp vụ dẫn tới ứng
dụng phải đắp thêm các chức năng mới nhưng hết sức chắp vá…
Trong khi đó, trên thế giới đã từng có những bài học kinh nghiệm quý báu mà chúng
ta hoàn toàn có thể học tập được.
Xin giới thiệu một cách tổng quan nhất quy trình phân tích, thiết kế, phát triển, thử
nghiệm và triển khai một hệ thống phần mềm do hãng Rational xây dựng và đã được hầu
hết các hãng phần mềm trên thế giới áp dụng thành công trong các dự án của mình. RUP
là một quy trình vòng lặp phát triển phần mềm được tạo ra bởi công ty Rational Software,
một bộ phận của IBM từ năm 2002 (IBM Rational).
Hy vọng bài tìm hiểu sẽ cung cấp được những kiến thức cơ bản về quy trình phát
triển phần mềm RUP như lịch sử phát triển, quy trình phát triển phần mềm RUP, cấu trúc
quy trình…Do đây là lần đầu tiên đi sâu tìm hiểu về vấn đề này nên không tránh khỏi có
những thiếu sót. Nhóm rất mong nhận được những ý kiến góp ý của thầy và các bạn.
Xin chân thành cảm ơn!
I. GIỚI THIỆU QUY TRÌNH RUP (Rational Unified Process)
Trong phát triển phần mềm, có những sai sót làm ảnh hưởng không nhỏ đến chất lượng
sản phẩm. Các sai sót này có thể phát sinh từ nhiều nguồn khác nhau trong quá trình xây
dựng hệ thống, chẳng hạn như không quản lý được các yêu cầu, không phát hiện lỗi kịp
thời, không quản lý được các thay đổi của dự án.
- RUP là một quy trình vòng lặp phát triển phần mềm được tạo ra bởi công ty

Rational Software, một bộ phận của IBM từ năm 2002 (IBM Rational).
- RUP không phải là một quy trình bó hẹp cụ thể đơn nhất nhưng là một nền tảng
quy trình thích ứng với sự phát triển các tổ chức và các nhóm dự án phần mềm, tất cả sẽ
chọn các yếu tố cần thiết của quy trình để phù hợp với nhu cầu, quy mô của công ty, dự
án và sản phẩm.
- RUP là một liên kết các kiến thức cơ bản với các Artifact và mô tả chi tiết với các
loại activity khác nhau. RUP được chứa bên trong sản phẩm IBM Rational Method
Composer (RMC) cho phép tối ưu tiến trình.
- Unified Process được thiết kế từ đặc điểm chung, quy trình phạm vi rộng lớn và
RUP là một mô tả chi tiết cụ thể.
- RUP hỗ trợ các hoạt động giữa các nhóm, phân chia công việc cho từng thành viên
trong nhóm, trong từng giai đoạn khác nhau của quá trình phát triển phần mềm.
- RUP sử dụng hệ thống ký hiệu trực quan của UML và RUP được phát triển song
song với UML.
- RUP là kết quả của nhiều “best pratcices”, được hỗ trợ nhiều công cụ phát triển
phần mềm.
- RUP là một sản phẩm tiến trình có thể tùy biến.
LỊCH SỬ PHÁT TRIỂN CỦA RUP
Bắt nguồn từ mô hình xoắn ốc (spiral model) của Barry Boehm. Rational Approach
được phát triển tại Rational Software trong những năm 1980 và 1990.
Trong năm 1995 Rational Software mua lại công ty Objectory AB. RUP là kết quả
của việc trộn Rational Approach và quy trình Objectory được phát triển bởi nhà sáng lập
Objectory AB là Ivar Jacobson, Objectory là một hệ phương pháp luận hướng đối tượng
được mở rộng từ Ericsson Approach một ngôn ngữ mô hình hoá được phát triển bởi
Ericsson.
Các kết quả đầu tiên của sự kết hợp trên được biết tới là Rational Objectory Process,
RUP được thiết kế theo quy trình Objectory nhưng phù hợp với công cụ Rational Rose.
Sau khi mục tiêu được hoàn thành thì được đổi tên thành Rational Unified Process, phiên
bản đầu tiên là 5.0 được phát hành năm 1998, kiến trúc sư trưởng là Philippe Kruchten.
Phiên bản cuối cùng là RUP 7.0 được phát hành là một phần của IBM Rational

Method Composer vào tháng 11-2005.
II. RUP LÀ QUY TRÌNH TẬP TRUNG VÀO KIẾN TRÚC
1. Tầm quan trọng của kiến trúc
Ngày nay, tất cả các hệ thống đơn giản đang xây dựng và việc quản lý các hệ thống
lớn phức tạp đã trở thành mối quan tâm hang đầu của các tổ chức phát triển phần mềm.
Họ muốn hệ thống của họ chạy nhanh hơn, có tính tái sử dụng ở phạm vi lớn và nó được
xây dựng ở những thành phần đã sẵn có. Phần mềm trở thành một thứ của cải quan trọng
và các tổ chức cần có công cụ để quản lý chúng.
“Kiến trúc” được sử dụng ở khắp nơi, phản ánh sự quan tâm và sử dụng ngày càng
lớn, nhưng một khái niệm rõ về nó thực sự không cần thiết vì sự đa dạng ngữ cảnh sử
dụng của nó.
Ba điểm chính được yêu cầu để một tổ chức tiếp nhận một kiến trúc:
• Hiểu rõ mục đích: Tại sao kiến trúc quan trọng? Lợi ích đem lại từ nó? Khai thác
nó như thế nào
• Bản mô tả kiến trúc: Cách tốt nhất để đưa ra khái niệm rõ rang về kiến trúc là đạt
được sự nhất trí về sự thể hiển của nó, để nó trở thành một vật cụ thể có thể giao
tiếp, xem xét, phê bình và cải tiến một cách có hệ thống
• Một quy trình kiến trúc: tạo ra và xác nhận kiến trúc như thể nào để đáp ứng các
như cầu của dự án? Ai tạo ra nó? Cái gì là sưu liệu và tính chất luồng công việc
Quy trinh RUP chứa một số câu trả lời cho ba điểm trên. Nhưng chúng ta hãy bắt đầu
bằng cách định nghĩa rõ ràng hơn về kiến trúc phần mềm.
2. Định nghĩa kiến trúc phần mềm
Kiến trúc phần mềm chứa các giải pháp quan trọng về:
•
Tổ chức của một hệ thống phần mềm
•
Sự lựa chọn các thành phần cấu tạo thành hệ thống và giao diện cảu chúng,
cùng với hành vi của chúng, được xác định trong sự cộng tác cảu các thành
phần này
•

Sự kết hợp của những thành phần trở thành hệ thống lớn
•
Loại kiến trúc biểu diễn một tổ chức, những thành phần và giao diện của
chúng, sự cộng tác và sự kết hợp giữa chúng
Kiến trúc phần mềm không chỉ liên quan đến cấu trúc và hành vi mà còn liên quan
đến ngữ cảnh: cách sử dụng, chức năng, tốc độ, tái sử dụng, khả năng toàn diện,
những rằng buộc, cân bằng về kinh tế, kỹ thuật va mỹ thuật. Kiến trúc là một phần
của thiết kế, quyết định cách thức hệ thống được xây dựng.
Để giúp các thành viên của hệ thống có thể giao tiếp, bàn bạc và tranh luận về kiến
trúc, cần có sự trình bày theo cách hiểu của họ. Từ đó đưa ra khung nhìn về kiến trúc
(architectural view)- Đó là mô tả hệ thống được đơn giản hóa từ một góc nhìn cụ thể,
trình bày những thứ cụ thể có thể liên quan và bỏ đi những thực thể không thích hợp
từ góc độ này.
Cần phân biệt khung nhìn kiến trúc và mô hình: Mô hình là sự chình bày hoàn chỉnh
về hệ thống, còn khung nhìn chỉ tập trung vào những gì có ý nghĩa về mặt cấu trúc,
tức là những gì có tác động lớn đến cấu trúc hệ thống và tốc độ, sự hoàn thiện và tính
tiến hóa của nó
Quy trình RUP đề nghị 5 khung nhìn sau:
Hình 1: 5 khung nhìn trong RUP
• Khung nhìn logic (Logical View): Mô tả các yêu cầu chức năng của hệ thống,
tức là những gì mà hệ thống nên làm cho người dùng cuối. Đó là sự trừu
tượng của mô hình thiết kế và xác định các gói thiết kế chính, các hệ thống
con và lớp chính
• Khung nhìn thực hiện (Implementation View): mô tả tổ chức của các module
(đơn thể) phần mềm tĩnh (như mã nguồn, tập tin dữ liệu, thành phần, tập tin
thực thi, và các sưu liệu đồng hành khác) trong mooi trường phát triển.
• Khung nhìn quy trình (Process View): mô tả khía cạnh xảy ra đồng thời của hệ
thống thời gian thực (run-time) (task, thread, process cũng như sự tương tác
giữa chúng).
• Khung nhìn triển khai (Development View): cho thấy các tập tin thực thi và

các thành phần khác nhau được trineer khai trên hệ thống như thế nào. Nó giải
quyết vấn đề triển khai cài đặt và tốc độ
• Khung nhìn chức năng hệ thống (Use Case View) đóng vai trò đặc biệt đối với
kiến trúc. Nó chứa một vài kịch bản hay chức năng hệ thống chủ yếu. Ban đầu
chúng được dùng để khám phá và thiết kế kiến trúc trong pha bắt đầu và pha
chuẩn bị, nhưng sau đó chúng được dùng để xác nhận các khung nhìn khác
nhau.
3. Mục đích của kiến trúc
• Cho phép kiểm soát dự án một cách thông minh, quản lý độ phức tạp của nó và
duy trì tính toàn vẹn của hệ thống
• Cung cấp cơ sở có hiệu quả để có thể tái sử dụng trên quy mô lớn
• Cung cấp nền tảng để quản lý dự án
4. Rup là quy trình tập trung vào kiến trúc phần mềm
Hình 2: RUP tập trung vào kiến trúc phần mềm
Quy trình RUP định nghĩa 2 sưu liệu chủ yếu có liên quan đến kiến trúc:
• Mô tả kiến trúc phần mềm (Software Architecture Description-SAD) mô tả
khung nhìn kiến trúc thích hợp đối với dự án
• Kiểu mẫu kiến trúc (Architecture Template): dùng để xác nhận kiến trúc và
làm cơ sở cho các thành phần còn lại của công việc phát triển.
• Hai sưu liệu chủ chốt này làm nền tảng cho 3 sưu liệu khác
• Những nguyên tắc thiết kế
• Cấu trúc sản phẩm trong môi trường phát triển được dựa trên Physical View
• Cấu trúc nhóm làm việc (team structure)
Quy trình RUP định nghĩa: Kiến trúc sư (Architect) chịu trách nhiệm về cấu trúc. Tuy
nhiên không chỉ kiến trúc sư là những người có liên quan đến kiến trúc, mà hầu hết các
thành viên trong nhóm đều có liên quan đến việc định nghĩa và thực hiện kiến trúc, đặc
biệt là trong pha chuẩn bị
• Các thiết kế viên (designer): tập trung vào các lớp và các cơ cấu có ý nghĩa về mặt
kiến trúc, hơn là tập trung vào chi tiết các lớp
• Các nhà tích hợp (integrator): tích hợp các thành phần chính của phần mềm, để

kiểm tra giao diện (interface). Họ tập trung chủ yếu vào việc loại bỏ những rủi ro
về tích hợp có liên quan đến các thành phần chính
• Các kiểm thử viên (Tester): kiểm tra kiểu mẫu kiến trúc về kiểu mẫu và tốc độ
hoàn thiện
5.RUP là quy trình hướng chức năng
Hình 3: RUP là quy trình hướng chức năng
a) Khái niệm
Phần lớn quy trình RUP tập trung vào mô hình hóa. Các mô hình giúp ta hiểu và định
hình vấn đề cần giải quyết cúng như đưa ra giải pháp cho vấn đề đó. Quy trình RUP cung
cấp một phương pháp hiệu quả để hiểu và mô hình hóa vấn đề: đó là kỹ thuật mô hình
hóa chức năng hệ thống. Các chức năng hệ thống cung cấp một phương tiện để mô tả vấn
đề theo một cách mà đa số các thành viên hệ thống (người sử dụng, các nhà phát triển và
khách hàng) có thể hiểu được
Để xây dựng một mô hình chức năng hệ thống, RUP định nghĩa 2 khái niệm chính:
• Chức năng hệ thống: là một chuỗi các hành động tuần tự mà hệ thống thực hiện và
tạo ra một kết quả có thể quan sát được đối với một tác nhân hệ thống cụ thể
• Tác nhân hệ thống: là người hay một thứ nào đó nằm ngoài hệ thống và tương tác
hệ thống
Ngoài ra, mô tả chức năng hệ thống là mô tả nhưng gì mà hệ thống phải làm khi một
chức năng hệ thống được thực hiện. Chức năng của hệ thống được định nghĩa bởi tập hợp
các chức năng hệ thống, mà mỗi chức năng hệ thống trình bày một luồng các sự kiện cụ
thể
Một luồng sự kiện mô tả chuỗi các hành động giữa các tác nhân hệ thống và hệ thống. Nó
được ghi bằng ngôn ngữ tự nhiên, theo một lối hành văn đơn giản, nhất quán và sử dụng
chính xác thuật ngữ chuyên môn.
Chúng ta không cần phải mô tả luồng thay thế bằng chức năng hệ thống riêng biệt.
Thay vào đó, ta sẽ nhóm chúng với các luồng sự kiện khác có liên quan. Nhóm này định
nghĩa một lớp chức năng của hệ thống. Thể hiện (instance) của một lớp chức năng hệ
thống là một luồng cụ thể các sự kiện và nó được gọi là một kịch bản (scenairo)
Mô hình chức năng hệ thống bao gồm tập hợp tất cả các chức năng hệ thống là một hệ

thống hay một phần của hệ thống, cùng với tập hợp tất cả các tác nhân hệ thống tương tác
với những chức năng hệ thống này, do đó nó mô tả đầy đủ chức năng hệ thống. Nó cung
cấp một mô hình các chức năng dự định và môi trường của hệ thống, đồng thời cũng có
thể xem như là một hợp đồng giữa khách hang và nhà phát triển. Quy trình RUP sử dụng
lược dồ chức năng hệ thống và lược đồ hoạt động để mô tả trực quan mô hình trúc năng
hệ thống, bao gồm các mối quan hệ có thể có của các chức năng hệ thống.
b) Xác định chức năng hệ thống
Các chức năng được tìm thấy khi ta xem xét các kết quả mà hệ thống cung cấp cho một
tác nhân hệ thống và khi ta gom chuỗi các hành động mà hệ thống phải thực hiện để tạo
ra các kết quả đó. Nói cách khác, chức năng hệ thống đáp ứng một mục đích cụ thể của
một tác nhân hệ thống và được thực hiện bởi hệ thống.
c) Cải tiến các chức năng hệ thống
Chúng ta nên bắt đầu bằng cách phác thảo các chức năng hệ thống, trước khi tập trung
vào chi tiết của nó. Ở vòng lặp ban đầu trong suốt pha chuẩn bị, chỉ có một ít các chức
năng hệ thống có ý nghĩa về mặt kiến trúc được mô tả chi tiết. Mô hình thường chứa các
chức năng hệ thống đơn giản đến mức không cần một mô tả chi tiết luồng sự kiện mà chỉ
cần một phác thảo là đủ
d) Tổ chức các chức năng hệ thống
Tổ chức các chức năng hệ thống bằng cách sử dụng các gói chức năng hệ thống (package
use case), tức là gom nhóm các chức năng hệ thống liên quan đến nhau. Ta cũng có thể
khai thác các mối quan hệ giữa các chức năng hệ thống này. Để làm được điều này cần
quan sát kỹ các sự kiện
e) Các chức năng hệ thống trong chương trình
RUP là một quy trình hướng chức năng. Do đó các chức năng hệ thống định nghĩa là cơ
sở nền tản cho toàn bộ quy trình phát triển
Mô hình chức năng hệ thống là kết quả của các luồng công việc, các yêu cầu. Trong đó,
các chức năng hệ thống được dùng để nắm bắt những gì mà hệ thống phải thực hiện từ
góc nhìn người dùng. Do đó các chức năng hệ thống hoạt động như là một ngôn ngữ
chung để khách hàng/người sử dụng và các nhà phát triển giao triếp với nhau
Trong phân tích và thiết kế, các chức năng hệ thống là cầu nối để kết hợp các yêu cầu và

các hoạt động thiết kế. Chúng phục vụ làm nền tảng cho việc thực hiện hóa các chức
năng hệ thống.
Trong suốt quá trình thực hiện, mô hình thiết kế là bản đặc tả thực thi (Implementation
Specification). Bởi các chức năng hệ thống là cơ sở của mô hình thiết kế, chúng được
thực hiện dưới dạng các lớp thiết kế. Việc hiện thực hóa chức năng hệ thống trong mô
hình thiết kế được sử dụng để hiểu những khía cạnh động của hệ thống và xác định
những gì cần tối ưu hóa tốc độ
Trong quá trình kiểm thử, cá chức năng hệ thống cấu tạo thành nền tảng để xác định các
chức năng và quy trình kiểm chứng. Nói cách khác mỗi chức năng hệ thống thực hiện để
kiểm chứng hệ thống
Trong quá trình dự án, các chức năng hệ thống được dùng để định nghĩa nội dung các
vòng lặp
Trong quá trình triển khai, các gói chức năng hệ thống có thể phục vụ để lập kế hoạch
cho việc triển khai theo giai đoạn hay định nghĩa các biểu thể của hệ thống
Trong mô hình hóa nghiệp vụ (Business Modeling) cũng sử dụng khái niệm chức năng
nhưng ở mức độ nghiệp vụ. Các mô hình chức năng nghiệp vụ mô tả các quy trình nghiệp
vụ ở mức cao, đồng thời cung cấp ngữ cảnh và luồng thông tin có thể mô tả chức năng hệ
thống của hệ thống.
III. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM RUP
1. Những bài học của Rational Unified Process
Quy trình phát triển hệ thống phần mềm của hãng Rational dựa trên cơ sở 6 bài học thực
tế rút ra được từ quá trình thành công cũng như thất bại của các dự án, đó là:
•
Phát triển tái lập (Develop software iteratively)
•
Quản trị yêu cầu (Manager requirements)
•
Sử dụng kiến trúc thành phần (Use component-base architectures)
•
Mô hình hóa trực quan (Visually model software)

•
Liên tục kiểm tra chất lượng (Verify software quality)
•
Quản trị thay đổi (Control changes to software)
 Phát triển tái lập
Chia quá trình phát triển thành các chu kỳ khác nhau, ở những chu kỳ đầu sẽ lựa chọn
phát triển trước những chức năng mấu chốt, quyết định toàn bộ sự thành công hay thất
bại của dự án, mỗi chu kỳ như vậy sẽ sinh ra một phiên bản thi hành được của ứng dụng
đang phát triển.
Việc phát triển tái lập như vậy có lợi điểm là: giải quyết được những rủi ro lớn trước khi
có những đầu tư cho các bước tiếp theo, cho phép sớm tiếp nhận được những phản hồi
của người sử dụng, thực hiện việc thử nghiệm và tích hợp một cách thường xuyên liên
tục, cho phép tập trung triển khai từng phần hệ thống.
 Quản trị yêu cầu:
Quản trị yêu cầu trong suốt quá trình phát triển đảm bảo giải quyết đúng vấn đề gặp phải
và xây dựng đúng hệ thống cần xây dựng, quản trị yêu cầu cho phép theo vết được các
vấn đề đặt ra từ nhu cầu của người sử dụng hệ thống đến các đặc tính của hệ thống, các
chức năng, các vấn đề về phân tích, thiết kế và kịch bản thử nghiệm.
 Sử dụng kiến trúc thành phần:
Chia nhỏ hệ thống phần mềm ra các thành phần nhỏ tương đối độc lập nhưng lại có quan
hệ với nhau theo những nguyên tắc nhất định.
Việc sử dụng kiến trúc thành phần cho phép hệ thống xây dựng vừa đáp ứng được các
yêu cầu ở hiện tại và những mở rộng trong tương lai, nó cho phép có thể tái sử dụng các
thành phần đã được xây dựng trước đó hoặc có thể mua các thành phần đã được các hãng
trên thế giới xây dựng từ đó có thể đẩy nhanh quá trình phát triển ứng dụng.
 Mô hình hóa trực quan:
Sử dụng ngôn ngữ chuẩn UML (Unified Modelling Language) để mô hình hóa toàn bộ hệ
thống phần mềm cần phát triển. Việc mô hình hóa trực quan bằng ngôn ngữ UML cho
phép: thu thập được toàn bộ cấu trúc và hành vi của hệ thống, chỉ ra cách thức để các
thành phần của hệ thống có thể kết hợp với nhau, đảm bảo sự thống nhất giữa bản thiết kế

và bản chương trình phần mềm được xây dựng, nâng cao chất lượng sự trao đổi giữa các
thành viên trong nhóm phát triển, giữa các nhóm phát triển với nhau.
 Liên tục kiểm tra chất lượng:
Việc kiểm tra thử nghiệm được thực hiên ở tất cả các chu kỳ phát triển ứng dụng và kiểm
tra trên cả 3 mặt chính: kiểm tra về mặt chức năng ứng dụng (thử nghiệm tất cả các kịch
bản tình huống sử dụng), kiểm tra tốc độ (hiệu năng) và kiểm tra độ tin cậy của ứng
dụng.
 Quản trị thay đổi:
Đảm bảo quản trị được các thay đổi về yêu cầu, các thay đổi phiên bản hay thay đổi cấu
hình trong suốt quá trình phát triển, triển khai, bảo trì và nâng cấp ứng dụng.
2. Kiến trúc tổng quan của quy trình RUP
Hình 1: Thể hiện cấu trúc của quy trình RUP. Nó gồm 2 phần:
Hình 4 : Quy trình RUP
- Trục hoành: là chiều biểu diễn thời gian và vòng đời của quy trình: thể hiện mặt
động của chu kì (cycles), được biểu diễn dưới dạng các giai đoạn (phase), các vòng lặp
(interations) và các cột mốc thời gian (milestones).
Hình 5:
- Trục tung: là chiều biểu diễn các tiến trình của quy trình, là các công việc được
nhóm lại một cách logic theo bản chất của chúng, thể hiện mặt tĩnh dưới dạng các thành
phần của chu trình như các tiến trình, các kết quả sinh ra (artifacts_WHAT), cá nhân hay
một nhóm thực hiện (worker_WHO), giai đoạn công việc hoạt động liên quan với nhau
(workflows_WHEN) và các đơn vị công việc (activities_HOW).
- Luồng công việc chính:
 Business modeling
 Requirement
 Analysis & Design
 Implemention
 Test
 Deployment
- Luồng công việc hỗ trợ:

 Project Management
 Configuration and Change Management
 Enviroment
3. Cấu trúc tĩnh của quy trình
a) Mô hình của quy trình
Quy trình mô tả ai đang làm gì và bằng cách nào, và khi nào. Quy trình RUP được
biểu diễn thông qua việc sử dụng bốn thành phần mô hình hóa chủ yếu : Worker (WHO-
ai), Activiy–hoạt động (HOW-bằng cách nào), Artifact – Sưu liệu (WHAT-cái gì),
Workflow-luồng công việc (WHEN-khi nào)
 Worker
Worker định nghĩa công việc và các trách nhiệm của môt cá nhân hay một tập thể.
Trong chu trình RUP, Worker là các vai trò chỉ ra cách thức để cá nhân làm việc. Một
worker có thể thực hiện một hoặc nhiều vai trò và sở hữu một bộ các sưu liệu (Artifact).
Các ví dụ về worker: Phân tích viên hệ thống, thiết kế viên, kiến trúc sư, kiểm thử viên,
….
Lưu ý rằng các worker không phải là cá nhân, mà thay vào đó là các worker mô tả
cách thức các cá nhân làm việc và trách nhiệm mỗi cá nhân.
 Activity (Hoạt động)
Hoạt động là một đơn vị công việc mà một cá nhân được yêu cầu thực hiện,và tạo ra
một kết quả có ý nghĩa trong ngữ cảnh của dự án. Mỗi hoạt động có một mục đích rõ
rang và được phân công cho một thừa tác viên cụ thể.
Ví dụ:
- Tìm các chức năng hệ thống (use case) và tác nhân hệ thống (actor): được thực
hiện bởi worker : Phân tích viên hệ thống
- Xem xét các bản thiết kế được thực hiện bởi worker: Nhân viên xem xét thiết
kế
Trong thuật ngữ hướng đối tượng, worker là một đối tượng và các hoạt động mà các
worker thực hiện là các thao tác được thực thi bởi các đối tượng đó.
Trong quy trình RUP, hoạt động được ký hiệu bằng cách thêm đầu ngữ Hoạt động
Ví dụ: Hoạt động tìm các chức năng hệ thống và tác nhân hệ thống.

Hoạt động được chia làm nhiều bước thuộc 3 loại chính sau
- Các bước khảo sát: các worker phải hiểu bản chất của công việc, thu thập và
xem xét các dữ liệu đầu vào và định dạng kết quả.
- Các bước thực hiện: worker tạo mới hay cập nhật một vài sưu liệu.
- Các bước kiểm tra: worker kiểm tra lại các kết quả theo một số tiêu chí nào đó.
Ví dụ: Hoạt động tìm các chức năng hệ thống và tác nhân hệ thống được chia thành 7
bước sau:
• Tìm các tác nhân hệ thống
• Tìm các chức năng hệ thống
• Mô tả cách thức các tác nhân hệ thống và các chức năng hệ thống tương tác với
nhau
• Đóng gói các chức năng hệ thống và các tác nhân hệ thống
• Trình bày mô hình chức năng hệ thống (mô hình use-case) bằng lược đồ chức
năng hệ thống (lược đồ use-case)
• Phát triển mô hình chức năng hệ thống tổng quát
• Đánh giá kết quả
Trong đó: Bước 1 đến bước 3 là các bước khảo sát, bước 2 đến bước 6 là các bước thực
hiện, liên quan đến việc thu thập kết quả trong mô hình chức năng hệ thống; bước 7 là
bước kiểm tra, yêu cầu các worker phải đánh giá chất lượng của các kết quả theo một vài
tiêu chí nào đó.
 Artifact
Artifac là những thông tin được tạo ra, thay đổi hay sử dụng được bởi một quy trình. Đó
là sản phẩm hữu hình của dự án. Các sưu liệu được các worker sử dụng làm đầu vào để
thực hiện một hoạt động, và chúng cũng là kết quả hay đầu ra của những hoạt động đó.
Artifac có thể có những hoạt động sau đây:
 Mô hình, như mô hình chức năng của hệ thống hay mô hình thiết kế
 Các thành phần của mô hình, như lớp, chức năng hệ thống, hay hệ thống con
(subsystem)
 Tài liệu như tài liệu của chức năng nghiệp vụ (business use case)
 Mã nguồn

Các Artifac có thể chứa các sưu liệu khác (Ví dụ: mô hình thiết kế chứa nhiều lớp)
Các Artifac chỉ thuộc trách nhiệm của một worker. Tuy mỗi người có thể sở hữu một sưu
liệu, nhưng nhiều người cũng có thể sử dụng sưu liệu này, thậm chí có thể điều chỉnh nếu
người đó cho phép.
Tương tự như Worker và Activity, trong quy trinh RUP, sưu liệu cũng được ký hiệu bằng
cách thêm đầu ngữ Sưu liệu. Ví dụ: Sưu liệu Đặc tả chức năng hệ thống.
Các sưu liệu của quy trình RUP được tổ chức thành 5 nhóm:
 Nhóm quản lý: Bao gồm các sưu liệu liên quan nghiệp vụ phần mềm và quản lý
dự án
 Nhóm các yêu cầu: Bao gồm các sưu liệu định nghĩa hệ thống phần mềm được
phát triển
 Nhóm thiết kế: chứa mô tả hệ thống được xây dựng
 Nhóm cài đặt: Bao gồm mã nguồn,tập thực thi và các tập tin khác có liên quan
 Nhóm triển khai: Bao gồm các tài liệu cài đặt hướng dẫn sử dụng và tài liệu huấn
luyện
Hình 6: Worker-Activities-Artifact
 Workflow (Luồng công việc)
Luồng công việc mô tả một chuỗi các hành động theo một trình tự để có thể tạo ra một
kết quả có thể quan sát được. trong thuật ngữ UML, một luồng công việc có thể được
diễn tả bằng lược đồ trình tự (lược đồ sequence), lược đồ cộng tác (lược đồ collaboration)
hay lược đồ hoạt động (lược đồ activity).
Trong quy trình RUP ta tổ chức tập hợp các hoạt động trong các luồng công việc bằng
cách dùng: các luồng công việc, chi tiết các luồng công việc và các kế hoạch lặp.
Có 9 luồng công việc trong quy trình RUP,bao gồm 6 luồng công việc chính và 3 luồng
công việc phụ. Các luồng công việc chính bao gồm :
 Luồng công việc mô hình hóa nghiệp vụ
 Luồng công việc các yêu cầu
 Luồng công việc phân tích và thiết kế
 Luồng công việc thực hiện (implementation)
 Luồng công việc kiểm thử

 Luồng công việc triển khai (development)
Các luồng công việc phụ bao gồm:
 Luồng công việc quản lý dự án
 Luồng công việc cấu hình và quản lý thay đổi
 Luồng công việc môi trường
Mặc dù các luồng công việc chính trông giống các pha tuần tự trong quy trình thác nước
truyền thống, nhưng các pha của một quy trình lặp thì hoàn toàn khác và các luồng công
việc được xem xét trong chu trình sống. Thực tế, luồng công việc chính của một dự án
bao gồm 9 luồng công việc này và chúng lặp lại với những mục đích và mức độ khác
nhau tại mỗi lần lặp.
Chi tiết các luồng công việc: Quy trình RUP sử dụng chi tiết các luồng công việc để diễn
tả một nhóm các hoạt động cụ thể có liên quan mật thiết với nhau. Chi tiết các luồng công
việc cho thấy các luồng thông tin (các sưu liệu đầu vào và ra từ các hoạt động) mô tả
cách thức các hoạt động tương tác với nhau thông qua các sưu liệu khác nhau.
Các kế hoạch lặp: Các kế hoạch lặp dùng để mô tả quy trình từ góc độ xem xét những gì
xảy ra trong một vòng lặp thông thường(giống với những gì mà luồng công việc chính
phải xử lý)
Hình 7
b) Những thành phần bổ xung của quy trình
Các Worker, Activity, Artifact là những thành phần cơ bản trong cấu trúc tĩnh của quy
trình RUP. Tuy nhiên một số thành phần khác được bổ xung vào các hoạt động và sưu
liệu nhằm làm cho quy trình dễ hiểu và dễ sử dụng hơn, đồng thời cung cấp sự hướng dẫn
toàn diện cho người thực hành. Những thành phần bổ xung là:
 Các nguyên tắc (guidelines): là những nguyên tắc, chỉ dẫn, …để hỗ trợ các hoạt
động và các bước. Đó còn là các kỹ thuật để tạo ra các sưu liệu nhất định, hay các
cách biến đổi một sưu liệu này thành một sưu liệu khác…. Những nguyên tắc này
còn được sử dụng để xem xét các hoạt động và đánh giá chất lượng các sưu liệu.
 Các khuôn mẫu (templates): là những mô hình hay kiểu mẫu (prototype) của các
sưu liệu, được kết hợp với các mô tả sưu liệu để tạo ra các sưu liệu tương ứng.
 Các chỉ dẫn sử dụng công cụ (tool mentors): Là những phương tiện hướng dẫn, bổ

xung nhằm để bàn cách thức thực hiện, các bước để sử dụng một công cụ phần
mềm cụ thể.
 Một số khái niệm chủ chốt: như vòng lặp, sưu liệu, pha, rủi ro…
4. Cấu trúc động của quy trình
a. Quy trình tuần tự
Lúc đầu quy trình tuần tự được xem như là một phương pháp hợp lý nhất để phát triển hệ
thống. Tuy nhiên trải qua nhiều thập niên, đã cho thấy các dự án sử dụng quy trình tuần
tự thường ít thành công bởi những nguyên nhân sau:
 Sự giả định ban đầu có sai sót
 Thất bại trong việc kết hợp các nhân tố cong người
 Chúng ta vẫn còn đang trong giai đoạn thăm dò của công nghệ phần mềm, và
không có nhiều khinh nghiệm. Đây là lý do chính.
b. Quy trình lặp
Cách tiếp cận tuần tự hay thác nước chỉ thích hợp và thành công đối với những dự án nhỏ
và ít rủi ro. Như vậy, câu hỏi đặt ra là tại sao ta không chia nhỏ một chu trình sống của
một dự án thành những thác nước nhỏ nối tiếp nhau? Bằng cách này ta có thể giải quyết
một số yêu cầu và rủi ro, thiết kế một ít, thực hiện một ít, kiểm tra một ít rồi lại lấy thêm
các yêu cầu, thiết kế thêm, xây dựng thêm…cho đến khi hoàn tất. Đây gọi là phương
pháp lặp (hay còn gọi là phát triển lặp).
Hình 8: Quy trình lặp
- Phát triển lặp là gi?
• Một dự án sử dụng quy trình phát triển lặp lại có một vòng đời chứa các
quy trình lặp. Một quá trình lặp là sự kết hợp chặt chẽ một chuỗi các hoạt
động: mô hình nghiệp vụ, tiếp nhận yêu cầu, phân tích và thiết kế, thực thi,
kiểm lỗi và triển khai với mức độ lặp không giống nhau, tùy theo vị trí cụ
thể của vòng phát triển.
• Quản lý, tiếp nhận yêu cầu và thiết kế là các hoạt động trọng điểm trong
giai đoạn khởi tạo và phân tích chi tiết dự án; các hoạt động thiết kế, thực
thi và kiểm lỗi đóng vai trò chủ chốt trong giai đoạn xây dựng; và các hoạt
động kiểm lỗi, triển khai đóng vai trò chủ đạo trong giai đoạn chuyển giao

dự án.
• Quá trình lặp được quản lý bởi timeboxed (thuật ngữ của RUP) được các
nhóm phát triển họp bàn và thiết lập
- Tại sao phải phát triển lặp lại ?
• Một thiết kế ban đầu chỉ là một sản phẩm chưa hoàn thiện, dựa trên các yêu
cầu căn bản, về sau quá trình thiết kế càng phát hiện ra thêm nhiều nhược
điểm đó là kết quả trả giá từ việc chạy thử và trong một số trường hợp dự
án phải hủy bỏ
• Tất cả các dự án đều có một tập các rủi ro phức tạp. Lúc ban đầu bạn có thể
xác định để ngăn ngừa một vài rủi ro theo đúng như kế hoạch của mình.
Tuy nhiên có rất nhiều rủi ro mà bạn không thể phát hiện ra một các đơn
giản, trơn tru cho đến khi bạn cố gắng tích hợp hệ thống. Bạn sẽ không bao
giờ có thể dự đoán trước được tất cả các rủi ro khi không quan tâm đến
kinh nghiệm của nhóm phát triển.
Hình 9:
- Lợi ích của phát triển lặp lại
• Hạn chế được nhiều rủi ro do các phần tử được tích hợp, xây dựng dần dần
• Cho phép thay đổi các yêu cầu, các phương thức cho thích hợp hơn
• Các tổ chức có thể nắm được phương pháp này và phát triển cho qui trình
của họ
• Tăng khả năng tái sử dụng
IV. CÁC PHA CỦA QUY TRÌNH RUP
1. Vòng đời
Hình10: Vòng đời quy trình
Để vận dụng được sáu bài học nói trên Rational đưa ra quy trình phát triển hợp nhất
(Rational Unified Process – RUP) gồm các giai đoạn (phase) và các luồng công việc
(workflow). Từ phương diện quản lý, vòng đời của một phần mềm theo RUP được chia
theo thời gian qua bốn giai đoạn nối tiếp nhau, mỗi giai đoạn có một mốc quan trọng, mỗi
giai đoạn thực chất là khoảng giữa của 2 điểm mốc. Cuối mỗi giai đoạn, bộ phận kiểm
định sẽ thực hiện thẩm định các đối tượng của giai đoạn này, nếu việc kiểm tra thích hợp

thì dự án sẽ được chuyển sang giai đoạn tiếp theo
2. Các giai đoạn (Phase)
Hình 11 : Mô hình các giai đoạn
a) Pha bắt đầu (Inception phase)
Pha bắt đầu bao gồm hình dung bức tranh tổng quát về sản phẩm cuối cùng và phác thảo
chức năng chi người dùng, đồng thời xác định phạm vi của dự án. Mục tiêu hàng đầu của