13 vấn đề chính trong công đoạn hạ nguồn của phát triển phần mềm

Trong phát triển phần mềm, công đoạn hạ nguồn đóng vai trò vô cùng quan trọng để đảm bảo chất lượng và độ tin cậy của sản phẩm phần mềm. Tuy nhiên, đây là một quy trình rất phức tạp và các nhà phát triển phải đối mặt với nhiều thách thức khác nhau. Bài viết này sẽ trình bày 13 vấn đề chính mà các nhà phát triển gặp phải trong công đoạn hạ nguồn.

1. Công đoạn hạ nguồn là gì

1.1. Công đoạn hạ nguồn là gì

Thuật ngữ “công đoạn hạ nguồn” chỉ giai đoạn phát triển, kiểm thử và triển khai hệ thống. Thuật ngữ này bắt nguồn từ mô hình phát triển phần mềm “waterfall” (mô hình thác nước), thể hiện quy trình phát triển tiến từ thượng nguồn xuống hạ nguồn giống như dòng thác đổ.

Mô hình thác nước là mô hình thể hiện quy trình phát triển hệ thống, phần mềm. Theo mô hình này, khi triển khai dự án, các công đoạn như định nghĩa yêu cầu, thiết kế, xây dựng, kiểm thử... cần được hoàn thành tuần tự từ đầu đến cuối. Ví von với dòng chảy của con sông, nửa đầu được gọi là công đoạn thượng nguồn, nửa sau được gọi là công đoạn hạ nguồn.

Vì vậy, công đoạn hạ nguồn là nửa sau của kế hoạch dự án: dựa trên tài liệu thiết kế và đặc tả kỹ thuật đã được xác định ở công đoạn thượng nguồn, đây là giai đoạn triển khai thực tế chương trình, hệ thống, phần mềm, tiến hành kiểm thử, đưa vào vận hành tại hiện trường, và bao gồm cả các công đoạn sau khi hoàn thành.

1.2. Các quy trình nằm trong công đoạn hạ nguồn

Công đoạn hạ nguồn bao gồm 3 quy trình: triển khai (lập trình), kiểm thử và đưa vào vận hành - bảo trì, mỗi quy trình được định nghĩa như sau.

• Quy trình “triển khai (lập trình)”: quy trình phát triển dựa trên các chức năng và ngôn ngữ lập trình đã được chỉ định.
• Quy trình “kiểm thử”: quy trình xác minh rằng các chức năng đã hoàn thành hoạt động bình thường và phản hồi đúng như mong đợi.
• Quy trình “deploy”: quy trình xác nhận hệ thống hoạt động thực tế tại môi trường của khách hàng, trước khi phát hành lên môi trường production.

Trong công đoạn hạ nguồn, nội dung đã được xác định ở công đoạn thượng nguồn sẽ được hiện thực hóa, đồng thời kiểm thử xem các chức năng có hoạt động đúng hay không. Do đó, càng tiến sâu về hạ nguồn thì việc thay đổi chức năng càng trở nên khó khăn. Việc thay đổi chức năng hoặc cấu hình ở giai đoạn hạ nguồn có thể gây ra vấn đề về tính nhất quán, dẫn đến khả năng không cung cấp được chức năng mà khách hàng cần.

2. 13 vấn đề chính trong công đoạn hạ nguồn

2.1 Vấn đề trong quá trình phát triển

2.1.1 Làm lại (rework)

Ngoài nguyên nhân gốc rễ là “chưa thu thập đầy đủ yêu cầu từ khách hàng”, xu hướng phát sinh sự cố ở công đoạn hạ nguồn trong phát triển hệ thống thường bắt nguồn từ việc xem nhẹ công đoạn thượng nguồn. Trong trường hợp xấu nhất, đội phát triển buộc phải làm lại từ đầu, dẫn đến nguy cơ lớn là không kịp thời hạn giao hàng.

Vấn đề phổ biến nhất trong công đoạn hạ nguồn là việc phải làm lại do định nghĩa yêu cầu ở công đoạn thượng nguồn chưa đầy đủ. Ở giai đoạn định nghĩa yêu cầu, điều quan trọng là phải hiểu rõ yêu cầu của khách hàng và đảm bảo không có thiếu sót hay mâu thuẫn.

Vì vậy, nếu không trao đổi tìm hiểu đầy đủ với khách hàng ở công đoạn thượng nguồn, có thể dẫn đến lệch pha nhận thức hoặc xung đột với khách hàng, khiến chức năng cần bổ sung ở hạ nguồn tăng quá nhiều, thậm chí phải làm lại toàn bộ dự án - phát sinh thêm chi phí, công sức, vượt ngân sách và chậm tiến độ.

