การจัดการคุณภาพซอฟต์แวร์ - คู่มือฉบับย่อ

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

• Software Functional Quality - สะท้อนให้เห็นว่ามันตอบสนองการออกแบบที่กำหนดได้ดีเพียงใดโดยพิจารณาจากข้อกำหนดด้านการใช้งานหรือข้อกำหนด

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

• Software Quality Assurance- Software Quality Assurance (SQA) เป็นชุดของกิจกรรมเพื่อรับรองคุณภาพในกระบวนการวิศวกรรมซอฟต์แวร์ซึ่งส่งผลให้ผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพในที่สุด กิจกรรมสร้างและประเมินกระบวนการผลิตผลิตภัณฑ์ มันเกี่ยวข้องกับการดำเนินการที่เน้นกระบวนการ

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

ความท้าทายด้านคุณภาพซอฟต์แวร์

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

ความซับซ้อนของผลิตภัณฑ์

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

การเปิดเผยผลิตภัณฑ์

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

การพัฒนาผลิตภัณฑ์และกระบวนการผลิต

ในผลิตภัณฑ์อุตสาหกรรมสามารถตรวจพบข้อบกพร่องได้ในช่วงต่อไปนี้ -

• Product development - ในขั้นตอนนี้นักออกแบบและเจ้าหน้าที่ฝ่ายประกันคุณภาพ (QA) จะตรวจสอบและทดสอบต้นแบบผลิตภัณฑ์เพื่อตรวจหาข้อบกพร่อง

• Product production planning- ระหว่างขั้นตอนนี้กระบวนการผลิตและเครื่องมือได้รับการออกแบบและจัดเตรียม ระยะนี้ยังให้โอกาสในการตรวจสอบผลิตภัณฑ์เพื่อตรวจหาข้อบกพร่องที่ไม่มีใครสังเกตเห็นในระหว่างขั้นตอนการพัฒนา

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

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

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

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

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

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

มีการแนะนำปัจจัยคุณภาพซอฟต์แวร์หลายรุ่นและการจัดหมวดหมู่ในช่วงหลายปีที่ผ่านมา โมเดลคลาสสิกของปัจจัยด้านคุณภาพซอฟต์แวร์ที่ McCall แนะนำประกอบด้วย 11 ปัจจัย (McCall et al., 1977) ในทำนองเดียวกันแบบจำลองที่ประกอบด้วย 12 ถึง 15 ปัจจัยได้รับการแนะนำโดย Deutsch and Willis (1988) และโดย Evans และ Marciniak (1987)

โมเดลทั้งหมดนี้ไม่มีความแตกต่างอย่างมากจากโมเดลของ McCall แบบจำลองปัจจัยของ McCall เป็นวิธีที่ใช้งานได้จริงและทันสมัยสำหรับการจำแนกข้อกำหนดของซอฟต์แวร์ (Pressman, 2000)

แบบจำลองปัจจัยของ McCall

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

• Product operation factors - ความถูกต้องความน่าเชื่อถือประสิทธิภาพความสมบูรณ์การใช้งาน

• Product revision factors - การบำรุงรักษาความยืดหยุ่นการทดสอบ

• Product transition factors - พกพา, นำกลับมาใช้ใหม่, การทำงานร่วมกัน

ปัจจัยด้านคุณภาพซอฟต์แวร์การดำเนินงานของผลิตภัณฑ์

ตามแบบจำลองของ McCall หมวดหมู่การทำงานของผลิตภัณฑ์ประกอบด้วยปัจจัยด้านคุณภาพซอฟต์แวร์ 5 ประการซึ่งจัดการกับข้อกำหนดที่ส่งผลโดยตรงต่อการทำงานประจำวันของซอฟต์แวร์ มีดังนี้ -

ความถูกต้อง

ข้อกำหนดเหล่านี้จัดการกับความถูกต้องของผลลัพธ์ของระบบซอฟต์แวร์ ได้แก่ -

• ภารกิจผลลัพธ์

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

• ความสมบูรณ์ของข้อมูลผลลัพธ์ซึ่งอาจได้รับผลกระทบจากข้อมูลที่ไม่สมบูรณ์

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

• ความพร้อมของข้อมูล

• มาตรฐานสำหรับการเข้ารหัสและการจัดทำเอกสารระบบซอฟต์แวร์

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

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

ประสิทธิภาพ

เกี่ยวข้องกับทรัพยากรฮาร์ดแวร์ที่จำเป็นในการทำหน้าที่ต่างๆของระบบซอฟต์แวร์ ซึ่งรวมถึงความสามารถในการประมวลผล (กำหนดเป็น MHz) ความจุในการจัดเก็บข้อมูล (กำหนดเป็น MB หรือ GB) และความสามารถในการสื่อสารข้อมูล (กำหนดเป็น MBPS หรือ GBPS)

นอกจากนี้ยังเกี่ยวข้องกับเวลาระหว่างการชาร์จหน่วยแบบพกพาของระบบเช่นหน่วยระบบข้อมูลที่อยู่ในคอมพิวเตอร์แบบพกพาหรือหน่วยอุตุนิยมวิทยาที่วางไว้กลางแจ้ง

ความซื่อสัตย์

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

การใช้งาน

ข้อกำหนดในการใช้งานจะเกี่ยวข้องกับทรัพยากรของพนักงานที่จำเป็นในการฝึกอบรมพนักงานใหม่และเพื่อใช้งานระบบซอฟต์แวร์

ปัจจัยด้านคุณภาพการแก้ไขผลิตภัณฑ์

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

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

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

ความยืดหยุ่น

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

ทดสอบได้

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

ปัจจัยด้านคุณภาพซอฟต์แวร์การเปลี่ยนผลิตภัณฑ์

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

การพกพา

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

การนำกลับมาใช้ใหม่

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

ความสามารถในการทำงานร่วมกัน

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

Software Quality Assurance(SQA) คือชุดของกิจกรรมเพื่อรับรองคุณภาพในกระบวนการวิศวกรรมซอฟต์แวร์ เพื่อให้แน่ใจว่าซอฟต์แวร์ที่พัฒนามีคุณสมบัติตรงตามและเป็นไปตามข้อกำหนดคุณภาพที่กำหนดไว้หรือเป็นมาตรฐาน SQA เป็นกระบวนการต่อเนื่องภายใน Software Development Life Cycle (SDLC) ที่ตรวจสอบซอฟต์แวร์ที่พัฒนาเป็นประจำเพื่อให้แน่ใจว่าเป็นไปตามมาตรการคุณภาพที่ต้องการ

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

รวมถึงกิจกรรมต่อไปนี้ -

• นิยามกระบวนการและการนำไปใช้
• Auditing
• Training

กระบวนการอาจเป็น -

• ระเบียบวิธีการพัฒนาซอฟต์แวร์
• การจัดการโครงการ
• การจัดการการตั้งค่า
• ข้อกำหนดการพัฒนา / การจัดการ
• Estimation
• การออกแบบซอฟต์แวร์
• การทดสอบ ฯลฯ

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

• ระบุจุดอ่อนในกระบวนการ
• แก้ไขจุดอ่อนเหล่านั้นเพื่อปรับปรุงกระบวนการอย่างต่อเนื่อง

ส่วนประกอบของระบบ SQA

ระบบ SQA จะรวมส่วนประกอบ SQA ที่หลากหลายไว้เสมอ ส่วนประกอบเหล่านี้สามารถแบ่งออกเป็นหกคลาสต่อไปนี้ -

ส่วนประกอบก่อนโครงการ

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

องค์ประกอบของการประเมินกิจกรรมวงจรชีวิตของโครงการ

วงจรชีวิตของโครงการประกอบด้วยสองขั้นตอนคือขั้นตอนของวงจรชีวิตการพัฒนาและขั้นตอนการดำเนินการ - การบำรุงรักษา

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

ส่วนประกอบ SQA ที่ใช้ในระหว่างขั้นตอนการบำรุงรักษา - การดำเนินงานประกอบด้วยส่วนประกอบการบำรุงรักษาเฉพาะทางและส่วนประกอบของวงจรชีวิตการพัฒนาซึ่งส่วนใหญ่จะใช้สำหรับฟังก์ชันการทำงานเพื่อปรับปรุงงานบำรุงรักษา

องค์ประกอบของการป้องกันข้อผิดพลาดของโครงสร้างพื้นฐานและการปรับปรุง

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

องค์ประกอบของการจัดการคุณภาพซอฟต์แวร์

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

องค์ประกอบของการกำหนดมาตรฐานการรับรองและการประเมินระบบ SQA

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

การจัดระเบียบ SQA - ส่วนประกอบของมนุษย์

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

ส่วนประกอบคุณภาพซอฟต์แวร์ก่อนโครงการ

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

• การทบทวนสัญญา
• แผนพัฒนาและคุณภาพ

การทบทวนสัญญา

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

โดยเฉพาะกิจกรรมการตรวจสอบสัญญา ได้แก่ -

• ชี้แจงความต้องการของลูกค้า

• ทบทวนกำหนดการของโครงการและประมาณการความต้องการทรัพยากร

• การประเมินความสามารถของพนักงานมืออาชีพในการดำเนินโครงการที่เสนอ

• การประเมินความสามารถของลูกค้าในการปฏิบัติตามภาระหน้าที่ของเขา

• การประเมินความเสี่ยงในการพัฒนา

แผนพัฒนาและคุณภาพ

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

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

ประเด็นหลักที่ได้รับการปฏิบัติในแผนพัฒนาโครงการคือ -

• Schedules
• กำลังคนและทรัพยากรฮาร์ดแวร์ที่จำเป็น
• การประเมินความเสี่ยง
• ปัญหาขององค์กร: สมาชิกในทีมผู้รับเหมาช่วงและความร่วมมือ
• วิธีการทำโครงงานเครื่องมือในการพัฒนา ฯลฯ
• แผนการใช้ซอฟต์แวร์ซ้ำ

ประเด็นหลักที่ได้รับการปฏิบัติในแผนคุณภาพของโครงการคือ -

• เป้าหมายคุณภาพแสดงในเงื่อนไขที่วัดได้ที่เหมาะสม

• เกณฑ์สำหรับการเริ่มต้นและสิ้นสุดแต่ละขั้นตอนของโครงการ

• รายการบทวิจารณ์การทดสอบและกิจกรรมการตรวจสอบและตรวจสอบตามกำหนดเวลาอื่น ๆ

เมตริกซอฟต์แวร์สามารถแบ่งออกเป็นสามประเภท -

• Product metrics - อธิบายลักษณะของผลิตภัณฑ์เช่นขนาดความซับซ้อนคุณสมบัติการออกแบบประสิทธิภาพและระดับคุณภาพ

• Process metrics - คุณสมบัติเหล่านี้สามารถใช้เพื่อปรับปรุงกิจกรรมการพัฒนาและการบำรุงรักษาซอฟต์แวร์

• Project metrics- เมตริกนี้อธิบายลักษณะโครงการและการดำเนินการ ตัวอย่าง ได้แก่ จำนวนนักพัฒนาซอฟต์แวร์รูปแบบการรับพนักงานตลอดวงจรชีวิตของซอฟต์แวร์ต้นทุนตารางเวลาและผลผลิต

เมตริกบางรายการอยู่ในหลายหมวดหมู่ ตัวอย่างเช่นเมตริกคุณภาพในกระบวนการของโครงการเป็นทั้งเมตริกกระบวนการและเมตริกโครงการ

Software quality metricsเป็นชุดย่อยของเมตริกซอฟต์แวร์ที่เน้นด้านคุณภาพของผลิตภัณฑ์กระบวนการและโครงการ สิ่งเหล่านี้มีความเกี่ยวข้องอย่างใกล้ชิดกับเมตริกกระบวนการและผลิตภัณฑ์มากกว่าเมตริกโครงการ

