Tự học PM

A fine WordPress.com site

Defect Prevention: Reducing Costs and Enhancing Quality

leave a comment »

“Prevention is better than cure” applies to defects in the software development life cycle as well as illnesses in medical science. Defects, as defined by software developers, are variances from a desired attribute. These attributes include complete and correct requirements and specifications as drawn from the desires of potential customers. Thus, defects cause software to fail to meet requirements and make customers unhappy.

And when a defect gets through during the development process, the earlier it is diagnosed, the easier and cheaper is the rectification of the defect. The end result in prevention or early detection is a product with zero or minimal defects.

How serious are defects in software development? In the United States, up to 60 percent of software developers are involved in fixing errors, Computer Finance Magazine reported in 1998. This fact alone, without consideration of providing the quality needed to please customers, shows the value of preventing software defects.

Advantage of Early Defect Detection

Data to support the need for early fixes of software defects is supplied by several reports. The National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of fixing one bug found in the production stage of software is 15 hours compared to five hours of effort if the same bug were found in the coding stage.

The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase (Figure 1).

Figure 1: Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)

Figure 1: Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)

Can software defects be prevented by simply logging them into some “defect tracking tool/system,” documenting them and providing fixes for them? The obvious answer is no, though this is the first step toward defect prevention.

Defect prevention involves a structured problem-solving methodology to identify, analyze and prevent the occurrence of defects. Defect prevention is a framework and ongoing process of collecting the defect data, doing root cause analysis, determining and implementing the corrective actions and sharing the lessons learned to avoid future defects.

Principles of Defect Prevention

How does a defect prevention mechanism work? The answer is in a defect prevention cycle (Figure 2). The integral part of the defect prevention process begins with requirement analysis – translating the customer requirements into product specifications without introducing additional errors. Software architecture is designed, code review and testing are done to find out the defects, followed by defect logging and documentation.

Figure 2: Defect Prevention Cycle (Source: 1998 IEEE Software Productivity Consortium)

Figure 2: Defect Prevention Cycle (Source: 1998 IEEE Software Productivity Consortium)

The blocks and processes in the gray-colored block represent the handling of defects within the existing philosophy of most of the software industry – defect detection, tracking/documenting and analysis of defects for arriving at quick, short-term solutions.

The processes that form the integral part of the defect prevention methodology are on the white background. The vital process of the defect prevention methodology is to analyze defects to get their root causes, to determine a quick solution and preventive action. These preventive measures, after consent and commitments from team members, are embedded into the organization as a baseline for future projects. The methodology is aimed at providing the organization a long-term solution and the maturity to learn from mistakes.

Most of the activities of the defect prevention methodology require a facilitator. The facilitator can be the software development project leader (wearing another hat of responsibility) or any member of the team. The designated defect prevention coordinator is actively involved in leading defect prevention efforts, facilitating meetings and communication among team and management, and consolidating the defect prevention measures/guidelines.

The five general activities of defect prevention are:

1. Software Requirements Analysis

Table 1: Division of Defects Introduced into Software by Phase

Software Development Phases

Percent of Defects Introduced


20 Perecent


25 Percent


35 Percent

User Manuals

12 Percent

Bad Fixes

8 Percent

Source: Computer Finance Magazine

Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also are more severe and more difficult to remove. Front-end errors in requirements and design cannot be found and removed via testing, but instead need pre-test reviews and inspections. Table 1 shows the defects introduced during different phases of the software development life cycle.

From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs (Figure 3), according toCrosstalk, the Journal of Defense Software Engineering.

Figure 3: Origin of Software Defects (Source: Crosstalk, the Journal of Defense Software Engineering)

Figure 3: Origin of Software Defects (Source: Crosstalk, the Journal of Defense Software Engineering)

Hence, it is important to have a proper process of analyzing the requirements in place to ensure that the customer needs are correctly translated into product specifications. Perhaps two or three iteration of interactive sessions with the customer can be of great help in verifying the understanding of the developer about actual requirements.

2. Reviews: Self-Review and Peer Review

Self-review is one of the most effective activites in uncovering the defects which may later be discovered by a testing team or directly by a customer. The majority of the software organizations are now making this a part of “coding best practices” and are really increasing their product quality.

