CMMI-28

Hỏi: Sao thầy chủ trương cải tiến qui trình phần mềm bằng việc dùng khuôn khổ CMMI? Sao không dùng mô hình khác?

Đáp: Có vài mô hình để cải tiến qui trình phần mềm nhưng theo cách nhìn riêng của tôi, mô hình chỉ là lí thuyết mà chính kĩ năng và kinh nghiệm của người dùng nó mới làm cho mọi sự xảy ra. Trước khi quyết định dùng khuôn khổ CMMI hay cái gì đó khác, có vài nhân tố mà tổ chức nên xét tới.

1.      Có những bằng chứng kinh nghiệm rằng khuôn khổ CMMI có tác dụng và phần nhiều trong đó đã được công bố trong các tạp chí phần mềm và bài báo chuyên môn. Không có bằng chứng tương tự về các mô hình cải tiến khác. Câu hỏi của tôi là tại sao tổ chức muốn dùng cái gì đó khi chúng ta không biết liệu nó có tác dụng hay không?

2.      Khuôn khổ CMMI thực sự là họ các mô hình (Phần mềm, Con người, Thu nhận, Hệ thống được tích hợp v.v.) đã được chấp nhận quốc tế và được thiết kế để bổ sung lẫn cho nhau. Sự phong phú thông tin này đã giúp cho CMMI trở thành mô hình được chọn lựa cho nhiều tổ chức trên khắp thế giới.

3.      Tôi đã làm việc với Watts Humphrey khi ông ấy xây dựng SW-CMM tại Viện Kĩ nghệ phần mềm – Software Engineering Institute (SEI) và đã có cái nhìn sâu sắc vào trong cách tiếp cận năm mức này: Watts nhận ra rằng có thứ tự tự nhiên đối với các vấn đề mà tổ chức phải giải quyết để cải tiến thực hành phần mềm. Ông ấy đã nhận ra rằng tổ chức phải sửa chữa lịch biểu của họ và các vấn đề dự án trước khi giải quyết các vấn đề kĩ nghệ. Bằng không, các thực hành kĩ nghệ sẽ không bao giờ có cơ hội sống còn trong sự hỗn độn được tạo ra bởi lịch biểu không thoả đáng. Vậy, nếu năng lực mức 2 mà còn chưa được thiết lập, thực hành kĩ nghệ sẽ bị hi sinh cho sức ép lịch biểu.

4.      Tôi thấy rằng các mô hình khác chỉ hội tụ vào việc lấy một qui trình và cải tiến nó, bất kể tới mức độ trưởng thành hay năng lực của tổ chức. Tôi tin việc cho phép mọi người lấy ra bất kì cái gì họ muốn để cải tiến là ấu trĩ vì cấp quản lí sẽ không bao giờ cho phép các kĩ sư làm bất kì cái gì họ muốn mà không có bằng chứng cụ thể rằng nó sẽ giải quyết các vấn đề căn bản và chuyển giao sản phẩm chất lượng trong thời gian nào đó.

5.      Tôi cũng tin bất kì cải tiến nào trong cô lập mà không có sự tham dự của toàn thể tổ chức sẽ dẫn tới những tình huống khó xử: Điều gì sẽ xảy ra khi bạn có qui trình kiểm thử tốt nhất nhưng làm việc trong môi trường mà phần mềm được đưa ra lại dựa trên lịch biểu cố định và thường không được kiểm thử. Cứ tưởng tượng rằng các sơ đồ kiểm soát sẽ được sinh ra bởi một qui trình ổn định trước đây lại nhận cái vào từ một qui trình mất kiểm soát. Không qui trình kĩ nghệ nào có thể đạt tới mức độ hiệu quả của nó nếu nó bị ngắt quãng bởi hỗn độn của các qui trình quanh nó.

6.      Theo quan điểm quản lí, CMMI với năm mức trưởng thành là có nghĩa bởi vì ở mức 4 tổ chức có thể xác định các qui trình nào nó tin là mấu chốt nhất cho kết quả kinh doanh của nó và nhắm tới những kết quả đó với kiểm soát thống kê. Tổ chức chỉ có thể làm được điều đó sau khi nó đã thiết lập một qui trình phát triển chuẩn vững chắc (OSSP- mức 3) mà có dữ liệu và cái hiểu sâu để xác định qui trình nào là dẫn lái kinh doanh mấu chốt.

7.      Theo kinh nghiệm riêng của tôi, ích lợi lớn đã được chứng tỏ ở mức 4 và 5 yêu cầu tổ chức thiết lập qui trình chuẩn đầy đủ (OSSP) có thể được tích hợp với các qui trình khác để tối ưu ích lợi – không chỉ một vài trong các qui trình mà mọi người chọn. Sự bùng nổ việc dùng lại tài sản và mức độ dự đoán được lịch biểu được quan sát thấy ở mức 4 và khả năng canh tân ở mức 5, tất cả đều yêu cầu rằng tổ chức có nền tảng qui trình vững chắc (OSSP) mà có thể được quản lí theo định lượng và rằng mọi người được huấn luyện để dùng qui trình đó. Điều này không thể được thực hiện bằng  cách tiếp cận đơn  giản như các mô hình khác chủ trương.

8.      Nhân tiện, ngành công nghiệp phần mềm đã cố gắng cải tiến cách tiếp cận một mảnh này trong hơn 30 năm qua, mà ít hay không thành công. Từ những năm 1970, mọi người đã chọn các qui trình riêng lẻ (thiết kế, kiểm thử, viết mã v.v.) và cố gắng cải tiến chúng một cách cô lập. Việc cải tiến này đã không tồn tại bởi vì tổ chức đã không giải quyết vấn đề nền tảng của mình – kiểm soát lịch biểu dự án. Watts Humphrey đã nhận ra nhu cầu cần tối ưu vấn đề ông ấy phải giải quyết. Khuôn khổ trưởng thành là con đường logic để cải tiến toàn thể qui trình phát triển.