เมตริกคุณภาพซอฟต์แวร์สามารถแบ่งออกได้เป็นสามประเภท -

• เมตริกคุณภาพผลิตภัณฑ์
• เมตริกคุณภาพในกระบวนการ
• เมตริกคุณภาพการบำรุงรักษา

เมตริกคุณภาพผลิตภัณฑ์

เมตริกนี้มีดังต่อไปนี้ -

• เวลาเฉลี่ยที่จะล้มเหลว
• ความหนาแน่นของข้อบกพร่อง
• ปัญหาของลูกค้า
• ความพึงพอใจของลูกค้า

เวลาเฉลี่ยที่จะล้มเหลว

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

ความหนาแน่นของข้อบกพร่อง

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

ปัญหาของลูกค้า

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

เมตริกปัญหามักจะแสดงในรูปของ Problems per User-Month (PUM).

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

ที่ไหน

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

โดยปกติ PUM จะคำนวณในแต่ละเดือนหลังจากที่ซอฟต์แวร์ออกสู่ตลาดและรวมถึงค่าเฉลี่ยรายเดือนตามปี

ความพึงพอใจของลูกค้า

ความพึงพอใจของลูกค้ามักวัดได้จากข้อมูลการสำรวจของลูกค้าผ่านมาตราส่วนห้าจุด -

• พึงพอใจมาก
• Satisfied
• Neutral
• Dissatisfied
• ไม่พอใจมาก

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

• เปอร์เซ็นต์ของลูกค้าที่พึงพอใจอย่างสมบูรณ์
• เปอร์เซ็นต์ของลูกค้าที่พึงพอใจ
• เปอร์เซ็นต์ของลูกค้าที่ไม่พึงพอใจ
• เปอร์เซ็นต์ของลูกค้าที่ไม่พึงพอใจ

โดยปกติแล้วจะใช้ความพึงพอใจเปอร์เซ็นต์นี้

เมตริกคุณภาพในกระบวนการ

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

• ความหนาแน่นของข้อบกพร่องระหว่างการทดสอบเครื่อง
• รูปแบบการมาถึงข้อบกพร่องระหว่างการทดสอบเครื่อง
• รูปแบบการกำจัดข้อบกพร่องตามเฟส
• ประสิทธิภาพในการกำจัดข้อบกพร่อง

ความหนาแน่นของข้อบกพร่องระหว่างการทดสอบเครื่อง

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

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

รูปแบบการมาถึงข้อบกพร่องระหว่างการทดสอบเครื่อง

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

• ข้อบกพร่องที่มาถึงหรือข้อบกพร่องที่รายงานในระหว่างขั้นตอนการทดสอบตามช่วงเวลา (เช่นสัปดาห์) ทั้งหมดนี้จะไม่ใช่ข้อบกพร่องที่ถูกต้อง

• รูปแบบของการมาถึงของข้อบกพร่องที่ถูกต้องเมื่อมีการกำหนดปัญหากับปัญหาที่รายงาน นี่คือรูปแบบข้อบกพร่องที่แท้จริง

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

รูปแบบการกำจัดข้อบกพร่องตามเฟส

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

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

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

ประสิทธิภาพในการกำจัดข้อบกพร่อง

สามารถกำหนดได้ดังนี้ -

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

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

เมตริกคุณภาพการบำรุงรักษา

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

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

แก้ไขดัชนีการจัดการสินค้าค้างและค้าง

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

Backlog Management Index (BMI) ใช้ในการจัดการ Backlog ของปัญหาที่เปิดอยู่และยังไม่ได้รับการแก้ไข

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

ถ้าค่าดัชนีมวลกายมากกว่า 100 หมายความว่างานในมือจะลดลง ถ้า BMI น้อยกว่า 100 งานในมือจะเพิ่มขึ้น

แก้ไขเวลาตอบสนองและแก้ไขการตอบสนอง

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

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

เปอร์เซ็นต์การแก้ไขที่ค้างชำระ

คำนวณได้ดังนี้ -

$Percent \:Delinquent\: Fixes =$

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

แก้ไขคุณภาพ

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

การแก้ไขข้อบกพร่องสามารถบันทึกได้สองวิธี: บันทึกในเดือนที่ค้นพบหรือบันทึกในเดือนที่ส่งการแก้ไข ประการแรกคือการวัดผลลูกค้า ประการที่สองคือการวัดกระบวนการ ความแตกต่างระหว่างวันที่ทั้งสองคือระยะเวลาแฝงของการแก้ไขที่บกพร่อง

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

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

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

การวัดผลในชีวิตประจำวัน

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

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

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

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

การวัดเป็นการวัดปริมาณโดยตรงในขณะที่การคำนวณเป็นวิธีทางอ้อมที่เรารวมการวัดที่แตกต่างกันโดยใช้สูตรบางสูตร

การวัดในวิศวกรรมซอฟต์แวร์

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

สำหรับโครงการพัฒนาส่วนใหญ่

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

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

ในวิศวกรรมซอฟต์แวร์การวัดผลเป็นสิ่งจำเป็นสำหรับกิจกรรมพื้นฐานสามประการต่อไปนี้ -

• เพื่อทำความเข้าใจสิ่งที่เกิดขึ้นระหว่างการพัฒนาและการบำรุงรักษา
• เพื่อควบคุมสิ่งที่เกิดขึ้นในโครงการ
• เพื่อปรับปรุงกระบวนการและเป้าหมาย

ทฤษฎีการวัดตัวแทน

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

ความสัมพันธ์เชิงประจักษ์

ในโลกแห่งความเป็นจริงเราเข้าใจสิ่งต่าง ๆ โดยการเปรียบเทียบไม่ใช่การกำหนดตัวเลขให้กับสิ่งเหล่านี้

ตัวอย่างเช่นในการเปรียบเทียบความสูงเราใช้คำว่า "สูงกว่า" สูงกว่า " ดังนั้นสิ่งเหล่านี้ 'สูงกว่า' สูงกว่า 'จึงเป็นความสัมพันธ์เชิงประจักษ์สำหรับความสูง

เราสามารถกำหนดความสัมพันธ์เชิงประจักษ์ได้มากกว่าหนึ่งความสัมพันธ์ในเซตเดียวกัน

ตัวอย่างเช่น X สูงกว่า Y X Y สูงกว่า Z มาก

ความสัมพันธ์เชิงประจักษ์สามารถเป็นเอกภาพไบนารีเทอร์นารี ฯลฯ

X สูง Y ไม่สูงเป็นความสัมพันธ์แบบเอกภาพ

X สูงกว่า Y เป็นความสัมพันธ์แบบไบนารี

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

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

ลิเคิร์ทสเกล

ที่นี่ผู้ใช้จะได้รับคำสั่งว่าพวกเขาต้องเห็นด้วยหรือไม่เห็นด้วย

For example - ซอฟต์แวร์นี้ทำงานได้ดี

เห็นด้วยอย่างยิ่ง	ตกลง	ไม่เห็นด้วยหรือไม่เห็นด้วย	ไม่เห็นด้วย	ไม่เห็นด้วยอย่างยิ่ง

การจัดอันดับบังคับ

เรียงลำดับทางเลือกที่กำหนดจาก 1 (ดีที่สุด) ถึง n (แย่ที่สุด)

ตัวอย่างเช่น: จัดอันดับโมดูลซอฟต์แวร์ 5 รายการต่อไปนี้ตามประสิทธิภาพ

ชื่อโมดูล	อันดับ
โมดูลก
โมดูล B
โมดูล C
โมดูล D
โมดูล E

มาตราส่วนความถี่ทางวาจา

For example - โปรแกรมนี้ล้มเหลวบ่อยแค่ไหน?

เสมอ	บ่อยครั้ง	บางครั้ง	ไม่ค่อย	ไม่เลย

มาตราส่วนปกติ

ที่นี่ผู้ใช้จะได้รับรายการทางเลือกและพวกเขาต้องเลือกอย่างใดอย่างหนึ่ง

For example - โปรแกรมนี้ล้มเหลวบ่อยแค่ไหน?

• Hourly
• Daily
• Weekly
• Monthly
• ปีละหลายครั้ง
• ปีละครั้งหรือสองครั้ง
• Never

มาตราส่วนเปรียบเทียบ

ที่นี่ผู้ใช้จะต้องให้ตัวเลขโดยการเปรียบเทียบตัวเลือกต่างๆ

Very superiorAbout the sameVery inferior

12345678910

มาตราส่วนตัวเลข

ที่นี่ผู้ใช้จะต้องให้หมายเลขตามความสำคัญ

UnimportantImportant

12345678910

กฎของการทำแผนที่

ในการทำแผนที่เราต้องระบุโดเมนช่วงและกฎในการทำแผนที่

For example - โดเมน - โลกแห่งความจริง

• Range - โลกทางคณิตศาสตร์เช่นจำนวนเต็มจำนวนจริง ฯลฯ

• Rules - สำหรับวัดส่วนสูงรองเท้าที่ใส่หรือไม่

ในทำนองเดียวกันในกรณีของการวัดผลซอฟต์แวร์รายการตรวจสอบของคำสั่งที่จะรวมอยู่ในบรรทัดของรหัสที่จะระบุ

เงื่อนไขการวัดที่เป็นตัวแทน

เงื่อนไขการเป็นตัวแทนยืนยันว่าการแม็ปการวัด (M) ต้องแมปเอนทิตีเป็นตัวเลขและความสัมพันธ์เชิงประจักษ์เข้ากับความสัมพันธ์เชิงตัวเลขในลักษณะที่ความสัมพันธ์เชิงประจักษ์รักษาและรักษาไว้โดยความสัมพันธ์เชิงตัวเลข

ตัวอย่างเช่น: ความสัมพันธ์เชิงประจักษ์ 'สูงกว่า' ถูกจับคู่กับความสัมพันธ์เชิงตัวเลข '>' กล่าวคือ X is taller than Y, if and only if M(X) > M(Y)

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

สำหรับความสัมพันธ์ยูนารี 'is tall' เราอาจมีความสัมพันธ์เชิงตัวเลข

X > 50

เงื่อนไขการเป็นตัวแทนกำหนดให้สำหรับการวัดใด ๆ M,

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

ขั้นตอนสำคัญของการวัดผลอย่างเป็นทางการ

ขั้นตอนสำคัญของการวัดสรุปได้ดังนี้ -

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

การวัดมีสองประเภท -

• การวัดโดยตรง
• การวัดทางอ้อม

การวัดโดยตรง

นี่คือการวัดที่สามารถวัดได้โดยไม่ต้องเกี่ยวข้องกับเอนทิตีหรือแอตทริบิวต์อื่นใด

มาตรการโดยตรงต่อไปนี้มักใช้ในวิศวกรรมซอฟต์แวร์

• ความยาวของซอร์สโค้ดโดย LOC
• ระยะเวลาในการทดสอบตามเวลาที่ผ่านไป
• จำนวนข้อบกพร่องที่ค้นพบในระหว่างกระบวนการทดสอบโดยการนับข้อบกพร่อง
• เวลาที่โปรแกรมเมอร์ใช้กับโปรแกรม

การวัดทางอ้อม

นี่คือการวัดที่สามารถวัดได้ในรูปของเอนทิตีหรือแอตทริบิวต์อื่น ๆ

มาตรการทางอ้อมต่อไปนี้มักใช้ในวิศวกรรมซอฟต์แวร์

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

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

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

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

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

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

การวัดผลเพื่อการทำนาย

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

มาตราส่วนการวัดคือการแมปที่ใช้เพื่อแสดงระบบความสัมพันธ์เชิงประจักษ์ ส่วนใหญ่มี 5 ประเภท -

• มาตราส่วนที่กำหนด
• มาตราส่วนปกติ
• มาตราส่วนช่วงเวลา
• มาตราส่วนอัตราส่วน
• มาตราส่วนสัมบูรณ์

