Đáp: Theo định nghĩa, năng lực lõi là tổ hợp của công nghệ và kĩ năng để tạo ra sản phẩm và dịch vụ mà tạo cho tổ chức ưu thế cạnh tranh trong thị trường. Năng lực lõi không phải là một thứ mà là tổ hợp của tri thức, kĩ năng và qui trình. Tri thức là phân tích về dữ liệu, thông tin, nguyên lí và áp dụng chúng để đạt tới cái gì đó. Kĩ năng là tài năng tới từ nhiều năm đào tạo và thực hành (kinh nghiệm). Qui trình là chuỗi các hoạt động được xác định rõ hướng tới kết quả cuố icufng.

Năng lực lõi là quan trọng bởi vì nó là ưu thế chiến lược dựa trên tri thức duy nhất mà vài tổ chức có.

Hỏi: Kiểm soát chất lượng (QC) có là một với đảm bảo chất lượng (SQA) không?

Đáp: Kiểm soát chất lượng (QC) là chuỗi các hoạt động như giám định, kiểm điểm, kiểm định và kiểm thử trong toàn bộ vòng phát triển để đảm bảo rằng từng sản phẩm công việc đáp ứng yêu cầu được đặt lên nó. Kiểm soát chất lượng bao gồm chu trình phản hồi về qui trình tạo ra sản phẩm. Tổ hợp của việc đo và phản hồi cho phép mọi người cải tiến qui trình khi sản phẩm không đáp ứng yêu cầu. Kiểm soát chất lượng được sử dụng rộng rãi trong qui trình chế tạo nơi từng bước chế tạo có thể được đo dễ dàng.

Đảm bảo chất lượng phần mềm (SQA) bao gồm kiểm điểm, kiểm định về vòng đời phần mềm rồi cung cấp thông tin này cho cấp quản lí. Chính trách nhiệm của cấp quản lí là đề cập tới những vấn đề này và có hành động sửa chữa. Phát triển phần mềm khác với qui trình chế tạo bởi vì không phải mọi bước đều có thể được đo vì nó giải quyết với sản phẩm vô hình và trí tuệ.

Việc của SQA là kiểm điểm các kế hoạch về sự đầy đủ, kiểm tuân thủ chuẩn, và kiểm điểm tuân thủ qui trình và cung cấp thông tin cho cấp quản lí.

Hỏi: Có ích lợi gì khi tuân theo qui trình chuẩn của tổ chức? Tại sao mọi người không thể tuân theo qui trình riêng của họ vì họ biết cách phát triển phần mềm và không cần ai đó bảo họ điều phải làm?

Đáp: Khi được thiết kế đúng, qui trình phần mềm chuẩn của tổ chức (OSSP) hướng dẫn các kĩ sư phần mềm khi họ làm việc như thành viên tổ dự án và đảm bảo rằng mọi người hiểu vai trò, trách nhiệm của họ và có khả năng tiến hành công việc của họ một cách nhất quán. Một tổ không tuân theo qui trình chuẩn hay mọi người có qui trình riêng của họ cũng giống như một tổ thể thao nơi từng người đi theo qui tắc riêng; một số theo qui tắc bóng đá trong khi số khác dùng qui tắc của bóng rổ hay bóng chày. Cho dù họ là những cầu thủ rất giỏi, tổ sẽ không bao giờ thành công.

Tương phản lại, một tổ tuân theo qui trình chuẩn nhất quán có thể lập kế hoạch tốt hơn, phối hợp công việc của riêng từng thành viên tổ và theo dõi tiến bộ của họ tương ứng. Đặc biệt hơn, qui trình phần mềm chuẩn của tổ chức (OSSP) thiết lập ra khuôn khổ kĩ nghệ, quản lí và hỗ trợ cho áp dụng các phương pháp, công cụ và phân công người cho các nhiệm vụ phần mềm thích hợp. Nó còn thiết lập thêm cách đo và cung cấp các tiêu chuẩn vào và ra cho mọi bước trong vòng đời phần mềm.

Như đã được nhắc tới ở trên, qui trình phần mềm chuẩn của tổ chức (OSSP) phải là thiết kế đúng điều ngụ ý nó phải được xây dựng trên cái gì đó đã có tác dụng hay “thực hành tốt nhất”. Nó phải linh hoạt và năng động bởi vì khi thực hành tốt hơn được tìm ra, chúng sẽ được tổ hợp vào trong qui trình chuẩn do vậy cho phép qui trình của tổ chức tiến hoá và mọi người tiếp tục học những điều mới. Một OSSP thành công không chỉ là tài liệu mà cũng là công cụ, cái gì đó người hành nghề truy nhập tới nó để tham chiếu bởi vì nó chứa thông tin hữu dụng như ví dụ, khuôn mẫu, danh sách kiểm và lời mách nước.

