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

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

คุณภาพของซอฟต์แวร์คือการรวบรวมคุณลักษณะของซอฟต์แวร์ที่เกี่ยวข้องกับความสามารถในการตอบสนองความต้องการที่ระบุไว้และที่ตั้งใจไว้

ลักษณะคุณภาพของซอฟต์แวร์

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

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

สะดวกในการใช้(Usability) – ความสามารถในการเข้าใจ ศึกษา การใช้งาน และความน่าดึงดูดใจของซอฟต์แวร์สำหรับผู้ใช้ได้อย่างง่ายดาย

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

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

การพกพา(ความสามารถในการพกพา) – กำหนดลักษณะของซอฟต์แวร์ในแง่ของความง่ายในการถ่ายโอนจากสภาพแวดล้อมหนึ่ง (ซอฟต์แวร์/ฮาร์ดแวร์) ไปยังอีกสภาพแวดล้อมหนึ่ง

แบบจำลองคุณภาพซอฟต์แวร์

ปัจจุบันมีการใช้งานกันมากที่สุด แบบจำลองคุณภาพซอฟต์แวร์หลายระดับนำเสนอในชุดมาตรฐาน ISO 9126โดดเด่นในระดับบนสุด 6 ลักษณะสำคัญของคุณภาพซอฟต์แวร์ซึ่งแต่ละรายการถูกกำหนดโดยชุดคุณลักษณะที่มีหน่วยวัดที่สอดคล้องกันสำหรับการประเมินในภายหลัง ( ดูรูปที่ 1).

รูปที่ 1 – โมเดลคุณภาพซอฟต์แวร์ (ISO 9126-1)

29. ลักษณะคุณภาพซอฟต์แวร์ (GOST)

GOST ISO 9126-93

คุณภาพของซอฟต์แวร์สามารถประเมินได้ตามลักษณะดังต่อไปนี้:

4.1 ฟังก์ชั่น(ฟังก์ชันการทำงาน) ชุดคุณลักษณะที่เกี่ยวข้องกับสาระสำคัญของชุดฟังก์ชันและคุณสมบัติเฉพาะของฟังก์ชัน ฟังก์ชั่นคือสิ่งที่ตอบสนองความต้องการที่ระบุไว้หรือที่คาดหวัง: หมายเหตุ

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

4.2 ความน่าเชื่อถือความน่าเชื่อถือ ชุดของคุณลักษณะที่เกี่ยวข้องกับความสามารถของซอฟต์แวร์ในการรักษาระดับประสิทธิภาพภายใต้เงื่อนไขที่กำหนดในช่วงเวลาที่กำหนด หมายเหตุ 1 ซอฟต์แวร์ไม่มีการสึกหรอหรือเสื่อมสภาพ ข้อจำกัดด้านความน่าเชื่อถือเกิดขึ้นเนื่องจากข้อผิดพลาดในข้อกำหนด การออกแบบ และการใช้งาน ความล้มเหลวเนื่องจากข้อผิดพลาดเหล่านี้ขึ้นอยู่กับวิธีใช้ซอฟต์แวร์และเวอร์ชันของซอฟต์แวร์ที่เลือกไว้ก่อนหน้านี้ หมายเหตุ 2 ISO 8402 ให้คำจำกัดความ "ความน่าเชื่อถือ" ว่าเป็น "ความสามารถขององค์ประกอบในการทำหน้าที่ที่ต้องการ" ในมาตรฐานนี้ ฟังก์ชันการทำงานเป็นเพียงคุณลักษณะหนึ่งของคุณภาพซอฟต์แวร์เท่านั้น ดังนั้น คำจำกัดความของความน่าเชื่อถือจึงถูกขยายเป็น "รักษาระดับประสิทธิภาพ" แทนที่จะ "ทำหน้าที่ที่จำเป็น" (ดู 3.4 เพิ่มเติม)

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

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

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

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

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

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

ระเบียบวิธีพัฒนาซอฟต์แวร์

คู่มืออิเล็กทรอนิกส์ Karpovich E.E.

การแนะนำ. 1

1. ซอฟต์แวร์ที่เป็นผลิตภัณฑ์อุตสาหกรรม 2

1.1 แนวคิดพื้นฐาน 2

1.2. ลักษณะคุณภาพของซอฟต์แวร์ 3

2. วงจรชีวิตของซอฟต์แวร์ 5

2.1. แนวคิดเรื่องวงจรชีวิตของซอฟต์แวร์ 5

2.2. กระบวนการวงจรชีวิตของซอฟต์แวร์ 6

2.3. แบบจำลองวงจรชีวิตของซอฟต์แวร์ สิบเอ็ด

2.4. กลยุทธ์การออกแบบซอฟต์แวร์ 15

3. วิธีการพัฒนาซอฟต์แวร์ 19

3.1 แนวทางเชิงโครงสร้างเพื่อการพัฒนาซอฟต์แวร์ 19

3.2 การเขียนโปรแกรมแบบโมดูลาร์ 22

3.3. แนวทางเชิงวัตถุในการพัฒนาซอฟต์แวร์ 31

3.3. วิธีการเขียนโปรแกรมด้วยภาพ 33

4. การทดสอบซอฟต์แวร์ 34

4.1. บทบัญญัติทั่วไป 34

4.2. เป้าหมายและวัตถุประสงค์. คำจำกัดความพื้นฐาน 34

4.3. การจัดกระบวนการทดสอบซอฟต์แวร์ 35

4.4. กลยุทธ์การทดสอบซอฟต์แวร์ 36

4.5. ระดับการทดสอบซอฟต์แวร์ 38

5. เอกสารประกอบของซอฟต์แวร์ 39

5.1. บทบัญญัติทั่วไป 39

5.2. โปรแกรมทดสอบและวิธีการ 39

5.3. คำอธิบายของโปรแกรม..40

5.4. หมายเหตุอธิบาย 41

5.5. ข้อความโปรแกรม..42

5.6. คำอธิบายของแอปพลิเคชัน 42

5.7. คู่มือโปรแกรมเมอร์ระบบ 42

5.8. คู่มือโปรแกรมเมอร์ 43

5.9. คู่มือการใช้งาน 43

วรรณกรรม. 44

การแนะนำ

ซอฟต์แวร์ (ซอฟต์แวร์) ของระบบคอมพิวเตอร์ (CS) มีความสำคัญ ซับซ้อน และอันตรายมากขึ้นเรื่อยๆ และยากต่อการพัฒนามากขึ้นเรื่อยๆ แต่ในขณะเดียวกัน ซอฟต์แวร์ก็ถูกทำให้เรียบง่ายขึ้นเรื่อยๆ ลดขนาด จัดการได้ง่ายขึ้น และง่ายขึ้น พัฒนา.

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

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

วัตถุประสงค์ของระเบียบวินัย "วิธีการพัฒนาซอฟต์แวร์" คือเพื่อสอนนักเรียนเกี่ยวกับหลักการพื้นฐานของการออกแบบซอฟต์แวร์ เพื่อทำความคุ้นเคยกับแนวคิด วิธีการพัฒนา การทดสอบ และการบันทึกซอฟต์แวร์

ซอฟต์แวร์ในฐานะผลิตภัณฑ์อุตสาหกรรม

แนวคิดพื้นฐาน

เป็นเรื่องปกติที่จะแยกแยะการสนับสนุนระบบคอมพิวเตอร์เจ็ดประเภท:

· คณิตศาสตร์;

· ภาษา;

· ข้อมูล;

· ซอฟต์แวร์;

· เทคนิค;

· มีระเบียบวิธี;

· องค์กร

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

ภายใต้ โปรแกรมเราจะเข้าใจ:

1) ชุดรหัสและข้อมูลที่เหมาะสมสำหรับการประมวลผลโดยโปรเซสเซอร์ (โปรแกรมปฏิบัติการ)

2) องค์ประกอบอิสระที่มีขนาดค่อนข้างเล็กซึ่งออกแบบมาเพื่อแก้ไขปัญหาในพื้นที่ (โปรแกรมเป็นส่วนประกอบของระบบ)

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

แพ็คเกจซอฟต์แวร์ที่ผ่านการทดสอบพร้อมขาย (จัดส่ง) อย่างสมบูรณ์และติดตั้งเอกสารที่จำเป็นทั้งหมดเรียกว่า ผลิตภัณฑ์ซอฟต์แวร์ (ผลิตภัณฑ์) หรือซอฟต์แวร์

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

เราจะแบ่งผลิตภัณฑ์ซอฟต์แวร์ตามเงื่อนไขออกเป็นขนาดเล็ก กลาง และใหญ่ ปริมาณข้อความต้นฉบับของโปรแกรมขนาดเล็กคือตัวดำเนินการภาษาระดับสูงหลายร้อยตัว ขนาดกลางถึงหลายหมื่นตัว และขนาดใหญ่ถึงหนึ่งล้านตัว

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

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

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

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

ลักษณะคุณภาพของซอฟต์แวร์

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

ฟังก์ชั่น;

ความน่าเชื่อถือ;

สะดวกในการใช้;

ประสิทธิภาพ;

คลอ;

ความคล่องตัว

ฟังก์ชันการทำงานคือความสามารถของซอฟต์แวร์ในการดำเนินชุดฟังก์ชันที่ตอบสนองความต้องการของผู้ใช้ที่ระบุหรือโดยนัย ชุดของฟังก์ชันที่ระบุถูกกำหนดไว้ในคำอธิบายภายนอกของซอฟต์แวร์

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

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

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

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

การบำรุงรักษาเป็นคุณลักษณะของซอฟต์แวร์ที่ลดความพยายามที่จำเป็นในการเปลี่ยนแปลงเพื่อขจัดข้อผิดพลาดและแก้ไขตามความต้องการที่เปลี่ยนแปลงไปของผู้ใช้

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

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

ลักษณะการทำงาน: สมบูรณ์.

ความน่าเชื่อถือ: ความสมบูรณ์ ความแม่นยำ ความเป็นอิสระ ความเสถียร ความปลอดภัย

ใช้งานง่าย: เอกสาร P, เนื้อหาข้อมูล (เฉพาะที่เกี่ยวข้องกับเอกสารประกอบการสมัคร), ทักษะการสื่อสาร, ความเสถียร, ความปลอดภัย

ประสิทธิภาพ: ประสิทธิภาพด้านเวลา, ประสิทธิภาพทรัพยากร (หน่วยความจำ), ประสิทธิภาพของอุปกรณ์

การบำรุงรักษา มีคุณภาพดั้งเดิมที่แตกต่างกันมากมายที่เกี่ยวข้องกับเกณฑ์นี้ อย่างไรก็ตาม สามารถแบ่งออกเป็นสองกลุ่ม โดยเน้นสองเกณฑ์ย่อยด้านคุณภาพ: ความสามารถในการศึกษาและความสามารถในการปรับเปลี่ยน

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

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

