Hỏi: Theo CMMI, để đạt tới mức trưởng thành 3 tổ chức phải có Qui trình phần mềm chuẩn của tổ chức đã được làm tài liệu – Organizational Standard Software Process (OSSP). Thầy làm tài liệu cho qui trình phần mềm thế nào? Nó trông giống cái gì?

Đáp: Thành công then chốt trong việc làm tài liệu qui trình phần mềm là tạo ra cái gì đó đơn giản, dễ đọc và hữu dụng cho mọi người trong tổ chức. Qui trình của tổ chức nên nói cho người phát triển điều cần được hoàn thành, khi nào nó được thực hiện, và kết quả phải là gì. Có nhiều cách làm tài liệu qui trình nhưng cách dễ nhất là dùng kí pháp Đưa vào, Nhiệm vụ, Trắc nghiệm và Đưa ra  – Entry, Task, Verification, và Exit (ETVX) như sau:

(1)   Tiêu chí đưa vào: Các yêu cầu tối thiểu để bắt đầu qui trình.

(2)   Nhiệm vụ: Hoạt động cần được thực hiện bên trong qui trình đó;

(3)   Trắc nghiệm: Thẩm tra lại rằng hoạt động đã được hoàn thành với kết quả mong muốn (chẳng hạn: Kiểm điểm, đo lường, cách đo, kiểm thử v.v.).

(4)   Tiêu chí đưa ra: Các yêu cầu tối thiểu để ra khỏi qui trình.

Để thực hiện Xác định qui trình tổ chức thành công, bạn phải:

(1)   Hiểu rằng việc xác định qui trình của tổ chức là quá trình tiến hoá, cần thời gian và nỗ lực để thực hiện, nó sẽ tiếp tục tiến hoá và không phải là chỉ làm một lần.

(2)  Duy trì hội tụ vào “Cái gì” chứ KHÔNG vào “Thế nào” và không nhảy quá nhanh vào giải pháp dễ dàng, như việc dùng công cụ tự động và các khuôn mẫu.

(3)  Viết qui trình mức cao để làm cho mọi người đi từ đầu dự án tới cuối (tức là các qui trình vòng đời phần mềm) và tập trung vào “Điều cần được thực hiện” mà không đi chi tiết vào “Cách nó được dự định thực hiện”.

(4)  Giữ cho qui trình của bạn đơn giản và tiến hoá. Bắt đầu bằng qui trình đơn giản, làm mịn nó, và thêm nhiều chi tiết qua thời gian, nếu cần. Không phạm sai lầm làm tài liệu chỉ vì tiến bộ.

(5)  Không bao giờ viết tài liệu lớn ngay một lúc mà hội tụ vào việc viết một tới ba trang mỗi lúc và yêu cầu người phát triển bình luận về nó trước khi tiếp tục thêm nhiều chi tiết khi bạn làm việc xuống các mức thấp hơn.

(6)  Nhớ trong đầu rằng qui trình chỉ nên là hướng dẫn để giúp mọi người làm việc của họ chứ không phải là cái gì đó bị áp đặt lên họ. Nhiều người làm qui trình và kết thúc bằng một tập dầy các qui trình chuẩn của tổ chức mà chẳng ai muốn đọc hay theo.

 

Hỏi: Khoán ngoài phần mềm là gì và làm sao nó có tác động tới xu hướng cải tiến phần mềm?

Đáp: Khoán ngoài phần mềm là việc xuất khẩu công việc có liên quan tới phần mềm từ nước này sang nước khác để tận dụng ưu thế chi phí lao động thấp, tiết kiệm thuế, dùng công nhân có kĩ năng hay các lí do khác. Một số tổ chức khoán ngoài bởi vì họ có thể thu được sản phẩm chất lượng cao hơn được những công nhân có kĩ năng cao xây dựng ở nước khác. Một số tổ chức khoán ngoài bởi vì họ có thể xây dựng sản phẩm với chi phí lao động thấp hơn nhưng tôi nghĩ đây là ngắn hạn thôi bởi vì theo thời gian, chi phí này cuối cùng sẽ tăng lên và họ sẽ phải tìm nhà cung cấp chi phí thấp khác ở nơi nào đó khác. Nỗ lực này là tốn thời gian và tốn kém bởi vì nó phụ thêm vào tổng phí làm kinh doanh.