9.      Các mô hình CMMI tạo ra văn hoá khác nhau tại từng mức trưởng thành. Chẳng hạn, các tổ chức mức 3 có thể được quan sát thấy cách văn hoá chuyên nghiệp có ảnh hưởng bằng việc chia sẻ những thực hành tốt nhất. Văn hoá bao gồm nhiều thực hành chung và nhiều người chia sẻ, điều tốt hơn là văn hoá sẽ nổi lên. Cách tiếp cận khác không làm cho tổ chức bị tràn ngập  bởi những thực hành chung, và điều như vậy quả ít làm thay đổi văn hoá của tổ chức. Thay đổi văn hoá là rất mấu chốt để thể lệ hoá các thực hành và đạt tới ích lợi của cải tiến qui trình.

Tôi chắc chắn trong tương lai có thể có những mô hình tốt hơn nhưng vào lúc này, tôi biết CMMI có tác dụng tốt trong nhiều tổ chức và đó là lí do tại sao tôi chủ trương mô hình này hơn các mô hình khác.

Hỏi: Công ti của tôi được một nhà tư vấn đánh giá năm ngoài là ở CMMI mức 1. Ông chủ của tôi không thích kết quả này cho nên ông ấy thuê một nhà tư vấn khác. Nhà tư vấn mới tới đem theo nhiều khuôn mẫu và tài liệu cho công ti chúng tôi dùng, kể cả dữ liệu mẫu và trong vòng mười tháng, ông ấy đã đánh giá công ti tôi là CMMI mức 5. Thầy nghĩ chúng tôi đáng phải ở mức nào?

Đáp: Không tiến hành đánh giá, tôi không thể nói được về mức độ trưởng thành của công ti bạn. Tuy nhiên, có thể là nhà tư vấn đầu là người trung thực và đã đánh giá công ti bạn ở mức 1 vì nó không có qui trình nào được làm tài liệu. Nhà tư vấn thứ hai đã đem tới tài liệu và khuôn mẫu riêng của ông ấy rồi dùng chúng làm bằng chứng rằng công ti bạn đã có tất cả các qui trình được làm tài liệu cũng như dữ liệu thống kể cho nên ông ấy có thể đánh giá công ti bạn ở mức cao hơn (mức 5). Điều này có thể được coi là “lừa bịp” và có thể là ông ta đã bán mức độ trưởng thành với giá mà công ti bạn sẵn lòng trả.

Vấn đề của tôi không phải là với nhà tư vấn mà là với ông chủ của bạn. Tại sao ông ấy muốn đạt tới cái gì đó mà công không có và lí do để làm điều đó là gì? Ông ấy có muốn quảng cáo cho công ti mình ở mức trưởng thành cao với hi vọng rằng mọi người sẽ mua sản phẩm và dịch vụ của bạn sao? Trong trường hợp đó, ông ấy có thể tiết kiệm nhiều tiền bằng việc in một mảnh giấy nói rằng công ti đang ở CMMI mức 5 thay vì trả tiền cho nhà tư vấn.

Tôi cũng nghĩ bất kì ai tin vào “Quảng cáo CMMI mức” như đảm bảo cho chất lượng cao mà không kiểm chứng điều đó, thì không phải là thông minh mấy. Về căn bản, loại lừa bịp này là rất ấu trĩ bởi vì phần lớn mọi người không biết họ đang mua gì và sẽ không bao giờ làm ăn với công ti có ý định lừa bịp họ bằng quảng cáo giả. Khi mọi người thấy các công ti nói đạt tới mức độ trưởng thành cao và nhìn vào chất lượng của công việc được chuyển giao, họ có thể nói điều khác và tất nhiên, họ không bao giờ làm ăn với công ti đó nữa.

Hỏi: Khi lập kế hoạch cải tiến qui trình phần mềm bằng việc dùng CMMI làm khuôn khổ, vấn đề chuyển sang mức 3 là gì khi so với đạt tới mức 2 như điều tiên quyết? Tôi không thấy khác biệt gì nếu SEPG yêu cầu người làm phần mềm cho phép qui trình chuẩn được xác định.

Đáp: Ý tưởng về SEPG “áp đặt” các qui trình mức 3 lên một nhóm mức 1 gồm những người chưa được huấn luyện để tuân theo mức 2 là rất khó. Cứ hình dung ai đó tới và bảo mọi người phát triển rằng cách thức họ đã làm việc cho tới giờ là tồi, và đây là cách làm mới, mà SEPG đã xác định cho họ tuân theo và đây là cách chúng ta làm việc từ giờ trở đi. Bạn nghĩ gì nếu bạn là người phát triển làm việc chăm chỉ cần mẫn?  Bạn có cho rằng bạn sẽ nghe ai đó mà bạn không biết bảo bạn cách bạn làm việc của mình không? Bất kì ai cũng có thể viết ra các qui trình, chính sách, thủ tục v.v. mức 3 nhưng lại cần nhiều tri thức và kĩ năng để hiểu cách thay đổi tổ chức bên trong những hành vi tập thể duy nhất của nó.

Về căn bản, ở mức 1, không ai biết cái gì làm việc, cái gì không làm việc vì chẳng cái gì được làm tài liệu. Phải mất thời gian viết ra điều những người phát triển làm như một công cụ trao đổi để thực sự hiểu cái gì thực sự làm việc, cái gì không làm việc và làm sao cải tiến chúng. Đây là bước đầu tiên của mọi cải tiến; bạn phải biết bạn ở đâu trước khi bạn có thể đi đâu đó.

