PHẦN 1: QUY TRÌNH RUP (RATIONAL UNIFIED PROCESS)
1.1. Giới thiê êu quy trình RUP
1.1.1. Khái quát
The Rational Unified Process(RUP) là mô tô quy trình 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).
Quy trình RUP hỗ trợ các hoạt động phát triển phần mềm theo nhóm,
phân chia công việc theo thứ tự cho từng thành viên của nhóm trong từng giai
đoạn khác nhau của quy trình phát triển. Mục đích chính của RUP là đề ra một
quy trình chặt chẽ nhấn mạnh việc lập kế hoạch chi tiết cho một dự án phát trển
phần mềm, nhằm giảm thiểu rủi ro và có được khả năng tiên đoán
(predictability) tốt nhất trong quá trình hiện thực qua đó giúp sản xuất những
phần mềm có chất lượng cao thỏa mãn yêu cầu của người dùng cuối với chi phí
thấp và năng suất cao trong khuôn khổ thời gian và ngân sách.
RUP không phải là một quy trình bó hẹp cụ thể đơn nhất, nó 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 sử dụng ngôn ngữ UML để mô hình hóa và hỗ trợ tất cả các giai
đoạn trong quy trình phát triển phần mềm.
RUP chứa nhiều kinh nghiê ôm đã được vâ ôn dụng hiê uô quả nhất trong
viê ôc phát triển phần mềm hiê ôn đại bao gồm:
Phát triển phần mềm theo vòng lă pô .
Quản lí các yêu cầu.
Sử dụng các kiến trúc thành phần (Component).
Mô hình hóa trực quan.
Kiểm định chất lượng.
Kiểm soát các thay đổi trong hê ô thống.
RUP là mô ôt sản phẩm tiến trình có thể tùy biến.
1.1.2. Lịch sử phát triển.
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.
1.1.3. Cấu trúc tổng quan của RUP.
RUP được tổ chức theo 2 trục:
Trục hoành: tổ chức theo thời gian phát triển dự án, thể hiê nô khía
cạnh đô nô g của quy trình bao gồm:
Chu kỳ (cycles).
Các pha (Phases).
Các quá trình lă ôp (interations).
Các cô ôt mốc (Milestones).
Trục tung: tổ chức theo nô iô dung công viê ôc, thể hiê ôn khía cạnh tĩnh
của quy trình bao gồm:
WHO (worker) : Thừa tác viên.
HOW (Activities): Hoạt đô ông.
WHAT(Artifacts): Sưu liê uô
WHEN (workflows): Luồng công viê ôc
Hình dưới đây mô tả kiến trúc tổng quan của RUP
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
1.2. Cấu trúc tĩnh của quy trình RUP
Mô ôt quy trình phát triển gồm tất cả tài liê ôu miêu tả những ai tham gia,
mỗi người phải làm gì, mỗi công viê ôc sẽ được làm khi nào, khi làm thì làm
theo cách nào để đạt mục tiêu đề ra. 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 là: thừa tác viên (workers),
hoạt đô ông (Activities), sưu liê uô (Artivities), luồng công viê ôc (Workflows).
1.2.1. Thừa tác viên (workers)
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.
1.2.2. Hoạt đô êng (Activity)
Hoạt đô nô g của mô ôt thừa tác viên là mô ôt đơn vị công viê ôc được giao cho
mô ôt cá nhân thực hiê ôn. Hoạt đô nô g có mục đích rõ ràng, thường là yêu cầu tạo
mới hoă ôc câ ôp nhâ tô mô tô số Artifacts như là model, class hoă ôc plan. Mỗi mô tô
Activity đượ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 care) và tác nhân hê ô thồng
(Actor): được thực hiê nô bởi Thừa tác viên: Nhân viên xem xét thiết kế.
Trong thuâ ôt ngữ hướng đối tượng, thừa tác viên là mô ôt đối tượng và các
hoạt đô nô g mà thừa tác viên thực hiê ôn là các thao tác được thực thi bởi đối
tượng đó.
Trong quy trình RUP, hoạt đô ông được ký hiê ôu bằng cách thêm tiếp đầ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..
Các hoạt đô nô g được chia thành nhiều bước thuô ôc ba loại chính sau:
Các bước khảo sát: thừa tác viên phải hiểu bản chất của công viê ôc,
thu thâ ôp và xem xét các sưu liê ôu đầu vào, và định dạng kết quả.
Các bước thực hiê ôn: thừa tác viên tạo mới hay câ ôp nhâ tô mô ôt vài sưu
liê ôu.
Các bước kiểm tra: thừa tác viên kiểm tra lại các kết quả theo mô ôt số
tiêu chí nhất định.
1.2.3. Sưu liê êu (Artifact)
Sưu liê ôu là những thông tin được tạo ra, thay đổi, hay được sử dụng bởi
mô ôt quy trình. Đó là kết quả của quá trình phát triển mô ôt dự án. Các sưu liê ôu
được thừa tác viên 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 đó.
Sưu liê uô bao gồm các mô hình và các bô ô tài liê uô sau:
Mô hình nghiê ôp vụ: mô tả 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: xác định các chức năng của hê ô
thống phần mềm.
Mô hình phân tích và thiết kế: xác định các đối tượng của hê ô
thống phần mềm dể giải quyết vấn đề của bài toán.
Mô hình triển khai: xác định kiến trúc phần cứng và phần mềm hê ô
thống cần thiết để triển khai.
Mô hình kiểm thử: 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ả các thành phần ứng dụng được phát
triển 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.
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
1.2.4. Luồng công viê êc (Workflows)
Luồng công viê ôc mô tả cách thức tiến hành các hoạt động theo trình tự
giai đoạn công việc hoạt đô ông liên quan đến nhau và vai trò của mỗi worker.
Trong ngôn ngữ UML, luồng công viê ôc có thể diễn đạt bằng Sequence
diagram, Collaboration diagram hoă ôc Activity diagram.
WORKER
ACTIVITY
DESIGNER
ANALYST:Nhâân dang Actor & Use Case
ARCHITECT:Prioritize Use Case
USE_CASE SPECIFIER:Detail a Use Case
...
Responsible for
ARTIFACT
USE_CASE:
REALIZATION
Hình . WORKER-ACTIVITY-ARTIFACT
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ụ (Business modeling):
mô tả cấu trúc và quy trình nghiê ôp vụ
Luồng công việc xác định yêu cầu (requirement) : mô tả nghiê ôp
vụ bằng phương pháp “Use case”.
Luồng công việc 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ế.
Luồng công việc thực hiện (implementation): 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.
Luồng công việc kiểm thử (Test): 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.
Luồng công việc triển khai (Deployment): đưa hê ô thống phần
mềm vào sử dụng.
Các luồng công việc phụ bao gồm:
Luồng công việc cấu hình và quản lý 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.
Luồng công việc quản lý dự án: quản lý toàn bô ô quá trình làm
viê ôc của dự án.
Luồng công việc 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.
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ý).
1.3. Cấu trúc đô êng của quy trình RUP.
1.3.1. Các pha (Phase) trong quy trình RUP.
Quy trình RUP được lă pô qua 4 pha (Phase). Trong mỗi mô ôt pha, các hoạt
đô nô g và luồng dữ liê ôu chính của pha đó sẽ được thực hiê nô .
Hình . Mô hình Phase của RUP.
Quy trình RUP được chia thành 4 pha:
Pha khởi đầu – Inception: Thành lâ ôp các trường hợp nghiê ôp vụ
(Business case) cho hê ô thống.
Pha xây dựng phác thảo- Elaboration: Nghiên cứu lĩnh vực
đang giải quyết và kiến trúc hê ô thống.
Pha xây dựng-Construction: Thiết kế hê ô thống, lâ pô trình, kiểm
thử.
Pha chuyển giao - Trasnition: Triển khai hê ô thống trong môi
trường vâ nô hành của nó.
Phân biê ôt giữa các pha là các cô ôt mốc (Milestone) đánh dấu sự kết thúc
của mỗi pha. Ở mỗi giai đoạn lại chia thành các bước lă pô (Iteration), kết thúc
mỗi bước lă ôp tạo ra mô ôt sản phẩm có thể vâ ôn hành được.
1.3.2. Hoạt đô êng chính trong các pha
1.3.2.1. Pha bắt đầu (Inception):
Pha bắt đầu bao gồm 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 pha này là đạt được sự nhất trí giữa các thành viên hệ thống
(stakeholder) về mục đích của chu trình sống trong dự án.
Mục đích của pha bắt đầu:
Thiết lập phạm vi dự án bao gồm cách thức hoạt động, phạm vi đánh
giá, và những dự định sẽ có hay không có trong phần mềm.
Xác định những chức năng hệ thống quan trọng sẽ điều khiển chức năng
của hệ thống và xác định tối thiểu một kiến trúc tiêu biểu cho chúng.
Ước lương chi phí và thời gian tổng thể của toàn dự án, đồng thời cung
cấp các ước lượng chi tiết cho pha chuẩn bị xảy ra ngay sau đó.
Ước lượng rủi ro.
Hoạt động chủ yếu của pha bắt đầu bao gồm:
Xác định phạm vi dự án, tức là nắm bắt ngữ cảnh,các yêu cầu và rằng
buộc quan trọng nhất để có thể thiết lập các tiêu chuẩn đánh giá cho sản
phẩm cuối.
Lập kế hoạch và chuẩn bị chức năng cho người dùng đồng thời đánh giá
lựa chọn các cách thức quản lý rủi ro, bố trí nhân viên, lập kế hoạch dự
án và sự cân đối giữa chi, thời gian và lợi nhuận.
Tập hợp các kiến trúc tiêu biểu để có thể ước lượng chi phí, thời gian, tài
nguyên.
Kết quả của pha bắt đầu là các sưu liệu sau;
Tài liệu về những yêu cầu, đặc tính và rằng buộc chính của dự án
Khảo sát về mô hình, chức năng của hệ thống để liệt kê tất cả các chức
năng hệ thống và tác nhân hệ thống mà có thể xác định được vào lúc này
Một bản chú giải thuật ngữ ban đầu cho dự án
Chức năng cho người dùng ban đầu, bao gồm:
-
Ngữ cảnh nghiệp vụ.
-
Tiêu chuẩn thành công.
-
Dự báo tài chính.
Ước lượng ban đầu về rủi ro
Kế hoạch dự án cho thấy các pha và các vòng lặp
Pha ban đầu cũng có thể tạo ra các sưu liệu sau:
Mô hình chức năng hệ thống ban đầu (hoàn chỉnh từ 10% đến 20%)
Một mô hình lĩnh vực (domain model)
Một mô hình nghiệp vụ (business model)
Mô tả sơ bộ về các chức năng phát triển
Một hoặc và kiểu mẫu
Kết thúc của pha bắt đầu là điểm mốc đầu tiên của dự án:trực quan hóa (life
cycle objective milestone)
Hình . Điểm mốc đầu tiên của dự án.
Các tiêu chuẩn đánh giá cho pha bắt đầu:
Sự nhất trí giữa các thành viên hệ thống về phạm vi dự án, các ước lượng
về chi phí và thời gian
Sự hiểu rõ các yêu cầu được thể hiển qua tính đúng đắn của những chức
năng hệ thống chủ yếu
Độ tin cậy của những ước lượng về chi phí, thời gian, rủi ro, và quy trình
phát triển
Chiều sâu và chiều rộng của những kiểu mẫu kiến trúc được phát triển
Những phí tổn thật sự so với những phí tổn đã được lập kế hoạch
Nếu dự án không vượt qua được mốc này, nó có thể bị hủy bỏ và xem xét lại.
1.3.2.2.
1.4.
- Xem thêm -