Những sai lầm khác ở công đoạn thượng nguồn bao gồm việc định giá quá thấp, không lắng nghe đầy đủ yêu cầu của khách hàng trước khi đưa ra các lựa chọn phù hợp - những điều này có thể dẫn đến rắc rối với khách hàng và khối lượng làm lại lớn ở công đoạn hạ nguồn. Ngoài ra còn có nguy cơ dự án đi chệch khỏi hệ thống đã được lên kế hoạch ban đầu đến mức không thể sửa chữa được.

2.1.2. Bỏ sót yêu cầu của khách hàng

Ngoài ra, cũng có trường hợp phía nhà phát triển bỏ qua yêu cầu của khách hàng, dẫn đến dự án không hoàn thành đúng như yêu cầu hoặc kế hoạch bị trì hoãn. Do đó, không chỉ ở công đoạn hạ nguồn mà xuyên suốt dự án, việc trao đổi tìm hiểu và rà soát đầy đủ với khách hàng vẫn luôn quan trọng, nhằm tránh những tình huống không mong muốn xảy ra gần thời điểm hoàn thành dự án.

Để tránh tình huống này, việc trao đổi tìm hiểu đầy đủ với khách hàng vẫn luôn là điều quan trọng.

2.1.3. Giao tiếp giữa các nhóm

Giao tiếp là yếu tố quan trọng trong phát triển phần mềm, đặc biệt trong ngành công nghệ thông tin, nơi không phải lập trình viên hay kỹ sư nào cũng có sẵn khả năng giao tiếp tốt. Để tránh chậm tiến độ, vượt chi phí và các vấn đề khác, giao tiếp hiệu quả là điều không thể thiếu.

Giải pháp là tổ chức các buổi họp định kỳ, brainstorming hoặc giao tiếp qua nền tảng web, giúp mọi thành viên trong nhóm dễ dàng kết nối và tiếp cận thông tin. Cần lưu ý rằng tất cả các nhóm chỉ nên sử dụng chung một bản ghi chú họp thống nhất để tránh thông tin sai lệch. Giao tiếp hiệu quả giúp giảm đáng kể các lỗi tiềm ẩn, đồng thời giúp dự án được giao đúng thời hạn.

2.2. Vấn đề trong quy trình kiểm thử

2.2.1. Tiêu chuẩn chất lượng chưa được xác định

Để người kiểm thử có thể đặt ra kỳ vọng về chất lượng của sản phẩm đang phát triển, tiêu chuẩn chất lượng được xác định rõ ràng là điều không thể thiếu. Tuy nhiên, tiêu chuẩn chất lượng thường không được xác định hoặc được xác định chưa đầy đủ, khiến việc kiểm thử trở nên vô cùng khó khăn. Khi không có tiêu chuẩn phù hợp, người kiểm thử sẽ rất khó đáp ứng nhu cầu của khách hàng, đáp ứng yêu cầu chất lượng hoặc tuân thủ các quy định liên quan.

2.2.2. Sao chép môi trường kiểm thử

Để phát hiện và khắc phục các vấn đề có thể ảnh hưởng đến trải nghiệm người dùng cuối, việc kiểm thử sản phẩm phần mềm trong môi trường thực tế là rất quan trọng. Tuy nhiên, phần lớn các nhóm chỉ giới hạn kiểm thử trong một số ít trường hợp, do đó không phản ánh đúng những thách thức mà sản phẩm có thể gặp phải trong thực tế.

2.2.3. Thiếu giao tiếp

Người kiểm thử thường làm việc một cách độc lập, điều này có thể dẫn đến thiếu giao tiếp, hiểu lầm và chậm trễ. Giao tiếp cởi mở và liên tục là nền tảng của một quy trình kiểm thử phần mềm tốt. Đầu tư vào các công cụ cộng tác theo thời gian thực giúp các nhóm dễ dàng liên lạc với nhau và cập nhật thông tin mới nhất về dự án.

2.2.4. Môi trường không ổn định

Môi trường kiểm thử không ổn định có thể làm gián đoạn toàn bộ quy trình phát hành, gây xung đột và chậm tiến độ, đồng thời ảnh hưởng đến chất lượng, tính khả dụng và hiệu quả của việc kiểm thử. Để giải quyết vấn đề môi trường không ổn định, điều quan trọng là phải chính thức hóa các yêu cầu về môi trường kiểm thử ngay từ giai đoạn đầu của vòng đời kiểm thử, sử dụng mẫu chính thức để nắm bắt yêu cầu kịp thời, phân bổ nguồn lực phù hợp và chuẩn bị hạ tầng cần thiết để xây dựng môi trường mới.

