การประมาณการและการวางแผนซอฟต์แวร์

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

Definition

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

Scope

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

Core questions

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

Key theories

แบบจำลองต้นทุนเชิงอัลกอริทึม

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

การวัดขนาดด้วยฟังก์ชันพอยต์

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

Clinical relevance

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

Evidence & guidelines

งานวิจัยเชิงประจักษ์เกี่ยวกับความแม่นยำของการประมาณการและแบบจำลอง เช่น COCOMO II ให้คำแนะนำที่อิงตามหลักฐาน และการนับฟังก์ชันพอยต์อยู่ภายใต้มาตรฐานการวัดขนาดฟังก์ชันของ IFPUG และ ISO/IEC

History

ฟังก์ชันพอยต์ถูกนำเสนอโดย Albrecht ในช่วงปลายทศวรรษ 1970 และ COCOMO โดย Boehm ในปี 1981 ซึ่งทำให้การประมาณการมีพื้นฐานเชิงปริมาณ; งานวิจัยต่อมาได้ปรับปรุงแบบจำลอง (COCOMO II) ศึกษาอคติในการประมาณการ และนำเสนอวิธีการวัดขนาดสัมพัทธ์แบบน้ำหนักเบาสำหรับการวางแผนแบบ Agile

Debates

การประมาณการกับการเคลื่อนไหวไม่ประมาณการ

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

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

ทำไมการประมาณการซอฟต์แวร์จึงมักผิดพลาดบ่อยครั้ง?

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

สตอรี่พอยต์เป็นเพียงชั่วโมงที่ปลอมตัวมาหรือไม่?

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