Tiểu luận Quy trình RUP trong Công Nghệ Phần Mềm

Rational Unified Process RUP là một quy trình phát triển phần mềm. Cung cấp bộ quy tắc cho phép tiếp cận việc phân công và trách nhiệm bên trong phạm vi một tổ chức phát triển. Mục đích của nó nhằm đảm bảo việc cho ra một phần mềm chất lượng cao đáp ứng được người dùng cuối, với kế hoạch và một khoản đầu tư có sẵn.RUP được phát triển lần đầu tiên bởi Rational Software , một đơn vị của tập đoàn IBM vào năm 2003.

Mục lục

Mục lục 1

I Tổng quan 4

1 Định nghĩa: 4

2 Mô hình 2 chiều của RUP: 6

3.Khái niệm cơ bản: 6

II.Các pha của quy trình RUP 10

1 Pha bắt đầu ( inception phase ) 10

2 Pha chuẩn bị ( elaboration phase ) 11

3 Pha xây dựng ( construction phase ) 13

4 Pha chuyển giao ( transition phase ) 14

III Workflow 16

1.Business modeling ( mô hình hóa nghiệp vụ) 16

Worker và Activity 17

Artifact 18

Assess Business Status 19

Describe Current Business 20

Identify Business Processes 21

Refine Roles and Responsibilities 22

2 Requirements( yêu cầu): 23

Worker và Activity 25

Artifact 26

Analyze the Problem 27

Understand Stakeholder Needs 28

Manage Changing Requirements 29

Manage the Scope of the System 30

Refine the System Definition 31

3 Analysis and design( Phân tích và thiết kế) 32

Đề ra kiến trúc ban đầ 34

Làm mịn 36

