Hỏi: Có thể nhảy qua CMMI mức 2 và đi vào CMMI mức 3 không? Tại sao có và tại sao không?

Đáp: Không, khuôn khổ CMMI framework được dựa trên khái niệm trưởng thành là mỗi mức đều được xây dựng trên nền tảng của mức trước đó do đó bạn KHÔNG THỂ nhảy qua các mức được.  Ý tưởng cơ bản của CMMI mức 2 là ở chỗ mọi dự án đều tuân theo một qui trình (từng dự án có thể theo qui trình khác nhau) nhưng ở CMMI mức 3 tất cả các qui trình khác nhau này đều được dùng chung, được kiểm điểm và rồi được tổ chức thành “qui trình chuẩn” được xác định và được hợp nhất tốt mà mọi dự án sẽ tuân theo.

Về căn bản CMMI mức 1 là môi trường hỗn độn với những người phát triển làm việc lâu hàng giờ để xây dựng phần mềm đáp ứng lịch biểu, họ không có thời gian để kiểm thử mã riêng của mình cho nên phần mềm có nhiều lỗi. Không ai biết cái gì làm việc, cái gì không làm việc và nếu bằng cách nào đó dự án hoàn thành đúng thời gian thì điều đó gần như may mắn. Tại CMMI mức 1, không có qui trình để tuân theo và hầu hết mọi người thậm chí không biết qui trình là gì. Họ quá bận rộn viết mã và kiểm thử. Nếu cấp quản lí áp đặt một qui trình chuẩn cho nhóm này, nhóm còn chưa có thói quen tuân theo qui trình thì nó sẽ không có tác dụng bởi vì họ không có thời gian hay huấn luyện làm việc gì đó khác. Nếu ai đó bảo họ rằng cách thức họ đã từng làm việc là xấu, và đây là cách mới mà họ nên làm việc từ bây giờ thì họ có thể giận dữ bởi vì họ đã chịu nhiều căng thẳng để làm việc của mình và bây giờ họ phải tuân theo một số qui trình do ai đó tạo ra. Phần lớn những người phát triển thậm chí có thể không nhìn vào điều bạn đã xác định.

Tại mức 2, bạn có thể yêu cầu rằng một số điều cần được thực hiện, nhưng không yêu cầu rằng chúng phải được thực hiện theo cách thức chuẩn. Các dự án được yêu cầu làm tài liệu các qui trình riêng của họ thay vì tuân theo cái gì đó được người khác làm tài liệu. Xem như hệ quả, bạn có thể có những qui trình rất linh tinh và tưởng tượng được thiết lập từ các dự án khác nhau. Cách đo được yêu cầu về tính hiệu lực và hiệu quả của các qui trình đa dạng sẽ cho phép SEPG xác định cái gì làm việc tốt nhất, xem xét tới môi trường, văn hoá, mục tiêu, v.v (nhóm SQA sẽ đảm bảo rằng cách đo thực tế tương ứng với thực tại). Phân tích này về các qui trình hiện tại sẽ cho phép SEPG bắt đầu hợp nhất và cải tiến các qui trình dựa trên dữ liệu và thực hành tốt nhất để xác định qui trình chuẩn cho mức 3.

Là nghiên cứu viên tại Carnegie Mellon, tôi đã thấy nhiều tổ chức cố gắng đi thẳng vào mức 3 mà không đi qua mức 2 – và rồi hoặc mất quan tâm hoặc bỏ lửng nỗ lực của họ. Tôi tin rằng lí do chính cho điều này là ở chỗ họ đơn giản không có cơ sở hiểu biết vững chắc về điều họ đang nhìn vào, và tại sao, chừng nào họ còn chưa đạt tới sự ổn định do mức 2 đảm đương. Không có điều đó, bạn không thể xác định một cách hiện thực các qui trình chuẩn cho mức 3 (hay bất kì mức nào) các chính sách, thủ tục v.v. Tôi biết một số nhà tư vấn thậm chí bán những điều đó vì tiền nhưng phải có hiểu biết vững chắc về cách thay đổi tổ chức bên trong hoàn cảnh duy nhất của nó để thay đổi văn hoá và hành vi cá nhân.

 

Hỏi: Tính mong manh trong an ninh máy tính là gì? Từ chối dịch vụ là gì? Giả mạo vận hành thế nào? Làm sao chúng ta có thể tránh được nó?

Đáp: Tính mong manh là nhược điểm trong ứng dụng, mà có thể là một thiếu sót thiết kế hay một lỗi thực hiện cho phép kẻ tấn công gây hại cho ứng dụng phần mềm. Thuật ngữ “tính mong manh” thường được dùng rất lỏng lẻo. Tuy nhiên, ở đây chúng ta cần phân biệt đe doạ, tấn công và biện pháp đối phó. Khi vấn đề xảy ra về an ninh, điều bạn không biết sẽ làm hại bạn. Điều quan trọng với bạn là hiểu các kĩ thuật tấn công là gì để cảnh giác.

Tấn công Từ chối dịch vụ là nỗ lực làm cho tài nguyên máy tính không sẵn có cho người dùng nó. Kẻ tấn công nói chung nhắm tới các máy phục vụ web đích có lịch sử sử dụng cao.

Từ chối một dịch vụ đặc biệt sẽ tới trong một trong hai dạng *:

Tiêu thụ hoàn toàn tài nguyên như giải thông, bộ nhớ, CPU, bộ giải quyết tệp, hay bất kì tài sản hữu hạn nào.

Khai thác điểm yếu trong dịch vụ để dừng sự vận hành của nó hay làm cho dịch vụ đổ vỡ.

