สารบัญ6 หัวข้อหลัก
- 1.กรอบของประมาณการและคุณลักษณะความน่าเชื่อถือ
- 2.Technical Baseline, WBS, สมมติฐาน ข้อมูล และวิธีประมาณ
- 3.จาก Effort สู่เครือข่ายงาน Critical Path และ Schedule Risk
- 4.Staffing Profile ค่าแรง ต้นทุนอื่น และ Contingency
- 5.Agile คุณภาพ Integration การย้ายข้อมูล และทางเลือกจัดหา
- 6.Schedule Basis, Baseline, Actual Progress และ Reforecast
กรอบของประมาณการและคุณลักษณะความน่าเชื่อถือ
กรอบความสัมพันธ์ของขอบเขต ขนาดงาน ความพยายาม บุคลากร ระยะเวลา ต้นทุน และความเสี่ยง — แนวทาง NASA และ GAO วางองค์ประกอบเหล่านี้เป็นระบบเดียวกัน ขนาดงานและคุณลักษณะของผลิตภัณฑ์เป็นฐานของ effort ส่วนเครือข่ายกิจกรรม ปฏิทิน และความพร้อมของทรัพยากรแปลง effort ไปเป็น duration จากนั้นอัตราต้นทุนและค่าใช้จ่ายที่มิใช่แรงงานจึงทําให้ได้ต้นทุนตลอดวงจรชีวิตพร้อมช่วงความไม่แน่นอน การประมาณโครงการซอฟต์แวร์มิใช่การเดาวันเสร็จหรือคูณจํานวนบุคลากรด้วยจํานวนเดือนโดยตรง แต่เป็นการสร้างแบบจําลองที่เชื่อมสิ่งที่จะส่งมอบ ปริมาณงาน ความยาก ทรัพยากร ลําดับกิจกรรม และต้นทุนเข้าด้วยกัน แล้วบอกความไม่แน่นอนอย่างซื่อสัตย์ ลําดับคิดที่ตรวจสอบได้เริ่มจากนิยามผลลัพธ์และขอบเขต ทํา technical baseline และ WBS วัดหรือเทียบขนาดงาน เลือกวิธีแปลงขนาดเป็น effort กระจาย effort ตามช่วงเวลาและทักษะ สร้างตารางเครือข่าย แล้วคิดต้นทุนตลอดวงจรชีวิต ความพยายามในการทํางานกับต้นทุนการพัฒนาซอฟต์แวร์ — NASA ระบุว่าประมาณการซอฟต์แวร์ต้องครอบคลุมวงจรชีวิตทั้งหมดและอาศัยคุณลักษณะโครงการ เช่น ขนาด ฟังก์ชัน ความซับซ้อน ความสําคัญ และความเสี่ยง
แนวทางปัจจุบันยังสนับสนุนประมาณการมากกว่าหนึ่งวิธี โดยอย่างน้อยหนึ่งวิธีควรเป็นแบบจําลอง เพื่อใช้ทวนสอบความสมเหตุผลของผลหลัก NASA อธิบายว่าซอฟต์แวร์ต่างจากฮาร์ดแวร์ตรงที่องค์ประกอบต้นทุนเด่นคือแรงงาน ดังนั้นการประมาณ development effort ให้สมเหตุผลจึงเป็นกุญแจสําคัญก่อนแปลงเป็นค่าใช้จ่ายและตารางเวลา สาระสําคัญคือเพราะแรงงานเป็นต้นทุนเด่นของการพัฒนาซอฟต์แวร์ แต่ไม่ควรตีความว่ามีเฉพาะเงินเดือน ยังมีค่าเครื่องมือ cloud อุปกรณ์ ผู้รับจ้าง การทดสอบ การเปลี่ยนผ่าน การฝึกอบรม การปฏิบัติการ และการเลิกใช้งาน สี่ลักษณะของประมาณการต้นทุนที่เชื่อถือได้ตาม GAO — GAO เชื่อมแนวปฏิบัติการประมาณต้นทุนกับสี่ลักษณะ คือ Comprehensive, Well-documented, Accurate และ Credible การประเมินคุณภาพต้องพิจารณาหลักฐานของแต่ละลักษณะร่วมกัน เพราะความครบถ้วนเพียงอย่างเดียวไม่ชดเชยการขาดการวิเคราะห์ความไว ความเสี่ยง การทวนสอบ หรือการอัปเดตด้วยต้นทุนจริง GAO สรุปลักษณะของประมาณการที่เชื่อถือได้เป็น ครอบคลุม มีเอกสารรองรับ ถูกต้องและน่าเชื่อถือ ซึ่งสัมพันธ์กันและต้องผ่านหรือเกือบผ่านทุกด้าน มิใช่เลือกทําเฉพาะด้านที่สะดวก
Comprehensive หมายถึงรวมต้นทุนทั้งหมด ใช้ technical baseline ปัจจุบัน และมี WBS ที่ไม่ทําให้งานตกหรือซ้ํา Well-documented หมายถึงตามกลับถึงข้อมูล วิธี และเหตุผลจนผู้ที่ไม่เคยจัดทําประมาณการสามารถเข้าใจและสร้างซ้ําได้ Comprehensive: ความครบถ้วนของขอบเขต วงจรชีวิต และผู้ปฏิบัติงาน — ประมาณการที่ครอบคลุมต้องรวม ต้นทุนตลอดวงจรชีวิต ตั้งแต่กําหนดแนวคิด วิเคราะห์ ออกแบบ พัฒนา ทดสอบ จัดหา ติดตั้ง ย้ายข้อมูล ฝึกอบรม ใช้งาน บํารุงรักษา จนถึงยุติระบบและเก็บหรือทําลายข้อมูล หากโครงการยังต้องทดสอบก่อนใช้งานและดูแลหลังส่งมอบ แต่ตัดรายการเหล่านี้ออกเพื่อให้ยอดงบต่ํา ผลประเมินคือไม่ครอบคลุมต้นทุนวงจรชีวิต มิใช่การประหยัด เพราะภาระยังอยู่เพียงถูกซ่อนจากตัวเลข ต้องรวมทั้งงานเจ้าของโครงการ ผู้รับจ้าง และหน่วยสนับสนุน เช่น จัดซื้อ ความมั่นคงปลอดภัย เจ้าของข้อมูล ผู้ใช้งาน ฝ่ายโครงสร้างพื้นฐาน และงานตรวจรับ เมื่อ WBS มีแต่งานผู้รับจ้างควรเพิ่มงานเจ้าของและผู้รับจ้างให้ครบ รายการที่ไม่รวมต้องระบุเหตุผล เจ้าของงบ และผลเชื่อมโยงให้ชัด มิฉะนั้นอาจทําให้ผู้ใช้ข้อมูลเข้าใจผิดว่าต้นทุนถูกนับแล้วหรือไม่มีความจําเป็น
Well-documented: เอกสาร ที่มา และความสามารถในการทําซ้ํา — เอกสารที่มีเพียงยอดรวมแต่ไม่บอกแหล่งข้อมูล ความน่าเชื่อถือ และวิธีคํานวณ มีจุดอ่อนด้าน Well-documented ต่อให้ตัวเลขดูละเอียดก็ยังตรวจสอบหรือปรับเมื่อสถานการณ์เปลี่ยนไม่ได้ เอกสารควรระบุเวอร์ชันขอบเขต วันที่ราคา หน่วยวัด นิยาม cost element แหล่ง actual สูตร การปรับ normalization เกณฑ์เลือกโครงการเทียบเคียง ความเห็นผู้เชี่ยวชาญ และประวัติการเปลี่ยนสมมติฐาน เกณฑ์ที่ใช้งานจริงคืออธิบายวิธีให้ผู้อื่นทําซ้ําได้ ผู้รับผิดชอบรายใหม่ควรใช้เอกสารกับข้อมูลต้นทางแล้วได้ผลเดิมภายในความคลาดเคลื่อนจากการปัดเศษ ไม่ต้องเดาว่าผู้ประมาณคิดอะไรในใจ Accurate: ความเหมาะสมของวิธี ฐานราคา และข้อมูลผลการดําเนินงานจริง — ความถูกต้องไม่ได้แปลว่าทายตรงเป๊ะตั้งแต่ต้น แต่หมายถึงเลือกวิธีที่เหมาะกับข้อมูล มีข้อผิดพลาดเล็กน้อยเท่าที่เป็นไปได้ และเปิดเผยความแปรปรวนเพื่อให้ forecast รุ่นต่อไปดีขึ้น ข้อมูลคนละปีต้องปรับฐานให้เปรียบเทียบกันได้ โดยเฉพาะ เงินเฟ้อ ค่าแรง อัตราแลกเปลี่ยน และราคาบริการที่เปลี่ยนตามเวลา ต้องระบุดัชนี ปีฐาน และวิธีแปลง ไม่คูณเปอร์เซ็นต์ลอย ๆ
ถ้าต้นทุนจริงต่ํากว่าแผน 20% การรายงานเพียงส่วนต่างยังไม่พอ แต่ ต้องอธิบายความแปรปรวน ว่าเกิดจากทํางานมีประสิทธิภาพ ตัดขอบเขต เลื่อนงาน บันทึกผิด หรือความเสี่ยงยังไม่เกิด เมื่อขอบเขตหรือต้นทุนจริงเปลี่ยน ทีมต้องปรับตามขอบเขตและต้นทุนจริง พร้อมรักษาประวัติฉบับก่อนหน้า เพื่อแยกผลจาก scope change ออกจากความคลาดเคลื่อนของแบบจําลอง Credible: การทวนสอบแบบจําลองและประมาณการอิสระ — ผลจากวิธีเดียวอาจรับอคติของข้อมูลหรือสมมติฐานทั้งหมด จึงต้อง cross-check และให้กลุ่มอิสระประมาณ โดยใช้วิธีอื่นหรือมุมมองที่พ้นจากแรงกดดันของทีมโครงการ เมื่อแบบจําลองหลักให้ effort ต่ํากว่าข้อมูลโครงการเทียบเคียงมาก ไม่ควรเฉลี่ยสองค่าโดยอัตโนมัติ ให้ตรวจขอบเขต หน่วย นิยามความเสร็จ maturity ของทีม cost drivers และเหตุผลที่ผลต่างก่อน reconciliation หากผู้บริหารต้องการตรวจความเป็นกลางของ estimate ที่ทีมภายในทํา ควรให้กลุ่มภายนอกประมาณอย่างอิสระ โดยยึด technical baseline และ ground rules ที่เทียบกันได้ แล้วบันทึกความแตกต่างกับข้อยุติ
ถ้าผล cross-check ต่างจากประมาณหลักมาก การตอบสนองที่ถูกคือตรวจข้อมูล สมมติฐาน และวิธี ไม่เลือกตัวเลขที่สอดคล้องกับความคาดหวังมากกว่า เพราะความต่างคือสัญญาณให้ค้นสาเหตุ กระบวนการประมาณต้นทุน 12 ขั้นตามแนวทาง GAO — กระบวนการ 12 ขั้นเริ่มจากกําหนดวัตถุประสงค์และแผนการประมาณ อธิบายโปรแกรมด้วย technical baseline สร้าง WBS กําหนด ground rules และ assumptions เก็บข้อมูล เลือกวิธีและสร้าง point estimate วิเคราะห์ sensitivity กับ risk and uncertainty จัดทําเอกสาร นําเสนอเพื่ออนุมัติ และอัปเดตด้วย actual cost เมื่อโครงการดําเนินไป ขั้น 1–4 คือกําหนดวัตถุประสงค์ วางแผนการประมาณ อธิบายโปรแกรมด้วย technical baseline และสร้างโครงประมาณผ่าน WBS ขั้น 5–7 คือกําหนด ground rules/assumptions เก็บข้อมูล และสร้าง point estimate รายองค์ประกอบ ขั้น 8–9 แยก sensitivity ออกจาก risk and uncertainty ขั้น 10 ทําเอกสาร ขั้น 11 เสนอผู้บริหาร และขั้น 12 อัปเดตจาก actual กับการเปลี่ยนแปลง แม้เรียงเป็นขั้น แต่หลายส่วนทําวนซ้ําได้และควรบันทึกระหว่างทาง
Technical Baseline, WBS, สมมติฐาน ข้อมูล และวิธีประมาณ
Technical baseline และขอบเขตของระบบที่จะพัฒนา — technical baseline อธิบายวัตถุประสงค์ ผู้ใช้ ฟังก์ชัน คุณภาพ สถาปัตยกรรม interface ข้อมูล เทคโนโลยี ข้อจํากัด deployment ปริมาณธุรกรรม ระดับบริการ ความปลอดภัย และสมมติฐานการดําเนินงานที่ขับต้นทุน การเพิ่มฟังก์ชันสําคัญแต่ยังใช้ baseline ฉบับเดิมจะทําให้ WBS ขนาด effort schedule และ risk ขัดกัน ก่อนปรับต้นทุนจึงต้องปรับ baseline ให้ตรงขอบเขตล่าสุด baseline ควรระบุสิ่งที่ไม่รวมและเกณฑ์ยอมรับด้วย เช่น ใครทํา data cleansing, จํานวนระบบที่เชื่อม, browser/device ที่รองรับ, retention, availability และ recovery target เพราะคําว่า “ระบบพร้อมใช้” กว้างเกินประมาณ ความเปลี่ยนแปลงมิใช่ความผิด แต่ต้องผ่าน change control: ระบุเหตุ ผลต่อ cost/schedule/risk การตัดสินใจ และเวอร์ชันที่มีผล แล้วจึง reforecast บนฐานใหม่โดยไม่ลบประวัติเดิม
WBS ที่เน้นผลผลิตและการป้องกันงานตกหล่นหรือนับซ้ํา — WBS ที่ดีเป็น product-oriented ครอบคลุมงานทั้งหมดและเชื่อมกับ statement of work ใช้หลัก WBS เน้นผลผลิต ติดตามได้ ไม่ซ้ํา เพื่อให้แต่ละ cost element มีเจ้าของ ขอบเขต และเกณฑ์เสร็จชัด ถ้าค่าทดสอบถูกนับทั้งหมวดพัฒนาและหมวดประกันคุณภาพ แนวแก้คือปรับ WBS กันตกหล่นและนับซ้ํา โดยทํา WBS dictionary ระบุว่าค่าใดอยู่ที่ไหน มิใช่ลบการทดสอบทั้งหมดจากหมวดหนึ่งโดยไม่ตรวจงาน ระดับของ WBS ต้องเหมาะกับ maturity ข้อมูล ระยะแรกอาจใช้ก้อนใหญ่และ parametric เมื่อข้อกําหนดนิ่งขึ้นจึงแตกเป็น work package ที่ประมาณ bottom-up ได้ ไม่ควรสร้างความละเอียดเทียมที่ไม่มีข้อมูลรองรับ Ground rules และ assumptions ของประมาณการ — สมมติฐานสําคัญ เช่น วันเริ่ม availability ของ SME อัตรา reuse ความพร้อมของ API คุณภาพข้อมูล จํานวน environment อัตราเปลี่ยน requirement
productivity ค่าแรง อัตราแลกเปลี่ยน และนโยบาย cloud ต้องมีเจ้าของกับวันที่ทบทวน เขียน assumptions ให้ทดสอบได้ เช่น “legacy API พร้อมให้ทดสอบภายใน 1 มิ.ย. และตอบไม่เกิน 2 วินาที” ดีกว่า “ระบบเดิมพร้อม” เพราะผูกกับหลักฐานและ trigger re-estimate ได้ ผู้ทํา schedule และ cost ต้องใช้ข้อมูลและสมมติฐานร่วมกัน มิฉะนั้นคนหนึ่งอาจสมมติทํางาน 5 วันต่อสัปดาห์ แต่อีกคนใช้ calendar 7 วัน หรือ effort model สมมติ reuse สูงในขณะที่แผนเขียนใหม่ทั้งหมด การคัดเลือกและปรับข้อมูลโครงการในอดีต — กรณีโครงการใหม่ใกล้เคียงโครงการเดิมที่ปิดแล้ว ข้อมูลจริงจากโครงการเทียบเคียง มักเพิ่มความแม่นกว่าความเห็นล้วน เพราะสะท้อน productivity, rework, defect, integration และข้อจํากัดขององค์กรจริง ก่อนใช้ต้อง normalize ขอบเขต หน่วย ราคา ปีฐาน เทคโนโลยี ความซับซ้อน ทีม กระบวนการ คุณภาพ และสิ่งที่ included/excluded โครงการที่รายงาน effort เฉพาะ coder เทียบตรงกับ full lifecycle effort
ไม่ได้ หากใช้ข้อมูลเก่าแต่ไม่บอกว่าดีเพียงใด ต้องระบุความน่าเชื่อถือของข้อมูล เช่น แหล่งบันทึก ความครบ วิธีเก็บ การแก้ outlier และข้อจํากัด เพราะตัวเลขละเอียดจากข้อมูลอ่อนยังเป็นฐานที่อ่อน การเลือกวิธีประมาณตามข้อมูลของแต่ละ WBS element — วิธีหลักได้แก่ analogous เทียบงานเดิม, parametric ใช้ความสัมพันธ์ขนาดกับ cost drivers, engineering/bottom-up แตกงานละเอียด, และ expert judgment ที่จัดโครงสร้าง เช่น Delphi ไม่จําเป็นต้องบังคับใช้วิธีเดียวทั้งโครงการ เมื่อองค์ประกอบหนึ่งมีข้อมูลเฉพาะดีขึ้น ควรเลือกวิธีตามข้อมูลของ WBS element เช่น license ใช้ใบเสนอราคา migration ใช้จํานวนตารางกับอัตราจริง testing ใช้ workload และ application ใช้ model ที่ calibrated analogous เร็วแต่ต้องอธิบายความเหมือนต่าง parametric เหมาะเมื่อมีข้อมูลสัมพันธ์ที่เชื่อถือได้ bottom-up เหมาะเมื่อออกแบบนิ่งแต่เสี่ยงลืมงานสนับสนุน และ expert judgment เสี่ยง anchoring
หากไม่มีหลักฐานกับการอภิปรายอิสระ ควร cross-check รายการใหญ่ด้วยวิธีสํารอง เช่น bottom-up เทียบ model หรือ vendor bid เทียบ reference class แล้ว reconcile โดยดูฐาน มิใช่เฉลี่ยเลขเพื่อให้ดูเป็นกลาง ขอบเขตและข้อจํากัดของแบบจําลองประมาณการซอฟต์แวร์ — NASA Appendix M ยกตัวอย่าง PRICE, SEER และ COCOMO โดยชี้ว่า COCOMO เป็นแบบจําลองที่ใช้แพร่หลาย ส่วน PRICE และ SEER เป็นชุดเครื่องมือเชิงพาณิชย์ที่มีความสามารถประมาณซอฟต์แวร์ โมเดล parametric โดยทั่วไปแปลงตัววัดขนาดร่วมกับ cost drivers เช่น ความน่าเชื่อถือ ความซับซ้อน reuse ความพร้อมทีม เครื่องมือ และข้อจํากัด schedule ให้เป็น effort แล้วจึงเป็น duration/cost ค่าปริยายของโมเดลมิใช่ข้อเท็จจริงขององค์กร ต้อง calibrate ด้วย actual ที่นิยามตรงกัน ตรวจช่วงที่สมการใช้ได้ และบันทึก version กับค่าพารามิเตอร์ หากข้อมูลไม่พอให้รายงาน uncertainty สูงขึ้น
อันตรายคือใส่ LOC หรือ function points แบบยังไม่รู้ requirement แล้วแสดงผลเป็นทศนิยมจํานวนมาก ความแม่นของหน้าจอไม่ลดความไม่แน่นอนของ input การวัดขนาดงานตามระดับข้อมูลที่มี — ระยะแนวคิดอาจใช้จํานวน capability, interface, use case หรือ reference class ระยะ requirement ใช้ function size หรือ backlog ที่ปรับนิยามแล้ว ระยะออกแบบอาจใช้ component และระยะพัฒนาจึงมีข้อมูล task/LOC ที่มั่นขึ้น LOC ไวต่อภาษา style generator และ reuse จึงไม่ควรใช้เป็นเป้าผลิตภาพ Function points หรือ functional size เน้นฟังก์ชันที่ผู้ใช้เห็นแต่ต้องมีผู้วัดที่ calibrated ส่วน story points เป็นสเกลสัมพัทธ์ของทีมหนึ่ง ไม่ควรแปลง story point เป็นชั่วโมงด้วยอัตราสากลหรือเปรียบ velocity ข้ามทีม เพราะสเกลและ Definition of Done ต่างกัน ใช้ historical throughput/velocity ของทีมเดียวกับ backlog ที่มีคุณภาพเพื่อ forecast เป็นช่วง
สายหลักฐานของประมาณการซอฟต์แวร์
- 1Technical baseline
- 2WBS และขนาดงาน
- 3ข้อมูลและสมมติฐาน
- 4แบบจำลองและ judgment
- 5ผลและความไม่แน่นอน
เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต