Đáp: Có vài “căn nguyên” nhưng tôi muốn chỉ ra hệ thống giáo dục là yếu tố chính. Mặc cho nhiều thay đổi nhanh chóng trong công nghệ trong những thập kỉ qua, nhiều đại học vẫn dạy cùng giáo trình, kĩ thuật và phương pháp như họ đã dạy trong những năm 1960. Phần lớn các đại học vẫn hội tụ vào kĩ thuật lập trình nơi sinh viên dành khối lượng lớn thời gian vào giải quyết những vấn đề nhỏ bằng việc viết vài trăm dòng mã.

Trong thực tế phần lớn các vấn đề trong công nghiệp đều rất phức tạp; một cách điển hình giải pháp sẽ yêu cầu hàng triệu dòng mã để giải quyết. Tuy nhiên, khối lượng nỗ lực trong viết mã là nhỏ, xấp xỉ 20% của tổng nỗ lực phát triển. Cho nên có lỗ hổng lớn giữa điều đại học dạy và điều công nghiệp cần. Công nghiệp thực sự cần người có kĩ năng trong thu thập yêu cầu, lập kế hoạch dự án, kiến trúc phần mềm, thiết kế hệ thống, giao tiếp khách hàng và quản lí sản phẩm nơi 80% nỗ lực được dành vào nhưng các kĩ năng mấu chốt này không được dạy trong trường. Công nghiệp không cần nhiều người chỉ có kĩ năng lập trình mà là điều hầu hết đại học tạo ra: Người biết cách viết vài trăm dòng mã và giải quyết những vấn đề nhỏ, từng việc từng lúc.

Tôi muốn dùng một ví dụ để chứng minh cho luận điểm của tôi. Chúng ta hãy nhìn vào doanh nghiệp xây dựng: Dựng phần mềm lớn cũng giống như xây toà nhà 200 tầng. Nếu một nhóm thợ mộc, thợ điện, thợ nước và nhà thầu gặp nhau trên hiện trường, nói trong vài giờ, đi tới một lịch biểu tuỳ tiện và rồi bắt đầu xây dựng, tôi chắc toà nhà sẽ rất không ổn định cho dù nó được dựng lên tất cả. Tuy nhiên, đó là cách nhiều phần mềm được dựng ngày nay, một nhóm những người lập trình gặp gỡ và đồng ý về lịch biểu rồi mọi người bắt đầu viết mã và hi vọng rằng phần mềm sẽ làm việc.

Trong doanh nghiệp xây dựng, có các vai trò và trách nhiệm và mọi người được đào tạo để làm việc của họ tương ứng. Trước khi toà nhà thậm chí được bắt đầu, kiến trúc sư trưởng gặp người chủ và hỏi về yêu cầu, tức là toà nhà cao bao nhiêu, toà nhà sẽ phục vụ cho chức năng nào, nó phải có cấu trúc gì, bao nhiêu phòng, bao nhiêu văn phòng v.v. Tất cả những yêu cầu này được tính tới và thương lượng về giá cả và lịch biểu bắt đầu trước khi bất kì công việc giấy tờ nào được kí kết cho tới khi cả hai bên đã đồng ý hoàn toàn.

Trước khi bắt đầu xây dựng, kiến trúc sư soạn ra bản kế hoạch chi tiết, dựng mô hình, và làm bản kế hoạch tổng thể. Tại từng pha, kế hoạch được kiểm điểm cẩn thận và cập nhật bằng lịch biểu mới, ước lượng chi phí, phân tích rủi ro vân vân. Trong xây dựng, thợ mộc, thợ điện, thợ nước tới vị trí toà nhà, từng người được phân công một vai trò để thực hiện dựa trên kĩ năng và tri thức chuyên gia, từng nhiệm vụ được kiểm thử và giám định kĩ lưỡng khi được hoàn thành rồi được trắc nghiệm theo bản kế hoạch gốc cho tới khi toàn bộ toà nhà được làm xong.