มาตราส่วนที่กำหนด

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

มีสองลักษณะสำคัญ -

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

• การกำหนดหมายเลขที่แตกต่างกันหรือการแสดงสัญลักษณ์ของชั้นเรียนเป็นมาตรการที่ยอมรับได้ แต่ไม่มีความคิดเกี่ยวกับขนาดที่เกี่ยวข้องกับตัวเลขหรือสัญลักษณ์

มาตราส่วนปกติ

วางองค์ประกอบในรูปแบบการจัดหมวดหมู่ตามลำดับ มีลักษณะดังต่อไปนี้ -

• ระบบความสัมพันธ์เชิงประจักษ์ประกอบด้วยคลาสที่เรียงลำดับตามแอตทริบิวต์

• การทำแผนที่ใด ๆ ที่รักษาการสั่งซื้อนั้นยอมรับได้

• ตัวเลขแสดงถึงการจัดอันดับเท่านั้น ดังนั้นการบวกการลบและการคำนวณทางคณิตศาสตร์อื่น ๆ จึงไม่มีความหมาย

มาตราส่วนช่วงเวลา

มาตราส่วนนี้รวบรวมข้อมูลเกี่ยวกับขนาดของช่วงเวลาที่แยกการจำแนกประเภท ดังนั้นจึงมีพลังมากกว่ามาตราส่วนเล็กน้อยและมาตราส่วนตามลำดับ

มีลักษณะดังต่อไปนี้ -

• มันรักษาคำสั่งเช่นเดียวกับมาตราส่วนลำดับ

• รักษาความแตกต่าง แต่ไม่ใช่อัตราส่วน

• การบวกและการลบสามารถทำได้ในมาตราส่วนนี้ แต่ไม่ใช่การคูณหรือการหาร

หากแอตทริบิวต์สามารถวัดได้ตามช่วงเวลาและ M และ M’ เป็นการแมปที่ตรงตามเงื่อนไขการเป็นตัวแทนจากนั้นเราจะหาตัวเลขสองจำนวนได้เสมอ a และ b ดังนั้น,

ม = aM '+ b

มาตราส่วนอัตราส่วน

นี่คือมาตราส่วนการวัดที่มีประโยชน์ที่สุด ที่นี่มีความสัมพันธ์เชิงประจักษ์ในการจับอัตราส่วน มีลักษณะดังต่อไปนี้ -

• เป็นการแมปการวัดผลที่รักษาการเรียงลำดับขนาดของช่วงเวลาระหว่างเอนทิตีและอัตราส่วนระหว่างเอนทิตี

• มีองค์ประกอบที่เป็นศูนย์ซึ่งแสดงถึงการขาดคุณสมบัติทั้งหมด

• การแมปการวัดต้องเริ่มต้นที่ศูนย์และเพิ่มขึ้นในช่วงเวลาที่เท่ากันซึ่งเรียกว่าหน่วย

• สามารถใช้การคำนวณทางคณิตศาสตร์ทั้งหมดได้

ที่นี่การทำแผนที่จะอยู่ในรูปแบบ

M = aM’

ที่ไหน ‘a’ เป็นสเกลาร์เชิงบวก

มาตราส่วนสัมบูรณ์

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

มีลักษณะดังต่อไปนี้ -

• การวัดทำได้โดยการนับจำนวนองค์ประกอบในชุดเอนทิตี

• แอตทริบิวต์จะอยู่ในรูปแบบ "จำนวนครั้งที่เกิดขึ้นของ x ในเอนทิตี"

• การแมปการวัดที่เป็นไปได้มีเพียงวิธีเดียวคือการนับจริง

• การคำนวณทางคณิตศาสตร์ทั้งหมดสามารถทำได้กับจำนวนผลลัพธ์

การสืบสวนเชิงประจักษ์เกี่ยวข้องกับการตรวจสอบทางวิทยาศาสตร์ของเครื่องมือเทคนิคหรือวิธีการใด ๆ การตรวจสอบนี้ส่วนใหญ่ประกอบด้วย 4 หลักการดังต่อไปนี้

• การเลือกเทคนิคการสืบสวน
• การระบุสมมติฐาน
• การรักษาการควบคุมตัวแปร
• ทำให้การสอบสวนมีความหมาย

การเลือกเทคนิคการสืบสวน

องค์ประกอบสำคัญของการตรวจสอบเชิงประจักษ์ในวิศวกรรมซอฟต์แวร์ ได้แก่ -

• Survey
• กรณีศึกษา
• การทดลองอย่างเป็นทางการ

สำรวจ

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

ในกรณีนี้เราไม่สามารถควบคุมสถานการณ์ได้ เราสามารถบันทึกสถานการณ์และเปรียบเทียบกับสถานการณ์ที่คล้ายกันได้

กรณีศึกษา

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

การทดลองอย่างเป็นทางการ

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

วิธีการสอบสวนเฉพาะสามารถเลือกได้ตามแนวทางต่อไปนี้ -

• หากกิจกรรมเกิดขึ้นแล้วเราสามารถทำการสำรวจหรือกรณีศึกษาได้ หากยังไม่เกิดขึ้นอาจเลือกกรณีศึกษาหรือการทดลองอย่างเป็นทางการ

• หากเราควบคุมตัวแปรที่มีผลต่อผลลัพธ์ได้ในระดับสูงเราสามารถใช้การทดลองได้ หากเราไม่สามารถควบคุมตัวแปรได้กรณีศึกษาจะเป็นเทคนิคที่ต้องการ

• หากไม่สามารถจำลองแบบได้ในระดับที่สูงขึ้นแสดงว่าไม่สามารถทำการทดลองได้

• หากต้นทุนในการจำลองแบบต่ำเราสามารถพิจารณาทดลองได้

การระบุสมมติฐาน

เพื่อเพิ่มการตัดสินใจของเทคนิคการสืบสวนโดยเฉพาะเป้าหมายของการวิจัยควรแสดงเป็นสมมติฐานที่เราต้องการทดสอบ สมมติฐานคือทฤษฎีเบื้องต้นหรือสมมติฐานที่โปรแกรมเมอร์คิดว่าจะอธิบายพฤติกรรมที่ต้องการสำรวจ

รักษาการควบคุมตัวแปร

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

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

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

ทำให้การสอบสวนมีความหมาย

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

สอดคล้องกับทฤษฎีและภูมิปัญญาดั้งเดิม

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

สำรวจความสัมพันธ์

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

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

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

การประเมินความถูกต้องของแบบจำลอง

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

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

การตรวจสอบมาตรการ

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

กรอบการทำงานสำหรับการวัดผลซอฟต์แวร์เป็นไปตามหลักการสามประการ -

• การจัดประเภทเอนทิตีที่จะตรวจสอบ
• การกำหนดเป้าหมายการวัดผลที่เกี่ยวข้อง
• การระบุระดับวุฒิภาวะที่องค์กรมีอยู่

การจำแนกประเภทของเอนทิตีที่จะตรวจสอบ

ในวิศวกรรมซอฟต์แวร์ส่วนใหญ่มีเอนทิตีสามประเภท พวกเขาคือ -

• Processes
• Products
• Resources

เอนทิตีทั้งหมดเหล่านี้มีเอนทิตีภายในและภายนอก

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

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

คุณลักษณะต่างๆที่สามารถวัดได้สำหรับแต่ละเอนทิตีมีดังนี้ -

กระบวนการ

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

• ระยะเวลาของกระบวนการหรือกิจกรรมอย่างใดอย่างหนึ่ง

• ความพยายามที่เกี่ยวข้องกับกระบวนการหรือกิจกรรมอย่างใดอย่างหนึ่ง

• จำนวนเหตุการณ์ที่ระบุประเภทที่เกิดขึ้นระหว่างกระบวนการหรือกิจกรรมอย่างใดอย่างหนึ่ง

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

ผลิตภัณฑ์

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

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

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

ทรัพยากร

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

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

การกำหนดเป้าหมายการวัดที่เกี่ยวข้อง

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

กระบวนทัศน์ - คำถาม - ตัวชี้วัด (GQM)

แนวทาง GQM มีกรอบที่เกี่ยวข้องกับสามขั้นตอนต่อไปนี้ -

• รายการเป้าหมายหลักของโครงการพัฒนาหรือบำรุงรักษา

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

• ตัดสินใจว่าจะต้องวัดผลอะไรเพื่อให้สามารถตอบคำถามได้อย่างเพียงพอ

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

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

เพื่อช่วยสร้างเป้าหมายคำถามและตัวชี้วัด Basili & Rombach ได้จัดเตรียมเทมเพลตไว้ให้

• Purpose - เพื่อ (กำหนดลักษณะประเมินคาดการณ์จูงใจ ฯลฯ ) (กระบวนการผลิตภัณฑ์แบบจำลองตัวชี้วัด ฯลฯ ) เพื่อทำความเข้าใจประเมินจัดการวิศวกรเรียนรู้ปรับปรุง ฯลฯ Example: เพื่อกำหนดลักษณะของผลิตภัณฑ์เพื่อเรียนรู้

• Perspective - ตรวจสอบ (ต้นทุนประสิทธิผลความถูกต้องข้อบกพร่องการเปลี่ยนแปลงมาตรการผลิตภัณฑ์ ฯลฯ ) จากมุมมองของผู้พัฒนาผู้จัดการลูกค้า ฯลฯ Example: ตรวจสอบข้อบกพร่องจากมุมมองของลูกค้า

• Environment - สภาพแวดล้อมประกอบด้วยสิ่งต่อไปนี้: ปัจจัยด้านกระบวนการปัจจัยบุคคลปัจจัยปัญหาวิธีการเครื่องมือข้อ จำกัด ฯลฯ Example: ลูกค้าของซอฟต์แวร์นี้คือผู้ที่ไม่มีความรู้เกี่ยวกับเครื่องมือ

การวัดผลและการปรับปรุงกระบวนการ

โดยปกติการวัดผลมีประโยชน์สำหรับ -

• ทำความเข้าใจเกี่ยวกับกระบวนการและผลิตภัณฑ์
• การสร้างพื้นฐาน
• การเข้าถึงและคาดการณ์ผลลัพธ์

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

Level 1: Ad hoc

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

Level 2: Repeatable

ในระดับนี้อินพุตและเอาต์พุตของกระบวนการข้อ จำกัด และทรัพยากรสามารถระบุได้ สามารถอธิบายกระบวนการที่ทำซ้ำได้ตามแผนภาพต่อไปนี้

มาตรการป้อนข้อมูลอาจเป็นขนาดและความผันผวนของข้อกำหนด ผลลัพธ์อาจวัดได้ในแง่ของขนาดระบบทรัพยากรในแง่ของความพยายามของพนักงานและข้อ จำกัด ในแง่ของต้นทุนและตารางเวลา

Level 3: Defined

ในระดับนี้มีการกำหนดกิจกรรมระดับกลางและทราบและเข้าใจอินพุตและเอาต์พุต ตัวอย่างง่ายๆของกระบวนการที่กำหนดได้อธิบายไว้ในรูปต่อไปนี้

ข้อมูลเข้าและผลลัพธ์จากกิจกรรมระดับกลางสามารถตรวจสอบวัดและประเมินได้

Level 4: Managed

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

Level 5: Optimizing

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

ในระดับวุฒิภาวะที่กำหนดเราสามารถรวบรวมการวัดสำหรับระดับนั้นและทุกระดับที่ต่ำกว่านั้น

การระบุระดับของวุฒิภาวะ

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

• ที่ level 1โครงการนี้มีแนวโน้มที่จะมีข้อกำหนดที่ไม่เหมาะสม ในระดับนี้การวัดลักษณะความต้องการทำได้ยาก

• ที่ level 2ข้อกำหนดได้รับการกำหนดไว้เป็นอย่างดีและสามารถรวบรวมข้อมูลเพิ่มเติมเช่นประเภทของข้อกำหนดแต่ละข้อและจำนวนการเปลี่ยนแปลงในแต่ละประเภทได้