Tấn công từ chối dịch vụ là một số trong những việc tấn công khó bảo vệ nhất. Mọi người đôi khi gạt bỏ những tấn công này bởi vì những tấn công đó không nhắm thẳng vào đặc quyền riêng, nhưng có những trường hợp mà kẻ tấn công lại có thể mạo nhận máy phục vụ nếu máy phục vụ trở thành không sẵn có. Loại tấn công này đang trở nên ngày càng thông dụng, cho nên bạn phải được chuẩn bị về chúng.

Phòng thủ chống lại cuộc tấn công từ chối dịch vụ là khó, vì không có cách nào bảo vệ chống lại các cuộc tấn công này một cách hoàn hảo. Xem như qui tắc chung, bạn nên:

Giới hạn tài nguyên được phân bổ cho bất kì người dùng nào tới trần tối thiểu.

Tối ưu điều chỉnh máy phục vụ với hiệu năng tốt nhất.

Duy trì cập nhật các miếng vá an ninh.

Một cách mà các hacker lọt vào trong hệ thống của bạn là “Phishing-giả mạo”. Bởi vì giả mạo dựa trên sự hợp tác tích cực của người dùng, việc phòng thủ quan trọng là về phần mỗi chúng ta phải nhận biết, tỉnh táo và thận trọng. Giả mạo là một dạng của việc dùng kiến thức xã hội. Giả mạo dùng lừa đảo để lấy thông tin quan trọng và nhạy cảm của bạn như tên truy nhập, mật khẩu, chi tiết thẻ tín dụng và các thông tin doanh nghiệp hay cá nhân khác. Cuộc tấn công giả mạo thường được thiết kế trông hợp pháp. Chẳng hạn, bạn có thể nhận được một e-mail hay tin nhắn nhanh hướng bạn tới một móc nối và bạn đưa dữ liệu của mình vào một website hư huyễn. Mặc dầu thông điệp này trông “chính thức” hay đáng tin, cuộc tấn công giả mạo được thiết kế để thu thập dữ liệu nhạy cảm trên website lừa đảo để thu được quyền truy nhập không có thẩm quyền hay đánh cắp căn cước. Mục đích của cuộc tấn công giả mạo là nhắm tới và lấy ID đăng nhập của bạn, mật khẩu và các thông tin định danh cá nhân khác.

Thông tin của công ti và cá nhân được đặt trên các website kết mạng xã hội (như, LinkedIn, Facebook và Twitter) có thể được dùng để tạo ra những thông điệp có vẻ như hợp pháp với người dùng và nên được tránh. Đây là vài bước đặc biệt mà bạn có thể lấy để cảnh giác chống lại cuộc tấn công giả mạo:

Không đáp lại. Nếu bạn nhận được một e-mail khả nghi yêu cầu thông tin cá nhân, tài chính hay các thông tin nhạy cảm khác, đừng đáp lại.

Không nhấn vào đường móc nối. Các móc nối bên trong email khả nghi có thể đưa bạn tới website hư huyễn hay tung ra phần mềm gián điệp. Đôi khi việc giả mạo sẽ cung cấp cả số điện thoại để gọi. Đừng bấm hay gọi; hãy kiểm tra với nguồn đó để chắc chắn nó là hợp pháp.

 

Hỏi: Làm sao thầy thuyết phục mọi người chú ý tới qui trình phần mềm của họ khi từ “qui trình” được nhiều người coi là giấy tờ và quan liêu?

Đáp: Có những người tin rằng mọi thứ đều cần phải được làm tài liệu. Họ dành thời gian làm tài liệu các qui trình của mình mà không dùng cách hiểu thông thường nào. Vì qui trình phần mềm ngụ ý những điều khác nhau với những người khác nhau, sau đây là một ví dụ về cách qui trình nên được dùng như phương tiện để đạt tới CMM mức 2:

1.    Các yêu cầu được làm tài liệu và được dùng như tuyến cơ sở cho mọi công việc.

2.    Thay đổi yêu cầu phải tuân theo thủ tục để kiểm soát một cách có hệ thống.

3.    Các pha vòng đời phần mềm được xác định với tiêu chí vào và ra và kiểm điểm được tiến hành tại chỗ cuối của từng pha.

4.    Kế hoạch dự án phần mềm được làm tài liệu bằng bảng phân việc và các ước lượng.

5.    Tiến độ của dự án được theo dõi tương ứng với kế hoạch dự án.

6.    Người đảm bảo chất lượng và quản lí cấu hình được tham gia vào dự án từ rất sớm.

Nếu các yêu cầu không được làm tài liệu, khách hàng có thể liên tục đổi ý nhiều lần và người phát triển sẽ không có tuyến cơ sở để bắt đầu công việc của họ.

Nếu thay đổi yêu cầu không dựa trên qui trình kiểm soát có hệ thống, khách hàng hay người quản lí có thể cam kết với sự biến thiên rộng những thay đổi không thể thức ở giữa chừng dự án. Vậy người phát triển sẽ phải đối diện với sức ép lịch biểu nghiêm trọng và luồn lách phạm vi.

Nếu dự án không nhận diện vòng đời bằng kiểm điểm tại cuối mỗi pha, mọi người sẽ bị buộc phải tuân theo các vòng thiết kế, viết mã, kiểm thử, thiết kế lại, viết mã lại, và kiểm thử lại vô tận. Tổ phần mềm sẽ dành nhiều thời gian hơn vào việc gỡ lỗi, ưu tiên hoá các nhiệm vụ, và thực hiện việc làm lại đến phút chót, chất lượng phần mềm sẽ bị ảnh hưởng.

