Hàng năm, mỗi sinh viên năm cuối đủ điều kiện bảo vệ đồ án tốt nghiệp đều phải liên hệvới các giáo viên trong khoa để được hướng dẫn đề tài và thực hiện đề tài đó.. Sinh viên sẽ mất thời
THU THẬP YÊU CẦU
BẢN KẾ HOẠCH QUẢN LÝ YÊU CẦU
DANH MỤC CÁC HÌNH ẢNH DANH MỤC BẢNG BIỂU DANH MỤC CÁC TỪ VIẾT TẮT VÀ GIẢI THÍCH CÁC THUẬT NGỮ
I BẢN KẾ HOẠCH QUẢN LÝ YÊU CẦU 4.3 Quy ước 4.4 Tính toán Step 1: Tính số UFC Step 2: Tính UFP Step 3: Technical Complexity Factor Step 4: Tính DI Step 5: Tính TCF dựa trên DI Step 6: Tính FP Step 7: Tính KLOC 4.5 Kết luận 4.6 References
2.1 Use Case tổng quát 2.1.1 Use Case chi tiết của actor sinh viên 2.1.2 Use Case chi tiết của actor giáo viên
2.2.10 Nộp đề cương 2.2.11 Nộp báo cáo 2.2.12 Xác nhận hoàn thành đăng kí giảng viên 2.2.13 Chọn thời gian trao đổi 2.2.14 Chọn deadline báo cáo final Chọn deadline để nộp báo cáo cuối cùng 2.2.15 Duyệt báo cáo Duyệt báo cáo 2.2.16 Duyệt đề tài 2.2.17 Giao đề tài
2.2.18 Duyệt đề cương 2.2.19 Gửi đề cương 2.2.20 Duyệt giảng viên hướng dẫn 2.2.21 Phân công giảng viên hướng dẫn 2.2.22 Tạo đợt đồ án 2.2.23 Cập nhập ngày bảo vệ 2.2.24 Tạo tài khoản bộ môn 2.2.25 Tạo tài khoản giảng viên 2.2.26 Tạo tài khoản sinh viên 2.2.27 Xác nhận thông tin Xác nhận thông tin
2.3.10 Nộp đề cương 2.3.11 Nộp báo cáo
2.3.12 Xác nhận hoàn thành đăng kí giảng viên
2.3.13 Chọn thời gian trao đổi 2.3.14 Chọn deadline báo cáo cuối final 2.3.15 Duyệt báo cáo 2.3.16 Duyệt đề tài 2.3.17 Giao đề tài 2.3.18 Duyệt đề cương 2.3.19 Gửi đề cương 2.3.20 Duyệt giảng viên hướng dẫn 2.3.21 Phân công giảng viên hướng dẫn 2.3.22 Tạo đợt đồ án 2.3.23 Cập nhập ngày bảo vệ 2.3.24 Tạo tài khoản bộ môn 2.3.25 Tạo tài khoản giảng viên 2.3.26 Tạo tài khoản sinh viên 2.3.27 Xác nhận thông tin 2.3.28 Gửi kết quả
2.4.10 Nộp đề cương 2.4.11 Nộp báo cáo
2.4.12 Xác nhận hoàn thành đăng kí giảng viên
2.4.13 Chọn thời gian trao đổi 2.4.14 Chọn deadline báo cáo cuối final 2.4.15 Duyệt báo cáo 2.4.16 Duyệt đề tài 2.4.17 Giao đề tài 2.4.18 Duyệt đề cương 2.4.19 Gửi đề cương 2.4.20 Duyệt giảng viên hướng dẫn 2.4.21 Phân công giảng viên hướng dẫn 2.4.22 Tạo đợt đồ án 2.4.23 Cập nhập ngày bảo vệ 2.4.24 Tạo tài khoản bộ môn 2.4.25 Tạo tài khoản giảng viên 2.4.26 Tạo tài khoản sinh viên 2.4.27 Xác nhận thông tin 2.4.28 Gửi kết quả
2.5.1.4 Xem danh sách giảng viên hương dẫn 123
2.5.1.8 Xác nhận hoàn thành đăng kí đề tài 124
2.5.1.12 Xác nhận hoàn thành đăng kí giảng viên 126
2.5.1.13 Chọn thời gian trao đổi 126
2.5.1.14 Chọn deadline báo cáo cuối final 126
2.5.1.20 Duyệt giảng viên hướng dẫn 129
2.5.1.21 Phân công giảng viên hướng dẫn 129
2.5.1.23 Cập nhập ngày bảo vệ 130
2.5.1.24 Tạo tài khoản bộ môn 130
2.5.1.25 Tạo tài khoản giảng viên 131
2.5.1.26 Tạo tài khoản sinh viên 131
134 Đường dẫn trang web: https://doantotnghiep.tlu.shinchoku.dev/
3.1 Thiết kế cơ sở dữ liệu 3.1.1
Mỗi năm, các trường đại học tổ chức lễ tốt nghiệp cho sinh viên Việc bảo vệ đồ án tốt nghiệp là một hoạt động phổ biến, tuy nhiên, cần có phương pháp quản lý đề tài của sinh viên một cách hiệu quả để đạt được kết quả tốt nhất.
Mỗi năm, sinh viên năm cuối đủ điều kiện bảo vệ đồ án tốt nghiệp cần liên hệ với giáo viên trong khoa để được hướng dẫn và thực hiện đề tài Tuy nhiên, việc liên lạc trực tiếp với giáo viên hướng dẫn thường tốn nhiều thời gian.
Cả sinh viên và giáo viên đều gặp khó khăn trong việc liên lạc Sinh viên thường mất thời gian để tìm thông tin cá nhân của giảng viên, và nếu giảng viên đã đủ số lượng sinh viên hướng dẫn, họ phải tìm giảng viên khác Đối với giảng viên, việc nhận quá nhiều yêu cầu từ sinh viên có thể gây phiền toái, khiến họ tốn thời gian cho việc nghe điện thoại và trả lời email.
Hệ thống quản lý đề tài khóa luận tốt nghiệp trên nền web giúp sinh viên và giảng viên giao tiếp nhanh chóng và thuận tiện Mỗi người dùng được cấp tài khoản đăng nhập để quản lý đề tài của mình Sinh viên có thể đề nghị giảng viên hướng dẫn nếu còn chỗ trống, trong khi giảng viên có thể đưa ra đề tài cho sinh viên tham khảo Số lượng sinh viên mà giảng viên có thể hướng dẫn phụ thuộc vào học vị của họ Do không phải sinh viên nào cũng đủ điều kiện làm khóa luận và không phải giảng viên nào cũng hướng dẫn, hệ thống cần có quản trị viên để cấp phát tài khoản cho người dùng.
Bao trùm tất cả các giai đoạn của quá trình phát triển dự án cho tới trước khi bắt tay vào quá trình lập trình.
- Các kiểu yêu cầu : STRQ, FEAT, UC
- Công cụ sử dụng :ms word, excel, trello 1.3 Các nhân tố tham gia
- Khách hàng : Văn phòng khoa
- Người dùng cuối : Sinh viên, giáo viên, văn phòng khoa, bộ môn
- Người quản lý: văn phòng khoa, bộ môn
- Nhà phát triển: Lập trình viên, người phân tích hệ thống, nhà thiết kế,
- Người quản lý phần mềm : Nhóm trưởng nhóm 1
- Người quản trị cơ sở dữ liệu: Team 3
- Người quản lý cấu hình: Team 2, Team 3
1.4 Bảng danh sách các công việc
II.XÁC ĐỊNH YÊU CẦU TỪ CÁC STAKEHOL DERS (Xác định STRQ, FEAT)
2.1 Xác định các yêu cầu từ các stakeholders (STRQs)
1: Sinh viên muốn hệ thống có chức năng liên hệ trực tiếp đến giáo viên hướng dẫn.
- STRQ2: Hệ thống có chức năng đăng nhập
- STRQ3: Sinh viên muốn hệ thống có chức năng đăng ký đề tài
- STRQ4: Sinh viên muốn có chức năng gửi đề tài tới giáo viên hướng dẫn
- STRQ5: Sinh viên chọn giáo viên hướng dẫn từ danh sách của hệ thống
- STRQ6: Sinh viên muốn gửi đề cương đến bộ môn phụ trách
- STRQ7: Giáo viên chấp nhận hoặc từ chối sinh viên chọn
- STRQ8: Giáo viên xem đề tài của sinh viên đưa ra nhận xét chọn hợp lý hoặc không hợp lý
- STRQ9: Giáo viên muốn tạo thời gian để trao đổi với cho sinh viên về đề tài
- STRQ10: Giáo viên muốn xét duyệt đồ án của sinh viên
(admin) có chức năng thêm danh sách giáo viên hướng dẫn
(admin) xét duyệt đề cương của sinh viên
- STRQ13: Bộ môn xét duyệt đề cương của sinh viên s
- STRQ14: VPK thông báo ngày bảo vệ cho sinh viên
- STRQ15: VPK muốn thông báo kết quả bảo vệ ch o si nh vi ên
K (a d mi n) m uố n qu ản lý tài kh oả n ng ườ i dù ng
- S T R Q 17 : Si nh vi ên sử a đề tài
- STRQ18: Sinh viên xác nhận hoàn thành bước đăng ký giáo viên
- STRQ19: VPK gửi mail xác nhận thông tin giáo viên
2.2 Xác định các FEATs từ các STRQs
- FEAT1: Sinh viên liên hệ trực tiếp với giáo viên hướng dẫn qua email
Hệ thống có chức năng đăng nhập
- FEAT3.1: Sinh viên đăng ký tên đề tài14
- FEAT3.2: Bộ môn đăng ký đề tài nếu quá hạn
- FEAT4: Sinh viên có thể gửi đề tài tới cho giáo viên hướng dẫn
- FEAT5: Sinh viên chọn giáo viên hướng dẫn từ danh sách
- FEAT6: Sinh viên có thể gửi file đề cương đến bộ môn phụ trách
- FEAT 7.1: Giáo viên chấp nhận sinh viên
- FEAT 7.2: Giáo viên từ chối sinh viên
- FEAT 8.1: Giáo viên xem đề tài của sinh viên nhận xét chọn hợp lý
- FEAT 8.2: Giáo viên xem đề tài của sinh viên nhận xét không hợp lý
- FEAT 9: Giáo viên có thể tạo thời gian để trao đổi với sinh viên
- FEAT10.1: Giáo viên có thể xem đề cương của sinh viên
- FEAT10.2: Giáo viên đồng ý đề cương của sinh viên
- FEAT10.3: Giáo viên không đồng ý đề cương của sinh viên
- FEAT11: Văn phòng khoa (admin) có chức năng thêm danh sách giáo viên hướng dẫn
- FEAT12.1: Văn phòng khoa (admin) có thể xem đề cương của sinh viên
- FEAT12.2: Văn phòng khoa (admin) đồng ý đề cương của sinh viên
- FEAT12.3: Văn phòng khoa (admin) không đồng ý đề cương của sinh viên
- FEAT12.4: Văn phòng khoa (admin) gửi lịch thực hiện học phần tốt nghiệp
- FEAT13.1: Bộ môn có thể xem đề cương của sinh viên
- FEAT13.2: Bộ môn đồng ý đề cương của sinh viên
- FEAT13.3: Bộ môn không đồng ý đề cương của sinh viên
- FEAT13.4: Bộ môn gửi đề cương về văn phòng khoa
- FEAT14: Văn phòng khoa gửi thông báo ngày bảo vệ cho sinh viên
- FEAT15: Văn phòng khoa gửi thông báo kết quả bảo vệ cho sinh viên
- FEAT16.1: Văn phòng khoa (admin) có thể thêm tài khoản người dùng
- FEAT16.2: Văn phòng khoa (admin) có thể xóa tài khoản người dùng
- FEAT16.3: Văn phòng khoa (admin) có thể sửa tài khoản người dùng
- FEAT17: Sinh viên sửa đề tài
- FEAT18: Sinh viên xác nhận hoàn thành bước đăng ký giáo viên
- FEAT19: Văn phòng khoa gửi mail xác nhận thông tin giáo viên
2.3 Xác định các chức năng của hệ thống
- Tạo tài khoản cho người dùng
- Đăng nhập vào hệ thống
- Tạo đợt đàm đồ án
- Tạo tài khoản cho sinh viên
- Xem danh sách giáo viên
- Chọn giáo viên liên hệ hướng dẫn
- Duyệt giáo viên hướng dẫn
- Phân công giáo viên hướng dẫn cho sinh viên
- Xác nhận hoàn thành bước đăng ký giáo viên
- Duyệt đề tài sinh viên đăng ký
- Đăng ký đề tài cho sinh viên
- Xác nhận hoàn thành bước đăng ký đề tài
2.3.4 Bộ môn phụ trách ngành phân công giáo viên hướng dẫn, thông báo tới giáo viên, sinh viên
Sinh viên gặp giáo viên hướng dẫn để nhận nhiệm vụ thực hiện HPTN
Sinh viên nộp đề cương về bộ môn phụ trách ngành để xét duyệt
- Xác nhận thông tin giáo viên
2.3.5 Bộ môn xét duyệt đề cương và nộp về Văn phòng khoa
- Nộp đề cương về VPK
- Lựa chọn thời gian trao đổi đồ án
2.3.6 Sinh viên thực hiện học phần tốt nghiệp
- Chọn thời gian liên lạc với giáo viên
- Chọn deadline để nộp báo cáo cuối (để chấp thuận xem có được báo cáo bảo vệ không)
- Duyệt báo cáo của sinh viên
- Cập nhật ngày bảo vệ
III Yêu cầu phi chức năng
- Giao diện thân thiện với người dùng
- Hệ thống có tính bảo mật cao
- Hệ thống có khả năng xử lý số lượng người dùng cần thiết mà không có sự suy giảm về hiệu suất
- Hệ thống sẵn sàng khi cần thiết
- Hệ thống phải bảo trì: dễ dàng sửa lỗi để cải thiện hiệu suất
- Hệ thống có thể chạy trên các nền tảng khác nhau
- Hệ thống đáng tin cậy và đáp ứng các yêu cầu của người sử dụng
- Hệ thống phải dễ sử dụng và dễ hiểu
- Hệ thống phải tương thích với các hệ thống khác
COCOMO có 3 loại: organic mode (quen thuộc); semi-detached mode (ở giữa), embedded mode (ràng buộc cứng nhắc)
=> Trong bài này, nhóm dự án sử dụng mô hình Basic Model / Basic COCOMO, với mô hình semi-detached mode.
Theo các mục đã nêu, chúng ta sẽ tiến hành ước lượng thời gian dựa trên mô hình Basic COCOMO, với công thức cần tính lần lượt là Effort Applied (E).
Development Time (D) và People Required (P). Để tính được 3 thông số trên, ta cần biết được KLOC (1k line of code).
Sau đây là những quy ước của các thuật ngữ trong bài này:
• Unadjusted Function Point Count: UFC
Step 1: Tính số UFC Ở bước này, ta sẽ đếm các danh mục cần có trong mỗi hạng mục yêu cầu Cụ thể:
Dữ liệu đầu vào trong phát triển phần mềm, hay còn gọi là external input, là thông tin được cung cấp từ bên ngoài hệ thống Cụ thể, khách hàng sẽ cung cấp các yêu cầu và thông tin cần thiết cho đội ngũ phát triển để xây dựng hệ thống.
Trong bài toán này, External input gồm danh sách các yêu cầu cơ bản, chức năng mà khách hàng muốn có trong hệ thống mong muốn.
Kết quả đầu ra bên ngoài là thông tin được gửi từ ứng dụng phần mềm đến người dùng hoặc các hệ thống khác, bao gồm các loại như báo cáo và biểu đồ.
In this task, the external output includes a list of important links, an agenda, a Gantt chart, functional requirements, non-functional requirements, a product backlog, Team 1's report, a design document, Team 2's report, UI/UX materials, detailed design documentation, source code, and administration manuals.
19 hướng dẫn vận hành (operational manual), test case document, report test, tài liệu hướng dẫn người dùng (user manual).
External inquiry: là các dữ liệu đầu ra cần được kiểm chứng, cụ thể, chúng ta có thể kiểm chứng thông qua các đặc tả được cung cấp.
Trong bài toán này có tất cả 27 use cases.
External files: là các file dùng để truyền thông tin tới các hệ thống khác ngoài hệ thống hiện tại sử dụng.
Trong bài toán này, ta có truyền thông tin sang một hệ thống ngoài đó là outlook (gửi email)
Internal files: là các file logic chính trong hệ thống xử lý.
Trong bài toán này, chúng ta sử dụng 30 file sử dụng logic chính
Bảng thông tin trên tổng hợp các danh mục từ bước 1, được phân loại theo ba mức độ hiện hành: đơn giản, trung bình và phức tạp Trong bài toán này, chúng ta chọn mức độ đơn giản để giảm thiểu sự phức tạp, đồng thời hệ thống của chúng ta không yêu cầu quy mô xử lý lớn.
Ta có: External input (user input) có 1 file; External output (user output) có 17 files; External inquiry (user request) có 27 files; External files có 1 file; Internal files có
Ta sẽ nhân lần lượt các thông số matching tương ứng nhau với thông số của cột simple.
Từ đó, ta có kết quả như sau:
UFP = (1*3) + (17*4) + (27*3) + (1*7) + (30*5) 309 Step 3: Technical Complexity Factor
Hệ số Phức tạp Kỹ thuật (TCF) là một chỉ số quan trọng trong phương pháp định lượng phần mềm COCOMO II, dùng để đo lường độ phức tạp kỹ thuật của phần mềm TCF đánh giá các yếu tố như khả năng tái sử dụng mã nguồn, tầm quan trọng của hệ thống, khả năng mở rộng và bảo trì, giao diện người dùng, tích hợp với các ứng dụng khác, cũng như độ tin cậy và an toàn của phần mềm.
TCF gồm 9 chỉ số và tương ứng từng chỉ số, ta sẽ nhận định và đánh giá từng danh mục trên thang điểm 5.
1 Scalability: The ability of a system to handle an increasing workload or number of users without sacrificing performance (2)
2 Interoperability: The ease with which a system can integrate with other systems or applications (2)
3 Security: The measures in place to protect a system from unauthorized access or attacks (3)
4 Availability: The extent to which a system is available and accessible to users.
5 Performance: The speed and efficiency with which a system performs its tasks.
6 Maintainability: The degree to which a system can be easily modified and updated over time (3)
7 Reliability: The ability of a system to perform consistently and predictably without error or failure (2)
8 Complexity of algorithms: The complexity of the algorithms used by the system to perform its tasks (3)
9 Data storage requirements: The amount and complexity of data that must be stored and managed by the system (2)
10 Technical skills required: The level of technical expertise required to develop and maintain the system (5)
PHÂN TÍCH - THIẾT KẾ
Use Case tổng quát
Hình 2.1: Use Case tổng quát 2.1.1 Use Case chi tiết của actor sinh viên
Hình 1.1.1: Use case chi tiết của actor sinh viên
2.1.2 Use Case chi tiết của actor giáo viên
Hình 2.1.2: Use case chi tiết của actor giáo viên 2.1.3 Use Case chi tiết của actor bộ môn
Hình 2.1.3: Use case chi tiết của actor bộ môn
2.1.4 Use Case chi tiết của actor văn phòng khoa
Hình 2.1.4: Use case chi tiết của actor văn phòng khoa
Đặc tả use case
Bảng 2.2.1 Đặc tả use case đăng nhập
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
4a.2 Thông tin email để trống hiện tin thông báo” Vui lòng nhập email!” Chuyển người dùng về bước 2.
4a.3 Thông tin mật khẩu để trống hiện tin thông báo” Vui lòng nhập mật khẩu!” Chuyển người dùng về bước 2.
4a.4 Thông tin mật khẩu không hợp lệ hiện tin thông báo” Sai mật khẩu!”.Chuyển người dùng về bước 2.
4a.5 Người dùng chọn lệnh lấy lại mật khẩu.Use Case tiếp tục Use Case USE CASE 1-2.
Bảng 2.2.2: Đặc tả use case lấy lại mật khẩu
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
*Định dạng mật khẩu: độ dài từ 6 đến 20 kí tự, 1 kí tự hoa, 1 kí tự thường, 1 số
Bảng 2.2.3 Đặc tả use case chọn giảng viên
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
2.2.4 Xem danh sách giảng viên hướnng dẫn
Bảng 2.2.4 : Đặc tả use case xem danh sách giảng viên
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Bảng 2.2.5 : Đặc tả use case liên hệ giảng viên
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
35 Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
Bảng 2.2.7 Đặc tả use case sửa đề tài
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
5a.1 Thông tin tên đề tài để trống hiện tin thông báo” Vui lòng nhập tên đề tài!” Chuyển người dùng về bước 4.
5a.2 Thông tin mô tả để trống hiện tin thông báo” Vui lòng nhập mô tả!” Chuyển người dùng về bước 4.
5a.3.Nhấn thoát khỏi form sửa đề tài Use case kết thúc.
*Phạm vi:Tên đề tài (Phạm vị 0/150 kí tự), Mô tả (Phạm vị 0/1000)
2.2.8 Xác nhận hoàn thành đăng kí đề tài
Bảng 2.2.8: Đặc tả use case xác nhận hoàn thành đăng kí đề tài
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Use case (ID 4) Xem nhiệm vụ
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
Luồng ngoại lệ Bước Hành động phân nhánh
Bảng 2.2.10 Đặc tả use case nộp đề cương
Mục tiêu Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
3 3a Người dùng nhấn thoát khỏi quản lý tài liệu.Use Case kết thúc.
Khi thông tin file báo cáo để trống, hệ thống sẽ hiển thị thông báo “Vui lòng chọn file!” và chuyển sang bước 4 Nếu người dùng nhấn thoát khỏi form nộp đề cương, Use Case sẽ kết thúc.
5a.3 Hệ thống xác thực thông tin file báo cáo không thành công và hiển thị thông báo ”File không đúng định dạng!!” Chuyển sang bước 4.
*Định dạng file: file docx
2.2.12 Xác nhận hoàn thành đăng kí giảng viên
Bảng 2.2.12 Đặc tả use case xác nhận hoàn thành đăng kí GV
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
2.2.13 Chọn thời gian trao đổi
Use case (ID : 7.1) Chọn thời gian trao đổi đồ án
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
2.2.14 Chọn deadline báo cáo final
Bảng 2.2.14 Đặc tả use case họn dealine báo cáo final
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
Bảng 2.2.15 Đặc tả use case duyệt báo cáo
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
7a1 Thông tin ghi chú để trống hiển thị thông báo” Vui lòng nhập ghi chú!” Chuyển người dùng về bước 4.
7a.2 Nhấn thoát khỏi form duyệt báo cáo Use case kết thúc.
Bảng 2.2.16 Đặc tả use case duyệt đề tài
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
7a.2 Nhấn thoát khỏi form duyệt đề tài Use case kết thúc.
Bảng 2.2.17: Đặc tả use case giáo đề tài
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Hệ thống xác thực thông tin giao đề tài không thành công và hiển thị thông báo lỗi Nếu thông tin tên đề tài để trống, hệ thống sẽ hiện thông báo “Vui lòng nhập tên đề tài!” và chuyển người dùng về bước 4.
7a.2 Thông tin mô tả để trống hiện tin thông báo” Vui lòng nhập mô tả!” Chuyển người dùng về bước 4.
7a.4 Nhấn thoát khỏi form giao đề tài Use case kết thúc.
Bảng 2.2.18: Đặc tả use case uyệt dể cương
Mục tiêu Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
7 7a1 Thông tin trạng thái duyệt để trống hiển thị thông báo” Vui lòng chọn trạng thái duyệt!”. Chuyển người dùng về bước 4.
7a2 Thông tin ghi chú để trống hiển thị thông báo” Vui lòng nhập ghi chú!” Chuyển người dùng về bước 4.
7a.3 Nhấn thoát khỏi form duyệt đề tài Use case kết thúc.
Mục tiêu Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
2.2.20 Duyệt giảng viên hướng dẫn
Bảng 2.2.20: Đặc tả use case duyệt giảng viên hướng dẫn
Mức độ ưu tiên Điều kiện tiên quyết
59 Điều kiện kết thúc thành công
Phân quyền Actors Kích hoạt
2.2.21 Phân công giảng viên hướng dẫn
Bảng 2.2.21 : Đặc tả use case phân công giảng viên hướng dẫn
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
61 Điều kiện kết thúc thất bại
Phân quyền Actors Kích hoạt
Bảng 2.2.22 : Đặc tả use case tạo đợt đồ án
Mức độ ưu tiên Điều kiện tiên quyết Điều kiện kết thúc thành công
1 Văn phòng khoa nhấn chọn mục “Đợt đồ án”.
5a2 Thông tin thời gian bắt đầu để trống hiển thị thông báo “Vui lòng chọn thời gian!”.Chuyển về bước 4.
5a.3 Người dùng nhấn thoát khoản form nhập thông tin đợt tạo đồ án.Use Case kết thúc.
*Yêu cầu thứ tự các mốc thời gian: Ngày bắt đầu
< ngày liên hệ Giảng viên