• ที่ level 3กิจกรรมระดับกลางถูกกำหนดด้วยเกณฑ์การเข้าและออกสำหรับแต่ละกิจกรรม

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

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

การตรวจสอบการวัดผลของระบบซอฟต์แวร์มีสองขั้นตอน -

• การตรวจสอบระบบการวัดผล
• การตรวจสอบระบบการทำนาย

การตรวจสอบระบบการวัด

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

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

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

ม. (P1 + P2) = ม. (P1) + ม. (P2)

ถ้าเป็นโปรแกรม P1 มีความยาวมากกว่าโปรแกรม P2แล้ววัดใด ๆ m ควรตอบสนองด้วย

ม. (P1)> ม. (P2)

ความยาวของโปรแกรมสามารถวัดได้โดยการนับบรรทัดของรหัส หากจำนวนนี้ตรงตามความสัมพันธ์ข้างต้นเราสามารถพูดได้ว่าบรรทัดของรหัสเป็นการวัดความยาวที่ถูกต้อง

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

การตรวจสอบระบบทำนาย

ระบบการทำนายใช้ในการทำนายคุณลักษณะบางอย่างของเอนทิตีในอนาคตที่เกี่ยวข้องกับแบบจำลองทางคณิตศาสตร์ที่มีขั้นตอนการทำนายที่เกี่ยวข้อง

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

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

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

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

• Product metrics อธิบายลักษณะของผลิตภัณฑ์เช่นขนาดความซับซ้อนคุณสมบัติการออกแบบประสิทธิภาพและระดับคุณภาพ

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

• Project metricsอธิบายลักษณะโครงการและการดำเนินการ ตัวอย่าง ได้แก่ จำนวนนักพัฒนาซอฟต์แวร์รูปแบบการรับพนักงานตลอดวงจรชีวิตของซอฟต์แวร์ต้นทุนตารางเวลาและผลผลิต

เมตริกบางรายการอยู่ในหลายหมวดหมู่ ตัวอย่างเช่นเมตริกคุณภาพในกระบวนการของโครงการเป็นทั้งเมตริกกระบวนการและเมตริกโครงการ

ขอบเขตของเมตริกซอฟต์แวร์

เมตริกซอฟต์แวร์ประกอบด้วยกิจกรรมมากมายซึ่งรวมถึงสิ่งต่อไปนี้ -

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

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

การประมาณการต้นทุนและความพยายาม

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

• โมเดล COCOMO ของ Boehm
• นางแบบบางของพัท
• แบบจำลองจุดฟังก์ชันของ Albrecht

รูปแบบและมาตรการเพิ่มผลผลิต

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

การเก็บรวบรวมข้อมูล

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

Quality Models and Measures

Quality models have been developed for the measurement of quality of the product without which productivity is meaningless. These quality models can be combined with productivity model for measuring the correct productivity. These models are usually constructed in a tree-like fashion. The upper branches hold important high level quality factors such as reliability and usability.

The notion of divide and conquer approach has been implemented as a standard approach to measuring software quality.

Reliability Models

Most quality models include reliability as a component factor, however, the need to predict and measure reliability has led to a separate specialization in reliability modeling and prediction. The basic problem in reliability theory is to predict when a system will eventually fail.

Performance Evaluation and Models

It includes externally observable system performance characteristics such as response times and completion rates, and the internal working of the system such as the efficiency of algorithms. It is another aspect of quality.

Structural and Complexity Metrics

Here we measure the structural attributes of representations of the software, which are available in advance of execution. Then we try to establish empirically predictive theories to support quality assurance, quality control, and quality prediction.

Capability Maturity Assessment

This model can assess many different attributes of development including the use of tools, standard practices and more. It is based on the key practices that every good contractor should be using.

Management by Metrics

For managing the software project, measurement has a vital role. For checking whether the project is on track, users and developers can rely on the measurement-based chart and graph. The standard set of measurements and reporting methods are especially important when the software is embedded in a product where the customers are not usually well-versed in software terminology.

Evaluation of Methods and Tools

This depends on the experimental design, proper identification of factors likely to affect the outcome and appropriate measurement of factor attributes.

Software metrics is a standard of measure that contains many activities, which involves some degree of measurement. The success in the software measurement lies in the quality of the data collected and analyzed.

What is Good Data?

The data collected can be considered as a good data, if it can produce the answers for the following questions −

• Are they correct? − A data can be considered correct, if it was collected according to the exact rules of the definition of the metric.

• Are they accurate? − Accuracy refers to the difference between the data and the actual value.

• Are they appropriately precise? − Precision deals with the number of decimal places needed to express the data.

• Are they consistent? − Data can be considered as consistent, if it doesn’t show a major difference from one measuring device to another.

• Are they associated with a particular activity or time period? − If the data is associated with a particular activity or time period, then it should be clearly specified in the data.

• Can they be replicated? − Normally, the investigations such as surveys, case studies, and experiments are frequently repeated under different circumstances. Hence, the data should also be possible to replicate easily.

How to Define the Data?

Data that is collected for measurement purpose is of two types −

• Raw data − Raw data results from the initial measurement of process, products, or resources. For example: Weekly timesheet of the employees in an organization.

• Refined data − Refined data results from extracting essential data elements from the raw data for deriving values for attributes.

Data can be defined according to the following points −

• Location
• Timing
• Symptoms
• End result
• Mechanism
• Cause
• Severity
• Cost

How to Collect Data?

Collection of data requires human observation and reporting. Managers, system analysts, programmers, testers, and users must record row data on forms. To collect accurate and complete data, it is important to −

• Keep procedures simple

• Avoid unnecessary recording

• Train employees in the need to record data and in the procedures to be used

• Provide the results of data capture and analysis to the original providers promptly and in a useful form that will assist them in their work

• Validate all data collected at a central collection point

Planning of data collection involves several steps −

• Decide which products to measure based on the GQM analysis

• Make sure that the product is under configuration control

• Decide exactly which attributes to measure and how indirect measures will be derived

• Once the set of metrics is clear and the set of components to be measured has been identified, devise a scheme for identifying each activity involved in the measurement process

• Establish a procedure for handling the forms, analyzing the data, and reporting the results

Data collection planning must begin when project planning begins. Actual data collection takes place during many phases of development.

For example − Some data related to project personnel can be collected at the start of the project, while other data collection such as effort begins at project starting and continues through operation and maintenance.

How to Store and Extract Data

In software engineering, data should be stored in a database and set up using a Database Management System (DBMS). An example of a database structure is shown in the following figure. This database will store the details of different employees working in different departments of an organization.

In the above diagram, each box is a table in the database, and the arrow denotes the many-to-one mapping from one table to another. The mappings define the constraints that preserve the logical consistency of the data.

Once the database is designed and populated with data, we can make use of the data manipulation languages to extract the data for analysis.

After collecting relevant data, we have to analyze it in an appropriate way. There are three major items to consider for choosing the analysis technique.

• The nature of data
• The purpose of the experiment
• Design considerations

The Nature of Data

To analyze the data, we must also look at the larger population represented by the data as well as the distribution of that data.

Sampling, population, and data distribution

Sampling is the process of selecting a set of data from a large population. Sample statistics describe and summarize the measures obtained from a group of experimental subjects.

Population parameters represent the values that would be obtained if all possible subjects were measured.

The population or sample can be described by the measures of central tendency such as mean, median, and mode and measures of dispersion such as variance and standard deviation. Many sets of data are distributed normally as shown in the following graph.

As shown above, data will be evenly distributed about the mean. which is the significant characteristics of a normal distribution.

Other distributions also exist where the data is skewed so that there are more data points on one side of the mean than other. For example: If most of the data is present on the left-hand side of the mean, then we can say that the distribution is skewed to the left.

The Purpose of the Experiment

Normally, experiments are conducted −

• To confirm a theory
• To explore a relationship

To achieve each of these, the objective should be expressed formally in terms of the hypothesis, and the analysis must address the hypothesis directly.

To confirm a theory

The investigation must be designed to explore the truth of a theory. The theory usually states that the use of a certain method, tool, or technique has a particular effect on the subjects, making it better in some way than another.

There are two cases of data to be considered: normal data and non-normal data.

If the data is from a normal distribution and there are two groups to compare then, the student’s t test can be used for analysis. If there are more than two groups to compare, a general analysis of variance test called F-statistics can be used.

If the data is non-normal, then the data can be analyzed using Kruskal-Wallis test by ranking it.

To explore a relationship

Investigations are designed to determine the relationship among data points describing one variable or multiple variables.

There are three techniques to answer the questions about a relationship: box plots, scatter plots, and correlation analysis.

• A box plot can represent the summary of the range of a set of data.

• A scatter plot represents the relationship between two variables.

• Correlation analysis uses statistical methods to confirm whether there is a true relationship between two attributes.

  • For normally distributed values, use Pearson Correlation Coefficient to check whether or not the two variables are highly correlated.

  • For non- normal data, rank the data and use the Spearman Rank Correlation Coefficient as a measure of association. Another measure for non-normal data is the Kendall robust correlation coefficient, which investigates the relationship among pairs of data points and can identify a partial correlation.

If the ranking contains a large number of tied values, a chi-squared test on a contingency table can be used to test the association between the variables. Similarly, linear regression can be used to generate an equation to describe the relationship between the variables.

For more than two variables, multivariate regression can be used.

Design Considerations

The investigation’s design must be considered while choosing the analysis techniques. At the same time, the complexity of analysis can influence the design chosen. Multiple groups use F-statistics rather than Student’s T-test with two groups.

For complex factorial designs with more than two factors, more sophisticated test of association and significance is needed.

Statistical techniques can be used to account for the effect of one set of variables on others, or to compensate for the timing or learning effects.

Internal product attributes describe the software products in a way that is dependent only on the product itself. The major reason for measuring internal product attributes is that, it will help monitor and control the products during development.

Measuring Internal Product Attributes

The main internal product attributes include size and structure. Size can be measured statically without having to execute them. The size of the product tells us about the effort needed to create it. Similarly, the structure of the product plays an important role in designing the maintenance of the product.

Measuring the Size

Software size can be described with three attributes −

• Length − It is the physical size of the product.

• Functionality − It describes the functions supplied by the product to the user.

• Complexity − Complexity is of different types, such as.

  • Problem complexity − Measures the complexity of the underlying problem.

  • Algorithmic complexity − Measures the complexity of the algorithm implemented to solve the problem

  • Structural complexity − Measures the structure of the software used to implement the algorithm.

  • Cognitive complexity − Measures the effort required to understand the software.

The measurement of these three attributes can be described as follows −

Length

There are three development products whose size measurement is useful for predicting the effort needed for prediction. They are specification, design, and code.

Specification and design

These documents usually combine text, graph, and special mathematical diagrams and symbols. Specification measurement can be used to predict the length of the design, which in turn is a predictor of code length.

The diagrams in the documents have uniform syntax such as labelled digraphs, data-flow diagrams or Z schemas. Since specification and design documents consist of texts and diagrams, its length can be measured in terms of a pair of numbers representing the text length and the diagram length.

For these measurements, the atomic objects are to be defined for different types of diagrams and symbols.

The atomic objects for data flow diagrams are processes, external entities, data stores, and data flows. The atomic entities for algebraic specifications are sorts, functions, operations, and axioms. The atomic entities for Z schemas are the various lines appearing in the specification.

Code

Code can be produced in different ways such as procedural language, object orientation, and visual programming. The most commonly used traditional measure of source code program length is the Lines of code (LOC).

The total length,

LOC = NCLOC + CLOC

i.e.,

LOC = Non-commented LOC + Commented LOC

Apart from the line of code, other alternatives such as the size and complexity suggested by Maurice Halsted can also be used for measuring the length.

