Qui trình phần mềm
Một sai lầm thông thường trong các sinh viên về phần mềm là ở chỗ phát triển phần mềm chỉ là lập trình. Khi họ nghĩ về lập trình, họ nghĩ tới các ngôn ngữ như C, C++, Java v.v. và chừng nào họ còn có thể viết mã trong các ngôn ngữ đó, họ có thể làm phần mềm. Thực ra, lập trình chỉ là một phần nhỏ của qui trình phát triển phần mềm. Có nhiều điều phải được thực hiện trước khi việc lập trình có thể xảy ra.
Qui trình của việc phát triển phần mềm bao gồm nhiều bước. Tổng của mọi bước được gọi là vòng đời phát triển phần mềm. Có nhiều vòng đời phát triển phần mềm như mô hình thác đổ, mô hình xoáy ốc, mô hình đưa ra tăng dần v.v. Tuy nhiên, tất cả các mô hình này đều bao gồm năm qui trình cơ bản tạo nên vòng đời phần mềm: Yêu cầu, Thiết kế, Thực hiện (viết mã), Tích hợp & kiểm thử, và Bảo trì.
Qui trình yêu cầu: Điển hình, tổ dự án nhận được đặc tả yêu cầu từ khách hàng. Tổ kiểm điểm, phân tích các yêu cầu này rồi gặp gỡ khách hàng để thảo luận và làm hợp thức các yêu cầu này. Người quản lí dự án và một số thành viên then chốt phải dùng một số kĩ thuật để đánh giá “nhu cầu thực” của khách hàng. Sai lầm thông thường trong các sinh viên là coi đặc tả yêu cầu là đủ tốt để bắt đầu dự án cho nên họ không học phân tích và thẩm tra các yêu cầu này. Thực ra, phần lớn các đặc tả yêu cầu do khách hàng viết đều không tốt. Phần lớn có nhiều yêu cầu xung đột hay thiếu và không biểu thị “nhu cầu thực” của khách hàng. Nhiều yêu cầu chỉ là “ước muốn” chứ không phải là “nhu cầu” và một số thậm chí đã áp đặt giải pháp cho người phát triển. Đó là lí do tại sao tổ dự án phải phân tích, kiểm điểm và làm hợp thức chúng với khách hàng trước khi dự án có thể bắt đầu. Nếu qui trình yêu cầu không được thực hiện đúng, phần mềm cuối cùng có thể không hữu dụng cho khách hàng hay không đáp ứng nhu cầu của họ.
Đặc tả yêu cầu được khách hàng viết thường phản ánh cái nhìn của người dùng. Tổ dự án phải phân tích và hiểu nhu cầu của người dùng, cách nó sẽ được dùng, và biến đổi chúng thành cái nhìn của người phát triển, nơi họ có thể thực hiện. Nếu yêu cầu không được xác định rõ vì khách hàng có thể không biết điều họ thực sự muốn, tổ dự án có thể phải dùng kĩ thuật như làm bản mẫu nhanh theo đó một “bản mẫu” đơn giản được xây dựng mô phỏng chức năng của phần mềm cuối cùng được mong đợi. Bằng việc dùng “bản mẫu” này để trình diễn cho khách hàng, tổ dự án có thể thảo luận chi tiết với khách hàng để hiểu các sản phẩm cuối cùng sẽ được dùng và xác định “yêu cầu thực”. Qui trình yêu cầu được hoàn tất khi bản đặc tả yêu cầu phần mềm được chuyển đầy đủ sang cách nhìn của người phát triển để cho tổ dự án có thể chuyển sang pha tiếp. (Lưu ý: Tổ dự án càng để nhiều nỗ lực vào qui trình này, các yêu cầu sẽ càng ít có khả năng thay đổi và cơ hội cho dự án phần mềm đạt tới sự thoả mãn của khách hàng là cao.)
Qui trình thiết kế: Trong qui trình này, tổ dự án quyết định “cách” họ sẽ xây dựng sản phẩm phần mềm để cho nó đáp ứng các đặc tả được chấp thuận. Thông thường qui trình thiết kế trải qua vài bước từ mức cao (kiến trúc) tới các mức thấp hơn (thiết kế chi tiết). Tại mức kiến trúc, các yêu cầu được tổ chức thành các kiểu hay cách nhìn khác nhau. Cách nhìn là biểu diễn của tập các cấu phần hệ thống và mối quan hệ giữa chúng. Đây là chỗ cấu phần phần cứng, cấu phần phần mềm và cấu phần giao diện được nhận diện và được tổ chức về cách chúng sẽ được thực hiện. Qui trình này được gọi là “làm mịn dần” (từng bước một) vì nó cho phép tổ dự án quản lí độ phức tạp của phần mềm. Bắt đầu ở mức cao tại tầng cấu phần, tổ dự án có thể phân rã chức năng thành các nhiệm vụ đặc biệt hơn ở câu lệnh ngôn ngữ lập trình. Khi thiết kế được hoàn tất, nó được ghi lại trong tài liệu đặc tả thiết kế. (Lưu ý: Tổ dự án càng để nhiều nỗ lực vào qui trình này, sản phẩm cuối cùng sẽ càng trở nên có chất lượng cao hơn và cấu trúc tốt hơn. Các thuộc tính nào đó như tính hiệu năng, tính đổi qui mô, tính bảo trì v.v được nhận diện trong qui trình thiết kế)
Qui trình thực hiện (viết mã): Trong qui trình này, tổ dự án bắt đầu viết mã của phần mềm dựa trên cấu phần thiết kế. Phần mềm được chia thành các đơn vị tách rời được gọi là mô đun để giải quyết độ phức tạp của qui trình lập trình. Tổ phải thực hiện những mô đun này tương ứng theo chuẩn và thủ tục viết mã. Thành viên tổ cũng chịu trách nhiệm cho làm tài liệu đúng mô tả cho mã của họ và cho kiểm thử mã để đảm bảo tính đúng đắn.
Thành viên tổ phải kiểm thử công việc riêng của họ để chắc chúng làm việc tốt (kiểm thử đơn vị) trước khi trao chúng cho qui trình tiếp. (Lưu ý: Qui trình này không yêu cầu nhiều nỗ lực nếu các qui trình trước đó được thực hiện đúng. Viết mã thường chỉ là thực hiện của thiết kế chi tiết. Nếu thiết kế được làm tốt, dự án không bao giờ có vấn đề với viết mã.)
Qui trình tích hợp & kiểm thử: Trong qui trình này, tổ dự án làm hợp thức và thẩm tra rằng phần mềm đáp ứng yêu cầu và làm việc như mong đợi. Vì các mô đun đã được phát triển tách biệt, kiểm thử là rất quan trọng để chắc rằng chúng tất cả đều cùng làm việc với nhau như đã lập kế hoạch. Ngay cả với thiết kế tốt, sự không tương hợp giữa các mô đun có thể xảy ra và chúng cần được nhận diện và sửa để làm đầy đủ việc tích hợp khi mọi mô đun riêng được tổ hợp để tạo nên sản phẩm phần mềm tích hợp. Có một số kiểm thử phải được thực hiện như kiểm thử chức năng, kiểm thử hệ thống, kiểm thử tích hợp, kiểm thử hiệu năng, kiểm thử an ninh v.v. (Lưu ý: Với dự án nhỏ, tổ dự án tiến hành tất cả những kiểm thử này. Với dự án lớn hơn, thường có tổ kiểm thử độc lập sẽ tiến hành các kiểm thử này. Mọi kiểm thử đều phải được lập kế hoạch, tổ chức và các trường hợp kiểm thử phải được kiểm điểm và chấp thuận trước khi việc kiểm thử có thể được thực hiện.)
Sau khi tất cả kiểm thử được hoàn tất thành công tổ dự án chuyển giao phần mềm cho khách hàng. Thường khách hàng sẽ tiến hành kiểm thử chấp nhận trên phần mềm để xác định liệu nó có đáp ứng đặc tả yêu cầu hay không, điều cả hai bên đã đồng khi trong qui trình yêu cầu. Nếu phần mềm được chấp nhận, nó được cài đặt và dùng bởi khách hàng.
Qui trình bảo trì: Phần lớn các sản phẩm phần mềm là không tĩnh tại mà sẽ thay đổi. Trong bảo trì, tổ dự án tiếp tục cung cấp hỗ trợ bằng việc sửa lỗi (nếu có), thêm chức năng mới, thay đổi phần mềm được dùng cho nền mới, hay thích nghi phần mềm với công nghệ mới. Mặc dầu nhiều sinh viên tin rằng dự án hoàn thành chuyển giao cho khách hàng, công việc tổ đáng phải xong, nhưng trong thực tế, mọi sản phẩm phần mềm đều tiến hoá qua thời gian để đáp ứng nhu cầu thay đổi của khách hàng. Bảo trì có lẽ là qui trình lâu nhất trong vòng đời phát triển phần mềm, nó có thể kéo dài vài năm sau khi phần mềm được chuyển giao cho khách hàng.
Nếu bạn hiểu qui trình phát triển phần mềm này, bạn có thể áp dụng nó cho bất kì mô hình nào như thác đổi, gia tăng hay xoáy ốc tuỳ theo kiểu dự án bạn đang dùng.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