Ở mức 2, có một số điều có thể được làm mà không yêu cầu rằng chúng được thực hiện theo cách thức chuẩn. Mọi dự án đều được yêu cầu làm tài liệu về các qui trình riêng của họ thay vì tuân theo cái gì đó được người khác làm tài liệu. Hệ quả là, tổ chức có thể có một số qui trình đa dạng được thiết lập trong các dự án khác nhau. Tuy nhiên, đây là chỗ nền tảng được đặt ra bởi vì các qui trình này được những người phát triển tạo ra. Dựa trên dữ liệu đo được SEPG thu thập, họ có thể xác định về tính hiệu quả và hiệu lực của các qui trình đa dạng để nhận diện cái gì có tác dụng tốt nhất. Nhóm SQA sẽ đảm bảo rằng độ đo được xác định rõ và tương ứng với thực tại. Phân tích này về các qui trình mức 2 sẽ cho phép SEPG hợp nhất và cải tiến các qui trình này thành thực hành tốt nhất chuẩn, đưa tới qui trình tổ chức mức 3.

Các mức trưởng thành của CMMI được tạo ra dựa trên nhiều năm nghiên cứu tại Đại học Carnegie Mellon và chúng phục vụ mục đích cho phép tổ chức trưởng thành qua thời gian. Xin đừng nhảy qua các mức.

Hỏi: Ở mức 3, chúng tôi đã thiết lập qui trình chuẩn của tổ chức và cung cấp huấn luyện cho mọi người làm phần mềm trong tổ chức chúng tôi. Chúng tôi không biết phải làm gì để đạt tới mức 4?

Đáp: Ở CMMI mức 4, việc hội tụ của cải tiến hội tụ được mở rộng sang cả dự án và nghiệp vụ của tổ chức.

Ở mức tổ chức, bạn cần:

1)     Thiết lập tuyến cơ sở hiệu năng, đặc trưng cho hiệu năng qui trình mong đợi của các qui trình chuẩn của tổ chức.

2)     Thiết lập các mục tiêu chất lượng cho mọi dự án phần mềm. Chẳng hạn không quá X lỗi trên KLOC; không quá Y % biến thiên giữa kế hoạch được ước lượng so với thực tại.

3)   Để tổ chức lựa ra các qui trình  hay qui trình con trong các qui trình chuẩn của tổ chức để phân tích hiệu năng như thiết lập các giới hạn kiểm soát (cận trên & cận dưới)

4)   Để tổ chức thiết lập Cách đo Hiệu năng-Qui trình bằng việc duy trì các định nghĩa về cách đo mà được đưa vào trong các phân tích hiệu năng-qui trình của tổ chức.

6)  Để tổ chức lựa chọn cách đo và kĩ thuật phân tích được dùng trong quản lí theo thống kê qui trình được lựa cho mọi dự án.

Ở mức dự án, bạn cần:

1)     Thiết lập các mục tiêu hiệu năng của dự án như lập các mục đích chất lượng, mục đích tuân thủ qui trình định lượng (chẳng hạn: Số các qui trình dưới kiểm soát thống kê)

2)     Lựa các qui trình con bên trong qui trình được xác định của dự án để được quản lí thống kê dựa trên sự ổn định lịch sử và dữ liệu năng lực. Bạn cần nhận diện các giới hạn kiểm soát bằng việc phân tích dữ liệu riêng của mình.

3)     Phân tích hiệu năng tập thể của các qui trình con của dự án để dự đoán liệu các mục tiêu của dự án về chất lượng và hiệu năng qui trình sẽ được thoả mãn và nhận diện nhu cầu hành động sửa chữa thích hợp.

4)     Dùng các mô hình hiệu năng qui trình đã định cỡ để nhận diện, phân tích và thực hiện hành động sửa đổi khi  cần.

5)     Nhận diện và quản lí thống kê về các qui trình con được lựa bên tronng qui trình được xác định của dự án bằng việc lập giới hạn kiểm soát.

6)     Để SQA kiểm điểm liệu có chắc chắn dự án tuân theo cách đo và các kĩ thuật phân tích được tổ chức lựa cho việc quản lí các qui trình của nó không?

7)     Thiết lập và hiểu biến thiên của các qui trình con được lựa bằng việc dùng các cách đo và kĩ thuật phân  tích được lựa.

8)     Nhận diện, đề cập, và ngăn cản việc tái xuất hiện của các nguyên nhân biến thiên đặc biệt trong các qui trình con được lựa.

9)     Phân tích hiệu năng của các qui trình con được lựa để dự đoán năng lực của chúng để thoả mãn chất lượng và các mục tiêu hiệu năng-qui trình của chúng, và lấy hành động sửa chữa khi cần.

10)    Ghi lại dữ liệu thống kê và quản lí chất lượng trong kho cách đo của tổ chức dành cho phân tích tương lai.

11)    Lựa dữ liệu nào đó cho phân tích bằng việc dùng tiêu chí đã thiết lập.

12)    Phân tích nguyên nhân chung của biến thiên để hiểu phẩm chất cố hữu và các ràng buộc hiệu năng qui trình.

Điều sau đây được nói tới ở CMMI mức 5, nhưng tôi nghĩ ở mức 4 bạn có thể thực hiện nó song song thay vì tuần tự:

13) Tiến hành phân tích nhân quả với các vấn đề được lựa để xác định căn nguyên của chúng (Điều này có nhiều hơn ở mức 5 nhưng bạn có thể làm điều đó thậm chí ở mức 4)

14) Đề nghị các hành động để đề cập tới các nguyên nhân chung được lựa của biến thiên  và ngăn ngừa việc tái xuất hiện của các vấn đề được lựa trong tổ chức.

15) Đệ trình các đề án cải tiến qui trình và công nghệ dựa trên dữ liệu lịch sử và phân tích hiệu năng dự án?

