Là một phần trong kế hoạch quản lý rủi ro, các danh sách rủi ro được xác định và cập nhật liên tục. Cụ thể các bạn đọc có thể tham khảo thêm phần phụ lục tài liệu của dự án. Trong phần này, tôi phân tích việc thực hiện quản lý rủi ro thông qua xây dựng kế hoạch quản lý rủi ro và xây dựng danh sách rủi ro. Với mỗi rủi ro cần thiết phải làm rõ các thông tin sau:
Tên rủi ro: Mô tả ngắn gọn, có ý nghĩa phản ánh đặc điểm chính của rủi ro. Ví dụ:
“Khách hàng không có kinh nghiệm với hệ thống”.
Độ lớn của rủi ro và phân loại: Đánh giá về mức độ nghiêm trọng của rủi ro ảnh hưởng đến hệ thống
Các dấu hiệu nhận biết khi rủi ro xảy ra: Là các sự kiện bất thường có thể nhận thức được khi rủi ro xảy ra.
Chiến lược phòng tránh rủi ro: Là các phương thức phòng tránh và khắc phục đề ra để hạn chế hậu quả của rủi ro.
Kế hoạch phòng tránh rủi ro: Là kế hoạch để thực hiện các chiến lược phòng tránh rủi ro đó. Có thể có kế hoạch cụ thể cho từng loại rủi ro hoặc kế hoạch tổng thể cho các rủi ro.
Tài liệu sau đây mô tả một phần của danh sách các rủi ro trong quá trình thực hiện dự án theo quy trình RUP, là một phần trong kế hoạch quản lý rủi ro.
Tài liệu 3-7 Danh sách rủi ro (Risk list) 1.9.6. Lập kế hoạch lặp cho giai đoạn tiếp theo
Trước mỗi giai đoạn lặp là công việc lập kế hoạch cho giai đoạn đó. Thực chất đây là công việc được thực hiện ở cuối môi giai đoạn thì việc lập kế hoạch cho giai đoạn sau phải được hoàn thành. Sau giai đoạn này là giai đoạn phân tích thiết kế (Elaboration) và bước lặp thứ nhất trong giai đoạn phân tích thiết kế (Iteration 1) như trong kế hoạch tổng thể đã nêu. Vì vậy, ở cuối giai đoạn này, tôi lập kế hoạch cho giai đoạn lặp thứ nhất trong pha phân tích thiết kế. Tuy nhiên, để hiểu kế hoạch thì trước hết phải hiểu các mục tiêu của giai đoạn đó. Đó đó để cho dễ hiểu tôi xin trình bày việc lập kế hoạch cho dự án của giai đoạn lặp này ở phần
Danh sách rủi ro
1. Giới thiệu 2. Các rủi tro
Rủi ro kỹ thuật: Các khách hàng của hệ thống không có kinh nghiệm làm việc với hệ thống mới này
Độ lớn của rủi ro và phân loại
Rủi ro này rất lớn có thể dẫn đến dừng dự án nếu khách hàng không thoả mãn Mô tả rủi ro
Đây là hệ thống mới hoàn toàn lần đầu tiên được đưa và sử dụng nên chưa khách hàng nào có kinh nghiệm về vấn đề này
Ảnh hưởng đến hệ thống
Hệ thống được sử dụng không đúng cách, các chức năng bị hiểu sai đẫn đến hoạt động không chính xác
Triệu chứng khi lỗi xảy ra
Các giao dịch bất thường, các thông báo lỗi liên tiếp chuyển cho người sử dụng Chiến lược phòng tránh
Trong hệ thống cần có một phần trợ giúp các khách hàng về luật, các quy tắc trong giao dịch một cách trực tuyến. Thay vì đưa ra các thông báo lỗi thì ta nên đưa ra phần trợ giúp tình huống bằng hình ảnh, âm thanh khi có lỗi xảy ra và giúp người sử dụng thực hiện lại giao dịch để mất cảm giác hệ thống bị hỏng
Kế hoạch thay đổi
Tăng cường hỗ trợ khách hàng trong huấn luyện và chắc chắn khâu lấy yêu cầu. Xem trong bản kế hoạch quản lý rủi ro
Rủi ro trong đáp ứng các hoạt động nghiệp vụ-Không hiểu nhu cầu thị trường
Độ lớn của rủi ro và phân loại Độ lớn rủi ro này rất lớn
sau, sau khi đã trình bày mục tiêu của dự án. Tuy nhiên, bạn đọc cần lưu ý là đây là cách trình bày, không phải là thứ tự thời gian, việc lập kế hoạch phải được tiến hành tại đây, trước khi vào thực hiện công việc.
1.10. PHA PHÂN TÍCH VÀ THIẾT KẾ (ELABORATION PHASE)
Như kế hoạch ở trong phần trước, trong phần này tôi trình bày tiến trình của dự án theo diễn biến của thời gian qua các giai đoạn lặp
1.10.1. Giai đoạn lặp lần thứ nhất (Iteration 1)
Ở các giai khởi động dự án thì một số vấn đề của dự án (tính khả thi, khả năng đầu tư, các nhất trì thoả thuận về chức năng hoạt động của hệ thống) đã được thống nhất. Mục tiêu chính của giai đoạn lặp này quan tâm đến phân tích các Use-Case và làm rõ các khái niệm phân tích có liên quan đến các Use-Case đó (trả lời câu hỏi What). Từ giai đoạn này trở đi, vai trò của UML là thực sự quan trọng không thể thiếu đối với một dự án sử dụng quy trình RUP
1.10.1.1. Mục tiêu
Quy trình RUP là một quy trình có sự lặp đi lặp lại thực hiện các luồng công việc tưởng chừng như giống nhau nhưng thực chất có sự quan trọng khác nhau trong từng giai đoạn, mỗi giai đoạn tập trung vào giải quyết một công việc trọng yếu nào đó và các công việc khác thì có quan tâm xem xét tới tuy không là chủ yếu nhưng cũng không thể bỏ qua. Đó chính là một trong những tư tưởng chủ đạo của quy trình RUP. Mục tiêu chính của giai đoạn lặp lần thứ nhất này là:
Thực hiện kiểu phân tích rộng và nông (wide and shallow), có nghĩa là bao quát để nắm tổng thể dự án, không vào chi tiết. Các công việc ở giai đoạn này không cần thiết phải đi quá sâu vào các chi tiết vấn đề, mà tìm hiểu hết các vấn đề để đánh giá phạm vi và sơm tiếp cận được với các công việc quan trọng nhất ngay từ ban đầu để có kế hoạch cho giai đoạn tiếp theo
Tập trung phân tích hành vi của hệ thống, làm rõ các khái niệm quan trọng liên quan
Tìm kiếm và phân tích các Use-Case trong đó tập trung vào các Use-Case quan trọng nhất, tuy nhiên, phân tích các Use-Case chỉ ở mức độ phân tích ngữ nghĩa của các khái niệm liên quan (Domain Model và Analysis Model) và phân tích hoạt động của các Use-Case đó (Activity Diagram)
Phần thiết kế và cài đặt bắt đầu được tiến hành, tuy nhiên, chỉ tập trung vào một số Use-Case quan trọng. Sở dĩ như vậy vì các Use-Case quan trọng đó làm nên chức năng chính của hệ thống nên cần phải xem xét và phân tích trước.
Các tài liệu hoặc các mô hình có thể thực hiện mới hoặc cập nhật bao gồm: − Mô hình hóa lĩnh vực (Domain Model) và mô hình phân tích (Analysis
Model).
− Mô hình thiết kế (Design Model).
− Mô hình cài đặt (Implemetation Model). − Mô hình kiểm thử (Test Model).
1.10.1.2. Kế hoạch của giai đoạn lặp thứ nhất
Tôi sử dụng công cụ Microsoft Project cho việc lập kế hoạch và việc này tiến hành lặp lại cho từng giai đoạn của dự án. Cũng tương tự giai đoạn khởi động của dự án, tôi xin trình bày ở đây bảng trích kế hoạch để bạn đọc có thể theo dõi tiến độ công việc. Còn chi tiết bạn đọc có thể tham khảo thêm trong phần phụ lục kèm theo của dự án
Hình 3-21 Kế hoạch của giai đoạn lặp lần thứ nhất
Một chú ý là trong giai đoạn lặp lần thứ nhất này, tôi chỉ tập trung vào phân tích các Use-Case thực sự quan trọng nhất của hệ thống (đó là 3 use-case Hyperbolic Analysis, use-case Analysis Kalman và use-case trình diễn đồ họa). Trong giai đoạn này thì công việc quản lý yêu cầu vẫn chiếm một khối lượng rất lớn và chủ yếu trong các hoạt động. Và có một số tài liệu hoặc một số hoạt động hoàn toàn được được lặp lại từ giai đoạn khởi động dự án, nhưng đó là hoạt động cập nhật thêm thông tin để hoàn thiện các phân tích thiết kế cho dự án.
1.10.1.3. Phân tích hành vi của hệ thống
Phân tích hành vi của hệ thống là hoạt động mô tả các tương tác của hệ thống với các tác nhân bên ngoài. Trong các giai đoạn khởi động, ta đã phân tích
một số Use-Case và các tác nhân sử dụng chúng. Tuy nhiên, hoạt động ấy chỉ thể hiện tương tác của các tác nhân sử dụng các chức năng của hệ thống một cách riêng lẻ, chưa có sự khái quát ở mức tổng thể của hệ thống. Hoạt động này cũng giống như việc thành lập biểu đồ mức đỉnh của hệ thống trong phân tích thiết kế cấu trúc hoá. Hệ thống được coi như là một hộp đen sẽ tương tác với các tác nhân bên ngoài thông qua các luồng dữ liệu
Tuy nhiên, trong UML sử dụng một loại biểu đồ dùng để mô hình hoá hành vi của hệ thống với các tác nhân bên ngoài, đó là biểu đồ tiếp diễn (Sequence Diagram), và biểu đồ tiếp diễn biểu diễn hành vi tương tác của toàn bộ hệ thống với các tác nhân bên ngoài gọi là System Sequence Diagram (SSD)
Hình 3-22 Phân tích hành vi của hệ thống
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 ) Analysis Model )
Trong quá trình phân tích thiết kế một Use-Case, ngay ở giai đoạn đầu tiên là gặp phải một số khái niệm liên quan đến các Use-Case trong một hệ thống. Đó chính là làm sao thống nhất các khái niệm liên quan đến quá trình phân tích các Use-Case và trước hết để hiểu Use-Case đó là cái gì (What), là bởi vì các Use-
Case được cấu thành từ các khái niệm khác có liên quan có tồn tại trong thực tế hoặc trừu tượng. Muốn phân tích chính xác các Use-Case thì trước hết phải làm rõ các khái niệm liên quan cấu thành Use-Case đó trước (trả lời câu hỏi What?). Chúng ta mới chỉ có duy nhất một tài liệu Glossary giải thích các khái niệm ấy, tuy nhiên không trực quan, và rất khó được mối quan hệ giữa các khái niệm ấy.
1.10.1.4.1 Tìm kiếm các lớp phân tích
Thí dụ: Use-Case Representation (trình diễn đồ hoạ) của dự án, trước hết cần làm rõ các khái niệm :Điểm 2 chiều, điểm 3 chiều, điểm trong toạ độ cực, đường thẳng, không gian 2 chiều,không gian 3 chiều, toạ độ, thế nào là hệ trục toạ độ Decac vuông góc, thế nào là hệ toạ độ cực, hình chữ nhật, hình tròn, đối tượng đồ hoạ 2 chiều, đối tượng đồ hoạ 3 chiều, vv, và cần mô tả các mối quan hệ liên quan giữa các khái niệm cấu thành các Use-Case trong hệ thống đó. Ví dụ như: Đường thẳng được cấu thành từ hai điểm, Hình chữ nhật được cấu thành từ hai điểm (góc trên bên trái và góc dưới bên phải). Tất cả các khái niệm đó được phân tích làm rõ và thống nhất biểu diến trên mô hình Domain Model. Ví dụ sau mô tả khái niệm tọa độ của một chất điểm trong không gian hai chiều được biểu diễn trên hệ tọa độ cực, nó bao gồm một cặp hai số (x,anpha), là vị trí của chất điểm trên trục cực (x) và góc cực (anpha).
Hình 3-23 Khái niệm tọa độ cực (CVPole)
Có thể coi việc mô hình hoá các khái niệm phân tích là một loại từ điển trực quan của dự án dùng trong giai đoạn phân tích và thiết kế, thể hiện các khái niệm liên quan trong một mối quan hệ thống nhất . Trong phần này còn một chú ý đối với các nhà phát triển dự án,nếu chưa thành thạo có thể sử dụng các Pattern (Analysis Pattern) [4], có thể dễ dàng thuận tiện hơn trong các phân tích thiết kế. Trong dự án này của tôi cũng sử dụng nhiều các pattern, và nó đóng một vai trò quan trọng. Tuy nhiên. để tránh trình bày lạc chủ đề và lan man tôi xin trình bày việc áp dụng các pattern đó trong chương sau của đồ án này
x O
Phần sau đây, tôi minh hoạ một số phân tích các khái niệm cấu thành các Use-Case của dự án và mô hình hoá sử dụng công cụ UML. Ví dụ Use-Case Login (Xem phần đặc tả Use-Case login), trong quá trình phân tích xuất hiện một số khái niệm liên quan đến nó là
Record PIN: Một bản ghi bao gồm tên định danh của người sử dụng hệ thống cùng password đã được mã hoá, sử dụng để ghi vào file cơ sở dữ liệu
PIN (Personal Identification Number): định danh của người sử dụng hệ thống và password được mã hoá
CKey: Mã hoá password của người sử dụng hệ thống. Mỗi người sử dụng hệ thống có một Password riêng đồng thời có cách mã hoá riêng của họ
Các khái niệm trên có liên quan đến nhau và được mô tả sơ lược như sau
Hình 3-24 Mô hình hoá khái niệm phân tích của Use-Case Login (Analysis Model) Với Use-Case Representation cũng tương tự như vậy
Hình 3-25 Mô hình hoá các khái niệm phân tích của Use-Case Representation Tuy nhiên để nhận ra các khái niệm phân tích này đôi khi cũng không phải là dễ. Thông thường các khái niệm phân tích này thường được thể hiện dạng danh từ và chứa trong một số lĩnh vực nhất định của dự án mà nhà phát triển dự án có thể dựa vào đó để tìm kiếm các khái niệm phân tích cho dự án, bao gồm:
Các khái niệm phân tích Ví dụ trong dự án
Đối tượng vật lý có thể quan sát Máy tương quan, màn hình
Các mô tả về một vấn đề Địa điểm
Các giao dịch
Vai trò con người Quản trị hệ thống,nhân viên
Các kho chứa Kho
Các phương tiện giao dịch điện tử Thẻ từ
Khái niệm trừu tượng Hệ trục toạ độ, điểm, hình chữ nhật,đối
tượng đồ hoạ Tổ chức
Sự kiện Thanh toán,
Luật và chính sách
Hợp đồng, sổ sách tài chính Sổ sách, báo cáo
Tài liệu, sách vở liên quan
1.10.1.4.2 Quan hệ giữa các lớp phân tích
Sau khi đã tìm kiếm được các lớp phân tích thì một điều cũng quan trọng là xác định được chính xác quan hệ giữa các lớp phân tích. Vì các quan hệ này thực sự cần thiết, nó ảnh hưởng đến toàn bộ các hoạt động về sau. Nếu việc tìm kiếm các lớp phân tích thiếu xót thì chỉ dẫn đến thiếu xót một chức năng nào đó của hệ thống thì việc phân tích và xác định các quan hệ sai dẫn đến sai lệch trong quan hệ ngữ nghĩa chức năng của cả hệ thống lớn. Tuy nhiên, mục tiêu chủ yếu của giai đoạn này là tìm kiếm các lớp phân tích vì chúng quan trọng hơn
Có một số quan hệ giữa các lớp phân tích mà ta có thể quan tâm lưu ý trong khi xem xét và mô hình hoá chúng lên mô hình phân tích
Phân loại quan hệ Ví dụ trong dự án
Lớp A là một bộ phận (vật lý hoặc logic) của lớp B
Quan hệ điểm -đường thẳng (quan hệ Include)
Lớp A bị chứa trong lớp B Hình bao gồm nhiều điểm
Lớp A là một dòng (báo cáo) của lớp B Dòng báo cáo-Báo cáo Lớp A là một tổ chức hay một hệ thống
con của lớp B
Lớp A sử dụng hay quản lý lớp B
A và B là hai đối tượng kế tiếp nhau Dòng báo cáo-Dòng báo cáo
A sở hữu B
A có quan hệ thông tin đến B
Bảng 3-5 Quan hệ giữa các lớp phân tích
Có thể đặt tên cho các quan hệ giữa các lớp phân tích, trong quy trình RUP và UML quy định một số chuẩn (không bắt buộc) cho việc đặt tên quan hệ như sau: [Tên lớp phân tích ]-Động từ-[Tên lớp phân tích] trong đó Tên lớp phân tích là không bắt buộc, tên quan hệ bắt đầu bằng chữ cái in hoa. Ví dụ [Hình chữ nhật]-
chứa-[điểm] hoặc có thể ngắn gọn hơn là Chứa
Hình 3-1 Quan hệ giữa các lớp phân tích
Cụ thể chi tiết dự án thì bạn đọc có thể xem trong mô hình phân tích của dự án phần Domain Model và Analysis Model
Quan hệ các lớp phân tích
1.10.1.5. Mô hình hoá trường hợp sử dụng (Use-Case Model)
Quá trình mô hình hóa trường hợp sử dụng trong phần này lại tiếp tục lặp lại có phần giống với hoạt động mô hình hóa trường hợp sử dụng trong phần khởi động của dự án (Inception Phase). Tuy nhiên, do RUP là quy trình công nghệ phần mềm có tính chất lặp nên một công việc có thể thực hiện nhiều lần là điều bình thường, tuy nhiên, ở mỗi lần mức độ và sự quan tâm mục tiêu chính của hoạt động có khác nhau. Nếu như trong giai đoạn khởi động của dự án chỉ tập