Quản lý chất lượng phần mềm - Hướng dẫn nhanh

Phần mềm chất lượng đề cập đến một phần mềm không có lỗi hoặc sai sót hợp lý, được phân phối trong thời gian và trong phạm vi ngân sách được chỉ định, đáp ứng các yêu cầu và / hoặc mong đợi và có thể bảo trì được. Trong bối cảnh kỹ thuật phần mềm, chất lượng phần mềm phản ánh cả haifunctional quality cũng như structural quality.

• Software Functional Quality - Nó phản ánh mức độ đáp ứng của nó đối với một thiết kế nhất định, dựa trên các yêu cầu chức năng hoặc thông số kỹ thuật.

• Software Structural Quality - Nó đề cập đến việc xử lý các yêu cầu phi chức năng hỗ trợ việc cung cấp các yêu cầu chức năng, chẳng hạn như tính mạnh mẽ hoặc khả năng bảo trì và mức độ phần mềm được sản xuất chính xác.

• Software Quality Assurance- Đảm bảo chất lượng phần mềm (SQA) là một tập hợp các hoạt động nhằm đảm bảo chất lượng trong các quy trình kỹ thuật phần mềm nhằm tạo ra các sản phẩm phần mềm có chất lượng. Các hoạt động thiết lập và đánh giá các quá trình tạo ra sản phẩm. Nó liên quan đến hành động tập trung vào quy trình.

• Software Quality Control- Kiểm soát chất lượng phần mềm (SQC) là một tập hợp các hoạt động nhằm đảm bảo chất lượng trong các sản phẩm phần mềm. Các hoạt động này tập trung vào việc xác định các khuyết tật trong các sản phẩm thực tế được sản xuất. Nó liên quan đến hành động tập trung vào sản phẩm.

Thách thức về chất lượng phần mềm

Trong ngành công nghiệp phần mềm, các nhà phát triển sẽ không bao giờ tuyên bố rằng phần mềm không có lỗi, không giống như các nhà sản xuất sản phẩm công nghiệp khác thường làm. Sự khác biệt này là do những lý do sau đây.

Độ phức tạp của sản phẩm

Đó là số chế độ hoạt động mà sản phẩm cho phép. Thông thường, một sản phẩm công nghiệp chỉ cho phép dưới vài nghìn chế độ hoạt động với các kết hợp khác nhau của các cài đặt máy của nó. Tuy nhiên, các gói phần mềm cho phép hàng triệu khả năng hoạt động. Do đó, việc đảm bảo tất cả các khả năng hoạt động này một cách chính xác là một thách thức lớn đối với ngành công nghiệp phần mềm.

Hiển thị sản phẩm

Vì các sản phẩm công nghiệp có thể nhìn thấy được, hầu hết các lỗi của nó có thể được phát hiện trong quá trình sản xuất. Ngoài ra, có thể dễ dàng phát hiện thấy sự vắng mặt của một bộ phận trong sản phẩm công nghiệp trong sản phẩm. Tuy nhiên, các khiếm khuyết trong các sản phẩm phần mềm được lưu trữ trên đĩa hoặc CD là vô hình.

Quy trình sản xuất và phát triển sản phẩm

Trong một sản phẩm công nghiệp, các lỗi có thể được phát hiện trong các giai đoạn sau:

• Product development - Trong giai đoạn này, các nhà thiết kế và nhân viên Đảm bảo Chất lượng (QA) kiểm tra và thử nghiệm nguyên mẫu sản phẩm để phát hiện các khuyết tật của nó.

• Product production planning- Trong giai đoạn này, quá trình sản xuất và công cụ được thiết kế và chuẩn bị. Giai đoạn này cũng cung cấp cơ hội để kiểm tra sản phẩm để phát hiện các khuyết tật không được chú ý trong giai đoạn phát triển.

• Manufacturing- Trong giai đoạn này, các thủ tục QA được áp dụng để tự phát hiện các hư hỏng của sản phẩm. Các khiếm khuyết trong sản phẩm được phát hiện trong giai đoạn đầu tiên của quá trình sản xuất thường có thể được sửa chữa bằng cách thay đổi thiết kế hoặc vật liệu của sản phẩm hoặc trong công cụ sản xuất, theo cách loại bỏ các khiếm khuyết đó trong các sản phẩm được sản xuất trong tương lai.

Tuy nhiên, trong trường hợp phần mềm, giai đoạn duy nhất có thể phát hiện ra các khiếm khuyết là giai đoạn phát triển. Trong trường hợp có phần mềm, các giai đoạn lập kế hoạch sản xuất và sản xuất sản phẩm không bắt buộc vì việc sản xuất các bản sao phần mềm và in sổ tay phần mềm được tiến hành tự động.

Các yếu tố ảnh hưởng đến việc phát hiện lỗi trong sản phẩm phần mềm so với các sản phẩm công nghiệp khác được trình bày trong bảng sau.

Đặc tính	Sản phẩm phần mềm	Các sản phẩm công nghiệp khác
Phức tạp	Hàng triệu tùy chọn hoạt động	hàng nghìn lựa chọn hoạt động
khả năng hiển thị của sản phẩm	Sản phẩm vô hình Khó phát hiện khuyết tật bằng mắt thường	Sản phẩm có thể nhìn thấy Phát hiện hiệu quả các khuyết tật bằng mắt
Bản chất của quá trình phát triển và sản xuất	có thể sửa lỗi chỉ trong một giai đoạn	có thể phát hiện các khuyết tật trong tất cả các giai đoạn sau Phát triển sản phẩm Lập kế hoạch sản xuất sản phẩm Manufacturing

Những đặc điểm này của phần mềm như tính phức tạp và khả năng tàng hình làm cho việc phát triển phương pháp luận đảm bảo chất lượng phần mềm và triển khai thành công nó là một thách thức chuyên môn cao.

Các yếu tố khác nhau, ảnh hưởng đến phần mềm, được gọi là các yếu tố phần mềm. Chúng có thể được chia thành hai loại. Loại đầu tiên của các yếu tố là những yếu tố có thể được đo lường trực tiếp như số lỗi lôgic, và loại thứ hai bao gồm những yếu tố chỉ có thể đo lường gián tiếp. Ví dụ, khả năng bảo trì nhưng mỗi yếu tố phải được đo lường để kiểm tra nội dung và kiểm soát chất lượng.

Một số mô hình về các yếu tố chất lượng phần mềm và phân loại chúng đã được đề xuất trong nhiều năm. Mô hình cổ điển về các yếu tố chất lượng phần mềm, do McCall đề xuất, bao gồm 11 yếu tố (McCall và cộng sự, 1977). Tương tự, các mô hình bao gồm 12 đến 15 yếu tố, được đề xuất bởi Deutsch và Willis (1988) và Evans và Marciniak (1987).

Tất cả các mô hình này về cơ bản không khác mô hình của McCall. Mô hình nhân tố McCall cung cấp một phương pháp thực tế, cập nhật để phân loại các yêu cầu phần mềm (Pressman, 2000).

Mô hình nhân tố của McCall

Mô hình này phân loại tất cả các yêu cầu phần mềm thành 11 yếu tố chất lượng phần mềm. 11 yếu tố được nhóm thành ba loại - hoạt động sản phẩm, sửa đổi sản phẩm và các yếu tố chuyển đổi sản phẩm.

• Product operation factors - Tính đúng đắn, độ tin cậy, tính hiệu quả, tính toàn vẹn, tính khả dụng.

• Product revision factors - Khả năng bảo trì, tính linh hoạt, khả năng kiểm tra.

• Product transition factors - Khả năng di động, Khả năng tái sử dụng, Khả năng tương tác.

Yếu tố chất lượng phần mềm vận hành sản phẩm

Theo mô hình của McCall, hạng mục hoạt động của sản phẩm bao gồm năm yếu tố chất lượng phần mềm, giải quyết các yêu cầu ảnh hưởng trực tiếp đến hoạt động hàng ngày của phần mềm. Chúng như sau:

Tính đúng đắn

Các yêu cầu này liên quan đến tính đúng đắn của đầu ra của hệ thống phần mềm. Chúng bao gồm -

• Nhiệm vụ đầu ra

• Độ chính xác cần thiết của đầu ra có thể bị ảnh hưởng tiêu cực bởi dữ liệu không chính xác hoặc tính toán không chính xác.

• Tính đầy đủ của thông tin đầu ra, có thể bị ảnh hưởng bởi dữ liệu không đầy đủ.

• Tính cập nhật của thông tin được hệ thống phần mềm xác định là thời gian giữa sự kiện và phản hồi.

• Sự sẵn có của thông tin.

• Các tiêu chuẩn để mã hóa và lập tài liệu hệ thống phần mềm.

độ tin cậy

Các yêu cầu về độ tin cậy đối phó với lỗi dịch vụ. Chúng xác định tỷ lệ lỗi tối đa cho phép của hệ thống phần mềm, và có thể đề cập đến toàn bộ hệ thống hoặc một hoặc nhiều chức năng riêng biệt của nó.

Hiệu quả

Nó xử lý các tài nguyên phần cứng cần thiết để thực hiện các chức năng khác nhau của hệ thống phần mềm. Nó bao gồm khả năng xử lý (tính bằng MHz), dung lượng lưu trữ (tính bằng MB hoặc GB) và khả năng giao tiếp dữ liệu (tính bằng MBPS hoặc GBPS).

Nó cũng đề cập đến thời gian giữa việc sạc lại các thiết bị di động của hệ thống, chẳng hạn như các đơn vị hệ thống thông tin được đặt trong máy tính xách tay hoặc các đơn vị khí tượng đặt ngoài trời.

Chính trực

Yếu tố này liên quan đến bảo mật hệ thống phần mềm, nghĩa là, để ngăn chặn truy cập của những người không được phép, cũng để phân biệt giữa nhóm người được cấp phép đọc cũng như ghi.

Khả năng sử dụng

Các yêu cầu về khả năng sử dụng liên quan đến nguồn nhân viên cần thiết để đào tạo một nhân viên mới và vận hành hệ thống phần mềm.

Các yếu tố chất lượng sửa đổi sản phẩm

Theo mô hình của McCall, ba yếu tố chất lượng phần mềm được đưa vào danh mục sửa đổi sản phẩm. Các yếu tố này như sau:

Khả năng bảo trì

Yếu tố này xem xét những nỗ lực cần thiết của người dùng và nhân viên bảo trì để xác định lý do gây ra lỗi phần mềm, sửa chữa lỗi và xác minh sự thành công của việc sửa chữa.

Uyển chuyển

Yếu tố này đề cập đến các khả năng và nỗ lực cần thiết để hỗ trợ các hoạt động bảo trì thích ứng của phần mềm. Chúng bao gồm việc điều chỉnh phần mềm hiện tại cho phù hợp với hoàn cảnh bổ sung và khách hàng mà không cần thay đổi phần mềm. Các yêu cầu của yếu tố này cũng hỗ trợ các hoạt động bảo trì hoàn hảo, chẳng hạn như các thay đổi và bổ sung đối với phần mềm để cải thiện dịch vụ của nó và để nó thích ứng với những thay đổi trong môi trường kỹ thuật hoặc thương mại của công ty.

Khả năng kiểm tra

Các yêu cầu về khả năng kiểm thử liên quan đến việc kiểm thử hệ thống phần mềm cũng như hoạt động của nó. Nó bao gồm các kết quả trung gian được xác định trước, tệp nhật ký và cũng như chẩn đoán tự động được thực hiện bởi hệ thống phần mềm trước khi khởi động hệ thống, để tìm hiểu xem tất cả các thành phần của hệ thống có hoạt động theo thứ tự hay không và nhận được báo cáo về các lỗi đã phát hiện. Một loại yêu cầu khác đề cập đến việc kiểm tra chẩn đoán tự động do các kỹ thuật viên bảo trì áp dụng để phát hiện nguyên nhân của lỗi phần mềm.

Yếu tố chất lượng phần mềm chuyển đổi sản phẩm

Theo mô hình của McCall, ba yếu tố chất lượng phần mềm được bao gồm trong hạng mục chuyển đổi sản phẩm liên quan đến sự thích ứng của phần mềm với các môi trường khác và sự tương tác của nó với các hệ thống phần mềm khác. Các yếu tố này như sau:

Tính di động

Các yêu cầu về tính di động có xu hướng thích ứng với một hệ thống phần mềm với các môi trường khác bao gồm các phần cứng khác nhau, các hệ điều hành khác nhau, v.v. Phần mềm sẽ có thể tiếp tục sử dụng cùng một phần mềm cơ bản trong các tình huống khác nhau.

Khả năng tái sử dụng

Yếu tố này liên quan đến việc sử dụng các mô-đun phần mềm được thiết kế ban đầu cho một dự án trong một dự án phần mềm mới hiện đang được phát triển. Chúng cũng có thể cho phép các dự án trong tương lai sử dụng một mô-đun nhất định hoặc một nhóm mô-đun của phần mềm hiện được phát triển. Việc sử dụng lại phần mềm được kỳ vọng sẽ tiết kiệm tài nguyên phát triển, rút ​​ngắn thời gian phát triển và cung cấp các mô-đun chất lượng cao hơn.

Khả năng tương tác

Các yêu cầu về khả năng tương tác tập trung vào việc tạo giao diện với các hệ thống phần mềm khác hoặc với phần sụn thiết bị khác. Ví dụ, phần sụn của máy móc sản xuất và thiết bị thử nghiệm giao diện với phần mềm điều khiển sản xuất.

Software Quality Assurance(SQA) là một tập hợp các hoạt động để đảm bảo chất lượng trong các quy trình kỹ thuật phần mềm. Nó đảm bảo rằng phần mềm được phát triển đáp ứng và tuân thủ các thông số chất lượng đã xác định hoặc tiêu chuẩn hóa. SQA là một quá trình liên tục trong Vòng đời Phát triển Phần mềm (SDLC) nhằm kiểm tra thường xuyên phần mềm được phát triển để đảm bảo phần mềm đó đáp ứng các biện pháp chất lượng mong muốn.

Thực hành SQA được thực hiện trong hầu hết các loại hình phát triển phần mềm, bất kể mô hình phát triển phần mềm cơ bản đang được sử dụng. SQA kết hợp và thực hiện các phương pháp kiểm thử phần mềm để kiểm tra phần mềm. Thay vì kiểm tra chất lượng sau khi hoàn thành, SQA xử lý kiểm tra chất lượng trong từng giai đoạn phát triển, cho đến khi phần mềm hoàn chỉnh. Với SQA, quá trình phát triển phần mềm chỉ chuyển sang giai đoạn tiếp theo khi giai đoạn hiện tại / trước đó tuân thủ các tiêu chuẩn chất lượng yêu cầu. SQA thường hoạt động dựa trên một hoặc nhiều tiêu chuẩn ngành giúp xây dựng các hướng dẫn về chất lượng phần mềm và chiến lược triển khai.

Nó bao gồm các hoạt động sau:

• Định nghĩa và thực hiện quy trình
• Auditing
• Training

Các quá trình có thể là -

• Phương pháp phát triển phần mềm
• Quản lý dự án
• Quản lý cấu hình
• Phát triển / Quản lý yêu cầu
• Estimation
• Thiết kế phần mềm
• Thử nghiệm, v.v.

Khi các quy trình đã được xác định và thực hiện, Đảm bảo chất lượng có các trách nhiệm sau:

• Xác định những điểm yếu trong quy trình
• Sửa chữa những điểm yếu đó để liên tục cải tiến quy trình

Các thành phần của Hệ thống SQA

Một hệ thống SQA luôn kết hợp một loạt các thành phần SQA. Các thành phần này có thể được phân loại thành sáu lớp sau:

Các thành phần tiền dự án

Điều này đảm bảo rằng các cam kết dự án đã được xác định rõ ràng có xem xét các nguồn lực cần thiết, tiến độ và ngân sách; và các kế hoạch phát triển và chất lượng đã được xác định một cách chính xác.

Các thành phần của đánh giá hoạt động vòng đời dự án

Vòng đời của dự án bao gồm hai giai đoạn: giai đoạn vòng đời phát triển và giai đoạn vận hành - bảo trì.

Các thành phần của giai đoạn vòng đời phát triển phát hiện lỗi thiết kế và lập trình. Các thành phần của nó được chia thành các lớp con sau: Đánh giá, Ý kiến ​​chuyên gia và Kiểm thử phần mềm.

Các thành phần SQA được sử dụng trong giai đoạn vận hành - bảo trì bao gồm các thành phần bảo trì chuyên dụng cũng như các thành phần vòng đời phát triển, được áp dụng chủ yếu cho chức năng cải thiện nhiệm vụ bảo trì.

Các thành phần của việc ngăn ngừa và cải thiện lỗi cơ sở hạ tầng

Mục tiêu chính của các thành phần này, được áp dụng trong toàn bộ tổ chức, là loại bỏ hoặc ít nhất là giảm tỷ lệ sai sót, dựa trên kinh nghiệm SQA tích lũy của tổ chức.

Các thành phần của quản lý chất lượng phần mềm

Nhóm thành phần này đề cập đến một số mục tiêu, chẳng hạn như kiểm soát các hoạt động phát triển và bảo trì, và đưa ra các hành động hỗ trợ quản lý sớm chủ yếu ngăn ngừa hoặc giảm thiểu các thất bại về lịch trình, ngân sách và kết quả của chúng.

Các thành phần của tiêu chuẩn hóa, chứng nhận và đánh giá hệ thống SQA

Các thành phần này thực hiện các tiêu chuẩn quốc tế về chuyên môn và quản lý trong tổ chức. Các mục tiêu chính của lớp này là sử dụng kiến ​​thức chuyên môn quốc tế, cải thiện sự phối hợp của hệ thống chất lượng của tổ chức với các tổ chức khác và đánh giá những thành tựu của hệ thống chất lượng theo một thang điểm chung. Các tiêu chuẩn khác nhau có thể được phân thành hai nhóm chính: tiêu chuẩn quản lý chất lượng và tiêu chuẩn quy trình dự án.

Tổ chức cho SQA - các thành phần con người

Cơ sở tổ chức của SQA bao gồm các nhà quản lý, nhân viên kiểm thử, đơn vị SQA và những người quan tâm đến chất lượng phần mềm như ủy viên SQA, thành viên ủy ban SQA và thành viên diễn đàn SQA. Mục tiêu chính của họ là khởi xướng và hỗ trợ việc thực hiện các thành phần của SQA, phát hiện các sai lệch so với các quy trình và phương pháp luận của SQA, đồng thời đề xuất các cải tiến.

Các thành phần chất lượng phần mềm tiền dự án

Các thành phần này giúp cải thiện các bước sơ bộ được thực hiện trước khi bắt đầu một dự án. Nó bao gồm -

• Xem xét hợp đồng
• Kế hoạch phát triển và chất lượng

Xem xét hợp đồng