ความสามารถในการเรียนรู้: เอกสาร C, ข้อมูล (ในที่นี้เกี่ยวข้องกับเอกสารสนับสนุน), ความเข้าใจ, โครงสร้าง, ความสามารถในการอ่าน

ความสามารถในการปรับเปลี่ยน: ความสามารถในการขยาย, ความสามารถในการปรับเปลี่ยน (ในความหมายแคบ, ในฐานะคุณภาพดั้งเดิม), โครงสร้าง, ความเป็นโมดูล

ความคล่องตัว: ความเป็นอิสระของอุปกรณ์, ความเป็นอิสระ, โครงสร้าง, ความเป็นโมดูล

ด้านล่างนี้คือคำจำกัดความของคุณภาพดั้งเดิมของซอฟต์แวร์ที่ใช้

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

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

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

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

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

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

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

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

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

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

ประสิทธิภาพของอุปกรณ์คือการวัดลักษณะประสิทธิภาพของการใช้อุปกรณ์เครื่องจักรเพื่อแก้ไขปัญหาที่กำหนด

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

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

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

ความสามารถในการอ่านเป็นคุณสมบัติที่แสดงถึงความง่ายในการรับรู้ข้อความของโปรแกรมซอฟต์แวร์ (การเยื้อง การแยกส่วน การจัดรูปแบบ)

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

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

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

ความเป็นอิสระของอุปกรณ์เป็นคุณสมบัติที่แสดงถึงความสามารถของซอฟต์แวร์ในการทำงานกับฮาร์ดแวร์ที่หลากหลาย (ประเภทต่างๆ ยี่ห้อ รุ่นของคอมพิวเตอร์)

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

วิธีการ สาขาวิชาที่เกี่ยวข้อง

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

คุณภาพของซอร์สโค้ด

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

• ความสามารถในการอ่านโค้ด
• ความง่ายในการสนับสนุน การทดสอบ การดีบัก การแก้ไขข้อบกพร่อง การปรับเปลี่ยน และความสามารถในการพกพา
• ความซับซ้อนของโค้ดต่ำ
• การใช้ทรัพยากรต่ำ: หน่วยความจำและเวลา CPU
• การจัดการข้อยกเว้นที่ถูกต้อง
• คำเตือนเล็กน้อยระหว่างการคอมไพล์และลิงก์

วิธีการปรับปรุงคุณภาพโค้ด: การรีแฟคเตอร์

ปัจจัยด้านคุณภาพ

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

ปัจจัยด้านคุณภาพบางประการได้แก่:

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

จากมุมมองของผู้ใช้

นอกจากมุมมองด้านเทคนิคเกี่ยวกับคุณภาพซอฟต์แวร์แล้ว ยังมีการประเมินคุณภาพจากมุมมองของผู้ใช้อีกด้วย บางครั้งคำว่า "การใช้งาน" ใช้สำหรับแง่มุมของคุณภาพนี้ เป็นการยากที่จะได้รับคะแนนการใช้งานสำหรับผลิตภัณฑ์ซอฟต์แวร์ที่กำหนด ประเด็นที่สำคัญที่สุดที่ส่งผลต่อการประเมิน:

• ส่วนติดต่อผู้ใช้ใช้งานง่ายหรือไม่?
• การดำเนินการง่ายๆ และบ่อยครั้งทำได้ง่ายเพียงใด?
• การดำเนินการที่ซับซ้อนทำได้ง่ายเพียงใด?
• โปรแกรมสร้างข้อความแสดงข้อผิดพลาดที่ชัดเจนหรือไม่?
• โปรแกรมทำงานตามที่คาดไว้เสมอหรือไม่?
• มีเอกสารประกอบและครบถ้วนแค่ไหน?
• ส่วนติดต่อผู้ใช้เป็นแบบอธิบาย/จัดทำเอกสารด้วยตนเองหรือไม่
• ความล่าช้าในการตอบสนองของโปรแกรมสามารถยอมรับได้เสมอหรือไม่?

ดูสิ่งนี้ด้วย

ลิงค์

มีชื่อเสียง ตัวเลข
กระบวนการ
แนวคิด
ทิศทาง
โมเดล การพัฒนา
รุ่นอื่นๆ
อื่น

มูลนิธิวิกิมีเดีย 2010.

• เอ็นไลท์
• เที่ยงคืนในสุสาน (ภาพยนตร์)

ดูว่า "คุณภาพซอฟต์แวร์" ในพจนานุกรมอื่น ๆ คืออะไร:

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

การพัฒนาซอฟต์แวร์- ขณะที่ Grace Hopper ทำงานเกี่ยวกับคอมพิวเตอร์ Harvard Mark II ที่ Harvard University เพื่อนร่วมงานของเธอค้นพบว่าผีเสื้อกลางคืนตัวนี้ติดอยู่ในรีเลย์ และรบกวนการทำงานของอุปกรณ์ หลังจากนั้นเธอสังเกตเห็นว่าพวกเขากำลัง "แก้ไขจุดบกพร่อง" ระบบ.... . .. วิกิพีเดีย

การทดสอบซอฟต์แวร์- การพัฒนาซอฟต์แวร์ กระบวนการพัฒนาซอฟต์แวร์ ขั้นตอนกระบวนการ การวิเคราะห์ การออกแบบ เอกสารการเขียนโปรแกรม ... Wikipedia

ผู้ผลิตซอฟต์แวร์- การพัฒนาซอฟต์แวร์ (อังกฤษ วิศวกรรมซอฟต์แวร์ การพัฒนาซอฟต์แวร์) เป็นกิจกรรมประเภทหนึ่ง (วิชาชีพ) และกระบวนการที่มุ่งสร้างและรักษาฟังก์ชันการทำงาน คุณภาพ และความน่าเชื่อถือของซอฟต์แวร์โดยใช้ ... Wikipedia

วิกฤตซอฟต์แวร์- "วิกฤตซอฟต์แวร์" เป็นคำที่ใช้ในวิทยาการคอมพิวเตอร์เพื่ออธิบายผลที่ตามมาจากการเติบโตอย่างรวดเร็วในพลังการประมวลผลของคอมพิวเตอร์และความซับซ้อนของปัญหาที่สามารถแก้ไขได้ด้วยความช่วยเหลือ โดยพื้นฐานแล้วนี่คือ... ... Wikipedia

วิศวกรรมซอฟต์แวร์- แอร์บัส เอ 380 ใหม่ ใช้ซอฟต์แวร์ค่อนข้างมากในการสร้างห้องนักบินที่ทันสมัยบนเครื่องบิน วิธีการทางวิศวกรรมซอฟต์แวร์ทำให้สามารถสร้างซอฟต์แวร์อากาศยานที่อธิบายเป็นล้านบรรทัดได้... Wikipedia

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

ความเป็นมิตรต่อผู้ใช้ของซอฟต์แวร์- คุณลักษณะของผลิตภัณฑ์ซอฟต์แวร์ที่: ช่วยลดความพยายามของผู้ใช้ในการเตรียมข้อมูลเบื้องต้น ใช้ผลิตภัณฑ์ซอฟต์แวร์และประเมินผลลัพธ์ที่ได้รับ และยังช่วยให้พวกเขากระตุ้นอารมณ์เชิงบวก... ... พจนานุกรมการเงิน

การบำรุงรักษาซอฟต์แวร์- ลักษณะของผลิตภัณฑ์ซอฟต์แวร์ที่ช่วยลดความพยายามในการเปลี่ยนแปลง: เพื่อกำจัดข้อผิดพลาด หรือเพื่อการปรับเปลี่ยนให้ตรงตามความต้องการของผู้ใช้ที่เปลี่ยนแปลงไป ดูเพิ่มเติม: คุณภาพซอฟต์แวร์... ... พจนานุกรมการเงิน

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

หนังสือ

• Code Perfect: คู่มือปฏิบัติเพื่อการพัฒนาซอฟต์แวร์ โดย S. McConnell เป็นเวลากว่า 10 ปีแล้วที่หนังสือเล่มนี้ฉบับพิมพ์ครั้งแรกถือเป็นคู่มือการเขียนโปรแกรมเชิงปฏิบัติที่ดีที่สุดเล่มหนึ่ง ขณะนี้หนังสือเล่มนี้ได้รับการอัปเดตอย่างสมบูรณ์โดยคำนึงถึงแนวโน้มและเทคโนโลยีสมัยใหม่...

ปัญหาหลักในการจัดการคุณภาพคือความจริงที่ว่าคำจำกัดความของคุณภาพนั้นคลุมเครือและคลุมเครือเกินไป เนื่องจากคำว่าคุณภาพมักจะถูกเข้าใจผิด ความสับสนนี้อาจเกิดจากสาเหตุหลายประการ...

ลองตอบคำถาม:

• มุมมองคุณภาพยอดนิยม
• ข้อสรุป

คุณภาพของซอฟต์แวร์คืออะไร?

ในตอนแรก เราจะพยายามกำหนดเงื่อนไขคุณภาพและคุณภาพของซอฟต์แวร์

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

อันดับแรกคุณภาพไม่ใช่แนวคิดหรือแนวคิดเดียว แต่เป็นแนวคิดที่มีหลายมิติและหลากหลาย

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

ที่สามคำว่าคุณภาพเป็นส่วนสำคัญของการสื่อสารในชีวิตประจำวันของเรา แต่การใช้งานทั่วไปและการใช้งานระดับมืออาชีพอาจแตกต่างกันมาก

มุมมองคุณภาพยอดนิยม

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

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

แนวทางอย่างมืออาชีพเพื่อคุณภาพ

น่าเสียดายที่มุมมองที่คลุมเครือและคลุมเครือดังกล่าวไม่สามารถใช้เพื่อปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ได้ ดังนั้นจึงจำเป็นต้องให้คำจำกัดความที่ชัดเจนและใช้งานได้ ในปี พ.ศ. 2522 Crosby กำหนดให้คุณภาพเป็น "ความสอดคล้องกับข้อกำหนด" และ Juran และ Gryna ในปี พ.ศ. 2513 ให้คำจำกัดความคุณภาพว่าเป็น "ความเหมาะสมในการใช้งาน" คำจำกัดความทั้งสองนี้มีความสัมพันธ์กันอย่างใกล้ชิดและลงตัวพอดี ดังที่เราจะได้เห็นในภายหลัง

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

คำนิยาม “ฟิตเนสเพื่อการใช้งาน”คำนึงถึงข้อกำหนดและความคาดหวังของผู้ใช้ผลิตภัณฑ์ซึ่งคาดหวังว่าผลิตภัณฑ์หรือบริการที่จัดให้จะสะดวกต่อความต้องการของตน อย่างไรก็ตาม ผู้ใช้ที่แตกต่างกันอาจใช้ผลิตภัณฑ์ในลักษณะที่แตกต่างกัน ซึ่งหมายความว่าผลิตภัณฑ์ควรมีกรณีการใช้งานที่แตกต่างกันมากที่สุดเท่าที่จะเป็นไปได้ ตามคำจำกัดความของ Juran แต่ละกรณีการใช้งานเป็นคุณลักษณะด้านคุณภาพ และทั้งหมดสามารถจัดเป็นหมวดหมู่เป็นพารามิเตอร์การใช้งานได้

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

