ตัวอย่างที่ดีของแนวคิดหรือเทคนิคการพัฒนาซอฟต์แวร์ที่เป็นความล้มเหลวคืออะไร

โดยเฉพาะสิ่งที่เป็นตัวอย่างของความคิดของมวลชนที่ผิด ทำไมผู้คนถึงยึดความคิดไว้ตั้งแต่แรก และทำไมความคิดจึงถูกไล่ออก? หรืออาจเป็นความคิดที่ยังมีชีวิตอยู่และดีและถ้าเป็นเช่นนั้นทำไม?

เช่นฉันอาจอธิบายCORBA (และเทคโนโลยีที่คล้ายคลึงกันอื่น ๆ ) เป็นสิ่งที่พยายามแก้ปัญหาการสื่อสารระหว่างส่วนประกอบของซอฟต์แวร์ หลายคนรู้สึกว่าจำเป็นต้องกำหนดสัญญาระหว่างส่วนประกอบต่าง ๆ ท้ายที่สุด HTTP + JSON แก้ปัญหาสำหรับมวลชนและกลไก RPC อื่น ๆ เช่น Thrift และ Proto-bufs ได้ผุดขึ้นมา

โดยพื้นฐานเช่นเดียวกับในโลกภายนอกคอมพิวเตอร์ความคิดและเทคโนโลยีต่างแข่งขันกันเพื่อให้ความสนใจยกระดับและอื่น ๆ บ้างชนะบางคนแพ้บ้าง และบางคนอาจดูเหมือนจะเป็นผู้ชนะในบางเวลาจากนั้นจางหายไปสู่ความสับสนด้วยการปรากฎตัวของสิ่งที่ยิ่งใหญ่ต่อไป มันอาจจะมีหรือไม่มีอะไรเกี่ยวข้องซึ่งอันที่จริงแล้วก็ดีกว่า เป็นสักขีพยานใน VHS vs Betamax หรือสงครามครั้งล่าสุดระหว่างรูปแบบ DVD ต่างๆ

CORBA มีขนาดใหญ่อึดอัดและยากต่อการใช้งาน แต่มันก็เป็นสิ่งที่ดีที่สุดที่คนบางคนสามารถประดิษฐ์ได้ในเวลานั้น (โปรดทราบว่ามันถูกออกแบบมาก่อนเวิลด์ไวด์เว็บ - และ HTTP, Java, XML, ... - เป็นที่รู้จักอย่างกว้างขวาง) และมันก็เป็นตัวอย่างคลาสสิกของการออกแบบโดยคณะกรรมการที่พวกเขาอัดแน่นในทุกความคิดที่จะทำให้ทุกคนพอใจในที่สุดทำให้มันดูไร้ประโยชน์ (อย่างน้อยก็มองด้วยตาของวันนี้) ไม่ต้องพูดถึงราคาของมันซึ่งในไม่ช้าการถือกำเนิดของ FOSS ก็กลายเป็นสิ่งต้องห้าม

ท้ายที่สุด HTTP + JSON แก้ปัญหาสำหรับมวลชน

อย่างน้อยสำหรับคนที่ไม่ได้เห็น "การแก้ปัญหาขั้นสุดท้าย" ที่คล้ายกันเพิ่มขึ้นและล้มลงในที่สุด ... มันเป็นเรื่องดีที่จะระลึกไว้ว่ามีความรู้สึกคล้าย ๆ กันเกี่ยวกับ CORBA ในเวลา ;-)

ฉันรู้สึกว่ามันเหมาะที่จะอ้างอิงจากThe Rise and Fall of CORBA :

ประวัติของ CORBA เป็นสิ่งที่อุตสาหกรรมคอมพิวเตอร์ได้เห็นมาหลายครั้งและดูเหมือนว่าความพยายามของมิดเดิลแวร์ในปัจจุบันโดยเฉพาะบริการทางเว็บจะทำให้เกิดประวัติศาสตร์ที่คล้ายกันขึ้นมาใหม่ [ ... ]