Thông thường, một phần mềm được phát triển cho một hợp đồng được thương lượng với khách hàng hoặc cho một đơn đặt hàng nội bộ để phát triển một phần sụn để được nhúng trong một sản phẩm phần cứng. Trong tất cả các trường hợp này, đơn vị phát triển cam kết thực hiện theo thỏa thuận về đặc điểm kỹ thuật chức năng, ngân sách và lịch trình. Do đó, hoạt động rà soát hợp đồng phải bao gồm việc kiểm tra chi tiết dự thảo đề xuất dự án và các dự thảo hợp đồng.

Cụ thể, các hoạt động xem xét hợp đồng bao gồm:

• Làm rõ các yêu cầu của khách hàng

• Xem xét lịch trình của dự án và ước tính yêu cầu nguồn lực

• Đánh giá năng lực của nhân viên chuyên môn để thực hiện dự án đề xuất

• Đánh giá năng lực thực hiện nghĩa vụ của khách hàng

• Đánh giá rủi ro phát triển

Kế hoạch phát triển và chất lượng

Sau khi ký hợp đồng phát triển phần mềm với một tổ chức hoặc một bộ phận nội bộ của cùng một tổ chức, một kế hoạch phát triển của dự án và các hoạt động đảm bảo chất lượng tích hợp của nó được chuẩn bị. Các kế hoạch này bao gồm các chi tiết bổ sung và các bản sửa đổi cần thiết dựa trên các kế hoạch trước đó tạo cơ sở cho đề xuất và hợp đồng hiện tại.

Hầu hết thời gian, phải mất vài tháng từ khi nộp thầu cho đến khi ký kết hợp đồng. Trong giai đoạn này, các nguồn lực như đội ngũ nhân viên sẵn có, năng lực chuyên môn có thể bị thay đổi. Các kế hoạch sau đó được sửa đổi để phản ánh những thay đổi xảy ra trong thời gian tạm thời.

Các vấn đề chính được xử lý trong kế hoạch phát triển dự án là:

• Schedules
• Nhân lực và tài nguyên phần cứng cần thiết
• Đánh giá rủi ro
• Các vấn đề về tổ chức: thành viên nhóm, nhà thầu phụ và quan hệ đối tác
• Phương pháp luận dự án, công cụ phát triển, v.v.
• Kế hoạch tái sử dụng phần mềm

Các vấn đề chính được xử lý trong kế hoạch chất lượng của dự án là -

• Mục tiêu chất lượng, được thể hiện bằng các thuật ngữ có thể đo lường thích hợp

• Tiêu chí bắt đầu và kết thúc từng giai đoạn dự án

• Danh sách các bài đánh giá, bài kiểm tra và các hoạt động xác minh và xác nhận theo lịch trình khác

Các chỉ số phần mềm có thể được phân thành ba loại:

• Product metrics - Mô tả các đặc tính của sản phẩm như kích thước, độ phức tạp, tính năng thiết kế, hiệu suất và mức chất lượng.

• Process metrics - Những đặc điểm này có thể được sử dụng để cải thiện các hoạt động phát triển và bảo trì của phần mềm.

• Project metrics- Số liệu này mô tả các đặc điểm của dự án và việc thực hiện. Ví dụ bao gồm số lượng nhà phát triển phần mềm, mô hình nhân sự trong vòng đời của phần mềm, chi phí, lịch trình và năng suất.

Một số chỉ số thuộc nhiều danh mục. Ví dụ: số liệu chất lượng trong quá trình của một dự án vừa là số liệu quá trình vừa là số liệu của dự án.

Software quality metricslà một tập hợp con các chỉ số phần mềm tập trung vào các khía cạnh chất lượng của sản phẩm, quy trình và dự án. Các chỉ số này liên quan chặt chẽ với các chỉ số về quy trình và sản phẩm hơn là với các chỉ số của dự án.

Các chỉ số chất lượng phần mềm có thể được chia thành ba loại:

• Chỉ số chất lượng sản phẩm
• Chỉ số chất lượng trong quá trình
• Chỉ số chất lượng bảo trì

Chỉ số chất lượng sản phẩm

Các chỉ số này bao gồm những điều sau:

• Thời gian thất bại trung bình
• Mật độ khuyết tật
• Vấn đề của khách hàng
• Sự hài lòng của khách hàng

Thời gian thất bại trung bình

Đó là khoảng thời gian giữa những lần thất bại. Chỉ số này chủ yếu được sử dụng với các hệ thống quan trọng về an toàn như hệ thống kiểm soát giao thông hàng không, hệ thống điện tử hàng không và vũ khí.

Mật độ khuyết tật

Nó đo lường các khuyết tật liên quan đến kích thước phần mềm được biểu thị dưới dạng các dòng mã hoặc điểm chức năng, v.v. tức là, nó đo chất lượng mã trên mỗi đơn vị. Số liệu này được sử dụng trong nhiều hệ thống phần mềm thương mại.

Vấn đề của khách hàng

Nó đo lường những vấn đề mà khách hàng gặp phải khi sử dụng sản phẩm. Nó chứa đựng quan điểm của khách hàng đối với không gian vấn đề của phần mềm, bao gồm các vấn đề định hướng không lỗi cùng với các vấn đề lỗi.

Chỉ số vấn đề thường được thể hiện dưới dạng Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Ở đâu,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM thường được tính cho mỗi tháng sau khi phần mềm được phát hành ra thị trường và cũng cho mức trung bình hàng tháng theo năm.

Sự hài lòng của khách hàng

Sự hài lòng của khách hàng thường được đo lường bằng dữ liệu khảo sát khách hàng thông qua thang năm điểm -

• Rất hài lòng
• Satisfied
• Neutral
• Dissatisfied
• Rất không hài lòng

Sự hài lòng với chất lượng tổng thể của sản phẩm và các kích thước cụ thể của nó thường có được thông qua nhiều phương pháp khảo sát khách hàng. Dựa trên dữ liệu thang năm điểm, một số chỉ số có sự thay đổi nhỏ có thể được xây dựng và sử dụng, tùy thuộc vào mục đích phân tích. Ví dụ -

• Phần trăm khách hàng hoàn toàn hài lòng
• Phần trăm khách hàng hài lòng
• Phần trăm khách hàng không hài lòng
• Phần trăm khách hàng không hài lòng

Thông thường, phần trăm sự hài lòng này được sử dụng.

Chỉ số chất lượng trong quá trình

Các thước đo chất lượng trong quá trình liên quan đến việc theo dõi sự xuất hiện của lỗi trong quá trình thử nghiệm máy chính thức đối với một số tổ chức. Chỉ số này bao gồm -

• Mật độ khuyết tật trong quá trình kiểm tra máy
• Mẫu xuất hiện khiếm khuyết trong quá trình kiểm tra máy
• Mẫu loại bỏ khuyết tật dựa trên giai đoạn
• Hiệu quả loại bỏ khiếm khuyết

Mật độ khuyết tật trong quá trình kiểm tra máy

Tỷ lệ sai sót trong quá trình kiểm tra máy chính thức (kiểm tra sau khi mã được tích hợp vào thư viện hệ thống) tương quan với tỷ lệ lỗi trong hiện trường. Tỷ lệ sai sót cao hơn được tìm thấy trong quá trình thử nghiệm là một chỉ báo cho thấy phần mềm đã bị tiêm lỗi cao hơn trong quá trình phát triển của nó, trừ khi tỷ lệ lỗi thử nghiệm cao hơn là do nỗ lực thử nghiệm bất thường.

Chỉ số lỗi đơn giản này trên mỗi KLOC hoặc điểm chức năng là một chỉ báo tốt về chất lượng, trong khi phần mềm vẫn đang được thử nghiệm. Nó đặc biệt hữu ích để theo dõi các bản phát hành tiếp theo của một sản phẩm trong cùng một tổ chức phát triển.

Mẫu xuất hiện khiếm khuyết trong quá trình kiểm tra máy

Mật độ khuyết tật tổng thể trong quá trình thử nghiệm sẽ chỉ cung cấp tóm tắt về các khuyết tật. Các mẫu lỗi đến cung cấp thêm thông tin về các mức chất lượng khác nhau trong lĩnh vực này. Nó bao gồm những điều sau:

• Các lỗi đến hoặc lỗi được báo cáo trong giai đoạn thử nghiệm theo khoảng thời gian (ví dụ: tuần). Ở đây tất cả sẽ không phải là khuyết tật hợp lệ.

• Mẫu lỗi hợp lệ xuất hiện khi việc xác định vấn đề được thực hiện trên các vấn đề được báo cáo. Đây là mẫu khuyết tật thực sự.

• Mô hình tồn đọng khiếm khuyết ngoài giờ. Số liệu này là cần thiết vì các tổ chức phát triển không thể điều tra và khắc phục tất cả các vấn đề được báo cáo ngay lập tức. Đây là một tuyên bố khối lượng công việc cũng như một tuyên bố chất lượng. Nếu tồn đọng khiếm khuyết lớn vào cuối chu kỳ phát triển và nhiều bản sửa lỗi vẫn chưa được tích hợp vào hệ thống, tính ổn định của hệ thống (do đó chất lượng của nó) sẽ bị ảnh hưởng. Kiểm tra lại (kiểm tra hồi quy) là cần thiết để đảm bảo đạt được các mức chất lượng sản phẩm mục tiêu.

Mẫu loại bỏ khuyết tật dựa trên giai đoạn

Đây là phần mở rộng của thước đo mật độ khuyết tật trong quá trình thử nghiệm. Ngoài việc kiểm tra, nó còn theo dõi các lỗi ở tất cả các giai đoạn của chu kỳ phát triển, bao gồm cả việc xem xét thiết kế, kiểm tra mã và xác minh chính thức trước khi kiểm tra.

Bởi vì một tỷ lệ lớn các lỗi lập trình liên quan đến các vấn đề thiết kế, việc tiến hành đánh giá chính thức hoặc xác minh chức năng để nâng cao khả năng loại bỏ lỗi của quy trình ở front-end sẽ giảm lỗi trong phần mềm. Mô hình loại bỏ khuyết tật theo giai đoạn phản ánh khả năng loại bỏ khuyết tật tổng thể của quá trình phát triển.

Đối với các thước đo cho giai đoạn thiết kế và mã hóa, ngoài tỷ lệ sai sót, nhiều tổ chức phát triển sử dụng các thước đo như phạm vi kiểm tra và nỗ lực kiểm tra để quản lý chất lượng trong quá trình.

Hiệu quả loại bỏ khiếm khuyết

Nó có thể được định nghĩa như sau:

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Số liệu này có thể được tính toán cho toàn bộ quá trình phát triển, cho giao diện người dùng trước khi tích hợp mã và cho từng giai đoạn. Nó được gọi làearly defect removal khi được sử dụng cho giao diện người dùng và phase effectivenesscho các giai đoạn cụ thể. Giá trị của số liệu càng cao, quá trình phát triển càng hiệu quả và càng ít khuyết tật được chuyển sang giai đoạn tiếp theo hoặc hiện trường. Số liệu này là một khái niệm chính của mô hình loại bỏ lỗi để phát triển phần mềm.

Chỉ số chất lượng bảo trì

Mặc dù không thể làm gì nhiều để thay đổi chất lượng của sản phẩm trong giai đoạn này, nhưng sau đây là các biện pháp sửa chữa có thể được thực hiện để loại bỏ các khuyết tật càng sớm càng tốt với chất lượng sửa chữa tuyệt vời.

• Sửa chỉ mục quản lý tồn đọng và tồn đọng
• Sửa thời gian phản hồi và sửa khả năng phản hồi
• Phần trăm sửa lỗi quá hạn
• Sửa chữa chất lượng

Sửa chỉ mục quản lý tồn đọng và tồn đọng

Khắc phục tồn đọng liên quan đến tỷ lệ lỗi đến và tốc độ có sẵn các bản sửa lỗi cho các vấn đề được báo cáo. Đó là một số lượng đơn giản các vấn đề được báo cáo vẫn còn vào cuối mỗi tháng hoặc mỗi tuần. Sử dụng nó ở định dạng biểu đồ xu hướng, số liệu này có thể cung cấp thông tin có ý nghĩa để quản lý quy trình bảo trì.

Chỉ số quản lý tồn đọng (BMI) được sử dụng để quản lý tồn đọng của các vấn đề đang mở và chưa được giải quyết.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Nếu BMI lớn hơn 100, nghĩa là lượng công việc tồn đọng giảm xuống. Nếu BMI dưới 100, thì lượng công việc tồn đọng sẽ tăng lên.

Sửa thời gian phản hồi và sửa khả năng phản hồi

Chỉ số thời gian phản hồi khắc phục thường được tính là thời gian trung bình của tất cả các sự cố từ mở đến đóng. Thời gian phản hồi sửa chữa ngắn dẫn đến sự hài lòng của khách hàng.

Các yếu tố quan trọng của khả năng đáp ứng sửa chữa là kỳ vọng của khách hàng, thời gian đã thỏa thuận để sửa và khả năng đáp ứng cam kết của một người với khách hàng.

Phần trăm sửa lỗi quá hạn

Nó được tính như sau:

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Sửa chữa chất lượng

Chất lượng sửa chữa hoặc số lượng sửa chữa lỗi là một thước đo chất lượng quan trọng khác cho giai đoạn bảo trì. Bản sửa lỗi bị lỗi nếu nó không khắc phục được sự cố được báo cáo hoặc nếu nó đã khắc phục được sự cố ban đầu nhưng lại đưa vào một lỗi mới. Đối với phần mềm quan trọng trong sứ mệnh, các bản sửa lỗi có thể gây hại cho sự hài lòng của khách hàng. Chỉ số phần trăm các bản sửa lỗi bị lỗi là phần trăm của tất cả các bản sửa lỗi trong một khoảng thời gian bị lỗi.

Việc khắc phục lỗi có thể được ghi theo hai cách: Ghi vào tháng nó được phát hiện hoặc ghi vào tháng đã giao sửa. Đầu tiên là thước đo khách hàng; thứ hai là một biện pháp quy trình. Sự khác biệt giữa hai ngày là khoảng thời gian tiềm ẩn của việc sửa lỗi.

Thông thường, thời gian chờ càng dài thì càng có nhiều khách hàng bị ảnh hưởng. Nếu số lượng khuyết tật lớn, thì giá trị nhỏ của số liệu phần trăm sẽ cho thấy một bức tranh lạc quan. Tất nhiên, mục tiêu chất lượng cho quá trình bảo trì là không có lỗi sửa chữa mà không vi phạm.

Đo lường là hành động đo lường một cái gì đó. Nó là sự gán một số cho một đặc tính của một đối tượng hoặc sự kiện, có thể được so sánh với các đối tượng hoặc sự kiện khác.

Về mặt hình thức, nó có thể được định nghĩa là, quá trình mà các số hoặc ký hiệu được gán cho các thuộc tính của các thực thể trong thế giới thực, theo cách mô tả chúng theo các quy tắc được xác định rõ ràng.

Đo lường trong cuộc sống hàng ngày

Đo lường không chỉ được sử dụng bởi các nhà công nghệ chuyên nghiệp, mà còn được sử dụng bởi tất cả chúng ta trong cuộc sống hàng ngày. Trong một cửa hàng, giá cả đóng vai trò là thước đo giá trị của một mặt hàng. Tương tự, các phép đo chiều cao và kích thước sẽ đảm bảo liệu vải có vừa vặn hay không. Do đó, phép đo sẽ giúp chúng ta so sánh một mặt hàng với một mặt hàng khác.

Phép đo lấy thông tin về các thuộc tính của các thực thể. Thực thể là một đối tượng chẳng hạn như một người hoặc một sự kiện chẳng hạn như một cuộc hành trình trong thế giới thực. Thuộc tính là một đặc điểm hoặc thuộc tính của một thực thể như chiều cao của một người, chi phí của một cuộc hành trình, v.v. Trong thế giới thực, mặc dù chúng ta đang nghĩ đến việc đo lường các thứ, nhưng thực ra chúng ta đang đo các thuộc tính của những thứ đó.

Các thuộc tính chủ yếu được xác định bằng số hoặc ký hiệu. Ví dụ, giá có thể được chỉ định bằng số rupee hoặc đô la, kích cỡ quần áo có thể được chỉ định theo kích thước nhỏ, vừa, lớn.

Độ chính xác của phép đo phụ thuộc vào dụng cụ đo cũng như định nghĩa của phép đo. Sau khi có được các phép đo, chúng tôi phải phân tích chúng và chúng tôi phải đưa ra kết luận về các thực thể.

Phép đo là phép định lượng trực tiếp trong khi phép tính là phép tính gián tiếp, trong đó chúng ta kết hợp các phép đo khác nhau bằng một số công thức.

Đo lường trong kỹ thuật phần mềm

Kỹ thuật phần mềm bao gồm quản lý, chi phí, lập kế hoạch, mô hình hóa, phân tích, chỉ định, thiết kế, triển khai, thử nghiệm và duy trì các sản phẩm phần mềm. Do đó, đo lường đóng một vai trò quan trọng trong kỹ thuật phần mềm. Một cách tiếp cận nghiêm ngặt sẽ là cần thiết để đo lường các thuộc tính của một sản phẩm phần mềm.

Đối với hầu hết các dự án phát triển,

• Chúng tôi không đặt mục tiêu có thể đo lường được cho các sản phẩm phần mềm của mình
• Chúng tôi không hiểu và định lượng chi phí thành phần của các dự án phần mềm
• Chúng tôi không định lượng hoặc dự đoán chất lượng của sản phẩm chúng tôi sản xuất

Vì vậy, để kiểm soát các sản phẩm phần mềm, việc đo lường các thuộc tính là cần thiết. Mọi hành động đo lường phải được thúc đẩy bởi một mục tiêu hoặc nhu cầu cụ thể được xác định rõ ràng và dễ hiểu. Các mục tiêu đo lường phải cụ thể, cố gắng đạt được những điều mà người quản lý, nhà phát triển và người dùng cần biết. Đo lường là cần thiết để đánh giá tình trạng của dự án, sản phẩm, quy trình và nguồn lực.

Trong kỹ thuật phần mềm, đo lường là cần thiết cho ba hoạt động cơ bản sau:

• Để hiểu những gì đang xảy ra trong quá trình phát triển và bảo trì
• Để kiểm soát những gì đang xảy ra trong dự án
• Để cải thiện các quy trình và mục tiêu

Lý thuyết đại diện về đo lường

Phép đo cho chúng ta biết các quy tắc đặt nền móng cho việc phát triển và lý luận về tất cả các loại phép đo. Nó là ánh xạ từ thế giới thực nghiệm sang thế giới quan hệ chính thức. Do đó, thước đo là số hoặc ký hiệu được gán cho một thực thể bằng cách ánh xạ này nhằm mô tả đặc điểm của một thực thể.

Mối quan hệ thực nghiệm

Trong thế giới thực, chúng ta hiểu mọi thứ bằng cách so sánh chúng, không phải bằng cách gán các con số cho chúng.

Ví dụ: để so sánh chiều cao, chúng tôi sử dụng các thuật ngữ 'cao hơn', cao hơn '. Vì vậy, những 'cao hơn', cao hơn 'là các quan hệ thực nghiệm cho chiều cao.