Nếu dự án không được lập kế hoạch tương ứng theo qui trình với bảng phân việc và ước lượng thì kế hoạch dự án không là gì ngoài sơ đồ lịch biểu được cam kết. Làm sao bạn có thể quản lí được một dự án với các nhiệm vụ không được xác định và lịch biểu không hợp lí? Người phát triển sẽ dành nhiều thời gian hơn cho việc tranh cãi về điều họ phải làm vào lúc nào đó hơn là làm việc thực.

Nếu người làm đảm bảo chất lượng và quản lí cấu hình không được tham dự sớm vào dự án, bạn sẽ mất kiểm soát về tính toàn vẹn của phần mềm và thay đổi qui trình và mọi thứ sẽ hỗn độn và khó sửa.

Không có qui trình được xác định, dự án sẽ mất nhiều thời gian vào tranh cãi thay vì làm các hoạt động gia tăng giá trị.

Người phát triển phần mềm muốn có năng suất; họ sẽ không dung thứ việc lãnh đạo yếu kém không cung cấp sự hỗ trợ hay ít giúp trong quản lí dự án. Lãnh đạo yếu kém đưa tới nhiều cãi lộn và sửa lỗi hơn là tạo ra nhiều phần mềm hơn. Cải tiến qui trình đảm bảo rằng có những qui trình tại chỗ để hỗ trợ cho dự án làm công việc có giá trị thực, không tạo ra tài liệu không cần thiết.

 

Hỏi: Định nghĩa của thầy về chương trình cải tiến qui trình thành công là gì? Đạt tới CMMI mức 5 sao?

Đáp: Định nghĩa riêng của tôi về chương trình cải tiến qui trình thành công là ở chỗ có tác động định lượng được lên hiệu năng của tổ chức. Mục đích tối thượng của bất kì chương trình cải tiến nào là cải tiến mục đích doanh nghiệp như chi phí, thời gian, lịch biểu v.v. Mức trưởng thành không có nghĩa gì chừng nào nó còn không có tác động lên mục đích và mục tiêu doanh nghiệp. Bằng không có lẽ nó là việc phí thời gian và tiền bạc. Tôi KHÔNG thích mức độ trưởng thành bởi vì nó đã bị quảng cáo và lạm dụng quá mức.

 

Hỏi: Tôi biết rằng Microsoft KHÔNG dùng CMMI nhưng dầu vậy vẫn rất thành công. Tại sao chúng ta không theo cách tiếp cận của họ?

Đáp: Không phải tất cả các tổ chức phần mềm đều như Microsoft. Chúng ta không thể so sánh Táo và Cam được. Với một số tổ chức phần mềm, mục đích là có sản phẩm phần mềm chất lượng cao để hỗ trợ cho kinh doanh dù nó là làm máy bay hay cung cấp dịch vụ cho khách hàng như Ngân hàng. Mục đích kinh doanh của Microsoft là số một trên thị trường để thâu tóm thị phần và kiểm soát thị trường để đảm bảo mọi người đều mua phần mềm của họ. Họ không coi chất lượng hay chi phí là quan trọng khi so sánh với thị phần. Tuy nhiên, tôi tin chúng ta có thể học được nhiều từ Microsoft. Bí mật của họ nằm ở động cơ và các gói đền bù của họ. Nếu chúng ta tập trung vào động cơ và cải tiến tinh thần nhân viên, tôi nghĩ chúng ta đang đi đường đúng.

 

Hỏi: Chúng tôi hiểu rằng việc thẩm định CMMI là rất tốn kém hơn và tốn thời gian cho nên chúng tôi chỉ muốn tiến hành tự thẩm định bằng việc điền vào bảng hỏi về trưởng thành. Làm thế có được không?

Đáp: Tại sao bạn muốn tiến hành tự thẩm định kiểu như thế? Có lẽ để tìm ra bạn đang ở đâu trên thang trưởng thành CMMI chăng? Được, vậy bạn đang ở CMMI mức 1 đấy rồi gì nữa nào? Tôi mạnh mẽ thúc giục tổ chức không tiến hành bất kì thẩm định nào chừng nào toàn bộ tổ chức còn chưa cam kết đầy đủ với việc cải tiến qui trình. Có nhiều điều cần được làm trước khi tiến hành thẩm định.

 

Hỏi: Tại sao chúng ta cần tuân theo khuôn khổ CMMI theo trật tự họ qui định? Ích lợi gì mà cố lên mức 3 trên nền việc bước qua mức 2 như một điều kiện tiên quyết?

Đáp: Giả sử một tổ chức CMMI mức 1 đang dưới sức ép lịch biểu cực kì gay cấn phải chuyển giao phần mềm. Không sửa sức ép lịch biểu này bằng việc quản lí dự án và thay đổi yêu cầu (các hoạt động mức 2), tổ chức vẫn “phải chịu số phận” đi lên mức 3. Tuy nhiên, phần lớn các thẩm định mức 1 đều khuyến cáo một số hoạt động mức 3 như thiết lập SEPG nếu còn chưa có, và điều khá thông dụng là khuyến cáo tiến hành nhiều kiểm điểm hơn. Là một thành viên SEPG, bạn phải nhạy cảm với sự chống lại thay đổi, và có lẽ mức độ hoài nghi nào đó trong đáp ứng lại thông điệp của bạn, “SEPG ở đây để giúp bạn cải tiến.” Bạn cần hiểu mọi khía cạnh của thay đổi để cho bạn có thể vượt qua nhiều rào chắn và thường điều đó nghĩa là giải quyết với những mối quan tâm chuyên dự án trước hết rồi mới tới chuẩn hoá tổ chức sau.

 