Quá trình khoán ngoài sẽ tiếp tục khi xu hướng toàn cầu hoá tiến hoá nhưng tôi tin tưởng mạnh mẽ rằng về dài hạn, bất kì công ti nào có thể xây dựng được phần mềm có chất lượng với giả phải chăng bao giờ cũng phát đạt trong loại môi trường cạnh tranh này và việc cải tiến qui trình là chìa khoá để đạt tới thành công này.

Hỏi: Làm sao thầy biết rằng việc xác định qui trình là thành công?

Đáp: Việc xác định qui trình thành công khi:

- Không mất đi khi những người làm việc trên nó ra đi.

- Được mọi người dùng một cách tự nguyện và không bị cấp quản lí áp đặt.

- Được thể lệ hoá đầy đủ (Được xác định, được làm tài liệu, được huấn luyện, được sử dụng, được kiểm nghiệm, được đo và được liên tục cải tiến)

- Được những người thực sự dùng nó cải tiến

- Những người dùng nó có thể thấy ích lợi thực

- Có sự kiện và dữ liệu để chứng tỏ rằng nó có tác dụng (Dữ liệu xu hướng, cách đo, thu hồi vốn đầu tư ROI)

 

Hỏi: Tổ chức của tôi đạt tới sự trưởng thành CMMI mức 2 tháng trước. Là một thành viên của SEPG, tôi muốn biết tôi phải làm gì khác để hướng dẫn tổ chức sang mức sau.

Đáp: Là một thành viên của SEPG của một tổ chức mức 2 mà muốn đạt tới mức 3 bạn cần:

1)     Tham gia vào các hoạt động dự án để nhận diện “thực hành tốt nhất”

2)     Thu thập “thực hành tốt nhất” từ mọi dự án và dùng chúng để thiết lập “Qui trình phần mềm chuẩn của tổ chức” – Organization Standard Software Process (OSSP)

3)     Phát sinh kế hoạch huấn luyện để huấn luyện mọi người trong tổ chức hiểu Qui trình phần mềm chuẩn của tổ chức

4)     Tạo điều kiện dùng Qui trình phần mềm chuẩn của tổ chức

5)     Thu thập cách đo dự án và phân tích chúng để nhận diện xu hướng của tổ chức

6)     Để người quản lí dự án và người quản lí tổ chức được thông tin về việc dùng qui trình phần mềm chuẩn của tổ chức và sự tuân thủ của dự án.

7)     Làm việc với mọi dự án để giới thiệu qui trình mới, kĩ thuật mới và chia sẻ “thực hành tốt nhất” với họ

8)     Đo tiến bộ và hiệu năng của tổ chức như một đơn vị nghiệp vụ và đưa ra gợi ý riêng về cải tiến qui trình.

 

Hỏi: Là thành viên của SEPG, công việc của tôi là tư vấn cải tiến qui trình. Tôi muốn thay đổi chức danh của mình là “Tư vấn cải tiến qui trình”. Thầy nghĩ thế nào?

Đáp: Thực hiện các hoạt động tư vấn không đòi hỏi rằng chức danh công việc của người ta phải chứa từ “Tư vấn.” Tôi tin rằng bạn tư vấn bất kì lúc nào bạn đang cố gắng thay đổi hay cải tiến một tình huống. Nhiều người trong chúng ta nhận vai trò nhà tư vấn trong các hoạt động hàng ngày của mình mà không có chức danh chính thức và chúng ta không muốn bị khoá cứng vào trong một vai trò như nhà tư vấn.  Theo ý kiến tôi, “thành viên SEPG” không phải là chức năng mà chỉ là phân công nhiệm vụ và nó có thể thay đổi qua thời gian. Tôi gợi ý bạn nên giữ chức danh chính thức của mình là “Kĩ sư phần mềm”, “Lập trình viên”, hay “Nhà phân tích tính toán”, điều có thể thích hợp hơn.

 