Chúng ta có thể xác định nhiều hơn một quan hệ thực nghiệm trên cùng một tập hợp.

Ví dụ, X cao hơn Y. X, Y cao hơn Z nhiều.

Các quan hệ thực nghiệm có thể là một bậc, nhị phân, bậc ba, v.v.

X cao, Y không cao là quan hệ một ngôi.

X cao hơn Y là một quan hệ nhị phân.

Các quan hệ thực nghiệm trong thế giới thực có thể được ánh xạ đến một thế giới toán học chính thức. Chủ yếu những mối quan hệ này phản ánh sở thích cá nhân.

Một số kỹ thuật ánh xạ hoặc đánh giá được sử dụng để ánh xạ các mối quan hệ thực nghiệm này với thế giới toán học như sau:

Thang đo Likert

Tại đây, người dùng sẽ được đưa ra một tuyên bố mà họ phải đồng ý hoặc không đồng ý.

For example - Phần mềm này hoạt động tốt.

Hoàn toàn đồng ý	Đồng ý	Không đồng ý cũng chẳng phản bác	Không đồng ý	Hoàn toàn không đồng ý

Xếp hạng cưỡng bức

Thứ tự các lựa chọn thay thế đã cho từ 1 (tốt nhất) đến n (xấu nhất).

Ví dụ: Xếp hạng 5 mô-đun phần mềm sau theo hiệu suất của chúng.

Tên mô-đun	Cấp
Mô-đun A
Mô-đun B
Mô-đun C
Mô-đun D
Mô-đun E

Thang tần số bằng lời nói

For example - Bao lâu thì chương trình này bị lỗi?

Luôn luôn	Thường	Đôi khi	Ít khi	Không bao giờ

Thang đo thông thường

Tại đây, người dùng sẽ được cung cấp một danh sách các lựa chọn thay thế và họ phải chọn một.

For example - Bao lâu thì chương trình này bị lỗi?

• Hourly
• Daily
• Weekly
• Monthly
• Vài lần một năm
• Một lần hoặc hai lần một năm
• Never

Quy mô so sánh

Ở đây, người dùng phải đưa ra một con số bằng cách so sánh các tùy chọn khác nhau.

Very superiorAbout the sameVery inferior

12345678910

Thang số

Ở đây, người dùng phải đưa ra một số theo mức độ quan trọng của nó.

UnimportantImportant

12345678910

Quy tắc lập bản đồ

Để thực hiện ánh xạ, chúng ta phải xác định miền, phạm vi cũng như các quy tắc để thực hiện ánh xạ.

For example - Miền - Thế giới thực

• Range - Thế giới toán học như số nguyên, số thực, v.v.

• Rules - Để đo chiều cao, giày có mang hay không

Tương tự, trong trường hợp đo lường phần mềm, danh sách kiểm tra của câu lệnh được đưa vào các dòng mã sẽ được chỉ định.

Điều kiện đại diện của phép đo

Điều kiện biểu diễn khẳng định rằng một ánh xạ đo lường (M) phải ánh xạ các thực thể thành số, và quan hệ thực nghiệm thành quan hệ số theo cách mà quan hệ thực nghiệm bảo toàn và được bảo toàn bởi quan hệ số.

Ví dụ: Quan hệ thực nghiệm 'cao hơn' được ánh xạ tới quan hệ số '>'. Tức là, X is taller than Y, if and only if M(X) > M(Y)

Vì có thể có nhiều quan hệ trên một tập hợp nhất định nên điều kiện biểu diễn cũng có ý nghĩa đối với mỗi quan hệ này.

Đối với quan hệ một ngôi 'là cao', chúng ta có thể có quan hệ số

X > 50

Điều kiện đại diện yêu cầu điều đó đối với bất kỳ biện pháp nào M,

X is tall if and only if M(X) > 50

Các giai đoạn chính của đo lường chính thức

Các giai đoạn đo lường chính có thể được tóm tắt như sau:

Mô hình rất hữu ích để giải thích hành vi của các phần tử số của các thực thể trong thế giới thực cũng như đo lường chúng. Để giúp quá trình đo, mô hình ánh xạ cũng cần được bổ sung với một mô hình của miền ánh xạ. Một mô hình cũng nên chỉ rõ các thực thể này có liên quan như thế nào với các thuộc tính và cách các đặc tính liên quan.

Phép đo có hai loại -

• Đo trực tiếp
• Đo lường gián tiếp

Đo lường trực tiếp

Đây là các phép đo có thể được đo lường mà không cần sự tham gia của bất kỳ thực thể hoặc thuộc tính nào khác.

Các biện pháp trực tiếp sau đây thường được sử dụng trong kỹ thuật phần mềm.

• Độ dài của mã nguồn theo LOC
• Thời lượng của mục đích thử nghiệm theo thời gian đã trôi qua
• Số lượng khuyết tật được phát hiện trong quá trình thử nghiệm bằng cách đếm các khuyết tật
• Thời gian một lập trình viên dành cho một chương trình

Đo lường gián tiếp

Đây là những phép đo có thể được đo theo bất kỳ thực thể hoặc thuộc tính nào khác.

Các biện pháp gián tiếp sau đây thường được sử dụng trong kỹ thuật phần mềm.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Đo lường để dự đoán

Để phân bổ các nguồn lực thích hợp cho dự án, chúng ta cần dự đoán nỗ lực, thời gian và chi phí để phát triển dự án. Phép đo để dự đoán luôn yêu cầu một mô hình toán học liên hệ các thuộc tính được dự đoán với một số thuộc tính khác mà chúng ta có thể đo lường ngay bây giờ. Do đó, một hệ thống dự đoán bao gồm một mô hình toán học cùng với một tập hợp các thủ tục dự đoán để xác định các tham số chưa biết và giải thích kết quả.

Các thang đo lường là các ánh xạ được sử dụng để biểu diễn hệ thống quan hệ thực nghiệm. Nó chủ yếu có 5 loại -

• Quy mô danh nghĩa
• Thang đo thông thường
• Thang đo khoảng thời gian
• Thang đo tỉ lệ
• Quy mô tuyệt đối

Quy mô danh nghĩa

Nó đặt các phần tử trong một sơ đồ phân loại. Các lớp học sẽ không được sắp xếp. Mỗi và mọi thực thể nên được đặt trong một lớp hoặc danh mục cụ thể dựa trên giá trị của thuộc tính.

Nó có hai đặc điểm chính -

• Hệ thống quan hệ thực nghiệm chỉ bao gồm các lớp khác nhau; không có khái niệm về thứ tự giữa các lớp.

• Bất kỳ cách đánh số riêng biệt hoặc biểu diễn ký hiệu nào của các lớp đều là một thước đo có thể chấp nhận được, nhưng không có khái niệm về độ lớn liên quan đến các số hoặc ký hiệu.

Thang đo thông thường

Nó đặt các phần tử trong một sơ đồ phân loại có thứ tự. Nó có các đặc điểm sau:

• Hệ thống quan hệ thực nghiệm bao gồm các lớp được sắp xếp theo thuộc tính.

• Mọi ánh xạ duy trì thứ tự đều được chấp nhận.

• Các con số chỉ đại diện cho xếp hạng. Do đó, các phép tính cộng, trừ và số học khác không có ý nghĩa.

Thang đo khoảng thời gian

Thang đo này nắm bắt thông tin về kích thước của các khoảng ngăn cách phân loại. Do đó, nó mạnh hơn thang đo danh nghĩa và thang đo thứ tự.

Nó có các đặc điểm sau:

• Nó bảo toàn trật tự như thang thứ tự.

• Nó bảo toàn sự khác biệt nhưng không bảo toàn tỷ lệ.

• Phép cộng và phép trừ có thể được thực hiện trên thang này nhưng không phải phép nhân hoặc phép chia.

Nếu một thuộc tính có thể đo lường được trên thang khoảng thời gian và M và M’ là các ánh xạ thỏa mãn điều kiện biểu diễn, thì chúng ta luôn có thể tìm được hai số a và b như vậy mà,

M = aM '+ b

Thang đo tỉ lệ

Đây là thang đo hữu ích nhất. Ở đây, tồn tại một quan hệ thực nghiệm để nắm bắt các tỷ lệ. Nó có các đặc điểm sau:

• Nó là một ánh xạ đo lường bảo tồn thứ tự, kích thước của các khoảng giữa các thực thể và tỷ lệ giữa các thực thể.

• Có một phần tử 0, thể hiện tổng số thiếu các thuộc tính.

• Ánh xạ đo lường phải bắt đầu từ 0 và tăng lên trong những khoảng thời gian bằng nhau, được gọi là đơn vị.

• Tất cả các phép toán số học đều có thể được áp dụng.

Ở đây, ánh xạ sẽ có dạng

M = aM’

Ở đâu ‘a’ là một đại lượng vô hướng dương.

Quy mô tuyệt đối

Trên thang đo này, sẽ chỉ có một phép đo khả thi cho một thuộc tính. Do đó, biến đổi duy nhất có thể xảy ra sẽ là biến đổi danh tính.

Nó có các đặc điểm sau:

• Phép đo được thực hiện bằng cách đếm số phần tử trong tập thực thể.

• Thuộc tính luôn có dạng "số lần xuất hiện của x trong thực thể".

• Chỉ có một ánh xạ đo lường khả thi, đó là số đếm thực tế.

• Tất cả các phép toán số học có thể được thực hiện trên kết quả đếm.

Điều tra thực nghiệm liên quan đến việc điều tra khoa học về bất kỳ công cụ, kỹ thuật hoặc phương pháp nào. Cuộc điều tra này chủ yếu bao gồm 4 nguyên tắc sau.

• Chọn một kỹ thuật điều tra
• Nêu giả thuyết
• Duy trì quyền kiểm soát đối với biến
• Làm cho cuộc điều tra có ý nghĩa

Chọn một kỹ thuật điều tra

Các thành phần chính của điều tra thực nghiệm trong kỹ thuật phần mềm là:

• Survey
• Nghiên cứu điển hình
• Thử nghiệm chính thức

Khảo sát

Khảo sát là nghiên cứu hồi cứu một tình huống để ghi lại các mối quan hệ và kết quả. Nó luôn được thực hiện sau khi một sự kiện đã xảy ra. Ví dụ, trong kỹ thuật phần mềm, các cuộc thăm dò có thể được thực hiện để xác định cách người dùng phản ứng với một phương pháp, công cụ hoặc kỹ thuật cụ thể để xác định xu hướng hoặc mối quan hệ.

Trong trường hợp này, chúng ta không thể kiểm soát được tình hình. Chúng tôi có thể ghi lại một tình huống và so sánh nó với một tình huống tương tự.

Nghiên cứu điển hình

Đây là một kỹ thuật nghiên cứu trong đó bạn xác định các yếu tố chính có thể ảnh hưởng đến kết quả của một hoạt động và sau đó ghi lại hoạt động: đầu vào, ràng buộc, nguồn lực và đầu ra của nó.

Thử nghiệm chính thức

Đây là một cuộc điều tra được kiểm soát chặt chẽ về một hoạt động, trong đó các yếu tố chính được xác định và thao tác để ghi lại ảnh hưởng của chúng đối với kết quả.

Một phương pháp điều tra cụ thể có thể được chọn theo các hướng dẫn sau:

• Nếu hoạt động đã diễn ra, chúng tôi có thể thực hiện khảo sát hoặc nghiên cứu điển hình. Nếu nó vẫn chưa xảy ra, thì nghiên cứu điển hình hoặc thử nghiệm chính thức có thể được chọn.

• Nếu chúng ta có mức độ kiểm soát cao đối với các biến có thể ảnh hưởng đến kết quả, thì chúng ta có thể sử dụng thử nghiệm. Nếu chúng ta không kiểm soát được biến, thì nghiên cứu điển hình sẽ là một kỹ thuật ưu tiên.

• Nếu không thể nhân rộng ở các cấp cao hơn thì không thể thử nghiệm.

• Nếu chi phí nhân rộng thấp, thì chúng ta có thể xem xét thử nghiệm.

Nêu giả thuyết

Để thúc đẩy quyết định của một kỹ thuật điều tra cụ thể, mục tiêu của nghiên cứu nên được thể hiện như một giả thuyết mà chúng tôi muốn kiểm tra. Giả thuyết là lý thuyết dự kiến ​​hoặc giả định mà lập trình viên cho rằng giải thích hành vi mà họ muốn khám phá.

Duy trì quyền kiểm soát các biến

Sau khi nêu giả thuyết, tiếp theo chúng ta phải quyết định các biến số khác nhau ảnh hưởng đến sự thật của nó cũng như mức độ kiểm soát của chúng ta đối với nó. Điều này là cần thiết vì yếu tố phân biệt chính giữa thử nghiệm và các nghiên cứu điển hình là mức độ kiểm soát đối với biến ảnh hưởng đến hành vi.

Biến trạng thái là yếu tố có thể đặc trưng cho dự án và cũng có thể ảnh hưởng đến kết quả đánh giá được sử dụng để phân biệt tình huống kiểm soát với tình huống thực nghiệm trong thí nghiệm chính thức. Nếu chúng ta không thể phân biệt kiểm soát với thực nghiệm, kỹ thuật nghiên cứu điển hình sẽ được ưu tiên hơn.

Ví dụ, nếu chúng ta muốn xác định liệu một thay đổi trong ngôn ngữ lập trình có thể ảnh hưởng đến năng suất của dự án hay không, thì ngôn ngữ đó sẽ là một biến trạng thái. Giả sử chúng tôi hiện đang sử dụng FORTRAN mà chúng tôi muốn thay thế bằng Ada. Sau đó FORTRAN sẽ là ngôn ngữ điều khiển và Ada sẽ là ngôn ngữ thử nghiệm.

Làm cho cuộc điều tra có ý nghĩa

Kết quả của một thử nghiệm thường có tính khái quát hơn là nghiên cứu trường hợp hoặc khảo sát. Kết quả của nghiên cứu điển hình hoặc khảo sát thường chỉ có thể áp dụng cho một tổ chức cụ thể. Những điểm sau đây chứng minh hiệu quả của những kỹ thuật này để trả lời nhiều câu hỏi.

Hợp nhất lý thuyết và trí tuệ thông thường

Các nghiên cứu điển hình hoặc khảo sát có thể được sử dụng để phù hợp với tính hiệu quả và tiện ích của trí tuệ thông thường và nhiều tiêu chuẩn, phương pháp hoặc công cụ khác trong một tổ chức. Tuy nhiên, thử nghiệm chính thức có thể điều tra các tình huống mà các tuyên bố nói chung là đúng.

Khám phá các mối quan hệ

Mối quan hệ giữa các thuộc tính khác nhau của tài nguyên và sản phẩm phần mềm có thể được gợi ý bằng một nghiên cứu điển hình hoặc khảo sát.

Ví dụ, một cuộc khảo sát về các dự án đã hoàn thành có thể cho thấy rằng một phần mềm được viết bằng một ngôn ngữ cụ thể có ít lỗi hơn một phần mềm được viết bằng các ngôn ngữ khác.

Hiểu và xác minh các mối quan hệ này là điều cần thiết cho sự thành công của bất kỳ dự án nào trong tương lai. Mỗi mối quan hệ này có thể được thể hiện dưới dạng một giả thuyết và một thí nghiệm chính thức có thể được thiết kế để kiểm tra mức độ giữ các mối quan hệ. Thông thường, giá trị của một thuộc tính cụ thể được quan sát bằng cách giữ các thuộc tính khác không đổi hoặc trong tầm kiểm soát.

Đánh giá độ chính xác của mô hình

Mô hình thường được sử dụng để dự đoán kết quả của một hoạt động hoặc để hướng dẫn việc sử dụng một phương pháp hoặc công cụ. Nó đưa ra một vấn đề đặc biệt khó khi thiết kế một thử nghiệm hoặc nghiên cứu điển hình, bởi vì những dự đoán của chúng thường ảnh hưởng đến kết quả. Các nhà quản lý dự án thường biến các dự đoán thành các mục tiêu để hoàn thành. Hiệu ứng này thường xảy ra khi sử dụng các mô hình chi phí và lịch trình.

Một số mô hình như mô hình độ tin cậy không ảnh hưởng đến kết quả, vì độ tin cậy được đo là thời gian trung bình để xảy ra lỗi không thể được đánh giá cho đến khi phần mềm sẵn sàng để sử dụng tại hiện trường.

Các biện pháp xác thực

Có nhiều biện pháp phần mềm để nắm bắt giá trị của một thuộc tính. Do đó, một nghiên cứu phải được thực hiện để kiểm tra xem một thước đo nhất định có phản ánh những thay đổi trong thuộc tính mà nó được cho là nắm bắt hay không. Việc xác nhận được thực hiện bằng cách so sánh một thước đo này với một thước đo khác. Biện pháp thứ hai cũng là thước đo trực tiếp và hợp lệ đối với yếu tố ảnh hưởng nên được sử dụng để xác nhận. Các biện pháp như vậy không phải lúc nào cũng có sẵn hoặc dễ đo lường. Ngoài ra, các biện pháp được sử dụng phải phù hợp với quan niệm của con người về yếu tố được đo lường.

Khung đo lường phần mềm dựa trên ba nguyên tắc:

• Phân loại các thực thể cần kiểm tra
• Xác định các mục tiêu đo lường có liên quan
• Xác định mức độ trưởng thành mà tổ chức đã đạt được

Phân loại các đối tượng được kiểm tra

Trong kỹ thuật phần mềm, chủ yếu tồn tại ba lớp thực thể. Họ là -

• Processes
• Products
• Resources

Tất cả các thực thể này có thực thể bên trong cũng như bên ngoài.

• Internal attributeslà những thứ có thể được đo lường thuần túy về bản thân quá trình, sản phẩm hoặc tài nguyên. Ví dụ: Kích thước, độ phức tạp, sự phụ thuộc giữa các mô-đun.

• External attributeslà những giá trị chỉ có thể đo được liên quan đến mối quan hệ của nó với môi trường. Ví dụ: Tổng số lỗi mà người dùng gặp phải, khoảng thời gian cần thiết để tìm kiếm cơ sở dữ liệu và truy xuất thông tin.

Các thuộc tính khác nhau có thể được đo lường cho từng thực thể như sau:

Quy trình

Quy trình là tập hợp các hoạt động liên quan đến phần mềm. Sau đây là một số thuộc tính bên trong có thể được đo lường trực tiếp cho một quá trình:

• Thời lượng của quá trình hoặc một trong các hoạt động của nó

• Nỗ lực liên quan đến quá trình hoặc một trong các hoạt động của nó

• Số lượng sự cố của một loại cụ thể phát sinh trong quá trình hoặc một trong các hoạt động của nó

Các thuộc tính bên ngoài khác nhau của một quá trình là chi phí, khả năng kiểm soát, hiệu quả, chất lượng và tính ổn định.

Các sản phẩm

