A. CÁC ĐỊNH NGHĨA

1.  Chung

– Phần mềm: là hệ thống (chương trình máy tính + tài liệu + dữ liệu + quy trình vận hành).

2. Công nghệ phần mềm (Software Engineering):

  • (1) Áp dụng cách tiếp cận có hệ thống, khoa họcđịnh lượng vào phát triển, vận hành và bảo trì phần mềm; (2) nghiên cứu các cách tiếp cận nêu trên [IEEE93].
  • Việc thiết kế và dùng các nguyên tắc công nghệ đúng đắn để thu được phần mềm một cách kinh tế nhất và chạy hiệu quả trên các máy thật [NATO68].

CNPM tập trung vào các chương trình lớn, phức tạp, yêu cầu cao về chất lượng. Tập trung vào phương pháp luận, nguyên tắc vận hành, làm việc khoa học, chuyên nghiệp.

Phạm vi: Điều hành và theo dõi, xem xét kỹ thuật, đảm bảo chất lượng, tài liệu, tái sử dụng, đo lường, quản lý rủi ro.

– Phát triển phần mềm không phải là chế tạo, lắp ráp. Phần mềm: trí tuệ, vô hình, thời gian dài, kinh phí lớn, outsource, không ngừng phát triển.

3. Nguyên nhân gây ra lỗi phần mềm

  • Lỗi đặc tả yêu cầu
  • Giao tiếp nhà phát triển-khách hàng thất bại
  • Cố ý sai lệch với yêu cầu phần mềm
  • Lỗi thiết kế luận lý
  • Lỗi codes…

4. Các vấn đề

Thỏa mãn yêu cầu khách hàng:

  • Giao hàng đúng hạn
  • Sản phẩm có chất lượng
  • Chi phí trong khung ngân sách

– Quản lý dự án phát triển phần mềm:

  • Lập kế hoạch
  • Kiểm soát

5. Qui trình phát triển+Các mô hình về tiến trình

– Đặc tả (10%), Phân tích (10), Thiết kế (15), Cài đặt (20), Kiểm thử (45)

– Đặc tả yêu cầu:

  • What, là hợp đồng, gồm các ràng buộc.
  • Yêu cầu chức năng + Phi chức năng
  • Kết quả: Tài liệu đặc tả yêu cầu.

– Phân tích:

  • Cuối đặc tả, đầu thiết kế.
  • Làm rõ yêu cầu, mô hình phân tích, định nghĩa, thuật ngữ.
  • Kết quả: Mô hình hệ thống ERD, DFD, SD, …

– Thiết kế:

  • Chuyển từ Yêu cầu –> Xây dựng, chia nhỏ hệ thống, mô tả chi tiết để xây dựng.
  • Chỉ ra giải pháp tối ưu.
  • Có thể dùng lại các mẫu.
  • Thiết kế kiến trúc (Module, giao diện, giải thuật) và TK chi tiết.

– Cài đặt:

  • Viết code (Lập trình, Nguồn mở, Chuẩn hóa,…), Kiểm thử (khác chạy thử)(Test Đơn vị-Tích hợp-Hệ thống-Chấp nhận-V)

B. ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM – SQA

1. Định nghĩa

– Đảm bảo chất lượng: thiết lập một tập hợp các họat động có chủ đích và có hệ thống nhằm mang lại sự tin tưởng sẽ đạt được chất lượng đòi hỏi.

  • Đảm bảo dự án phần mềm sẽ hoàn thành đúng đặc tả, theo chuẩn mực định trước và các chức năng đòi hỏi, không có hỏng hóc và các vấn đề tiềm ẩn.
  • Điều khiển và cải tiến tiến trình phát triển phần mềm ngay từ khi dự án bắt đầu. Nó có tác dụng “phòng ngừa” cái xấu, cái kém chất lượng.
  • Mục tiêu: thỏa mãn khách hàng (Thời gian+Ngân sách+Chất lượng)

2. Một số thuật ngữ

– Fault: là nguyên nhân làm cho hệ thống hỏng khi thực hiện chức năng nào đó.
– Errorlà sự không nhất quán giữa giá trị đầu ra của phần mềm so với giá trị đúng tương ứng với một đầu vào.
– Failure: sự bất lực của phần mềm khi thực hiện một chức năng theo đặc tả.
 3. Mục tiêu ĐBCL trong PTPM