Phân tích hành vi( 39

Thiết kế thành phần 40

Thiết kế theo thời gian thực 42

Thiết kế dữ liệu 44

4 Implementation (xây dựng) 46

Xây dựng mô hình cấu trúc(Structure the Implementation Model) 47

Xây dựng kế hoạch tích hợp(Plan the Integration) 48

Thành phần thực hiện(Implement Components) 49

Tích hợp các hệ thống con( Integrate each Subsystem) 51

Tích hợp hệ thống(Integrate the System) 52

5 Kiểm thử (Test) 53

Plan test ( lên kế hoạch kiểm thử): 55

Design test ( thiết kế kiểm thử) 56

Implement Test (xây dựng thử nghiệm) 57

Execute Tests in intergration test stage (thực thi kiểm thử trong giai đoạn kiểm tra tích hợp) 59

Execute tests in system test stage (thực thi kiểm thử trong giai đoạn kiểm tra hệ thống) 60

Evaluate test (Đánh giá kiểm tra) 61

6 Deployment (triển khai) 62

Plan Deployment (lên kế hoạch triển khai) 63

Develop Support Material( tài liệu hỗ trợ phát triển) 64

Manage Acceptance Test( quản lý công nhận kiểm thử) 64

Produce Deployment Unit (đơn vị phát triển sản phẩm) 65

Beta Test Product (kiểm thử sản phẩm beta) 66

Manage Acceptance Test( quản lý công nhận kiểm thử) 66

Package Product (gói sản phảm) 67

Provide Access to Download Site (cung cấp truy cập tài về từ trang web) 68

7 Quản lý dự án: 69

8 Cấu hình và quản lý thay đổi: 75

9 Môi trường: 82

Tài liệu tham khảo: 88

THÀNH VIÊN CỦA NHÓM: 89

I Tổng quan.

1 Định nghĩa:

RUP là gì?

Rational Unified Process - RUP là một quy trình phát triển phần mềm Cung cấp

bộ quy tắc cho phép tiếp cận việc phân công và trách nhiệm bên trong phạm vi một

tổ chức phát triển Mục đích của nó nhằm đảm bảo việc cho ra một phần mềm chấtlượng cao đáp ứng được người dùng cuối, với kế hoạch và một khoản đầu tư cósẵn

RUP được phát triển lần đầu tiên bởi Rational Software , một đơn vị của tập đoànIBM vào năm 2003

Ưu điểm của quy trình RUP?

RUP là quy trình được Rational phát triển dựa trên 6 đặc điểm chính:

 Phần mềm được phát triển qua nhiều lần lặp: giảm bớt rủi ro, cho phép sớmnhận được phản hồi của người dùng cuối và thực hiện thử nghiệm và cậpnhất một cách thường xuyên

 Quản lý các yêu cầu: Quản trị yêu cầu trong suốt quá trình phát triển đảmbảo giải quyết đúng vấn đề gặp phải và xây dựng đúng hệ thống cần xâydựng; quản trị yêu cầu cho phép theo vết được các vấn đề đặt ra từ nhu cầucủ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 component-based: Chia nhỏ hệ thống ra nhiều phần độclập có liên kết với nhau Là kiến trúc linh động cho phép xây dựng được hệthống đáp ứng các yêu cầu hiện tại cũng như mở rộng hệ thống trong tươnglai

 Mô hình hóa trực quan phần mềm: Sử dụng ngôn ngữ chuẩn UML để môhình hóa toàn bộ hệ thống phần mềm cần phát triển Điều này cho phépngười phát triển phần mềm nắm rõ được toàn bộ cấu trúc và hoạt động của

hệ thống

 Kiểm tra chất lượng phần mềm: Việc kiểm tra và thử nghiệm phần mềmđược thực hiện ở tất cả các chu kỳ phát triển của phần mềm để xem xét hiệunăng, độ tin cậy

 Kiểm soát thay đổi: Trước mỗi thay đổi hoặc cập nhật cần được đảm bảo vàxem xét kỹ

Ngoài ra, quy trình RUP là quy trình phát triển phần mềm theo hướng lặp

Do đó RUP cũng mang những ưu điểm của một quy trình lặp tiêu biểu như:

 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ầndầ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 quitrình của họ

 Tăng khả năng tái sử dụng

2 Mô hình 2 chi u c a RUP: ều của RUP: ủa RUP:

Có thể hình dung về quy trình dưới cách thể hiện của trục tọa độ hai chiều:

 Trục hoành biểu diễn thời gian và các thành phận động của quy trình và giảithích cho các phase, vòng lặp và milestone

 Trục tung biểu diễn các thành phần tĩnh của quy trình: woker, workflow,activity

Worker xác định trách nhiệm và công việc của một cá nhân hoặc một nhóm ngườilàm việc cùng với nhau Một cá nhân có thể xuất hiện trong nhiều vai trò khácnhau Worker được xác định một tập các activity và được phép làm chủ một tậpcác artifact

Mỗi activity là một đơn vị công việc được giao cho một cá nhân trong Worker thựchiện Activity có một mục tiêu rõ ràng, thường được quy định rõ ràng trong quátrình khởi tạo hoặc cập nhật artifact, ví dụ như một mô hình, một lớp hoặc một kếhoạch Với mỗi activity được gán cho một worker riêng biệt Mức độ chi tiết củamột activity thường được tính theo vài giờ cho đến vài ngày, thường bao gồm mộtworker và tác động tới một hoặc một nhóm nhỏ các artifact Một activity nên được

sử dụng như một thành phần trong việc lên kế hoạch hoặc sự phát triển

Artifact

Artifact là một phần thông tin được tạo ra, chỉnh sửa hoặc sử dụng trong quy trình.Artifact là là sản phẩm thực của dự án, được dự án tạo ra hoặc sử dụng trong quátrình làm việc để cho ra sản phẩm cuối cùng, Artifact được sử dụng như input đốivới worker để triển khai một activity, và là kết quả cuối cùng hoặc output của mộtvài activity Trong thiết kế hướng đối tượng, activity là hoạt động của một đốitượng động( worker), artifact là các thông số của những activity đó

 Artifact tồn tại dưới nhiều hình thức khác nhau

 Một mô hình, ví dụ như Mô hình Use-Case hoặc Mô hình thiết kế

 Một thành phần của mô hình, ví dụ như một thành phần bên trong một môhình như một lớp, một use-case hoặc subsystem

 Một văn bản, ví dụ như Bản kiến trúc phần mềm

 Source code

Một tập hợp gồm các worker, activity và artifact chưa làm nên được một quytrình Workflow giúp thể hiện một cách đầy đủ nhất những chuỗi activity cho rakết quả có giá trị, và thể hiện mối quan hệ giữa các worker

II.Các pha c a quy trình RUP ủa RUP:

Một chu trình phát triển phần mềm được chia ra thành nhiều giai đoạn, mỗi giaiđoạn tương ứng với một thế hệ sản phẩm RUP chia một giai đoạn phát triển củaphần mềm thành 4 pha liên tục

Cuối mỗi pha là một điểm mốc ( milestone )- lúc những quyết định về phần mềmđược đưa ra, xem xét và đánh giá trước khi chuyển sang pha tiếp theo

1 Pha b t đ u ( inception phase ) ắt đầu ( inception phase ) ầu ( inception phase )

Pha bắt đầu hình dung bức tranh tổng quát về sản phẩm cuối cùng và phác thảochức năng cho người dùng, đồng thời xác định phạm vi của dự án ( phần mềm ).Mục tiêu là đạt được sự nhất trí giữa các thành viên trong hệ thống và các mục đíchcủa dự án ( phần mềm )

Mục đích:

 Thiết lập phạm vi dự án : cách thức hoạt động, tiêu chuẩn đánh giá và những

dự định sẽ có ( hay không ) trong dự án ( phần mềm )

 Xác định 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 cũng cungcấp các ước lượng chi tiết cho cho pha chuẩn bị xảy ra sau đó

 Ước lượng rủi ra gặp phải trong quá trình thực hiện

 Tổng hợp kiến trúc tiêu biểu để có thể ước lượng chi phí, thời gian, tàinguyên

Kết quả đạt được:

 Tài liệu về những yêu cầu, đặc tính và ràng buộc 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 vào lúc này

 Đề cương ban đầu cho dự án

 Ước lượng ban đầu về rủi ro

 Kế hoạch dự án, bao gồm các pha và vòng lặp

 Hiểu rõ chính xác các yêu cầu của phần mềm ( dự án )

 Độ tin cậy về những ước lượng chi phí, thời gian, rủi ro và quy trình pháttriển

 Chiều sâu và chiều rộng của nhưng mẫu kiến trúc được phát triển

 Những phí tổn thực sự so với những phí tổn đã lên kế hoạch

 Nếu dự án ( phần mềm ) không vượt qua mốc này, nó có thể bị hủy bỏ hoặcxem xét lại

2 Pha chu n b ( elaboration phase ) ẩn bị ( elaboration phase ) ị ( elaboration phase )

Lập kế hoạch các hoạt động và các tài nguyên cần thiết, xác định các tính năng vàthiết kế kiến trúc Mục tiêu của pha này là phân tích vấn đề, phát triển kế hoạch vàloại bỏ những thành phần có rủi ro cao của dự án Để làm được điều này thì phải cócái nhìn sâu rộng về hệ thống : phạm vi hệ thống, chức năng chính và yêu cầu phichức năng ( tốc độ dự án )

Đây là pha quan trọng nhất trong 4 pha, cuối pha này sẽ quyết định có tiếp tục xâydụng và chuyển giao dự án nữa hay không

Mục đích

 Xác định, phê chuẩn và lập kiến trúc nền tảng càng nhanh càng tốt

 Lập kế hoạch đúng đắn cao cho pha tiếp theo

 Trình bày kiến trúc nền tảng được thực hiện với chi phí thích hợp trong thời

Công việc chính

 Hiểu rõ những chức năng hệ thống quan trọng nhất có ảnh hưởng đến kiếntrúc và việc lập kế hoạch

 Chuẩn bị cơ sở hạ tầng, môi trường phát triển và công cụ tự hỗ trợ động hóa

 Chuẩn bị kiến trúc và sự lựa chọn các thành phần Đánh giá các thành phần

có tiềm năng và việc tạo/mua/tái sử dụng chúng để xác định được chi phi vàthời gian cho xây dựng

 Xác định các tính năng và thiết kế kiến trúc

Kết quả đạt được

 Một mô hình chức năng hệ thống ( tối thiểu hoàn thành 80% )trong đó tất cảcác chức năng hệ thống và tác nhân hệ thống đã được xác định và hầu hếtcác mô tả chức năng hệ thống đã được phát triển

 Những yêu cầu bổ sung bao gồm các yêu cầu phi chức năng và bất cứ yêucầu nào không được kết hợp với một chức năng hệ thống cụ thể

 Mô tả về kiến trúc phần mềm

 Một kiểu mẫu kiến trúc có thể thực thi được

 Danh sách rủi ro và các chức năng cho người dùng đã được xem xét lại

 Kế hoạch phát triển cho toàn bộ dự án

 Các chức năng phát triển đã được cập nhật

 Tài liệu hướng dẫn sự dụng sơ bộ ( nếu cần thiết )

Milestone

 Lifecycle architecture milestone :kiến trúc cơ bản

 Các tiêu chuẩn đánh giá cho pha chuẩn bị:

 Sự hình dung về sản phẩm

 Sự ổn định của kiến trúc

 Sự giải quyết rủi ro và sự tin cậy

 Sự chính xác và đầy đủ cho kế hoạch của pha tiếp theo

 Sự đồng ý của tất cả thành viên trong hệ thống về việc xây dựng sản phẩmvới kế hoạch đã lập ra trước đó

 Sự chấp nhận của phí tổn tài nguyên thực sự so với phí tổn đã lập kế hoạch

 Nếu dự án không vượt qua được pha này, nó có thể bị bỏ dở hoặc xem xétlại

3 Pha xây d ng ( construction phase ) ựng ( construction phase )

Xây dựng và cải tiến sản phẩm, kiến trúc và các kế hoạch cho đến khi sản phẩmcuối cùng đã sẵn sàng để phân phối cho người dùng Trong suốt pha xây dựng, tất

cả các thành phần và tính năng còn lại của ứng dụng được phát triển và tích hợpvào sản phẩm Pha này nhấn mạnh việc quản lí tài nguyên và kiểm soát các hoạtđộng để tối ưu hóa chi phí, thời gian và chất lượng

Mục đích:

 Tối thiểu hóa các chi phí phát triển

 Đạt được chất lượng tương xứng càng nhanh càng tốt

 Tạo ra các phiên bản khác nhau

Công việc chính:

 Quản lí tài nguyên, kiểm soát tài nguyên, tối ưu hóa quy trình

 Hoàn chính việc phát triển các thành phần và kiểm tra chúng theo các tiêuchí định trước

 Đánh giá các phiên bản của sản phẩm theo những tiêu chuẩn đánh giá đãđịnh trước

Kết quả đạt được:

 Sản phẩm đã sẵn sàng chuyển giao cho người sử dụng

 Sản phẩm phần mềm được tích hợp trên các hệ thống tương ứng

 Các tài liệu hướng dẫn sử dụng

 Mô tả phiên bản hiện hành

Milestone:

 initial operational capability milestone ( các tính năng khởi đầu )

 Các tiêu chuẩn đánh giá cho pha xây dựng gồm:

 Phiên bản sản phầm có ổn định ? đủ hoàn thiện để phân bố đến người dùng ?

 Tất cả thành viên có đồng ý chuyển giao cho người dùng ?

 Phí tổn tài nguyên thực sự so với phó tổn tài nguyên khi lập kế hoạch cóchấp nhận được ?

 Việc chuyển giao có thể bị trì hoãn nếu không đạt được mốc này

4 Pha chuy n giao ( transition phase ) ển giao ( transition phase )

Chuyển giao sản phẩm đến người dùng bao gồm sản xuất, phân phối, huấn luyện,

o Kiểm tra, phê chuẩn hệ thống mới có đáp ứng nhu cầu người dùng

o Việc chuyển đổi các cơ sở dữ liệu vận hành

o Huấn luyện người sử dụng và các chuyên viên bảo trì

o Phát hành sản phẩm ta thị trường, phân phối bán hàng

Mục đích:

 Đạt được khả năng tự hỗ trợ của người dùng

 Đạt được sự nhất trí của các thành viên hệ thống rằng các nên tảng để pháthành sản phẩm đã hoàn chỉnh và thống nhất các tiêu chí đánh giá sản phẩm

 Nhanh chóng đạt được sản phẩm cuối cùng và có hiệu quả về chi phí

Công việc chính:

 Đóng gói và sản xuất thương mại, tung ra bán hàng, huấn luyện nhân sự

 Sửa lỗi, tăng cường tốc độ và khả năng sử dụng

 Đánh giá các cơ sở để triển khai và các tiêu chuẩn thành công của sản phẩmMilestone:

 Product release milestone( đưa ra sản phẩm )

 Điểm mốc này cũng kết thúc cả chu kì Các tiêu chuẩn đánh giá cho pha nàybao gồm

o Sự hài lòng của người dùng

o Phí tổn tài nguyên thực sự so với phí tổn khi lập kế hoạch có thể chấpnhận

Các pha của quy trình RUP lập thành chu trì phát triển và tạo ra một thế hệ phầnmềm Một sản phẩm phần mềm được tao ra trong chu kì phát triển ban đầu Nếusản phẩm vượt qua điểm mốc cuối cùng thì sản phẩm sẽ được cải tiến sang thế hệtiếp bằng cách lặp lại các pha ở trên nhưng với mục tiêu khác nhau trên những phakhác nhau ( chu kì tiến hóa )

Khi sản phẩm vượt qua vài chu kì tiến hóa, những thế hệ mới của sản phẩm đượctạo ra Các chu kì tiến hóa có thể được khởi đầu từ những cải tiến do người dùng

đề nghị ( thay đổi ngữ cảnh người dung, thay đổi công nghệ nền tảng, cạnh tranh ).Trong thực tế các chu kì có thể chồng lên nhau 1 ít, pha bắt đầu và chuẩn bị có thểkhởi đầu ở phần cuối của pha chuyển giao trong chu kì trước đó

Các pha không nhất thiết có khoảng thời gian bằng nhau , độ dài của chúng thayđổi tùy vào tình huống cụ thể của dự án Điều quan trọng là mục đích của mỗi pha

và các điểm mốc kết thúc của chúng

Worker và Activity

Business-Process Analyst: Có trách nhiệm tổ chức và bố trí việc mô hình hóa

business use-case, bằng cách vạch rõ và giới hạn tổ chức được mô hình hóa Ví dụnhư việc xác định business actor và business use-case và cách thức tương tác củachúng

Business Designer: Chịu trách nhiệm mô tả chi tiết đặc tả của từng phần trong tổ

chức bằng cách thể hiện workflow của một hoặc một vài business use-case Ngoài

ra còn có trách nhiệm xác định rõ trách nhiệm, hoạt động, thuộc tính và mối quan

hệ giữa các worker và thực thể nghiệp vụ

Business Model Reviewer: Là người đánh giá mô hình use-case business hoặc mô

hình đối tượng

Business Glossary: Định nghĩa những thuật ngữ quan trọng được sử dụng trong

phần mô hình hóa nghiệp vụ của dự án

Business Rules: Nêu ra những quy tắc cũng như các điều kiện cần phải được đáp

Business Use-Case Model: Là mô hình thể hiện những chức năng nghiệp vụ.

Được sư dụng như một input để định nghĩa role và sản phẩm của tổ chức

Business Use Case: Định nghĩa một tập các thể hiện use-case nghiệp vụ, trong đấy

mỗi thể hiện là một chuỗi các hành động mang tính chất nghiệp vụ mang lại mộtkết quả có giá trị quan sát được của một business actor cụ thể

Organization Unit: Là một bộ các business worker, thực thể nghiệp vụ, mối quan

hệ cũng như use-case business diagram Được dùng để xây đựng mô hình nghiệp

vụ hướng đối tượng bằng cách chia nhỏ thành nhiều phần khác nhau

Business actor: Thể hiện vai trò của người tham gia vào nghiệp vụ, có thể là

người hoặc môi trường nghiệp vụ

Assess Business Status

Mục đích:

 Đánh giá tình trạng của tổ chức sẽ được triển khai trong hệ thống

 Tìm ra cách phân loại các dự án và kịch bản mô hình hóa nghiệp vụ phù hợpnhất

 Đưa ra quyết định về cách thức tiếp tục công việc trong phiên hiện tại cũng như vạch ra cách làm việc trong những phiên tiếp theo với artifact

 Cung cấp những hiểu biết đầu tiên về mục đích và các đối tượng của tổ chức

Để đạt được những mục tiêu này cần đến hai artifact chính là Target-Organization Assessment và Business Vision

Worker: Business-Process Analyst

Artifact: Business Glossary, Business Rules, Business Vision,

Target-Organization Assessment, Business Modeling Guidelines

Activity: Assess Target Organization, Set and Adjust Goal, Maintain Business

Rules, Capture a Common Business Vocabulary, Business Glossary

Describe Current Business

Mục đích:

 Hiểu được cách thức hoạt động cũng như cấu trúc của tổ chức

 Dựa trên những hiểu biết này, đưa ra mục tiêu của việc mô hình hóa nghiệp vụ

Worker: Business- Process Analyst

Artifact: Business Glossary, Business Rules, Business Vision,

Target-Organization Assessment, Business Modeling Guidelines, Supplementary BusinessSpecification, Business Use-case Realization, Business Object Model, Business Use-case Modelm Business Use-Case

Activity: Find Business Worker anf Entities, Find Business Actors and Use Cases,

Assess Target Organization, Set and Adjust Goal

Identify Business Processes

Mục đích:

 Lựa chọn thuật ngữ

 Vạch ra được business use-case model

 Ưu tiên mô tả chi tiết business use case

Worker: Business- Process Analyst

Artifact: Business Glossary, Business Rules, Business Vision,

Target-Organization Assessment, Business Modeling Guidelines, Supplementary BusinessSpecification, Business Use-case Model, Business Use-Case, Business

Architecture Documentation

Activity: Maintain Business Rules, Set and Adjust Goal, Define Business

Architecture, Capture a Common Business Vocabulary, Find Business Actors and Uses Cases

Refine Roles and Responsibilities

Mục đích:

 Định nghĩa chi tiết các thực thể nghiệp vụ

 Mô tả chi tiết công việc của từng business worker

 Kiểm định kết quả của việc mô hình hóa các đối tượng nghiệp vụ phù hợp với quan điểm của các bên liên quan

Worker: Business Model Reviewer, Business Designer.

Artifact: Business Glossary, Business Rules, Business Vision,

Target-Organization Assessment, Business Modeling Guidelines, Supplementary BusinessSpecification, Business Architecture Documentation Business Worker,

Organization Unit, Business Entity, Review Record

Activity: Detail a Business Worker, Detail a Business a Entity, Review the

Business Object Model

2 Requirements( yêu c u): ầu ( inception phase )

 Cung cấp cơ sở cho việc lập kế hoạch nội dung kỹ thuật lặp sau này

 Cung cấp cơ sở cho việc ước tính chi phi và thời gian phát triển hệthống

 Xác định giao diện người sử dụng cho hệ thống, tập trung vào nhu cầu

và mục tiêu của người sử dụng

Mỗi chi tiết luồng công việc đại diện cho một kỹ năng quan trọng mà nên được ápdụng để thực hiện hiệu quả yêu cầu quản lý Analyze the Problem (phân tích cácvấn đề) và Understand Stakeholder Needs (hiểu được nhu cầu của các bên liênquan) tập trung vào trong giai đoạn inception phase (khởi động) của một dự án,trong khi nhấn mạnh Define the System (Xác định hệ thống) và Refine the SystemDefinition ( sàng lọc hệ thống định nghĩa) trong Elaboration (giai đoạn xây dựng)

Manage the Scope of the System (Quản lý phạm vi của hệ thống) và ManageChanging Requirements (quản lý các yêu cầu thay đổi) được thực hiện liên tụctrong quá trình thực hiện dự án

Worker và Activity

Architect: là người chịu trách nhiệm và điều phối những hoạt động về kĩ thuật

trong suốt quá trình dự án Kiến trúc sư là người thiết lập cấu trúc tổng thể( cáinhìn khái quát, các yếu tố ) Vì thế, kiến trúc sư cần phải có cái nhìn rộng ( khôngcần thiết phải sâu)

Use-case Specifier: Chịu trách nhiệm mô tả chi tiết những đặc điểm của từng phần

trong chức năng của hệ thống được thể hiện trong Requirements

User-Interface Designer: Chịu trách nhiệm chỉ đạo và phân phối các bản thử

nghiệm cũng như các bản thiết kế giao diện người dùng

Requirements Reviewer: Lên kế hoạch và tiến hành đánh giá mô hình use-case System Analyst: Điều phối những yêu cầu gợi mở cũng như mô hình hóa use-

case, bằng cách vạch ra những chức năng chính cũng như giới hạn cho hệ thống

Requirements Management Plan: Thể hiện những yêu cầu, kiểu yêu cầu và

nhưng thuộc tính yêu cầu quan trọng, phân loại thông tin và cơ chế kiểm soát việcthu thập và sử dụng cho thông báo và kiểm soát những thay đổi đối với yêu cầucủa sản phẩm

Stakeholder Requests: Bao gồm bất cứ yêu cầu nào từ các bên liên quan( khách

hàng, người dùng cuối, nhân viên marketing, ) có thể được có trong hệ thống

Glossary: Định nghĩa các thuật ngữ quan trọng dùng trong dự án.

Vision: Tầm nhìn cụ thể của những yêu cầu chính trong dự án, cung cấp thỏa

thuận cơ sở cho những yêu cầu kỹ thuật chi tiết hơn

Supplementary Specification: Lưu lại các yêu cầu hệ thống chưa thực sự được

xuất hiện trong mô hình use-case

Analyze the Problem

Mục đích:

 Đạt được sự đồng ý của cách thức giải quyết các vấn đề

 Xác định các bên liên quan

 Xác định phạm vi của hệ thống

 Xác định những ràng buộc của hệ thống

Understand Stakeholder Needs

Mục đích: Thu thập và bổ sung các thông tin từ các bên liên quan của dự án nhằm

hiểu một cách chính xác những điều họ thực sự mong muốn Những yêu cầu được thu thập từ các bên liên quan có thể được liệt kê và sử dụng như một input trong việc xác định những chức năng chính của hệ thống và được thể hiện trong Vision

Manage Changing Requirements

Mục đích:

 Đánh giá những yêu cầu thay đổi và xác định sự tác động của chúng đối với

hệ thống hiện tại

 Xây đựng mô hình use-case

 Xác nhận kết quả công việc của workflow Requirement phù hợp với những yêu cầu của khách hàng

Manage the Scope of the System

Mục đích:

 Tinh chỉnh input cho các chức năng chính và những yêu cầu có trong phiên hiện tại

 Xác định bộ các use-case thể hiện những chức năng chính

 Xác định những thuộc tính yêu cầu và khả năng truy vết để bảo trì

Refine the System Definition

Mục đích:

 Thể hiện được luồng use-case của các sự kiện một cách chi tiết

 Mô tả chi tiết Supplementary Specifications

 Cung cấp Software Requirements Specification

 Mô hình hóa và thử nghiệm giao diện người dùng

3 Analysis and design( Phân tích và thi t k ) ết kế) ết kế)

