ในบริบทของวิศวกรรมซอฟต์แวร์คุณภาพซอฟต์แวร์หมายถึงแนวคิดสองประการที่เกี่ยวข้องกันแต่แตกต่างกัน: ^{[ 1 ]}

• คุณภาพการทำงานของซอฟต์แวร์สะท้อนให้เห็นว่าซอฟต์แวร์นั้นสอดคล้องกับการออกแบบที่กำหนดได้ดีเพียงใด โดยอิงตามข้อกำหนดหรือคุณสมบัติ การทำงาน ^{[ 2 ]}คุณลักษณะดังกล่าวอาจอธิบายได้ว่าเป็นความเหมาะสมสำหรับวัตถุประสงค์ของซอฟต์แวร์ชิ้นหนึ่ง หรือเปรียบเทียบกับคู่แข่งในตลาดในฐานะผลิตภัณฑ์ที่มีคุณค่า[ 3 ^{]มันคือ}ระดับของการผลิตซอฟต์แวร์ที่ถูกต้อง
• คุณภาพเชิงโครงสร้างของซอฟต์แวร์ หมายถึง วิธีที่ซอฟต์แวร์นั้นตอบสนองความต้องการที่ไม่ใช่เชิงฟังก์ชัน ซึ่งสนับสนุนการส่งมอบความต้องการเชิงฟังก์ชัน เช่น ความทนทาน หรือความสามารถในการบำรุงรักษา โดยส่วนใหญ่แล้วจะเกี่ยวข้องกับระดับที่ซอฟต์แวร์ทำงาน ได้ตามที่ต้องการ

คุณภาพเชิงโครงสร้างหลายแง่มุมสามารถประเมินได้แบบคงที่ เท่านั้น โดยการวิเคราะห์โครงสร้างภายในของซอฟต์แวร์ ซอร์สโค้ด (ดูเมตริกซอฟต์แวร์ ) ^{[ 4 ]}ในระดับหน่วย และในระดับระบบ (บางครั้งเรียกว่าการทดสอบแบบครบวงจร^{[ 5 ]} ) ซึ่งในทางปฏิบัติคือสถาปัตยกรรมเป็นไปตามหลักการที่ดีของสถาปัตยกรรมซอฟต์แวร์ที่ระบุไว้ในเอกสารเกี่ยวกับหัวข้อนี้โดยObject Management Group (OMG) ^{[ 6 ]}

คุณสมบัติเชิงโครงสร้างบางอย่าง เช่นความสามารถในการใช้งานสามารถประเมินได้เฉพาะแบบไดนามิก เท่านั้น (ผู้ใช้หรือบุคคลอื่นที่กระทำการแทนผู้ใช้โต้ตอบกับซอฟต์แวร์ หรืออย่างน้อยที่สุด ต้นแบบหรือการใช้งานบางส่วน แม้แต่การโต้ตอบกับเวอร์ชันจำลองที่ทำจากกระดาษแข็งก็ถือเป็นการทดสอบแบบไดนามิก เพราะเวอร์ชันดังกล่าวสามารถถือเป็นต้นแบบได้) ส่วนด้านอื่นๆ เช่น ความน่าเชื่อถือ อาจเกี่ยวข้องไม่เพียงแต่ซอฟต์แวร์เท่านั้น แต่ยังรวมถึงฮาร์ดแวร์พื้นฐานด้วย ดังนั้นจึงสามารถประเมินได้ทั้งแบบคงที่และแบบไดนามิก ( การทดสอบความเครียด )

การใช้การทดสอบอัตโนมัติและฟังก์ชันฟิตเนสสามารถช่วยรักษาคุณลักษณะที่เกี่ยวข้องกับคุณภาพบางประการได้^{[ 7 ]}

โดยทั่วไป คุณภาพการทำงานจะได้รับการประเมินแบบไดนามิก แต่ก็สามารถใช้การทดสอบแบบคงที่ได้เช่นกัน (เช่นการตรวจสอบซอฟต์แวร์ )

ในอดีต โครงสร้าง การจำแนกประเภท และคำศัพท์ของคุณลักษณะและตัวชี้วัดที่ใช้ได้ในการจัดการคุณภาพซอฟต์แวร์นั้นได้มาจากหรือดึงมาจากมาตรฐานISO 9126และมาตรฐานISO/IEC 25000 ในเวลาต่อมา ^{[ 8 ]}โดยอิงจากแบบจำลองเหล่านี้ (ดูแบบจำลอง) Consortium for IT Software Quality (CISQ) ได้กำหนดลักษณะโครงสร้างที่สำคัญ 5 ประการที่จำเป็นสำหรับซอฟต์แวร์ชิ้นหนึ่งเพื่อให้เกิดคุณค่าทางธุรกิจได้แก่^{[ 9 ]}ความน่าเชื่อถือ ประสิทธิภาพ ความปลอดภัย ความสามารถในการบำรุงรักษา และขนาด (ที่เพียงพอ) ^{[ 10 ] [ 11 ] [ 12 ]}

การวัดคุณภาพซอฟต์แวร์เป็นการวัดปริมาณว่าโปรแกรมหรือระบบซอฟต์แวร์นั้นมีคะแนนในแต่ละมิติทั้งห้ามากน้อยเพียงใด สามารถคำนวณค่าคุณภาพซอฟต์แวร์โดยรวมได้โดยใช้ระบบการให้คะแนนเชิงคุณภาพหรือเชิงปริมาณ หรือการผสมผสานทั้งสองอย่าง แล้วจึงใช้ระบบการถ่วงน้ำหนักที่สะท้อนถึงลำดับความสำคัญ มุมมองเกี่ยวกับคุณภาพซอฟต์แวร์ที่วางอยู่บนเส้นต่อเนื่องเชิงเส้นนี้ได้รับการเสริมด้วยการวิเคราะห์ "ข้อผิดพลาดในการเขียนโปรแกรมที่สำคัญ" ซึ่งภายใต้สถานการณ์เฉพาะอาจนำไปสู่การหยุดชะงักอย่างร้ายแรงหรือประสิทธิภาพที่ลดลงจนทำให้ระบบนั้นไม่เหมาะสมสำหรับการใช้งานไม่ว่าคะแนนที่ได้จากการวัดโดยรวมจะเป็นอย่างไรก็ตาม ข้อผิดพลาดในการเขียนโปรแกรมดังกล่าวที่พบในระดับระบบคิดเป็นสัดส่วนถึง 90 เปอร์เซ็นต์ของปัญหาในการผลิต ในขณะที่ในระดับหน่วย แม้จะมีจำนวนมากกว่ามาก แต่ข้อผิดพลาดในการเขียนโปรแกรมคิดเป็นสัดส่วนน้อยกว่า 10 เปอร์เซ็นต์ของปัญหาในการผลิต (ดูเพิ่มเติมที่กฎเก้าสิบต่อเก้าสิบ ) ดังนั้น คุณภาพของโค้ดที่ปราศจากบริบทของระบบทั้งหมด ดังที่W. Edwards Demingได้อธิบายไว้ จึงมีคุณค่าจำกัด

เพื่อดู สำรวจ วิเคราะห์ และสื่อสารการวัดคุณภาพซอฟต์แวร์ แนวคิดและเทคนิคการแสดงภาพข้อมูลช่วยให้มีวิธีการแสดงผลแบบโต้ตอบที่เป็นประโยชน์ โดยเฉพาะอย่างยิ่งหากการวัดคุณภาพซอฟต์แวร์หลายรายการต้องเชื่อมโยงกันหรือเชื่อมโยงกับส่วนประกอบของซอฟต์แวร์หรือระบบ ตัวอย่างเช่นแผนที่ซอฟต์แวร์แสดงถึงแนวทางเฉพาะที่ "สามารถแสดงและรวมข้อมูลเกี่ยวกับการพัฒนาซอฟต์แวร์ คุณภาพซอฟต์แวร์ และพลวัตของระบบ" ^{[ 13 ]}