Hỏi: Liệu có thể để người phát triển trong dự án thực hiện cả các chức năng SQA và kiểm điểm ngang quyền không? Tại sao có và tại sao không?

Đáp: Thuật ngữ Kiểm điểm ngang quyền, như tên của nó ngụ ý, được thực hiện bởi “người ngang quyền” hay những người đang làm việc trong dự án cùng bạn để kiểm điểm KHÔNG CHÍNH THỨC công việc của bạn để xác định xem liệu nó có tốt không nhưng sẽ không đánh giá hay trắc nghiệm sản phẩm của bạn để được chấp nhận chính thức. Việc kiểm điểm như vậy được thực hiện với mục đích phát hiện, sớm nhất có thể được, bất kì vấn đề nào trong vật phẩm phần mềm của bạn (kế hoạch, thiết kế, mã, v.v.).

SQA được thực hiện bởi những người đang ở vị trí trắc nghiệm KHÁCH QUAN sản phẩm và qui trình phần mềm.  Bạn phải đừng quên rằng ý định của SQA là yêu cầu cách nhìn KHÁCH QUAN và phải KHÔNG thiên vị cho nên SQA KHÔNG nên được thực hiện bởi những người đang làm việc trong dự án.

Hỏi: Công ti tôi được đánh giá ở CMMI mức 5. Chúng tôi phải làm gì tiếp? Có mức 6 không? Tôi nghĩ mức 4 và 5 là dễ đạt tới hơn mức 2 hay 3. Thầy nghĩ sao?

Đáp: Nếu bạn thành công, đà sẽ có đó và tôi không ngạc nhiên với nhiệt tình của bạn để tiếp tục sang mức sau. Theo kinh nghiệm của tôi, tổ chức đã thành công trong cải tiến qui trình và làm chủ tất cả các miền qui trình của mức 2 và 3 có thể đi nhanh hơn vào hai mức tiếp. Một số tổ chức thậm chí còn có thể làm việc trên miền qui trình của mức 4 và mức 5 song song thay vì tuần tự. Tôi nghĩ Phân tích nhân quả và giải pháp có thể được thực hiện ở mức 4 vì mức 4 họi tụ vào việc dùng dữ liệu để cải tiến nghiệp vụ tổ chức. Nhận diện nguyên nhân của vấn đề và khử bỏ chúng là điều đúng cần làm và không cần đợi tới mức 5.

Tôi tin hội tụ của mức 5 là vào việc duy trì tuyệt hảo bằng việc biểu lộ tuyệt hảo hiệu năng và đo được. Ở mức 5, tổ chức đã trưởng thành đầy đủ bằng việc có hiệu năng nhất quán trong mọi khía cạnh. Vấn đề ở đây là làm sao duy trì đà của tuyệt hảo phần mềm trong môi trường thay đổi nhanh chóng.

Hỏi: Làm sao thầy đo kích cỡ phần mềm nếu thầy không dùng dòng mã (LOC) hay điểm chức năng (FP)?

Đáp: Đo kích cỡ có thể thay đổi trong vòng đời phần mềm. Chẳng hạn, đo kích cỡ của pha yêu cầu là số các yêu cầu. Đo kích cỡ của pha thiết kế là số các phần tử thiết kế. Đo kích cỡ của pha thực hiện là số dòng mã, chương trình con, đối tượng hay lớp đối tượng trong mã nguồn đã hoàn thành.

Hỏi: Là sinh viên, em thực sự thích lớp kĩ nghệ phần mềm tại Carnegie Mellon nhưng em bây giờ đang làm việc và không có thời gian học thêm.

Đáp: Tất cả chúng ta đều bận rộn với cuộc sống thường ngày của mình để giữ cân bằng giữa công việc và gia đình. Không mấy  người có thể đảm đương được việc để thời gian cho đào tạo vốn là điều bản chất để vẫn còn hiện hành cùng công nghệ. Chúng ta biết rằng để vẫn còn có là cá nhân có khả năng cạnh tranh trong thời đại thay đổi, việc học liên tục là cấu phần mấu chốt cho thành công. Điều quan trọng cần biết xu hướng trong công nghiệp, biết cái gì là quan trọng và cái gì không, và liên tục  học và trưởng thành cả như một con người và nhà chuyên môn. Tuy nhiên, học tập không nhất thiết có nghĩa bạn phải tham dự lớp học. Bạn có thể học nhiều từ các hoạt động thường ngày của mình, từ dự án của bạn, từ người khác và từ bạn của bạn. Cơ hội học tập là vô tận nếu bạn nghiêm chỉnh về học tập. Tôi mạnh mẽ tin tưởng vào học cả đời từ mọi cơ hội. Trước khi về nhà mỗi ngày, tôi bao giờ cũng dành vài khoảnh khắc để suy nghĩ về hoạt động trong ngày với ý định thu được cái nhìn sâu và học từ sai lầm của mình. Tôi bao giờ cũng nói với tổ của tôi và hỏi họ về xu hướng trong công nghiệp và cái gì là điều tôi phải biết. Tôi bao giờ cũng viết thư trao đổi với bạn bè, nhiều người là các giáo sư ở đại học, để biết họ đang làm loại nghiên cứu gì để cho tôi có thể học được từ họ. Tôi nghĩ tất cả chúng ta đều có thể làm cùng điều đó. Đừng để thời gian trôi qua mà không học. Tâm trí là thứ dễ phí hoài kinh khủng.

Hỏi: Tại sao chúng ta khoán ngoài phát triển phần mềm cho các công ti khác? Rủi ro của việc không xây dựng phần mềm trong nội bộ là gì?