Trong phần mềm, mọi người làm ít việc lập kế hoạch trước và lập tức hội tụ vào việc viết mã bởi vì họ được đào tạo viết mã chứ không lập kế hoạch. Rất ít người biết cách lập kế hoạch và lập lại kế hoạch trong tiến trình và rất ít người sẽ phân tích rủi ro hay cố giảm nhẹ nó. Đó là lí do tại sao kĩ năng quản lí phần mềm vẫn còn được tìm kiếm nhiều nhất sau ngần ấy năm bởi vì ít người thế biết tới nó. Do lập kế hoạch lúc đầu kém, lịch biểu bao giờ cũng dựa trên phỏng đoán tốt nhất thay vì phân tích yêu cầu logic trong khi mọi sự tiếp tục thay đổi. Lịch biểu không hợp lí, tuỳ tiện này là căn nguyên của hầu hết thất bại dự án phần mềm. Tất nhiên, có vài dự án thành công nhưng phần lớn có thể được qui cho nỗ lực anh hùng của vài kĩ sư giỏi thay vì qui trình tốt.

Sự kiện đáng buồn là ở chỗ sau vài cuộc tranh cãi, các dự án phần mềm tiếp tục thất bại với tỉ lệ đáng báo động bởi vì nhiều đại học không thừa nhận qui trình kĩ nghệ tốt nên được áp dụng cho phần mềm cũng như chúng đã áp dụng cho kĩ nghệ xây dựng. Là một ngành công nghiệp, mọi người vẫn không thừa nhận rằng kĩ nghệ phần mềm là khác với lập trình phần mềm và phần lớn các đại học vẫn dạy lập trình thay vì kĩ nghệ phần mềm.

Trong 15 năm qua, tôi đã nói nhiều bài trình bày ở các hội nghị kĩ thuật. Nếu tôi nói về cách cải tiến phần mềm, tôi có thể hấp dẫn được 50-80 người nghe. Nếu tôi nói về cách viết mã trong Java hay kiểm thử một đối tượng trong môi trường phát triển mới, tôi có thể được 300-500 người nghe. Tôi tin rằng việc thiếu quan tâm tới qui trình là trung tâm của vấn đề của chúng ta. Nhiều người trong chúng ta tin tưởng sai lầm rằng đóng góp thực duy nhất cho dự án là viết mã. Dùng ví dụ về xây dựng văn phòng lần nữa, điều này giống như nói rằng nếu bạn không có búa trong tay thì đóng góp của bạn cho toà nhà là không có ý nghĩa.

Hỏi: SEI CMM là gì? Làm sao nó có liên quan tới SW-CMM hay CMMI?

Đáp: Mô hình tăng trưởng năng lực Capability Maturity Model (CMM) là mô hình qui trình được Viện kĩ nghệ phần mềm Software Engineering Institute (SEI) tại đại học Carnegie Mellon University (CMU) phát triển. Lúc ban đầu, chỉ có một mô hình: SW-CMM và nhiều người gọi mô hình này là SEI CMM điều xác định năng lực kĩ nghệ phần mềm được yêu cầu để phát triển phần mềm chất lượng cao. SEI cũng đã phát triển phương pháp đánh giá chính thức để xác định mức độ trưởng thành qui trình theo thang từ 1 tới 5. Ngày nay, với nhiều CMM đã đưa ra, SEI CMM vẫn là thuật ngữ chung mọi người dùng để nói tới hoặc SW-CMM hoặc CMMI.

Hỏi: Tại sao thành viên SEPG phải cần có nhiều kinh nghiệm phần mềm? Tôi tin tôi có thể học lớp CMMI và làm tốt như bất kì ai khác.

Đáp: Để tôi bắt đầu bằng một câu chuyện ngắn: Nhiều năm trước đây, tôi đã nhận việc làm quản lí dự án và người đã làm việc đó trước tôi đã trao tay cho tôi một danh sách các “nghĩa vụ” mà người đó đã thực hiện và rằng tôi cần phải tiếp tục.  Phần lớn trong chúng chẳng liên quan gì tới vai trò quản lí dự án.  Thay vì thế, chúng thực sự là nhiệm vụ của người lập trình mà ông ta đã nhận từ đó vì điều đó là dễ dàng cho ông ta làm hơn là uỷ quyền cho ai đó khác.  Không may, ông ta bận rộn để làm những nhiệm vụ phi quản lí này tới mức ông ta đã không gắn lại cùng bản kế hoạch dự án và kế hoạch giảm nhẹ rủi ro cho một dự án dùng chủ yếu phần mềm rất phức tạp. Bạn có lẽ cũng biết phần còn lại của điều kinh hoàng mà tôi phải đối diện vào thời đó.

