Visual Paradigm Desktop | 
Visual Paradigm Online
Trong phát triển phần mềm, những lỗi tốn kém nhất không nằm trong mã nguồn. Chúng nằm ở các yêu cầu. Khi một đội phát triển xây dựng một tính năng dựa trên mô tả mơ hồ, kết quả thường là phải làm lại. Việc làm lại này tiêu tốn thời gian, ngân sách và tinh thần làm việc. Một tài liệu yêu cầu được cấu trúc tốt có thể hoạt động như một lá chắn chống lại những chi phí này. Trong nghiên cứu trường hợp này, chúng tôi xem xét cách một kỹ thuật mô hình hóa trực quan đã phát hiện ra một khiếm khuyết nghiêm trọng trong phạm vi dự án trước khi một dòng mã nào được viết ra.
Dự án liên quan đến một nền tảng hậu cần được thiết kế để kết nối các nhà điều hành kho với các tài xế giao hàng. Yêu cầu ban đầu rất đơn giản: xây dựng một module để quản lý việc giao nhận gói hàng. Đội ngũ đã giả định quy trình làm việc là tuyến tính. Tuy nhiên, việc giới thiệu sơ đồ trường hợp đã tiết lộ những trường hợp đặc biệt phức tạp mà bản tóm tắt bằng lời ban đầu hoàn toàn bỏ qua. Lần can thiệp trực quan đơn giản này đã giúp tổ chức tránh được một cuộc cải tổ kiến trúc lớn trong giai đoạn sau của vòng đời dự án.
Khách hàng là một công ty chuỗi cung ứng quy mô trung bình đang mở rộng cơ sở hạ tầng số hóa của mình. Họ đang chuyển từ việc theo dõi thủ công sang hệ thống tự động hóa hoàn toàn. Mục tiêu chính là giảm thời gian giữa lúc gói hàng đến trung tâm và việc giao nó cho tài xế. Nhóm bên liên quan bao gồm các quản lý vận hành, giám sát viên kho và các nhà phát triển cấp cao.
Các cuộc họp ban đầu tập trung vào “đường đi lý tưởng”. Đây là tình huống lý tưởng khi mọi thứ diễn ra đúng như kế hoạch. Các bên liên quan mô tả quy trình mà tại đó một tài xế đến, quét mã vạch và hệ thống xác nhận việc giao nhận. Mọi người gật đầu. Dự án được thông qua. Đội ngũ phát triển bắt đầu thiết lập sơ đồ cơ sở dữ liệu và các điểm cuối API.
Tuy nhiên, hoạt động thực tế hiếm khi diễn ra theo tuyến tính. Hậu cần thực tế bao gồm các sự gián đoạn, lỗi và ngoại lệ. Không có mô hình trực quan chính thức để kiểm tra tính bền vững của yêu cầu, đội ngũ tiếp tục với giả định rằng hệ thống chỉ xử lý các tương tác tiêu chuẩn. Chính giả định này là nơi rủi ro bắt đầu.
Sơ đồ trường hợp là một cái nhìn hành vi về hệ thống. Nó minh họa các tương tác giữa các tác nhân bên ngoài và chính hệ thống. Nó không hiển thị logic nội bộ hay cấu trúc mã nguồn. Thay vào đó, nó tập trung vào ‘ai’ và ‘cái gì’.
Các thành phần chính bao gồm:
Việc tạo ra sơ đồ này buộc đội ngũ phải nêu rõ ranh giới của hệ thống. Nó biến những giả định ngầm thành rõ ràng. Nếu một bên liên quan đề cập đến một quy trình không phù hợp với sơ đồ, điều đó cho thấy có khoảng trống trong yêu cầu.
Trước khi sơ đồ được vẽ, phạm vi được xác định bởi một tài liệu liệt kê các tính năng cấp cao. Đội ngũ cho rằng phạm vi nằm trong module ‘Giao nhận’. Các giả định bao gồm:
Những giả định này phổ biến trong các giai đoạn lập kế hoạch ban đầu. Chúng cho phép đội ngũ bắt đầu công việc nhanh chóng. Tuy nhiên, chúng rất mong manh. Khi thực tế của môi trường kho hàng được đưa vào, những giả định này đã thất bại.
Các bên liên quan không nêu rõ các ngoại lệ. Họ cho rằng hệ thống sẽ xử lý chúng một cách tự động. Việc thiếu mô hình trực quan có nghĩa là không ai đặt câu hỏi về tính đầy đủ của luồng cho đến khi quá muộn.
Trưởng dự án yêu cầu một cuộc xem xét chính thức các yêu cầu bằng cách sử dụng mô hình trực quan. Bước này không nằm trong lịch trình ban đầu nhưng được đưa vào để xác nhận kiến trúc. Đội ngũ đã tập hợp các giám sát viên kho để vẽ sơ đồ trên bảng trắng.
Phiên họp này đã thay đổi động lực của dự án. Thay vì thảo luận về các tính năng trừu tượng, mọi người đều nhìn vào một bản đồ cụ thể về luồng công việc. Sơ đồ được xây dựng theo từng bước lặp:
Khi sơ đồ phát triển, mức độ phức tạp trở nên rõ ràng. Bảng trắng không còn là một đường đơn giản. Nó phân nhánh thành nhiều con đường. Bằng chứng trực quan này là không thể chối cãi.
Trong buổi mô hình hóa, một tương tác cụ thể đã bị ghi nhận là đã bị bỏ qua. Trường hợp sử dụng ‘Quét gói hàng’ được kết nối với trường hợp sử dụng ‘Báo cáo hư hỏng’ thông qua mối quan hệ ‘Mở rộng’. Điều này có nghĩa là nếu tài xế quét một gói hàng, họ có thể lựa chọn báo cáo hư hỏng.
Sơ đồ tiết lộ một mối phụ thuộc không nằm trong phạm vi ban đầu. Để hỗ trợ ‘Báo cáo hư hỏng’, hệ thống cần thu thập hình ảnh, tọa độ GPS và thời điểm ghi lại. Nó cũng cần thông báo ngay lập tức cho trưởng kho.
Ban đầu, nhóm cho rằng đây chỉ là một tính năng phụ nhỏ. Sơ đồ cho thấy tính năng này đòi hỏi một cấu trúc dữ liệu hoàn toàn khác biệt. Cơ sở dữ liệu ban đầu được thiết kế cho các cập nhật trạng thái đơn giản. Nó không hỗ trợ đính kèm phương tiện hoặc thông báo thời gian thực.
Hơn nữa, sơ đồ làm nổi bật mâu thuẫn giữa tác nhân ‘Tài xế’ và tác nhân ‘Trưởng kho’. Tài xế cần tải dữ liệu lên khi không kết nối mạng, nhưng trưởng kho cần xem dữ liệu trực tuyến. Điều này ngụ ý cần có bộ nhớ cục bộ và logic đồng bộ hóa, vốn không nằm trong kế hoạch ban đầu.
Nếu không có sơ đồ, phát hiện này có thể đã xảy ra trong giai đoạn kiểm thử. Vào thời điểm đó, việc thay đổi cấu trúc cơ sở dữ liệu sẽ tốn kém. Nhờ có sơ đồ, nhóm đã phát hiện vấn đề trong giai đoạn thiết kế.
Ngay sau khi phát hiện khoảng trống, kiến trúc đã được điều chỉnh. Nhóm quyết định chia mô-đun thành hai thành phần riêng biệt:
Việc tách biệt các nhiệm vụ này đã đơn giản hóa mô-đun chính. Nó có thể duy trì nhẹ nhàng và nhanh chóng. Mô-đun ngoại lệ có thể phức tạp hơn mà không làm chậm luồng công việc chính.
Sơ đồ cũng làm rõ quyền hạn. Trường hợp sử dụng ‘Báo cáo hư hỏng’ được mở rộng để bao gồm bước ‘Phê duyệt của Quản lý’. Điều này thêm một lớp bảo mật mà trước đó chưa có. Mô hình trực quan cho thấy không phải mọi báo cáo hư hỏng nào cũng giống nhau. Một số cần can thiệp ngay lập tức, trong khi những cái khác có thể được ghi lại để xem xét sau.
Tác động của hoạt động mô hình hóa trực quan này là có thể đo lường được. Bằng cách xác định yêu cầu sớm, dự án đã tránh được việc phải thay đổi lớn sau khi phát triển đã bắt đầu. Bảng dưới đây tóm tắt sự khác biệt giữa tình huống ‘Không có sơ đồ’ và ‘Có sơ đồ’.
| Chỉ số | Không có mô hình trực quan | Có mô hình trực quan |
|---|---|---|
| Phát hiện khuyết điểm nghiêm trọng | Sau phát triển (giai đoạn kiểm thử) | Tiền phát triển (Giai đoạn thiết kế) |
| Yêu cầu tái cấu trúc cơ sở dữ liệu | Có (Chi phí cao) | Không (Đã lên kế hoạch từ đầu) |
| Ảnh hưởng đến tiến độ dự án | Điều chỉnh chậm lại 4 tuần | Đúng tiến độ |
| Mức độ tin tưởng của các bên liên quan | Thấp (Không chắc chắn) | Cao (Xác nhận trực quan) |
| Nỗ lực phát triển | 120% so với ước tính | 100% so với ước tính |
Chi phí thay đổi một yêu cầu trong giai đoạn thiết kế là thấp hơn đáng kể so với giai đoạn lập trình. Biểu đồ đã giúp đội ngũ tính toán chính xác nỗ lực phát triển. Họ biết rõ chính xác mình đang xây dựng điều gì trước khi bắt đầu.
Để tái hiện thành công này, các đội nhóm nên tuân theo các hướng dẫn cụ thể khi tạo sơ đồ trường hợp sử dụng. Những thực hành này đảm bảo mô hình có ích và không chỉ là hình thức.
Sử dụng những thực hành này ngăn biểu đồ trở nên lỗi thời hoặc không còn liên quan. Nó đảm bảo mô hình luôn là công cụ hữu ích trong suốt vòng đời dự án.
Ngay cả với những ý định tốt, các đội nhóm vẫn có thể mắc sai lầm khi mô hình hóa yêu cầu. Những sai lầm này có thể dẫn đến sự nhầm lẫn thay vì rõ ràng.
Tránh những sai lầm này đảm bảo sơ đồ đạt được mục đích của nó. Nó trở thành công cụ giao tiếp, chứ không phải ràng buộc kỹ thuật.
Nghiên cứu trường hợp cho thấy mô hình hóa trực quan không chỉ là một bước thủ tục. Đó là một tài sản chiến lược. Sơ đồ use case đã đóng vai trò như một bộ lọc cho các yêu cầu. Nó phát hiện được những lỗi mà các tài liệu văn bản bỏ sót.
Với các quản lý dự án và nhà phát triển, bài học là rõ ràng. Đừng chỉ dựa vào mô tả văn bản. Sử dụng hình ảnh để cầu nối khoảng cách giữa nhu cầu kinh doanh và triển khai kỹ thuật. Khi yêu cầu rõ ràng, mã nguồn dễ viết hơn. Khi mã nguồn dễ viết hơn, sản phẩm có chất lượng cao hơn.
Sự đầu tư vào việc tạo ra một sơ đồ đơn giản đã mang lại lợi ích gấp nhiều lần. Nó ngăn chặn việc phải thay đổi lớn tính năng. Nó giúp dự án duy trì tiến độ. Nó đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu thực tế của người dùng.
Trong tương lai, tổ chức này dự định đưa mô hình hóa use case thành bước bắt buộc cho mọi yêu cầu tính năng quan trọng. Chi phí cho buổi mô hình hóa chỉ bằng một phần nhỏ chi phí sửa chữa. Lợi ích đầu tư là rõ ràng.
Bằng cách ưu tiên sự rõ ràng hơn tốc độ ở giai đoạn đầu, các đội nhóm có thể đạt được tốc độ và chất lượng ở giai đoạn sau. Con đường dẫn đến một dự án thành công được lát bằng các yêu cầu rõ ràng. Sơ đồ use case là bản đồ đáng tin cậy cho hành trình này.
Sự khác biệt giữa một dự án thành công và một dự án gặp khó khăn thường phụ thuộc vào việc các yêu cầu được hiểu rõ đến mức nào. Một sơ đồ đơn giản có thể tạo nên sự khác biệt lớn.