Chất lượng phần mềm. Quy trình kiểm soát chất lượng: Đầu vào. Hệ thống quản lý chất lượng

Chất lượng phần mềm là mức độ mà phần mềm có được sự kết hợp các thuộc tính cần thiết.

Chất lượng phần mềm là tập hợp các đặc tính của phần mềm liên quan đến khả năng đáp ứng các nhu cầu đã nêu và dự kiến.

Đặc tính chất lượng phần mềm

Chức năng(Chức năng) - được xác định bởi khả năng của phần mềm trong việc giải quyết các vấn đề tương ứng với nhu cầu được ghi lại và mong đợi của người dùng, trong các điều kiện sử dụng phần mềm nhất định. Những thứ kia. Đặc tính này đảm bảo rằng phần mềm hoạt động đúng cách và chính xác, có khả năng tương tác, đáp ứng các tiêu chuẩn ngành và được bảo vệ khỏi sự truy cập trái phép.

độ tin cậyĐộ tin cậy – khả năng phần mềm thực hiện các tác vụ được yêu cầu trong các điều kiện xác định trong một khoảng thời gian xác định hoặc một số hoạt động xác định. Các thuộc tính của đặc tính này là tính đầy đủ và toàn vẹn của toàn bộ hệ thống, khả năng phục hồi độc lập và chính xác sau các lỗi cũng như khả năng chịu lỗi.

Dễ sử dụng(Usability) - khả năng dễ dàng hiểu, nghiên cứu, sử dụng và tính hấp dẫn của phần mềm đối với người sử dụng.

Hiệu quả(Hiệu quả) – khả năng phần mềm cung cấp mức hiệu suất được yêu cầu phù hợp với nguồn lực, thời gian và các điều kiện được chỉ định khác được phân bổ.

Dễ bảo trì(Khả năng bảo trì) - sự dễ dàng mà phần mềm có thể được phân tích, kiểm tra, thay đổi để sửa lỗi, thực hiện các yêu cầu mới, tạo điều kiện thuận lợi cho việc bảo trì thêm và thích ứng với môi trường nhất định.

Tính di động(Tính di động) – mô tả phần mềm ở khía cạnh dễ dàng chuyển nó từ môi trường này (phần mềm/phần cứng) sang môi trường khác.

Mô hình chất lượng phần mềm

Phổ biến và được sử dụng nhiều nhất hiện nay mô hình chất lượng phần mềm đa cấp, được trình bày trong một bộ tiêu chuẩn ISO 9126. Nổi bật ở cấp cao nhất 6 đặc điểm chính của chất lượng phần mềm, mỗi thuộc tính được xác định bởi một tập hợp các thuộc tính có số liệu tương ứng để đánh giá tiếp theo ( xem hình. 1).

Hình 1 - Mô hình chất lượng phần mềm (ISO 9126-1)

29. Đặc tính chất lượng phần mềm (GOST).

GOST ISO 9126-93

Chất lượng của phần mềm có thể được đánh giá qua các đặc điểm sau:

4.1 Chức năng(Chức năng) Một tập hợp các thuộc tính liên quan đến bản chất của một tập hợp các chức năng và các thuộc tính cụ thể của chúng. Chức năng là những chức năng đáp ứng nhu cầu đã nêu hoặc dự kiến: Ghi chú

1 Tập hợp các thuộc tính này mô tả những gì phần mềm thực hiện để đáp ứng nhu cầu, trong khi các tập hợp khác chủ yếu mô tả thời điểm và cách thức phần mềm được thực hiện.

4.2 Độ tin cậyĐộ tin cậy Một tập hợp các thuộc tính liên quan đến khả năng phần mềm duy trì mức hiệu suất của nó trong các điều kiện xác định trong một khoảng thời gian xác định. Lưu ý 1 Không có sự hao mòn hoặc lão hóa của phần mềm. Hạn chế về độ tin cậy xảy ra do lỗi trong yêu cầu, thiết kế và triển khai. Lỗi do những lỗi này phụ thuộc vào cách sử dụng phần mềm và phiên bản phần mềm đã chọn trước đó. CHÚ THÍCH 2 ISO 8402 định nghĩa “độ tin cậy” là “khả năng của một phần tử thực hiện chức năng được yêu cầu”. Trong tiêu chuẩn này, chức năng chỉ là một trong những đặc điểm của chất lượng phần mềm. Do đó, định nghĩa về độ tin cậy được mở rộng sang “duy trì mức hiệu quả hoạt động” thay vì “thực hiện một chức năng được yêu cầu” (xem thêm 3.4).

4.3 Tính thực tiễn(Tính khả dụng) Một tập hợp các thuộc tính liên quan đến phạm vi công việc cần thiết để sử dụng và đánh giá riêng lẻ về việc sử dụng đó của một phạm vi người dùng cụ thể hoặc dự định. Lưu ý 1 “Người dùng” có thể được hiểu là phần lớn người dùng trực tiếp của phần mềm tương tác. Người dùng có thể bao gồm người vận hành, người dùng cuối và người dùng gián tiếp, những người

bị ảnh hưởng bởi phần mềm này hoặc điều đó phụ thuộc vào việc sử dụng nó. Tính thực tiễn phải được xem xét trong nhiều điều kiện vận hành khác nhau của người dùng có thể ảnh hưởng đến phần mềm, bao gồm cả việc chuẩn bị sử dụng và đánh giá kết quả.

2 Khả năng sử dụng, được định nghĩa trong tiêu chuẩn này là một tập hợp các thuộc tính cụ thể của sản phẩm phần mềm, khác với định nghĩa theo quan điểm ecgônômi, trong đó các đặc điểm khác như tính hiệu quả và tính không hiệu quả được coi là các thành phần của khả năng sử dụng.

4.4 Hiệu quả(Hiệu quả) Một tập hợp các thuộc tính liên quan đến mối quan hệ giữa mức chất lượng hoạt động của phần mềm và lượng tài nguyên được sử dụng trong các điều kiện cụ thể. LƯU Ý Tài nguyên có thể bao gồm các sản phẩm phần mềm, phần cứng, vật liệu khác (ví dụ: giấy in, đĩa mềm) và các dịch vụ của nhân viên vận hành, bảo trì hoặc bảo trì.

4.5 Khả năng bảo trì(Khả năng bảo trì) Một tập hợp các thuộc tính liên quan đến khối lượng công việc cần thiết để thực hiện các thay đổi (sửa đổi) cụ thể. LƯU Ý Thay đổi có thể bao gồm sửa chữa, cải tiến hoặc điều chỉnh phần mềm phù hợp với những thay đổi về môi trường, yêu cầu và điều kiện vận hành.

4.6 Tính cơ động(Tính di động) Một tập hợp các thuộc tính liên quan đến khả năng phần mềm được chuyển từ môi trường này sang môi trường khác. CHÚ THÍCH: Môi trường có thể bao gồm môi trường tổ chức, kỹ thuật hoặc phần mềm.

Phương pháp phát triển phần mềm

Sổ tay điện tử Karpovich E.E.

Giới thiệu. 1

1. Phần mềm là sản phẩm công nghiệp. 2

1.1 Các khái niệm cơ bản. 2

1.2. Đặc tính chất lượng phần mềm. 3

2. Vòng đời phần mềm. 5

2.1. Khái niệm vòng đời phần mềm. 5

2.2. Các quy trình vòng đời phần mềm. 6

2.3. Các mô hình vòng đời phần mềm. mười một

2.4. Các chiến lược thiết kế phần mềm. 15

3. Phương pháp phát triển phần mềm. 19

3.1 Cách tiếp cận mang tính cấu trúc để phát triển phần mềm. 19

3.2 Lập trình mô-đun. 22

3.3. Cách tiếp cận hướng đối tượng trong phát triển phần mềm. 31

3.3. Phương pháp lập trình trực quan. 33

4. Kiểm thử phần mềm. 34

4.1. Các quy định chung. 34

4.2. Mục tiêu và mục đích. Định nghĩa cơ bản. 34

4.3. Tổ chức quy trình kiểm thử phần mềm 35

4.4. Chiến lược kiểm thử phần mềm. 36

4.5. Các cấp độ kiểm thử phần mềm 38

5. Tài liệu của phần mềm. 39

5.1. Các quy định chung. 39

5.2. Chương trình và phương pháp thử nghiệm. 39

5.3. Mô tả chương trình.. 40

5.4. Ghi chú giải thích. 41

5.5. Văn bản chương trình.. 42

5.6. Mô tả ứng dụng. 42

5.7. Hướng dẫn lập trình viên hệ thống. 42

5.8. Hướng dẫn lập trình viên. 43

5.9. Hướng dẫn sử dụng. 43

Văn học. 44

Giới thiệu

Phần mềm hệ thống máy tính (CS) ngày càng trở nên quan trọng, phức tạp, nguy hiểm và ngày càng khó phát triển, nhưng đồng thời phần mềm không ngừng được đơn giản hóa, giảm kích thước, dễ quản lý và dễ phát triển hơn .

Một mặt, yêu cầu về phần mềm ngày càng tăng do sự cải tiến và phức tạp của hệ điều hành, phần cứng và giao diện người dùng cũng như nhu cầu giới thiệu các công nghệ thông tin hiện đại, chủ yếu là mạng. Về vấn đề này, cấu trúc bên trong của các chương trình ngày càng trở nên phức tạp hơn và yêu cầu về độ tin cậy của chúng ngày càng tăng.

Mặt khác, kinh nghiệm phát triển phần mềm được tích lũy và khái quát hóa, đồng thời ngày càng xuất hiện nhiều phương pháp và công cụ linh hoạt và mạnh mẽ hỗ trợ tất cả các giai đoạn phát triển phần mềm. Phương pháp lập trình trực quan đang được phát triển và ngôn ngữ lập trình đang được cải thiện. Những cải tiến về phần cứng giúp tăng tốc quá trình biên dịch và thường giúp bạn không phải lo lắng về hiệu quả của các chương trình được tạo.

Mục đích của môn học “Phương pháp phát triển phần mềm” là dạy cho sinh viên những nguyên tắc cơ bản của thiết kế phần mềm, giúp họ làm quen với các khái niệm, phương pháp phát triển, thử nghiệm và ghi lại phần mềm.

Phần mềm là một sản phẩm công nghiệp

Các khái niệm cơ bản

Người ta thường phân biệt bảy loại hỗ trợ cho hệ thống máy tính:

· toán học;

· ngôn ngữ học;

· thông tin;

· phần mềm;

· kỹ thuật;

· có phương pháp;

· tổ chức.

Trong tất cả các loại phần mềm, phần mềm chiếm một vị trí đặc biệt, vì phần mềm chiếm phần lớn chi phí trang bị và vận hành máy bay. Hãy xác định các khái niệm cơ bản như chương trình, gói phần mềm, hệ thống phần mềm, sản phẩm phần mềm và phần mềm.

Dưới chương trình chúng tôi sẽ hiểu:

1) một bộ mã và dữ liệu phù hợp để bộ xử lý thực thi (chương trình có thể thực thi);

2) một thành phần độc lập có kích thước tương đối nhỏ, được thiết kế để giải quyết vấn đề cục bộ (chương trình là thành phần hệ thống).

Gói phần mềm hoặc hệ thống phần mềm là tập hợp các chương trình phối hợp dưới sự kiểm soát chung, được thiết kế để giải quyết một vấn đề phức tạp hoặc một số vấn đề có liên quan với nhau.

Một gói phần mềm đã vượt qua các bài kiểm tra, hoàn toàn sẵn sàng để bán (giao hàng) và được trang bị tất cả các tài liệu cần thiết, được gọi là sản phẩm phần mềm (sản phẩm) hoặc phần mềm.

Phần mềm- khái niệm chung nhất mà theo đó các chương trình, hệ thống phần mềm hoặc sản phẩm được hiểu chung hoặc riêng lẻ, tùy thuộc vào ngữ cảnh sử dụng thuật ngữ này.

Chúng tôi sẽ có điều kiện chia các sản phẩm phần mềm thành nhỏ, vừa và lớn. Khối lượng văn bản nguồn của các chương trình nhỏ là vài trăm toán tử ngôn ngữ cấp cao, trung bình - lên tới hàng chục nghìn và lớn - lên tới một triệu.

Trong nhiều trường hợp, các chương trình được tạo thành một bản sao duy nhất để giải quyết các vấn đề nghiên cứu cụ thể, tăng tốc độ tính toán, mô phỏng các quy trình, v.v. Những chương trình như vậy không được sử dụng rộng rãi và chỉ dành cho những người phát triển chúng. Chúng là đối tượng của sự sáng tạo khoa học kỹ thuật và chỉ trong những trường hợp đặc biệt mới trở thành sản phẩm công nghiệp.

Một loại chương trình hoàn toàn khác là phần mềm chính thức, hiện được phân loại là sản phẩm dành cho mục đích công nghiệp. Với khả năng này, sản phẩm phần mềm là lực lượng sản xuất trực tiếp và không khác biệt với bất kỳ sản phẩm công nghiệp nào khác.

Tạo ra một sản phẩm phần mềm tốt là một công việc tốn rất nhiều công sức, mà giải pháp cho nó, theo quy luật, nằm ngoài khả năng của một người. Các lập trình viên solo (“hacker”) có thể có thiên tài trong việc nhanh chóng thuật toán và mã hóa các vấn đề không hề tầm thường, tạo ra các phương pháp và ý tưởng lập trình mới, đồng thời đạt được danh tiếng đáng kể. Tuy nhiên, họ không thể một mình giải quyết toàn bộ các vấn đề trong quá trình phát triển các sản phẩm phần mềm vừa và lớn trong khung thời gian có thể chấp nhận được.

Vì vậy, hiện tại, bất kỳ sản phẩm quan trọng nào đều được tạo ra bởi các nhóm lập trình viên. Trong những nhóm như vậy, lập trình viên-nhà phát triển coi trọng những phẩm chất như khả năng đọc viết, kỷ luật, độ tin cậy và kỹ năng giao tiếp. Kiến thức có nghĩa là kiến ​​thức và hiểu biết về các phương pháp và công cụ phát triển phần mềm tiên tiến, mục đích và tính năng của chúng cũng như khả năng áp dụng kiến ​​thức này vào thực tế.

Đặc tính chất lượng phần mềm

Tập hợp các thuộc tính phần mềm tạo nên chất lượng phần mềm thỏa đáng cho người dùng tùy thuộc vào các điều kiện và tính chất hoạt động của phần mềm này, tức là. từ vị trí mà chất lượng của phần mềm này nên được xem xét. Vì vậy, khi mô tả chất lượng phần mềm, trước hết tiêu chí lựa chọn các thuộc tính phần mềm cần có phải được xác định rõ ràng. Hiện nay tiêu chí chất lượng phần mềm(tiêu chí chất lượng phần mềm) được coi là:

Chức năng;

Độ tin cậy;

Dễ sử dụng;

Hiệu quả;

Khả năng bảo trì;

Tính di động.

Chức năng là khả năng phần mềm thực hiện một tập hợp các chức năng đáp ứng nhu cầu cụ thể hoặc ngụ ý của người dùng. Tập hợp các chức năng được chỉ định được xác định trong phần mô tả bên ngoài của phần mềm.