Bên cạnh đó, OSSP cũng là công cụ trao đổi bởi vì nó thiết lập ra ngôn ngữ chung nơi mọi người có thể trao đổi với nhau đặc biệt là người dùng, người phát triển, người quản lí, khách hàng và người hỗ trợ chức năng. Nó thúc đẩy hiểu biết tốt hơn; cung cấp cơ sở cho ước lượng, tự động hoá và học những điều mới. Nó cũng tạo điều kiện cho việc dùng lại và tránh dư thừa trong các dự án. Việc phát triển phần mềm là rất tốn thời gian và tốn kém nếu từng dự án tiếp tục xác định qui trình riêng của nó và xây dựng mọi thứ từ đầu.

Hỏi: Vì công nghệ cứ thay đổi mãi, làm sao tôi có thể sống còn được vì kĩ năng của tôi bị lạc hậu?

Đáp: Trong thế giới thay đổi nhanh chóng của thời đại thông tin, mọi người phải liên tục học những điều mới, kĩ năng mới để sống còn và đây là điều học cả đời tất cả nghĩa là gì.

Tôi nghĩ bạn cần đánh giá bạn đang ở đâu bây giờ. Bạn đã học được gì qua tới trường chính thức và theo cách riêng của bạn?  Bạn cần liệt kê những thành thạo của bạn hay điều bạn rất giỏi. Bạn cũng cần nhận diện chuyên môn của bạn hay khu vực bạn hiểu rõ. So sánh điều đó với xu hướng hiện thời trong công nghiệp và nhận diện lỗ hổng trong tri thức của bạn.  Bạn cần học cái gì để tồn tại trong việc làm của mình và thịnh vượng trong tương lai?  Bạn muốn có thể làm được cái gì trong ba, năm hay mười năm nữa kể từ bây giờ? Loại học tập nào đó có chuyển bạn tới gần hơn việc nhận ra mục đích nghề nghiệp của bạn không?

Học không có nghĩa là bạn phải quay lại trường nhưng có thể là trong việc làm hay đào tạo tại nhà. Bạn cần chọn lựa một trong những điều khớp với bạn nhất. Bạn có thể kiểm những đào tạo tại nhà về chủ đề bạn cần hay yêu cầu đồng nghiệp dạy cho bạn một kĩ năng mà họ đã làm chủ. Bắt đầu dự án học tập cộng tác với vài người vì học nhóm là đặc biệt hiệu quả. Đều đặn, tái đánh giá kế hoạch học tập của bạn. Thay đổi bên trong tổ chức của bạn hay phát triển công nghệ mới có thể gợi ý việc sửa đổi giữa chừng. Trong thời đại thay đổi nhanh chóng này, bạn cần làm kế hoạch.

Hỏi: Dường như là Motorola rất thành công với Six-Sigma. Tại sao chúng ta không thể dùng kĩ thuật này cho cải tiến phần mềm của chúng ta?

Đáp: Six-Sigma là kĩ thuật hệ thống làm cho Motorola rất thành công trong qui trình chế tạo của họ và một số người tin nó cũng có thể áp dụng được cho bất kì qui trình nào kể cả phần mềm.

Nói chung, Six-Sigma bao gồm hai phần:

1) Vòng đời để làm những cải tiến có tên là DMAIC (Define the To be or problem- xác định cái phải có hay vấn đề, Measure the current or As Is performance – Đo hiện thời hay hiệu năng như đang vậy, Analyze gaps between current performance and target performance – phân tích lỗ hổng giữa hiệu năng hiện thời mà hiệu năng nhắm tới, Implement the improvements and Control the process – thực hiện cải tiến và kiểm soát qui trình).

2) Áp dụng các kĩ thuật phân tích thống kê vào dữ liệu đã thu thập trong pha đo (như, sơ đồ chạy, phân tầng, phân tích căn nguyên và giới hạn kiểm soát) và làm chúng thành thấy được cho quản lí cấp cao có hành động.

Dựa trên kinh nghiệm riêng của tôi, khối lượng giá trị mà một tổ chức có thể đưa tới từ Six Sigma là phụ thuộc vào qui trình hiện thời của nó trưởng thành thế nào. Nếu tổ chức vẫn ở CMM mức 1 hay 2, tôi nghĩ Six-Sigma không thể có ích được.

Hỏi: Làm sao thầy thuyết phục được các thành viên SEPG người không tin vào cải tiến mà chỉ tin vào bất kì cái gì họ thích làm?

Đáp: Nếu những người có trách nhiệm làm cho cải tiến xảy ra như SEPG mà không tin vào cải tiến thì tổ chức không bao giờ cải tiến được. Khởi đầu, không phải mọi người đều sẽ tin vào cải tiến bởi vì điều tự nhiên là ngần ngại. Có lẽ có một số người đã từng trải qua cải tiến thất bại điều để lại cho họ rất thất vọng cho nên họ không tin nó có thể xảy ra. Với những người này, bạn phải chứng minh cho họ rằng kỉ luật kĩ nghệ và kế hoạch cải tiến tốt có thể thực sự đem tới thay đổi cho tổ chức.

