Đáp: Để cải tiến kĩ năng của mình bạn phải biết bản thân mình trước hết. Cho nên đây là một số bước bạn có thể làm:

1) Lập viễn kiến về cải tiến cá nhân: Bạn phải tự hỏi mình tại sao bạn muốn cải tiến kĩ năng của mình rồi xác định nỗ lực bạn phải làm để đạt tới nó. Bạn phải hiểu rõ ràng nhu cầu cải tiến và khả năng cải tiến bằng việc đánh giá quan hệ nghề nghiệp giữa bạn và các thành viên tổ của bạn, người dùng của bạn và khách hàng của bạn. Từ đánh giá này, bạn có thể phát triển những trông đợi nào đó về kĩ năng của mình và bắt đầu tạo ra viễn kiến cho việc cải tiến.

2) Tạo khả năng cải tiến cá nhân: Để làm viễn kiến thành thực tại, bạn cần lập cho mình những mục đích cải tiến nào đó và các mục tiêu hiệu năng. Bạn có thể cần huấn luyện các kĩ năng là quan trọng cho mục đích của mình như học về công nghệ mới, qui trình mới, dữ liệu đo, công cụ phần mềm, và qui trình về cách học những điều mới. Bạn có thể yêu cầu hỗ trợ của người khác như bạn bè, người quản lí. Bạn không tìm kiếm sự chấp thuận của họ mà chỉ là động viên của họ và sự giúp đỡ của họ trong việc loại bỏ rào chắn nỗ lực cá nhân của bạn.

3) Tập trung vào cải tiến: Xây dựng kế hoạch hướng dẫn nỗ lực của bạn và đánh giá tiến bộ của bạn. Chẳng hạn, nếu bạn đặt cho mình mục đích học C++ bằng việc theo ba lớp đào tạo tại đại học, bạn phải có kế hoạch chi tiết về cách học ba lớp này cũng như thời gian bạn dự định hoàn thành. Mỗi lúc hoàn thành một lớp, bạn đạt tới một cột mốc và khi bạn hoàn thành cả ba lớp, bạn hoàn thành kế hoạch đào tạo. Bạn cũng cần cách đo chất lượng để giúp bạn đánh giá nỗ lực của mình kiểu như bạn đã học được bao nhiêu dựa trên điểm của bạn tốt tới mức nào. Bạn có qua được lớp với điểm tốt hay chỉ trần sì qua được nó? Kĩ năng của bạn thế nào trước và sau khi theo lớp? Bạn học được bao nhiêu bằng việc theo các lớp này và bạn đã để bao nhiêu nỗ lực vào các lớp này? Đây nên là biểu thị rõ ràng cam kết của bạn với cải tiến kĩ năng.

4) Cải tiến nghề nghiệp của bạn: Một khi bạn có kĩ năng thì bạn cần bản kế hoạch để cải tiến nghề nghiệp của mình bằng cách xác định tập các hoạt động về cách làm việc với các thành viên tổ khác. Bạn có thể muốn đặt mục đích hiệu năng của mình với người dùng, khách hàng và thành viên tổ.  Việc của bạn chỉ là thu thập các qui trình bạn theo để bạn viết chúng ra, đánh giá chúng và hiểu cách những qui trình này tương hỗ và có quan hệ với các qui trình khác, chẳng hạn như các thành viên tổ, người dùng và khách hàng. Một khi bạn có mọi thứ tại chỗ thì bạn có thể tự hỏi mình “Mình có thể làm gì để làm cho những qui trình này tốt hơn?” Bằng việc loại bỏ độ phức tạp khỏi các qui trình này và cải tiến chúng, nên chúng trở nên hiệu quả hơn trong việc của bạn cũng như theo cách bạn làm việc. Bạn cần chứng tỏ cam kết của mình với mục đích cá nhân, không bị ngã lòng khi bạn không làm nhiệm vụ nào đó, nhớ rằng bạn là con người và phạm sai lầm là điều thông thường, không phải là cái gì đó bạn phải cảm thấy xấu về nó. Có dũng cảm mà đi tiếp.

