Đáp: Có khác biệt giữa phần cứng và phần mềm:

a)     Bạn có thể chạm tới phần cứng nhưng bạn không thể chạm tới phần mềm.

b)     Bạn có thể nhìn vào phần cứng nhưng bạn không thể nhìn vào phần mềm.

c)     Bạn có thể quan sát hệ thống phần cứng được xây dựng và biết quãng 50% hệ thống phần cứng ngay tại chỗ, nhưng bạn không biết về điều này với phần mềm.

d)     Bạn có thể giải quyết các vấn đề phần cứng bằng việc lắp CPU hiệu năng cao, thêm bộ nhớ, tăng giải thông, hay đổi bo mẹ để cho hệ thống phần cứng có thể chạy nhanh hơn hay thực hiện tốt hơn. Điều này không bao giờ xảy ra trong phần mềm.

e)     Để xây dựng phần cứng nhanh hơn bạn có thể thêm nhiều người hơn và tăng khối lượng sản xuất nhưng điều này không đúng trong phần mềm. Đôi khi nhiều người còn tạo ra nhiều vấn đề hơn với phần mềm.

f)       Qui trình phát triển phần cứng có thể được xác định chính xác, bạn biết cái gì phải làm trước và cái gì phải làm sau cùng và bạn có thể đo thời gian tốn cho từng bước trong qui trình một cách chính xác. Nhưng bạn không thể làm điều đó với phần mềm bởi vì mọi người làm mọi thứ khác nhau không chính xác.

Khi tổ chức phần mềm được quản lí bởi những người thành công trong nghiệp vụ phần cứng, rắc rối nghiêm trọng sẽ xảy ra. Cả hai phía đều phải tranh đấu để thuyết phục nhau bởi vì cách nghĩ khác nhau. Sản phẩm phần mềm là duy nhất tới mức các phương pháp và công cụ chung không có tác dụng tốt. Không có “một phương pháp phù hợp cho tất cả” trong phần mềm. Bạn phải nhìn vào các phương pháp và công cụ chuyên lĩnh vực bởi vì ưu tiên là khác nhau giữa các lĩnh vực. Chẳng hạn, qui trình mấu chốt cho phần mềm thương mại là việc sửa luồng dữ liệu nhưng phần mềm khoa học lại tập trung vào thuật toán đúng. Với phần mềm thương mại trên thị trường (COTS) điều quan trọng là thiết kế giao diện tốt nhưng với hệ thống nhúng thì điều quan trọng là đẩy các lệnh vào chip bộ nhớ ít nhất. Người thiết kế phần mềm cho vệ tinh viễn thông không làm theo cùng cách họ làm khi thiết kế website e-commerce.

Hỏi: Tại sao chúng ta cần Ban chỉ đạo, SEPG, và nhóm công tác hay cải tiến qui trình? Thầy có đang biện bộ cho quan liêu hơn không đấy?

Đáp: Sau nhiều năm quản lí cải tiến qui trình phần mềm, tôi thấy rằng kết cấu nền là điều mấu chốt nhất cho sự thành công hay thất bại của cải tiến. Theo kinh nghiệm riêng của mình, tôi mạnh mẽ thúc giục tổ chức thành lập một cấu trúc ba bên như sau:

1)    Ban chỉ đạo bao gồm những người lãnh đạo điều hành cấp cao và người quản lí then chốt của tổ chức. Vai trò của họ là thiết lập hướng đi cho cải tiến, lập ưu tiên và cấp quyền cho các hoạt động cải tiến, cấp phát tài nguyên và thúc đẩy các hoạt động cải tiến.

2)    SEPG bao gồm những người có kĩ năng và kinh nghiệm trong tổ chức để phối hợp và tạo điều kiện cho các hoạt động cải tiến và giữ thông báo thường xuyên cho ban chỉ đạo biết.

3)    Các nhóm công tác bao gồm những người kĩ thuật được thành lập để trển khai các hoạt động cải tiến, để giải quyết các vấn đề được nhận diện trong kế hoạch hành động và để làm cho cải tiến xảy ra.