– Đảm bảo mức độ tin cậy (Tuân thủ chức năng trong đặc tả+Quản lý+Ngân sách)
– Kiến tạo và quản lý hiệu quả các hoạt động phát triển và ĐBCL.
4. Phân biệt
– Assurance: chuỗi các hoạt động ngăn ngừa lỗi.
– Testing: Hoạt động nhằm phát hiện lỗi thông qua test case.
5. Các khía cạnh
– Kế hoạch ĐBCL: Mô tả chất lượng, Xác định qui trình đánh giá, chuẩn mực về quản lý.
– Kiểm soát CL: thanh tra, kiểm duyệt, kiểm thử đảm bảo tuân thủ đặc tả.
– Đảm bảo chất lượng: Xác định và báo cáo về qui trình để cung cấp thông tin quản lý và ra quyết định.
6. Yêu cầu chung

– Tuân thủ đặc tả là nền tảng để đo lường chất lượng.

 – Các chuẩn được xác định trước
– Tuân thủ yêu cầu chức năng và phi chức năng (không tường minh)
7. Các nguyên tắc
– Nguyên tắc 1: Bài bản
  • Qui trình: Chỉ rõ cách tiến hành, kiểm tra, giám sát ĐBCL
  • Tài liệu số liệu chứng minh

 Nguyên tắc 2: Không ngừng cải tiến

  • Kế hoạch, thực hiện, kiểm tra, cải tiến

8. Hoạt động của nhóm SQA

  • Lập kế hoạch ĐBCL
  • Tham gia xây dựng qui trình Phần mềm
  • Xem xét các hoạt động
  • Xác định mức độ đạt chuẩn
  • Đảm bảo sản phẩm được tài liệu hóa và giám sát.
  • Ghi nhận và báo cáo sai phạm.

9. Cách tiếp cận

  1. Chứng minh đúng đắn
  2. Thống kế chất lượng (Thông tin hỏng hóc, xác định nguyên nhân, nguyên lý Pareto 80/20)
  3. Tổ hợp cả 2 (Mô hình tăng trưởng, Đặc tả hình thức, Kiểm tra tĩnh (Lý lẽ) + động (Testing), ngăn ngừa hỏng hóc)

10.  Các yếu tố chất lượng

– 11 yếu tố chia làm 3 nhóm:

  • Vận hành sản phẩm: Correctness, Efficiency, Integrity (toàn vẹn), Usability
  • Xem xét lại sản phẩm: Maintainability, Flexibility, Testability
  • Chuyển giao sản phẩm: Portability, Reusability, Interoperability (tương tác)
 – Phân tích:
  • Correctness: Xác định một danh sách các output được đòi hỏi.
  •  Reliability: Định rõ xác suất vận hành không lỗi/thời gian, hoặc tần suất xuất hiện lỗi cao nhất/thời gian.
    • Có thể đo bằng dữ liệu quá khứ hoặc lúc phát triển.
    • Toàn hệ thống hoặc 1 chức năng.
    • Tần suất xuất hiện lỗi của bộ điều khiển nhịp tim là 1/20 năm.
  • Efficiency: Tài nguyên cần thiết (Thời gian, bộ nhớ. lưu trữ)
  • Integrity: Ngăn truy cập trái phép, khả năng phục hồi.
  • Usability: Tài nguyên con người cần thiết
  • Maintainability: Công sức bỏ ra để xác định lỗi phần mềm, sửa chữa, kiểm chứng…
  • Flexibility (Công sức thích ứng với phần mềm)
  • Testability (Khám nghiệm/ghi lỗi tự động)
  • Portability: Thích ứng hệ thống trong môi trường mới, hardware, OS…
  • Reusability: Tái sử dụng code, modun, tài liệu, rút ngắn thời gian. GUI của Java hoặc .Net
  • Interoperability: Phát triển giao diện với các hệ thống/thiết bị khác.

11. Hệ thống đảm bảo chất lượng

– Mục tiêu:
  • Tối thiểu hóa số lỗi phần mềm
  • Đạt được mức chất lượng đòi hỏi

– 6 thành phần:

  1. Tiền dự án: Thời gian+Ngân sách thiết lập phù hợp. Kế hoạch phát triển và Đảm bảo phải xác định rõ.
  2. Đánh giá các hoạt động trong vòng đời: 2 giai đoạn
    • Phát triển: Kiểm tra – Xác nhận – Xét duyệt – Chuyên gia – Kiểm thử
    • Vận hành, bảo trì: Các thành phần liên quan. Lưu ý bên thứ 3.
  3. Thành phần ngăn chặn lỗi và cải tiến
  4. Thành phần quản lý
  5. Thành phần chuẩn hóa, chứng nhận, đánh giá
    • Quốc tế và chuyên nghiệp
    • Chuẩn quản lý chất lượng: (What) ISO 9001, SEI CMM
    • Chuẩn Qui trình: (How) IEEE 1012, ISO/IEC 12297
  6. Thành phần tổ chức nhân sự
    • Tổ chức cơ bản: người quản lý, đội kiểm thử, đội SQA
    • Các thành phần SQA
    • Hệ quả các thủ tục
    • Cải tiến các thành phần SQA
  • SQA tổ chức và hoạt động trong lòng một tổ chức –> mang dấu ấn tổ chức.

12. Xét duyệt trong SQA – Xét duyệt:

  • Formal Technical Review (FTR), Formal Design Review, Inspection, Walkthrough, Peer Review, etc.
  • Phát triển bởi by Michael Fagan in the 1970’s (IBM)
  • Kỹ thuật họp: nhóm làm việc
 – Mục đích: Tìm và loại bỏ sớm các lỗi trong dự án. Dự án được chia nhỏ thành lộ trình.
  • Tìm các lỗi còn sót trong chức năng, logic hoặc cài đặt.
  • Kiểm tra các tài liệu (software code, specification, etc.) thỏa mãn đặc tả
  • Đảm bảo phần mềm thỏa các chuẩn mực (standards) qui định trước
  • Làm cho dự án là quản trị được.
 – Qui trình:
  1. Tổ chức xét duyệt: Tài liệu phù hợp, đủ thời gian tiếp cận tài liệu, số người hợp lý.
  2. Thực hiện xét duyệt: Người trình bày (Tạo ra tài liệu), tập trung tìm lỗi, hạn chế tranh luận.
  3. Sau cuộc họp: Chấp nhận/Chấp nhận tạm thời/Loại bỏ. Ghi nhận và lưu trữ kết quả.
13. Các mục tiêu
– Ngăn chặn lỗi hệ thống và cải tiến hiệu quả: Hạ thấp tỉ lệ lỗi, cải tiến hiệu quả các qui trình.
– Quản lý chất lượng: Kiểm soát các hoạt động phát triển, bảo trì và hỗ trợ.
Các khía cạnh:
  • Các độ đo chất lượng
  • Giá của chất lượng
  • Kiểm soát tiến độ
14. Tổng kết
Mục tiêu SQA: Thỏa mãn khách hàng
Nguyên tắc SQA: Bài bản, không ngừng cải tiến
– Các yếu tố chất lượng McCall
– Các thành phần của các hệ thống chất lượng.
C. CÁC CHUẨN CHẤT LƯỢNG PHẦN MỀM
1. Chuẩn

Khái niệmChuẩn là một định nghĩa đầy đủ, rõ ràng một kỹ thuật, qui trình hoặc thủ tục bởi một nhóm các nhà cung cấp dịch vụ hay sản phẩm.

  •  Chuẩn làm cho các sản phẩm, dịch vụ có nguồn gốc khác nhau có thể so sánh được hay nối kết được.
  • Giúp đảm bảo chất lượng cao, chỉ ra được chất lượng
  • Gia tăng đồng bộ
  • Cung cấp hướng dẫn thực hành, bảo hộ pháp luật.

– Có 2 loại:

  • Thực tế
  • Luật

2. Hệ thống chuẩn trong CNPM

ISO – International Organization for Standardization
CMM –  Software Engineering Institute’s (SEI) Capability Maturity Model
IEEE – Institute of Electrical and Electronics Engineers
DOD – U.S. Department of Defence
3. Chuẩn trong CNPM
– Chuẩn KTPM (software engineering)
  • Terminology: IEEE Std 610.12:1990
    • Standard of Software Engineering Terminology
  • Technical: ISO/IEC 8631:1989
    • Program Constructs and Conventions for their Representation
– Quản lí chất lượng phần mềm
  • Quality management: ISO 9000-3
    • Quality Management and Quality Assurance Standards – Part 3: Guidelines for the application of 9001 to the development, supply, installation and maintenance of computer software
  • Quality measurement: IEEE Std 1061-1992
    • Standard for Software Quality Metrics Methodology
