Thân chào các Bê (*),
Hôm nay xin viết nhăng về một đề tài có tính chuyên môn trong công nghệ viết phần mềm (software development). "Theo thời gian trong quy trình phát triển phần mềm" thật ra chỉ là theo những công đoạn (những bước) trong quy trình phát triển software.
Có nhiều quy trình phát triển software khác nhau (waterfall, agile, v-shaped, interative, incremental, etc...) nhưng tựu chung thì vẫn là qua quá trình từ nhu cầu/yêu cầu (requirements), tới thiết kế (design), tới viết code (development), tới thử nghiệm (testing), tới cài đặt (deployment/installation) và tới bảo trì (maintenance, bảo hành, bảo dưỡng hay nôm na là sửa lỗi) (xin xem hình trong phụ chú E).
Dạ, dạ Đệ xin vào đề...
Bài này mục đích là vạch ra một chân lý ngàn đời: phát hiện lỗi (bugs) ở giai đoạn sau, thí dụ như ở giai đoạn design, thì sẽ rất tốn kém so với phát hiện lỗi ở giai đoạn trước, thí dụ như ở giai đoạn viết requirements (nên nhớ là viết ra giấy và hoàn thiện requirements phải được duyệt đi duyệt lại và phải được phê chuẩn (approved) bởi cấp thẩm quyền độc lập với các nhóm phát triển software (software development teams).
Dạ, dạ Đệ xin vào đề...
Bài này mục đích là vạch ra một chân lý ngàn đời: phát hiện lỗi (bugs) ở giai đoạn sau, thí dụ như ở giai đoạn design, thì sẽ rất tốn kém so với phát hiện lỗi ở giai đoạn trước, thí dụ như ở giai đoạn viết requirements (nên nhớ là viết ra giấy và hoàn thiện requirements phải được duyệt đi duyệt lại và phải được phê chuẩn (approved) bởi cấp thẩm quyền độc lập với các nhóm phát triển software (software development teams).
"Tay mơ" sẽ nói: "Có code xong và thử thì mới phát hiện lỗi chứ?" Thật sự thì theo chân lý trên thì giai đoạn nào cũng có thể có lỗi. Sửa càng sớm càng dễ và ít tốn kém. Xin lấy thí dụ có người khách đến tiệm bánh và đặt một chiếc bánh cưới. Requirements ở đây là: kích thước bánh, hình dạng bánh, các màu và lối phối màu (bánh màu kem, hoa màu như hoa thật, hoa gì, lá màu xanh, trong bánh có kem không, bánh mấy lớp, bao giờ giao bánh, có phải chở tới nhà hàng không, etc...). Tất cả các requirements phải được sự đồng ý của hai bên (khách hàng và tiệm bánh). Khi hai bên thương thảo thì cũng là lúc tiệm bánh có thể yêu cầu sửa đổi requirements (thí dụ khách muốn kem với dâu tươi mà đang không phải mùa dâu). Requirements sau nhiều lần thương thảo thì hai bên phải đồng phê chuẩn.
Đó! Nếu có lỗi ở giai đoạn requirements thì sửa khá dễ, khá nhanh vì chỉ cần hai bên đồng ý với requirement mới (thí dụ như dùng dâu đông lạnh). Nhưng nếu vì sơ xuất mà tiệm bánh không tim ra dâu tươi mà thế đại bằng dâu đông lạnh thì có thể bị thưa kiện vì không làm đúng thỏa thuận (lỗi này khá là khó sửa).
Chân lý trên nói là sửa lỗi ở giai đoạn sau phải trả giá tăng theo cấp số nhân (thí dụ sửa lỗi ở requirements là $10 (giá của số giờ thương thảo) thì nếu để tới giai đoạn giao cho khách hàng (deployment) thì phải đổi từ dâu đông lạnh sang dâu tươi thì chỉ có hai cách:
- hoặc cho không khách hàng cái bánh với dâu đông lạnh và đền thêm một số tiền (giá của cách này có thể là $(10 x 10 x 10 x 10 x 10) = $10,000 + tiền đền + mất tiếng tăm tiệm bánh;
- hoặc cho người bay qua nước nào có dâu tươi, mua và mang về bằng chuyên cơ hỏa tốc và làm lại chiếc bánh với việc tăng số thợ làm bánh và tăng giờ phụ trội!
Tất cả những điều nói trên. trong thập niên 2000's, bị một hãng software của Mỹ đã phá và hãng này đưa ra một luận cứ mới: cứ đưa sản phẩm ra thị trường sớm và nếu người tiêu thụ tìm ra lỗi thì sửa sau (beta test by real customers).
Phụ chú F nói về việc IBM sáng tạo ra khái niệm Alpha Testing và Beta Testing (nhưng beta testing theo IBM là giao cho một nhóm nhỏ khách hàng tự nguyện thử nghiệm sản phẩm mới). Phải đến 2004 thì Google công khai giao GMail, được ghi rõ là bản Beta, cho khách hàng dùng. Từ đó, lịch sử đã sang trang...
Chúc các Bê một cuối tuần vui vẻ bên gia đình và người thân.
Thân,
Chú thích:
(*) Bê là Bê 60: Từ chữ tắt B60 (Beyond 60 years young) để chỉ các bác trên 60 tuổi trẻ. Tuổi Bê thì Life is short. Don't make it shorter!
Phụ chú:
A. Blogs Đã Viết--Theo Đề Tài
B. The exponential cost of fixing bugs
C. SDLC Models