Cải tiến qui trình là về thay đổi và thay đổi chủ yếu là về cách làm. Nếu mọi người không thay đổi cách làm của mình, không có cải tiến. Ban Chỉ đạo đặt ra mục đich và mong đợi về thay đổi cách làm và trông đợi thấy nó xảy ra. SEPG ủng hộ thay đổi cách làm, và quản lí các hoạt động thay đổi. Để thành công, họ phải có kĩ năng đúng để quản lí các hoạt động cải tiến hay động viên việc thay đổi cách làm. Nhiều người có thể được huấn luyện bằng việc tham dự lớp học nhưng có thể không phát triển các kĩ năng này nếu họ không áp dụng điều họ đã học vào thực tế. Nếu tổ chức có thể nhận diện các sai lầm hay thất bại, thì họ có thể phát triển và duy trì các kĩ năng cần để giữ cho thất bại không xảy ra nữa. Tôi thực sự tin SEPG giúp cho tổ chức trở nên có kĩ năng mà không mất mặt.  Nhóm công tác phải được lựa chọn cẩn  thẩn cho hoạt động cải tiến vì họ giải quyết cho việc thay đổi cách làm và nêu gương về hành vi mong muốn. Bạn không thể lấy bất kì ai sẵn có rồi bảo họ “cứ làm điều đó đi” mà phải chọn người cẩn thận bởi vì họ sẽ đóng vai trò mô hình cho toàn bộ tổ chức.

Hỏi: Những điều mà tổ chức thành công đã làm để cải tiến qui trình và đạt tới mức độ trưởng thành cao hơn là gì?

Đáp: Dựa trên bài học rút ra, mọi tổ chức thành công đều có chung những điều sau:

1)     Cam kết của cấp quản lí hỗ trợ cho việc đang diễn ra, tài trợ và tạo kết cấu nền (như Ban chỉ đạo, SEPG, và Nhóm công tác qui trình)

2)     Những người quản lí dự án đồng ý cam kết để mọi người làm việc theo các hoạt động cải tiến. Điều này là rất quan trọng, không cải tiến qui trình nào có thể thành công mà không có hỗ trợ từ quản lí dự án dự ứng và mạnh mẽ

3)     Phần lớn mọi người làm việc về cải tiến qui trình đều được lấy từ các dự án trong toàn tổ chức.

4)     Nhóm SEPG nhỏ tồn tại để tạo điều kiện thuận lợi cho việc chia sẻ thông tin và tư vấn về hoạt động cải tiến.

5)     Hội tụ vào hành động thực, không chỉ vào chính sách và thủ tục mà xác định các qui trình, thử nghiệm thực tế, và làm mịn chúng trước khi huấn luyện cho mọi người dùng chúng một cách có hiệu quả.

6)     Nhiều phiên “nâng cao nhận biết” được tiến hành để giúp tập trung vào qui trình then chốt.

7)     Thiết lập dự án và cách đo qui trình và lập tuyến cơ sở để đo.

8)     Có cơ chế theo dõi tại chỗ và theo dõi các hoạt động hàng tháng.

9)     Cấp quản lí liên tục trao đổi về tầm quan trọng của cải tiến qui trình lặp đo lặp lại.

10)   Họ tất cả đều vui đùa khi làm điều đó

Hỏi: Tổ chức của tôi bắt đầu cải tiến qui trình phần mềm vài năm trước đây và chúng tôi đang tạo ra tiến bộ. Tuy nhiên, do thay đổi nghiệp vụ chúng tôi không chắc làm sao duy trì được sáng kiến này. Thầy có gợi ý nào không?

Đáp: Bao giờ cũng có thăng giáng trong vòng nghiệp vụ nhưng bạn có thể duy trì chương trình cải tiến của mình bằng cách:

1) Giữ cho mọi hoạt động cải tiến đều thấy được:

Bạn nên giữ các hoạt động cải tiến qui trình là thấy được cho mọi cấp quản lí để cho họ không thể bỏ qua được nó. Bạn cần gióng thẳng các mục đích của cải tiến qui trình với mục đích nghiệp vụ và trao đổi về nhu cầu cải tiến nghiệp vụ trong toàn tổ chức.

2) Làm cho mọi người đều tham dự:

Không việc cải tiến qui trình  nào có thể thành công trong chân không. Mọi người trong tổ chức phải tham gia vào thực hiện một số nhiệm vụ cải tiến. Bạn cần theo dõi dấu vết của những hoạt động này và thông báo cho mọi cấp quản lí về điều đang diễn ra.

3) Đo kết quả cải tiến:

Mọi chương trình cải tiến qui trình đều phải có mục đích đo được rõ ràng có liên quan tới nghiệp vụ. Mọi kết quả cải tiến qui trình đều phải được thu thập, phân tích và theo dõi dấu vết về tới các mục đích nghiệp vụ, và phải được trao đổi trong toàn tổ chức. Nếu xu hướng này là có triển vọng, đó là hoạt động cải tiến của bạn quả đạt tới các mục tiêu của nó, không ai muốn làm xáo trộn thành công.

Hỏi: Tôi nghĩ tiến hành nhiều kiểm điểm hơn là tốt nhưng không hiện thực. Chúng tôi cần phần mềm có thể được tạo ra nhanh nhất.  Tại sao kiểm điểm và để trễ việc đưa ra? Sao chúng ta không có “phần mềm đủ tốt” thôi?

Đáp: Câu hỏi của tôi là “Thế nào là đủ tốt?” Tôi không biện hộ cho việc tiến hành nhiều kiểm điểm chỉ vì mục đích kiểm điểm nhưng trong thế giới thay đổi nhanh chóng và cạnh tranh cao này, thành công của doanh nghiệp bao giờ cũng phụ thuộc vào chất lượng của sản phẩm chúng ta sản xuất ra cho khách hàng và chúng ta không thể chấp nhận được việc có cái gì có thể gây nguy hiểm cho tương lai của chúng ta ở đây.

Hỏi: Nhà cung cấp của tôi được xác nhận ISO 9001 và tôi muốn tổ chức phần mềm của tôi tiến theo cùng hướng để cho chúng tôi có thể so sánh lưu ý và chia sẻ bài học rút ra. Thầy nghĩ gì về ISO 9001?

Đáp: Theo ý kiến tôi, IS0 9001 là chỗ bắt đầu tốt cho cải tiến chất lượng nhưng vì nó mông lung thế, tôi nghĩ tổ chức của bạn có lẽ sẽ có nhiều câu hỏi hơn là có câu trả lời. Tôi nghĩ nhiều về điều này khi tôi học trở thành  người kiểm định ISO 9001 năm 1991. ISO 9001 “chung chung” tới mức gần như bất kì tổ chức phần mềm nào cũng có thể có đủ tư cách cho nó. Tôi biết nhiều công ti đã nhận chứng chỉ ISO 9001 khi họ chắc chắn vẫn là công ti “CMMI mức 1” khi được thẩm định theo CMMI. Trong những năm qua, tôi đã thẩm định 3 tổ chức ở mức 1 nhưng tất cả đều có xác nhận ISO 9001. Những người ở đó bảo tôi “Dễ lừa kiểm định viên ISO lắm.” Bình luận này làm tôi bận tâm nhiều bởi vì thời gian và tiền bạc bị phí hoài vào “chơi” xác nhận ISO 9001.

Vừa là cả kiểm định viên ISO 9001 và người lãnh đạo thẩm định CMMI, tôi mạnh mẽ tin ISO 9001 là mô hình rất tốt để bắt đầu cuộc hành trình cải tiến chất lượng. Điều không may là nhiều tổ chức cảm nhận việc có chứng chỉ ISO 9001 như chỗ kết thúc thay vì chỗ bắt đầu.

Hỏi: Liệu có khả năng cho một tổ chức đưa vào hoạt động cải tiến mà không có hỗ trợ của cấp quản lí không?

Đáp: Phần lớn việc cải tiến đều yêu cầu sự hỗ trợ của cấp quản lí nhưng nếu bạn muốn cải tiến qui trình riêng của mình, bạn có thể bắt đầu với việc giám định chính thức tại cuối các pha vòng đời (Yêu cầu, Thiết kế, Viết mã, và Kiểm thử) hay tiến hành nhiều kiểm thử hơn để cải tiến chất lượng phần mềm.