Sản phẩm không chỉ là mặt hàng mà ban quản lý cam kết cung cấp mà còn là bất kỳ hiện vật hoặc tài liệu nào được tạo ra trong vòng đời phần mềm.

Các thuộc tính sản phẩm nội bộ khác nhau là kích thước, nỗ lực, chi phí, đặc điểm kỹ thuật, chiều dài, chức năng, mô đun, tái sử dụng, dự phòng và tính đúng cú pháp. Trong số những kích thước này, công sức và chi phí tương đối dễ đo lường hơn những kích thước khác.

Các thuộc tính sản phẩm bên ngoài khác nhau là khả năng sử dụng, tính toàn vẹn, hiệu quả, khả năng kiểm tra, khả năng tái sử dụng, tính di động và khả năng tương tác. Các thuộc tính này không chỉ mô tả mã mà còn mô tả các tài liệu khác hỗ trợ nỗ lực phát triển.

Tài nguyên

Đây là những thực thể được yêu cầu bởi một hoạt động quy trình. Nó có thể là bất kỳ đầu vào nào cho quá trình sản xuất phần mềm. Nó bao gồm nhân sự, vật liệu, công cụ và phương pháp.

Các thuộc tính bên trong khác nhau của tài nguyên là tuổi, giá, kích thước, tốc độ, dung lượng bộ nhớ, nhiệt độ, v.v. Các thuộc tính bên ngoài khác nhau là năng suất, kinh nghiệm, chất lượng, khả năng sử dụng, độ tin cậy, sự thoải mái, v.v.

Xác định các mục tiêu đo lường có liên quan

Một phép đo cụ thể sẽ chỉ hữu ích nếu nó giúp hiểu quá trình hoặc một trong những sản phẩm kết quả của nó. Việc cải tiến quy trình hoặc sản phẩm chỉ có thể được thực hiện khi dự án đã xác định rõ các mục tiêu cho quy trình và sản phẩm. Sự hiểu biết rõ ràng về các mục tiêu có thể được sử dụng để tạo ra các số liệu được đề xuất cho một dự án nhất định trong bối cảnh của khuôn khổ quá trình hoàn thiện.

Mô hình Mục tiêu – Câu hỏi – Chỉ số (GQM)

Phương pháp GQM cung cấp một khuôn khổ bao gồm ba bước sau:

• Liệt kê các mục tiêu chính của dự án phát triển hoặc bảo trì

• Xuất phát các câu hỏi từ mỗi mục tiêu phải được trả lời để xác định xem các mục tiêu có được đáp ứng hay không

• Quyết định những gì phải được đo lường để có thể trả lời các câu hỏi một cách thỏa đáng

Để sử dụng mô hình GQM, trước tiên chúng tôi thể hiện các mục tiêu tổng thể của tổ chức. Sau đó, chúng tôi tạo ra các câu hỏi sao cho biết câu trả lời để chúng tôi có thể xác định liệu các mục tiêu có được đáp ứng hay không. Sau đó, hãy phân tích từng câu hỏi về phép đo nào chúng ta cần để trả lời từng câu hỏi.

Các mục tiêu điển hình được thể hiện bằng năng suất, chất lượng, rủi ro, sự hài lòng của khách hàng, v.v. Các mục tiêu và câu hỏi phải được xây dựng dựa trên đối tượng của họ.

Để giúp tạo ra các mục tiêu, câu hỏi và số liệu, Basili & Rombach đã cung cấp một loạt các mẫu.

• Purpose - Để (mô tả đặc điểm, đánh giá, dự đoán, thúc đẩy, v.v.) (quy trình, sản phẩm, mô hình, số liệu, v.v.) để hiểu, đánh giá, quản lý, kỹ sư, học hỏi, cải tiến, v.v. Example: Để mô tả đặc điểm của sản phẩm để tìm hiểu nó.

• Perspective - Kiểm tra (chi phí, hiệu quả, tính đúng đắn, khiếm khuyết, thay đổi, biện pháp sản phẩm, v.v.) từ quan điểm của nhà phát triển, người quản lý, khách hàng, v.v. Example: Xem xét các khuyết tật từ quan điểm của khách hàng.

• Environment - Môi trường bao gồm các yếu tố sau: yếu tố quá trình, yếu tố con người, yếu tố vấn đề, phương pháp, công cụ, ràng buộc, v.v. Example: Khách hàng của phần mềm này là những người không có kiến ​​thức về các công cụ.

Đo lường và cải tiến quy trình

Thông thường, phép đo hữu ích cho -

• Hiểu biết về quy trình và sản phẩm
• Thiết lập đường cơ sở
• Truy cập và dự đoán kết quả

Theo mức độ thuần thục của quy trình do SEI đưa ra, loại phép đo và chương trình đo sẽ khác nhau. Sau đây là các chương trình đo lường khác nhau có thể được áp dụng ở mỗi cấp độ trưởng thành.

Level 1: Ad hoc

Ở cấp độ này, các đầu vào không được xác định rõ ràng, trong khi các đầu ra được mong đợi. Quá trình chuyển đổi từ đầu vào sang đầu ra là không xác định và không được kiểm soát. Đối với mức độ thành thục của quy trình này, cần có các phép đo cơ bản để cung cấp điểm khởi đầu cho việc đo lường.

Level 2: Repeatable

Ở cấp độ này, các đầu vào và đầu ra của quá trình, các ràng buộc và nguồn lực có thể xác định được. Một quá trình lặp lại có thể được mô tả bằng sơ đồ sau.

Các thước đo đầu vào có thể là quy mô và sự biến động của các yêu cầu. Đầu ra có thể được đo lường về quy mô hệ thống, các nguồn lực về nỗ lực của nhân viên, và các ràng buộc về chi phí và lịch trình.

Level 3: Defined

Ở cấp độ này, các hoạt động trung gian được xác định, đầu vào và đầu ra của chúng được biết và hiểu rõ. Một ví dụ đơn giản về quy trình được xác định được mô tả trong hình sau.

Đầu vào và đầu ra từ các hoạt động trung gian có thể được kiểm tra, đo lường và đánh giá.

Level 4: Managed

Ở cấp độ này, phản hồi từ các hoạt động ban đầu của dự án có thể được sử dụng để thiết lập các ưu tiên cho các hoạt động hiện tại và sau đó cho các hoạt động dự án. Chúng tôi có thể đo lường hiệu quả của các hoạt động trong quy trình. Phép đo phản ánh các đặc điểm của quá trình tổng thể và sự tương tác giữa các hoạt động chính.

Level 5: Optimizing

Ở cấp độ này, các biện pháp từ các hoạt động được sử dụng để cải thiện quy trình bằng cách loại bỏ và thêm các hoạt động quy trình và thay đổi cấu trúc quy trình một cách linh động để đáp ứng với phản hồi đo lường. Do đó, thay đổi quy trình có thể ảnh hưởng đến tổ chức và dự án cũng như quy trình. Quy trình sẽ hoạt động như cảm biến và màn hình, và chúng tôi có thể thay đổi quy trình đáng kể để phản ứng với các dấu hiệu cảnh báo.

Ở một cấp độ trưởng thành nhất định, chúng tôi có thể thu thập các phép đo cho cấp độ đó và tất cả các cấp độ bên dưới nó.

Xác định mức độ trưởng thành

Quá trình chín muồi đề xuất chỉ đo lường những gì có thể nhìn thấy được. Vì vậy, sự kết hợp của quá trình trưởng thành với GQM sẽ cung cấp hầu hết các biện pháp hữu ích.

• Tại level 1, dự án có thể có các yêu cầu không xác định rõ. Ở cấp độ này, việc đo lường các đặc tính yêu cầu là khó khăn.

• Tại level 2, các yêu cầu được xác định rõ và có thể thu thập thông tin bổ sung như loại của từng yêu cầu và số lượng thay đổi đối với mỗi loại.

• Tại level 3, các hoạt động trung gian được xác định với các tiêu chí vào và ra cho mỗi hoạt động

Phân tích mục tiêu và câu hỏi sẽ giống nhau, nhưng số liệu sẽ thay đổi theo thời gian trưởng thành. Quá trình càng trưởng thành, các phép đo sẽ càng phong phú hơn. Mô hình GQM, phù hợp với quá trình hoàn thiện, đã được sử dụng làm cơ sở cho một số công cụ hỗ trợ các nhà quản lý trong việc thiết kế các chương trình đo lường.

GQM giúp hiểu được nhu cầu đo lường thuộc tính và mức độ trưởng thành của quá trình cho thấy liệu chúng ta có khả năng đo lường thuộc tính đó theo cách có ý nghĩa hay không. Chúng cùng nhau cung cấp bối cảnh để đo lường.

Xác thực phép đo của hệ thống phần mềm bao gồm hai bước:

• Xác thực hệ thống đo lường
• Xác thực hệ thống dự đoán

Xác thực hệ thống đo lường

Các biện pháp hoặc hệ thống đo lường được sử dụng để đánh giá một thực thể hiện có bằng cách mô tả số lượng một hoặc nhiều thuộc tính của nó. Một phép đo là hợp lệ nếu nó mô tả chính xác thuộc tính mà nó yêu cầu đo lường.

Xác thực hệ thống đo lường phần mềm là quá trình đảm bảo rằng phép đo là một đặc tính số thích hợp của thuộc tính được xác nhận quyền sở hữu bằng cách chỉ ra rằng điều kiện biểu diễn được thỏa mãn.

Để xác thực hệ thống đo lường, chúng ta cần cả một mô hình chính thức mô tả các thực thể và một ánh xạ số để bảo toàn thuộc tính mà chúng ta đang đo lường. Ví dụ: nếu có hai chương trình P1 và P2 và chúng tôi muốn nối các chương trình đó, thì chúng tôi hy vọng rằng bất kỳ biện pháp nàom chiều dài để đáp ứng điều đó,

m (P1 + P2) = m (P1) + m (P2)

Nếu một chương trình P1 có độ dài hơn chương trình P2, sau đó bất kỳ biện pháp nào m cũng nên thỏa mãn,

m (P1)> m (P2)

Độ dài của chương trình có thể được đo bằng cách đếm các dòng mã. Nếu số đếm này thỏa mãn các mối quan hệ trên, chúng ta có thể nói rằng các dòng mã là một thước đo độ dài hợp lệ.

Yêu cầu chính thức để xác nhận một phép đo bao gồm việc chứng minh rằng nó đặc trưng cho thuộc tính đã nêu theo nghĩa lý thuyết đo lường. Việc xác thực có thể được sử dụng để đảm bảo rằng các thước đo được xác định đúng và phù hợp với hành vi trong thế giới thực của thực thể.

Xác thực các Hệ thống Dự đoán

Hệ thống dự đoán được sử dụng để dự đoán một số thuộc tính của thực thể trong tương lai liên quan đến mô hình toán học với các thủ tục dự đoán liên quan.

Xác thực hệ thống dự đoán trong một môi trường nhất định là quá trình thiết lập độ chính xác của hệ thống dự đoán bằng phương pháp thực nghiệm, tức là bằng cách so sánh hiệu suất của mô hình với dữ liệu đã biết trong môi trường nhất định. Nó liên quan đến thử nghiệm và kiểm tra giả thuyết.

Mức độ chính xác được chấp nhận để xác nhận phụ thuộc vào việc hệ thống dự đoán là xác định hay ngẫu nhiên cũng như người thực hiện đánh giá. Một số hệ thống dự đoán ngẫu nhiên phức tạp hơn những hệ thống khác.

Ví dụ về hệ thống dự đoán ngẫu nhiên là các hệ thống như ước tính chi phí phần mềm, ước tính nỗ lực, ước tính lịch trình, v.v. Do đó, để xác thực chính thức hệ thống dự đoán, chúng ta phải quyết định xem nó là ngẫu nhiên như thế nào, sau đó so sánh hiệu suất của hệ thống dự đoán với dữ liệu đã biết.

Số liệu phần mềm là một tiêu chuẩn đo lường bao gồm nhiều hoạt động liên quan đến một số mức độ đo lường. Nó có thể được phân thành ba loại: số liệu sản phẩm, số liệu quy trình và số liệu dự án.

• Product metrics mô tả các đặc tính của sản phẩm như kích thước, độ phức tạp, tính năng thiết kế, hiệu suất và mức chất lượng.

• Process metricscó thể được sử dụng để cải thiện việc phát triển và bảo trì phần mềm. Ví dụ bao gồm hiệu quả của việc loại bỏ khuyết tật trong quá trình phát triển, mô hình kiểm tra sự xuất hiện của khuyết tật và thời gian phản hồi của quá trình sửa chữa.

• Project metricsmô tả các đặc điểm và thực hiện dự án. Ví dụ bao gồm số lượng nhà phát triển phần mềm, mô hình nhân sự trong vòng đời của phần mềm, chi phí, lịch trình và năng suất.

Một số chỉ số thuộc nhiều danh mục. Ví dụ: số liệu chất lượng trong quá trình của một dự án vừa là số liệu quá trình vừa là số liệu của dự án.

Phạm vi đo lường phần mềm

Các chỉ số phần mềm chứa nhiều hoạt động bao gồm:

• Ước tính chi phí và nỗ lực
• Các biện pháp và mô hình năng suất
• Thu thập dữ liệu
• Mô hình số lượng và các biện pháp
• Các mô hình độ tin cậy
• Mô hình hiệu suất và đánh giá
• Các chỉ số về cấu trúc và độ phức tạp
• Khả năng - đánh giá sự trưởng thành
• Quản lý theo số liệu
• Đánh giá các phương pháp và công cụ

Đo lường phần mềm là một tập hợp đa dạng các hoạt động này bao gồm từ các mô hình dự đoán chi phí dự án phần mềm ở một giai đoạn cụ thể đến các phép đo cấu trúc chương trình.

Ước tính chi phí và nỗ lực

Nỗ lực được thể hiện dưới dạng hàm của một hoặc nhiều biến số như quy mô của chương trình, khả năng của nhà phát triển và mức độ sử dụng lại. Các mô hình ước tính chi phí và nỗ lực đã được đề xuất để dự đoán chi phí của dự án trong các giai đoạn đầu của vòng đời phần mềm. Các mô hình khác nhau được đề xuất là -

• Mô hình COCOMO của Boehm
• Mô hình mỏng của Putnam
• Mô hình điểm chức năng của Albrecht

Mô hình năng suất và các biện pháp

Năng suất có thể được coi là một hàm của giá trị và chi phí. Mỗi loại có thể được phân chia thành các kích thước, chức năng, thời gian, tiền bạc có thể đo lường khác nhau, v.v. Các thành phần có thể có khác nhau của mô hình năng suất có thể được biểu thị trong sơ đồ sau.

Thu thập dữ liệu

Chất lượng của bất kỳ chương trình đo lường nào rõ ràng phụ thuộc vào việc thu thập dữ liệu cẩn thận. Dữ liệu thu thập được có thể được chắt lọc thành các biểu đồ và đồ thị đơn giản để người quản lý có thể hiểu được tiến trình và vấn đề của sự phát triển. Việc thu thập dữ liệu cũng rất cần thiết cho việc điều tra khoa học về các mối quan hệ và xu hướng.

Các mô hình và thước đo chất lượng

Các mô hình chất lượng đã được phát triển để đo lường chất lượng của sản phẩm mà không có năng suất là vô nghĩa. Các mô hình chất lượng này có thể được kết hợp với mô hình năng suất để đo lường năng suất chính xác. Những mô hình này thường được xây dựng theo kiểu cây. Các nhánh trên nắm giữ các yếu tố chất lượng cấp cao quan trọng như độ tin cậy và khả năng sử dụng.

Khái niệm cách tiếp cận phân chia và chinh phục đã được thực hiện như một cách tiếp cận tiêu chuẩn để đo lường chất lượng phần mềm.

Mô hình độ tin cậy

Hầu hết các mô hình chất lượng đều bao gồm độ tin cậy như một yếu tố thành phần, tuy nhiên, nhu cầu dự đoán và đo lường độ tin cậy đã dẫn đến một chuyên ngành riêng trong mô hình hóa và dự đoán độ tin cậy. Vấn đề cơ bản trong lý thuyết độ tin cậy là dự đoán khi nào một hệ thống cuối cùng sẽ thất bại.

Đánh giá Hiệu suất và Mô hình

Nó bao gồm các đặc điểm hiệu suất của hệ thống có thể quan sát được bên ngoài như thời gian phản hồi và tỷ lệ hoàn thành, và hoạt động bên trong của hệ thống như hiệu quả của các thuật toán. Đó là một khía cạnh khác của chất lượng.

Các chỉ số về cấu trúc và độ phức tạp

Ở đây chúng tôi đo lường các thuộc tính cấu trúc của các biểu diễn của phần mềm, các thuộc tính này có sẵn trước khi thực thi. Sau đó, chúng tôi cố gắng thiết lập các lý thuyết dự đoán theo kinh nghiệm để hỗ trợ đảm bảo chất lượng, kiểm soát chất lượng và dự đoán chất lượng.

Đánh giá khả năng trưởng thành

Mô hình này có thể đánh giá nhiều thuộc tính khác nhau của sự phát triển bao gồm việc sử dụng các công cụ, thực hành tiêu chuẩn và hơn thế nữa. Nó dựa trên các thông lệ chính mà mọi nhà thầu tốt nên sử dụng.

Quản lý theo số liệu

Để quản lý dự án phần mềm, đo lường có một vai trò quan trọng. Để kiểm tra xem dự án có đang đi đúng hướng hay không, người dùng và nhà phát triển có thể dựa vào biểu đồ và đồ thị dựa trên đo lường. Bộ tiêu chuẩn của các phép đo và phương pháp báo cáo đặc biệt quan trọng khi phần mềm được nhúng vào một sản phẩm mà khách hàng thường không thông thạo về thuật ngữ phần mềm.

Đánh giá các phương pháp và công cụ

Điều này phụ thuộc vào thiết kế thử nghiệm, xác định đúng các yếu tố có khả năng ảnh hưởng đến kết quả và đo lường thích hợp các thuộc tính của yếu tố.

Số liệu phần mềm là một tiêu chuẩn đo lường bao gồm nhiều hoạt động, liên quan đến một số mức độ đo lường. Thành công trong đo lường phần mềm nằm ở chất lượng của dữ liệu được thu thập và phân tích.

Dữ liệu tốt là gì?

Dữ liệu được thu thập có thể được coi là một dữ liệu tốt, nếu nó có thể tạo ra câu trả lời cho các câu hỏi sau:

• Are they correct? - Một dữ liệu có thể được coi là chính xác, nếu nó được thu thập theo các quy tắc chính xác của định nghĩa về số liệu.

• Are they accurate? - Độ chính xác đề cập đến sự khác biệt giữa dữ liệu và giá trị thực tế.

• Are they appropriately precise? - Độ chính xác giải quyết số lượng vị trí thập phân cần thiết để thể hiện dữ liệu.