Hỏi: Tổ chức của tôi được thẩm định ở CMMI mức 1. Chúng tôi có khó khăn khi lập tập các cách đo được đặt vào kế hoạch cải tiến của mình.  Thầy gợi ý gì?

Đáp: Với tổ chức ở mức 1, tập các chỉ báo hiệu năng phần mềm có thể được đưa vào là như sau:

(1)   Chất lượng

A.     Tỉ lệ lỗi sau khi đưa ra (lỗi sau khi đưa ra một sản phẩm liên quan tới kích cỡ sản phẩm).

B.      Chi phí cho tỉ lệ chất lượng (tỉ số thời gian dành cho kiểm điểm phần mềm so với thời gian sửa chữa hỏng).

(2)   Tính dự đoán được

A.     Độ trượt thời gian trôi qua tương đối (khác biệt giữa thời gian trôi qua thực tế và thời gian ước lượng của hoạt động).

B.     Độ trượt Chi phí/Nỗ lực tương đối (chi phí thực tại /chi phí ước lượng).

 

Hỏi: Tổ chức của tôi đã có kế hoạch cải tiến. Chúng tôi cần làm gì nữa để đảm bảo thành công?

Đáp: Bên cạnh làm việc thực hiện các nhiệm vụ đã được nhận diện ra trong bản kế hoạch thực hiện, tổ chức của bạn có thể cần

(1)   Thiết lập kết cấu nền để phối hợp các hoạt động cải tiến như Nhóm qui trình kĩ nghệ phần mềm Software Engineering Process Group (SEPG).

(2)   Làm việc để thay đổi hành vi của mọi người hướng tới qui trình chứ không hướng sản phẩm.

(3)   Thực hiện các hoạt động cải tiến thấy được cho mọi người.

(4)   Phát triển kĩ năng cho mọi người thực hiện các hoạt động.

(5)   Duy trì cam kết của cấp quản lí bằng việc tạo ra báo cáo hiện trạng hàng tháng, nơi bạn thảo luận các vấn đề cũng như thành công với cấp quản lí và hỏi xin ý kiến chỉ đạo của họ.

Hỏi: Khác biệt giữa kiểm nghiệm (validation) phần mềm và trắc nghiệm (verification) phần mềm là gì?

Đáp: Kiểm nghiệm phần mềm đảm bảo rằng các yêu cầu của người dùng là nhất quán và đầy đủ tương ứng với các yêu cầu mức cao. Kiểm nghiệm thường bao gồm người dùng để xác nhận tính hợp lệ các yêu cầu bằng việc tiến hành kiểm thử trong môi trường riêng của họ để chắc chắn rằng sản phẩm phần mềm là chấp nhận được.

Trắc nghiệm phần mềm đảm bảo rằng giải pháp được lựa đáp ứng các yêu cầu kĩ thuật riêng.

 

Hỏi: Làm sao thầy huấn luyện được kĩ sư mới làm theo cách “đúng” cho mọi thứ khi tổ chức không có qui trình được xác định (Còn chưa đạt tới mức 3)?

Đáp: Tổ chức không cần phải ở mức 3 để làm mọi việc đúng. Có nhiều cách huấn luyện kĩ sư mới như Học nghề, Kèm cặp, nhưng có lẽ điều quan trọng nhất là trao đổi giữa các kĩ sư về kinh nghiệm quá khứ với các dự án tương tự. Nếu tổ chức có thể tạo ra được “môi trường làm việc đúng” nơi mọi người tự do trao đổi và chia sẻ các giải pháp kĩ thuật (những thực hành tốt nhất) thì việc học sẽ xảy ra.

 

Hỏi: Văn hoá của tổ chức thay đổi thế nào khi thực hiện cải tiến qui trình?