Độ tin cậy của phần mềm là khả năng thực hiện một số chức năng nhất định mà không gặp lỗi trong các điều kiện nhất định trong một khoảng thời gian nhất định với xác suất đủ cao. Trong trường hợp này, lỗi phần mềm được hiểu là biểu hiện của lỗi trong phần mềm đó. Do đó, phần mềm đáng tin cậy không loại trừ sự hiện diện của các lỗi trong đó - điều quan trọng là những lỗi này khá hiếm khi xuất hiện trong quá trình sử dụng thực tế phần mềm này trong các điều kiện nhất định. Bạn có thể xác minh rằng phần mềm có thuộc tính này bằng cách kiểm tra nó thông qua quá trình kiểm tra cũng như trong quá trình sử dụng thực tế. Như vậy, trên thực tế, chúng ta chỉ có thể phát triển phần mềm đáng tin cậy chứ không thể phát triển phần mềm chính xác.

Khi đánh giá mức độ tin cậy của phần mềm, hậu quả của từng lỗi cũng cần được tính đến. Một số lỗi trong phần mềm có thể chỉ gây ra một số bất tiện khi sử dụng, trong khi một số lỗi khác có thể gây ra hậu quả thảm khốc, chẳng hạn như đe dọa tính mạng con người. Do đó, để đánh giá độ tin cậy của phần mềm, đôi khi các chỉ số bổ sung được sử dụng để tính đến chi phí (tác hại) đối với người dùng sau mỗi lần lỗi.

Dễ sử dụng là đặc điểm của phần mềm cho phép giảm thiểu nỗ lực của người dùng trong việc chuẩn bị dữ liệu ban đầu, sử dụng phần mềm và đánh giá kết quả thu được, cũng như gợi lên cảm xúc tích cực của người dùng cụ thể hoặc ngụ ý.

Hiệu quả là tỷ lệ giữa mức độ dịch vụ do phần mềm cung cấp cho người dùng trong các điều kiện nhất định với lượng tài nguyên được sử dụng.

Khả năng bảo trì là đặc điểm của phần mềm giúp giảm thiểu nỗ lực cần thiết để thực hiện các thay đổi nhằm sửa lỗi và sửa đổi phần mềm để đáp ứng nhu cầu thay đổi của người dùng.

Tính di động là khả năng phần mềm được chuyển từ môi trường (môi trường) này sang môi trường (môi trường) khác, đặc biệt là từ máy tính này sang máy tính khác.

Chức năng và độ tin cậy là tiêu chí chất lượng bắt buộc Phần mềm và việc đảm bảo độ tin cậy sẽ là chủ đề xuyên suốt tất cả các giai đoạn và quy trình phát triển phần mềm. Các tiêu chí còn lại được sử dụng tùy theo nhu cầu của người dùng phù hợp với yêu cầu của phần mềm. Để xác định chất lượng phần mềm cho từng tiêu chí, một tập hợp tiêu chuẩn gồm các thuộc tính phần mềm khá đơn giản được các nhà phát triển giải thích rõ ràng sẽ được sử dụng. Chúng ta sẽ gọi những thuộc tính đó chất lượng phần mềm nguyên thủy. Một số nguyên thủy có thể được sử dụng theo một số tiêu chí. Dưới đây là sự phụ thuộc của tiêu chí chất lượng vào chất lượng nguyên thủy của phần mềm.

Chức năng: đầy đủ.

Độ tin cậy: đầy đủ, chính xác, tự chủ, ổn định, bảo mật.

Dễ sử dụng: Tài liệu P, nội dung thông tin (chỉ liên quan đến tài liệu ứng dụng), kỹ năng giao tiếp, tính ổn định, bảo mật.

Hiệu quả: hiệu quả về thời gian, hiệu quả về tài nguyên (bộ nhớ), hiệu quả của thiết bị.

Khả năng bảo trì. Có nhiều nguyên thủy chất lượng khác nhau liên quan đến tiêu chí này. Tuy nhiên, chúng có thể được chia thành hai nhóm, nêu bật hai tiêu chí phụ về chất lượng: khả năng nghiên cứu và khả năng sửa đổi.

Khả năng học được là đặc điểm của phần mềm giúp giảm thiểu nỗ lực nghiên cứu và hiểu các chương trình và tài liệu phần mềm.

Khả năng sửa đổi là các đặc tính của phần mềm cho phép tự động điều chỉnh các điều kiện sử dụng phần mềm hoặc đơn giản hóa việc đưa các thay đổi và sửa đổi cần thiết vào phần mềm theo cách thủ công.

Khả năng học hỏi: Tài liệu C, tính thông tin (ở đây liên quan đến tài liệu hỗ trợ), tính dễ hiểu, tính cấu trúc, tính dễ đọc.

Khả năng sửa đổi: khả năng mở rộng, khả năng sửa đổi (theo nghĩa hẹp, như một nguyên thủy về chất lượng), tính cấu trúc, tính mô đun.

Tính di động: tính độc lập của thiết bị, tính tự chủ, cấu trúc, tính mô đun.

Dưới đây là các định nghĩa về chất lượng phần mềm nguyên thủy được sử dụng.

Tính hoàn chỉnh là thuộc tính đặc trưng cho mức độ mà phần mềm sở hữu tất cả các phần và tính năng cần thiết để thực hiện các chức năng rõ ràng và tiềm ẩn của nó.

Độ chính xác là thước đo đặc trưng cho khả năng chấp nhận được mức độ sai sót trong kết quả do các chương trình phần mềm tạo ra theo quan điểm mục đích sử dụng của chúng.

Tính độc lập là đặc tính đặc trưng cho khả năng của phần mềm thực hiện các chức năng được quy định mà không cần sự trợ giúp hoặc hỗ trợ của các thành phần phần mềm khác.

Tính mạnh mẽ là đặc tính đặc trưng cho khả năng phần mềm tiếp tục hoạt động chính xác mặc dù dữ liệu đầu vào không chính xác (có lỗi).

Khả năng phòng thủ là đặc tính đặc trưng cho khả năng phần mềm chống lại các hành động phá hoại có chủ ý hoặc vô ý của người dùng.

Tài liệu P (u. tài liệu) là một thuộc tính đặc trưng cho sự hiện diện, tính đầy đủ, dễ hiểu, khả năng truy cập và khả năng hiển thị của tài liệu giáo dục, hướng dẫn và tham khảo cần thiết cho việc sử dụng phần mềm.

Trách nhiệm giải trình là đặc tính mô tả sự hiện diện của thông tin cần và đủ trong phần mềm để hiểu mục đích của phần mềm, các giả định được chấp nhận, các hạn chế hiện có, dữ liệu đầu vào và kết quả hoạt động của từng thành phần riêng lẻ, cũng như trạng thái hiện tại của các chương trình trong phần mềm. quá trình hoạt động của họ.

Khả năng giao tiếp là đặc tính mô tả mức độ mà phần mềm tạo điều kiện thuận lợi cho việc đặc tả hoặc mô tả dữ liệu đầu vào và khả năng tạo ra thông tin hữu ích ở dạng khá đơn giản và có nội dung dễ hiểu.

Hiệu quả về thời gian là thước đo đặc trưng cho khả năng phần mềm thực hiện các chức năng được giao cho nó trong một khoảng thời gian nhất định.

Hiệu quả tài nguyên là thước đo đặc trưng cho khả năng phần mềm thực hiện các chức năng được giao cho nó dưới những hạn chế nhất định đối với tài nguyên được sử dụng (bộ nhớ được sử dụng).

Hiệu suất của thiết bị là thước đo đặc trưng cho hiệu quả của việc sử dụng các thiết bị của máy để giải quyết một nhiệm vụ nhất định.

Tài liệu C là một thuộc tính đặc trưng theo quan điểm về tính sẵn có của tài liệu phản ánh các yêu cầu đối với phần mềm và kết quả của các giai đoạn phát triển khác nhau của phần mềm này, bao gồm các khả năng, hạn chế và các tính năng khác của phần mềm, cũng như các tính năng của chúng. sự biện minh.

Tính dễ hiểu là đặc tính mô tả mức độ mà phần mềm cho phép người nghiên cứu nó hiểu mục đích của nó, các giả định và hạn chế được đưa ra, dữ liệu đầu vào và đầu ra của các chương trình, văn bản của các chương trình này và trạng thái triển khai chúng.

Tính cấu trúc là một thuộc tính đặc trưng cho các chương trình phần mềm theo quan điểm tổ chức các phần được kết nối với nhau của chúng thành một tổng thể duy nhất theo một cách nhất định (ví dụ, theo các nguyên tắc lập trình có cấu trúc).

Khả năng đọc là một thuộc tính đặc trưng cho sự dễ dàng nhận biết văn bản của chương trình phần mềm (thụt lề, phân mảnh, định dạng).

Khả năng mở rộng là thuộc tính đặc trưng cho khả năng phần mềm sử dụng nhiều bộ nhớ hơn để lưu trữ dữ liệu hoặc mở rộng chức năng của từng thành phần riêng lẻ.

Khả năng sửa đổi là thước đo đặc trưng của phần mềm về tính dễ dàng thực hiện các thay đổi và sửa đổi cần thiết ở tất cả các giai đoạn và giai đoạn của vòng đời phần mềm.

Tính mô-đun là một đặc tính đặc trưng cho phần mềm về mặt tổ chức các chương trình của nó từ các thành phần riêng biệt mà việc thay đổi một trong số chúng có tác động tối thiểu đến các thành phần khác.

Tính độc lập của thiết bị là đặc tính đặc trưng cho khả năng phần mềm hoạt động trên nhiều loại phần cứng (nhiều loại, nhãn hiệu, kiểu máy tính khác nhau).

Sự phát triển của một công cụ phần mềm kết thúc bằng việc chứng nhận nó. Chứng nhận phần mềm - đây là một xác nhận có thẩm quyền về chất lượng của nó. Theo quy định, một ủy ban gồm các chuyên gia được thành lập để chứng nhận. Ủy ban này tiến hành các thử nghiệm chấp nhận phần mềm để có được thông tin cần thiết nhằm đánh giá chất lượng của nó. Trong trường hợp này, chỉ các tiêu chí chất lượng đã thiết lập và chất lượng ban đầu mới được đánh giá.

Phương pháp luận Các ngành liên quan

Chất lượng phần mềm- đặc điểm của phần mềm (phần mềm) là mức độ tuân thủ các yêu cầu của nó. Đồng thời, các yêu cầu có thể được giải thích khá rộng rãi, điều này dẫn đến một số định nghĩa độc lập về khái niệm này. Định nghĩa được sử dụng phổ biến nhất là ISO 9001, theo đó chất lượng là “mức độ mà các đặc tính vốn có đáp ứng được yêu cầu”.

Chất lượng mã nguồn

Chất lượng mã có thể được xác định theo nhiều tiêu chí khác nhau. Một số trong số chúng chỉ có ý nghĩa từ góc độ con người. Ví dụ: cách định dạng văn bản của chương trình hoàn toàn không quan trọng đối với máy tính nhưng có thể có tác động nghiêm trọng đến việc bảo trì sau này. Nhiều tiêu chuẩn mã hóa hiện có, xác định các quy ước dành riêng cho ngôn ngữ và đặt ra một số quy tắc nhằm cải thiện khả năng đọc mã, nhằm tạo điều kiện thuận lợi cho việc bảo trì phần mềm trong tương lai, bao gồm cả việc gỡ lỗi và cập nhật. Có những tiêu chí khác xác định xem mã có được viết “tốt” hay không, chẳng hạn như tính cấu trúc - mức độ mà mã được chia một cách hợp lý thành một số khối có thể quản lý được.

• Khả năng đọc mã
• Dễ hỗ trợ, kiểm tra, gỡ lỗi, sửa lỗi, sửa đổi và tính di động
• Độ phức tạp mã thấp
• Sử dụng tài nguyên thấp: bộ nhớ và thời gian CPU
• Xử lý ngoại lệ đúng
• Một số cảnh báo trong quá trình biên dịch và liên kết

Các phương pháp cải thiện chất lượng mã: tái cấu trúc.

Yếu tố chất lượng

Yếu tố chất lượng phần mềm là một yêu cầu phi chức năng đối với một chương trình thường không được mô tả trong hợp đồng với khách hàng nhưng tuy nhiên vẫn là một yêu cầu mong muốn nhằm cải thiện chất lượng của chương trình.

Một số yếu tố chất lượng là:

Tính dễ hiểu Mục đích của phần mềm phải rõ ràng từ chính chương trình và tài liệu. Tính đầy đủ Tất cả các phần cần thiết của chương trình phải được trình bày và thực hiện đầy đủ. ngắn gọn Thiếu thông tin trùng lặp, không cần thiết. Các phần mã lặp lại phải được chuyển đổi thành một lệnh gọi thủ tục chung. Tài liệu cũng vậy. Tính di động Dễ dàng thích ứng một chương trình với môi trường khác: kiến ​​trúc, nền tảng, hệ điều hành khác hoặc phiên bản của nó. Tính nhất quán Các quy ước, định dạng và ký hiệu giống nhau phải được sử dụng trong suốt chương trình và tài liệu. Khả năng bảo trì Khó khăn như thế nào khi thay đổi một chương trình để đáp ứng các yêu cầu mới. Yêu cầu này cũng quy định rằng chương trình phải được ghi chép đầy đủ, không quá khó hiểu và có chỗ để phát triển trong việc sử dụng tài nguyên (bộ nhớ, bộ xử lý). khả năng kiểm tra Liệu chương trình có cho phép bạn kiểm tra các đặc điểm chấp nhận hay không, liệu khả năng đo lường hiệu suất có được hỗ trợ hay không. dễ sử dụng Sự đơn giản và dễ sử dụng của chương trình. Yêu cầu này áp dụng chủ yếu cho giao diện người dùng. độ tin cậy sự vắng mặt của các lỗi và sai sót trong hoạt động của chương trình, cũng như sự dễ dàng sửa chữa các khiếm khuyết và lỗi: hiệu quả có cấu trúc Cách chương trình xử lý tài nguyên (bộ nhớ, bộ xử lý) một cách hợp lý khi thực hiện các tác vụ của nó. sự an toàn

Từ quan điểm của người dùng

Ngoài góc độ kỹ thuật về chất lượng phần mềm, còn có đánh giá chất lượng từ góc độ người dùng. Thuật ngữ "khả năng sử dụng" đôi khi được sử dụng cho khía cạnh chất lượng này. Rất khó để có được đánh giá về khả năng sử dụng cho một sản phẩm phần mềm nhất định. Các vấn đề quan trọng nhất ảnh hưởng đến việc đánh giá:

• Giao diện người dùng có trực quan không?
• Việc thực hiện các thao tác đơn giản, thường xuyên có dễ dàng như thế nào?
• Các thao tác phức tạp có thể thực hiện dễ dàng như thế nào?
• Chương trình có đưa ra thông báo lỗi rõ ràng không?
• Chương trình có luôn hoạt động như mong đợi không?
• Có tài liệu và mức độ đầy đủ như thế nào?
• Giao diện người dùng có tự mô tả/tự ghi lại tài liệu không?
• Độ trễ phản hồi của chương trình có luôn được chấp nhận không?

Xem thêm

Liên kết

Nổi tiếng số liệu
Quá trình
Các khái niệm
Hướng
Người mẫu phát triển
Người mẫu khác
Khác

Quỹ Wikimedia. 2010.

• Nlite
• Nửa đêm ở nghĩa trang (phim)

Xem “Chất lượng phần mềm” là gì trong các từ điển khác:

Chất lượng phần mềm- khả năng của một sản phẩm phần mềm xác nhận giá trị sử dụng đặc tả của nó, với điều kiện là đặc tả đó tập trung vào các đặc tính mà người dùng mong muốn. Xem thêm: Chất lượng phần mềm Phần mềm Tài chính… … Từ điển tài chính

Phát triển phần mềm- Khi Grace Hopper đang làm việc trên máy tính Harvard Mark II tại Đại học Harvard, các đồng nghiệp của cô đã phát hiện ra con sâu bướm này bị mắc kẹt trong rơle và do đó cản trở hoạt động của thiết bị, sau đó cô lưu ý rằng họ đang "gỡ lỗi" hệ thống.... .. Wikipedia

Kiểm thử phần mềm- Phát triển phần mềm Quy trình phát triển phần mềm Các bước xử lý Phân tích Thiết kế Tài liệu lập trình ... Wikipedia

Nhà sản xuất phần mềm- Phát triển phần mềm (tức là công nghệ phần mềm, phát triển phần mềm) là một loại hoạt động (nghề nghiệp) và một quy trình nhằm tạo ra và duy trì chức năng, chất lượng và độ tin cậy của phần mềm sử dụng ... Wikipedia

Khủng hoảng phần mềm- "Khủng hoảng phần mềm" là thuật ngữ từng được sử dụng trong khoa học máy tính để mô tả hậu quả của sự tăng trưởng nhanh chóng về sức mạnh tính toán của máy tính và mức độ phức tạp của các vấn đề có thể được giải quyết với sự trợ giúp của chúng. Về bản chất, đây là... ... Wikipedia

Kỹ thuật phần mềm- Airbus A 380 mới sử dụng khá nhiều phần mềm để tạo ra buồng lái hiện đại trên máy bay. Phương pháp công nghệ phần mềm giúp tạo ra phần mềm máy bay được mô tả bằng hàng triệu dòng... Wikipedia

Tính di động của phần mềm- khả năng phần mềm chạy trên các nền tảng phần cứng khác nhau hoặc dưới các hệ điều hành khác nhau. Từ đồng nghĩa: Tính di động của phần mềm Xem thêm: Chất lượng phần mềm Hệ thống mở... ... Từ điển tài chính

Tính thân thiện với người dùng của phần mềm- đặc điểm của sản phẩm phần mềm: cho phép giảm thiểu công sức của người dùng trong việc chuẩn bị dữ liệu ban đầu, sử dụng sản phẩm phần mềm và đánh giá kết quả thu được, đồng thời cho phép gợi lên những cảm xúc tích cực... ... Từ điển tài chính

Khả năng bảo trì phần mềm- đặc điểm của sản phẩm phần mềm cho phép giảm thiểu nỗ lực thực hiện các thay đổi đối với sản phẩm đó: loại bỏ lỗi; hoặc để sửa đổi để đáp ứng nhu cầu thay đổi của người dùng. Xem thêm: Chất lượng phần mềm.... Từ điển tài chính

Chức năng phần mềm- khả năng của một sản phẩm phần mềm để thực hiện một tập hợp các chức năng: được xác định trong mô tả bên ngoài của nó; và đáp ứng nhu cầu cụ thể hoặc tiềm ẩn của người dùng. Từ đồng nghĩa: Khả năng tương tác của phần mềm Xem thêm: Chất lượng... ... Từ điển tài chính

Sách

• Code Perfect: Hướng dẫn thực hành về phát triển phần mềm của S. McConnell Trong hơn 10 năm, ấn bản đầu tiên của cuốn sách này được coi là một trong những hướng dẫn lập trình thực tế tốt nhất. Bây giờ cuốn sách này đã được cập nhật hoàn toàn có tính đến các xu hướng và công nghệ hiện đại...

Vấn đề chính trong quản lý chất lượng là định nghĩa về chất lượng quá mơ hồ và mơ hồ. Điều này là do thuật ngữ chất lượng thường bị hiểu lầm. Sự nhầm lẫn này có thể do nhiều nguyên nhân...

Hãy thử trả lời các câu hỏi:

• Quan điểm phổ biến về chất lượng
• kết luận

Chất lượng phần mềm là gì?

Trong tập đầu tiên, chúng ta sẽ cố gắng định nghĩa các thuật ngữ chất lượng và chất lượng phần mềm.

Vấn đề chính trong quản lý chất lượng là định nghĩa về chất lượng quá mơ hồ và mơ hồ. Điều này là do thuật ngữ chất lượng thường bị hiểu lầm. Sự nhầm lẫn này có thể là do một số lý do.

Đầu tiên, chất lượng không phải là một ý tưởng hay khái niệm đơn lẻ mà là khái niệm đa chiều, đa dạng.

Thứ hai, đối với bất kỳ khái niệm và định nghĩa nào cũng có nhiều mức độ trừu tượng, chẳng hạn khi người ta nói về chất lượng, một bộ phận hiểu nó theo nghĩa rất rộng và mơ hồ, trong khi bộ phận khác có thể đề cập đến một định nghĩa và ý nghĩa cụ thể.

Ngày thứ ba, thuật ngữ chất lượng là một phần không thể thiếu trong giao tiếp hàng ngày của chúng ta, nhưng cách sử dụng thông thường và chuyên nghiệp có thể hoàn toàn khác nhau.

Quan điểm phổ biến về chất lượng

Quan điểm được chấp nhận rộng rãi về chất lượng là nó là thứ gì đó vô hình và “vô hình” - có thể có những tranh luận và thảo luận về nó, có thể bị chỉ trích và khen ngợi, nhưng không thể cân nhắc và đo lường chất lượng. Những cách diễn đạt như “chất lượng tốt” và “chất lượng kém” là một ví dụ rõ ràng về cách mọi người nói về điều gì đó mơ hồ đối với họ, điều gì đó mà họ không thể mô tả và định nghĩa rõ ràng. Quan điểm này phản ánh thực tế là mọi người nhận thức và diễn giải chất lượng một cách khác nhau. Người ta hiểu rằng chất lượng không thể được kiểm soát và quản lý, và càng không thể định lượng được. Quan điểm này trái ngược hẳn với cách tiếp cận chuyên nghiệp về quản lý chất lượng - chất lượng là một đại lượng được xác định rõ ràng, có thể đo lường và kiểm soát, có thể quản lý và cải thiện.

Một quan điểm phổ biến khác cho rằng chất lượng gắn bó chặt chẽ với sự sang trọng, đẳng cấp và hương vị tinh tế. Một sản phẩm đắt tiền, được cân nhắc kỹ lưỡng và phức tạp hơn về mặt kỹ thuật được coi là sự đảm bảo cho chất lượng cao nhất so với các sản phẩm tương tự rẻ hơn. Theo logic này, Cadillac là một chiếc xe chất lượng, nhưng Chevrolet thì không, mặc dù độ tin cậy và số lần hỏng hóc của nó; hoặc hệ thống HI-FI là hệ thống chất lượng cao, nhưng đài thông thường thì không. Theo cách tiếp cận này, chất lượng bị giới hạn ở một loại sản phẩm đắt tiền nhất định có chức năng phức tạp và sản phẩm đẳng cấp. Nói một cách đơn giản, một sản phẩm rẻ tiền khó có thể được xếp vào loại sản phẩm chất lượng.

Cách tiếp cận chuyên nghiệp về chất lượng

Thật không may, quan điểm mơ hồ và mơ hồ như vậy không thể được sử dụng để cải thiện quy trình phát triển phần mềm. Vì vậy, cần phải đưa ra một định nghĩa rõ ràng và khả thi. Năm 1979, Crosby định nghĩa chất lượng là “sự phù hợp với yêu cầu”, còn Juran và Gryna vào năm 1970 định nghĩa chất lượng là “sự phù hợp để sử dụng”. Hai định nghĩa này có liên quan chặt chẽ và hoàn toàn phù hợp, như chúng ta sẽ thấy sau.

"Tuân thủ các yêu cầu" giả định rằng các yêu cầu phải được xác định rõ ràng để chúng không thể bị hiểu lầm hoặc giải thích sai. Sau đó, trong giai đoạn phát triển, việc đo lường thường xuyên sản phẩm đã phát triển sẽ được thực hiện để xác định việc tuân thủ các yêu cầu. Bất kỳ sự khác biệt nào đều được coi là khiếm khuyết - thiếu chất lượng. Ví dụ: thông số kỹ thuật cho một kiểu radio nhất định có thể yêu cầu khả năng nhận một tần số sóng vô tuyến nhất định ở khoảng cách hơn 30 km tính từ nguồn phát sóng. Trường hợp đài phát thanh không đáp ứng được yêu cầu này là không đảm bảo yêu cầu về chất lượng và bị coi là không sử dụng được, kém chất lượng. Dựa trên những nguyên tắc tương tự, nếu một chiếc Cadillac đáp ứng được tất cả các yêu cầu đối với xe Cadillac thì đó là một chiếc xe chất lượng. Nếu một chiếc Chevrolet đáp ứng được tất cả những yêu cầu của xe Chevrolet thì đó cũng là một chiếc xe chất lượng. Hai chiếc xe có thể hoàn toàn khác nhau về kiểu dáng, tốc độ và tính kinh tế, nhưng nếu so sánh với tiêu chuẩn tiêu chuẩn của chúng thì cả hai đều là những chiếc xe chất lượng.

Sự định nghĩa "Thể dục để sử dụng" tính đến các yêu cầu và mong đợi của người dùng cuối đối với sản phẩm, những người mong đợi sản phẩm hoặc dịch vụ được cung cấp sẽ thuận tiện cho nhu cầu của họ. Tuy nhiên, những người dùng khác nhau có thể sử dụng sản phẩm theo những cách khác nhau, điều đó có nghĩa là sản phẩm phải có nhiều trường hợp sử dụng khác nhau nhất có thể. Theo định nghĩa của Juran, mỗi trường hợp sử dụng là một đặc tính chất lượng và tất cả chúng có thể được phân loại thành các loại dưới dạng tham số khả năng sử dụng.

Hai định nghĩa về chất lượng này (“sự phù hợp” và “sự phù hợp với mục đích”) về cơ bản là giống nhau. Sự khác biệt là “sự phù hợp để sử dụng” cho thấy các yêu cầu và mong đợi của khách hàng đóng một vai trò quan trọng. Vai trò của khách hàng liên quan đến chất lượng không bao giờ có thể được đánh giá quá cao. Theo quan điểm của khách hàng, chất lượng của sản phẩm họ mua bao gồm nhiều yếu tố khác nhau, chẳng hạn như giá cả, hiệu suất, độ tin cậy, v.v..

Chỉ có khách hàng mới có thể cho bạn biết về chất lượng vì đây là thứ duy nhất họ thực sự mua. Khách hàng không mua sản phẩm. Anh ta mua sự đảm bảo của bạn rằng mọi mong đợi của anh ta về sản phẩm sẽ được đáp ứng.

Guaspari “Tôi Biết Khi Tôi Nhìn Thấy Nó”

kết luận

Hãy thử xác định lại chất lượng từ quan điểm của khách hàng hoặc người sử dụng sản phẩm.

Chất lượng là sự phù hợp cho việc sử dụng. Sản phẩm này có làm được điều tôi cần không, có giúp công việc của tôi dễ dàng hơn không, tôi có thể sử dụng theo cách phù hợp với mình không.

Bây giờ hãy nhìn vào quan điểm của nhà phát triển.

Chất lượng là sự tuân thủ các yêu cầu đã được xác định và thu thập Sản phẩm có làm được mọi điều nó nói không?

Vấn đề là các yêu cầu được chỉ định và thu thập thường chỉ là một phần trong tất cả các yêu cầu và mong đợi thực tế của khách hàng. Đâu là định nghĩa chính xác về chất lượng?

Chất lượng là sự tuân thủ các yêu cầu thực tế, rõ ràng và tiềm ẩn. Thông thường, các yêu cầu tiềm ẩn quá rõ ràng đối với khách hàng hoặc người dùng đến mức họ thậm chí không cho rằng các nhà phát triển không biết đến chúng. Ví dụ: hãy quay lại với ô tô của chúng ta - khách hàng có thể mô tả chi tiết các yêu cầu về thiết kế, thông số động cơ, thiết kế nội thất, màu sắc thân xe, nhưng không nơi nào chỉ ra rằng lốp phải tròn và kính chắn gió phải trong suốt.

Khách hàng sẽ chỉ hài lòng khi sản phẩm mua đáp ứng đầy đủ các yêu cầu thực tế và quan trọng của mình, dù có được chỉ định hay không.

Chất lượng phần mềm là mối quan tâm thường xuyên của công nghệ phần mềm và được thảo luận trong nhiều lĩnh vực kiến ​​thức.

• Phil Crosby: Chất lượng là sự phù hợp với yêu cầu của người sử dụng.
• Watts Humphrey: Chất lượng là sự đạt được mức độ sử dụng tuyệt vời.
• Công ty IBM:đã đặt ra cụm từ “chất lượng theo định hướng thị trường”.
• Tiêu chí Baldrige:“chất lượng hướng đến khách hàng”.
• Hệ thống quản lý chất lượng ISO 9001: Chất lượng là mức độ mà các đặc tính vốn có đáp ứng được yêu cầu.

Chất lượng chấp nhận được- đây là mức độ hoàn thiện mong muốn của sản phẩm (dịch vụ) được tạo ra, có khả năng làm hài lòng người dùng và có thể đạt được trong giới hạn thiết kế nhất định.

Chất lượng trong hoạt động dự án:

• Quản lý yêu cầu (“thuộc tính chất lượng” là một loại yêu cầu phi chức năng);
• Kiểm tra (còn gọi là MTBF, các số liệu như MTTF - Thời gian trung bình để xảy ra lỗi, nghĩa là thời gian trung bình giữa các lỗi hệ thống được phát hiện, v.v.).

"Chất lượng chấp nhận được" có thể được so sánh với cấp độ dịch vụ trong SLA - Thỏa thuận cấp độ dịch vụ nhất định. Nghĩa là, chất lượng có thể chấp nhận được có thể được coi là<количественно выраженный>sự thỏa hiệp giữa khách hàng và nhà thầu về đặc tính của sản phẩm do nhà thầu tạo ra vì lợi ích của<решения задач>khách hàng, có tính đến các hạn chế khác của dự án (cụ thể là chi phí, thường được gọi là “chi phí chất lượng”).

Hình “Khu vực tri thức – Chất lượng phần mềm”

Hình “Mô hình hệ thống quản lý chất lượng”

Nguyên tắc cơ bản về chất lượng phần mềm

Thỏa thuận đạt được về các yêu cầu chất lượng, cùng với sự trao đổi rõ ràng với các kỹ sư về những gì tạo nên chất lượng<получаемого продукта>, yêu cầu thảo luận và định nghĩa chính thức về nhiều khía cạnh của chất lượng.

Các kỹ sư phải hiểu khái niệm về chất lượng, đặc điểm và ý nghĩa của chất lượng liên quan đến phần mềm đang được phát triển hoặc bảo trì.

Một ý tưởng quan trọng là các yêu cầu phần mềm xác định các đặc tính chất lượng phần mềm được yêu cầu và cũng ảnh hưởng đến các phương pháp định lượng được xây dựng để đánh giá các đặc tính này.<соответствующие>tiêu chí chấp nhận.