มีเพียงลูกค้าของคุณเท่านั้นที่สามารถบอกคุณเกี่ยวกับคุณภาพได้ เพราะนี่คือสิ่งเดียวที่เขาซื้อจริงๆ ลูกค้าไม่ได้ซื้อสินค้า เขาซื้อการรับประกันของคุณว่าจะเป็นไปตามความคาดหวังทั้งหมดของเขาสำหรับผลิตภัณฑ์

Guaspari “ฉันรู้เมื่อฉันเห็นมัน”

ข้อสรุป

ลองอีกครั้งเพื่อกำหนดคุณภาพจากมุมมองของลูกค้าหรือผู้ใช้ผลิตภัณฑ์

คุณภาพคือความเหมาะสมในการใช้งานผลิตภัณฑ์นี้ทำสิ่งที่ฉันต้องการหรือไม่ ทำให้งานของฉันง่ายขึ้น ฉันสามารถใช้มันในลักษณะที่เหมาะกับฉันได้หรือไม่

ตอนนี้เรามาดูมุมมองของนักพัฒนากัน

คุณภาพเป็นไปตามข้อกำหนดที่ระบุและรวบรวมผลิตภัณฑ์ทำทุกอย่างตามที่กล่าวไว้หรือไม่

ปัญหาคือข้อกำหนดที่ระบุและรวบรวมมักเป็นเพียงส่วนหนึ่งของข้อกำหนดและความคาดหวังที่แท้จริงของลูกค้าเท่านั้น คำจำกัดความของคุณภาพที่ถูกต้องอยู่ที่ไหน?

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

ลูกค้าจะพึงพอใจก็ต่อเมื่อผลิตภัณฑ์ที่ซื้อตรงตามความต้องการที่แท้จริงและสำคัญของลูกค้าอย่างเต็มที่ ไม่ว่าจะระบุไว้หรือไม่ก็ตาม

คุณภาพของซอฟต์แวร์เป็นข้อกังวลอย่างต่อเนื่องเกี่ยวกับวิศวกรรมซอฟต์แวร์และมีการอภิปรายในความรู้หลายสาขา

• ฟิล ครอสบี:คุณภาพเป็นไปตามข้อกำหนดของผู้ใช้
• วัตต์ ฮัมฟรีย์:คุณภาพคือความสำเร็จของระดับการใช้งานที่ยอดเยี่ยม
• บริษัทไอบีเอ็ม:บัญญัติคำว่า "คุณภาพที่ขับเคลื่อนด้วยตลาด"
• เกณฑ์ Baldrige:“คุณภาพที่ขับเคลื่อนโดยลูกค้า”
• ระบบการจัดการคุณภาพ ISO 9001:คุณภาพคือระดับที่คุณลักษณะโดยธรรมชาติตรงตามข้อกำหนด

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

คุณภาพในกิจกรรมโครงการ:

• การจัดการข้อกำหนด (“คุณลักษณะด้านคุณภาพ” เป็นหมวดหมู่ของข้อกำหนดที่ไม่เป็นไปตามหน้าที่)
• การทดสอบ (เรียกว่า MTBF ตัวชี้วัด เช่น MTTF - Mean Time To Failure ซึ่งก็คือเวลาเฉลี่ยระหว่างความล้มเหลวของระบบที่ตรวจพบ ฯลฯ)

“คุณภาพที่ยอมรับได้”สามารถเปรียบเทียบกับระดับการบริการภายใน SLA - ข้อตกลงระดับการให้บริการที่กำหนด นั่นก็คือคุณภาพที่ยอมรับได้ถือได้ว่าเป็น<количественно выраженный>การประนีประนอมระหว่างลูกค้าและผู้รับเหมาเกี่ยวกับลักษณะของผลิตภัณฑ์ที่สร้างขึ้นโดยผู้รับเหมาเพื่อประโยชน์ของ<решения задач>ลูกค้า โดยคำนึงถึงข้อจำกัดอื่นๆ ของโครงการ (โดยเฉพาะต้นทุน ซึ่งมักเรียกว่า “ต้นทุนด้านคุณภาพ”)

รูปภาพ "ขอบเขตความรู้ - คุณภาพซอฟต์แวร์"

แผนภาพ “รูปแบบระบบบริหารคุณภาพ”

ความรู้พื้นฐานด้านคุณภาพซอฟต์แวร์

บรรลุข้อตกลงเกี่ยวกับข้อกำหนดด้านคุณภาพ พร้อมด้วยการสื่อสารที่ชัดเจนถึงวิศวกรถึงสิ่งที่ถือเป็นคุณภาพ<получаемого продукта>จำเป็นต้องมีการอภิปรายและคำจำกัดความอย่างเป็นทางการของคุณภาพหลายๆ ด้าน

วิศวกรต้องเข้าใจแนวคิดเรื่องคุณภาพ คุณลักษณะ และความหมายของคุณภาพที่เกี่ยวข้องกับซอฟต์แวร์ที่กำลังพัฒนาหรือบำรุงรักษา

แนวคิดที่สำคัญคือข้อกำหนดของซอฟต์แวร์จะกำหนดคุณลักษณะคุณภาพของซอฟต์แวร์ที่ต้องการ และยังมีอิทธิพลต่อวิธีการวัดปริมาณที่จัดทำขึ้นเพื่อประเมินคุณลักษณะเหล่านี้<соответствующие>เกณฑ์การยอมรับ.

วัฒนธรรมและจริยธรรมวิศวกรรมซอฟต์แวร์

วิศวกรซอฟต์แวร์ได้รับการคาดหวังให้ยอมรับปัญหาคุณภาพของซอฟต์แวร์โดยเป็นส่วนหนึ่งของปัญหาดังกล่าว<профессиональной>วัฒนธรรม.
ข้อพิจารณาด้านจริยธรรมสามารถมีบทบาทสำคัญในคุณภาพซอฟต์แวร์ วัฒนธรรม และทัศนคติของวิศวกร<к своей работе>- IEEE Computer Society และ ACM ได้พัฒนาจรรยาบรรณและแนวปฏิบัติทางวิชาชีพโดยยึดหลักการ 8 ประการเพื่อช่วยให้วิศวกรเสริมสร้างความมุ่งมั่นต่อคุณภาพและความเป็นอิสระ<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>ในการทำงานประจำวันของพวกเขา

มูลค่าและต้นทุนของคุณภาพ

จริงๆ แล้ว แนวคิดเรื่อง "คุณภาพ" ไม่ได้ชัดเจนและเรียบง่ายอย่างที่คิดเมื่อมองแวบแรก สำหรับผลิตภัณฑ์ทางวิศวกรรมนั้นมีมากมาย<интерпретаций>คุณภาพขึ้นอยู่กับ “ระบบพิกัด” เฉพาะเจาะจง มุมมองเหล่านี้หลายประการจำเป็นต้องมีการหารือและกำหนดในขั้นตอนการพัฒนาข้อกำหนดสำหรับผลิตภัณฑ์ซอฟต์แวร์ คุณลักษณะด้านคุณภาพอาจจำเป็นต้องมีในระดับที่แตกต่างกัน อาจขาดหายไป หรืออาจกำหนดข้อกำหนดบางประการ ซึ่งทั้งหมดนี้อาจเป็นผลมาจากการประนีประนอมบางประเภท

ต้นทุนด้านคุณภาพสามารถแบ่งออกเป็น:

• ค่าใช้จ่ายในการเตือน<дефектов>(ค่าป้องกัน)
• ค่าประเมิน,
• ต้นทุนความล้มเหลวภายใน
• ต้นทุนความล้มเหลวภายนอก

แรงผลักดันเบื้องหลังโครงการซอฟต์แวร์คือความปรารถนาที่จะสร้างซอฟต์แวร์ที่มีคุณค่าที่แน่นอน มูลค่าของซอฟต์แวร์อาจหรืออาจไม่แสดงอยู่ในรูปของต้นทุนก็ได้ ลูกค้ามักจะมีแนวคิดของตัวเองเกี่ยวกับการลงทุนด้วยต้นทุนสูงสุดซึ่งคาดว่าจะได้รับผลตอบแทนหากบรรลุเป้าหมายหลักในการสร้างซอฟต์แวร์ ลูกค้าอาจมีความคาดหวังบางประการเกี่ยวกับคุณภาพของซอฟต์แวร์ บางครั้งลูกค้าไม่ได้คำนึงถึงปัญหาด้านคุณภาพและต้นทุนที่เกี่ยวข้อง คุณลักษณะที่มีคุณภาพมีการตกแต่งเพียงอย่างเดียวหรือเป็นส่วนสำคัญของซอฟต์แวร์หรือไม่ คำตอบอาจอยู่ตรงกลาง เช่นเดียวกับในกรณีเหล่านี้เกือบทุกครั้ง และเป็นเรื่องของการอภิปรายถึงระดับที่ลูกค้ามีส่วนร่วมในกระบวนการตัดสินใจ และความเข้าใจทั้งหมดของลูกค้าเกี่ยวกับต้นทุนและผลประโยชน์ เกี่ยวข้องกับการบรรลุถึงระดับคุณภาพโดยเฉพาะ ตามหลักการแล้ว การตัดสินใจส่วนใหญ่เหล่านี้ควรทำในระหว่างกระบวนการตามข้อกำหนด แต่ปัญหาเหล่านี้อาจเกิดขึ้นตลอดวงจรชีวิตของซอฟต์แวร์ ไม่มีเลย<“стандартных”>กฎเกณฑ์ว่าควรตัดสินใจอย่างไร อย่างไรก็ตาม วิศวกรจะต้องสามารถจินตนาการถึงทางเลือกต่างๆ และต้นทุนได้

แบบจำลองและลักษณะคุณภาพ

ISO/IEC กำหนดโมเดลคุณภาพซอฟต์แวร์ที่เกี่ยวข้องสามโมเดล (ISO 9126-01 วิศวกรรมซอฟต์แวร์ - คุณภาพผลิตภัณฑ์ ส่วนที่ 1: โมเดลคุณภาพ):

• คุณภาพภายใน
• คุณภาพภายนอกและ
• คุณภาพระหว่างการดำเนินงานตลอดจนชุดงานที่เกี่ยวข้องเพื่อประเมินคุณภาพของซอฟต์แวร์ (การประเมินผลิตภัณฑ์ซอฟต์แวร์ ISO14598-98)

คุณภาพกระบวนการทางวิศวกรรมซอฟต์แวร์

การจัดการคุณภาพ (การจัดการคุณภาพซอฟต์แวร์) และคุณภาพกระบวนการวิศวกรรมซอฟต์แวร์ (คุณภาพกระบวนการวิศวกรรมซอฟต์แวร์)เกี่ยวข้องโดยตรงกับคุณภาพของผลิตภัณฑ์ซอฟต์แวร์ที่สร้างขึ้น

