Software/Sytems developments: What to check?

Setup:
– Bên A yêu cầu bên B phát triển một phần mềm/hệ thống
– Contractor (bên A) thực hiện basic design và chuyển cho contractee (bên B) – Bên B dựa trên basic design đó, viết detail design, coding (lập trình), thực hiện Unit test
– Bên A nhận lại detail design, code, unit test result để kiểm tra cũng như tiến hành integration test (step 1, được gọi là ITa)

Ghi chú: Trong “setup” không mô tả và cũng không đi quá chi tiết về những công việc được tiến hành nội bộ bởi bên B. Thực tế, tùy theo tình hình thực tế, bên B có thể tiến hành (hiểu theo nghĩa: làm bổ sung hoặc chi tiết hóa): Phân tích (tiền khả thi), thiết kế chương trình (program design), UML design (một số loại)… tùy thuộc vào tình hình dự án và thống nhất giữa hai bên A và B.

Mô hình phát triển:
Đây là mô hình waterfall điển hình, vẫn được áp dụng rộng rãi (Ghi chú cá nhân:…một cách máy móc trong những dự án lớn, dài, nghiệp vụ phức tạp với lý do rằng “chỉ waterwall mới cho CXO một cái nhìn sớm về CAPEX đầy đủ, ít rủi ro với dự án phát triển phần mềm/hệ thống”)

Bài toán:
Bên A (cũng như bên B) cần kiểm tra sản phẩm (theo thuật ngữ PMBOK: configuration) nào?

Hướng giải quyết:
Trong mô hình waterfall nói trên cũng như các software development life cycle (SDLC) khác, việc kiểm tra thực hiện ở đầu ra và đầu vào đối với từng công đoạn và từng bên giao nộp hoặc nhận sản phẩm (configuration) đó.

Trong tường hợp trên, bên A cũng như bên B cần kiểm tra basic design khi chuyển giao/giao nộp cho nhau. Có thể coi quá trình “kiểm tra” này là việc bên B review lại output (basic design) từ bên A, confirm lại những nghi vấn, yêu cầu bên A giải thích, viết rõ ràng hơn cho tới khi bên B cảm thấy thỏa mãn rằng basic design đó đủ để bên B tiến hành các bước tiếp theo: thực hiện detail design, coding và test.

Tiếp đó, bên A kiểm tra tương tự theo định hướng trên đối với detail design, code và unit test result cho tới khi bên A cho rằng các output đó đảm bảo đến bên A đủ thông tin, đầu vào để thực hiện tiếp công đoạn tiếp theo: integration test step 2 (ITb), system test/acception test (dưới quan điểm end-user), operation test.

Tiểu kết:
Nguyên lý kiểm tra trên áp dụng cho mọi công đoạn phát triển phần mềm cũng nhưng các công việc đã được định nghĩa rõ từng công đoạn trong tổng thể một quy trình (process) hay workflow.

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s