คุณภาพซอฟต์แวร์ยังมีบทบาทในขั้นตอนการเผยแพร่ของโครงการซอฟต์แวร์ โดยเฉพาะอย่างยิ่ง คุณภาพและการกำหนดกระบวนการเผยแพร่ (รวมถึงกระบวนการแก้ไขข้อบกพร่อง ) ^{[ 14 ] [ 15 ]}การจัดการการกำหนดค่า^{[ 16 ]}เป็นส่วนสำคัญของกระบวนการวิศวกรรมซอฟต์แวร์โดยรวม^{[ 17 ] [ 18 ] [ 19 ]}

คุณภาพของซอฟต์แวร์ได้รับแรงผลักดันจากมุมมองหลักอย่างน้อยสองประการ:

• การจัดการความเสี่ยง : ความล้มเหลวของซอฟต์แวร์ไม่ได้ก่อให้เกิดเพียงแค่ความไม่สะดวกเท่านั้น ข้อผิดพลาดของซอฟต์แวร์อาจทำให้เกิดการเสียชีวิตของมนุษย์ได้ (ดูตัวอย่างเช่น: รายชื่อข้อบกพร่องของซอฟต์แวร์ ) สาเหตุมีตั้งแต่การออกแบบส่วนติดต่อผู้ใช้ที่ไม่ดีไปจนถึงข้อผิดพลาดในการเขียนโปรแกรมโดยตรง[ 20 ^{] [ 21 ] [ 22 ]ดูตัวอย่าง}เช่นกรณีของ Boeing 737หรือกรณีการเร่งความเร็วโดยไม่ตั้งใจ^{[ 23 ] [ 24 ]}หรือกรณีของTherac-25 ^{[ 25 ]}ส่งผลให้เกิดข้อกำหนดสำหรับการพัฒนาซอฟต์แวร์บางประเภท โดยเฉพาะอย่างยิ่งและในอดีตสำหรับซอฟต์แวร์ที่ฝังอยู่ในอุปกรณ์ทางการแพทย์และอุปกรณ์อื่นๆ ที่ควบคุมโครงสร้างพื้นฐานที่สำคัญ: "[วิศวกรที่เขียนซอฟต์แวร์ฝังตัว] เห็นโปรแกรม Java หยุดทำงานเป็นเวลาหนึ่งในสามของวินาทีเพื่อทำการเก็บขยะและอัปเดตส่วนติดต่อผู้ใช้ และพวกเขานึกภาพเครื่องบินตกจากท้องฟ้า" ^{[ 26 ]}ในสหรัฐอเมริกา ภายใต้สำนักงานบริหารการบินแห่งสหรัฐอเมริกา (FAA) บริการรับรองอากาศยานของ FAA ให้บริการโปรแกรมซอฟต์แวร์ นโยบาย คำแนะนำ และการฝึกอบรม โดยมุ่งเน้นที่ซอฟต์แวร์และฮาร์ดแวร์อิเล็กทรอนิกส์ที่ซับซ้อนซึ่งมีผลต่อผลิตภัณฑ์ทางอากาศ ("ผลิตภัณฑ์" หมายถึง อากาศยาน เครื่องยนต์ หรือใบพัด) ^{[ 27 ]}มาตรฐานการรับรอง เช่นDO-178C , ISO 26262 , IEC 62304เป็นต้น ให้คำแนะนำ
• การจัดการต้นทุน : เช่นเดียวกับในสาขาวิศวกรรมอื่นๆ ผลิตภัณฑ์หรือบริการซอฟต์แวร์ที่มีคุณภาพซอฟต์แวร์ที่ดีจะมีต้นทุนในการบำรุงรักษาน้อยกว่า เข้าใจง่ายกว่า และสามารถเปลี่ยนแปลงได้อย่างคุ้มค่ามากขึ้นเพื่อตอบสนองต่อความต้องการทางธุรกิจที่เร่งด่วน^{[ 28 ]}ข้อมูลจากอุตสาหกรรมแสดงให้เห็นว่าคุณภาพโครงสร้างแอปพลิเคชันที่ไม่ดีในแอปพลิเคชันทางธุรกิจ หลัก (เช่นระบบวางแผนทรัพยากรองค์กร (ERP) ระบบ บริหารจัดการลูกค้าสัมพันธ์ (CRM) หรือ ระบบ ประมวลผลธุรกรรม ขนาดใหญ่ ในบริการทางการเงิน) ส่งผลให้ต้นทุนสูงขึ้น กำหนดการล่าช้า และสร้างความสูญเปล่าในรูปแบบของการทำงานซ้ำ (ดูMuda (คำศัพท์ภาษาญี่ปุ่น) ) ^{[ 29 ] [ 30 ] [ 31 ]}ยิ่งไปกว่านั้น คุณภาพโครงสร้างที่ไม่ดีมีความสัมพันธ์อย่างมากกับการหยุดชะงักทางธุรกิจที่มีผลกระทบสูงเนื่องจากข้อมูลเสียหาย การหยุดทำงานของแอปพลิเคชัน การละเมิดความปลอดภัย และปัญหาด้านประสิทธิภาพ^{[ 32 ]}
  • รายงานของ CISQ เกี่ยวกับต้นทุนของสินค้าคุณภาพต่ำประเมินผลกระทบดังนี้:
    • 2.08 ล้านล้านดอลลาร์ในปี 2020 ^{[ 33 ] [ 34 ]}
    • 2.84 ล้านล้านดอลลาร์สหรัฐในปี 2018
  • รายงานต้นทุนการละเมิดข้อมูลของ IBM ปี 2020 ประมาณการว่าต้นทุนเฉลี่ยทั่วโลกของการละเมิดข้อมูลมีดังนี้: ^{[ 35 ]}
    • 3.86 ล้านเหรียญสหรัฐ

คุณภาพซอฟต์แวร์คือ "ความสามารถของผลิตภัณฑ์ซอฟต์แวร์ในการปฏิบัติตามข้อกำหนด" ^{[ 36 ] [ 37 ]}ในขณะที่สำหรับบางคนอาจมีความหมายเหมือนกันกับการสร้างลูกค้าหรือคุณค่า^{[ 38 ] [ 39 ]}หรือแม้กระทั่งระดับข้อบกพร่อง^{[ 40 ]}การวัดคุณภาพซอฟต์แวร์สามารถแบ่งออกเป็นสามส่วน ได้แก่ คุณภาพกระบวนการ คุณภาพผลิตภัณฑ์ ซึ่งรวมถึงคุณสมบัติภายในและภายนอก และสุดท้าย คุณภาพในการใช้งาน ซึ่งเป็นผลกระทบของซอฟต์แวร์^{[ 41 ]}

ASQใช้คำจำกัดความต่อไปนี้: คุณภาพซอฟต์แวร์อธิบายถึงคุณลักษณะที่พึงประสงค์ของผลิตภัณฑ์ซอฟต์แวร์ มีแนวทางหลักสองประการ ได้แก่ การจัดการข้อบกพร่องและคุณลักษณะด้านคุณภาพ^{[ 42 ]}

การรับประกันซอฟต์แวร์ (SA) ครอบคลุมทั้งคุณสมบัติและกระบวนการเพื่อให้ได้มาซึ่งคุณสมบัตินั้น: ^{[ 43 ]}