Bạn phải giải thích cách nó làm việc, cách các tổ chức khác đã đạt tới thành công bằng việc tuân theo qui trình được xác định và bổ sung kỉ luật vào cách họ xây dựng phần mềm thì có thể họ muốn “cho nó việc thử khác”. Tất nhiên, có những người không tin vào cái gì, chẳng thành vấn đề bạn làm gì vì họ chỉ quan tâm tới bản thân họ và thích làm bất kì cái gì họ muốn làm. Nếu họ được cho phép đưa ra hoài nghi về cải tiến hay có thái độ tiêu cực đối với nỗ lực của tổ thì họ phải được yêu cầu ra đi. Nếu bạn không thể thuyết phục được tổ làm việc cùng nhau hướng tới mục đích và chiều hướng chung thì bạn cứ quay bánh xe, phí thời gian và nỗ lực bởi vì thay đổi sẽ không bao giờ xảy ra.

Hỏi: Khác biệt gì giữa người quản lí dự án và người quản lí dự án phần mềm?

Đáp: Quản lí dự án phần mềm là kĩ năng đặc biệt khác với quản lí dự án khác bởi vì phần mềm là vô hình và quản lí cái gì đó mà khó thấy hay sờ thấy yêu cầu kinh nghiệm và đào tạo nhiều.

Phần mềm, giống như mọi công việc tri thức, có mối quan hệ phi tuyến quan trọng giữa nỗ lực, thời gian, tính năng, chất lượng và điều đó làm cho lập kế hoạch và giám sát dự án thành khó khăn hơn nhiều. Chẳng hạn, nếu tôi xây nhà, tôi có thể biết rằng ngôi nhà được hoàn thành 30% hay 80% khá chính xác nhưng tôi không thể biết được liệu dự án phần mềm được hoàn thành 30% hay 80%. Với những thứ vật lí, yêu cầu bao giờ cũng vững chắc bởi vì khách hàng biết đích xác điều họ muốn nhưng với cái gì đó vô hình như phần mềm thì khó mà hình dung ra, các yêu cầu chưa bao giờ vững chắc mà cứ thay đổi luôn làm cho dự án phần mềm thành khó quản lí.

Đào tạo quản lí dự án hiện thời được dạy trong đại học dựa nặng vào thứ tự tuần tự và quan hệ tuyến tính giữa các vật là không phù hợp cho quản lí dự án phần mềm. Đào tạo quản lí dự án phần mềm là rất khác và yêu cầu cả tri thức kĩ thuật và kĩ năng quản lí như quyền lãnh đạo, trao đổi, doanh nghiệp, bán hàng và tiếp thị.

Năm ngoái, tôi đã dạy một lớp quản lí phần mềm cho vài người quản lí dự án có kinh nghiệm. Phần lớn sinh viên của tôi đều nói rằng đây là lần đầu tiên họ có khả năng tạo ra bản kế hoạch dự án với các mục đích bên cạnh lịch biểu; họ có khả năng bảo vệ kế hoạch dự án và chống lại sức ép từ khách hàng để làm các cam kết lịch biểu không hiện thực. Họ có khả năng nhận diện tài nguyên được cấp quản lí cam kết phân bổ cho các dự án khác vì rủi ro tiềm năng lớn nhất của chúng. Họ cũng thấy rằng thành viên tổ có thể không có khả năng dành thời gian cho nhiệm vụ theo tỉ lệ được lập kế hoạch của họ quãng 20 giờ một tuần cho thành viên tổ.

Không ai nhận diện bất kì vấn đề kĩ thuật nào là sự tố rủi ro chính để mà hài lòng với. Đến cuối lớp, phần lớn các sinh viên của tôi đều ủng hộ cho quan niệm rằng nếu họ không quản lí chất lượng, họ không thể quản lí được dự án. Sau lớp, tất cả họ đều bảo tôi rằng họ đã có khả năng thêm bản kế hoạch chất lượng về các mục đích đo được vào trong bản kế hoạch dự án và hội tụ nhiều hơn vào phát hiện sớm và loại bỏ lỗi và không dựa quá nhiều vào kiểm thử. Nhiều người gọi điện cho tôi vài tháng sau và bảo tôi rằng dự án phần mềm của họ đã được hoàn thành thành công dựa trên điều họ đã học trong lớp và được thực hành.

Tháng trước, tôi thấy dữ liệu sau từ tạp chí Phố WalL, Wall Street Journal: Năm 2001, chính phủ Mĩ chi tiêu hàng năm về công nghệ thông tin là $81 tỉ đô la nhưng gần nửa các dự án đã bị huỷ bỏ; $40 tỉ đô là có vấn đề. Nghiên cứu mới nhất của chính phủ Mĩ cũng ước lượng rằng tác động của lỗi phần mềm lên công nghiệp Mĩ là quãng $22 tỉ đô la hàng năm.  Với tôi dường như là con số còn nhiều hơn, chúng ta cần đào tạo nhiều người quản lí dự án phần mềm hơn chứ không chỉ bất kì người quản lí nào.

Hỏi: Tại sao nhiều công ti khoán ngoài phần mềm của họ ra nước ngoài? Đó là vì chi phí hay chất lượng?