Đáp: Xu hướng hiện thời ngày nay là khoán ngoài một phần việc phát triển phần mềm cho các công ti khác. Có nhiều lí do để làm điều đó như tổ chức có thể không có đủ tài nguyên để việc đó được thực hiện trong nội bộ, hay họ không  có các kĩ năng mấu chốt để làm nó. Tuy nhiên, khoán ngoài là kĩ năng rất đặc thù trong bản thân nó cần sự chú ý đặc biệt. Nếu công ti gặp thời kì khó khăn trong quản lí các dự án riêng của mình, đâu sẽ là cơ hội cho quản lí thành công dự án đi nửa đường quanh thế giới? Nếu yêu cầu tiếp tục thay đổi, làm sao bạn kiểm soát và quản lí được những thay đổi đó?

Khoán ngoài đòi hỏi nhu cầu về các yêu cầu được viết tốt – rõ ràng, chính xác, và kiểm tửh được. Điều rất quan trọng là đặt nỗ lực lớn vào hoạt động này để đi tới hợp đồng xác định rõ ràng phạm vi, vật chuyển giao, lịch biểu và cơ chế kiểm soát thay đổi. Điểm then chốt khác khi làm việc với các công ti khác là ở chỗ bạn phải có ít nhất nhiều kiểm soát và hiểu thấu vào điều đang diễn ra như bạn làm việc với nhóm riêng của mình. Quản lí và điều phối nhà cung cấp của bạn là vấn đề rất quan trọng. Đó là lí  do tại sao CMMI yêu cầu kĩ năng này ở mức 2 (Quản lí nhà thầu). Khi làm việc với nhà cung cấp, tổ chức phải có quyền đảm bảo rằng họ có cái nhìn sâu vào trong qui trình được dùng và tiến độ so với vật chuyển giao. Nếu nhà cung cấp không muốn cung cấp việc nhìn sâu đó để giảm nhẹ rủi ro của bạn, bạn có thể khôn ngoan nhìn sang nơi nào đó khác.

Khi vấn đề nảy sinh trong tình huống khoán ngoài, giải pháp thường được tìm trong chi tiết của hợp đồng. Điều không được viết ra có thể bị áp đặt. Do đó, bạn phải soạn thảo cẩn thận hợp đồng để tránh lâm vào điểm có vấn đề đó.

Hỏi: Có nhiều mô hình kinh doanh điện tử: doanh nghiệp với khách hàng Business to Consumer (B2C), doanh nghiệp với doang nghiệp Business to Business (B2B). Thế còn doanh nghiệp với chính phủ Business to Government (B2G) thì sao? Liệu có thị trường để làm kinh doanh điện tử với chính phủ không?

Đáp: Mặc dầu nhiều chính phủ đã bị tụt lại sau khu vực tư nhân trong việc vào trực tuyến, tôi tin thương mại điện tử doanh nghiêp với chính phủ, được biết là B2G hay G2B, là rất lớn. Nhiều công ti tư gần đây đã bắt đầu tổ chức các website chính phủ và xây dựng thị trường ảo của chính phủ. IBM gần đây đã cộng tác với chính phủ Mĩ để cung cấp tư vấn trực tuyến cho các cơ quan chính phủ và tạo ra website chính phủ để phục vụ nhu cầu công dân. Có việc tăng mạnh sự thừa nhận của chính phủ về giá trị của việc đưa mọi thứ lên web và giá trị chúng có thể đem lại cho các công dân. Nhóm Gartner ước lượng chi tiêu về thương mại điện tử của chính phủ liên bang, chính phủ bang và chính quyền địa phương sẽ tăng từ $1 tỉ đô la năm 2000 lên hơn $16 tỉ trong năm 2010. Có thể là thị trường B2G có thể trở thành thị trường thương mại điện tử lớn nhất thế giới, có thể làm giảm nhu cầu của chính phủ với nhân viên hành chính và cũng sinh ra thu nhập cho công ti xây dựng và giữ website của chính phủ.

Hỏi: Mĩ có còn là số một trong phần mềm hay Ấn Độ đã vượt qua chúng ta? Xin cập nhật cho chúng tôi về những xu hướng này.

Đáp: Vào lúc này, Mĩ vẫn dẫn đầu nhưng Ấn Độ không xa đằng sau. Nếu xu hướng này tiếp tục, trong vài năm tới, Mĩ và Ấn Độ có thể rất gần nhau.

Đây là một số dữ liệu: xuất khẩu phần mềm của Ấn Độ năm 2007 tổng $60 tỉ đô la Mĩ với 70% xuất khẩu sang Mĩ. Ngày nay các công ti của Ấn Độ như TCS, H.C.L, Wipro, và Infosys Technologies đều nổi tiếng ở Mĩ và trên thế giới. Xuất khẩu phần mềm Ấn Độ chiếm 24% kinh doanh này trên toàn thế giới. Người ta ước lượng rằng xuất khẩu của Ấn Độ năm 2010 sẽ tăng xấp xỉ $100 tỉ đô la, sẽ chiếm 30% thị phần kinh doanh phần mềm toàn thế giới. Nhân tiện, lương kĩ sư phần mềm Ấn Độ cũng đã tăng đáng kể trong vài năm qua do nhu cầu cao. Nhiều người không muốn làm chỉ lập trình mà đòi hỏi vai trò lớn hơn trong quản lí dự án, thiết kế hệ thống, và tích hợp qui mô lớn và họ đã khoán ngoài phát triển phần mềm cho các nước có chi phí thấp khác.

Hỏi: Tại sao chúng tôi cần làm tài liệu qui trình? Nó là hoạt động gia tăng giá trị hay chỉ để thoả mãn các yêu cầu CMMI?

Đáp: Kĩ nghệ phần mềm là kinh doanh nặng về tri thức. Tuy nhiên, tri thức này không được làm tài liệu cho người khác dùng nhưng được giữ trong đầu của người phát triển. Khi họ ra đi, họ đem tri thức của mình đi cùng họ và tri thức không được làm tài liệu bị mất. Tri thức là tài sản, giá trị, và sở hữu trí tuệ của công ti. Không có tài liệu, công ti thậm chí không biết loại tri thức nào mình bị mất.

