3. Những Khó Khăn Thƣờng Gặp Trong Phát Triển Phần Mềm [4]
3.4. Khó khăn mức Quản Lý
Tiến thêm một mức mới qua các khó khăn mức 3, các tổ chức phần mềm nên mong đợi để thực hiện các cải tiến chất lƣợng đáng kể. Vấn để tiềm ẩn lớn nhất ở
cách tiềm tàng về qui trình phần mềm, nhƣng dữ liệu nhƣ vậy là đắt khi thu thập và bảo trì.
Do đó, cần thu thập dữ liệu với sự thận trọng và định nghĩa một cách chính xác mỗi mẩu dữ liệu trƣớc. Dữ liệu về năng suất về cơ bản là vô nghĩa nếu không đƣợc định nghĩa một cách tƣờng minh. Ví dụ, đo đạc cơ bản số dòng mã mỗi tháng phát triển có thể biến đổi 100 lần hoặc hơn, phụ thuộc vào sự hiểu các tham số. Sự đếm mã có thể bao gồm chỉ một vài mã mới hay mã bị sửa hoặc có thể là tất cả các dòng lệnh đƣợc chuyển đi. Đối với các chƣơng trình đƣợc sửa đổi, điều này có thể dẫn đến mức độ thay đổi của một thừa số là 10. Tƣơng tự, các dòng không trống không phải chú thích, các chỉ thị chạy hoặc các chỉ thị hợp ngữ tƣơng đƣơng có thể đƣợc đếm với mức độ thay đổi lên tới 7 lần. Nhân viên quản lý, kiểm thử, làm tài liệu, và hỗ trợ có thể hoặc không đƣợc tính khi tính tháng làm việc đã tiêu. Một lần nữa, mức độ biến đổi có thể ít nhất cao nhƣ một thừa số của 7.
Khi nhiều nhóm khác nhau thu thập dữ liệu nhƣng không dùng các định nghĩa giống nhau, các kết quả sẽ không thể so sánh với nhau đƣợc, thậm chí là có nghĩa để so sánh chúng. Khuynh hƣớng với những dữ liệu này là sử dụng chúng để so sánh nhiều nhóm và để phê bình chúng với những thứ hạng thấp nhất. Đây là một sự sử dụng sai đáng tiếc với dữ liệu qui trình. Hiếm khi hai dự án đƣợc so sánh bởi bất kỳ một phép đo đơn giản nào. Sự khác nhau trong độ phức tạp của công việc gây ra bởi các loại sản phẩm khác nhau có thể vƣợt quá năm lần. Tƣơng tự nhƣ vậy, chi phí cho mỗi dòng mã của những thay đổi nhỏ thƣờng gấp 2 tới 3 lần chi phí cho những chƣơng trình mới. Mức độ thay đổi của yêu cầu có thể tạo ra một sự khác nhau to lớn, nhƣ có thể là tình trạng thiết kế của một chƣơng trình ban đầu trong trƣờng hợp nâng cao.
Dữ liệu qui trình chắc chắn không đƣợc dùng để so sánh giữa các dự án hay cá nhân. Mục đích của nó là để làm sáng tỏ sản phẩm sẽ đƣợc phát triển và để cung cấp nền tảng có hiểu biết cho việc cải tiến qui trình. Khi những dữ liệu này đƣợc sử dụng bởi việc quản lý để định giá các cá nhân hay nhóm, tính đáng tin cậy của dữ liệu sẽ giảm giá trị.
Hai yêu cầu cơ bản để vƣợt qua khó khăn mức này là:
1. Hỗ trợ tự động thu thập dữ liệu qui trình. Tất cả dữ liệu là dễ bị lỗi, mất, vài dữ liệu không thể thu thập bằng tay, và độ chính xác của việc thu thập
dữ liệu bằng tay thƣờng thấp.
2. Dùng dữ liệu qui trình vừa để phân tích và sửa đổi qui trình để ngăn ngừa các vấn để và cải tiến hiệu quả.
3.5. Khó khăn mức Tối Ưu Hóa
Việc cải tiến qui trình phải đƣợc tiếp tục tại mọi mức trƣởng thành của qui trình. Đó là khó khăn duy nhất còn lại cho tổ chức khi đã vƣợt qua các khó khăn ở mức độ 4: Làm thế nào để liên tục cải tiến qui trình. Tới mức này cần có một sự dịch chuyển về mô hình (paradigm). Đến tận điểm này các nhà quản lý phát triển phần mềm đã tập trung ở mức độ lớn vào sản phẩm của họ và thông thƣờng sẽ thu thập và phân tích chỉ những dữ liệu quan hệ trực tiếp tới cải tiến sản phẩm. Đến mức này dữ liệu còn có tác dụng để tự điều chỉnh qui trình. Với một chút kinh nghiệm, việc quản lý sẽ chẳng mấy chốc thấy rằng tối ƣu qui trình có thể đem lại chất lƣợng lớn và những lợi ích về năng suất.
Ví dụ, nhiều loại lỗi có thể đƣợc xác định và sửa trƣớc rất nhiều về mặt kinh tế bằng những cuộc soi mã và soi thiết kế hơn là bằng việc kiểm thử. Không may là, chỉ có một lƣợng giới hạn dữ liệu đƣợc công bố sẵn có về chi phí để tìm và sửa lỗi. Tuy nhiên, từ kinh nghiệm, có một qui tắc bổ ích: sẽ mất 1 tới 4 giờ làm việc để tìm và sửa một lỗi bằng cách soi và khoảng 5 tới 20 giờ làm việc để tìm và sửa một lỗi trong việc kiểm thử chức năng hoặc kiểm thử hệ thống. Để mở rộng đƣợc, các tổ chức nhận thấy rằng những con số này áp dụng trong hoàn cảnh của họ, họ nên xem xét đặt ít lòng tin cậy hơn vào việc kiểm thử nhƣ là cách chính để tìm và sửa lỗi.
Tuy nhiên, vài loại lỗi là hoặc không kinh tế hoặc không thể tìm thấy ngoại trừ dùng máy móc. Ví dụ là những lỗi liên quan đến chính tả và cú pháp, giao diện, tốc độ, các nhân tố con ngƣời, và hồi phục lỗi. Sẽ là không thông minh khi loại bỏ việc kiểm thử hoàn toàn vì kiểm thử cung cấp một sự kiểm tra hữu ích những nhƣợc điểm của con ngƣời.
Dữ liệu sẵn có cho chúng ta một khía cạnh mới trong việc kiểm thử. Đối với hầu hết các dự án, một phân tích nhỏ đã chỉ ra rằng có hai hoạt động riêng rẽ dính líu vào: sự loại bỏ các lỗi và sự đánh giá chất lƣợng của chƣơng trình. Để giảm chi phí
hiệu quả về mặt chi phí khác. Vai trò của kiểm thử chức năng và hệ thống khi đó nên đƣợc thay đổi thành một việc trong việc thu thập dữ liệu chất lƣợng về các chƣơng trình. Điều này dính líu đến việc nghiên cứu mỗi lỗi để xem liệu lỗi đó là một vấn để tách biệt hay nó chỉ ra một vấn đề thiết kế mà đòi hỏi phân tích tổng hợp nhiều hơn.
Với qui trình để vƣợt qua khó khăn mức này, tổ chức có các phƣơng tiện để xác định các thành phần yếu nhất của qui trình và sửa chúng. Tại điểm này trong việc cải tiến qui trình, dữ liệu là sẵn có để biện hộ cho việc áp dụng kỹ thuật vào nhiều nhiệm vụ nguy cấp, và những bằng chứng số là sẵn có về tính hiệu quả mà qui trình đã đƣợc áp dụng cho bất cứ một sản phẩm cho trƣớc nào. Chúng ta không cần hàng tập giấy để mô tả những gì đã xảy ra vì những chỗ quanh co về lợi nhuận và những biểu đồ thống kê cung cấp những chỉ thị chính xác và rõ ràng. Khi đó sẽ có thể đảm bảo qui trình và vì vậy có tự tin về chất lƣợng của các sản phẩm kết quả.
Các khái niệm cơ bản [1]
Qui trình - Theo từ điển Webster, một qui trình là "một hệ thống các thao tác để tạo ra một chuỗi các hoạt động, các thay đổi, hoặc các chức năng để đạt tới đích hoặc kết quả". Viện Công Nghệ Điện Và Điện Tử IEEE định nghĩa một qui trình là "một chuỗi tuần tự các bƣớc đƣợc thực hiện nhằm một mục đích cho trƣớc". Một qui trình phần mềm có thể đƣợc định nghĩa nhƣ là một tập các hoạt động, các phƣơng pháp, các thực tiễn, các sự biến đổi mà ngƣời ta dùng để phát triển và bảo trì phần mềm và các sản phẩm liên quan (ví dụ: các kế hoạch dự án, các tài liệu thiết kế, mã nguồn, các trƣờng hợp kiểm thử (test cases), và các sổ tay ngƣời dùng). Khi một tổ chức trƣởng thành, qui trình phần mềm của tổ chức đó đƣợc xác định tốt hơn và đƣợc thực thi nhất quán hơn trong toàn bộ tổ chức.
Khả năng qui trình phần mềm (software process capability) mô tả loại kết quả mong đợi có thể đạt đƣợc bằng cách tuân theo một qui trình phần mềm. Khả năng qui trình phần mềm của một tổ chức cung cấp một phƣơng tiện để dự đoán kết quả gần nhƣ chính xác cho dự án phần mềm tiếp theo mà tổ chức sẽ thực hiện.
Hiệu suất qui trình phần mềm (Software process performance) diễn tả các kết quả thực sự đạt đƣợc nếu tuân theo một qui trình phần mềm. Vì vậy, hiệu suất qui trình phần mềm tập trung vào các kết quả đạt đƣợc thực sự, trong khi đó khả năng qui trình phần mềm tập trung vào các kết quả có thể đạt đƣợc. Dựa trên các thuộc
tính của một dự án cụ thể và ngữ cảnh ở đó dự án đƣợc thực hiện, hiệu suất thực sự của dự án có thể không phản ánh toàn bộ khả năng của qui trình; nghĩa là: khả năng của một dự án bị giới hạn bởi môi trƣờng (ngữ cảnh) của nó. Ví dụ, những thay đổi cơ bản về ứng dụng hay công nghệ đƣợc sử dụng có thể đặt đội phát triển ở thế phải học hỏi thêm dẫn đến khả năng và hiệu suất của dự án kém so với khả năng qui trình nói chung của tổ chức.
Sự trưởng thành qui trình phần mềm là sự mở rộng mà ở đó một qui trình cụ thể đƣợc định nghĩa, quản lý, đo đạc, điều khiển một cách rõ ràng, và qui trình này hiệu quả. Sự trƣởng thành ngụ ý một tiềm năng phát triển khả năng và biểu lộ cả sự đầy đủ về qui trình lẫn sự nhất quán áp dụng qui trình trong toàn bộ tổ chức. Qui trình phần mềm đƣợc nắm bắt tốt trong toàn bộ tổ chức, thông thƣờng qua tài liệu và đào tạo, và qui trình liên tục đƣợc theo dõi giám sát và cải tiến bởi ngƣời sử dụng qui trình. Khả năng của một qui trình phần mềm đã trƣởng thành đƣợc tổ chức hiểu rõ. Sự trƣởng thành qui trình phần mềm ngụ ý rằng năng suất và chất lƣợng nhận đƣợc từ qui trình phần mềm của một tổ chức có thể đƣợc cải tiến qua thời gian nhờ những lợi ích liên tục đạt đƣợc từ qui trình phần mềm.
Khi một tổ chức phần mềm đạt đƣợc sự trƣởng thành qui trình phần mềm, nó thể chế hoá qui trình phần mềm của nó qua các chính sách, các chuẩn, và các cấu trúc về mặt tổ chức. Sự thể chế hoá đòi hỏi xây dựng một cơ sở hạ tầng và một văn hoá công ty hỗ trợ các phƣơng pháp, các thực tiễn, và các thủ tục kinh doanh nhờ đó chúng tồn tại đƣợc sau khi những ngƣời định nghĩa ra chúng đã ra đi.
CHƯƠNG 3
NĂM MỨC ĐỘ TĂNG TRƯỞNG CỦA CMM
Chƣơng này giới thiệu chi tiết các mức độ tăng trƣởng của CMM và các quy trình then chốt. [10]
1. MỨC 1: KHỞI ĐẦU
Hình 3. 1 : Mức khởi đầu 1.1. Hiểu mức tăng trưởng khởi đầu 1: 1.1. Hiểu mức tăng trưởng khởi đầu 1:
- Hiệu năng phần mềm bị điều khiển bởi năng lực và tính DÁM LÀM VIỆC của ngƣời làm công việc đó
- Chất lƣợng cao và hiệu năng ngoại lệ có thể chừng nào còn có thể thuê đƣợc ngƣời giỏi nhất
Hình 3. 2 : Mô tả mức khởi đầu 1.2. Thuộc tính của tổ chức mức 1 1.2. Thuộc tính của tổ chức mức 1
Qui trình sản xuất PM còn lô ̣n xô ̣n , không khoa ho ̣c, khả năng rủi ro cao. Mô ̣t số công đoa ̣n bi ̣ phu ̣ thuô ̣c vào mô ̣t, hai cá nhân nào đó.
- Thiếu / hiểu sai yêu cầu
- Ƣớc lƣợng / Lập kế hoạch kém - Thiếu qui trình đƣợc xác định - Các dấu hiệu cảnh báo bị bỏ qua - Quá hạn là chuyện thƣờng.
- Không có huấn luyện về qui trình - Hiếm khi đáp ứng ràng buộc ngân sách - Hiếm khi đáp ứng ràng buộc lịch biểu
- Thiếu phản hồi có thể gây ra nỗ lực bị lãng phí - Khách hàng và nhân viên ít đƣợc thoả mãn.
Hình 3. 3 : Mức lặp lại được
* Chuyển từ mức (1) sang (2)
- Mức (1) = lung tung, chỉ cốt việc đƣợc làm!
- Mức (2) = các qui trình quản lí dự án đƣợc làm tƣ liệu và thực hiện. Hội tụ vào dự án.
2.1. Hiểu mức tăng trưởng lặp lại 2
Quy trình đã có sƣ̣ kiểm soát bằng viê ̣c lên kế hoa ̣ch , rút kinh nghiệm từ thành công của nhƣ̃ng dƣ̣ án trƣớc. Mƣ́c này đã thiết lâ ̣p mô ̣t số qui trình quản lý dƣ̣ án cơ bản nhƣ theo dõi chi phí, thời ha ̣n và chƣ́c năng.
- Các qui trình quản lí dự án đƣợc làm tƣ liệu và tuân theo.
- Thực hành thành công đƣợc phát triển dựa trên các dự án trƣớc đƣợc lặp lại. (Phân tích nhân quả)
- Chính sách của tổ chức động viên việc thiết lập các qui trình quản lí dự án xác định tốt.
Hình 3. 4 : Mô tả mức lặp lại được
* Qui trình đƣợc làm tƣ liệu chứa những gì? - Mục đích và mục tiêu
- Ngƣời đƣợc dự định đọc - Các giả định
- Thủ tục về cách cải tiến qui trình - Cái vào/ra qui trình chi tiết (Giao diện) - Các bƣớc qui trình chi tiết (có lí do) 1 .. N - Xác định cách đo qui trình để đạt hiệu quả đo - Chuẩn và nguyên tắc chỉ đạo qui trình
- Ngƣời liên hệ, danh sách viết tắt, từ điển dữ liệu
2.2. Các KPA cho mức lặp lại 2
1. Quản lí yêu cầu (RM)
2. Lập kế hoạch dự án phần mềm (PP)
3. Theo dõi và giám sát dự án phần mềm (PT) 4. Quản lí nhà thầu phần mềm (SM)
5. Đảm bảo chất lƣợng phần mềm (QA) 6. Quản lí cấu hình phần mềm (CM)
2.2.1. Quản Lý Yêu Cầu
Mục đích của Quản Lý Yêu Cầu là thiết lập một hiểu biết chung giữa khách hàng và dự án phần mềm nhằm thực hiện yêu cầu khách hàng.
Quản Lý Yêu Cầu liên quan đến thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu cho dự án phần mềm. Sự thoả thuận này đƣợc nói đến nhƣ là "các yêu cầu hệ thống chỉ định cho phần mềm". "Khách hàng" có thể đƣợc hiểu nhƣ là nhóm kỹ sƣ hệ thống, nhóm tiếp thị, một tổ chức nội bộ khác, hoặc một khách hàng bên ngoài. Sự thoả thuận bao gồm cả các yêu cầu kỹ thuật và phi kỹ thuật (ví dụ: các ngày chuyển giao). Sự thoả thuận hình thành cơ sở để ƣớc tính, lập kế hoạch, thực hiện, và theo dõi các hoạt động của dự án phần mềm trong suốt vòng đời phần mềm.
Sự chỉ định yêu cầu hệ thống cho phần mềm, phần cứng và các thành phần hệ thống khác (ví dụ: ngƣời) có thể đƣợc thực hiện bởi một nhóm bên ngoài nhóm kỹ nghệ phần mềm (software engineering group) (ví dụ nhóm kỹ sƣ hệ thống), và nhóm kỹ nghệ phần mềm có thể không kiểm soát trực tiếp sự chỉ định này. Trong phạm vi các ràng buộc của dự án, nhóm kỹ nghệ phần mềm thực hiện các bƣớc thích hợp để bảo đảm rằng các yêu cầu hệ thống chỉ định cho phần mềm, những yêu cầu mà họ chịu trách nhiệm, đƣợc lập thành tài liệu và kiểm soát.
Để đạt đƣợc sự kiểm soát này, nhóm kỹ nghệ phần mềm xem xét lại các yêu cầu hệ thống chỉ định cho phần mềm – khi bắt đầu và đã đƣợc xét duyệt - để giải quyết các vấn đề trƣớc khi chúng đƣợc tích hợp vào dự án phần mềm. Bất cứ khi nào các yêu cầu hệ thống chỉ định cho phần mềm thay đổi, các kế hoạch phần mềm, công việc phần mềm và các hoạt động bị ảnh hƣởng đƣợc điều chỉnh để bảo đảm nhất quán với các yêu cầu đã đƣợc cập nhật.
Mục tiêu 1: Những yêu cầu hệ thống về phần mềm cần đƣợc kiểm soát nhằm lập thành một phiên bản sử dụng trong quản lý và kỹ nghệ phần mềm.
Mục tiêu 2: Các kế hoạch, sản phẩm và hoạt động phần mềm cần đƣợc giữ nhất quán với các yêu cầu hệ thống về phần mềm
Hành động 1: Nhóm kỹ nghệ phần mềm xem xét các yêu cầu đƣợc chỉ định trƣớc khi chúng đƣợc tích hợp và dự án phần mềm.
Hành Động 2: Nhóm kỹ nghệ phần mềm sử dụng các yêu cầu chỉ định nhƣ