Đáp: Một số tổ chức đã khoán ngoài vì tiết kiệm chi phí, số khác khoán ngoài vì yêu cầu chất lượng. Tuy nhiên, có sự tố khác mà mọi người hiếm khi nói tới: “Việc chán ngán triệu chứng anh hùng.” Nhiều tổ chức, đặc biệt tổ chức trưởng thành mức rất thấp dựa nặng nề vào các cá nhân với bất kì năng lực phần mềm nào họ có. Bất kì khi nào những người đó bỏ đi, tổ chức mất năng lực đó (hay các bộ phận từ đó).

Để giữ họ, tổ chức phải trả lương theo tỉ lệ trên trung bình cho các cán bộ then chốt với tri thức mấu chốt và điều này giúp tạo ra văn hoá “anh hùng” nơi các anh hùng bao giờ cũng được thưởng nhưng điều này làm hại cho doanh nghiệp vì đãi ngộ cao của họ. Đó là lí do tại sao khoán ngoài đã trở thành rất phổ biến ngày nay nơi các tổ chức có thể tiến hành kinh doanh ở nơi lao động sẵn lòng, có khả năng và động cơ làm việc với trả lương thấp hơn nhiều và đưa nhiều ‘anh hùng” ra khỏi doanh nghiệp.

Hỏi: Tại sao lỗi xuất hiện? Nó là vì qui trình hay lỗi con người?

Đáp: Câu trả lời là cả hai. Có vài nguyên nhân cho lỗi:

Giáo dục: Mọi người không hiểu cách làm cái gì đó

Trao đổi: Mọi người không được thông tin đúng về cái gì đó

Giám sát: Mọi người bỏ không làm cái gì đó

Ghi chép: Mọi người biết điều phải làm nhưng phạm sai lầm khi làm nó

Qui trình: Qui trình của họ bằng cách nào đó dẫn sai hành động của họ

Hỏi: Làm sao chúng tôi thoả mãn được yêu cầu về thiết lập cách đo và độ đo khi sản phẩm của chúng tôi là ứng dụng website? Tôi nghĩ chúng ta không thể đo được ứng dụng web.

Đáp: Ngược lại, thu thập cách đo cho ứng dụng web là dễ thế do bản chất của phương tiện số thức.

1) Khi mọi người lướt web, họ bao giờ cũng để lại dấu vết ghi lại nơi họ đã tới. Nhóm của bạn có thể thu lấy những dữ liệu này để tối ưu kết cấu nền của bạn, cải tiến kiến trúc website của bạn, và đo tính hiệu quả của thiết kế website.

2) Mỗi lần ai đó trên web yêu cầu một trang từ một nguồn phục vụ, nguồn phục vụ ghi lại yêu cầu đó và các thông tin đa dạng liên kết với biến cố đó. Dữ liệu này có thể được thu thập trong tệp sự kí cho phân tích tương lai để hiểu hình mẫu sử dụng của trạm.

Tất nhiên, sự kiện rằng hoạt động trên web có thể được đo là không đủ nhưng tôi nghĩ cách đo cần có nghĩa. Bạn phải phân tích dữ liệu được thu thập để cho thông tin có nghĩa. Tôi nghĩ thu thập dữ liệu và phân tích hoạt động của web chỉ mới bắt đầu từ đầu trên bề mặt của điều có thể là khả năng trong tương lai như dùng sự kí nguồn phục vụ làm nền tảng, dữ liệu phụ có thể được thu thập để theo dõi các hoạt động bất hợp pháp và lạm dụng với nguồn của sự cố chính bao gồm cả vi rút máy tính và thư rác SPAM

Hỏi: Làm sao thầy phân loại dự án phần mềm là nhỏ, vừa hay lớn? Tôi đã làm việc trên dự án kéo dài xấp xỉ quãng  2 tới 4 tuần, nó là dự án cỡ nhỏ hay vừa?

Đáp: Có nhiều cách phân loại dự án phần mềm nhưng tôi nghĩ thời hạn 2 tuần có thể được xét cho dự án nhưng có lẽ là cho nhiệm vụ của dự án lớn hơn.

Theo kinh nghiệm của riêng tôi, tôi xét thời hạn xấp xỉ 6 tới 12 tháng là dự án nhỏ; từ 12 tới 24 tháng là dự án cỡ trung bình; và từ 24 tới 48 tháng hay hơn là dự án lớn. Một số người không dùng thời hạn hay thời gian để phân loại dự án mà dùng nỗ lực hay số người được cần để hỗ trợ cho một dự án để xác định phân loại dự án. Dự án nhỏ điển hình yêu cầu xấp xỉ 5 tới 25 người; dự án cỡ trung yêu cầu 25 tới 100 người và dự án lớn sẽ yêu cầu 100 tới 300 người. Có các phương pháp khác xem xét số yêu cầu hay đòi hỏi thay đổi đối với việc đưa ra phần mềm là cách xác định phân loại dự án. Chẳng hạn dự án nhỏ có thể có 20 tới 250 đòi hỏi thay đổi; cỡ trung có thể có 250 – 500 đòi hỏi thay đổi; và dự án lớn có thể có 500 tới 2,000 đòi hỏi thay đổi. Nhớ lấy, tất cả những phân loại này đều tương đối và có thể khác biệt từ ứng dụng nọ sang ứng dụng kia.