Nhiều người nhìn vào chức vụ “SEPG” như “danh hiệu chính trị” thay vì “vai trò chức năng”.  Họ tin vị trí này có thể cho họ nhiều kính trọng và con đường nghề nghiệp của họ có thể bắt đầu bằng “SEPG” và làm việc theo cách của họ tới đỉnh. Tuy nhiên, SEPG là một chức năng yêu cầu nhiều kĩ năng trong phối hợp, tạo điều kiện và trao đổi và những kĩ năng này không được dạy trong trường hay có thể thu được qua đọc sách.  Làm sao bạn phối hợp được cái gì đó khi bạn không biết bạn đang làm gì? Làm sao bạn trao đổi về cái gì đó khi bạn không thực sự hiểu nó? Sau rốt, bạn đang giải quyết với con người và cách họ làm việc và làm sao bạn có thể giúp họ cải tiến hoạt động hàng ngày của bạn mà không biết gì về qui trình của họ, công cụ của họ, môi trường của họ? 

Nếu bạn muốn họ kính trọng bạn thì bạn cần chỉ cho họ việc kính trọng trước hết không bằng ẩn nấp đằng sau “chức danh địa vị” và bi bô với họ bằng những “lối nói kĩ thuật” mà phải thu được sự kính trọng của họ bằng việc giúp họ cải tiến qua các tấm gương từ kinh nghiệm riêng của bạn. Như bạn có lẽ biết, kinh nghiệm tới từ nhiều năm thực hành, không từ các lớp học hay sách vở. Cải tiến qui trình có thể được so sánh với cuộc hành trình rất dài và khó và nó đem cả tổ đi cùng nhau để tới đích. SEPG là người hướng dẫn đưa đi trên cuộc hành trình này. Làm sao bạn có thể hướng dẫn người nào nếu bạn chưa bao giờ ở đó trước đó? SEPG là việc làm rất khó; nó yêu cầu tri thức, kĩ năng, kiên nhẫn, chuyên tâm và phần lớn của tất cả là nhiều kinh nghiệm từ nhiều năm thực hành.

Trong thời thay đổi và bất định này, tôi nghĩ chúng ta có thể giúp cho công ti của mình và nhân viên của mình bằng việc duy trì chân thực với cam kết riêng của mình và biết khả năng riêng của chúng ta trước khi tiến hành bất kì việc nào bất kể tới chức danh. Không có lối tắt trong cuộc sống và đi lên con đường nghề nghiệp vững chắc yêu cầu người ta phải có chỗ để chân mạnh mẽ trong mọi bước và trong đường dài, chính kinh nghiệm làm ra điều đó. Người có thể làm cho mọi sự sẽ xảy ra sẽ thành công và được thưởng.

Hỏi: Quản lí thay đổi công nghệ là gì? Điều đó có nghĩa là chúng tôi phải thay đổi khi công nghệ thay đổi sao?

Đáp: Chúng ta đang sống trong một thế giới thay đổi rất nhanh chóng được dẫn lái bởi công nghệ nhưng điều đó không có nghĩa là chúng ta phải thay đổi như thay đổi công nghệ. Quản lí thay đổi công nghệ là về ra quyết định đúng để chấp nhận công nghệ đúng cho qui trình đúng hay quản lí khía cạnh công nghệ. Nhiều tổ chức bận bịu phản ứng với mọi thay đổi trong công nghệ nhưng ít người chú ý tới quản lí công nghệ. Nền tảng của quản lí công nghệ cho nghề kĩ nghệ còn chưa được thám hiểm tốt bởi cả giới hàn lâm và công nghiệp.

Đó là lí do tại sao nhiều người thế vẫn hội tụ vào “Nền tảng tri thức” của phân tích công nghệ chứ không biết “làm sao áp dụng, khi nào chấp nhận, và vào khu vực nào”. Có nỗi sợ trong công nghiệp rằng nếu tổ chức không bắt kịp theo thay đổi công nghệ, họ sẽ bị bỏ lại đằng sau. Đây là ý niệm sai được biện minh bởi nhiều nhà cung cấp công nghệ khi thúc giục tổ chức phải bắt kịp với xu hướng vì mọi người đang làm điều đó. Quản lí thay đổi công nghệ là về tầm quan trọng của ra quyết định dựa trên phân tích thấu đáo về công nghệ, ích lợi và tiềm năng kinh tế cũng như tác động lên doanh nghiệp. Nó là móc nối giữa thế giới công nghệ và thế giới doanh nghiệp.

