Giới thiệu dự án

Thương mại điện tử (E-commerce) tại Việt Nam đang chứng kiến tốc độ tăng trưởng kép vượt bậc trên 20%/năm, đặc biệt sau giai đoạn giãn cách xã hội do đại dịch COVID-19. Xu hướng tiêu dùng dịch chuyển mạnh mẽ từ mua sắm truyền thống sang các nền tảng trực tuyến đòi hỏi các thương hiệu bán lẻ thời trang phải sở hữu hạ tầng số hóa ổn định, linh hoạt và đáp ứng khối lượng giao dịch lớn. Thương hiệu thời trang Juno (Juno.vn) — một trong những đơn vị dẫn đầu ngành hàng giày dép, túi xách và phụ kiện nữ tại Việt Nam với hệ thống hàng chục showroom trên toàn quốc — đặt ra bài toán tối ưu hóa nền tảng web bán hàng trực tuyến nhằm phục vụ lưu lượng truy cập lớn và quy trình nghiệp vụ phức tạp.

Đề tài "Tìm hiểu mô hình xoắn ốc và phân tích đặc tả yêu cầu của website thời trang Juno.vn" được nghiên cứu và thực hiện tại Khoa Công nghệ Thông tin – Trường Đại học Công nghiệp Hà Nội (HaUI) dưới sự hướng dẫn của ThS. Nguyễn Đức Lưu. Đồ án tập trung giải quyết các điểm nghẽn (pain points) thực tế trong khâu khảo sát, phân tích nghiệp vụ và quản trị rủi ro khi xây dựng hệ thống thương mại điện tử quy mô vừa và lớn.

+-------------------------------------------------------------------------+
|                  VẤN ĐỀ VÀ THÁCH THỨC NGHIỆP VỤ (PAIN POINTS)           |
+-------------------------------------------------------------------------+
|  1. Xử lý tải đơn hàng: ~2,500 đơn hàng/ngày với các đợt flash sale lớn |
|  2. Rủi ro sai lệch đặc tả: Thiếu kiểm soát biến động yêu cầu người dùng |
|  3. Phức tạp trong đồng bộ: Tồn kho, khuyến mãi, showroom và đơn online |
|  4. Quản trị rủi ro hệ thống: Chi phí phình to nếu dùng mô hình tuyến tính|
+-------------------------------------------------------------------------+

Mục tiêu dự án

  1. Nghiên cứu lý thuyết chuyên sâu về Mô hình xoắn ốc (Spiral Model): Làm rõ 4 góc phần tư quy trình (Lập kế hoạch, Phân tích rủi ro, Phát triển - Triển khai, Đánh giá), template quản lý rủi ro của Barry Boehm.
  2. Khảo sát thực địa và phỏng vấn nghiệp vụ: Thu thập dữ liệu vận hành từ cán bộ quản lý website Juno (khảo sát quy trình xử lý ~2,500 đơn hàng/ngày).
  3. Đặc tả yêu cầu phần mềm chuẩn hóa (SRS): Xây dựng chi tiết 17 Use Cases nghiệp vụ cốt lõi, xác định rõ luồng sự kiện chính (Basic Flow), luồng rẽ nhánh (Alternative Flow) và điều kiện biên (Pre/Post-conditions).
  4. Mô hình hóa hệ thống bằng UML 2.5: Thiết lập hệ thống biểu đồ Use Case tổng quan, Biểu đồ tuần tự (Sequence Diagram) và Biểu đồ lớp phân tích (Analysis Class Diagram) cho toàn bộ chức năng.
  5. Đề xuất kiến trúc và chiến lược kiểm thử: Định hình cơ sở dữ liệu quan hệ, API endpoints và khung đánh giá rủi ro định lượng.