Hỏi: Lập trình cực đoan eXtreme Programming (EP) là gì. Chúng ta nên hay không nên chấp thuận EP và làm sao nó khớp vào các hoạt động CMM?

Đáp: Lập trình cực đoan eXtreme Programming (EP) là phương pháp phát triển phần mềm đã được Kent Beck mô tả bằng các tài liệu có liên quan do Martin Fowler và Ron Jeffries sinh ra. Mới thoáng nhìn, người ta có thể nghĩ rằng nó là phương pháp được thiết kế với sự tập trung vào lập trình, không phải vào kĩ nghệ phần mềm. Tuy nhiên, bản thân là một người lập trình EP, tôi tin nó bao quát nhiều ý tưởng kĩ nghệ phần mềm tuyệt hảo như lập trình cặp đôi, phát triển gia tăng, khách hàng tại chỗ, tích hợp liên tục, và kiểm thử liên tục. Mục đích đằng sau eXtreme Programming là thời gian chu kì và quản lí rủi ro. Và nó cũng không thực sự mới; nó chỉ lấy các khái niệm nổi tiếng và đẩy chúng tới các giới hạn.

Theo ý kiến của tôi, nó có tác dụng tốt cho tổ nhỏ (2 tới 6 người) làm sản phẩm phần mềm riêng lẻ với việc tích hợp hay trao đổi dữ liệu có giới hạn. Cũng giống như tập bất kì môn thể thao một cách mù quáng đều rất nguy hiểm, làm eXtreme Programming, mà không hiểu rõ ràng những giới hạn của nó về sử dụng phương pháp này, có thể dẫn dự án EP vào môi trường hỗn độn không thể thức.

 

Hỏi: Tôi đã xem các blog của thầy về CMMI và tin nó là tốt nhưng chúng tôi không có thời gian để làm tất cả những hoạt động cho dự án rất lớn của tôi. Nếu tôi chỉ có thể làm một hoạt động để cải tiến, nó sẽ thế nào?

Đáp: Thống kê chỉ ra rằng các chương trình phần mềm lớn thất bại ở tỉ lệ đáng báo động. Tỉ lệ thất bại đối với chương trình lớn (quãng 1 triệu dòng mã hay hơn) cao vào quãng 65%, tương ứng với nghiên cứu được Ts. Capers Jones thực hiện. Nhiều chương trình phí tiền bạc, tài nguyên, và thời gian và không chuyển giao điều chúng hứa hẹn. Các nghiên cứu thêm tìm ra căn nguyên của tất cả những điều tồi tệ này là ở chỗ người quản lí chương trình và khách hàng không xác định và thiết lập thích hợp về phạm vi và yêu cầu của chương trình. Nếu bạn chỉ có thể làm được một điều, tôi gợi ý tập trung vào việc nắm bắt yêu cầu và kiểm soát phạm vi của chương trình.

 

Hỏi: Tại sao chúng tôi cần cải tiến qui trình  khi kinh doanh của chúng tôi là phát triển sản phẩm để bán trên thị trường?

Đáp: Thuật ngữ “cải tiến qui trình” được dùng để đặc trưng cho nỗ lực của tổ chức kiểm tra chặt chẽ và cải tiến qui trình của mình. Nó dựa trên giả định rằng qui trình được cải tiến sẽ có tác dụng vào sản phẩm được cải tiến. Mục đích tối thượng là thực sự cải tiến bản thân sản phẩm. Nếu qui trình được cải tiến không có tác dụng tích cực lên sản phẩm được sinh ra, thế thì chẳng có biện minh gì được cho việc tạo ra thay đổi cả.

 

Hỏi: Tôi muốn phát triển một công cụ để tự động hoá cải tiến qui trình để giúp tổ chức đạt tới mức trưởng thành cao hơn. Có công cụ như thế trên thị trường chưa?

Đáp: Tôi không biết công cụ như thế ngày nay có tồn tại không nhưng trước khi bạn bắt đầu tạo ra công cụ, bạn có thể cần xem xét điều này: Qui trình phải tồn tại trước khi tự động hoá qui trình có thể xảy ra và cải tiến qui trình là cải tiến qui trình đang tồn tại. Làm sao bạn phát triển một công cụ để cải tiến qui trình mà có thể còn chưa tồn tại?  Công cụ là việc thực hiện của qui trình và nó phải tuân theo qui trình đang tồn tại chứ không phải là khái niệm về qui trình.

 

Hỏi: Chúng tôi quan tâm tới việc bắt đầu chương trình cải tiến qui trình trong tổ chức của mình. Làm sao chúng tôi bắt đầu đây?

Đáp: Cải tiến qui trình phần mềm là cuộc hành trình dài yêu cầu có cam kết. Có những vấn đề mà bạn sẽ gặp phải như sự hỗ trợ của cấp quản lí, tài nguyên nhân lực, tri thức và kĩ năng. Tổ chức của bạn phải có khả năng giải quyết những điều này trước khi bắt đầu cuộc hành trình cải tiến qui trình: Bạn cần tự hỏi mình những câu hỏi sau:

1.    Mục đích của chúng ta là gì?

2.    Tại sao chúng ta cần cải tiến qui trình?

3.    Chúng ta cần có loại kết cấu nền nào tại chỗ?

4.    Ai cần được tham gia vào?

5.    Làm sao chúng ta có được sự ủng hộ của cấp quản lí?

