การฝึกฝนคือครูที่ดีที่สุด
— PUBLILIUS
ประสบการณ์เป็นครูที่แพง แต่คนโง่จะไม่เรียนรู้จากครูอื่นใด
— POOR RICHARD'S ALMANAC
งานเขียนโปรแกรมระบบใช้เวลานานแค่ไหน? ต้องใช้ความพยายามเท่าไหร่? และเราจะประมาณการกันอย่างไร?
ผมได้กล่าวถึงอัตราส่วนที่ใช้กับเวลาวางแผน การเขียนโค้ด การทดสอบคอมโพเนนต์ และการทดสอบระบบไว้ก่อนหน้านี้แล้ว สิ่งแรกที่ต้องทำความเข้าใจคือ เราไม่ควรประมาณการงานทั้งหมดโดยกะเฉพาะส่วนการเขียนโค้ดแล้วคูณด้วยอัตราส่วน เพราะการเขียนโค้ดเป็นแค่ประมาณหนึ่งในหกของปัญหาทั้งหมด ความผิดพลาดในการประมาณการส่วนนั้นหรือในอัตราส่วนอาจทำให้ผลลัพธ์ที่ออกมาไร้สาระได้
ประการที่สอง ต้องบอกว่าข้อมูลจากการสร้างโปรแกรมเล็กๆ แบบแยกเดี่ยวใช้ไม่ได้กับผลิตภัณฑ์ระบบขนาดใหญ่ ตัวอย่างเช่น Sackman, Erikson และ Grant รายงานว่าโปรแกรมขนาดเฉลี่ยประมาณ 3200 คำสั่ง ใช้เวลาเขียนโค้ดและดีบักรวมกันประมาณ 178 ชั่วโมงต่อโปรแกรมเมอร์หนึ่งคน ซึ่งถ้าเทียบสัดส่วนแบบเส้นตรงจะได้ผลผลิตประมาณ 35,800 คำสั่งต่อปี ส่วนโปรแกรมที่ขนาดครึ่งหนึ่งใช้เวลาไม่ถึงหนึ่งในสี่ และผลผลิตที่เทียบสัดส่วนก็เกือบ 80,000 คำสั่งต่อปี [1] ต้องบวกเวลาวางแผน การเขียนเอกสาร การทดสอบ การรวมระบบ และการฝึกอบรมเข้าไปอีก การเทียบสัดส่วนเชิงเส้นของตัวเลขระยะสั้นแบบนี้ไม่มีความหมายอะไรเลย มันเหมือนกับการเทียบสัดส่วนเวลาจากการวิ่งร้อยหลาแล้วสรุปว่าคนเราสามารถวิ่งหนึ่งไมล์ได้ในเวลาไม่ถึงสามนาที
อย่างไรก็ตาม ก่อนจะมองข้ามตัวเลขเหล่านี้ไป ลองสังเกตว่าตัวเลขเหล่านี้ แม้จะไม่ได้มาจากปัญหาที่เทียบเคียงกันโดยตรง แต่ก็ชี้ให้เห็นว่าความพยายามแปรผันตามขนาดแบบยกกำลัง แม้กระทั่ง ในกรณีที่ไม่มีการติดต่อสื่อสารใดๆ นอกจากคนคนเดียวกับสมองของตัวเอง
รูปที่ 8.1 บอกเล่าเรื่องราวที่น่าเศร้า มันแสดงผลลัพธ์จากการศึกษาของ Nanus และ Farr [2] ที่ System Development Corporation ซึ่งแสดงค่า exponent ที่ 1.5 นั่นคือ
Figure 8.1. ความพยายามที่ใช้ในการเขียนโปรแกรมเทียบกับขนาดของโปรแกรม
ความพยายาม = (ค่าคงที่) x (จำนวนคำสั่ง) 1.5 .
การศึกษาอีกชิ้นของ SDC ที่รายงานโดย Weinwurm [3] ก็แสดงค่า exponent ที่ใกล้เคียงกับ 1.5 เช่นกัน
มีการศึกษาเกี่ยวกับผลิตภาพของโปรแกรมเมอร์อยู่จำนวนหนึ่ง และมีเทคนิคการประมาณการหลายอย่างถูกเสนอขึ้นมา Morin ได้จัดทำแบบสำรวจข้อมูลที่ถูกตีพิมพ์ไว้ [4] ในที่นี้ผมจะยกมาแค่บางส่วนที่ดูจะให้ความกระจ่างเป็นพิเศษ
Portman's Data (ข้อมูลของ Portman)
Charles Portman ผู้จัดการแผนกซอฟต์แวร์ของ ICL, Computer Equipment Organization (Northwest) ที่เมือง Manchester ให้ข้อมูลเชิงลึกส่วนตัวที่มีประโยชน์อีกชิ้นหนึ่ง [5]
เขาพบว่าทีมโปรแกรมเมอร์ของเขาทำงานพลาดกำหนดการประมาณครึ่งหนึ่ง—แต่ละงานใช้เวลานานกว่าที่ประมาณไว้เกือบสองเท่า การประมาณการนั้นทำอย่างละเอียดรอบคอบ โดยทีมงานที่มีประสบการณ์เป็นผู้กะ man-hours สำหรับงานย่อยหลายร้อยงานบน PERT chart เมื่อเห็นรูปแบบความล่าช้า เขาจึงให้ทีมบันทึกเวลาทำงานประจำวันอย่างละเอียด ปรากฏว่าความผิดพลาดในการประมาณการทั้งหมดอธิบายได้จากข้อเท็จจริงที่ว่าทีมของเขาใช้เวลาจริงในการเขียนโปรแกรมและดีบักเพียง 50 เปอร์เซ็นต์ของสัปดาห์ทำงานเท่านั้น เวลาที่เหลือหายไปกับเครื่องเสีย งานด่วนอื่นๆ ที่ไม่เกี่ยวข้อง การประชุม งานเอกสาร ธุระบริษัท การเจ็บป่วย เวลาส่วนตัว ฯลฯ พูดง่ายๆ คือ การประมาณการตั้งอยู่บนสมมติฐานที่ไม่สมจริงเกี่ยวกับจำนวนชั่วโมงทำงานด้านเทคนิคต่อ man-year ประสบการณ์ของผมเองก็ยืนยันข้อสรุปของเขาเช่นกัน [6]
Aron's Data (ข้อมูลของ Aron)
Joel Aron ผู้จัดการฝ่าย Systems Technology ที่ IBM ใน Gaithersburg รัฐ Maryland ได้ศึกษาผลิตภาพของโปรแกรมเมอร์ในการทำงานกับระบบขนาดใหญ่ 9 ระบบ (โดยคร่าวๆ ขนาดใหญ่ หมายถึงโปรแกรมเมอร์มากกว่า 25 คน และคำสั่งที่ส่งมอบได้มากกว่า 30,000 คำสั่ง) [7] เขาแบ่งประเภทของระบบเหล่านี้ตามปฏิสัมพันธ์ระหว่างโปรแกรมเมอร์ (และส่วนประกอบของระบบ) และพบผลิตภาพดังนี้:
ตัวเลข man-years ดังกล่าวไม่รวมกิจกรรมสนับสนุนและการทดสอบระบบ มีเพียงการออกแบบและการเขียนโปรแกรมเท่านั้น เมื่อตัวเลขเหล่านี้ถูกหารด้วยสองเพื่อครอบคลุมการทดสอบระบบ ก็จะใกล้เคียงกับข้อมูลของ Harr
Harr's Data (ข้อมูลของ Harr)
John Harr ผู้จัดการฝ่ายเขียนโปรแกรมของ Bell Telephone Laboratories' Electronic Switching System รายงานประสบการณ์ของเขาและผู้อื่นในบทความที่ 1969 Spring Joint Computer Conference [8] ข้อมูลเหล่านี้แสดงอยู่ใน Figs. 8.2 , 8.3 และ 8.4 .
Figure 8.2. สรุปงานโปรแกรม ESS หมายเลข 1 จำนวนสี่งาน
Figure 8.3. อัตราการเขียนโปรแกรมที่คาดการณ์และที่เกิดขึ้นจริงของ ESS
Figure 8.4. อัตราการดีบักที่คาดการณ์และที่เกิดขึ้นจริงของ ESS
ในจำนวนนี้ Fig. 8.2 มีรายละเอียดมากที่สุดและมีประโยชน์มากที่สุด สองงานแรกเป็น control programs ส่วนสองงานหลังเป็น language translators ผลผลิตวัดจากจำนวนคำที่ผ่านการดีบักต่อ man-year ซึ่งรวมการเขียนโปรแกรม การทดสอบคอมโพเนนต์ และการทดสอบระบบ แต่ไม่ชัดเจนว่ารวมเวลาวางแผน งานสนับสนุนเครื่อง การเขียนเอกสาร และอื่นๆ ไว้มากน้อยแค่ไหน
ผลิตภาพก็แบ่งออกเป็นสองประเภทเช่นกัน งาน control programs อยู่ที่ประมาณ 600 คำต่อ man-year ส่วนงาน translators อยู่ที่ประมาณ 2200 คำต่อ man-year สังเกตว่างานทั้งสี่งานมีขนาดใกล้เคียงกัน—สิ่งที่แตกต่างคือขนาดของทีมงาน ระยะเวลา และจำนวนโมดูล อะไรคือสาเหตุและอะไรคือผล? งาน control programs ต้องการคนมากขึ้นเพราะมันซับซ้อนกว่าหรือ? หรือมันต้องการโมดูลและ man-months มากขึ้นเพราะถูกจัดสรรคนมากขึ้น? มันใช้เวลานานขึ้นเพราะความซับซ้อนที่มากกว่า หรือเพราะมีคนถูกจัดสรรมาทำงานมากขึ้น? ไม่มีใครตอบได้แน่ชัด งาน control programs ซับซ้อนกว่าอย่างแน่นอน ไม่ว่าจะมีความไม่แน่นอนเหล่านี้ ตัวเลขก็บรรยายถึงผลิตภาพที่เกิดขึ้นจริงบนระบบขนาดใหญ่โดยใช้เทคนิคการเขียนโปรแกรมในยุคนั้นได้เป็นอย่างดี และนั่นถือเป็นคุณูปการที่แท้จริง
Figures 8.3 และ 8.4 แสดงข้อมูลที่น่าสนใจเกี่ยวกับอัตราการเขียนโปรแกรมและการดีบักเทียบกับอัตราที่คาดการณ์ไว้
OS/360 Data (ข้อมูลของ OS/360)
ประสบการณ์จาก IBM OS/360 แม้จะไม่มีรายละเอียดเท่าข้อมูลของ Harr แต่ก็ยืนยันผลลัพธ์เดียวกัน กลุ่ม control programs มีผลิตภาพอยู่ในช่วง 600–800 คำสั่งที่ผ่านการดีบักต่อ man-year ส่วนกลุ่ม language translators มีผลิตภาพอยู่ในช่วง 2000–3000 คำสั่งที่ผ่านการดีบักต่อ man-year ตัวเลขเหล่านี้รวมเวลาวางแผนของทีม การเขียนโค้ด การทดสอบคอมโพเนนต์ การทดสอบระบบ และกิจกรรมสนับสนุนบางอย่าง เท่าที่ดูก็เทียบได้กับข้อมูลของ Harr
ข้อมูลของ Aron, ข้อมูลของ Harr และข้อมูลของ OS/360 ล้วนยืนยันความแตกต่างอย่างมีนัยสำคัญของผลิตภาพที่เกี่ยวข้องกับความซับซ้อนและความยากของตัวงานเอง แนวทางของผมในความยุ่งเหยิงของการประมาณการความซับซ้อนคือ compiler นั้นยากกว่าโปรแกรมประยุกต์แบบ batch ทั่วไปถึงสามเท่า และ operating system ก็ยากกว่า compiler ถึงสามเท่า [9]
Corbatò's Data (ข้อมูลของ Corbatò)
ทั้งข้อมูลของ Harr และข้อมูลของ OS/360 ต่างก็เป็นข้อมูลจากการเขียนโปรแกรมด้วย assembly language ดูเหมือนจะมีข้อมูลที่ถูกตีพิมพ์น้อยมากเกี่ยวกับผลิตภาพของการเขียนโปรแกรมระบบโดยใช้ภาษาระดับสูง อย่างไรก็ตาม Corbatò จาก Project MAC ของ MIT รายงานว่ามีผลิตภาพเฉลี่ย 1200 บรรทัดของคำสั่ง PL/I ที่ผ่านการดีบักต่อ man-year บนระบบ MULTICS (ระหว่าง 1 ถึง 2 ล้านคำ) [10]
ตัวเลขนี้เป็นตัวเลขที่น่าตื่นเต้นมาก เช่นเดียวกับโปรเจกต์อื่นๆ MULTICS รวมทั้ง control programs และ language translators เช่นเดียวกับโปรเจกต์อื่นๆ มันกำลังผลิตผลิตภัณฑ์ระบบที่ผ่านการทดสอบและมีเอกสารครบถ้วน ข้อมูลดูเหมือนจะเทียบเคียงได้ในแง่ของประเภทของความพยายามที่รวมอยู่ และตัวเลขผลิตภาพนี้ก็เป็นค่าเฉลี่ยที่ดีระหว่างผลิตภาพของ control program และ translator ของโปรเจกต์อื่นๆ
แต่ตัวเลขของ Corbatò เป็น บรรทัด ต่อ man-year ไม่ใช่ คำ ! แต่ละ statement ในระบบของเขาเทียบเท่ากับประมาณสามถึงห้าคำของโค้ดที่เขียนด้วยมือ! ซึ่งนำไปสู่ข้อสรุปสำคัญสองประการ
• ผลิตภาพดูจะคงที่ในแง่ของจำนวน statement พื้นฐาน ซึ่งเป็นข้อสรุปที่สมเหตุสมผลเมื่อพิจารณาจากปริมาณความคิดที่แต่ละ statement ต้องใช้และข้อผิดพลาดที่มันอาจมี [11]
• ผลิตภาพในการเขียนโปรแกรมสามารถเพิ่มขึ้นได้ถึงห้าเท่าเมื่อใช้ภาษาระดับสูงที่เหมาะสม [12]