Halstead’s software science attempted to capture different attributes of a program. He proposed three internal program attributes such as length, vocabulary, and volume that reflect different views of size.

He began by defining a program P as a collection of tokens, classified by operators or operands. The basic metrics for these tokens were,

• μ₁ = Number of unique operators

• μ₂ = Number of unique operands

• N₁ = Total Occurrences of operators

• N₂ = Number of unique operators

The length P can be defined as

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

The vocabulary of P is

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

The volume of program = No. of mental comparisons needed to write a program of length N, is

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

The program level of a program P of volume V is,

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

Where, $V^\ast$ is the potential volume, i.e., the volume of the minimal size implementation of P

The inverse of level is the difficulty −

$$D = 1\diagup L$$

According to Halstead theory, we can calculate an estimate L as

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

Similarly, the estimated program length is, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

The effort required to generate P is given by,

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

Where the unit of measurement E is elementary mental discriminations needed to understand P

The other alternatives for measuring the length are −

• In terms of the number of bytes of computer storage required for the program text

• In terms of the number of characters in the program text

Object-oriented development suggests new ways to measure length. Pfleeger et al. found that a count of objects and methods led to more accurate productivity estimates than those using lines of code.

Functionality

The amount of functionality inherent in a product gives the measure of product size. There are so many different methods to measure the functionality of software products. We will discuss one such method ─ the Albrecht’s Function Point method ─ in the next chapter.

Function point metrics provide a standardized method for measuring the various functions of a software application. It measures the functionality from the user’s point of view, that is, on the basis of what the user requests and receives in return. Function point analysis is a standard method for measuring software development from the user's point of view.

The Function Point measure originally conceived by Albrecht received increased popularity with the inception of the International Function Point Users Group (IFPUG) in 1986. In 2002, IFPUG Function Points became an international ISO standard – ISO/IEC 20926.

What is a Function Point?

FP (Function Point) is the most widespread functional type metrics suitable for quantifying a software application. It is based on five users identifiable logical "functions", which are divided into two data function types and three transactional function types. For a given software application, each of these elements is quantified and weighted, counting its characteristic elements, such as file references or logical fields.

The resulting numbers (Unadjusted FP) are grouped into Added, Changed, or Deleted functions sets, and combined with the Value Adjustment Factor (VAF) to obtain the final number of FP. A distinct final formula is used for each count type: Application, Development Project, or Enhancement Project.

Applying Albrecht’s Function Point Method

Let us now understand how to apply the Albrecht’s Function Point method. Its procedure is as follows −

Determine the number of components (EI, EO, EQ, ILF, and ELF)

• EI − The number of external inputs. These are elementary processes in which derived data passes across the boundary from outside to inside. In an example library database system, enter an existing patron's library card number.

• EO − The number of external output. These are elementary processes in which derived data passes across the boundary from inside to outside. In an example library database system, display a list of books checked out to a patron.

• EQ − The number of external queries. These are elementary processes with both input and output components that result in data retrieval from one or more internal logical files and external interface files. In an example library database system, determine what books are currently checked out to a patron.

• ILF − The number of internal log files. These are user identifiable groups of logically related data that resides entirely within the applications boundary that are maintained through external inputs. In an example library database system, the file of books in the library.

• ELF − The number of external log files. These are user identifiable groups of logically related data that are used for reference purposes only, and which reside entirely outside the system. In an example library database system, the file that contains transactions in the library's billing system.

Compute the Unadjusted Function Point Count (UFC)

• Rate each component as low, average, or high.

• For transactions (EI, EO, and EQ), the rating is based on FTR and DET.

  • FTR − The number of files updated or referenced.

  • DET − The number of user-recognizable fields.

  • Based on the following table, an EI that references 2 files and 10 data elements would be ranked as average.

FTRs	DETs
	1-5	6-15	>15
0-1	Low	Low	Average
2-3	Low	Average	High
>3	Average	High	High

• For files (ILF and ELF), the rating is based on the RET and DET.

  • RET − The number of user-recognizable data elements in an ILF or ELF.

  • DET − The number of user-recognizable fields.

  • Based on the following table, an ILF that contains 10 data elements and 5 fields would be ranked as high.

RETs	DETs
	1-5	6-15	>15
1	Low	Low	Average
2-5	Low	Average	High
>5	Average	High	High

• Convert ratings into UFCs.

Rating	Values
	EO	EQ	EI	ILF	ELF
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

Compute the Final Function Point Count (FPC)

• Compute value adjustment factor (VAF) based on 14 general system characteristics (GSC).

General System Characteristic		Brief Description
GSC 1	Data communications	How many communication facilities are there to aid in the transfer or exchange of information with the application or system?
GSC 2	Distributed data processing	How are distributed data and processing functions handled?
GSC 3	Performance	Was the response time or throughput required by the user?
GSC 4	Heavily used configuration	How heavily used is the current hardware platform where the application will be executed?
GSC 5	Transaction rate	How frequently are transactions executed daily, weekly, monthly, etc.?
GSC 6	On-Line data entry	What percentage of the information is entered online?
GSC 7	End-user efficiency	Was the application designed for end-user efficiency?
GSC 8	On-Line update	How many ILFs are updated by online transaction?
GSC 9	Complex processing	Does the application have extensive logical or mathematical processing?
GSC 10	Reusability	Was the application developed to meet one or many user’s needs?
GSC 11	Installation ease	How difficult is conversion and installation?
GSC 12	Operational ease	How effective and/or automated are start-up, back-up, and recovery procedures?
GSC 13	Multiple sites	Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?
GSC 14	Facilitate change	Was the application specifically designed, developed, and supported to facilitate change?

• Weigh each GSC on a scale of 0 to 5 based on whether it has no influence to strong influence.

• Compute the FPC as follows −

  FPC = UFC * (0.65+(sum(GSC) * .01))

Complexity

Complexity is a separate component of size. It is of two types −

• Complexity of a problem − It is the amount of resources required for an optimal solution to the problem.

• Complexity of a solution − It is the resources needed to implement a particular solution. It has two aspects. They are as follows −

  • Time complexity − The resource is computer time.

  • Space complexity − The resource is computer memory.

Measuring Complexity

One aspect of complexity is efficiency. It measures any software product that can be modeled as an algorithm.

For example: If an algorithm for solving all instances of a particular problem requires f(n) computations, then f(n) is asymptotically optimal, if for every other algorithm with complexity g that solves the problem f is O(g). Then, the complexity of the given problem is big - O of the asymptotically optimal algorithm for the problem’s solution.

Measurement of structural properties of a software is important for estimating the development effort as well as for the maintenance of the product. The structure of requirements, design, and code helps understand the difficulty that arises in converting one product to another, in testing a product, or in predicting the external software attributes from early internal product measures.

Types of Structural Measures

The structure of software has three parts. They are −

• Control-flow structure − It is the sequence in which instructions are executed in a program.

• Data-flow structure − It is the behavior of the data as it interacts with the program.

• Data structure − It is the organization of the data elements in the form of lists, queue, stacks, or other well-defined structures along with algorithm for creating, modifying, or deleting them.

Measuring Control-Flow Structure

The control flow measures are usually modeled with directed graph, where each node or point corresponds to program statements, and each arc or directed edge indicates the flow of control from one statement to another. Theses graphs are called control-flow graph or directed graph.

If ‘m’ is a structural measure defined in terms of the flow graph model, and if program A is structurally more complex than program B, then the measure m(A) should be greater than m(B).

Measuring Data-Flow Structure

Data flow or information flow can be inter-modular (flow of information within the modules) or intra-modular (flow of information between individual modules and the rest of the system).

According to the way in which data is moving through the system, it can be classified into the following −

• Local direct flow − If either a module invokes a second module and passes information to it or the invoked module returns a result to the caller.

• Local indirect flow − If the invoked module returns information that is subsequently passed to a second invoked module.

• Global flow − If information flows from one module to another through a global data structure.

Information flow complexity can be expressed according to Henry and Kafura as,

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

Where,

• Fan-in (M) − The number of local flows that terminate at M + the number of data structures from which the information is retrieved by M.

• Fan–out (M) − The number of local flows that emanate from M + the number of data structures that are updated by M.

Measuring Data Structure

Data structure can be both local and global.

Locally, the amount of structure in each data item will be measured. A graph-theoretic approach can be used to analyze and measure the properties of individual data structures. In that simple data types such as integers, characters, and Booleans are viewed as primes and the various operations that enable us to build more complex data structures are considered. Data structure measures can then be defined hierarchically in terms of values for the primes and values associated with the various operations.

Globallyระบบจะวัดจำนวนตัวแปรที่ผู้ใช้กำหนดทั้งหมด

สถาบันมาตรฐานระดับชาติและระดับนานาชาติหลายแห่งองค์กรวิชาชีพและองค์กรที่มุ่งเน้นอุตสาหกรรมมีส่วนร่วมในการพัฒนามาตรฐาน SQA

สถาบันและองค์กรต่อไปนี้เป็นผู้พัฒนาหลักของ SQA และมาตรฐานวิศวกรรมซอฟต์แวร์ -

• IEEE (สถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์) Computer Society
• ISO (องค์การระหว่างประเทศเพื่อการมาตรฐาน)
• DOD (กระทรวงกลาโหมสหรัฐฯ)
• ANSI (สถาบันมาตรฐานแห่งชาติของอเมริกา)
• IEC (International Electro Technical Commission)
• EIA (สมาคมอุตสาหกรรมอิเล็กทรอนิกส์)

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

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

นอกจากนี้ยังมีเครื่องมือสำหรับการประเมินตนเองเกี่ยวกับระบบ SQA ขององค์กรและการดำเนินงาน แบบจำลองความสมบูรณ์ของความจุ (CMM) ที่พัฒนาโดยสถาบันวิศวกรรมซอฟต์แวร์ (SEI) มหาวิทยาลัยคาร์เนกีเมลลอนและ ISO / IEC Std 15504 เป็นตัวอย่างของแนวทางนี้

มาตรฐาน SQA

มาตรฐานการประกันคุณภาพซอฟต์แวร์สามารถแบ่งออกเป็นสองประเภทหลัก -

• มาตรฐานการจัดการการประกันคุณภาพซอฟต์แวร์รวมถึงการรับรองและวิธีการประเมิน (มาตรฐานการจัดการคุณภาพ)

• มาตรฐานกระบวนการพัฒนาโครงการซอฟต์แวร์ (มาตรฐานกระบวนการโครงการ)

มาตรฐานการจัดการคุณภาพ

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

Example - ISO 9000-3 และ Capability Maturity Model (CMM)

มาตรฐานกระบวนการโครงการ

สิ่งเหล่านี้มุ่งเน้นไปที่วิธีการในการดำเนินโครงการพัฒนาและบำรุงรักษาซอฟต์แวร์ มาตรฐานเหล่านี้มีดังต่อไปนี้ -

• ขั้นตอนที่จะต้องดำเนินการ
• ข้อกำหนดด้านเอกสารการออกแบบ
• เนื้อหาของเอกสารการออกแบบ
• ออกแบบบทวิจารณ์และตรวจสอบปัญหา
• การทดสอบซอฟต์แวร์ที่จะดำเนินการ
• หัวข้อการทดสอบ

ตามลักษณะของมาตรฐาน SQA จำนวนมากในคลาสนี้สามารถใช้เป็นมาตรฐานวิศวกรรมซอฟต์แวร์และในทางกลับกัน

คุณลักษณะของมาตรฐานทั้งสองประเภทนี้สรุปได้ในตารางต่อไปนี้