Hỏi: Việc đo chính cho tổ chức mức 2 là gì? Khi nào chúng ta cần lấy hành động sửa chữa?

Đáp: Ở mức 2, hội tụ là vào quản lí dự án và việc đo chính là kích cỡ, chi phí, nỗ lực, lỗi và lịch biểu của dự án. Trong lập kế hoạch dự án phần mềm và theo dõi dấu vết dự án phần mềm và giám sát các KPA, có các thực hành mô tả ước lượng, theo dõi vết và ước lượng lại cho những việc đo này và có hành động sửa chữa khi cần và ghi lại chúng cho cải tiến tương lai. Với một số dự án bảo trì, kích cỡ của phần mềm là tương đối dễ thu thập nhưng với dự án mới nó có thể là khó cho nên nhiều người dùng nỗ lực thay vì kích cỡ là cái chuẩn hoá.

Theo dõi dấu vết bao gồm giám sát hiệu năng thực tế đối với hiệu năng được lập kế hoạch (được lập kế hoạch so với thực tại qua thời gian).  Hành động sửa chữa được tiến hành khi hiệu năng thực tại bắt đầu lệch đáng kể khỏi ước lượng và nó thường bao gồm việc sửa đổi lại ước lượng và kế hoạch. Điều được ngụ ý bởi “lệch đáng kể” mang tính chủ quan và tuỳ thuộc vào tình huống, độ lệch 5 ngày so với dự án một năm không phải là mối bận tâm chính nhưng lệch 5 ngày cho dự án một tháng là đáng kể rồi.

Hỏi: Hệ thống mở là gì? Chúng tôi có nên dùng hệ thống mở trong phát triển ứng dụng của chúng tôi để tiết kiệm tiền không?

Đáp: Hệ thống mở là khái niệm có thể cung cấp việc phát triển hệ thống nhanh hơn và kinh tế hơn, điều là cập nhật công nghệ. Hệ thống mở là tuyển tập các cấu phần phần mềm tương tác, phần cứng và con người:

1)    Được thiết kế để thoả mãn nhu cầu với đặc tả giao diện của các cấu phần của nó đã được xác định đầy đủ

2)    Sẵn có cho công chúng và

3)    Được bảo trì theo sự thống nhất nhóm trong đó việc thực hiện các cấu phần tuân thủ theo đặc tả giao diện

Niềm tin thông thường về ưu thế dùng hệ thống mở bao gồm những điều sau:

1)    kém tin cậy về sản phẩm sở hữu riêng

2)    nhiều cạnh tranh dẫn tới chi phí thấp

3)    xác suất giảm đi về chậm trễ lịch biểu

4)    sản phẩm được kiểm thử tốt hơn (nhiều người dùng)

5)    ứng dụng khả chuyển

6)    liên tác

7)    chèn thêm công nghệ nhanh hơn

8)    nền tảng cho tiến hoá hệ thống

Tuy nhiên, đây chỉ là ưu thế “theo nghĩa thông dụng”. Chưa có bằng chứng được làm tài liệu định lượng dựa trên hệ thống mở thực để chứng minh chúng.

Vì không có nghiên cứu khoa học nào để đánh giá hệ thống mở, khó bàn về tiết kiệm được bao nhiêu tiền bằng việc dùng cách tiếp cận hệ thống mở. Câu trả lời có thể là “không”, đặc biệt trong ngắn hạn hay từ cảnh quan của chỉ một chương trình hay hệ thống. Tới nay, không tiết kiệm chi phí nào đã được chứng minh. Điều này là do nhiều sự tố, kể cả: thời gian ngắn mà hệ thống mở đã được phát triển, thiếu chỉ báo rõ ràng về chi phí để được theo dõi vết; và khó khăn trong việc tách bạch chi phí liên kết với hệ thống mở từ các chi phí liên kết với các khía cạnh khác của cách tiếp cận toàn diện

Hỏi: Chúng tôi thường nghe nói về thất bại dự án phần mềm nhưng sự tố mấu chốt là gì cho dự án phần mềm thành công?

Đáp: Dự án phần mềm thường thất bại bởi vì chúng ta không nhận ra kỉ luật của kĩ nghệ phần mềm và qui trình của nó mà tiếp tục phản ứng với sức ép của lịch biểu không hiện thực và yêu cầu không hợp lí của khách hàng.

Tôi tin có các sự tố then chốt mà tất cả các dự án thành công đều có chung như cam kết của quản lí cấp cao, qui trình được xác định rõ và quyền lãnh đạo kĩ thuật có kinh nghiệm.

Tôi nhiệt thành tin tưởng rằng cam kết của cấp quản lí là sự tố thành công mấu chốt nhất. Cam kết có nghĩa là hiểu biết, chấp nhận và hỗ trợ. Không có cam kết đầy đủ từ cấp quản lí, khi vấn đề nảy sinh trên dự án, dự án sẽ sụp đổ.