Văn hóa và đạo đức công nghệ phần mềm

Các kỹ sư phần mềm được kỳ vọng sẽ chấp nhận các vấn đề về chất lượng phần mềm như một phần công việc của họ.<профессиональной>văn hoá.
Những cân nhắc về đạo đức có thể đóng một vai trò quan trọng trong chất lượng phần mềm, văn hóa và thái độ của các kỹ sư.<к своей работе>. Hiệp hội Máy tính IEEE và ACM đã phát triển bộ quy tắc đạo đức và thực hành nghề nghiệp dựa trên tám nguyên tắc để giúp các kỹ sư tăng cường cam kết về chất lượng và tính độc lập.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>trong công việc hàng ngày của họ.

Giá trị và chi phí của chất lượng

Trên thực tế, khái niệm “chất lượng” không hề rõ ràng và đơn giản như thoạt nhìn. Đối với bất kỳ sản phẩm kỹ thuật nào cũng có rất nhiều<интерпретаций>chất lượng, tùy thuộc vào “hệ tọa độ” cụ thể. Nhiều quan điểm trong số này cần được thảo luận và xác định ở giai đoạn phát triển các yêu cầu đối với một sản phẩm phần mềm. Các đặc tính chất lượng có thể được yêu cầu ở các mức độ khác nhau, có thể không có hoặc có thể đặt ra các yêu cầu nhất định, tất cả đều có thể là kết quả của một số loại thỏa hiệp.

Chi phí chất lượng có thể được phân biệt thành:

• chi phí cảnh báo<дефектов>(chi phí phòng ngừa),
• thẩm định giá cả,
• chi phí sai sót nội bộ,
• chi phí hư hỏng bên ngoài.

Động lực đằng sau các dự án phần mềm là mong muốn tạo ra phần mềm có giá trị nhất định. Giá trị của phần mềm có thể được thể hiện hoặc không dưới dạng chi phí. Khách hàng thường có ý tưởng riêng của mình về mức đầu tư chi phí tối đa, dự kiến ​​sẽ thu được lợi nhuận nếu đạt được các mục tiêu chính của việc tạo ra phần mềm. Khách hàng cũng có thể có những mong đợi nhất định về chất lượng của phần mềm. Đôi khi, khách hàng không nghĩ đến vấn đề chất lượng và chi phí liên quan. Các tính năng chất lượng chỉ mang tính trang trí hay chúng là một phần không thể thiếu của phần mềm? Câu trả lời có thể nằm ở đâu đó ở giữa, hầu như luôn xảy ra trong những trường hợp này và là vấn đề thảo luận về mức độ tham gia của khách hàng vào quá trình ra quyết định cũng như sự hiểu biết đầy đủ của khách hàng về chi phí và lợi ích. liên quan đến việc đạt được một mức chất lượng cụ thể. Lý tưởng nhất là hầu hết các quyết định này nên được đưa ra trong quá trình yêu cầu, nhưng những vấn đề này có thể phát sinh trong suốt vòng đời của phần mềm. không có bất kỳ<“стандартных”>quy định về cách thức đưa ra những quyết định như vậy một cách chính xác. Tuy nhiên, các kỹ sư phải có khả năng tưởng tượng ra nhiều lựa chọn thay thế khác nhau và chi phí của chúng.

Mẫu mã và đặc tính chất lượng

ISO/IEC xác định ba mô hình chất lượng phần mềm liên quan (ISO 9126-01 Kỹ thuật phần mềm - Chất lượng sản phẩm, Phần 1: Mô hình chất lượng):

• chất lượng bên trong,
• chất lượng bên ngoài và
• chất lượng trong quá trình vận hành cũng như bộ công việc liên quan để đánh giá chất lượng phần mềm (Đánh giá sản phẩm phần mềm ISO14598-98).

Chất lượng quy trình công nghệ phần mềm

Quản lý chất lượng (quản lý chất lượng phần mềm) và chất lượng quy trình công nghệ phần mềm (chất lượng quy trình công nghệ phần mềm) liên quan trực tiếp đến chất lượng của sản phẩm phần mềm được tạo ra.

Có hai tiêu chuẩn quan trọng trong lĩnh vực chất lượng phần mềm.

• TickIT- liên quan đến việc xem xét hệ thống quản lý chất lượng tổng thể ISO 9001-00 khi áp dụng cho các dự án phần mềm.
• Một tiêu chuẩn quan trọng khác là CMMI, được thảo luận trong lĩnh vực kiến ​​thức Quy trình Công nghệ Phần mềm, đưa ra các khuyến nghị để cải thiện quy trình. Các lĩnh vực quy trình CMMI (lĩnh vực năng lực) liên quan trực tiếp đến quản lý chất lượng:
  • đảm bảo chất lượng sản phẩm và quy trình (danh mục quy trình “Hỗ trợ” của CMMI),
  • xác minh (danh mục “Kỹ thuật”) và
  • chứng nhận (xác nhận, hạng mục “Kỹ thuật”).

Đồng thời CMMI phân loại ôn tập Và kiểm toán như các phương pháp xác minh, nhưng không phải là các quy trình độc lập.

Các tiêu chuẩn này vẫn được coi là bổ sung và chứng nhận ISO 9001 giúp đạt được mức độ trưởng thành CMMI cao cấp.

Chất lượng sản phẩm phần mềm

Trước hết người kỹ sư phải xác định mục tiêu tạo ra phần mềm. Trong bối cảnh này, điều đặc biệt quan trọng cần nhớ là yêu cầu của khách hàng là chính và bao gồm các yêu cầu về chất lượng chứ không chỉ về chức năng (yêu cầu chức năng). Do đó, các kỹ sư chịu trách nhiệm rút ra các yêu cầu về chất lượng không phải lúc nào cũng được trình bày rõ ràng, cũng như thảo luận về tầm quan trọng của chúng và mức độ khó khăn để đạt được chúng. Tất cả các quy trình liên quan đến chất lượng (ví dụ: lắp ráp, kiểm tra và cải tiến chất lượng) phải được thiết kế phù hợp với các yêu cầu này và chịu gánh nặng chi phí bổ sung (là một phần quan trọng trong chi phí của phần mềm).

Tiêu chuẩn ISO 9126-01 (Kỹ thuật phần mềm - Chất lượng sản phẩm, Phần 1: Mô hình chất lượng) xác định, đối với hai trong số ba mô hình được mô tả trong đó, các đặc điểm liên quan và "các đặc điểm phụ" về chất lượng, cũng như các thước đo hữu ích để đánh giá chất lượng của sản phẩm phần mềm.

Sự hiểu biết về thuật ngữ “sản phẩm” được mở rộng để bao gồm tất cả các tạo phẩm được tạo ra dưới dạng đầu ra của tất cả các quy trình được sử dụng để tạo ra sản phẩm phần mềm cuối cùng. Ví dụ về sản phẩm bao gồm (nhưng không giới hạn):

• hoàn thành đặc tả yêu cầu hệ thống,
• đặc tả các yêu cầu phần mềm cho các thành phần phần mềm của hệ thống (đặc tả yêu cầu phần mềm, SRS),
• mô hình,
• tài liệu kiểm tra,
• các báo cáo được tạo ra từ kết quả của công việc phân tích chất lượng.

Mặc dù thuật ngữ chất lượng thường được sử dụng nhiều nhất liên quan đến sản phẩm cuối cùng và hành vi của hệ thống trong quá trình vận hành, nhưng thực hành kỹ thuật tốt là yêu cầu đánh giá sự phù hợp với các đặc tính chất lượng đã chỉ định đối với các sản phẩm đầu ra/vòng đời trong suốt tất cả các quy trình công nghệ phần mềm.

Cải thiện chất lượng

Chất lượng phần mềm có thể được cải thiện thông qua quá trình cải tiến liên tục lặp đi lặp lại. Điều này đòi hỏi sự kiểm soát, phối hợp và phản hồi trong việc quản lý nhiều quy trình đang chạy đồng thời:

1. các quá trình vòng đời,
2. quá trình phát hiện, loại bỏ và ngăn ngừa các hư hỏng/khiếm khuyết và
3. các quá trình cải tiến chất lượng.

Các lý thuyết và khái niệm áp dụng cho công nghệ phần mềm là cải tiến chất lượng cơ bản. Ví dụ, ngăn ngừa và chẩn đoán sớm lỗi, cải tiến liên tục và chú ý đến yêu cầu của khách hàng (tập trung vào khách hàng), tạo nên nguyên tắc “xây dựng chất lượng”. Những khái niệm này dựa trên công việc của các chuyên gia chất lượng, những người tin rằng chất lượng của sản phẩm có liên quan trực tiếp đến chất lượng của quy trình được sử dụng để tạo ra sản phẩm đó.

Những cách tiếp cận như TQM(Quản lý chất lượng toàn diện - Total Quality Management) và PDCA(Lập kế hoạch, Thực hiện, Kiểm tra, Hành động – Lập kế hoạch, Hành động, Kiểm tra, Phản ứng/Điều chỉnh) là những công cụ để đạt được các mục tiêu liên quan đến chất lượng. Hỗ trợ quản lý giúp thực hiện các quy trình, đánh giá sản phẩm và thu thập tất cả dữ liệu cần thiết. Ngoài ra, chương trình cải tiến đã phát triển (chương trình cải tiến, thường có mục tiêu và bao trùm toàn bộ công việc của một bộ phận hoặc tổ chức) xác định chi tiết tất cả các hành động và dự án cải tiến.<отдельных аспектов деятельности>trong một khoảng thời gian nhất định trong đó các dự án đó có thể được thực hiện với giải pháp thành công cho các vấn đề liên quan. Đồng thời, sự hỗ trợ của quản lý có nghĩa là tất cả các dự án cải tiến đều có đủ nguồn lực để đạt được mục tiêu của mình. Hỗ trợ của quản lý có liên quan chặt chẽ đến việc thực hiện tương tác tích cực trong nhóm và sẽ ngăn chặn sự xuất hiện của các vấn đề tiềm ẩn (và sự phản kháng thụ động hoặc thậm chí chủ động đối với việc thực hiện chương trình cải tiến hoặc các dự án riêng lẻ của nó). Việc thành lập các nhóm làm việc, sự hỗ trợ của các nhà quản lý cấp trung và các nguồn lực chuyên dụng ở cấp dự án sẽ được thảo luận trong lĩnh vực kiến ​​thức “Quy trình Kỹ thuật Phần mềm”.

Quy trình chất lượng phần mềm

Quản lý chất lượng phần mềm (SQM, Quản lý chất lượng phần mềm)áp dụng cho tất cả các khía cạnh của quy trình, sản phẩm và nguồn lực. SQM xác định các quy trình, chủ sở hữu quy trình cũng như các yêu cầu về quy trình, thước đo quy trình và kết quả của chúng, cùng với các kênh phản hồi.

Quy trình quản lý chất lượng bao gồm nhiều hoạt động. Một số trong số chúng cho phép bạn trực tiếp tìm ra lỗi, trong khi một số khác giúp bạn xác định chính xác vị trí cần tiến hành nghiên cứu chi tiết hơn, sau đó, một lần nữa, công việc được thực hiện để phát hiện trực tiếp lỗi. Nhiều hành động cũng có thể được thực hiện nhằm đạt được cả hai mục tiêu.

Lập kế hoạch chất lượng phần mềm bao gồm:

1. Xác định sản phẩm cần thiết về mặt đặc tính chất lượng.
2. Quy trình lập kế hoạch để có được sản phẩm cần thiết.

Các quy trình này khác với các quy trình SQM về bản chất, do đó nhằm mục đích đánh giá hiệu suất chất lượng theo kế hoạch hơn là thực hiện các kế hoạch này trên thực tế. Quy trình quản lý chất lượng phải đề cập đến việc sản phẩm sẽ đáp ứng nhu cầu của khách hàng và các bên liên quan tốt như thế nào, mang lại giá trị cho khách hàng và các bên liên quan cũng như có chất lượng cần thiết để đáp ứng các yêu cầu phần mềm đã nêu.

SQM có thể được sử dụng để đánh giá cả sản phẩm cuối cùng và sản phẩm trung gian. Một số quy trình SQM chuyên biệt được xác định trong tiêu chuẩn 12207:

• Quy trình đảm bảo chất lượng;
• quá trình xác minh;
• Quá trình xác nhận;
• Quy trình đánh giá chung;
• Quá trình kiểm toán.

Tất cả các quy trình này hỗ trợ việc theo đuổi chất lượng và cũng giúp xác định các lỗi có thể xảy ra. Tuy nhiên, họ khác nhau ở những gì họ tập trung vào.

Các quy trình SQM bao gồm các nhiệm vụ và kỹ thuậtđược thiết kế để đánh giá các kế hoạch phần mềm đang thành hiện thực như thế nào và các sản phẩm trung gian và cuối cùng đáp ứng các yêu cầu cụ thể tốt như thế nào. Kết quả của những nhiệm vụ này được báo cáo cho người quản lý trước khi thực hiện các hành động khắc phục thích hợp. Quy trình SQM được quản lý với sự tự tin rằng dữ liệu báo cáo là chính xác.
Như được mô tả trong lĩnh vực kiến ​​thức này, các quy trình SQM có liên quan chặt chẽ với nhau. Chúng có thể chồng lên nhau và đôi khi còn kết hợp với nhau. Về bản chất, họ có vẻ phản ứng do thực tế là họ xem các quy trình trong bối cảnh thực tiễn đã học và các sản phẩm đã được sản xuất. Tuy nhiên, họ đóng vai trò chính trong giai đoạn lập kế hoạch, chủ động thực hiện các quy trình và thủ tục cần thiết để đạt được các đặc điểm và mức chất lượng mà các bên liên quan yêu cầu.<проекта>phần mềm.

Quản lý rủi ro cũng có thể đóng một vai trò quan trọng trong việc cung cấp phần mềm chất lượng. Bao gồm phân tích rủi ro “thường xuyên” (thường xuyên, không định kỳ; trong bản gốc – có kỷ luật) và<соответствующих>kỹ thuật viên điều khiển<рисками>vào các quy trình vòng đời phần mềm có thể làm tăng tiềm năng tạo ra một sản phẩm có chất lượng. Thông tin chi tiết hơn về quản lý rủi ro có thể được tìm thấy trong khu vực kiến ​​thức “Quản lý kỹ thuật phần mềm”.

Đảm bảo chất lượng phần mềm (SQA)

Quy trình SQA cung cấp bằng chứng cho thấy các sản phẩm phần mềm và quy trình vòng đời dự án đáp ứng các yêu cầu cụ thể. Việc xác nhận này được thực hiện trên cơ sở lập kế hoạch, thiết lập<работ>ban hành và thực hiện một tập hợp các hành động nhằm đảm bảo rằng chất lượng trở thành một phần không thể thiếu của phần mềm.
Quan điểm này bao hàm một công thức rõ ràng và chính xác của vấn đề, cũng như thực tế là các yêu cầu đối với<программному>phán quyết. SQA đạt được sự đảm bảo chất lượng trong quá trình phát triển và bảo trì bằng cách thực hiện nhiều hoạt động khác nhau ở tất cả các giai đoạn<жизненного цикла>, cho phép bạn xác định các vấn đề ở giai đoạn đầu, điều gần như không thể tránh khỏi trong bất kỳ hoạt động phức tạp nào.

Quản lý rủi ro là một công cụ bổ sung quan trọng để đảm bảo chất lượng phần mềm.