Hỏi: Liệu có thể áp dụng kĩ thuật Six-Sigma cho phát triển phần mềm không? Thầy có lời khuyên nào về triển khai Six-Sigma cho phần mềm không?

Đáp: Kĩ thuật Six Sigma đã được dùng để đạt tới cải tiến trong chất lượng sản phẩm và năng suất trong chế tạo nhưng việc đưa chúng vào kĩ nghệ phần mềm đã bị giới hạn hơn.  Phát triển phần mềm, sau rốt, là hoàn toàn khác với chế tạo và chương trình triển khai thành công phải bắt đầu bằng việc nhận ra sự kiện này.

Để triển khai bạn cần hiểu tính áp dụng được cũng như giới hạn của kĩ thuật Six-sigma cho phát triển phần mềm. Bạn cũng cần nhấn mạnh tới khác biệt giữa qui trình chế tạo chuẩn và qui trình phát triển phần mềm. Bạn cần hiểu các kĩ thuật thu thập dữ liệu; khối lượng dữ liệu được yêu cầu để được bắt đầu, tối thiểu hoá biến thiên dữ liệu, và tính áp dụng được của những kĩ thuật đặc biệt như sơ đồ điều khiển, kĩ thuật rà lại, phân tích biến thiên, và thiết kế từ thực nghiệm. Kĩ thuật là như nhau nhưng thu thập dữ liệu có thể hoàn toàn khác.

Hỏi: Vai trò của kĩ sư hệ thống là gì trong phát triển phần mềm?

Đáp: Kĩ sư hệ thống có vai trò rất quan trọng trong phát triển phần mềm. Họ làm việc với khách hàng để thu được yêu cầu hệ thống, phân tích chúng và phân bổ cho phần mềm. Họ lập kế hoạch di trú hệ thống, thực hiện hoạt động bù trừ, phát triển kiến trúc và thiết kế kể cả yêu cầu phần mềm, phần cứng, trao đổi và giao diện.

Ngày nay chúng ta không xây dựng các hệ thống đơn lẻ một mình nữa, phần lớn các hệ thống đều được tích hợp và người kĩ sư hệ thống chịu trách nhiệm phát triển chiến lược để tích hợp hệ thống phần mềm. Cả kĩ sư hệ thống và kĩ sư phần mềm đều là những chức năng mấu chốt trong phát triển hệ thống được tích hợp phức tạp.

Hỏi: Chúng tôi là tổ chức phần mềm, không tiếp thị hay tài chính. Tại sao chúng tôi cần đo thu hồi theo đầu tư Return-On-Investment (ROI) trong phát triển phần mềm?

Đáp: Thu hồi theo đầu tư (ROI) của cải tiến phần mềm thực sự là về cách tổ chức đảm bảo rằng nó chi ra số tiền đúng về đúng loại hoạt động sao cho nó có thể cải tiến chất lượng, năng suất, làm tăng tính sinh lời và chung cuộc, nâng cao giá trị của các cổ đông.

Trong quá khứ, nhiều tổ chức cảm thấy rằng họ đã có ít chọn lựa nhưng có cải tiến qui trình bởi vì ai đó đã nói vậy và họ chi nhiều tiền cho các hoạt động cải tiến và hi vọng rằng ích lợi nào đó có thể xuất hiện. Loại thái độ đó đang thay đổi nhanh chóng trong môi trường cạnh tranh cao của sụt giảm kinh tế. Ngày nay các tổ chức đang ở dưới sức ép phải làm công việc cải tiến với sự kiện định lượng và dữ liệu. Người quản lí cấp cao đòi hỏi biết ngân sách của tổ chức họ được đưa vào sử dụng hiệu quả thế nào hay làm sao họ có thể chi tiền của họ để đạt tới thu hồi theo đầu tư cao nhất.

Trong các thập niên qua, nhiều tổ chức đã dựa trên bằng chứng giai thoại và độ đo thô sơ để đánh giá tính hiệu quả của họ. Ngày nay tương phản lại, quản lí cấp cao yêu cầu dùng các độ đo phức tạp để phân tích và định lượng chi tiêu đầu tư và thu hồi theo đầu tư.