6.    Làm sao chúng ta đặt ra các ưu tiên?

7.    Chúng ta có thể có giúp đỡ từ đâu?

Không đề cập tới những câu hỏi này sẽ làm nảy sinh cuộc hành trình cải tiến hỗn độn không thể thức chẳng dẫn tới đâu cả.

 

Hỏi: Quản lí yêu cầu chỉ áp dụng cho dự án mới phát triển thôi chứ? Chúng ta có thể áp dụng nó cho dự án bảo trì không?

Đáp: Quản lí yêu cầu có thể được áp dụng cho cả dự án phát triển và bảo trì. Trong dự án bảo trì điển hình, có Yêu cầu thay đổi, Báo cáo vấn đề …v.v. điều có thể được xem như các yêu cầu vì chúng xác định ra phạm vi của nỗ lực riêng mà bạn sẽ phải làm việc trên chúng. Điều CMMI yêu cầu là tất cả các yêu cầu đều phải được làm tài liệu, được kiểm soát và được đồng ý từ mọi nhóm bị ảnh hưởng. Mọi kế hoạch, thay đổi, và hoạt động đều phải được giữa nhất quán và theo dõi được về những yêu cầu này.

Hỏi:

Sự khác biệt giữa dùng lại theo cơ hội và dùng lại có hệ thống là gì?

Đáp:

Dùng lại theo cơ hội bao gồm phần lớn là mã, điều có thể có sẵn trong kho nơi mọi người có thể truy lục và dùng. Mọi người có thể thay đổi nó khi họ thấy khớp. Việc dùng không thể thức này không rất ích lợi do việc thực hiện và sửa đổi không đúng. Không có tiết kiệm chi phí trong cách tiếp cận này vì người phát triển vẫn phải tìm điều họ cần, sửa nó, và kiểm thử sản phẩm cuối cùng.

Dùng lại có hệ thống là việc phát triển sản phẩm phần mềm từ tập các tài sản dùng lại, để cho sự tương tự trong các yêu cầu và kiến trúc giữa các ứng dụng có thể được khai thác để đạt tới ích lợi bản chất về năng suất, hiệu năng, chất lượng và mục đích kinh doanh. Cách tiếp cận này yêu cầu dùng lại theo thiết kế không ngẫu nhiên. Tài sản dùng lại là các yêu cầu, kế hoạch dự án, ước lượng, kiến trúc, thiết kế, giao diện người dùng, kế hoạch kiểm thử, trường hợp kiểm thử, dữ liệu, KHÔNG chỉ có mã. Tôi tin dùng lại có hệ thống, nếu được hiểu đúng, và được thực hiện đầy đủ, có thể cải tiến triệt để năng lực phát triển của tổ chức phần mềm.

 

Hỏi: Tôi được bảo phải thiết lập tuyến cơ sở đo nhưng tổ chức của chúng tôi đã được tái tổ chức nhiều lần trong quá khứ, phần lớn dữ liệu đều không liên quan và không nhất quán.

Đáp: Tổ chức cần thu thập dữ liệu hiệu năng lịch sử (lịch biểu, chi phí, chất lượng) để thiết lập tuyến cơ sở cho so sánh tương lai. Chúng ta đang tìm xu hướng chứ không phải là dữ liệu chính xác hay tuyệt đối, tôi tin bất kể tổ chức thay đổi thế nào, xu hướng như vậy đều có thể được tìm thấy mà không mất quá nhiều công sức.

 

Hỏi: Sao chúng ta cần cải tiến qui trình phần mềm khi khoán ngoài dường như là câu trả lời?

Đáp: Tôi biết rằng chất lượng, năng suất, chi phí và thời gian chu kì là then chốt cho thành công kinh doanh. Trong phần lớn các tổ chức phần mềm các nhân tố này thường không thích hợp đó là lí do tại sao chúng ta cần cải tiến qui trình phần mềm. Rất dễ nhảy vào kết luận khi các từ  thông dụng như “Khoán ngoài,” “thương mại sẵn trên giá”, “Công cụ Case,” “Phương pháp luận thần kì” đang nóng trong công nghiệp. Với hoàn cảnh lịch sử, điều dường như là thiển cận cho bất kì tổ chức nào thực hiện công nghệ mà không có xem xét nào đó.

Tôi tin, dành tiền cho phát triển phần mềm từ đầu khi đã có sản phẩm hàng hoá hoàn hảo “sẵn trên giá” không phải là cách dùng tiền tốt. Tôi cũng tin rằng việc chọn lựa phần mềm COTS đã đóng gói sẵn từ một công ti, và dành thời gian để sửa nó để chắc chắn nó làm việc không phải là nước đi khôn ngoan nữa. Trước khi chúng ta để ai đó làm việc cho chúng ta (khoán ngoài, hợp đồng phụ) chúng ta phải có qui trình để lựa công ti có phẩm chất tốt nhất, quản lí hợp đồng cẩn thận, điều phối sự phát triển của họ đều kì, và tạo ra tiêu chí chấp nhận để đảm bảo hiệu năng của sản phẩm của họ trước khi tích hợp chúng vào môi trường của chúng ta.

Chừng nào còn chưa quyết định về khoán ngoài, vẫn còn nhiều chỗ để cải tiến trong nhà, đặc biệt trong qui trình phần mềm. Trong hầu hết các tổ chức từng dự án đều vẫn được coi là duy nhất, và bài học rút ra từ dự án quá khứ không được bắt giữ hay dùng theo cách có tổ chức. Nếu chúng ta phạm phải sai lầm, chúng ta có thể lặp lại cùng sai lầm lặp đi lặp lại. Tôi tin rằng nếu chúng ta có thể dùng lại thực hành tốt nhất, khử bỏ các lỗi và phế thải từ qui trình hiện thời, thì sẽ tạo ra sản phẩm chất lượng, năng suất sẽ được cải thiện, và chung cuộc chi phí và thời gian chu kì sẽ giảm.

 

Hỏi: Tại sao chúng ta không thể triển khai nhiều hành động một lúc để cho chúng ta có thể xúc tiến các hoạt động cải tiến? Tại sao phải đi qua các pha như xác định, thử nghiệm, xét duyệt và thể lệ hoá.

Đáp: Thực hiện gia tăng được dựa trên các bài học rút ra từ kinh nghiệm quá khứ. Tôi tin cải tiến là quá trình học tập và tổ chức không thể học mọi thứ một lúc được. Có đường cong học tập cho mọi nhiệm vụ mới và việc thể lệ hoá mất thời gian. Sau khi thẩm định, tổ chức sẽ lập kế hoạch hành động và bản kế hoạch hành động phải bao gồm nhiều nhiệm vụ nhỏ cần được thực hiện trong khuôn khổ thời gian hay pha ba tháng (xác định, thử nghiệm, xét duyệt và thể lệ hoá). Tổ chức có thể thực hiện một tập hai hay ba nhiệm vụ đồng thời để giảm nhẹ rủi ro và đảm bảo thời gian học cho tổ chức.

—-English version————-

 

Question: Is it possible to skip CMMI level 2 and go to CMMI Level 3? Why and Why not?

Answer: No, the CMMI framework is based on a maturity concept that each level is built on the foundation of previous level therefore you can NOT skip level.  The basic idea of CMMI level 2 is that every project is following a process (Each project may follow different process) but at CMMI level 3 all of these different processes are shared, reviewed and then organized into a well defined and consolidated well defined “Standard process” that all projects will follow.

Typically CMMI Level 1 is a chaotic environment with developers working long hours to build software to meet the schedule, they do not have time to test their own code so the software have many defects. Nobody knows what works, what do not work and if somehow the project complete on time is it mostly luck. At CMMI Level 1, there is no process to follow and most people do not even know what a process is. They just too busy coding and testing. If management imposes a standard process on this group who are not yet in the habit of following a process then it will not work because they do not have time or the training to do something else. If someone tells them that the way they have been working is bad, and this is the new way that they should work from now on then they could be angry because they already have a lot of stress to do their works and now they have to follow some processes created by somebody. Most developers may not even look at what you have defined.

At level 2, you can request that a number of things be done, but without requiring that they be performed in a standard manner. The projects are requested to document their own processes rather than following something documented by another. As a consequence, you may have some very diverse and imaginative processes established in different projects. The required metrics on the efficiency and effectiveness of the various processes will allow the SEPG to determine what is working best, considering the environment, the culture, the objectives, etc (the SQA group will ensure that the metrics actually correspond to the reality). This analysis of the existing processes will allow the SEPG to start consolidating and improving the processes based on data and best practices to define the standard process for Level 3.

As a researcher at Carnegie Mellon, I have seen so many organizations try to go directly to Level 3 without moving through Level 2 – and then either losing interest or abandoning their efforts. I believe that the primary reason for this is that they simply don’t have a solid basis of understanding of what they’re good at, and why, until they achieve the stability afforded by Level 2. Without that, you cannot realistically define standard processes at Level 3 that serve the projects’ needs. Anyone can write standard process for Level 3 (or any level) policies, procedures, etc. I know some consultants even sell them for money but it takes a solid understanding of how to change an organization within its unique context to change the culture and individual behavior.

 

Question: What is vulnerability in computer security? What is Denial of Service? How it Phishing works? How can we avoid it?

Answer: Vulnerability is a weakness in the application, which can be a design flaw or an implementation defect that allows an attacker to cause harm to the software application. The term “vulnerability” is often used very loosely. However, here we need to distinguish threats, attacks, and countermeasures. When it comes to security, what you don’t know will hurt you. It’s important for you to understand what attack techniques to watch for.

A Denial of Service attack is an attempt to make a computer resource unavailable to its users. Attackers generally target high-profile web servers.

Denial of a particular service will come in one of two forms*:

Complete consumption of a resource such as bandwidth, memory, CPU, file handles, or any other finite asset.

Exploiting a weakness in the service to stop it functioning or causing the service to crash.

Denial of service attacks are some of the most difficult attacks to protect against. People sometimes dismiss these attacks because the attacks don’t directly elevate privilege, but there are cases in which an attacker might be able to impersonate the server if a server becomes unavailable. This kinds of attack are becoming increasingly common, so you should be prepared for them.

Defending against denial of service attacks is difficult, as there is no way to protect against these attacks perfectly. As a general rule, you should:

Limit the resources allocated to any user to a bare minimum.

Optimize server tuning for best performance.

Stay up to date with security patches.

One way hackers get into your system is “Phishing”. Because phishing relies on the active cooperation of users, an important defense is for each of us to be aware, alert and cautious. Phishing is a form of social engineering. Phishing uses fraudulent attempts to acquire your important and sensitive information such as usernames, passwords, credit card details and other business or personal information. A phishing attack usually is designed to look legitimate. For example, you might receive an e-mail or instant message directing you to link to and enter your data at a bogus Web site. Although the message looks “official” or trustworthy, a phishing attack is designed to gather sensitive data on these fraudulent Web sites to gain unauthorized access or steal identities. The goal of a phishing attack is to target and get your logon IDs, passwords and other personally identifiable information.