Hỏi: Làm sao SEPG giúp được cho tổ chức đạt tới mức trưởng thành cao hơn nếu họ chưa bao giờ làm việc trong một tổ chức mức cao hơn trước đây? Cái gì là đặc trưng của mức 4 và 5?

Đáp: Theo hiểu biết của tôi, rất ít thành viên SEPG có đủ may mắn để làm việc ở các tổ chức trưởng thành mức cao hơn. Chỉ có vài tổ chức ở mức 4 và 5. Đó là lí do tại sao tôi cổ vũ SEPG lấy ưu thế của việc huấn luyện nhiều hơn, chia sẻ nhiều hơn các kinh nghiệm.

Tôi đã tiến hành mười bốn thẩm định ở các tổ chức mức 4 và 5 và tôi phải nói rằng bên cạnh việc thoả mãn tất cả các mục đích miền qui trình của mức 4 và 5, các tổ chức này còn vượt ra ngoài thực hành trong CMMI.  Không thành vấn đề điều bạn có thể hình dung ra trước, một tổ chức như vậy sẽ có nhiều điều làm bạn ngạc nhiên — những canh tân mà họ đã nghĩ tới và thực hiện mà tác giả của CMMI cũng không thể nhìn thấy trước được. (Điều này có lẽ là vì đã không có các tổ chức mức 4 hay 5 tồn tại khi CMM được tạo ra)  Chẳng hạn: Không có chỗ nào mà CMMI khuyến cáo rằng quyết định đưa ra sản phẩm phần mềm nên là kết quả của nhóm SQA (không phải của người phát triển) hay chức năng tính toán theo thuật toán lớn phải dựa trên việc đo: nếu ít hơn một ngưỡng nào đó, thì cho ra; ngược lại, làm lại.  Nhưng tất nhiên, một số tổ chức mức 4 sẽ làm điều đó.  Và khi bạn thấy một qui trình như vậy, có sự thừa nhận lập tức về phần người lãnh đạo thẩm định cho dù bạn còn chưa thấy điều này trước đó.  Và phản ứng của bạn là — “Ồ vâng, điều đó có nghĩa đấy.  Sao mình không nghĩ về điều đó trước đây?  Nó hiển nhiên thế khi mình thấy nó!”

Hỏi: Thầy đạt tới việc thoả mãn khách hàng thế nào bên cạnh việc chuyển giao sản phẩm đúng thời gian?

Đáp: Bạn cần tự hỏi mình những câu hỏi này:

Khách hàng của chúng ta là ai?

Chúng ta có hiểu trông đợi của họ không?

Chúng ta có hiểu cách họ đo những trông đợi này không, và chúng ta có hiểu cách chúng ta đang làm ngược với những cách đo đó không?

Chúng ta có hiểu cái gì là quan trọng đối với khách hàng theo quan điểm cải tiến?

Chúng ta có kế hoạch đưa những cải tiến đó vào thực tế không?

Hỏi: Kiến trúc sư hệ thống làm việc thế nào? Chúng ta cần loại vấn đề gì khi tích hợp hệ thống?

Đáp: Cũng như nhà thầu yêu cầu bản kế hoạch tổng thể trước khi bắt đầu xây dựng, kiến trúc sư hệ thống cần bản kế hoạch chi tiết khi thiết kế hệ thống máy tính. Khi nhiều hệ thống và ứng dụng phải cùng tồn tại bên trong cùng một công ti, việc lập kế hoạch thậm chí còn trở nên mấu chốt hơn. Số lớn các công nghệ khác nhau và các chuẩn cạnh tranh có thể dẫn tới chi phí bảo trì cực kì cao và thất vọng vô tận với các yêu cầu tích hợp. Khi tích hợp công nghệ mới hay nâng cao hệ thống hiện có, kiến trúc sư hệ thống phải đảm bảo rằng chúng nhất quán với kiến trúc kĩ thuật tổng thể phục vụ cho nghiệp vụ.  Các khía cạnh then chốt của kiến trúc công nghệ tại từng mức là: tính đổi qui mô được, tính an ninh, tính khả chuyển, tính dùng lại, tính bảo trì được và tính thích nghi được theo các qui tắc nghiệp vụ mới.

English version 

CMMI-21