5) Giúp người khác cải tiến: Một nhân tố then chốt trong cải tiến cá nhân là giúp người khác cải tiến bản thân họ. Qua nỗ lực cải tiến cá nhân, tổ chức như một toàn thể có thể cải tiến thêm. Bằng việc đào tạo và hỗ trợ người khác bạn tạo ra các thành viên tổ có kĩ năng hơn cho công ti bạn. Bằng việc tạo ra công việc tổ và xoá bỏ rào chắn bạn đang làm tiến bộ trong cuộc truy tìm cá nhân tới điều tốt nhất. Bằng việc động viên các hoạt động cải tiến của người khác bạn chứng tỏ quyền lãnh đạo của mình và nhiệt tình của bạn sẽ lan rộng trong toàn tổ chức như lửa dại. Đến lúc đó mọi người sẽ bắt đầu thừa nhận bạn và tôi chắc chắn bạn sẽ được đền bù tương ứng.

6) Đánh giá tiến bộ của bạn: Xin đừng quá tự tin. Bạn cần kiểm điểm tiến bộ của mình theo mục đích cá nhân của mình. Là người giỏi nhất không phải là đích tới mà là cuộc hành trình nên bạn sẽ biết rằng giá trị của cải tiến thực sự là ở nỗ lực cải tiến bên ngoài kết quả. Khi thừa nhận điều này, đó là lúc quay lại chỗ bắt đầu.

7) Quay lại bước 1: Bắt đầu việc cải tiến của bạn lần nữa bằng việc tuân theo qui trình cải tiến cá nhân.

Hỏi: Tại sao thầy lại làm lớn điều về chất lượng thế? Nếu phần mềm bị hỏng thì mình chữa nó lại thôi. Điều đó chẳng có nghĩa là giữ việc của mình sao?

Đáp: Tôi có thể hiểu rằng bạn hoài nghi về cải tiến phần mềm nhưng tôi đảm bảo rằng bạn du hành trong máy bay và hiểu rằng chất lượng của phần mềm trên máy bay và phần mềm quản lí thiết bị kiểm soát không lưu là rất quan trọng. Tương tự, bạn có lẽ muốn tài khoản ngân hàng của mình, thẻ tín dụng của mình, hoá đơn điện thoại di động của mình, hệ thống điện xe ô tô của bạn không có lỗi, đúng không?

Hỏi: Tại sao thầy cần thiết lập Nhóm qui trình kĩ nghệ phần mềm Software Engineering Process Group (SEPG) cho việc cải tiến qui trình?

Đáp:

Để cải tiến qui trình bạn phải có ai đó làm việc trên nó. Liệu có thể để người phát triển đã rất bận rộn làm việc với cải tiến nữa không? Tôi ngạc nhiên là một số người quản lí nghĩ vậy, họ tin rằng người phát triển phần mềm của họ, người đã rất bận rộn với công việc dự án có thể dành thời gian và nỗ lực phụ cho cải tiến qui trình.  Từ kinh nghiệm riêng của tôi, trong trường hợp này, chẳng cái gì sẽ thay đổi. Những người phát triển phần mềm đã học qua nhiều năm làm việc vất vả về cách bao quát đa nhiệm vụ, thay đổi yêu cầu, nhu cầu của khách hàng, khiếm khuyết phần mềm và vấn đề máy tính, khi họ làm việc theo lịch biểu rất chặt chẽ với sức ép lớn. Họ phải được thuyết phục rằng cải tiến sẽ làm cho công việc của họ tốt hơn nếu không họ sẽ tiếp tục cách thông thường của họ. Thay đổi là gian nan và yêu cầu nhiều công việc mà không thể được thực hiện bởi những người đã rất bận rộn. SEPG là một nhóm đặc biệt chuyên trách cho việc cải tiến cách tổ chức làm việc.

Hỏi: Cách đo và độ đo là gì mà chúng ta có thể dùng cho dự án của mình? Làm sao chúng ta có thể đo được qui trình phần mềm?

Đáp: Đây là một số cách đo và độ đo điển hình:

1)     Đo kích cỡ: Số dòng mã (SLOC),  Số điểm chức năng, Số đối tượng trong dự án;

2)     Đo năng suất: Số thời gian dành cho dự án, số thời gian dành cho từng nhiệm vụ, số thời gian dành để sửa yêu cầu thay đổi;

3)     Đo khiếm khuyết: Độ nghiêm trọng về từng khiếm khuyết (Cao, Trung bình, Thấp);

4)     Đo chất lượng: Tổng số khiếm khuyết, số khiếm khuyết trong từng trình con hay mô đun hay đối tượng, khiếm khuyết trung bình trên nghìn dòng mã, Thời gian trung bình giữa các hỏng hóc.

Hỏi: Tại sao chúng ta cần kiến trúc phần mềm? Tại sao chúng ta không chỉ thiết kế và viết mã?

Đáp: Theo định nghĩa, “kiến trúc phần mềm” là qui trình tạo ra kiến trúc cho sản phẩm phần mềm. Vì phần mềm không tự nó chạy được mà phải chạy bên trong hệ thống máy tính cho nên mối quan hệ và giao diện giữa phần mềm và phần cứng phải được xem xét tới. Phần lớn phần mềm đều có vài cấu phần có quan hệ tương hỗ với nhau, người kĩ sư phần mềm cần quyết định về cấu trúc của những cấu phần này và cách chúng tương tác và thực hiện.

Để làm điều đó người kĩ sư phần mềm phải quen thuộc với phong cách kiến trúc cũng như công nghệ. Kiến trúc là quan niệm mức cao về cách sản phẩm phần mềm làm việc. Kiến trúc phải hội tụ vào hệ thống toàn bộ trong khi thiết kế là việc thực hiện thực tế của kiến trúc và thường ở mức thấp hơn, chi tiết hơn, và thường hội tụ vào một số cấu phần của hệ thống.

Kiến trúc bao gồm nhiều pha:

1)     Khêu gợi yêu cầu kiến trúc: Kiểm điểm các yêu cầu của khách hàng và thảo luận với khách hàng về hệ thống.

2)     Thiết kế kiến trúc: Kiểm điểm yêu cầu mục đích, mục tiêu và chức năng dự án để chắc chắn kiến trúc có thể hoàn thành các yêu cầu này. Tiến hành phân tích bù trừ để thẩm định rủi ro và chi phí;

3)     Làm tài liệu kiến trúc:  Làm tài liệu các quan niệm, tạo ra bản mẫu, ra quyết định về yêu cầu, phong cách, góc nhìn, giao diện và thuộc tính chất lượng (hiệu năng, tính đổi qui mô, tính an ninh, tính dùng đượcv.v.);

4)     Phân tích kiến trúc: Kiểm điểm với khách hàng để làm sáng tỏ các yêu cầu thiết kế, chứng minh qua biểu diễn hay bản mẫu rằng hệ thống sẽ đáp ứng yêu cầu;

5)     Thực hiện kiến trúc: Tiến hành phân tích thấu đáo để ra quyết định về phần mềm, hệ điều hành, ngôn ngữ máy tính, công cụ, phương pháp, cấu trúc và nhiệm vụ cho từng cấu phần, bắt đầu phân rã chức năng để tạo ra thiết kế mức cao.

6)     Duy trì kiến trúc: Tạo ra tài liệu để chắc chắn thay đổi thiết kế tương lai sẽ không thay đổi kiến trúc hệ thống;

Hỏi: Tại sao người quản lí phần mềm bao giờ cũng tìm “Phép màu” như CMMI? Tại sao họ không hiểu rằng phát triển phần mềm là công việc gian nan không có lối tắt?

Đáp:

Người quản lí phần mềm, giống như người quản lí các bộ môn khác, thường bị dưới sức ép phải duy trì ngân sách, giữ lịch biểu khỏi trượt, và cải tiến chất lượng sản phẩm. Giống như người chết đuối vớ lấy bất kì cái gì gần đó để nổi được, nhiều người quản lí phần mềm thường túm lấy niềm tin nào đó nếu nó có thể làm nhẹ bớt sức ép, cho dù là tạm thời. Chúng ta biết rằng một số công nghệ tới với nhiều hứa hẹn nhưng không thể chuyển giao được và thế rồi trở thành bị bỏ xó thành “trạng thái mốt nhất thời.” Theo ý kiến riêng của tôi nhiều Công cụ, Phương pháp hay thậm chí khuôn khổ CMMI có tác dụng tốt, với giả định rằng có qui trình được xác định để tích hợp chúng đúng đắn và mọi người được huấn luyện dùng chúng tương ứng. Lí do phần lớn các công nghệ mới dường như không có tác dụng là bởi vì tổ chức còn chưa đủ trưởng thành để đón nhận chúng hay thiếu kỉ luật để tuân theo chúng tương ứng.

