ฉันจะขอนำเสนอสิ่งนี้ด้วยความจริงที่ว่าสิ่งที่ฉันค้นพบส่วนใหญ่มาจากปี 1970 และต้นปี 1980 ในช่วงเวลานี้แบบจำลองกระบวนการต่อเนื่องนั้นพบได้บ่อยกว่าวิธีแบบวนซ้ำและ / หรือแบบเพิ่มขึ้น งานส่วนใหญ่นี้สร้างขึ้นจากโมเดลตามลำดับ อย่างไรก็ตามฉันไม่คิดว่าจะทำลายความสัมพันธ์ แต่หนึ่งในข้อดีของวิธีการวนซ้ำ / การเพิ่มขึ้นคือการปล่อยคุณลักษณะ (การแบ่งส่วนแนวตั้งทั้งหมดของแอปพลิเคชัน) อย่างรวดเร็วและแก้ไขปัญหาก่อนที่จะพึ่งพาการฉีดและความซับซ้อนของแต่ละเฟส สูง
ฉันเพิ่งดึงสำเนาเศรษฐศาสตร์วิศวกรรมซอฟต์แวร์ของฉันออกมาและพบการอ้างอิงถึงข้อมูลที่อยู่เบื้องหลังแผนภูมินี้ในบทที่ 4 เขาอ้างถึง "การออกแบบและการตรวจสอบโค้ดเพื่อลดข้อผิดพลาดในการพัฒนาโปรแกรม" โดย ME Fagan ( IEEE , PDF จาก UMD ), EB "การจัดการวิศวกรรมซอฟต์แวร์" ของ Daly เรา WE Stephenson "การวิเคราะห์ทรัพยากรที่ใช้ในการพัฒนาซอฟต์แวร์ระบบป้องกัน" ( ACM ) และ "โครงการ TRW หลายโครงการ"
... ค่าใช้จ่ายสัมพัทธ์ของการแก้ไขข้อผิดพลาดของซอฟต์แวร์ (หรือทำการเปลี่ยนแปลงซอฟต์แวร์อื่น ๆ ) เป็นฟังก์ชันของเฟสที่ทำการแก้ไขหรือเปลี่ยนแปลง หากตรวจพบและแก้ไขข้อผิดพลาดข้อกำหนดของซอฟต์แวร์ในระหว่างขั้นตอนการวางแผนและข้อกำหนดการแก้ไขนั้นเป็นเรื่องที่ค่อนข้างง่ายในการอัพเดตข้อกำหนดคุณสมบัติ หากข้อผิดพลาดเดียวกันไม่ได้รับการแก้ไขจนกว่าจะถึงช่วงการบำรุงรักษาการแก้ไขจะเกี่ยวข้องกับข้อมูลจำเพาะรหัสคู่มือผู้ใช้และการบำรุงรักษาที่มีขนาดใหญ่กว่าและวัสดุการฝึกอบรม
นอกจากนี้การแก้ไขล่าช้าจะเกี่ยวข้องกับกระบวนการอนุมัติและควบคุมการเปลี่ยนแปลงที่เป็นทางการมากขึ้นและกิจกรรมที่กว้างขวางยิ่งขึ้นเพื่อตรวจสอบการแก้ไขอีกครั้ง ปัจจัยเหล่านี้รวมกันเพื่อทำให้ข้อผิดพลาดโดยทั่วไปมีราคาแพงกว่า 100 เท่าในการแก้ไขในขั้นตอนการบำรุงรักษาในโครงการขนาดใหญ่กว่าในขั้นตอนความต้องการ
Bohem ยังดูโครงการขนาดเล็กที่เป็นทางการน้อยกว่าสองโครงการและพบว่ามีค่าใช้จ่ายเพิ่มขึ้น แต่มีนัยสำคัญน้อยกว่า 100 เท่าที่ระบุในโครงการขนาดใหญ่ เมื่อพิจารณาจากแผนภูมิความแตกต่างที่ปรากฏขึ้นมีค่ามากกว่า 4 เท่าในการแก้ไขข้อบกพร่องของข้อกำหนดหลังจากระบบทำงานได้ดีกว่าในช่วงข้อกำหนด เขาบันทึกสิ่งนี้ลงในรายการสินค้าที่มีขนาดเล็กกว่าซึ่งประกอบด้วยโครงการและรูปแบบที่ลดลงซึ่งนำไปสู่ความสามารถในการใช้งานที่ง่ายขึ้นแก้ไขได้เร็วขึ้น
ขึ้นอยู่กับ Boehm ในสาขาเศรษฐศาสตร์วิศวกรรมซอฟต์แวร์ตารางใน Code Complete นั้นค่อนข้างจะป่อง (ช่วงต่ำสุดของช่วงมักสูงเกินไป) ค่าใช้จ่ายในการเปลี่ยนแปลงใด ๆ ภายในเฟสเป็นจริง ๆ 1 การคาดการณ์จากรูปที่ 4-2 ในสาขาเศรษฐศาสตร์วิศวกรรมซอฟต์แวร์การเปลี่ยนแปลงความต้องการควรเป็น 1.5-2.5 เท่าในสถาปัตยกรรม 2.5-10 ในการเข้ารหัส 4-20 ในการทดสอบและ 4- 100 ในการบำรุงรักษา จำนวนขึ้นอยู่กับขนาดและความซับซ้อนของโครงการเช่นเดียวกับพิธีการของกระบวนการที่ใช้
ในภาคผนวก E ของ Barry Boehm และความคล่องตัวและดุลยพินิจของ Richard Turner มีส่วนเล็ก ๆ ในการค้นพบเชิงประจักษ์เกี่ยวกับต้นทุนการเปลี่ยนแปลง
ย่อหน้าเปิดกล่าวถึงการเขียนโปรแกรม Extreme ของ Kent Beck อธิบายโดยอ้างถึง Beck มันบอกว่าถ้าค่าใช้จ่ายของการเปลี่ยนแปลงเพิ่มขึ้นอย่างช้าๆเมื่อเวลาผ่านไปการตัดสินใจจะเกิดขึ้นช้าที่สุดเท่าที่จะทำได้และสิ่งที่จำเป็นเท่านั้นที่จะต้องดำเนินการ สิ่งนี้เรียกว่า "เส้นโค้งแบน" และเป็นสิ่งที่ขับเคลื่อนการเขียนโปรแกรมขั้นสูง อย่างไรก็ตามสิ่งที่พบวรรณกรรมก่อนหน้าคือ "โค้งชัน" ที่มีระบบขนาดเล็ก (<5 KSLOC) มีการเปลี่ยนแปลง 5: 1 และระบบขนาดใหญ่ที่มีการเปลี่ยนแปลง 100: 1
ส่วนอ้างอิงศูนย์วิศวกรรมซอฟต์แวร์ตามประจักษ์มหาวิทยาลัยแมริแลนด์ (สนับสนุนโดยมูลนิธิวิทยาศาสตร์แห่งชาติ) พวกเขาทำการค้นหาวรรณกรรมที่มีอยู่และพบว่าผลลัพธ์มีแนวโน้มที่จะยืนยันอัตราส่วน 100: 1 โดยมีผลลัพธ์บางรายการที่ระบุช่วงของ 70: 1 ถึง 125: 1 น่าเสียดายที่โครงการเหล่านี้มักจะเป็นโครงการ "ที่มีการออกแบบครั้งใหญ่มาก" และมีการจัดการตามลำดับ
มีตัวอย่างของ "โครงการ Java เชิงพาณิชย์ขนาดเล็ก" ที่ทำงานโดยใช้ Extreme Programming สำหรับแต่ละเรื่องจำนวนของความพยายามในการแก้ไขข้อผิดพลาดการออกแบบใหม่และการปรับโครงสร้างใหม่ถูกติดตาม ข้อมูลแสดงให้เห็นว่าเมื่อระบบได้รับการพัฒนา (มีการนำเรื่องราวของผู้ใช้มาใช้มากขึ้น) ความพยายามโดยเฉลี่ยมีแนวโน้มที่จะเพิ่มขึ้นในอัตราที่ไม่สำคัญ ความพยายามในการปรับโครงสร้างเพิ่มขึ้นประมาณ 5% และความพยายามในการแก้ไขความพยายามเพิ่มขึ้นประมาณ 4%
สิ่งที่ฉันเรียนรู้คือความซับซ้อนของระบบมีบทบาทอย่างมากในปริมาณความพยายามที่จำเป็น โดยการสร้างชิ้นส่วนแนวตั้งผ่านระบบคุณจะลดอัตราการโค้งโดยการเพิ่มความซับซ้อนอย่างช้าๆแทนที่จะเพิ่มเป็นแบบกอง แทนที่จะจัดการกับความซับซ้อนของข้อกำหนดจำนวนมากตามด้วยสถาปัตยกรรมที่ซับซ้อนมากตามด้วยการใช้งานที่ซับซ้อนและอื่น ๆ คุณเริ่มต้นได้ง่ายและเพิ่ม
สิ่งนี้มีผลกระทบต่อต้นทุนในการแก้ไขหรือไม่ ในท้ายที่สุดอาจจะไม่มาก อย่างไรก็ตามมันมีข้อดีของการอนุญาตให้ควบคุมความซับซ้อนได้มากขึ้น (ผ่านการจัดการหนี้ทางเทคนิค) นอกจากนี้การส่งมอบบ่อยครั้งที่เกี่ยวข้องกับความคล่องตัวหมายความว่าโครงการอาจสิ้นสุดเร็วกว่าแทนที่จะส่ง "ระบบ" ชิ้นส่วนจะถูกส่งจนกว่าความต้องการทางธุรกิจจะพอใจหรือมีการเปลี่ยนแปลงอย่างรุนแรงว่าระบบใหม่ (และดังนั้นโครงการใหม่) มันจำเป็น.
ตัวชี้วัดและแบบจำลองของสตีเฟ่นแคนในงานวิศวกรรมคุณภาพซอฟต์แวร์มีส่วนในบทที่ 6 เกี่ยวกับประสิทธิผลด้านต้นทุนของการกำจัดข้อบกพร่องเฟส
เขาเริ่มต้นด้วยการอ้างถึงบทความของ Fagan ในปี 1976 (อ้างถึงในสาขาเศรษฐศาสตร์วิศวกรรมซอฟต์แวร์) เพื่อระบุว่าการทำงานซ้ำในการออกแบบระดับสูง (สถาปัตยกรรมระบบ), การออกแบบระดับต่ำ (การออกแบบโดยละเอียด) และการนำไปปฏิบัติอาจมีราคาถูกกว่า 10 ถึง 100 เท่า กว่างานที่ทำระหว่างการทดสอบส่วนประกอบและระดับระบบ
นอกจากนี้เขายังอ้างอิงสองสิ่งพิมพ์จากปี 1982 และ 1984 โดย Freedman และ Weinberg ที่พูดถึงระบบขนาดใหญ่ ที่แรกก็คือ "คู่มือของ Walkthroughs, Inspections และ Technical Reviews" และที่สองคือ "Reviews, Walkthroughs และ Inspections" การใช้ความเห็นในช่วงต้นของวงจรการพัฒนาสามารถลดจำนวนข้อผิดพลาดที่ถึงขั้นตอนการทดสอบได้ 10 เท่าการลดจำนวนข้อบกพร่องนี้นำไปสู่การลดค่าใช้จ่ายในการทดสอบลง 50% ถึง 80% ฉันจะต้องอ่านการศึกษาในรายละเอียดเพิ่มเติม แต่ดูเหมือนว่าค่าใช้จ่ายยังรวมถึงการค้นหาและแก้ไขข้อบกพร่อง
การศึกษาโดย Remus ปี 1983 "การตรวจสอบซอฟต์แวร์แบบรวมในมุมมองของการตรวจสอบ / ทบทวน" ศึกษาต้นทุนของการขจัดข้อบกพร่องในขั้นตอนต่าง ๆ การออกแบบ / การตรวจสอบรหัส / การทดสอบและการบำรุงรักษาโดยเฉพาะโดยใช้ข้อมูลจากห้องปฏิบัติการ Santa Teresa ของ IBM ในแคลิฟอร์เนีย ผลลัพธ์ที่ถูกอ้างถึงแสดงถึงอัตราส่วนต้นทุนที่ 1:20:82 นั่นคือข้อบกพร่องที่พบในการออกแบบหรือการตรวจสอบรหัสมีค่าใช้จ่ายต่อการเปลี่ยนแปลง 1 หากข้อบกพร่องเดียวกันหลบหนีไปสู่การทดสอบจะมีค่าใช้จ่ายเพิ่มขึ้น 20 เท่า หากผู้ใช้หนีออกมาได้ก็จะเพิ่มค่าใช้จ่ายให้ถูกต้องมากถึง 82 เท่ากาญจน์โดยใช้ข้อมูลตัวอย่างจากโรงงาน Rochester, Minnessota ของไอบีเอ็มพบว่าต้นทุนการกำจัดข้อบกพร่องสำหรับโครงการ AS / 400 ใกล้เคียงกัน เวลา 1:13:92 อย่างไรก็ตามเขาชี้ให้เห็นว่าการเพิ่มขึ้นของต้นทุนอาจเป็นเพราะความยากลำบากที่เพิ่มขึ้นในการค้นหาข้อบกพร่อง
Gilb's 1993 ( "Software Inspection" ) และ 1999 ("ข้อกำหนดคุณสมบัติของวิศวกรรมซอฟต์แวร์ที่เหมาะสมและกระบวนการควบคุมคุณภาพ") ในการตรวจสอบซอฟต์แวร์ถูกกล่าวถึงเพื่อยืนยันการศึกษาอื่น ๆ
ข้อมูลเพิ่มเติมอาจพบได้ในหน้าของ Construx เรื่องการเพิ่มต้นทุนที่มีข้อบกพร่องซึ่งเป็นข้อมูลอ้างอิงจำนวนหนึ่งเกี่ยวกับการเพิ่มขึ้นของต้นทุนการซ่อมแซมข้อบกพร่อง ควรสังเกตว่า Steve McConnell ผู้แต่ง Code Complete ก่อตั้งและทำงานให้กับ Construx
ฉันเพิ่งฟังการพูดคุย, วิศวกรรมซอฟต์แวร์จริงที่ได้รับจากGlenn Vanderburgที่การประชุม Lone Star Ruby Conference ในปี 2010 เขาได้รับการพูดคุยเดียวกันที่Scottish Ruby ConferenceและErubyconในปี 2011, QCon San Francisco ในปี 2012และการประชุมสถาปัตยกรรมซอฟต์แวร์ O'Reilly ในปี 2015 ฉันได้ฟังการประชุม Lone Star Ruby Conference เท่านั้น แต่การพูดคุยได้พัฒนาไปตามกาลเวลาเนื่องจากความคิดของเขาได้รับการปรับปรุง
Venderburg แสดงให้เห็นว่าข้อมูลในอดีตทั้งหมดนี้แสดงค่าใช้จ่ายในการแก้ไขข้อบกพร่องเมื่อเวลาผ่านไปไม่จำเป็นว่าโครงการจะต้องดำเนินการผ่านเฟส หลายโครงการที่ตรวจสอบในเอกสารและหนังสือที่กล่าวถึงก่อนหน้านี้คือโครงการ "น้ำตก" ตามลำดับซึ่งเฟสและเวลาย้ายกัน อย่างไรก็ตามรูปแบบที่คล้ายกันจะเกิดขึ้นในโครงการแบบวนซ้ำและแบบเพิ่มขึ้น - ถ้ามีข้อบกพร่องถูกฉีดเข้าไปในการวนซ้ำหนึ่งครั้งมันจะค่อนข้างถูกเมื่อเทียบกับการทำซ้ำนั้น อย่างไรก็ตามเมื่อความคืบหน้าการทำซ้ำมีหลายสิ่งเกิดขึ้น - ซอฟต์แวร์มีความซับซ้อนมากขึ้นผู้คนลืมรายละเอียดเล็กน้อยบางอย่างเกี่ยวกับการทำงานในโมดูลหรือส่วนของรหัสโดยเฉพาะความต้องการเปลี่ยนแปลง สิ่งเหล่านี้จะเพิ่มค่าใช้จ่ายในการแก้ไขข้อบกพร่อง
ฉันคิดว่านี่น่าจะใกล้เคียงกับความเป็นจริงมากขึ้น ในโครงการน้ำตกค่าใช้จ่ายเพิ่มขึ้นเนื่องจากจำนวนของสิ่งประดิษฐ์ที่ต้องได้รับการแก้ไขเนื่องจากปัญหาต้นน้ำ ในโครงการแบบวนซ้ำและแบบเพิ่มขึ้นค่าใช้จ่ายจะเพิ่มขึ้นเนื่องจากซอฟต์แวร์มีความซับซ้อนเพิ่มขึ้น