• ความมั่นใจที่สมเหตุสมผลว่าซอฟต์แวร์นั้นปราศจากช่องโหว่ ไม่ว่าจะเป็นช่องโหว่ที่ออกแบบมาโดยเจตนาหรือช่องโหว่ที่เกิดขึ้นโดยไม่ได้ตั้งใจในระหว่างวงจรชีวิตของซอฟต์แวร์ และซอฟต์แวร์นั้นทำงานได้ตามที่ตั้งใจไว้
• ชุดกิจกรรมที่วางแผนและเป็นระบบซึ่งรับประกันว่ากระบวนการและผลิตภัณฑ์ในวงจรชีวิตของซอฟต์แวร์เป็นไปตามข้อกำหนด มาตรฐาน และขั้นตอนต่างๆ

คู่มือ PMBOKของสถาบันการจัดการโครงการ "ส่วนขยายซอฟต์แวร์" ไม่ได้นิยาม"คุณภาพซอฟต์แวร์"เอง แต่นิยามการประกันคุณภาพซอฟต์แวร์ (SQA) ว่าเป็น"กระบวนการต่อเนื่องที่ตรวจสอบกระบวนการซอฟต์แวร์อื่นๆ เพื่อให้แน่ใจว่ากระบวนการเหล่านั้นได้รับการปฏิบัติตาม (รวมถึงแผนการจัดการคุณภาพซอฟต์แวร์เป็นต้น)"ในขณะที่การควบคุมคุณภาพซอฟต์แวร์ (SCQ) หมายถึง"การดูแลในการใช้วิธีการ เครื่องมือ เทคนิค เพื่อให้มั่นใจว่าผลิตภัณฑ์งานเป็นไปตามข้อกำหนดด้านคุณภาพสำหรับซอฟต์แวร์ที่อยู่ระหว่างการพัฒนาหรือการแก้ไข" ^{[ 44 ]}

นิยามแรกของคำว่าคุณภาพในประวัติศาสตร์ที่บันทึกไว้มาจาก Shewhart ในช่วงต้นศตวรรษที่ 20: "คุณภาพมีสองด้านที่เหมือนกัน ด้านหนึ่งเกี่ยวข้องกับการพิจารณาคุณภาพของสิ่งใดสิ่งหนึ่งในฐานะความเป็นจริงเชิงวัตถุวิสัยที่ไม่ขึ้นกับการดำรงอยู่ของมนุษย์ อีกด้านหนึ่งเกี่ยวข้องกับสิ่งที่เราคิด รู้สึก หรือรับรู้ อันเป็นผลมาจากความเป็นจริงเชิงวัตถุวิสัย กล่าวอีกนัยหนึ่งคือ คุณภาพมีด้านอัตวิสัย" ^{[ 45 ]}

Kitchenhamและ Pfleeger รายงานเพิ่มเติมเกี่ยวกับคำสอนของ David Garvin ระบุมุมมองที่แตกต่างกัน 5 ประการเกี่ยวกับคุณภาพ: ^{[ 46 ] [ 47 ]}

• มุมมองเชิงอภิปรัชญาเกี่ยวข้องกับแง่มุมทางอภิปรัชญาของคุณภาพ ในมุมมองนี้ คุณภาพคือ "บางสิ่งที่เราพยายามไปให้ถึงในฐานะอุดมคติ แต่อาจไม่สามารถบรรลุได้อย่างสมบูรณ์" ^{[ 48 ]}แทบจะนิยามไม่ได้ แต่คล้ายกับสิ่งที่ผู้พิพากษาของรัฐบาลกลางเคยแสดงความคิดเห็นเกี่ยวกับความลามกอนาจารว่า "ฉันรู้ว่ามันคืออะไรเมื่อฉันเห็นมัน" ^{[ 49 ]}
• มุมมองของผู้ใช้เกี่ยวข้องกับความเหมาะสมของผลิตภัณฑ์สำหรับบริบทการใช้งานที่กำหนด ในขณะที่มุมมองแบบเหนือธรรมชาติเป็นสิ่งที่จับต้องไม่ได้ มุมมองของผู้ใช้จะมีความเป็นรูปธรรมมากกว่า โดยยึดตามคุณลักษณะของผลิตภัณฑ์ที่ตรงกับความต้องการของผู้ใช้^{[ 48 ]}
• มุมมองการผลิตแสดงถึงคุณภาพในแง่ของการปฏิบัติตามข้อกำหนด มาตรฐานต่างๆ เช่น ISO 9001 เน้นย้ำถึงแง่มุมของคุณภาพนี้ โดยกำหนดคุณภาพว่า "ระดับที่ชุดคุณลักษณะโดยธรรมชาติเป็นไปตามข้อกำหนด" (ISO/IEC 9001 ^{[ 50 ]} )
• มุมมองด้านผลิตภัณฑ์บ่งชี้ว่า คุณภาพสามารถประเมินได้จากการวัดคุณลักษณะที่แท้จริงของผลิตภัณฑ์
• มุมมองสุดท้ายของคุณภาพคือมุมมองที่อิงตามคุณค่า^{[ 38 ]}มุมมองนี้ยอมรับว่ามุมมองที่แตกต่างกันของคุณภาพอาจมีความสำคัญหรือคุณค่าที่แตกต่างกันสำหรับผู้มีส่วนได้ส่วนเสียต่างๆ

ปัญหาที่เกิดขึ้นในการพยายามกำหนดคุณภาพของผลิตภัณฑ์ ไม่ว่าจะเป็นผลิตภัณฑ์ใดก็ตาม ได้รับการกล่าวถึงโดยอาจารย์ Walter A. Shewhart ความยากลำบากในการกำหนดคุณภาพคือการแปลความต้องการในอนาคตของผู้ใช้ให้เป็นคุณลักษณะที่วัดได้ เพื่อให้สามารถออกแบบและผลิตผลิตภัณฑ์ออกมาให้ผู้ใช้พึงพอใจในราคาที่ผู้ใช้ยินดีจ่าย ซึ่งไม่ใช่เรื่องง่าย และทันทีที่รู้สึกว่าประสบความสำเร็จพอสมควรในความพยายามนี้ ก็จะพบว่าความต้องการของผู้บริโภคเปลี่ยนไป คู่แข่งเข้ามาแข่งขัน ฯลฯ^{[ 51 ]}

คุณภาพเป็นสิ่งที่ลูกค้ากำหนด ไม่ใช่สิ่งที่วิศวกรกำหนด ไม่ใช่สิ่งที่ฝ่ายการตลาดกำหนด หรือสิ่งที่ฝ่ายบริหารกำหนดโดยทั่วไป คุณภาพขึ้นอยู่กับประสบการณ์จริงของลูกค้าที่มีต่อผลิตภัณฑ์หรือบริการ โดยวัดจากความต้องการของเขาหรือเธอ ไม่ว่าจะระบุไว้หรือไม่ระบุไว้ รู้ตัวหรือไม่รู้ตัว ใช้งานได้จริงทางเทคนิคหรือเป็นอัตวิสัยโดยสิ้นเชิง และเป็นเป้าหมายที่เปลี่ยนแปลงอยู่เสมอในตลาดที่มีการแข่งขัน^{[ 52 ]}