– Quản lí dự án
  • General project management: IEE Std 1058.1-1987
    • Standard for Software Project Management Plans
  • Producing plans: IEEE Std 1059-1993
    • Guide for Software Verification and Validation Plans

 – Sản phẩm phần mềm

  • Product evaluation : ISO/IEC 14598
    • Software product evaluation
  • Packaging: ISO/IEC 12119:1994
    • Software Packages – Quality Requirements and Testing
– Qui trình phần mềm
  • Life cycle: ISO/IEC 12207:1995
    • Information Technology – Software Life Cycle Processes
  • Acquisition: ISO/IEC 15026
    • System and software Integrity Levels
  • Maintenance: IEEE Std 1219-1992
    • Standard for Software Maintenance
  • Productivity: IEE Std 1045-1992
    • Standard for Software Productivity Metrics
 4. Quan điểm trong QLCL
untitled
5. Chuỗi ISO 9000
– Chuẩn quốc tế cho quản lí chất lượng.
– Từ công nghiệp chế tạo –> công nghiệp dịch vụ
  • ISO 9000: Fundamentals and vocabulary
  • ISO 9001: Requirements
  • ISO 9004: Guidelines for performance improvements ISO

– 9001 áp dụng cho tổ chức thiết kế, phát triển, bảo trì phần mềm.

– ISO 9001 là mô hình tổng quát cho tiến trình chất lượng và nó phải được cụ thể hóa ở mỗi tổ chức dùng chuẩn này.
 – ISO 9001:2000 – Hệ thống quản lý chất lượng-Yêu cầu
– ISO 90003:2004 – Kỹ thuật phần mềm, hướng dẫn cho các hợp đồng cung ứng, phát triển…
 – Triết lý của ISO 9000
  • Tài liệu hóa cái mình làm
  • Làm cái đã viết trong tài liệu
  • Ghi nhận cái đã làm
  • Minh chứng cái đã làm
6. Yêu cầu của ISO 9001
  1. Xác nhận và tài liệu hóa các chính sách chất lượng, được thông suốt ở mọi cấp tổ chức.
  2. Tài liệu hóa mọi qui trình.
  3. Nhà cung cấp có khả năng đáp ứng mọi hợp đồng cung cấp hàng hóa.
  4. Phải có qui trình xét duyệt, phê chuẩn các thiết kế và tài liệu.
  5. Liên quan đến bên thứ 3 phải có qui trình kiểm tra chặt chẽ.
  6. Mỗi sản phẩm có thể nhận diện thành phần của nó.
  7. Lên kế hoạch và kiểm soát tiến trình phát triển.
  8. Thanh tra và kiểm thử xuyên suốt. Kể cả bên thứ 3.
  9. Kiểm soát cả thiết bị sản xuất.
  10. Ghi chép rõ ràng, đầy đủ trạng thái kiểm tra.
  11. Kiểm soát được các phần tử lỗi.
  12. Loại bỏ lỗi và đảm bảo ko xuất hiện lại.
  13. Qui định thỏa đáng về sử dụng, lưu trữ, đóng gói, chuyển giao…
  14. Đủ số liệu chứng minh chất lượng.
  15. Hệ thống quản lý chất lượng được xác nhận thường xuyên.
  16. Các hoạt động phụ vụ và trợ giúp.
  17. Thiết lập các chỉ số thống kê để kiểm tra tính chấp nhận.

7. ISO 9126

3 góc nhìn chất lượng sản phẩm phần mềm

  • Chất lượng trong: từ góc bên trong, trong suốt quá trình phát triển. (Code, kiến trúc)
  • Chất lượng ngoài: từ góc nhìn bên ngoài thông qua thực thi chương trình.
  • Chất lượng dùng: từ người dùng trong 1 môi trường cụ thể.

–> TRONG xác định chất lượng NGOÀI, NGOÀI ảnh hưởng đến DÙNG.