Phần lớn các dự án phần mềm đều được xây dựng với ít suy nghĩ tới qui trình. Tổ họp lại cùng nhau và bắt đầu thực hiện các hoạt động. Ngay khi đủ thông tin được thu thập, viết mã bắt đầu. Việc thiếu chú ý tới qui trình này có thể giết chết dự án rất nhanh chóng. Dễ dàng thấy kết quả của việc thiếu chú ý tới qui trình sau khi dự án thất bại. Thông thường những phần chính của yêu cầu người dùng bị bỏ qua hay thiết kế không tính tới các yêu cầu thay đổi thường xuyên. Nhiều người tin qui trình chỉ là gánh nặng bị áp lên họ nhưng điều quan trọng của qui trình là giữ cho dự án được tổ chức theo cách nhất quán và hội tụ và suy nghĩ qua qui trình một cách cẩn thận ngay từ đầu dự án. Tất nhiên, không phải mọi qui trình đều hoàn hảo nhưng nếu một qui trình có lỗi, thường nó bị lỗi không nghiêm trọng và bất kì qui trình nào cũng là tốt hơn không có qui trình nào cả.

Cũng như toà nhà cần kiến trúc sư, dự án phần mềm cần người lãnh đạo kĩ thuật. Để thành công, người lãnh đạo kĩ thuật phải là người kiểm soát “kiến trúc” của dự án, có nghĩa là mô hình dữ liệu và thiết kế ứng dụng. Mức kiểm soát này phải được thừa nhận và chấp nhận bởi mọi người tham gia vào dự án. Bằng không, từng phần của hệ thống có thể được xây dựng một cách độc lập bởi một phần của tổ và các mảnh sẽ không khớp với nhau vào lúc cuối.

English version

CMMI-38

Question:

What is core competency? Why is it important to an organization?

Answer:

By definition, core competency is the combination of technology and skills to create products and services that give an organization competitive advantage in the market place. Core competency is not a single thing but a combination of knowledge, skills and processes. Knowledge is the analysis of data, information, principles and applies them to achieve something. Skill is talent comes from years of training and practices (Experiences). Processes are series of well defined activities directed toward an end-result.

Core competency is important because it is a strategic advantage based on unique knowledge that few organizations have.

Question:

Is quality control (QC) the same as quality assurance (SQA)?

Answer:

Quality control (QC) is a series of activities such as inspections, reviews, audits and tests to be used throughout the development cycle to ensure that each work product meets the requirements placed upon it. Quality control includes a feedback loop to the process that created the product. The combination of measurement and feedback allow people to improve the process when the products failed to meet the requirements. Quality control is widely used in manufacturing process where each steps of the manufacturing can be measured easily.

Software Quality Assurance (SQA) consists of reviews, audits of the software life cycle then provides these informations to management. It is management’s responsibility to address these problems and take corrective actions. Software development differs from manufacturing process because not all steps can be measured since it deals with an intangible and intellectual product.

The job of SQA is review plans for completeness, check for standard compliances, and review for process adherence and provide information to management.

Question:

What is the benefit of following an organizational standard process? Why can’t people follow their own process since they know how to develop software and do not need someone tell them what to do?

Answer:

When properly designed, the organizational standard software process (OSSP) guides software engineers as they work as a project team members and ensure that everyone understand their roles, responsibilities and be able conduct their work consistently. A team that does not follow a standard process or everybody has his or her own process is like a sport team where each member follows different rules; some follow football rules when other uses basket ball or baseball rules. Even they are very good players, the team will never succeed. In contrast, a team that follows consistent standard process can better plan, coordinate the work of individual team members and track their progress accordingly. More specifically, the organizational standard software process (OSSP) sets out the engineering, management and support framework for applying methods, tools, and assign people to appropriate software tasks. It further establishes measures and provides entry and exit criteria for every step in the software life cycle.

As mentioned above, an organizational standard software (OSSP) process must be properly design that means it should be built on something that already works or “Best practices”. It must be flexible and dynamic because when better practices are found, they will be incorporated into the standard process thus permits the organizational process to evolve and people continue to learn new things. A successful OSSP is not only a document but also a tool, something practitioners access it for reference because it contains useful informations such as examples, templates, checklists, and tips. In addition, the OSSP is also a communication tool because it establishes a common language where people can communicate with each others especially users, developers, managers, customers and functional support people. It promotes better understanding; provide a basis for estimation, automation and learning new things. It also facilitates reuse and avoids redundancy among projects. Software development is very time consuming and expensive if each project continue to define its own process and build everything from scratch.

Question:

As technology keeps on changing, how could I survive as my skill becoming obsolete?

Answer:

In this fast changing world of information-age, people must continue to learn new things, new skills in order to survive and this is what lifelong learning is all about.

I think you need to evaluate where you stand now.  What have you learned through your formal schooling and on your own?  You need to list your proficiencies or what you are very good at. You also need to identify your specialties or the area that you understand well. Compare that with the current trend in the industry and identify gaps in your knowledge.  What do you need to learn to survive in your job and thrive in the future?  What do you want to be able to do in three, five, or ten years from now? Would some kind of learning move you closer to realizing your career goals? Learning does not mean you have to go back to school but could be on the job or in-house training. You need to select the one that best fit you. You may check in-house trainings on a topic that you need or ask co-workers to teach you a skill that they have mastered. Start a collaborative learning project with few people since group learning is particularly effective. Periodically, reassess your learning plan. Changes within your organization or new technological developments may suggest a mid-course correction. In this era of rapid change, you need to make a plan.