มีสองมาตรฐานที่สำคัญในด้านคุณภาพซอฟต์แวร์

• ติ๊กไอที- เกี่ยวข้องกับการพิจารณาระบบการจัดการคุณภาพโดยรวม ISO 9001-00 ที่นำไปใช้กับโครงการซอฟต์แวร์
• มาตรฐานที่สำคัญอีกประการหนึ่งคือ CMMIที่กล่าวถึงในพื้นที่ความรู้กระบวนการวิศวกรรมซอฟต์แวร์ ให้คำแนะนำสำหรับการปรับปรุงกระบวนการ พื้นที่กระบวนการ CMMI (ขอบเขตความสามารถ) เกี่ยวข้องโดยตรงกับการจัดการคุณภาพ:
  • การประกันคุณภาพกระบวนการและผลิตภัณฑ์ (หมวดกระบวนการ "สนับสนุน" ของ CMMI)
  • การตรวจสอบ (หมวด "วิศวกรรม") และ
  • การรับรอง (การตรวจสอบความถูกต้องหมวด "วิศวกรรม")

ในเวลาเดียวกัน CMMI จะจัดประเภท ทบทวนและ การตรวจสอบเป็นวิธีการตรวจสอบ แต่ไม่ใช่เป็นกระบวนการอิสระ

มาตรฐานเหล่านี้ยังถือว่าเป็นมาตรฐานเสริม และการรับรองมาตรฐาน ISO 9001 ช่วยในการบรรลุวุฒิภาวะ CMMI ระดับสูง

คุณภาพผลิตภัณฑ์ซอฟต์แวร์

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

มาตรฐาน ISO 9126-01 (วิศวกรรมซอฟต์แวร์ - คุณภาพผลิตภัณฑ์ ส่วนที่ 1: แบบจำลองคุณภาพ)กำหนดคุณลักษณะที่เกี่ยวข้องและ "คุณลักษณะย่อย" ของคุณภาพ สำหรับสองในสามแบบจำลองที่อธิบายไว้ในนั้น ตลอดจนตัวชี้วัดที่มีประโยชน์สำหรับการประเมินคุณภาพของผลิตภัณฑ์ซอฟต์แวร์

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

• ข้อกำหนดความต้องการของระบบที่สมบูรณ์
• ข้อกำหนดข้อกำหนดซอฟต์แวร์สำหรับส่วนประกอบซอฟต์แวร์ของระบบ (ข้อกำหนดข้อกำหนดซอฟต์แวร์, SRS)
• โมเดล,
• เอกสารการทดสอบ
• รายงานที่สร้างขึ้นอันเป็นผลมาจากงานวิเคราะห์คุณภาพ

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

การปรับปรุงคุณภาพ

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

1. กระบวนการวงจรชีวิต
2. กระบวนการตรวจจับ กำจัด และป้องกันความล้มเหลว/ข้อบกพร่อง และ
3. กระบวนการปรับปรุงคุณภาพ

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

แนวทางเช่น ทีคิวเอ็ม(การจัดการคุณภาพโดยรวม - การจัดการคุณภาพโดยรวม) และ พีดีซีเอ(วางแผน ทำ ตรวจสอบ ดำเนินการ – การวางแผน การดำเนินการ ตรวจสอบ ปฏิกิริยา/การปรับเปลี่ยน) เป็นเครื่องมือในการบรรลุวัตถุประสงค์ที่เกี่ยวข้องกับคุณภาพ การสนับสนุนด้านการจัดการช่วยในการดำเนินกระบวนการ ประเมินผลิตภัณฑ์ และการได้รับข้อมูลที่จำเป็นทั้งหมด นอกจากนี้ โปรแกรมการปรับปรุงที่พัฒนาแล้ว (โปรแกรมการปรับปรุง มักจะกำหนดเป้าหมายและครอบคลุมงานของแผนกหรือองค์กรโดยรวม) ระบุรายละเอียดการดำเนินการและโครงการปรับปรุงทั้งหมด<отдельных аспектов деятельности>ภายในระยะเวลาที่กำหนดในระหว่างที่โครงการดังกล่าวสามารถดำเนินไปพร้อมกับการแก้ไขปัญหาที่เกี่ยวข้องได้สำเร็จ ในขณะเดียวกัน การสนับสนุนด้านการจัดการหมายความว่าโครงการปรับปรุงทั้งหมดมีทรัพยากรเพียงพอที่จะบรรลุเป้าหมาย การสนับสนุนด้านการจัดการมีความสัมพันธ์อย่างใกล้ชิดกับการดำเนินการโต้ตอบเชิงรุกในทีม และควรป้องกันไม่ให้เกิดปัญหาที่อาจเกิดขึ้น (และการต่อต้านเชิงรับหรือเชิงรุกต่อการดำเนินการตามโครงการปรับปรุงหรือแต่ละโครงการ) การจัดตั้งกลุ่มงาน การสนับสนุนผู้จัดการระดับกลาง และทรัพยากรเฉพาะในระดับโครงการจะมีการหารือกันในพื้นที่ความรู้ "กระบวนการทางวิศวกรรมซอฟต์แวร์"

กระบวนการคุณภาพซอฟต์แวร์

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

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

การวางแผนคุณภาพซอฟต์แวร์ประกอบด้วย:

1. คำจำกัดความของผลิตภัณฑ์ที่ต้องการในแง่ของลักษณะคุณภาพ
2. กระบวนการวางแผนเพื่อให้ได้ผลิตภัณฑ์ที่ต้องการ

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

สามารถใช้ SQM เพื่อประเมินทั้งผลิตภัณฑ์ขั้นสุดท้ายและผลิตภัณฑ์ขั้นกลางได้ กระบวนการ SQM เฉพาะทางบางอย่างถูกกำหนดไว้ในมาตรฐาน 12207:

• กระบวนการประกันคุณภาพ
• กระบวนการตรวจสอบ
• กระบวนการตรวจสอบความถูกต้อง
• กระบวนการทบทวนร่วม
• กระบวนการตรวจสอบ

กระบวนการทั้งหมดนี้สนับสนุนการแสวงหาคุณภาพและยังช่วยในการระบุข้อผิดพลาดที่อาจเกิดขึ้นอีกด้วย อย่างไรก็ตาม พวกเขาต่างกันในสิ่งที่พวกเขามุ่งเน้น

กระบวนการ SQM ประกอบด้วยงานและเทคนิคต่างๆออกแบบมาเพื่อประเมินว่าแผนซอฟต์แวร์บรรลุผลอย่างไร และผลิตภัณฑ์ระดับกลางและขั้นสุดท้ายตรงตามข้อกำหนดที่ระบุได้ดีเพียงใด ผลลัพธ์ของงานเหล่านี้จะถูกรายงานต่อผู้จัดการก่อนที่จะดำเนินการแก้ไขที่เหมาะสม กระบวนการ SQM ได้รับการจัดการด้วยความมั่นใจว่าข้อมูลการรายงานมีความถูกต้อง
ตามที่อธิบายไว้ในพื้นที่ความรู้นี้ กระบวนการ SQM มีความสัมพันธ์กันอย่างใกล้ชิด พวกมันสามารถทับซ้อนกันและบางครั้งก็รวมกันได้ ดูเหมือนว่าพวกมันจะมีปฏิกิริยาโดยธรรมชาติ เนื่องจากพวกเขามองกระบวนการในบริบทของการปฏิบัติที่เรียนรู้และผลิตภัณฑ์ที่ผลิตไปแล้ว อย่างไรก็ตาม มีบทบาทสำคัญในขั้นตอนการวางแผน โดยเป็นกระบวนการและขั้นตอนที่จำเป็นเพื่อให้บรรลุคุณลักษณะและระดับคุณภาพที่ผู้มีส่วนได้ส่วนเสียต้องการ<проекта>ซอฟต์แวร์.

การจัดการความเสี่ยงยังมีบทบาทสำคัญในการส่งมอบซอฟต์แวร์ที่มีคุณภาพอีกด้วย การรวมการวิเคราะห์ความเสี่ยง “ปกติ” (เป็นการถาวร ไม่ใช่เป็นระยะ ในแบบดั้งเดิม – มีระเบียบวินัย) และ<соответствующих>ช่างเทคนิคควบคุม<рисками>เข้าสู่กระบวนการวงจรชีวิตของซอฟต์แวร์สามารถเพิ่มศักยภาพในการผลิตผลิตภัณฑ์ที่มีคุณภาพ ข้อมูลรายละเอียดเพิ่มเติมเกี่ยวกับการบริหารความเสี่ยงสามารถพบได้ในพื้นที่ความรู้ “การจัดการวิศวกรรมซอฟต์แวร์”

การประกันคุณภาพซอฟต์แวร์ (SQA)

กระบวนการ SQAแสดงหลักฐานว่าผลิตภัณฑ์ซอฟต์แวร์และกระบวนการวงจรชีวิตของโครงการเป็นไปตามข้อกำหนดที่ระบุ การยืนยันดังกล่าวดำเนินการบนพื้นฐานของการวางแผน การตั้งค่า<работ>การออกกฎหมายและการดำเนินการชุดการดำเนินการเพื่อให้แน่ใจว่าคุณภาพจะกลายเป็นส่วนสำคัญของซอฟต์แวร์
มุมมองนี้แสดงถึงการกำหนดปัญหาที่ชัดเจนและแม่นยำ เช่นเดียวกับที่มีการกำหนดข้อกำหนดสำหรับการแก้ปัญหาที่เกี่ยวข้องและแสดงออกอย่างชัดเจน สมบูรณ์ และตีความอย่างไม่คลุมเครือ<программному>การตัดสินใจ. SQA บรรลุการประกันคุณภาพในกระบวนการพัฒนาและบำรุงรักษาโดยการดำเนินกิจกรรมต่างๆ ในทุกขั้นตอน<жизненного цикла>ซึ่งช่วยให้คุณระบุปัญหาได้ตั้งแต่ระยะแรกซึ่งแทบจะหลีกเลี่ยงไม่ได้ในกิจกรรมที่ซับซ้อนใดๆ

การบริหารความเสี่ยงเป็นเครื่องมือเพิ่มเติมที่สำคัญในการรับรองคุณภาพของซอฟต์แวร์

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

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

เพื่อให้บรรลุเป้าหมายนี้ อันดับแรกจำเป็นจะต้องมีการกำหนดและทำความเข้าใจเป้าหมายคุณภาพอย่างชัดเจน (และยังสามารถตีความได้อย่างชัดเจน ซึ่งเป็นข้อกำหนดเบื้องต้นสำหรับเป้าหมายและข้อกำหนดที่เกี่ยวข้อง) สิ่งนี้จะต้องสะท้อนให้เห็นในแผนการจัดการที่เกี่ยวข้อง<проектом>การพัฒนาและการสนับสนุน

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