Từ cảnh quan riêng của tôi, ROI không phải chỉ là hệ thống đo mà còn là triết lí quản lí yêu cầu thay đổi trong thiết kế tổ chức và qui trình doanh nghiệp để tối ưu mục tiêu doanh nghiệp. Để đo thực tính hiệu quả cải tiến, tổ chức phải tham gia vào cách tư duy mới và chấp nhận nhu cầu về biến đổi toàn diện cách họ phát triển và bảo trì phần mềm.

Hỏi: Tại sao yêu cầu phần mềm là vấn đề chính cho hầu hết dự án? Chúng tôi có thể làm gì để giải quyết vấn đề này?

Đáp: Yêu cầu phần lớn là chức năng và hiệu năng mà khách hàng muốn đối với sản phẩm phần mềm. Nó là hoạt động mấu chốt bởi vì nếu bạn không thu được yêu cầu đúng, dự án của bạn sẽ thất bại chẳng thành vấn đề bạn thực hiện các hoạt động khác tốt tới đâu. Lấy các yêu cầu đúng đã chứng tỏ là một trong những khu vực khó khăn nhất của kĩ nghệ phần mềm bởi vì yêu cầu là đầu kết mở về bản chất. Nhiều khách hàng có xu hướng đổi ý hay đi tới các yêu cầu mới vì họ hài lòng và những hoạt động “không thể thức” này làm ngắt quãng qui trình phát triển phần mềm. Sự kiện khác là ở chỗ thời gian dành cho yêu cầu thường ngắn bởi vì phần lớn người quản lí tin rằng dự án phải đi tới thiết kế và viết mã nhanh nhất có thể được.

Có vài giải pháp để giải quyết các vấn đề yêu cầu nhưng trong phạm vi của Hỏi & Đáp này, tôi sẽ cung cấp cho bạn một kĩ thuật mà cá nhân tôi dùng mọi lúc. Chúng ta hãy nghĩ tới các yêu cầu về dự án của bạn hay dự án bạn đang kiểm điểm, và trả lời bốn câu hỏi sau.

1.        Các yêu cầu có thể dẫn tới giải pháp khả thi về kĩ thuật không?

2.        Các yêu cầu có thể dẫn tới giải pháp có chi phí chấp nhận được không (phát triển, sản xuất, vận hành và hỗ trợ)?

3.        Các yêu cầu có thể dẫn tới giải pháp có rủi ro chấp nhận được không?

4.        Các yêu cầu có thể dẫn tới giải pháp thoả mãn thoả đáng nhu cầu của khách hàng không?

Nếu bạn không có bằng chứng khách quan rằng câu trả lời là CÓ cho cả bốn câu hỏi này, thì dự án của bạn gần như chắc chắn gặp rắc rối. Nếu câu trả lời không được biết tới, có rủi ro lớn rằng dự án sẽ thất bại. Mục đích chính của pha yêu cầu là phát triển tập yêu cầu theo đó câu trả lời cho cả bốn câu hỏi là CÓ. Nếu bạn không thể đạt tới mọi câu trả lời là CÓ thì bạn nên kiểm điểm lại chúng với khách hàng để làm sáng tỏ hơn và kiểm nghiệm chúng trước khi tiếp tục. Tôi nhiệt thành nghĩ rằng bước đầu tiên hướng tới thành công dự án là tìm ra câu trả lời cho các câu hỏi trên.

Hỏi: Tôi nghe nói rằng mô hình vòng đời phần mềm cổ là hết thời rồi vì phát triển mới phần nhiều là về vấn đề tích hợp COTS, có thể viết ra giao diện chút ít hay “mã dán”. Thầy nghĩ gì?

Đáp: Tôi nghĩ mô hình truyền thống vẫn đi cùng chúng ta trong nhiều năm tới. Chúng có thể thay đổi thế nào đó nhưng dứt khoát không hết thời.  Người ta cần thừa nhận rằng COTS bản thân nó là “khái niệm” trong từ vựng lập trình cùng nó người ta tạo ra sản phẩm phần mềm mới. Xa với việc loại bỏ vấn đề lập trình, các bổ sung như vậy về sản phẩm đã được xây dựng sẽ chuyển việc phát triển phần mềm lên mức độ phức tạp hơn. Tích hợp COTS là không tầm thường như viết chút ít giao diện hay “mã dán” như bạn có thể mong đợi mà là thách thức rất lớn.