Question:

It seems that Motorola is very successful with Six-Sigma. Why can’t we use this technique for our software improvement?

Answer:

Six-Sigma is a systematic technique that made Motorola very successful in their manufacturing process and some people believe it can also be applied to any processes including software.

In general, Six-Sigma consists of two parts:

1) A life cycle for making improvements called DMAIC (Define the To be or problem, Measure the current or As Is performance, Analyze gaps between current performance and target performance, Implement the improvements and Control the process).

2) Apply Statistical analysis techniques to data collected in the measure phase (e.g., run charts, stratification, root cause analysis and control limits) and making them visible to senior management for actions.

Based on my own experiences, the amount of value an organization can derive from Six Sigma is depended on how mature its current process is. If the organization is still at CMM level 1 or 2, I do not think Six-Sigma could help.

Question:

How do you convince SEPG members whom do not believe in improvement but only do whatever they like to do?

Answer:

If people who are responsible to make improvement happen such as the SEPG does not believe in improvement then the organization never improves. Initially, not everybody will believe in improvement because it is natural to be skeptic. There are probably some people who have been through an improvement that failed which left them very disappointed so they do not believe it can happens. For these people, you must demonstrate to them that engineering discipline and a good improvement plan can really bring changes to the organization. You must explain how it works, how other organizations have achieved success by following a defined process and add discipline to the way they build software then maybe they want to “give it another try”. Of course, there are people who do not believe anything, no matter what you do because they only interest in themselves and like to do whatever they want to do. If they are allowed to raise doubt about improvement or having a negative attitude regarding the team’s effort then they must be asked to leave. If you can not convince the team to work together toward a common goals and direction than you are just spinning your wheels, wasting time and efforts because change will never happen.

Question:

What is the different between project manager and software project manager?

Answer:

Software project management is a special skill that differs from other project management because software is intangible and to manage something that is difficult to see and touch requires significant experiences and training.

Software, like all of knowledge work, has important non-linear relationships among effort, time, features, quality, and that make project planning and monitoring much more difficult. For example, if I build a house, I can tell that the house is 30% completed or 80% completed fairly accurately but I can not tell if a software project is 30% or 80% completed. For a physical thing, requirements are always firm because the customers know exactly what they want but for something intangible like software which is difficult to visualize, requirements are never firm but keep on changing which make software project difficult to manage. Current project management training taught in university which relies heavily on sequential order and linear relationship among things is not suitable for software project management. Software project management training is very different and requires both technical knowledge and management skills such as leadership, communication, business, sale and marketing.

Last year, I taught a software management class for several experienced project managers. Most of my students said that this was the first time they were able to create project plans with goals besides schedules; they were able to defend the project plans and resist pressures from customers to make unrealistic schedule commitments. They were able to identify management reallocating committed resources to other projects as their biggest potential risk. They also found that team members may not be able to spend time on task at their planned rate of around 20 hours per week per team member. No one identified any technical issues or problems as a major risk factor to contend with. At the end of the class, most of my students supported the notion that if they do not manage quality, they can not manage the project. After class, they all told me that they were able to add quality plan with measurable goals into the project plan and focus more on early detection and removal of defect and not rely too much on testing. Many called me few months later and told me that their software projects were completed successfully based on what they learned in class and practiced.

Last month, I found the following data from the Wall Street Journal: In 2001, the U.S. Government annual spending on Information Technology was $81 billion dollars but roughly half projects were cancelled; a $40 billion problem. The latest U.S Government study also estimated that the impact of software defects on U.S. industry is around $22 billion annually.  It seems to me that more than ever, we need to train more qualified software project manager not just any manager.

Question:

Why so many companies are outsourced their software oversea? Is it cost or quality?

Answer:

Some organizations outsourced for cost saving, other outsourced because of quality requirements. However, there is another factor that people rarely talk about: “The fed up with hero symptom”. Many organizations, especially the very low maturity rely heavily on individuals for whatever software capability they have. Whenever those people quit, the organizations lose that capability (or portions thereof). In order to keep them, the organization has to pay above-average rates to key staff with critical knowledge and this help create the “Hero” culture where heroes are always rewarded but this hurt the business because of their high compensation. That is why outsourcing has become very popular today where organization can take the business to where the labor is willing, able and motivate to do work with much less pay and put many “Heroes” out of business.

Question:

Why defect happens? Is it because of process or human errors?

Answer:

The answer is both. There are several causes for defect:

·         Education: People did not understand how to do something

·         Communication: People were not properly informed about something

·         Oversight: People omitted doing something

·         Transcription: People know what to do but make a mistake in doing it

·         Process: Their process somehow misdirected their actions

Question:

How do we satisfy the requirement of establishing measurements and metrics when our products are website applications? I do not think we can measure web applications.