2.2.5. Thu thập yêu cầu chưa đầy đủ

Việc thu thập yêu cầu chưa đầy đủ có thể khiến chức năng bị thiếu sót, hoặc khiến các yêu cầu mới bị phát hiện muộn ở giai đoạn sau của vòng đời phát triển. Điều này tạo áp lực lớn lên tiến độ dự án và có thể buộc người kiểm thử phải bỏ qua một số trường hợp kiểm thử để tiết kiệm thời gian. Dành đủ thời gian cho việc thu thập yêu cầu là điều thiết yếu để nhóm hiểu rõ những chức năng sản phẩm cần có và mức độ chức năng được kỳ vọng.

2.3 Vấn đề trong quá trình phát hành và bảo trì

Bảo trì phần mềm là quy trình cập nhật và điều chỉnh phần mềm để tiếp tục đáp ứng nhu cầu người dùng và sửa các lỗi được phát hiện. Vì phần mềm luôn thay đổi và phát triển không ngừng, đây là một phần quan trọng trong vòng đời phát triển phần mềm.

Tuy nhiên, có một số thách thức khiến việc bảo trì phần mềm trở nên khó khăn và tốn thời gian. Các thách thức này bao gồm:

2.3.1 Sự cố do khách hàng gây ra sau khi đưa vào vận hành

Những vấn đề ngoài dự kiến có thể phát sinh khi khách hàng thực hiện các thao tác mà nhà phát triển không thể lường trước. Tuy nhiên, trong phần lớn trường hợp, nguyên nhân là do việc trao đổi tìm hiểu ở công đoạn thượng nguồn chưa đầy đủ.

2.3.2 Không xác định được nguyên nhân gốc rễ của vấn đề

Mã nguồn thường không thể truy ngược lại yêu cầu hay đặc tả thiết kế ban đầu, khiến lập trình viên khó hiểu được mục đích của đoạn mã và khó xác định nguyên nhân gốc rễ của vấn đề.

2.3.3 Thiếu chú thích trong mã nguồn

Nhiều hệ thống phần mềm không có đủ chú thích trong mã nguồn, khiến lập trình viên gặp khó khăn khi tìm hiểu mã nguồn và thực hiện thay đổi.

2.3.4 Hệ thống legacy đã lỗi thời

Nhiều hệ thống legacy vẫn đang được sử dụng nhưng không được thiết kế với mục tiêu dễ bảo trì. Điều này khiến việc bảo trì trở nên khó khăn và tốn kém.

2.3.5 Lựa chọn sai framework

Loại framework được sử dụng để phát triển phần mềm có thể gây ra vấn đề cho việc bảo trì phần mềm trong tương lai. Quyết định sai khi lựa chọn framework có thể khiến công ty phần mềm không thể tìm được đủ hỗ trợ hoặc nguồn lực có chuyên môn để bảo trì phần mềm.

Để vượt qua những thách thức này, điều quan trọng là phải xây dựng một quy trình bảo trì phần mềm được định nghĩa rõ ràng.

3. Tổng kết

Công đoạn hạ nguồn là yếu tố không thể thiếu để dự án phát triển phần mềm thành công. Tuy nhiên, quá trình này có thể đi kèm với nhiều thách thức như làm lại, bỏ sót yêu cầu của khách hàng, tiêu chuẩn chất lượng chưa được xác định, thiếu khả năng truy vết mã nguồn, hoặc lựa chọn sai loại framework.

Nhận diện và có biện pháp giảm thiểu các thách thức này giúp nhà phát triển nâng cao hiệu quả, chất lượng của công đoạn hạ nguồn.

Miichisoft là công ty công nghệ Việt Nam sở hữu nhiều dự án phát triển đa nền tảng thành công cho khách hàng Nhật Bản. Chúng tôi tự tin vào năng lực dẫn dắt các dự án CNTT và tự hào có thể đóng góp vào thành công trong hoạt động kinh doanh của khách hàng. Với hơn 150 dự án thành công, chúng tôi đã tích lũy được thành tích đáng tin cậy. Nếu quý khách quan tâm đến phát triển hệ thống, hãy liên hệ với chúng tôi để cùng nhau tìm hiểu cơ hội hợp tác kinh doanh.