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

RUP ra đời trở thành chiến lược vững vàn của Rational:

• Một qui trình hướng dẫn phát triển phần mềm
• Công cụ tạo tự động ứng dụng theo qui trình
• Dịch vụ làm cho Qui trình và Tool được hiệu quả hơn

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.

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.

Những bài học của Rational

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à:

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

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

3. Sử dụng kiến thứ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.

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

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

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

Cách vận dụng
Để 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 pha (phase) và các giai đoạn công việc (workflow) mà đội thực hiện dự án cần tuân theo. Các pha của RUP bao gồm:


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 đủ.

Các giai đoạn công việc của RUP bao gồm:
- Mô hình hóa nghiệp vụ (business modeling): mô tả cấu trúc và quy trình nghiệp vụ.
- Xác định yêu cầu (requirement): mô tả nghiệp vụ bằng phương pháp “tình huống sử dụng” (use case base method)
- Phân tích và thiết kế (analysis & design): mô tả kiến trúc hệ thống thông qua các sơ đồ phân tích thiết kế.
- Lập trình: thực hiện các việc xây dựng chương trình bằng ngôn ngữ lập trình.
- Thử nghiệm: mô tả các tình huống và kịch bản thử nghiệm, tiến hành thử nghiệm hệ thống phần mềm.
- Triển khai: đưa hệ thống phần mềm vào sử dụng.
- Quản trị cấu hình và quản trị thay đổi: kiểm soát các thay đổi và duy trì sự hợp nhất của các thành phần dự án.
- Quản trị dự án: quản lý toàn bộ quá trình làm việc của dự án.
- Môi trường: đảm bảo các hạ tầng cần thiết để có thể phát triển được hệ thống.

Quá trình thực hiện qua toàn bộ các pha được gọi là chu trình phát triển; Kết quả của quá trình phát triển các RUP được gọi là các Artifact, bao gồm các mô hình và các bộ tài liệu, đó là:
- Mô hình nghiệp vụ: là sự trừu tượng hóa tổ chức nghiệp vụ của hệ thống cần xây dựng.
- Mô hình tình huống sử dụng: các yêu cầu mang tính chức năng của hệ thống phần mềm.
- Mô hình phân tích và thiết kế: mô hình tổ chức các đối tượng của hệ thống phần mềm để giải quyết vấn đề của bài toán.
- Mô hình triển khai: mô hình kiến trúc phần cứng và phần mề hệ thống cần thiết để triển khai.
- Mô hình thử nghiệm: xác định các bước mà hệ thống sẽ được kiểm tra.
- Bộ tài liệu về xác định yêu cầu hệ thống: mô tả những gì hệ thống cần lầm.
- Bộ tài liệu thiết kế: mô tả hệ thống sẽ được xây dựng như thế nào.
- Bộ tài liệu lập trình: mô tả các thành phần ứng dụng được phát triển như thế nào.
- Bộ tài liệu triển khai: mô tả cấu trúc triển khai hệ thống.
Để áp dụng được quy trình phát triển hệ thống phần mềm của Rational thì yêu cầu không thể thiếu là hệ thống các phần mềm công cụ hỗ trợ. Hãng Rational đã xây dựng một hệ thống công cụ như vậy, mà tiêu biểu và thường dùng nhất cho hệ thống tài chính ngân hàng là:
- Phần mềm Rational Requisite Pro: cho phép phân tích các yêu cầu, xây dựng kế hoạch thực hiện, xác định các tác nhân của hệ thống cùng những tình huống sử dụng.
- Phần mềm Rational Rose: cho phép xây dựng các mô hình phân tích, thiết kế, triển khai.
- Phần mềm Rational XDE: cho phép vừa xây dựng các mô hình vừa kết sinh mà nguồn chương trình song song vớinhau.
- Phần mềm Rational Clear Case: quản trị dự án phân tích thiết kế, cho phép làm việc theo nhóm.

Như vậy, việc áp dụng quy trình chuẩn để xây dựng hệ thống phần mềm đã trở thành một tất yếu đối với bất kỳ tổ chức, đơn vị nào muốn nâng cao và đảm bảo cho chất lượng của hệ thống phần mềm của mình

Cùng với việc triển khai áp dụng quy trình Rational, cần nâng tầm hiểu biết và vận dụng quy trình của cán bộ tin học đồng thời thay đổi thói quen và suy nghĩ phát triển ứng dụng chỉ là lập trình.