3. Những Khó Khăn Thƣờng Gặp Trong Phát Triển Phần Mềm [4]
3.1. Khó khăn mức Khởi Đầu
Ban đầu các tổ chức có thể có qui trình tuỳ ý, không theo thể thức, và nó thƣờng hỗn độn. Tại giai đoạn này tổ chức thƣờng hoạt động mà không có các thủ tục; các ƣớc tính chi phí và các kế hoạch dự án một cách chính thức. Các công cụ không đƣợc tích hợp tốt với qui trình và cũng không đƣợc áp dụng đồng bộ. Quản lý thay đổi thì lỏng lẻo, và ít có chuyện quản lý cấp cao hiểu đƣợc các bài toán và các vấn đề. Vì nhiều vấn đề bị hoãn lại hoặc thậm chí bị bỏ quên, cài đặt phần mềm và bảo trì thƣờng có nhiều vấn đề nghiêm trọng.
Trong khi các tổ chức có thể có các thủ tục chính thức để lập kế hoạch và theo dõi công việc của họ, lại không có cơ chế quản lý để bảo đảm rằng chúng đã đƣợc sử dụng. Cách kiểm tra tốt nhất là quan sát những tổ chức nhƣ vậy xoay sở thế nào trong một cuộc khủng hoảng. Nếu nó từ bỏ những thủ tục đã đƣợc thiết lập và về bản chất lại trở lại việc viết mã và kiểm thử, tổ chức đó có thể đang gặp những khó khăn ở mức khởi đầu. Sau hết, nếu các kỹ thuật và phƣơng pháp là thích hợp, khi đó chúng sẽ đƣợc dùng trong khủng hoảng; nếu chúng không thích hợp trong khủng hoảng, chúng sẽ không đƣợc dùng một chút nào.
Một lý do mấu chốt tại sao các tổ chức cƣ xử theo cách thức này là họ không trải qua những lợi ích của một qui trình chín chắn và vì vậy không hiểu những hậu quả của các hành xử lộn xộn của họ. Bởi vì nhiều hành động phần mềm hiệu quả (ví dụ thiết kế và soi mã hoặc phân tích dữ liệu kiểm thử) không có vẻ trực tiếp hỗ trợ việc tạo ra sản phẩm, chúng có vẻ nhƣ có thể bỏ đi đƣợc.
Rất giống nhƣ lái một chiếc xe ô tô. Vài ngƣời lái xe không một chút kinh nghiệm sẽ tiếp tục lái rất lâu khi đèn cảnh báo của động cơ sáng, bất kể sự vội vàng của họ. Tƣơng tự, hầu hết các lái xe bắt đầu một chuyến đi mới sẽ, bất kể sự vội vã của họ, dừng lại để xem bản đồ. Họ đã học đƣợc sự khác nhau giữa tốc độ và sự tiến triển.
Trong phần mềm, viết mã và kiểm thử có vẻ nhƣ là sự tiến tới, nhƣng chúng thƣờng chỉ là sự quay tròn của bánh xe. Trong khi chúng phải đƣợc thực hiện, luôn luôn có những nguy hiểm nếu đi sai hƣớng. Nếu không có một kế hoạch tốt và một phân tích kỹ càng các vấn đề, không có cách nào để biết.
Các tổ chức gặp những khó khăn nhƣ vậy có qui trình ở mức khởi đầu trong mô hình CMM.
Các tổ chức ở mức qui trình khởi đầu có thể cải tiến hiệu suất của họ bằng cách tiến hành các kiểm soát dự án cơ bản. Quan trọng nhất là quản trị dự án, giám sát quản lý, bảo đảm chất lƣợng, và kiểm soát các thay đổi.
Vai trò cơ bản của một hệ thống quản lý dự án là bảo đảm kiểm soát có hiệu quả các cam kết. Điều này đòi hỏi sự chuẩn bị thích đáng, trách nhiệm rõ ràng, sự công bố công khai và sự dành riêng (dedication) cho hiệu suất.
Cho phần mềm, quản trị dự án bắt đầu bằng việc hiểu độ lớn của công việc. Trong bất kỳ dự án nào ngoại trừ những cái đơn giản nhất, một kế hoạch phải đƣợc lập để quyết định lịch làm việc tốt nhất và các tài nguyên lƣờng trƣớc cần thiết. Nếu thiếu một kế hoạch thứ tự nhƣ vậy, không có cam kết nào có thể tốt hơn một sự ƣớc chừng đƣợc rèn luyện.
Một tổ chức phát triển phần mềm có kỷ luật phù hợp phải có giám sát quản lý cấp cao. Điều này bao gồm xem xét lại và phê chuẩn tất cả các kế hoạch phát triển chính trƣớc khi cam kết thực hiện chính thức.
Cũng nhƣ vậy, một sự xem lại hàng quý nên đƣợc dẫn dắt bao gồm sự làm đúng theo qui trình trong phạm vi toàn bộ các điều kiện (facility-wide), hiệu suất chất lƣợng đã đƣợc đặt, theo dõi lịch làm việc, các xu hƣớng chi phí, dịch vụ tính toán, và mục tiêu năng suất và chất lƣợng theo dự án. Thiếu những sự xem lại nhƣ vậy thƣờng dẫn đến việc thực thi qui trình không đều và nói chung là không đủ cũng nhƣ là những sự cam kết quá đáng và những sự ngạc nhiên về chi phí cao.
Một nhóm bảo đảm chất lƣợng có trách nhiệm bảo đảm việc quản lý công việc phần mềm đƣợc thực hiện theo cách mà nó đƣợc cho là phải đƣợc thực hiện. Để có hiệu quả, tổ chức bảo đảm phải có một đƣờng (line) báo cáo độc lập tới quản lý cấp cao và các tài nguyên đủ để giám sát hiệu suất của tất cả các hoạt động lập kế hoạch, thực thi và kiểm tra chủ chốt. Nói chung điều này đòi hỏi ở một tổ chức khoảng 3 tới 6 phần trăm cỡ của tổ chức phần mềm
Kiểm soát thay đổi trong phần mềm là thiết yếu để mà kiểm soát được nghiệp vụ và tài chính cũng nhƣ để nhắm tới sự ổn định về mặt kỹ thuật. Để phát triển phần
mềm có chất lƣợng theo một lịch làm việc có thể dự đoán trƣớc, các yêu cầu phải đƣợc củng cố và giữ với độ ổn định hợp lý trong suốt vòng phát triển. Trong khi những thay đổi của các yêu cầu thƣờng cần thiết, các bằng chứng lịch sử chứng minh rằng nhiều cái có thể bị hoãn lại và đƣợc kết hợp lại sau. Những thay đổi về thiết kế và viết mã phải đƣợc thực hiện để sửa những vấn đề phát hiện trong phát triển và kiểm thử, nhƣng những thay đổi này phải đƣợc đƣa vào một cách cẩn thận. Nếu các thay đổi không đƣợc kiểm soát, khi đó theo thứ tự thiết kế, thực thi, và kiểm thử là không thể và không kế hoạch chất lƣợng nào lại có thể hiệu quả đƣợc.