Đáp: Văn hoá của tổ chức có thể được xác định như giá trị của nó, các qui tắc không viết ra, và hành vi tập thể của mọi người trong tổ chức. Để cải tiến qui trình, bạn phải hiểu văn hoá của tổ chức mà bạn đang định thay đổi. Chẳng hạn, một tổ chức đang cố gắng xác định qui trình chuẩn cho mọi người tuân theo nhưng cấp quản lí vẫn thưởng cho những người thích làm theo cách của họ và bỏ qua qui trình chuẩn quốc tế thì văn hoá này sẽ không thay đổi và việc cải tiến sẽ không xảy ra.

 

Hỏi: Làm sao thầy cung cấp việc tư vấn được cho tổ chức chỉ muốn đạt tới CMMI mức 3 và không gì khác?

Đáp: Khi cung cấp tư vấn cải tiến qui trình, điều quan trọng là bạn hiểu mục đích và động cơ của những người trong tổ chức và chuẩn bị công việc của bạn tương ứng.

Nếu họ chỉ muốn đạt tới mức độ trưởng thành, bạn cần giáo dục họ về các ích lợi khác của việc cải tiến và cảnh quan dài hạn của việc là tổ chức chất lượng. Bạn cần hỏi họ mức 3 nghĩa là gì với họ theo cảnh quan kinh doanh cũng như kĩ thuật. Bạn cần hướng dẫn họ theo chiều hướng đúng của việc là tổ chức thành công.

 

Hỏi: Triển khai chức năng chất lượng – Quality Function Deployment (QFD) là gì trong phát triển phần mềm?

Đáp: Triển khai chức năng chất lượng – Quality Function Deployment (QFD) là kĩ thuật để nhận diện nhu cầu khách hàng và ưu tiên của họ. Những kĩ thuật này được ánh xạ vào các đặc trưng kĩ thuật được yêu cầu. Tương tác giữa những đặc trưng này được nhận diện và phân loại xem liệu nó là tương quan tích cực, trung lập hay tiêu cực. QFD được dùng lúc đầu trong vòng đời phát triển phần mềm, thông thường trong yêu cầu, phân tích bù trừ hay phân tích thị trường.

 

Hỏi: Ưu điểm và nhược điểm của vòng đời “Thác đổ” là gì? Một số người bênh vực nó nhưng nhiều người nói nó không có tác dụng. Ý kiến của thầy là gì?

Đáp: Vòng đời Thác đổ dựa trên cách tiếp cận phát triển trên xuống và là một tập có thứ tự các pha, được thực hiện tuần tự. (Yêu cầu, Thiết kế, Thực hiện, Kiểm thử, Đưa ra). Nó được thiết kế để là mô hình có hệ thống, có trật tự để quản lí kích cỡ và độ phức tạp của qui trình phát triển phần mềm.

Vòng đời thác đổ làm việc tốt nhất khi yêu cầu có thể được xác định đầy đủ trước khi bắt đầu pha tiếp hay thiết kế sơ bộ. Tuy nhiên, do bản chất của yêu cầu thường xuyên thay đổi, bạn sẽ cần tiến hành công việc làm bản mẫu nào đó trong pha yêu cầu để giảm bớt rủi ro của yêu cầu được xác định bộ phận.

Ưu điểm của mô hình này là:

1)     Có cấu trúc tốt, dễ hiểu

2)     Tiếp cận trên xuống

3)     Buộc khách hàng phải xác định các yêu cầu từ phía đầu trên

4)     Khuyến khích nhiều trao đổi giữa khách hàng và người phát triển

Nhược điểm của mô hình này là:

1)     Rất rủi ro nếu các yêu cầu không thể được xác định

2)     Phần lớn khách hàng không thể hoàn thành được các yêu cầu trong pha đầu tiên và làm trễ công việc phát triển

3)     Qui trình tốn kém với nhiều chậm trễ, việc phải làm lại nếu không làm giảm bớt rủi ro tương ứng.

—-English version——

 

CMMI-7

Question: According to the CMMI, to achieve maturity level 3 the organization must have a documented Organizational Standard Software Process (OSSP). How do you document a software process? What does it look like?