SQA, do SWEBOK xây dựng, tập trung vào các quy trình. Vai trò của SQA là đảm bảo rằng các quy trình được lên kế hoạch phù hợp, các quy trình tiếp tục được thực hiện dựa trên kế hoạch và các phép đo quy trình cần thiết được thực hiện cũng như kết quả đo lường được thông báo cho các bên liên quan (tổ chức và cá nhân).

Kế hoạch SQA xác định các phương tiện sẽ được sử dụng để đảm bảo rằng sản phẩm đang được phát triển đáp ứng các yêu cầu cụ thể của người dùng với mức chất lượng cao nhất có thể trong giới hạn thiết kế đã chỉ định.

Để đạt được điều này, trước tiên các mục tiêu chất lượng cần phải được xác định và hiểu rõ ràng (và cũng có thể diễn giải rõ ràng, đây là điều kiện tiên quyết cho bất kỳ mục tiêu và yêu cầu tương ứng nào). Điều này phải được phản ánh trong các kế hoạch quản lý có liên quan.<проектом>, phát triển và hỗ trợ.

Các hoạt động và nhiệm vụ đảm bảo chất lượng cụ thể được cấu trúc với các yêu cầu chi tiết về chi phí và các nguồn lực liên quan, mục tiêu quản lý và lịch trình tương ứng trong bối cảnh các mục tiêu do kế hoạch quản lý, phát triển và bảo trì đặt ra. Kế hoạch SQA xác định các tài liệu, tiêu chuẩn, thông lệ và quy ước được sử dụng để kiểm soát dự án cũng như cách xác minh và giám sát các khía cạnh này để đảm bảo tính đầy đủ và tuân thủ với kế hoạch đã chỉ định.
Kế hoạch SQA xác định các số liệu, kỹ thuật thống kê, báo cáo sự cố và quy trình hành động khắc phục, các công cụ như công cụ, kỹ thuật và phương pháp, vấn đề bảo mật phương tiện vật lý, đào tạo, báo cáo và tài liệu liên quan đến các vấn đề SQA.

Ngoài ra, kế hoạch SQA còn bao gồm các vấn đề liên quan đến hoạt động đảm bảo chất lượng liên quan đến các loại hoạt động khác được mô tả trong<различных>kế hoạch tạo phần mềm, bao gồm cả việc cung cấp, cài đặt, bảo trì các giải pháp phần mềm tùy chỉnh và/hoặc có thể nhân rộng/sẵn sàng (thương mại sẵn có, COTS) cần thiết cho một dự án phần mềm nhất định. Kế hoạch SQA có thể bao gồm các tiêu chí chấp nhận phần mềm cũng như các hoạt động quản lý và báo cáo cần thiết để đảm bảo chất lượng.<и контролю над>làm.

Xác minh và Xác thực (V&V)

Xác minh và chứng nhận phần mềm là một cách tiếp cận có kỷ luật để đánh giá các sản phẩm phần mềm, được áp dụng trong toàn bộ vòng đời. Các nỗ lực xác minh và xác định chất lượng nhằm mục đích đảm bảo chất lượng như một đặc tính không thể thiếu của phần mềm và đáp ứng yêu cầu của người dùng.
V&V trực tiếp giải quyết các vấn đề về chất lượng phần mềm và sử dụng các kỹ thuật kiểm tra thích hợp để phát hiện các lỗi cụ thể. Tuy nhiên, V&V có thể được sử dụng cho các sản phẩm trung gian trong phạm vi các “bước” trung gian tương ứng với<соответствующих>các quá trình vòng đời.

Quy trình V&V xác định mức độ sản phẩm (kết quả) của công việc phát triển và bảo trì nhất định đáp ứng các yêu cầu được đưa ra trong khuôn khổ các công việc này và sản phẩm cuối cùng đáp ứng các mục tiêu đã chỉ định và yêu cầu của người dùng.

xác minh- nỗ lực đảm bảo rằng sản phẩm được thiết kế chính xác (sản phẩm được sản xuất theo đúng cách; thường dành cho sản phẩm trung gian, đôi khi dành cho sản phẩm cuối cùng), theo nghĩa là sản phẩm do hoạt động này tạo ra đáp ứng các thông số kỹ thuật do hoạt động trước đó đặt ra .
Chứng nhận– nỗ lực để đảm bảo rằng sản phẩm phù hợp được tạo ra (sản phẩm phù hợp được tạo ra; thông thường, trong bối cảnh sản phẩm cuối cùng), nhằm đạt được mục tiêu đã nêu.

Cả hai quy trình – xác minh và chứng nhận– bắt đầu ở giai đoạn đầu của quá trình phát triển và bảo trì. Chúng cung cấp sự kiểm tra (kiểm tra) các khả năng chính của sản phẩm cả trong bối cảnh của các sản phẩm chuyển giao ngay trước đó (sản phẩm trung gian) và về việc đáp ứng các thông số kỹ thuật liên quan. Mục đích của việc lập kế hoạch V&V là cung cấp cho quá trình xác minh và chứng nhận các nguồn lực cần thiết cũng như phân công rõ ràng vai trò và trách nhiệm. Các tài liệu về kế hoạch V&V thu được và<детально>mô tả các nguồn lực, vai trò và hoạt động khác nhau cũng như các kỹ thuật và công cụ được sử dụng.
Kế hoạch này cũng đề cập đến các khía cạnh quản lý, truyền thông, chính sách và thủ tục của các hoạt động xác minh và chứng nhận cũng như sự tương tác của chúng. Ngoài ra, nó có thể giải quyết các vấn đề liên quan đến báo cáo lỗi và tài liệu yêu cầu.

Xem xét và kiểm toán

Năm loại đánh giá và kiểm toán:

• Đánh giá của ban quản lý
• Đánh giá kỹ thuật
• Kiểm tra
• “Đi bộ qua”
• Kiểm toán

Đánh giá của ban quản lý

Mục đích của đánh giá quản lý là theo dõi sự phát triển<проекта/продукта>, xác định tình trạng của các kế hoạch và lịch trình, phê duyệt các yêu cầu và phân bổ nguồn lực hoặc đánh giá tính hiệu quả của các phương pháp quản lý được sử dụng để đạt được các mục tiêu đã đề ra.

Đánh giá của quản lý hỗ trợ các quyết định thực hiện thay đổi và thực hiện các hành động khắc phục cần thiết trong quá trình thực hiện dự án phần mềm.

Đánh giá của ban quản lý xác định tính đầy đủ của các kế hoạch, lịch trình và yêu cầu, đồng thời theo dõi tiến độ hoặc sự không tuân thủ của chúng. Những đánh giá này có thể được thực hiện trên sản phẩm, được ghi lại dưới dạng báo cáo kiểm toán, báo cáo trạng thái (phát triển), báo cáo V&V, cũng như các loại kế hoạch khác nhau - quản lý rủi ro dự án/quản lý dự án, quản lý cấu hình, bảo mật<использования>phần mềm (an toàn), đánh giá rủi ro, v.v.

Đánh giá kỹ thuật

Mục đích của đánh giá kỹ thuật là kiểm tra một sản phẩm phần mềm để xác định tính phù hợp của nó với mục đích đã định. Mục tiêu là xác định những sai lệch so với các thông số kỹ thuật và tiêu chuẩn đã được phê duyệt. Để đảm bảo đánh giá kỹ thuật, các vai trò sau phải được phân bổ: người ra quyết định; lãnh đạo rà soát; máy ghi âm; cũng như nhân viên kỹ thuật hỗ trợ (trực tiếp thực hiện) hoạt động đánh giá.

Đánh giá kỹ thuật chắc chắn yêu cầu dữ liệu đầu vào sau:

• Tuyên bố mục tiêu
• Một sản phẩm phần mềm cụ thể (đang được đánh giá)
• Một kế hoạch dự án nhất định (kế hoạch quản lý dự án)
• Danh sách các vấn đề (câu hỏi) liên quan đến sản phẩm
• Thủ tục đánh giá kỹ thuật

Đội<технической оценки> tuân theo một thủ tục đánh giá cụ thể. Các cá nhân có trình độ (về mặt kỹ thuật) cung cấp cái nhìn tổng quan về sản phẩm (đại diện cho nhóm phát triển). Học<продукта> được thực hiện qua một hoặc nhiều cuộc họp (giữa những người trình bày sản phẩm và những người đưa ra đánh giá). Việc đánh giá kỹ thuật được hoàn thành sau khi hoàn thành tất cả các hoạt động điều tra sản phẩm theo quy định.

Kiểm tra

Mục đích của việc kiểm tra là phát hiện và xác định những điểm bất thường trong một sản phẩm phần mềm. Có hai điểm khác biệt chính giữa kiểm tra và đánh giá (quản lý và kỹ thuật):

1. Những người giữ chức vụ quản lý (người quản lý) có quan hệ với bất kỳ thành viên nào trong đoàn thanh tra không được tham gia thanh tra.
2. Việc kiểm tra phải được chỉ đạo bởi một người lãnh đạo công bằng (độc lập với dự án và các mục tiêu của dự án) đã được đào tạo về kỹ thuật kiểm tra.

Việc kiểm tra phần mềm luôn có sự tham gia của các tác giả của sản phẩm trung gian hoặc sản phẩm cuối cùng, không giống như các đánh giá không nhất thiết yêu cầu điều này. Thanh tra (với tư cách là đơn vị tổ chức tạm thời - tổ, đội) gồm có người đứng đầu, người đăng ký, người soát xét và một số (2 đến 5) thanh tra viên. Các thành viên của đoàn kiểm tra có thể chuyên về các lĩnh vực chuyên môn khác nhau (có các lĩnh vực năng lực khác nhau), ví dụ như lĩnh vực chủ đề, phương pháp thiết kế, ngôn ngữ, v.v. Tại một thời điểm (khoảng) thời gian nhất định, việc kiểm tra được thực hiện liên quan đến một phần nhỏ riêng biệt của sản phẩm (trong hầu hết các trường hợp, tập trung vào chức năng riêng lẻ hoặc các đặc tính khác; thường bắt đầu từ các quy tắc kinh doanh riêng lẻ, yêu cầu chức năng hoặc thuộc tính chất lượng). , Lưu ý của tác giả). Mỗi thành viên trong nhóm nên kiểm tra sản phẩm phần mềm và các đầu vào khác trước cuộc họp kiểm tra, có thể áp dụng các kỹ thuật phân tích khác nhau cho các phần nhỏ của sản phẩm hoặc cho toàn bộ sản phẩm, trong trường hợp sau chỉ xem xét một khía cạnh của nó, chẳng hạn như giao diện. Bất kỳ sự bất thường nào được phát hiện đều phải được ghi lại và thông tin được truyền đạt cho người đứng đầu thanh tra. Trong quá trình kiểm tra, người lãnh đạo chủ trì phiên họp<инспекции>và kiểm tra xem mọi thứ<члены команды>chuẩn bị cho cuộc kiểm tra.

Một công cụ phổ biến được sử dụng trong quá trình kiểm tra là một danh sách kiểm tra chứa các điểm bất thường và các câu hỏi liên quan đến các khía cạnh<программного продукта>, khơi gợi sự quan tâm. Bảng kết quả thường phân loại các điểm bất thường và được nhóm đánh giá về tính đầy đủ và chính xác. Quyết định hoàn thành việc kiểm tra được đưa ra theo một (bất kỳ) trong ba tiêu chí:

1. Nhận con nuôi<продукта>không có hoặc ít cần xử lý
2. Nhận con nuôi<продукта>với việc kiểm tra các đoạn đã được xử lý
3. Cần phải kiểm tra lại

Các cuộc họp kiểm tra thường kéo dài vài giờ, không giống như các cuộc đánh giá và kiểm toán kỹ thuật, trong hầu hết các trường hợp đòi hỏi nhiều công việc hơn và do đó kéo dài lâu hơn.

Hướng dẫn

Mục đích của hoạt động này là để đánh giá sản phẩm phần mềm. Việc kiểm tra có thể được thực hiện nhằm mục đích làm quen (đào tạo) khán giả với sản phẩm phần mềm.

Mục tiêu chính của cuộc chạy là:

• Tìm kiếm sự bất thường
• Cải tiến sản phẩm
• Thảo luận về các cách thực hiện thay thế
• Đánh giá sự tuân thủ các tiêu chuẩn và thông số kỹ thuật

Việc kiểm tra cũng tương tự như việc kiểm tra, tuy nhiên, nó thường được tiến hành theo cách ít trang trọng hơn. Về cơ bản, cuộc chạy được các kỹ sư tổ chức cho các thành viên khác trong nhóm nhằm nhận được phản hồi từ họ về công việc của họ, như một trong những yếu tố (kỹ thuật) đảm bảo chất lượng.

Kiểm toán

Mục đích của kiểm toán phần mềm là việc đánh giá độc lập các sản phẩm và quy trình phần mềm về việc tuân thủ các quy định, tiêu chuẩn, hướng dẫn, kế hoạch và thủ tục hiện hành.

Kiểm toán là một hoạt động được tổ chức chính thức trong đó những người tham gia thực hiện các vai trò cụ thể, chẳng hạn như kiểm toán viên chính, kiểm toán viên khác, người ghi chép và người khởi xướng. Đại diện của tổ chức/đơn vị tổ chức được đánh giá tham gia kiểm toán. Kết quả của cuộc kiểm toán là các trường hợp không tuân thủ được xác định và một báo cáo được nhóm yêu cầu sẽ được tạo ra<разработки>để có hành động khắc phục.

Mặc dù có nhiều tên chính thức (và phân loại) khác nhau để đánh giá và kiểm tra, nhưng điều quan trọng cần lưu ý là các loại hoạt động này có thể được thực hiện trên hầu hết mọi sản phẩm ở bất kỳ giai đoạn nào của quá trình phát triển hoặc bảo trì.

Cân nhắc thực tế

Yêu cầu chất lượng phần mềm

Yếu tố ảnh hưởng

Việc lập kế hoạch, quản lý và lựa chọn các hoạt động và kỹ thuật SQM bị ảnh hưởng bởi nhiều yếu tố khác nhau, bao gồm:

• Phạm vi của hệ thống mà phần mềm sẽ hoạt động (quan trọng về an toàn)<людей>), kinh doanh quan trọng, v.v.)
• Yêu cầu hệ thống và phần mềm
• Những thành phần nào được sử dụng trong hệ thống - thương mại (bên ngoài) hoặc tiêu chuẩn (nội bộ)
• Những tiêu chuẩn kỹ thuật phần mềm nào được áp dụng trong bối cảnh nhất định?
• Các phương pháp và công cụ phần mềm nào được sử dụng để phát triển và bảo trì, cũng như để đảm bảo và cải tiến chất lượng (sản phẩm và quy trình)
• Ngân sách, nhân sự, tổ chức các hoạt động dự án, kế hoạch và lịch trình cho tất cả các quá trình
• Ai là người dùng mục tiêu và mục đích của hệ thống là gì
• Mức độ toàn vẹn của hệ thống

Thông tin về các yếu tố này ảnh hưởng đến cách tổ chức và ghi lại chính xác các quy trình SQM, những hoạt động SQM nào sẽ được lựa chọn (được chuẩn hóa trong một dự án, nhóm, đơn vị tổ chức, tổ chức), những nguồn lực nào cần thiết và những hạn chế nào được đặt ra đối với những nỗ lực hướng tới. đảm bảo chất lượng.