• Are they consistent? - Dữ liệu có thể được coi là nhất quán, nếu nó không cho thấy sự khác biệt lớn giữa thiết bị đo này với thiết bị đo khác.

• Are they associated with a particular activity or time period? - Nếu dữ liệu được liên kết với một hoạt động hoặc khoảng thời gian cụ thể, thì nó cần được chỉ định rõ ràng trong dữ liệu.

• Can they be replicated?- Thông thường, các cuộc điều tra như khảo sát, nghiên cứu trường hợp và thí nghiệm thường được lặp lại trong các trường hợp khác nhau. Do đó, dữ liệu cũng có thể được sao chép một cách dễ dàng.

Làm thế nào để xác định dữ liệu?

Dữ liệu được thu thập cho mục đích đo lường có hai loại:

• Raw data- Dữ liệu thô là kết quả từ phép đo ban đầu của quá trình, sản phẩm hoặc tài nguyên. Ví dụ: Bảng chấm công hàng tuần của các nhân viên trong tổ chức.

• Refined data - Dữ liệu tinh chỉnh là kết quả từ việc trích xuất các phần tử dữ liệu thiết yếu từ dữ liệu thô để lấy giá trị cho các thuộc tính.

Dữ liệu có thể được xác định theo các điểm sau:

• Location
• Timing
• Symptoms
• Kết quả cuối cùng
• Mechanism
• Cause
• Severity
• Cost

Làm thế nào để thu thập dữ liệu?

Việc thu thập dữ liệu cần có sự quan sát và báo cáo của con người. Người quản lý, nhà phân tích hệ thống, người lập trình, người kiểm tra và người dùng phải ghi dữ liệu hàng vào biểu mẫu. Để thu thập dữ liệu chính xác và đầy đủ, điều quan trọng là phải -

• Giữ các thủ tục đơn giản

• Tránh ghi âm không cần thiết

• Đào tạo nhân viên về nhu cầu ghi lại dữ liệu và trong các thủ tục được sử dụng

• Cung cấp kết quả thu thập và phân tích dữ liệu cho các nhà cung cấp ban đầu ngay lập tức và ở dạng hữu ích để hỗ trợ họ trong công việc

• Xác thực tất cả dữ liệu được thu thập tại điểm thu thập trung tâm

Lập kế hoạch thu thập dữ liệu bao gồm một số bước:

• Quyết định sản phẩm nào cần đo lường dựa trên phân tích GQM

• Đảm bảo rằng sản phẩm được kiểm soát cấu hình

• Quyết định chính xác các thuộc tính cần đo lường và cách thức các phép đo gián tiếp sẽ được lấy ra

• Sau khi tập hợp các chỉ số rõ ràng và tập hợp các thành phần được đo lường đã được xác định, hãy lập sơ đồ để xác định từng hoạt động liên quan đến quá trình đo lường

• Thiết lập một thủ tục để xử lý các biểu mẫu, phân tích dữ liệu và báo cáo kết quả

Lập kế hoạch thu thập dữ liệu phải bắt đầu khi bắt đầu lập kế hoạch dự án. Việc thu thập dữ liệu thực tế diễn ra trong nhiều giai đoạn phát triển.

For example - Một số dữ liệu liên quan đến nhân sự của dự án có thể được thu thập khi bắt đầu dự án, trong khi việc thu thập dữ liệu khác như nỗ lực bắt đầu khi bắt đầu dự án và tiếp tục thông qua vận hành và bảo trì.

Cách lưu trữ và trích xuất dữ liệu

Trong kỹ thuật phần mềm, dữ liệu phải được lưu trữ trong cơ sở dữ liệu và được thiết lập bằng Hệ thống quản lý cơ sở dữ liệu (DBMS). Ví dụ về cấu trúc cơ sở dữ liệu được hiển thị trong hình sau. Cơ sở dữ liệu này sẽ lưu trữ thông tin chi tiết của các nhân viên khác nhau làm việc trong các bộ phận khác nhau của một tổ chức.

Trong sơ đồ trên, mỗi hộp là một bảng trong cơ sở dữ liệu và mũi tên biểu thị ánh xạ nhiều-một từ bảng này sang bảng khác. Các ánh xạ xác định các ràng buộc bảo toàn tính nhất quán logic của dữ liệu.

Khi cơ sở dữ liệu được thiết kế và điền dữ liệu, chúng ta có thể sử dụng các ngôn ngữ thao tác dữ liệu để trích xuất dữ liệu để phân tích.

Sau khi thu thập dữ liệu liên quan, chúng tôi phải phân tích nó một cách thích hợp. Có ba mục chính cần xem xét để lựa chọn kỹ thuật phân tích.

• Bản chất của dữ liệu
• Mục đích của thử nghiệm
• Cân nhắc thiết kế

Bản chất của dữ liệu

Để phân tích dữ liệu, chúng ta cũng phải xem xét dân số lớn hơn được đại diện bởi dữ liệu cũng như sự phân bố của dữ liệu đó.

Lấy mẫu, dân số và phân phối dữ liệu

Lấy mẫu là quá trình chọn một tập hợp dữ liệu từ một tập hợp lớn. Thống kê mẫu mô tả và tóm tắt các biện pháp thu được từ một nhóm đối tượng thực nghiệm.

Các thông số dân số đại diện cho các giá trị sẽ thu được nếu đo tất cả các đối tượng có thể.

Tổng thể hoặc mẫu có thể được mô tả bằng các thước đo của xu hướng trung tâm như giá trị trung bình, giá trị trung bình và phương thức và các thước đo độ phân tán như phương sai và độ lệch chuẩn. Nhiều bộ dữ liệu được phân phối bình thường như trong biểu đồ sau.

Như hình trên, dữ liệu sẽ được phân bổ đều về giá trị trung bình. đó là các đặc điểm quan trọng của phân phối chuẩn.

Các bản phân phối khác cũng tồn tại trong đó dữ liệu bị lệch để có nhiều điểm dữ liệu ở một phía của giá trị trung bình hơn điểm khác. Ví dụ: Nếu hầu hết dữ liệu nằm ở phía bên trái của giá trị trung bình, thì chúng ta có thể nói rằng phân phối bị lệch sang bên trái.

Mục đích của Thử nghiệm

Thông thường, các thí nghiệm được tiến hành -

• Để xác nhận một lý thuyết
• Để khám phá một mối quan hệ

Để đạt được từng điều này, mục tiêu cần được thể hiện một cách chính thức dưới dạng giả thuyết và việc phân tích phải giải quyết trực tiếp giả thuyết.

Để xác nhận một lý thuyết

Cuộc điều tra phải được thiết kế để khám phá sự thật của một lý thuyết. Lý thuyết thường nói rằng việc sử dụng một phương pháp, công cụ hoặc kỹ thuật nhất định có tác dụng cụ thể đối với các đối tượng, làm cho nó tốt hơn theo một cách nào đó.

Có hai trường hợp dữ liệu được xem xét: normal data và non-normal data.

Nếu dữ liệu là từ phân phối chuẩn và có hai nhóm để so sánh thì bài kiểm tra t của học sinh có thể được sử dụng để phân tích. Nếu có nhiều hơn hai nhóm để so sánh, có thể sử dụng phân tích tổng quát của kiểm định phương sai được gọi là thống kê F.

Nếu dữ liệu không bình thường, thì dữ liệu có thể được phân tích bằng cách sử dụng kiểm tra Kruskal-Wallis bằng cách xếp hạng nó.

Để khám phá một mối quan hệ

Các cuộc điều tra được thiết kế để xác định mối quan hệ giữa các điểm dữ liệu mô tả một biến hoặc nhiều biến.

Có ba kỹ thuật để trả lời các câu hỏi về mối quan hệ: biểu đồ hộp, biểu đồ phân tán và phân tích tương quan.

• A box plot có thể đại diện cho tóm tắt phạm vi của một tập hợp dữ liệu.

• A scatter plot biểu diễn mối quan hệ giữa hai biến.

• Correlation analysis sử dụng các phương pháp thống kê để xác nhận xem có mối quan hệ thực sự giữa hai thuộc tính hay không.

  • Đối với các giá trị được phân phối bình thường, hãy sử dụng Pearson Correlation Coefficient để kiểm tra xem hai biến có tương quan cao hay không.

  • Đối với dữ liệu không bình thường, hãy xếp hạng dữ liệu và sử dụng Spearman Rank Correlation Coefficientnhư một thước đo của sự liên kết. Một biện pháp khác cho dữ liệu không bình thường làKendall robust correlation coefficient, điều tra mối quan hệ giữa các cặp điểm dữ liệu và có thể xác định mối tương quan một phần.

Nếu xếp hạng chứa một số lượng lớn các giá trị ràng buộc, chi-squared testtrên một bảng dự phòng có thể được sử dụng để kiểm tra sự liên kết giữa các biến. Tương tự,linear regression có thể được sử dụng để tạo ra một phương trình để mô tả mối quan hệ giữa các biến.

Đối với nhiều hơn hai biến, multivariate regression có thể được sử dụng.

Cân nhắc thiết kế

Thiết kế của cuộc điều tra phải được xem xét trong khi lựa chọn các kỹ thuật phân tích. Đồng thời, sự phức tạp của phân tích có thể ảnh hưởng đến thiết kế được chọn. Nhiều nhóm sử dụng thống kê F thay vì kiểm tra T của học sinh với hai nhóm.

Đối với các thiết kế giai thừa phức tạp có nhiều hơn hai yếu tố, cần phải kiểm tra phức tạp hơn về sự liên kết và ý nghĩa.

Kỹ thuật thống kê có thể được sử dụng để tính đến ảnh hưởng của một tập hợp các biến số khác, hoặc để bù đắp cho các tác động về thời gian hoặc học tập.

Các thuộc tính sản phẩm bên trong mô tả các sản phẩm phần mềm theo cách chỉ phụ thuộc vào chính sản phẩm đó. Lý do chính để đo lường các thuộc tính sản phẩm nội bộ là nó sẽ giúp giám sát và kiểm soát sản phẩm trong quá trình phát triển.

Đo lường các thuộc tính sản phẩm nội bộ

Các thuộc tính sản phẩm nội bộ chính bao gồm size và structure. Kích thước có thể được đo tĩnh mà không cần phải thực hiện chúng. Kích thước của sản phẩm cho chúng ta biết về nỗ lực cần thiết để tạo ra nó. Tương tự, cấu trúc của sản phẩm đóng một vai trò quan trọng trong việc thiết kế bảo trì sản phẩm.

Đo kích thước

Kích thước phần mềm có thể được mô tả bằng ba thuộc tính:

• Length - Đó là kích thước vật lý của sản phẩm.

• Functionality - Nó mô tả các chức năng do sản phẩm cung cấp cho người dùng.

• Complexity - Độ phức tạp có nhiều loại khác nhau, chẳng hạn như.

  • Problem complexity - Đo lường mức độ phức tạp của vấn đề cơ bản.

  • Algorithmic complexity - Đo độ phức tạp của thuật toán được thực hiện để giải quyết vấn đề

  • Structural complexity - Đo lường cấu trúc của phần mềm được sử dụng để thực hiện thuật toán.

  • Cognitive complexity - Đo lường nỗ lực cần thiết để hiểu phần mềm.

Phép đo của ba thuộc tính này có thể được mô tả như sau:

Chiều dài

Có ba sản phẩm phát triển mà phép đo kích thước của chúng hữu ích cho việc dự đoán nỗ lực cần thiết cho việc dự đoán. Chúng là đặc điểm kỹ thuật, thiết kế và mã.

Đặc điểm kỹ thuật và thiết kế

Các tài liệu này thường kết hợp văn bản, đồ thị và các sơ đồ và ký hiệu toán học đặc biệt. Phép đo đặc điểm kỹ thuật có thể được sử dụng để dự đoán độ dài của thiết kế, do đó nó là một dự đoán về độ dài mã.

Các sơ đồ trong tài liệu có cú pháp thống nhất như đồ thị được gắn nhãn, sơ đồ luồng dữ liệu hoặc lược đồ Z. Vì tài liệu đặc tả và thiết kế bao gồm văn bản và sơ đồ, độ dài của nó có thể được đo bằng một cặp số thể hiện độ dài văn bản và độ dài sơ đồ.

Đối với các phép đo này, các đối tượng nguyên tử phải được xác định cho các loại biểu đồ và ký hiệu khác nhau.

Các đối tượng nguyên tử cho sơ đồ luồng dữ liệu là quy trình, thực thể bên ngoài, kho dữ liệu và luồng dữ liệu. Các thực thể nguyên tử cho các đặc tả đại số là sắp xếp, hàm, phép toán và tiên đề. Các thực thể nguyên tử cho các lược đồ Z là các dòng khác nhau xuất hiện trong đặc tả.

Mã

Mã có thể được tạo ra theo nhiều cách khác nhau như ngôn ngữ thủ tục, hướng đối tượng và lập trình trực quan. Thước đo truyền thống được sử dụng phổ biến nhất về độ dài chương trình mã nguồn là Dòng mã (LOC).

Tổng chiều dài,

LOC = NCLOC + CLOC

I E,

LOC = Non-commented LOC + Commented LOC

Ngoài dòng mã, các lựa chọn thay thế khác như kích thước và độ phức tạp do Maurice Halsted đề xuất cũng có thể được sử dụng để đo chiều dài.

Khoa học phần mềm của Halstead đã cố gắng nắm bắt các thuộc tính khác nhau của một chương trình. Ông đề xuất ba thuộc tính nội bộ của chương trình như độ dài, từ vựng và khối lượng phản ánh các quan điểm khác nhau về kích thước.

Ông bắt đầu bằng cách xác định một chương trình Pdưới dạng tập hợp các mã thông báo, được phân loại theo toán tử hoặc toán hạng. Các chỉ số cơ bản cho các mã thông báo này là,

• μ₁ = Số lượng toán tử duy nhất

• μ₂ = Số toán hạng duy nhất

• N₁ = Tổng số lần xuất hiện của các toán tử

• N₂ = Số lượng toán tử duy nhất

Độ dài P có thể được định nghĩa là

$$N = N_{1}+ N_{2}$$

Từ vựng của P Là

$$\mu =\mu _{1}+\mu _{2}$$

Khối lượng chương trình = Số phép so sánh tinh thần cần thiết để viết một chương trình có độ dài N, Là

$$V = N\times {log_{2}} \mu$$

Cấp độ chương trình của một chương trình P khối lượng V Là,

$$L = \frac{V^\ast}{V}$$

Ở đâu, $V^\ast$ là khối lượng tiềm năng, tức là khối lượng triển khai kích thước tối thiểu của P

Nghịch đảo của mức độ là khó khăn -

$$D = 1\diagup L$$

Theo lý thuyết Halstead, chúng ta có thể tính toán một ước tính L như

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

Tương tự, thời lượng chương trình ước tính là, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

Nỗ lực cần thiết để tạo ra P được đưa ra bởi,

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Đơn vị đo lường ở đâu E sự phân biệt tinh thần cơ bản cần thiết để hiểu P

Các lựa chọn thay thế khác để đo chiều dài là -

• Về số lượng byte bộ nhớ máy tính cần thiết cho văn bản chương trình

• Xét về số lượng ký tự trong văn bản chương trình

Phát triển hướng đối tượng đề xuất những cách mới để đo độ dài. Pfleeger và cộng sự. nhận thấy rằng số lượng đối tượng và phương pháp dẫn đến ước tính năng suất chính xác hơn so với những người sử dụng dòng mã.

Chức năng

Số lượng chức năng vốn có trong một sản phẩm cho phép đo kích thước sản phẩm. Có rất nhiều phương pháp khác nhau để đo lường chức năng của các sản phẩm phần mềm. Chúng ta sẽ thảo luận về một phương pháp như vậy ─ phương pháp Điểm hàm của Albrecht ─ trong chương tiếp theo.

Các thước đo điểm chức năng cung cấp một phương pháp chuẩn hóa để đo lường các chức năng khác nhau của một ứng dụng phần mềm. Nó đo lường chức năng từ quan điểm của người dùng, nghĩa là, trên cơ sở những gì người dùng yêu cầu và nhận lại. Phân tích điểm chức năng là một phương pháp tiêu chuẩn để đo lường sự phát triển phần mềm theo quan điểm của người dùng.

Phép đo Điểm chức năng ban đầu do Albrecht hình thành đã nhận được sự phổ biến ngày càng tăng với sự ra đời của Nhóm người dùng điểm chức năng quốc tế (IFPUG) vào năm 1986. Năm 2002, Điểm chức năng IFPUG trở thành tiêu chuẩn ISO quốc tế - ISO / IEC 20926.

Điểm chức năng là gì?

FP (Function Point)là số liệu kiểu chức năng phổ biến nhất phù hợp để định lượng một ứng dụng phần mềm. Nó dựa trên năm "chức năng" logic có thể nhận dạng được người dùng, được chia thành hai loại chức năng dữ liệu và ba loại chức năng giao dịch. Đối với một ứng dụng phần mềm nhất định, mỗi phần tử này được định lượng và có trọng số, đếm các phần tử đặc trưng của nó, chẳng hạn như tham chiếu tệp hoặc trường logic.

Các số kết quả (FP chưa điều chỉnh) được nhóm thành các bộ chức năng Đã thêm, Đã thay đổi hoặc Đã xóa và kết hợp với Hệ số điều chỉnh giá trị (VAF) để có được số FP cuối cùng. Một công thức cuối cùng riêng biệt được sử dụng cho từng loại đếm: Ứng dụng, Dự án phát triển hoặc Dự án nâng cao.

Áp dụng phương pháp điểm hàm của Albrecht

Bây giờ chúng ta hãy hiểu cách áp dụng phương pháp Điểm chức năng của Albrecht. Quy trình của nó như sau:

Xác định số lượng các thành phần (EI, EO, EQ, ILF và ELF)

• EI- Số lượng đầu vào bên ngoài. Đây là các quy trình cơ bản trong đó dữ liệu xuất phát đi qua ranh giới từ ngoài vào trong. Trong hệ thống cơ sở dữ liệu thư viện mẫu, hãy nhập số thẻ thư viện của khách hàng quen hiện có.

• EO- Số lượng đầu ra bên ngoài. Đây là các quy trình cơ bản trong đó dữ liệu xuất phát đi qua ranh giới từ bên trong ra bên ngoài. Trong hệ thống cơ sở dữ liệu thư viện mẫu, hãy hiển thị danh sách các sách đã được khách hàng quen.

• EQ- Số lượng truy vấn bên ngoài. Đây là các quy trình cơ bản có cả thành phần đầu vào và đầu ra dẫn đến việc truy xuất dữ liệu từ một hoặc nhiều tệp logic bên trong và tệp giao diện bên ngoài. Trong hệ thống cơ sở dữ liệu thư viện ví dụ, hãy xác định những sách nào hiện được gửi cho khách hàng quen.

• ILF- Số lượng tệp nhật ký nội bộ. Đây là những nhóm dữ liệu liên quan đến logic người dùng có thể nhận dạng được nằm hoàn toàn trong ranh giới ứng dụng được duy trì thông qua các đầu vào bên ngoài. Trong một hệ thống cơ sở dữ liệu thư viện ví dụ, tệp sách trong thư viện.

• ELF- Số lượng tệp nhật ký bên ngoài. Đây là những nhóm dữ liệu liên quan đến logic người dùng có thể nhận dạng được chỉ được sử dụng cho mục đích tham khảo và nằm hoàn toàn bên ngoài hệ thống. Trong hệ thống cơ sở dữ liệu thư viện mẫu, tệp chứa các giao dịch trong hệ thống thanh toán của thư viện.

Tính số điểm chức năng chưa điều chỉnh (UFC)

• Xếp hạng từng thành phần là low, average, hoặc là high.

• Đối với các giao dịch (EI, EO, and EQ), xếp hạng dựa trên FTR và DET.

  • FTR - Số lượng tệp được cập nhật hoặc tham chiếu.

  • DET - Số lượng trường mà người dùng có thể nhận ra.

  • Dựa vào bảng sau, một EI tham chiếu đến 2 tệp và 10 phần tử dữ liệu sẽ được xếp hạng là average.

FTRs	DETs
	1-5	6-15	>15
0-1	Thấp	Thấp	Trung bình cộng
2-3	Thấp	Trung bình cộng	Cao
>3	Trung bình cộng	Cao	Cao

• Đối với tệp (ILF and ELF), xếp hạng dựa trên RET và DET.

  • RET - Số lượng phần tử dữ liệu người dùng có thể nhận ra trong một ILF hoặc là ELF.

  • DET - Số lượng trường mà người dùng có thể nhận ra.

  • Dựa vào bảng sau, một ILF chứa 10 phần tử dữ liệu và 5 trường sẽ được xếp hạng là high.

RETs	DETs
	1-5	6-15	>15
1	Thấp	Thấp	Trung bình cộng
2-5	Thấp	Trung bình cộng	Cao
>5	Trung bình cộng	Cao	Cao

• Chuyển đổi xếp hạng thành UFCs.

Xếp hạng	Giá trị
	EO	EQ	EI	ILF	ELF
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

Tính tổng số điểm chức năng cuối cùng (FPC)

• Tính toán hệ số điều chỉnh giá trị (VAF) dựa trên 14 đặc điểm chung của hệ thống (GSC).

Đặc điểm hệ thống chung		Mô tả ngắn gọn
GSC 1	Truyền thông dữ liệu	Có bao nhiêu phương tiện liên lạc để hỗ trợ việc chuyển giao hoặc trao đổi thông tin với ứng dụng hoặc hệ thống?
GSC 2	Xử lý dữ liệu phân tán	Dữ liệu phân tán và các chức năng xử lý được xử lý như thế nào?
GSC 3	Hiệu suất	Thời gian phản hồi hoặc thông lượng có được yêu cầu bởi người dùng không?
GSC 4	Cấu hình được sử dụng nhiều	Nền tảng phần cứng hiện tại được sử dụng nhiều đến mức nào, nơi ứng dụng sẽ được thực thi?
GSC 5	Tỷ lệ giao dịch	Tần suất các giao dịch được thực hiện hàng ngày, hàng tuần, hàng tháng, v.v.?
GSC 6	Nhập dữ liệu trực tuyến	Bao nhiêu phần trăm thông tin được nhập trực tuyến?
GSC 7	Hiệu quả của người dùng cuối	Ứng dụng có được thiết kế cho người dùng cuối hiệu quả không?
GSC 8	Cập nhật trực tuyến	Có bao nhiêu ILF được cập nhật bằng giao dịch trực tuyến?
GSC 9	Xử lý phức tạp	Ứng dụng có xử lý logic hoặc toán học mở rộng không?
GSC 10	Khả năng tái sử dụng	Ứng dụng có được phát triển để đáp ứng một hoặc nhiều nhu cầu của người dùng không?
GSC 11	Cài đặt dễ dàng	Chuyển đổi và cài đặt có khó không?
GSC 12	Hoạt động dễ dàng	Quy trình khởi động, sao lưu và phục hồi hiệu quả và / hoặc tự động như thế nào?
GSC 13	Nhiều trang web	Ứng dụng có được thiết kế, phát triển và hỗ trợ đặc biệt để được cài đặt tại nhiều trang web cho nhiều tổ chức không?
GSC 14	Tạo điều kiện cho sự thay đổi	Ứng dụng có được thiết kế, phát triển và hỗ trợ đặc biệt để tạo điều kiện thay đổi không?

• Cân từng GSC trên thang điểm từ 0 đến 5 dựa trên việc nó không ảnh hưởng đến ảnh hưởng mạnh hay không.

• Tính toán FPC như sau -

  FPC = UFC * (0,65+ (tổng (GSC) * .01))

Phức tạp

Độ phức tạp là một thành phần riêng biệt của kích thước. Nó có hai loại -

• Complexity of a problem - Là lượng tài nguyên cần thiết cho một giải pháp tối ưu cho vấn đề.

• Complexity of a solution- Đó là các nguồn lực cần thiết để thực hiện một giải pháp cụ thể. Nó có hai khía cạnh. Chúng như sau:

  • Time complexity - Tài nguyên là thời gian máy tính.

  • Space complexity - Tài nguyên là bộ nhớ máy tính.

Đo lường độ phức tạp

Một khía cạnh của sự phức tạp là hiệu quả. Nó đo lường bất kỳ sản phẩm phần mềm nào có thể được mô hình hóa dưới dạng thuật toán.

Ví dụ: Nếu một thuật toán để giải quyết tất cả các trường hợp của một vấn đề cụ thể yêu cầu f(n) tính toán, sau đó f(n) là tối ưu về mặt tiệm cận, nếu đối với mọi thuật toán khác có độ phức tạp g giải quyết được vấn đề f Là O(g). Sau đó, sự phức tạp của vấn đề đã cho là lớn -O của thuật toán tiệm cận tối ưu cho giải pháp của vấn đề.

Việc đo lường các đặc tính cấu trúc của một phần mềm là quan trọng để ước tính nỗ lực phát triển cũng như bảo trì sản phẩm. Cấu trúc của các yêu cầu, thiết kế và mã giúp hiểu được khó khăn nảy sinh khi chuyển đổi sản phẩm này sang sản phẩm khác, trong việc thử nghiệm sản phẩm hoặc trong việc dự đoán các thuộc tính phần mềm bên ngoài từ các biện pháp ban đầu của sản phẩm nội bộ.

Các loại biện pháp kết cấu

Cấu trúc của phần mềm có ba phần. Họ là -

• Control-flow structure - Là trình tự thực hiện các lệnh trong một chương trình.

• Data-flow structure - Đó là hành vi của dữ liệu khi nó tương tác với chương trình.

• Data structure - Là sự tổ chức của các phần tử dữ liệu dưới dạng danh sách, hàng đợi, ngăn xếp hoặc các cấu trúc được xác định rõ khác cùng với thuật toán tạo, sửa đổi hoặc xóa chúng.

Đo lường cấu trúc kiểm soát dòng chảy

Các thước đo luồng điều khiển thường được mô hình hóa bằng đồ thị có hướng, trong đó mỗi nút hoặc điểm tương ứng với các câu lệnh của chương trình và mỗi cung hoặc cạnh có hướng chỉ ra luồng điều khiển từ câu lệnh này sang câu lệnh khác. Đồ thị của luận án được gọi là đồ thị luồng điều khiển hoặc đồ thị có hướng.

Nếu ‘m’ là một biện pháp cấu trúc được xác định theo mô hình biểu đồ luồng và nếu chương trình A có cấu trúc phức tạp hơn chương trình B, sau đó là biện pháp m(A) phải lớn hơn m(B).

Đo lường cấu trúc luồng dữ liệu

Luồng dữ liệu hoặc luồng thông tin có thể là liên mô-đun (luồng thông tin trong các mô-đun) hoặc nội mô-đun (luồng thông tin giữa các mô-đun riêng lẻ và phần còn lại của hệ thống).

Theo cách thức mà dữ liệu đang di chuyển qua hệ thống, nó có thể được phân loại thành các loại sau:

• Local direct flow - Nếu một mô-đun gọi một mô-đun thứ hai và chuyển thông tin đến nó hoặc mô-đun được gọi trả về một kết quả cho người gọi.

• Local indirect flow - Nếu mô-đun được gọi trả về thông tin sau đó được chuyển đến mô-đun được gọi thứ hai.

• Global flow - Nếu thông tin chuyển từ mô-đun này sang mô-đun khác thông qua cấu trúc dữ liệu toàn cục.

Theo Henry và Kafura, độ phức tạp của luồng thông tin có thể được thể hiện như,

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))²

Ở đâu,

• Fan-in (M) - Số luồng cục bộ kết thúc tại M + số cấu trúc dữ liệu mà từ đó M lấy thông tin.

• Fan–out (M) - Số lượng luồng cục bộ tạo ra từ M + số lượng cấu trúc dữ liệu được M cập nhật.

Đo lường cấu trúc dữ liệu

Cấu trúc dữ liệu có thể là cả hai local và global.

Locally, số lượng cấu trúc trong mỗi mục dữ liệu sẽ được đo lường. Phương pháp tiếp cận lý thuyết đồ thị có thể được sử dụng để phân tích và đo lường các thuộc tính của cấu trúc dữ liệu riêng lẻ. Trong đó, các kiểu dữ liệu đơn giản như số nguyên, ký tự và Boolean được xem là số nguyên tố và các phép toán khác nhau cho phép chúng ta xây dựng các cấu trúc dữ liệu phức tạp hơn được xem xét. Sau đó, các thước đo cấu trúc dữ liệu có thể được xác định theo thứ bậc về giá trị cho các số nguyên tố và giá trị liên quan đến các phép toán khác nhau.

Globally, sẽ đo lường tổng số biến do người dùng xác định.

Một số viện tiêu chuẩn quốc gia và quốc tế, các tổ chức chuyên nghiệp và định hướng ngành đã tham gia vào việc phát triển các tiêu chuẩn SQA.

Các viện và tổ chức sau đây là những nhà phát triển chính của SQA và các tiêu chuẩn kỹ thuật phần mềm -

• IEEE (Viện Kỹ sư Điện và Điện tử) Hiệp hội Máy tính
• ISO (Tổ chức Tiêu chuẩn hóa Quốc tế)
• DOD (Bộ Quốc phòng Hoa Kỳ)
• ANSI (Viện Tiêu chuẩn Quốc gia Hoa Kỳ)
• IEC (Ủy ban kỹ thuật điện quốc tế)
• EIA (Hiệp hội các ngành công nghiệp điện tử)

Các tổ chức này cung cấp các tiêu chuẩn quốc tế cập nhật về chất lượng của các hoạt động chuyên môn và quản lý được thực hiện trong các tổ chức phát triển và bảo trì phần mềm.

Họ cũng cung cấp chứng chỉ SQA thông qua các cuộc đánh giá chất lượng chuyên nghiệp độc lập. Các cuộc đánh giá bên ngoài này đánh giá những thành tựu trong việc phát triển các hệ thống SQA và việc thực hiện chúng. Chứng chỉ được cấp sau các cuộc đánh giá định kỳ sẽ chỉ có giá trị cho đến lần đánh giá tiếp theo và do đó phải được gia hạn. Hiện tại, Dịch vụ Chứng nhận ISO 9000 là nhà cung cấp chứng nhận SQA nổi bật nhất ở Châu Âu và các nước khác.

Họ cũng cung cấp các công cụ để tự đánh giá hệ thống SQA của một tổ chức và hoạt động của nó. Mô hình trưởng thành năng lực (CMM) được phát triển bởi Viện Kỹ thuật Phần mềm (SEI), Đại học Carnegie Mellon và ISO / IEC Std 15504 là những ví dụ của cách tiếp cận này.

Tiêu chuẩn SQA

Các tiêu chuẩn đảm bảo chất lượng phần mềm có thể được phân thành hai loại chính:

• Các tiêu chuẩn quản lý đảm bảo chất lượng phần mềm, bao gồm các phương pháp luận chứng nhận và đánh giá (tiêu chuẩn quản lý chất lượng)

• Tiêu chuẩn quy trình phát triển dự án phần mềm (tiêu chuẩn quy trình dự án)

Tiêu chuẩn quản lý chất lượng

Những điều này tập trung vào hệ thống SQA, cơ sở hạ tầng và các yêu cầu của tổ chức, trong khi để tổ chức lựa chọn các phương pháp và công cụ. Với các tiêu chuẩn quản lý chất lượng, các tổ chức có thể chắc chắn rằng các sản phẩm phần mềm của họ đạt được mức chất lượng có thể chấp nhận được.

Example - ISO 9000-3 và Mô hình trưởng thành về năng lực (CMM)

Tiêu chuẩn quy trình dự án

Chúng tập trung vào các phương pháp luận để thực hiện các dự án phát triển và bảo trì phần mềm. Các tiêu chuẩn này bao gồm những điều sau:

• Các bước cần thực hiện
• Yêu cầu tài liệu thiết kế
• Nội dung tài liệu thiết kế
• Đánh giá thiết kế và xem xét các vấn đề
• Kiểm thử phần mềm được thực hiện
• Chủ đề thử nghiệm

Đương nhiên, do các đặc điểm của chúng, nhiều tiêu chuẩn SQA trong lớp này có thể dùng làm tiêu chuẩn kỹ thuật phần mềm và ngược lại.

Đặc điểm của hai loại tiêu chuẩn này được tóm tắt trong bảng sau.

Nét đặc trưng	Tiêu chuẩn quản lý chất lượng	Tiêu chuẩn quy trình dự án
Đơn vị mục tiêu	Quản lý phát triển, bảo trì phần mềm và các đơn vị SQA cụ thể	Nhóm dự án phát triển và bảo trì phần mềm
Trọng tâm chính	Tổ chức hệ thống SQA, cơ sở hạ tầng và yêu cầu	Phương pháp luận để thực hiện các dự án phát triển và bảo trì phần mềm
Mục tiêu của tiêu chuẩn	"Cái gì" để đạt được	"Làm thế nào" để thực hiện
Mục tiêu của tiêu chuẩn	Đảm bảo chất lượng phần mềm của nhà cung cấp và đánh giá khả năng xử lý phần mềm của họ	Đảm bảo chất lượng phần mềm của nhà cung cấp và đánh giá khả năng xử lý phần mềm của nhà cung cấp Đảm bảo chất lượng của một dự án phần mềm cụ thể.
Ví dụ	ISO 9000-3 SEI's CMM	ISO / IEC 12207 IEEEStd 1012-1998

Chứng nhận ISO 9001

ISO (Tổ chức Tiêu chuẩn hóa Quốc tế) là một liên đoàn trên toàn thế giới của các cơ quan tiêu chuẩn quốc gia. Các ủy ban kỹ thuật ISO chuẩn bị các tiêu chuẩn quốc tế. ISO hợp tác chặt chẽ với Ủy ban kỹ thuật điện quốc tế (IEC) về tất cả các vấn đề của tiêu chuẩn hóa kỹ thuật điện.

Các tiêu chuẩn quốc tế được soạn thảo phù hợp với các quy tắc được đưa ra trong Chỉ thị ISO / IEC, Phần 2. Dự thảo các tiêu chuẩn quốc tế được các ủy ban kỹ thuật thông qua sẽ được gửi tới các cơ quan thành viên để bỏ phiếu. ISO 9001 được xây dựng bởi Ban kỹ thuật ISO / TC 176, Quản lý chất lượng và đảm bảo chất lượng, Tiểu ban SC 2, Hệ thống chất lượng.

Phương pháp tiếp cận quy trình

Tiêu chuẩn này khuyến khích việc áp dụng cách tiếp cận theo quá trình khi xây dựng, thực hiện và nâng cao hiệu lực của hệ thống quản lý chất lượng, nhằm nâng cao sự thỏa mãn của khách hàng bằng cách đáp ứng các yêu cầu của khách hàng. Để một tổ chức hoạt động hiệu quả, nó phải xác định và quản lý nhiều hoạt động liên kết. Một hoạt động hoặc một tập hợp các hoạt động sử dụng các nguồn lực và được quản lý để cho phép chuyển đầu vào thành đầu ra, có thể được coi là một quá trình.

Thường thì đầu ra từ một quy trình trực tiếp tạo thành đầu vào cho quy trình tiếp theo. Việc áp dụng hệ thống các quá trình trong một tổ chức, cùng với việc xác định và tương tác của các quá trình này, và việc quản lý chúng để tạo ra kết quả mong muốn, có thể được gọi là“process approach”.

Một ưu điểm của cách tiếp cận quá trình là sự kiểm soát liên tục mà nó cung cấp đối với mối liên kết giữa các quá trình riêng lẻ trong hệ thống các quá trình, cũng như sự kết hợp và tương tác của chúng. Khi được sử dụng trong hệ thống quản lý chất lượng, cách tiếp cận như vậy nhấn mạnh tầm quan trọng của những điều sau:

• Hiểu và đáp ứng các yêu cầu
• Cần xem xét các quy trình về giá trị gia tăng
• Thu được các kết quả về hiệu suất và hiệu quả của quá trình
• Cải tiến liên tục các quy trình dựa trên đo lường khách quan

ISO 9001 - Ứng dụng cho Phần mềm: Sáng kiến ​​TickIT

TickIT được ra mắt vào cuối những năm 1980 bởi ngành công nghiệp phần mềm Vương quốc Anh hợp tác với Bộ Thương mại và Công nghiệp Vương quốc Anh nhằm thúc đẩy sự phát triển của phương pháp luận để điều chỉnh ISO 9001 cho phù hợp với các đặc điểm của ngành công nghiệp phần mềm được gọi là sáng kiến ​​TickIT.

Ngoài ra, TickIT cũng chuyên về công nghệ thông tin (CNTT). Nó bao gồm toàn bộ các dịch vụ phát triển và bảo trì phần mềm thương mại. TickIT, hiện được quản lý và duy trì bởi Bộ DISC của BSI (Viện Tiêu chuẩn Anh), được công nhận để cấp chứng chỉ cho các tổ chức CNTT ở Anh và Thụy Điển.

Các hoạt động của nó bao gồm -

• Xuất bản Hướng dẫn TickIT, hỗ trợ các nỗ lực của ngành công nghiệp phần mềm để phổ biến chứng chỉ ISO 9001. Hướng dẫn hiện tại (ấn bản 5.0, TickIT, 2001), bao gồm các tham chiếu đến ISO / IEC 12207 và ISO / IEC 15504, được phân phối cho tất cả khách hàng của TickIT.

• Thực hiện các đánh giá dựa trên kiểm toán đối với hệ thống chất lượng phần mềm và tư vấn cho các tổ chức về việc cải tiến các quy trình phát triển và bảo trì phần mềm ngoài việc quản lý của họ.

• Tiến hành đánh giá chứng nhận ISO 9000.