Answer: The key success in documenting a software process is creating something simple, easy to read and useful to people in the organization. The organization process should tell developers what is to be accomplished, when it is done, and what the results should be. There are many ways to document a process but the easiest way is using the Entry, Task, Verification, and Exit (ETVX) notation as follows:

(1)   Entry criteria: Minimum requirements to start the process.

(2)   Task: Activities to be done within that process;

(3)   Verification: Verify that activity has been completed with the desired results (for example: Review, measures, metrics, test, etc.).

(4)   Exit criteria: Minimum requirements to exit the process.

To implement the Organization Process Definition successfully, you should:

(1)   Understand that organization process definition is an evolutionary process, it takes time and effort to implement it , it will continue to evolve and not a one time only.

(2)   Stay focused on the “What” NOT the “How” and do not jump too quickly to an easy solution, such as using automated tools and templates.

(3)   Write a high level process to enable people to go from the beginning of a project to the end (e.g., software life cycle processes) and concentrate on “What needs to be done” without detail on “How it is to be accomplished”.

(4)   Keep your process simple and evolving. Start with simple process, refining it, and adding more detail over time, as necessary. Do not mistake documentation for progress.

(5)   Never write a large document all at once but focus on getting one to three pages at a time and ask developers to comment on it before continue adding more details as you work your way down to lower levels.

(6)   Keep in mind that a process should only be a guide to help people do their jobs not something imposed on them. Many people get carried away and end up with a large volume of organization standard process that nobody wants to read or to follow.

 

Question: What is software outsourcing and how does it impact the software improvement trend?

Answer: Software outsourcing is the exporting of software -related work from one country to another to take advantage of lower labor costs, tax savings, skilled workers or other reasons. Some organizations outsource because they can get higher quality product build by highly skilled workers in another country. Some organizations outsource because they can build product with lower labor costs but I think this is a short term because in time, the cost will eventually go up and they will have to find another lower cost supplier elsewhere. This effort is time consuming and costly because it will add up to the overall cost of doing business.

The outsourcing process will continue as globalization trend evolve but I strongly believe that in a long term, any company that can build quality software at reasonable cost will always thrive in this kind of competitive environment and process improvement is the key to achieve this success.

 

Question: How do you know that a process definition is successful?

Answer: A successful process definition:

- Does not go away when people who work on it leaves.

- Is used by people voluntarily and not imposed by management.

- Is fully institutionalized (Defined, documented, trained, used, validated, measured and continuously improved)

- Is improved by people who are actually using it

- People who use it can see real benefits

- Have facts and data to prove that it works (Trends, metrics, ROI data)

 

Question: My organization achieved CMMI maturity level 2 last month. As a SEPG member, I want to know what I should do differently to guide the organization to the next level.

Answer: As a SEPG member of a level-2 organization that want to achieve a level 3 you need to:

1)     Participate in project’s activities to identify “best practices”

2)     Collect “best practices” from all projects and use them to establish the “Organization Standard Software Process” (OSSP)

3)     Generate a training plan to train everybody in the organization to understand the Organization Standard Software Process

4)     Facilitate the use of the Organization Standard Software Process

5)     Collect project metrics and analyze them to identify organization’s trends

6)     Keep project manager and organization manager informed about the use of organization standard software process and project’s compliance

7)     Working with all projects to introduce new process, new technique and share “best practices” with them

8)     Measure progress and organization’s performance as a business unit and make specific suggestion for process improvement.

 

Question: As a member of a SEPG, my job is to consult on process improvement. I would like to change my title to “Process Improvement Consultant”. What do you think?

Answer: Performing consulting activities does not require that one’s job title to include the word “Consultant.” I believe that you are consulting any time you are trying to change or improve a situation. Many of us take on the role of consultant in our daily activities without a formal title and we do not want to be locked in to a single role as a consultant.  In my opinion, “SEPG member” is not a title but only an assignment and it can change over time. I suggest you keep your formal title as a “Software Engineer”, “Programmer”, or “Computing Analyst”, which may be more appropriate.

 