Ý tưởng rằng giao diện hay mã dán “chỉ” là chất dán và do vậy không phải là cái gì lớn nhắc nhở tôi về xu hướng của nhiều môi trường phát triển để bắt buộc kiểm soát mã nguồn chặt chẽ cho mã được dịch, trong khi gần như không khác với các kịch đoạn. Thái độ đó đã phai mờ nhiều vì việc tới của Internet dựa chủ yếu trên kịch đoạn (và việc nhận ra vi rút lớn nào bạn có thể viết mã dùng kịch đoạn), nhưng vào thời xưa nó đã là quan điểm tối mỉa mai. Kịch đoạn thực tế thường mạnh hơn và nguy hiểm hơn nhiều so với mã được dịch mà chúng kiểm soát.

Tôi nghĩ những bình luận tương tự áp dụng được cho một số phương pháp bây giờ được dùng để vá lại các gói phần mềm COTS tạp nham với nhau. Cũng như cố gắng ép khớp động cơ V-8 vào một xe MG có thể có những hậu quả không lường trước (chia nhỏ các bước truyền cho tâm), quá “nhiệt tình” về việc dán các bộ phận lớn với nhau có thể dẫn tới những kết quả rất thú vị.

English version

CMMI -37

Question: For years, software is always blamed for everything that went wrong. What is the “root cause” of most software failure and how to improve it?

Answer: There are several “root causes” but I would like to point to the education system as the main factor. Despite so many rapid changes in technology in the past decades, many universities are still teaching the same curricula, techniques and methods as they were taught in the 1960s. Most universities are still focusing on programming technique where students spent a large amount of time solving small problem by writing few hundred line of code. In reality most of the problems in the industry are very complex; typically solution would require million lines of code to solve. However, the amount of effort in coding is small, approximately 20% of the total development effort. So there is a large gap between what the university teaches and what the industry needs. The industry really needs people with skills in requirements gathering, project planning, software architecture, system design, customer interfaces and product management where 80% of the efforts are spent but these critical skills are not taught in school. The industry does not need a lot of people with programming skill only but that is what most universities produce: People who know how to code a few hundred lines of code and solving small problems, one at a time.

I would like to use an example to demonstrate my point. Let look at construction business:Building large software is like constructing a 200-story building. If a group of carpenters, electricians, plumbers and contractors meet in a field, talk for a few hours, come up with an arbitrarily schedules and then start building, I am sure the building will be very unstable if it even gets built at all. However, that is the way many softwares are being built today, a group of programmers meet and agree on a schedule then everybody starts to code and hope that the software will work.

In construction business, there are roles and responsibilities and people are trained to do their jobs accordingly. Before the building is even started, the chief architect meets the owner and asks about requirements, i.e. how tall is the building, what function the building will serve, what structure it should be, how many rooms, how many offices etc. All of these requirements are taken into consideration and a price and schedule negotiation begins before any paperwork is signed until both sides are completely in agreement. Before starting to build, an architect draws up detailed plans, builds models, and makes blueprints. At each phase, the plans are carefully reviewed and updated with new schedules, costs estimates, risks analysis and so on. During construction, carpenters, electricians, plumbers come into the building site, each person is assigned a role to perform based on skills and expertise, each task is tested and inspected thoroughly when completed then verified against the original plan until the entire building is done.

In software, people do a little planning upfront and immediately focus on writing code because they are trained to code not to plan. Very few people know how to plan and replan along the progress and very few would analyze the risk or try to mitigate it. That is why software management skills are still the most sought after all these years because so few people know it. Due to poor planning up front, the schedule is always based on the best guess rather than a logical requirements analysis as things continue to change. This unreasonable, arbitrary schedule is the root cause of most software project failures. Of course, there are few successful projects but most can be attributed to the heroic efforts of a few good engineers rather than a good process.

The sad fact is that after several decades, software projects continue to fail at an alarming rate because many universities do not recognize that good engineering processes should be applied to software just as they are to constructing buildings. As an industry, people still do not recognize that software engineering is different from software programming and most universities are still teaching programming instead of software engineering.
In the past 15 years, I have given many presentations at technical conferences. If I talk about how to improve a software process, I can attract 50-80 listeners. If I talk about how to code in Java or test an object in a new development environment, I can get 300-500 listeners. I believe that this lack of interest in process is at the heart of our problems. Many of us mistakenly believe that the only real contribution to a project is writing code. Using the office building example again, this is like saying that if you don’t have a hammer in your hand your contribution to the building is not significant.