Mục đích:

 Để chuyển những yêu cầu vào thiết kế hệ thống

 Để phát triển vững chắc kiến trúc của hệ thống

 Để thích ứng các thiết kế phù hợp với môi trường xây dựng

Early Elaboration Phase (Giai đoạn chuẩn bị đầu tiên) tập trung vào việc tạo ra mộtkiến trúc ban đầu cho hệ thống (Define a Candidate Architecture) để cung cấp mộtđiểm khởi đầu cho công tác phân tích chính Nếu kiến trúc đã tồn tại (hoặc vì nóđược sản xuất từ các bước lặp trước, trong các dự án trước đây, hoặc là thu được từmột khung ứng dụng), trọng tâm của sự thay đổi công việc để tinh chỉnh kiến trúc(Refine the Architecture) và phân tích hành vi và tạo ra một ban đầu thiết lập cácyếu tố cung cấp các hành vi thích hợp (Analyze Behavior)

Sau khi các yếu tố ban đầu được xác định, họ tiếp tục sàng lọc Các thiết kế thànhphần (Design Components) và các thiết kế thành phần thời gian thực (Design Real-Time Components) sản xuất một tập hợp các thành phần cung cấp các hành vithích hợp để đáp ứng các yêu cầu về hệ thống Song song với các hoạt động này,các vấn đề bền vững đã được xử lý trong thiết kế cơ sở dữ liệu(Design theDatabase) Kết quả là một thiết lập ban đầu của các thành phần được tiếp tục sànglọc trong Implementation workflow