Hỏi: Chúng tôi có việc đánh giá CMMI vài tháng trước đây và được bảo rằng các qui trình của chúng tôi không được làm tài liệu. Chúng tôi đã có nhiều chuẩn và thủ tục thế để xây dựng phần mềm. Tại sao chúng tôi phải làm tài liệu qui trình và tạo ra thậm chí còn nhiều tài liệu hơn?

Đáp: Tổ chức của bạn có thể có nhiều chuẩn và thủ tục nhưng chúng có được dùng không? Người của bạn có nhận biết về sự tồn tại của chúng không? Chúng có phản ánh thực hành hiện thời của bạn không? Chúng có đầy đủ không? Chúng tốt thế nào? Bạn có đo việc dùng chúng không? SQA có thẩm tra rằng mọi người tuân theo chúng một cách đúng đắn không? Bạn hay quản lí cấp cao của bạn có kiểm điểm chúng không? Có ai duy trì và cập nhật chúng khi cần không? Người của bạn có nhận được đào tạo dùng chúng không? Nếu câu trả lời cho bất kì câu hỏi nào trong những câu hỏi này là KHÔNG thì bạn có thể cần xem xét lại tài liệu của bạn để đảm bảo nó phản ánh điều đang diễn ra trong tổ chức của bạn.

Hỏi: Khi bộ phận chế tạo của chúng tôi bị tụt lại sau lịch, chúng tôi thêm nhiều người cho dự án hay thêm luân chuyển thứ ba. Tại sao chúng tôi không thể thêm người vào dự án phần mềm khi chúng tôi bị tụt lại sau lịch?

Đáp: Tôi  không chắc rằng thêm người cho dự án của bạn có thể giúp kịp lịch biểu. Nếu nó thế, thì qui trình đó phải rất máy móc vì nhiều người giúp giải quyết nó. Bạn cần biết rằng phát triển phần mềm không phải là qui trình máy móc; do đó, thêm người sẽ không ích gì. Tôi tin rằng đôi khi thêm người muộn vào một dự án phần mềm sẽ làm cho nó còn chậm hơn nhiều.

Hỏi: Vì tôi bảo vệ cho cải tiến qui trình, tôi đã nhận được nhiều bình luận từ mọi người trong công ti của tôi. Thầy nghĩ gì về những bình luận này?

Đáp: Có vẻ như bạn đang đối diện với sự chống cự lớn với thay đổi. Đây là một số trong những diễn giải của tôi về các bình luận của bạn:

1.      “Tôi không thể cải tiến được chừng nào anh chưa cho tôi thêm chi tiết.”- Có thể nghĩa là bao nhiêu chi tiết bạn đưa ra cũng không thành vấn đề, nó sẽ không bao giờ đủ và họ sẽ yêu cầu thêm nữa cho nên họ không phải làm gì cả.

2.      “Tôi bận làm việc thực ở đây.”- Có thể có nghĩa là họ không coi việc của bạn có giá trị hay họ cảm nhận việc cải tiến  là không quan trọng khi so với điều họ đang làm và họ từ chối làm nó.

3.      “Tôi vẫn không chắc điều anh đang cố gắng làm.” – Có thể nghĩa là họ sẽ tiếp tục tuyên bố bị lẫn lộn, ngay cả khi bạn giải thích mọi thứ nhiều lần. Vì họ không hiểu, họ không phải cải tiến.

4.      “Giải pháp của anh đâu? Chỉ cho tôi giải pháp.”- Có thể nghĩa là họ muốn nhảy ngay vào giải pháp, không dành thời gian cần thiết để nhận diện rõ ràng và phân tích vấn đề.