Often, a self-review of the code helps reduce the defects related to algorithm implementations, incorrect logic or certain missing conditions. Once the developer feels they are ready with the module code, a glance through the code and understanding what it does compared to what it is supposed to do, would complete the self-review.

Peer review is similar to self-review in terms of the objective – the only difference is that it is a peer (someone who understands the functionality of the code very well) who reviews the code. The advantage is that of a “fresh pair of eyes.”

3. Defect Logging and Documentation

Effective defect tracking begins with a systematic process. A structured tracking process begins with initially logging the defects, investigating the defects, then providing the structure to resolve them. Defect analysis and reporting offer a powerful means to manage defects and defect depletion trends, hence, costs.

A defect logging tool should document certain vital information regarding the defect such as:

  • Correct and complete description of the defect – so that everyone on the development team understands what it is and how to reproduce it.
  • Phase at which it is found – so that preventive measures can be taken and propagation of the defect to next phase (software build) is avoided.
  • Further description of the defect by screenshots.
  • Names of those who uncover defects – so everyone knows who to contact for a better understanding of the defect.

4. Root Cause Analysis and Preventive Measures Determination

After defects are logged and documented, the next step is to analyze them. Generally the designated defect prevention coordinator or development project leader facilitates a meeting to explore root causes.

The root cause analysis of a defect is driven by three key principles:

  • Reducing the defects to improve the quality: The analysis should lead to implementing changes in processes that help prevent defects and ensure their early detection.
  • Applying local expertise: The people who really understand what went wrong are the people present when the defects were inserted – members of the software engineering team. They can give the best suggestions for how to avoid such defects in the future.
  • Targeting the systematic errors: There may be many errors or defects to be handled in such an analysis forum; however, some mistakes tend to be repeated. These systematic errors account for a large portion of the defects found in the typical software project. Identifying and preventing systematic errors can have a big impact on quality (in terms of defects) for a relatively small investment.

With these guidelines, defects are analyzed to determine their origins. A collection of such causes will help in doing the root cause analysis. The defects are classified based on their types. A Pareto chart is prepared to show the defect category with the highest frequency of occurrence – the target. An example of defect classification in a Pareto chart is shown in Figure 4.

Figure 4: Example of Defect Classification in a Pareto Chart

Figure 4: Example of Defect Classification in a Pareto Chart

Root cause analysis is the process of finding and eliminating the cause, which would prevent the problem from recurring. Finding the causes and eliminating them are equally important.

Each defect category and the causes making those defects happen can be represented using a cause-and-effect diagram, as shown in Figure 5.

Figure 5: Cause-and-Effect Diagram for a Defect

Figure 5: Cause-and-Effect Diagram for a Defect

The cause-and-effect diagram, also known as a fishbone diagram, is a simple graphical technique for sorting and relating factors that contribute to a given situation. A team usually develops the cause-and-effect diagram in a facilitated brainstorming session. Once the root causes are documented, finding ways to eliminate them requires another round of brainstorming. The object is to determine what changes should be incorporated in the processes so that recurrence of the defects can be minimized.

5. Embedding Procedures into Software Development Process

Implementation is the toughest of all activities of defect prevention. It requires total commitment from the development team and management. A plan of action is made for deployment of the modification of the existing processes or introduction of the new ones with the consent of management and the team. Some of the other activities in this phase of defect prevention are:

  • Monthly status of the team should mention the severe defects and their analyses.
  • Fortnightly or monthly (based on the project schedule) meetings to make the team aware of the systematic errors/defects, their symptoms and solutions.
  • Embedding the defect prevention measures in software development life cycle processes.
  • Learning from the previous project’s root cause analysis of defects should be used as the baseline for future projects.
  • Monitoring the defect prevention progress. Is the number of defects decreasing? Is the development team learning from past mistakes?

Finally, defect prevention is not an individual exercise but a team effort. The software development team should be striving to improve its process by identifying defects early, minimizing resolution time and therefore reducing project costs.

Conclusion: Beyond ‘To Err Is Human’