Đề ra kiến trúc ban đầu (Define a Candidate Architecture )

Worker : architect, designer

Activity: prioritize, architectural analysis, use-case analysis, develop design,

submit change request

Actifact: glossary, business object model, use-case model, design

model,supplementary specifications, software architecture document, reference architecture, design guildelines, use-case relization, deployment model, analysis class, change request

Mục đích:

o Tạo ra bản phác thảo kiến trúc ban đầu của hệ thống

o Phân tích từ kiến trúc đã đưa ra

o Cập nhật trên thực tế với những phân tích đã có

Kiến trúc sư (architect) là người chịu trách nhiệm và điều phối những hoạt động

về kĩ thuật trong suốt quá trình dự án Kiến trúc sư là người thiết lập cấu trúc tổng thể( cái nhìn khái quát, các yếu tố ) Vì thế, kiến trúc sư cần phải có cái nhìn rộng ( không cần thiết phải sâu)

Nhà thiết kế (designer) xác định trách nhệm, hoạt động, thuộc tính, các mối quan

hệ và môi trường xung quanh Ngoài ra cần phải có trách nhiệm với một hay nhiều nhà thiết kế khác trong hệ thống

Phân tích kiến trúc (architectural analysis) bao gồm

Xác định kiến trúc ban đầu dựa trên kinh nghiệm của bản thân hoặc những