Độ tin cậy

Khả năng đảm bảo- bảo đảm<высокой>độ tin cậy, bảo vệ khỏi sự cố.
Trong trường hợp lỗi hệ thống có thể dẫn đến hậu quả cực kỳ nghiêm trọng (những hệ thống như vậy đôi khi được gọi là “hệ thống có độ tin cậy cao” hoặc “hệ thống có tính toàn vẹn cao” trong các nguồn tiếng Anh, trong tiếng Nga, chúng đôi khi được gọi là “hệ thống có độ tin cậy cao”, “hệ thống có độ tin cậy cao”. tính khả dụng” và v.v.), khả năng bảo hành (tích lũy) chung của hệ thống (dưới dạng kết hợp giữa phần cứng, phần mềm và con người) là yêu cầu chất lượng chính và ưu tiên liên quan đến chức năng chính<системы>.

Độ tin cậy phần mềm bao gồm các đặc điểm như khả năng chịu lỗi, an toàn sử dụng (an toàn - an toàn trong bối cảnh rủi ro có thể chấp nhận được đối với sức khỏe con người, doanh nghiệp, tài sản, v.v.), bảo mật hoặc bảo mật thông tin (bảo mật - bảo vệ thông tin khỏi các hoạt động trái phép, bao gồm quyền truy cập đọc, cũng như đảm bảo tính sẵn có của thông tin cho người dùng được ủy quyền, trong phạm vi quyền được giao cho họ), cũng như sự thuận tiện và dễ sử dụng (khả năng sử dụng). Độ tin cậy cũng là một tiêu chí có thể được xác định dưới dạng khả năng bảo hành.

Trong cuộc thảo luận về vấn đề này, tài liệu phong phú về các hệ thống có độ tin cậy cao đóng một vai trò quan trọng. Đồng thời, thuật ngữ được sử dụng xuất phát từ lĩnh vực hệ thống cơ và điện truyền thống (bao gồm cả những hệ thống không bao gồm phần mềm) và mô tả các khái niệm về nguy hiểm, rủi ro, tính toàn vẹn của hệ thống, v.v.

Mức độ toàn vẹn của phần mềm

Mức độ toàn vẹn của phần mềmđược xác định dựa trên hậu quả có thể xảy ra của lỗi phần mềm và khả năng xảy ra lỗi đó. Khi các khía cạnh khác nhau của an toàn (ứng dụng và bảo mật thông tin) là quan trọng, thì các kỹ thuật phân tích mối nguy hiểm (trong bối cảnh an toàn sử dụng) và phân tích mối đe dọa (trong bối cảnh bảo mật thông tin) có thể được sử dụng để phát triển các kế hoạch làm việc nhằm xác định các điểm nóng có thể xảy ra tai nạn. . Lịch sử lỗi của các hệ thống tương tự cũng có thể giúp xác định các kỹ thuật hữu ích nhất để phát hiện lỗi và<всесторонней>đánh giá chất lượng phần mềm.

Khi xem xét tính toàn vẹn của phần mềm một cách chi tiết hơn trong bối cảnh của các dự án cụ thể, cần đặc biệt chú ý (phân bổ nguồn lực phù hợp và thực hiện các công việc cần thiết) không chỉ cho các quy trình SQM (đặc biệt là các quy trình chính thức, bao gồm kiểm toán và chứng nhận), mà còn cả đến các khía cạnh quản lý yêu cầu (về mặt tính toàn vẹn của tiêu chí), quản lý rủi ro (bao gồm lập kế hoạch rủi ro ở cả giai đoạn phát triển và giai đoạn vận hành và bảo trì hệ thống), thiết kế (để tăng năng lực bảo hành, nhất thiết phải liên quan đến -phân tích chuyên sâu và xác minh các giải pháp kiến ​​trúc và công nghệ được lên kế hoạch sử dụng, thường thông qua việc tạo các dự án thí điểm, gian hàng trình diễn, v.v.) và thử nghiệm (để đảm bảo nghiên cứu toàn diện về đặc điểm hành vi của hệ thống, bao gồm cả việc mô phỏng môi trường vận hành /cấu hình mà hệ thống sẽ được sử dụng trong quá trình vận hành).

Đặc tính khuyết tật

Các quy trình SQM đảm bảo rằng các khiếm khuyết được tìm thấy. Việc mô tả các đặc điểm lỗi đóng vai trò cơ bản trong việc hiểu sản phẩm, tạo điều kiện thuận lợi cho việc điều chỉnh quy trình hoặc sản phẩm và thông báo cho người quản lý dự án và khách hàng về trạng thái của quy trình hoặc sản phẩm. Có nhiều cách phân loại (phân loại và phương pháp cấu trúc) của các khiếm khuyết (thất bại). Đặc tính của khiếm khuyết cũng được sử dụng trong kiểm tra và đánh giá, trong đó người lãnh đạo đánh giá thường trình bày danh sách các điểm bất thường do các thành viên trong nhóm đánh giá biên soạn để thảo luận tại các cuộc họp thích hợp.

Trong bối cảnh của sự phát triển (và sự xuất hiện của các phương pháp và ngôn ngữ thiết kế mới), cùng với các công nghệ phần mềm mới, các loại lỗi mới xuất hiện. Điều này đòi hỏi nỗ lực rất lớn để giải thích (và sửa chữa) các loại lỗi (thất bại) được xác định trước đó. Khi theo dõi các khuyết tật, người kỹ sư không chỉ quan tâm đến số lượng mà còn cả loại của chúng. Việc phân bổ các lỗi theo loại đặc biệt quan trọng để xác định các yếu tố yếu nhất của hệ thống, về mặt công nghệ và giải pháp kiến ​​trúc được sử dụng, dẫn đến nhu cầu nghiên cứu chuyên sâu về chúng, tạo ra các dự án thí điểm chuyên biệt, bằng chứng bổ sung. về khái niệm (POC - cách tiếp cận thường được sử dụng khi sử dụng công nghệ mới), thu hút các chuyên gia bên thứ ba, v.v. Bản thân thông tin, nếu không được phân loại, thường đơn giản là vô ích trong việc xác định nguyên nhân thất bại, vì để xác định cách giải quyết vấn đề, cần phải nhóm chúng thành các loại thích hợp. Câu hỏi đặt ra là xác định cách phân loại lỗi có ý nghĩa đối với các kỹ sư và toàn bộ tổ chức.

SQM đảm bảo thu thập thông tin ở tất cả các giai đoạn phát triển và bảo trì phần mềm. Thông thường, khi chúng tôi nói “khiếm khuyết”, chúng tôi muốn nói đến “thất bại” như được định nghĩa dưới đây. Tuy nhiên, các nền văn hóa và tiêu chuẩn khác nhau có thể hàm ý những ý nghĩa khác nhau đối với những thuật ngữ này.

Định nghĩa một phần của các khái niệm thuộc loại này như sau:

• Lỗi:“Sự khác biệt... giữa kết quả đúng và kết quả tính toán<полученным с использованием программного обеспечения>”
• Lỗi:“Định nghĩa bước, quy trình hoặc dữ liệu không chính xác trong chương trình máy tính.”
• Sự thất bại: “<Некорректный>kết quả đạt được do sự thiếu hụt”
• Lỗi con người/người dùng (lỗi):“Một hành động của con người dẫn đến kết quả không chính xác”

Khi thảo luận về chủ đề này, lỗi được hiểu là kết quả của lỗi phần mềm. Các mô hình độ tin cậy được xây dựng dựa trên dữ liệu lỗi được thu thập trong quá trình kiểm thử hoặc sử dụng phần mềm. Những mô hình như vậy có thể được sử dụng để dự đoán các lỗi trong tương lai và giúp quyết định có nên dừng thử nghiệm hay không.

Dựa trên kết quả của công việc SQM nhằm phát hiện các khiếm khuyết, các hành động được thực hiện để loại bỏ các khiếm khuyết khỏi sản phẩm đang nghiên cứu. Tuy nhiên, sự việc không dừng lại ở đó. Có những hành động khả thi khác để tận dụng tối đa kết quả của công việc SQM liên quan. Trong số đó có phân tích và tổng hợp (tóm tắt)<по обнаруженным несоответствиям/дефектам>, việc sử dụng các kỹ thuật đánh giá định lượng (thu thập số liệu) để cải thiện sản phẩm và quy trình, theo dõi các lỗi và loại bỏ chúng khỏi hệ thống (với sự quản lý và kiểm soát kỹ thuật đối với các hành động khắc phục cần thiết). Đổi lại, nguồn thông tin để cải tiến quy trình nói riêng là quy trình SQM.

Dữ liệu về sự không nhất quán và khiếm khuyết được tìm thấy trong quá trình triển khai các kỹ thuật SQM có liên quan phải được ghi lại để ngăn ngừa sự mất mát của chúng. Đối với một số kỹ thuật (ví dụ: đánh giá kỹ thuật, kiểm toán, thanh tra), việc có máy ghi âm là bắt buộc, để ghi lại những thông tin đó một cách chính xác, cùng với các vấn đề (bao gồm cả những vấn đề cần xem xét bổ sung) và các quyết định được đưa ra. Trong trường hợp sử dụng các công cụ tự động hóa thích hợp, chúng cũng có thể cung cấp thông tin đầu ra cần thiết về lỗi (ví dụ: số liệu thống kê tóm tắt về trạng thái lỗi, người chịu trách nhiệm, v.v.). Dữ liệu về lỗi có thể được thu thập và ghi lại dưới dạng yêu cầu thay đổi phần mềm (SCR) và sau đó có thể được nhập vào một số loại cơ sở dữ liệu nhất định (ví dụ: để theo dõi số liệu thống kê lịch sử/dự án chéo để phân tích thêm và cải tiến quy trình), cả theo cách thủ công và tự động từ các công cụ phân tích thích hợp (một số công cụ thiết kế hiện đại và các công cụ chuyên dụng cho phép bạn phân tích mã và mô hình bằng cách sử dụng các số liệu thích hợp có ý nghĩa quan trọng để đảm bảo chất lượng sản phẩm và quy trình). Báo cáo khiếm khuyết được gửi đến cấp quản lý của tổ chức/đơn vị tổ chức hoặc cơ cấu (để đưa ra các quyết định phù hợp liên quan đến dự án, sản phẩm, quy trình, nhân sự, ngân sách, v.v.).

Kỹ thuật quản lý chất lượng phần mềm

Kỹ thuật SQM có thể được phân thành nhiều loại:

• tĩnh
• kỹ thuật đòi hỏi sử dụng nhiều nguồn nhân lực
• phân tích
• năng động

Kỹ thuật tĩnh

Kỹ thuật tĩnh bao gồm<детальное>nghiên cứu (kiểm tra) tài liệu thiết kế, phần mềm và thông tin khác về sản phẩm phần mềm mà không cần thực hiện nó. Những kỹ thuật này có thể bao gồm các hoạt động đánh giá “tập thể” hoặc phân tích “cá nhân” khác được thảo luận dưới đây, bất kể mức độ sử dụng tự động hóa.

Kỹ thuật thâm dụng con người

Hình thức của các loại kỹ thuật này, bao gồm đánh giá và kiểm tra, có thể bao gồm từ các cuộc họp chính thức đến các cuộc họp hoặc thảo luận không chính thức về sản phẩm mà không hề đề cập đến mã của nó. Thông thường, loại kỹ thuật này bao gồm sự tương tác trực tiếp giữa ít nhất hai người và trong hầu hết các trường hợp là nhiều chuyên gia hơn. Đồng thời, những cuộc họp như vậy có thể cần phải chuẩn bị sơ bộ (hầu như luôn liên quan đến việc xác định nội dung của cuộc họp, tức là danh sách các vấn đề cần thảo luận). Các tài nguyên được sử dụng trong các kỹ thuật như vậy, cùng với các tạo phẩm đang được nghiên cứu (sản phẩm, tài liệu, mô hình, v.v.), có thể bao gồm nhiều loại danh sách kiểm tra khác nhau và kết quả của các kỹ thuật phân tích (được thảo luận dưới đây) và công việc thử nghiệm. Ví dụ, những kỹ thuật này được thảo luận trong tiêu chuẩn 12207 khi thảo luận về việc xem xét và kiểm toán.

Kỹ thuật phân tích

Các kỹ sư phần mềm thường sử dụng các kỹ thuật phân tích. Từ quan điểm của các phương pháp và cách tiếp cận Agile, các cá nhân và sự tương tác giả định<непосредственное>giao tiếp và tương tác thường xuyên giữa các thành viên trong nhóm.

Đôi khi, một số kỹ sư sử dụng cùng một kỹ thuật nhưng trên các phần khác nhau của sản phẩm. Một số kỹ thuật dựa trên đặc điểm cụ thể của các công cụ được sử dụng, một số khác liên quan đến công việc “thủ công”. Nhiều kỹ thuật có thể giúp tìm ra lỗi một cách trực tiếp, nhưng hầu hết chúng thường được sử dụng để hỗ trợ các kỹ thuật khác. Một số kỹ thuật cũng bao gồm nhiều hình thức kiểm tra (đánh giá) khác nhau như một yếu tố không thể thiếu trong phân tích chất lượng tổng thể. Ví dụ về các kỹ thuật như vậy là phân tích độ phức tạp, phân tích logic điều khiển (hoặc phân tích luồng điều khiển) và phân tích thuật toán.

Mỗi loại phân tích có một mục đích cụ thể và không phải tất cả các loại đều có thể áp dụng cho mọi dự án. Một ví dụ về kỹ thuật hỗ trợ là phân tích độ phức tạp, kỹ thuật này rất hữu ích để xác định các phần của thiết kế hệ thống quá phức tạp để có thể triển khai, kiểm tra hoặc bảo trì một cách chính xác. Kết quả phân tích độ phức tạp cũng có thể được sử dụng để phát triển các trường hợp thử nghiệm. Các kỹ thuật phát hiện lỗi như phân tích logic điều khiển cũng có thể được sử dụng trong các trường hợp khác. Đối với phần mềm có logic thuật toán mở rộng, việc áp dụng các kỹ thuật thuật toán là cực kỳ quan trọng, đặc biệt trong trường hợp thuật toán không chính xác (không phải cách triển khai nó mà là logic, ghi chú của tác giả) có thể dẫn đến kết quả thảm khốc (ví dụ: phần mềm hệ thống điện tử hàng không, đối với sự an toàn vấn đề sử dụng – an toàn đóng vai trò quyết định).

Các loại kỹ thuật phân tích khác, chính thức hơn được gọi là phương pháp chính thức. Chúng được sử dụng để xác minh các yêu cầu và thiết kế (phải thừa nhận rằng, chỉ thỉnh thoảng, trong thực tế phát triển phần mềm công nghiệp ngày nay). Kiểm tra tính chính xác được áp dụng cho các phần quan trọng của phần mềm (nói chung là ít liên quan đến các phương pháp chính thức - đây là cách tự nhiên để đạt được chất lượng chấp nhận được trong khi giảm thiểu chi phí). Thông thường, chúng được sử dụng để xác minh các phần đặc biệt quan trọng của các hệ thống quan trọng, chẳng hạn như các yêu cầu cụ thể.<информационной>an toàn và độ tin cậy.

Kỹ thuật động