– Chất lượng trong và ngoài:

  • Chức năng (Functionality): khả năng cung cấp chức năng tương ứng
    • Suitability (thích hợp): phù hợp với công việc và mục đích
    • Accuracy (chính xác): kết quả đúng đắn, chính xác
    • Interoperability (tương tác): tương tác 1 hoặc nhiều hệ thống khác
    • Security (an toàn): bảo vệ thông tin dữ liệu, phân quyền truy cập
    • Functional Compliance (thỏa chuẩn chức năng): thỏa mãn qui định luật pháp.
  • Tin cậy (Reliability): đạt mức đọ hiệu quả xác định trong một điều kiện cụ thể.
    • Maturity (chín chắn): tránh hỏng hóc.
    • Fault tolerance (chịu đựng lỗi): đạt mức độ hiệu quả xác định trong trường hợp bị lỗi hoặc xâm hại.
    • Recoverability (Phục hồi): Phục hồi dữ liệu trong trường hợp hỏng hóc.
    • Reliability compliance (thỏa chuẩn độ tin cậy): Thỏa các qui định về pháp luật.
  • Tính sẳn dùng (Availability): tổ hợp của maturity, fault tolerance và recoverability.
  • Dùng được (Usability):
    • Understandability (hiểu được)
    • Learnability (học được)
    • Operability (vận hành được)
    • Attractiveness (hấp dẫn)
    • Usability compliance (thỏa mãn chuẩn về dùng được)
    • Web –> Bao gồm truy cập được.
  • Hiệu quả (Efficiency): Hiệu quả sử dụng nguồn lực, tài nguyên.
  • Time behavior (đáp ứng về thời gian)- thời gian thao tác hoặc trả lời hoặc tần xuất đứt quãng.
  • Resource utilization (dùng tài nguyên).
  • Efficiency compliance (thỏa mãn chuẩn về hiệu quả).
  • Bảo trì được (Maintainability): Sửa lỗi, cải tiến để đáp ứng thay đổi về môi trường/chức năng.
    • Analyzability (phân tích được) – sự phụ thuộc hoặc nguyên nhân hỏng hóc.
    • Changeability (thay đổi được).
    • Stability (ổn định)- tránh hiệu ứng lề.
    • Testability (kiểm tra được) – kiểm chứng sửa đổi.
    • Maintainability Compliance (thỏa mãn chuẩn về tính bảo trì được).
  • Khả chuyển (Portability): chuyển từ môi trường này sang môi trường khác.
    • Adaptability (thích ứng)- các môi trường khác nhau.
    • Installability – (cài đặt được).
    • Co-existence (cùng tồn tại)-với các phần mềm độc lập khác và chia sẻ tài nguyên.
    • Replaceability (thay thế được), ví dụ IE8 thay IE7.
    • Portability Compliance (thỏa mãn chuẩn về khả chuyển).
  • Chất lượng dùng (Quality in use)
    • Effectiveness (hiệu quả): chính xác và đầy đủ trong ngữ cảnh.
    • Productivity (hiệu suất): trả một lượng phù hợp về tài nguyên.
    • Safety (an toàn): mức độ rủi ro phù hợp
    • Satisfaction (thỏa mãn người dùng)
  • 8. CMM

    – 5 mức trưởng thành công ty phần mềm

    1. Initial: Không ổn định, ít định nghĩa. Nhờ vào tài năng và nỗ lực cá nhân.
      • Có thể thành công nhưng khả năng thất bại cao và ko kịp tiến độ. Ước lượng đôi lúc thiếu chính xác.
      • Đội ngũ mỗi dự án mỗi lần khác nhau
      • Phụ thuộc vào người giỏi
    2. Repeatable: Kiểm soát cơ bản giá, thời gian, chức năng. Kỷ luật và chặt chẽ.
      • Qui trình được thiết lập (Yêu cầu KH, kế hoạch, hợp đồng, đảm bảo, cấu hình, đo lường, phân tích…)
      • Kế hoạh dự án dựa trên những cái trước đó.
      • Chuẩn hóa code, test.
    3. Defined: Qui trình kỹ nghệ+quản lí —> tài liệu hóa, chuẩn hóa và tích hợp –> qui trình chuẩn. Dùng chung một phiên bản được duyệt.
      • Qui trình được định nghĩa và tài liệu hóa.
      • Chuẩn hóa, kiểm tra chéo.
      • Có hạ tầng cho quy trình và quản lý.
    4. Managed: Các độ đo được tập hợp. Được hiểu và kiểm soát định lượng.
      • Đo lường và phân tích –> Dữ liệu –> Qui trình mới
      • Định lượng và dự báo trước. Cải tiến.
      •  Hiểu biết qui trình và sản phẩm đag xây dựng.
    5. Optimizing: Cải tiến liên tục dựa trên phản hồi qui trình và sáng kiến.
      • Qui trình được thiết lập và đo được
      • Phân tích hỏng hóc và nguyên nhân
      • Đạt tiến độ kế hoạch, trưởng thành.
    –> Nếu các tiêu chí thỏa mãn, cty được cấp chứng chỉ ISO.
    9. Phạm vi qui trình
    – Tập các hoạt động –> Đồng loạt –> hoàn thành mục tiêu+Nâng cao khả năng.
    – KPA được định nghĩa để tập trung –> mức trưởng thành
    – Xác định các vấn đề để giải quyết –> mức trưởng thành.
    – Các đặc tính chung:
    • Cam kết thực hiện
    • Khả năng thực hiện
    • Các hoạt động được thực hiện
    • Đo lường và phân tích
    • Kiểm chứng các thiết lập

     10. CMMI (Capability Maturity Model Integration)

    – Mục tiêu: Mô hình –> Cải tiến –> Kiểm tra
    – Khung CMMI: Kho dữ liệu –> CMM –> trợ giúp đánh giá
    – Đầu ra CMMI:
    • Mô hình
    • Tài liệu tập huấn
    • Phương pháp đánh giá
    • Qui tắc đơn lẻ và phức hợp

    – Các mô hình:

    • Software Engineering (CMMI-SW)
    • System Engineering (CMMI-SE)
    • System Engineering + Software Engineering (CMMI-SE/SW)
    • Systems Engineering + Software Engineering with Integrated Product & Process Development (CMMI-SE/SW/IPPD)
    – 3 bước thực hiện
    • Selection of the Model
    • Selection of the Assessment Method
    • Selection of the Model Representation 

     D. ĐO CHẤT LƯỢNG

    1. Các định nghĩa
    Số đo (Measure) trong CNPM là một danh từ:
    • Số đo cung cấp phạm vi, số lượng, kích thước, khả năng của một thuộc tính của một sản phẩm hoặc qui trình.
    Đo (Measurement): là một hành động xác định số đo.
    Độ đo (Metric):
    • Một số đo định lượng mức độ.
    Chỉ báo (Indicator):
    • Một hoặc tổ hợp các độ đo cung cấp cái nhìn sâu vào bên trong qui trình, dự án hoặc sản phẩm.
    2. Độ đo chất lượng phần mềm (Software Quality Metric)
    SQM: đo định lượng –> mức độ –> phần tử có thuộc tính chất lượng
    Hàm: đầu vào –> dữ liệu, đầu ra –> giá trị số, phản ánh mức độ chất lượng.
    – Mục tiêu:
    • Dễ dàng kiểm soát, quản lí, lập kế hoạch và thực hiện các điều chỉnh về quản lí, dựa trên:
      • Thực tế so với hiệu năng mong đợi, với thời gian, ngân sách dự kiến.
    • Các hoạt động ngăn lỗi hoặc sửa lỗi
      • Ví dụ: tích lũy các độ đo nhằm vào hiệu năng của nhóm làm việc.
     3. Phân loại độ do
    –  Theo giai đoạn
    • Qui trình phát triển
    • Qui trình vận hành và bảo trì
    – Theo chủ đề
    • Chất lượng
    • Thời gian
    • Hiệu quả

    4. Đo lường phần mềm

    – Đo kích thước
    • KLOC – một độ đo cổ điển bằng số ngàn dòng lệnh.
    • Number of function points (NFP) – độ đo công sức để phát triển dựa vào đặc tả phần mềm.
    – Độ đo chất lượng tiến trình
    • Độ đo mật độ lỗi = Số lỗi/KLOC
    • Độ đo nhạy cảm với lỗi
    – Độ đo khung thời gian của tiến trình
    – Độ đo hiệu quả loại trừ lỗi
    – Độ đo hiệu quả của tiến trình
     5. Thách thức các độ đo
    – Cách nhìn khác nhau về chất lượng và độ phức tạp.
    – Mục tiêu: pháp triển nhiều độ đo –> nắm bắt chỉ số chất lượng. Tuy nhiên, PP luận khoa học chưa được đưa ra.
     6. Nguyên tắc các độ do
    – Công thức hóa – Rút ra các độ đo phù hợp cho phần mềm.
    – Tập hợp dữ liệu – Độ đo hình thức hóa
    – Phân tích – tính toán và áp dụng công cụ toán học.
    – Diễn dịch – đánh giá dựa vào công sức –> chất lượng của hệ thống
    – Phản hồi – các khuyến nghị rút ra từ diễn dịch các độ đo.
    7. Các đặc điểm độ đo hiệu quả
    – Đơn giản và tính được
    – Phù hợp thực nghiệm và trực quan
    – Nhất quán và khách quan
    – Nhất quán trong đơn vị và chiều
    – Độc lập NNLT
    – Cơ chế phản hồi hiệu quả
    8. Điểm chức năng
    untitled
     9. Độ đo thiết kế mức tổng thể
    – Structural Complexity
    • S(i) = f2out(i)
    • fout(i) = fan-out of module i
    – Data Complexity
    • D(i) = v(i)/[fout(i) +1]
    • v(i) = # of input and output variables to and from module i
    – System Complexity
    • C(i) = S(i) + D(i)
     10. Độ đo hình thái
    – size = n + a
    – n = number of modules
    – a = number of arcs (lines of control)
    – arc-to-node ratio, r = a/n
    – depth = longest path from the root to a leaf
    – width = maximum number of nodes at any level
     untitled
    11. Độ đo thiết kế ở mức chi tiết
    – Đo tính hợp nhất
    – Đo phụ thuộc:
    • Phụ thuộc vào dòng dữ liệu và điều khiển
    • Phụ thuộc tổng quan
    • Phụ thuộc môi trường
    – Đo độ phức tạp
    • Số Cyclomatic
    • Số này > 10 thì chương trình sẽ phức tạp và khó test
    12. Đo thiết kế giao diện 
    – Các thực thể trình bày – graphic icons, text, menus, windows, …
    – Bố trí các thực thể phù hợp:
    • Vị trí tương đối, tuyệt đối
    • Tần suất dùng
    • Giá để chuyển này sang khác
    – LA = 100 x [(cost of LA-optimal layout) /  (cost of proposed layout)]
    – Thiết kế giao diện cuối cùng nên dựa trên phản hồi từ các giao diện làm bản mẫu.
     13. Đo độ phức tạp theo McCabe 
    – Dựa vào dòng điều khiển trong chương trình.
    1 Chương trình như 1 sơ đồ dòng điều khiển.
    Nút là công việc, gồm 1 hoặc nhiều lệnh (khối tuần tự)
    Cạnh là dòng điều khiển giữa các nút
    Độ phức tạp:
    • C = V(G) = E – N + 2
      • E : số cạnh
      • N: số nút

    untitled

    – Nếu chương trình được biểu diễn –> đồ thị liên thông thì
    • C = V(G) = P + 1
    • P là số nút điều kiện (điều khiển rẽ nhánh)
     14. Độ đo cho kiểm thử 
    – Các độ đo cho phân tích, cài đặt –> thiết kế và thực hiện test cases.
    – Độ đo hoàn thành test
    Độ rộng: tổng số yêu cầu được test.
    Độ sâu: phần trăm đường đi độc lập được test so với tổng trong chương trình.
    – Tóm lược lỗi: ưu tiên hóa và phân loại các lỗi chưa được test bao trùm.
     15. Độ đo cho bảo trì 
     Chỉ số mức độ chín chắn (SMI)
    • MT = tổng số module
    • Fc =  tổng số module bị thay đổi
    • Fa =  tổng số module dược thêm vào
    • Fd =  tổng số module bị xóa
     SMI = [MT  – (Fc  + Fa  + Fd)] / MT
    16. Độ đo cho TK HĐT
     – Kích thước
    – Size: Xác định theo khung nhìn
    • Số lượng: số lượng tĩnh các thực thể HĐT như số lớp, số phép toán
    • Khối lượng: số lượng động, tương tự
    • Độ dài : dãy liên kết giữa các phần tử thiết kế
    • Chức năng: chỉ báo gián tiếp về giá trị chuyển giao cho khách hàng
    Độ phức tạp – Complexity
    • Được xem xét theo cấu trúc
    – Độ gắn kết – Coupling
    – Hiệu quả – Sufficiency
    – Đầy đủ – Completeness
    – Nhất quán – Cohesion
    – Tính nguyên sơ – Primitiveness
    – Đơn giản – Similarity
    – Tính không bền vững – Volatility
    en
    understand ) – Learnability ( learned ) – Operability ( which is ) – Attractiveness ( attractive ) Usability – compliance ( t
    en → vi
    erability (mà
    en → vi
    – Biến động
    vi → en
    standard Software Tech
    vi → en
    Formulated
    en → vi
    Trusted ( đáng tin cậy )
    vi → en
    bring trust