Tổng kết của những dự án tương tứ trước đó

o Xác định mô hình hệ thống, cơ chế hoạt động

o Xác định chiến lước tái sử dụng

o Cung cấp tài liệu đầu vào cho quá trình lập kế hoạch

Phân tích use-case

o Xác định trách nhiệm, thuộc tính của use-case

o Lưu ý việc sử dụng cơ chế kiến trúc

Glossary: đưa ra những thuật ngữ quan trọng dùng trong dự án

Software architecture documents: tài liệu mô tả phần mềm kiến trúc, cung cấp

cái nhìn khái quát về kiến trúc hệ thống, sử dụng để mô tả các khía cạnh khác nhaucủa kiến trúc

Reference architecture: những kiến trúc tham khảo, bao gồm mô hình kiến trúc

đã xác định từ trước hoặc một tập các mô hình được thiết kế, chứng minh là phù hợp

Làm mịn (Refine the Architecture)

Worker: architect, architecture reviewer

Activity: identify design mechanisms, identify design elements, incorporate

existing design element, describe run-time architecture, review the architecture, prioritize use cases

Artifact: supplementary specification, design guideline, software architecture

document, change request, risk list, review record

Mục đích:

Đưa ra sự thay đổi từ phân tích đến thiết kế, bao gồm:

o Yếu tố thiết kế dựa trên yếu tố phân tích

o Cơ chế thiết kế dựa trên cơ chế phân tích

Duy trì sự thống nhất toàn vẹn của kiến trúc

o Các yếu tó cho thiết kế hiện tại được tích hợp với các yếu tố của thiết

kế trước

o Tái sử dụng tối đa các thành phần có sẵn

Xây dựng mô hình chuyển đổi cho việc thiết kế và thực hiện chúng

Architecture reviewer : là người xem xét kiến trúc, đánh giá theo những quy

chuẩn

Identify design mechanisms: tinh chỉnh, điều chình những cơ chế đã phân tích

dựa trên những hạn chế do môi trường

Identify design elements: phân tích những tương tác để xác định yếu tố thết kế Review the architecture: đánh giá kiến trúc ( những rủi ro chưa lường trước về

lịch trình thực hiện hoặc ngân sách, phát hiện những lỗ hổng trong quá trình thiết

kế, sự không phù hợp giữa yêu cầu ban đầu và thực tế thiết kế , …)

Supplementary specification: thông số kĩ thuật bổ sung

Design guideline: bản miêu tả và hướng dẫn quá trình thiết kế

Software architecture document: tài liệu về phần mềm kiến trúc, đưa ra cái nhìn

tổng quát về kiến trúc hệ thống, sử dụng cái nhìn khác nhau để mô tả các khía cạnhkhác nhau

Risk list: danh sách rủi ro