Giới thiệu các quy trình trong "
sổ tay phần mềm" (
STPM)
STPM-01QT - Phân tích xác định yêu cầu (*)
STPM-02QT - Thiết kế phần mềm (*)
STPM-03QT - Lập trình (*)
STPM-04QT - Kiểm tra phần mềm (*)
STPM-05QT - Triển khai phần mềm
STPM-06QT - Quản lý cấu hình
STPM-07QT - Xử lý yêu cầu phần mềm
STPM-08QT - Hỗ trợ khách hàng
Trong đó, mình thấy sát thực với các bạn là 4 quy trình đánh dấu (*) ở trên. Trong mỗi 1 quy trình thì có 1 số tài liệu cần phải xây dựng.
Ví dụ:
Quy trình "Phân tích xác định yêu cầu" thì có các tài liệu liên quan sau:
- Cán bộ phân tích hệ thống
- Mô tả hệ thống hiện tại
- Mô tả yêu cầu mức cao
- Đặc tả yêu cầu phần mềm (Software requirement Specification - SRS - là tài liệu mà h2h từng nhắc tới rất nhiều lần ở box "Dự án phần mềm")
- Đặc tả tình huống sử dụng (Usecase spec: Có 2 dạng: giản đơn và phức tạp)
- Kịch bản sử dụng (User Scenario)
Tương tự, quy trình "Thiết kế phần mềm" cũng có nhiều tài liệu như: Thiết kế tổng thể, thiết kế mức cao, xem xét thiết kế phần mềm (review), mô tả module (hay gọi là thiết kế chi tiết). Thông thường, với dân phần mềm thì các thiết kế mức cao và thiết kế chi tiết được xây dựng dựa trên ngôn ngữ UML và thường sử dụng các trình thiết kế như Rational Rose, v.v...
Quy trình "Lập trình" cũng vậy, sẽ có nhiều tài liệu là kết quả đầu ra của quy trình đó.
Dĩ nhiên, chúng ta chỉ lướt qua để "ngắm chơi" thôi chứ làm chuyên nghiệp thì mỗi tài liệu nói trên bao giờ cũng phải có hướng dẫn và biểu mẫu riêng chứ ko phải thích vẽ thế nào thì vẽ.
Bây giờ, mọi người có biết Database design nó nằm đâu trong mấy quy trình nói trên ko? (Dĩ nhiên là nó nằm ở quy trình thiết kế, nhưng ý là nằm trong loại tài liệu nào ấy?)
Sách vở thì chỉ chỉ các thủ thuật, cách làm. Tuy nhiên để định hướng mọi người (mới) cách hình dung về 1 cấu trúc Cơ sở dữ liệu như thế nào, quan hệ ra sao, tại sao lại như vậy mà không là khác .. . . . thì chẳng có sách nào nói đến.
Không có gì khác ngoài sách vở nói đâu, chẳng qua sách nói nhưng chưa hiểu vì cần phải làm thực tiễn nữa.
Trong thiết kế CSDL, mọi người chỉ cần xác định khi nào thì sử dụng quan hệ
Identifying Relationship và
Non-Identifying Relationship
Ví dụ:
Giả sử khi thiết kế hóa đơn (Invoice) thì ta có 1 vài quan hệ sau:
+ Relation giữa Customer với Invoice là Non-Identifying Relationship (Not Allow Null)
+ Relation giữa Invoice với Invoice_LineItem (chi tiết dòng chứng từ) là Identifying Relationship
+ Relation giữa InventoryItem với Invoice_LineItem (chi tiết dòng chứng từ) là Non-Identifying Relationship (Not Allow Null)
+ v.v...
Còn tại sao lại là như vậy thì ... phải hiểu nghiệp vụ.
Best Regards,