5.      “Tôi rất bận và không có thời gian cho bất kì chất liệu cải tiến nào.”- Có thể nghĩa là thời gian hết, hay họ sẽ không làm nó dù bất kì cái gì.

6.      “Tôi cần có kế hoạch trước hết trước khi tôi có thể làm nó” – có thể nghĩa là họ muốn lập kế hoach nhưng không muốn thực hiện. Lập kế hoạch không sai, thực hiện có thể sai cho nên họ làm nó theo cách an toàn nhưng không làm gì cả.

Kết luận của tôi: Dường như là tổ chức của bạn KHÔNG muốn cải tiến chút nào.

Hỏi: Định nghĩa về dự án lớn, nhỏ, vừa là gì?

Đáp: Có nhiều cách khác nhau để định nghĩa dự án điển hình nhưng sau đây là ý kiến cá nhân của tôi:

Tổ dự án nhỏ bao gồm 1 tới 10 người – làm việc điển hình trên xấp xỉ 10,000 – 50,000 dòng mã.

Tổ dự án cỡ trung bình bao gồm 10 tới 50 người – làm việc điển hình trên xấp xỉ 50,000 tới 100,000 dòng mã.

Tổ dự án lớn bao gồm từ 50 tới 500 người – làm việc điển hình trên xấp xỉ 100,000 tới 1,000, 000 dòng mã.

Tổ dự án rất lớn bao gồm từ 500 tới 2000 người – làm việc điển hình trên xấp xỉ 1,000,000 tới 10,000,000 dòng mã.

Nếu dự án bao gồm hơn 100 người, nó có thể cần được chia ra thành nhiều dự án với mục đích quản lí. Dễ quản lí vài dự án nhỏ hơn là quản lí toàn thể vấn đề.

Hỏi: SPICE là gì? Ai dùng nó? Chúng ta có nên dùng nó không?

Đáp: Tổ chức tiêu chuẩn quốc tế – The International Organization for Standardization (ISO) đang phát triển một chuỗi các chuẩn về thẩm định qui trình phần mềm có tên là “Software Process Improvement and Capability dEtermination” hay SPICE. Nó là một nỗ lực độc lập của ISO nhưng nó được hứng khởi bởi CMM và ISO 9001. Tuy nhiên, SPICE nhằm vào việc hài hoà số các mô hình khác nhau bao gồm ISO 9001, ISO 1207, STD, Bootstrap, v.v. Do đó, nó sẽ là duy nhất và không đồng nhất với cái nào. Tại lúc này, công ti ở Mĩ không cam kết dùng nó. Ý kiến về SPICE ở Mĩ còn hỗn hợp và tôi không thấy lí do nào để dùng mô hình khác mà không thấy dữ liệu nào.

English version

CMMI-16

Question: How could a programmer improve the skill to be the best? Do you have any advice?

Answer: In order to improve your skill you must know yourself first. So here are some steps that you can do:

1) Set vision for personal improvement: You must ask yourself why you want to improve your skill then determines the effort that you must do to achieve it. You must clearly understand the need to improve and the ability to improve by evaluate the professional relationship between you and your team members, your users and your customers. From this evaluation, you can develop certain expectations for your skill and begin to create a vision for the improvement.

2) Enable personal improvement: To make the vision a reality, you need to set yourself some improvement goals and performance objectives. You may need training in the skills that are important to your goals such as learning about new technology, new process, measurement data, software tools, and the process of how to learn new things. You may ask for the support of other people such as your friends, your managers. You are not seeking their approvals but only for their encouragements and their help in removing barriers to your personal efforts.

3) Focus on improvement: Develop a plan to guide your efforts and evaluate your progress. For example if you set yourself a goal to learn C++ by taking three training classes at the university. You must have a plan detail how to take these three classes as well as the time that you expect to complete. Each time complete a class, you reach a milestone and when you complete all three classes, you complete the training plan. You also need quality measurements to help you evaluate your effort such as how much you learned based on how good your grades are. Are you passing the class with good grade or just barely pass it? How is your skill before and after taking the class? How much do you learn by taking these classes and how much efforts have you put in these classes? These should be a clear demonstration of your commitment to the skill improvement.