Ta hãy hình dung rằng chúng ta có thể dùng lại mọi kinh nghiệm và tri thức về cách phát triển thành công phần mềm hay quản lí dự án. Điều đó sẽ mạnh mẽ và đáng muốn biết bao! Nắm bắt tri thức là điều việc làm tài liệu qui trình tất cả là gì – cách biểu diễn và cất giữ tri thức và công cụ nào dùng để thu nhận, cất giữ, tìm kiếm và truy lục tri thức và kinh nghiệm một cách hiệu quả và hiệu lực.

Nhân tiện, câu hỏi và câu trả lời này trên website này là cách khác để làm tài liệu và chia sẻ tri thức của tôi với tất cả các bạn.

Hỏi: Sao chúng ta cần kiểm điểm đều kì về hoạt động cải tiến? Nó có phải là quản lí vi mô không?

Đáp: Không, nó không phải là quản lí vi mô mà là cách hiệu quả để điều phối đầu tư của tổ chức vào cải tiến qui trình. Kiểm điểm đều kì về hoạt động cải tiến tạo khả năng cho người quản lí truy nhập vào tiến bộ cải tiến, vấn đề hiệu năng mấu chốt, phân tích kết quả cải tiến để vi chỉnh và tối ưu doanh nghiệp, thu lấy tính thấy được trong nhiệm vụ cải tiến và tác động của chúng lên hiệu năng của tổ chức.

—-English version—–

Question: Why do you advocate software process improvement using the CMMI framework? Why not other models?

Answer: There are several models to improve the software process but from my own perspective, a model is just a theory but it is the skills and experiences of people who use it to make things happen. Before decide to use the CMMI framework or something else, there are few factors that the organization should consider.

1.      There are empirical evidences that the CMMI framework does work and much of it published either in software journals and professional papers. There is no similar evidence on other improvement models. My question is why would an organization want to use something when we don’t know whether it will work or not?

2.      CMMI framework is really a family of models (Software, People, Acquisition, System integrated etc.) that have been adopted internationally and designed to complement one another. This richness of information has helped the CMMI to become the model of choice for many organizations all over the world.

3.      I worked with Watts Humphrey when he developed the SW-CMM at the Software Engineering Institute (SEI) and do have some insight into the five- level approach: Watts realized that there was a natural ordering to the problems an organization must solve to improve software practices. He realized that an organization must fix their schedule and project problems before solving engineering problems. Otherwise, the engineering practices would never have a chance to survive in the chaotic created by unreasonable schedules. Thus, if a Level 2 capability were not established, engineering practices would be sacrificed to schedule pressures.

4.      I found that other models only focusing on taking any single process and improving it, regardless of maturity level or capability of an organization. I believe allowing people to pick whatever they want to improve is naïve since management will never allow engineers to do whatever they like without concrete evidence that it will solve basic problems and deliver quality product within a certain time.

5.      I also believe any improvement in isolation without the entire organization involvement will lead to awkward situations: What would happen when you have the best testing process but work in an environment where software is released based on a fix schedule and frequently not tested. Imagine that the control charts that will be generated by a formerly stable process receive input from an out of control process. No engineering process can achieve its level of efficiency if it is disrupted by the chaos of the processes around it.

6.      From the management point of view, CMMI with five maturity levels makes sense because at level 4 the organization can determine which processes it believes are most critical to its business results and target those for statistical control. The organization can only do that after it has established a solid standard development process (OSSP- Level 3) that has the data and insight to determine which processes are the critical business drivers.

7.      Based on my own experiences, the strong benefits that have been demonstrated at Levels 4 and 5 require the organization established a full standard process (OSSP) that can be integrated with others’ processes to optimize the benefits—not just a few of the processes that people choose. The explosion of asset reuse and the level of schedule predictability observed at level 4 and the ability to innovate at level 5, all require that the organization has a solid standard process foundation (OSSP) that can be quantitatively managed and that people are trained to use that process. This cannot be accomplished by a single approach as other models advocates.

8.      By the way, the software industry has been trying to improve in this single piece approach for more than 30 years, with little or no success. Since the 1970s, people has selected individual processes (design, testing, coding etc.) and tried to improve them in isolation. The improvements did not survive because the organization did not solve its fundamental problem—controlling the project schedule. Watts Humphrey realized the need to prioritize the problems he had to solve. The maturity framework was a logical path to improving the whole development process.

9.      The CMMI models create different cultures at each maturity level. For example, Level 3 organizations can be observed to see how a professional culture took hold by the sharing of best practices. A culture is composed of many shared practices and the more people share, the better that culture will emerge. Other approach does not cause the organization to be pervaded by common practices, and as such does little to change the organization’s culture. Cultural change is very critical to institutionalizing the practices and achieving the benefits of process improvement.

I am sure in the future there could be better models but at this time, I know the CMMI works well in many organizations and that is why I advocate this model over others.

Question: My company is appraised last year at CMMI Level 1 by a consultant. My boss did not like the result so he hired another consultant. The new consultant came with many templates and documents for our company to use, including sample data and within ten months, he appraised my company as CMMI Level 5. What level do you think we should be at?

Answer: Without conduct an appraisal, I can not tell about the maturity level of your company. However, it is possible that the first consultant was honest and appraised your company as Level 1 since it does not have any documented processes. The second consultant brought in his own documents and templates then use them as evidences that your company already had all the documented processes as well as statistical data so he could appraise your company at higher level (Level 5). This could be considered “Cheating” and it is possible that he sold the maturity level at a price your company was willing to pay.