To err is human but defect prevention practices enhance the ability of software developers to learn from those errors and, more importantly, learn from the mistakes of others. The benefits of implementing a defect prevention methodology are:

  • Improved checklist for product quality
  • Reduced rework effort
  • Significant reduction the number of defects and their severity
  • Better communication among the project team and upper management
  • More optimized resource planning



Written by hoantv

September 26, 2014 at 10:46 am

Posted in Uncategorized

Quản lý cấu hình – Yêu cầu cơ bản trong mọi dự án phần mềm

leave a comment »

Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về quản lý cấu hình, tuy rằng chúng vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần nào làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của quản lý cấu hình trong quy trình sản xuất phần mềm.

Những ai quan tâm đến quy trình sản xuất phần mềm, chắc hẳn không ít lần gặp khái niệm về quản lý cấu hình (Configuration Management). Ta dễ dàng tìm thấy các yêu cầu về quản lý cấu hình (QLCH) một cách trực tiếp hay gián tiếp trong các bộ tiêu chuẩn hoặc mô hình quy trình sản xuất phần mềm (QTSXPM) thông dụng hiện nay như CMM/CMMI, ISO 15504 hoặc ISO 9001:2000. Trong CMM và CMMI, QLCH là yêu cầu bắt buộc ngay từ mức 2, là mức cơ bản nhất của hai mô hình này.

Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về QLCH, tuy rằng chúng vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần nào làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của QLCH trong QTSXPM.

Tại sao cần Quản lý cấu hình?

Chắc hẳn trong chúng ta đã ít nhất một lần gặp những tình huống sau:

• Một lỗi (bug) nào đó của phần mềm đang xây dựng đã tốn nhiều công sức sửa chữa, bỗng “thình lình” xuất hiện trở lại.

• Một chức năng (function) nào đó của phần mềm đã được phát triển và kiểm tra cẩn thận bổng thất lạc hoặc biến mất một cách khó hiểu.

• Một chương trình (program) đã được kiểm tra hết sức cẩn thận, bỗng nhiên không “chạy” được nữa.

• Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức năng, các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng bao gồm nhiều tập tin mã nguồn (source code) với nhiều phiên bản (version) khác nhau. Khi tích hợp hệ thống và biên dịch, trong hàng chục tập tin source code với hàng trăm version, tập tin nào, version nào là đúng và cần phải lấy để tiến hành tích hợp?

Các vấn đề trên sẽ không xảy ra nếu như trong dự án, việc QLCH được thực hiện nghiêm túc và kiểm soát chặt chẽ.

Ta có thể tham khảo định nghĩa ngắn gọn sau từ CMM và ISO 15504: “Mục đích của QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó.”

Nói cho dễ hiểu và gần gũi, QLCH bao gồm các công việc về nhận dạng, tổ chức, và quản lý các thay đổi đối với những sản phẩm đang được xây dựng bởi một nhóm lập trình viên, từ các sản phẩm trung gian đến sản phẩm sau cùng.

QLCH tốt sẽ giải quyết được hàng loạt những khó khăn trong các dự án, đặc biệt trong các dự án lớn:

– Cập nhật đồng thời: Khi 2 hoặc nhiều lập trình viên làm việc cách biệt nhau nhưng trên cùng một chương trình hoặc dự án, những thay đổi mà người này thực hiện có thể sẽ phá vỡ kết quả làm việc của người khác. Ví dụ: Sản phẩm anh A sử dụng kết quả công việc của anh B, sản phẩm của anh B thay đổi có thể làm cho sản phẩm anh A không chạy được nữa.

– Chia sẻ source code: Trong các hệ thống lớn, khi các chức năng chung bị thay đổi, tất cả những người liên quan phải được biết.

– Phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ thống lớn được phát triển với nhiều release tiến hóa từ thấp đến cao. Trong trường hợp một release khách hàng đang dùng, release khác đang được kiểm tra (test), và một release khác nữa đang trong quá trình phát triển, khi có lỗi (bug) xảy ra, việc sửa lỗi phải đồng bộ giữa ba phần này, nếu không quản lý source code tốt, vấn đề đồng bộ rất khó thực hiện được. Nếu lỗi ở release khách hàng đang dùng, nó phải được sửa chữa trong tất cả các release sau đó.