Question: What is the SEI CMM? How does it relate to the SW-CMM or CMMI?

Answer: The Capability Maturity Model (CMM) is a process model created by the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). In the beginning, there is only one model: The SW-CMM and many people call this model SEI CMM which defines software engineering capabilities that are required to develop high quality software. The SEI also developed a formal assessment method to determine level of process maturity on scale from 1 to 5. Today, with several CMMs already released, SEI CMM is still a common term people use to refer to either the SW-CMM or the CMMI.

Question: Why should SEPG member need to have a lot of software experiences? I believe I could take a CMMI class and do well like anybody else.

Answer: Let me begin with a short story: Several years ago, I accepted a project management job and the person who had the job before me handed me a list of “duties” that he was performing and that I would need to carry on.  Most of them had nothing to do with a project management role.  Instead, they were really programmer tasks that he had taken on since it was easier for him to do it than to delegate to somebody else.  Unfortunately, he was so busy doing all these non-managerial tasks that he had failed to put together a project plan and a risk mitigation plan for a very complex software intensive project. You probably know the rest of the horror that I had to face at that time.

Many people look at the designation “SEPG” as a “positional title” rather than as a “functional role”.  They believe this position could give them a lot of respect and their career path could start with “SEPG” and work their way to the top. However, SEPG is a function that requires a lot of skills in coordination, facilitation and communication and these skills are not taught in school or can be acquired by reading books.  How do you coordinate something when you do not know what you are doing? How do you communicate about something when you do not really understand it? After all, you are dealing with people and the way they work and how can you help them to improve their daily activities without knowing anything about their process, their tools, their environment?  If you want them to respect you then you need to show them respect first by not hiding behind a “Positional title” and babble them with “Techno jargon” but to earn their respect by help them improve with examples from your own experiences. As you probably know, experience come from years of practice, not from classes or books. Process improvement can be compared to a very long and difficult journey and it takes a team to travel together to get to the destination. A SEPG is a guide that leads the journey. How can you guide anyone if you have never been there before? SEPG is a very difficult job; it requires knowledge, skills, patient, dedication and most of all a lot of experiences from many years of practice.

In this changing and uncertain time, I think we could help our company and our employees by stay true to our own commitment and know our own abilities before undertake any job regardless of the title. There is no short cut in life and to climb a solid career path require one to have a strong foothold in every step and in a long run, it’s the experience that count. The one who can make thing happen will be successful and rewarded.

Question: What is Technology Change Management? Does it mean we have to change as technology change?

Answer: We are living in a very fast changing world driven by technology but it does not mean we have to change as technology change. Technology Change Management is about making the right decision to adopt the right technology for the right process or the managing aspect of technology. Many organizations are so busy reacting to all the changes in technology but few pay attention to technology management. The fundamental of technology management for the engineering profession is not well explored by both the academic and the industry. That is why so many are focusing on the “Fundamental of knowledge” of analyzing the technology rather than knowing “How to apply, when to adopt, and to what area”. There is fear in the industry that if organizations do not keep up with the technology changes, they will be left behind. This is a false notion advocated by several technology vendors urging organization to keep up with the trends because everybody is doing it. Technology change management is about the importance of decision making based on a thorough analysis of the technology, the economic benefits and potential as well as the impact on the business. It is the link between the technological world and the business world.

Question: Is it possible to apply Six-Sigma technique to software development? Do you have any advice on the deployment of Six-Sigma to software?

Answer: Six Sigma techniques have been used to achieve major improvements in product quality and productivity in manufacturing but their introduction into software engineering has been more limited.  Software development is, after all, quite different from manufacturing and a successful deployment program must begin by recognizing this fact.

To deploy you need to understand the applicability as well as limitation of Six- sigma techniques to software development. You also need to emphasize the differences between standard manufacturing process and software development process. You need to understand data collection techniques; the amount of data required to get started, minimizing data variation, and the applicability of specific techniques such as control charts, regression techniques, analysis of variance, and design of experiments. The technique is the same but the data collection may be quite different.