ลักษณะเฉพาะ	มาตรฐานการจัดการคุณภาพ	มาตรฐานกระบวนการโครงการ
หน่วยเป้าหมาย	การจัดการการพัฒนาซอฟต์แวร์การบำรุงรักษาและหน่วย SQA เฉพาะ	ทีมโครงการพัฒนาและบำรุงรักษาซอฟต์แวร์
เน้นหลัก	การจัดระบบ SQA โครงสร้างพื้นฐานและข้อกำหนด	ระเบียบวิธีในการดำเนินโครงการพัฒนาและบำรุงรักษาซอฟต์แวร์
วัตถุประสงค์ของมาตรฐาน	“ อะไร” ที่จะบรรลุ	“ วิธีการ” ดำเนินการ
เป้าหมายของมาตรฐาน	การรับรองคุณภาพซอฟต์แวร์ของซัพพลายเออร์และการประเมินความสามารถของกระบวนการซอฟต์แวร์	การตรวจสอบคุณภาพซอฟต์แวร์ของซัพพลายเออร์และการประเมินความสามารถของกระบวนการซอฟต์แวร์การรับรองคุณภาพของโครงการซอฟต์แวร์เฉพาะ
ตัวอย่าง	CMM ของ ISO 9000-3 SEI	ISO / IEC 12207 IEEEStd 1012-1998

การรับรอง ISO 9001

ISO (องค์การระหว่างประเทศเพื่อการมาตรฐาน) เป็นสหพันธ์ทั่วโลกของหน่วยงานมาตรฐานแห่งชาติ คณะกรรมการด้านเทคนิคของ ISO จัดทำมาตรฐานสากล ISO ร่วมมืออย่างใกล้ชิดกับ International Electro-technical Commission (IEC) ในทุกเรื่องของมาตรฐานทางเทคนิคไฟฟ้า

มาตรฐานสากลได้รับการร่างตามกฎที่กำหนดไว้ในคำสั่ง ISO / IEC ส่วนที่ 2 ร่างมาตรฐานสากลที่คณะกรรมการด้านเทคนิคนำมาใช้จะถูกส่งไปยังองค์กรสมาชิกเพื่อลงคะแนนเสียง ISO 9001 จัดทำโดยคณะกรรมการด้านเทคนิค ISO / TC 176 การจัดการคุณภาพและการประกันคุณภาพอนุกรรมการ SC 2 ระบบคุณภาพ

แนวทางกระบวนการ

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

บ่อยครั้งผลลัพธ์จากกระบวนการหนึ่งจะสร้างอินพุตไปยังกระบวนการถัดไปโดยตรง การประยุกต์ใช้ระบบของกระบวนการภายในองค์กรร่วมกับการระบุและปฏิสัมพันธ์ของกระบวนการเหล่านี้และการจัดการเพื่อให้ได้ผลลัพธ์ที่ต้องการสามารถเรียกได้ว่า“process approach”.

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

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

ISO 9001 - การประยุกต์ใช้กับซอฟต์แวร์: TickIT Initiative

TickIT เปิดตัวในช่วงปลายทศวรรษ 1980 โดยอุตสาหกรรมซอฟต์แวร์ของสหราชอาณาจักรโดยร่วมมือกับกระทรวงการค้าและอุตสาหกรรมแห่งสหราชอาณาจักรเพื่อส่งเสริมการพัฒนาวิธีการในการปรับ ISO 9001 ให้เข้ากับลักษณะของอุตสาหกรรมซอฟต์แวร์ที่เรียกว่าการริเริ่มของ TickIT

TickIT เป็นผู้เชี่ยวชาญด้านเทคโนโลยีสารสนเทศ (IT) ครอบคลุมบริการพัฒนาและบำรุงรักษาซอฟต์แวร์เชิงพาณิชย์ทั้งหมด ขณะนี้ TickIT ได้รับการจัดการและดูแลโดย DISC Department of BSI (British Standards Institute) ได้รับการรับรองการรับรององค์กรไอทีในสหราชอาณาจักรและสวีเดน

กิจกรรมประกอบด้วย -

• การเผยแพร่ TickIT Guide ซึ่งสนับสนุนความพยายามของอุตสาหกรรมซอฟต์แวร์ในการเผยแพร่การรับรอง ISO 9001 คู่มือฉบับปัจจุบัน (ฉบับ 5.0, TickIT, 2001) ซึ่งรวมถึงการอ้างอิงถึง ISO / IEC 12207 และ ISO / IEC 15504 แจกจ่ายให้กับลูกค้า TickIT ทั้งหมด

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

• ดำเนินการตรวจสอบการรับรอง ISO 9000

ผู้ตรวจสอบของ TickIT ที่ดำเนินการประเมินตามการตรวจสอบและการตรวจสอบการรับรองได้รับการลงทะเบียนโดย International Register of Certificated Auditors (IRCA) ผู้ตรวจสอบบัญชี IRCA ที่ลงทะเบียนจำเป็นต้องมีประสบการณ์ในการบริหารจัดการและการพัฒนาซอฟต์แวร์ พวกเขาจะต้องสำเร็จหลักสูตรผู้สอบบัญชีด้วย

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

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

การประเมินซอฟต์แวร์ (หรือการตรวจสอบ) สามารถมีได้สามประเภท

• ก self-assessment (first-party assessment) ดำเนินการภายในโดยบุคลากรขององค์กรเอง

• ก second-party assessment ดำเนินการโดยทีมประเมินภายนอกหรือองค์กรได้รับการประเมินโดยลูกค้า

• ก third-party assessment ดำเนินการโดยบุคคลภายนอกหรือ (เช่นซัพพลายเออร์ที่ได้รับการประเมินโดยบุคคลที่สามเพื่อตรวจสอบความสามารถในการทำสัญญากับลูกค้า)

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

การประเมินความสมบูรณ์ของกระบวนการซอฟต์แวร์

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

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

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

• แม้ว่าจะอยู่ในองค์กรเดียวกัน แต่ตัวอย่างของโครงการที่เลือกเพื่อเป็นตัวแทนขององค์กรอาจส่งผลต่อขอบเขตและผลลัพธ์

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

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

วงจรการประเมินกระบวนการซอฟต์แวร์

ตามที่ Paulk และเพื่อนร่วมงาน (1995) แนวทางการประเมินตาม CMM ใช้วงจร 6 ขั้นตอน พวกเขาคือ -

• เลือกทีม - สมาชิกในทีมควรเป็นมืออาชีพที่มีความรู้ด้านวิศวกรรมซอฟต์แวร์และการจัดการ

• ตัวแทนของไซต์ที่จะประเมินจะต้องกรอกแบบสอบถามความเหมาะสมของกระบวนการมาตรฐาน

• ทีมประเมินจะทำการวิเคราะห์คำตอบของแบบสอบถามและระบุพื้นที่ที่รับประกันการสำรวจเพิ่มเติมตามขั้นตอนสำคัญของ CMM

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

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

• ทีมประเมินเตรียมการวิเคราะห์โปรไฟล์ Key Process Area (KPA) และนำเสนอผลลัพธ์ต่อผู้ชมที่เหมาะสม

ตัวอย่างเช่นทีมประเมินต้องนำโดยผู้ประเมินลูกค้าเป้าหมาย SEI ที่ได้รับอนุญาต ทีมต้องประกอบด้วยสมาชิกในทีมระหว่างสี่ถึงสิบคน อย่างน้อยสมาชิกในทีมหนึ่งคนต้องมาจากองค์กรที่ได้รับการประเมินและสมาชิกในทีมทุกคนต้องสำเร็จหลักสูตร Introduction to the CMM ของ SEI (หรือเทียบเท่า) และหลักสูตรการฝึกอบรมทีม CBA IPI ของ SEI สมาชิกในทีมต้องมีคุณสมบัติตรงตามแนวทางการคัดเลือกบางประการ

เกี่ยวกับการรวบรวมข้อมูล CBA IPI อาศัยสี่วิธี -

• แบบสอบถามวุฒิภาวะมาตรฐาน
• การสัมภาษณ์รายบุคคลและกลุ่ม
• การตรวจสอบเอกสาร
• ข้อเสนอแนะจากการตรวจสอบข้อค้นพบฉบับร่างกับผู้เข้าร่วมการประเมิน

SCAMPI

วิธีการประเมินมาตรฐาน CMMI สำหรับการปรับปรุงกระบวนการ (SCAMPI) ได้รับการพัฒนาเพื่อให้เป็นไปตามข้อกำหนดของโมเดล CMMI (Software Engineering Institute, 2000) นอกจากนี้ยังขึ้นอยู่กับ CBA IPI ทั้ง CBA IPI และ SCAMPI ประกอบด้วยสามเฟส -

• วางแผนและเตรียมการ
• ดำเนินการประเมินนอกสถานที่
• รายงานผล

กิจกรรมสำหรับแผนและขั้นตอนการเตรียมการ ได้แก่ -

• ระบุขอบเขตการประเมิน
• พัฒนาแผนการประเมิน
• เตรียมและฝึกอบรมทีมประเมิน
• ทำการประเมินผู้เข้าร่วมโดยย่อ
• จัดการแบบสอบถามการประเมิน CMMI
• ตรวจสอบคำตอบของแบบสอบถาม
• ดำเนินการตรวจสอบเอกสารเบื้องต้น

กิจกรรมสำหรับขั้นตอนการประเมินนอกสถานที่ ได้แก่ -

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

กิจกรรมของระยะผลการรายงาน ได้แก่ -

• นำเสนอข้อค้นพบขั้นสุดท้าย
• ดำเนินการประชุมผู้บริหาร
• สรุปการประเมิน

คำจำกัดความของ IEEE สำหรับการประกันคุณภาพซอฟต์แวร์มีดังต่อไปนี้ -

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

วัตถุประสงค์ของกิจกรรม SQA

วัตถุประสงค์ของกิจกรรม SQA มีดังนี้ -

ในการพัฒนาซอฟต์แวร์ (เน้นกระบวนการ)

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

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

• การริเริ่มและจัดการกิจกรรมเพื่อการปรับปรุงและประสิทธิภาพที่ดีขึ้นของการพัฒนาซอฟต์แวร์และกิจกรรม SQA

ในการบำรุงรักษาซอฟต์แวร์ (เน้นผลิตภัณฑ์)

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

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

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

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

กรอบองค์กรด้านการประกันคุณภาพที่ดำเนินการภายในโครงสร้างองค์กรประกอบด้วยผู้เข้าร่วมดังต่อไปนี้ -

ผู้จัดการ

• ผู้บริหารระดับสูงโดยเฉพาะผู้บริหารโดยตรงที่รับผิดชอบด้านการประกันคุณภาพซอฟต์แวร์

• ผู้จัดการแผนกพัฒนาและบำรุงรักษาซอฟต์แวร์

• ผู้จัดการแผนกทดสอบซอฟต์แวร์

• ผู้จัดการโครงการและหัวหน้าทีมของโครงการพัฒนาและบำรุงรักษา

• ผู้นำทีมทดสอบซอฟต์แวร์

ผู้ทดสอบ

• สมาชิกของทีมทดสอบซอฟต์แวร์

ผู้เชี่ยวชาญด้าน SQA และผู้ปฏิบัติงานที่สนใจ -

• ผู้ดูแล SQA
• สมาชิกคณะกรรมการ SQA
• สมาชิกฟอรัม SQA
• สมาชิกในทีมหน่วย SQA

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

โดยพื้นฐานแล้วโครงสร้างการจัดการสามระดับมีอยู่ในองค์กรพัฒนาซอฟต์แวร์ -

• ผู้บริหารระดับสูง
• การจัดการแผนก
• การจัดการโครงการ

ความรับผิดชอบของผู้บริหารสูงสุดในคุณภาพซอฟต์แวร์

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

• รับประกันคุณภาพของผลิตภัณฑ์ซอฟต์แวร์ของ บริษัท และบริการบำรุงรักษาซอฟต์แวร์

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

• รับประกันการทำงานที่น่าพอใจและปฏิบัติตามข้อกำหนดของลูกค้าอย่างเต็มที่

• ตรวจสอบให้แน่ใจว่ามีการกำหนดวัตถุประสงค์คุณภาพสำหรับระบบ SQA ขององค์กรและบรรลุวัตถุประสงค์

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

• แทรกแซงโดยตรงเพื่อสนับสนุนการแก้ไขสถานการณ์วิกฤตและลดความเสียหายให้น้อยที่สุด

• ตรวจสอบความพร้อมของทรัพยากรที่ระบบ SQA ต้องการ

ผู้บริหารระดับสูงสามารถดำเนินการตามขั้นตอนต่อไปนี้เพื่อปฏิบัติตามความรับผิดชอบ -

• การกำหนดและปรับปรุงนโยบายคุณภาพซอฟต์แวร์ขององค์กร

• มอบหมายให้ผู้บริหารคนใดคนหนึ่งเช่นรองประธานของ SQA เป็นผู้ดูแลปัญหาคุณภาพซอฟต์แวร์

• ดำเนินการตรวจสอบประสิทธิภาพของฝ่ายจัดการอย่างสม่ำเสมอเกี่ยวกับปัญหาด้านคุณภาพซอฟต์แวร์

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

นโยบายคุณภาพซอฟต์แวร์ขององค์กรควรสื่อสารถึงข้อกำหนดต่อไปนี้ -

• สอดคล้องกับวัตถุประสงค์และเป้าหมายขององค์กร

• ความมุ่งมั่นในแนวคิดการประกันคุณภาพซอฟต์แวร์ทั่วไป

• ความมุ่งมั่นในมาตรฐานคุณภาพที่นำมาใช้โดยองค์กร

• มุ่งมั่นที่จะจัดสรรทรัพยากรที่เพียงพอสำหรับการประกันคุณภาพซอฟต์แวร์

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

ผู้บริหารที่รับผิดชอบด้านคุณภาพซอฟต์แวร์

ความรับผิดชอบของผู้บริหารที่รับผิดชอบปัญหาคุณภาพซอฟต์แวร์อาจแบ่งได้เป็น -

• ความรับผิดชอบในการจัดทำโครงการกิจกรรม SQA ประจำปีและงบประมาณ

• ความรับผิดชอบในการจัดทำแผนพัฒนาระบบ SQA

• การควบคุมโดยรวมของการดำเนินโครงการกิจกรรมประจำปีของ SQA และโครงการพัฒนา SQA ที่วางแผนไว้

• การนำเสนอและการสนับสนุนประเด็น SQA ต่อผู้บริหารระดับสูง

ความรับผิดชอบในการจัดทำโครงการกิจกรรม SQA ประจำปี

สิ่งนี้ต้องการให้ผู้บริหาร -

• กำหนดวัตถุประสงค์ SQA ของระบบสำหรับปีหน้า

• ตรวจสอบข้อเสนอที่จัดทำโดยหน่วย SQA สำหรับโครงการกิจกรรมประจำปีและตรวจสอบศักยภาพของข้อเสนอเพื่อบรรลุวัตถุประสงค์ที่กำหนดไว้สำหรับระบบ SQA

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

• กำหนดความเพียงพอของกำลังคนและทรัพยากรอื่น ๆ ที่วางแผนไว้สำหรับการดำเนินการตามโปรแกรม SQA

• อนุมัติเวอร์ชันสุดท้ายของโครงการกิจกรรม SQA ประจำปีและงบประมาณ

ความรับผิดชอบในการจัดทำแผนพัฒนาระบบ SQA

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

• การทบทวนแนวโน้มที่คาดว่าจะส่งผลต่อคุณภาพซอฟต์แวร์ขององค์กรในอนาคตอันใกล้

• ทบทวนข้อเสนอสำหรับการปรับ SQA เช่นการจัดทำขั้นตอนใหม่ที่เหมาะสมกับเครื่องมือใหม่และมาตรฐาน SQA

• การเตรียมโปรแกรมการฝึกอบรมสำหรับทีมพัฒนาซอฟต์แวร์ที่มีประสบการณ์และสมาชิกในทีมที่ได้รับคัดเลือกใหม่

• การพัฒนาเมตริกคุณภาพซอฟต์แวร์ที่เหมาะสมสำหรับการประเมินเครื่องมือและมาตรฐานใหม่ตลอดจนความสำเร็จของโปรแกรมการฝึกอบรม

• การอนุมัติเวอร์ชันสุดท้ายของโครงการพัฒนา SQA ที่วางแผนไว้รวมถึงกำหนดการและงบประมาณ

การควบคุมโดยรวมของการดำเนินการตามโปรแกรม SQA ประจำปี

ผู้บริหารมีหน้าที่รับผิดชอบ -

• การกำกับดูแลทั่วไปของโครงการกิจกรรมประจำปี

• ทบทวนความคืบหน้าของโครงการปรับ SQA

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

• ทบทวนการปฏิบัติตามขั้นตอนและมาตรฐาน SQA ตามการตรวจสอบคุณภาพภายใน

• การติดตามทั่วไปของการปฏิบัติตามกำหนดการและงบประมาณของโครงการพัฒนาซอฟต์แวร์

• การติดตามทั่วไปของการให้บริการบำรุงรักษาคุณภาพแก่ลูกค้าภายนอกและภายใน

การนำเสนอและการสนับสนุนประเด็น SQA ต่อผู้บริหาร

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

• การนำเสนอเพื่อขออนุมัติขั้นสุดท้ายของโครงการกิจกรรมประจำปีและงบประมาณที่เสนอ

• การนำเสนอเพื่อขออนุมัติขั้นสุดท้ายของโครงการปรับ SQA ที่วางแผนไว้พร้อมกับงบประมาณที่เกี่ยวข้อง

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

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

ความรับผิดชอบของฝ่ายบริหารสำหรับ SQA

ความรับผิดชอบในการประกันคุณภาพของผู้บริหารระดับกลาง ได้แก่ -

• การจัดการระบบการจัดการคุณภาพซอฟต์แวร์ (งานที่เกี่ยวข้องกับระบบคุณภาพ)

• การจัดการงานที่เกี่ยวข้องกับโครงการและบริการที่ดำเนินการโดยหน่วยงานหรือทีมภายใต้อำนาจของผู้จัดการเฉพาะ (งานที่เกี่ยวข้องกับโครงการ)

ความรับผิดชอบที่เกี่ยวข้องกับระบบคุณภาพ

ซึ่งรวมถึงกิจกรรม SQA ที่จะดำเนินการในระดับแผนก -

• การจัดทำโครงการและงบประมาณกิจกรรม SQA ประจำปีของแผนกตามโปรแกรมแนะนำที่จัดทำโดยหน่วย SQA

• การจัดทำแผนพัฒนาระบบ SQA ของแผนกตามแผนแนะนำที่จัดทำโดยหน่วย SQA

• การควบคุมการปฏิบัติงานของโครงการกิจกรรม SQA ประจำปีและโครงการพัฒนาของแผนก

• การนำเสนอประเด็น SQA ของแผนกต่อผู้บริหารระดับสูง

ความรับผิดชอบที่เกี่ยวข้องกับโครงการ

สิ่งเหล่านี้แตกต่างกันไปตามขั้นตอนขององค์กรและการกระจายอำนาจ พวกเขามักจะเกี่ยวข้องกับ -

• การควบคุมการปฏิบัติตามขั้นตอนการประกันคุณภาพในหน่วยงานของแผนกรวมถึงหน่วยงาน CAB, SCM และ SCCA

• การติดตามผลการตรวจสอบสัญญาโดยละเอียดและการอนุมัติข้อเสนอ

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

• การติดตามผลการทดสอบซอฟต์แวร์และผลการทดสอบ การอนุมัติผลิตภัณฑ์ซอฟต์แวร์ของโครงการ

• การติดตามความคืบหน้าของกำหนดการโครงการพัฒนาซอฟต์แวร์และการเบี่ยงเบนงบประมาณ

• คำแนะนำและการสนับสนุนแก่ผู้จัดการโครงการในการแก้ไขปัญหากำหนดการงบประมาณและความสัมพันธ์กับลูกค้า

• การติดตามคุณภาพของการให้บริการบำรุงรักษา

• การติดตามความเสี่ยงของโครงการโดยละเอียดและแนวทางแก้ไข

• ติดตามการปฏิบัติตามโครงการตามความต้องการของลูกค้าและความพึงพอใจของลูกค้า

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

ความรับผิดชอบในการจัดการโครงการเกี่ยวกับคุณภาพซอฟต์แวร์

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

งานของเขารวมถึงงานในมือและงานบริหารมืออาชีพโดยเฉพาะอย่างยิ่งต่อไปนี้ -

• Professional hands-on tasks

  • การจัดทำโครงการและแผนคุณภาพและการปรับปรุง

  • การมีส่วนร่วมในคณะกรรมการลูกค้าและซัพพลายเออร์ร่วมกัน

  • การติดตามอย่างใกล้ชิดของทีมงานโครงการรวมถึงการเข้าร่วมการสรรหาการฝึกอบรมและการสอน

• Management tasks

  ผู้จัดการโครงการแก้ไขปัญหาการติดตามเช่น -

  • ประสิทธิภาพของกิจกรรมการทบทวนและการแก้ไขผลที่ตามมา

  • การพัฒนาซอฟต์แวร์และกิจกรรมการทดสอบประสิทธิภาพการรวมและระบบของหน่วยการพัฒนาซอฟต์แวร์และการบำรุงรักษาตลอดจนการแก้ไขและการทดสอบการถดถอย

  • ประสิทธิภาพของการทดสอบการยอมรับ

  • การติดตั้งซอฟต์แวร์ในไซต์ของลูกค้าระยะไกลและการดำเนินการของระบบซอฟต์แวร์โดยลูกค้า

  • การฝึกอบรม SQA และคำแนะนำของสมาชิกในทีมโครงการ

  • กำหนดการและทรัพยากรที่จัดสรรให้กับกิจกรรมโครงการ

  • คำขอและความพึงพอใจของลูกค้า

  • การพัฒนาความเสี่ยงในการพัฒนาโครงการการประยุกต์ใช้แนวทางแก้ไขและการควบคุมผลลัพธ์

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

งานที่ดำเนินการโดยหัวหน้าหน่วย SQA

หัวหน้าหน่วย SQA รับผิดชอบงานประกันคุณภาพทั้งหมดที่ดำเนินการโดยหน่วย SQA และหน่วยย่อย งานเหล่านี้สามารถแบ่งออกเป็นประเภทต่อไปนี้ -

• การวางแผนงาน
• การจัดการหน่วย
• กิจกรรมระดับมืออาชีพของ SQA

งานการวางแผน

• การจัดทำโครงการกิจกรรมประจำปีและงบประมาณของหน่วย

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

• การจัดทำโปรแกรมกิจกรรม SQA ประจำปีที่แนะนำและแผนการพัฒนาระบบ SQA สำหรับแผนกพัฒนาและบำรุงรักษาซอฟต์แวร์

งานการจัดการ

• การจัดการกิจกรรมของทีม SQA

• การตรวจสอบการใช้งานโปรแกรมกิจกรรม SQA

• การเสนอชื่อสมาชิกในทีมสมาชิกคณะกรรมการ SQA และผู้ดูแล SQA

• การจัดทำรายงานพิเศษและเป็นระยะเช่นสถานะของปัญหาคุณภาพซอฟต์แวร์ภายในองค์กรและรายงานผลการดำเนินงานประจำเดือน

SQA กิจกรรมระดับมืออาชีพ

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

โครงการ Life Cycle SQA

งาน SQA ที่เกี่ยวข้องกับหน่วยย่อยของวงจรชีวิตของโครงการอาจแบ่งได้เป็นสองกลุ่ม -

• งานติดตามและอนุมัติการจัดการ "บริสุทธิ์" (งานควบคุมวงจรชีวิตของโครงการ)