Khi nào thì cần tiến hành QLCH? QLCH được thực hiện xuyên suốt chu kỳ sống của dự án, từ lúc bắt đầu đến khi kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau dự án. (Hình 1)


Trước khi đi vào chi tiết, ta cần tìm hiểu 2 khái niệm rất cơ bản trong QLCH:

• Configuration Item – CI: định danh này trong QLCH là tên gọi của các sản phẩm, sản phẩm trung gian, một tập tin (file) hoặc nhóm file, tài liệu hoặc nhóm tài liệu trong một dự án mà ta cần phải quản lý và kiểm soát. Nói chung là những “món” được tạo ra trong một dự án mà ta cần phải quản lý, ví dụ: một file source code, tài liệu về yêu cầu sản phẩm, bản thiết kế v.v.

• Baseline: một điểm “mốc” được thỏa thuận bởi những người liên quan trong một dự án, sao cho sau điểm “mốc” này, mọi thay đổi phải được thông báo tới tất cả những người có liên quan.

Một cách tổng quan, QLCH bao gồm các nhóm hoạt động như hình 2.

Lập kế hoạch QLCH
(Configuration Management planning)

Thông thường, việc lập kế hoạch cho QLCH được thể hiện trong tài liệu có tên Kế hoạch quản lý cấu hình (Configuration Manegement Plan – CMP). Bản kế hoạch này thường bao gồm:

• Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch

• Vai trò và trách nhiệm của nhóm, cá nhân trong dự án thực hiện các hoạt động khác nhau liên quan đến QLCH. Định nghĩa rõ ràng ai thực hiện (perform), ai xem xét (review), ai phê duyệt (approve) trên các CI của dự án, cũng như vai trò của khách hàng, người sử dụng đầu cuối. Xem ví dụ ở hình 3.

• Công cụ (tool), môi trường (environment) và cơ sở hạ tầng (infrastructure). Phần này mô tả các công cụ phần mềm hoặc quy trình thủ tục được sử dụng hỗ trợ QLCH, chẳng hạn công cụ quản lý phiên bản sản phẩm (version control); mô tả vị trí các máy chủ, máy trạm, cấu hình hệ thống client-server,…

• Phương pháp định danh và thiết lập baseline trên các CI

• Quy ước đặt tên trong dự án, gồm cả tên file

• Quy trình xử lý và quản lý các thay đổi (change control process)

• Chỉ định thành viên nhóm Configuration Control Board (CCB)

• Thông tin nơi lưu trữ các CI

• Kiểm kê và báo cáo cấu hình (configuration accounting and reporting)

• Quy trình thủ tục lưu trữ và chép dự phòng (backup and archieve)

Các điểm trong bản kế hoạch trên sẽ được giải thích rõ trong các phần tiếp sau.

Định danh/đánh số các CI
(Identification of Configuration Items)

Định danh là một trong những hoạt động nền tảng của QLCH. Mục đích của định danh là để xác định tính duy nhất của một CI, cũng như mối quan hệ của nó với các CI khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc trưng, giúp nhận biết và phân biệt một CI với các CI hay thành phần khác.

Bạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tế. Ví dụ, người ta đánh số bàn trong nhà hàng nhằm giúp người phục vụ mang đúng thức ăn cho khách.

Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file. Ví dụ: một module tên ExpMod có thể được coi là một CI, module này có 2 file ExpMod.h và ExpMod.c.

Mỗi CI phải có một số định danh duy nhất, dạng thức thường thấy là:

Ví dụ: PRJ001_REQB_1.0.4_draft_B cho biết:
Số ID của dự án: PRJ001
Số ID của Item : REQB
Phiên bản: 1.0.4_draft_B

Trong một dự án, thường có rất nhiều file source code, quy tắc cơ bản là: các file cùng tạo nên một khối chức năng được gom chung thành một CI.

Kiểm soát phiên bản (Version Control)

Có nhiều định nghĩa và cách hiểu khác nhau về version control, ở đây chúng tôi chỉ muốn định nghĩa nó ở khía cạnh thông dụng, sát với bản thân cụm từ nhất.