My issue is not with the consultant but with your boss. Why would he want to achieve something that the company is not and what is the reason for doing that? Does he want to advertise the company as a high maturity level with the hope that people will buy your products and services? In that case, he could save a lot of money by print out a piece of paper claiming that the company is a CMMI level 5 rather than pay the consultant.

I also think anyone who believes an “Advertising CMMI level” as a guarantee of high quality without verifying it, is not very smart. Basically, this kind of cheating is very naïve because most people do know what they are buying and would never do business with company that is intentionally cheating them by false advertising. When people saw companies claim to achieve a high maturity level and look at the quality of the work being delivered, they can tell the different and of course, they never do business with that company again.

Question: When planning software process improvement using the CMMI as the framework, what are the problems of going for Level 3 as opposed to achieve Level 2 as a prerequisite? I do not see the different if SEPG requires software people to follow a defined standard process.

Answer: The idea of SEPG “imposing” level 3 processes on a group of level 1 people who are not yet trained to follow a level 2 is very difficult. Imagine somebody come and tell all developers that the way they have been working so far is bad, and this is the new way, that the SEPG defined for them to follow and this is how we are working from now on. What do you think if you are a hard working developer?  Do you think that you will listen to someone that you do not know tell you how to do your job? Anyone can write Level 3 processes, policies, procedures, etc. but it takes a lot of knowledge and skills to understand how to change an organization within its unique collective behaviors.

Typically, at Level 1, nobody knows what works, what does not work since nothing is documented. It takes time to write down what developers do as a communication tool to really understand what really works, what does not work and how to improve them. This is the first step of all improvements; you must know where you are before you can go somewhere.

At level 2, there are number of things can be done without requiring that they be performed in a standard manner. All projects are requested to document their own processes rather than following something documented by another. As a consequence, the organization may have some diverse processes established in different projects. However, this is where the foundation is laid because these processes are created by the developers. Based on measurements data collected by the SEPG, they can determine on the efficiency and effectiveness of the various processes to identify what is working best. The SQA group will ensure that the metrics are well defined and correspond to the reality. This analysis of the existing Level 2 processes will allow the SEPG to consolidate and improve these processes into the standard best practices, leading to a level 3 organizational process.

The maturity levels of the CMMI are created based on many years of research at CarnegieMellonUniversity and they serve a purpose of allowing the organization to mature over time. Please do not skip level.

Question: As a Level 3, we have established organization standard process and provide training to all software people in our organization. We do not know what to do to achieve Level 4?

Answer: At CMMI Level 4, the improvement focus is broaden to both project and organization business.

At the organization level, you need to:

1)     Establish a performance baseline, which characterize the expected process performance of the organization’s standard processes.

2)     Set quality objectives for all software projects. For example no more than X defects per KLOC; no more than Y % variation between estimated plan vs. actual.

3)   Have the organization select processes or sub-process in the organization’s standard processes for performance analyses such as set control limit (upper & lower bound)

4)   Have the organization establish Process-Performance Measures by maintain definitions of the measures that are to be included in the organization’s process-performance analyses.

6) Have the organization selected the measures and analytical techniques to be used in statistically managing the selected process for all projects.

At the project level, you need to:

1)     Establish the project’s performance objectives such as set quality goals, quantitative process compliance goal (for example: Number of process under statistical control)

2) Select the sub-processes within the project’s defined process to be under statistical managed based on historical stability and capability data. You need to identify control limits by analyze your own data.

3) Analyze the collective performance of the project’s sub-processes to predict whether the project’s objectives for quality and process performance will be satisfied and identify the need for corrective action as appropriate.

4) Use calibrated process performance models to identify, analyze, and execute corrective action when necessary.

5) Identify and statistical manage performance of selected sub-processes within the project’s defined process by setting control limit.

6) Have SQA review to make sure project follow the measures and analytical techniques selected by the organization for managing its processes?

7) Establish an understanding of the variation of the selected sub-processes using the selected measures and analytical techniques.

8) Identify, address, and prevent reoccurrence of special causes of variation in the selected sub-processes.

9) Analyze the performance of the selected sub processes to predict their capability to satisfy their quality and process-performance objectives, and take corrective action as necessary.

10) Record statistical and quality management data in the organization’s measurement repository for future analysis.

11) Select certain data for analysis, using established criteria.

12) Analyze common causes of variation to understand the inherent quality and process performance constraints.

The following are addressed at CMMI level 5, but I think at Level 4 you can do it concurrently rather than serially:

13) Conduct causal analysis on selected problems to determine their root causes (This is more a Level 5 but you can do it even at level 4)

14) Propose actions to address selected common causes of variation and to prevent recurrence of selected problems in the organization.

15) Submit process- and technology-improvement proposals based on historical data and project performance analysis?

Question: Is it possible to have developers in project performing both SQA and Peer Review functions? Why and why not?

Answer: The term Peer Reviews, as its name implies, are done by “Peers” or people who are working on the project with you to INFORMALLY review your work to determine if it is good but will not evaluate you or verify your products for formal acceptance. Such reviews are done for the purpose of detecting, as early as possible, any problems in your software artifacts (plan, design, code, etc.).

SQA is done by people who are in a position to verify OBJECTIVELY the software products and processes.  You we must not forget that the intent of SQA is requiring an OBJECTIVE view and should NOT be biased so SQA should NOT be performed by people who work on the project.

Question: My company is appraised at CMMI Level 5. What should we do next? Is there a Level 6? I think level 4 and 5 are easy to achieve than level 2 or 3. What do you think?

Answer:

If you are successful, the momentum would be there and I am not surprised at your enthusiast to continue to the next level. Based on my experiences, organizations that have been successful in process improvement and master all the process areas of level 2 and 3 can move faster in the next two levels. Some could even work on process areas of Level 4 and Level 5 concurrently rather than serially. I think the Causal Analysis and Resolution can be done at Level 4 since Level 4 is focusing on using data to improve the organization business. Identify the cause of problems and eliminate them is the right thing to do and do not need to wait until Level 5.