4) Improving your career: Once you have the skill then you need a plan to improve your career by defining a set of activities on how to work with other team members. You may want to set your performance goal with users, customers, and team members.  Your job is only a collection of processes that you follow so you will need to write them down, evaluate them and understand how these processes interrelate and relate to others such as your  team members, users and customers. Once you have everything in place then you can ask yourself “What can I do to make these processes better?” By removing complexity from these processes and improve them so become more effective in your job as well as in the way you work. You need to demonstrate your commitment to your personal goal, do not get discourage when you fail certain task, remember that you are a human being and making mistake is common thing, not something that you have to feel bad about it. Have courage and move on.

5) Help other to improve: A key factor in the personal improvement is to help others to improve themselves. Through the personal improvement effort, the organization as a whole can improve. By training and supporting others you are creating more skilled team members for your company. By create teamwork and eliminate barriers you are making progress in your personal quest to be the best. By encouraging the improvement activities of others you are demonstrate your leadership and your enthusiasm will spread throughout the organization like wild fire. By that time people will begin to recognize you and I am sure you will be compensated accordingly.

7) Evaluate your progress: Please do not be over-confident. You need to review your progress again your personal goal. Being the best is not a destination but a journey then you will know that the value of improvement is really in the effort to improve beyond the results. When recognize this, it is time to return to the beginning.

8) Return to step 1: Start your improvement again by following the personal improvement process.

Question: Why do you make such a big thing about quality? If the software is broken then you fix it. Doesn’t that mean keeping your job for a while?

Answer: I can understand that you’re cynical about software improvement but I assume that you do travel in an airplane and understand that the quality of the software on the plane and the software that runs the air traffic control equipment are very important. Similarly, you probably want your bank accounts, your credit cards, your cellular phone bills, your car’s electrical system to be error free don’t you?

Question: Why do you need to establish a Software Engineering Process Group (SEPG) for process improvement?

Answer: To improve the process you must have someone working on it. Is it possible for developers who are very busy already to work on improvement too? I am surprised that some managers think so, they believe that their software developers who are already very busy with project work could spend extra time and effort for process improvement.  From my own experience, in this case, nothing will change. Software developers have learned through many years of hard working on how to cope with multiple tasks, requirements changes, customer demands, software defects and computer problems, as they work under very strict schedules with significant pressures. They have to be convinced that improvement will make their works better or else they will continue their usual ways. Change is hard and requires a lot of work which can not be done by people who already are very busy. SEPG is a special group dedicate to improve the way organization work.

Question: What are the measurements and metrics that we can use for our project? How can we measure software process?

Answer: Here are some typical measurements and metrics:

1)     Size measurement: Number of Single lines of code (SLOC),  Number of Function Point, Number of objects in the project;

2)     Productivity measurements: Number of time spent on the project, number of time spent on each task, number of time spent to fix a change request;

3)     Defect measurement: Severity of each defect (High, Medium, Low);

4)     Quality metrics: Total number of defects, number of defects in each routine or module or object, average defects per thousand lines of code, Mean time between failures.

Question: Why do we need to architect software? Why don’t we just design and code?

Answer: By definition, “software architecting” is the process of creating the architecture for a software product. Since software does not run by itself but have to run within a computer system so the relationship and interface between software and hardware must be taken into consideration. Most software have several components that are interrelated with each others, software engineers need to decide about the structure of these components and how they interact and perform.

In order to do that software engineer must be familiar with the architecture styles as well as technologies. Architecture is the high level concept about how the software product works. Architect must focus at the total system when design is the actual implementation of the architecture and usually at lower levels, more details, and usually focus on certain components of the system.

The architecture consists of several phases:

1)     Elicit architectural requirements: Review customer’s requirements and discuss with customers about the system.

2)     Design the architecture: Review project goals, objectives and functionality requirements to make sure the architecture can fulfill these requirements. Conduct trade-off analysis to assess risks and costs;

3)     Document the architecture:  Document the concepts, create prototyping, make decision on requirements, styles, views, interfaces and quality attributes (performance, scalability, security, usability etc.);

4)     Analyze the architecture: Review with customer for clarification of design requirements, prove through demonstration or prototype that the system will meet requirements;

5)     Realize the architecture: Conduct thorough analysis to make decisions about software, operating system, computer languages, tools, methods, structure and tasks for each component, begin functional decomposition to create a high level design.