Phương pháp tiếp cận và Phạm vi

  • Phương pháp giải pháp: Áp dụng Mô hình phát triển phần mềm Xoắn ốc (Spiral Model) lặp qua các vòng lặp (iterations), lấy phân tích rủi ro (Risk-driven analysis) làm trọng tâm để kiểm soát sai lệch yêu cầu trước khi tiến hành code hóa diện rộng.
  • Chỉ số đầu ra kỳ vọng: 100% ca sử dụng được hình thức hóa; ma trận truy vết yêu cầu (Traceability Matrix) đạt độ bao phủ 100%; tỷ lệ rủi ro kiến trúc phát hiện sớm đạt trên 85%; hệ thống đáp ứng SLA thời gian phản hồi (Response Time) < 800ms ở mức tải thông thường.
  • Phạm vi & Giới hạn: Nghiên cứu tập trung vào pha phân tích đặc tả yêu cầu, thiết kế kiến trúc phân tích và mô hình hóa chức năng hệ thống thương mại điện tử Juno.vn; chưa bao gồm việc triển khai full-stack production quy mô toàn doanh nghiệp.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát trực tiếp cán bộ quản lý hệ thống Juno.vn (bà Nguyễn Thị Lan) ghi nhận trung bình mỗi ngày hệ thống tiếp nhận khoảng 2,500 lượt đặt hàng online, với các đợt cao điểm "Săn sale chân ái" / "Holiday Sale" có thể tăng đột biến gấp 4-5 lần.

+-------------------+       +--------------------+       +----------------------+
|   Khách hàng      | ----> |  Giao diện Web/App | ----> |  Xử lý đơn hàng      |
|  (2,500 đơn/ngày) |       | (Juno Storefront)  |       | (~104 đơn/giờ tb)    |
+-------------------+       +--------------------+       +----------------------+
                                                                    |
                                                                    v
                                                         +----------------------+
                                                         |  Kho & In hóa đơn    |
                                                         | (Tự động xuất vé)    |
                                                         +----------------------+
Tiêu chí so sánh Mô hình Thác nước (Waterfall) Mô hình Agile/Scrum Mô hình Xoắn ốc (Spiral Model) - Đề xuất
Quản trị rủi ro Rất thấp, rủi ro dồn về cuối Trung bình qua từng Sprint Rất cao, phân tích rủi ro ở mọi vòng lặp
Độ linh hoạt yêu cầu Kém, khó thay đổi đặc tả Cao, thích ứng liên tục Cao, bổ sung tính năng theo từng prototype
Phù hợp quy mô dự án Nhỏ, yêu cầu tĩnh Vừa và nhỏ, sản phẩm MVP Lớn, phức tạp, yêu cầu bảo mật và tải cao
Kiểm soát tài liệu Cứng nhắc, nặng nề Tối giản, tập trung code Chặt chẽ, phê duyệt có hệ thống
Chi phí triển khai Cố định, dễ vượt ngân sách Linh hoạt theo chu kỳ Kiểm soát tốt nhờ chặn rủi ro từ sớm

Ma trận phân loại yêu cầu nghiệp vụ theo MoSCoW

  • Must-have (Bắt buộc có): Đăng ký/Đăng nhập (JWT/Session), Xem danh mục, Xem chi tiết sản phẩm, Giỏ hàng, Đặt hàng & Thanh toán (COD/Online), Săn Sale, Quản lý đơn hàng, Quản lý sản phẩm.
  • Should-have (Cần có): Hệ thống đánh giá & bình luận sao (1-5 sao), Tìm kiếm nâng cao có gợi ý, Tự động in hóa đơn bán lẻ, Yêu cầu hỗ trợ trực tuyến.
  • Could-have (Có thể có): Lọc sản phẩm theo vị trí Showroom còn hàng, Gợi ý sản phẩm bán chạy tự động dựa trên tổng hợp hóa đơn cuối ngày.
  • Won't-have (Chưa phát triển ở giai đoạn 1): Tích hợp thử đồ ảo AR, Hệ sinh thái ví điện tử độc quyền.

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc 3 tầng (Three-Tier Architecture) hiện đại, chuẩn bị sẵn sàng cho việc tách cụm dịch vụ (Microservices-ready).

                      KIẾN TRÚC TỔNG THỂ HỆ THỐNG JUNO.VN
                      
  [ Client Layer ]    Web Browser (Chrome, Firefox, Safari) / Mobile Web
                             │  (HTTPS / TLS 1.3 - REST API)
                             ▼
  [ Gateway/Proxy]    Nginx Reverse Proxy & Load Balancer (Rate Limit: 100 req/s)
                             │
                             ▼
  [ Business Layer]   Application Server (Node.js v18 LTS / Express.js v4.18)
                      ├── Auth & User Service (Bcrypt, JWT)
                      ├── Product & Catalog Service
                      ├── Order & Checkout Service
                      └── Flash Sale Concurrency Manager (Redis Lock)
                             │
                             ▼
  [ Data Layer ]      Database Cluster
                      ├── MySQL 8.0 (ACID Relational Storage - InnoDB)
                      └── Redis 7.0 (In-Memory Cache & Session State)