Version control là sự kiểm soát các phiên bản (version) khác nhau của một CI (bao gồm việc định danh và sự lưu trữ CI đó).

Thế phiên bản là gì? một phiên bản là một thực thể mới của một CI sau khi đã qua một hoặc nhiều lần xem xét và thay đổi.

Hiện có nhiều công cụ trên thị trường hỗ trợ cho việc kiểm soát phiên bản, một số công cụ thông dụng là: Visual Source Safe của Microsoft, ClearCase của Rational, CVS (nguồn mở).

Mỗi phiên phản sẽ có một số ID đầy đủ, và được tăng dần cho mỗi phiên bản mới.

Lưu ý rằng phiên bản của một CI khác với phiên bản của các file thành phần của CI đó. Trong ví dụ trên, phiên bản của CI “ExpMod” khác với phiên bản của file thành phần “ExpMod.h” và “ExpMod.c”. (Xem hình 3)

Các phiên bản quan trọng của một CI có thể được đánh dấu để nhận biết một “mốc” quan trọng trong tiến trình phát triển CI đó, phiên bản mà CI được phê duyệt hay baseline.

Quản lý baseline
(Baseline Management)

Cũng như Version Control, baseline có nhiều cách hiểu khác nhau, trong phạm vi bài viết này, chúng tôi chọn ý nghĩa tương đối phổ biến. Trong thực tế thường gặp các loại baseline sau:

• Chức năng (functional)

• Kế hoạch (planning)

• Yêu cầu (requirements)

• Sản phẩm (product)

• Bản phân phối (release)

• Kiểm tra (test)

• Môi trường hoạt động (environment)

Quản lý baseline bao gồm:

• Chọn các CI cho mỗi loại baseline

• Tiến hành “ghim chết” baseline tại thời điểm sau khi các thay đổi đã được chấp thuận và phê chuẩn.

Thông thường, baseline được tiến hành tại điểm kết thúc của mỗi giai đoạn hay tại các “mốc” quan trọng trong dự án. Hình 4 cho thấy rõ hơn các loại và thời điểm baseline.

Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập hoặc phê chuẩn baseline cũng phải được định nghĩa.

Kiểm soát thay đổi (Change control)

Khi phát triển hoặc bảo trì một sản phẩm phần mềm, việc thay đổi yêu cầu là không thể tránh khỏi.

Mục đích của change control là để kiểm soát đầy đủ tất cả các thay đổi ảnh hưởng đến việc phát triển một sản phẩm. Đôi lúc chỉ một vài yêu cầu thay đổi nhỏ của khách hàng, tất cả các chặng của quy trình phát triển phần mềm từ thiết kế, đến viết code, đến kiểm tra sản phẩm đều phải thay đổi theo.

Nếu các thay đổi này không được kiếm soát chặt chẽ sẽ dẫn đến rất nhiều sai sót. Xét ví dụ sau: 5 lập trình viên cùng làm trong một dự án, nhưng chỉ có 3 được thông báo về việc thay đổi thiết kế. Kết quả là khi tích hợp, hệ thống sẽ không vận hành được.

Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất cả những người hoặc nhóm làm việc có liên quan.

Hình 5 minh họa một quy trình cơ bản kiểm soát thay đổi.

Các bước cơ bản của kiểm soát thay đổi bao gồm:

Nghiên cứu, phân tích

Phê chuẩn hoặc không phê chuẩn

Thực hiện việc thay đổi

Kiểm tra việc thay đổi

Xác lập baseline mới

Trong kiểm soát thay đổi, ta cũng thường gặp khái niệm “nhóm kiểm soát thay đổi” gọi tắt là CCB (Change Control Board), nhóm này được thành lập trong từng dự án. CCB thông thường bao gồm:

Người QLC H (Configuration Manager)

Trưởng dự án (Project Manager)

Trưởng nhóm (Technical Lead)

Trưởng nhóm kiểm soát chất lượng (Test Lead)

Kỹ sư chất lượng (Quality Engineer)

Và những ai bị ảnh hưởng bởi các thay đổi

Nhiệm vụ của CCB thường là:

• Bảo đảm tất cả các thay đổi là được các bộ phận liên quan nhận biết và tham gia

• Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline

• Kiểm tra, xác nhận các thay đổi

• Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng

Báo cáo tình trạng cấu hình
(Configuration Status Accounting)

Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như yêu cầu thay đổi, tập hợp số liệu thống kê về CI, đặc biệt là các CI góp phần tạo nên sản phẩm. Nó trả lời những câu hỏi như: có bao nhiêu file bị ảnh hưởng khi sữa chữa một lỗi phần mềm nào đó?

Kết quả của công việc này được ghi nhận trong một báo cáo mang tên Configuration Status Accounting Report (CSAR). Báo cáo này thường làm rõ những điểm sau:

• Liệt kê tất cả baseline và CI thành phần hoặc có liên quan.

• Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi

• Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh hưởng (bởi sự thay đổi đó)

Việc báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.


(Audit là một thuật ngữ rất thường dùng, cho nhiều ngành nghề khác nhau, tuy nhiên trong lĩnh vực sofware, chúng tôi không tìm thấy từ tiếng Việt tương đương phản ánh đủ ý nghĩa, do vậy xin giữ nguyên thuật ngữ gốc, nó có ý nghĩa gần với “kiểm tra” và “xem xét”). Có 3 loại audit thường được thực hiện.

– CSAR Audit: Thường được làm sau mỗi lần một CSAR được tạo ra, việc kiểm tra bao gồm:

• Bảo đảm các baseline mới nhất được liệt kê trong CSAR

Bảo đảm tất cả CI tạo nên một baseline được liệt kê

Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng với các yêu cầu thay đổi để khẳng định rằng sự thay đổi trên CI là hợp lý.

– Physical configuration audit (PCA): nhằm mục đích khẳng định xem những gì khách hàng yêu cầu có được hiện thực hay không. Gồm 2 việc:

Kiểm tra vết để phản ánh tính 2 chiều (traceability) giữa yêu cầu khách hàng và việc hiện thực code trong dự án.

Xác định những gì sẽ được phân phối cho khách hàng (executable files, source code, tài liệu đi kèm…) có đáp ứng yêu cầu khách hàng hay không.

– Functional configuration audit (FCA): nhằm mục đích khẳng định những gì khách hàng yêu cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng hay không. Gồm:

Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra sản phẩm.

Quản lý release
(Release management)

Trong thực tế, có nhiếu định nghĩa khác nhau về khái niệm “release”. Về cơ bản, chúng ta có thể hiểu: Quá trình phát triển một phần mềm thường qua nhiều lần tích hợp, kết quả của mỗi lần tích hợp là một bản “build”, trong rất nhiều bản “build” đó, một số bản đáp ứng một số yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ được gởi cho khách hàng để kiểm tra hoặc đánh giá. Các bản build này được gọi là “release”; công việc tạo ra và phân phối các bản release được gọi là công việc “release”. Theo cách hiểu này, sản phẩm sau cùng cũng là một bản release, đôi khi được gọi là “final release”.

Trong quá trình release, việc quản lý đòi hỏi phải thực hiện các công việc sau:

• Baseline môi trường phát triển sản phẩm và các file, tài liệu (sẽ release)

• Thực hiện báo cáo CSAR (xem định nghĩa ở trên)

• Thực hiện các audit: PCA và FCA

• Đóng gói file và tài liệu sẽ release

Xác nhận đã nhận bản release từ khách hàng

Lưu trữ và chép dự phòng (Backup & archive)

Lưu trữ và chép dự phòng là một hoạt động của QLCH và là một trong những hoạt động quan trọng phải có của sản xuất phần mềm. Nó giúp khắc phục các trường hợp rủi ro bị mất mát dữ liệu do thao tác sai, virus, hoặc sự cố phần cứng/ phần mềm. Ở khía cạnh khác, nó hỗ trợ cho hoạt động version control (đã nói ở trên) trong trường hợp ta muốn sử dụng những version khác nhau.

Lưu trữ và chép dự phòng đòi hỏi toàn bộ sản phẩm và sản phẩm trung gian của dự án phải được định kỳ chép dự phòng trên những thiết bị hoặc những nơi khác một cách an toàn.

Và khi dự án kết thúc, các hoạt động sau cần phải thực hiện:

• Lưu trữ toàn bộ dữ liệu của dự án, tuân thủ quy trình lưu trữ đã được thiết lập (định nghĩa bởi dự án hoặc quy định ở cấp công ty).

• Lưu trữ hoặc huỷ bỏ các tài liệu ở dạng giấy.

• Dọn sạch dữ liệu hoặc thông tin của dự án vừa kết thúc, sau khi đã chép lưu trữ.

Vai trò của các thành viên trong dự án

Trong một dự án điển hình, thông thường có 4 (nhóm) chức năng sau (thường gọi tắt là role) tham gia thực hiện các hoạt động QLCH:

CM (Configuration manager)

• Thiết lập và bảo trì kho lưu trữ (repository) của dự án.

Phát triển và triển khai các quy trình thủ tục QLCH của dự án.

Thiết lập các baseline, ghi nhận chi tiết các thay đổi trên các baseline

Bảo đảm các baseline không bị thay đổi khi chưa được phê chuẩn.

Tổ chức và điều phối các cuộc họp của CCB

Trưởng dự án (Project manager):

• Giám sát các hoạt động QLCH.

Bảo đảm các yêu cầu cần thiết cho hoạt động QLCH. Ví dụ: số giờ thành viên dự án bỏ ra cho QLCH, công cụ hỗ trợ cho QLCH…

CCB (Configuration Control Board)

Bao gồm các thành viên trong dự án, và có chức năng như đã nói ở trên.

Các thành viên của dự án

Các thành viên của dự án, kể cả CM, PM và thành viên CCB, có trách nhiệm:

Tuân thủ tất cả các quy trình thủ tục của bản kế hoạch QLCH (CMP)

Tham gia vào nhóm CCB khi có yêu cầu

Lời Kết

Trên đây là vài nét hết sức cơ bản về QLCH – một lĩnh vực quan trọng và cơ bản trong phát triển và sản xuất phần mềm. Thực tế, mỗi hoạt động thành phần của QLCH đều có những chi tiết riêng phức tạp. Nếu có điều kiện, trong tương lai chúng tôi sẽ bàn sâu thêm từng hoạt động thành phần, đặc biệt ở khía cạnh kỹ thuật và áp dụng thực tế. Mọi đóng góp xin gởi về địa chỉ email: toanngo@cybersoft-vn.com.

Ngô Văn Toàn
Công ty Global CyberSoft Vietnam


Written by hoantv

February 23, 2014 at 4:13 am

Impact of poor quality?

leave a comment »

  1. Increased costs
  2. Decreased profits
  3. Low morale
  4. Low customer satisfaction
  5. Increased risk
  6. Rework
  7. Schedule delays


Written by hoantv

September 12, 2013 at 4:12 pm

PMIS: Project Management Information System

leave a comment »

1. It includes automated tools to allow you to know the status of your project at all times:

  • Scheduling software
  • Configuration management system
  • Shared workspaces for file storage or distribution
  • Work authorization software
  • Time-tracking software
  • Procurement management software
  • Plus repositories for historical software

2. It is a part of EEF.

Written by hoantv

September 9, 2013 at 4:09 pm

Estimate accuracy

leave a comment »

1. Rough Order of Magnitude (ROM) Estimate: made during project initiating, -25% –> +75% (depend on how much is known about the project)

2. Budget Estimate: made during project planning, -10% –> +25%.

3. Definitive Estimate: as the project progress, the estimate becomes more refined. Can be 2 cases:

– Case 1: -10% –> +10%.

– Case 2: -5% –> +10%.

Written by hoantv

September 9, 2013 at 3:59 pm

Posted in 07. Prj Cost Mgt

WBS is the foundation of the project!

leave a comment »


Written by hoantv

August 30, 2013 at 5:07 pm

Posted in 05. Prj Scope Mgt

Project Scope Statement

leave a comment »

Project Scope Statement included:

  1. Product scope
  2. Project scope
  3. Deliverables (for the product and the project)
  4. Acceptance criteria
  5. What is not part of the project
  6. Assumptions and constraints


Written by hoantv

August 30, 2013 at 3:58 pm

Posted in 05. Prj Scope Mgt