Hẳn ai đang học programming/lập trình cũng đều trải qua cảm giác này rồi nhỉ?
"Dù tuôi có học cũng không thể làm project được hiu hiu"
"Sắp bắt tay vào phát triển/develop/coding rồi giờ tuôi phải làm gì đây?"
"Định nghĩa yêu cầu là cái quái gì vậy?"
Để giải quyết được những phiền não đó, trước hết bạn phải lý giải được tổng quát về phát triển.
Các bạn hãy xem sơ đồ "ソフトウェア開発プロセス/Quá trình phát triển phần mềm".
※Từ vựng:
1. 企画: Kế hoạch
2. 業務設計: thiết kế nghiệp vụ
3. 要件定義: định nghĩa yêu cầu
4. 設計: Design
5. 実装: Coding (Programming)
6. テスト: Test
7. リリース: Release
8. 保守: Maintaince (bảo trì)
⇒Từ step 1 đến step 4 sẽ tổn tại nhiều bức tường/khó khăn trước khi bước vào giai đoạn coding.
Túm cái quần lại là sẽ tồn tại 4 bức tường trước khi bạn kịp phát huy năng lực/thực lực lập trình.
Vì vậy, trong blog này Mặt trời sẽ mô tả các trình tự liên quan đến step từ "Plan ~ Design" các bạn cùng xem nhé.
Đặc biệt, các anh Dev nhớ focus/tập trung lý giải phần "Định nghĩa yêu cầu" và "Design nhé".
À, các bạn nhớ chú ý rằng thường trong 1 dự án 50% tổng số sẽ được sử dụng cho giai đoạn đầu của dự án như là định nghĩa yêu cầu và design nhé.
① Mục đích của định nghĩa yêu cầu:
Có 2 loại người như sau tham gia vào phát triển hệ thống:
● Người "Tạo/Create" hệ thống (người phát triển)
● Người "Sử dụng/Use" hệ thống (người order)
Nếu anh muốn tự tạo cho mình một hệ thống mà anh muốn, thì chả có vấn đề gì vì anh đã có sẵn những hình dung/mường tượng hoàn chỉnh về hệ thống đó trong đầu rồi.
Nhưng cũng có nhiều trường hợp việc phát triển được thực hiện bằng cách yêu cầu theo kiểu "người order ⇒ người phát triển".
Khi đó, nếu không làm rõ/sáng tỏ những hình ảnh/hình dung trong đầu của người order thì người phát triển sẽ không biết mình sẽ phải làm cái gì.
Vì vậy mới tồn tại cái gọi là định nghĩa yêu cầu bểu thị cho mục đích tương thông tương ý nhau.
Lấy ví dụ thế này:
Khi bạn khác thì hẳn bạn sẽ yêu cầu người khác là "Mày mua cho tao cốc nước đi".
Đúng ra là "mua hộ tao cốc cà phê", và cụ thể hơn là "mua hộ tao cốc cà phê có đường. Loại ly nhựa chứ không phải dạng lon đâu nha".
Nếu bạn không hiển đạt theo ý như trên thì đối phương không thể nào mua cho bạn cốc cà phê được.
Việc phát triển hệ thống cũng y như vậy.
Mục đích của định nghĩa yêu cầu là thống nhất một cách rõ ràng cho việc "Tôi sẽ làm những gì để anh cảm thấy thỏa mãn/hài lòng?"
Túm lại,
Các bạn chỉ cần hiểu "Định nghĩa yêu cầu = Cam kết trước khi có thể xác nhận cụ thể là "Ồ mày làm như thế này là quá Ổn quá Okela rồi" tại thời điểm delivery. "
② Quá trình chốt định nghĩa yêu cầu:
Sau khi nắm được mục đích của định nghĩa yêu cầu, các bạn hãy cùng mình lý giải 3 step để hoàn thành định nghĩa yêu cầu.
❖ 3 tầng định nghĩa:
● 要望/Wish list: Những Idea/Ý tưởng/sáng kiến gọi là "Nếu có hệ thống như thế này thì tốt biết mấy"
● 要求/Request：List chức năng sơ bộ mà bạn muốn thực thi trong hệ thống
● 要件/Requirement: List chức năng cụ thể và phương pháp implement cụ thể mà 2 bên đã thỏa thuận
❖ Sự khác nhau giữa 3 tầng:
要望/Wish list: Nếu có hệ thống như thế này thì tốt biết mấy
↓
要求/Request：Tôi muốn coding những chức năng này
↓
要件/Requirement: Hãy coding chức năng này
Trong 3 giai đoạn này cần có Communication/giao tiếp thông qua "検討/xem xét" và "提案/đề xuất/suggest".
Mình sẽ sắp xếp theo trình tự như dưới đây:
1. 要望/Wish list: Vấn đề/Issue cần giải quyết (Task/nhiệm vụ của người order)
・Các issue hiện tại
・Mục tiêu/goal (trạng thái mong muốn)
・Khoảng cách/gap giữa Hiện tại và mục tiêu (Issue cần giải quyết)
2. 要求/Request：Chức năng muốn coding trong hệ thống ( Task/nhiệm vụ của người order)
・Bối cảnh/background của kế hoạch (issue cần giải quyết)
・Overview của hệ thống cần thiết cho việc resolve issues/giải quyết vấn đề
・List chức năng cụ thể mà bạn muốn coding
3. 検討/xem xét, điều tra: Suy nghĩ/cân nhắc về tính hiện thực của request (Task/nhiệm vụ của người order)
・Về mặt kỹ thuật có thể phát triển được không?
・Cần bao nhiêu Budget/dự toán?
・Thời điểm delivery/giao hàng là khi nào?
4. Đề xuất/Suggest: Trả kết quả điều tra về cho người order (Task của developer)
・Chức năng có thể coding
・Số tiền yêu cầu thanh toán
・Kỳ hạn/deadling có thể delivery/giao hàng
5. 要件/Requirement: Các mục mà 2 bên đã chốt deal (quyết định thỏa thuận giữa người order và nhà phát triển)
・List chức năng sẽ thực thi trong hệ thống
・Cũng có trường hợp sẽ mô tả deadline và số tiền thanh toán.
③ Các mục chốt/thỏa thuận trong định nghĩa yêu cầu:
Sau khi nắm bắt được flow thực hiện thì chúng ta sẽ sắp xếp sơ bộ các mục sẽ chốt/thảo thuận trong định nghĩa yêu cầu.
Mình sẽ sắp xếp theo kiểu 3W (Why, What, How)
❖ WHY: Mục đích của phát triển hệ thống (Wish list)
● Issue hiện tại
● Goal/mục tiêu (trạng thái mong muốn)
● Gap/khoảng cách giữa hiện tại và mục tiêu (issue cần giải quyết)
❖ WHAT: Làm thế nào để giải quyết vấn đề
● Flow nghiệp vụ sau khi đưa hệ thống vào sử dụng
● Yêu cầu chức năng/Requirement:
・List chức năng thực thi trong hệ thống
● Yêu cầu phi chức năng/Non-requirement:
・Các chức năng như là tốc độ xử lý, security/bảo mật
❖ HOW: Usability/tính tiện dụng đứng từ góc nhìn của user và phương pháp coding cụ thể (task cận tiệm với design system/thiết kế hệ thống)
● Basic design/thiết kế cơ bản (hay còn gọi là BD đóa):
・Design screen/thiết kết màn hình (design UI)
・Design function/thiết kế chức năng
・Design data/thiết kế data
● Detail design/thế kế chi tiết (hay còn gọi là DD đóa):
・Class diagrams, sequence diagrams (về định nghĩa của 2 cía này thì hỏi chị Google nhé)
・System architecture
・Các design như là công nghệ coding theo từng phần...
④ Cách làm Basic design (Design screen, design function, design data)
● Design screen (Design UI)
・Có thể làm gì/thao tác gì/có những actions gì ở mỗi màn hình?
・Thông tin hiển thị (như là text hay image) và layout
・Gom/tổng hợp những nội dung trên vào luồng di chuyển màn hình
● Design function
・Xử lý ở phía sau (ở phía Back-end đó quý dzị) (Tên chức năng và nội dung xử lý)
・Data cần cho việc xử lý và nguồn get data (ví dụ như Input trực tiếp từ màn hình hay get từ DB)
・Nguồn truyền/transfer data đã xử lý (ví dụ như hiển thị lên màn hình hay lưu vào DB..)
● Design data
・Nội dung cụ thể của data
・Design database
・Flow data (data flow chart)
Cùng mình đi tìm hiểu cụ thể về 3 mục phía trên bằng các sơ đồ dưới đây nhé
● Design screen (Design UI)
● Design function
(Tương tự cho các màn hình sau)
● Design data
● Sơ đồ ER
● Flow data