• “ ลงมือปฏิบัติ” หรือการมีส่วนร่วมอย่างแข็งขันในกิจกรรม SQA ของทีมโครงการซึ่งจำเป็นต้องมีการช่วยเหลืออย่างมืออาชีพ

งานควบคุมวงจรชีวิตของโครงการ

• การติดตามการปฏิบัติตามข้อกำหนดของทีมพัฒนาและการบำรุงรักษาตามขั้นตอน SQA และคำแนะนำในการทำงาน

• การอนุมัติหรือแนะนำผลิตภัณฑ์ซอฟต์แวร์ตามขั้นตอนที่เกี่ยวข้อง

• ตรวจสอบการส่งมอบบริการบำรุงรักษาซอฟต์แวร์ให้กับลูกค้าภายในและภายนอก

• ติดตามความพึงพอใจของลูกค้าและรักษาการติดต่อกับตัวแทนประกันคุณภาพของลูกค้า

งานการมีส่วนร่วม

งานเหล่านี้รวมถึงการมีส่วนร่วมใน -

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

งานปฏิบัติการโครงสร้างพื้นฐาน SQA

ระบบ SQA ใช้ส่วนประกอบโครงสร้างพื้นฐานที่หลากหลายเพื่อให้ทำงานได้อย่างราบรื่น ได้แก่ -

• ขั้นตอนและคำแนะนำในการทำงาน
• รองรับอุปกรณ์คุณภาพ (เทมเพลตรายการตรวจสอบ)
• การฝึกอบรมพนักงานคำแนะนำและการรับรอง
• ปฏิบัติการป้องกันและแก้ไข
• การจัดการการตั้งค่า
• การควบคุมเอกสาร

โดยเฉพาะอย่างยิ่งงานของหน่วยย่อย SQA เกี่ยวกับส่วนประกอบเหล่านี้ ได้แก่ -

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

• การส่งการฝึกอบรมและคำแนะนำเกี่ยวกับการปฏิบัติตามและการประยุกต์ใช้ขั้นตอน SQA คำแนะนำในการทำงานและสิ่งที่คล้ายกันไปยังพนักงานใหม่และปัจจุบัน

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

• การติดตามและสนับสนุนการดำเนินการตามขั้นตอน SQA ใหม่และที่ปรับปรุงใหม่

• การติดตามกิจกรรมการรับรองพนักงาน

• ข้อเสนอของหัวข้อที่ต้องดำเนินการป้องกันและแก้ไขรวมถึงการมีส่วนร่วมในคณะกรรมการ CAB

• การติดตามกิจกรรมการจัดการการกำหนดค่ารวมถึงการมีส่วนร่วมในคณะกรรมการ CCA

• ติดตามการปฏิบัติตามขั้นตอนเอกสารและคำแนะนำในการทำงาน

งานตรวจสอบและรับรองภายใน SQA

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

• การตรวจสอบภายใน

• การตรวจสอบผู้รับเหมาช่วงและซัพพลายเออร์เพื่อประเมินระบบ SQA

• การตรวจสอบภายนอกดำเนินการโดยหน่วยงานรับรอง

• การตรวจสอบภายนอกดำเนินการโดยลูกค้าที่ต้องการประเมินระบบ SQA ก่อนที่จะยอมรับองค์กรเป็นซัพพลายเออร์

การตรวจสอบสองคลาสแรกเริ่มต้นและดำเนินการโดยหน่วยย่อย SQA สองคลาสสุดท้ายโดยหน่วยงานภายนอก

หน่วย SQA ทำหน้าที่ต่อไปนี้สำหรับการตรวจสอบ SQA ภายใน

• การจัดทำโปรแกรมประจำปีสำหรับการตรวจสอบ SQA ภายใน

• ประสิทธิภาพของการตรวจสอบ SQA ภายใน

• การติดตามการแก้ไขและการปรับปรุงที่จะดำเนินการโดยทีมตรวจสอบและหน่วยงานอื่น ๆ

• การจัดทำรายงานสรุปสถานะของผลการตรวจประเมินเป็นระยะ ๆ รวมถึงคำแนะนำสำหรับการปรับปรุง

หน่วย SQA ทำหน้าที่ดังต่อไปนี้สำหรับการตรวจสอบผู้รับเหมาช่วงและซัพพลายเออร์ -

• การจัดทำโปรแกรมประจำปีสำหรับการตรวจสอบ SQA ของผู้รับเหมาช่วงและซัพพลายเออร์

• ประสิทธิภาพของการตรวจสอบ SQA ของผู้รับเหมาช่วงและซัพพลายเออร์

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

• การรวบรวมข้อมูลเกี่ยวกับประสิทธิภาพของผู้รับเหมาช่วงและซัพพลายเออร์จากแหล่งภายในและภายนอก

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

  • คำแนะนำเกี่ยวกับการรับรองผู้รับเหมาช่วงและซัพพลายเออร์

  • การตรวจสอบภายนอกที่ดำเนินการโดยหน่วยงานรับรองเกี่ยวข้องกับงานต่อไปนี้ -

    • การประสานงานเนื้อหาและกำหนดการของการตรวจสอบการรับรอง

    • การเตรียมเอกสารที่หน่วยรับรองกำหนด

    • คำแนะนำของทีมตรวจสอบและประสิทธิภาพของการเตรียมการที่จำเป็นสำหรับการตรวจสอบการรับรอง

    • การมีส่วนร่วมในการตรวจสอบการรับรอง

    • ตรวจสอบให้แน่ใจว่ามีการแก้ไขและปรับปรุงที่จำเป็น

การตรวจสอบ SQA ที่ดำเนินการโดยลูกค้าขององค์กรทำให้เกิดงานเหล่านี้ -

• การประสานงานเนื้อหาและกำหนดการของการตรวจสอบ

• การเตรียมเอกสารที่กำหนดโดยผู้สอบบัญชีของลูกค้า

• คำแนะนำของทีมตรวจสอบและประสิทธิภาพของการเตรียมการที่จำเป็นสำหรับการตรวจสอบ SQA โดยลูกค้าขององค์กร

• การมีส่วนร่วมในการตรวจสอบ

• ตรวจสอบให้แน่ใจว่าได้ดำเนินการแก้ไขและปรับปรุงที่จำเป็นแล้ว

งานสนับสนุน SQA

ผู้บริโภคส่วนใหญ่ของบริการสนับสนุน SQA ตั้งอยู่ภายในองค์กร ซึ่งรวมถึงผู้จัดการโครงการหัวหน้าทีมและผู้ดูแล SQA งานของพวกเขา ได้แก่ -

• การจัดทำแผนงานโครงการและแผนคุณภาพโครงการ

• ทีมตรวจสอบพนักงาน

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

• ทางเลือกของมาตรการเพื่อแก้ไขความล่าช้าของกำหนดการและการใช้จ่ายเกินงบประมาณ

• การเลือกเมตริก SQA และองค์ประกอบต้นทุนซอฟต์แวร์

• การใช้ระบบสารสนเทศ SQA

• การเลือกวิธีการพัฒนาและเครื่องมือที่สะท้อนข้อมูลประสบการณ์ความล้มเหลวที่สะสมโดยหน่วย SQA

งานมาตรฐานและขั้นตอน SQA

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

• จัดทำโปรแกรมประจำปีสำหรับการพัฒนาขั้นตอนใหม่และการปรับปรุงขั้นตอน

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

• ติดตามการพัฒนาและการเปลี่ยนแปลงใน SQA และมาตรฐานวิศวกรรมซอฟต์แวร์ การแนะนำขั้นตอนเพิ่มเติมและการเปลี่ยนแปลงที่เกี่ยวข้องกับองค์กร

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

งานวิศวกรรม SQA

การติดตามความก้าวหน้าทางวิชาชีพการแก้ปัญหาในการปฏิบัติงานและการวิเคราะห์ความล้มเหลวโดยผู้เชี่ยวชาญเป็นวัตถุประสงค์เฉพาะของหน่วยย่อย SQA นี้

ดังนั้นงานวิศวกรรมหลักจึงเกี่ยวข้องกับสิ่งต่อไปนี้ -

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

• การประเมินคุณภาพและผลผลิตของการพัฒนาวิธีการบำรุงรักษาใหม่และการปรับปรุงวิธีการ

• การพัฒนาวิธีแก้ปัญหาที่ต้องเผชิญในการประยุกต์ใช้เครื่องมือและวิธีการพัฒนาซอฟต์แวร์ที่ใช้อยู่ในปัจจุบัน

• การพัฒนาวิธีการวัดคุณภาพซอฟต์แวร์และประสิทธิผลของทีม

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

งานระบบสารสนเทศ SQA

ระบบสารสนเทศ SQA มีขึ้นเพื่ออำนวยความสะดวกและปรับปรุงการทำงานของระบบ SQA งานที่เกี่ยวข้อง ได้แก่ -

• การพัฒนาระบบสารสนเทศ SQA สำหรับหน่วยพัฒนาและบำรุงรักษาซอฟต์แวร์สำหรับ

  • การรวบรวมข้อมูลกิจกรรม

  • การประมวลผลเช่นรายงานประจำงวดรายการรายงานข้อยกเว้นและแบบสอบถาม

  • การประมวลผลเช่นรายงานประจำงวดรายการรายงานข้อยกเว้นและแบบสอบถาม

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

• การอัปเดตระบบข้อมูล SQA

• การพัฒนาและบำรุงรักษาไซต์ SQA Internet / Intranet ขององค์กร

SQA Trustees และงานของพวกเขา

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

งานของพวกเขาอาจแตกต่างกันไปขึ้นอยู่กับองค์กร ดังนั้นอาจเป็นงานที่เกี่ยวข้องกับหน่วยและ / หรืองานที่เกี่ยวข้องกับองค์กร

งานที่เกี่ยวข้องกับหน่วย

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

• ช่วยผู้จัดการหน่วยในการดำเนินงาน SQA ที่เกี่ยวข้อง

• ส่งเสริมการปฏิบัติตามและตรวจสอบการปฏิบัติตามขั้นตอน SQA และคำแนะนำในการทำงานของเพื่อนร่วมงาน

• รายงานเหตุการณ์การไม่ปฏิบัติตามที่เป็นระบบและเป็นระบบไปยังหน่วย SQA

• รายงานความล้มเหลวอย่างรุนแรงของคุณภาพซอฟต์แวร์ไปยังหน่วย SQA

งานที่เกี่ยวข้องกับองค์กร

• ทริกเกอร์การเปลี่ยนแปลงและการปรับปรุงขั้นตอน SQA ทั่วทั้งองค์กรและคำแนะนำในการทำงาน

• กระตุ้นการปรับปรุงกระบวนการพัฒนาและการบำรุงรักษาในองค์กร

• เริ่มต้นแอปพลิเคชันไปยัง CAB เกี่ยวกับวิธีแก้ไขความล้มเหลวที่เกิดขึ้นซ้ำที่พบในหน่วยที่เกี่ยวข้อง

• ระบุความต้องการการฝึกอบรม SQA ทั่วทั้งองค์กรและเสนอการฝึกอบรมหรือโปรแกรมการสอนที่เหมาะสมที่จะดำเนินการโดยหน่วย SQA

คณะกรรมการ SQA และงานของพวกเขา

คณะกรรมการ SQA สามารถเป็นได้ทั้งแบบถาวรหรือแบบเฉพาะกิจ งานอาจแตกต่างกันไปมากในแต่ละองค์กร

• Permanent committees โดยทั่วไปจะจัดการกับ SCC (Software Change Control), CA (Corrective Actions), ขั้นตอน, เครื่องมือในการพัฒนาวิธีการและเมตริกคุณภาพ

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

คณะกรรมการ SQA ถาวรเป็นส่วนสำคัญของกรอบองค์กร SQA โดยปกติงานและการดำเนินการของพวกเขาจะถูกกำหนดไว้ในขั้นตอน SQA ขององค์กร

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