คำว่าคุณภาพมีความหมายหลายอย่าง ความหมายสองอย่างที่ใช้กันมากที่สุดคือ 1. คุณภาพประกอบด้วยคุณลักษณะของผลิตภัณฑ์ที่ตรงตามความต้องการของลูกค้าและทำให้เกิดความพึงพอใจในผลิตภัณฑ์ 2. คุณภาพประกอบด้วยการปราศจากข้อบกพร่อง อย่างไรก็ตาม ในคู่มือเช่นนี้ การกำหนดนิยามสั้นๆ ของคำว่าคุณภาพเป็น "ความเหมาะสมสำหรับการใช้งาน" ถือเป็นเรื่องสะดวก^{[ 53 ]}

ทอม เดอมาร์โคได้เสนอว่า "คุณภาพของผลิตภัณฑ์นั้นขึ้นอยู่กับว่ามันเปลี่ยนแปลงโลกให้ดีขึ้นได้มากเพียงใด" เดอมาร์โค, ทอม (1999). "การจัดการสามารถทำให้คุณภาพเป็นไปได้ (หรือไม่เป็นไปได้)" การประชุมสุดยอดด้านไอทีของคัตเตอร์{{cite web}}: ข้อมูลหายไปหรือว่างเปล่า|url=( ความช่วยเหลือ )นี่อาจตีความได้ว่า คุณภาพการใช้งานและความพึงพอใจของผู้ใช้มีความสำคัญมากกว่าคุณภาพเชิงโครงสร้างในการพิจารณาคุณภาพซอฟต์แวร์

นิยามอีกประการหนึ่งที่ Gerald Weinbergบัญญัติไว้ใน Quality Software Management: Systems Thinking คือ "คุณภาพคือคุณค่าสำหรับบุคคลบางคน" ^{[ 54 ] [ 55 ]}

หนึ่งในความท้าทายในการกำหนดคุณภาพคือ "ทุกคนรู้สึกว่าเข้าใจมัน" ^{[ 56 ]}และคำจำกัดความอื่น ๆ ของคุณภาพซอฟต์แวร์อาจขึ้นอยู่กับการขยายคำอธิบายต่าง ๆ ของแนวคิดคุณภาพที่ใช้ในธุรกิจ

คุณภาพซอฟต์แวร์มักจะถูกเข้าใจผิดว่าเป็นส่วนหนึ่งของการประกันคุณภาพ หรือการจัดการแก้ไขปัญหา^{[ 57 ]} หรือการควบคุมคุณภาพ^{[ 58 ]} หรือDevOpsมันทับซ้อนกับพื้นที่เหล่านี้ (ดูคำจำกัดความของ PMI ด้วย) แต่มีลักษณะเฉพาะคือไม่ได้มุ่งเน้นเฉพาะการทดสอบเท่านั้น แต่ยังรวมถึงกระบวนการ การจัดการ การปรับปรุง การประเมิน ฯลฯ ด้วย^{[ 58 ]}

การวัดคุณภาพซอฟต์แวร์ด้วยวิธีที่สามารถนำไปใช้ในการตัดสินใจของนักพัฒนาได้นั้นเป็นเรื่องยาก ความยากลำบากนี้เกิดขึ้นส่วนหนึ่งเพราะคุณลักษณะด้านคุณภาพหลายอย่าง เช่น ความซับซ้อนหรือความสามารถในการบำรุงรักษา มีหลายมิติและไม่สามารถวัดได้อย่างครบถ้วนด้วยตัวชี้วัดเดียว^{[ 59 ]}

แม้ว่าแนวคิดที่นำเสนอในส่วนนี้จะใช้ได้กับทั้งคุณภาพซอฟต์แวร์เชิงโครงสร้างและเชิงฟังก์ชัน แต่การวัดคุณภาพซอฟต์แวร์เชิงฟังก์ชันนั้นโดยพื้นฐานแล้วจะดำเนินการผ่าน การ ทดสอบซอฟต์แวร์^{[ 60 ]}การทดสอบอย่างเดียวไม่เพียงพอ: จากการศึกษาหนึ่งพบว่า "โปรแกรมเมอร์แต่ละคนมีประสิทธิภาพในการค้นหาข้อบกพร่องในซอฟต์แวร์ของตนเองน้อยกว่า 50% และการทดสอบส่วนใหญ่มีประสิทธิภาพเพียง 35% เท่านั้น ทำให้ยากที่จะกำหนดคุณภาพ [ซอฟต์แวร์]" ^{[ 61 ]}

การวัดคุณภาพซอฟต์แวร์คือการหาปริมาณว่าระบบหรือซอฟต์แวร์นั้นมีคุณลักษณะที่พึงประสงค์มากน้อยเพียงใด ซึ่งสามารถทำได้โดยวิธีการเชิงคุณภาพหรือเชิงปริมาณ หรือผสมผสานทั้งสองวิธี ในทั้งสองกรณี สำหรับคุณลักษณะที่พึงประสงค์แต่ละอย่าง จะมีชุดของคุณลักษณะที่วัดได้ ซึ่งการมีอยู่ของคุณลักษณะเหล่านั้นในซอฟต์แวร์หรือระบบมักจะมีความสัมพันธ์และเกี่ยวข้องกับคุณลักษณะดังกล่าว ตัวอย่างเช่น คุณลักษณะที่เกี่ยวข้องกับความสามารถในการพกพาคือจำนวนคำสั่งที่ขึ้นอยู่กับเป้าหมายในโปรแกรม กล่าวโดยละเอียดแล้ว การใช้ แนวทาง Quality Function Deployment ( QFDE) คุณลักษณะที่วัดได้เหล่านี้คือ "วิธีการ" ที่ต้องบังคับใช้เพื่อให้ "สิ่งที่ต้องการ" ในคำจำกัดความของคุณภาพซอฟต์แวร์ข้างต้นเกิดขึ้นได้

โครงสร้าง การจำแนกประเภท และคำศัพท์ของคุณลักษณะและตัวชี้วัดที่ใช้ได้กับการจัดการคุณภาพซอฟต์แวร์นั้น ได้มาจากการดัดแปลงหรือดึงมาจากมาตรฐาน คุณภาพ ISO 9126-3และมาตรฐานคุณภาพ ISO/IEC 25000:2005 ที่ตามมา โดยเน้นที่คุณภาพเชิงโครงสร้างภายในเป็นหลัก มีการสร้างหมวดหมู่ย่อยขึ้นเพื่อจัดการกับพื้นที่เฉพาะ เช่น สถาปัตยกรรมแอปพลิเคชันทางธุรกิจ และลักษณะทางเทคนิค เช่น การเข้าถึงและการจัดการข้อมูล หรือแนวคิดเรื่องธุรกรรม

แผนภาพด้านขวาแสดงแผนผังความสัมพันธ์ระหว่างคุณลักษณะคุณภาพซอฟต์แวร์และคุณลักษณะที่วัดได้ โดยแต่ละคุณลักษณะทั้ง 5 ประการที่มีความสำคัญต่อผู้ใช้ (ด้านขวา) หรือเจ้าของระบบธุรกิจนั้นขึ้นอยู่กับคุณลักษณะที่วัดได้ (ด้านซ้าย):

• แนวทางปฏิบัติทางสถาปัตยกรรมแอปพลิเคชัน
• หลักปฏิบัติในการเขียนโค้ด
• ความซับซ้อนของแอปพลิเคชัน
• เอกสารประกอบ
• พกพาสะดวก
• ปริมาณทางเทคนิคและการใช้งาน

ความสัมพันธ์ระหว่างข้อผิดพลาดในการเขียนโปรแกรมและข้อบกพร่องในการผลิตเผยให้เห็นว่าข้อผิดพลาดของโค้ดพื้นฐานคิดเป็น 92 เปอร์เซ็นต์ของข้อผิดพลาดทั้งหมดในซอร์สโค้ด ปัญหาในระดับโค้ดจำนวนมากเหล่านี้คิดเป็นเพียง 10 เปอร์เซ็นต์ของข้อบกพร่องในการผลิตเท่านั้น แนวทางปฏิบัติที่ไม่ดีด้านวิศวกรรมซอฟต์แวร์ในระดับสถาปัตยกรรมคิดเป็นเพียง 8 เปอร์เซ็นต์ของข้อบกพร่องทั้งหมด แต่ใช้ความพยายามมากกว่าครึ่งหนึ่งในการแก้ไขปัญหา และนำไปสู่ปัญหาความน่าเชื่อถือ ความปลอดภัย และประสิทธิภาพที่ร้ายแรงถึง 90 เปอร์เซ็นต์ในการผลิต^{[ 62 ] [ 63 ]}

มาตรการซอฟต์แวร์ที่มีอยู่จำนวนมากนับองค์ประกอบโครงสร้างของแอปพลิเคชันที่เป็นผลมาจากการแยกวิเคราะห์ซอร์สโค้ดสำหรับคำสั่งแต่ละรายการ^{[ 64 ]}โทเค็น^{[ 65 ]}โครงสร้างควบคุม ( ความซับซ้อน ) และวัตถุ^{[ 66 ]}

การวัดคุณภาพซอฟต์แวร์คือการหาปริมาณว่าระบบหรือซอฟต์แวร์นั้น ๆ มีประสิทธิภาพในมิติต่าง ๆ มากน้อยเพียงใด การวิเคราะห์สามารถทำได้โดยใช้วิธีการเชิงคุณภาพหรือเชิงปริมาณ หรือผสมผสานทั้งสองวิธีเพื่อให้ได้ภาพรวม (เช่น การใช้ค่าเฉลี่ยถ่วงน้ำหนักที่สะท้อนถึงความสำคัญสัมพัทธ์ระหว่างปัจจัยที่วัด)

มุมมองเกี่ยวกับคุณภาพซอฟต์แวร์บนเส้นต่อเนื่องเชิงเส้นนี้จะต้องได้รับการเสริมด้วยการระบุข้อผิดพลาดในการเขียนโปรแกรมที่สำคัญ แบบแยกส่วน ช่องโหว่เหล่านี้อาจไม่ทำให้การทดสอบล้มเหลว แต่เป็นผลมาจากการปฏิบัติที่ไม่ดีซึ่งภายใต้สถานการณ์เฉพาะอาจนำไปสู่การหยุดชะงักที่ร้ายแรง ประสิทธิภาพที่ลดลง การละเมิดความปลอดภัย ข้อมูลที่เสียหาย และปัญหาอื่นๆ อีกมากมาย^{[ 67 ]}ที่ทำให้ระบบที่กำหนดไม่เหมาะสมสำหรับการใช้งานโดยพฤตินัยโดยไม่คำนึงถึงการจัดอันดับตามการวัดโดยรวม ตัวอย่างที่รู้จักกันดีของช่องโหว่คือCommon Weakness Enumeration [ ^{68 ] ซึ่ง}เป็นคลังของช่องโหว่ในซอร์สโค้ดที่ทำให้แอปพลิเคชันเสี่ยงต่อการละเมิดความปลอดภัย

การวัดคุณลักษณะที่สำคัญของแอปพลิเคชันเกี่ยวข้องกับการวัดคุณลักษณะเชิงโครงสร้างของสถาปัตยกรรม การเขียนโค้ด และเอกสารประกอบแบบอินไลน์ของแอปพลิเคชัน ดังแสดงในภาพด้านบน ดังนั้น คุณลักษณะแต่ละอย่างจึงได้รับผลกระทบจากคุณลักษณะในระดับนามธรรมหลายระดับในแอปพลิเคชัน และคุณลักษณะทั้งหมดเหล่านี้จะต้องรวมอยู่ในการคำนวณการวัดคุณลักษณะ หากต้องการให้เป็นตัวทำนายผลลัพธ์ด้านคุณภาพที่มีคุณค่าซึ่งส่งผลต่อธุรกิจ แนวทางแบบหลายชั้นในการคำนวณการวัดคุณลักษณะที่แสดงในภาพด้านบนได้รับการเสนอครั้งแรกโดย Boehm และเพื่อนร่วมงานของเขาที่ TRW (Boehm, 1978) ^{[ 69 ]}และเป็นแนวทางที่ใช้ในมาตรฐาน ISO 9126 และ 25000 คุณลักษณะเหล่านี้สามารถวัดได้จากผลลัพธ์ที่แยกวิเคราะห์จากการวิเคราะห์แบบคงที่ของซอร์สโค้ดของแอปพลิเคชัน แม้แต่คุณลักษณะแบบไดนามิกของแอปพลิเคชัน เช่น ความน่าเชื่อถือและประสิทธิภาพการทำงาน ก็มีรากฐานมาจากโครงสร้างแบบคงที่ของแอปพลิเคชัน

การวิเคราะห์และวัดคุณภาพเชิงโครงสร้างนั้นดำเนินการโดยการวิเคราะห์ซอร์สโค้ดสถาปัตยกรรมเฟรมเวิร์กซอฟต์แวร์และสคีมาฐานข้อมูลโดยพิจารณาจากหลักการและมาตรฐานต่างๆ ที่ร่วมกันกำหนดสถาปัตยกรรมเชิงแนวคิดและเชิงตรรกะของระบบ ซึ่งแตกต่างจากการวิเคราะห์โค้ดระดับส่วนประกอบพื้นฐานที่มักดำเนินการโดยเครื่องมือพัฒนาซอฟต์แวร์ซึ่งส่วนใหญ่มุ่งเน้นไปที่การพิจารณาการใช้งานจริง และมีความสำคัญอย่างยิ่งในระหว่างกิจกรรม การดีบักและการทดสอบ

สาเหตุหลักของความน่าเชื่อถือต่ำนั้นเกิดจากการไม่ปฏิบัติตามหลักการออกแบบสถาปัตยกรรมและการเขียนโค้ดที่ดี การไม่ปฏิบัติตามหลักการเหล่านี้สามารถตรวจพบได้โดยการวัดคุณลักษณะด้านคุณภาพแบบคงที่ของแอปพลิเคชัน การประเมินคุณลักษณะแบบคงที่ซึ่งเป็นพื้นฐานของความน่าเชื่อถือของแอปพลิเคชันจะช่วยประเมินระดับความเสี่ยงทางธุรกิจและความน่าจะเป็นของความล้มเหลวและข้อบกพร่องที่อาจเกิดขึ้นกับแอปพลิเคชันเมื่อนำไปใช้งาน

การประเมินความน่าเชื่อถือจำเป็นต้องตรวจสอบอย่างน้อยหลักปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์และคุณลักษณะทางเทคนิคดังต่อไปนี้:

ขึ้นอยู่กับสถาปัตยกรรมของแอปพลิเคชันและส่วนประกอบของบุคคลที่สามที่ใช้ (เช่น ไลบรารีภายนอกหรือเฟรมเวิร์ก) ควรมีการกำหนดการตรวจสอบแบบกำหนดเองตามแนวทางที่ระบุไว้ในรายการแนวทางปฏิบัติที่ดีที่สุดข้างต้น เพื่อให้มั่นใจได้ว่าสามารถประเมินความน่าเชื่อถือของซอฟต์แวร์ที่ส่งมอบได้ดียิ่งขึ้น