นอกจากนี้ แผน SQA ยังกล่าวถึงประเด็นที่เกี่ยวข้องกับกิจกรรมการประกันคุณภาพที่เกี่ยวข้องกับกิจกรรมประเภทอื่น ๆ ที่อธิบายไว้ในนั้น<различных>แผนสำหรับการสร้างซอฟต์แวร์ ซึ่งรวมถึงการจัดหา การติดตั้ง การบำรุงรักษาโซลูชันซอฟต์แวร์แบบกำหนดเองและ/หรือทำซ้ำได้/พร้อมใช้งาน (COTS ในเชิงพาณิชย์) ที่จำเป็นสำหรับโครงการซอฟต์แวร์ที่กำหนด แผน SQA อาจมีเกณฑ์การยอมรับซอฟต์แวร์และกิจกรรมการรายงานและการจัดการที่จำเป็นเพื่อให้มั่นใจในคุณภาพ<и контролю над>ทำงาน

การตรวจสอบและการตรวจสอบความถูกต้อง (V&V)

การตรวจสอบและรับรองซอฟต์แวร์เป็นแนวทางที่มีระเบียบวินัยในการประเมินผลิตภัณฑ์ซอฟต์แวร์ที่นำไปใช้ตลอดวงจรชีวิตทั้งหมด ความพยายามในการตรวจสอบและรับรองคุณสมบัติมีวัตถุประสงค์เพื่อให้มั่นใจในคุณภาพซึ่งเป็นคุณลักษณะสำคัญของซอฟต์แวร์และตอบสนองความต้องการของผู้ใช้
V&V จัดการปัญหาคุณภาพของซอฟต์แวร์โดยตรง และใช้เทคนิคการทดสอบที่เหมาะสมเพื่อตรวจจับข้อบกพร่องเฉพาะ อย่างไรก็ตาม สามารถใช้ V&V สำหรับผลิตภัณฑ์ขั้นกลางได้ ในขอบเขตที่ "ขั้นตอน" ระดับกลางสอดคล้องกัน<соответствующих>กระบวนการวงจรชีวิต

กระบวนการ V&V กำหนดขอบเขตของผลิตภัณฑ์ (ผลลัพธ์) ของงานการพัฒนาและบำรุงรักษาบางอย่างที่ตรงตามข้อกำหนดที่กำหนดไว้ภายในกรอบงานเหล่านี้ และผลิตภัณฑ์ขั้นสุดท้ายเป็นไปตามเป้าหมายที่ระบุและข้อกำหนดของผู้ใช้

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

ทั้งสองกระบวนการ – การตรวจสอบและการรับรอง– เริ่มต้นในระยะแรกของการพัฒนาและบำรุงรักษา พวกเขาจัดให้มีการตรวจสอบ (การตรวจสอบ) ความสามารถของผลิตภัณฑ์หลักทั้งในบริบทของการส่งมอบก่อนหน้าทันที (ผลิตภัณฑ์ระดับกลาง) และในแง่ของการปฏิบัติตามข้อกำหนดที่เกี่ยวข้อง วัตถุประสงค์ของการวางแผน V&V คือเพื่อให้กระบวนการตรวจสอบและรับรองมีทรัพยากรที่จำเป็น และกำหนดบทบาทและความรับผิดชอบอย่างชัดเจน เอกสารแผน V&V ที่เกิดขึ้นและ<детально>อธิบายทรัพยากร บทบาท และกิจกรรมต่างๆ ตลอดจนเทคนิคและเครื่องมือที่ใช้
แผนดังกล่าวยังกล่าวถึงด้านการจัดการ การสื่อสาร นโยบายและขั้นตอนของกิจกรรมการตรวจสอบและรับรองคุณสมบัติ และการโต้ตอบของพวกเขา นอกจากนี้ ยังอาจแก้ไขปัญหาที่เกี่ยวข้องกับการรายงานข้อบกพร่องและเอกสารข้อกำหนดอีกด้วย

การตรวจสอบและการตรวจสอบ

การประเมินและการตรวจสอบห้าประเภท:

• บทวิจารณ์ของฝ่ายบริหาร
• บทวิจารณ์ทางเทคนิค
• การตรวจสอบ
• "บทสรุปเกม"
• การตรวจสอบ

บทวิจารณ์ฝ่ายบริหาร

วัตถุประสงค์ของการประเมินฝ่ายบริหารคือเพื่อติดตามการพัฒนา<проекта/продукта>การกำหนดสถานะของแผนและกำหนดการ การอนุมัติข้อกำหนดและการจัดสรรทรัพยากร หรือการประเมินประสิทธิผลของแนวทางการจัดการที่ใช้ในการบรรลุเป้าหมายที่ระบุไว้

การประเมินของฝ่ายบริหารสนับสนุนการตัดสินใจในการเปลี่ยนแปลงและดำเนินการแก้ไขที่จำเป็นในระหว่างการดำเนินโครงการซอฟต์แวร์

การประเมินของฝ่ายบริหารจะกำหนดความเพียงพอของแผน กำหนดการ และข้อกำหนด พร้อมทั้งติดตามความคืบหน้าหรือการไม่ปฏิบัติตามข้อกำหนด การประเมินเหล่านี้สามารถดำเนินการกับผลิตภัณฑ์ โดยถูกบันทึกในรูปแบบของรายงานการตรวจสอบ รายงานสถานะ (การพัฒนา) รายงาน V&V รวมถึงแผนประเภทต่างๆ - การจัดการความเสี่ยงของโครงการ/การจัดการโครงการ การจัดการการกำหนดค่า การรักษาความปลอดภัย<использования>ซอฟต์แวร์ (ความปลอดภัย) การประเมินความเสี่ยง ฯลฯ

บทวิจารณ์ทางเทคนิค

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

การประเมินทางเทคนิคจำเป็นต้องมีข้อมูลอินพุตต่อไปนี้:

• คำแถลงเป้าหมาย
• ผลิตภัณฑ์ซอฟต์แวร์เฉพาะ (กำลังได้รับการประเมิน)
• แผนโครงการที่กำหนด (แผนการจัดการโครงการ)
• รายการปัญหา (คำถาม) ที่เกี่ยวข้องกับผลิตภัณฑ์
• ขั้นตอนการประเมินทางเทคนิค

ทีม<технической оценки> ปฏิบัติตามขั้นตอนการประเมินที่กำหนด บุคคลที่ผ่านการรับรอง (ทางเทคนิค) จะให้ภาพรวมของผลิตภัณฑ์ (เป็นตัวแทนของทีมพัฒนา) ศึกษา<продукта> ดำเนินการมากกว่าหนึ่งครั้งหรือมากกว่าการประชุม (ระหว่างผู้ที่นำเสนอผลิตภัณฑ์และผู้ที่ให้การประเมินผล) การประเมินทางเทคนิคจะเสร็จสมบูรณ์หลังจากกิจกรรมการตรวจสอบผลิตภัณฑ์ที่กำหนดทั้งหมดเสร็จสิ้นแล้ว

การตรวจสอบ

วัตถุประสงค์ของการตรวจสอบคือการตรวจจับและระบุความผิดปกติในผลิตภัณฑ์ซอฟต์แวร์ มีความแตกต่างที่สำคัญสองประการระหว่างการตรวจสอบและการประเมิน (ด้านการจัดการและด้านเทคนิค):

1. ผู้ดำรงตำแหน่งผู้บริหาร (ผู้จัดการ) ที่เกี่ยวข้องกับสมาชิกของทีมตรวจสอบไม่ควรเข้าร่วมในการตรวจสอบ
2. การตรวจสอบควรนำโดยผู้นำที่เป็นกลาง (ไม่ขึ้นอยู่กับโครงการและวัตถุประสงค์) ที่ได้รับการฝึกอบรมในเทคนิคการตรวจสอบ

การตรวจสอบซอฟต์แวร์เกี่ยวข้องกับผู้เขียนผลิตภัณฑ์ระดับกลางหรือขั้นสุดท้ายเสมอ ซึ่งแตกต่างจากการประเมินซึ่งไม่จำเป็นต้องทำเช่นนี้ การตรวจสอบ (เป็นหน่วยองค์กรชั่วคราว - กลุ่มหรือทีม) ประกอบด้วยผู้นำ นายทะเบียน ผู้ตรวจสอบ และผู้ตรวจสอบหลายคน (2 ถึง 5 คน) สมาชิกของทีมตรวจสอบอาจเชี่ยวชาญเฉพาะด้านที่แตกต่างกัน (มีความสามารถที่แตกต่างกัน) เช่น สาขาวิชา วิธีการออกแบบ ภาษา ฯลฯ ณ จุด (ระยะเวลา) ที่กำหนด การตรวจสอบจะดำเนินการโดยสัมพันธ์กับชิ้นส่วนเล็กๆ ที่แยกจากกันของผลิตภัณฑ์ (โดยส่วนใหญ่ จะเน้นไปที่ลักษณะการทำงานส่วนบุคคลหรือคุณลักษณะอื่นๆ มักจะเริ่มต้นจากกฎเกณฑ์ทางธุรกิจแต่ละข้อ ข้อกำหนดด้านการทำงาน หรือคุณลักษณะด้านคุณภาพ , บันทึกของผู้เขียน) สมาชิกในทีมแต่ละคนควรตรวจสอบผลิตภัณฑ์ซอฟต์แวร์และข้อมูลอื่นๆ ก่อนการประชุมการตรวจสอบ อาจใช้เทคนิคการวิเคราะห์ต่างๆ กับผลิตภัณฑ์ส่วนเล็กๆ หรือผลิตภัณฑ์โดยรวม ในกรณีหลังนี้พิจารณาเพียงด้านเดียวเท่านั้น เช่น อินเทอร์เฟซ ความผิดปกติใดๆ ที่พบควรได้รับการบันทึกไว้และข้อมูลที่สื่อสารไปยังผู้นำการตรวจสอบ ในระหว่างกระบวนการตรวจสอบ ผู้นำจะเป็นผู้นำเซสชั่น<инспекции>และตรวจสอบว่าทุกอย่าง<члены команды>เตรียมไว้สำหรับการตรวจสอบ

เครื่องมือทั่วไปที่ใช้ในการตรวจสอบคือรายการตรวจสอบที่มีความผิดปกติและคำถามที่เกี่ยวข้องกับแง่มุมต่างๆ<программного продукта>กระตุ้นความสนใจ เอกสารผลลัพธ์มักจะจัดหมวดหมู่ความผิดปกติและได้รับการประเมินโดยทีมงานเพื่อความครบถ้วนและถูกต้อง การตัดสินใจดำเนินการตรวจสอบให้เสร็จสิ้นตามเกณฑ์ข้อใดข้อหนึ่งจากสามข้อ:

1. การรับเป็นบุตรบุญธรรม<продукта>โดยไม่ต้องมีการประมวลผลหรือเพียงเล็กน้อย
2. การรับเป็นบุตรบุญธรรม<продукта>ด้วยการตรวจสอบชิ้นส่วนที่ประมวลผลแล้ว
3. จำเป็นต้องตรวจสอบอีกครั้ง

