1. Mô hình yêu cầu chức năng
• Yêu cầu quản lý tài liệu
• Yêu cầu quản lý người dùng
Hình 4-78 4-79: Yêu cầu quản lý người dùng
2. Yêu cầu phi chức năng An toàn
Bảo mật
Hình 4-82 4-83 : Yêu cầu bảo mật
• Quy định
Hình 4-84 4-85: Yêu cầu quy định
• Thực hiện
Hình 4-86 4-87: Yêu cầu thực hiện
1. Mô hình Usecase
Hình 4-88 4-89: Biểu đồ tác nhân
• Biểu đồ usecase tổng quan
Hình 4-90 4-91: Uusecase tổng quan
Hình 4-92 4-93: Usecase quản lý thành viên
• Use case quản lý nhóm
• Quản lý văn bản
Hình 4-96 4-97: Usecase quản lý văn bản
c. Mô hình thiết kế
1. Mô hình đặc tả usecase Quản lý tài liệu
Tạo thư mục
Tạo thư mục con
Hình 4-100 4-101: Usecase tạo thư mục con
Tạo thư mục gốc
Quản lý văn bản
Hình 4-104 4-105: Usecase quản lý văn bản
Tìm kiếm thông tin
Hình 4-108 4-109: Usecase xem thông tin
Quản lỳ người dùng
Đăng nhập
Hình 4-110 4-111: Usecase đăng nhập
Quản lý nhóm
Thay đổi Pass
Hình 4-116 4-117: Usecase thay đổi mật khẩu
Thiết lập cấu hình
• Mô hình thực thi (lớp)
Hình 4-120 4-121: Biểu đồ lớp
class database Folder «column» *pfK IDFolder: INTEGER Name: CHAR(10) Path: CHAR(10) Description: CHAR(10) Order: CHAR(50) «FK» + FK_IDFolder(INTEGER) «PK» + PK_Folder(INTEGER) «unique» + UQ_Folder_Name(CHAR) Document «column» *PK IDDoc: INTEGER Article: CHAR(10) Links: CHAR(70) CreateFileName: CHAR(50) ContentFileName: CHAR(10) Content: CHAR(60) IDOrder: INTEGER «PK» + PK_Document(INTEGER) «unique» + UQ_Document_Article(CHAR) + UQ_Document_IDOrder(INTEGER) User «column» *PK ID: INTEGER Account: CHAR(10) Password: CHAR(10) *FK IDMember: INTEGER * IDUserGroup: INTEGER «FK» + FK_IDMember(INTEGER) «PK» + PK_User(INTEGER) «unique» + UQ_User_Account(CHAR) + UQ_User_IDMember(INTEGER) + UQ_User_IDUserGroup(INTEGER) UserGroup «column» *pfK ID: INTEGER Name: CHAR(10) «FK» + FK_ID(INTEGER) «PK» + PK_UserGroup(INTEGER) Member «column» *PK ID: INTEGER Name: CHAR(10) Birthday: DATE Phone: CHAR(10) Degree: CHAR(50) Email: CHAR(10) Note: CHAR(10) «PK» + PK_Member(INTEGER) «unique» + UQ_Member_Name(CHAR) ActionPermission «column» *PK ID FK IDUserGroup: INTEGER IDActionName: INTEGER «FK» + FK_IDUserGroup(INTEGER) «PK» + PK_ActionPermission() «unique» + UQ_ActionPermission_IDActionName(INTEGER) + UQ_ActionPermission_IDUserGroup(INTEGER) ActionName «column» *pfK ID: INTEGER TypeName: CHAR(5) DegreeName: CHAR(10) ActionName: CHAR(10) «FK» + FK_ID(INTEGER) «PK» + PK_ActionName(INTEGER) +ID 1 +UQ_ActionPermission_IDActionName 1 +IDUserGroup 1..* +PK_UserGroup 1..* +ID 1 +UQ_User_IDUserGroup 1..* +IDMember 1 +ID 1 +IDFolder 1 +UQ_Document_IDOrder 0..* Hình 4-122 4-123: Biểu đồ CSDL d. Mô hình kiểm thử Kiểm thử lớp
Hình 4-124 4-125: Kiểm thử lớp
Hình 4-126 4-127: Kiểm thử yêu cầu chức năng
Hình 4-128 4-129: Kiểm thử yêu cầu phi chức năng
1.16. Thử nghiệm
1.16.1. Thử nghiệm
Ứng dụng được chạy thử nghiệm trên 2 dự án khác nhau: Example do EA cung cáp và ứng dụng bài toán mẫu DMS được tạo ra.
Example DMS
Số biểu đồ 139 40
Số yêu cầu 39 31
Số cấp gói dữ liệu 4 4
1.16.2. Nhận xét và đánh giá
• Ứng dụng đã đưa ra và xử lý được những thông tin cần thiết về vết yêu cầu. tuy nhiên, ứng dụng chưa kiểm tra được tớnh chớnh xác về mặt thông tin mà chỉ kiểm tra dựa trên chuẩn liên kết vết.
•
• Thời gian chạy ứng dụng phụ thuộc vào cấp các gói trong dự án và số lư ợng các phần tử nên với các dự án được phân nhỏ thành nhiều gói và nhiều phần tử sẽ diễn ra chậm, mất nhiều thời gian.
• Thời gian thực hiện ứng dụng đối với những dự án được tạo ở mức phõn lớp nhiều sẽ lớn do việc quét tất cả các gói để tỡm kiếm thông tin.
1.17. Kết chương
Như vậy chương này đã trình bày về quá trình phát triển một ứng dụng có thể đưa ra vết yêu cầu phần mềm dựa trên công cụ EA 7.0. Bên cạnh đó là những đánh giá về kết quả của dự án. Tuy rằng ứng dụng cũn một số hạn chế nhưng đã đưa ra được thông tin vết cần thiết từ các mô hình được xõy dựng trên công cụ EA 7.0.
KẾT LUẬN Những việc đã làm được
Đồ án tốt nghiệp đã nghiên cứu khá đầy đủ cơ sở lý thuyết về bài toán “Quản lý vết yêu cầu phần mềm”. Tác giả đã tìm hiểu, tập hợp khá nhiều và khá chi tiết về quản lý yêu cầu phần mềm đặt trọng tâm vàovà vết yêu cầu phần mềm,, các phương pháp quản lý và đưađưa ra vết yêu cầu đồng thời tìm ra công cụkỹ thuật phần mềm trợ giúp máy tính CASE phù hợp nhằm quản lý yêu cầu và vết yêu cầu Enterprise Architecture 7.0 và á. Áp dụng thành công quy trình tìm vết vào trong công cụ CASE được chọn-Enterprise Architecture 7.0.
Vận dụngÁp dụngđượcmột kỹ thuật vềlưu vết yêu cầu phù hợp, tìm ra quy trình lưu vết phù hợp với chiến lược và công cụ đưa ra. và áÁp dụng thành công kỹ thuật và chiến lược tìm vết yêu cầu trong vào công cụ EA 7.0 nhằm khắc phục một số nhược điểm của công cụ này đồng thời đưa ra thành các báo cáo hỗ trợ cho quá trình lưu vết và phát triển phần mềm.
Tác giả đã tỡm hiểu và áp dụng chiến thuật phù hợp đưa ra thông tin vết và trả lời cõu hỏi áp dụng chiến thuật và kỹ thuật nào đồng thời đưa vào đó trong EA như thế nào để đạt hiệu quả cao và có thể sử dụng được trong thực tế..
Về mặt kỹ thuật, tác giả đã sử dụng được thành thạo công cụ EA 7.0. Đõy là công cụ thương mại dùng trong thiết kế và xây dựng phần mềm chưa được sử dụng nhiều ở Việt Nam. Tác giả cũng tỡm ra được ưu nhược điểm của công cụ EA trong việc phân tích và xây dựng phần mềm cũng như quản lý vết yêu cầu. Từ ưu nhược điểm của EA,và tập trung vào thế mạnh của công cụ này để áp dụng đưa vào quy trình lưu vết yêu cầu. Tác giả cũng tương tác thành công với công cụ này để đưa ra được thông tin vết cần thiết.
Về mặt ứng dụng, tác giả đã sử dụng công cụ EA 7.0 xõy dựng lên một bài toán mẫu hệ thống quản lý văn bản-DMS và xõy dựng lên ứng dụng nhằm hạn chế khuyết điểm của quản lý vết yêu cầu trong EA 7.0 đồng thời đưa ra thành báo cáo cụ thể với đầy đủ thông tin về vết yêu cầu.
Những khó khăn và hạn chế
Vấn đề công cụ,mã nguồn mở, EA là công cụ mã nguồn mở nhưng cũng là công cụ thương mại nên có hạn chế các tác động của người dùng bên ngoài vào hệ thống, điều này gaây cản trỏ trong quá trình đưa ra thông tin và xử lý thông tin sao cho hiệu quả và đầy đủ.
Chiến lược đưa ra chưa thực sự được cụ thể hoá trong nhiều trường hợp và chưa đưa ra được mức độ phù hợp cho từng dự án. Với những dự án với quy mô khác nhau cần nắm rừ mức độ của thông tin vết đưa ra tránh thừa thông tin cũng như thông tin đưa ra không đầy đủ.
Về các chiến lược đưa ra chưa xét được vết tổng quan giữa tất cả các loại biểu đồ mà chỉ tập trung vào vết giữa yêu cầu tới usecase, usecase tới lớp và vết tới các test- suite của chúng mà chưa đưa ra được vết liên quan tới mô hình triển khai, tới môi trường thiết lập hay mô hình giao dịch ban đầu.
Bản báo cáo chỉ đưa ra thông tin vết khi có sự kích hoạt ứng dụng bằng cách nhấn vào nút Generate trên giao diện chính của ứng dụng mà không tự động đưa ra thông tin vết khi dự án bắt đầu. điều này gây hạn chế trong vấn đề có những thay đổi liên tục và chỉ đưa ra được thông tin vết khi có yêu cầu của người dùng mà
EA không cho phép lưu thông tin về những phần tử đã bị xoá, hay bị thay đổi. Điều này gây khó khăn khi đưa ra thông tin vết về những yêu cầu đã bị thay đổi hay không còn tồn tại. Chính vì thế thông tin vết đưa ra chỉ bao gồm những yêu cầu hiện có trong dự án mà không bao quát hết thông tin về những yêu cầu không còn tồn tại.
TÀI LIỆU THAM KHẢO
[1] Gotel, O. & Finkelstein, A. 1994a. An Analysis of the Requirements Traceability Problem. London. Imperial College of Science, Technology and Medicine, University of London. 27 p.
[2] Sommerville, I. & Sawyer, P. 1997. Requirements Engineering: A Good
Practice Guide. West Sussex, England, John Wiley & Sons Ltd. 391 p.
[3] Gotel, O. 1995. Thesis: Contribution Structures for Requirements
Traceability. London. Imperial College of Science, Technology and Medicine, University of London. 354 p.
[4] Wiegers, K. 1999. Software Requirements. Washington, United States of
America, Microsoft Press. 350 p.
[5] Leino, V. 2000. Types and Techniques of Requirements Traceability. Helsinki. Helsinki University of Technology. QURE Project. 27 p.
[Egyed 00] A. Egyed, "A Scenario-Driven Aproach to Traceability", 23rd
International Conference on Software Engineering, 2000, pp.123-132.
[Gotel 95] Gotel, O. 1995. Thesis: Contribution Structures for
Requirements Traceability. London. Imperial College of Science, Technology and Medicine, University of London. 354 p.
[Gotel 97] O. Gotel and A. Finkelstein, “Extended Requirements
Traceability: Results of an Industrial Case Study”, 3rd IEEE International Symposium on Requirements Engineering, 1997, pp. 169-178.
[Gotel 20006] Gotel, O. 2000. 7th International Summer School in
Novel Computing: Systems Requirements Engineering, Unit 7. London. University College London. 35 p.
[7] D. Reifer, Making the Software Business Case: Improvement by the Numbers, Addison-Wesley, 2001.[Gotel. & Finkelstein 1994a]
Gotel, O. & Finkelstein, A. 1994a. An Analysis of the Requirements Traceability Problem. London. Imperial College of Science, Technology and Medicine, University of London. 27 p.
[IEEE 04] IEEE Computer Society SWEBOK Team, Guide to the
Software Engineering Body of Knowledge (SWEBOK), IEEE, 2004.
[Kataikko 2000] Kataikko, M. 2000. Sub-process: System Concept Process.
Sonera Ltd. 10 p.
[Leffingwell & Widrig. 20009]
Leffingwell, D. & Widrig, D. 2000. Managing Software Requirements: A Unified Approach. 2nd Edition. California, United States of America, Addison Wesley Longman, Inc. 491 p.
[11] A. Egyed, "A Scenario-Driven Aproach to Traceability", 23rd International Conference on Software Engineering, 2000, pp.123-132.
[12] Kataikko, M. 2000. Sub-process: System Concept Process. Sonera Ltd. 10 p.
[Leino K. 2000] Leino, K. 2000. Sub-process: Requirements Capture Process.
Sonera Ltd. 9 p.
[Leino 2000] Leino, V. 2000. Types and Techniques of Requirements
Traceability. Helsinki. Helsinki University of Technology. QURE Project. 27 p.
[Ovaska 200013] Ovaska, P. 2000. Sub-Process: the Design and
Implementation Process. Sonera Ltd. 22 p.
[14] Ylimäki, Y. 1999. Sub-process: The Testing Process. 10 p.
[RUP15] RUP Website: http://www-
06.ibm.com/software/awdtools/rup/
[Reifer 2001] D. Reifer, Making the Software Business Case: Improvement
[Sommerville, I. & Sawyer]
Sommerville, I. & Sawyer, P. 1997. Requirements Engineering: A Good Practice Guide. West Sussex, England, John Wiley & Sons Ltd. 391 p.
[Sommerville & Finkelstein 1994]
Sommerville, I. & Sawyer, P. 1997. Requirements Engineering: A Good Practice Guide. West Sussex, England, John Wiley & Sons Ltd. 391 p.
[Spence & Probasco 1998]
Spence I., Probasco L., "Traceability Strategies for Managing
Requirements with Use Cases" Rational Software White Paper, 2000
[Takeda, Shiomi,KawaiOhiwa, 1993]
Takeda, N., Shiomi, A., Kawai, K. & Ohiwa, H. (1993). Requirements Analysis by the KJ Editor, Proceedings of the
IEEE International Symposium on Requirements Engineering,
San Diego, California, Jan. 4-6, pp. 98-101.
[Webster] Marriam-Webster Dictionary online: http://www.m-w.com.
[Wiegers 1999] Wiegers, K. 1999. Software Requirements. Washington, United States of America, Microsoft Press. 350 p.
[Weigers 03] K. Weigers, Software Requirements, Redmond: Microsoft
Press, 2003.