เช่นเดียวกับเรื่องความน่าเชื่อถือ สาเหตุของประสิทธิภาพการทำงานที่ลดลงมักพบได้จากการละเมิดหลักปฏิบัติที่ดีด้านสถาปัตยกรรมและการเขียนโค้ด ซึ่งสามารถตรวจพบได้โดยการวัดคุณลักษณะด้านคุณภาพแบบคงที่ของแอปพลิเคชัน คุณลักษณะแบบคงที่เหล่านี้สามารถทำนายปัญหาคอขวดด้านประสิทธิภาพการทำงานที่อาจเกิดขึ้นและปัญหาด้านความสามารถในการขยายขนาดในอนาคต โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันที่ต้องการความเร็วในการประมวลผลสูงเพื่อจัดการกับอัลกอริทึมที่ซับซ้อนหรือข้อมูลจำนวนมหาศาล

การประเมินประสิทธิภาพการทำงานจำเป็นต้องตรวจสอบอย่างน้อยหลักปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์และคุณลักษณะทางเทคนิคดังต่อไปนี้:

• แนวทางปฏิบัติทางสถาปัตยกรรมแอปพลิเคชัน
• การปฏิสัมพันธ์ที่เหมาะสมกับแหล่งข้อมูลที่มีราคาแพงและ/หรืออยู่ห่างไกล
• ประสิทธิภาพการเข้าถึงข้อมูลและการจัดการข้อมูล
• การจัดการหน่วยความจำ เครือข่าย และพื้นที่ดิสก์
• การปฏิบัติตามหลักการเขียนโค้ด^{[ 70 ]} ( หลักการเขียนโค้ดที่ดีที่สุด )

คุณภาพซอฟต์แวร์รวมถึง ความปลอดภัย ของซอฟต์แวร์^{[ 71 ]}ช่องโหว่ด้านความปลอดภัยจำนวนมากเกิดจากการเขียนโค้ดและแนวทางปฏิบัติทางสถาปัตยกรรมที่ไม่ดี เช่น การโจมตีแบบ SQL injection หรือ cross-site scripting ^{[ 72 ] [ 73 ]}สิ่งเหล่านี้ได้รับการบันทึกไว้อย่างดีในรายการที่ดูแลโดย CWE ^{[ 74 ]}และ SEI/Computer Emergency Center (CERT)ที่มหาวิทยาลัย Carnegie Mellon ^{[ 70 ]}

การประเมินความปลอดภัยจำเป็นต้องตรวจสอบอย่างน้อยที่สุดหลักปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์และคุณลักษณะทางเทคนิคดังต่อไปนี้:

• การนำไปใช้ การจัดการกระบวนการพัฒนาที่คำนึงถึงความปลอดภัยและเสริมความแข็งแกร่ง เช่นวงจรการพัฒนาความปลอดภัย (Microsoft) หรือกรอบงานวิศวกรรมความปลอดภัยของ IBM ^{[ 75 ]}
• แนวปฏิบัติสถาปัตยกรรมแอปพลิเคชันที่ปลอดภัย^{[ 76 ] [ 77 ]}
• การปฏิบัติตามการออกแบบหลายชั้น
• แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย (การตรวจสอบความถูกต้องของข้อมูลขาเข้า, การโจมตี SQL Injection, การโจมตี Cross-Site Scripting, การควบคุมการเข้าถึง ฯลฯ) ^{[ 78 ] [ 79 ]}
• แนวทางการเขียนโปรแกรมที่ปลอดภัยและดี^{[ 70 ]}
• การจัดการข้อผิดพลาดและข้อยกเว้น

ความสามารถในการบำรุงรักษาประกอบด้วยแนวคิดเรื่องความเป็นโมดูลาร์ความเข้าใจได้ ความสามารถในการเปลี่ยนแปลง ความสามารถในการทดสอบ ความสามารถในการนำกลับมาใช้ใหม่ และความสามารถในการถ่ายโอนจากทีมพัฒนาหนึ่งไปยังอีกทีมหนึ่ง สิ่งเหล่านี้ไม่ได้อยู่ในรูปแบบของปัญหาที่สำคัญในระดับโค้ด แต่ความสามารถในการบำรุงรักษาที่ไม่ดีมักเป็นผลมาจากการละเมิดเล็กน้อยนับพันครั้งในแนวทางปฏิบัติที่ดีที่สุดในด้านเอกสาร กลยุทธ์การหลีกเลี่ยงความซับซ้อน และแนวทางปฏิบัติการเขียนโปรแกรมพื้นฐานที่สร้างความแตกต่างระหว่างโค้ดที่สะอาดและอ่านง่ายกับโค้ดที่ไม่เป็นระเบียบและอ่านยาก^{[ 80 ]}

การประเมินความสามารถในการบำรุงรักษาจำเป็นต้องตรวจสอบหลักปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์และคุณลักษณะทางเทคนิคดังต่อไปนี้:

ความสามารถในการบำรุงรักษาเกี่ยวข้องอย่างใกล้ชิดกับแนวคิดเรื่องหนี้ทางเทคนิค ของ Ward Cunningham ซึ่งเป็นการแสดงออกถึงต้นทุนที่เกิดจากการขาดความสามารถในการบำรุงรักษา สาเหตุที่ความสามารถในการบำรุงรักษาต่ำสามารถจำแนกได้เป็นความประมาทเลินเล่อเทียบกับความรอบคอบ และเจตนาเทียบกับความไม่ตั้งใจ^{[ 81 ] [ 82 ]}และมักมีต้นกำเนิดมาจากความไม่สามารถของนักพัฒนา การขาดเวลาและเป้าหมาย ความประมาทเลินเล่อ และความไม่สอดคล้องกันในต้นทุนและผลประโยชน์ของการสร้างเอกสาร และโดยเฉพาะอย่างยิ่งซอร์สโค้ด ที่สามารถบำรุง รักษา ได้ ^{[ 83 ]}

การวัดขนาดซอฟต์แวร์จำเป็นต้องรวบรวมซอร์สโค้ดทั้งหมดอย่างถูกต้อง รวมถึงสคริปต์โครงสร้างฐานข้อมูล ซอร์สโค้ดการจัดการข้อมูล เฮดเดอร์ของคอมโพเนนต์ ไฟล์การกำหนดค่า ฯลฯ โดยพื้นฐานแล้วขนาดซอฟต์แวร์ที่ต้องวัดมีสองประเภท คือ ขนาดทางเทคนิค (ฟุตพรินต์) และขนาดเชิงฟังก์ชัน:

• มี วิธี การประเมินขนาดทางเทคนิคของซอฟต์แวร์ หลาย วิธีที่ได้รับการอธิบายอย่างกว้างขวาง วิธีการประเมินขนาดทางเทคนิคที่พบได้บ่อยที่สุดคือ จำนวนบรรทัดของโค้ด (#LOC) ต่อเทคโนโลยี จำนวนไฟล์ ฟังก์ชัน คลาส ตาราง ฯลฯ ซึ่งสามารถคำนวณค่า Function Point ที่เกิดขึ้นได้
• วิธีการวัดขนาดฟังก์ชันการทำงานที่พบได้บ่อยที่สุดคือ การวิเคราะห์ ฟังก์ชันพอยต์ ( Function Point Analysis) การวิเคราะห์ฟังก์ชันพอยต์วัดขนาดของซอฟต์แวร์ที่ส่งมอบได้จากมุมมองของผู้ใช้ การกำหนดขนาดด้วยฟังก์ชันพอยต์ทำโดยอิงตามความต้องการของผู้ใช้ และให้การแสดงผลที่แม่นยำทั้งขนาดสำหรับนักพัฒนา/ผู้ประเมิน และคุณค่า (ฟังก์ชันการทำงานที่จะส่งมอบ) และสะท้อนถึงฟังก์ชันการทำงานทางธุรกิจที่ส่งมอบให้กับลูกค้า วิธีการนี้รวมถึงการระบุและการให้น้ำหนักกับอินพุต เอาต์พุต และแหล่งเก็บข้อมูลที่ผู้ใช้สามารถรับรู้ได้ จากนั้นค่าขนาดจะสามารถนำไปใช้ร่วมกับมาตรวัดต่างๆ เพื่อวัดและประเมินการส่งมอบและประสิทธิภาพของซอฟต์แวร์ (ต้นทุนการพัฒนาต่อฟังก์ชันพอยต์ ข้อบกพร่องที่ส่งมอบต่อฟังก์ชันพอยต์ ฟังก์ชันพอยต์ต่อเดือนของพนักงาน)

มาตรฐานการวิเคราะห์ฟังก์ชันพอยต์ (Function Point Analysis) ได้รับการสนับสนุนจากกลุ่มผู้ใช้ฟังก์ชันพอยต์ระหว่างประเทศ (International Function Point Users Group หรือIFPUG ) สามารถนำไปใช้ได้ตั้งแต่ช่วงต้นของวงจรการพัฒนาซอฟต์แวร์ และไม่ขึ้นอยู่กับจำนวนบรรทัดโค้ดเหมือนกับวิธีการ Backfiring ที่ไม่แม่นยำนัก วิธีการนี้ไม่ขึ้นกับเทคโนโลยีใดๆ และสามารถใช้สำหรับการวิเคราะห์เปรียบเทียบระหว่างองค์กรและอุตสาหกรรมต่างๆ ได้

นับตั้งแต่มีการคิดค้นการวิเคราะห์ Function Point ขึ้นมา ก็มีการพัฒนาและขยายขอบเขตของเทคนิคการวัดขนาดงานเชิงฟังก์ชันให้ครอบคลุมถึงวิธีการต่างๆ เช่น COSMIC, NESMA, Use Case Points, FP Lite, Early and Quick FPs และล่าสุดคือ Story Points Function Point มีประวัติความถูกต้องทางสถิติ และถูกใช้เป็นหน่วยวัดงานทั่วไปในการจัดการพัฒนาแอปพลิเคชัน (ADM) หรือการเอาท์ซอร์สจำนวนมาก โดยทำหน้าที่เป็น "หน่วยวัด" ที่ใช้ในการประเมินการส่งมอบบริการและวัดประสิทธิภาพ

ข้อจำกัดทั่วไปอย่างหนึ่งของวิธีการ Function Point คือเป็นกระบวนการแบบใช้คนทำ ซึ่งอาจใช้แรงงานมากและมีค่าใช้จ่ายสูงในโครงการขนาดใหญ่ เช่น การพัฒนาแอปพลิเคชันหรือการจ้างงานภายนอก ข้อเสียนี้อาจเป็นแรงผลักดันให้ผู้นำด้านไอทีในอุตสาหกรรมก่อตั้ง Consortium for IT Software Quality ซึ่งมุ่งเน้นการแนะนำมาตรฐานเมตริกที่คำนวณได้สำหรับการวัดขนาดซอฟต์แวร์โดยอัตโนมัติ ในขณะที่ IFPUG ยังคงส่งเสริมวิธีการแบบใช้คนทำ เนื่องจากกิจกรรมส่วนใหญ่ของ IFPUG ขึ้นอยู่กับการรับรองตัวนับ FP

CISQนิยามการกำหนดขนาดว่าเป็นการประมาณขนาดของซอฟต์แวร์เพื่อสนับสนุนการประมาณต้นทุน การติดตามความคืบหน้า หรือกิจกรรมการจัดการโครงการซอฟต์แวร์อื่นๆ ที่เกี่ยวข้อง มีการใช้มาตรฐานสองแบบ ได้แก่Automated Function Pointsเพื่อวัดขนาดฟังก์ชันของซอฟต์แวร์ และAutomated Enhancement Pointsเพื่อวัดขนาดของทั้งโค้ดฟังก์ชันและโค้ดที่ไม่ใช่ฟังก์ชันในการวัดครั้งเดียว^{[ 84 ]}

ข้อผิดพลาดในการเขียนโปรแกรมที่สำคัญคือแนวปฏิบัติที่ไม่ดีเฉพาะด้านสถาปัตยกรรมและ/หรือการเขียนโค้ด ซึ่งส่งผลให้เกิดความเสี่ยงต่อการหยุดชะงักทางธุรกิจสูงสุด ทั้งในระยะสั้นและระยะยาว^{[ 85 ]}

สิ่งเหล่านี้มักเกี่ยวข้องกับเทคโนโลยีและขึ้นอยู่กับบริบท วัตถุประสงค์ทางธุรกิจ และความเสี่ยงเป็นอย่างมาก บางคนอาจพิจารณาเรื่องการเคารพหลักเกณฑ์การตั้งชื่อ ในขณะที่บางคน เช่น ผู้ที่เตรียมการสำหรับการถ่ายทอดความรู้ จะถือว่าเรื่องนี้มีความสำคัญอย่างยิ่ง

ข้อผิดพลาดในการเขียนโปรแกรมที่สำคัญสามารถจำแนกได้ตามคุณลักษณะของ CISQ ตัวอย่างพื้นฐานมีดังต่อไปนี้:

• ความน่าเชื่อถือ
  • หลีกเลี่ยงรูปแบบการเขียนโปรแกรมที่อาจนำไปสู่พฤติกรรมที่ไม่คาดคิด ( เช่น ตัวแปรที่ไม่ได้กำหนดค่าเริ่มต้น , พอยเตอร์ที่เป็นค่าว่าง เป็นต้น)
  • วิธีการ ขั้นตอน และฟังก์ชันที่ทำการแทรก อัปเดต ลบ สร้างตาราง หรือเลือกข้อมูล ต้องมีการจัดการข้อผิดพลาดด้วย
  • ฟังก์ชันมัลติเธรดควรมีความปลอดภัยต่อเธรด ตัวอย่างเช่น เซิร์ฟเล็ตหรือ คลาสแอ็กชันของ Strutsจะต้องไม่มีฟิลด์สแตติกที่เป็นอินสแตนซ์/ไม่ใช่ค่าสุดท้าย
• ประสิทธิภาพ
  • ตรวจสอบให้แน่ใจว่าคำขอของลูกค้า (ขาเข้าและข้อมูล) ถูกรวมศูนย์ เพื่อลดปริมาณการรับส่งข้อมูลบนเครือข่าย
  • หลีกเลี่ยงการใช้คำสั่ง SQL ที่ไม่ใช้ดัชนีกับตารางขนาดใหญ่ในลูป
• ความปลอดภัย
  • หลีกเลี่ยงการใช้ฟิลด์ที่ไม่ใช่ final static ในคลาสเซิร์ฟเล็ต
  • หลีกเลี่ยงการเข้าถึงข้อมูลโดยไม่รวมการจัดการข้อผิดพลาด
  • ตรวจสอบรหัสส่งคืนของระบบควบคุมและนำกลไกการจัดการข้อผิดพลาดมาใช้
  • ตรวจสอบความถูกต้องของข้อมูลที่ป้อนเข้าเพื่อหลีกเลี่ยงช่องโหว่การโจมตีแบบ Cross-Site Scripting หรือ SQL Injection
• ความสามารถในการบำรุงรักษา
  • ควรหลีกเลี่ยงโครงสร้างลำดับชั้นทางพันธุกรรมที่ซับซ้อนและการซ้อนกันหลายระดับ เพื่อเพิ่มความเข้าใจง่าย
  • โมดูลควรมีการเชื่อมต่อแบบหลวมๆ (มีการกระจายสัญญาณและไม่มีตัวกลาง) เพื่อหลีกเลี่ยงการส่งต่อการเปลี่ยนแปลง
  • บังคับใช้หลักเกณฑ์การตั้งชื่อที่เป็นมาตรฐานเดียวกัน

ข้อเสนอใหม่ๆ สำหรับแบบจำลองคุณภาพ เช่นSqualeและ Quamoco ^{[ 86 ]}ส่งเสริมการบูรณาการโดยตรงของคำจำกัดความของคุณลักษณะคุณภาพและการวัดผล โดยการแบ่งคุณลักษณะคุณภาพออกเป็นส่วนย่อยๆ หรือแม้แต่การกำหนดชั้นเพิ่มเติม คุณลักษณะคุณภาพที่ซับซ้อนและเป็นนามธรรม (เช่น ความน่าเชื่อถือหรือความสามารถในการบำรุงรักษา) จะสามารถจัดการและวัดผลได้ง่ายขึ้น แบบจำลองคุณภาพเหล่านี้ถูกนำไปใช้ในบริบทอุตสาหกรรม แต่ยังไม่ได้รับการยอมรับอย่างแพร่หลาย

• แนวทางการพัฒนาระบบปฏิบัติการAndroid ที่มีคุณภาพ รวมถึงรายการตรวจสอบสำหรับส่วนติดต่อผู้ใช้ ความปลอดภัย และอื่นๆ เดือนกรกฎาคม 2564
• สมาคมผู้จัดการด้านเทคโนโลยีสารสนเทศและการสื่อสารทางทะเล (AMMITEC) แนวทางคุณภาพซอฟต์แวร์ทางทะเลกันยายน 2560
• Capers Jonesและ Olivier Bonsignour, "เศรษฐศาสตร์ของคุณภาพซอฟต์แวร์", Addison-Wesley Professional, ฉบับพิมพ์ครั้งที่ 1, 31 ธันวาคม 2011, ISBN 978-0-13-258220-9
• CAT Lab - ห้องปฏิบัติการเครื่องมือวิเคราะห์โค้ด CNES (บน GitHub)
• Girish Suryanarayana, กระบวนการซอฟต์แวร์เทียบกับคุณภาพการออกแบบ: การต่อสู้แย่งชิงกัน? ^{[ 87 ]}
• Ho-Won Jung, Seung-Gweon Kim และ Chang-Sin Chung การวัดคุณภาพผลิตภัณฑ์ซอฟต์แวร์: การสำรวจมาตรฐาน ISO/IEC 9126 IEEE Software , 21(5):10–13, กันยายน/ตุลาคม 2547
• องค์การมาตรฐานสากล. วิศวกรรมซอฟต์แวร์—คุณภาพผลิตภัณฑ์—ส่วนที่ 1: แบบจำลองคุณภาพ . ISO, เจนีวา, สวิตเซอร์แลนด์, 2001. ISO/IEC 9126-1:2001(E).
• การวัดคุณภาพผลิตภัณฑ์ซอฟต์แวร์: มาตรฐาน ISO 25000 และ CMMI (เว็บไซต์ SEI)
• MSQF - กรอบคุณภาพซอฟต์แวร์ที่อิงตามการวัดผลห้องสมุดมหาวิทยาลัยคอร์เนลล์
• Omar Alshathry, Helge Janicke, "การเพิ่มประสิทธิภาพการประกันคุณภาพซอฟต์แวร์," compsacw, หน้า 87–92, การประชุมเชิงปฏิบัติการ IEEE ครั้งที่ 34 ประจำปี 2010 ด้านซอฟต์แวร์คอมพิวเตอร์และการประยุกต์ใช้งาน, 2010
• โรเบิร์ต แอล. กลาส. การสร้างซอฟต์แวร์คุณภาพ . สำนักพิมพ์เพรนติส ฮอลล์, อัปเปอร์ แซดเดิล ริเวอร์, นิวเจอร์ซีย์, 1992.
• โรลันด์ เพตราสช์, " นิยามของ 'คุณภาพซอฟต์แวร์': แนวทางปฏิบัติ ", ISSRE, 1999
• ผู้เชี่ยวชาญด้านคุณภาพซอฟต์แวร์^{[ 88 ]}สมาคมคุณภาพแห่งอเมริกา (ASQ)
• วารสารคุณภาพซอฟต์แวร์^{[ 89 ]}โดยSpringer Nature
• Spinellis, Diomidis (4 เมษายน 2549). คุณภาพของโค้ด: มุมมองโอเพนซอร์ส . อัปเปอร์ แซดเดิล ริเวอร์, นิวเจอร์ซีย์, สหรัฐอเมริกา: Addison-Wesley Professional. ISBN 978-0-321-16607-4.
• Stephen H. Kan. ตัวชี้วัดและแบบจำลองในวิศวกรรมคุณภาพซอฟต์แวร์ . Addison-Wesley, Boston, MA, ฉบับพิมพ์ครั้งที่สอง, 2002.
• สเตฟาน วากเนอร์. การควบคุมคุณภาพผลิตภัณฑ์ซอฟต์แวร์ . สปริงเกอร์, 2013.

วิกิมีเดียคอมมอนส์มีสื่อที่เกี่ยวข้องกับคุณภาพซอฟต์แวร์

• เมื่อโค้ดคือราชา: การสร้างความเป็นเลิศด้านซอฟต์แวร์ยานยนต์ (McKinsey, 2021)
• คุณภาพซอฟต์แวร์ระบบฝังตัว: ทำไมมันถึงแย่บ่อยครั้ง? เราจะทำอะไรได้บ้าง? (โดยฟิลิป คูปแมน )
• มาตรฐานคุณภาพโค้ดโดยCISQ ™
• บล็อกของ CISQ: https://blog.it-cisq.org
• คู่มือการประกันคุณภาพซอฟต์แวร์ (ESA)
• คู่มือการประยุกต์ใช้มาตรฐานวิศวกรรมซอฟต์แวร์ ESA กับโครงการซอฟต์แวร์ขนาดเล็ก (ESA)
• ภาพรวมของบริการรับประกันคุณภาพผลิตภัณฑ์ซอฟต์แวร์ของ ESA (NASA/ESA)
• แนวทางการให้ความสำคัญกับคุณภาพของศูนย์พัฒนาซอฟต์แวร์ Volkswagen ในลิสบอน
• คู่มือการจัดรูปแบบของ Google
• การรับรองคุณภาพผลิตภัณฑ์ที่ Google (2011)
• การรับประกันคุณภาพซอฟต์แวร์ของ NASA
• กลุ่มคุณภาพซอฟต์แวร์ NIST
• OMG/CISQ Automated Function Points ( ISO/IEC 19515 )
• มาตรฐานหนี้ทางเทคนิคอัตโนมัติของ OMG
• การประกันคุณภาพอัตโนมัติ (บทความโดย Harry Sneed ใน IREB )
• การทดสอบแบบมีโครงสร้าง: วิธีการทดสอบโดยใช้เมตริกความซับซ้อนแบบไซโคลมาติก (1996)
• การวิเคราะห์คุณภาพแอปพลิเคชันโดยใช้เครื่องมือวิเคราะห์โค้ด (Microsoft, เอกสารประกอบ, Visual Studio, 2016)