การประชุมการตรวจสอบมักจะใช้เวลาหลายชั่วโมง ซึ่งแตกต่างจากการประเมินทางเทคนิคและการตรวจสอบ ซึ่งโดยส่วนใหญ่แล้วจะมีงานมากขึ้นและใช้เวลานานกว่านั้น

บทสรุปเกม

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

วัตถุประสงค์หลักของการวิ่งคือ:

• กำลังมองหาความผิดปกติ
• การปรับปรุงผลิตภัณฑ์
• การอภิปรายถึงแนวทางปฏิบัติทางเลือกอื่น
• การประเมินการปฏิบัติตามมาตรฐานและข้อกำหนด

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

การตรวจสอบ

วัตถุประสงค์ของการตรวจสอบซอฟต์แวร์คือการประเมินผลิตภัณฑ์ซอฟต์แวร์และกระบวนการโดยอิสระเพื่อให้สอดคล้องกับกฎระเบียบ มาตรฐาน แนวทาง แผนงาน และขั้นตอนที่เกี่ยวข้อง

การตรวจสอบเป็นกิจกรรมที่จัดขึ้นอย่างเป็นทางการโดยผู้เข้าร่วมจะมีบทบาทเฉพาะ เช่น หัวหน้าผู้ตรวจสอบ ผู้ตรวจสอบอีกคน ผู้บันทึก และผู้ริเริ่ม ตัวแทนขององค์กร/หน่วยองค์กรที่ได้รับการประเมินจะมีส่วนร่วมในการตรวจสอบ จากผลการตรวจสอบ จะมีการระบุกรณีของการไม่ปฏิบัติตามข้อกำหนดและสร้างรายงานที่ทีมงานต้องการ<разработки>เพื่อดำเนินการแก้ไข

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

ข้อควรพิจารณาในทางปฏิบัติ

ข้อกำหนดด้านคุณภาพซอฟต์แวร์

ปัจจัยที่มีอิทธิพล

การวางแผน การจัดการ และการเลือกกิจกรรมและเทคนิค SQM ได้รับอิทธิพลจากปัจจัยต่างๆ ได้แก่:

• ขอบเขตของระบบที่ซอฟต์แวร์จะทำงาน (สำคัญด้านความปลอดภัย)<людей>) ที่สำคัญต่อธุรกิจ ฯลฯ)
• ข้อกำหนดของระบบและซอฟต์แวร์
• ส่วนประกอบใดบ้างที่ใช้ในระบบ - เชิงพาณิชย์ (ภายนอก) หรือมาตรฐาน (ภายใน)
• มาตรฐานวิศวกรรมซอฟต์แวร์ใดบ้างที่มีผลบังคับใช้ในบริบทที่กำหนด
• วิธีการและเครื่องมือซอฟต์แวร์ที่ใช้สำหรับการพัฒนาและการบำรุงรักษา ตลอดจนการประกันและปรับปรุงคุณภาพ (ผลิตภัณฑ์และกระบวนการ) คืออะไร
• งบประมาณ บุคลากร การจัดกิจกรรมโครงการ แผนงานและกำหนดการสำหรับกระบวนการทั้งหมด
• ใครคือผู้ใช้เป้าหมาย และจุดประสงค์ของระบบคืออะไร
• ระดับความสมบูรณ์ของระบบ

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

ความน่าเชื่อถือ

การรับประกัน- รับประกัน<высокой>ความน่าเชื่อถือการป้องกันจากความล้มเหลว
ในกรณีที่ระบบล้มเหลวอาจนำไปสู่ผลกระทบร้ายแรงอย่างยิ่ง (ระบบดังกล่าวบางครั้งเรียกว่า "ระบบความน่าเชื่อถือสูง" หรือ "ระบบความสมบูรณ์สูง" ในแหล่งข้อมูลภาษาอังกฤษ ในภาษารัสเซียบางครั้งเรียกว่า "ระบบความน่าเชื่อถือสูง", "ระบบความน่าเชื่อถือสูง" ความพร้อมใช้งาน” และอื่นๆ) ความสามารถในการรับประกันทั่วไป (สะสม) ของระบบ (เป็นการผสมผสานระหว่างฮาร์ดแวร์ ซอฟต์แวร์ และบุคลากร) เป็นข้อกำหนดด้านคุณภาพหลักและลำดับความสำคัญที่เกี่ยวข้องกับฟังก์ชันการทำงานหลัก<системы>.

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

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

ระดับความสมบูรณ์ของซอฟต์แวร์

ระดับความสมบูรณ์ของซอฟต์แวร์พิจารณาจากผลที่อาจเกิดขึ้นจากความล้มเหลวของซอฟต์แวร์และความน่าจะเป็นของความล้มเหลวดังกล่าวจะเกิดขึ้น เมื่อแง่มุมต่างๆ ของความปลอดภัย (แอปพลิเคชันและความปลอดภัยของข้อมูล) มีความสำคัญ สามารถใช้เทคนิคการวิเคราะห์อันตราย (ในบริบทของความปลอดภัยในการใช้งาน) และการวิเคราะห์ภัยคุกคาม (ในบริบทของความปลอดภัยของข้อมูล) เพื่อพัฒนาแผนงานเพื่อระบุจุดที่อาจเกิดอุบัติเหตุได้ . ประวัติความล้มเหลวของระบบที่คล้ายกันยังสามารถช่วยในการระบุเทคนิคที่มีประโยชน์ที่สุดในการตรวจจับความล้มเหลวและ<всесторонней>การประเมินคุณภาพซอฟต์แวร์

เมื่อพิจารณาความสมบูรณ์ของซอฟต์แวร์โดยละเอียดมากขึ้นในบริบทของโครงการเฉพาะ จำเป็นต้องให้ความสนใจเป็นพิเศษ (การจัดสรรทรัพยากรที่เหมาะสมและดำเนินงานที่จำเป็น) ไม่เพียงแต่กับกระบวนการ SQM (โดยเฉพาะกระบวนการที่เป็นทางการ รวมถึงการตรวจสอบและการรับรอง) แต่ยังรวมถึง ในแง่มุมของการจัดการความต้องการ (ในแง่ของความสมบูรณ์ของเกณฑ์) การบริหารความเสี่ยง (รวมถึงการวางแผนความเสี่ยงทั้งในขั้นตอนการพัฒนาและในขั้นตอนของการดำเนินงานและการบำรุงรักษาระบบ) การออกแบบ (ซึ่งเพื่อเพิ่มความสามารถในการรับประกัน จำเป็นต้องเกี่ยวข้องกับการใน -การวิเคราะห์เชิงลึกและการตรวจสอบโซลูชันทางสถาปัตยกรรมและเทคโนโลยีที่วางแผนไว้สำหรับการใช้งาน มักจะผ่านการสร้างโครงการนำร่อง แท่นสาธิต ฯลฯ) และการทดสอบ (เพื่อให้แน่ใจว่ามีการศึกษาที่ครอบคลุมเกี่ยวกับลักษณะพฤติกรรมของระบบ รวมถึงการจำลองสภาพแวดล้อมการทำงาน /configuration ที่ควรใช้ระบบระหว่างการทำงาน)

การระบุลักษณะข้อบกพร่อง

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

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

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

คำจำกัดความบางส่วนของแนวคิดประเภทนี้มีดังนี้:

• ข้อผิดพลาด:“ความแตกต่าง...ระหว่างผลลัพธ์ที่ถูกต้องกับผลลัพธ์ที่คำนวณได้<полученным с использованием программного обеспечения>”
• ความผิดพลาด:“ขั้นตอน กระบวนการ หรือคำจำกัดความข้อมูลในโปรแกรมคอมพิวเตอร์ไม่ถูกต้อง”
• ความล้มเหลว: “<Некорректный>ผลที่ได้มาจากความบกพร่อง”
• ข้อผิดพลาดจากมนุษย์/ผู้ใช้ (ข้อผิดพลาด):“การกระทำของมนุษย์ซึ่งนำไปสู่ผลลัพธ์ที่ไม่ถูกต้อง”

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

จากผลลัพธ์ของงาน SQM ที่มุ่งเป้าไปที่การตรวจจับข้อบกพร่อง จะมีการดำเนินการเพื่อกำจัดข้อบกพร่องออกจากผลิตภัณฑ์ภายใต้การศึกษา อย่างไรก็ตามเรื่องไม่ได้จบเพียงแค่นั้น มีการดำเนินการอื่นๆ ที่เป็นไปได้เพื่อใช้ประโยชน์จากผลลัพธ์ของงาน SQM ที่เกี่ยวข้องอย่างเต็มที่ ในนั้นมีการวิเคราะห์และสรุป (สรุป)<по обнаруженным несоответствиям/дефектам>การใช้เทคนิคการประเมินเชิงปริมาณ (การได้รับตัวชี้วัด) เพื่อปรับปรุงผลิตภัณฑ์และกระบวนการ การติดตามข้อบกพร่องและนำสิ่งเหล่านั้นออกจากระบบ (ด้วยการจัดการและการควบคุมทางเทคนิคของการดำเนินการแก้ไขที่จำเป็น) ในทางกลับกัน แหล่งที่มาของข้อมูลสำหรับการปรับปรุงกระบวนการโดยเฉพาะคือกระบวนการ SQM

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

เทคนิคการจัดการคุณภาพซอฟต์แวร์

เทคนิค SQM สามารถแบ่งได้เป็นหลายประเภท:

• คงที่
• เทคนิคที่ต้องใช้ทรัพยากรมนุษย์อย่างเข้มข้น
• วิเคราะห์
• พลวัต

เทคนิคแบบคงที่

เทคนิคแบบคงที่เกี่ยวข้องกับ<детальное>การวิจัย (การตรวจสอบ) เอกสารการออกแบบ ซอฟต์แวร์ และข้อมูลอื่น ๆ เกี่ยวกับผลิตภัณฑ์ซอฟต์แวร์โดยไม่มีการดำเนินการ เทคนิคเหล่านี้อาจรวมถึงกิจกรรมการประเมิน "โดยรวม" หรือกิจกรรมการวิเคราะห์ "รายบุคคล" อื่นๆ ที่กล่าวถึงด้านล่าง โดยไม่คำนึงถึงขอบเขตที่ใช้ระบบอัตโนมัติ

เทคนิคคนเข้มข้น

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

เทคนิคการวิเคราะห์

วิศวกรซอฟต์แวร์มักใช้เทคนิคการวิเคราะห์ จากมุมมองของวิธีการและแนวทางแบบ Agile บุคคลและการโต้ตอบถือว่า<непосредственное>การสื่อสารและการมีปฏิสัมพันธ์อย่างต่อเนื่องระหว่างสมาชิกในทีม

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

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