Trong quá trình phát triển và bảo trì phần mềm, người ta phải sử dụng nhiều loại kỹ thuật động khác nhau. Về cơ bản, đây là những kỹ thuật thử nghiệm. Tuy nhiên, các kỹ thuật mô phỏng, kiểm tra mô hình và “thực thi ký hiệu” có thể được coi là các kỹ thuật động (thực thi ký hiệu, thường liên quan đến việc sử dụng các mô-đun “giả” về mặt logic được thực thi, với đầu vào và đầu ra được mô phỏng khi xem xét kịch bản chung của hoạt động của các hệ thống nhiều mô-đun; đôi khi Thuật ngữ này cũng bao gồm các kỹ thuật khác, tùy thuộc vào nguồn được chọn).

Việc xem lại (đọc) mã thường được coi là một kỹ thuật tĩnh, nhưng một kỹ sư có kinh nghiệm có thể thực thi mã trực tiếp “trong khi” đọc nó (ví dụ: sử dụng các công cụ gỡ lỗi tương tác từng bước để xem xét hoặc đánh giá mã của người khác). Vì vậy, kỹ thuật này cũng có thể được coi là động. Những khác biệt trong việc phân loại các kỹ thuật như vậy cho thấy rõ ràng rằng tùy thuộc vào vai trò của một người trong tổ chức, anh ta có thể chấp nhận và áp dụng các kỹ thuật giống nhau theo những cách khác nhau.

Tùy thuộc vào tổ chức<ведения>dự án, một số công việc thử nghiệm nhất định có thể được thực hiện trong quá trình phát triển hệ thống phần mềm trong quy trình SQA và V&V. Vì kế hoạch SQM giải quyết các vấn đề về kiểm thử nên chủ đề này bao gồm một số nhận xét về kiểm thử.

Kiểm tra

Quy trình xác nhận<качества> , được mô tả trong SQA và V&V<планах>, kiểm tra và đánh giá mọi đầu ra (bao gồm sản phẩm trung gian và sản phẩm cuối cùng) liên quan đến đặc tả yêu cầu phần mềm đối với:

• truy xuất nguồn gốc
• Tính nhất quán
• sự đầy đủ/sự đầy đủ,
• sự đúng đắn
• và trực tiếp thực hiện<требований>(hiệu suất).

Việc xác nhận như vậy cũng bao gồm mọi tạo phẩm đầu ra từ quá trình phát triển và bảo trì, thu thập, phân tích và định lượng kết quả. Các hoạt động SQA đảm bảo rằng các loại thử nghiệm thích hợp (cần thiết trong bối cảnh dự án nhất định) được lên kế hoạch, thiết kế và triển khai, đồng thời V&V - phát triển các kế hoạch, chiến lược, kịch bản và quy trình thử nghiệm<тестирования>.
Các vấn đề về kiểm thử sẽ được thảo luận chi tiết trong phần Kiến thức kiểm thử. Hai loại thử nghiệm tuân theo các mục tiêu do SQA và V&V đặt ra vì chúng chịu trách nhiệm về chất lượng của dữ liệu được sử dụng trong dự án:

• Đánh giá và thử nghiệm các công cụ được sử dụng trong dự án
• Thử nghiệm tuân thủ (hoặc đánh giá các thử nghiệm tuân thủ) của các thành phần và sản phẩm COTS (COTS - sản phẩm bán sẵn, sẵn sàng sử dụng) để sử dụng trong sản phẩm đang được tạo ra.

Đôi khi, các tổ chức V&V độc lập có thể yêu cầu khả năng giám sát quá trình thử nghiệm và trong một số trường hợp nhất định, chứng nhận (hoặc thường xuyên hơn là tài liệu/hồ sơ) việc thực hiện thực tế<тестов>để đảm bảo rằng chúng được thực hiện theo các thủ tục quy định. Mặt khác, có thể gọi đến V&V để đánh giá bản thân cuộc thử nghiệm: tính đầy đủ của kế hoạch và quy trình, tính phù hợp và chính xác của kết quả.

Một loại thử nghiệm khác được thực hiện dưới sự giám sát của tổ chức V&V là thử nghiệm của bên thứ ba. Bản thân bên thứ ba đó không phải là nhà phát triển sản phẩm và không được liên kết dưới bất kỳ hình thức nào với nhà phát triển sản phẩm. Hơn nữa, bên thứ ba là nguồn đánh giá độc lập, thường được công nhận để có bằng cấp phù hợp (ví dụ: tổ chức phát triển tiêu chuẩn, sự tuân thủ được đánh giá bởi một chuyên gia độc lập và hành động của họ được xác nhận bởi người tạo ra tiêu chuẩn ). Mục đích của loại thử nghiệm này là kiểm tra xem sản phẩm có tuân thủ một bộ yêu cầu nhất định hay không (ví dụ: bảo mật thông tin).

Đo lường chất lượng phần mềm

Các mô hình chất lượng sản phẩm phần mềm thường bao gồm các số liệu để xác định mức độ của từng đặc tính chất lượng mà sản phẩm có.

Nếu các đặc tính chất lượng được chọn chính xác, các phép đo như vậy có thể hỗ trợ chất lượng (mức chất lượng) theo nhiều cách. Số liệu có thể giúp hướng dẫn quá trình ra quyết định. Số liệu có thể giúp xác định các khía cạnh có vấn đề và các điểm nghẽn trong quy trình. Số liệu là công cụ để các kỹ sư đánh giá chất lượng công việc của họ - cho cả mục đích được xác định bởi SQA và từ quan điểm của một quá trình cải tiến dài hạn<достигаемого>chất lượng.
Với sự gia tăng độ phức tạp bên trong và sự phức tạp của phần mềm, các vấn đề về chất lượng vượt xa việc nêu rõ thực tế là phần mềm hoạt động hay không hoạt động. Câu hỏi đặt ra là các mục tiêu chất lượng được định lượng đang đạt được tốt đến mức nào.

Có một số chủ đề khác thảo luận về các số liệu hỗ trợ trực tiếp cho SQM. Chúng bao gồm hỗ trợ trong việc quyết định khi nào nên dừng thử nghiệm. Trong bối cảnh này, các mô hình độ tin cậy và so sánh với các mẫu (tiêu chuẩn được chấp nhận làm ví dụ về chất lượng nhất định - điểm chuẩn) có vẻ hữu ích.

Chi phí của quá trình SQM là một trong những chi phí<проблемных>những câu hỏi luôn nảy sinh trong quá trình quyết định cách tổ chức dự án (công việc thiết kế). Thông thường, các mô hình chi phí chung được sử dụng, dựa trên việc xác định chính xác thời điểm phát hiện lỗi và cần bao nhiêu nỗ lực để sửa lỗi so với tình huống nếu lỗi được tìm thấy sớm hơn trong vòng đời. Dữ liệu thiết kế có thể giúp cung cấp một bức tranh rõ ràng hơn về chi phí.

Cuối cùng, bản thân báo cáo SQM cung cấp thông tin hữu ích không chỉ về bản thân các quy trình (ngụ ý trạng thái hiện tại của chúng, ghi chú của tác giả) mà còn về cách cải thiện tất cả các quy trình trong vòng đời.

Mặc dù các ước tính định lượng (trong trường hợp này chúng ta đang nói về kết quả đánh giá chứ không phải về quá trình đo lường) về các đặc tính chất lượng có thể hữu ích (ví dụ: số lượng yêu cầu chưa được đáp ứng và tỷ lệ các yêu cầu đó), nhưng chúng có thể<эффективно>áp dụng các kỹ thuật toán học và đồ họa để tạo điều kiện thuận lợi cho việc giải thích các giá trị số liệu. Những kỹ thuật như vậy được phân loại khá tự nhiên, ví dụ như sau:

• Dựa trên các phương pháp thống kê (ví dụ: phân tích Pareto, phân phối chuẩn, v.v.)
• Kiểm tra thống kê
• Phân tích xu hướng
• Dự đoán (ví dụ: mô hình độ tin cậy)

Các kỹ thuật dựa trên thống kê và kiểm tra thống kê thường cung cấp một “bản tóm tắt” về các lĩnh vực có vấn đề nhất của sản phẩm phần mềm đang được nghiên cứu (và nhân tiện, điều này cũng thường đúng với các quy trình). Các đồ thị và biểu đồ thu được sẽ hỗ trợ trực quan cho người ra quyết định trong việc xác định các lĩnh vực cần tập trung nguồn lực<проекта>. Kết quả phân tích xu hướng có thể cho thấy lịch trình đang bị vi phạm, chẳng hạn như trong quá trình thử nghiệm; hoặc lỗi của một số lớp nhất định ngày càng trở nên thường xuyên cho đến khi hành động khắc phục được thực hiện trong quá trình phát triển. Kỹ thuật dự đoán giúp lập kế hoạch thời gian thử nghiệm và dự đoán lỗi.

Đặc tính chất lượng phần mềm

Tính di động- Một tập hợp các thuộc tính liên quan đến khả năng của phần mềm có thể được chuyển từ môi trường này sang môi trường khác.
CHÚ THÍCH: Môi trường có thể bao gồm môi trường tổ chức, kỹ thuật hoặc phần mềm.

độ tin cậy- Một tập hợp các thuộc tính liên quan đến khả năng phần mềm duy trì mức hiệu suất của nó trong các điều kiện xác định trong một khoảng thời gian xác định.

Ghi chú:

1. Không có sự hao mòn hoặc lão hóa của phần mềm. Hạn chế về độ tin cậy xảy ra do lỗi trong yêu cầu, thiết kế và triển khai. Lỗi do những lỗi này phụ thuộc vào cách sử dụng phần mềm và phiên bản phần mềm đã chọn trước đó.
2. ISO 8402 định nghĩa “độ tin cậy” là “khả năng của một phần tử thực hiện chức năng được yêu cầu”. Trong tiêu chuẩn này, chức năng chỉ là một trong những đặc điểm của chất lượng phần mềm. Do đó, định nghĩa về độ tin cậy đã được mở rộng thành “duy trì mức hiệu suất” thay vì “thực hiện một chức năng cần thiết”.

Khả năng sử dụng- Một tập hợp các thuộc tính liên quan đến phạm vi công việc cần thiết để sử dụng và đánh giá riêng lẻ về việc sử dụng đó của một nhóm người dùng cụ thể hoặc dự định.

Ghi chú:

1. “Người dùng” có thể được hiểu là phần lớn người dùng trực tiếp của phần mềm tương tác. Người dùng có thể bao gồm người vận hành, người dùng cuối và người dùng gián tiếp bị ảnh hưởng hoặc phụ thuộc vào việc sử dụng phần mềm. Tính thực tế phải được xem xét trên nhiều điều kiện vận hành của người dùng có thể ảnh hưởng đến phần mềm, bao gồm cả việc chuẩn bị sử dụng và đánh giá kết quả.
2. Khả năng sử dụng, được định nghĩa trong tiêu chuẩn này là một tập hợp các thuộc tính cụ thể của sản phẩm phần mềm, khác với định nghĩa theo quan điểm ecgônômi, trong đó các đặc điểm khác như tính hiệu quả và tính không hiệu quả được coi là các thành phần của khả năng sử dụng.

Khả năng bảo trì- Tập hợp các thuộc tính liên quan đến phạm vi công việc cần thực hiện các thay đổi (sửa đổi) cụ thể.
LƯU Ý Thay đổi có thể bao gồm sửa chữa, cải tiến hoặc điều chỉnh phần mềm phù hợp với những thay đổi về môi trường, yêu cầu và điều kiện vận hành.

Chức năng- Tập hợp các thuộc tính liên quan đến bản chất của tập hợp hàm và các thuộc tính cụ thể của chúng. Chức năng là những chức năng đáp ứng các nhu cầu đã nêu hoặc dự kiến.

Ghi chú:

1. Tập hợp các thuộc tính này mô tả những gì phần mềm thực hiện để đáp ứng nhu cầu, trong khi các tập hợp khác chủ yếu mô tả thời điểm và cách thức thực hiện phần mềm.
2. Trong đặc tả này, ghi chú định nghĩa chất lượng được tính đến cho các nhu cầu đã nêu và dự kiến.

Hiệu quả- Tập hợp các thuộc tính liên quan đến mối quan hệ giữa mức độ chất lượng hoạt động của phần mềm và lượng tài nguyên được sử dụng trong các điều kiện xác định.
LƯU Ý Tài nguyên có thể bao gồm các sản phẩm phần mềm, phần cứng, vật liệu khác (ví dụ: giấy in, đĩa mềm) và các dịch vụ của nhân viên vận hành, bảo trì hoặc bảo trì.

Chất lượng sản phẩm phần mềm

Chất lượng phần mềm- toàn bộ phạm vi các tính năng và đặc điểm của một sản phẩm phần mềm liên quan đến khả năng đáp ứng các nhu cầu đã thiết lập hoặc dự kiến ​​của nó.

Tầm quan trọng của từng đặc tính chất lượng khác nhau tùy thuộc vào loại phần mềm. Ví dụ: độ tin cậy là quan trọng nhất đối với phần mềm hệ thống quan trọng trong chiến đấu, hiệu quả là quan trọng nhất đối với phần mềm hệ thống thời gian thực quan trọng về thời gian và khả năng sử dụng là quan trọng nhất đối với phần mềm đối thoại của người dùng cuối.

Tầm quan trọng của từng đặc tính chất lượng cũng khác nhau tùy thuộc vào quan điểm được áp dụng.

Chế độ xem người dùng

Người dùng chủ yếu quan tâm đến ứng dụng của phần mềm, hiệu suất và kết quả sử dụng của nó. Người dùng đánh giá phần mềm mà không kiểm tra các khía cạnh bên trong của nó hoặc cách phần mềm được tạo ra.

Người dùng có thể quan tâm đến các câu hỏi sau:

• Phần mềm có các tính năng cần thiết không?
• Phần mềm có độ tin cậy như thế nào?
• Phần mềm có hiệu quả như thế nào?
• Phần mềm có thân thiện với người dùng không?
• Việc chuyển giao phần mềm và các môi trường khác dễ dàng đến mức nào?

Chế độ xem dành cho nhà phát triển

Quá trình tạo yêu cầu người dùng và nhà phát triển sử dụng các đặc tính chất lượng phần mềm giống như chúng được sử dụng để thiết lập các yêu cầu và sự chấp nhận. Khi phần mềm được phát triển để bán, các yêu cầu về chất lượng phải phản ánh được nhu cầu dự kiến.

Vì các nhà phát triển chịu trách nhiệm tạo ra phần mềm phải đáp ứng các yêu cầu về chất lượng nên họ quan tâm đến chất lượng của các sản phẩm trung gian cũng như chất lượng của sản phẩm cuối cùng. Để đánh giá chất lượng của các sản phẩm trung gian ở mỗi giai đoạn của chu kỳ phát triển, nhà phát triển phải sử dụng các số liệu khác nhau cho cùng một đặc điểm vì các số liệu giống nhau không áp dụng cho tất cả các giai đoạn của vòng đời.

Ví dụ: người dùng hiểu hiệu quả về mặt thời gian phản hồi, trong khi nhà thiết kế sử dụng các thuật ngữ về độ dài và độ trễ của tuyến đường cũng như thời gian truy cập trong đặc tả thiết kế. Số liệu được sử dụng cho giao diện bên ngoài của sản phẩm có thể thay thế được với số liệu được sử dụng cho cấu trúc của sản phẩm.

Lời giới thiệu của người quản lý