Answer:

On the contrary, it is so easy to collect measurements for web applications due to the nature of the digital medium.

1) As people surf the web, they always leave a trail that records where they have been. Your group could collect these data to optimize your infrastructure, improve your web site architecture, and measure the effectiveness of website design.

2) Each time someone on the web requests a page from a server, the server records the request and various information associated with that event. The data can be collected in the log for future analysis to understand the site’s usage patterns.

Of course, the fact that activity on the web can be measured is not enough but I think measurements need to be meaningful. You must analyze data collected to yield meaningful informations. I think the data collection and analysis of web activity has only just begun to scratch the surface of what may be possible in the future such as using server logs as a foundation, additional data can be gathered to track illegal and abusive activities to the source of major incidents involving computer viruses, and SPAM

Question

How do you categorize software project as small, medium or large? I have been working on project that last approximately about 2 to 4 weeks, is it a small or medium size project?

Answer:

There are many ways to categorize software project but I do not think 2 weeks duration can be considered a project but probably a task of a larger project.

From my own experience, I would consider approximately 6 to 12 months duration as a small project; a 12 to 24 months duration as a medium size project; and a 24 to 48 months or more as a large project. Some people do not use duration or time to categorize project but use effort or number of people required to support a project to determine project category. A small project typically requires approximately 5 to 25 people; a medium size project requires 25 to 100 people and a large project would require 100 to 300 people. There are other methods that consider number of requirements or change requests toward a software release as a way to determine project category. For example a small project could have 20 to 250 change requests; a medium size could have 250 – 500 change requests; and a large project could have 500 to 2,000 change requests. Remember, all these categories are relative and may differ from applications to applications.

Question

What are the primary measures for a level 2 organization? When do we need to take corrective action?

Answer:

At level 2, the focus is on project management and primary measures are size, cost, effort, defect and schedule of the projects. In the software project planning and software project tracking and oversight KPAs, the practices describe estimating, tracking and re-estimating of these measures and take correction when needed and record them for future improvement. For some maintenance projects, the size of software is relatively easy to collect but for new project it may be difficult so many people use efforts instead of size as a Normalizer. Tracking involves monitoring actual performance against estimates or planned performance. (Planned vs. actuals over time)  Corrective actions are taken when actual performance begins to deviate significantly from estimates and it usually involves revising the estimates and the plan. What is meant by “significant deviation” is subjective and depends on the situation, a 5 days deviation from a one year project is not a major concern but a 5 days deviation from a 1 month project is significant.

Question

What is an open system? Should we use open system in our application development to save money?

Answer:

Open Systems is a concept that can provide faster and more economical development of systems that are technologically up-to-date. An open system is a collection of interacting software, hardware, and human components:

1)    Designed to satisfy stated needs with interface specifications of its components that are fully defined

2)    Available to the public and

3)    Maintained according to a group consensus in which the implementations of the components conform to the interface specifications

The commonly held beliefs about the advantages to using open systems include the following:

1)    less reliance on proprietary products

2)    more competition leading to lower cost

3)    decreased probability of schedule delay

4)    better tested products (more users)

5)    portable applications

6)    interoperability

7)    faster technology insertion

8)    foundation for system evolution

However, these are only “common sense” advantages. There is no quantitative documented evidence based on real open systems to prove them yet.

Since there is no scientific research to evaluate open system, it is hard to speculate on how much money is saved by using an open systems approach. The answer may be “none,” especially in the short-term or from the perspective of only one program or system. To date, no cost savings have been proven as of yet. This is due to many factors, including: the short time that open systems have been in development, a lack of clear indicators of the costs to be tracked; and difficulties in separating costs associated with open systems from those associated with other aspects of a comprehensive approach

Question

We often hear about software project failure but what are the critical factors for a software project to be successful?

Answer:

Software projects frequently fail because we do not recognize the discipline of software engineering and its process but continue to react to the pressure of unrealistic schedule and unreasonable customer’s requirements.

I believe there are key factors that all successful projects have in common such as senior management commitment, well-defined process and experienced technical leadership.

I strongly believe that management commitment is the most critical success factor. Commitment means understand, accept and support. Without full commitment from management, when problems arise on a project, the project will collapse.

Most software projects are built with little thought to process. The team gets together and starts performing activities. As soon as enough information is gathered, coding begins. This lack of attention to process can kill a project very fast. It is easy to see the result of a lack of attention to process after a system fails. Usually major portions of the user requirements are ignored or the design does not taking into consideration of the ever-changing requirements. Many people believe process is only a burden imposes on them but the important of process is keeping the project organized in a consistent and focused way and thinking through the process carefully at the beginning of the project. Of course, not all processes are perfect but if a process is flawed, usually it is not seriously flawed and any process is better than no process at all.

Just as a building need an architect, a software project needs a technical lead. To be successful, the technical lead must be the one in control of the “architecture” of the project, namely the data model and application design. This level of control must be recognized and acknowledged by everyone involved with the project. Otherwise, each portion of the system may be constructed independently by a portion of the team and the pieces won’t fit together at the end.