เทคนิคการวิเคราะห์ประเภทอื่นที่เป็นทางการมากกว่าเรียกว่าวิธีการอย่างเป็นทางการ ใช้เพื่อตรวจสอบข้อกำหนดและการออกแบบ (เป็นที่ยอมรับ เป็นครั้งคราวเท่านั้น ในการปฏิบัติงานจริงของการพัฒนาซอฟต์แวร์อุตสาหกรรมในปัจจุบัน) การตรวจสอบความถูกต้องถูกนำไปใช้กับซอฟต์แวร์ที่สำคัญ (ซึ่งโดยทั่วไปแล้ว แทบไม่เกี่ยวข้องกับวิธีการอย่างเป็นทางการ นี่เป็นวิธีธรรมชาติในการได้รับคุณภาพที่ยอมรับได้ในขณะที่ลดต้นทุน) ส่วนใหญ่มักจะใช้เพื่อตรวจสอบส่วนที่สำคัญโดยเฉพาะของระบบที่มีความสำคัญต่อภารกิจ เช่น ข้อกำหนดเฉพาะ<информационной>ความปลอดภัยและความน่าเชื่อถือ

เทคนิคแบบไดนามิก

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

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

ทั้งนี้ขึ้นอยู่กับองค์กร<ведения>โครงการ งานทดสอบบางอย่างสามารถดำเนินการได้ในระหว่างการพัฒนาระบบซอฟต์แวร์ในกระบวนการ SQA และ V&V เนื่องจากแผน SQM เน้นถึงปัญหาการทดสอบ หัวข้อนี้จึงมีความคิดเห็นบางส่วนเกี่ยวกับการทดสอบ

การทดสอบ

กระบวนการยืนยัน<качества> ตามที่อธิบายไว้ใน SQA และ V&V<планах>ตรวจสอบและประเมินผลลัพธ์ใด ๆ (รวมถึงผลิตภัณฑ์ระดับกลางและขั้นสุดท้าย) ที่เกี่ยวข้องกับข้อกำหนดข้อกำหนดซอฟต์แวร์สำหรับ:

• การตรวจสอบย้อนกลับ
• ความสม่ำเสมอ
• ความสมบูรณ์ / ความครบถ้วน,
• ความถูกต้อง
• และดำเนินการโดยตรง<требований>(ผลงาน).

การยืนยันดังกล่าวยังครอบคลุมถึงสิ่งประดิษฐ์เอาต์พุตใดๆ จากกระบวนการพัฒนาและบำรุงรักษา การรวบรวม การวิเคราะห์ และการหาปริมาณของผลลัพธ์ กิจกรรม SQA ช่วยให้มั่นใจได้ว่าประเภทการทดสอบที่เหมาะสม (จำเป็นในบริบทของโครงการที่กำหนด) ได้รับการวางแผน ออกแบบ และนำไปใช้ และ V&V - การพัฒนาแผนการทดสอบ กลยุทธ์ สคริปต์ และขั้นตอนต่างๆ<тестирования>.
ปัญหาการทดสอบจะมีการกล่าวถึงโดยละเอียดในพื้นที่ความรู้เกี่ยวกับการทดสอบ การทดสอบสองประเภทเป็นไปตามวัตถุประสงค์ที่กำหนดโดย SQA และ V&V เนื่องจากมีหน้าที่รับผิดชอบต่อคุณภาพของข้อมูลที่ใช้ในโครงการ:

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

บางครั้ง องค์กร V&V อิสระอาจต้องการความสามารถในการติดตามกระบวนการทดสอบ และในบางกรณี รับรอง (หรือบ่อยกว่านั้นคือจัดทำเอกสาร/บันทึก) การดำเนินการตามจริง<тестов>เพื่อให้มั่นใจว่าได้ดำเนินการตามขั้นตอนที่กำหนด ในทางกลับกัน อาจมีการเรียก V&V เพื่อประเมินการทดสอบ: ความเพียงพอของแผนงานและขั้นตอน ความเหมาะสมและความถูกต้องของผลลัพธ์

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

การวัดคุณภาพซอฟต์แวร์

โมเดลคุณภาพผลิตภัณฑ์ซอฟต์แวร์มักมีหน่วยเมตริกเพื่อกำหนดระดับของลักษณะคุณภาพแต่ละอย่างที่ผลิตภัณฑ์มี

หากเลือกคุณลักษณะด้านคุณภาพอย่างถูกต้อง การวัดดังกล่าวสามารถรองรับคุณภาพ (ระดับคุณภาพ) ได้หลายวิธี ตัวชี้วัดสามารถช่วยชี้แนะกระบวนการตัดสินใจได้ ตัวชี้วัดสามารถช่วยระบุแง่มุมที่เป็นปัญหาและจุดคอขวดในกระบวนการได้ ตัวชี้วัดเป็นเครื่องมือสำหรับวิศวกรในการประเมินคุณภาพงานของพวกเขา - ทั้งเพื่อวัตถุประสงค์ที่กำหนดโดย SQA และจากมุมมองของกระบวนการปรับปรุงในระยะยาว<достигаемого>คุณภาพ.
ด้วยความซับซ้อนภายในและความซับซ้อนของซอฟต์แวร์ที่เพิ่มขึ้น ปัญหาด้านคุณภาพไปไกลกว่าการระบุว่าซอฟต์แวร์ใช้งานได้หรือไม่ทำงาน คำถามคือบรรลุเป้าหมายคุณภาพเชิงปริมาณได้ดีเพียงใด

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

ต้นทุนของกระบวนการ SQM เป็นหนึ่งในนั้น<проблемных>คำถามที่มักเกิดขึ้นในกระบวนการตัดสินใจว่าจะจัดโครงการ (งานออกแบบ) อย่างไร บ่อยครั้งที่มีการใช้แบบจำลองต้นทุนทั่วไป โดยพิจารณาจากการระบุอย่างแน่ชัดว่าเมื่อใดที่มีการค้นพบข้อบกพร่อง และต้องใช้ความพยายามมากเพียงใดในการแก้ไข เมื่อเทียบกับสถานการณ์หากพบข้อบกพร่องตั้งแต่เนิ่นๆ ในวงจรชีวิต ข้อมูลการออกแบบสามารถช่วยให้เห็นภาพต้นทุนได้ชัดเจนยิ่งขึ้น

สุดท้ายนี้ การรายงาน SQM เองจะให้ข้อมูลที่เป็นประโยชน์ไม่เพียงแต่เกี่ยวกับกระบวนการเท่านั้น (หมายถึงสถานะปัจจุบันของกระบวนการเหล่านั้น บันทึกของผู้เขียน) แต่ยังเกี่ยวกับวิธีปรับปรุงกระบวนการวงจรชีวิตทั้งหมดอีกด้วย

แม้ว่าการประมาณเชิงปริมาณ (ในกรณีนี้เรากำลังพูดถึงผลการประเมิน และไม่เกี่ยวกับกระบวนการวัด) ของคุณลักษณะด้านคุณภาพอาจมีประโยชน์ในตัวเอง (เช่น จำนวนข้อกำหนดที่ยังไม่ได้รับการตอบสนองและสัดส่วนของข้อกำหนดดังกล่าว) แต่ก็สามารถทำได้<эффективно>ใช้เทคนิคทางคณิตศาสตร์และกราฟิกเพื่ออำนวยความสะดวกในการตีความค่าเมตริก เทคนิคดังกล่าวจัดจำแนกได้ค่อนข้างเป็นธรรมชาติ เช่น

• ขึ้นอยู่กับวิธีการทางสถิติ (เช่น การวิเคราะห์พาเรโต การแจกแจงแบบปกติ ฯลฯ)
• การทดสอบทางสถิติ
• วิเคราะห์แนวโน้ม
• การคาดการณ์ (เช่น โมเดลความน่าเชื่อถือ)

เทคนิคที่ใช้ทางสถิติและการทดสอบทางสถิติมักจะให้ "ภาพรวม" ของพื้นที่ที่มีปัญหามากที่สุดของผลิตภัณฑ์ซอฟต์แวร์ภายใต้การศึกษา (และโดยวิธีการเดียวกันนี้มักเกิดขึ้นจริงในกระบวนการ) กราฟและแผนภูมิที่ได้จะช่วยให้ผู้มีอำนาจตัดสินใจสามารถระบุพื้นที่ที่จะมุ่งเน้นทรัพยากรได้อย่างชัดเจน<проекта>- ผลการวิเคราะห์แนวโน้มอาจแสดงให้เห็นว่ามีการละเมิดกำหนดการ เช่น ในระหว่างการทดสอบ หรือความล้มเหลวบางประเภทเกิดขึ้นบ่อยขึ้นจนกว่าจะมีการดำเนินการแก้ไขในระหว่างการพัฒนา เทคนิคการคาดการณ์ช่วยในการวางแผนเวลาทดสอบและการทำนายความล้มเหลว

ลักษณะคุณภาพของซอฟต์แวร์

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

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

หมายเหตุ:

1. ไม่มีการสึกหรอหรือเสื่อมสภาพของซอฟต์แวร์ ข้อจำกัดด้านความน่าเชื่อถือเกิดขึ้นเนื่องจากข้อผิดพลาดในข้อกำหนด การออกแบบ และการใช้งาน ความล้มเหลวเนื่องจากข้อผิดพลาดเหล่านี้ขึ้นอยู่กับวิธีใช้ซอฟต์แวร์และเวอร์ชันของซอฟต์แวร์ที่เลือกไว้ก่อนหน้านี้
2. ISO 8402 ให้คำจำกัดความ "ความน่าเชื่อถือ" ว่าเป็น "ความสามารถขององค์ประกอบในการทำหน้าที่ที่จำเป็น" ในมาตรฐานนี้ ฟังก์ชันการทำงานเป็นเพียงคุณลักษณะหนึ่งของคุณภาพซอฟต์แวร์เท่านั้น ดังนั้น คำจำกัดความของความน่าเชื่อถือจึงถูกขยายออกไปเพื่อ "รักษาระดับประสิทธิภาพ" แทนที่จะ "ทำหน้าที่ตามที่ต้องการ"

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

หมายเหตุ:

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

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

ฟังก์ชั่นการทำงาน- ชุดคุณลักษณะที่เกี่ยวข้องกับสาระสำคัญของชุดฟังก์ชันและคุณสมบัติเฉพาะ หน้าที่คือสิ่งที่ตอบสนองความต้องการที่ระบุไว้หรือที่คาดการณ์ไว้

หมายเหตุ:

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

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

คุณภาพผลิตภัณฑ์ซอฟต์แวร์

คุณภาพของซอฟต์แวร์- ขอบเขตคุณลักษณะและคุณลักษณะทั้งหมดของผลิตภัณฑ์ซอฟต์แวร์ที่เกี่ยวข้องกับความสามารถในการตอบสนองความต้องการที่กำหนดไว้หรือที่คาดการณ์ไว้

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