I believe the focus of Level 5 is on sustaining excellence by a demonstration of measurable and performance excellence. At level 5, the organization is fully matured by having consistent performance in every aspect. The issue here is how to sustain the momentum of software excellence in a rapidly changing environment.

Question: How do you measure software size if you do not use Line of code (LOC) or Function Point (FP)?

Answer: The size measure can vary in the software life cycle. For example, the size measure of the requirements phase is the number of requirements. The size measure of design phase is the number of design elements. The size measure of implement phase is the number of lines of code, subroutines, object or class of object in the completed source code.

Question: As a student, I really enjoy your software engineering classes at Carnegie Mellon but I am working now and do not have time to learn more.

Answer: All of us are busy with our daily life of balancing between work and family. Not many can afford to take time out for the training that is essential to stay current with technology. We know that to stay competitive in the changing time as an individual, ongoing learning is a critical component to success. It is important to know the trends in the industry, to know what is important and what is not, and to continue to learn and grow both as a person and a professional. However, learning does not necessarily mean you have to attend classes. You can learn a lot from your daily activities, from your projects, from others and from your friends. The opportunity to learn is endless if you are serious about learning. I am strongly believed in lifelong learning from every opportunity. Before going home each day, I always spend a few moments to reflect on the day’s activities with the intent to gain insight and learn from my mistakes. I always talk to my team and ask them about the trends in the industry and what are things that I should know. I always correspondent with my friends, many are professors in universities, to know what kind of research that they are doing so I can learn from them. I think all of us can do the same. Do not let time go by without learning. A mind is a terrible thing to waste.

Question: Why are we outsourcing software development to other companies? What are the risks of not building software internally?

Answer: The current trend today is to outsource part of the software development to other companies. There are many reasons for doing it such as the organization may not have enough resources to get the job done internally, or they do not have the critical skills to do it. However, outsourcing is a very special skill in itself that needs special attention. If the company has a difficult time managing their own projects what would be the chance of successfully managing a project half way around the world? If the requirements continue to change, how would you control and manage those changes?

Outsourcing requires the need for well-written requirements—clear, concise, and testable. It is very important to put significant effort into this activity to come up with a contract that clearly specifies scope, deliverables, schedule, and change control mechanism. Another key point when working with other companies is that you should have at least as much control and insight into what is going on as you would with your own group. Managing and monitoring your suppliers are very important issues. That is why CMMI requires this skill at Level 2 (Subcontract Management). When working with suppliers, the organization must have the right to ensure that they have insight into the process being used and the progress against the deliverables. If the supplier does not want to provide that insight to mitigate your risk, you may be wise to look elsewhere.

When problems arise in a outsourcing situation, a solution is often sought in the details of the contract. What is not written can not be enforced. Therefore, you must carefully craft your contract to avoid getting to that problem point.

Question: There are several e-business models: Business to Consumer (B2C), Business to Business (B2B). What about Business to Government (B2G)? Is there a market to do e- business with government?

Answer: Although several governments have lagged behind the private sector in the rush to get on-line, I believe business-to-government e-commerce, known as B2G or G2B, is very big. Several private companies have recently begun hosting government web sites and building government virtual marketplaces. IBM recently collaborated with U.S Government to provide online consulting for government agencies and create government web sites to serve the needs of citizens. There is a dramatic increase in the government’s recognition of the value of putting things on the web and the value they can bring to its citizens. The Gartner Group estimates spending on e-commerce by federal, state, and local governments will increase from $1 billion in 2000 to more than $16 billion in 2010. It is possible that the B2G market may become the largest e-commerce market in the world possibly reducing the government’s need for administrative staff and also generating revenue for companies that build and host government sites.

Question: Does the U.S. remains number one in software or has India passed us by? Please keep us up to date on these trends.

Answer: At this time, the U.S still has the lead but India is not far behind. If the trend continues, in the next few years, U.S and India could be very close.

Here are some data: India’s software exports in 2007 totaled $60 billion U.S. dollars with 70% of the exports going to the U.S. Today India’s companies such as TCS, H.C.L, Wipro, and Infosys Technologies are well known in the U.S. and in the world. India’s software exports were 24% of the worldwide business. It is estimated that in 2010 India’s exports will increase to approximately $100 billion, which will amount to 30% share of worldwide software business. By the way, Indian software engineers’ salaries also increased significantly in the past several years due to high demand. Many no longer want to do just programming but demand a bigger role in project management, system design, and large-scale integration and they already outsource software development to other lower cost countries.

Question: Why do we need to document a process? Is it a value-added activity or just to satisfy the CMMI requirements?

Answer: Software Engineering is a knowledge intensive business. However, this knowledge is not documented for others to use but kept in the heads of developers. When they leave, they take their knowledge with them and the undocumented knowledge is lost. Knowledge is the asset, the value, and the intellectual property of the company. Without documentation, the company does not even know what kind of knowledge they lost.

Let’s imagine that we can reuse all the experience and knowledge of how to successfully develop software or manage projects. How powerful and desirable that would be! Capturing knowledge is what process documentation is all about—how to represent and store knowledge and what tools to use to acquire, store, search, and retrieve knowledge and experience effectively and efficiently.

By the way, this questions and answers in this website is another way of documenting and sharing my knowledge with all of you.

Question: Why do we need periodic review of improvement activities? Is it micro management?

Answer: No, it is not micro management but an effective way of monitor organizational investment in process improvement. Periodic reviews of improvement activities enables manager to assess improvement progress, critical performance issues, analyze improvement results for fine-tuning and optimizing the business, gain visibility into improvement tasks and their impact on organization’s performance.