6)     Maintain the architecture: Create documents to make sure future design changes will not change the system architecture;

Question: Why are software managers always looking for a “Miracle” such as the CMMI? Why don’t they understand that developing software is hard work with no shortcuts?

Answer: Software managers, like managers in other disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve the quality of products. Like a drowning person who grasps at anything nearby to stay afloat, many software managers often grasp at a certain belief if it can lessen the pressure, even temporarily. We do know that some technologies come with lot of promises but can not deliver and then become relegated to a “fad status”. In my own opinion many Tools, Methods or even CMMI framework do work well, assuming that there is a defined process to integrate them properly and people are trained to use them accordingly. The reason most new technologies do not seem to work is because the organization is not mature enough to receive them or there is lack of a discipline to follow them accordingly.

Question: We had a CMMI appraisal few months ago and were told that our processes were not documented. We already have so many standards and procedures for building software. Why must we document processes and create even more documents?

Answer: Your organization may have many standards and procedures but are they used? Are your people aware of their existence? Do they reflect your current practices? Are they complete? How good are they? Do you measure their usage? Does SQA verify that people follow them correctly? Do you or your senior management review them? Does anybody maintain and update them when necessary? Do your people receive training to use them? If the answer to any of these questions is NO then you may need to revise your document to ensure it reflects what is going on in your organization.

Question: When our manufacturing is behind schedule, we add more people to the project or add a third shift. Why can’t we add more people to a software project when we get behind schedule?

Answer: I’m not sure that adding more people to a project can help make the schedule. If it does, then that process must be very mechanical for more people to help expedite it. You need to know that software development is not a mechanistic process; therefore, adding people will not help. I believe that sometime adding people late in a software project will make it much later.

Question: Since I advocate process improvement, I have received many comments from people in my company. What do you think about these comments?

Answer: It sounds like you are facing a big resistance to change. Here are some of my interpretations on your comments:

1.      “I can’t improve until you give me more detail.”—Could mean no matter how much detail you give, it’s never enough and they will ask for more so they do not have to do anything.

2.      “I am busy doing real work here.”—Could mean they do not value your work or they perceive improvement is not important as compare with what they are doing and they refuse to do it.

3.      “I am still not sure of what you are trying to do.”—Could mean they will continue to claim to be confused, even when you explained everything several times. Since they do not understand, they do not have to improve.

4.      “Where is your solution? Just show me the solution.”—Could mean they want to jump immediately into solutions, without spending the time necessary to clearly identify and analyze the problem.

5.      “I am very busy and do not have time for any improvement stuff.”—Could mean the timing is off, or they will not do it no matter what.

6.      “I need to have a plan first before I can do it” – Could mean they want to plan but do not want to implement. Plan do not fail, implement may fail so they do it in a safe way by not doing anything.

My conclusion: It seems that your organization does NOT want to improve at all.

Question: What is the definition of big, small, medium project?

Answer: There are many different ways of defining a typical project but following is my personal opinion:

A small project team consists of 1 to 10 people—typically working on approximately 10,000 – 50,000 lines of code.

A medium size project team consists of 10 to 50 people—typically working on approximately 50,000 to 100,000 lines of code.

A large project team consists of 50 to 500 people—typically working on approximately 100,000 to 1,000, 000 lines of code.

A very large project team consists of 500 to 2000 people—typically working on approximately 1,000,000 to 10,000,000 lines of code.

If the project involves more than 100 people, it may need to be broken down into more than one project for management purpose. It is easier to manage several small projects than the whole thing.

Question: What is SPICE? Who used it? Should we use it?

Answer: The International Organization for Standardization (ISO) is developing a suite of standards on software process assessment called “Software Process Improvement and Capability dEtermination” or SPICE. It is an independent effort by ISO but it is inspired by the CMM and ISO 9001. However, SPICE aims at harmonizing a number of different models including ISO 9001, ISO 1207, STD, Bootstrap, etc. Therefore, it will be unique and identical to none. At this time, company in the U.S has not committed to use it. The opinions about SPICE in the U.S are mixed and I do not see any reason to use another model without seeing any data.