Question: Why separate software and hardware? Why focus on software management, as hardware engineer, I think that I can manage software too.

Answer: There are differences between hardware and software:

a)     You can touch hardware but can not touch software.

b)     You can look at hardware but can not look at software.

c)      You can watch the hardware system being built and knowing that about half or 50% of the hardware system is in place, but you do not know about this with software.

d)     You can solve hardware problem by installing high performance CPU, add more memory, increase bandwidth, or change motherboard so the hardware system can run faster or perform better. This never happen in software.

e)     To build hardware faster you can put more people and increase production volume but this is not true in software. Sometime more people create more problems with software.

f)        A hardware development process can be defined precisely, you know what to do first and what to do last and you can measure the time it takes for each step in the process precisely. But you can not do that with software because people do things differently not precisely.

When a software organization is managed by managers who succeeded in hardware business, serious trouble will take place. Both sides have to struggle in persuading each others because different mindset. Software products are unique so that generic methods and tools do not work well. There is no “one size fits all” in software. You must look at domain specific methods and tools because priority is different between domains. For example, the critical process of commercial software is fixing data flow but scientific software is focusing on select the right algorithm. With commercial of the shelf software (COTS) the important is the designing of good interface but embedded system is pushing instructions into least memory chips. People who design software for the telecommunication satellite do not do it the same way they would when design a website e-commerce.

Question: Why do we need a Steering committee, a SEPG, and a Working group for process improvement? Are you advocating more bureaucracy?

Answer: After many years of managing software process improvement, I found that infrastructure is the most critical to the success or failure of improvement. Based on my own experiences, I strongly urge the organization to set up a three-tier structure as follows:

1)     A Steering committee consists of senior executives and key managers of the organization. Their role is to set direction for improvement, prioritizes and authorizes improvement activities, allocates resources and promotes improvement activities.

2)     The SEPG consists of skilled and experienced people from the organization to coordinate and facilitate improvement activities and keep the steering committee informed.

3)     The Working groups consist of technical people formed to deploy improvement activities, to solve problems identified in the action plan and to make improvement happen.

Process improvement is about change and change is mostly behavior. If people do not change their behavior, then there is no improvement. The Steering committee sets goals and expectations for behavior change and expects to see it happen. The SEPG advocates behavior change, and manages the change activities. In order to succeed, they must have the right skills to manage improvement activities or encourage behavior changes. Many people maybe trained by taking classes but may not develop the skills if they do not apply what they learned into practice. If the organization can identify the mistakes or failure, then they can develop and maintain the skills needed to keep failure from happening again. I really believe the SEPG helps the organization become skilled without losing face.  The working group must be carefully selected for improvement activities since they deal with behavior change and set an example for the desired behavior. You can not take anybody that are available and tell them “just do it” but choose the people carefully because they will serve as the role model for the entire organization.

Question: What are things that successful organizations did to improve the process and achieved higher levels of maturity?

Answer: Based on lessons learned, all successful organizations share the following common things:

1)     Management commitment back up with on-going support, funding and infrastructure. (i.e. Steering committee, SEPG, and Process Working Group)

2)     Project managers agree to commit people to work on improvement activities. This is very important, no process improvement can be successful without strong and proactive project management support

3)     Most people working on process improvement come from projects across the organization.

4)     A small SEPG group exists to facilitate the sharing of information and consult on improvement activities.

5)     Focusing on real actions, not just policies and procedures but define the actual processes, pilots and refine them before train people to use them effectively.

6)     A lot of “awareness” sessions are held to focus on key process.

7)     Establish project and process measurements and a baseline to measure against.

8)     Having a tracking mechanism in place and track activities monthly.

9)     Management continues to communicate the importance of process improvement over and over again.

10) They all have fun doing it

Question: My organization started software process improvement several years ago and we are making progress. However, due to business changes we are not sure how to sustain this initiative. Do you have any suggestion?

Answer: There are always up and down in business cycle but you can sustain your process improvement program by:

1) Keep all improvement activities visible:

You should keep process improvement activities visible to all levels of management so they can not ignore it. You need to align the goals of process improvement to the business goals and communicate the need to improve the business throughout the organization.

2) Make everyone involve:

No process improvement can succeed in a vacuum. Everybody in the organization must involve in implementing some improvement tasks. You need to keep track of these activities and inform all levels of management of what is going on.

3) Measure the improvement results:

Every process improvement program must have clear measurable goals that relate to the business. All process improvement results must be collected, analyzed and tracked against business goals, and communicated across the organization. If the trend is favorable, that is your improvement activities do achieve its objectives, no one will like to tamper with success.

Question: I think conducting more reviews is good but not realistic. We need software as fast as we can produce them.  Why reviews and delay the release? Why don’t we have “just good enough software”?

Answer: My question is “How good is enough?” I do not advocate conducting more reviews for review sake but in the fast changing and highly competitive world, the success of business always depends on the quality of the product that we produce to the customer and we can not afford to have anything that may jeopardize our future here.

Question: My supplier is ISO 9001 certified and I want my software organization to move in the same direction so that we can compare note and share lessons learned. What do you think of ISO 9001?

Answer: In my opinion, IS0 9001 is a good start for quality improvement but since it is so vague, I think your organization probably will have more questions than getting answers. I thought a lot about this when I was in training to become ISO 9001 auditor in 1991. The ISO 9001 is so “generic” that almost any software organization could qualify for it. I knew many companies have received ISO 9001 certified when they were without a doubt still a “CMMI level 1” when assessed against the CMMI. In the past years, I have assessed 3 organizations at level 1 but all got ISO 9001 certifications. The people there told me “It is easy to cheat the ISO auditors”. This comment bothers me a lot because the time and money wasted on “gaming” the ISO 9001 certification.

As both ISO 9001 auditor and CMMI Lead Assessor, I strongly believe ISO 9001 is a very good model to start on the quality improvement journey. The unfortunate is many organizations perceive ISO 9001 certification as the end rather the beginning.

Question: Is it possible for an organization to put in place an improvement activity without management support?

Answer: Most process improvement does require management support but if you want to improve your own process, you can start with formal inspections at the end of each life-cycle phases (Requirements, Design, Code, and Test.) or conducting more tests to improve software quality.

Question: How can SEPG help organizations reach higher levels of maturity if they never work in a higher level organization before? What are the characteristics of a level 4 and 5?

Answer: From my knowledge, very few SEPG members are lucky enough to work at higher maturity organizations. There are only few level 4 and 5 organizations. That is why I encourage SEPG to take advantage of more training, more sharing of experiences.

I have conducted fourteen assessments in level 4 and 5 organizations and I have to say that besides satisfy all the Process Area goals of the level 4 and 5, these organizations go beyond the practices in the CMMI.  No matter what you may envision beforehand, such an organization will have lots of surprises for you — innovations that they have thought of and implemented which the authors of the CMMI could not foresee. (This is probably because there were no level 4 or 5 organizations exist when the CMM was created)  For example: Nowhere does the CMMI recommend that the decision to release a software product should be the result of the SQA group (not the developers) or computing a heavy algorithm-driven function based on measurements: if less than the threshold, release; else, rework.  But of course, some Level 4 organization will do just that.  And when you see such a process, there is instant recognition on the part of the Lead Assessor even if you haven’t seen this before.  And your reaction is — “Oh yeah, that makes sense.  Why didn’t I think of that before?  It’s so obvious once I see it!”

Question: How do you achieve customer satisfaction beside deliver a product on time?

Answer: You need to ask yourself these questions:

Who are our customers?

Do we understand their expectations?

Do we understand how they measure those expectations, and do we understand how we are doing against those measurements?

Do we understand what is important to our customer from an improvement standpoint?

Do we have a plan to put those improvements in place?

Question: How does System Architect work? What kind of issues do we need to consider when integrate systems?

Answer: Just as contractors require blueprints before beginning construction, system architects need detailed plans when designing computer systems. When multiple systems and applications must coexist within the same company, planning becomes even more critical. A mass of different technologies and competing standards can lead to extremely high maintenance costs and endless frustration with integration requirements. When integrate new technologies or enhance existing systems, System Architect must ensure that they are consistent with the overall technical architecture for the business.  The key aspects of technology architecture at each level are: Scalability, Security, Portability, Reuse, Maintainability and Adaptability to new business rules.