Các đánh giá viên của TickIT thực hiện đánh giá dựa trên đánh giá và đánh giá chứng nhận được đăng ký bởi Cơ quan đăng ký quốc tế về đánh giá được chứng nhận (IRCA). Ngoài ra, các kiểm toán viên IRCA đã đăng ký được yêu cầu phải có kinh nghiệm về quản lý và phát triển phần mềm; họ cũng phải hoàn thành xuất sắc khóa học kiểm toán viên.

Các đánh giá viên chính đã đăng ký được yêu cầu phải có kinh nghiệm chứng minh trong việc thực hiện và chỉ đạo các cuộc đánh giá TickIT.

Đánh giá quy trình phần mềm là một cuộc kiểm tra có kỷ luật các quy trình phần mềm được sử dụng bởi một tổ chức, dựa trên một mô hình quy trình. Việc đánh giá bao gồm việc xác định và mô tả đặc điểm của các hoạt động hiện tại, xác định các điểm mạnh và điểm yếu, và khả năng kiểm soát hoặc tránh các nguyên nhân quan trọng của chất lượng, chi phí và tiến độ (phần mềm) kém.

Đánh giá phần mềm (hoặc đánh giá) có thể có ba loại.

• A self-assessment (first-party assessment) được thực hiện trong nội bộ bởi chính nhân sự của tổ chức.

• A second-party assessment được thực hiện bởi nhóm đánh giá bên ngoài hoặc tổ chức được đánh giá bởi khách hàng.

• A third-party assessment được thực hiện bởi một bên bên ngoài hoặc (ví dụ: một nhà cung cấp được bên thứ ba đánh giá để xác minh khả năng ký kết hợp đồng với khách hàng).

Đánh giá quy trình phần mềm được thực hiện trong một môi trường mở và hợp tác. Chúng được tổ chức sử dụng để cải tiến các quy trình phần mềm và kết quả được bảo mật cho tổ chức. Tổ chức được đánh giá phải có các thành viên trong đoàn đánh giá.

Đánh giá độ chín của quy trình phần mềm

Phạm vi đánh giá quá trình phần mềm có thể bao gồm tất cả các quá trình trong tổ chức, một tập hợp con được chọn của các quá trình phần mềm hoặc một dự án cụ thể. Hầu hết các cách tiếp cận đánh giá quá trình dựa trên tiêu chuẩn luôn dựa trên khái niệm về sự trưởng thành của quá trình.

Khi mục tiêu đánh giá là tổ chức, các kết quả đánh giá quá trình có thể khác nhau, ngay cả khi áp dụng liên tiếp cùng một phương pháp. Có hai lý do cho các kết quả khác nhau. Họ đang,

• Tổ chức đang được điều tra phải được xác định. Đối với một công ty lớn, có thể có một số định nghĩa về tổ chức và do đó phạm vi đánh giá thực tế có thể khác nhau trong các cuộc đánh giá liên tiếp.

• Ngay cả trong cùng một tổ chức, mẫu dự án được chọn để đại diện cho tổ chức có thể ảnh hưởng đến phạm vi và kết quả.

Khi đơn vị đánh giá mục tiêu ở cấp độ dự án, việc đánh giá cần bao gồm tất cả các yếu tố có ý nghĩa góp phần vào sự thành công hay thất bại của dự án. Nó không nên bị giới hạn bởi các kích thước đã thiết lập của một mô hình quá trình hoàn thiện nhất định. Tại đây, mức độ thực hiện và hiệu quả của chúng được chứng minh bằng dữ liệu dự án được đánh giá.

Sự trưởng thành của quy trình trở nên phù hợp khi một tổ chức dự định bắt tay vào một chiến lược cải tiến dài hạn tổng thể. Đánh giá dự án phần mềm nên là đánh giá độc lập để khách quan.

Chu kỳ đánh giá quy trình phần mềm

Theo Paulk và cộng sự (1995), phương pháp đánh giá dựa trên CMM sử dụng một chu trình sáu bước. Họ là -

• Chọn một nhóm - Các thành viên của nhóm phải là những chuyên gia am hiểu về kỹ thuật và quản lý phần mềm.

• Các đại diện của địa điểm được đánh giá hoàn thành bảng câu hỏi về mức độ trưởng thành của quy trình tiêu chuẩn.

• Nhóm đánh giá thực hiện phân tích các câu trả lời của bảng câu hỏi và xác định các khu vực cần thăm dò thêm theo các lĩnh vực quy trình chính của CMM.

• Nhóm đánh giá tiến hành một chuyến thăm trang web để hiểu rõ về quy trình phần mềm được thực hiện bởi trang web.

• Nhóm đánh giá đưa ra một danh sách các phát hiện xác định điểm mạnh và điểm yếu của quy trình phần mềm của tổ chức.

• Nhóm đánh giá chuẩn bị phân tích hồ sơ Khu vực Quy trình Chính (KPA) và trình bày kết quả cho đối tượng thích hợp.

Ví dụ, nhóm đánh giá phải được dẫn dắt bởi một Chuyên gia đánh giá trưởng SEI được ủy quyền. Nhóm phải bao gồm từ bốn đến mười thành viên trong nhóm. Ít nhất, một thành viên trong nhóm phải đến từ tổ chức được đánh giá và tất cả các thành viên trong nhóm phải hoàn thành phần Giới thiệu của SEI về khóa học CMM (hoặc khóa học tương đương) và khóa đào tạo nhóm CBA IPI của SEI. Các thành viên trong nhóm cũng phải đáp ứng một số nguyên tắc lựa chọn.

Liên quan đến việc thu thập dữ liệu, CBA IPI dựa trên bốn phương pháp:

• Bảng câu hỏi về độ tuổi trưởng thành tiêu chuẩn
• Phỏng vấn cá nhân và nhóm
• Đánh giá tài liệu
• Phản hồi từ việc xem xét các phát hiện dự thảo với những người tham gia đánh giá

LỪA ĐẢO

Phương pháp đánh giá CMMI tiêu chuẩn để cải tiến quy trình (SCAMPI) được phát triển để đáp ứng các yêu cầu của mô hình CMMI (Viện Kỹ thuật phần mềm, 2000). Nó cũng dựa trên CBA IPI. Cả CBA IPI và SCAMPI đều bao gồm ba giai đoạn -

• Lập kế hoạch và chuẩn bị
• Tiến hành đánh giá tại chỗ
• Báo cáo kết quả

Các hoạt động cho kế hoạch và giai đoạn chuẩn bị bao gồm:

• Xác định phạm vi đánh giá
• Xây dựng kế hoạch đánh giá
• Chuẩn bị và đào tạo nhóm đánh giá
• Đánh giá ngắn gọn về những người tham gia
• Quản lý Bảng câu hỏi thẩm định CMMI
• Kiểm tra câu trả lời bảng câu hỏi
• Tiến hành đánh giá tài liệu ban đầu

Các hoạt động cho giai đoạn đánh giá tại chỗ bao gồm:

• Tiến hành một cuộc họp khai mạc
• Tiến hành phỏng vấn
• Tổng hợp thông tin
• Chuẩn bị bản trình bày các phát hiện nháp
• Trình bày các phát hiện nháp
• Củng cố, xếp hạng và chuẩn bị các phát hiện cuối cùng

Các hoạt động của giai đoạn báo cáo kết quả bao gồm:

• Trình bày những phát hiện cuối cùng
• Tiến hành một phiên điều hành
• Kết thúc đánh giá

Định nghĩa IEEE về đảm bảo chất lượng phần mềm như sau:

"Một mô hình có kế hoạch và có hệ thống về tất cả các hành động cần thiết để tạo ra sự tin tưởng đầy đủ rằng một mặt hàng hoặc sản phẩm phù hợp với các yêu cầu kỹ thuật đã thiết lập. Một tập hợp các hoạt động được thiết kế để đánh giá quá trình phát triển hoặc sản xuất sản phẩm."

Mục tiêu của các hoạt động SQA

Mục tiêu của các hoạt động SQA như sau:

Trong Phát triển phần mềm (hướng theo quy trình)

• Đảm bảo mức độ tin cậy có thể chấp nhận được rằng phần mềm sẽ phù hợp với các yêu cầu kỹ thuật chức năng.

• Đảm bảo mức độ tin cậy có thể chấp nhận được rằng phần mềm sẽ tuân thủ các yêu cầu về ngân sách và lập kế hoạch của người quản lý.

• Khởi xướng và quản lý các hoạt động nhằm cải tiến và hiệu quả hơn các hoạt động phát triển phần mềm và SQA.

Trong bảo trì phần mềm (theo định hướng sản phẩm)

• Đảm bảo với mức độ tin cậy có thể chấp nhận được rằng các hoạt động bảo trì phần mềm sẽ phù hợp với các yêu cầu kỹ thuật chức năng.

• Đảm bảo với mức độ tin cậy có thể chấp nhận được rằng các hoạt động bảo trì phần mềm sẽ tuân theo các yêu cầu về ngân sách và lập kế hoạch của người quản lý.

• Khởi xướng và quản lý các hoạt động nhằm cải thiện và tăng hiệu quả của các hoạt động bảo trì phần mềm và SQA. Điều này liên quan đến việc cải thiện triển vọng đạt được các yêu cầu về chức năng và quản lý trong khi giảm chi phí.

Tổ chức đảm bảo chất lượng

Khung tổ chức đảm bảo chất lượng hoạt động trong cơ cấu tổ chức bao gồm những người tham gia sau:

Người quản lý

• Các giám đốc điều hành cấp cao nhất, đặc biệt là giám đốc điều hành trực tiếp phụ trách đảm bảo chất lượng phần mềm

• Giám đốc bộ phận phát triển và bảo trì phần mềm

• Quản lý bộ phận kiểm thử phần mềm

• Quản lý dự án và trưởng nhóm của các dự án phát triển và bảo trì

• Lãnh đạo nhóm kiểm thử phần mềm

Người kiểm tra

• Thành viên của nhóm kiểm thử phần mềm

Các chuyên gia SQA và các học viên quan tâm -

• Người được ủy thác SQA
• Thành viên ủy ban SQA
• Thành viên diễn đàn SQA
• Thành viên nhóm đơn vị SQA

Chỉ những người quản lý và nhân viên của bộ phận kiểm thử phần mềm mới được sử dụng toàn thời gian trong việc thực hiện các nhiệm vụ SQA. Những người khác dành một phần thời gian của họ cho các vấn đề chất lượng, cho dù trong quá trình hoàn thành các chức năng quản lý hoặc nhiệm vụ chuyên môn của họ, hoặc làm tình nguyện viên cho những người khác, thường là ủy ban SQA, diễn đàn SQA hoặc với tư cách là người được ủy thác SQA.

Về cơ bản, một cấu trúc quản lý ba cấp tồn tại trong các tổ chức phát triển phần mềm -

• Quản lý hàng đầu
• Quản lý bộ phận
• Quản lý dự án

Trách nhiệm quản lý hàng đầu về chất lượng phần mềm

Sau đây là trách nhiệm của lãnh đạo cao nhất trong việc đảm bảo Chất lượng Phần mềm -

• Đảm bảo chất lượng của các sản phẩm phần mềm và dịch vụ bảo trì phần mềm của công ty

• Truyền đạt tầm quan trọng của chất lượng sản phẩm và dịch vụ bên cạnh sự hài lòng của khách hàng cho nhân viên ở mọi cấp độ

• Đảm bảo hoạt động tốt và tuân thủ đầy đủ các yêu cầu của khách hàng

• Đảm bảo rằng các mục tiêu chất lượng được thiết lập cho hệ thống SQA của tổ chức và các mục tiêu của nó được hoàn thành

• Bắt đầu lập kế hoạch và giám sát việc thực hiện các thay đổi cần thiết để điều chỉnh hệ thống SQA với những thay đổi lớn bên trong cũng như bên ngoài liên quan đến khách hàng, cạnh tranh và công nghệ của tổ chức

• Can thiệp trực tiếp để hỗ trợ giải quyết các tình huống khủng hoảng và giảm thiểu thiệt hại

• Đảm bảo sự sẵn có của các tài nguyên theo yêu cầu của hệ thống SQA

Lãnh đạo cao nhất có thể thực hiện các bước sau để hoàn thành trách nhiệm của mình:

• Thiết lập và cập nhật chính sách chất lượng phần mềm của tổ chức.

• Phân công một trong những giám đốc điều hành như Phó chủ tịch SQA phụ trách các vấn đề chất lượng phần mềm

• Thực hiện đánh giá quản lý thường xuyên về hiệu suất liên quan đến các vấn đề chất lượng phần mềm

Chính sách chất lượng phần mềm

Chính sách chất lượng phần mềm của tổ chức phải truyền đạt các yêu cầu sau:

• Sự phù hợp với mục đích và mục tiêu của tổ chức

• Cam kết về các khái niệm đảm bảo chất lượng phần mềm chung

• Cam kết với các tiêu chuẩn chất lượng được tổ chức thông qua

• Cam kết phân bổ đủ nguồn lực để đảm bảo chất lượng phần mềm

• Cam kết liên tục cải tiến chất lượng và năng suất của tổ chức

Giám đốc điều hành phụ trách chất lượng phần mềm

Trách nhiệm của người điều hành phụ trách các vấn đề chất lượng phần mềm có thể được phân loại là:

• Trách nhiệm chuẩn bị chương trình và ngân sách hoạt động SQA hàng năm

• Trách nhiệm chuẩn bị các kế hoạch phát triển hệ thống SQA

• Kiểm soát tổng thể việc thực hiện chương trình hoạt động thường xuyên hàng năm của SQA và các dự án phát triển SQA theo kế hoạch

• Trình bày và vận động các vấn đề SQA cho quản lý điều hành

Trách nhiệm Chuẩn bị Chương trình Hoạt động SQA Hàng năm

Điều này đòi hỏi người điều hành phải -

• Thiết lập các mục tiêu SQA của hệ thống cho năm tới

• Xem xét các đề xuất do đơn vị SQA chuẩn bị cho chương trình hoạt động hàng năm và xác minh tiềm năng của đề xuất để hoàn thành các mục tiêu đặt ra cho hệ thống SQA

• Xác định xem chương trình hoạt động có phù hợp với các đặc điểm và phạm vi của dịch vụ nhà thầu phụ và việc mua phần mềm được lên kế hoạch cho năm tới hay không

• Xác định sự đầy đủ của nhân lực và các nguồn lực khác được lập kế hoạch để thực hiện chương trình SQA

• Phê duyệt phiên bản cuối cùng của chương trình và ngân sách hoạt động SQA hàng năm

Trách nhiệm chuẩn bị các kế hoạch phát triển hệ thống SQA

Các kế hoạch này phải thích ứng với những thay đổi về công nghệ cũng như nhu cầu của khách hàng và sự cạnh tranh. Các trách nhiệm bao gồm -

• Xem xét các xu hướng dự kiến ​​sẽ ảnh hưởng đến chất lượng phần mềm của tổ chức trong tương lai gần

• Xem xét các đề xuất để điều chỉnh SQA chẳng hạn như chuẩn bị các thủ tục mới phù hợp với các công cụ mới và tiêu chuẩn SQA

• Chuẩn bị các chương trình đào tạo cho các nhóm phát triển phần mềm kỳ cựu và các thành viên trong nhóm mới được tuyển dụng

• Phát triển các thước đo chất lượng phần mềm thích hợp để đánh giá các công cụ và tiêu chuẩn mới cũng như sự thành công của các chương trình đào tạo

• Phê duyệt phiên bản cuối cùng của các dự án phát triển SQA đã lên kế hoạch, bao gồm cả lịch trình và ngân sách của chúng

Kiểm soát tổng thể việc thực hiện Chương trình SQA hàng năm

Người phụ trách điều hành chịu trách nhiệm về -

• Giám sát chung chương trình hoạt động hàng năm

• Đánh giá tiến độ của các dự án thích ứng SQA

• Giám sát chung đối với các hành động được thực hiện để đạt được các thành tựu chất lượng do mục tiêu của nhóm (dựa trên báo cáo định kỳ)

• Đánh giá việc tuân thủ các thủ tục và tiêu chuẩn SQA dựa trên đánh giá chất lượng nội bộ

• Theo dõi chung việc tuân thủ lịch trình và ngân sách dự án phát triển phần mềm

• Theo dõi chung việc cung cấp các dịch vụ duy trì chất lượng cho khách hàng bên ngoài và bên trong

Trình bày và Vận động các Vấn đề SQA đối với Quản lý Điều hành

Để nâng cao chất lượng và giải quyết các khó khăn của hệ thống SQA, nó yêu cầu -

• Trình bày để phê duyệt lần cuối chương trình và ngân sách hoạt động hàng năm được đề xuất

• Trình bày để phê duyệt lần cuối các dự án thích ứng SQA đã lên kế hoạch cùng với ngân sách tương ứng

• Khởi xướng và lãnh đạo các cuộc họp đánh giá quản lý định kỳ dành riêng cho chất lượng phần mềm của tổ chức

• Bắt đầu các cuộc thảo luận ở cấp quản lý dành riêng cho các sự kiện chất lượng phần mềm đặc biệt, chẳng hạn như lỗi chất lượng nghiêm trọng, các mối đe dọa đối với việc hoàn thành thành công dự án do thiếu nhân viên chuyên nghiệp nghiêm trọng, khủng hoảng quản lý trong đơn vị SQA, v.v.

Trách nhiệm của Ban quản lý đối với SQA

Trách nhiệm đảm bảo chất lượng của quản lý cấp trung bao gồm:

• Quản lý hệ thống quản lý chất lượng phần mềm (các nhiệm vụ liên quan đến hệ thống chất lượng)

• Quản lý các nhiệm vụ liên quan đến các dự án và dịch vụ được thực hiện bởi các đơn vị hoặc nhóm dưới quyền của người quản lý cụ thể (các nhiệm vụ liên quan đến dự án)

Trách nhiệm liên quan đến hệ thống chất lượng

Chúng bao gồm các hoạt động SQA được thực hiện ở cấp bộ phận -

• Chuẩn bị chương trình và ngân sách hoạt động SQA hàng năm của bộ, dựa trên chương trình khuyến nghị do đơn vị SQA chuẩn bị

• Chuẩn bị kế hoạch phát triển hệ thống SQA của bộ phận, dựa trên kế hoạch khuyến nghị do đơn vị SQA chuẩn bị

• Kiểm soát việc thực hiện chương trình hoạt động SQA hàng năm của bộ phận và các dự án phát triển

• Trình bày về các vấn đề SQA của bộ phận với lãnh đạo cao nhất

Các trách nhiệm liên quan đến dự án

Những điều này thay đổi tùy theo thủ tục của tổ chức và sự phân bổ quyền hạn; chúng thường liên quan đến -

• Kiểm soát việc tuân thủ các quy trình đảm bảo chất lượng trong các đơn vị của bộ phận, bao gồm các cơ quan CAB, SCM và SCCA

• Theo dõi chi tiết kết quả xem xét hợp đồng và phê duyệt đề xuất

