đồ án công nghệ thông tin Quy trình RUP và ứng dụng

Quy trình xoáy ốc Sprial: thích hợp với phát triển các dự án lớn và phức tạp.Trong phát triển phần mềm, yếu tố con người và tổ chức dự án là quan trọng.Cần có một khung làm việc thống nh

Đồ án tốt nghiệp Quy trình RUP và ứng dụng

MỤC LỤC

DANH MỤC HÌNH 3

DANH MỤC TÀI LIỆU 4

DANH MỤC BẢNG 4

DANH MỤC TỪ 4

LỜI CẢM ƠN 5

LỜI NÓI ĐẦU 6

ĐẶT VẤN ĐỀ 9

1.1 MỤC ĐÍCH CỦA ĐỀ TÀI 11 1.2 GIỚI THIỆU BÀI TOÁN, NHIỆM VỤ CỦA ĐỀ TÀI 12 1.3 LÝ DO CHỌN ĐỀ TÀI 13 TỔNG QUAN VỀ QUY TRÌNH RUP 14

1.4 MỘT SỐ VẤN ĐỀ TRONG PHÁT TRIỂN PHẦN MỀM 15 1.4.1 Công nghệ học phần mềm 15

1.5 QUY TRÌNH PHẦN MỀM RUP (RATIONAL UNIFIED PROCESS) 16 1.5.1 Hiệu suất phát triển phần mềm 16

1.5.2 Quy trình công nghệ phần mềm RUP hướng sử dụng (Use-Case Driven) 17

1.5.3 Quy trình công nghệ phần mềm RUP lấy kiến trúc làm trung tâm (Architecture Centric) 18

1.5.3.1 Mô hình và kiến trúc phần mềm 18

1.5.3.2 Kiến trúc phần mềm là quan trọng 19

1.5.3.3 Yêu cầu của kiến trúc phần mềm 19

1.5.3.4 RUP là quy trình lấy kiến trúc phần mềm làm trung tâm 19

1.5.4 Quy trình công nghệ phần mềm RUP lặp và tăng dần từng bước (Iterative and Incremental) 21

1.5.4.1 Hạn chế rủi ro 21

1.5.4.2 Tạo một kiến trúc phần mềm vững chắc 22

1.5.4.3 Đáp ứng kịp thời việc thay đổi yêu cầu 23

1.5.4.4 Liên tục tích hợp hệ thống 23

1.6 RUP TẬP HỢP CÁC KINH NGHIỆM TỐT TRONG PHÁT TRIỂN PHẦN MỀM 23 1.6.1 Phát triển phần mềm có sự lặp lại (Iteratively) 24

1.6.2 Quản lý tốt các yêu cầu (Management Requirements) 24

1.6.3 Sử dụng các kiến trúc thành phần (Use Component Architecture) 25

1.6.4 Mô hình hoá các phân tích thiết kế (Model Visually- UML) 26

1.6.5 Liên tục thẩm định chất lượng (Continously Verify Quality) 26

1.6.6 Quản lý thay đổi (Manager Change) 27

1.7 QUY TRÌNH RUP CỦA RATIONAL CORP 28 1.7.1 Quy trình Rational Unified Process-RUP 28

1.7.1.1 Nội dung (Discipline) 30

1.7.1.2 Các pha (Phase) 30

1.7.1.3 Luồng công việc (Workflow) và luồng chi tiết công việc (Workflow Detail) .31

1.7.2 Ngôn ngữ hợp nhất mô hình UML (Unified Modelling Language) 32

Đồ án tốt nghiệp Quy trình RUP và ứng dụng

1.8.1 Giới thiệu nội dung dự án 33

1.8.1.1 Các khái niệm liên quan đến dự án 33

1.8.1.2 Các nguyên lý hoạt động 34

1.8.1.3 Tổng quan dự án 35

1.8.1.4 Hệ thống theo dõi và giám sát (Monitoring and Evaluation Systems) 37

1.8.2 Các yêu cầu khách hàng 37

THỰC HIỆN DỰ ÁN THEO QUY TRÌNH RUP 38

1.9 PHA KHỞI ĐẦU (INCEPTION PHASE) 39 1.9.1 Mục đích yêu cầu 39

1.9.2 Phát triển các tài liệu làm việc (Artifact) 39

1.9.3 Kế hoạch lặp cho giai đoạn khởi đầu 39

1.9.4 Quản lý yêu cầu khách hàng 40

1.9.4.1 Tiếp cận yêu cầu 40

1.9.4.2 Mô hình Use-Case 44

1.9.4.3 Đặc tả Use-Case 47

1.9.4.4 Hỗ trợ đặc tả yêu cầu khách hàng 48

1.9.5 Quản lý rủi ro dự án 50

1.9.5.1 Kế hoạch quản lý rủi ro (Risk Management Plan) 50

1.9.5.2 Danh sách các rủi ro 50

1.9.6 Lập kế hoạch lặp cho giai đoạn tiếp theo 51

1.10 PHA PHÂN TÍCH VÀ THIẾT KẾ (ELABORATION PHASE) 52 1.10.1 Giai đoạn lặp lần thứ nhất (Iteration 1) 52

1.10.1.1 Mục tiêu 52

1.10.1.2 Kế hoạch của giai đoạn lặp thứ nhất 53

1.10.1.3 Phân tích hành vi của hệ thống 53

1.10.1.4 Mô hình hoá trực quan các khái niệm phân tích (Domain và Analysis Model ) 54

1.10.1.5 Mô hình hoá trường hợp sử dụng (Use-Case Model) 59

1.10.1.6 Quản lý phụ thuộc yêu cầu (Management Dependency) 63

1.10.2 Giai đoạn lặp lần thứ hai (Iteration 2) 64

1.10.2.1 Mục tiêu 64

1.10.2.2 Kế hoạch của giai đoạn lặp lần thứ hai 65

1.10.2.3 Sử dụng các mẫu thiết kế (Design Pattern) 65

1.10.2.4 Thiết kế đáp ứng các yêu cầu phi chức năng (Supplementary Specification) 69

1.10.3 Giai đoạn lặp lần thứ ba (Iteration 3) 71

1.10.3.1 Xem xét quan hệ giữa các Use-Case 71

1.10.3.2 Tổ chức thành kiến trúc tổng thể của hệ thống 73

1.11 PHA XÂY DỰNG (CONSTRUCTION PHASE) 75 1.12 PHA CHUYỂN GIAO (TRANSITION PHASE) 75 CÁC KẾT QUẢ ĐẠT ĐƯỢC 76

1.13 CÁC KẾT QUẢ THỰC HIỆN DỰ ÁN 77 1.14 ÁP DỤNG CÁC PATTERN 79 CÁC SO SÁNH ĐÁNH GIÁ VÀ HƯỚNG PHÁT TRIỂN 82

Đồ án tốt nghiệp Quy trình RUP và ứng dụng

1.17.1 RUP chưa phải là quy trình phần mềm hoàn thiện 86 1.17.2 Mở rộng quy trình RUP 87

CÁC PHỤ LỤC 92

1.20.1 Tài liệu quản lý dự án 94 1.20.2 Tài liệu quản lý yêu cầu 94 1.20.3 Tài liệu phân tích thiết kế 94

DANH MỤC HÌNH

DANH MỤC TÀI LIỆU

DANH MỤC BẢNG

DANH MỤC TỪ

Architecture Centric

Artifact

Best Practice

Biểu đồ tiếp diễn

Checkpoint

CMM

CNHPM

Component Architecture

Công nghệ học phần mềm

Công nghệ phần mềm

17, 18, 21, 23, 28, 29, 30, 59, 65, 86,

87, 88, 89

Hệ thống theo dõi và giám sát

Iteratively

Kế hoạch

52, 53, 65, 79, 84, 85, 86, 94, 97 Khái niệm phân tích

Khung nhìn

Khuôn mẫu

Milestone

Mô hình hoá

Monitoring and Evaluation Systems

Nguyên lý định vị

Phân tích

Phân tích viên hệ thống

Phụ thuộc yêu cầu

Quan hệ bao hàm

Quan hệ mở rộng

Quản lý dự án

84, 94, 97 Quản lý rủi ro

Quản lý thay đổi

Quy trình RUP

26, 28, 32, 50, 52, 83, 86, 87, 88 Rađa thụ động

Radioactive Source

Rational RequirePro

Rational SoDA

Rational Unified Process

Report

Role

Rủi ro

Rủi ro kỹ thuật

Rủi ro nghiệp vụ

System Analysis

Tác nhân

Tài liệu viễn cảnh chung

Template

Thiết kế

24, 25, 26, 27, 28, 30, 33, 34, 35, 37, 38, 40, 41, 43, 46, 51, 52, 54, 55, 59, 61, 64, 65, 66, 68, 69, 70, 71, 72, 75, 77, 79, 80, 83, 85, 94, 95, 96 Thiết kế kiến trúc hệ thống phần mềm

77 Tool Mentor

Triển khai

UML

Use-Case Driven

vô tuyến định vị thụ động

Waterfall

Workflow

Yêu cầu chức năng

Yêu cầu phi chức năng

70, 77 Đặc tả yêu cầu khách hàng

Đặc tả yêu cầu phần mềm

77, 94 Đặc tính của sản phẩm

Đặc tính sản phẩm

Đối tượng

58, 61, 64, 65, 66, 67, 68, 69, 71, 72,

77, 79, 83, 86, 89, 91, 94, 95, 96, 97

LỜI CẢM ƠN

Những lời nói đầu tiên của đồ án tốt nghiệp này, tôi xin gửi lời cảm ơn chân

thành tới tất cả mọi người, những người thân trong gia đình, thầy cô giáo, bạn bè

đã giúp đỡ động viên tôi trong thời gian vừa qua giúp tôi hoàn thành đồ án tốt

nghiệp này

Tôi xin gửi lời cảm ơn chân thành và sâu sắc PGS TS Nguyễn Ngọc Bình, bộ

môn Công nghệ phần mềm, khoa Công nghệ thông tin, trường đại học Bách Khoa

Hà Nội, là người không chỉ đã trực tiếp hướng dẫn tôi thực hiện hoàn thành đồ án

tốt nghiệp này, hơn nữa đã cho tôi những điều lớn hơn thế, đó là niềm say mê

hứng thú trong lựa chọn chuyên nghành Công nghệ phần mềm như là một lĩnh

vực chính của mình trong tương lai Bản thân đồ án tốt nghiệp này cũng là nghiên

