การประมาณราคาซอฟต์แวร์

1. การประมาณราคาซอฟต์แวร์การประมาณราคาซอฟต์แวร์ ในการประมาณราคาซอฟต์แวร์นั้น คิดจากความพยายามในการพัฒนา (Effort) ซึ่งความพยายามในการพัฒนาซอฟต์แวร์นั้น ก็ขึ้นอยู่กับขนาดของซอฟต์แวร์ที่ จะพัฒนา (Size) เป็นหลัก การวัดขนาดของซอฟต์แวร์ก็จะมีวิธีการวัดหลายอย่าง เช่น วัดจากจำนวนบรรทัด (Line of Code) หรือวัดจากค่าฟังก์ชันพอยต์ (Function Point) และวิธีการวัดอื่นๆ ต่อมามีผู้คิดค้นแบบจำลองเพื่อใช้ในการประมาณราคาซอฟต์แวร์ จนกระทั่งในปี 1981 Barry Boehm ได้นำเอาแนวความคิดของการคำนวณทางคณิตศาสตร์ การใช้ค่าสถิติ และปัจจัยอื่นๆที่ส่งผลกระทบในการประมาณราคาซอฟต์แวร์แบบปกติ เรียกว่า COnstruction COst MOdel (COCOMO 81) ซึ่งเป็นแบบจำลองที่ได้รับการยอมรับ และใช้กันอย่างแพร่หลาย ในประเทศสหรัฐอเมริกา และได้พัฒนามาเป็น COnstruction COst MOdel II (COCOMO II) ในปี 2000 แบบจำลองดังกล่าวนั้นเหมาะสำหรับการราคาซอฟต์แวร์แบบที่ไม่ใช่ซอฟต์แวร์ที่พัฒนาบนเว็บ

2. ในยุคต่อมารูปแบบของการพัฒนาซอฟต์แวร์เริ่มเปลี่ยนทิศทางมาพัฒนาบนเว็บมากขึ้น ซึ่งเรียกกันว่า ซอฟต์แวร์ที่พัฒนาบนเว็บ (Web Based Application) แบบจำลองหนึ่งที่ได้รับการยอมรับในการประมาณความพยายามและระยะเวลาในการพัฒนาซอฟต์แวร์ที่พัฒนาบนเว็บ คือ เว็บโมเดล (Web Model) [1] ซึ่งได้พัฒนามาจากแบบจำลอง COCOMO II [2][3] และใช้วิธีการวัดของWeb Object (WO) [7] ซึ่งเป็นการประมาณขนาดของซอฟต์แวร์ที่พัฒนาบนเว็บโดยเฉพาะ ซึ่ง Web Model เป็นแบบจำลองที่เหมาะสมกับการประมาณความพยายามและระยะเวลาที่ใช้ในการพัฒนาซอฟต์แวร์ที่พัฒนาบนเว็บที่มีลักษณะแบบอีคอมเมิร์ซ (e-commerce), เว็บแอปพลิเคชันเกี่ยวกับการเงิน (Finance), เว็บแอปพลิเคชันเชิงธุรกิจต่อธุรกิจ (Business to Business) และเว็บแอปพลิเคชันยูทิลีตี้ (Web based information Utilities) โดยในงานวิจัยของ Reifer, D.J [1] มีการเก็บข้อมูลจากโครงการทั้งหมด 46 โครงการ และมี Cost Drivers ซึ่งเป็นพารามิเตอร์ที่ใช้ในการปรับค่าของข้อมูลตามแต่ละโครงการ

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

4. ตารางที่ 2.1กระบวนการประมาณราคาซอฟต์แวร์

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

6. การประมาณการค่าใช้จ่าย (Cost Estimation) แนวทางในการประมาณราคาซอฟต์แวร์ (Cost Estimate) จะมุ่งเน้นถึงการประมาณขนาดของซอฟต์แวร์ (Size) การประมาณความพยายามที่ต้องใช้ (Effort) การประมาณระยะเวลาของการพัฒนาซอฟต์แวร์ (Time) และการประมาณค่าใช้จ่ายอื่นในการพัฒนา (Investment) ดังที่แสดงในรูปที่ 2.1 รูปที่ 2.1การประเมินราคาซอฟต์แวร์

7. ขนาดของซอฟต์แวร์ (Size) หมายถึง ขนาดของการพัฒนาซอฟต์แวร์ มีหน่วยวัดเป็นจำนวนบรรทัด การประมาณความพยายามที่ต้องใช้ (Effort) หมายถึง กำลังคนที่จะใช้ในการพัฒนาซอฟต์แวร์ การประมาณระยะเวลาของการพัฒนาซอฟต์แวร์ (Time) หมายถึง ระยะเวลาที่จะใช้ในการพัฒนาซอฟต์แวร์ มีหน่วยเป็นช่วงเวลา เช่น Man Month (MM) หรือ Person Month (PM) และการประมาณค่าใช้จ่ายอื่นในการพัฒนา (Investment) หมายถึงค่าใช้จ่ายที่เกี่ยวข้อง ซึ่งอาจจะเป็นค่าเสื่อมของอุปกรณ์ ค่าไฟฟ้า ค่าน้ำ ที่เป็นค่าที่ต้องใช้จ่ายแน่นอน เป็นต้น เมื่อพิจารณาจากองค์ประกอบทั้ง 4 จะเห็นว่าในการประมาณราคานั้น สิ่งที่สำคัญที่สุดจะขึ้นอยู่กับการประมาณขนาดของซอฟต์แวร์ ซึ่งเมื่อได้ขนาดของซอฟต์แวร์ สิ่งที่จะได้ต่อมาคือความพยายามที่ต้องใช้ (Effort) และระยะเวลาในการพัฒนา (Time) ซึ่งวิธีการที่จะใช้ในการประมาณการขนาดของซอฟต์แวร์จะได้กล่าวในรายละเอียดต่อไป

8. การประมาณการขนาด (Size) ขนาดของซอฟต์แวร์ เป็นตัวแปรหลักในการประมาณการราคาในการพัฒนาซอฟต์แวร์ วิธีการหลักๆที่ใช้ในการประมาณขนาด เช่น การใช้วิธีการนับจำนวนบรรทัด (Line of Code) การวิเคราะห์จำนวนฟังก์ชันของระบบ เพื่อให้ได้ค่าฟังก์ชันพอยต์ (Function Point) [5] และการนับจำนวนวัตถุ (Object Point) [7] นอกจากนี้ก็ยังมีวิธีวัดแบบใหม่อีกหลายวิธี เช่น การวัดจากยูสเคส (Use Case Point) ฯลฯ ซึ่งการประมาณขนาดถือเป็นตัวแปรสำคัญในการประมาณการราคาซอฟต์แวร์

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

10. โดย Productivity คือ ค่าประสิทธิผลในการผลิต Line of Code คือจำนวนบรรทัดของซอฟต์แวร์ Function Point คือค่าจากการสัดฟังก์ชันพอยต์ Effort คือ กำลังคนหรือแรงงานที่ต้องใช้ในการพัฒนา ซอฟต์แวร์

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

12. วิธีการประมาณการขนาด (Size) ของซอฟต์แวร์ การวัดขนาด (Size) ของซอฟต์แวร์จะเริ่มจาก การเลือกวิธีวัดให้เหมาะสมกับการพัฒนาซอฟต์แวร์ วิธีการวัดแบ่งออกเป็น 2 ลักษณะ [9] คือ การวัดโดยตรง (Direct Measures) เป็นลักษณะการวัดขนาดของงานที่สามารถวัดจากข้อมูลที่สามารถนับได้ เช่น จำนวนหรือความยาว จะประกอบด้วยตัววัดดังต่อไปนี้ ค่าใช้จ่าย (Investment) ความพยายามหรือกำลังคนที่ต้องใช้ (Effort) จำนวนบรรทัด (Line of Code / Kilo of Delivered Source Instruction) ค่าที่ได้จากฟังก์ชันพอยต์ (Function Point) ความเร็วของการพัฒนา (Speed) ความผิดพลาดของการพัฒนา (Number of Error)

13. และการวัดแบบโดยอ้อม(Indirect Measures) เป็นการวัดในด้านประสิทธิภาพ จะประกอบด้วยตัววัดดังต่อไปนี้ คุณภาพ (Quality) ความซับซ้อน (Complexity) ประสิทธิภาพ (Efficiency) ความน่าเชื่อถือ (Reliability) การดูแลรักษา (Maintainability) ซึ่งเมื่อผนวกรวมทั้งสองลักษณะแล้วจะนำไปสู่การวัดขนาดของซอฟต์แวร์ได้ วิธีการที่พบบ่อยในการวัดขนาดของซอฟต์แวร์ มักจะใช้ตัววัดคือ Line of Code และ Function Point

14. การวัดขนาดโดยใช้ Line of Code / Kilo of Delivered Source Instruction การวัดขนาดของซอฟต์แวร์โดยใช้จำนวนบรรทัดเป็นวิธีการที่ใช้ในการวัดที่ง่ายที่สุดโดยการนับจำนวนบรรทัดที่พัฒนาซอฟต์แวร์ได้ Line of Code (LOC) หรือ Kilo Line of Code (KLOC) [10] ในบางครั้งอาจจะใช้ Kilo of Delivered Source Instruction (KDSI) ซึ่งได้มีการสรุปลักษณะการวัด LOC ดังนี้ - นับเฉพาะบรรทัดที่มีการจัดส่งเป็น Source Code ไม่นับรวมส่วนของการทดสอบ - นับเฉพาะส่วนที่พัฒนาโดยบุคลากร ไม่รวมส่วนที่ระบบสามารถสร้างได้อัตโนมัติ - ถือว่า หนึ่งคำสั่ง คือ หนึ่ง LOC - นับส่วนประกาศค่า (Declaration) เป็นส่วนของคำสั่ง (Instruction) - ไม่นับส่วนขยาย (Comment) - แม้ว่าวิธีการวัดขนาดของโปรแกรมด้วยจำนวนบรรทัดนี้จะทำได้ง่าย แต่มีจุดอ่อนหลายประการ เนื่องจากโปรแกรมที่ทำงานอย่างเดียวกันที่เขียนด้วยภาษาคอมพิวเตอร์ต่างกัน จะมีจำนวนบรรทัดที่ต่างกัน

15. การวัดขนาดโดยใช้ Function Point จากปัญหาเกี่ยวกับความแตกต่างของภาษาในการวัดด้วย Line Of Code จึงมีการแก้ปัญหาโดยใช้ Function Point โดย A.J. Albrecht จากบริษัท IBM โดยใช้วิธีวิเคราะห์ฟังก์ชันพอยต์ (Function Point Analysis: FPA) วิธีการของ Function Point จะไม่สนใจว่าเขียนด้วยภาษาใด แต่จะนับจากผลลัพธ์ของฟังกำชันส่วนประกอบของระบบ ฟังก์ชันพอยต์แต่ละประเภทจะมีความซับซ้อนต่างกัน ดังนั้นจึงมีการให้ค่าน้ำหนัก (Complexity Weight) เพื่อแบ่งความซับซ้อนของฟังก์ชันพอยต์แต่ละประเภท ดังจะแสดงในตารางที่ 2.2โดยสมการของการหาฟังก์ชันพอยต์ คือ

16. FP = UFP * TCF ….……………….สมการที่ 2.3 VAF = General Applications Characteristics[ i ] ….……………….สมการที่ 2.4 TCF = 0.65 + 0.01 * VAF …….…….……….สมการที่ 2.5 โดย FP(Function Point) คือ ค่าของฟังก์ชันพอยต์ TCF(Technical Complexity Factor) คือ ค่าความซับซ้อนของตัวแปรที่มีผลกระทบ UFP (Unjustified Function Point) คือฟังก์ชันพอยต์ที่ยังไม่คิดตัวแปรที่ส่งผลกระทบ VAF (Value Adjustment Factor) คือ ความซับซ้อนของการพัฒนาซอฟต์แวร์ i คือ ค่าของ VAF จำนวน 14 ค่า

17. โดยตัวแปรที่มีผลกระทบในการพัฒนาซอฟต์แวร์ (Value Adjustment Factor) หรือสภาพแวดล้อมในของการพัฒนาซอฟต์แวร์นั้น อาจจะมีหรือไม่มีผลกระทบจากตัวแปรเหล่านี้หรือไม่ ซึ่งผู้ประมาณการจะเป็นผู้ให้ค่าน้ำหนักเพื่อหาค่า Technical Complexity Factor (TCF) หรือ ค่าความซับซ้อนของตัวแปรที่มีผลกระทบต่อไปโดย ค่า Value Adjustment Factor(VAF) ประกอบด้วยตัวแปร 14 ค่า ดังนี้ Data communication ข้อมูลและการควบคุมข้อมูลที่ใช้ในซอฟต์แวร์ Distributed function การประมวลผลข้อมูลแบบกระจาย Performance ประสิทธิภาพด้านต่างๆของซอฟต์แวร์ Heavily used configuration โปรแกรมที่ต้องมีการคอนฟิกบ่อยครั้ง Transaction rates อัตราการทำงานของข้อมูล

18. On-line data entry สามารถที่จะควบคุมข้อมูลแบบออนไลน์ Design for end-user efficiency ประสิทธิภาพในการออกแบบสำหรับผู้ใช้ On-line update คุณสมบัติในการปรับปรุงข้อมูลแบบออนไลน์ Complex processing ความซับซ้อนในการประมวลผล Usability in other applications มีความยืดหยุ่นที่จะใช้ร่วมกับแอปพลิเคชันอื่น Installation ease ความง่ายในการติดตั้ง Operational ease ความง่ายในการใช้งาน Multiple sites มีการแบ่งการทำงานเป็นหลายที่หรือไม่ Facilitate change สามารถที่เปลี่ยนแปลงซอฟต์แวร์ได้ง่าย

19. การตัดสินใจในเรื่องของขนาดโดยใช้ส่วนประกอบในการประมวลผลของซอฟต์แวร์ โดยถือเอาว่าส่วนประกอบของระบบคือสิ่งที่ผู้ใช้ใช้งานหรือมองเห็นได้ (เรียก User Function Types by IBM) [9] และมีการกำหนดการวัดขนาดที่ใช้วัดดังนี้ ข้อมูลเข้าจากภายนอก (External Input) ข้อมูลที่ส่งออกสู่ภายนอก (External Output) ข้อมูลที่ดึงมาจากภายนอก (External Inquiries) ข้อมูลที่ต้องการจากภายนอก (External Interface Files) ข้อมูลเชิงตรรกะภายใน (Internal Logical Files)

20. และนอกจากการวัดขนาดของ User Function แล้ว ยังมีการกำหนดค่าน้ำหนัก (Weighting Factor) ที่จะนำไปคูณกับ User Function โดยผู้ประมาณการจะเป็นผู้กำหนดว่าควรจะให้ค่าน้ำหนักเป็นเท่าใดแล้วมาหาผลรวมของการคูณทั้งหมด ซึ่งจะถูกเรียกว่า “ฟังก์ชันพอยต์ที่ยังไม่คิดตัวแปรที่ส่งผลกระทบต่อการทำงาน (The Unadjusted Function Point) หรือตัวย่อคือ ยูเอฟซี (UFC)” ดังสมการที่ 2.6 UFP = EI(WEI) + EO(WEO) + EQ(WEQ) + EIF(WEIF) + ILF (WILF) …………………………..สมการที่ 2.6 โดย UFP (Unjustified Function Point) คือ ฟังก์ชันพอยต์ที่ยังไม่คิดตัวแปรที่ ส่งผลกระทบต่อการทำงาน

21. EI (External Input) คือ ข้อมูลเข้าจากภายนอก EO (External Output) คือ ข้อมูลที่ส่งออกสู่ภายนอก EQ (External Inquiries) คือ ข้อมูลที่ดึงมาจากภายนอก EIF (External Interface Files) คือ ข้อมูลที่ต้องการจากภายนอก ILF (Internal Logical Files) คือ ข้อมูลเชิงตรรกะภายใน WEI WEO WEQ WEIF WILF คือ ค่าน้ำหนักของความซับซ้อนใน แต่ละฟังก์ชันพอยต์ ค่าน้ำหนักความซับซ้อนนั้นแบ่งเป็น 3 ระดับคือ Simple, Average, Complex ซึ่งข้อมูลนี้ เป็นข้อมูลที่ได้จากข้อมูลสถิติที่กำหนดโดย IFPUG [5] ดังจะแสดงในจากตารางที่ 2.2

22. ตารางที่ 2.2 ค่าน้ำหนักความซับซ้อนของ Function Point

23. การเลือกค่าน้ำหนักของตัวแปรนั้นได้ถูกกำหนดโดย Albrecht [11] “ค่าน้ำหนักมีความสำคัญกับฟังก์ชันผู้ใช้และลูกค้า” และ “การกำหนดนั้นมาจากการประชุมเพื่อแสดงความคิดเห็นและพิจารณา” ความเคลือบแคลงเกี่ยวกับค่าน้ำหนักเกิดขึ้นว่าจะมีความเหมาะสมกับทุกๆกรณีหรือไม่ เริ่มเป็นปัญหาที่ถกเถียงขึ้น เพราะค่าน้ำหนักทุกค่านั้นมาจากซอฟต์แวร์ที่สร้างภายใต้มาตรฐานและวัฒนธรรมของ IBM และจะมั่นใจได้อย่างไรว่าค่าน้ำหนักเหล่านี้เหมาะสมกับซอฟต์แวร์อื่นๆ ที่ไม่ได้พัฒนาแบบ IBM หรือไม่ เป็นเหตุทำให้มีการศึกษาการวิเคราะห์ค่าน้ำหนัก ยกตัวอย่างระบบที่เป็นแบบ Batch ที่จำนวน Input / Output มีข้อมูลเกี่ยวกับ FP ที่สามารถนับค่าได้ หากพัฒนาระบบนี้เป็นแบบ Online มีข้อมูล Input / Output เท่าเดิมจะเกิดปัญหาว่า ถ้าใช้ FPA แบบ Albrecht ค่าก็ย่อมออกมาเท่ากัน กรณีปัญหานี้บอกให้รู้ว่า FPA ยังไม่คลอบคลุมไปในเรื่องที่เกี่ยวกับความสัมพันธ์ทางด้านเทคโนโลยี ซึ่งการวิเคราะห์แบบใหม่คือ Object Orient Approach [18] จะมีขอบเขตที่ควบคุมปัญหาเหล่านี้ด้วย

24. การวัดขนาดโดยใช้ Web Object Point เว็บออบเจ็กต์พอยต์ (Web Object Point) เป็นวิธีการวัดที่ใช้กับซอฟต์แวร์ที่พัฒนาบนเว็บ เป็นวิธีแบบ Indirect Metric ที่เหมือนกับ FP โดยจะวัดข้อมูลประเภท ส่วนประกอบของเว็บ (Web Component) ฟังก์ชันหรือโมดูลสำเร็จรูป (Building Block) ไฟล์สคริปต์ (Script Files) ภาพกราฟิก (Graphic Files) ออบเจ็กต์ หรือแอปพลิเคชันพอยต์ (Object or Application Point) และส่วนที่ติดต่อกับผู้ใช้ เช่น รายงาน หน้าจอรับข้อมูล โดยจะมีการแบ่งความซับซ้อนของตัววัดคล้ายกับฟังก์ชันพอยต์ แบ่งความซับซ้อนเป็น 3 ระดับ ได้แก่ Basic, Intermediate และ Advanced

25. ตารางที่ 2.3 ตัววัดขนาดของเว็บออบเจ็กต์พอยต์ (Web Object Point)

26. ตารางที่ 2.3 ตัววัดขนาดของเว็บออบเจ็กต์พอยต์ (Web Object Point) (ต่อ) เมื่อผู้ประมาณการวัดขนาดของซอฟต์แวร์ที่พัฒนาบนเว็บเรียบร้อยแล้ว ต่อไปก็จะหาค่าน้ำหนักตามตารางที่ 2.3 ต่อไป

27. วิธีในการประมาณค่าใช้จ่าย (Costing Model) ของการพัฒนาซอฟต์แวร์ Costing Model เป็นวิธีการที่จะมุ่งประมาณการค่าใช้จ่ายดังที่กล่าวมาแล้วในข้อ 2.1โดยข้อดีของการใช้ Cost Models ใช้ได้กับระบบที่เป็นแบบ Non Expert ข้อเสียของระบบนี้คือ การพัฒนาซอฟต์แวร์นั้นมีการปรับปรุงเปลี่ยนแปลงอยู่ตลอด หากใช้สมการก็ต้องมีการปรับเปลี่ยนค่าตามไปด้วย ซึ่งนอกจากวิธีการใช้สมการทางคณิตศาสตร์ ยังมีวิธีการที่ใช้ในปัจจุบัน เช่น 1.การประมาณการค่าใช้จ่ายโดยวิธีทางสถิติ จะใช้ข้อมูลทางสถิติเดิมมาประมาณการค่าใช้จ่ายและใช้ข้อมูลนี้มาประมาณการระยะเวลาและค่าใช้จ่าย มีความน่าเชื่อถือ 2.การใช้ความคิดเห็นของผู้เชี่ยวชาญ (Expert Judgment) เป็นการทำนายโดยใช้ประสบการณ์และความสามารถของผู้เชี่ยวชาญ เทคนิคที่ใช้ก็จะแตกต่างกันไปในแต่ละบุคคล

28. 3. การวิเคราะห์ข้อมูลเดิม (Analogy)เป็นวิธีการหนึ่งของการประมาณการแบบ Expert Opinion ผู้ที่ประมาณการจะเปรียบเทียบกับข้อมูลเดิมที่มีอยู่ว่ามีความเหมือนหรือความแตกต่างของระบบงานหรือซอฟต์แวร์ใหม่อย่างไรโดยการประมาณการจะอาศัยข้อมูลบรรทัดฐานของข้อมูลเก่าที่มีการเก็บเอาไว้ แล้วใช้ข้อมูลนี้ในการทำนาย 4. กฎของพาร์คินสัน (Parkinson’s Law)เป็นวิธีการที่จะพัฒนาซอฟต์แวร์ภายใต้ระยะเวลาและทรัพยากรบุคคลที่จำกัด ค่าใช้จ่ายในแต่ละโครงการจะคิดจากบุคลากรที่มีอยู่ในองค์กร โดยไม่สนใจปัจจัยภายนอกที่มาเกี่ยวข้อง 5. แบบล่างขึ้นบน (Bottom-up)การประมาณการด้วยวิธี Bottom-up เป็นการประมาณการโดยให้ส่วนที่ล่างที่สุดของระบบ โดยประมาณการจากส่วนที่ย่อยๆ ที่สุดไล่ระดับขึ้นไป จากคอมโพเนนท์ ไปเป็นระดับที่สูงกว่า ส่วนการประมาณการแบบ Top-up จะใช้การประมาณการจากระบบโดยภาพรวม แล้วแตกรายละเอียดไล่ไปจนถึงระดับล่างสุด

29. 6.แบบใช้ราคาเพื่อให้ได้งาน (Price-to Win)เป็นวิธีการที่ต้องการชัยชนะ โดยอาจจะประมาณการที่ต่ำกว่าทุน เพื่อให้ได้งานนั้นมา ดังนั้นในการพัฒนาจริงอาจจะเกินงบ แต่โดยส่วนใหญ่แล้ว อาจจะต้องการพัฒนาซอฟต์แวร์นี้เพื่อผลประโยชน์อย่างอื่น เช่น ต้องการไปพัฒนา หรือทำธุรกิจต่อ หรือเพื่อสร้างเครดิต เป็นต้น 7. COnstructive COst MOdel (COCOMO II)โมเดลในการประเมินราคาซอฟต์แวร์ หรือ Software Costing Model ซึ่งโมเดลนี้ถูกสร้างขึ้น ในปี 1981 โดย Barry Boehm ซึ่งเป็นที่ยอมรับและนำเอาไปใช้กันแพร่หลายในสหรัฐอเมริกา โดยแนวความคิดนั้นต้องการเพื่อประเมินราคาซอฟต์แวร์ โดยจะต้องนำเอาความแตกต่างของแต่ละโครงการ, ลักษณะเฉพาะ, ผู้ที่เกี่ยวข้องต่างๆ มาคิดคำนวณค่าออกมาเป็นตัวเลข โดยปัจจุบันพัฒนามาถึง COCOMO II ซึ่งมีการนำเอาแนวคิดเกี่ยวกับ CMM (Capability Maturity Model) มาใช้ร่วมด้วยในส่วนของคุณภาพของการบริหารจัดการซอฟต์แวร์ และการควบคุมคุณภาพของซอฟต์แวร์ ในงานวิจัยนี้ผู้วิจัยได้ศึกษาวิธีการในการประมาณการความพยายามและระยะเวลา และเลือกศึกษา Costing Model คือ COCOMO II เนื่องจากเป็นแบบจำลองที่มีความน่าเชื่อถือและได้รับความนิยมในปัจจุบัน

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

31. PM = A x Size x EM + Pmauto ...............................สมการที่ 2.7 E = B + 0.01 *  Scale Factors ……………………..สมการที่ 2.8 ซึ่ง PM คือ Effort มีหน่วยเป็น Person-Months (PM) A คือ ค่าคงที่ที่ได้จากการรวบรวมข้อมูลใน 161 โครงการ โดย A = 2.94 B คือ Scaling Base-exponent สำหรับคำนวณ Efforts E คือ Economics of Scale ซึ่งเป็นผลที่ขนาดของซอฟต์แวร์สัมพันธ์กับ ขนาดของโครงการ Size คือ ขนาดของซอฟต์แวร์ EM คือ Effort Multipliers เป็นค่าที่ได้จากการคำนวณ Cost Driver ที่ เกี่ยวกับโครงการ ที่ส่งผลต่อ Effort ในการพัฒนาซอฟต์แวร์ ดังแสดงในตารางที่ 2.4

32. Pmauto คือ ค่าของ Effort ที่ได้จากการแปลงอัตโนมัติ ซึ่งจะเกิดเมื่อมี การ Reuse Code โดยค่านั้นจะไม่มีผลต่อการพัฒนา แต่เนื่องจากมีผลต่อ ค่าใช้จ่าย ถ้าเป็นการพัฒนาซอฟต์แวร์ใหม่ ค่า Pmauto จะเป็น 0 Scale Factors คือ ตัวแปรที่มีผลกระทบข่อขนาด ดังจะแสดงในตารางที่ 2.5 ตารางที่ 2.4 COCOMO II Software Development Effort Multipliers

33. ตารางที่ 2.4COCOMO II Software Development Effort Multipliers (ต่อ)

35. ซึ่งเมื่อใช้สมการที่ 2.7 คำนวณหาค่า PM ได้แล้ว ต่อไปคือการคำนวณหาค่าระยะเวลาที่ใช้ในการพัฒนา ระยะเวลาที่ใช้ในการพัฒนาซอฟต์แวร์มีสูตรดังนี้ TDEV = [ C x (PM) F ] x SCED%…………..สมการที่ 2.9 100 F = [ D + 0.2 (E-B) ] ................สมการที่ 2.10 ซึ่ง TDEV คือ Time to Develop ระยะเวลาที่ใช้ในการพัฒนา PM คือ Effort มีหน่วยเป็น Person-Months (PM) SCED คือ ความรีบเร่งของเวลาเมื่อเปรียบเทียบกับการพัฒนาปกติ B คือ Scaling Base-exponent สำหรับคำนวณ Efforts C คือ Schedule Coefficient ที่ใช้มาคำนวณ โดย C = 3.67 D คือ Scaling Base-exponent สำหรับ ระยะเวลา โดย D = 0.28 E คือ Economics of Scale ซึ่งเป็นผลที่ขนาดของซอฟต์แวร์สัมพันธ์กับ ขนาดของโครงการ F คือ Scaling Exponent สำหรับระยะเวลา

36. ตารางที่ 2.5COCOMO II Scale Factors