เวลาที่ใช้ตามความต้องการและผลกระทบต่อความสำเร็จของโครงการและเวลาในการพัฒนา

มีหลักฐานบ่งชี้ว่าเวลาที่ใช้ในการเขียนหรือคิดเกี่ยวกับข้อกำหนดจะมีผลต่อเวลาในการพัฒนาหรือไม่? การศึกษาที่ทำโดย Standish (1995) แสดงให้เห็นว่าข้อกำหนดที่ไม่สมบูรณ์บางส่วน (13.1%) มีส่วนทำให้โครงการล้มเหลว มีการศึกษาใดที่แสดงให้เห็นว่าเวลาที่ใช้ในการวิเคราะห์ความต้องการจะมีผลต่อเวลาในการพัฒนาโครงการหรือความสำเร็จของโครงการ

ดูรหัสเสร็จสมบูรณ์โดย Steve McConnell ตารางที่ 3-1 เขาเปรียบเทียบค่าใช้จ่ายเฉลี่ยในการแก้ไขข้อบกพร่องโดยพิจารณาจากเวลาที่ตรวจพบและถูกแนะนำ การตรวจจับในเวลาก่อสร้างมีค่าใช้จ่ายมากกว่าการตรวจจับในเวลาที่กำหนด 5-10 เท่าและการโพสต์มากกว่า 10-100 เท่า

ตารางอ้างอิงจากแหล่งข้อมูลต่อไปนี้:

1. "การออกแบบและการตรวจสอบรหัสเพื่อลดข้อผิดพลาดในการพัฒนาโปรแกรม" (Fagan 1976)

2. การกำจัดข้อบกพร่องของซอฟต์แวร์ (Dunn 1984)

3. "การปรับปรุงกระบวนการซอฟต์แวร์ที่เครื่องบินของฮิวจ์" (Humphrey, Snyder และ WIllis 1991)

และอีกมากมาย

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

กฎของกลาส: ข้อบกพร่องของความต้องการเป็นสาเหตุหลักของความล้มเหลวของโครงการ

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

สิ่งนี้ชี้ให้เห็นว่ามีความสัมพันธ์ระหว่างคุณภาพของข้อกำหนดและผลลัพธ์ของโครงการ

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

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

กฎข้อที่สองของ Boehm: การทำ ต้นแบบ (อย่างมีนัยสำคัญ) ช่วยลดความต้องการและข้อผิดพลาดในการออกแบบโดยเฉพาะอย่างยิ่งสำหรับส่วนต่อประสานผู้ใช้

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

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

การอ้างอิงสำหรับกฎหมายเหล่านี้คือ:

กฎหมายของ Glass: Glass, RL: Software Runaways บทเรียนที่เรียนรู้จากความล้มเหลวของโครงการซอฟต์แวร์ขนาดใหญ่ อัปเปอร์แซดเดิลริเวอร์, นิวเจอร์ซีย์: Prentice Hall 1998

กฎข้อแรกของ Boehm: Boehm, BW, McClean, RK, Urfrig, DB: ประสบการณ์บางอย่างกับเครื่องช่วยอัตโนมัติในการออกแบบซอฟต์แวร์ขนาดใหญ่ที่เชื่อถือได้ IEEE Trans บนวิศวกรรมซอฟต์แวร์ 1, 1 (1975), 125–133

กฎข้อที่สองของ Boehm: Boehm, BW, สีเทา, TE, Seewaldt, T .: การสร้างต้นแบบและการระบุ: การทดลองแบบหลายจุด IEEE Trans บนวิศวกรรมซอฟต์แวร์ 10, 3 (1984), 290–302

นอกจากนี้ข้อมูลอ้างอิงต่อไปนี้อาจเป็นที่สนใจ: Endres, A. และ Rombach, D. คู่มือของวิศวกรรมซอฟต์แวร์และระบบ การสังเกตเชิงประจักษ์กฎหมายและทฤษฎี Fraunhofer IESE ซีรี่ส์ทางวิศวกรรมซอฟต์แวร์ Addison Wesley, 2003