Đáp: CMMI viết tắt cho Capability Maturity Model Integration – Mô hình trưởng thành năng lực tích hợp – và là khuôn khổ cho cải tiến qui trình phần mềm. Nó dựa trên khái niệm về các thực hành tốt nhất về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ti có thể dùng để cải tiến các qui trình của họ. Mô hình này đã được phát triển như kết quả của nghiên cứu của Bộ quốc phòng Mĩ (DoD) như một cách đánh giá các công việc của các nhà cung cấp phần mềm cho chính phủ Mĩ. Trong các năm 1980 tới 1985, nhiều hệ thống quân sự đã được các nhà cung cấp này phát triển đều tốn kém và đầy lỗi.
Chính phủ Mĩ quan tâm tới điều này nên họ đã lựa chọn đại học tốt nhất ở Mĩ về Kĩ nghệ phần mềm để tạo ra công cụ đánh giá khả năng của những nhà thầu của chính phủ trong việc thực hiện dự án phần mềm. Viện Kĩ nghệ phần mềm (SEI) tại Đại học Carnegie Mellon đã được chọn cho dự án này. Mặc dầu nó đã được thiết kế để đo phát triển phần mềm, nó cũng đã được dùng như một mô hình chung cho sự trưởng thành của qui trình trong cả các tổ chức phần mềm và phi phần mềm. Watt Humphrey, người phát minh ra CMMI đã tạo ra mô hình này với năm mức trưởng thành của một tổ chức:
CMMI mức 1: Khởi đầu (hỗn độn, không thể thức): Điểm bắt đầu cho việc dùng kỉ luật kĩ nghệ phần mềm.
CMMI mức 2: Lặp lại được (qui trình quản lí dự án): Qui trình được dùng theo cách lặp lại.
CMMI mức 3: Được xác định (Qui trình được thể lệ hoá): Qui trình được xác định tốt và được dùng như qui trình nghiệp vụ chuẩn.
CMMI mức 4: Được quản lí (Qui trình được định lượng): Quản lí và đo qui trình là đầy đủ tại chỗ.
CMMI mức 5: Tối ưu hoá (Cải tiến liên tục): Doanh nghiệp liên tục trưởng thành và lấy ưu thế của qui trình của mình qua việc tối ưu hoá.
Các công ti được trông đợi được thẩm định để nhận diện họ ở đâu trong khuôn khổ trưởng thành và làm kế hoạch cải tiến để liên tục chuyển sang mức tiếp. CMMI rất thành công trong việc nâng cao ngành công nghiệp phần mềm của Mĩ và cuối cùng đã được chấp nhận trên toàn thế giới như chuẩn cho việc cải tiến chất lượng phần mềm. Do thành công khởi đầu của họ, nhiều ngành công nghiệp bắt đầu thích nghi CMMI sang các miền khác và yêu cầu SEI tạo ra các mô hình khác như Cộng tác cải tiến qui trình công ti – Enterprise Process Improvement Collaboration (EPIC), Mô hình trưởng thành năng lực kĩ nghệ hệ thống – Systems Engineering Capability Maturity Model (SE-CMM), Thu nhận phần mềm CMM – Software Acquisition CMM (Acq.-CMM), và CMM con người – People CMM (P-CMM).
Viện Kĩ nghệ phần mềm nói rằng các mô hình này nên được dùng cho việc tự cải tiến, để giúp nâng cao chất lượng sản phẩm phần mềm do đó SEI không đưa ra chứng nhận thuộc bất kì dạng nào (bất kì ai nói với bạn khác hơn hay cung cấp chứng nhận CMMI có lẽ làm điều đó vì lợi nhuận riêng của họ). Viện SEI có cấp phép và uỷ quyền cho các nhà đánh giá hàng đầu để tiến hành đánh giá CMMI và dùng tài liệu của họ với mục đích huấn luyện.
Hỏi: Nhiều công ti khoán ngoài nói rằng họ đã được thẩm định ở CMMI mức 5. Làm sao thầy biết rằng họ là thực và câu hỏi nào cần được hỏi trước khi bất kì quyết định nào được đưa ra để làm kinh doanh với họ?
Đáp: Bạn có thể hỏi:
Ai đã thực hiện đánh giá CMMI?
Họ có tư cách là người đánh giá hàng đầu được Viện Kĩ nghệ phần mềm tại Carnegie Mellon thừa nhận không?
Người đánh giá hàng đầu là cán bộ cơ quan hay là nhà tư vấn bên thứ ba?
Khi nào việc đánh giá được tiến hành?
Bao nhiêu đánh giá đã được tiến hành trong công ti đó?
Phạm vi của đánh giá là gì?
Bao nhiêu dự án được tham gia vào đánh giá này?
Bao nhiêu phần trăm tổ chức được đánh giá? – Đó là một dự án, vài dự án hay hầu hết các dự án?
Bao nhiêu dự án có trong tổ chức của họ?
Loại dữ liệu nào họ có thể chia sẻ với bạn?
Họ có dữ liệu về ích lợi không? Họ có dữ liệu thu hồi vốn đầu tư (ROI) không?
Họ có dữ liệu năng suất không?
Họ có dữ liệu về khiếm khuyết không?
Họ có tại chỗ loại qui trình ngăn ngừa khiếm khuyết nào?
Làm sao họ quản lí được thay đổi công nghệ?
Làm sao họ lựa chọn, đánh giá và quản lí chuyển giao công nghệ?
Cho dù họ có những dữ liệu này và có thể trả lời các câu hỏi của bạn, bạn vẫn có thể kiểm tra website tại Viện Kĩ nghệ phần mềm tại Carnegie Mellon để xem liệu tên của họ có được liệt kê ở đó không.
Hỏi: Bộ môn kĩ nghệ phần mềm là gì? “Văn hoá kĩ nghệ phần mềm” là gì?
Đáp: Kĩ nghệ phần mềm là bộ môn để tạo ra giải pháp hiệu quả chi phí cho các vấn đề của doanh nghiệp bằng việc áp dụng tri thức khoa học vào thiết kế và thực hiện sản phẩm phần mềm. Hiện thời, phần mềm vẫn còn là bộ môn chưa chín muồi với nhiều người làm nhiều điều theo cách riêng của họ vì có ít tri thức hay chuẩn sẵn có cho họ dùng như tham chiếu.
“Văn hoá kĩ nghệ phần mềm ” là thuật ngữ tôi dùng để mô tả cho một môi trường mà trong đó các thành viên của nhóm phần mềm chia sẻ cam kết để xây dựng sản phẩm chất lượng cao theo cách có kỉ luật. Tất cả các bộ môn kĩ nghệ đều đã tiến hoá qua thời gian. Trong những giai đoạn đầu, phần lớn các hoạt động đều không thể thức và được thực hiện chỉ bởi những người có kĩ năng. Những người này không trao đổi hay chia sẻ mọi thứ với người khác nhưng giữ cho bản thân họ hay trong một nhóm rất nhỏ các bạn bè. Cuối cùng, một số trong những hoạt động này được viết ra để cho nó có thể được dạy hay chia sẻ giữa những người thực hiện cùng công việc. Việc truyền tri thức qua các thủ tục được viết mở ra tri thức trong giai đoạn thương mại nơi các thủ tục được kiểm thử và tiến hoá thành các chuẩn và “thân tri thức” (Sách hướng dẫn, thực hành tốt nhất) và các bộ môn bắt đầu phát triển.
Hỏi: Tôi cần loại kĩ năng nào để chuẩn bị cho bản thân mình là người quản lí dự án phần mềm tốt? Tôi được đề bạt làm người quản lí nhưng không nhận được huấn luyện nào.
Đáp: Bạn không một mình. Dựa trên dữ liệu tôi đã thu thập trong nhiều năm qua, phần lớn các nhà quản lí dự án phần mềm đều không nhận được huấn luyện nào cả. Giữ những vai trò kĩ thuật hay chức năng xuất sắc trước đây, nhiều người đảm đương trách nhiệm quản lí dự án phần mềm mà không có mấy chuẩn bị. Nếu có huấn luyện nào, có lẽ nó hội tụ nhiều hơn vào việc dùng công cụ hay kĩ thuật chứ không vào quản lí dự án. Quản lí dự án không chỉ là áp dụng công cụ mà là áp dụng “Trạng thái tâm trí” đúng, hay thái độ đúng. Người quản lí dự án tốt phải có những kĩ năng sau:
1) Kĩ năng lãnh đạo: Có khả năng đưa ra chiều hướng và tầm nhìn rõ ràng; thiết lập các mục đích và mục tiêu đo được và cổ vũ công việc tổ; uỷ quyền và ra quyết định.
2) Tri thức chuyên gia kĩ thuật: Hiểu công nghệ liên quan tới dự án; Hiểu ứng dụng, thị trường, và yêu cầu của khách hàng; Quản lí công nghệ; Thẩm định rủi ro và bù trừ; Dự đoán xu hướng công nghệ và trao đổi hiệu quả với tổ.
3) Kĩ năng con người: Có khả năng xây dựng tổ, Động viên các thành viên tổ; Quản lí xung đột, và trao đổi hiệu quả
4) Kĩ năng quản trị: Lập kế hoạch dự án; ước lượng; Thương lượng tài nguyên, đảm bảo cam kết; Tạo ra lịch biểu và cột mốc; Điều phối và kiểm điểm tiến độ và làm hành động sửa chữa.
5) Kĩ năng tổ chức: Khả năng chèo lái trong tổ chức; Xây dựng tổ công tác đa chức năng; Làm việc hiệu quả với quản lí cấp cao, và hiểu giao diện tổ chức.
6) Kĩ năng doanh nghiệp: Cảnh quan quản lí chung; Quản lí dự án như quản lí doanh nghiệp; đáp ứng các mục tiêu lợi nhuận và phát triển mục tiêu mới và đi theo doanh nghiệp.
Hỏi: Làm sao chúng tôi vẫn đi đầu khi có nhiều công nghệ mới thế đang nổi lên mọi ngày?
Đáp: Tôi nghĩ công nghệ sẽ tiếp tục thay đổi cứ ba tới năm năm và thậm chí có thể còn đi nhanh hơn. Thay đổi này dứt khoát ảnh hưởng tới cách mọi người làm kinh doanh. Ngay cả các công ti tốt nhất cũng sẽ không có khả năng giữ lại tất cả các tri thức chuyên gia cần thiết cho doanh nghiệp của họ. Điều này sẽ dẫn tới khoán ngoài, gửi một số việc ra bên ngoài và hội tụ chỉ vào nghiệp vụ cốt lõi là bản chất cho công ti. Để giữ được hàng đầu, bạn cần hội tụ vào công nghệ quan trọng nhất mà công ti bạn muốn giữ lại, điều có thể cần tới việc huấn luyện phụ thêm cho người của bạn và khoán ngoài những công nghệ bạn không có tri thức chuyên gia hay coi như không quan trọng bằng.
Tôi tin rằng lỗ hổng công nghệ giữa công ti tốt nhất và công ti trung bình sẽ tiếp tục tăng lên ngày càng lớn mọi năm. Công ti không theo kịp với những thay đổi này sẽ bị khử dần. Với toàn cầu hoá, thay đổi công nghệ làm cho mọi doanh nghiệp phải linh động hơn trước đây bởi vì cạnh tranh có thể tới từ bất kì đâu, bất kì lúc nào. Để giữ hàng đầu, bạn cần bắt đầu hành động từ bây giờ bằng việc cải tiến kĩ năng người của bạn cũng như hỗ trợ cho tổ chức của bạn cải tiến năng lực của nó để cung cấp giá trị cho doanh nghiệp. Đầu tư tốt nhất là liên tục cung cấp huấn luyện công nghệ cho người của bạn.
Hỏi: Tôi là một CEO của công ti cỡ trung bình. Nhà tư vấn bảo tôi rằng “trao đổi” là điểm yếu chính trong công ti của tôi. Tôi không đồng ý với anh ta vì tôi đã nói với mọi người mọi lúc rồi.
Đáp: Bất kì khi nào quản lí cấp cao trao đổi cái gì đó qua hệ thống quản lí, bao giờ cũng có nguy cơ bị hiểu lầm. Vấn đề không chỉ nảy sinh khi mọi người không đồng ý theo diễn giải của họ về ý nghĩa của người quản lí, mà thường có lẫn lộn cả về điều người quản lí muốn. Chừng nào người quản lí cấp cao còn chưa nỗ lực đặc biệt, mọi người sẽ ngần ngại hỏi để làm sáng tỏ. Một yêu cầu đơn giản có thể được đón chào bằng tranh cãi về nghĩa của nó, với nhiều người đưa ra các ý kiến. Chẳng mấy chốc những ý kiến này sẽ mang đặc tính của sự kiện được thiết lập và điều xảy ra có thể không phải là điều người quản lí cấp cao nghĩ trong đầu.
Nếu trao đổi là điểm yếu chính như được người tư vấn nêu ra, nó cần được giải quyết bởi vì nếu quản lí cấp cao không theo dõi chiều hướng của mình, những người ở mức thấp hơn, thường có nhiều điều để làm, sẽ quên về chiều hướng và chẳng cái gì sẽ được làm.
Hỏi: Tại sao chúng ta phải tập trung quá nhiều vào làm tài liệu mọi thứ của quá khứ như “Bài học rút ra”?
Đáp: Bài học rút ra đại diện cho lịch sử của tổ chức và khả năng của nó ghi nhớ điều đã xảy ra. Bài học rút ra là tri thức có giá trị phải được gìn giữ, phân tích, sử dụng và cập nhật. Nếu bạn không học từ bài học của quá khứ, bạn sẽ phạm phải cùng sai lầm lần nữa. Làm tài liệu chỉ là một khía cạnh của việc ghi lại điều đã xảy ra, nó vẫn cần được phân tích và tổ chức thành cái gì đó có giá trị như tập các danh sách kiểm mà tổ chức có thể học được từ nó. Danh sách kiểm là tài sản có thể ngăn cản tổ chức khỏi phạm sai lầm hai lần.
Hỏi: Qui trình là gì? Phương pháp là gì? Về công cụ thì sao?
Đáp: Qui trình là dãy logic các nhiệm vụ được thực hiện để đạt tới một mục tiêu đặc biệt. Qui trình xác định ra “Cái gì” cần được thực hiện, không xác định “Cách làm” từng nhiệm vụ được thực hiện.
Phương pháp bao gồm các kĩ thuật để thực hiện một nhiệm vụ hay “Cách làm” từng nhiệm vụ. Phương pháp thường ngụ ý một mức độ kỉ luật hay chi tiết liên quan tới từng nhiệm vụ.
Công cụ là một dụng cụ mà khi được áp dụng vào một phương pháp đặc biệt, có thể nâng cao tính hiệu quả của nhiệm vụ.
Hỏi: CMMI có yêu cầu dùng lại phần mềm không, nếu có, ở mức độ nào? Thầy đã bao giờ coi dùng lại phần mềm là cách giảm chi phí, vòng thời gian, và cải tiến chất lượng không?
Đáp: CMMI là khuôn khổ cho cải tiến không phải là yêu cầu. Nó không yêu cầu tổ chức thực hiện dùng lại phần mềm, nhưng nó có khuyến khích dùng lại các vật phẩm, dưới dạng tài sản phần mềm.
Theo kinh nghiệm riêng của tôi, dùng lại phần mềm không thực sự xảy ra mãi cho tới mức 4, nhưng kết cấu nền cho dùng lại nên có tại chỗ ở mức 3 (tức là, thư viện tài sản qui trình). Tôi mạnh mẽ tin tưởng vào việc dùng lại “có hệ thống” như một cách giảm chi phí, vòng thời gian, và cải tiến chất lượng chứ không phải là dùng lại “không thể thức”, chính là qui trình hỗn độn đầy những lời lẽ hoa mĩ, và là cách tiếp cận vô kỉ luật tới vấn đề kĩ thuật.
Phần lớn các nỗ lực dùng lại phần mềm đều thất bại bởi vì tổ chức đã không hiểu sự khác biệt giữa dùng lại “có hệ thống” và “không thể thức.” Tổ chức này có qui trình được thiết lập tốt, thu thập “các thực hành tốt nhất” để dùng một cách có hệ thống và tổ chức khác là “một đống chất liệu phần mềm” mà bất kì ai cũng có thể đem cúng tiến với hi vọng rằng nó có thể được ai đó dùng, người có thời gian phân loại qua nó.
Hỏi: Tập các độ đo tốt là gì để người quản lí dự án có thể dùng?
Đáp: Tôi tin tập tối thiểu các độ đo nên là kích cỡ, nỗ lực, chi phí, thời gian và chất lượng (tức là khiếm khuyết). Người quản lí dự án cần dịch chuyển tư duy của họ từ việc chỉ nhìn vào chi phí và lịch biểu sang điều phối kích cỡ, nỗ lực, chi phí, thời gian, khiếm khuyết và làm hành động sửa chữa. Tuy nhiên, người quản lí dự án cần rất cẩn trọng trong việc đưa ra phán xét về những người thực hiện việc. Người quản lí không nên dùng các cách đo này để đánh giá con người. Việc sợ bị đánh giá vẫn còn phổ biến trong nền văn hoá của chúng ta. Khi được dùng đúng, những cách đo này có thể cho phép mọi người thấy rằng trách móc thường không là việc của những người làm kĩ nghệ hay làm kế hoạch. Nó bao giờ cũng là vấn đề của quản lí; với những người bị yêu cầu thực hiện kế hoạch mà không thể thành công được.
Hỏi: Qui trình phần mềm cá nhân – Personal Software Process (PSP) là gì? Nó liên quan thế nào với CMMI?
Đáp: Qui trình phần mềm cá nhân – Personal Software Process (PSP) lấy thực hành của tổ chức, được mô tả trong Mô hình trưởng thành năng lực, và giảm cấp nó xuống mức độ cá nhân. Watts Humphrey, thuộc Viện Kĩ nghệ phần mềm, đã phát triển PSP để đáp ứng nhu cầu của từng kĩ sư phần mềm thu được cách tiếp cận có kỉ luật và hiệu quả tới việc viết chương trình phần mềm (tức là viết mã). Triết lí đằng sau PSP là ở chỗ năng lực của tổ chức để xây dựng hệ thống phần mềm lớn tuỳ thuộc vào năng lực của riêng từng kĩ sư phần mềm của nó trong phát triển các chương trình qui mô nhỏ chất lượng cao theo cách thức có kỉ luật, hiệu quả.
PSP được thiết kế để giúp người kĩ sư tổ chức và lập kế hoạch công việc của họ, theo dõi hiệu năng của họ, quản lí chất lượng phần mềm, và phân tích và cải tiến qui trình cá nhân của họ về việc viết chương trình phần mềm. PSP giúp người phát triển phần mềm hiểu thế nào và tại sao các yếu tố đa dạng của kĩ nghệ phần mềm là cần thiết và làm sao chúng khớp lại với nhau. Dựa trên các thử nghiệm trong công nghiệp và đại học, phương pháp PSP là rất hiệu quả trong tổ chức ít nhất đã đạt tới mức độ trưởng thành 3 (tức là qui trình nhất quán) hay cao hơn.
Hỏi: Làm sao người ta có thể tránh được vấn đề khi yêu cầu bao giờ cũng thay đổi, đôi khi rất muộn trong vòng đời phát triển? Làm sao chúng ta có thể kiểm thử được phần mềm để đảm bảo hệ thống sẽ thực hiện như mong đợi?
Đáp: Yêu cầu thay đổi rất thường xuyên trong phát triển phần mềm nhưng nó có thể được dõi về việc thiếu hiểu biết giữa khách hàng và người phát triển. Lời khuyên của tôi là kiểm tra chéo để xem liệu bạn có thực sự hiểu các yêu cầu bằng việc tạo ra kế hoạch kiểm thử đồng thời với lúc bạn viết yêu cầu. Bạn cần tự hỏi mình “Yêu cầu này có kiểm thử được không?” và “Làm sao tôi biết tôi đã thành công?” Mức độ hiểu biết chi tiết này sẽ giúp bạn đi tới các yêu cầu tốt hơn và làm giảm bớt cơ hội yêu cầu thay đổi.
Có yêu cầu tốt cũng giúp bạn trong pha sau của lập kế hoạch dự án (tức là ước lượng nỗ lực công việc). Bạn cần chia nhỏ các yêu cầu thành các nhiệm vụ quản lí được. Nhiệm vụ càng nhỏ, ước lượng của bạn càng chính xác. Vì kiểm thử sẽ chiếm phần lớn dự án của bạn, lịch của bạn cần phản ánh điều đó. Bởi vì phần mềm thường là phức tạp, sửa thường xuyên, và rất tuỳ thuộc hoàn cảnh, nên việc kiểm thử đầy đủ thường là không thực tế. [Phụ thuộc hoàn cảnh nghĩa là tất cả phần mềm và phần cứng đều phải cùng làm việc, để đạt tới hiệu quả bạn mong muốn.]
Kiểm thử theo ngữ cảnh (biết tất cả các phiên bản) là cần cho kiểm thử hợp thức. Mã đơn thể cùng với giao diện được xác định tốt có thể có ích bằng việc tạo ra những mẩu mã nhỏ hơn, có thể được kiểm thử tốt một cách riêng rẽ (kiểm thử đơn vị), trước khi kiểm thử toàn hệ thống. Nếu mã đơn thể là hướng theo dữ liệu, bạn có thể có khả năng làm bản mẫu nhanh chóng cho mã của mình. Bằng việc dùng mã để hỗ trợ cho trao đổi toàn hệ thống, được các đơn vị riêng mà bạn tạo ra sử dụng, bạn có thể làm kiểm thử sớm về tốc độ mà thiết kế sơ bộ của bạn sẽ hỗ trợ, cho nên thiết kế lại có thể xảy ra trước khi nhiều việc viết mã được thực hiện.
Question: Can you tell me more about the CMMI framework. What is it and how it is considered as the standard for measuring quality?
Answer: CMMI stands for Capability Maturity Model Integration and is a framework for software process improvement. It is based on the concept of software engineering best practices and explains the discipline that companies can use to improve their processes. The model was developed as a result of a study by the U.S Department of Defense (DoD) as a way to evaluate the work of software suppliers to U.S government. During 1980 to 1985, many military systems developed by these suppliers were costly and full of defects, The U.S government were so concerned so they selected the best university in the U.S in Software Engineering to create a tool to evaluate the ability of government contractors to perform a software project. The Software Engineering Institute (SEI) at CarnegieMellonUniversity was selected for this project. Though it was designed to measure software development, it has been used as a general model of the maturity of processes in both software and non-software organizations. Watt Humphrey, the inventor of the CMMI created the model with five levels of process maturity for an organization:
CMMI Level 1: Initial (chaotic, ad hoc): The starting point for use of a software engineering discipline.
CMMI Level 2: Repeatable (project management process): The process is used repeatedly.
CMMI Level 3: Defined (institutionalized Process): The process is well defined and used as a standard business process.
CMMI Level 4: Managed (quantified Process): Process management and measurement are fully in place.
CMMI Level 5: Optimizing (Continuous improvement): Business continues to mature and take advantage of its process via optimization.
Companies were expected to be assessed to identify where they are in the maturity framework and make improvement plans to continue to move to the next level. The CMMI were very successful in improving the U.S software industry and eventually being adopted worldwide as the standard for improving software quality. Due to their initial success, many industries began to adapt the CMMI to other areas and asked the SEI to create other models such as Enterprise Process Improvement Collaboration (EPIC), Systems Engineering Capability Maturity Model (SE-CMM), Software Acquisition CMM (Acq.-CMM), and the People CMM (P-CMM).
The Software Engineering Institute stated that these models should be used in self improvement, to help raise the level of quality of software products therefore the SEI does not offer certification of any form (anyone who tells you otherwise or offer CMMI certificate is probably do it for their own profit). The SEI does licenses and authorizes lead appraisers to conduct CMMI appraisals and use their materials for training purpose.
Question: Many outsourcing companies claimed that they were assessed at CMMI Level 5. How do you know that they are real and what questions need to be asked before any decision is made to do business with them?
Answer: You may want to ask:
1) Who performed the CMMI appraisal?
2) Are they a qualified Lead appraiser recognized by the Software Engineering Institute at Carnegie Mellon?
3) Is the Lead appraiser an internal staff or third party consultant?
4) When was the appraisal conducted?
5) How many appraisals have been conducted in that company?
6) What is the scope of the appraisal?
7) How many projects were participated in the appraisal?
8) What percentage of the organization was appraised? – Is it one single project, few project or most of the projects?
9) How many projects are there in their organization?
10) What kind of data can they share with you?
11) Do they have benefit data? Do they have Return on Investment (ROI) data?
12) Do they have productivity data?
13) Do they have defects data?
14) What kind of defect prevention process do they have in place?
15) How do they manage technological changes?
16) How do they select, evaluate and manage technology transfer?
Even they have these data and could answer your questions, you may also check the website at the Software Engineering Institute at Carnegie Mellon to see if their name is listed there.
Question: What is software engineer discipline? What is “software engineering culture”?
Answer: Software engineering is a discipline to create cost effective solutions to business problems by applying scientific knowledge to the design and implement of software products. Currently, software is still an immature discipline with so many people do things according to their own way since there is few knowledge or standard available for them to use as reference.
“Software engineering culture” is the term I used to describe an environment in which the members of a software group share a commitment to build high-quality products in a disciplined way. All engineering disciplines have evolved overtime. During earlier stages, most activities are ad hoc and performed only by skilled people. These people do not communicate or share things with each other but keep to themselves or within a very small group of friends. Eventually, some of these activities are written down so it can be taught or shared among people performing the same work. The transmitting of knowledge via written procedures open the knowledge into the commercial stage where procedures are tested and evolved into standards and “body of knowledge” (Guide Books, best practices) and the disciplines begins to develop.
Question: What kind of skills do I need to prepare myself to be a good software project manager? I got promoted to manager but receive no training.
Answer: You are not alone. Based on the data that I have collected in the past several years, most software project managers do not receive any training at all. Having excelled previously in technical or functional roles, many people assume software project management responsibility without much preparation. If there is any training, it probably focuses more on using tools or techniques rather managing a project. Project management is not just an application of tools but the right “State of mind”, or attitude. A good software project manager should have the following skills:
1) Leadership: Be able to provide a clear direction and vision; set measurable goals and objectives and foster team work; delegating and decision making.
2) Technical expertise: Understand the technologies relevant to the project; Understand applications, markets, and customer requirements; Managing technology; Assessing risks and trade-offs; Predicting technology trends and communicate effectively with the team.
3) People skills: Be able to building team, Motivating team members; Managing conflict, and effective communication
4) Administrative skills: Project planning; estimating; Resource negotiations, securing commitments; Creating schedule and milestones; Monitor and review progress and take corrective actions.
5) Organizational skills: Ability to navigate in the organization; Building multifunctional work teams; Working effectively with senior management, and understand organization interfaces.
Entrepreneurial skills: General management perspective; Managing project like running a business; Meeting profit objectives and developing new and follow on business.
Question: How do we keep ahead when there are so many new technologies emerging everyday?
Answer: I think technology will continue to change every three to five years and may even go faster. This change will definitely affect the way people do business. Even best companies will not be able to retain all the required expertise for their business. This will lead to outsourcing, sending some works outside and focus only on the core business that is essential for the company. To keep ahead, you need to focus on the most important technology that your company wants to keep in house which may require additional training for your people and outsource the one that you do not have expertise or consider not so important. I believe that the technology gap between the best company and the average company will continue to grow larger every year. Company that does not keep up with these changes will be eliminated. With globalization, technology change makes every business more volatile than ever before because competition can come from anywhere, anytime. To keep ahead, you need to start acting now by improving your people skills as well as supporting your organization improving its capability to provide values to the business. The best investment is continuous provide technology training to your people.
Question: I am a CEO of a medium size company. My consultant told me that “communication” was as a major weakness in my company. I did not agree with him since I talked to my people all the time.
Answer: Whenever senior managers communicate something through the management system, there is always a chance of misunderstanding. Not only do problems arise when people disagree with their interpretations of managers’ meaning, but there is often confusion about what senior manager wants. Unless senior managers make a special effort, their people will be reluctant to ask for clarification. A simple request may be greeted by debate about its meaning, with several people offering opinions. Soon some of these opinions will take on the character of established fact and what happens may not be what senior managers had in mind.
If communication is a major weakness as indicated by a consultant, it needs to be resolved because if senior managers do not follow-up on their direction, people at lower level, usually having so much things to do, will forget about the direction and nothing will be done.
Question: Why should we focus too much on document things of the past such as “Lessons Learned”?
Answer: Lessons learned represent the history of an organization and its capability to remember what has happened. Lessons learned are valuable knowledge that must be kept, analyzed, used and updated. If you do not learn from lessons of the past, you will make the same mistake time and time again. Document is only one aspect of recording what has happened, it still need to be analyzed and organized into something valuable such as a set of checklist that the organization can learn from it. Checklist is an asset that can prevent the organization from making the mistake twice.
Question: What is a process? What is a method? What’s about tool?
Answer: A process is a logical sequence of tasks performed to achieve a particular objective. A process defines “What” is to be done, without specifying “How” each task is to be performed. A method consists of techniques for performing a task or the “How” of each task. Methods usually imply a degree of disciplines or details regarding each task. A tool is an instrument that, when applied to a particular method, can enhance the efficiency of a task.
Question: Does the CMMI require software reuse, if so, at what level? Have you ever considered software reuse as a way to reduce cost, cycle time, and improve quality?
Answer: The CMMI is a framework for improvement not a requirement. It does not require the organization to implement software reuse, but it does encourage reuse of artifacts, in term of software assets.
In my own experience, software reuse does not really happen until level 4, but the infrastructure for reuse should be in place at level 3 (i.e., process assets library). I strongly believe in “systemic” reuse as a way to reduce cost, cycle time, and improve quality but not “ad hoc” reuse, which is a chaotic process full of rhetoric, and is an undisciplined approach to a technical issue.
Most software reuse attempts have failed because the organization did not understand the difference between “systemic” and “ad hoc” reuse. One is a well-defined process that collects “best practices” for systemic use and the other is a “heap of software stuff” that anybody can donate to with the hope that maybe it can be used by somebody who has the time to sort through it.
Question: What would be a good set of measurements that project manager could use?
Answer: I believe the minimum set of measurements should be size, effort, cost, time and quality (i.e., defects). Project managers need to shift their thinking from looking only at cost and schedules to monitoring size, effort, cost, time, defects and take corrective actions. However, project managers need to be very careful about attaching judgments to people performing the job. Managers should not use these measures to evaluate people. The fear of being judged is still pervasive in our culture. When used correctly, these measurements can allow everyone to see that blame usually does not lie with those doing the engineering or planning. It is always a management problem; with people being asked to execute a plan that can not possibly succeed.
Question: What is Personal Software Process (PSP)? How does it relate to the CMMI?
Answer: The Personal Software Process (PSP) takes the organizational practices, described in the Capability Maturity Model and scales them down to a personal level. Watts Humphrey, of the Software Engineering Institute, developed the PSP to address the need for individual software engineers to acquire a disciplined and effective approach to writing software programs (i.e., coding). The philosophy behind the PSP is that an organization’s ability to build large-scale software systems depends upon the ability of its individual software engineers to develop high quality small-scale programs in a disciplined, effective manner. The PSP is designed to help engineers to organize and plan their work, track their performance, manage software quality, and analyze and improve their personal process of writing software program. The PSP helps software developers understand how and why the various elements of software engineering are necessary and how they fit together. Based upon pilots in industry and universities, the PSP method is very effective in organizations that has achieved at least a maturity level of 3 (i.e., consistent process) or above.
Question: How can one avoid problems when requirements are always changing, sometimes very late in the development life cycle? How can we test software to ensure the system will perform as expected?
Answer: Requirements change is very common in software development but it can be traced to the lack of understanding between customer and developer. My advice is to cross-check to see whether you really understand the requirements by creating a test plan at the same time you write the requirements. You need to ask yourself “Is this requirement testable?” and “How will I know I’ve succeeded?” This level of detailed understanding will help you to come up with better requirements and lessen the chance of requirements changes.
Having a good requirements also help you in the next phase of project planning (i.e., estimating the work effort). You need to breakdown the requirements into small manageable tasks. The smaller your tasks, the more accurate your estimates are. Since testing will take a large portion of your project, your schedule needs to reflect that. Because software is often complex, frequently modified, and very context dependent, complete testing is often impractical. [Context dependent means all software and hardware have to work together, to achieve the effect you desire.]
Testing in context (knowing all the versions) is necessary for a valid test. Modular code with well defined interfaces could help by creating smaller pieces of code that can be well tested separately (unit testing), before testing the entire system. If the modular code is data-driven, you may be able to rapidly prototype your code. By using code to support system-wide communication, used by the individual units you create, you can do early testing for the speed your preliminary design will support, so redesign can happen before lots of coding is done.