cứu về một quy trình công nghệ phần mềm, điều làm tôi rất say mê Sự say mê đóhoàn toàn xuất phát từ thực tế, trong thời gian học tập và rèn luyện ở khoa Côngnghệ thông tin, tôi đã nhận ra những điều rất khó khăn trong thực hiện các bài tậplớn dù chỉ là đơn giản nhất nhưng vẫn thiếu đi một điều gì đó còn chưa đượcchuyên nghiệp, chưa phải là quy trình mà vẫn làm theo ý chủ quan Tôi đã sớmnhận ra được điều đó khi học môn Công nghệ phần mềm, sự thiếu hụt, sự khókhăn của mình trong công việc đó chính là công nghệ phần mềm, dù chỉ là các bàitập nhỏ nhất thì cũng phải làm sao cho thật chuyên nghiệp, cho đúng quy trình Vìvậy, ước mơ của tôi là trong thời gian còn học ở trường làm sao để tiếp cậnnghiên cứu thành thạo một quy trình công nghệ phần mềm Và PGS TS NguyễnNgọc Bình đã giúp đỡ tôi thực hiện được ước mơ đó, đã hướng dẫn tôi nghiêncứu quy trình công nghệ phần mềm RUP, là một quy trình công nghệ phần mềmphổ biến hiện nay Đến giờ đây, khi đã hoàn thành đồ án, tôi thấy những kiếnthức mà mình thu được thật bổ ích, giúp cho tôi có một cách tiếp cận và nhìnnhận các dự án một cách dễ dàng và tổng quát nhất

Tôi xin trân trọng gửi lời biết ơn đến các thầy cô giáo trường đại học BáchKhoa Hà Nội, là nơi tôi đã lựa chọn để tiếp thu rèn luyện đạo đức và kiến thứctrong những năm vừa qua Tôi xin chân thành cảm ơn các thầy cô giáo trong khoaCông nghệ thông tin đã dìu dắt tôi những bước đầu tiên trên con đường tiếp cậnkiến thức, tu dưỡng kỹ năng ngành nghề mà tôi lựa chọn, đó là những kiến thức

vô cùng quan trọng là hành trang suốt cuộc đời của mỗi sinh viên Công nghệthông tin Bách Khoa nói chung và bản thân tôi nói riêng

Cuối cùng, tôi xin gửi lời biết ơn tới gia đình, bạn bè đã cổ vũ động viên tinhthần và vật chất, tạo mọi điều kiện cho tôi thực hiện hoàn thành đồ án tốt nghiệpnày một cách thuận lợi nhất Tôi xin chân thành cảm ơn tất cả mọi người

Hà Nội, ngày 10 tháng 05 năm 2004

LỜI NÓI ĐẦU

Hiện nay, có nhiều quy trình công nghệ phần mềm nhằm vào hoạt động tổchức phát triển và quản lý các tác vụ trong phát triển các hệ thống thông tin mộtcách có hiệu quả Mỗi quy trình phần mềm ra đời trong một bối cảnh lịch sử đềuphụ thuộc vào điều kiện công nghệ và các hỗ trợ cho phát triển công nghệ thôngtin hiện tại, trình độ nhận thức cũng như kinh nghiệm phát triển công nghệ thôngtin của các đội dự án Các quy trình công nghệ phần mềm sau một thời gian rađời đều xuất hiện một số hạn chế và xuất hiện các quy trình phần mềm khác cóthể phủ định lên quy trình cũ hoặc có thể hỗ trợ các thiếu xót của quy trình cũhoặc cũng có thể kế thừa từ nhiều ưu điểm của nhiều quy trình công nghệ phầnmềm cũ để tạo nên một quy trình khác Cùng với sự hỗ trợ đắc lực của công các

công cụ kèm theo, các tài liệu, các kinh nghiệm phát triển của các chuyên giatrong phát triển các dự án lớn

Quy trình công nghệ phần mềm Rational Unified Process (RUP) của công tyRational (hiện nay là của IBM) là quy trình công nghệ phần mềm mới ra đời, nó kếthừa từ bốn quy trình công nghệ phần mềm trước đó, bao gồm:

Quy trình thác nước (Waterfall), là quy trình kinh điển nhất và lâu đời nhất và đãtừng được sử dụng rộng rãi, Tuy rằng còn tồn tại nhiều hạn chế, nhưng đó là mộtquy trình công nghệ kinh điển mà hầu hết các quy trình công nghệ phần mềm saunày đều ít nhiều chịu ảnh hưởng của nó

Quy trình phát triển phần mềm theo kiểu chế thử nguyên mẫu (Prototype), thíchhợp cho việc thu thập yêu cầu một cách có hiệu quả

Quy trình phát triển gia tăng (Increamental): một cách tiếp cận dự án theo từngbước, tăng dần sự phát triển dự án theo sự tăng dần nhận thức và hiểu biết cũngnhư kinh nghiệm giải quyết vấn đề của đội dự án

Quy trình xoáy ốc (Sprial): thích hợp với phát triển các dự án lớn và phức tạp.Trong phát triển phần mềm, yếu tố con người và tổ chức dự án là quan trọng.Cần có một khung làm việc thống nhất, một cơ chế thông tin hiệu quả kịp thờigiữa các thành viên, một cơ chế quản lý phân chia công việc toàn diện, hợp lý,lựa chọn công cụ và công nghệ thích hợp, vv，tất cả là để đáp ứng được tốtnhất yêu cầu của khách hàng Đồng thời yếu tố chi phí (nhân lực tiền bạc, vậtchất) và yếu tố thời gian là các yếu tố quan trọng không kém Vậy làm thế nào cóthể đạt được các yếu tố trên một cách đồng thời ?

Quy trình công nghệ phần mềm RUP ra đời đã giải quyết được phần lớn cácyêu cầu đó Nó cung cấp một khung (framework) chung cho toàn đội dự án bằngcách cả đội dự án dùng chung một Website thông tin của dự án, dùng chung cácnguồn tài liệu, các nền tảng kiến thức về công nghệ phần mềm (quy trình RUPluôn sẵn có Online) Đồng thời là sự hỗ trợ hùng hậu và mạnh mẽ của các công

cụ kèm theo của Rational (UML, SoDA, RequirePro, Test Manager, vv) cũng nhưcủa các nhà cung cấp thứ ba (thirt party) như công cụ của Microsoft (VisualStudio, DotNet vv), của Sun (Java…), của Oracle…vv Quy trình công nghệ phầnmềm RUP cũng bao gồm rất nhiều kinh nghiệm của các chuyên gia trong pháttriển phần mềm qua kinh nghiệm thành công của các dự án làm tăng hiệu quảphát triển, giảm đáng kể chi phí và công sức của đội dự án

Quy trình công nghệ phần mềm RUP đưa ra nhiều kinh nghiệm thực tế pháttriển dự án được coi là tốt nhất “Best Practice”, đưa ra nhiều cách tiếp cận dự ánmột cách hiện đại đáp ứng yêu cầu thực tế trong phát triển dự án

Quy trình xử lý hướng sử dụng (Use-Case Driven Process)

Tiếp cận hướng kiến trúc làm trung tâm (Architectutre-centric Process)

Lặp và tăng dần từng bước (Iteration and Increamental)

Mục đích của đồ án của đợt thực tập tốt nghiệp này là nghiên cứu cụ thể mộtcách chi tiết nội dung của quy trình RUP mà trong đợt thực tập chuyên ngànhchưa có điều kiện tiếp cận và tìm hiểu đến và hoàn thiện một cách căn bản cáchiểu biết về quy trình RUP Đồng thời đây cũng là giai đoạn chuyển tiếp để tiếnhành các công việc áp dụng kỹ thuật và công nghệ của quy trình RUP vào thực tế.Tuy nhiên, cả một quy trình phần mềm là rất lớn, bao gồm nhiều phạm vi, nhiềulĩnh vực mà bản thân nó cũng là phát triển cho cả một đội ngũ dự án với nhiều vaitrò khác nhau, đòi hỏi ở mỗi một vai trò cần thiết một nền tảng kiến thức nhất định.

Do đó một cá nhân trong một dự án RUP cũng không thể đảm đương quá nhiềuvai trò được Vì vậy, trong đồ án này, về lý thuyết tôi nghiên nội dung chính (core)của quy trình RUP còn phần thực hiện dự án, tôi chỉ thực hiện trên một số nộidung quan trọng và đóng một số vai trò trong dự án, bản thân một cá nhân khôngthể đảm đương nhiều vai trò được Đó là các nội dung:

Quản lý dự án (Project Management)

Thu thập, phân tích và quản lý yêu cầu (Requirements)

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

Đồng thời nghiên cứu thêm một số công cụ hỗ trợ cho phát triển dự án theoquy trình RUP đó là:

Ngôn ngữ hợp nhất mô hình (Unified Modelling Language UML)

Công cụ lập tàì liệu tự động (Rational SoDA)

Công cụ quản lý yêu cầu: Rational RequirePro

Như ở trên đã nói, bản thân quy trình RUP là một quy trình khá hoàn thiệnnhưng thực tế là chưa đầy đủ, chưa bao quát hết tất các các yếu tố cần thiết cáctác vụ của một quy trình phần mềm Nghiên cứu quy trình RUP của đồ án nàytrước hết là nghiên cứu một quy trình công nghệ phần mềm mới Tất nhiên lànghiên cứu một cách cặn kẽ các vấn đề và các chi tiết nhỏ trong quy trình để cóthể nắm được một cách cơ bản quy trình và có thể áp dụng thực tế được Kết quảcủa nhiệm vụ nghiên cứu này là một tài liệu làm việc của dự án, với các tập yêucầu, tập các thiết kế, tập các tài liệu quản trị dự án (chủ yếu là tập các tài liệu ởmức quản lý, phân tích yêu cầu, phân tích và thiết kế) vì đây cũng là nội dung(core) chính mà tôi tìm hiểu trong quy trình RUP

Trong đồ án tốt nghiệp này tôi tìm hiểu quy trình RUP và ứng dụng của quytrình RUP thực tế ở Việt Nam Đây là yêu cầu thực tế, vì việc áp dụng quy trìnhnhiều khi do nhiều nguyên nhân mà bị bỏ qua (có thể ở mức chấp nhận được haykhông chấp nhận được), và mức độ ảnh hưởng khi áp dụng một cách thiếu xótquy trình như thế Đồng thời, tìm hiểu thiếu xót của quy trình công nghệ phầnmềm RUP và có thể đề ra một cách bổ xung thêm vào quy trình công nghệ phầnmềm này các yếu tố thiếu xót đó, có thể là các Plug-Ins sẵn có của các công cụ

hỗ trợ RUP (trong bản thân quy trình RUP là một hệ thống mở hỗ trợ một cáchlinh hoạt cho việc thêm bớt các cấu hình tuỳ biến của người sử dụng) Điều này,

về kỹ thuật thì không khó, chỉ khó do yếu tố nội dung của các Plug-Ins thực sựphù hợp và nhất quán với toàn bộ quy trình RUP và cài đặt sao cho nó thống nhất

và nhất quán với quy trình ấy Đây cũng chính là nội dung phương hướng mứcgần và mức xa tôi đề xuất trong đồ án tốt nghiệp này

ĐẶT VẤN ĐỀ

Tóm tắt chương

Chương mở đầu này tôi xin được giới thiệu một số nét chung về đồ án tốtnghiệp mà tôi lựa chọn để thực hiện Đồng thời, trong phần này, tôi cũng trình bàymột số nét tổng quan về đề tài của đồ án tốt nghiệp, về những lý do, động cơ thúcđẩy nghiên cứu và tìm hiểu đề tài của tôi, về những mục đích đặt ra và yêu cầucủa của đề tài mà tôi đã nghiên cứu thực hiện trong thời gian qua

1.1 MỤC ĐÍCH CỦA ĐỀ TÀI

Các quy trình công nghệ phần mềm hiện nay có nhiêu, mỗi quy trình phầnmềm có những điểm và các hạn chế nhất định của nó và chỉ thích hợp áp dụngtrong những bối cảnh nhất định Và việc áp dụng các quy trình phần mềm vàotrong các dự án phần mềm luôn luôn phụ thuộc nhiều vào yếu tố con người, vàokhả năng quản lý, phối kết hợp các thành viên trong dự án Ngay cả sản phẩmcủa các dự án phần mềm là các hệ thống phần mềm cũng không thể có một kháiniệm gọi là đúng hay chính xác một cách tuyệt đối để đánh giá chúng, mà chỉ cóthể đánh giá chúng là tốt, tốt hơn hay kém hơn, đạt yêu cầu hay không đạt yêucầu Có nghĩa là sự đánh giá rất “mờ” (fuzzy) không được rõ ràng, và dường như

là không có giới hạn cho sự tốt nhất hoặc xấu nhất Để có một hệ thống phầnmềm “tốt hơn” (better), thì cần thiết phải có yếu tố cầu thành vào trong dự án “tốthơn” và những quy trình phần mềm áp dụng “hợp lý hơn”

Quy trình RUP là một quy trình công nghệ phần mềm ra đời trên cơ sở kếthừa từ nhiều ưu điểm của các quy trình công nghệ phần mềm trước đó (thácnước, lặp và gia tăng, nguyên mẫu, xoáy ốc) Đặc biệt là các tác giả của quy trìnhRUP (Ivar Jacobson, Grady Booch, James Rumbauch, Philippe Kruchten) lại làcác tác giả nổi tiếng có nhiều kinh nghiệm thực tế với các dự án phần mềm vàđồng thời lại là tác giả của ngôn ngữ mô hình hóa đối tượng (UML) Do đó, trongquy trình RUP, các tác giả đã đưa vào rất nhiều kinh nghiệm thành công của các

dự án đã được đúc kết (best practice), cùng với nhiều yếu tố thích hợp để có thểđáp ứng được xu thế của các hệ thống phần mềm hiện đại Với quy trình RUP cáctác giả đã giải quyết tương đối trọn vẹn và chi tiết hầu hết các vấn đề của một dự

án phần mềm Đồng thời cũng nghiên cứu một số công cụ (case tools) hỗ trợ đặcbiệt mạnh mẽ cho quy trình RUP và cũng là một lợi thế rất mạnh của quy trình Như tên của đề tài đồ án tốt nghiệp là “Quy trình RUP và ứng dụng”, chính làthể hiện mục đích của đề tài Việc nghiên cứu quy trình RUP không chỉ là nghiêncứu một quy trình phần mềm mà hơn thế nữa là các tư tưởng tiếp cận và giải quếtvấn đề mà các tác giả đã đưa vào quy trình, các kiến thức yêu cầu đối với cácthành viên tham gia dự án RUP Đồng thời áp dụng quy trình nghiên cứu được đểgiải quyết một vấn đề (dự án) nhỏ (do hạn chế về thời gian và nhân lực) để thấy

rõ và hiểu biết cặn kẽ hơn quy trình RUP, đồng thời đưa ra các đánh giá thích hợp

về tính hợp lý, ưu điểm mạnh mẽ của quy trình, bối cảnh thích hơp để áp dụng vànhững hạn chế , những điểm không thích hợp của nó Tuy nhiên, trong phần thựchiện phần ứng dụng của dự án, tôi chỉ thực hiện một số nội dung của quy trìnhRUP-do hạn chế về thời gian, tôi chỉ tập trung vào thực hiện ba nội dung chính làquản lý yêu cầu, phân tích thiết kế và quản lý dự án theo quy trình RUP Và trongphần ứng dụng tôi có thực hiện xây dựng một số đoạn mã chương trình nhằm đểminh họa các thiết kế của mình

1.2 GIỚI THIỆU BÀI TOÁN, NHIỆM VỤ CỦA ĐỀ TÀI

Nhiệm vụ của đề tài có hai phần rất rõ ràng đó là :

Nghiên cứu quy trình RUP

Áp dụng quy trình RUP đã nghiên cứu vào giải quyết một dự án

Về phần lý thuyết nghiên cứu quy trình RUP, tôi xin trình bày một cách tổngquan các vấn đề có thể coi là tư tưởng chính mang tính cốt lõi của các tác giả đểhình thành nên quy trình RUP Do quy trình RUP không đơn thuần là một quy trìnhphần mềm (với lý thuyết thuần túy và những tư tưởng) mà nó thực sự là một sảnphẩm (product), vì vậy, tôi cũng xin được trình bày về sản phẩm quy trình RUPcủa Rational Corp và IBM (hiện nay hai công ty đã hợp nhất thành IBM), và một

số công cụ liên quan hỗ trợ quy trình Vì quy trình RUP đặc biệt thích hợp áp dụngvới các quy trình phần mềm sử dụng kỹ thuật hướng đối tượng và không thể táchkhỏi UML, nên tôi cũng xin trình bày về mối quan hệ của quy trình RUP và vai tròcủa UML với quy trình RUP (còn tìm hiểu UML là nằm ngoài phạm vi nghiên cứucủa đồ án tốt nghiệp này, coi như bạn đọc đã biết, các bạn có thể tham khảothêm)

Về phần áp dụng quy trình RUP vào thực hiện một dự án, tôi xin trình bày vềnội dung của một dự án lớn và phần thực hiện của tôi là một dự án nhỏ trong dự

án lớn đó Qua đó để bạn đọc có thể nắm được một cách tổng tổng quan về dự

án lớn và nắm chi tiết về vấn đề tồn tại cần giải quyết, các yêu cầu đặt ra trongphạm vi của dự án nhỏ, là phần thực hiện của tôi Sau đó là cách giải quyết dự áncủa tôi theo quy trình phần mền RUP Đồng thời trong quá trình giải quyết dự ántheo quy trình RUP cần phải đưa ra một số các đánh giá về sự phù hợp, hợp lýkhi áp dụng quy trình RUP và những chỗ chưa hợp lý trong quá trình thực hiện Tuy nhiên, do hạn chế về thời gian và nhân lực, nên trong phần thực hiện dự

án tôi không giải quết hết mọi vấn đề trong một dự án theo quy trình RUP và tôicũng không không đóng nhiều vai trò trong một dự án Phần thực hiện của dự ánnày, tôi chỉ giải quyết ba nội dung lớn trong quy trình RUP đó là

Quản lý yêu cầu (Requirement Managements)

Phân tích thiết kế (Analysis and Design)

Quản lý dự án phần mềm (Project Managements)

Đồng thời để giải quyết các vấn đề đó tôi thực hiện một số vai trò trong dự ánlà: phân tích viên hệ thống (System Analysis), đặc tả yêu cầu phần mềm(Requirement Specifier), thiết kế kiến trúc hệ thống phần mềm (SoftwareArchitecture), thiết kế (Designer), quản lý dự án (Project Manager) Các sản phẩmchuyển giao của nghiên cứu và thực hiện là các mô hình và báo cáo cùng các tàiliệu trong quá trình thực hiện ba nội dung trên của quy trình RUP Việc lập trìnhthực hiện trên một số Use-Case chủ yếu để mô tả ý nghĩa và tính chất đúng đắn

của các thiết kế, chưa phải là nội dung chuyển giao cuối cùng của một dự ánphần mềm

1.3 LÝ DO CHỌN ĐỀ TÀI

Làm phần mềm không chỉ là lập trình, tạo mã một cách đơn thuần để cuốicùng ra một chương trình có khả năng chạy được Điều đó chỉ thích hợp với các

dự án thật nhỏ, và rất nhỏ, hay đúng hơn là các chương trình đơn giản Với các

dự án phần mềm còn có rất nhiều điều quan trọng hơn thế, ở mức phân tích thiết

kế, ở mức quản lý, phối kết hợp các nguồn nhân lực trong dự án một cách hiệuquả và thực tế thành công của các dự án phần mềm ngày càng nhiều phụ thuộcvào các yếu tố đó Và cũng có nhiều lý thuyết, tư tưởng ra đời để thực hiện cáccông việc đó, đó là các quy trình phần mềm

Trong nhà trường, tôi đã được học về rất nhiều quy trình phần mềm, việcnghiên cứu thực sự sâu sắc về một quy trình phần mềm là không có điều kiện , dohạn chế về thời gian Và do nhận thức dự án tầm quan trọng của quy trình phầnmềm đối với các dự án phần mềm, nên tôi chọn đề tài “quy trình phần mềm RUP

và ứng dụng” là đề tài tốt nghiệp của mình Với tất cả các kiến thức cơ sở đãđược học trong nhà trường cùng sự hướng dẫn của thầy, tôi cố gắng, tìm hiểunghiên cứu quy trình RUP, là một trong những quy trình phần mềm rất hiện đạihiện nay Điều này, đối với một sinh viên chưa có thực tế thì hơn khó khăn vìnghiên cứu và hiểu một quy trình phần mềm và đóng nhiều vai trò trong quy trình

ấy thì ngoài yêu cầu kiến thức ở mức nhất định thì cần thiết phải có những trảinghiệm thực tế Tuy nhiên, điều đó chỉ là yếu tố khách quan Trong thời gian qua,được sự hướng dẫn tận tình của PGS.TS Nguyễn Ngọc Bình, bộ môn Công nghệphần mềm, khoa Công nghệ thông tin, trường Đại học Bách Khoa Hà Nội, và sự

cố gắng của bản thân, tôi đã thực hiện hoàn thành yêu cầu của đề tài Với việcnghiên cứu một quy trình phần mềm và ứng dụng nó vào thực tế, tôi nghĩ đó làmột bước chuyển tiếp nghiên cứu rất quan trọng, từ hàn lâm sang công nghiệp, làbước chuẩn bị quan trọng Do đó, theo tôi nghĩ đây là một đề tài rất hay, và thiếtthực, và rất tin tưởng thực hiện đề tài này

TỔNG QUAN VỀ QUY TRÌNH RUP

Tóm tắt chương:

Trong chương này mục đích của tôi xin trình bày về một số vấn đề thuộc về

cơ sở lý thuyết của đề tài thực tập:

Các vấn đề trong phát triển phần mềm: Khái niệm về công nghệ học phần mềm Khái quát về quy trình RUP Quy trình RUP ra đời là do yêu cầu khắc phục và hạnchế một số khó khăn của các quy trình phát triển phần mềm trước Tuy rằng nócũng có các ưu điểm và nhược điểm

Trình bày về một số tư tưởng chính của quy trình RUP, đó là các quan điểm tổngquát bao hàm và xuyên xuốt quy trình RUP là nền tảng cho sự phát triển của quytrình RUP

Một số kinh nghiệm phát triển phần mềm hiện đại được đưa vào quy trình RUPcùng một số công cụ hỗ trợ

1.4 MỘT SỐ VẤN ĐỀ TRONG PHÁT TRIỂN PHẦN MỀM

1.4.1 Công nghệ học phần mềm

Vì RUP là một quy trình phần mềm, vì vậy để nghiên cứu một quy trình côngnghệ phần mềm trước hết cần thiết phải nắm được khái niệm về công nghệ họcphần mềm Khái niệm công nghệ học phần mềm: có rất nhiều định nghĩa về côngnghệ học phần mềm của rất nhiều tác giả tuỳ theo quan điểm và hoàn cảnh lịch

sử trong từng giai đoạn, thời kỳ:

Bauer [1969]: “CNHPM1 là việc thiết lập và sử dụng các nguyên tắc công nghệhọc đúng đắn dùng để thu được phần mềm một cách kinh tế vừa tin cậy vừa làmviệc hiệu quả trên các máy thực”

Parnas [1987]: “CNHPM là việc xây dựng phần mềm nhiều phiên bản bởi nhiều

người”

Ghezzi [1991]: “CNHPM là một lĩnh vực của khoa học máy tính, liên quan đến

xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một sốnhóm kỹ sư”

IEEE [1993]: “CNHPM là

− Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hoá trong phát triển, vận hành và bảo trì phần mềm;

− Nghiên cứu các phương pháp tiếp cận được dùng trong (1)"

Pressman [1995]: “CNHPM là bộ môn tích hợp cả quy trình, các phương pháp,

các công cụ để phát triển phần mềm máy tính”

Sommerville [1995]: “CNHPM là lĩnh vực liên quan đến lý thuyết, phương pháp

và công cụ dùng cho phát triển phần mềm”

K Kawamura [1995]: “CNHPM là lĩnh vực học "vấn về các kỹ thuật, phương

pháp luận công nghệ học (lý luận và kỹ thuật được hiện thực hoá trên nhữngnguyên tắc, nguyên lý nào đó) trong toàn bộ quy trình phát triển phần mềm nhằmnâng cao cả chất và lượng của sản xuất phần mềm”

Bộ môn công nghệ phần mềm, khoa Công nghệ thông tin, trường Đại học Bách

Khoa Hà Nội: “

Công nghệ học phần mềm là lĩnh vực khoa học về các phương pháp luận, kỹthuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằmtạo ra phần mềm với những chất lượng mong muốn”

Về công nghệ học phần mềm, các bạn có thể tham khảo giáo trình về tài liệucông nghệ học phần mềm của bộ môn Công nghệ phần mềm, khoa Công nghệthông tin, trường Đại học Bách Khoa Hà Nội, hoặc các tài liệu tham khảo khác

1 Công nghệ học phần mềm

1.5 QUY TRÌNH PHẦN MỀM RUP (Rational Unified Process)

1.5.1 Hiệu suất phát triển phần mềm

Năm 1990, Kitchenham đã đề ra công thức toán học ước lượng đánh giá cácchi phí và hiệu năng phát triển phần mềm Công thức này đã được chấp nhậnrộng rãi và trong các báo cáo điều tra của IBM về xu hướng của nền kinh tế phầnmềm hiện đại trong những năm gần đây [11] cũng xác nhận điều đó Công thức

đó là:

Trong đó:

Project Performance là nỗ lực hay thời gian phát triển phần mềm, cần phải hạnchế càng thấp càng tốt

Complexity là độ phức tạp của dự án, càng phức tạp thì giá trị càng lớn

Process là quy trình phần mềm, giá trị được chọn trong khoảng từ 0 đến 1, là độthành thục trong phát triển phần mềm Nếu quy trình càng tốt thì giá trị này càngnhỏ, giá trị này bằng 0 là tốt nhất và bằng 1 là tồi nhất (có nghĩa là luôn thay đổicùng với sự phức tạp của dự án)

Team là kỹ năng kinh nghiệm và kỳ vọng của đội dự án

Tools là các công cụ hỗ trợ tự động các quá trình trong phát triển phần mềm Vấn đề quan trọng là làm sao làm giảm nỗ lực và thời gian phát triển phầnmềm Trong công thức toán học trên ta thấy nó được cấu thành từ bốn yếu tố là

độ phức tạp của dự án, về quy trình xử lý áp dụng trong dự án, về kỹ năng kinhnghiệm và hợp tác các thành viên và cuối cùng là các công cụ (case tools) sửdụng trong một số quá trình tự động trong dự án

Quy trình RUP tập trung vào các làm giảm các yếu tố cấu thành nên chi phíthời gian và nỗ lực phát triển phần mềm của công thức ước lượng trên [11] Đồngthời, quy trình RUP còn kế thừa có chọn lọc nhiều quy trình phần mềm trước đó

và có sự hỗ trợ mạnh mẽ của các công cụ đặc biệt là các công cụ của Rational.Trong phần này, tôi xin trình bày các tư tưởng chính hình thành nên bản chất củaquy trình phát triển phần mềm RUP Quy trình RUP, đó là:

Hướng sử dụng (Use-Case Driven)

Lấy kiến trúc làm trung tâm (Architecture Centric)

Lặp và gia tăng từng bước (Iterative and Incremental)

) (

) (

) (

e Performanc

=

1.5.2 Quy trình công nghệ phần mềm RUP hướng sử dụng Case Driven)

(Use-Mục tiêu của quy trình công nghệ phần mềm RUP là thực hiện ra các sảnphẩm đáp ứng được nhu cầu tối đa của khách hàng Hiệu năng của được tínhbằng giá thành, chất lượng, và thời gian thực hiện sản phẩm Mọi hoạt động trong

dự án làm ra sản phẩm là thỏa mãn được yêu cầu khách hàng

Tuy nhiên yêu cầu của khách hàng rất đa rạng, phong phú, có thể phân ra làmhai loại yêu cầu là:

Các yêu cầu chức năng:Thể hiện các chức năng sẽ được cung cấp của hệ thống,

và xác định rõ ràng cho mỗi yêu cầu là cung cấp các chức năng cụ thể cho mỗingười sử dụng (for each user?) Yêu cầu này thực sự quan trọng, chúng là mụctiêu của các phân tích thiết kế và cài đặt sau này (drive the development process).Các yêu cầu này dễ dàng được mô hình trực quan bằng công cụ UML

Yêu cầu phi chức năng: Là các yêu cầu hỗ trợ cho hệ thống tuy nhiên rất quantrọng Nó không phải là chức năng sử dụng được của hệ thống mà chỉ là các ràngbuộc khác yêu cầu hệ thống phải thỏa mãn Các yêu cầu này không được thểhiện trên các mô hình và không phải chức năng gọi là yêu cầu phi chức năng.Quy trình công nghệ phần mềm RUP bắt đầu bằng việc lưu giữ yêu cầu củakhách hàng, bằng các mô hình Use-Case Sau đó mọi hoạt động phân tích, thiết

kế cài đặt là đáp ứng các Use-Case Cuối cùng là việc kiểm thử là để đáp ứngthẩm định các yêu cầu của khách hàng đã được đáp ứng Trong các mô hình đóthì mô hình cài đặt (Implementation Model) là hiện thực nhất, mô hình yêu cầuUse-Case là trừu tượng nhất, gần với ngôn ngữ tự nhiên nhất, diễn tả ngôn ngữcủa khách hàng Tuy nhiên có một điều là trong quy trình RUP, mọi hoạt độngphân tích thiết kế, kiểm thử, xem xét (review) và chấp nhận phê chuẩn (approve)đếu tiến hành dựa trên mô hình quản lý yêu cầu khách hàng (use-case model)

Bùi Doãn Ngọc-CNPM K44-Đại học Bách Khoa Hà Nội 17/99

Trace to

Trace to Trace to

Trace to

Trace to Use-Case

Mode

Analyis Mode

Design Mode Deployment

Mode

Implementation Mode

Hình 2-1 Quy trình RUP hướng sử dụng (Use-Case Driven)

Quy trình RUP hướng sử dụng (Use-Case Driven) có nghĩa là một quy trìnhphát triển là một luồng nối tiếp nhau mà khởi đầu của luồng đó là các chức năngcủa hệ thống

1.5.3 Quy trình công nghệ phần mềm RUP lấy kiến trúc làm trung tâm (Architecture Centric)

1.5.3.1 Mô hình và kiến trúc phần mềm

Trong quy trình phần mềm RUP một trong những công việc quan trọng là sửdụng các mô hình với các ký pháp để mô tả hệ thống, các vấn đề và cách thứcgiải quết vấn đề dựa trên các mô hình ấy Các mô hình giúp mô tả hệ thống vốnphức tạp trong thực tế theo một cách đơn giản dễ hiểu và một điều quan trọng làrất trực quan

Tuy nhiên, không thể có một mô hình nào mà lại bao quát được hết tất cả mọivấn đề, mọi góc nhìn, mọi giải pháp phân tích thiết kế cho một hệ thống Cũnggiống như các hình chiếu trong các bản vẽ kỹ thuật, chúng ta cần phải rất nhiềuhình chiếu trên các góc độ khác nhau, thậm chí cắt lắt theo các mặt khác nhau đểtìm hiểu hết được chi tiết phức tạp của vật thể chi tiết máy Phần mềm cũng là mộtsản phẩm phức tạp, có kiến trúc, cấu tạo bởi nhiều thành phần khác nhau, và mỗithành phần cũng có kiến trúc khác nhau Do vậy, để phân tích thiết kế phần mềmmột cách chi tiết và hoàn chỉnh chúng ta cần nhiều mô hình và mỗi một mô hình

có thể coi như là một mặt cắt của hệ thống phần mềm phức tạp Mỗi mô hình thểhiện sự quan tâm một khía cạnh khác nhau đối với hệ thống Do vậy, trong tài liệu

dự án của một hệ thống phần mềm theo quy trình RUP có rất nhiều các mô hình,

và bản thân các mô hình rất phức tạp Tuy nhiên, phải đảm bảo làm sao cho các

mô hình ấy thực sự nhất quán với nhau, mô tả vừa đủ không thừa không thiếu để

có thể hiểu được hệ thống, đó chính là kiến trúc của hệ thống “Architecture iswhat remains when you cannot take away any more things and still understand thesystem and explain how it works.”[2]

1.5.3.2 Kiến trúc phần mềm là quan trọng

Trong quá trình làm phần mềm, các nhà thiết kế có cảm giác là kiến trúc phầnmềm là yếu tố nào đó rất quan trọng, tuy nhiên, việc diễn tả khái niệm đó ra lạikhông phải lúc nào cũng rõ ràng và rành mạch được, bởi vì bản thân kiến trúcphần mềm là một khái niệm mờ (fuzzy) và rất trừu tượng (abstract) Trong các dự

án nhỏ thì kiến trúc phần mềm nhiều khi không thể hiện rõ ràng thành các mô hình

và văn bản mà có thể coi như là thỏa thuận hoặc hiểu ngầm giữa các nhà pháttriển và chỉ họ mới hiểu Tuy nhiên, với các hệ thống lớn, yêu cầu phức tạp, nhiềuthay đổi mà không có các tài liệu các mô hình mô tả hệ thống khiến các nhà pháttriển không thể nào bao quát theo dõi được hết mọi vấn đề, không quản lý và theokịp được sự thay đổi dẫn tới không khắc phục được rủi ro của dự án, và dễ dàngdẫn tới đổ vỡ dự án

1.5.3.3 Yêu cầu của kiến trúc phần mềm

Một kiến trúc phần mềm tốt phải mô tả tốt được các yêu cầu sau:

Mô tả được mục đích của hệ thống

Diễn tả các kiến trúc hệ thống càng trực quan càng tốt, mô tả các ngữ nghĩa của

hệ thống, tránh các nhập nhằng gây hiểu lầm

Các xử lý để mô tả hệ thống (architecture process), mô tả cách thức tạo và kiếmtra các mô hình, các kiến trúc, các tài liệu cho dự án, chỉ ra vai trò (who?) cần thiếttrong dự án để hoàn thành tài liệu đó

1.5.3.4 RUP là quy trình lấy kiến trúc phần mềm làm trung tâm

Tư tưởng lấy kiến trúc làm trung tâm của quy trình phần mềm RUP là xácđịnh mỗi thành phần tham gia vào dự án phải được tổ chức trên các mô hình vàthể hiện tốt các mối liên quan vai trò trách nhiệm của chúng trong tổng thể dự ántheo các kiến trúc đã thống nhất trong dự án Quy trình RUP xác định vai trò và vịtrí của kiến trúc phần mềm như sau:

Kiến trúc phần mềm trong quy trình RUP không chỉ quan tâm đến cấu trúc vàcác hành vi của các thành phần mà nó còn quan tâm đến các khía cạnh khác rấtquan trọng của hệ thống là các yêu cầu mà rất khó có thể thể hiện trên các môhình, đó là: tính sử dụng, tính chức năng, khả năng thực thi, co giãn hệ thống (khảnăng mở rộng và thu hẹp), tái sử dụng., tính dễ hiểu, tính kinh tế của dự án, cácràng buộc kỹ thuật, và các thỏa hiệp, vv.

Quy trình RUP thể hiện các kiến trúc phần mềm, thông qua các vai trò(Roles), mô hình (Models) và khung nhìn (View), vv tạo thành các mô hình phứctạp đa chiều (multidimentional) của hệ thống phần mềm Trong mỗi một khung nhìnđảm bảo các yêu tố sau

Mục tiêu chính của mô hình, là lĩnh vực quan tâm quan trọng nhất mà mô hình mà

nó thể hiện

Các thành trong mô hình cùng với các mối quan hệ của chúng

Cấu trúc tổ chức của các thành phần

Các xử lý áp dụng đối với mô hình

Trong quy trình RUP thể hiện bằng kiến trúc rất nổi tiếng là mô hình kiến trúc4+1

Hình 2-2 Khung nhìn kiến trúc 4+1

Khung nhìn Use-Case

Đóng vai trò quan trọng trung tâm trong kiến trúc phần mềm, nó bao gồm một

số kịch bản của các Use-Case quan trọng

Khung nhìn Logic

Khung nhìn logic của kiến trúc mô tả các yêu cầu về chức năng của hệthống-chức năng cung cấp cho người sử dụng

Khung nhìn cài đặt (Implementation View)

Mô tả tổ chức của các thành phần tĩnh của dự án tổ chức mã nguồn, file, cácthành phần

Khung nhìn xử lý

Deployment View

Implementation ViewLogical View

Implementation View

Use-Case View

Mô tả hệ thống trong quá trình thực hiện, các tác vụ, các luồng, phân tuyến vàcác tương tác của chúng, sự phân bổ các đối tượng cho các xử lý, vv

Khung nhìn triển khai

Mô tả các thành phần của hệ thống trên các nền phần cứng phần mềm của

Đưa ra các luận chứng kinh tế cho dự án về tính kinh tế của dự án

Lý do chính để phát triển một phần mềm theo cách tiếp cận lặp và gia tăng làmột điều đơn giản mà rất khó khăn: tạo nên một phần mềm tốt hơn (bettersoftware) Việc lặp và gia tăng thông qua các pha, trong pha có các bước lặp nhỏ(Iterative) và có các mốc rõ ràng thông qua các bước lặp đó Trong mỗi bước lặptoàn bộ dự án được tiến hành xem xét qua tất cả các bước (yêu cầu, phân tích ,thiết kế, …) Đồng thời thông qua các bước lặp để kiểm soát sự phát triển

Ta sẽ xem xét cụ thể việc lặp và gia tăng từng bước của quy trình RUP nhưsau

1.5.4.1 Hạn chế rủi ro

Rủi ro là một vấn đề lớn trong trong phát triển phần mềm, là nguyên nhân của

sự đổ vỡ trong phát triển phần mềm Trong bất kỳ một quy trình phần mềm nàocũng cần thiết phải quan tâm đến rủi ro một cách thích đáng

Iterative and Incremental

Waterfall

Risk

Hình 2-3 Quy trình RUP hạn chế và khắc phục rủi roTrong quy trình thác nước được tiến hành theo một chiều không có sự xemxét lại thì việc tiến hành dự án ban đầu có vẻ rất suôn xẻ nhưng rủi ro thực sự vànặng nề xuất hiện khi mà kiểm thử và tích hợp hệ thống Các rủi ro xuất hiện ởgiai đoạn này rất nhiều có thể dẫn đến đổ vỡ dự án Để hạn chế rủi ro, trong quytrình phần mềm tiếp cận lặp và gia tăng sẽ tiến hành từ rất sớm, các rủi ro trọngyếu được lưu ý ngay từ ban đầu,và có kế hoạch ngăn chặn và có kế hoạch khắcphục Hơn thế nữa, thông qua quá trình lặp và gia tăng để tăng cường sự học hỏi

và tiếp cận của đội dự án

Trong quá trình làm dự án phần mềm, có một cách tiếp cận mà khá quantrọng đó là tiếp cận dự án theo hướng khắc phục rủi ro của dự án (Risk DrivenApproach) Cách tiếp cận lặp và gia tăng chính là một trong những cách tiếp cậnhướng khắc phục rủi ro Trong quá trình làm dự án, liên tục phải phát hiện, phânloại và đề ra các chiến lược nhằm hạn chế rủi ro, và quá trình này được lặp đi lặplại

1.5.4.2 Tạo một kiến trúc phần mềm vững chắc

Kiến trúc phần mềm được tiến hành xây dựng từ rất sớm, bắt đầu là cácthành phần quan trọng nhất có tính chất trọng yếu của dự án, thỏa mãn được cácyêu cầu quan trọng nhất (chính là bộ khung của dự án) Giải quết các yêu cầu đóthông qua quá trình xem xét khắc phục rủi ro có thể xảy ra với các yêu cầu quantrọng nhất, đó cũng chính là cá rủi ro trọng yếu nhất, một trong những cách tiếpcận trung tâm của quá trình phát triển phần mềm theo cách tiếp cận lặp và giatăng Hơn nữa việc xem xét vấn đề một cách lặp đi lặp lại nhằm tăng cường khả

năng giải quết vấn đề, hiểu biết vấn đề và đó là một trong những cách tiếp cận đểhọc hỏi của con người trước các vấn đề mới

Việc xây dựng kiến trúc trong quy trình phần mềm lặp bắt đầu từ các thànhphần quan trọng nhất, xây dựng dần dần, có sự lặp lại Kiến trúc phần mềm của

hệ thống được xem xét lặp đi lặp lại do đó làm giảm được các rủi ro

1.5.4.3 Đáp ứng kịp thời việc thay đổi yêu cầu

Hoạt động của các bản mẫu phần mềm ngay cả khi nó chưa hoàn thiện, chưahiệu quả, chưa chính xác cũng giúp các khách hàng có những hình dung đúngđắn, hiểu hệ thống hơn và những điều chỉnh thay đổi trong thời gian làm dự án,ngay từ rất sớm Theo đó khách hàng có các phản hồi lại đội dự án , và cần thiếtphải có các điều chỉnh kịp thời từ phía đội dự án Đó chính là việc đáp ứng việcthay đổi yêu cầu của quy trình RUP Vì việc thay đổi yêu cầu là một quá trình tấtyếu trong các dự án phần mềm, các yêu cầu ngay từ ban đầu không bao giờ đầy

đủ và chính xác, cần thiết phải có quá trình xem xét, kiểm duyệt yêu cầu một cáchkịp thời

Phát triển phần mềm có sự lặp lại (Develop Iteratively)

Quản lý yêu cầu khách hàng (Manage Requirements)

Sử dụng kiến trúc thành phần (Use Component Architecture)

Mô hình hoá trực quan các phân tích thiết kế (Model Visually- UML)

Liên tục thẩm định chất lượng phần mềm (Continously Verify Quality)

Quản lý thay đổi (Manage Change)

1.6.1 Phát triển phần mềm có sự lặp lại (Iteratively)

Hình 2-4 Phát triển lặp và tăng dần từng bước

Kế thừa từ mô hình chế thử và mô hình xoắn ốc Mỗi lần phát triển trải quacác hoạt động có tính chất lặp lại từ khảo sát , đánh giá, phân tích, thiết kế, kiểmthử đánh giá rút kinh nghiệm cho lần phát triển sau, tuy nhiên ở mức độ phát triểncao hơn Nguyên nhân của việc phát triển lặp lại là việc tiếp cận vấn đề cần phảitrải qua một thời gian, có sự làm đi làm lại mới phát triển đúng Không thể ngay từlần đầu tiên đã hoàn thành ngay mọi công việc Mặt khác việc phát triển lặp nhưtrên làm phân bố lại các công việc tương đối dàn trải theo thời gian trong pháttriển dự án phần mềm Tác dụng của phát triển lặp:

Giảm rủi ro, về số lượng cũng như mức độ: vì nhiều rủi ro chỉ xuất hiện khi màđến một giai đoạn và thời kỳ nào đó trong làm dự án, cần phải nhanh nhất nắmđược rủi ro và có các biện pháp khắc phục càng sớm càng tốt

Dễ quản lý yêu cầu: do yêu cầu của khách hàng có thể thay đổi thường xuyên, dohoàn cảnh thay đổi, và các tác động khác Nói chung là trong phát triển dự án phảichấp nhận thay đổi và quản lý thay đổi

Dễ dàng phát triển và cải tiến sản phẩm trong thời gian phát triển

Tổ chức làm dự án có thể điều kiện tiếp cận và hiểu dự án

Tăng khả năng tái sử dụng: trong quá trình phát triển, xem xét vấn đề một cáchlặp đi lặp lại, giúp cho các nhà phân tích có thể nhận ra các thành phần chung, cóthể tái sử dụng, mà ngay lần tiếp cận đầu tiên không dễ gì nhận ra

1.6.2 Quản lý tốt các yêu cầu (Management Requirements)

Quản lý yêu cầu là công việc phát hiện ra các yêu cầu, phân tích yêu cầu, lậptài liệu, theo dõi và quản lý sự thay đổi của các yêu cầu Định nghĩa yêu cầu củamột hệ thống phần mềm là khả năng hay năng lực mà hệ thống phải đáp ứng vàthoả mãn

Trong thực tế yêu cầu của phần mềm đôi khi không được nhà phát triển dự ánhiểu đúng và đó cũng là một loại rủi ro lớn của dự án phần mêm

Các yêu cầu không rõ ràng, từ nhiều nguồn gốc khác nhau

Các yêu cầu đôi khi không dễ dàng thể hiện bằng từ ngữ

Có nhiều loại yêu cầu cần có sự phân loại thích hợp

Các yêu cầu chồng chéo lên nhau, đôi khi mâu thuẫn nhau,cần có sự thoả hiệpcác yêu cầu

Yêu cầu thay đổi

Để quản lý yêu cầu Rational Unified Process đưa ra công cụ RationalRequirePro để quản lý yêu cầu và công cụ UML để mô hình hoá yêu cầu Và việcphân tích thiết kế sử dụng mô hình hoá là một trong các quy tắc phát triển củaRational Và họ đưa ra một cách tiếp cận cho vấn đề đó là cách tiếp cận hướngtheo yêu cầu của người sử dụng (Use – Case Driven Approach), điều đó có nghĩa

là các Use-Case đã được định nghĩa và phát triển sẽ là các nền tảng cho toàn bộcác hoạt động của dự án về sau, dựa trên sự phát triển các hệ thống Use-Caseđó

1.6.3 Sử dụng các kiến trúc thành phần (Use Component

Architecture)

Hình 2-5 Kiến trúc dựa thành phần

Là hoạt động của phân tích và thiết kế Các thành phần kiến trúc của hệ thốngphần mềm là một kiến trúc dựa trên các thành phần có thể thay thế, khiến chophần mềm có khả năng linh hoạt, dễ thay đổi, tiết kiệm công sức trong phát triển

hệ thống dựa trên các thành phần sẵn có và giúp cho dễ dàng quản lý các hệthống phức tạp nhiều thành phần Rational Unified Process hỗ trợ rất mạnh chophát triển phần mềm dựa thành phần

1.6.4 Mô hình hoá các phân tích thiết kế (Model Visually- UML)

Hình 2-6 Mô hình hóa phân tích thiết kế

Mô hình hoá các phân tích thiết kế là sử dụng các công cụ mô hình hoá, tậpcác ký hiệu trực quan và các luật để biểu diễn các mô hình kiến trúc của hệ thống.Quá trình mô hình hoá sẽ liên tục theo thời gian, qua mỗi pha thì nó được làm mịndần các thiết kế Trong quy trình RUP có một số các mô hình

Mô hình sử dụng (Use-Case Model)

Mô hình phân tích (Analysis Model)

Mô hình thiết kế (Design Model)

Mô hình cài đặt (Implementation Model)

Các mô hình đi từ trên xuống, càng ở trên thì càng thô, tuy nhiên lại dễ hiểuđối với con người, càng dưới thì càng mịn, càng gần với sự thực thi trong máytính, tuy nhiên rất phức tạp Quy trình RUP đưa ra cách tiếp cận mô hình hoá trựcquan các mô hình từ đơn giản đến phức tạp, giúp con người dễ dàng kiểm soátcác thiết kế của mình thông qua các công cụ trực quan Đây là một lợi thế rấtmạnh của quy trình RUP

1.6.5 Liên tục thẩm định chất lượng (Continously Verify Quality)

Trong quá trình làm phần mềm, nếu một vấn đề sai xót hoặc lỗi được pháthiện và sửa chữa sau khi chuyển giao phần mềm sẽ tốn kém gấp từ một trăm đếnmột nghìn lần vấn đề đó nếu nó được phát hiện trong quá trình làm phần mềm[2] Do đó, điều rất quan trọng là cần thiêt phải liên tục có sự đánh giá và thẩmđịnh chất lượng phần mềm (ví dụ như các khía cạnh về chức năng, về độ tin cậy,khả năng thực thi của phần mềm và của hệ thống…vv) Cần phải phát hiện lỗicàng sớm càng tốt

Hình 2-7 Chi phí khắc phục và lỗi theo thời gian

Liên tục thẩm định chất lượng của phần mềm có nghĩa là liên tục tạo ra cáckiểm thử đánh giá chức năng và hành vi và hoạt động của hệ thống Thông quaquá trình liên tục đánh giá thẩm định đó rủi ro có thể ảnh hưởng đến chất lượngphần mềm sớm được quản lý và có kế hoạch khắc phục ngay từ ban đầu, cónghĩa là có kế hoạch phát hiện, quản lý và khắc phục rủi ro ngay từ sớm nhất cóthể, như trên biểu đồ Như vậy làm giảm chi phí phát triển phần mềm Mặt khácliên tục thẩm định đánh giá chất lượng phần mềm giúp các nhà quản lý dự án cóđiều kiện sớm tìm hiểu nguyên nhân của các vấn đề của dự án và có thể sớm tìm

ra được bản chất của vấn đề Điều này cũng phù hợp với cách thức nhận thức vàtiếp cận vấn đề của con người không thể ngay một lúc mà có thể hiểu và nắm bắthết mọi thứ, cần thông qua quá trình tiếp cận dần dần và có sự lặp lại ở mức caohơn và sâu hơn về bản chất của cùng một vấn đề Tuy nhiên, có một điều mà tacần phải lưu ý ở đây là, việc liên tục thẩm định chất lượng phần mềm và quản lýrủi ro này chỉ làm phần mềm ít lỗi và tăng độ tin cậy hơn chứ không thể làm chochất lượng phần mềm vượt quá mục tiêu của yêu cầu và khâu thiết kế được Vànhư biểu đồ ở trên đã chỉ ra trong thực tế là phát hiện và khắc phục lỗi càng sớmthì càng hạn chế được chi phí và tăng độ tin cậy của phần mềm

1.6.6 Quản lý thay đổi (Manager Change)

Có một vấn đề thực tế trong phát triển của các hệ thống phần mềm là các dự

án phần mềm được cấu thành từ nhiều yếu tố (con người, tổ chức, trình độchuyên môn, trình độ tiếp cận nghiệp vụ, chức vụ hoàn cảnh công việc khác nhaucủa các thành viên tham gia, vv) Tóm lại là rất nhiều yếu tố khác biệt cùng tồn tạitrong cùng một dự án phần mềm bắt buộc phải chấp nhận, không có cách nàokhác Vì vậy, vấn đề yêu cầu cần đặt ra làm làm thế nào để phối kết hợp các yếu

tố cấu thành của dự án một cách hiệu quả mà vẫn phải chấp nhận sự khác biệt vềnhiều thứ kể trên Nhiều khi các vấn đề xảy ra mà rất khó xác định được nguyênnhân gốc rễ của nó để khắc phục, vì các yếu tố liên quan chồng chéo lên nhau, và

Thời gian Chi phí

các tác động nhiều chiều xảy đối với các vấn đề đó Nhận thức vấn đề quan trong

đó, quy trình RUP đề nghị đưa ra cách thức kiểm soát sự thay đổi trong dự ánphần mềm Thông qua quá trình kiểm soát thay đổi đó, các gốc rễ của vấn đềđược xác định, các tác động nhiều chiều được xác định và quản lý Và thông quáquá trình quản lý có kế hoạch đó, giúp các nhà quản lý dự án có thể tiên đoánđược một số vấn đề và có kế hoạch quản lý trước khi nó xảy ra Kiểm soát sựthay đổi, giúp các nhà quản lý dự án sớm đưa ra được các giải pháp khắc phụccác vấn đề trong phát triển phần mềm một cách tương đối tốt

1.7 QUY TRÌNH RUP CỦA RATIONAL CORP

Ngoài ý nghĩa là một quy trình phần mềm, RUP thực sự là một sản phẩm sửdụng của Rational, do đó trong phần này tôi xin trìn bày về sản phẩm RUP củaRational Corp Đây là giải pháp của Rational cho quy trình công nghệ phần mềmbao gồm cả quy trình và công cụ và là một điểm rất mạnh của quy trình RUP.Trong đồ án tốt nghiệp của tôi cũng có sử dụng một số trong các công cụ đó:Quy trình RUP (Rational Unified Process)

Bộ công cụ mô hình hóa phân tích thiết kế (Unifed Modelling Language-UML)

Bộ công cụ phân tích và quản lý yêu cầu (Rational RequirePro)

Bộ công cụ lập tài liệu (Rational SoDA)

1.7.1 Quy trình Rational Unified Process-RUP

Hình 2-8 Quy trình Rational Unified Process-RUP

Để thể hiện quy trình công nghệ phần mềm, RUP đưa ra thành phần, các kháiniệm để cấu thành để thể hiện nội dung của quy trình Về cơ bản, kiến trúc xử lýcủa của quy trình RUP gồm hai chiều Nếu trên góc độ các trục tọa độ là hai trụchoành (ngang) và trục tung (thẳng đứng), nếu trên góc độ xử lý thì nó thể hiện

khía cạnh động theo thời gian và khía cạnh kiến trúc tĩnh các thành phần tham gia

xử lý Khía cạnh động của hệ thống thể hiện bằng các pha, các tương tác, cácmốc xử lý Khía cạnh tĩnh của hệ thống thể hiện mối liên quan của các thành phầncấu thành nên quy trình phần mềm RUP (các thành phần, các tài liệu, các luồngcông việc, thành viên dự án vv), đó là các nội dung công việc của quy trình(Discipline)

Nội dung của quy trình RUP bao gồm các thành phần như như sau:

Quy trình công nghệ phần mềm (Software Engineering Process)

Luồng công việc lặp (Iteration Workflow)

Nội dung (Discipline)

Luồng công việc (Workflow) và luồng chi tiết công việc (Workflow Details)

Vai trò (Role)

Hoạt động (Activity)

Tài liệu làm việc (Artifact)

Các hướng dẫn công cụ (Tool Mentor)

Tôi sẽ phân tích mối quan hệ giữa các thành phần cấu tạo nên quy trình RUPcủa Rational, trực quan trên mô hình sau đây, về vấn đề chi tiết của từng thànhphần sẽ nói sau khi phân tích mối quan hệ này

Hình 2-9 Kiến trúc xử lý của quy trình RUPĐóng vai trò trung tâm là quy trình công nghệ phần mềm (SoftwareEngineering Process)-ở đây là quy trình RUP, nội dung của quy trình chính là các

Discipline (lấy yêu cầu, phân tích thiết kế, cài đặt ,,vv) Thứ tự thực hiện các côngviệc2 trong quy trình được tổ chức thành các Workflow và các Workflow Detail.Trong mỗi luồng công việc có các vai trò (Role) chịu trách nhiệm về một số hoạtđộng (Activity) và tạo ra các tài liệu làm việc cho dự án, là một phần sản phẩm của

dự án Các tài liệu này có thể dựa trên các khuôn mẫu sẵn có (Template-trong quytrình RUP cung cấp một số lượng lớn các Template cho các tài liệu) được kiếm tra(Checkpoint) và lập thành các báo cáo (Report) Trong quá trình phát triển dự ánđược sự hướng dẫn hỗ trợ về công cụ (chủ yếu là của Rational Corp) là các ToolMentor Chi tiết cụ thể như sau:

1.7.1.1 Nội dung (Discipline)

Khái niệm nội dung của quy trình RUP gần giống với khái niệm các pha trongquy trình thác nước (Waterfall) Nội dung của quy trình công nghệ phần mềm RUPđược chia thành hai phần chính:

Quy trình xử lý (Core Process Workflow), bao gồm sáu nội dung chính sau:

Mô hình hoá nghiệp vụ (Buiness Modelling)

Phân tích và quản lý yêu cầu (Requirements)

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

Cài đặt (Implementation)

Kiểm thử (Test)

Triển khai (Deployment)

Hỗ trợ dự án (Support Process Workflow)

Quản lý cấu hình và quản lý thay đổi (Configurationa and Change Management)Quản lý dự án (Project Management)

Thiết lập môi trường dự án (Environments)

1.7.1.2 Các pha (Phase)

Trong quy trình RUP có bốn pha chính, các pha này nối tiếp nhau theo thứ tựthời gian:

Pha Pha khởi đầu (Inception)

Pha Pha phân tích (Elaboration)

Pha Pha xây dựng (Construction)

Pha Pha chuyển giao (Transition)

Trong mỗi pha có các pha nhỏ hơn gọi là các bước lặp (Iteration) Một pha cóthể có một hay nhiều bước lặp Mỗi bước lặp thực hiện đầy đủ các nội dung(Discipline) tức là làm toàn bộ các công việc và đưa dự án đến một trạng thái nào

đó Sự thực hiện dự án là thực hiện một loạt các bước lặp nhỏ-trong đó các côngviệc được thực hiện đi thực hiện lại- tuy nhiên ở mức sau cao hơn mức trước Khi

đã đạt được các tiêu chuẩn nào đó thì có thể qua được một bước lặp, hoặc quamột pha Chuyển giao giữa các pha này là các mốc (Milestone)

2 Là một dãy các hoạt động nhằm tạo ra một số giá trị và kết quả cho dự án

1.7.1.3 Luồng công việc (Workflow) và luồng chi tiết công việc (Workflow Detail)

Là một dãy các hoạt động có thứ tự nối tiếp nhau tạo ra các kết quả hay cácgiá trị cho dự án Mỗi luồng công việc là thực hiện trọn vẹn một nội dung của quytrình RUP nó được thể hiện như là các Activity Diagram Ví dụ như luồng côngviệc lấy yêu cầu

Hình 2-10 Luồng công việc - WorkflowTrong mỗi luồng công việc có thể có nhiều luồng công việc chi tiết Trong mỗiluồng công việc chi tiết thể hiện các tác nhân thực hiện các hoạt động trên các tàiliệu cụ thể và kết quả của từng hoạt động trong từng giai đoạn Ví dụ về một luồngcông việc chi tiết như sau:

Hình 2-11 Luồng công việc chi tiết

1.7.2 Ngôn ngữ hợp nhất mô hình UML (Unified Modelling

Language)

Quy trình RUP thì không thể thiếu được UML Mục đích của quy trình RUP là

hỗ trợ mạnh mạnh mẽ việc thể hiện UML và ngược lại UML thể hiện rất mạnhtrong quy trình RUP Thực tế trong phát triển dự án theo quy trình RUP thì UML vàRUP là hai thành tố chính không thể thiếu [11]

Hình 2-12 Quy trình RUP và UML

Trong nội dung của đồ án này không tập trung vào nghiên cứu UML mà chỉtập trung vào khai thác khía cạnh quy trình RUP sử dụng UML như thế nào Do

đó, cần thiết các nhà phát triển dự án theo quy trình RUP phải hiểu được UMLnhư là một phần không thể thiếu được trong quy trình RUP, và cần thiết phải cómột kiến thức nhất định về UML khi thực hiện quy trình RUP Bạn đọc có thể thamkhảo UML của chính các tác giả tạo nên ngôn ngữ mô hình hóa UML trong tài liệutham khảo [8]

Phát triển dự

án phần mềm

Quy trình RUP

Mô hình hoá UML

1.8 GIỚI THIỆU NỘI DUNG DỰ ÁN

Để sử dụng quy trình RUP cần phải thực hiện trên một dự án cụ thể Ở đâytôi áp dụng quy trình RUP đã nghiên cứu vào dự án theo dõi và giám sát(Monitoring and Evaluation Systems) cho Rada thụ động-phần xử lý trên trạm thutrung tâm Để bạn đọc hiểu rõ về nội dung của dự án, và các ngữ cảnh trước khi

đi sâu vào phân tích thiết kế, tôi dành phần này để mô tả tóm tắt nội dung của dự

án để bạn đọc có thể có những hiểu biết cần thiết trước khi đi sâu và các thiết kếchi tiết của dự án Phần này quan trọng do nó sẽ là nền tảng định hướng cho cácnội dung của các chương sau

1.8.1 Giới thiệu nội dung dự án

Đây là một dự án thực tế của công ty Tư vấn đầu tư và phát triển công nghệthông tin AIC (Advantaced Information Technology Corporation) về trung tâm xử lýcủa Rada thụ động Là một dự án lớn được chia làm nhiều giai đoạn, nhiều dự ánnhỏ Tôi chỉ tham gia vào một phần của dự án là giải quyết phần theo dõi và giámsát trên trung tâm xử lý (Monitoring and Evaluation Systems)-có thể coi như đó làmột dự án nhỏ

Tuy nhiên trong phần này, tôi xin giới thiệu toàn bộ tổng thể về dự án lớn đểgiúp cho bạn đọc có được hiểu biết tổng quan nhất, và riêng phần thực hiện dự áncủa tôi-coi như một dự án nhỏ-sẽ là phần chi tiết và là nội dung chính trong hoạtđộng phân tích thiết kế của đồ án tốt nghiệp này

1.8.1.1 Các khái niệm liên quan đến dự án

Hệ thống Vô tuyến định vị thụ động (gọi tắt là Rađa thụ động) là loại trang bị

có nhiệm vụ xác định tọa độ mục tiêu theo các nguồn bức xạ do chính mục tiêuphát ra Các nguồn bức xạ này luôn luôn tồn tại đi kèm theo các phương tiện tấncông khi các hệ thống trang thiết bị của vũ khí của chúng hoạt động (rađa, thôngtin,…vv.) Rađa thụ động được dùng dùng để phát hiện, nhận dạng, đo hướng vàbám sát tự động các mục tiêu trên đất, trên biển và trên không

Khác với Rađa chủ động là loại Rađa chủ động phát ra bức xạ để xác định vịtrí của mục tiêu, Rađa thụ động hoàn toàn không phát ra bức xạ điện từ mà nóchỉ thu bức xạ điện từ của vật phát xạ, do đó nó có một số ưu điểm sau:

Cự ly hoạt động xa - chỉ bị giới hạn bởi đường chân trời

Bí mật vì có thể hoàn toàn không bức xạ sóng điện từ

Dải phát hiện mục tiêu theo độ cao rất lớn

Độ chính xác cao hơn rađa quan sát làm việc theo nguyên lý chủ động

Khả năng phát hiện cao

Có thể tự động bám sát số lượng lớn mục tiêu

Có thể thực hiện nhận dạng mục tiêu

Có thể làm việc trong điều kiện nhiễu

1.8.1.2 Các nguyên lý hoạt động

1.8.1.2.1 Các nguyên lý định vị của Rada thụ động

Các nguyên lý định vị là các giải thuật xác định toạ độ của một chất điểmtrong không gian dựa trên một số đo đạc gián tiếp có thể thực hiện được Sở dĩcần thiết phải giới thiệu nguyên lý định vị này là do nó liên quan đến rất nhiều cácchi tiết xử lý và tính toán trong quá trình phân tích thiết kế Và đây là một trongnhững yêu cầu quan trọng nhất của hệ thống

Để xác định vị trí nguồn bức xạ vô tuyến với độ chính xác chấp nhận được,hiện nay có một số phương pháp xác định phổ biến là

TOA (Time of Arrival): dựa trên thời gian lan truyền của sóng điện từ xuất phát từnguồn bức xạ đến các máy thu

TDOA (Time Difference of Arrival): dựa trên hiệu thời gian lan truyền của sóngđiện từ đến các máy thu khác vị trí Phương pháp này còn gọi là phương phápHyperbolic

AOA (Angle of Arrival): dựa trên hướng nguồn bức xạ so với vị trí các máy thu

SS (Signal Strength): dựa trên mức tín hiệu đo được tại vị trí các máy thu

CP (Carrier Phase): dựa trên di pha của sóng mang thu được tại vị trí máy thu sovới tín hiệu gốc

Hình 2-13 Các nguyên lý định vị của Rađa thụ độngTuy nhiên trong đặc tính kỹ thuật, hệ thống đã lựa chọn nguyên lý TDOA lànguyên lý định vị tín hiệu bức xạ của hệ thống

1.8.1.2.2 Nguyên lý TDOA (Time Difference of Arrival)

Còn gọi là phương pháp Hyperbolic, dựa trên một khái niệm định nghĩa toánhọc của một loại đường Conic là đường Hyperbol Đó là nguyên lý tập hợp các

điểm trên mặt phẳng có hiệu khoảng cách đến hai điểm cố định không đổi là mộtHyperbol (trong không gian đó là khái niệm Hypeboloit tròn xoay hai tầng).

Giả sử có một nguồn phát xạ tín hiệu, có toạ độ (x,y,z), và có M trạm thu Cáctrạm thu sẽ thu tín hiệu bức xạ điện từ từ nguồn phát xạ (tốc độ bức xạ của sóngđiện từ bằng tốc độ ánh sáng) Do khoảng cách khác nhau từ nguồn bức xạ đếncác trạm thu là khác nhau nên hiệu thời gian (tương ứng tỷ lệ với hiệu khoảngcách) tín hiệu đến các trạm thu khác nhau Với mỗi cặp hai trạm thu cố định sẽtính toán được một Hypeboloit, vậy nếu M đủ lớn ta có thể có được nhiềuHypeboloit và giao của các Hypeboloit xác định toạ độ của nguồn phát xạ(Radioactive Source) Với không gian 3 chiều, có 3 toạ độ của nguồn phát xạ, thìcần ít nhất là 3 Hypeboloit giao nhau, vậy cần tối thiểu là 4 trạm thu tín hiệu Vớikhông gian 2 chiều, chỉ cần biết 2 toạ độ thì chỉ cần 3 trạm thu và 2 cặp Hypeboloitgiao nhau

Hình 2-14 Nguyên lý TDOA với 4 trạm thu, mỗi trạm thu sẽ xác định một cặp với

trạm thu trung tâm để xác định một Hypeboloit tròn xoay

1.8.1.2.3 Hệ thống lọc nhiễu tín hiệu Kalman

Là một khái niệm quan trọng, và yêu cầu quan trọng của dự án, đây là bộ lọc

sử dụng thuật toán Kalman để loại bỏ tín hiệu nhiễu trong quá trình đo đạc tínhtoán Ở đây tôi chỉ trình bày khái niệm bộ lọc Kalman, còn các chi tiết kỹ thuật vàthuật toán sẽ được thể hiện rõ hơn ở phần phân tích thiết kế sau này

1.8.1.3 Tổng quan dự án

Ở các phần trên, tôi trình bày một số khái niệm có tính chất kỹ thuật cho dự

án giúp bạn đọc dễ hiểu khi đi sâu vào phân tích nghiên cứu dự án trong đồ án tốtnghiệp này Trong phần này tôi trình bày tổng quan dự án, để bạn đọc có thể nắmđược nội dung của toàn bộ dự án lớn, còn trong phần sau tôi trình bày chi tiết về

hệ thống theo dõi và giám sát cho Rada thụ động là một phần của dự án lớn do tôithực hiện áp dụng theo quy trình RUP và đó cũng là nội dung chính của đồ án tốtnghiệp này Về cơ bản hệ thống hoạt động như sau:

Hình 2-15 Tổng quan dự án

Tổ chức hoạt động của dự án

Hình 2-16 Tổ chức hoạt động dự án

Mô tả hoạt động của hệ thống

Có một trạm thu trung tâm và một số các trạm thu tín hiệu khác Các trạm thunày được bố trí để đồng bộ thu tín hiệu bức xạ của nguồn phát xạ Kết quả thu tínhiệu được chuyển ngay lập tức về trạm thu trung tâm và thực hiện các phân tíchtính toán trên trạm thu trung tâm

Tại trạm thu trung tâm có các máy đo tương quan để đồng bộ tín hiệu từ cácmáy thu khác nhau và máy trung tâm để xác định sự sai khác về thời gian, sau đó

Chủ trì d/a

Nhóm chuyên gia tham khảo

Máy thu SCT

Tín hiệu thị tần S(t)

Đường truyền tốc

tâm xử lý

Tín hiệu thị tần từ các máy thu khácMột máy thu

Bộ phân tích tương quanTín

bám sát quỹ đạoL

R (từ xa) C (tại chỗ)

chuyển kết quả cho hệ thống theo dõi và giám sát (Monitoring and EvaluationSystems) Ở hệ thống theo dõi và giám sát này sẽ thực hiện phân tích Hyperbolicsau đó hiển thị hình ảnh tại chỗ của nguồn phát xạ, theo dõi nó và có các báo cáocần thiết lên sở chỉ huy cấp trên.

1.8.1.4 Hệ thống theo dõi và giám sát (Monitoring and Evaluation Systems)

Phần này tôi xin trình bày chi tiết hơn về hệ thống theo dõi và giám sát làphần nội dung xuyên suốt của các phân tích thiết kế cho chương sau Hệ thốngnày giới hạn bắt đầu từ hoạt động nhận tín hiệu đồng bộ từ các máy tương quan,sau đó thực hiện các lọc nhiễu bằng phần mềm, tính toán, hiển thị và báo cáo cáckết quả cần thiết Hệ thống theo dõi và giám sát bao gồm phần mềm Tracker (theodõi giám sát) và phần mềm Hyperbolic (phân tích) Tôi xin trình bày mô tả sơ đồkhối của hệ thống theo dõi và giám sát như sau:

Hình 2-17 Hệ thống theo dõi và giám sát

1.8.2 Các yêu cầu khách hàng

(Các yêu cầu của khách hàng có thể tham khảo thêm chi tiết trong tài liệu Vision trong phần phụ lục của dự án)

Có cơ chế đăng nhập và quản lý người sử dụng hệ thống

Thu nhận các tín hiệu vô tuyến do các nguồn bức xạ (từ các máy phát trên máybay)

Xác định (tự động3/bán tự động4) vị trí các nguồn bức xạ theo phương pháp hiệuthời gian TDOA (phương pháp Hyperbolic)

Khởi tạo, bám sát (tự động/bán tự động) và quản lý quỹ đạo các mục tiêu

Hiển thị bức tranh tình huống tại chỗ

Truyền thông tin quỹ đạo mục tiêu về SCH cấp trên (TBD)

Báo cáo các kết quả cần thiết

3 Hệ thống sẽ tự động nhận dạng và giám sát mục tiêu trong điều kiện nhiễu

4 Người sử dụng sẽ chỉ ra mục tiêu trong nhiễu sau đó cho hệ thống giám sát

c

Giám sát quỹ đạo mục tiêu

Hiển thị trên màn hình

Báo cáo thông tin mục tiêu Lọc nhiễu

THỰC HIỆN DỰ ÁN THEO QUY TRÌNH RUP

Tóm tắt chương

Trong chương này sẽ trình bày về việc thực hiện áp dụng giải pháp của quytrình RUP vào giải quết vấn đề của dự án Đây là nội dung chủ yếu của phần ứngdụng Do yêu cầu phạm vi của dự án, do yêu cầu về thời gian và yêu cầu về conngười nên trong đồ án tốt nghiệp này chỉ tập trung vào khâu quản lý yêu cầu(Requirement Managements), phân tích thiết kế (Analysis and Design) thể hiệntheo quy trình RUP Còn thực tế thực hiện dự án theo một quy trình nào đó cầnthiết yêu cầu nhiều thành viên tham gia với nhiều vai trò lĩnh vực khác nhau, nhiều

kỹ năng kinh nghiệm khác nhau

Chương này được chia làm bốn phần tương ứng với bốn pha trong phát triểnphần mềm theo quy trình RUP, đó là:

Pha khởi đầu (Inception Phase)

Pha phân tích (Elaboration Phase)

Pha cài đặt (Construction Phase)

Pha chuyển giao (Deployment Phase)

Trong mỗi pha của dự án, tôi xin trình bày các nội dung của quy trình RUP ápdụng cho dự án, tuy nhiên, như đã nói ở phần trên, do yêu cầu của đề tài, do vấn

đề thời gian, nên phạm vi của đề tài này là thực hiện dự án tập trung chủ yếu vàonội dung Quản lý yêu cầu (Requirement Managements) và Phân tích và Thiết kế(Analysis and Design) Nội dung trong mỗi phần như sau:

Các mục đích yêu cầu và mục tiêu chủ yếu của phase

Kế hoạch hoạt động của phase

Luồng công việc (Workflow)

Phát triển các tài liệu làm việc (Artifact)

1.9 PHA KHỞI ĐẦU (INCEPTION PHASE).

Nói chung trong mọi dự án đều có một thời gian ban đầu tuy ngắn nhưngquan trọng giai đoạn khởi đầu của dự án Trong quy trình RUP gọi đó là pha khởiđầu (Inception Phase) Trong phần này, tôi xin trình bày về thực hiện pha khởi đầuđối với dự án Monitoring and Evaluation Systems

Quết định tiếp tục phát triển hay dừng dự án, dựa trên tính khả thi của dự án

1.9.2 Phát triển các tài liệu làm việc (Artifact).

Một số tài liệu quan trọng của dự án được phát triển trong pha khởi đầu của

dự án bao gồm:

Tài liệu viễn cảnh chung của dự án (Vision)

Tài liệu về mô hình Use-Case (Use-Case Model)

Tài liệu hỗ trợ đặc tả yêu cầu (Supplementary Specification)

Tài liệu về từ thuật ngữ chung của dự án (Glossary)

Tài liệu về Rủi ro và Kế hoạch quản lý rủi ro (Risk List and Risk ManagementPlan)

Kế hoạch lặp cho dự án (Iteration Plan)

Kế hoạch phát triển phần mềm (Software Development Plan)

Có một điều cần chú ý là các tài liệu này tuy được thực hiện ở đây, chỉ có ýnghĩa là bắt đầu ở giai đoạn này, không có nghĩa là kế thúc giai đoạn là phải hoànthiện Chúng còn được bổ xung và cập nhất thông qua các giai đoạn sau

1.9.3 Kế hoạch lặp cho giai đoạn khởi đầu

Sở dĩ tôi trình bày trước tiên kế hoạch lặp cho giai đoạn khởi đầu là vi tưtưởng của quy trình RUP luôn luôn lấy việc lập kế hoạch là nền tảng quan trọngnhất, quyết định thành công của dự án Mọi việc đều làm theo kế hoạch, việc luônluôn chú ý đến lập và làm theo kế hoạch là điều quan trọng Việc lập kế hoạch

5 Viễn cảnh chung (Vision) là các thỏa thuận giữa nhà phát triển và khách hàng về các tính chất đặc tính của sản phẩm nhằm để phát triển sản phẩm thỏa mãn yêu cầu khách hàng Được phát triển từ rất sớm ngay từ giai đoạn đầu tiên của dự án

6 Đặc tính của sản phẩm (Feature) là các dịch vụ, chức năng cung cấp bởi hệ thống nhằm thỏa mãn yêu cầu của khách hàng (Customer Needs).

không chỉ diễn ra một lần mà nó diễn ra liên tục lặp đi lặp lại cho nhiều giai đoạnnhiều pha của dự án (Iteration Plan) Do đó trong dự án RUP không chỉ có một kếhoạch mà có rất nhiều kế hoạch, trước mỗi giai đoạn bao giờ cũng là kế hoạch, kếhoạch luôn luôn đi trước

Với dự án này trước tiên, tôi trình bày kế hoạch cho giai đoạn khởi đầu, đểbạn đọc có thể có hình dung về tiến trình giai đoạn của dự án, sau đó ở cuối mỗichương tôi xin trình bày về kế hoạch cho các chương sau

Giai đoạn khởi đầu chỉ tập trung vào một số pha và công việc nhất định nhằmkhởi động một số hoạt động nền tảng cho dự án Trong tài liệu kế hoạch lặp, tôinhấn mạnh công việc vào 3 pha chủ yếu:

Tài liệu 3-1 Hoạt động dự án giai đoạn khởi đầu Giai đoạn khởi đầu này thường rất khó, phải hoàn tất một số công việc chuẩn

bị cần thiết trước khi vào dự án (thành lập đội dự án, tìm hiểu nghiệp vụ, tìm hiểu

hệ thống cũ, xác định các rủi ro,…vv) Một điều chú ý trong giai đoạn khởi đầu này

là các rủi ro chỉ tập trung vào hai loại chính là rủi ro nghiệp vụ 7 và rủi ro kỹ thuật8cần thiết phải tập trung giải quết trước

1.9.4 Quản lý yêu cầu khách hàng

Trong phần này tập trung vào thực hiện việc tiếp cận lấy yêu cầu, phân tíchyêu cầu, lập tài liệu, tổ chức và thực hiện quản lý sự thay đổi yêu cầu đối với dự

án áp dụng quy trình RUP Trách nhiệm chủ yếu của hoạt động này thuộc về cácSystem Analysis (phân tích viên hệ thống) Nội dung của phần này sẽ lần lượt giảiquết từng hoạt động đó

1.9.4.1 Tiếp cận yêu cầu

Theo chức năng, yêu cầu khách hàng được chia làm hai loại là:

Các yêu cầu chức năng của hệ thống: Cung cấp các chức năng sử dụng đượccho người sử dụng hệ thống và được biểu diễn một cách rõ ràng trên các mô hìnhUse-Case

Các yêu cầu phi chức năng: Yêu cầu không thể hiện rõ ràng không biểu diễn rõràng trên các mô hình mà các yêu cầu này chỉ được xem xét và lưu ý khi phântích thiết kế cài đặt, kiểm thử,…vv (ví dụ: yêu cầu về mức độ bảo mật được thểhiện trên các giải pháp, thuật toán lựa chọn, giao thức lựa chọn, yêu cầu về tính

7 Phần mềm không đáp ứng hoạt động nghiệp vụ của khách hàng, không phù hợp với các chiến lược của công ty, gây khó khăn trong vận hành,…vv

8 Là các rủi ro trong đặc tả yêu cầu, phân tích, thiết kế, kiểm thử, bảo trì hệ thống, sự thay đổi công nghệ,…vv