Company and personal information placed on social networking Web sites (e.g., LinkedIn, Facebook and Twitter) can be used to craft messages that appear to be legitimate to the user and should be avoided. Here are some specific steps that you can take to guard against phishing attacks:

Don’t respond. If you get a suspicious e-mail that requests personal, financial or other sensitive information, don’t respond.

Don’t click on links. Links inside suspicious e-mails can take you to bogus Web sites or launch spyware. Sometimes phishing will provide a phone number to call. Don’t click or call; check with the source to make sure it is legitimate.

 

Question: How do you convince people to pay attention to their software process when the word “process” is viewed by many as paperwork and bureaucracy?

Answer: There are people who believe that for everything there must be documented. They spend time documenting their processes without using any common sense. Since software process means different things to different people, here is an example of how a process should be used as a means to achieve CMM Level 2:

1.    Requirements are documented and used as a baseline for all the work.

2.    Changes to requirements follow a procedure for systemic control.

3.    Software life cycle phases are defined with entry and exit criteria and reviews are conducted at the end of each phase.

4.    Software project plans are documented with work breakdown structures and estimates.

5.    Progress of a project is tracked according to the project plan.

6.    Quality assurance and configuration management people are involved in the project very early.

If requirements are not documented, customers may continue to change their minds several times and developers will have no baseline to start their work.

If changes to requirements are not based on a systemic control process, customers or managers may commit to a wide variety of ad-hoc changes in the middle of a project. Developers will then be facing serious schedule pressure and scope creep.

If projects do not identify life cycles with reviews at the end of each phase, people will be forced to follow the design, code, test, redesign, recode, and retest cycles ad infinitum. The software team will spend more time fixing bugs, prioritizing tasks, and doing reworks and in the end, the quality of the software will suffer.

If the project is not planned according to a process with a work breakdown structure and estimates then the project plan is nothing but a committed schedule chart. How can you manage a project with undefined tasks and an unreasonable schedule? Developers will spend more time arguing over what they have to do at certain times than doing real work.

If quality assurance and configuration management people are not involved early in the project, you will lose control of software integrity and the change process and everything will be chaotic and difficult to fix.

Without a defined process, the project will spend a lot of time arguing rather than doing value added activities.

Software developers like to be productive; they will not tolerate weak leadership that provides no support or little help in managing the project. Weak leadership leads to more arguing and fixing defects than to creating more software. Process improvement is ensuring that there are processes in place to support the project to do real value work, not to create unnecessary documentation.

 

Question: What is your definition of a successful process improvement program? Achieving CMMI level 5?

Answer: My own definition of a successful process improvement program is that there is a quantifiable impact on organization performance. The ultimate goal of any improvement program is to improve the business goals such as cost, time, schedule etc. A maturity level does not mean anything unless it has impact on the business goals and objectives. Otherwise it is probably a waste of time and money. I do NOT like maturity level because it has been overly advertised and abused.

 

Question: I know that Microsoft did NOT use the CMMI but still very successful. Why can’t we follow their approach?

Answer: Not all software organizations are like Microsoft. We can not compare Apples and Oranges. To some software organizations, the goal is to have high quality software products to support the business whether it is building an airplane or providing a service to customer such as a Bank. Microsoft‘s business goal is to be the first on the market to capture market share and control the market to ensure everybody buy their software. They do not consider quality or cost as important when compare with market share. However, I believe we can learn a lot from Microsoft. Their secret lies in their motivation and compensation packages. If we focus on motivation and improving employee morale, I think we are on the right track.

 

Question: We understand that a CMMI appraisal is very costlier and time consuming so we only want to conduct a self-assessment by fill out the maturity questionnaire. Is it OK?

Answer: Why would you want to conduct a self-assessment like that? Perhaps to find out where you are on the CMMI maturity scale? OK so you are a CMMI level 1 then what? I strongly urge the organization not to conduct any assessment unless the entire organization is fully committed to improve the process. There are many things needed to be done before conduct assessment.

 

Question: Why do we need to follow the CMMI framework in the order they prescribe? What are the benefits of striving for Level 3 as opposed to stepping through Level 2 as a prerequisite?

Answer: Suppose a CMMI Level 1 organization is under extreme schedule pressure to deliver software. Without fixing this schedule pressure by managing the project and requirements changes (Level 2 activities), the organization is “doomed” to go to level 3. However, most Level 1 assessments do recommend some Level 3 activities such as the establishment of a SEPG if one doesn’t already exist, and it’s fairly common to recommend conducting more reviews. As a SEPG member, you must be sensitive to the resistance to change, and perhaps a degree of cynicism in response to your message, “SEPG is here to help you to improve”. You need to understand all aspects of the change process so you can overcome many roadblocks and frequently that means dealing with project-specific concerns first and organizational standardization later.

 

Question: What is eXtreme Programming (EP). Should we or shouldn’t we adopt EP and how does it fit in CMM activities?

Answer: eXtreme Programming (EP) is a software development method that has been described by Kent Beck with related materials generated by Martin Fowler and Ron Jeffries. At first glance, one may think that it is a method designed with a focus on programming, not software engineering. However, as an EP programmer myself, I believe it covers many excellent software engineering ideas like pair programming, incremental development, on-site customer, continuous integration, and continuous testing. The goals behind eXtreme Programming are cycle time and risk management. And it’s not really new; it just takes well-known concepts and pushes them to the limits.

