Qui trình phát triển phần mềm
Nhiều sinh viên được đào tạo tốt trong viết mã vì đa số thời gian của họ ở đại học tập trung vào viết mã nhưng ít tập trung vào qui trình phát triển phần mềm. Một số sinh viên coi phát triển phần mềm là công việc cá nhân vì họ thường nhận được phân công cá nhân điều mỗi người phải làm và phần lớn nhiệm vụ được phân là về viết mã. Khi họ đi làm nhiều người có xu hướng bắt đầu viết mã ngay lập tức sau khi nhận được phân công mà không hiểu đầy đủ vấn đề. Vì yêu cầu thường xuyên thay đổi và họ phải sửa mã của mình, họ thường phạm sai lầm cần sửa. Chúng càng được sửa, mã của họ càng trở nên phức tạp hơn. Cuối cùng, sẽ quá khó không thể hiểu nổi cấu trúc mã của họ và logic của họ cho kiểm thử hay bảo trì. Nếu người phát triển chỉ viết mã và sửa bất kì cái gì họ muốn thì sẽ khó mà tích hợp mã của họ vào một sản phẩm phần mềm cố kết.
Khi sinh viên được đào tạo về qui trình phát triển phần mềm, họ hiểu rằng phát triển không chỉ là viết mã mà nó là nỗ lực tổ. Trước khi bắt đầu, tổ phải có hiểu biết chung về vấn đề mà họ phải giải quyết, mục đích dự án, hoạt động dự án nơi từng thành viên tổ có vai trò và trách nhiệm nào đó cho công việc. Qui trình phần mềm là bản lộ trình chỉ ra cho tổ cách phát triển phần mềm từ mức cao tới mức chi tiết. Có một trật tự trình tự được gọi là vòng đời phát triển nơi toàn thể qui trình được phân chia thành vài pha và từng pha có vai trò, trách nhiệm nào đó cho các thành viên tổ.
Qui trình phần mềm bắt đầu bằng việc hiểu vấn đề qua việc thẩm tra các yêu cầu với khách hàng. Bởi vì khách hàng thường không mô tả nhu cầu của họ rõ ràng và thường đổi ý của họ, tổ phải chắc điều khách hàng đã đòi hỏi là điều họ cần. Chỉ khi các yêu cầu này được thảo luận và xác nhận, tổ mới bắt đầu làm tài liệu chúng thành đặc tả yêu cầu phần mềm. Bằng việc tuân theo qui trình, tổ hiểu rằng nguyên nhân thông thường nhất của thất bại dự án là các yêu cầu không ổn định hay xác định kém và bằng việc có các yêu cầu được kiểm nghiệm đầy đủ họ có thể giảm bớt rủi ro của yêu cầu thay đổi. Sau khi khách hàng đã chấp nhận tài liệu yêu cầu, tổ bắt đầu thảo luận riêng của họ để chắc rằng mọi thành viên của tổ hiểu vấn đề đủ rõ trước khi họ chia dự án thành những nhiệm vụ nhỏ hơn mà họ phải làm.
Bằng việc tuân theo qui trình phần mềm, tổ xác định kiến trúc của hệ thống qua nhiều cấu phần. Các thành viên tổ nhận diện giao diện giữa các cấu phần này và thế rồi thẩm tra rằng mọi cấu phần có thể được dõi vết trở lại các yêu cầu để cho sản phẩm sẽ đáp ứng nhu cầu của khách hàng. Điều này là quan trọng bởi vì bất kì lỗi nào trong kiến trúc cũng có thể tạo ra vấn đề trong việc tích hợp phần mềm trong pha sau. Khi dự án tiến từ pha yêu cầu sang pha kiến trúc, tổ sẽ khám phá ra rằng có nhiều “yêu cầu suy dẫn” mà cần được thực hiện. Thỉnh thoảng danh sách các yêu cầu suy diễn còn nhiều hơn các yêu cầu nguyên gốc vì kiến trúc sư phải xem xét mọi thứ như hiệu năng, tính đổi qui mô, tính dùng được, và tính bảo trì mà khách hàng mong đợi nhưng không đòi hỏi. Dựa trên kiến trúc, tổ chọn công cụ phần mềm mà họ sẽ dùng để xây dựng hệ thống. Đồng thời, các thành viên tổ có thể bắt đầu tạo ra tập các kiểm thử đơn vị để được áp dụng một khi họ kết thúc viết mã. Nhiều người phát triển không nghĩ về kiểm thử mãi cho tới khi họ kết thúc viết mã nhưng nếu họ bắt đầu phát triển kiểm thử đơn vị sớm trong pha kiến trúc, họ có thể tránh được nhiều sai lầm mà thường xảy ra trong pha thiết kế. Bằng cách làm việc trên kiểm thử đơn vị sớm, họ hiểu các yêu cầu tốt hơn, điều giúp cho họ thiết kế sản phẩm tốt hơn.
Pha thiết kế là nơi logic nội bộ của từng cấu phần được tổ chức. Trong pha này, các thành viên tổ làm việc trên chi tiết về cấu trúc dữ liệu và thuật toán của từng cấu phần. Trong pha kiến trúc, hội tụ chính là vào nhận diện các cấu phần và mối quan hệ của những cấu phần này và cách chúng tương tác lẫn nhau. Trong pha thiết kế, hội tụ là vào thiết kế logic cho từng cấu phần trong những cấu phần này. Các thành viên tổ tuân theo qui trình và dùng tập các kĩ thuật và hướng dẫn như phân hoạch vấn đề và trừu tượng hoá. Việc dùng trừu tượng hoá cho phép các thành viên tổ hội tụ vào một nhiệm vụ mỗi lúc, không lo nghĩ về chi tiết của các nhiệm vụ khác. Khi mọi nhiệm vụ đều được thực hiện, tổ phải tuân theo qui trình trắc nghiệm bằng việc có cuộc kiểm điểm thiết kế của từng cấu phần. Một cách điển hình, người quản lí dự án, kiến trúc sư hệ thống, và đảm bảo chất lượng phải tham gia vào kiểm điểm để chắc rằng mọi việc đều được thực hiện tương ứng theo kế hoạch, kiến trúc hệ thống tổng thể, và trong tuân thủ theo qui trình chuẩn.
Khi thiết kế được thẩm tra đầy đủ và chấp thuận, các thành viên tổ có thể bắt đầu pha thực hiện (viết mã). Nhiều người thích viết mã ngay nhưng nếu họ tuân theo qui trình, họ phải chọn cấu trúc dữ liệu đáp ứng nhu cầu của thiết kế; giữ cho cấu trúc logic đơn giản nhất có thể được; lựa chọn các tên biến có nghĩa nhất quán với chuẩn. Bằng việc lựa cấu trúc dữ liệu trước, rồi bắt đầu với tổ chức logic của cấu trúc mã họ có thể tránh được nhiều sai lầm thường xảy ra trong pha này. Sau khi hoàn thành việc viết mã đầu tiên, thành viên tổ phải tiến hành buổi thảo duyệt để kiểm điểm mã của họ để chắc chúng tuân thoe chuẩn viết mã và cấu trúc của chúng là nhất quán với cách dự án được tổ chức và được lập kế hoạch. Từng thành viên tổ phải thực hiện kiểm thử đơn vị và sửa các lỗi đã được tìm ra trước khi chuyển sang pha tiếp.
Trong pha kiểm thử, các thành viên tổ chuyển mã của họ cho tổ kiểm thử. Kiểm thử là quá trình thực hiện một chương trình với ý định tìm ra lỗi. Kiểm thử tốt là kiểm thử có xác suất cao tìm ra lỗi. Bằng việc tuân theo qui trình, thành viên tổ hiểu rằng kiểm thử nên được lập kế hoạch sớm trong pha thiết kế và mọi kiểm thử đều phải dõi vết được về yêu cầu của khách hàng. Việc kiểm thử phải bắt đầu trong phần nhỏ nhất và tiến tới kiểm thử phần lớn hơn và cuối cùng tới toàn thể sản phẩm phần mềm. (Kiểm thử đơn vị, kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hệ thống v.v.)
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