ความสำคัญของคุณลักษณะด้านคุณภาพแต่ละอย่างยังแตกต่างกันไปขึ้นอยู่กับมุมมองที่นำมาใช้

มุมมองผู้ใช้

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

ผู้ใช้อาจสนใจคำถามต่อไปนี้:

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

มุมมองนักพัฒนา

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

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

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

การแนะนำของผู้จัดการ

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

การประเมินคุณภาพผลิตภัณฑ์ซอฟต์แวร์

รูปต่อไปนี้สรุปขั้นตอนหลักที่จำเป็นในการประเมินคุณภาพซอฟต์แวร์

ภาพที่ “รูปแบบกระบวนการประเมิน”

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

แบบจำลองคุณภาพกระบวนการ

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

ภาพที่ “รูปแบบแนวคิดคุณภาพกระบวนการพัฒนา”

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

แนวทางการประยุกต์ใช้คุณลักษณะด้านคุณภาพ

1 การบังคับใช้

2 แนวคิดเกี่ยวกับคุณภาพซอฟต์แวร์

2.1 มุมมองผู้ใช้
2.2 การแนะนำของนักพัฒนา
2.3 การแนะนำผู้จัดการ

3.1 การสร้างข้อกำหนดด้านคุณภาพ

3.2 การเตรียมการประเมิน

3.2.1 การเลือกตัวชี้วัดคุณภาพ (ตัวชี้วัด)
3.2.2 การกำหนดระดับการจัดอันดับ
3.2.3 คำจำกัดความของเกณฑ์การประเมิน

3.3 ขั้นตอนการประเมิน

3.3.1 การวัด
3.3.2 อันดับ
3.3.3 การประเมินผล

1. บทนำ

2 คำจำกัดความของตัวชี้วัดคุณภาพที่ครอบคลุม

2.1 ฟังก์ชันการทำงาน

2.1.1 ความเหมาะสม
2.1.2 ความแม่นยำ
2.1.3 การทำงานร่วมกัน
2.1.4 การปฏิบัติตาม
2.1.5 ความปลอดภัย

2.2 ความน่าเชื่อถือ

2.2.1 ความมั่นคง (ครบกำหนด)
2.2.2 การยอมรับข้อผิดพลาด
2.2.3 ความสามารถในการกู้คืน

2.3 การใช้งาน

2.3.1 ความเข้าใจ
2.3.2 ความสามารถในการเรียนรู้
2.3.3 ความง่ายในการใช้งาน (Operability)

2.4 ประสิทธิภาพ

2.4.1 พฤติกรรมด้านเวลา
2.4.2 พฤติกรรมของทรัพยากร

2.5 การบำรุงรักษา

2.5.1 การวิเคราะห์
2.5.2 การเปลี่ยนแปลงได้
2.5.3 ความเสถียร
2.5.4 ความสามารถในการทดสอบ

2.6 การพกพา

2.6.1 ความสามารถในการปรับตัว
2.6.2 ความง่ายในการใช้งาน (การติดตั้ง)
2.6.3 ความสอดคล้อง
2.6.4 สามารถถอดเปลี่ยนได้

หมายเหตุ:

1. ความสามารถในการเปลี่ยนแทนกันได้ถูกนำมาใช้แทนความเข้ากันได้เพื่อหลีกเลี่ยงความสับสนที่อาจเกิดขึ้นกับการทำงานร่วมกัน
2. ความสามารถในการสับเปลี่ยนกับเครื่องมือซอฟต์แวร์เฉพาะไม่ได้หมายความว่าเครื่องมือนั้นสามารถใช้แทนกันได้กับเครื่องมือซอฟต์แวร์ที่ต้องการ
3. ความสามารถในการสับเปลี่ยนอาจรวมถึงคุณลักษณะของความง่ายในการใช้งานและการปรับตัว แนวคิดนี้ถูกนำมาใช้เป็นคุณลักษณะย่อยที่แยกจากกันเนื่องจากมีความสำคัญ

คุณภาพของโครงการ

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

การจัดการคุณภาพโครงการ

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

หลักการคุณภาพ (ISO 9000)

1. มุ่งเน้นลูกค้า
2. ความรับผิดชอบในการบริหารจัดการ
3. มีส่วนร่วมกับผู้คน
4. แนวทางกระบวนการ
5. แนวทางการจัดการอย่างเป็นระบบ
6. พัฒนาอย่างต่อเนื่อง
7. การตัดสินใจบนพื้นฐานของข้อเท็จจริง
8. ความสัมพันธ์ที่เป็นประโยชน์ร่วมกันกับซัพพลายเออร์

รูปภาพ “ความแตกต่างในการทำความเข้าใจการจัดการคุณภาพใน ISO 9000 และ PMBoK”

การจัดการคุณภาพโครงการ (PMI): กระบวนการย่อย

• การวางแผนคุณภาพ
• การประกันคุณภาพ
• ควบคุมคุณภาพ

การวางแผนคุณภาพ

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

กระบวนการวางแผนคุณภาพ: ปัจจัยนำเข้า

• นโยบายคุณภาพ.เอกสารที่มีหลักการสำหรับวิธีที่องค์กรกำหนดคุณภาพ แต่ไม่มีวิธีในการบรรลุคุณภาพ
• เนื้อหาโครงการ (ขอบเขต)กำหนดสิ่งที่ต้องทำอันเป็นผลมาจากโครงการ และสิ่งที่จำเป็นต้องได้รับการตรวจสอบในกระบวนการจัดการคุณภาพ เอกสารนี้เป็นผลลัพธ์ของกระบวนการวางแผนขอบเขตโครงการ
• รายละเอียดสินค้า.ประกอบด้วยรายละเอียดด้านเทคนิคและประเด็นที่เกี่ยวข้องอื่น ๆ ที่อาจส่งผลต่อการวางแผนคุณภาพ
• มาตรฐานและข้อบังคับรายการมาตรฐานและข้อบังคับที่เกี่ยวข้องกับพื้นที่หรือโครงการที่กำหนด
• เอกสารอื่นๆ.

กระบวนการวางแผนคุณภาพ: เครื่องมือและเทคโนโลยี

• การวิเคราะห์ผลประโยชน์/ต้นทุน ที่เกี่ยวข้องกับการอภิปรายเรื่องต้นทุนคุณภาพ วัตถุประสงค์ของเครื่องมือนี้คือเพื่อเปรียบเทียบต้นทุนที่แท้จริงของการขาดคุณภาพกับประโยชน์ของการประกันคุณภาพ
• การเปรียบเทียบ. ใช้เพื่อสร้างแนวคิดในการปรับปรุงโดยเปรียบเทียบกับโครงการอื่น จะมีประสิทธิภาพมากที่สุดเมื่อทำการเปรียบเทียบกับสิ่งที่ดีที่สุด ไม่ใช่แค่กับโครงการภายในอื่นๆ เท่านั้น
• ไดอะแกรม ใช้เพื่อแสดงให้เห็นว่าองค์ประกอบต่างๆ มีปฏิสัมพันธ์กันอย่างไร แผนภาพมีหลายประเภท รวมถึงแผนภาพสาเหตุและผลกระทบ
• การตั้งค่าการทดลอง ใช้สถานการณ์สมมติแบบ What-if เพื่อพิจารณาว่าตัวแปรใดมีอิทธิพลมากที่สุดต่อผลลัพธ์สุดท้ายของโครงการ
• ต้นทุนคุณภาพ

กระบวนการวางแผนคุณภาพ: ผลลัพธ์ ผลลัพธ์

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

การประกันคุณภาพ

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

กระบวนการคุณภาพ: ปัจจัยการผลิต

• คำแนะนำในการทำงาน ผลลัพธ์อีกประการหนึ่งของกระบวนการวางแผนคุณภาพ
• ผลลัพธ์ของการวัดการควบคุมคุณภาพ ผลลัพธ์ของกระบวนการควบคุมคุณภาพ

กระบวนการประกันคุณภาพ: เครื่องมือและเทคนิค

เครื่องมือและเทคนิคการวางแผนคุณภาพ ซึ่งรวมถึงการวิเคราะห์ต้นทุน-ผลประโยชน์ การเปรียบเทียบ ไดอะแกรม การออกแบบการทดลอง และการประเมินต้นทุนคุณภาพ

การตรวจสอบคุณภาพ

“การเช็คอิน” แบบมีโครงสร้างที่ยืนยัน “บทเรียนที่ได้รับ” ประเภทของการตรวจสอบคุณภาพคือ:

• ภายในภายนอก,
• ระบบ / ผลิตภัณฑ์ / กระบวนการ / องค์กร
• วางแผน/สม่ำเสมอ
• พิเศษและซับซ้อน

กระบวนการประกันคุณภาพ: ผลลัพธ์

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

ควบคุมคุณภาพ

การตรวจสอบผลลัพธ์บางอย่างเพื่อกำหนดการปฏิบัติตามมาตรฐานคุณภาพที่ยอมรับและระบุวิธีกำจัดสาเหตุของประสิทธิภาพที่ไม่น่าพอใจ

กระบวนการควบคุมคุณภาพ: ปัจจัยการผลิต

• ผลลัพธ์ของการทำงาน ผลลัพธ์จะปรากฏในกระบวนการทำงานร่วมกัน การดำเนินการ และการวางแผนโครงการใหม่เสมอ
• แผนการจัดการคุณภาพ ผลลัพธ์ของกระบวนการวางแผนคุณภาพ
• คำแนะนำในการทำงาน ผลลัพธ์ของกระบวนการวางแผนคุณภาพ
• รายการตรวจสอบ

การควบคุมคุณภาพ: เครื่องมือและเทคนิค

• การตรวจสอบ รวมถึงกิจกรรมต่างๆ เช่น การวัด การทดสอบ การทดสอบ เพื่อให้มั่นใจว่าผลลัพธ์ตรงตามข้อกำหนด
• แผนภูมิควบคุม เรียกใช้แผนภูมิจะกำหนดขีดจำกัดบนและล่างทางสถิติ ซึ่งสะท้อนอยู่ที่ด้านใดด้านหนึ่งของค่าเฉลี่ยกระบวนการ
• แผนภาพ: อิชิคาวะ, พาเรโต
• การสุ่มตัวอย่างทางสถิติ
• วิเคราะห์แนวโน้ม.

« วัตถุประสงค์ของการใช้เครื่องมือ– บันทึกผลลัพธ์หรือการเปลี่ยนแปลง แสดงเป็นภาพกราฟิก จากนั้นระบุและแก้ไขปัญหาในลักษณะที่เหมาะสม”

กระบวนการควบคุมคุณภาพ: ผลลัพธ์

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

อ้างอิง

• http://sorlik.blogspot.com, เซอร์เกย์ ออร์ลิก, 2004-2005
• เจเนลต์ เอ.อี. คู่มือการศึกษาและระเบียบวิธีสำหรับวินัย "การจัดการคุณภาพของการพัฒนาซอฟต์แวร์" ปี 2550 เซนต์ปีเตอร์สเบิร์ก