โดยรวมแล้วกระบวนการที่ใช้เทคโนโลยีของ OMG ต้องถูกมองว่าเป็นเหตุผลหลักสำหรับการลดลงของ CORBA กระบวนการนี้ส่งเสริมการออกแบบโดยคณะกรรมการและการวางแผนทางการเมืองจนถึงจุดที่ยากที่จะบรรลุความธรรมดาทางเทคนิค ยิ่งไปกว่านั้นการเพิ่มคุณสมบัติที่แยกจากกันนำไปสู่การพังทลายของวิสัยทัศน์ทางสถาปัตยกรรมอย่างค่อยเป็นค่อยไป [ ... ]

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

ตอนนี้จากมุมที่แตกต่าง: เมื่ออ่านคำว่า "แนวคิดเรื่องมวลชน" ของคุณฉันคิดถึงสิ่งที่แตกต่างจาก CORBA หรือมาตรฐานอื่น ๆ สิ่งเหล่านี้มักเป็นความคิดของคนคนหนึ่งหรือกลุ่มเล็ก ๆ ฉันคิดเกี่ยวกับการปฏิบัติที่มีชื่อเสียง / มุมมองเช่น "โคบาลโคด", "รหัสและอธิษฐาน", "มันทำงานบนเครื่องของฉัน" ฯลฯ นี่เป็นแนวคิดของมวลชน "IMHO จริง ๆ เพราะนี่เป็นวิธีเริ่มต้นสำหรับผู้เริ่มต้นเกือบทุกคน นักพัฒนาเริ่มเขียนโค้ดโดยสัญชาตญาณ และพวกเขาก็ผิดเพราะพวกเขาไม่ได้ปรับขนาดในอวกาศหรือในเวลา - หนึ่งไม่สามารถสร้างโปรแกรมขนาดใหญ่ที่สามารถบำรุงรักษาและขยายได้ด้วยวิธีนี้ แต่ฉันรู้สึกว่าน่าเสียดายที่มันยังคงเป็นบรรทัดฐานมากกว่าที่จะเป็นข้อยกเว้นสำหรับผู้คนที่พยายามจะทำงานในร้านค้ามืออาชีพทั่วโลก

สิ่งที่สุดขั้วนี้คือแนวคิดของผู้จัดการและนักทฤษฎีหลายคนเกี่ยวกับ "แนวทางที่ถูกต้อง" ในการพัฒนา SW การแสดงออกในวิธีการใหญ่ ๆ อย่าง CMM, RUP, Waterfall และอื่น ๆ ความคิดที่อยู่เบื้องหลังสิ่งเหล่านี้คือทั้งหมดที่คุณต้องการคือ กระบวนการที่เหมาะสมและจะเริ่มต้นผลิตซอฟต์แวร์ที่มีคุณภาพโดยอัตโนมัติในลักษณะที่กำหนดได้ไม่ว่าผู้พัฒนาจะเป็นใคร โปรดสังเกตว่าเกมเดียวกันนี้สามารถเล่นได้โดยใช้วิธี Agile ด้วย - เป็นเพียงการเปลี่ยนป้ายกำกับ ผู้จัดการคนใดก็ตามที่เชื่อว่าการเลือก (และการรักษา) สมาชิกที่เหมาะสมสำหรับทีมพัฒนาของเขา / เธอนั้นมีความสำคัญน้อยกว่ากระบวนการพัฒนานั้นจะต้องล้มเหลวไม่ว่ากระบวนการนั้นจะเกิดขึ้นก็ตาม อย่างไรก็ตามความเชื่อในกระบวนการนี้ยังคงเป็นที่แพร่หลาย - บางทีมันอาจจะสอนในโรงเรียนการจัดการ?

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

ภาพนี้ตามด้วยข้อความนี้:

ฉันเชื่อในแนวคิดนี้ แต่การดำเนินการตามที่อธิบายไว้ข้างต้นมีความเสี่ยงและเชิญล้มเหลว ... ขั้นตอนการทดสอบที่เกิดขึ้นเมื่อสิ้นสุดรอบการพัฒนาเป็นเหตุการณ์แรกที่กำหนดเวลาการจัดเก็บอินพุต / เอาต์พุตการถ่ายโอน ฯลฯ เป็นประสบการณ์ที่แตกต่างจากการวิเคราะห์ ปรากฏการณ์เหล่านี้ไม่สามารถวิเคราะห์ได้อย่างแม่นยำ พวกมันไม่ใช่คำตอบของสมการเชิงอนุพันธ์ย่อยบางส่วนของฟิสิกส์เชิงคณิตศาสตร์เช่น แต่หากปรากฏการณ์เหล่านี้ล้มเหลวในการตอบสนองต่อข้อ จำกัด ภายนอกที่หลากหลายดังนั้นการออกแบบครั้งใหญ่จึงจำเป็น แพทช์ฐานแปดอย่างง่ายหรือการทำซ้ำรหัสที่แยกบางตัวจะไม่แก้ไขปัญหาประเภทนี้ การเปลี่ยนแปลงการออกแบบที่ต้องการนั้นมีแนวโน้มที่จะก่อกวนจนข้อกำหนดของซอฟต์แวร์ที่ใช้ในการออกแบบและเป็นสาเหตุของการละเมิดทุกอย่าง ต้องมีการปรับเปลี่ยนข้อกำหนดหรือจำเป็นต้องมีการเปลี่ยนแปลงอย่างมีนัยสำคัญในการออกแบบ ผลที่ตามมาคือกระบวนการพัฒนาได้กลับไปสู่จุดเริ่มต้นและคาดว่าจะมีค่าใช้จ่ายเกินกำหนด 100% ตามกำหนดเวลาและ / หรือค่าใช้จ่าย

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

ทำไมผู้คนถึงลงไปที่น้ำตกแห่งแรกฉันไม่รู้ ฉันเดาว่าพวกเขาชอบรับความเสี่ยงและเชิญชวนความล้มเหลว

รุ่นอัตโนมัติของรหัสจากระดับนามธรรมสูงกว่าหรือการเขียนโปรแกรมอัตโนมัติ

บทความ Wikipedia ค่อนข้างขาดข้อมูลทางประวัติศาสตร์ แต่นี่เป็นความฝันของผู้จัดการตั้งแต่โปรแกรมเมอร์กลายเป็นราคาแพงกว่าคอมพิวเตอร์

หลังจากการพัฒนาภาษาระดับสูงเช่น Fortran และ Cobol การพัฒนาของภาษาสำหรับโดเมนพิเศษเช่นการเขียนรายงาน EasytrieveและSASเป็นตัวอย่าง

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

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

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

วิธีการอย่างเป็นทางการ

กาลครั้งหนึ่งมันถูกเสนอว่าซอฟต์แวร์สามารถพิสูจน์ได้ว่าถูกต้อง (ความคิดที่ว่าการทดสอบไม่สามารถแสดงได้ว่าไม่มีข้อผิดพลาด แต่สามารถพิสูจน์ได้) แต่น่าเสียดายที่การพิสูจน์การพิสูจน์โปรแกรมมีข้อบกพร่องที่สำคัญบางประการ:

• มันยากและเสียเวลามากกว่าการเขียนโปรแกรม
• มันจะต้องครอบคลุมโปรแกรมทั้งหมดซึ่งหมายความว่าคุณต้องการหลักฐานสำหรับห้องสมุดใด ๆ ระบบปฏิบัติการ ฯลฯ ...
• ไม่ได้พิสูจน์ว่าไม่มีข้อบกพร่องเนื่องจากข้อบกพร่องเหล่านั้นอาจเกิดจากอุบัติเหตุ

แนวคิดนี้เป็นที่นิยมมากในยุค 70

การเชื่อมโยง: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods