May 17, 2012

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.

--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype:
vuhung16plus, twitter: vuhung, MSN: vuhung16.
http://www.facebook.com/nguyenvuhung
Nguyễn Vũ Hưng's blog on Free and Open Source:
http://nguyenvuhungvietnam.wordpress.com/
Học tiếng Nhật: http://hoc-tiengnhat.blogspot.com/
Vietnamese LibreOffice: http://libo-vi.blogspot.com/
Mozilla & Firefox tiếng Việt: http://mozilla-vi.blogspot.com/

Disclaimer: When posted to social networking groups include, but not
limited Linux Users' Groups,
Free and Open Sources forums, mailing lists, the above is my personal
opinion and is *not*
the opinion of my employer(s), associations and/or groups I join.

1 comment:

Anonymous said...

I take pleasure in, result in I found just what I was having a look for.
You have ended my four day lengthy hunt! God Bless you man.
Have a nice day. Bye

Also visit my page :: toys shop online