ผมไม่รู้วิธีอื่นในการตัดสินอนาคต นอกจากผ่านอดีต
— PATRICK HENRY
คุณไม่มีทางวางแผนอนาคตจากอดีตได้ [1]
— EDMUND BURKE
Why Is There a Twentieth Anniversary Edition? (ทำไมถึงมีฉบับครบรอบ 20 ปี)
เครื่องบินดังก้องไปในยามค่ำคืนมุ่งหน้าสู่ LaGuardia เมฆและความมืดปกคลุมทัศนียภาพที่น่าสนใจทั้งหมด เอกสารที่กำลังอ่านอยู่นั้นก็ธรรมดา แต่กระนั้นผมก็ไม่รู้สึกเบื่อ คนแปลกหน้าที่นั่งข้างๆ กำลังอ่าน The Mythical Man-Month อยู่ และผมก็รอดูว่าเขาจะมีปฏิกิริยาทางคำพูดหรือท่าทางอย่างไร ในที่สุดเมื่อเราแท็กซี่ไปยังประตูขึ้นเครื่อง ผมก็รอไม่ไหวอีกต่อไป:
"หนังสือเล่มนั้นเป็นยังไงบ้าง? แนะนำไหม?"
"ฮึ! ไม่มีอะไรที่ฉันไม่รู้มาก่อน" ผมตัดสินใจไม่แนะนำตัวเอง
ทำไม The Mythical Man-Month ถึงยังคงอยู่? ทำไมมันยังคงถูกมองว่ามีความเกี่ยวข้องกับการปฏิบัติทางซอฟต์แวร์ในปัจจุบัน? ทำไมมันถึงมีผู้อ่านนอกวงการวิศวกรรมซอฟต์แวร์ ก่อให้เกิดรีวิว การอ้างอิง และจดหมายโต้ตอบจากทนายความ แพทย์ นักจิตวิทยา นักสังคมวิทยา รวมถึงคนในวงการซอฟต์แวร์ด้วย? หนังสือที่เขียนขึ้นเมื่อ 20 ปีก่อนเกี่ยวกับประสบการณ์การสร้างซอฟต์แวร์เมื่อ 30 ปีก่อน ยังคงมีความเกี่ยวข้องได้อย่างไร ไม่ต้องพูดถึงว่ายังมีประโยชน์อีกด้วย?
คำอธิบายหนึ่งที่มักได้ยินคือ วินัยการพัฒนาซอฟต์แวร์ไม่ได้ก้าวหน้าอย่างปกติหรือเหมาะสม มุมมองนี้มักถูกสนับสนุนโดยการเปรียบเทียบประสิทธิภาพการผลิตการพัฒนาซอฟต์แวร์กับประสิทธิภาพการผลิตการผลิตฮาร์ดแวร์คอมพิวเตอร์ ซึ่งเพิ่มขึ้นอย่างน้อยพันเท่าในช่วงสองทศวรรษที่ผ่านมา ดังที่ Chapter 16 ได้อธิบายไว้ ความผิดปกติไม่ได้อยู่ที่ซอฟต์แวร์มีความก้าวหน้าช้า แต่อยู่ที่เทคโนโลยีคอมพิวเตอร์ได้ระเบิดตัวในแบบที่ไม่เคยมีมาก่อนในประวัติศาสตร์ของมนุษย์ โดยส่วนใหญ่แล้วสิ่งนี้มาจากการเปลี่ยนผ่านอย่างค่อยเป็นค่อยไปของการผลิตคอมพิวเตอร์จากอุตสาหกรรมประกอบเป็นอุตสาหกรรมกระบวนการ จากเน้นแรงงานเป็นเน้นทุน การพัฒนาฮาร์ดแวร์และซอฟต์แวร์ซึ่งตรงกันข้ามกับการผลิต ยังคงต้องใช้แรงงานเข้มข้นโดยธรรมชาติ
คำอธิบายที่สองที่มักถูกหยิบยกขึ้นมาคือ The Mythical Man-Month นั้นเกี่ยวกับซอฟต์แวร์โดยบังเอิญเท่านั้น แต่ที่จริงแล้วเป็นเรื่องเกี่ยวกับวิธีที่คนในทีมสร้างสิ่งต่างๆ ขึ้นมา ซึ่งก็มีความจริงอยู่ไม่น้อย คำนำในฉบับปี 1975 กล่าวว่าการจัดการโปรเจกต์ซอฟต์แวร์นั้นคล้ายกับการจัดการทั่วไปมากกว่าที่โปรแกรมเมอร์ส่วนใหญ่คิดไว้ในตอนแรก ผมยังคงเชื่อว่ามันเป็นความจริง ประวัติศาสตร์ของมนุษย์คือละครที่เรื่องราวยังคงเดิม บทละครของเรื่องเหล่านั้นเปลี่ยนไปช้าๆ ตามวัฒนธรรมที่เปลี่ยนแปลง และฉากก็เปลี่ยนไปตลอดเวลา ดังนั้นเราจึงเห็นภาพของเราในศตวรรษที่ 20 สะท้อนอยู่ใน Shakespeare, Homer, และพระคัมภีร์ และในแง่ที่ The MM-M พูดถึงคนและทีม ความล้าสมัยก็น่าจะเกิดขึ้นอย่างช้าๆ
ไม่ว่าด้วยเหตุผลใดก็ตาม ผู้อ่านยังคงซื้อหนังสือเล่มนี้ และยังคงส่งความคิดเห็นที่ผมซาบซึ้งใจอย่างมากให้แก่ผม ปัจจุบันผมมักถูกถามว่า "ตอนนี้คุณคิดว่าอะไรที่เขียนผิดไป? อะไรที่ล้าสมัยแล้ว? มีอะไรใหม่จริงๆ ในโลกวิศวกรรมซอฟต์แวร์บ้าง?" คำถามที่แตกต่างกันเหล่านี้ล้วนเป็นคำถามที่ยุติธรรม และผมจะตอบให้ดีที่สุด ไม่ใช่ตามลำดับนั้น แต่เป็นกลุ่มหัวข้อ ก่อนอื่น มาดูกันว่าอะไรที่ถูกต้องเมื่อตอนเขียน และยังคงถูกต้องอยู่
The Central Argument: Conceptual Integrity and the Architect (ข้อโต้แย้งหลัก: ความสมบูรณ์ทางแนวคิดและสถาปนิก)
Conceptual integrity (ความสมบูรณ์ทางแนวคิด). ผลิตภัณฑ์ซอฟต์แวร์ที่สะอาดและสง่างามต้องนำเสนอโมเดลทางความคิดที่สอดคล้องกันเกี่ยวกับแอปพลิเคชัน กลยุทธ์ในการทำงานกับแอปพลิเคชัน และกลวิธีของส่วนติดต่อผู้ใช้ที่ใช้ในการระบุการกระทำและพารามิเตอร์ ให้กับผู้ใช้แต่ละคน ความสมบูรณ์ทางแนวคิดของผลิตภัณฑ์ตามที่ผู้ใช้รับรู้ เป็นปัจจัยที่สำคัญที่สุดในความสะดวกในการใช้งาน (แน่นอนว่ายังมีปัจจัยอื่นๆ อีก ความสอดคล้องกันของส่วนติดต่อผู้ใช้ของ Macintosh ทุกแอปพลิเคชันเป็นตัวอย่างที่สำคัญ ยิ่งไปกว่านั้น ยังเป็นไปได้ที่จะสร้างส่วนติดต่อที่สอดคล้องกันแต่ก็ยังค่อนข้างใช้งานยาก ลองนึกถึง MS-DOS ดู)
มีตัวอย่างมากมายของผลิตภัณฑ์ซอฟต์แวร์ที่ออกแบบโดยบุคคลคนเดียว หรือโดยคู่คน งานทางปัญญาส่วนใหญ่อย่างเช่น หนังสือหรือบทประพันธ์ดนตรี ก็ผลิตในลักษณะนี้ อย่างไรก็ตาม กระบวนการพัฒนาผลิตภัณฑ์ในหลายอุตสาหกรรมไม่สามารถใช้วิธีตรงไปตรงมาแบบนี้เพื่อให้ได้ความสมบูรณ์ทางแนวคิดได้ แรงกดดันด้านการแข่งขันทำให้เกิดความเร่งด่วน ในเทคโนโลยีสมัยใหม่หลายอย่าง ผลิตภัณฑ์ขั้นสุดท้ายค่อนข้างซับซ้อน และการออกแบบโดยธรรมชาติต้องใช้ความพยายามหลาย man-month ผลิตภัณฑ์ซอฟต์แวร์ทั้งซับซ้อนและแข่งขันกันอย่างดุเดือดในเรื่องตารางเวลา
ผลิตภัณฑ์ใดก็ตามที่ใหญ่หรือเร่งด่วนพอที่จะต้องใช้ความพยายามจากหลายคน จึงพบกับความยากลำบากอย่างประหลาด: ผลลัพธ์ต้องมีความสอดคล้องทางแนวคิดในมุมมองของผู้ใช้คนเดียว แต่ในขณะเดียวกันก็ต้องถูกออกแบบโดยหลายคน แล้วเราจะจัดระเบียบความพยายามในการออกแบบอย่างไรเพื่อให้ได้ความสมบูรณ์ทางแนวคิดเช่นนี้? นี่คือคำถามหลักที่ The MM-M กล่าวถึง หนึ่งในข้อเสนอของมันคือ การจัดการโปรเจกต์ซอฟต์แวร์ขนาดใหญ่นั้นแตกต่างในเชิงคุณภาพจากการจัดการโปรเจกต์ขนาดเล็ก เพียงเพราะจำนวนคนที่เกี่ยวข้อง จำเป็นต้องมีการจัดการที่ตั้งใจและถึงขั้นกล้าหาญเพื่อให้เกิดความสอดคล้องกัน
The architect (สถาปนิก). ผมโต้แย้งใน Chapters 4 ถึง 7 ว่าการดำเนินการที่สำคัญที่สุดคือการแต่งตั้งคนคนหนึ่งให้เป็น สถาปนิก ของผลิตภัณฑ์ ซึ่งรับผิดชอบต่อความสมบูรณ์ทางแนวคิดของทุกแง่มุมของผลิตภัณฑ์ที่ผู้ใช้สามารถรับรู้ได้ สถาปนิกเป็นผู้สร้างและเป็นเจ้าของโมเดลทางความคิดสาธารณะของผลิตภัณฑ์ที่จะใช้อธิบายการใช้งานให้ผู้ใช้เข้าใจ ซึ่งรวมถึงสเปกโดยละเอียดของฟังก์ชันทั้งหมดและวิธีการเรียกใช้และควบคุมมัน สถาปนิกยังเป็นตัวแทนของผู้ใช้ คอยแทนที่ผลประโยชน์ของผู้ใช้ในการประนีประนอมที่หลีกเลี่ยงไม่ได้ระหว่างฟังก์ชัน การทำงาน ขนาด ต้นทุน และตารางเวลา บทบาทนี้เป็นงานเต็มเวลา และเฉพาะในทีมที่เล็กที่สุดเท่านั้นที่สามารถรวมกับบทบาทของผู้จัดการทีมได้ สถาปนิกเปรียบเหมือนผู้กำกับ และผู้จัดการเปรียบเหมือนโปรดิวเซอร์ของภาพยนตร์
Separation of architecture from implementation and realization (การแยกสถาปัตยกรรมออกจากการนำไปปฏิบัติและการทำให้เกิดขึ้นจริง). เพื่อให้ภารกิจสำคัญของสถาปนิกเป็นไปได้ จำเป็นต้องแยกสถาปัตยกรรม ซึ่งเป็นคำจำกัดความของผลิตภัณฑ์ตามที่ผู้ใช้รับรู้ ออกจากการนำไปปฏิบัติ สถาปัตยกรรมกับการนำไปปฏิบัติกำหนดขอบเขตที่ชัดเจนระหว่างส่วนต่างๆ ของงานออกแบบ และมีงานมากมายในแต่ละด้านของขอบเขตนั้น
Recursion of architects (การเรียกซ้ำของสถาปนิก). สำหรับผลิตภัณฑ์ที่ใหญ่มาก คนคนเดียวไม่สามารถทำสถาปัตยกรรมทั้งหมดได้ แม้หลังจากแยกข้อกังวลด้านการนำไปปฏิบัติทั้งหมดออกไปแล้ว ดังนั้นจึงจำเป็นที่สถาปนิกหลักของระบบจะต้องแบ่งระบบออกเป็นระบบย่อย ขอบเขตของระบบย่อยต้องอยู่ที่จุดที่อินเทอร์เฟซระหว่างระบบย่อยมีน้อยที่สุดและง่ายที่สุดในการกำหนดอย่างรัดกุม จากนั้นแต่ละส่วนจะมีสถาปนิกของตัวเอง ซึ่งต้องรายงานต่อสถาปนิกหลักของระบบในส่วนที่เกี่ยวกับสถาปัตยกรรม เห็นได้ชัดว่ากระบวนการนี้สามารถดำเนินการแบบเรียกซ้ำได้ตามต้องการ
Today I am more convinced than ever (วันนี้ผมมั่นใจมากขึ้นกว่าที่เคย). ความสมบูรณ์ทางแนวคิด คือ หัวใจสำคัญของคุณภาพผลิตภัณฑ์ การมีสถาปนิกระบบ คือ ขั้นตอนที่สำคัญที่สุดเพียงขั้นตอนเดียวสู่ความสมบูรณ์ทางแนวคิด หลักการเหล่านี้ไม่ได้จำกัดอยู่แค่ระบบซอฟต์แวร์เท่านั้น แต่ใช้กับการออกแบบสิ่งก่อสร้างที่ซับซ้อนใดๆ ไม่ว่าจะเป็นคอมพิวเตอร์ เครื่องบิน Strategic Defense Initiative หรือ Global Positioning System หลังจากสอนห้องปฏิบัติการวิศวกรรมซอฟต์แวร์มากว่า 20 ครั้ง ผมเริ่มยืนยันว่าทีมนักศึกษาที่เล็กเพียง 4 คนก็ควรเลือกผู้จัดการและสถาปนิกที่แยกจากกัน การกำหนดบทบาทที่แตกต่างในทีมขนาดเล็กเช่นนี้อาจจะดูสุดโต่งไปหน่อย แต่ผมสังเกตว่ามันใช้งานได้ดีและมีส่วนช่วยให้การออกแบบประสบความสำเร็จแม้ในทีมขนาดเล็ก
The Second-System Effect: Featuritis and Frequency-Guessing (เอฟเฟกต์ระบบที่สอง: โรคฟีเจอร์ล้นและการเดาความถี่)
Designing for large user sets (การออกแบบสำหรับกลุ่มผู้ใช้ขนาดใหญ่). ผลที่ตามมาประการหนึ่งของการปฏิวัติคอมพิวเตอร์ส่วนบุคคลคือ ในปัจจุบัน อย่างน้อยในวงการประมวลผลข้อมูลทางธุรกิจ แพ็คเกจสำเร็จรูปกำลังเข้ามาแทนที่แอปพลิเคชันที่สร้างขึ้นเองเฉพาะกิจ ยิ่งไปกว่านั้น แพ็คเกจซอฟต์แวร์มาตรฐานขายได้หลายแสนหรือ甚至หลายล้านชุด สถาปนิกระบบสำหรับซอฟต์แวร์ที่มาพร้อมกับเครื่องจากผู้ผลิตเครื่องจักรต้องออกแบบสำหรับกลุ่มผู้ใช้ที่ใหญ่และไม่มีรูปร่างแน่นอนมาโดยตลอด แทนที่จะเป็นแอปพลิเคชันเฉพาะที่กำหนดได้ชัดเจนภายในบริษัทเดียว ขณะนี้สถาปนิกระบบจำนวนมากกำลังเผชิญกับภารกิจนี้
ที่ขัดแย้งกันคือ การออกแบบเครื่องมือเอนกประสงค์นั้นยากกว่าการออกแบบเครื่องมือเฉพาะกิจมาก เพราะนักออกแบบต้องให้น้ำหนักกับความต้องการที่แตกต่างกันของผู้ใช้ที่หลากหลาย
Featuritis (โรคฟีเจอร์ล้น). สิ่งล่อใจที่คอยหลอกหลอนสถาปนิกของเครื่องมือเอนกประสงค์ เช่น สเปรดชีตหรือโปรแกรมประมวลผลคำ คือการใส่ฟีเจอร์ที่ให้ประโยชน์เพียงเล็กน้อยมากเกินไป โดยแลกกับประสิทธิภาพและแม้แต่ความสะดวกในการใช้งาน เสน่ห์ของฟีเจอร์ที่นำเสนอนั้นเห็นได้ชัดตั้งแต่แรกเริ่ม ส่วนโทษด้านประสิทธิภาพจะเห็นได้ชัดก็ต่อเมื่อการทดสอบระบบดำเนินไปเท่านั้น การสูญเสียความสะดวกในการใช้งานค่อยๆ แทรกซึมเข้ามาอย่างร้ายกาจ เมื่อมีการเพิ่มฟีเจอร์ทีละเล็กทีละน้อย และคู่มือก็หนาขึ้นเรื่อยๆ [2]
สำหรับผลิตภัณฑ์ตลาดมวลชนที่อยู่รอดและวิวัฒนาการผ่านหลายรุ่น สิ่งล่อใจนี้รุนแรงเป็นพิเศษ ลูกค้าหลายล้านคนขอฟีเจอร์นับร้อย คำขอใดๆ ก็เป็นหลักฐานว่า "ตลาดต้องการมัน" บ่อยครั้งที่สถาปนิกระบบดั้งเดิมได้ก้าวไปสู่ความสำเร็จที่ยิ่งใหญ่กว่า และสถาปัตยกรรมก็ตกอยู่ในมือของคนที่มีประสบการณ์น้อยกว่าในการเป็นตัวแทนผลประโยชน์โดยรวมของผู้ใช้ในเรื่องความสมดุล บทวิจารณ์ล่าสุดของ Microsoft Word 6.0 กล่าวว่า "Word 6.0 ยัดเยียดฟีเจอร์ อัปเดตช้าลงเพราะสัมภาระหนัก... Word 6.0 ยังใหญ่และช้าอีกด้วย" มันบันทึกด้วยความผิดหวังว่า Word 6.0 ต้องการ RAM 4 MB และกล่าวต่อไปว่าฟังก์ชันที่เพิ่มเข้ามามากมายหมายความว่า "แม้แต่ Macintosh IIfx [ก็] แทบจะไม่พอสำหรับงาน Word 6" [3]
Defining the user set (การกำหนดกลุ่มผู้ใช้). ยิ่งกลุ่มผู้ใช้ใหญ่และไม่มีรูปร่างแน่นอนมากเท่าไหร่ ก็ยิ่งจำเป็นต้องกำหนดมันอย่างชัดเจนมากขึ้นเท่านั้น หากต้องการบรรลุความสมบูรณ์ทางแนวคิด สมาชิกทีมออกแบบแต่ละคนจะมีภาพของกลุ่มผู้ใช้ในใจที่แตกต่างกันอย่างแน่นอน และภาพของผู้ออกแบบแต่ละคนก็จะแตกต่างกัน เนื่องจากภาพของผู้ใช้ของสถาปนิก ไม่ว่าจะรู้ตัวหรือไม่ก็ตาม มีผลต่อทุกการตัดสินใจทางสถาปัตยกรรม จึงจำเป็นอย่างยิ่งที่ทีมออกแบบจะต้องมีภาพร่วมกันเพียงภาพเดียว และนั่นต้องมีการเขียนคุณลักษณะของกลุ่มผู้ใช้ที่คาดหวังไว้ รวมถึง:
• พวกเขาเป็นใคร
• พวกเขาต้องการอะไร
• พวกเขาคิดว่าตัวเองต้องการอะไร
• พวกเขาอยากได้อะไร
Frequencies (ความถี่). สำหรับผลิตภัณฑ์ซอฟต์แวร์ใดๆ คุณลักษณะใดๆ ของกลุ่มผู้ใช้ก็คือการกระจายตัวที่มีค่าที่เป็นไปได้หลายค่า แต่ละค่ามีความถี่ของตัวเอง แล้วสถาปนิกจะหาความถี่เหล่านี้ได้อย่างไร? การสำรวจประชากรที่ไม่มีนิยามชัดเจนนี้เป็นเรื่องที่น่าสงสัยและมีต้นทุนสูง [4] ตลอดหลายปีที่ผ่านมาผมเชื่อมั่นว่าสถาปนิกควร เดา หรือถ้าคุณต้องการก็ ตั้งสมมติฐาน ชุดคุณลักษณะและค่าที่สมบูรณ์พร้อมความถี่ เพื่อพัฒนา Description ที่สมบูรณ์ ชัดเจน และเป็น shared ของกลุ่มผู้ใช้
ประโยชน์มากมายเกิดจากขั้นตอนที่ไม่น่าเป็นไปได้นี้ ประการแรก กระบวนการเดาความถี่อย่างรอบคอบจะทำให้สถาปนิกคิดอย่างถี่ถ้วนเกี่ยวกับกลุ่มผู้ใช้ที่คาดหวัง ประการที่สอง การเขียนความถี่ลงไปจะทำให้เกิดการถกเถียง ซึ่งจะให้ความกระจ่างแก่ผู้เข้าร่วมทุกคน และนำความแตกต่างของภาพผู้ใช้ที่ผู้ออกแบบหลายคนมีขึ้นมาสู่ผิว ประการที่สาม การแจกแจงความถี่อย่างชัดเจนช่วยให้ทุกคนตระหนักว่าการตัดสินใจใดขึ้นอยู่กับคุณสมบัติของกลุ่มผู้ใช้แบบใด ถึงแม้การวิเคราะห์ความไวแบบไม่เป็นทางการนี้ก็มีคุณค่า เมื่อพบว่าการตัดสินใจที่สำคัญมาก hinging อยู่กับการเดาเฉพาะบางอย่าง ก็คุ้มค่าที่จะลงทุนเพื่อให้ได้ค่าประมาณที่ดีกว่าสำหรับค่านั้น (ระบบ gIBIS ที่พัฒนาโดย Jeff Conklin เป็นเครื่องมือสำหรับการติดตามการตัดสินใจในการออกแบบอย่างเป็นทางการและแม่นยำ และบันทึกเหตุผลของการตัดสินใจแต่ละอย่าง [5] ผมยังไม่มีโอกาสได้ใช้มัน แต่คิดว่ามันน่าจะมีประโยชน์มาก)
สรุป: เขียนการเดาที่ชัดเจนสำหรับคุณลักษณะของกลุ่มผู้ใช้ การชัดเจนและผิด ดีกว่าการคลุมเครือมาก
แล้ว "Second-System Effect" ล่ะ? นักเรียนคนหนึ่งที่เฉียบแหลมตั้งข้อสังเกตว่า The Mythical Man-Month แนะนำสูตรแห่งหายนะ: วางแผนที่จะส่งมอบเวอร์ชันที่สองของระบบใหม่ใดๆ ( Chapter 11 ) ซึ่ง Chapter 5 ระบุว่าเป็นระบบที่อันตรายที่สุดที่ใครก็เคยออกแบบ ผมต้องยอมรับว่าเขาจับผิดได้
ความขัดแย้งนั้นเป็นเรื่องของภาษามากกว่าความเป็นจริง ระบบ "ที่สอง" ที่อธิบายใน Chapter 5 คือระบบที่สองที่ถูกนำไปใช้งานจริง ระบบต่อเนื่องที่เชิญชวนให้เพิ่มฟังก์ชันและลูกเล่น ส่วนระบบ "ที่สอง" ใน Chapter 11 คือความพยายามครั้งที่สองในการสร้างสิ่งที่ควรเป็นระบบแรกที่ถูกนำไปใช้งานจริง มันถูกสร้างภายใต้ข้อจำกัดด้านตารางเวลา ความสามารถ และความไม่รู้ทั้งหมดที่ characterize โปรเจกต์ใหม่—ข้อจำกัดที่บังคับให้มีความมีวินัยแบบบางเฉียบ
The Triumph of the WIMP Interface (ชัยชนะของอินเทอร์เฟซ WIMP)
หนึ่งในการพัฒนาที่น่าประทับใจที่สุดในซอฟต์แวร์ในช่วงสองทศวรรษที่ผ่านมาคือชัยชนะของอินเทอร์เฟซ Windows, Icons, Menus, Pointing หรือเรียกสั้นๆ ว่า WIMP ปัจจุบันมันคุ้นเคยจนไม่ต้องอธิบาย แนวคิดนี้ถูกสาธิตต่อสาธารณะครั้งแรกโดย Doug Englebart และทีมของเขาจาก Stanford Research Institute ในการประชุม Western Joint Computer Conference ปี 1968 [6] จากนั้นแนวคิดก็ไปที่ Xerox Palo Alto Research Center ซึ่งปรากฏในเวิร์กสเตชันส่วนบุคคล Alto ที่พัฒนาโดย Bob Taylor และทีม ต่อมา Steve Jobs นำไปใช้ใน Apple Lisa ซึ่งเป็นคอมพิวเตอร์ที่ช้าเกินไปที่จะแบกรับแนวคิดความสะดวกในการใช้งานที่น่าตื่นเต้นของมัน แนวคิดเหล่านี้ Jobs ได้นำมาใช้ใน Apple Macintosh ที่ประสบความสำเร็จในเชิงพาณิชย์ในปี 1985 ต่อมาถูกนำไปใช้ใน Microsoft Windows สำหรับ IBM PC และเครื่องที่เข้ากันได้ ผมจะใช้ Mac เป็นตัวอย่าง [7]
Conceptual integrity via a metaphor (ความสมบูรณ์ทางแนวคิดผ่านอุปมา). WIMP เป็นตัวอย่างที่ยอดเยี่ยมของส่วนติดต่อผู้ใช้ที่มีความสมบูรณ์ทางแนวคิด ซึ่งเกิดขึ้นได้โดยการนำโมเดลทางความคิดที่คุ้นเคยอย่างอุปมาเดสก์ท็อปมาใช้ และขยายความอย่างสม่ำเสมอเพื่อใช้ประโยชน์จากการใช้งานคอมพิวเตอร์กราฟิก ตัวอย่างเช่น การตัดสินใจที่ costly แต่ถูกต้องในการซ้อนทับหน้าต่างแทนที่จะเรียงต่อกันนั้น มาจากอุปมาโดยตรง ความสามารถในการปรับขนาดและรูปร่างของหน้าต่างเป็นการขยายความที่สอดคล้องกัน ซึ่งให้พลังใหม่แก่ผู้ใช้ที่สื่อกลางคอมพิวเตอร์กราฟิก enable เอกสารบนเดสก์ท็อปจริงไม่สามารถปรับขนาดและรูปร่างได้ง่ายๆ การลากแล้ววางก็มาจากอุปมาโดยตรง การเลือกไอคอนโดยชี้ด้วยเคอร์เซอร์เป็น analog โดยตรงของการหยิบสิ่งของด้วยมือ ไอคอนและโฟลเดอร์ที่ซ้อนกันเป็น analog ที่เที่ยงตรงของเอกสารบนเดสก์ท็อป ถังขยะก็เช่นกัน แนวคิดของการตัด คัดลอก และวาง ก็สะท้อนสิ่งที่เราเคยทำกับเอกสารบนเดสก์ท็อปอย่างเที่ยงตรง อุปมาถูกปฏิบัติตามอย่างเที่ยงตรงและการขยายความก็สอดคล้องกันมากจนผู้ใช้ใหม่รู้สึกสะดุดอย่างเห็นได้ชัดกับแนวคิดการลากไอคอนดิสก์ไปที่ถังขยะเพื่อนำดิสก์ออก ถ้าอินเทอร์เฟซไม่สอดคล้องกันเกือบทุกจุด ความไม่สอดคล้องกันที่ (ค่อนข้างแย่) นั้นก็คงไม่ทำให้รู้สึกขัดใจนัก
อินเทอร์เฟซ WIMP ถูกบังคับให้ไปไกลกว่าอุปมาเดสก์ท็อปที่ไหน? ที่เห็นได้ชัดที่สุดคือสองเรื่อง: เมนูและการใช้มือเดียว เมื่อทำงานกับเดสก์ท็อปจริง เรา ลงมือ ทำกับเอกสาร แทนที่จะบอกให้ใครสักคนหรืออะไรสักอย่างทำ และเมื่อเราบอกให้ใครทำอะไรสักอย่าง เรามักจะสร้าง มากกว่าเลือก คำสั่งกริยาที่เป็นวาจาหรือลายลักษณ์อักษร: "กรุณาเก็บแฟ้มนี้" "กรุณาหาจดหมายโต้ตอบก่อนหน้านี้" "กรุณาส่งให้ Mary จัดการ"
อนิจจา การตีความคำสั่งภาษาอังกฤษที่สร้างขึ้นอย่างอิสระอย่างน่าเชื่อถือนั้นเกินกว่าศิลปะในปัจจุบัน ไม่ว่าจะเป็นคำสั่งที่เป็นลายลักษณ์อักษรหรือคำพูด ดังนั้นนักออกแบบอินเทอร์เฟซจึงห่างไกลจากการกระทำโดยตรงของผู้ใช้กับเอกสารถึงสองขั้น พวกเขาหยิบยกตัวอย่างเดียวของการเลือกคำสั่งจากเดสก์ท็อปทั่วไปขึ้นมาอย่างชาญฉลาด นั่นคือ buck slip ที่พิมพ์ไว้ ซึ่งผู้ใช้เลือกจากเมนูคำสั่งที่มีข้อจำกัดซึ่ง semantic ได้ถูกมาตรฐานไว้แล้ว แนวคิดนี้พวกเขาขยายเป็นเมนูแนวนอนของเมนูย่อยแบบดึงลงในแนวตั้ง
Command utterances and the two-cursor problem (การออกคำสั่งและปัญหาสองเคอร์เซอร์). คำสั่งคือประโยคคำสั่ง มันมักมีกริยาและมักมีกรรมตรง สำหรับการกระทำใดๆ เราต้องระบุกริยาและคำนาม อุปมาการชี้บอกว่า ในการระบุสองสิ่งในเวลาเดียวกัน ให้มีเคอร์เซอร์ที่ distinguished สองตัวบนหน้าจอ แต่ละตัวขับเคลื่อนด้วยเมาส์แยกกัน—อันหนึ่งในมือขวาและอีกอันในมือซ้าย ท้ายที่สุดแล้ว บนเดสก์ท็อปจริง เรามักจะทำงานด้วยสองมือ (แต่มือข้างหนึ่งมักจะจับสิ่งของให้อยู่กับที่ ซึ่งเกิดขึ้นโดยค่าเริ่มต้นบนเดสก์ท็อปคอมพิวเตอร์) จิตใจสามารถทำงานแบบสองมือได้แน่นอน เรามักใช้สองมือในการพิมพ์ ขับรถ ทำอาหาร อนิจจา การมีเมาส์หนึ่งตัวก็เป็นก้าวที่ยิ่งใหญ่สำหรับผู้ผลิตคอมพิวเตอร์ส่วนบุคคลแล้ว ไม่มีระบบเชิงพาณิชย์ใดรองรับการกระทำของเมาส์-เคอร์เซอร์สองตัวพร้อมกัน โดยแต่ละตัวขับเคลื่อนด้วยมือแต่ละข้าง [8]
นักออกแบบอินเทอร์เฟซยอมรับความจริงและออกแบบสำหรับเมาส์ตัวเดียว โดยใช้หลักไวยากรณ์ที่ว่าให้ชี้ (เลือก) คำนามก่อน แล้วจึงชี้ไปที่กริยา ซึ่งเป็นรายการเมนู ซึ่งทำให้ความสะดวกในการใช้งานลดลงอย่างมาก เมื่อผมดูผู้ใช้ หรือวิดีโอเทปของผู้ใช้ หรือรอยทางคอมพิวเตอร์ของการเคลื่อนที่เคอร์เซอร์ ผมรู้สึกทันทีว่าเคอร์เซอร์หนึ่งตัวต้องทำงานของสองตัว: เลือกวัตถุในส่วนเดสก์ท็อปของหน้าต่าง; เลือกกริยาในส่วนเมนู; ค้นหาหรือค้นหาอีกครั้งเพื่อหาวัตถุในเดสก์ท็อป; อีกครั้งดึงเมนูลง (มักจะเป็นเมนูเดิม) และเลือกกริยา กลับไปกลับมา กลับไปกลับมา เคอร์เซอร์เคลื่อนที่จาก data-space ไปยัง menu-space ทิ้งข้อมูลที่เป็นประโยชน์ว่ามันอยู่ที่ไหนครั้งล่าสุดใน space นี้ทุกครั้ง—โดยรวมแล้ว เป็นกระบวนการที่ไม่มีประสิทธิภาพ
A brilliant solution (ทางออกที่ยอดเยี่ยม). แม้ว่าอิเล็กทรอนิกส์และซอฟต์แวร์จะสามารถจัดการเคอร์เซอร์ที่ active พร้อมกันสองตัวได้อย่างง่ายดาย แต่ก็มีปัญหาเรื่องการจัดวางพื้นที่ เดสก์ท็อปในอุปมา WIMP จริงๆ แล้วรวมถึงเครื่องพิมพ์ดีด และเราต้องรองรับคีย์บอร์ดจริงในพื้นที่ทางกายภาพบนเดสก์ท็อปจริง คีย์บอร์ดบวกกับแผ่นรองเมาส์สองอันกินพื้นที่เอื้อมถึงเป็นจำนวนมาก อย่างไรก็ตาม ปัญหาของคีย์บอร์ดสามารถเปลี่ยนเป็นโอกาส—ทำไมไม่ทำให้การทำงานสองมือมีประสิทธิภาพโดยใช้มือข้างหนึ่งบนคีย์บอร์ดเพื่อระบุกริยา และอีกมือหนึ่งบนเมาส์เพื่อเลือกคำนามล่ะ ตอนนี้เคอร์เซอร์อยู่ใน data space เฉพาะที่ของการเลือกคำนามที่ต่อเนื่องกัน ประสิทธิภาพจริง พลังผู้ใช้จริง
User power versus ease of use (พลังผู้ใช้ versus ความสะดวกในการใช้งาน). อย่างไรก็ตาม ทางออกนั้นทำให้เสียสิ่งที่ทำให้เมนูใช้งานง่ายสำหรับมือใหม่—เมนูนำเสนอกริยาที่ถูกต้อง ณ สถานะใดๆ ที่เป็นไปได้ เราสามารถซื้อแพ็คเกจ กลับบ้าน และเริ่มใช้มันโดยไม่ต้องเปิดคู่มือ แค่รู้ว่าซื้อมาเพื่ออะไร และทดลองกับกริยาต่างๆ ในเมนู
หนึ่งในประเด็นที่ยากที่สุดที่สถาปนิกซอฟต์แวร์ต้องเผชิญคือการสร้างสมดุลระหว่างพลังผู้ใช้กับความสะดวกในการใช้งาน พวกเขาควรออกแบบเพื่อการทำงานที่ง่ายสำหรับมือใหม่หรือผู้ใช้เป็นครั้งคราว หรือเพื่อประสิทธิภาพสำหรับผู้ใช้มืออาชีพ? คำตอบในอุดมคติคือให้ทั้งสองอย่าง ในวิธีที่สอดคล้องทางแนวคิด—ซึ่งทำได้ในอินเทอร์เฟซ WIMP กริยาเมนูที่ใช้ความถี่สูงแต่ละตัวมี equivalents ปุ่มเดี่ยว + command-key ซึ่งส่วนใหญ่ถูกเลือกให้กดได้ง่ายเป็นคอร์ดเดียวด้วยมือซ้าย บน Mac ตัวอย่างเช่น ปุ่ม command อยู่ใต้ปุ่ม Z และ X พอดี ดังนั้นการดำเนินการที่ใช้ความถี่สูงสุดจึงถูกเข้ารหัสเป็น command-z, command-x, command-c, command-v, command-s
Incremental transition from novice to power user (การเปลี่ยนผ่านแบบค่อยเป็นค่อยไปจากมือใหม่สู่ผู้ใช้ระดับสูง). ระบบคู่สำหรับการระบุกริยาคำสั่งนี้ไม่เพียงตอบสนองความต้องการการเรียนรู้ต่ำของมือใหม่และความต้องการประสิทธิภาพของผู้ใช้ระดับสูง แต่ยังช่วยให้ผู้ใช้แต่ละคนสามารถเปลี่ยนผ่านระหว่างโหมดได้อย่างราบรื่น การเข้ารหัสตัวอักษรที่เรียกว่า short cuts จะแสดงบนเมนูข้างกริยา เพื่อให้ผู้ใช้ที่ไม่แน่ใจสามารถดึงเมนูลงเพื่อตรวจสอบตัวอักษรที่เทียบเท่า แทนที่จะเลือกรายการเมนูเท่านั้น มือใหม่แต่ละคนจะเรียนรู้ short cuts สำหรับการดำเนินการที่ใช้ความถี่สูงของตนเองก่อน short cut ใดที่เขาสงสัย เขาสามารถลองได้ เพราะ command-z จะยกเลิกความผิดพลาดใดๆ ก็ตาม หรือเขาสามารถตรวจสอบเมนูเพื่อดูว่าคำสั่งใดใช้ได้ มือใหม่จะดึงเมนูจำนวนมาก ผู้ใช้ระดับสูงจะดึงน้อยมาก และผู้ใช้ระดับกลางจะต้องเลือกจากเมนูเป็นครั้งคราวเท่านั้น เพราะแต่ละคนจะรู้ short cuts ไม่กี่อันที่ประกอบเป็นการดำเนินการส่วนใหญ่ของตนเอง พวกเรานักออกแบบซอฟต์แวร์ส่วนใหญ่คุ้นเคยกับอินเทอร์เฟซนี้เกินไปจนไม่ชื่นชมความสง่างามและพลังของมันอย่างเต็มที่
The success of direct incorporation as a device for enforcing architecture (ความสำเร็จของการรวมโดยตรงในฐานะเครื่องมือบังคับใช้สถาปัตยกรรม). อินเทอร์เฟซ Mac นั้นโดดเด่นในอีกทางหนึ่ง โดยไม่มีการบังคับ นักออกแบบของมันทำให้มันเป็นอินเทอร์เฟซมาตรฐานข้ามแอปพลิเคชัน รวมถึงส่วนใหญ่ที่เขียนโดยบุคคลที่สาม ดังนั้นผู้ใช้จึงได้รับความสอดคล้องทางแนวคิดในระดับอินเทอร์เฟซไม่เพียงภายในซอฟต์แวร์ที่มาพร้อมกับเครื่องเท่านั้น แต่ข้ามแอปพลิเคชันทั้งหมด
ความสำเร็จนี้ นักออกแบบ Mac ทำได้โดยการสร้างอินเทอร์เฟซไว้ใน read-only memory เพื่อให้นักพัฒนาใช้งานมันได้ง่ายและเร็วกว่าการสร้างอินเทอร์เฟซเฉพาะของตัวเอง แรงจูงใจตามธรรมชาติสำหรับความเป็นเอกภาพนี้แพร่หลายมากพอที่จะสร้างมาตรฐาน โดยพฤตินัย แรงจูงใจตามธรรมชาติได้รับการเสริมด้วยความมุ่งมั่นของผู้บริหารทั้งหมดและการโน้มน้าวใจอย่างมากจาก Apple ผู้ตรวจสอบอิสระในนิตยสารผลิตภัณฑ์ ซึ่งตระหนักถึงคุณค่าอันมหาศาลของความสอดคล้องทางแนวคิดข้ามแอปพลิเคชัน ได้เสริมแรงจูงใจตามธรรมชาติด้วยการวิจารณ์ผลิตภัณฑ์ที่ไม่ปฏิบัติตามอย่างไม่ปรานี
นี่เป็นตัวอย่างที่ยอดเยี่ยมของเทคนิคที่แนะนำใน Chapter 6 คือการบรรลุความสอดคล้องกันโดยการสนับสนุนให้ผู้อื่นรวมโค้ดของเราเข้าไปในผลิตภัณฑ์ของพวกเขาโดยตรง แทนที่จะพยายามให้พวกเขาสร้างซอฟต์แวร์ของตัวเองตามสเปกของเรา
The fate of WIMP: Obsolescence (ชะตากรรมของ WIMP: ความล้าสมัย). แม้จะมีความยอดเยี่ยม ผมคาดว่าอินเทอร์เฟซ WIMP จะกลายเป็นของเก่าในอีกหนึ่งรุ่น การชี้จะยังคงเป็นวิธีในการแสดงคำนามเมื่อเราสั่งการเครื่องจักรของเรา เสียงพูดคือวิธีที่ถูกต้องในการแสดงกริยาอย่างแน่นอน เครื่องมืออย่าง Voice Navigator สำหรับ Mac และ Dragon สำหรับ PC ก็มีความสามารถนี้อยู่แล้ว
Don't Build One to Throw Away—The Waterfall Model Is Wrong! (อย่าสร้างเพื่อทิ้ง—โมเดล Waterfall ผิด!)
ภาพที่น่าจดจำของ Galloping Gertie สะพาน Tacoma Narrows เปิด Chapter 11 ซึ่งแนะนำอย่างถึงรากถึงโคน: "วางแผนที่จะทิ้งหนึ่งครั้ง คุณก็จะทิ้งมันอยู่ดี" ตอนนี้ผมมองว่ามันผิด ไม่ใช่เพราะมันถึงรากถึงโคนเกินไป แต่เพราะมันง่ายเกินไป
ความผิดพลาดที่ใหญ่ที่สุดในแนวคิด "Build one to throw away" คือมันสันนิษฐานโดยปริยายถึงโมเดล sequential หรือ waterfall แบบคลาสสิกของการสร้างซอฟต์แวร์ โมเดลนี้มาจากการจัดวาง Gantt chart ของกระบวนการแบบเป็นขั้นตอน และมักถูกวาดดังใน Figure 19.1 Winton Royce ปรับปรุงโมเดล sequential ในบทความคลาสสิกปี 1970 โดยการให้
• มี feedback จากขั้นตอนหนึ่งไปยังขั้นตอนก่อนหน้า
• จำกัด feedback ไว้เฉพาะขั้นตอนก่อนหน้าโดยตรงเท่านั้น เพื่อควบคุมต้นทุนและความล่าช้าของตารางเวลาที่เกิดขึ้น
Figure 19.1. Waterfall model of software construction (โมเดล Waterfall ของการสร้างซอฟต์แวร์)
เขามาก่อน The MM-M ในการแนะนำให้ผู้สร้าง "build it twice" [9] Chapter 11 ไม่ใช่เพียงบทเดียวที่ถูกแต้มสีโดยโมเดล sequential waterfall; มันแทรกซึมไปทั้งเล่ม เริ่มจากกฎการจัดตารางเวลาใน Chapter 2 กฎทั่วไปนั้นจัดสรร 1/3 ของตารางเวลาให้กับการวางแผน 1/6 ให้กับการเขียนโค้ด 1/4 ให้กับการทดสอบคอมโพเนนต์ และ 1/4 ให้กับการทดสอบระบบ
ข้อผิดพลาดพื้นฐานของโมเดล waterfall คือมันสมมติว่าโปรเจกต์ดำเนินผ่านกระบวนการ เพียงครั้งเดียว ว่าสถาปัตยกรรมยอดเยี่ยมและใช้งานง่าย การออกแบบ implementation ถูกต้อง และการทำให้เป็นจริงสามารถแก้ไขได้เมื่อการทดสอบดำเนินไป อีกนัยหนึ่ง โมเดล waterfall สมมติว่าความผิดพลาดทั้งหมดจะอยู่ในการทำให้เป็นจริง และด้วยเหตุนี้การแก้ไขจึงสามารถแทรกแซงการทดสอบคอมโพเนนต์และระบบได้อย่างราบรื่น
"Plan to throw one away" โจมตีข้อผิดพลาดนี้ตรงๆ จริง มันไม่ใช่การวินิจฉัยที่ผิด แต่เป็นวิธีการแก้ไข ตอนนี้ผมแนะนำว่าอาจทิ้งและออกแบบระบบแรกใหม่ทีละส่วน แทนที่จะทิ้งทั้งหมดในคราวเดียว ซึ่งใช้ได้ในระดับหนึ่ง แต่ไม่สามารถแก้ที่ต้นตอของปัญหาได้ โมเดล waterfall วางการทดสอบระบบ และโดยนัยแล้วคือการทดสอบ ผู้ใช้ ไว้ท้ายสุดของกระบวนการสร้าง ดังนั้นเราจึงพบความยุ่งยากที่ impossible สำหรับผู้ใช้ หรือประสิทธิภาพที่ยอมรับไม่ได้ หรือความอ่อนไหวที่เป็นอันตรายต่อความผิดพลาดหรือเจตนาร้ายของผู้ใช้ หลังจากลงทุนในการสร้างเต็มรูปแบบเท่านั้น จริงอยู่ที่การตรวจสอบสเปกแบบ Alpha test มีเป้าหมายเพื่อค้นหาข้อบกพร่องเหล่านี้ตั้งแต่เนิ่นๆ แต่ก็ไม่มีอะไรแทนที่ผู้ใช้จริงได้
ข้อผิดพลาดที่สองของโมเดล waterfall คือมันสมมติว่าเราสร้างทั้งระบบในคราวเดียว โดยนำชิ้นส่วนมารวมกันเพื่อการทดสอบระบบแบบ end-to-end หลังจากที่การออกแบบ implementation เสร็จสิ้น โค้ดส่วนใหญ่เขียนเสร็จ และการทดสอบคอมโพเนนต์ส่วนใหญ่ดำเนินไปแล้ว
โมเดล waterfall ซึ่งเป็นวิธีที่คนส่วนใหญ่คิดเกี่ยวกับโปรเจกต์ซอฟต์แวร์ในปี 1975 น่าเสียดายที่ถูกทำให้เป็นมาตรฐานใน DOD-STD-2167 ซึ่งเป็นสเปกของกระทรวงกลาโหมสำหรับซอฟต์แวร์ทางการทหารทั้งหมด สิ่งนี้ทำให้มันอยู่รอดมานานเกินกว่าที่ผู้ปฏิบัติงานที่รอบคอบส่วนใหญ่จะตระหนักถึงความไม่เหมาะสมของมันและละทิ้งมันไป โชคดีที่ DoD เริ่มเห็นแสงสว่างแล้ว [10]
There has to be upstream movement (ต้องมีการเคลื่อนที่ขึ้นต้นน้ำ). เช่นเดียวกับปลาแซลมอนที่กระฉับกระเฉงในภาพเปิดบท ประสบการณ์และแนวคิดจากแต่ละส่วนปลายน้ำของกระบวนการสร้างต้องกระโดดขึ้นต้นน้ำ บางครั้งมากกว่าหนึ่งขั้นตอน และส่งผลต่อกิจกรรมต้นน้ำ
การออกแบบ implementation จะแสดงให้เห็นว่าคุณลักษณะทางสถาปัตยกรรมบางอย่างทำให้ประสิทธิภาพพิการ ดังนั้นสถาปัตยกรรมจึงต้องถูกปรับใหม่ การเขียนโค้ด realization จะแสดงว่าฟังก์ชันบางอย่างทำให้ความต้องการพื้นที่พองตัว ดังนั้นอาจต้องมีการเปลี่ยนแปลงสถาปัตยกรรมและ implementation
ดังนั้น เราอาจวนซ้ำผ่านวงจรการออกแบบสถาปัตยกรรม-implementation สองครั้งหรือมากกว่าก่อนที่จะทำให้เป็นจริงเป็นโค้ด
An Incremental-Build Model Is Better—Progressive Refinement (โมเดลสร้างแบบเพิ่มทีละน้อยดีกว่า—การปรับแต่งแบบก้าวหน้า)
Building an end-to-end skeleton system (การสร้างระบบโครงร่างแบบ end-to-end)
Harlan Mills ซึ่งทำงานในสภาพแวดล้อมระบบ real-time ได้สนับสนุนตั้งแต่แรกว่าเราควรสร้าง basic polling loop ของระบบ realtime โดยมี subroutine calls (stubs) สำหรับฟังก์ชันทั้งหมด ( Fig. 19.2 ) แต่มีเฉพาะ subroutine ที่ว่างเปล่า คอมไพล์มัน; ทดสอบมัน มันวนไปเรื่อยๆ โดยไม่ทำอะไรเลยจริงๆ แต่ทำอย่างถูกต้อง [11]
Figure 19.2.
จากนั้น เราสร้างโมดูลอินพุต (อาจเป็นแบบ primitive) และโมดูลเอาต์พุตขึ้นมา voilá! ระบบที่ทำงานได้ ซึ่งทำอะไรบางอย่าง แม้จะน่าเบื่อ ตอนนี้ ทีละฟังก์ชัน เราสร้างและเพิ่มโมดูลแบบ incremental ในทุกขั้นตอน เรามีระบบที่ทำงานได้ ถ้าเราขยัน เราก็จะมีระบบที่ debug แล้วและทดสอบแล้วในทุกขั้นตอน (เมื่อระบบโตขึ้น ภาระในการ regression-test แต่ละโมดูลใหม่กับเทสเคสก่อนหน้าทั้งหมดก็เพิ่มขึ้นตามไปด้วย)
หลังจากทุกฟังก์ชันทำงานในระดับ primitive เราก็ปรับแต่งหรือเขียนโมดูลทีละตัวใหม่ เติบโต ระบบแบบ incremental บางครั้งแน่นอนว่าเราต้องเปลี่ยน driving loop ดั้งเดิม หรือแม้แต่อินเทอร์เฟซโมดูลของมัน
เนื่องจากเรามีระบบที่ทำงานได้ตลอดเวลา
• เราสามารถเริ่มการทดสอบผู้ใช้ได้ตั้งแต่เนิ่นๆ และ
• เราสามารถนำกลยุทธ์ build-to-budget มาใช้ซึ่งป้องกันการเกินงบประมาณหรือตารางเวลาอย่างแน่นอน (โดยแลกกับฟังก์ชันที่อาจขาดตกบกพร่อง)
เป็นเวลาประมาณ 22 ปี ผมสอนห้องปฏิบัติการวิศวกรรมซอฟต์แวร์ที่ University of North Carolina บางครั้งร่วมกับ David Parnas ในหลักสูตรนี้ ทีมที่มีนักศึกษาปกติ 4 คนสร้างระบบแอปพลิเคชันซอฟต์แวร์จริงภายในหนึ่งภาคเรียน ประมาณครึ่งทางของปีเหล่านั้น ผมเปลี่ยนมาสอนการพัฒนาแบบ incremental ผมตกใจกับผลกระทบที่ทำให้ทีมมีขวัญกำลังใจดีขึ้นอย่างน่าทึ่งของภาพแรกบนหน้าจอ ระบบที่ทำงานได้ระบบแรกนั้น
Parnas Families (ตระกูล Parnas)
David Parnas เป็นผู้นำทางความคิดหลักในวิศวกรรมซอฟต์แวร์ตลอดช่วง 20 ปีนี้ ทุกคนคุ้นเคยกับแนวคิด information hiding ของเขา แต่ที่คุ้นเคยน้อยกว่าแต่สำคัญมากคือแนวคิดของ Parnas ในการออกแบบผลิตภัณฑ์ซอฟต์แวร์เป็น ตระกูล ของผลิตภัณฑ์ที่เกี่ยวข้องกัน [12] เขาเรียกร้องให้นักออกแบบคาดการณ์ทั้งการขยายในแนวราบและเวอร์ชันต่อเนื่องของผลิตภัณฑ์ และกำหนดความแตกต่างของฟังก์ชันหรือแพลตฟอร์มเพื่อสร้างแผนภูมิตระกูลของผลิตภัณฑ์ที่เกี่ยวข้อง ( Fig 19.3 )
Figure 19.3.
เคล็ดลับในการออกแบบแผนภูมิดังกล่าวคือการวางการตัดสินใจออกแบบที่มีแนวโน้มจะเปลี่ยนแปลงน้อยไว้ใกล้รากของมัน
กลยุทธ์การออกแบบดังกล่าวเพิ่มการใช้ซ้ำของโมดูลให้สูงสุด ที่สำคัญกว่านั้น กลยุทธ์เดียวกันสามารถขยายให้รวมไม่เพียงผลิตภัณฑ์ที่ส่งมอบได้ แต่ยังรวมถึงเวอร์ชันกลางที่ต่อเนื่องกันที่สร้างขึ้นในกลยุทธ์การสร้างแบบ incremental ผลิตภัณฑ์จะเติบโตผ่านขั้นตอนกลางของมันด้วยการย้อนกลับน้อยที่สุด
Microsoft's "Build Every Night" Approach (แนวทาง "Build Every Night" ของ Microsoft)
James McCarthy อธิบายให้ผมฟังถึงกระบวนการผลิตภัณฑ์ที่ทีมของเขาและทีมอื่นๆ ที่ Microsoft ใช้ มันคือการเติบโตแบบ incremental ที่นำไปสู่ข้อสรุปเชิงตรรกะ เขากล่าวว่า
หลังจากที่เราส่งมอบครั้งแรก เราจะส่งมอบเวอร์ชันต่อๆ ไปที่เพิ่มฟังก์ชันให้กับผลิตภัณฑ์ที่ทำงานอยู่แล้ว ทำไมกระบวนการสร้างครั้งแรกถึงต้องแตกต่าง? เริ่มจากช่วงเวลาของ milestone แรกของเรา [ซึ่งการเดินทางสู่การส่งมอบครั้งแรกมีสาม milestone ระหว่างทาง] เราสร้างระบบที่กำลังพัฒนาขึ้นใหม่ทุกคืน [และรันเทสเคส] วงจร build กลายเป็นจังหวะการเต้นของหัวใจของโปรเจกต์ ทุกวัน ทีมโปรแกรมเมอร์-เทสเตอร์หนึ่งทีมขึ้นไปเช็คอินโมดูลที่มีฟังก์ชันใหม่ หลังจากทุก build เรามีระบบที่ทำงานได้ ถ้า build พัง เราหยุดกระบวนการทั้งหมดจนกว่าปัญหาจะถูกพบและแก้ไข ตลอดเวลาทุกคนในทีมรู้สถานะ
มันยากจริงๆ คุณต้องทุ่มเททรัพยากรมากมาย แต่มันเป็นกระบวนการที่มีวินัย เป็นกระบวนการที่ถูกติดตามและรู้จัก มันทำให้ทีมมีความน่าเชื่อถือต่อตัวเอง ความน่าเชื่อถือของคุณกำหนดขวัญกำลังใจ สภาวะทางอารมณ์ของคุณ
ผู้สร้างซอฟต์แวร์ในองค์กรอื่นรู้สึกประหลาดใจ甚至ตกใจกับกระบวนการนี้ มีคนหนึ่งกล่าวว่า "ผมมีแนวปฏิบัติที่จะ build ทุกสัปดาห์ แต่ผมคิดว่ามันคงทำงานหนักเกินไปที่จะ build ทุกคืน" และนั่นอาจเป็นจริง Bell Northern Research ตัวอย่างเช่น สร้างระบบ 12 ล้านบรรทัดของมันขึ้นใหม่ทุกสัปดาห์
Incremental-Build and Rapid Prototyping (การสร้างแบบ Incremental และ Rapid Prototyping)
เนื่องจากกระบวนการพัฒนาแบบ incremental ช่วยให้ทดสอบกับผู้ใช้จริงได้ตั้งแต่เนิ่นๆ แล้วความแตกต่างระหว่างมันกับ rapid prototyping คืออะไร? สำหรับผมแล้ว ดูเหมือนว่าทั้งสองอย่างเกี่ยวข้องกันแต่แยกจากกัน เราสามารถมีอย่างใดอย่างหนึ่งโดยไม่มีอีกอย่างหนึ่งได้
Harel นิยาม prototype อย่างมีประโยชน์ว่า
[ เวอร์ชันของโปรแกรมที่ ] สะท้อนเฉพาะการตัดสินใจออกแบบที่ทำในกระบวนการเตรียมโมเดลแนวคิด และไม่ใช่การตัดสินใจที่ driven โดยข้อกังวลด้านการนำไปปฏิบัติ [13]
เป็นไปได้ที่จะสร้าง prototype ที่ไม่ได้เป็นส่วนหนึ่งของผลิตภัณฑ์ที่เติบโตไปสู่การส่งมอบเลย ตัวอย่างเช่น เราอาจสร้าง interface prototype ที่ไม่มีฟังก์ชันโปรแกรมจริงอยู่เบื้องหลัง มีแต่ finite-state machine ที่ทำให้มันดูเหมือนทำงานผ่านขั้นตอนต่างๆ เราสามารถ even prototype และทดสอบอินเทอร์เฟซด้วยเทคนิค Wizard-of-Oz โดยมีมนุษย์ที่ซ่อนอยู่จำลองการตอบสนองของระบบ การทำ prototype ดังกล่าวมีประโยชน์มากสำหรับการได้รับ feedback จากผู้ใช้ตั้งแต่เนิ่นๆ แต่มันแยกจากการทดสอบผลิตภัณฑ์ที่เติบโตไปสู่การส่งมอบ
ในทำนองเดียวกัน ผู้ implement อาจดำเนินการสร้าง vertical slice ของผลิตภัณฑ์ ซึ่งชุดฟังก์ชันที่จำกัดมากถูกสร้างขึ้นอย่างสมบูรณ์ เพื่อให้แสงแดดส่องเข้ามาในช่วงต้นในที่ที่งูประสิทธิภาพอาจซ่อนตัวอยู่ ความแตกต่างระหว่าง first-milestone-build ของกระบวนการ Microsoft กับ rapid prototype คืออะไร? ฟังก์ชัน ผลิตภัณฑ์ milestone แรกอาจมีฟังก์ชันไม่เพียงพอที่จะเป็นที่น่าสนใจสำหรับใครเลย ผลิตภัณฑ์ที่ส่งมอบได้ถูกกำหนดโดยความสมบูรณ์ในการให้ชุดฟังก์ชันที่มีประโยชน์ และโดยคุณภาพ ความเชื่อว่ามันทำงานได้อย่าง robust
Parnas Was Right, and I Was Wrong about Information Hiding (Parnas ถูกต้อง และผมผิดเกี่ยวกับ Information Hiding)
ใน Chapter 7 ผมเปรียบเทียบสองแนวทางกับคำถามว่าสมาชิกทีมแต่ละคนควรได้รับอนุญาตหรือถูกสนับสนุนให้รู้เกี่ยวกับการออกแบบและโค้ดของกันและกันมากแค่ไหน ในโปรเจกต์ Operating System/360 เราตัดสินใจว่า โปรแกรมเมอร์ทุกคน ควรเห็น เนื้อหาทั้งหมด —นั่นคือโปรแกรมเมอร์แต่ละคนมีสำเนาของ project workbook ซึ่งมีจำนวนมากกว่า 10,000 หน้า Harlan Mills โต้แย้งอย่างน่าเชื่อถือว่า "การเขียนโปรแกรมควรเป็นกระบวนการสาธารณะ" การเปิดเผยงานทั้งหมดให้ทุกคนมองเห็นช่วยควบคุมคุณภาพ ทั้งโดยแรงกดดันจากเพื่อนให้ทำสิ่งต่างๆ อย่างดี และโดยเพื่อนที่ spotting ข้อบกพร่องและบั๊กได้จริง
มุมมองนี้แตกต่างอย่างมากกับคำสอนของ David Parnas ที่ว่าโมดูลของโค้ดควรถูก encapsulate ด้วยอินเทอร์เฟซที่กำหนดไว้อย่างดี และภายในของโมดูลดังกล่าวควรเป็นสมบัติส่วนตัวของโปรแกรมเมอร์ ไม่สามารถ discernible จากภายนอก โปรแกรมเมอร์มีประสิทธิภาพสูงสุดหากถูกป้องกัน ไม่ใช่ถูกเปิดเผย ต่อภายในของโมดูลที่ไม่ใช่ของตนเอง [14]
ผมปฏิเสธแนวคิดของ Parnas ว่าเป็น "สูตรแห่งหายนะ" ใน Chapter 7 Parnas ถูกต้อง และผมผิด ตอนนี้ผมเชื่อมั่นว่า information hiding ซึ่งทุกวันนี้มักถูกทำให้เป็นจริงใน object-oriented programming เป็นวิธีเดียวที่จะยกระดับการออกแบบซอฟต์แวร์
เราสามารถประสบหายนะได้ด้วยเทคนิคทั้งสอง เทคนิคของ Mills ทำให้แน่ใจว่าโปรแกรมเมอร์สามารถรู้ semantic โดยละเอียดของอินเทอร์เฟซที่พวกเขาทำงานด้วยโดยรู้ว่ามีอะไรอยู่อีกด้านหนึ่ง การซ่อน semantic เหล่านั้นนำไปสู่บั๊กของระบบ ในทางกลับกัน เทคนิคของ Parnas นั้น robust ภายใต้การเปลี่ยนแปลง และเหมาะสมกว่าในปรัชญาการออกแบบเพื่อการเปลี่ยนแปลง
Chapter 16 โต้แย้งดังนี้:
• ความก้าวหน้าส่วนใหญ่ในอดีตของ productivity ซอฟต์แวร์มาจากการกำจัดความยากลำบากที่ไม่ใช่ inherent เช่น ภาษาเครื่องที่ใช้งานยากและ turnaround แบบ batch ที่ช้า
• มีความง่ายแบบนี้อีกไม่มากนัก
• ความก้าวหน้าแบบ radical จะต้องมาจากการโจมตีความยากลำบากที่ essential ของการสร้าง conceptual constructs ที่ซับซ้อน
วิธีที่ชัดเจนที่สุดในการทำเช่นนี้คือการตระหนักว่าโปรแกรมประกอบขึ้นจาก chunk ทางแนวคิดที่ใหญ่กว่าคำสั่ง high-level language แต่ละคำสั่งมาก—subroutines หรือ modules หรือ classes ถ้าเราสามารถจำกัดการออกแบบและการสร้างให้เพียงแค่การประกอบและการกำหนดพารามิเตอร์ของ chunk ดังกล่าวจากคอลเล็กชันที่สร้างไว้ล่วงหน้า เราก็ได้ยกระดับ conceptual level อย่าง radical และกำจัดงานจำนวนมหาศาลและโอกาสมากมายสำหรับข้อผิดพลาดที่อาศัยอยู่ที่ระดับคำสั่งแต่ละคำสั่ง
คำจำกัดความของโมดูลแบบ information-hiding ของ Parnas คือขั้นตอนแรกที่ตีพิมพ์ในโปรแกรมการวิจัยที่สำคัญยิ่งนั้น และมันเป็นบรรพบุรุษทางปัญญาของ object-oriented programming เขากำหนดโมดูลว่าเป็น entity ซอฟต์แวร์ที่มี data model และชุดการดำเนินการของตัวเอง ข้อมูลของมันสามารถเข้าถึงได้ผ่านการดำเนินการที่เหมาะสมของมันเท่านั้น ขั้นตอนที่สองเป็นการมีส่วนร่วมของนักคิดหลายคน: การยกระดับโมดูล Parnas ให้เป็น abstract data type ซึ่งสามารถ derive วัตถุจำนวนมากได้ abstract data type ให้วิธีที่สม่ำเสมอในการคิดเกี่ยวกับและระบุอินเทอร์เฟซโมดูล และวินัยการเข้าถึงที่ง่ายต่อการบังคับใช้
ขั้นตอนที่สาม object-oriented programming นำเสนอแนวคิดที่ทรงพลังของ inheritance ซึ่งคลาส (data types) ใช้คุณลักษณะที่ระบุจากบรรพบุรุษในลำดับชั้นคลาสเป็นค่าเริ่มต้น [15] สิ่งที่เราหวังว่าจะได้รับจาก object-oriented programming ส่วนใหญ่จริงๆ แล้วมาจากขั้นตอนแรกคือ module encapsulation รวมกับแนวคิดของไลบรารีที่สร้างไว้ล่วงหน้าของโมดูลหรือคลาส ที่ถูกออกแบบและทดสอบเพื่อการ reuse หลายคนเลือกที่จะไม่สนใจความจริงที่ว่าโมดูลดังกล่าวไม่ใช่แค่โปรแกรม แต่เป็นผลิตภัณฑ์โปรแกรมในความหมายที่กล่าวถึงใน Chapter 1 บางคนหวังอย่างไร้เดียงสาสำหรับการ reuse โมดูลอย่างมีนัยสำคัญโดยไม่ต้องจ่ายต้นทุนเริ่มต้นในการสร้างโมดูลระดับผลิตภัณฑ์—ที่ถูก generalize, robust, ทดสอบแล้ว และมีเอกสารประกอบ Object-oriented programming และ reuse ถูกกล่าวถึงใน Chapters 16 และ 17 .
How Mythical Is the Man-Month? Boehm's Model and Data (Man-Month เป็นมายาคติแค่ไหน? โมเดลและข้อมูลของ Boehm)
ตลอดหลายปีที่ผ่านมา มีการศึกษาเชิงปริมาณมากมายเกี่ยวกับ productivity ของซอฟต์แวร์และปัจจัยที่มีผลต่อมัน โดยเฉพาะ trade-off ระหว่างการจัดบุคลากรของโปรเจกต์และตารางเวลา
การศึกษาที่มีสาระสำคัญที่สุดคือการศึกษาของ Barry Boehm จากโปรเจกต์ซอฟต์แวร์ประมาณ 63 โปรเจกต์ ส่วนใหญ่เป็น aerospace ประมาณ 25 โปรเจกต์ที่ TRW หนังสือ Software Engineering Economics ของเขามีไม่เพียงผลลัพธ์ แต่ยังมีชุดโมเดลต้นทุนที่มีความครอบคลุมแบบก้าวหน้า แม้ว่าสัมประสิทธิ์ในโมเดลจะแตกต่างกันอย่างแน่นอนสำหรับซอฟต์แวร์เชิงพาณิชย์ทั่วไปและซอฟต์แวร์ aerospace ที่สร้างตามมาตรฐานของรัฐบาล แต่โมเดลของเขาก็ backed โดยข้อมูลจำนวนมหาศาล ผมคิดว่าหนังสือเล่มนี้จะเป็นคลาสสิกที่มีประโยชน์ในอีกหนึ่งชั่วอายุคน
ผลลัพธ์ของเขายืนยันอย่างมั่นคงถึงคำกล่าวอ้างของ The MM-M ว่า trade-off ระหว่างคนกับเดือนนั้นห่างไกลจากเชิงเส้น ว่า man-month เป็นมายาคติจริงในฐานะหน่วยวัด productivity โดยเฉพาะ เขาพบว่า: [16]
• มีเวลาตารางที่เหมาะสมด้านต้นทุนในการส่งมอบครั้งแรก T = 2.5 (MM) 1/3 นั่นคือ เวลาที่เหมาะสมในเดือนเป็นรากที่สามของความพยายามที่คาดหวังใน man-month ซึ่งเป็นตัวเลขที่ derived จากค่าประมาณขนาดและปัจจัยอื่นๆ ในโมเดลของเขา เส้นโค้งการจัดบุคลากรที่เหมาะสมเป็นผลต่อเนื่อง
• เส้นโค้งต้นทุนเพิ่มขึ้นช้าๆ เมื่อตารางเวลาที่วางแผนยาวกว่า optimum คนที่มีเวลามากกว่าจะใช้เวลามากกว่า
• เส้นโค้งต้นทุนเพิ่มขึ้น sharp เมื่อตารางเวลาที่วางแผนสั้นกว่า optimum
• แทบไม่มีโปรเจกต์ใดสำเร็จในเวลาน้อยกว่า 3/4 ของตารางเวลาที่ optimum ที่คำนวณได้ ไม่ว่าจะใช้คนกี่คนก็ตาม! ผลลัพธ์ที่โดดเด่นนี้ให้กระสุนที่มั่นคงแก่ผู้จัดการซอฟต์แวร์เมื่อผู้บริหารระดับสูงต้องการข้อผูกมัดตารางเวลาที่เป็นไปไม่ได้
Brooks's Law จริงแค่ไหน? มี even การศึกษาอย่างรอบคอบที่ประเมินความจริงของ Brooks's Law (ที่ตั้งใจให้เรียบง่ายเกินไป) ที่ว่าการเพิ่มคนให้กับโปรเจกต์ซอฟต์แวร์ที่ล่าช้าทำให้มันล่าช้ายิ่งขึ้น การรักษาที่ดีที่สุดคือของ Abdel-Hamid และ Madnick ในหนังสือที่ ambitious และมีคุณค่าของพวกเขาในปี 1991 Software Project Dynamics: An Integrated Approach . [17] หนังสือเล่มนี้พัฒนาโมเดลเชิงปริมาณของ dynamics ของโปรเจกต์ บทของพวกเขาเกี่ยวกับ Brooks's Law ให้ insight ที่มีรายละเอียดมากขึ้นเกี่ยวกับสิ่งที่เกิดขึ้นภายใต้สมมติฐานต่างๆ ว่ามีการเพิ่มคนที่ไหนและเมื่อไหร่ ในการตรวจสอบนี้ ผู้เขียนขยายโมเดลที่รอบคอบของตนเองของโปรเจกต์แอปพลิเคชันขนาดกลางโดยสมมติว่าคนใหม่มีเส้นโค้งการเรียนรู้และการคำนวณงานสื่อสารและการฝึกอบรมเพิ่มเติม พวกเขาสรุปว่า "การเพิ่มคนให้กับโปรเจกต์ที่ล่าช้านั้นทำให้มีต้นทุนมากขึ้นเสมอ แต่มันไม่ได้ทำให้เสร็จช้าลง เสมอไป [ตัวเอียงตามต้นฉบับ]" โดยเฉพาะ การเพิ่มคนเสริมในช่วงต้นของตารางเวลาเป็นกลยุทธ์ที่ปลอดภัยกว่าการเพิ่มภายหลังมาก เนื่องจากคนใหม่มักมีผลกระทบเชิงลบทันทีซึ่งต้องใช้เวลาหลายสัปดาห์ในการชดเชย
Stutzke พัฒนาโมเดลที่ง่ายกว่าเพื่อทำการตรวจสอบที่คล้ายกัน โดยมีผลลัพธ์ที่คล้ายกัน [18] เขาพัฒนาการวิเคราะห์โดยละเอียดของกระบวนการและต้นทุนในการ assimilate คนทำงานใหม่ รวมถึงการ divert ที่ปรึกษาของพวกเขาจากงานโปรเจกต์เองอย่างชัดเจน เขาทดสอบโมเดลของเขากับโปรเจกต์จริงที่เพิ่มกำลังคนสำเร็จเป็นสองเท่าและบรรลุตารางเวลาเดิม หลังจากล่าช้ากลางโปรเจกต์ เขาจัดการกับทางเลือกอื่นนอกเหนือจากการเพิ่มโปรแกรมเมอร์ โดยเฉพาะการทำงานล่วงเวลา สิ่งที่มีค่าที่สุดคือคำแนะนำเชิงปฏิบัติมากมายของเขาเกี่ยวกับวิธีการเพิ่มคนทำงานใหม่ ฝึกอบรม สนับสนุนด้วยเครื่องมือ ฯลฯ เพื่อลดผลกระทบที่ disruptive ของการเพิ่มพวกเขา โดยเฉพาะอย่างยิ่งที่น่าสังเกตคือความเห็นของเขาที่ว่าคนใหม่ที่เพิ่มเข้ามาช้าในโปรเจกต์พัฒนาต้องเป็นผู้เล่นทีมที่เต็มใจลงมือและทำงานภายในกระบวนการ และไม่พยายามเปลี่ยนแปลงหรือปรับปรุงกระบวนการเอง!
Stutzke เชื่อว่าภาระเพิ่มเติมของการสื่อสารในโปรเจกต์ที่ใหญ่กว่าเป็นเอฟเฟกต์อันดับสองและไม่ได้จำลองมัน ไม่ชัดเจนว่า Abdel-Hamid และ Madnick นำมันมาพิจารณาหรือไม่และอย่างไร โมเดลทั้งสองไม่ได้คำนึงถึงความจริงที่ว่างานต้องถูกแบ่งส่วนใหม่ ซึ่งเป็นกระบวนการที่ผมมักพบว่าไม่ใช่เรื่องเล็กน้อย
คำกล่าวที่ "ทำให้เรียบง่ายอย่างเกินเหตุ" ของ Brooks's Law ทำให้มีประโยชน์มากขึ้นโดยการรักษาที่รอบคอบเกี่ยวกับ qualifications ที่เหมาะสม โดยรวมแล้ว ผมยืนหยัดกับคำกล่าวเปล่าๆ ว่าเป็น approximation อันดับศูนย์ที่ดีที่สุดของความจริง กฎทั่วไปเพื่อเตือนผู้จัดการไม่ให้ทำการแก้ไขตามสัญชาตญาณอย่างมืดบอดกับโปรเจกต์ที่ล่าช้า
People Are Everything (Well, Almost Everything) (คนคือทุกสิ่ง (เกือบทุกอย่าง))
ผู้อ่านบางคนพบว่ามันน่าสนใจที่ The MM-M อุทิศบทความส่วนใหญ่ให้กับแง่มุมการจัดการของวิศวกรรมซอฟต์แวร์ มากกว่าประเด็นทางเทคนิคมากมาย อคตินี้ส่วนหนึ่งมาจากธรรมชาติของบทบาทของผมใน IBM Operating System/360 (ปัจจุบันคือ MVS/370) โดยพื้นฐานแล้ว มันเกิดจากความเชื่อมั่นว่าคุณภาพของคนในโปรเจกต์ และการจัดองค์กรและการจัดการของพวกเขา เป็นปัจจัยที่สำคัญต่อความสำเร็จมากกว่าเครื่องมือที่พวกเขาใช้หรือแนวทางเทคนิคที่พวกเขาใช้
งานวิจัยต่อมาได้สนับสนุนความเชื่อมั่นนั้น โมเดล COCOMO ของ Boehm พบว่าคุณภาพของทีมเป็นปัจจัยที่ใหญ่ที่สุดในความสำเร็จของมัน มากกว่าปัจจัยถัดไปถึงสี่เท่า งานวิจัยทางวิชาการส่วนใหญ่เกี่ยวกับวิศวกรรมซอฟต์แวร์เน้นที่เครื่องมือ ผมชื่นชมและปรารถนาเครื่องมือที่คม แต่กระนั้นก็เป็นกำลังใจที่ได้เห็นความพยายามวิจัยอย่างต่อเนื่องเกี่ยวกับการดูแล การเติบโต และการเลี้ยงดูคน และเกี่ยวกับ dynamics ของการจัดการซอฟต์แวร์
Peopleware. ผลงานสำคัญในช่วงปีที่ผ่านมาคือหนังสือของ DeMarco และ Lister ในปี 1987 Peopleware: Productive Projects and Teams วิทยานิพนธ์พื้นฐานของมันคือ "ปัญหาหลักของงานเราไม่ใช่ เทคโนโลยี แต่เป็น สังคมวิทยา ในธรรมชาติ" มันเต็มไปด้วยอัญมณีอย่างเช่น "หน้าที่ของผู้จัดการไม่ใช่การทำให้คนทำงาน แต่มันคือการทำให้คนสามารถทำงานได้" มันจัดการกับหัวข้อทั่วไปอย่างพื้นที่ เฟอร์นิเจอร์ การกินข้าวร่วมกันของทีม DeMarco และ Lister ให้ข้อมูลจริงจาก Coding War Games ของพวกเขาที่แสดงความสัมพันธ์ที่ stunning ระหว่างประสิทธิภาพของโปรแกรมเมอร์จากองค์กรเดียวกัน และระหว่างลักษณะสถานที่ทำงานกับทั้ง productivity และระดับข้อบกพร่อง
พื้นที่ของผู้ที่มีประสิทธิภาพสูงสุดเงียบกว่า เป็นส่วนตัวกว่า ป้องกันการรบกวนได้ดีกว่า และมีมากกว่า... มันสำคัญสำหรับคุณจริงหรือ... ว่าความเงียบ พื้นที่ และความเป็นส่วนตัวช่วยให้คนของคุณทำงานได้ดีขึ้นหรือ [ หรืออีกทางหนึ่ง ] ช่วยให้คุณดึงดูดและรักษาคนที่ดีกว่าไว้? [19]
ผมขอแนะนำหนังสือเล่มนี้อย่างเต็มที่แก่ผู้อ่านทุกคน
Moving projects (การย้ายโปรเจกต์). DeMarco และ Lister ให้ความสนใจอย่างมากกับ การหลอมรวม ของทีม ซึ่งเป็นคุณสมบัติที่จับต้องไม่ได้แต่สำคัญ ผมคิดว่าที่ผู้จัดการมองข้ามการหลอมรวมนี้เองที่ทำให้เกิดความพร้อมที่ผมสังเกตเห็นในบริษัทที่มีหลายสถานที่ในการย้ายโปรเจกต์จากห้องปฏิบัติการหนึ่งไปยังอีกห้องปฏิบัติการหนึ่ง
ประสบการณ์และการสังเกตของผมจำกัดอยู่ที่การย้ายประมาณครึ่งโหล ผมไม่เคยเห็นการย้ายที่ประสบความสำเร็จสักครั้ง เราสามารถย้าย ภารกิจ ได้สำเร็จ แต่ในทุกกรณีของความพยายามย้ายโปรเจกต์ ทีมใหม่จริงๆ แล้วเริ่มต้นใหม่ แม้จะมีเอกสารที่ดี การออกแบบที่ก้าวหน้าไปบ้าง และคนบางส่วนจากทีมที่ส่งมา ผมคิดว่ามันคือการทำลายการหลอมรวมของทีมเก่าที่ทำให้ผลิตภัณฑ์ที่กำลังตั้งครรภ์แท้ง และทำให้เกิดการเริ่มต้นใหม่
The Power of Giving Up Power (พลังแห่งการสละอำนาจ)
ถ้าเราเชื่อ อย่างที่ผมโต้แย้งในหลายที่ในหนังสือเล่มนี้ ว่าความคิดสร้างสรรค์มาจากบุคคล ไม่ใช่จากโครงสร้างหรือกระบวนการ แล้วคำถามหลักที่ผู้จัดการซอฟต์แวร์ต้องเผชิญคือวิธีออกแบบโครงสร้างและกระบวนการเพื่อเสริมสร้าง แทนที่จะยับยั้ง ความคิดสร้างสรรค์และความคิดริเริ่ม โชคดีที่ปัญหานี้ไม่ได้จำกัดเฉพาะองค์กรซอฟต์แวร์ และนักคิดผู้ยิ่งใหญ่ได้ทำงานเกี่ยวกับมัน E. F. Schumacher ในหนังสือคลาสสิกของเขา Small is Beautiful: Economics as if People Mattered เสนอทฤษฎีการจัดระเบียบองค์กรเพื่อเพิ่มความคิดสร้างสรรค์และความสุขของคนทำงานให้สูงสุด สำหรับหลักการแรก เขาเลือก "Principle of Subsidiary Function" จากสารตรา Quadragesimo Anno ของสมเด็จพระสันตะปาปาปิอุสที่ 11:
เป็นความอยุติธรรมและในขณะเดียวกันก็เป็นความชั่วร้ายร้ายแรงและการรบกวนระเบียบที่ถูกต้องที่จะมอบหมายให้สมาคมที่ใหญ่กว่าและสูงกว่าทำสิ่งที่องค์กรย่อยและรองลงมาสามารถทำได้ เพราะกิจกรรมทางสังคมทุกอย่างโดยธรรมชาติของมันควรให้ความช่วยเหลือแก่สมาชิกของร่างกายสังคม และไม่เคยทำลายและดูดซับพวกเขา... ผู้ที่อยู่ในคำสั่งควรแน่ใจว่ายิ่งรักษาลำดับชั้นอย่างสมบูรณ์แบบมากขึ้นในบรรดาสมาคมต่างๆ โดยการปฏิบัติตามหลักการของ subsidiary function มากเท่าไหร่ อำนาจทางสังคมและประสิทธิผลก็จะแข็งแกร่งมากขึ้น และสภาพของรัฐก็จะมีความสุขและเจริญรุ่งเรืองมากขึ้น [20]
Schumacher ตีความต่อ:
Principle of Subsidiary Function สอนเราว่าศูนย์กลางจะได้รับอำนาจและประสิทธิผลมากขึ้นหากรักษาอิสรภาพและความรับผิดชอบของรูปแบบที่ต่ำกว่าไว้อย่างระมัดระวัง ซึ่งส่งผลให้องค์กรโดยรวมจะ "มีความสุขและเจริญรุ่งเรืองมากขึ้น"
โครงสร้างเช่นนี้จะบรรลุได้อย่างไร?... องค์กรขนาดใหญ่จะประกอบด้วยหน่วยกึ่งอิสระจำนวนมาก ซึ่งเราอาจเรียกว่า quasi-firms . แต่ละหน่วยจะมีอิสระอย่างมาก เพื่อให้โอกาสสูงสุดแก่ความคิดสร้างสรรค์และ entrepreneurship ... แต่ละ quasi-firm ต้องมีทั้งบัญชีกำไรขาดทุนและงบดุล [21]
หนึ่งในการพัฒนาที่น่าตื่นเต้นที่สุดในวิศวกรรมซอฟต์แวร์คือช่วงเริ่มต้นของการนำแนวคิดองค์กรดังกล่าวไปปฏิบัติ ประการแรก การปฏิวัติไมโครคอมพิวเตอร์สร้างอุตสาหกรรมซอฟต์แวร์ใหม่ของบริษัทสตาร์ทอัพร้อยแห่ง ซึ่งทั้งหมดเริ่มต้นเล็ก และโดดเด่นด้วยความกระตือรือร้น อิสระ และความคิดสร้างสรรค์ อุตสาหกรรมกำลังเปลี่ยนแปลงในขณะนี้ เนื่องจากบริษัทเล็กๆ จำนวนมากถูกซื้อกิจการโดยบริษัทที่ใหญ่กว่า ยังต้องรอดูว่าผู้ซื้อรายใหญ่จะเข้าใจความสำคัญของการรักษาความคิดสร้างสรรค์ของความเล็กหรือไม่
ที่น่าทึ่งยิ่งกว่านั้น ผู้บริหารระดับสูงในบริษัทใหญ่บางแห่งได้ดำเนินการมอบอำนาจลงไปสู่ทีมโปรเจกต์ซอฟต์แวร์แต่ละทีม ทำให้พวกเขาเข้าใกล้ quasi-firms ของ Schumacher ในโครงสร้างและความรับผิดชอบ พวกเขาประหลาดใจและ delighted กับผลลัพธ์
Jim McCarthy แห่ง Microsoft อธิบายประสบการณ์ของเขาในการปลดปล่อยทีมของเขา:
ทีมฟีเจอร์แต่ละทีม (30–40 คน) เป็นเจ้าของชุดฟีเจอร์ของมัน ตารางเวลาของมัน และแม้แต่กระบวนการของมันในการกำหนด สร้าง ส่งมอบ ทีมประกอบด้วยสี่หรือห้าความเชี่ยวชาญพิเศษ รวมถึงการสร้าง การทดสอบ และการเขียน ทีมจัดการข้อพิพาท; เจ้านายไม่จัดการ ผมไม่สามารถเน้นย้ำมากพอถึงความสำคัญของการ empowerment ของทีมที่รับผิดชอบต่อตนเองเพื่อความสำเร็จของมัน
Earl Wheeler หัวหน้าฝ่ายธุรกิจซอฟต์แวร์ของ IBM ที่เกษียณแล้ว เล่าประสบการณ์ของเขาในการดำเนินการมอบอำนาจลงล่างที่เคยรวมศูนย์ในฝ่ายบริหารของ IBM:
แนวรุกสำคัญ [ ในปีที่ผ่านมา ] คือการมอบอำนาจลงล่าง มันเหมือนกับเวทมนตร์! คุณภาพดีขึ้น productivity ดีขึ้น ขวัญกำลังใจดีขึ้น เรามีทีมเล็กๆ โดยไม่มีการควบคุมจากส่วนกลาง ทีมเป็นเจ้าของกระบวนการ แต่พวกเขาต้องมีกระบวนการหนึ่ง พวกเขามีกระบวนการที่แตกต่างกันมากมาย พวกเขาเป็นเจ้าของตารางเวลา แต่พวกเขารู้สึกถึงแรงกดดันของตลาด แรงกดดันนี้ทำให้พวกเขาแสวงหาเครื่องมือด้วยตัวเอง
แน่นอนว่าการสนทนากับสมาชิกทีมแต่ละคนแสดงให้เห็นทั้งความซาบซึ้งในอำนาจและอิสระที่ได้รับมอบหมาย และการประเมินที่ค่อนข้างอนุรักษ์นิยมมากขึ้นว่ามีการควบคุมเท่าไหร่ที่ถูกมอบให้จริง อย่างไรก็ตาม การมอบอำนาจที่ทำได้นั้นชัดเจนว่าเป็นก้าวไปในทิศทางที่ถูกต้อง มันให้ผลลัพธ์ตามที่ Pius XI ทำนายไว้ทุกประการ: ศูนย์กลางได้รับอำนาจที่แท้จริงโดยการมอบอำนาจ และองค์กรโดยรวมก็มีความสุขและเจริญรุ่งเรืองมากขึ้น
What's the Biggest New Surprise? Millions of Computers (ความประหลาดใจใหม่ที่ใหญ่ที่สุดคืออะไร? คอมพิวเตอร์นับล้านเครื่อง)
ทุก guru ซอฟต์แวร์ที่ผมคุยด้วยยอมรับว่าถูกจับให้ประหลาดใจกับการปฏิวัติไมโครคอมพิวเตอร์และผลพลอยได้ของมัน อุตสาหกรรมซอฟต์แวร์แบบ shrink-wrapped นี่คือไม่ต้องสงสัยเลยว่าการเปลี่ยนแปลงที่สำคัญของสองทศวรรษนับตั้งแต่ The MM-M มันมีผลกระทบมากมายต่อวิศวกรรมซอฟต์แวร์
การปฏิวัติไมโครคอมพิวเตอร์เปลี่ยนวิธีที่ทุกคนใช้คอมพิวเตอร์ Schumacher กล่าวถึงความท้าทายนี้เมื่อกว่า 20 ปีที่แล้ว:
สิ่งที่เราต้องการจริงๆ จากนักวิทยาศาสตร์และนักเทคโนโลยี? ผมควรตอบ: เราต้องการวิธีการและอุปกรณ์ที่
• ถูกพอที่จะเข้าถึงได้กับเกือบทุกคน;
• เหมาะสมสำหรับการประยุกต์ใช้ขนาดเล็ก; และ
• เข้ากันได้กับความต้องการความคิดสร้างสรรค์ของมนุษย์ [22]
เหล่านี้คือคุณสมบัติที่ยอดเยี่ยมที่การปฏิวัติไมโครคอมพิวเตอร์นำมาสู่อุตสาหกรรมคอมพิวเตอร์และผู้ใช้ของมัน ซึ่งปัจจุบันคือประชาชนทั่วไป คนอเมริกันโดยเฉลี่ยสามารถซื้อได้ไม่เพียงคอมพิวเตอร์ของตัวเอง แต่ยังมีชุดซอฟต์แวร์ที่เมื่อ 20 ปีก่อนคงมีราคาเท่ากับเงินเดือนของกษัตริย์ เป้าหมายของ Schumacher แต่ละข้อคุ้มค่าแก่การพิจารณา; ระดับที่แต่ละข้อบรรลุนั้นคุ้มค่าแก่การซาบซึ้ง โดยเฉพาะข้อสุดท้าย ในพื้นที่แล้วพื้นที่เล่า วิธีการแสดงออกใหม่ๆ เข้าถึงได้สำหรับคนธรรมดาเช่นเดียวกับมืออาชีพ
ส่วนหนึ่งการเสริมสร้างนี้มาในสาขาอื่นๆ เช่นเดียวกับที่เกิดขึ้นในการสร้างซอฟต์แวร์—ในการขจัดความยากลำบากโดยบังเอิญ ต้นฉบับที่เขียนด้วยลายมือเคยถูกทำให้แข็งทื่อโดยบังเอิญจากเวลาและค่าใช้จ่ายในการพิมพ์ซ้ำเพื่อรวมการเปลี่ยนแปลง ในงาน 300 หน้า เราอาจต้องพิมพ์ซ้ำทุกสามถึงหกเดือน แต่ในระหว่างนั้นก็แค่ขีดเขียนต้นฉบับต่อไป เราไม่สามารถประเมินได้ง่ายๆ ว่าการเปลี่ยนแปลงได้ทำอะไรกับกระแสของตรรกะและจังหวะของคำพูด ตอนนี้ ต้นฉบับกลายเป็นของเหลวอย่างน่าอัศจรรย์ [23]
คอมพิวเตอร์ได้นำความลื่นไหลที่คล้ายกันมาสู่สื่ออื่นๆ มากมาย: ภาพวาดศิลปะ แผนผังอาคาร ภาพวาดทางกล บทประพันธ์ดนตรี ภาพถ่าย ลำดับวิดีโอ งานนำเสนอสไลด์ งานมัลติมีเดีย และแม้แต่สเปรดชีต ในแต่ละกรณี วิธีการผลิตด้วยมือจำเป็นต้องคัดลอกส่วนที่ไม่เปลี่ยนแปลงที่เทอะทะเพื่อให้เห็นการเปลี่ยนแปลงในบริบท ตอนนี้เรา enjoy สำหรับแต่ละสื่อถึงประโยชน์เดียวกันที่ time-sharing นำมาสู่การสร้างซอฟต์แวร์—ความสามารถในการแก้ไขและประเมินผลทันทีโดยไม่สูญเสีย train of thought
ความคิดสร้างสรรค์ยังถูกเสริมสร้างโดยเครื่องมือเสริมใหม่ๆ ที่ยืดหยุ่น สำหรับการผลิตร้อยแก้ว เป็นตัวอย่างหนึ่ง ตอนนี้เรามี spelling checkers, grammar checkers, style advisors, ระบบบรรณานุกรม และความสามารถที่ remarkable ในการเห็นหน้าพร้อมกันถูกจัดรูปแบบเป็นเลย์เอาต์สุดท้าย เรายังไม่ชื่นชมว่าสารานุกรมทันทีหรือทรัพยากรที่ไม่มีที่สิ้นสุดของ World-Wide Web จะมีความหมายอย่างไรต่อการวิจัยกะทันหันของนักเขียน
ที่สำคัญที่สุด ความลื่นไหลใหม่ของสื่อทำให้การสำรวจทางเลือกที่แตกต่างอย่าง radical เป็นเรื่องง่ายเมื่องานสร้างสรรค์กำลังเป็นรูปเป็นร่าง นี่เป็นอีกกรณีที่ลำดับความสำคัญในพารามิเตอร์เชิงปริมาณ ที่นี่คือเวลาเปลี่ยนแปลง ทำให้เกิดความแตกต่างเชิงคุณภาพในวิธีที่เราดำเนินงาน
เครื่องมือสำหรับการวาดภาพช่วยให้นักออกแบบอาคารสำรวจตัวเลือกมากขึ้นต่อชั่วโมงของการลงทุนสร้างสรรค์ การเชื่อมต่อคอมพิวเตอร์กับซินธิไซเซอร์ พร้อมซอฟต์แวร์สำหรับสร้างหรือเล่นโน้ตดนตรีโดยอัตโนมัติ ทำให้การจับการเคาะคีย์บอร์ดแบบเล่นๆ ง่ายขึ้นมาก การจัดการภาพถ่ายดิจิทัล เช่นกับ Adobe Photoshop ช่วยให้การทดลองที่ใช้เวลาไม่กี่นาทีซึ่งในห้องมืดอาจใช้เวลาหลายชั่วโมง สเปรดชีตช่วยให้การสำรวจสถานการณ์ "what if" หลายสิบแบบเป็นเรื่องง่าย
สุดท้าย สื่อสร้างสรรค์ใหม่ทั้งหมดถูก enable โดยความแพร่หลายของคอมพิวเตอร์ส่วนบุคคล Hypertexts ที่เสนอโดย Vannevar Bush ในปี 1945 ใช้การได้จริงกับคอมพิวเตอร์เท่านั้น [24] งานนำเสนอมัลติมีเดียและประสบการณ์เป็นเรื่องใหญ่—ยุ่งยากเกินไป—ก่อนคอมพิวเตอร์ส่วนบุคคลและซอฟต์แวร์ที่ร่ำรวยและราคาถูกที่มีให้สำหรับมัน ระบบ Virtual-environment ยังไม่ถูกหรือแพร่หลาย แต่จะกลายเป็น และจะเป็นสื่อสร้างสรรค์อีกสื่อหนึ่ง
การปฏิวัติไมโครคอมพิวเตอร์เปลี่ยนวิธีสร้างซอฟต์แวร์ของทุกคน กระบวนการซอฟต์แวร์ในยุค 1970 เองก็ถูกเปลี่ยนแปลงโดยการปฏิวัติไมโครโพรเซสเซอร์และความก้าวหน้าทางเทคโนโลยีที่ enable มัน ความยากลำบากโดยบังเอิญหลายอย่างของกระบวนการสร้างซอฟต์แวร์เหล่านั้นถูกกำจัด คอมพิวเตอร์ส่วนบุคคลที่เร็วกลายเป็นเครื่องมือประจำของนักพัฒนาซอฟต์แวร์ ดังนั้น turnaround time จึงเป็นแนวคิดที่เกือบล้าสมัย คอมพิวเตอร์ส่วนบุคคลในปัจจุบันไม่เพียงเร็วกว่าซูเปอร์คอมพิวเตอร์ในปี 1960 แต่มันเร็วกว่าเวิร์กสเตชัน Unix ในปี 1985 ด้วย ทั้งหมดนี้หมายความว่าการคอมไพล์เร็ว even บนเครื่องที่ต่ำต้อยที่สุด และหน่วยความจำขนาดใหญ่ได้กำจัดการรอสำหรับ disk-based linking หน่วยความจำขนาดใหญ่ยังทำให้การเก็บ symbol tables ไว้ในหน่วยความจำพร้อม object code เป็นเรื่องที่สมเหตุสมผล ดังนั้น high-level debugging โดยไม่ต้องคอมไพล์ใหม่จึงเป็นเรื่องปกติ
ใน 20 ปีที่ผ่านมา เราได้ผ่านพ้นการใช้ time-sharing ในฐานะวิธีวิทยาสำหรับการสร้างซอฟต์แวร์มาเกือบสมบูรณ์ ในปี 1975 time-sharing เพิ่งแทนที่ batch computing เป็นเทคนิคที่พบบ่อยที่สุด เครือข่ายถูกใช้เพื่อให้นักสร้างซอฟต์แวร์เข้าถึงทั้งแฟ้มที่ shared และเครื่องมือที่ทรงพลังที่ shared สำหรับการคอมไพล์ การ linking และการทดสอบ วันนี้ เวิร์กสเตชันส่วนบุคคลให้เครื่องมือคำนวณ และเครือข่ายส่วนใหญ่ให้การเข้าถึง shared file ที่เป็น work-product ที่กำลังพัฒนาของทีม ระบบ Client-server ทำให้การเข้าถึง shared ต่อ check-in, build, และการใช้เทสเคสเป็นกระบวนการที่แตกต่างและง่ายขึ้น
ความก้าวหน้าที่คล้ายกันในอินเทอร์เฟซผู้ใช้ก็เกิดขึ้น อินเทอร์เฟซ WIMP ให้การแก้ไขข้อความโปรแกรมที่สะดวกกว่ามากเช่นเดียวกับข้อความภาษาอังกฤษ หน้าจอ 24 บรรทัด 72 คอลัมน์ถูกแทนที่ด้วยหน้าจอเต็มหน้าหรือ even หน้าจอสองหน้า ดังนั้นโปรแกรมเมอร์สามารถเห็นบริบทมากขึ้นสำหรับการเปลี่ยนแปลงที่พวกเขากำลังทำ [25]
Whole New Software Industry—Shrink-Wrapped Software (อุตสาหกรรมซอฟต์แวร์ใหม่ทั้งอุตสาหกรรม—ซอฟต์แวร์แบบ Shrink-Wrapped)
ข้างเคียงอุตสาหกรรมซอฟต์แวร์คลาสสิก ได้มีการระเบิดขึ้นอีกอุตสาหกรรมหนึ่ง ยอดขายผลิตภัณฑ์ต่อหน่วยอยู่ที่หลายแสน even หลายล้าน แพ็คเกจซอฟต์แวร์ที่สมบูรณ์และร่ำรวยสามารถมีได้ในราคาต่ำกว่าต้นทุนของโปรแกรมเมอร์ที่ได้รับการสนับสนุนหนึ่งวัน อุตสาหกรรมทั้งสองแตกต่างกันในหลายๆ ด้าน และพวกมันอยู่ร่วมกัน
อุตสาหกรรมซอฟต์แวร์คลาสสิก ในปี 1975 อุตสาหกรรมซอฟต์แวร์มีองค์ประกอบที่ระบุได้และค่อนข้างแตกต่างหลายอย่าง ซึ่งทั้งหมดยังคงมีอยู่ในปัจจุบัน:
• ผู้ผลิตคอมพิวเตอร์ ซึ่งจัดหาระบบปฏิบัติการ คอมไพเลอร์ และยูทิลิตี้สำหรับผลิตภัณฑ์ของตน
• ผู้ใช้แอปพลิเคชัน เช่น แผนก MIS ของสาธารณูปโภค ธนาคาร บริษัทประกันภัย และหน่วยงานรัฐบาล ซึ่งสร้างแพ็คเกจแอปพลิเคชันสำหรับใช้เอง
• ผู้สร้างแอปพลิเคชันตามสั่ง ซึ่งทำสัญญาสร้างแพ็คเกจที่เป็นกรรมสิทธิ์สำหรับผู้ใช้ หลายคนรับเหมาเหล่านี้เชี่ยวชาญด้านแอปพลิเคชันป้องกันประเทศ ซึ่งข้อกำหนด มาตรฐาน และขั้นตอนการตลาดนั้น peculiar
• นักพัฒนาแพ็คเกจเชิงพาณิชย์ ซึ่งในเวลานั้นส่วนใหญ่พัฒนาแอปพลิเคชันขนาดใหญ่สำหรับตลาดเฉพาะ เช่น แพ็คเกจวิเคราะห์ทางสถิติและระบบ CAD
Tom DeMarco สังเกตการแตกเป็นเสี่ยงของอุตสาหกรรมซอฟต์แวร์คลาสสิก โดยเฉพาะองค์ประกอบผู้ใช้แอปพลิเคชัน:
สิ่งที่ผมไม่ได้คาดหวัง: สาขาได้แบ่งส่วนเป็น niches วิธีการที่คุณทำอะไรบางอย่างเป็นฟังก์ชันของ niche มากกว่าการใช้วิธีวิเคราะห์ระบบทั่วไป ภาษาทั่วไป และเทคนิคการทดสอบทั่วไป Ada เป็นภาษาจุดประสงค์ทั่วไปภาษาสุดท้าย และมันกลายเป็นภาษาเฉพาะ niche
ใน niche แอปพลิเคชันเชิงพาณิชย์ประจำ ภาษา fourth-generation ได้สร้างคุณูปการที่ทรงพลัง Boehm กล่าวว่า "4GL ที่ประสบความสำเร็จส่วนใหญ่เป็นผลมาจากการที่ใครสักคน codify ส่วนหนึ่งของ application domain ในรูปของตัวเลือกและพารามิเตอร์" 4GL ที่แพร่หลายที่สุดคือ application generator และแพ็คเกจ database-communications แบบรวมที่มีภาษาสืบค้น
โลกของระบบปฏิบัติการได้รวมตัวกัน ในปี 1975 ระบบปฏิบัติการมีอยู่มากมาย: ผู้ผลิตฮาร์ดแวร์ทุกรายมีระบบปฏิบัติการที่เป็นกรรมสิทธิ์อย่างน้อยหนึ่งระบบต่อกลุ่มผลิตภัณฑ์ หลายรายมีสองระบบ ทุกวันนี้แตกต่างกันมาก! ระบบเปิดเป็นคำสำคัญ และมีสภาพแวดล้อมระบบปฏิบัติการที่สำคัญเพียงห้าแห่งที่คนนำแพ็คเกจแอปพลิเคชันออกสู่ตลาด (ตามลำดับเวลา):
• สภาพแวดล้อม IBM MVS และ VM
• สภาพแวดล้อม DEC VMS
• สภาพแวดล้อม Unix ในรูปแบบใดรูปแบบหนึ่ง
• สภาพแวดล้อม IBM PC ไม่ว่าจะเป็น DOS, OS-2 หรือ Windows
• สภาพแวดล้อม Apple Macintosh
อุตสาหกรรม shrink-wrapped สำหรับนักพัฒนาในอุตสาหกรรม shrink-wrapped เศรษฐศาสตร์แตกต่างอย่างสิ้นเชิงจากอุตสาหกรรมคลาสสิก: ต้นทุนการพัฒนาถูกหารด้วยปริมาณมาก ต้นทุนการบรรจุและการตลาดเป็นสัดส่วนที่ใหญ่ ในอุตสาหกรรมพัฒนาแอปพลิเคชันภายในองค์กรแบบคลาสสิก ตารางเวลาและรายละเอียดของฟังก์ชันสามารถต่อรองได้ ต้นทุนการพัฒนาอาจจะไม่; ในตลาดเปิดที่แข่งขันอย่างรุนแรง ตารางเวลาและฟังก์ชันครอบงำต้นทุนการพัฒนาอย่างชัดเจน
อย่างที่คาดไว้ เศรษฐศาสตร์ที่แตกต่างอย่าง stark ได้ก่อให้เกิดวัฒนธรรมการเขียนโปรแกรมที่ค่อนข้างแตกต่าง อุตสาหกรรมคลาสสิกมักถูกครอบงำโดยบริษัทขนาดใหญ่ที่มีรูปแบบการจัดการและวัฒนธรรมการทำงานที่ established ในทางกลับกัน อุตสาหกรรม shrink-wrapped เริ่มต้นเป็นสตาร์ทอัพร้อยแห่ง ดำเนินการอย่างอิสระและมุ่งเน้นอย่างรุนแรงที่การทำงานให้สำเร็จมากกว่ากระบวนการ ในบรรยากาศนี้ มีการยอมรับความสามารถของโปรแกรมเมอร์แต่ละคนมากกว่าเสมอ การรับรู้โดยนัยว่าการออกแบบที่ยอดเยี่ยมมาจากนักออกแบบที่ยอดเยี่ยม วัฒนธรรมสตาร์ทอัพมีความสามารถในการให้รางวัลดาราที่มีผลงานตามสัดส่วนของผลงานของพวกเขา; ในอุตสาหกรรมซอฟต์แวร์คลาสสิก สังคมวิทยาของบริษัทและแผนการจัดการเงินเดือนของพวกเขาทำให้เรื่องนี้ยากเสมอ ไม่น่าแปลกใจที่ดาราหลายคนของรุ่นใหม่ได้ gravitate ไปสู่อุตสาหกรรม shrink-wrapped
Buy and Build—Shrink-Wrapped Packages As Components (ซื้อ และ สร้าง—แพ็คเกจ Shrink-Wrapped ในฐานะคอมโพเนนต์)
ความ robust และ productivity ของซอฟต์แวร์ที่ดีขึ้นอย่าง radical สามารถทำได้โดยการเลื่อนระดับขึ้น และสร้างโปรแกรมโดยการประกอบของโมดูล หรือออบเจกต์ แนวโน้มที่มีแนวโน้มโดยเฉพาะคือการใช้แพ็คเกจตลาดมวลชนเป็นแพลตฟอร์มที่สร้างผลิตภัณฑ์ที่สมบูรณ์กว่าและปรับแต่งได้มากกว่า ระบบติดตามรถบรรทุกสร้างบน database และแพ็คเกจการสื่อสารแบบ shrink-wrapped; ระบบข้อมูลนักศึกษาก็เช่นกัน โฆษณาต้องการในนิตยสารคอมพิวเตอร์เสนอ Hypercard stacks และ templates ที่ปรับแต่งสำหรับ Excel หลายร้อยรายการ ฟังก์ชันพิเศษใน Pascal สำหรับ MiniCad หรือฟังก์ชันใน AutoLisp สำหรับ AutoCad
Metaprogramming. การสร้าง Hypercard stacks, Excel templates, หรือ MiniCad functions บางครั้งเรียกว่า metaprogramming การสร้างชั้นใหม่ที่ปรับแต่งฟังก์ชันสำหรับสับเซตของผู้ใช้แพ็คเกจ แนวคิด metaprogramming ไม่ใช่เรื่องใหม่ แค่ฟื้นคืนและถูกเปลี่ยนชื่อ ในช่วงต้นทศวรรษ 1960 ผู้ผลิตคอมพิวเตอร์และร้าน MIS ขนาดใหญ่หลายแห่งมีกลุ่มผู้เชี่ยวชาญขนาดเล็กที่สร้างภาษาโปรแกรมแอปพลิเคชันทั้งภาษาจากมาโครใน assembly language ร้าน MIS ของ Eastman Kodak มีภาษาแอปพลิเคชันภายในบ้านที่กำหนดบน IBM 7080 macroassembler เช่นเดียวกับ OS/360 Queued Telecommunications Access Method ของ IBM เราสามารถอ่านหลายหน้าของโปรแกรมโทรคมนาคม assembly language ที่เสมือนจริงก่อนที่จะเจอ instruction ระดับเครื่อง ขณะนี้ chunk ที่ metaprogrammer นำเสนอมีขนาดใหญ่กว่ามาโครเหล่านั้นหลายเท่า การพัฒนาตลาดรองนี้เป็นสิ่งที่น่าปลื้มใจที่สุด—ในขณะที่เรารอคอยที่จะเห็นตลาดที่มีประสิทธิภาพใน C++ classes เกิดขึ้น ตลาดของ metaprograms ที่ใช้ซ้ำได้ได้เติบโตขึ้นโดยไม่ถูกสังเกต
นี่โจมตี essence จริงๆ เพราะปรากฏการณ์ build-on-package ในปัจจุบันไม่ส่งผลต่อโปรแกรมเมอร์ MIS โดยเฉลี่ย มันจึงยังไม่ชัดเจนนักต่อวินัยวิศวกรรมซอฟต์แวร์ อย่างไรก็ตาม มันจะเติบโตอย่างรวดเร็ว เพราะมันโจมตี essence ของการสร้าง conceptual constructs แพ็คเกจ shrink-wrapped ให้โมดูลฟังก์ชันขนาดใหญ่ พร้อมอินเทอร์เฟซที่ elaborate แต่เหมาะสม และโครงสร้างแนวคิดภายในของมันไม่ต้องถูกออกแบบเลย ผลิตภัณฑ์ซอฟต์แวร์ที่มีฟังก์ชันสูง เช่น Excel หรือ 4th Dimension เป็นโมดูลขนาดใหญ่จริงๆ แต่มันทำหน้าที่เป็นโมดูลที่รู้จัก มีเอกสาร ทดสอบแล้วสำหรับการสร้างระบบที่ปรับแต่งได้ ผู้สร้างแอปพลิเคชันระดับถัดไปได้รับความสมบูรณ์ของฟังก์ชัน เวลาการพัฒนาที่สั้นกว่า คอมโพเนนต์ที่ทดสอบแล้ว เอกสารที่ดีกว่า และต้นทุนที่ต่ำกว่าอย่าง radical
แน่นอนว่าความยากคือแพ็คเกจซอฟต์แวร์ shrink-wrapped ถูกออกแบบให้เป็น entity แบบ stand-alone ซึ่งฟังก์ชันและอินเทอร์เฟซที่ metaprogrammer ไม่สามารถเปลี่ยนแปลงได้ ยิ่งไปกว่านั้น และที่ร้ายแรงกว่า ผู้สร้างแพ็คเกจ shrink-wrapped ดูเหมือนจะมีแรงจูงใจเพียงเล็กน้อยในการทำให้ผลิตภัณฑ์ของตนเหมาะสมเป็นโมดูลในระบบที่ใหญ่กว่า ผมคิดว่าการรับรู้นั้นผิด ว่ามีตลาดที่ยังไม่ได้ถูกใช้ประโยชน์ในการจัดหาแพ็คเกจที่ออกแบบมาเพื่ออำนวยความสะดวกในการใช้งานของ metaprogrammer
แล้วต้องการอะไร? เราสามารถระบุผู้ใช้แพ็คเกจ shrink-wrapped ได้สี่ระดับ:
• ผู้ใช้แบบ as-is ซึ่งใช้งานแอปพลิเคชันในลักษณะตรงไปตรงมา พอใจกับฟังก์ชันและอินเทอร์เฟซที่นักออกแบบให้ไว้
• Metaprogrammer ผู้สร้าง templates หรือ functions บนแอปพลิเคชันเดียว โดยใช้อินเทอร์เฟซที่ให้ไว้ เพื่อประหยัดงานให้ผู้ใช้ปลายทางเป็นหลัก
• นักเขียนฟังก์ชันภายนอก ผู้เขียนโค้ดฟังก์ชันเพิ่มเติมด้วยมือลงในแอปพลิเคชัน สิ่งเหล่านี้คือ application language primitives ใหม่ที่เรียกใช้โมดูลโค้ดแยกต่างหากที่เขียนในภาษาจุดประสงค์ทั่วไป เราต้องการความสามารถในการเชื่อมต่อฟังก์ชันใหม่เหล่านี้กับแอปพลิเคชันในฐานะคำสั่งที่ถูก intercept, callbacks, หรือ overloaded functions
• Metaprogrammer ที่ใช้แอปพลิเคชันหนึ่ง หรือโดยเฉพาะหลายแอปพลิเคชันเป็นคอมโพเนนต์ในระบบที่ใหญ่กว่า นี่คือผู้ใช้ที่ความต้องการยังได้รับการตอบสนองไม่ดีในปัจจุบัน นี่ยังเป็นการใช้งานที่สัญญาว่าจะเพิ่มประสิทธิภาพอย่างมากในการสร้างแอปพลิเคชันใหม่
สำหรับผู้ใช้รายสุดท้ายนี้ แอปพลิเคชัน shrink-wrapped ต้องการอินเทอร์เฟซที่มีเอกสารเพิ่มเติม นั่นคือ metaprogramming interface (MPI) มันต้องการความสามารถหลายอย่าง ประการแรก metaprogram ต้องควบคุมกลุ่มของแอปพลิเคชัน ในขณะที่ปกติแล้วแต่ละแอปพลิเคชันจะถือว่ามันควบคุมอยู่เอง กลุ่มต้องควบคุมอินเทอร์เฟซผู้ใช้ ซึ่งปกติแอปพลิเคชันจะถือว่ามันกำลังทำอยู่ กลุ่มต้องสามารถเรียกใช้ฟังก์ชันแอปพลิเคชันใดๆ ราวกับว่าสตริงคำสั่งของมันมาจากผู้ใช้ มันควรได้รับผลลัพธ์จากแอปพลิเคชันราวกับว่ามันคือหน้าจอ ยกเว้นว่ามันต้องการผลลัพธ์ที่ถูก parse เป็นหน่วยตรรกะของ datatype ที่เหมาะสม แทนที่จะเป็นสตริงข้อความที่จะถูกแสดง แอปพลิเคชันบางตัว เช่น FoxPro มี wormholes ที่ให้เราส่งสตริงคำสั่งเข้าไปได้ แต่ข้อมูลที่ได้กลับมานั้น skimpy และไม่ได้ parse wormhole เป็นการแก้ไข เฉพาะกิจ สำหรับความต้องการที่ต้องการ solution ทั่วไปที่ออกแบบมา
การมี scripting language สำหรับควบคุม interaction ระหว่างกลุ่มของแอปพลิเคชันนั้นทรงพลัง Unix จัดหาฟังก์ชันประเภทนี้เป็นครั้งแรก ด้วย pipes และรูปแบบไฟล์ ASCII-string มาตรฐาน ปัจจุบัน AppleScript เป็นตัวอย่างที่ค่อนข้างดี
The State and Future of Software Engineering (สถานะและอนาคตของวิศวกรรมซอฟต์แวร์)
ผมเคยถาม Jim Ferrell ประธานภาควิชาวิศวกรรมเคมีที่ North Carolina State University ให้เล่าประวัติของวิศวกรรมเคมี ซึ่งแตกต่างจากเคมี เขาได้บรรยายอย่างยอดเยี่ยมแบบกะทันหันยาวหนึ่งชั่วโมง เริ่มจากการมีอยู่ตั้งแต่โบราณกาลของกระบวนการผลิตที่แตกต่างกันมากมายสำหรับผลิตภัณฑ์มากมาย ตั้งแต่เหล็กจนถึงขนมปังจนถึงน้ำหอม เขาเล่าว่า Professor Arthur D. Little ก่อตั้งภาควิชา Industrial Chemistry ที่ MIT ในปี 1918 เพื่อค้นหา พัฒนา และสอนฐานเทคนิคร่วมที่ใช้ร่วมกันในทุกกระบวนการ อันดับแรกคือกฎทั่วไป จากนั้นคือ nomograms เชิงประจักษ์ จากนั้นคือสูตรสำหรับการออกแบบคอมโพเนนต์เฉพาะ จากนั้นคือโมเดลทางคณิตศาสตร์สำหรับการถ่ายเทความร้อน การถ่ายเทมวล การถ่ายเทโมเมนตัมในภาชนะเดี่ยว
เมื่อเรื่องราวของ Ferrell คลี่คลาย ผมประทับใจกับความคล้ายคลึงหลายอย่างระหว่างการพัฒนาวิศวกรรมเคมีและการพัฒนาวิศวกรรมซอฟต์แวร์ เกือบห้าสิบปีต่อมา Parnas ตำหนิผมที่เขียนเกี่ยวกับ วิศวกรรมซอฟต์แวร์ เลย เขาเปรียบเทียบวินัยซอฟต์แวร์กับวิศวกรรมไฟฟ้าและรู้สึกว่ามันเป็นการ presumptuous ที่จะเรียกสิ่งที่เราทำว่าวิศวกรรม เขาอาจจะถูกว่าสาขานี้จะไม่พัฒนาเป็นวินัยทางวิศวกรรมที่มีฐานทางคณิตศาสตร์ที่แม่นยำและครอบคลุมทุกอย่างเช่นวิศวกรรมไฟฟ้า ท้ายที่สุดแล้ว วิศวกรรมซอฟต์แวร์ เช่นเดียวกับวิศวกรรมเคมี เกี่ยวข้องกับปัญหาที่ไม่เป็นเชิงเส้นของการขยายขนาดเป็นกระบวนการระดับอุตสาหกรรม และเช่นเดียวกับวิศวกรรมอุตสาหการ มันถูก confounded อย่างถาวรโดยความซับซ้อนของพฤติกรรมมนุษย์
อย่างไรก็ตาม แนวทางและช่วงเวลาของการพัฒนาวิศวกรรมเคมีทำให้ผมเชื่อว่าวิศวกรรมซอฟต์แวร์ที่อายุ 27 ปีอาจไม่สิ้นหวัง แต่เพียงยังไม่เติบโตเต็มที่ เช่นเดียวกับวิศวกรรมเคมีในปี 1945 เพียงหลังสงครามโลกครั้งที่สองที่วิศวกรเคมีจัดการกับพฤติกรรมของระบบไหลต่อเนื่องแบบ closed-loop interconnected อย่างจริงจัง
ข้อกังวลที่โดดเด่นของวิศวกรรมซอฟต์แวร์ในวันนี้คือสิ่งที่กำหนดไว้ใน Chapter 1 อย่างแท้จริง:
• วิธีออกแบบและสร้างชุดของโปรแกรมให้เป็น ระบบ
• วิธีออกแบบและสร้างโปรแกรมหรือระบบให้เป็น ผลิตภัณฑ์ ที่ robust, ทดสอบแล้ว, มีเอกสาร, และได้รับการสนับสนุน
• วิธีรักษาการควบคุมทางปัญญาเหนือ ความซับซ้อน ในปริมาณมาก
หลุมดักของวิศวกรรมซอฟต์แวร์จะยังคงเหนียวหนึบไปอีกนาน เราสามารถคาดหวังให้มนุษย์ยังคงพยายามสร้างระบบที่อยู่แค่เอื้อมหรือเกินเอื้อมของเรา; และระบบซอฟต์แวร์อาจเป็นสิ่งประดิษฐ์ที่ซับซ้อนที่สุดของมนุษย์ งานฝีมือที่ซับซ้อนนี้จะเรียกร้องให้เราพัฒนาวินัยอย่างต่อเนื่อง เรียนรู้การประกอบในหน่วยที่ใหญ่ขึ้น ใช้เครื่องมือใหม่อย่างดีที่สุด ปรับใช้วิธีการจัดการทางวิศวกรรมที่พิสูจน์แล้วอย่างดีที่สุด ใช้สามัญสำนึกอย่างเสรี และมีความถ่อมตนที่พระเจ้าประทานให้เพื่อตระหนักถึงความผิดพลาดและข้อจำกัดของเรา