In my opinion, it works well for a small team (2 to 6 people) doing stand-alone software products with limited integration or data exchange. Just like blindly doing any sport can be very dangerous, doing eXtreme Programming, without clearly understanding its limitations on the usage of the method, can lead an EP Project into an ad hoc chaotic environment.

 

Question: I have seen your blogs on CMMI and believe it is good but we do not have time to do all activities for my very large project. If I can do only one activity to improve, what would it be?

Answer: Statistics show that large software programs fail at an alarming rate. The failure rate for large programs (around 1 million lines of code or more) is as high as 65%, according to studies performed by Dr. Capers Jones. Many programs waste money, resources, and time and not deliver what they promise. Further studies found the root cause of all the bad things is that the program manager and the customer fail to adequately define and establish the scope and requirements of the program. If you can only do one thing, I suggest focusing on capturing requirements and controlling the scope of the program.

 

Question: Why do we need to improve the process when our business is to develop a product to be sold on the market?

Answer: The term “Process improvement” is used to characterize the efforts of an organization to closely examine and improved its process. It is based on the assumption that an improved process will result in an improved product. The ultimate goal is really to improve the product itself. If an improved process has no positive impact on the product generated, then there is no justification for making the change.

 

Question: I would like to develop a tool for automate process improvement to help organization achieving higher level of maturity. Is there tool like that in the market yet?

Answer: I do not know such a tool exist today but before you start to create a tool, you may want to consider this: Process must exist before process automation can take place and process improvement is the improvement of an existing process. How do you develop a tool to improve a process that may not exist yet?  Tool is the implementation of a process and it must flows from an existing process not a concept of a process.

 

Question: We are interested in starting a process improvement program in our organization. How do we start?

Answer: Software process improvement is a long journey that requires commitments. There are issues that you will encounter such as management support, resources, knowledge and skills. Your organization must be able to resolve these before starting the process improvement journey: You need to ask yourself the following questions:

1.    What are our goals?

2.    Why do we need to improve the process?

3.    What kind of infrastructure do we need to have in place?

4.    Who needs to be involved?

5.    How do we obtain management sponsorship?

6.    How do we set priorities?

7.    Where can we turn for help?

Failure to address these questions properly will result in ad-hoc chaotic improvement journey that leads to nowhere.

 

Question: Does Requirements Management only apply to new development project? Can we apply it to maintenance project too?

Answer: Requirements Management can be applied both to development and maintenance projects. In a typical maintenance project, there are Change Requests, Problem Reports …etc. which can be considered requirements since they define the scope of specific efforts that you will have to work on them. What the CMMI requires is all requirements must be documented, controlled and agreed by all affected groups. All plans, changes, and activities must be kept consistent with and traceable to these requirements.

 

Question: What is the different between opportunistic reuse and systemic reuse?

Answer: Opportunistic reuse involves mostly code, which may available in a repository where people can retrieve and use. People may modify it as they see fit. This ad-hoc reuse is not very beneficial due to improper implementation and modification. There is no cost saving in this approach since developer still have to search for what they want, modify it, and test the final product.

Systemic reuse is the developing software product from a set of reusable assets, so that similarity in requirements and architecture between applications can be exploited to achieve substantial benefits in productivity, performance, quality and business goals. This approach requires reuse by design not random. Reusable assets are requirements, project plans, estimates, architectures, designs, user interfaces, test plans, test cases, data, NOT just code. I believe systemic reuse, properly understood, and fully implemented, can radically improve the development capability of a software organization.

 

Question: We are told to establish a measurement baseline but our organization has been reorganized several times in the past, most data are irrelevant and inconsistent.

Answer: Organization needs to collect historical performance data (Schedule, cost, quality) to establish a baseline for future comparison. We are looking for trends not accurate or absolute data, I believe regardless of organization changes, such a trend can be found without too much effort.

 

Question: Why do we need software process improvement when outsourcing seems to be the answer?

Answer: I do know that quality, productivity, costs, and cycle time are the key to business success. In most software organizations these factors are often inadequate that is why we need software process improvement. It is very easy to jump into conclusion when certain buzzword such as “Outsourcing”, “Commercial Off The Shelf”, “Case-Tools”, “Miracle Methodology” are hot in the industry. Given historical perspective, it seems shortsighted for any organization to implement technology without certain consideration.

I believe, spending money developing software from scratch when there are perfectly good “Off-the-Shelf” product is not a good use of money. I also believe that selecting a pre-packaged COTS software from a company, and spending time modifying it to make sure it works is not a wise move, either. Before we let somebody to do the work for us (Outsourcing, subcontracting) we must have a process to select the best qualified company, manage the contracts carefully, monitor their development periodically, and create an acceptance criteria to ensure the performance of their product before integrate them into our environment.

Until decision is made on outsourcing, there are plenty of rooms to improve in house, especially in the software process. In most organizations each project is still considered unique, and lessons learn from past project is not captured or used in an organized way. If we made mistakes, we could repeat the same mistake again and again. I believe that if we can reuse the best practices, eliminating defects and waste from current process, then produce quality product, productivity will improve, and ultimately costs and cycle time will fall.

 

Question: Why can’t we deploy several actions at once so we can expedite the improvement activities? Why go through phases such as define, pilot, revise, and institutionalize.

Answer: Incremental implementation is based on lessons learned from past experiences. I believe improvement is a learning process and the organization can not learn everything at once. There is a learning curve for every new task and institutionalization takes time. After the assessment, organization will plan actions and the action plan should consist of several small tasks to be implemented in a three month time frame or phrase (Define, pilot, revise, and institutionalize). The organization can implemented a set of two or three tasks at the same time to mitigate risk and ensure learning time to the organization.