Question: What is the role of System Engineer in software development?

Answer: System Engineer has a very important role in software development. They work with customer to obtain system requirements, analyze them and allocate to software. They plan system migration, perform trade-off activities, develop architecture and design including software, hardware, communications and interface requirements.

Today we do not build stand alone systems anymore, most systems are integrated and System Engineer is responsible for the development of the strategy to integrate software systems. Both System Engineer and Software Engineer are critical functions in the development of complex integrated systems.

Question: We are a software organization, not marketing or finance. Why do we need to measure Return-On-Investment (ROI) in software improvement?

Answer: Software improvement Return on Investment (ROI) is really about how an organization ensures that it is spending the right amount of money on the right kind of activities so that it can improve quality, productivity, increase profitability and ultimately, enhance shareholder value.

In the past, many organizations felt that they had little choice but do process improvement because somebody said so and they spent a lot of money for improvement activities and hope that some benefits may occur. That kind of attitude is changing fast in the highly competitive environment of an economic downturn. Today organizations are under significant pressure to make improvement works with quantifiable facts and data. Senior managers demand to know how efficiently their organization’ budget are being put to use or how they can spend their dollars to attain the highest possible return on their investments

In past decades, many organizations relied on anecdotal evidence and rudimentary metrics to assess their effectiveness. Today by contrast, senior management requires the use of sophisticated metrics to analyze and quantify investment spending and return on investment.

From my own perspective, ROI is not only a measurement system but also management philosophy that requires changes in organizational design and business processes to optimize business objectives. To truly measure improvement effectiveness, organizations must engage in a new way of thinking and accept the need for a comprehensive transformation of the way they develop and maintain software.

Question: Why is software requirement a major problem for most projects? What can we do to solve this problem?

Answer: Requirements are mostly functions and performance that customers want for a software product. It is a critical activity because if you don’t get the requirements right, your project will fail no matter how well you perform other activities. Getting requirements right has proven to be one of the more difficult areas of software engineering because requirements are open ended in nature. Many customers have a tendency to change their mind or come up with new requirements as they please and these “ad hoc” activities disrupt the software development process. Another fact is that time spent on requirements is often short because most managers believe that projects should move on to design and code as fast as possible.

There are several solutions to solve requirements issues but in the scope of this Question & Answer, I will provide you with one technique that I use personally all the time. Let‘s think about the requirements on your project or a project that you are reviewing, and answer the following four questions.

1.        Are the requirements likely to lead to a solution that is technically feasible?

2.        Are the requirements likely to lead to a solution that has acceptable costs (development, production, operations and support)?

3.        Are the requirements likely to lead to a solution that has acceptable risks?

4.        Are the requirements likely to lead to a solution that adequately satisfies customer needs?

If you don’t have objective evidence that the answer is YES to all four questions, then your project is almost certainly in trouble. If the answers are not known, there is enormous risk that the project will fail. The primary purpose of requirements phase is to develop a set of requirements for which the answer to all four questions is YES. If you cannot achieve all YES answers then you should review them with the customer for further clarification and validated them before continue. I strongly think that the first step toward project success is finding the answers to the above questions.

Question: I heard that the old software life cycle models are out because new development is more a matter of integrating COTS, maybe writing a little interface or “Glue code”. What do you think?

Answer: I think traditional models are still going to be with us for many years to come. They may be changing somewhat but definitely not out.  One needs to recognize that COTS is itself a “concept” in the programming vocabulary with which one creates new software product. Far from removing the programming problem, such additions of already built product would move software development up to a more complex level. COTS integration is not trivia as writing a few interfaces or “Glue code” as you may expect but a very big challenge. The idea that interfaces or glue code are “only” glue and thus not that big a deal reminds me of tendency of many of development environments to enforce rigorous source code control for compiled code, while being almost indifferent to scripts. That attitude has faded a lot since the advent of the heavily script-based Internet (and the realization of what great viruses you can code using scripts), but in the old days it was a supremely ironic stance. The scripts were in fact usually often far more powerful and dangerous operationally than the compiled code they controlled.

I think similar comments apply to some of the methods now being used to stitch together disparate COTS software packages. Just as trying to force-fit a V-8 engine into an MG car can have unexpected implications (shredding the transmission leaps to mind), too “Gung Ho” about gluing together large parts can lead to very interesting results.