Question: My organization was assessed at CMMI level 1. We have difficulty coming up with a set of metrics to be put on our improvement plan.  What do you suggest?

Answer: For a level 1 organization, a set of software performance indicators can be introduced as follows:

(1)   Quality

A.     Post-released Defect rate (defects after a release of a product related to product size).

B.      Cost of Quality ratio (ratio of time spent in software reviews vs. time to fix failures).

(2)   Predictability

A.     Relative Lead-time Slip (differences between actual and estimated lead-time of an activity).

B.     Relative Cost/Effort Slip (actual cost/estimated cost).

 

Question: My organization already has an improvement plan. What else do we need to do to ensure success?

Answer: Besides working to implement tasks identified in the improvement plan, your organization may need to

(1)   Establish an infrastructure to coordinate improvement activities such as the Software Engineering Process Group (SEPG).

(2)   Work on changing behavior of people toward process oriented rather than product oriented.

(3)   Make process improvement activities visible to everybody.

(4)   Develop skills for people implementing improvement activities.

(5)   Maintain management’s commitment by create a monthly status reporting where you discuss problems as well as success with management and ask for their direction.

 

Question: What is the different between Software Validation and Software verification?

Answer: Software Validation ensures that the user requirements are consistent and complete with respect to high level requirements. Validation usually involves users to validate the requirements by conducting a test in their own environment to make sure that the software product is acceptable.

Software verification ensures that the selected solution meets the specified technical requirements.

 

Question: How do you train new engineer in the “Right” way of doing thing when the organization does not have a defined process (Have not achieve level 3)?

Answer: Organization does not have to be a level 3 in order to do thing right. There is several way of training new engineer such as Apprenticeship, Mentoring, but probably the most important is communication among engineers on past experiences on similar projects. If the organization can create a “Right working environment” where everybody freely communicate and share technical solutions (Best Practices) then the learning will take place.

 

Question: How much change in the organization’s culture when implementing process improvement?

Answer: Organization’s culture can be defined as its values, unwritten rules, and collective behaviors of people within an organization. To improve the process, you must understand the culture of the organization that you are trying to change. For example, an organization trying to define the standard process for everybody to follow but if management is still rewarding people who like do thing their way and ignore organizational standard process then the culture will not change and the improvement will not happen.

 

Question: How do you provide consultation to an organization that only wants to achieve a CMMI level 3 and nothing else?

Answer: When provide process improvement consultation, it is important that you understand the goals and motivation of the people in the organization and prepare your work accordingly.

If they only want to achieve a maturity level, you need to educate them about other benefits of improvement and the long term perspective of being a quality organization. You need to ask them what a level 3 means to them from business as well as technical perspective. You need to guide them to the right direction of being successful organization.

 

Question: What is Quality Function Deployment (QFD) in software development?

Answer: Quality Function Deployment (QFD) is a technique for identifying customer needs and their priority. These needs are mapped to the required technical characteristics. Interaction between these characteristics is identified and categorized as to whether it is positive, neutral or negative correlation. QFD is used early in the software development life cycle, usually in requirements, trade-off analysis or market analysis.

 

Question: What is the advantage and disadvantage of the “Waterfall” life cycle? Some people advocate it but many said it did not work. What is your opinion?

Answer: The Waterfall life cycle is based on a top-down development approach and is an ordered set of phases that are performed in sequence. (Requirement, Design, Implement, Test, Release). It is designed to be an orderly, systematic model to manage the size and complexity of a software development process.

The waterfall life cycle work best when the requirements can be completely defined before starting the next phase or preliminary design. However, due to the nature of requirements keep on changing, you will need to conduct some prototype works during requirement phase to reduce the risk of partially specified requirements.

The advantages of this model are:

1)     Well structured, easy to understand

2)     Top-down approach

3)     Force the customer to specify requirements up-front

4)     Encourage more communication between customer and developer

The disadvantages of this model are:

1)     Very risky work if the requirements can not be specified

2)     Most customers can not complete the requirements within the first phase and delay the development work

3)     Expensive process with many delays, re-works if not mitigate risks accordingly.