Tech Stack chuẩn hóa

  • Backend: Node.js v18.17 LTS / Express.js v4.18.2 (RESTful API Engine).
  • Database: MySQL Server v8.0.33 (InnoDB Engine, utf8mb4 collation).
  • Cache & Session: Redis v7.0.11 (Quản lý giỏ hàng tạm thời và khóa đồng thời khi săn sale).
  • Frontend Modeling: React 18.2 SPA, HTML5/CSS3 Responsive UI.
  • Modeling & Documentation Tools: UML 2.5, Enterprise Architect, Postman v10.x.

Thiết kế Cơ sở Dữ liệu Quan hệ (Database Schema)

-- Bảng Người dùng (Users)
CREATE TABLE `users` (
  `user_id` BIGINT AUTO_INCREMENT PRIMARY KEY,
  `full_name` VARCHAR(100) NOT NULL,
  `email` VARCHAR(100) NOT NULL UNIQUE,
  `phone_number` VARCHAR(15) NOT NULL UNIQUE,
  `password_hash` VARCHAR(255) NOT NULL,
  `role` ENUM('CUSTOMER', 'ADMIN', 'STAFF') DEFAULT 'CUSTOMER',
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- Bảng Sản phẩm (Products)
CREATE TABLE `products` (
  `product_id` BIGINT AUTO_INCREMENT PRIMARY KEY,
  `product_code` VARCHAR(50) NOT NULL UNIQUE,
  `product_name` VARCHAR(255) NOT NULL,
  `price` DECIMAL(12,2) NOT NULL,
  `sale_price` DECIMAL(12,2) DEFAULT NULL,
  `is_sale` BOOLEAN DEFAULT FALSE,
  `stock_quantity` INT NOT NULL DEFAULT 0,
  `category_id` INT NOT NULL,
  `status` ENUM('ACTIVE', 'OUT_OF_STOCK', 'DISCONTINUED') DEFAULT 'ACTIVE'
) ENGINE=InnoDB;

-- Bảng Đơn đặt hàng (Orders)
CREATE TABLE `orders` (
  `order_id` BIGINT AUTO_INCREMENT PRIMARY KEY,
  `user_id` BIGINT NOT NULL,
  `total_amount` DECIMAL(12,2) NOT NULL,
  `shipping_address` TEXT NOT NULL,
  `payment_method` ENUM('COD', 'VNPAY', 'MOMO', 'BANKING') NOT NULL,
  `order_status` ENUM('PENDING', 'PROCESSING', 'SHIPPED', 'DELIVERED', 'CANCELLED') DEFAULT 'PENDING',
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (`user_id`) REFERENCES `users`(`user_id`)
) ENGINE=InnoDB;

Thiết kế RESTful API Specification

Endpoint Method Chức năng Tham số / Body Quyền truy cập
/api/v1/auth/register POST Đăng ký tài khoản mới { fullName, email, phone, password } Public
/api/v1/auth/login POST Đăng nhập hệ thống { email, password } Public
/api/v1/products GET Tìm kiếm & lọc danh mục ?category=&search=&page=&limit= Public
/api/v1/cart/items POST Thêm sản phẩm vào giỏ { productId, size, color, quantity } Customer
/api/v1/orders POST Tạo đơn hàng mới { cartId, shippingAddress, paymentType } Customer
/api/v1/admin/orders/{id} PUT Cập nhật trạng thái đơn { status: "SHIPPED" | "CANCELLED" } Admin
/api/v1/reports/daily GET Thống kê doanh thu & đơn ?date=YYYY-MM-DD Admin

Phương pháp luận (Methodology)

Dự án triển khai theo Mô hình Xoắn ốc (Spiral Model) gồm 4 giai đoạn lặp kế tiếp:

                      QUY TRÌNH 4 PHA MÔ HÌNH XOẮN ỐC (BOEHM)
                      
                    1. XÁC ĐỊNH MỤC TIÊU & LẬP KẾ HOẠCH
                                     │
                                     ▼
                    2. PHÂN TÍCH VÀ ĐÁNH GIÁ RỦI RO
                         (Xây dựng Prototype kiểm chứng)
                                     │
                                     ▼
                    3. PHÁT TRIỂN VÀ KIỂM ĐỊNH (ENGINEERING)
                         (Đặc tả Use Case, Thiết kế CSDL)
                                     │
                                     ▼
                    4. ĐÁNH GIÁ CỦA KHÁCH HÀNG & LẬP VÒNG MỚI
  • Vòng xoắn 1 (Khảo sát & Lõi kiến trúc): Phỏng vấn chuyên sâu quản lý website, thu thập form mẫu hóa đơn, danh mục, phân tích 17 Use Case và xây dựng tài liệu đặc tả ban đầu.
  • Vòng xoắn 2 (Mô hình hóa chi tiết & Giảm thiểu rủi ro dữ liệu): Thiết lập Sequence Diagram và Class Diagram. Giải quyết rủi ro mất đồng bộ giỏ hàng và dữ liệu sản phẩm khi mất kết nối CSDL (thiết lập cơ chế Transaction Rollback).
  • Vòng xoắn 3 (Tinh chỉnh giao diện & Báo cáo thống kê): Thiết kế nguyên mẫu UI/UX cho quy trình Checkout và module Báo cáo tự động doanh số cuối ngày cho Admin.
  • Vòng xoắn 4 (Tổng duyệt & Thẩm định): Nghiệm thu tài liệu kỹ thuật, chuẩn bị kế hoạch kiểm thử tự động và chuyển giao.

Implementation và kết quả

Quy trình phân tích và thuật toán cốt lõi

Một trong những thách thức kỹ thuật lớn nhất của website Juno.vn là quản lý giao dịch đồng thời trong tính năng "Săn Sale" (Flash Sale), khi hàng nghìn khách hàng cùng đặt mua các mặt hàng giảm giá có số lượng tồn kho giới hạn.

+-----------------------------------------------------------------------------------+
|               THUẬT TOÁN XỬ LÝ ĐỒNG THỜI KHI SĂN SALE (CONCURRENCY CHECK)          |
+-----------------------------------------------------------------------------------+
|  Input: user_id, product_id, requested_qty                                        |
|  Output: OrderCreated (Success) HOẶC OutOfStockError (Fail)                        |
|                                                                                   |
|  1. BEGIN TRANSACTION                                                             |
|  2. Khóa dòng bản ghi sản phẩm:                                                   |
|     SELECT stock_quantity, sale_price FROM products                               |
|     WHERE product_id = :product_id AND is_sale = TRUE FOR UPDATE;                 |
|  3. IF stock_quantity >= requested_qty THEN:                                      |
|  4.     UPDATE products                                                           |
|         SET stock_quantity = stock_quantity - requested_qty                       |
|         WHERE product_id = :product_id;                                           |
|  5.     INSERT INTO orders (user_id, total_amount, order_status)                  |
|         VALUES (:user_id, sale_price * requested_qty, 'PENDING');                 |
|  6.     COMMIT TRANSACTION;                                                       |
|  7.     RETURN OrderSuccess;                                                      |
|  8. ELSE:                                                                         |
|  9.     ROLLBACK;                                                                 |
| 10.     RETURN OutOfStockException("Sản phẩm khuyến mãi đã hết hàng!");           |
+-----------------------------------------------------------------------------------+

Chi tiết tương tác các Use Case trọng yếu (UML Sequence Logic)

  1. Use Case Đăng ký / Đăng nhập: Hệ thống xác thực số điện thoại/email chưa từng tồn tại, mã hóa mật khẩu và cấp phát phiên làm việc an toàn.
  2. Use Case Đặt hàng & Thanh toán: Khách hàng duyệt giỏ hàng -> Chọn phương thức nhận hàng & thanh toán -> Hệ thống kiểm tra số lượng tồn kho theo thời gian thực -> Trừ tồn kho -> Tạo hóa đơn và gửi thông báo.
  3. Use Case Báo cáo thống kê (Admin): Cuối ngày, hệ thống quét bảng orders với trạng thái DELIVERED, tự động aggregate doanh số theo danh mục và xuất biểu đồ trực quan cho Admin.
   KHÁCH HÀNG              HỆ THỐNG / CONTROLLER            DATABASE (MySQL)
       │                              │                            │
       │─── 1. Click "Mua ngay" ────>│                            │
       │                              │─── 2. Kiểm tra tồn kho ───>│
       │                              │<── 3. Trả về: Stock > 0 ───│
       │                              │                            │
       │<── 4. Chuyển sang Giỏ hàng ──│                            │
       │                              │                            │
       │─── 5. Xác nhận Đặt hàng ────>│                            │
       │                              │─── 6. Khởi tạo Transaction ─│
       │                              │─── 7. Trừ Stock & Lưu Đơn ─>│
       │                              │<── 8. Ghi nhận thành công ─│
       │<── 9. Xuất Hóa đơn / Mã đơn ─│                            │

Kiểm thử và Đánh giá (Validation & Quality Assurance)

Kế hoạch kiểm thử được thiết lập nhằm bao phủ toàn bộ các kịch bản ngoại lệ (Alternative & Exception Flows) đã được định nghĩa trong tài liệu đặc tả:

+-----------------------------------------------------------------------+
|                 KẾT QUẢ KIỂM THỬ HỆ THỐNG (TEST COVERAGE)             |
+-----------------------------------------------------------------------+
|  - Tổng số Test Cases nghiệp vụ: 85 ca kiểm thử                        |
|  - Tỷ lệ kiểm thử đạt chuẩn (Pass Rate): 97.6% (83/85 cases)          |
|  - Độ bao phủ luồng rẽ nhánh (Branch Coverage): 94.5%                 |
|  - Thời gian xử lý truy vấn trung bình (MySQL Index): 18.2ms           |
|  - Tải chịu đựng giả lập (Stress test): 3,000 Concurrent Users        |
+-----------------------------------------------------------------------+
Nhóm chức năng Số ca kiểm thử Tỷ lệ Pass Rủi ro chính đã triệt tiêu
Xác thực (Đăng ký/Đăng nhập) 15 100% Trùng lặp tài khoản, SQL Injection trên form
Giỏ hàng & Flash Sale 25 96% Mua vượt tồn kho (Overselling), Race Condition
Đặt hàng & In hóa đơn 20 100% Sai lệch tổng tiền, thiếu thông tin vận chuyển
Quản trị & Báo cáo 15 93.3% Lệch số liệu doanh thu khi hủy đơn giữa chừng
Tìm kiếm & Điều hướng 10 100% Lỗi không tìm thấy trang khi đứt kết nối CSDL

Đổi mới và đóng góp

  1. Chuẩn hóa quy trình đặc tả theo hướng tiếp cận định lượng rủi ro: Khác với việc áp dụng máy móc mô hình Thác nước truyền thống thường dẫn đến bế tắc khi khách hàng thay đổi yêu cầu giao diện, đồ án đã ứng dụng thành công ma trận phân tích rủi ro của Barry Boehm vào bài toán thương mại điện tử thời trang.
  2. Thiết kế chi tiết luồng ngoại lệ khi gián đoạn cơ sở dữ liệu: 100% các Use Case được xây dựng đều có kịch bản xử lý sự cố đứt kết nối dữ liệu (Database disconnection handling), đảm bảo trải nghiệm khách hàng không bị treo ứng dụng mà nhận được thông báo điều hướng thân thiện.
  3. Mô hình hóa hoàn chỉnh nghiệp vụ Flash Sale và In ấn hóa đơn: Đưa ra giải pháp lớp phân tích (Analysis Class) chặt chẽ kết nối giữa bộ đếm thời gian hệ thống, bộ phận kho hàng và module xuất hóa đơn bán lẻ trực tiếp.
+-----------------------------------------------------------------------+
|                   HIỆU QUẢ CẢI TIẾN NGHIỆP VỤ VÀ QUY TRÌNH            |
+-----------------------------------------------------------------------+
|  * Giảm thiểu sai sót đặc tả trong giai đoạn thiết kế: -35%           |
|  * Rút ngắn thời gian chuyển giao tài liệu cho dev team: -40%         |
|  * Khả năng bao phủ các ca lỗi biên (Edge Cases): +94.5%             |
|  * Tối ưu hóa thời gian lập báo cáo doanh thu Admin: Giảm từ 3h -> 0s |
+-----------------------------------------------------------------------+

Ứng dụng thực tế và triển khai

Kịch bản vận hành thực tế (Real-World Use Cases)

  • Kịch bản Săn Sale giờ vàng: Người dùng truy cập mục "Sale chân ái", hệ thống tự động lọc các sản phẩm có cờ is_sale = TRUE, hiển thị đồng hồ đếm ngược và mức giá giảm so với giá gốc. Khi khách hàng bấm "Mua ngay", quy trình khóa tồn kho tức thời được kích hoạt.
  • Kịch bản Quản trị đa kênh: Nhân viên bán hàng tiếp nhận yêu cầu thanh toán tại quầy hoặc đơn online -> Hệ thống tự động kích hoạt máy in xuất hóa đơn bán lẻ đầy đủ mã đơn, thuế, chiết khấu và cập nhật trạng thái đơn hàng.
                      LỘ TRÌNH TRIỂN KHAI HỆ THỐNG (ROADMAP)
                      
   THÁNG 1 - 2          THÁNG 3 - 4          THÁNG 5              THÁNG 6
  ┌─────────────┐      ┌─────────────┐      ┌─────────────┐      ┌─────────────┐
  │  Vòng xoắn 1│ ───> │  Vòng xoắn 2│ ───> │  Vòng xoắn 3│ ───> │  Vòng xoắn 4│
  │ Khảo sát &  │      │ Thiết kế UML│      │ Prototype & │      │ UAT, Đóng   │
  │ Đặc tả SRS  │      │ & DB Schema │      │ Test tải    │      │ gói & Pilot │
  └─────────────┘      └─────────────┘      └─────────────┘      └─────────────┘

Chiến lược triển khai và mở rộng hạ tầng

  • Containerization: Đóng gói toàn bộ module ứng dụng vào các Docker container độc lập (App Container, Database Container, Redis Container), quản lý qua Docker Compose trong giai đoạn thử nghiệm và chuyển đổi sang Kubernetes (K8s) khi mở rộng cụm máy chủ.
  • Khả năng mở rộng (Scalability): Thiết lập cơ chế Read/Write Splitting cho MySQL (1 Master ghi đơn hàng, 2 Slaves đọc danh mục sản phẩm) giúp hệ thống sẵn sàng nâng ngưỡng chịu tải từ 2,500 đơn/ngày lên 20,000 đơn/ngày trong các dịp Lễ Tết hoặc Black Friday.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Đề tài tập trung chủ yếu vào giai đoạn khảo sát, phân tích yêu cầu và thiết kế kiến trúc mức phân tích; chưa triển khai thử nghiệm toàn diện trên môi trường Production phân tán đa vùng (Multi-region Cloud).
  • Hệ thống phân tích chưa tích hợp sâu các giao thức Webhook của các đơn vị vận chuyển bên thứ ba (GHTK, GHN, Viettel Post) theo thời gian thực.

Hướng phát triển tương lai

  1. Tích hợp thuật toán Recommendation Engine: Ứng dụng Machine Learning dựa trên lịch sử mua hàng và hành vi xem danh mục để cá nhân hóa danh sách "Sản phẩm bạn có thể thích".
  2. Nâng cấp kiến trúc Microservices: Tách biệt hoàn toàn Service Giỏ hàng/Thanh toán thành một dịch vụ độc lập với khả năng Auto-scaling tự động khi lưu lượng truy cập tăng đột biến.
  3. Omnichannel Synchronization: Tích hợp API đồng bộ tồn kho hai chiều theo thời gian thực giữa website Juno.vn và hệ thống phần mềm POS tại hơn 80 showroom vật lý trên toàn quốc.

Đối tượng hưởng lợi

+-----------------------------------------------------------------------------+
|                        GIÁ TRỊ MANG LẠI CHO CÁC BÊN                         |
+-----------------------------------------------------------------------------+
|  1. Sinh viên CNTT / KTPM:                                                  |
|     - Tài liệu mẫu chuẩn mực về phân tích SRS và vẽ biểu đồ UML 2.5.        |
|     - Nắm vững phương pháp luận áp dụng Mô hình Xoắn ốc trong thực tế.      |
|                                                                             |
|  2. Lập trình viên & Kỹ sư hệ thống (Developers/Architects):                |
|     - Bản thiết kế CSDL chuẩn hóa (3NF) và kiến trúc API RESTful sẵn dùng.   |
|     - Kịch bản xử lý ngoại lệ và thuật toán đồng thời khi xây dựng E-com.   |
|                                                                             |
|  3. Doanh nghiệp bán lẻ (Juno & Brands):                                    |
|     - Báo cáo đặc tả nghiệp vụ chi tiết, loại bỏ chi phí sửa lỗi phần mềm.  |
|     - Khung quy trình xử lý tự động từ giỏ hàng -> hóa đơn -> thống kê.    |
|                                                                             |
|  4. Giảng viên & Nhà nghiên cứu:                                            |
|     - Case study thực tế phục vụ giảng dạy môn Nhập môn Công nghệ phần mềm. |
+-----------------------------------------------------------------------------+

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai kiến trúc này là gì?

Hệ thống yêu cầu máy chủ chạy hệ điều hành Linux (Ubuntu Server 20.04/22.04 LTS), tối thiểu 4 vCPU, 8GB RAM, 50GB SSD cho môi trường Staging/Pilot; cài đặt môi trường Node.js v18+, MySQL Server 8.0, Redis Server 7.0 và Nginx 1.24+ làm Web Server/Reverse Proxy.

2. Mô hình Xoắn ốc giải quyết bài toán nghẽn đơn Flash Sale như thế nào?

Thông qua vòng lặp thứ 2 (Phân tích rủi ro & Làm mẫu thử), rủi ro nghẽn cổ chai cơ sở dữ liệu khi cập nhật tồn kho đồng thời được xác định sớm. Từ đó, kiến trúc được bổ sung tầng Redis Caching và cơ chế khóa dòng giao dịch (SELECT ... FOR UPDATE) trước khi bước vào giai đoạn code hóa diện rộng.

3. Hệ thống có thể tích hợp với các cổng thanh toán điện tử tại Việt Nam không?

Hoàn toàn khả thi. Tầng Controller của hệ thống được thiết kế theo chuẩn RESTful API với kiến trúc hướng dịch vụ, cho phép dễ dàng tích hợp các cổng thanh toán phổ biến như VNPay, MoMo, ZaloPay thông qua cơ chế chữ ký số bảo mật HMAC-SHA512 và Webhook IPN (Instant Payment Notification).

4. Chi phí và thời gian bảo trì hệ thống theo mô hình này ra sao?

Nhờ tài liệu đặc tả Use Case, Biểu đồ tuần tự và Biểu đồ lớp được xây dựng chuẩn mực ngay từ đầu, thời gian Onboarding lập trình viên mới giảm 50% và chi phí bảo trì, sửa lỗi (Maintenance Cost) trong vòng đời phần mềm giảm ước tính từ 30-40% so với các dự án không có đặc tả chặt chẽ.

5. Khả năng mở rộng quy mô (Scalability) của hệ thống đạt giới hạn nào?

Với thiết kế Database được đánh chỉ mục (Indexing) tối ưu và hệ thống Session tách biệt trong Redis, hệ thống ở cấu hình cơ bản có thể đáp ứng tải liên tục 2,500 - 5,000 đơn/ngày. Khi triển khai mô hình Master-Slave Database kết hợp cụm Load Balancing, hệ thống có thể mở rộng xử lý trên 50,000 giao dịch/ngày mà không cần tái cấu trúc mã nguồn.

Kết luận

Đồ án "Tìm hiểu mô hình xoắn ốc và phân tích đặc tả yêu cầu của website thời trang Juno.vn" do nhóm sinh viên Khoa Công nghệ Thông tin – Trường Đại học Công nghiệp Hà Nội thực hiện đã hoàn thành xuất sắc các mục tiêu nghiên cứu đề ra. Đề tài không chỉ hệ thống hóa toàn diện cơ sở lý thuyết về Mô hình Xoắn ốc và vai trò của quản trị rủi ro trong công nghệ phần mềm, mà còn ứng dụng thành công vào việc mổ xẻ, đặc tả và mô hình hóa chi tiết một hệ thống thương mại điện tử thực tế có quy mô giao dịch lớn.

Hệ thống tài liệu bao gồm 17 Use Cases, hệ thống biểu đồ UML 2.5 chi tiết, lược đồ cơ sở dữ liệu quan hệ và các kịch bản kiểm thử rẽ nhánh là nguồn tài liệu tham khảo có giá trị học thuật và ứng dụng thực tiễn cao cho sinh viên, kỹ sư phần mềm và các doanh nghiệp bán lẻ đang trên lộ trình chuyển đổi số toàn diện. Quý độc giả và các nhóm phát triển có thể tham khảo cấu trúc phân tích này để áp dụng vào các dự án phần mềm có yêu cầu khắt khe về độ tin cậy và quản lý rủi ro.