• Đánh giá việc thực hiện của đơn vị đối với các hoạt động đánh giá theo kế hoạch; phê duyệt các tài liệu dự án và giai đoạn hoàn thành dự án

• Theo dõi các thử nghiệm phần mềm và kết quả thử nghiệm; phê duyệt các sản phẩm phần mềm của dự án

• Theo dõi tiến độ của lịch trình dự án phát triển phần mềm và sai lệch ngân sách

• Tư vấn và hỗ trợ quản lý dự án giải quyết các khó khăn về tiến độ, ngân sách và quan hệ khách hàng

• Theo dõi chất lượng cung cấp dịch vụ bảo trì

• Theo dõi chi tiết các rủi ro của dự án và các giải pháp của chúng

• Theo dõi sự tuân thủ của dự án với các yêu cầu của khách hàng và sự hài lòng của khách hàng

• Phê duyệt các đơn đặt hàng thay đổi phần mềm lớn và sai lệch đáng kể so với thông số kỹ thuật của dự án

Trách nhiệm quản lý dự án về chất lượng phần mềm

Hầu hết các trách nhiệm quản lý dự án được xác định trong các thủ tục và hướng dẫn công việc; người quản lý dự án là người chịu trách nhiệm đảm bảo rằng tất cả các thành viên trong nhóm tuân thủ các quy trình và hướng dẫn đã nêu.

Nhiệm vụ của anh ấy bao gồm các nhiệm vụ quản lý và thực hành chuyên môn, đặc biệt là những việc sau:

• Professional hands-on tasks

  • Chuẩn bị các kế hoạch chất lượng và dự án và cập nhật của chúng

  • Tham gia vào ủy ban chung khách hàng - nhà cung cấp

  • Theo dõi chặt chẽ nhân sự của nhóm dự án, bao gồm cả việc tham dự tuyển dụng, đào tạo và hướng dẫn

• Management tasks

  Các nhà quản lý dự án giải quyết các vấn đề tiếp theo như -

  • Hiệu suất của các hoạt động xem xét và các sửa chữa do hậu quả

  • Các hoạt động kiểm tra hiệu suất, tích hợp và hệ thống của đơn vị phát triển và bảo trì phần mềm cũng như kiểm tra hiệu chỉnh và kiểm tra hồi quy

  • Thực hiện các thử nghiệm nghiệm thu

  • Cài đặt phần mềm tại các trang web của khách hàng từ xa và khách hàng thực hiện hệ thống phần mềm

  • Đào tạo và hướng dẫn SQA cho các thành viên trong nhóm dự án

  • Lịch trình và nguồn lực được phân bổ cho các hoạt động dự án

  • Yêu cầu của khách hàng và sự hài lòng

  • Phát triển rủi ro phát triển dự án, áp dụng các giải pháp và kiểm soát kết quả

Cấu trúc của đơn vị SQA thay đổi tùy theo loại hình và quy mô của tổ chức. Hình sau đây cho thấy một ví dụ về cấu trúc tiêu chuẩn và tất cả các thành phần trong một đơn vị SQA. Trong chương này, chúng ta sẽ thảo luận về vai trò và trách nhiệm của từng đơn vị con.

Nhiệm vụ do Trưởng đơn vị SQA thực hiện

Người đứng đầu đơn vị SQA chịu trách nhiệm về tất cả các nhiệm vụ đảm bảo chất lượng do đơn vị SQA và các đơn vị trực thuộc thực hiện. Các nhiệm vụ này có thể được phân loại thành các loại sau:

• Lập kế hoạch nhiệm vụ
• Quản lý đơn vị
• Hoạt động chuyên môn của SQA

Lập kế hoạch Nhiệm vụ

• Chuẩn bị chương trình hoạt động hàng năm đề xuất và ngân sách cho đơn vị

• Lập kế hoạch và cập nhật hệ thống quản lý chất lượng phần mềm của tổ chức

• Chuẩn bị các chương trình hoạt động SQA hàng năm được khuyến nghị và kế hoạch phát triển hệ thống SQA cho các bộ phận phát triển và bảo trì phần mềm

Nhiệm vụ quản lý

• Quản lý các hoạt động của nhóm SQA

• Giám sát việc thực hiện chương trình hoạt động SQA

• Đề cử các thành viên trong nhóm, thành viên ủy ban SQA và ủy viên SQA

• Chuẩn bị các báo cáo đặc biệt và định kỳ, ví dụ: tình trạng của các vấn đề chất lượng phần mềm trong tổ chức và báo cáo hiệu suất hàng tháng

Hoạt động chuyên môn của SQA

• Tham gia vào các ủy ban chung của dự án
• Tham gia đánh giá thiết kế chính thức
• Xem xét và phê duyệt các sai lệch so với thông số kỹ thuật
• Tham vấn với các nhà quản lý dự án và trưởng nhóm
• Tham gia vào các ủy ban và diễn đàn của SQA

Vòng đời dự án SQA

Các nhiệm vụ SQA liên quan đến tiểu đơn vị vòng đời của dự án có thể được phân thành hai nhóm:

• Nhiệm vụ theo dõi và phê duyệt của người quản lý “thuần túy” (nhiệm vụ kiểm soát vòng đời của dự án)

• “Thực hành” hoặc tham gia tích cực vào các hoạt động SQA của nhóm dự án, nơi cần có sự đóng góp chuyên môn (nhiệm vụ tham gia)

Nhiệm vụ kiểm soát vòng đời dự án

• Theo dõi sự tuân thủ của nhóm phát triển và bảo trì đối với các thủ tục SQA và hướng dẫn công việc

• Phê duyệt hoặc đề xuất các sản phẩm phần mềm theo các thủ tục liên quan

• Giám sát việc cung cấp dịch vụ bảo trì phần mềm cho khách hàng nội bộ và bên ngoài

• Theo dõi sự hài lòng của khách hàng và duy trì liên hệ với các đại diện đảm bảo chất lượng của khách hàng

Nhiệm vụ tham gia

Những nhiệm vụ này bao gồm tham gia vào -

• Đánh giá hợp đồng
• Chuẩn bị và cập nhật kế hoạch chất lượng và phát triển dự án
• Đánh giá thiết kế chính thức
• Đánh giá thiết kế chính thức của nhà thầu phụ
• Kiểm thử phần mềm, bao gồm kiểm thử chấp nhận của khách hàng
• Kiểm tra chấp nhận phần mềm đối với các sản phẩm phần mềm của nhà thầu phụ
• Cài đặt các sản phẩm phần mềm mới

Nhiệm vụ vận hành cơ sở hạ tầng SQA

Hệ thống SQA sử dụng nhiều thành phần cơ sở hạ tầng khác nhau để hoạt động trơn tru, cụ thể là -

• Quy trình và hướng dẫn công việc
• Hỗ trợ các thiết bị chất lượng (mẫu, danh sách kiểm tra)
• Đào tạo nhân viên, hướng dẫn và cấp chứng chỉ
• Các hành động phòng ngừa và khắc phục
• Quản lý cấu hình
• Kiểm soát tài liệu

Cụ thể hơn, nhiệm vụ của đơn vị con SQA liên quan đến các thành phần này bao gồm:

• Xuất bản các phiên bản cập nhật của các thủ tục, hướng dẫn công việc, các mẫu, danh sách kiểm tra, v.v., cùng với việc lưu hành chúng dưới dạng bản cứng và / hoặc bằng phương tiện điện tử

• Truyền đào tạo và hướng dẫn về việc tuân thủ và áp dụng các thủ tục SQA, hướng dẫn công việc và các hạng mục tương tự cho nhân viên mới và hiện tại

• Hướng dẫn của các ủy viên SQA về các thủ tục mới và sửa đổi cũng như các công cụ và phương pháp phát triển, trong số các thành phần khác

• Giám sát và hỗ trợ thực hiện các thủ tục SQA mới và sửa đổi

• Theo dõi các hoạt động chứng nhận nhân viên

• Đề xuất các đối tượng cần hành động ngăn ngừa và khắc phục, bao gồm cả việc tham gia vào các ủy ban CAB

• Theo dõi các hoạt động quản lý cấu hình, bao gồm cả việc tham gia vào các ủy ban CCA

• Theo dõi việc tuân thủ các thủ tục tài liệu và hướng dẫn công việc

Nhiệm vụ Kiểm toán nội bộ và Chứng nhận SQA

Các loại đánh giá SQA được thực hiện trong hoặc bởi các tổ chức phần mềm có thể được phân loại như sau:

• Kiểm toán nội bộ

• Đánh giá các nhà thầu phụ và nhà cung cấp để đánh giá hệ thống SQA của họ

• Đánh giá bên ngoài do tổ chức chứng nhận thực hiện

• Đánh giá bên ngoài được thực hiện bởi những khách hàng muốn đánh giá hệ thống SQA trước khi chấp nhận tổ chức là nhà cung cấp

Hai lớp đánh giá đầu tiên do tiểu đơn vị SQA bắt đầu và thực hiện, hai lớp cuối cùng do các cơ quan bên ngoài thực hiện.

Đơn vị SQA thực hiện các nhiệm vụ sau đối với các cuộc đánh giá SQA nội bộ

• Chuẩn bị các chương trình hàng năm cho các cuộc đánh giá SQA nội bộ

• Hiệu suất của các cuộc đánh giá SQA nội bộ

• Theo dõi các chỉnh sửa và cải tiến do nhóm được đánh giá và các đơn vị khác thực hiện

• Chuẩn bị các báo cáo tóm tắt định kỳ về tình trạng của các phát hiện đánh giá, bao gồm cả các khuyến nghị để cải tiến

Đơn vị SQA thực hiện các nhiệm vụ sau để đánh giá các nhà thầu phụ và nhà cung cấp -

• Chuẩn bị chương trình hàng năm cho các cuộc đánh giá SQA của các nhà thầu phụ và nhà cung cấp

• Hiệu suất đánh giá SQA của các nhà thầu phụ và nhà cung cấp

• Theo dõi các sửa chữa và cải tiến do nhà thầu phụ và nhà cung cấp được kiểm toán thực hiện

• Thu thập dữ liệu về hiệu suất của các nhà thầu phụ và nhà cung cấp từ các nguồn nội bộ cũng như bên ngoài

• Đánh giá định kỳ hệ thống SQA của nhà thầu phụ được chứng nhận của tổ chức và nhà cung cấp dựa trên báo cáo đánh giá và thông tin thu thập từ các nguồn nội bộ và bên ngoài khác. Báo cáo đánh giá bao gồm:

  • Khuyến nghị về chứng nhận nhà thầu phụ và nhà cung cấp

  • Đánh giá bên ngoài do tổ chức chứng nhận thực hiện bao gồm các nhiệm vụ sau:

    • Phối hợp các nội dung và lịch trình đánh giá chứng nhận

    • Chuẩn bị các tài liệu do tổ chức chứng nhận quy định

    • Hướng dẫn các nhóm được đánh giá và thực hiện các công việc chuẩn bị cần thiết cho đánh giá chứng nhận

    • Tham gia đánh giá chứng nhận

    • Đảm bảo các chỉnh sửa và cải tiến cần thiết được thực hiện

Đánh giá SQA do khách hàng của tổ chức thực hiện đòi hỏi những nhiệm vụ sau:

• Phối hợp các nội dung và lịch trình kiểm toán

• Chuẩn bị các tài liệu do kiểm toán viên của khách hàng chỉ định

• Hướng dẫn các nhóm được đánh giá và thực hiện các công việc chuẩn bị cần thiết cho các cuộc đánh giá SQA bởi khách hàng của tổ chức

• Tham gia vào các cuộc kiểm toán

• Đảm bảo rằng các chỉnh sửa và cải tiến cần thiết được thực hiện

Nhiệm vụ hỗ trợ SQA

Hầu hết những người sử dụng dịch vụ hỗ trợ của SQA đều nằm trong tổ chức. Họ bao gồm người quản lý dự án, trưởng nhóm và người được ủy thác SQA. Nhiệm vụ của họ bao gồm -

• Chuẩn bị kế hoạch dự án và kế hoạch chất lượng dự án

• Nhóm đánh giá nhân sự

• Lựa chọn các biện pháp để giải quyết các rủi ro phát triển phần mềm đã xác định

• Lựa chọn các biện pháp để giải quyết tình trạng chậm tiến độ và vượt quá ngân sách

• Lựa chọn các chỉ số SQA và các thành phần chi phí phần mềm

• Sử dụng hệ thống thông tin SQA

• Lựa chọn phương pháp luận phát triển và công cụ phản ánh dữ liệu kinh nghiệm thất bại do đơn vị SQA tích lũy

Các nhiệm vụ về tiêu chuẩn và quy trình SQA

Đơn vị con SQA liên quan mật thiết đến việc quyết định các tiêu chuẩn SQA nào sẽ được thông qua cũng như phát triển và duy trì các thủ tục của tổ chức. Để hoàn thành các nghĩa vụ của người phục vụ, đơn vị SQA phải -

• Chuẩn bị một chương trình hàng năm để phát triển các thủ tục mới và cập nhật thủ tục

• Chịu trách nhiệm phát triển các thủ tục mới và cập nhật thủ tục, với sự tham gia của các ủy ban và diễn đàn thích hợp

• Theo dõi sự phát triển và thay đổi trong SQA và các tiêu chuẩn kỹ thuật phần mềm; giới thiệu các thủ tục bổ sung và những thay đổi liên quan đến tổ chức

• Bắt đầu cập nhật và điều chỉnh các thủ tục để đáp ứng với những thay đổi trong tiêu chuẩn nghề nghiệp, bao gồm cả việc chấp nhận hoặc xóa bỏ các tiêu chuẩn được tổ chức áp dụng

Nhiệm vụ kỹ thuật SQA

Theo dõi các tiến bộ chuyên môn, giải quyết các khó khăn vận hành và phân tích chuyên môn về các lỗi là những mục tiêu trước mắt của đơn vị con SQA này.

Do đó, các nhiệm vụ kỹ thuật chính liên quan đến những điều sau:

• Kiểm tra các khía cạnh chất lượng và năng suất đối với các công cụ phát triển mới và các phiên bản mới của các công cụ phát triển hiện đang được sử dụng

• Đánh giá chất lượng và năng suất của các phương pháp phát triển và bảo trì mới và cải tiến phương pháp

• Phát triển các giải pháp cho những khó khăn gặp phải khi áp dụng các công cụ và phương pháp phát triển phần mềm đang được sử dụng

• Phát triển các phương pháp đo lường chất lượng phần mềm và năng suất của nhóm

• Cung cấp hỗ trợ công nghệ cho các ủy ban CAB trong quá trình phân tích các lỗi phát triển phần mềm và xây dựng các giải pháp đề xuất

Nhiệm vụ của hệ thống thông tin SQA

Hệ thống thông tin SQA nhằm tạo điều kiện và cải thiện hoạt động của hệ thống SQA. Các nhiệm vụ liên quan bao gồm:

• Phát triển hệ thống thông tin SQA cho các đơn vị phát triển và bảo trì phần mềm cho

  • thu thập dữ liệu hoạt động

  • xử lý, ví dụ, báo cáo định kỳ, danh sách, báo cáo ngoại lệ và truy vấn

  • xử lý, ví dụ, báo cáo định kỳ, danh sách, báo cáo ngoại lệ và truy vấn

• Phát triển hệ thống thông tin SQA tạo điều kiện thuận lợi cho đơn vị SQA xử lý thông tin do đơn vị phát triển và bảo trì phần mềm cung cấp, bao gồm cả ước tính về số liệu chất lượng phần mềm và chi phí chất lượng phần mềm

• Cập nhật hệ thống thông tin SQA

• Phát triển và duy trì trang web SQA Internet / Intranet của tổ chức

Người được ủy thác SQA và nhiệm vụ của họ

Người được ủy thác SQA là những thành viên chủ yếu tham gia vào việc thúc đẩy chất lượng phần mềm. Các thành viên này cung cấp sự hỗ trợ nội bộ cần thiết để thực hiện thành công các thành phần của SQA.

Nhiệm vụ của họ có thể khác nhau tùy thuộc vào các tổ chức. Theo đó, nó có thể là các nhiệm vụ liên quan đến đơn vị và / hoặc liên quan đến tổ chức.

Nhiệm vụ liên quan đến đơn vị

• Hỗ trợ đồng nghiệp giải quyết những khó khăn trong quá trình thực hiện các quy trình chất lượng phần mềm và hướng dẫn công việc

• Hỗ trợ người quản lý đơn vị thực hiện các nhiệm vụ SQA liên quan

• Thúc đẩy sự tuân thủ và giám sát việc thực hiện các thủ tục SQA và hướng dẫn công việc của đồng nghiệp

• Báo cáo các sự kiện không tuân thủ đáng kể và có hệ thống cho đơn vị SQA

• Báo cáo lỗi chất lượng phần mềm nghiêm trọng cho đơn vị SQA

Các nhiệm vụ liên quan đến tổ chức

• Kích hoạt các thay đổi và cập nhật các thủ tục SQA trong toàn tổ chức và hướng dẫn công việc

• Kích hoạt các cải tiến của quá trình phát triển và bảo trì trong tổ chức

• Bắt đầu ứng dụng cho CAB liên quan đến các giải pháp cho các lỗi lặp lại được quan sát thấy trong các đơn vị tương ứng

• Xác định nhu cầu đào tạo SQA trong toàn tổ chức và đề xuất chương trình đào tạo hoặc hướng dẫn thích hợp để đơn vị SQA thực hiện

Ủy ban SQA và Nhiệm vụ của họ

Ủy ban SQA có thể là thường trực hoặc đột xuất. Các nhiệm vụ có thể khác nhau đáng kể giữa các tổ chức.

• Permanent committees thường giải quyết SCC (Kiểm soát thay đổi phần mềm), CA (Hành động khắc phục), các thủ tục, công cụ phát triển phương pháp và chỉ số chất lượng.

• Ad hoc committees thường giải quyết các trường hợp cụ thể được quan tâm chung như cập nhật quy trình cụ thể, phân tích và giải pháp cho lỗi phần mềm, xây dựng số liệu phần mềm cho quy trình hoặc sản phẩm được nhắm mục tiêu, cập nhật chi phí chất lượng phần mềm và phương pháp thu thập dữ liệu cho một vấn đề cụ thể.

Các ủy ban thường trực của SQA là bộ phận không thể tách rời của khuôn khổ tổ chức SQA; nhiệm vụ và hoạt động của họ thường được xác định trong các thủ tục SQA của tổ chức.

Các ủy ban đặc biệt được thành lập trên cơ sở ngắn hạn cho mỗi vấn đề, với các thành viên được chỉ định bởi giám đốc điều hành chịu trách nhiệm về các vấn đề chất lượng phần mềm, người đứng đầu Đơn vị SQA, các đơn vị phụ của SQA, ủy ban SQA thường trực hoặc bất kỳ cơ quan nào khác đã khởi xướng sự hình thành của nó và có một mối quan tâm đến công việc. Cơ quan này cũng xác định các nhiệm vụ của ủy ban đặc biệt.