Người quản lý có thể quan tâm đến chất lượng tổng thể hơn là đặc tính chất lượng cụ thể và vì lý do này sẽ cần xác định tầm quan trọng của các giá trị phản ánh yêu cầu kinh doanh đối với các đặc điểm riêng lẻ.
Người quản lý cũng có thể cần cân nhắc việc cải tiến chất lượng với các tiêu chí có thể kiểm soát, chẳng hạn như sự chậm trễ theo kế hoạch hoặc vượt chi phí, bởi vì anh ta muốn tối ưu hóa chất lượng trong những hạn chế về chi phí, lao động và thời gian.

Đánh giá chất lượng sản phẩm phần mềm

Hình dưới đây phác thảo các bước chính cần thiết để đánh giá chất lượng phần mềm.

Hình “Mô hình của quá trình đánh giá”

Quá trình đánh giá bao gồm ba giai đoạn: thiết lập (xác định) các yêu cầu về chất lượng, chuẩn bị cho quá trình đánh giá và đánh giá. Quá trình này có thể được áp dụng ở bất kỳ giai đoạn thích hợp nào trong vòng đời của từng thành phần phần mềm.
Mục đích của giai đoạn đầu là thiết lập các yêu cầu về đặc tính chất lượng. Các yêu cầu thể hiện nhu cầu của môi trường bên ngoài đối với sản phẩm phần mềm đang được đề cập và phải được xác định trước khi bắt đầu phát triển.
Mục đích của giai đoạn thứ hai là chuẩn bị cơ sở cho việc đánh giá.
Kết quả thứ ba là kết luận về chất lượng của sản phẩm phần mềm. Chất lượng tổng thể sau đó được so sánh với các yếu tố khác như thời gian và chi phí. Quyết định quản lý cuối cùng được đưa ra dựa trên tiêu chí kiểm soát. Kết quả là quyết định của ban quản lý về việc chấp nhận hay từ chối, phát hành hay không phát hành sản phẩm phần mềm.

Mô hình chất lượng quy trình

Quá trình phát triển phải được cấu trúc sao cho có thể đo lường được chất lượng của sản phẩm. Nghiên cứu được tiến hành cho thấy rằng chất lượng của quá trình phát triển càng cao thì chất lượng của phần mềm được phát triển trong quá trình này càng cao. Chất lượng ở mỗi giai đoạn của dự án tăng lên, thứ nhất là do hệ quả trực tiếp của quá trình hoàn thiện và thứ hai là do việc sử dụng sản phẩm trung gian chất lượng cao hơn được sản xuất ở giai đoạn trước. Cần nhấn mạnh rằng tầm quan trọng của lý do thứ hai, lý do đảm bảo sự gia tăng chất lượng trong suốt vòng đời của các quy trình trưởng thành, hóa ra lại quan trọng hơn nhiều. Tất cả điều này có thể được thể hiện dưới dạng một số mô hình.

Hình “Mô hình khái niệm về chất lượng quá trình phát triển”

Từ đó dẫn đến những hậu quả sau:
Thứ nhất: chất lượng được tích lũy trong một sản phẩm trong quá trình sản xuất phức tạp theo cách tích lũy và sự đóng góp vào chất lượng được thực hiện ở các giai đoạn đầu có tác động mạnh hơn đến sản phẩm cuối cùng so với các giai đoạn sau. Điều này được xác nhận bởi tất cả thực hành lập trình; ví dụ, người ta biết rằng những thiếu sót trong thiết kế hệ thống không thể được bù đắp bằng mã hóa chất lượng cao.
Vì vậy, để quản lý chất lượng xây dựng một hệ thống phức tạp, cần lựa chọn nhà sản xuất dựa trên việc đo lường mức độ trưởng thành và minh bạch của các quy trình phát triển được sử dụng. Đo lường chất lượng quá trình phát triển của nhà thầu là một phần quan trọng của quản lý chất lượng tổng thể, quan trọng hơn việc đo lường chất lượng của sản phẩm tạo ra trong quá trình thử nghiệm nghiệm thu.
Thứ hai: việc kiểm tra và đo lường chất lượng phải diễn ra ở tất cả các giai đoạn của vòng đời. Việc truy xuất dữ liệu chất lượng đã được xây dựng ở giai đoạn đầu có thể rất tốn kém nếu không có kết quả đầy đủ

Hướng dẫn áp dụng các đặc tính chất lượng

1 Khả năng ứng dụng

2 Ý tưởng về chất lượng phần mềm

2.1 Chế độ xem của người dùng
2.2 Giới thiệu của nhà phát triển
2.3 Giới thiệu người quản lý

3.1 Thiết lập các yêu cầu về chất lượng

3.2 Chuẩn bị đánh giá

3.2.1 Lựa chọn các thước đo chất lượng (chỉ số)
3.2.2 Xác định cấp độ xếp hạng
3.2.3 Xác định tiêu chí đánh giá

3.3 Quy trình đánh giá

3.3.1 Đo lường
3.3.2 Xếp hạng
3.3.3 Đánh giá

1. Giới thiệu

2 Định nghĩa các chỉ số chất lượng toàn diện

2.1 Chức năng

2.1.1 Sự phù hợp
2.1.2 Độ chính xác
2.1.3 Khả năng tương tác
2.1.4 Tuân thủ
2.1.5 Bảo mật

2.2 Độ tin cậy

2.2.1 Tính ổn định (Sự trưởng thành)
2.2.2 Khả năng chịu lỗi
2.2.3 Khả năng phục hồi

2.3 Khả năng sử dụng

2.3.1 Tính dễ hiểu
2.3.2 Khả năng học hỏi
2.3.3 Dễ sử dụng (Khả năng hoạt động)

2.4 Hiệu quả

2.4.1 Hành vi thời gian
2.4.2 Hành vi tài nguyên

2.5 Khả năng bảo trì

2.5.1 Khả năng phân tích
2.5.2 Khả năng thay đổi
2.5.3 Tính ổn định
2.5.4 Khả năng kiểm tra

2.6 Tính di động

2.6.1 Khả năng thích ứng
2.6.2 Dễ thực hiện (Có thể cài đặt)
2.6.3 Sự phù hợp
2.6.4 Có thể thay thế

Ghi chú:

1. Khả năng thay thế lẫn nhau được sử dụng thay vì khả năng tương thích để tránh nhầm lẫn có thể xảy ra với khả năng tương tác.
2. Khả năng thay thế lẫn nhau với một công cụ phần mềm cụ thể không có nghĩa là công cụ đó có thể thay thế được với công cụ phần mềm được đề cập.
3. Khả năng thay thế lẫn nhau có thể bao gồm các thuộc tính dễ thực hiện và khả năng thích ứng. Khái niệm này được giới thiệu như một đặc tính phụ riêng biệt do tầm quan trọng của nó.

Chất lượng dự án

Chất lượng bao gồm tất cả các hoạt động của dự án nhằm đảm bảo rằng dự án đáp ứng được các mục tiêu đã đề ra. Do đó, quản lý chất lượng áp dụng cho cả dự án và sản phẩm của dự án.
Chất lượng là cực kỳ quan trọng vì nó nói lên và ghi lại các mục tiêu, biến chúng thành tài liệu (chính thức hóa).
Vì vậy, chất lượng là một thành phần quan trọng của quản lý cấu trúc dự án.
Về chất lượng, mọi thứ đều có thể đo lường được.

Quản lý chất lượng dự án

Nếu quản lý chất lượng tập trung vào một bộ phận của tổ chức thì nó sẽ không mang tính phổ quát. Người quản lý dự án có thể ủy quyền các khía cạnh của quản lý chất lượng. Người quản lý dự án giữ trách nhiệm cuối cùng.

Nguyên tắc chất lượng (ISO 9000)

1. Khách hàng trọng điểm
2. Trách nhiệm quản lý
3. Thu hút mọi người
4. Cách tiếp cận quy trình
5. Cách tiếp cận có hệ thống để quản lý
6. Cải tiến liên tục
7. Ra quyết định dựa trên thực tế
8. Mối quan hệ đôi bên cùng có lợi với nhà cung cấp

Hình “Sự khác biệt trong cách hiểu về quản lý chất lượng theo ISO 9000 và PMBoK”

Quản lý chất lượng dự án (PMI): Các quy trình phụ

• Kế hoạch chất lượng
• Đảm bảo chất lượng
• Kiểm soát chất lượng

Kế hoạch chất lượng

Một trong những giai đoạn là xác định những tiêu chuẩn hiện có nào áp dụng cho một dự án nhất định và cách tuân thủ chúng. Đầu ra của việc lập kế hoạch chất lượng là danh sách tất cả các tiêu chuẩn chất lượng áp dụng cho dự án. Đính kèm là danh sách các khuyến nghị về cách đáp ứng các yêu cầu của các tiêu chuẩn này.

Quy trình hoạch định chất lượng: Đầu vào

• Chính sách chất lượng. Tài liệu chứa các nguyên tắc về cách tổ chức xác định chất lượng nhưng không chứa các cách để đạt được chất lượng.
• Nội dung dự án (phạm vi). Xác định những gì cần phải được thực hiện do dự án và do đó những gì cần được giám sát trong quy trình quản lý chất lượng. Tài liệu này là đầu ra của quá trình lập kế hoạch phạm vi dự án.
• Mô tả Sản phẩm. Chứa các chi tiết kỹ thuật và các khía cạnh liên quan khác có thể ảnh hưởng đến việc lập kế hoạch chất lượng.
• Tiêu chuẩn và quy định. Danh sách các tiêu chuẩn và quy định liên quan đến một khu vực hoặc dự án nhất định.
• Các tài liệu khác.

Quy trình hoạch định chất lượng: công cụ và công nghệ

• Phân tích lợi ích/chi phí. Có liên quan đến cuộc thảo luận về chi phí chất lượng. Mục đích của công cụ này là so sánh chi phí thực tế của việc thiếu chất lượng với lợi ích của việc đảm bảo chất lượng.
• So sánh. Được sử dụng để tạo ra các ý tưởng cải tiến thông qua việc so sánh với các dự án khác. Sẽ hiệu quả nhất khi so sánh với những dự án tốt nhất chứ không chỉ với các dự án nội bộ khác.
• Sơ đồ. Được sử dụng để hiển thị cách các yếu tố khác nhau tương tác. Có nhiều loại sơ đồ, trong đó có sơ đồ nguyên nhân và kết quả.
• Thiết lập thí nghiệm. Sử dụng kịch bản giả định để xác định biến nào có ảnh hưởng nhất đến kết quả cuối cùng của dự án.
• Chi phí chất lượng.

Quy trình hoạch định chất lượng: đầu ra, kết quả

• Kế hoạch quản lý chất lượng. Mô tả cách nhóm quản lý dự án sẽ thực hiện chính sách chất lượng. Nên bao gồm các lĩnh vực sau:
• Kiểm soát thiết kế.
• Kiểm soát tài liệu.
• Kiểm soát việc mua sắm vật tư.
• Kiểm tra.
• Kiểm soát các bài kiểm tra (thử nghiệm).
• Kiểm soát thiết bị điều khiển và đo lường.
• Hanh động đung đăn.
• Hồ sơ chất lượng.
• Kiểm toán (kế hoạch và thủ tục)
• Các thủ tục bằng văn bản và hướng dẫn công việc. Họ mô tả chi tiết các quy trình và cách đo lường chất lượng của quy trình, quy trình con và các hành động riêng lẻ được thực hiện.
• Danh sách kiểm tra. Danh sách các câu hỏi để kiểm tra xem không có gì bị thiếu.

Đảm bảo chất lượng

Quy trình đảm bảo chất lượng- đây là việc áp dụng các biện pháp có hệ thống theo kế hoạch để đảm bảo thực hiện tất cả các quy trình cụ thể cần thiết để dự án (sản phẩm, dịch vụ) đáp ứng các yêu cầu về chất lượng.
Đảm bảo chất lượng là quá trình phụ chính của quản lý chất lượng. Hoạt động này tiếp tục trong suốt dự án.

Quy trình chất lượng: Đầu vào

• Hướng dẫn công việc. Một đầu ra khác của quá trình lập kế hoạch chất lượng.
• Kết quả đo kiểm soát chất lượng. Đầu ra của quá trình kiểm soát chất lượng.

Quy trình đảm bảo chất lượng: Công cụ và kỹ thuật

Các công cụ và kỹ thuật lập kế hoạch chất lượng. Chúng bao gồm phân tích chi phí-lợi ích, so sánh, sơ đồ, thiết kế thử nghiệm và đánh giá chi phí chất lượng.

Kiểm toán chất lượng

Các cuộc “kiểm tra” có cấu trúc xác nhận “bài học kinh nghiệm”. Các loại kiểm toán chất lượng là:

• bên trong bên ngoài,
• hệ thống/sản phẩm/quy trình/tổ chức,
• kế hoạch / thường xuyên,
• đặc biệt và phức tạp.

Quy trình đảm bảo chất lượng: Kết quả đầu ra

Cải thiện chất lượng. Liên quan đến việc thực hiện các hành động nhằm tăng hiệu quả và năng suất của dự án nhằm mang lại lợi ích bổ sung cho chủ dự án.

Kiểm soát chất lượng

Giám sát một số kết quả nhất định để xác định sự tuân thủ của chúng với các tiêu chuẩn chất lượng được chấp nhận và xác định các cách để loại bỏ nguyên nhân dẫn đến hiệu quả hoạt động không đạt yêu cầu.

Quy trình kiểm soát chất lượng: Đầu vào

• Kết quả của công việc. Kết quả luôn xuất hiện trong quá trình hợp tác, thực hiện và lập kế hoạch lại dự án.
• Kế hoạch quản lý chất lượng. Đầu ra của quá trình lập kế hoạch chất lượng.
• Hướng dẫn công việc. Đầu ra của quá trình lập kế hoạch chất lượng.
• Danh sách kiểm tra.

Kiểm soát chất lượng: Công cụ và kỹ thuật

• Kiểm tra. Bao gồm các hoạt động như đo lường, kiểm tra, thử nghiệm để đảm bảo kết quả đạt yêu cầu.
• Bảng kiểm soát. Biểu đồ chạy xác định một cách thống kê các giới hạn trên và dưới, được phản ánh ở hai bên của mức trung bình của quá trình.
• Sơ đồ: Ishikawa, Pareto.
• Lấy mẫu thống kê.
• Phân tích xu hướng.

« Mục đích sử dụng công cụ– ghi lại các kết quả hoặc thay đổi, hiển thị chúng bằng đồ họa, sau đó xác định và khắc phục sự cố theo cách thích hợp.”

Quy trình kiểm soát chất lượng: Kết quả đầu ra

• Cải thiện chất lượng. Thoát khỏi quá trình đảm bảo chất lượng.
• Đưa ra quyết định. Các quyết định được đưa ra tùy thuộc vào việc đối tượng được kiểm tra được chấp nhận hay từ chối.
• Hanh động đung đăn. Một hành động được thực hiện để làm cho một đối tượng không phù hợp trở nên phù hợp.
• Danh sách kiểm tra đã hoàn thành.
• Thiết lập quy trình.

Người giới thiệu

• http://sorlik.blogspot.com, Sergey Orlik, 2004-2005
• Genelt A.E. Cẩm nang giáo dục và phương pháp luận về môn học “Quản lý chất lượng phát triển phần mềm” 2007, St. Petersburg