อ่าน 8 นาที
ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์
ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์เริ่มต้นขึ้นราวทศวรรษ 1960 การเขียนซอฟต์แวร์ได้พัฒนาไปสู่วิชาชีพที่เกี่ยวข้องกับวิธีการเพิ่มคุณภาพของซอฟต์แวร์ให้สูงสุดและวิธีการสร้างซอฟต์แวร์
ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์
| ประวัติศาสตร์ของการคำนวณ |
|---|
| ฮาร์ดแวร์ |
| ซอฟต์แวร์ |
| วิทยาการคอมพิวเตอร์ |
| แนวคิดสมัยใหม่ |
| ตามประเทศ |
| ลำดับเหตุการณ์ของวิทยาการคอมพิวเตอร์ |
| ศัพท์เฉพาะทางด้านวิทยาการคอมพิวเตอร์ |
ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์เริ่มต้นขึ้นราวทศวรรษ 1960 การเขียนซอฟต์แวร์ได้พัฒนาไปสู่วิชาชีพที่เกี่ยวข้องกับวิธีการเพิ่มคุณภาพของซอฟต์แวร์ให้สูงสุดและวิธีการสร้างซอฟต์แวร์ คุณภาพอาจหมายถึงความสามารถในการบำรุงรักษาซอฟต์แวร์ ความเสถียร ความเร็ว ความสามารถในการใช้งาน ความสามารถในการทดสอบ ความสามารถในการอ่าน ขนาด ต้นทุน ความปลอดภัย และจำนวนข้อบกพร่องหรือ "บั๊ก" ตลอดจนคุณสมบัติที่วัดได้ยากกว่า เช่น ความสวยงาม ความกระชับ และความพึงพอใจของลูกค้า รวมถึงคุณลักษณะอื่นๆ อีกมากมาย วิธีการสร้างซอฟต์แวร์คุณภาพสูงให้ดีที่สุดเป็นปัญหาที่แยกต่างหากและเป็นที่ถกเถียงกัน ซึ่งครอบคลุมหลักการออกแบบซอฟต์แวร์ สิ่งที่เรียกว่า "แนวปฏิบัติที่ดีที่สุด" สำหรับการเขียนโค้ด ตลอดจนประเด็นการจัดการที่กว้างขึ้น เช่น ขนาดทีมที่เหมาะสม กระบวนการ วิธีการส่งมอบซอฟต์แวร์ให้ตรงเวลาและรวดเร็วที่สุด วัฒนธรรมในที่ทำงาน แนวทางการจ้างงาน และอื่นๆ ทั้งหมดนี้อยู่ภายใต้ขอบเขตกว้างๆ ของวิศวกรรมซอฟต์แวร์[ 1 ]
ภาพรวม
วิวัฒนาการของวิศวกรรมซอฟต์แวร์นั้นโดดเด่นในหลายด้าน:
- การเกิดขึ้นในฐานะวิชาชีพ: ในช่วงต้นทศวรรษ 1980 วิศวกรรมซอฟต์แวร์ได้เกิดขึ้นเป็นวิชาชีพที่แท้จริงแล้ว[ 2 ] เพื่อยืนเคียงข้างวิทยาศาสตร์คอมพิวเตอร์และวิศวกรรมแบบดั้งเดิม
- บทบาทของผู้หญิง : ก่อนปี 1970 ผู้ชายที่ทำงาน ด้านวิศวกรรมฮาร์ดแวร์ที่มีเกียรติและค่าตอบแทนสูงกว่ามักจะมอบหมายให้ผู้หญิงเขียนโปรแกรม และบุคคลระดับตำนานอย่างเกรซ ฮอปเปอร์หรือมาร์กาเร็ต แฮมิลตัน ก็ทำงานด้าน การเขียนโปรแกรมคอมพิวเตอร์มากมาย[ 3 ] [ 4 ]ปัจจุบัน ผู้หญิงทำงานด้านวิศวกรรมซอฟต์แวร์น้อยกว่าในวิชาชีพอื่นๆ ซึ่งเป็นสถานการณ์ที่ยังไม่สามารถระบุสาเหตุได้อย่างชัดเจน องค์กรทางวิชาการและวิชาชีพหลายแห่งมองว่าสถานการณ์นี้ไม่สมดุลและกำลังพยายามอย่างหนักเพื่อแก้ไข[ 5 ]
- กระบวนการ: กระบวนการต่างๆได้กลายเป็นส่วนสำคัญอย่างมากในวิศวกรรมซอฟต์แวร์ ได้รับการยกย่องในศักยภาพที่จะช่วยปรับปรุงซอฟต์แวร์ แต่ก็ถูกวิพากษ์วิจารณ์อย่างหนักในศักยภาพที่จะจำกัดความคิดสร้างสรรค์ของโปรแกรมเมอร์
- ต้นทุนของฮาร์ดแวร์: ต้นทุนสัมพัทธ์ของซอฟต์แวร์เทียบกับฮาร์ดแวร์เปลี่ยนแปลงไปอย่างมากในช่วง 50 ปีที่ผ่านมา เมื่อเมนเฟรมมีราคาแพงและต้องการเจ้าหน้าที่สนับสนุนจำนวนมาก องค์กรจำนวนน้อยที่ซื้อเมนเฟรมก็มีทรัพยากรที่จะสนับสนุนโครงการวิศวกรรมซอฟต์แวร์แบบกำหนดเองขนาดใหญ่และมีราคาแพงได้เช่นกัน ปัจจุบันคอมพิวเตอร์มีจำนวนมากขึ้นและมีประสิทธิภาพมากขึ้น ซึ่งส่งผลกระทบต่อซอฟต์แวร์หลายประการ ตลาดที่ใหญ่ขึ้นสามารถรองรับโครงการขนาดใหญ่ในการสร้าง ซอฟต์แวร์ สำเร็จรูปเชิงพาณิชย์ได้เช่นเดียวกับที่บริษัทต่างๆ เช่นไมโครซอฟต์ ทำ เครื่องคอมพิวเตอร์ราคาถูกช่วยให้โปรแกรมเมอร์แต่ละคนมีเทอร์มินัลที่สามารถคอมไพ ล์ได้อย่างรวดเร็ว โปรแกรมเหล่านั้นสามารถใช้เทคนิคต่างๆ เช่น การจัดการ หน่วยความจำอัตโนมัติ (garbage collection ) ซึ่งทำให้โปรแกรมเมอร์เขียนโปรแกรมได้ง่ายและเร็วขึ้น ในทางกลับกัน องค์กรจำนวนน้อยลงที่สนใจจ้างโปรแกรมเมอร์สำหรับโครงการซอฟต์แวร์แบบกำหนดเองขนาดใหญ่ แต่หันมาใช้ ซอฟต์แวร์ สำเร็จรูปเชิงพาณิชย์ให้มากที่สุดเท่าที่จะเป็นไปได้
ปี 1945 ถึง 1965: จุดเริ่มต้น
การใช้คำว่า วิศวกรรมซอฟต์แวร์ในยุคแรกๆได้แก่ จดหมายจากประธาน ACM Anthony Oettinger ในปี 1965 [ 6 ] [ 7 ] การบรรยายของDouglas T. Rossที่ MIT ในช่วงทศวรรษ 1950 [ 8 ] Margaret H. Hamiltonเป็นผู้ที่คิดริเริ่มตั้งชื่อสาขาวิชานี้ว่าวิศวกรรมซอฟต์แวร์ เพื่อให้มีความชอบธรรมในระหว่างการพัฒนาApollo Guidance Computer [ 9 ] [ 10 ]
ผมต่อสู้เพื่อนำพาซอฟต์แวร์ให้ได้รับการยอมรับอย่างถูกต้องตามกฎหมาย เพื่อให้ซอฟต์แวร์และผู้ที่สร้างมันขึ้นมาได้รับการเคารพอย่างที่ควรจะเป็น และด้วยเหตุนี้ผมจึงเริ่มใช้คำว่า 'วิศวกรรมซอฟต์แวร์' เพื่อแยกแยะมันออกจากฮาร์ดแวร์และวิศวกรรมประเภทอื่นๆ แต่ยังคงถือว่าวิศวกรรมแต่ละประเภทเป็นส่วนหนึ่งของกระบวนการวิศวกรรมระบบโดยรวม เมื่อผมเริ่มใช้คำนี้ครั้งแรก มันถูกมองว่าเป็นเรื่องตลกมาก มันเป็นเรื่องตลกที่พูดกันมานาน พวกเขาชอบล้อผมเกี่ยวกับความคิดที่แหวกแนวของผม ในที่สุดซอฟต์แวร์ก็ได้รับการเคารพเช่นเดียวกับสาขาวิชาอื่นๆ อย่างหลีกเลี่ยงไม่ได้
คณะกรรมการวิทยาศาสตร์ของ NATOได้สนับสนุนการประชุมสองครั้ง[ 12 ]เกี่ยวกับวิศวกรรมซอฟต์แวร์ในปี พ.ศ. 2511 ( เมืองการ์มิชประเทศเยอรมนี) และ พ.ศ. 2512 ซึ่งเป็นจุดเริ่มต้นสำคัญของสาขานี้ หลายคนเชื่อว่าการประชุมเหล่านี้ถือเป็นจุดเริ่มต้นอย่างเป็นทางการของวิชาชีพวิศวกรรมซอฟต์แวร์[ 6 ] [ 13 ]
ปี 1965 ถึง 1985: วิกฤตการณ์ซอฟต์แวร์และระบบปฏิบัติการ
วิศวกรรมซอฟต์แวร์ได้รับการกระตุ้นจากสิ่งที่เรียกว่าวิกฤตซอฟต์แวร์ในช่วงทศวรรษ 1960, 1970 และ 1980 ซึ่งระบุปัญหามากมายของการพัฒนาซอฟต์แวร์ โครงการหลายโครงการใช้งบประมาณและเวลาเกินกว่าที่กำหนด โครงการบางโครงการก่อให้เกิดความเสียหายต่อทรัพย์สิน จากการละเลยในการเผยแพร่ซอฟต์แวร์ที่มีข้อบกพร่องร้ายแรง บางคนเสียชีวิตเนื่องจากความล้มเหลวของซอฟต์แวร์ ตัวอย่างที่โดดเด่นที่สุดอย่างหนึ่งของอันตรายจากข้อบกพร่องของซอฟต์แวร์คือ ข้อบกพร่องเงื่อนไขการแข่งขันของ Therac-25ข้อบกพร่องนี้ทำให้เครื่องฉายรังสีบำบัดจ่ายรังสีเกินขนาดในกรณีที่ควรใช้ปริมาณรังสีต่ำ วิกฤตซอฟต์แวร์เดิมทีถูกกำหนดในแง่ของผลผลิตแต่ต่อมาได้พัฒนาไปเน้นที่คุณภาพบางคนใช้คำว่าวิกฤตซอฟต์แวร์เพื่ออ้างถึงความไม่สามารถจ้างโปรแกรมเมอร์ที่มีคุณสมบัติเพียงพอ ในช่วงเวลานี้ซิลิคอนแวลลีย์ได้สร้างความแข็งแกร่งให้กับตัวเองในฐานะสถานที่ที่ดีที่สุดสำหรับวิศวกรซอฟต์แวร์ในการทำงาน[ 14 ]
- ค่าใช้จ่ายและงบประมาณที่เกินกำหนด : ระบบปฏิบัติการ OS/360เป็นตัวอย่างคลาสสิก โครงการที่กินเวลานานนับทศวรรษตั้งแต่ทศวรรษ 1960 ในที่สุดก็สร้างระบบซอฟต์แวร์ที่ซับซ้อนที่สุดระบบหนึ่งในเวลานั้น[ 13 ] OS/360 เป็นหนึ่งในโครงการซอฟต์แวร์ขนาดใหญ่โครงการแรกๆ (โปรแกรมเมอร์ 1,000 คน) เฟรด บรูคส์อ้างในThe Mythical Man-Monthว่าเขาทำผิดพลาดมูลค่าหลายล้านดอลลาร์จากการไม่พัฒนาสถาปัตยกรรม ที่สอดคล้องกัน ก่อนเริ่มการพัฒนา[ 13 ]
- ความเสียหายต่อทรัพย์สิน: ข้อบกพร่องของซอฟต์แวร์อาจทำให้เกิดความเสียหายต่อทรัพย์สินการรักษาความปลอดภัยของซอฟต์แวร์ ที่อ่อนแอ ทำให้แฮกเกอร์สามารถขโมยข้อมูลส่วนบุคคล ซึ่งทำให้เสียเวลา เงิน และชื่อเสียง
- ชีวิตและความตาย: ข้อบกพร่องของซอฟต์แวร์สามารถคร่าชีวิตได้ระบบฝังตัวที่ใช้ใน เครื่อง ฉายรังสีพิสูจน์ให้เห็นถึงความสามารถในการล้มเหลวอย่างร้ายแรงจนทำให้ผู้ป่วยได้รับรังสีในปริมาณที่ถึงแก่ชีวิตความล้มเหลวที่โด่งดังที่สุดคือเหตุการณ์Therac-25 [ 15 ]
Peter G. Neumannได้รวบรวมรายชื่อปัญหาและภัยพิบัติของซอฟต์แวร์ในปัจจุบัน[ 16 ]วิกฤตการณ์ซอฟต์แวร์เริ่มจางหายไป เนื่องจากเป็นเรื่องยากอย่างยิ่งทางจิตวิทยาที่จะคงอยู่ในโหมดวิกฤตเป็นเวลานาน (มากกว่า 20 ปี) อย่างไรก็ตาม ซอฟต์แวร์ โดยเฉพาะซอฟต์แวร์ฝังตัวแบบเรียลไทม์ ยังคงมีความเสี่ยงและแพร่หลาย และสิ่งสำคัญคืออย่าปล่อยให้เกิดความพึงพอใจ ในช่วง 10-15 ปีที่ผ่านมาMichael A. Jacksonได้เขียนเกี่ยวกับธรรมชาติของวิศวกรรมซอฟต์แวร์อย่างกว้างขวาง ได้ระบุแหล่งที่มาหลักของความยากลำบากว่าเป็นเพราะการขาดความเชี่ยวชาญ และได้เสนอแนะว่ากรอบปัญหาของเขาเป็นพื้นฐานสำหรับ "แนวปฏิบัติปกติ" ของวิศวกรรมซอฟต์แวร์ ซึ่งเป็นข้อกำหนดเบื้องต้นหากวิศวกรรมซอฟต์แวร์จะกลายเป็นวิทยาศาสตร์ทางวิศวกรรม[ 17 ]
หนึ่งในโครงการที่ใหญ่ที่สุดที่วิศวกรซอฟต์แวร์ดำเนินการในช่วงเวลานี้คือการพัฒนาระบบปฏิบัติการ สมัยใหม่ เริ่มต้นที่ Bell Labs แล้วย้ายไปที่ UC Berkeley Ken ThompsonและDennis Ritchieรวมถึงวิศวกรซอฟต์แวร์คนอื่นๆ ได้ร่วมกันสร้างUnix V6ในปี 1975 Unix V6 เป็นระบบปฏิบัติการสำคัญที่กำหนดมาตรฐานสำหรับระบบปฏิบัติการในอนาคต และยังคงใช้ในปัจจุบันเพื่อสอนนักเรียนเกี่ยวกับหลักการของระบบปฏิบัติการที่ถูกต้อง[ 18 ]ยิ่งไปกว่านั้น ระบบปฏิบัติการในอนาคตที่สร้างขึ้นบนวิธีการของ Unix V6 และระบบที่สืบทอดต่อมาสามารถจัดกลุ่มได้เป็น 5 ประเภทของกระบวนทัศน์ระบบปฏิบัติการ ได้แก่ ระบบระดับรากหญ้า ระบบขนาดใหญ่ ระบบไฮบริด ระบบทดลอง และระบบขนาดเล็ก[ 19 ]ในทางตรงกันข้ามกับ Unix วิศวกรซอฟต์แวร์ที่ MIT ในปี 1983 ได้สร้างGNU (แปลตรงตัวว่า "GNU's Not Unix") เป็นทางเลือกโอเพนซอร์สแทน Unix ในฐานะซอฟต์แวร์โอเพนซอร์สยุคแรก GNU เป็นที่รักของกลุ่มนักพัฒนาขนาดเล็ก และผลงานของ GNU ได้ช่วยให้ชุมชนการพัฒนาซอฟต์แวร์โอเพนซอร์สเติบโตขึ้นในช่วงทศวรรษ 1980 [ 20 ]
ปี 1985 ถึง 1989: " ไม่มีทางออกที่ง่ายดาย "
เป็นเวลาหลายทศวรรษที่การแก้ไขวิกฤตซอฟต์แวร์เป็นสิ่งสำคัญยิ่งสำหรับนักวิจัยและบริษัทผู้ผลิตเครื่องมือซอฟต์แวร์ ต้นทุนในการเป็นเจ้าของและบำรุงรักษาซอฟต์แวร์ในช่วงทศวรรษ 1980 นั้นสูงกว่าต้นทุนการพัฒนาซอฟต์แวร์ถึงสองเท่า
- ในช่วงทศวรรษ 1990 ค่าใช้จ่ายในการเป็นเจ้าของและการบำรุงรักษาเพิ่มขึ้น 30% เมื่อเทียบกับทศวรรษ 1980
- ในปี 1995 สถิติแสดงให้เห็นว่าครึ่งหนึ่งของโครงการพัฒนาที่สำรวจนั้นดำเนินการอยู่ แต่ไม่ถือว่าประสบความสำเร็จ
- โดยเฉลี่ยแล้ว โครงการพัฒนาซอฟต์แวร์มักล่าช้ากว่ากำหนดการครึ่งหนึ่ง
- สามในสี่ของผลิตภัณฑ์ซอฟต์แวร์ขนาดใหญ่ที่ส่งมอบให้กับลูกค้าล้วนเป็นผลิตภัณฑ์ที่ล้มเหลว ไม่ว่าจะเป็นผลิตภัณฑ์ที่ลูกค้าไม่ได้ใช้งานเลย หรือไม่ตรงตามความต้องการของลูกค้า
โครงการซอฟต์แวร์
ดูเหมือนว่าเทคโนโลยีและแนวปฏิบัติใหม่ ๆ ทุกอย่างตั้งแต่ทศวรรษ 1970 ถึง 1990 จะถูกยกย่องว่าเป็นทางออกวิเศษที่จะแก้ปัญหาวิกฤตซอฟต์แวร์ได้ เครื่องมือ ระเบียบวินัยวิธีการที่เป็นทางการกระบวนการ และความเป็นมืออาชีพ ล้วนถูกยกย่องว่าเป็นทางออกวิเศษ:
- เครื่องมือ: โดยเฉพาะอย่างยิ่งมีการเน้นย้ำถึงเครื่องมือต่างๆ เช่นการเขียนโปรแกรมเชิงโครงสร้างการเขียนโปรแกรมเชิงวัตถุ เครื่องมือ CASEเช่นระบบCADES CASE ของ ICL [ 21 ] Ada เอกสารประกอบและมาตรฐานต่างๆซึ่งได้รับการยกย่องว่าเป็นทางออกที่ดีที่สุด
- วินัย: ผู้เชี่ยวชาญบางคนกล่าวว่าวิกฤตซอฟต์แวร์เกิดจากการขาดวินัยของโปรแกรมเมอร์
- วิธีการที่เป็นทางการ: บางคนเชื่อว่าหากนำวิธีการทางวิศวกรรมที่เป็นทางการมาใช้ในการพัฒนาซอฟต์แวร์ การผลิตซอฟต์แวร์ก็จะกลายเป็นอุตสาหกรรมที่คาดการณ์ได้เช่นเดียวกับสาขาวิศวกรรมอื่นๆ พวกเขาจึงสนับสนุนให้พิสูจน์ว่าโปรแกรมทั้งหมดถูกต้อง
- กระบวนการ: หลายฝ่ายสนับสนุนการใช้กระบวนการและวิธีการ ที่กำหนดไว้อย่างชัดเจน เช่นโมเดลวัดระดับความสามารถ (Capability Maturity Model )
- ความเป็นมืออาชีพ: สิ่งนี้จึงนำไปสู่การจัดทำจรรยาบรรณ ใบอนุญาต และมาตรฐานความเป็นมืออาชีพ
ในปี 1986 เฟรด บรูคส์ได้ตีพิมพ์ บทความเรื่อง "ไม่มีทางออกวิเศษที่จะแก้ปัญหาได้ทุกอย่าง" โดยโต้แย้งว่าไม่มีเทคโนโลยีหรือวิธีการใดวิธีหนึ่งที่จะสามารถเพิ่มผลผลิตได้ถึง 10 เท่าภายใน 10 ปี
การถกเถียงเรื่อง "ทางออกวิเศษ" ยังคงดำเนินต่อไปตลอดทศวรรษถัดมา ผู้สนับสนุนภาษาAda ส่วนประกอบและกระบวนการต่างๆ ยังคงโต้แย้งกันมานานหลายปีว่าเทคโนโลยีที่พวกเขาชื่นชอบจะเป็น "ทางออกวิเศษ" ผู้ที่สงสัยไม่เห็นด้วย ในที่สุดเกือบทุกคนก็ยอมรับว่าไม่มี "ทางออกวิเศษ" ใดๆ ที่จะถูกค้นพบได้ อย่างไรก็ตาม การกล่าวอ้างเกี่ยวกับ " ทางออกวิเศษ"ยังคงปรากฏขึ้นเป็นครั้งคราว แม้กระทั่งในปัจจุบัน
บางคนตีความว่าการไม่มีทางออกที่ง่ายดายหมายความว่าวิศวกรรมซอฟต์แวร์ล้มเหลว อย่างไรก็ตาม เมื่ออ่านเพิ่มเติม บรูคส์กล่าวต่อไปว่า "เราจะมีความก้าวหน้าอย่างมากในอีก 40 ปีข้างหน้าอย่างแน่นอน ความก้าวหน้าในระดับหลายเท่าตัวใน 40 ปีนั้นไม่ใช่เรื่องมหัศจรรย์อะไรเลย..."
การค้นหากุญแจสำคัญเพียงดอกเดียวสู่ความสำเร็จนั้นไม่เคยได้ผล เทคโนโลยีและแนวปฏิบัติที่เรารู้จักกันทั้งหมดได้ช่วยปรับปรุงประสิทธิภาพและคุณภาพการทำงานไปทีละเล็กทีละน้อยเท่านั้น อย่างไรก็ตาม ไม่มีทางลัดสู่ความสำเร็จในวิชาชีพอื่นใดเช่นกัน บางคนตีความว่าการที่ไม่มีทางลัดสู่ความสำเร็จนั้นเป็นเครื่องพิสูจน์ว่าวิศวกรรมซอฟต์แวร์ได้เติบโตเต็มที่แล้ว และตระหนักว่าโครงการต่างๆ จะประสบความสำเร็จได้ก็ต่อเมื่อทำงานหนักเท่านั้น
อย่างไรก็ตาม อาจกล่าวได้ว่าในปัจจุบันมี วิธีการ แก้ปัญหาแบบเบ็ดเสร็จ อยู่หลายวิธี รวมถึงวิธีการแบบเบา (ดู " การจัดการโครงการ "), เครื่องคำนวณในสเปรดชีต, เบราว์เซอร์ ที่ปรับแต่งเอง , เครื่องมือค้นหาในเว็บไซต์, เครื่องมือสร้างรายงานฐานข้อมูล, โปรแกรมแก้ไขโค้ดที่รวมการออกแบบ การทดสอบ และการแก้ไขเข้าด้วยกัน พร้อมฟังก์ชันหน่วยความจำ/ความแตกต่าง/การยกเลิก และบริษัทเฉพาะทางที่สร้างซอฟต์แวร์เฉพาะกลุ่ม เช่น เว็บไซต์ข้อมูล ในราคาที่ต่ำกว่าการพัฒนาเว็บไซต์แบบกำหนดเองทั้งหมดมาก ถึงกระนั้นก็ตาม สาขาวิศวกรรมซอฟต์แวร์ดูซับซ้อนและหลากหลายเกินกว่าจะมี "วิธีการแก้ปัญหาแบบเบ็ดเสร็จ" เพียงวิธีเดียวที่จะแก้ไขปัญหาได้เกือบทั้งหมด และแต่ละปัญหาก็คิดเป็นเพียงส่วนเล็ก ๆ ของปัญหาซอฟต์แวร์ทั้งหมดเท่านั้น
ปี 1990 ถึง 1999: ยุคที่อินเทอร์เน็ตเฟื่องฟู
การเกิดขึ้นของอินเทอร์เน็ตนำไปสู่การเติบโตอย่างรวดเร็วของความต้องการระบบแสดงข้อมูล/อีเมลระหว่างประเทศบนเวิลด์ไวด์เว็บ โปรแกรมเมอร์จำเป็นต้องจัดการกับภาพประกอบ แผนที่ ภาพถ่าย และภาพอื่นๆ รวมถึงแอนิเมชั่นอย่างง่าย ในอัตราที่ไม่เคยมีมาก่อน โดยมีวิธีการเพิ่มประสิทธิภาพการแสดงผล/จัดเก็บภาพ (เช่น การใช้ภาพขนาดย่อ) ที่เป็นที่รู้จักกันดีเพียงไม่กี่วิธี
การเติบโตของการใช้งานเบราว์เซอร์ ซึ่งทำงานบนภาษา HyperText Markup Language (HTML) ได้เปลี่ยนวิธีการจัดระเบียบการแสดงผลและการเรียกค้นข้อมูล การเชื่อมต่อเครือข่ายที่แพร่หลายนำไปสู่การเติบโตและการป้องกันไวรัสคอมพิวเตอร์ ระหว่างประเทศ บนคอมพิวเตอร์ MS Windows และการแพร่กระจายอย่างมหาศาลของอีเมลสแปมกลายเป็นปัญหาการออกแบบที่สำคัญในระบบอีเมล ทำให้ช่องทางการสื่อสารเต็มไปด้วยอีเมลและจำเป็นต้องมีการคัดกรองเบื้องต้นแบบกึ่งอัตโนมัติ ระบบค้นหาคำหลักพัฒนาไปสู่เครื่องมือค้นหา บนเว็บ และระบบซอฟต์แวร์จำนวนมากต้องได้รับการออกแบบใหม่สำหรับการค้นหาในระดับสากล โดยขึ้นอยู่กับการเพิ่มประสิทธิภาพเครื่องมือค้นหา (SEO) ระบบการแปลภาษาธรรมชาติของมนุษย์มีความจำเป็นในการพยายามแปลการไหลของข้อมูลในหลายภาษาต่างประเทศ โดยระบบซอฟต์แวร์จำนวนมากได้รับการออกแบบสำหรับการใช้งานหลายภาษาโดยอิงจากแนวคิดการออกแบบจากนักแปลมนุษย์ ฐานผู้ใช้คอมพิวเตอร์โดยทั่วไปเพิ่มขึ้นจากหลักร้อยหรือหลักพันคน เป็นหลายล้านคนทั่วโลก
ปี 2000 ถึง 2015: ระเบียบวิธีที่เน้นความเบา
ด้วยความต้องการซอฟต์แวร์ที่เพิ่มขึ้นในองค์กรขนาดเล็กจำนวนมาก ความจำเป็นในการหาโซลูชันซอฟต์แวร์ราคาประหยัดจึงนำไปสู่การเติบโตของวิธีการที่เรียบง่ายและรวดเร็วกว่า ซึ่งช่วยให้การพัฒนาซอฟต์แวร์ที่ใช้งานได้จริง ตั้งแต่การกำหนดความต้องการไปจนถึงการใช้งาน ทำได้รวดเร็วและง่ายขึ้น การใช้การสร้างต้นแบบอย่างรวดเร็วได้พัฒนาไปสู่ระเบียบวิธีที่ มีน้ำหนักเบา เช่นExtreme Programming (XP) ซึ่งพยายามลดความซับซ้อนในหลายด้านของวิศวกรรมซอฟต์แวร์ รวมถึงการรวบรวมความต้องการและการทดสอบความน่าเชื่อถือสำหรับระบบซอฟต์แวร์ขนาดเล็กจำนวนมากที่กำลังเติบโต ระบบซอฟต์แวร์ขนาดใหญ่ยังคงใช้วิธีการที่มีเอกสารประกอบอย่างละเอียด โดยมีเอกสารจำนวนมาก แต่ระบบขนาดเล็กมีแนวทางทางเลือกที่ง่ายและรวดเร็วกว่าในการจัดการการพัฒนาและการบำรุงรักษาการคำนวณและอัลกอริทึมของซอฟต์แวร์ การจัดเก็บ/เรียกค้นข้อมูล และการแสดงผล
แนวโน้มปัจจุบันในด้านวิศวกรรมซอฟต์แวร์
วิศวกรรมซอฟต์แวร์เป็นสาขาวิชาที่ยังใหม่และกำลังพัฒนาอย่างต่อเนื่อง ทิศทางการพัฒนาของวิศวกรรมซอฟต์แวร์ ได้แก่:
แง่มุมต่างๆ
แง่มุม (Aspects)ช่วยให้วิศวกรซอฟต์แวร์จัดการกับคุณลักษณะด้านคุณภาพโดยการจัดหาเครื่องมือเพื่อเพิ่มหรือลบโค้ดซ้ำซ้อนจากหลายส่วนในซอร์สโค้ดแง่มุมอธิบายว่าวัตถุหรือฟังก์ชันทั้งหมดควรทำงานอย่างไรในสถานการณ์เฉพาะ ตัวอย่างเช่นแง่มุมสามารถเพิ่มการดีบักการบันทึกหรือการล็อกการควบคุมลงในวัตถุทั้งหมดของประเภทเฉพาะ นักวิจัยกำลังศึกษาทำความเข้าใจวิธีการใช้แง่มุมในการออกแบบโค้ดอเนกประสงค์ แนวคิดที่เกี่ยวข้อง ได้แก่การเขียนโปรแกรมเชิงสร้างสรรค์ (Generative Programming)และเทมเพลต (Templates )
การทดลอง
วิศวกรรมซอฟต์แวร์เชิงทดลองเป็นสาขาหนึ่งของวิศวกรรมซอฟต์แวร์ที่สนใจในการออกแบบการทดลองกับซอฟต์แวร์ การรวบรวมข้อมูลจากการทดลอง และการสร้างกฎและทฤษฎีจากข้อมูลเหล่านั้น
กลุ่มผลิตภัณฑ์ซอฟต์แวร์
กลุ่มผลิตภัณฑ์ซอฟต์แวร์ หรือที่เรียกว่า วิศวกรรมตระกูลผลิตภัณฑ์คือวิธีการที่เป็นระบบในการสร้างกลุ่มระบบซอฟต์แวร์ แทนที่จะสร้างผลิตภัณฑ์ที่แยกจากกันโดยสิ้นเชิงทีละรายการ วิธีนี้เน้นการนำโค้ดกลับมาใช้ ซ้ำอย่างกว้างขวาง เป็นระบบ และเป็นทางการ เพื่อพยายามทำให้กระบวนการพัฒนาซอฟต์แวร์เป็นแบบอุตสาหกรรม
การประชุม Future of Software Engineering (FOSE) ซึ่งจัดขึ้นที่ ICSE 2000 ได้บันทึกสถานะของ SE ในปี 2000 และระบุปัญหามากมายที่ต้องแก้ไขในทศวรรษถัดไป หัวข้อ FOSE ในการประชุม ICSE 2000 [ 22 ]และ ICSE 2007 [ 23 ]ยังช่วยระบุสถานะของวิศวกรรมซอฟต์แวร์อีกด้วย
วิศวกรรมซอฟต์แวร์ในปัจจุบัน
วิชาชีพนี้กำลังพยายามกำหนดขอบเขตและเนื้อหาของตนเอง โดยองค์ความรู้ด้านวิศวกรรมซอฟต์แวร์(SWEBOK)ได้ถูกนำเสนอเป็นมาตรฐาน ISO ในปี 2549 (ISO/IEC TR 19759)
ในปี พ.ศ. 2549 นิตยสาร Money MagazineและSalary.comจัดอันดับให้วิศวกรรมซอฟต์แวร์เป็นงานที่ดีที่สุดในอเมริกาในแง่ของการเติบโต ค่าตอบแทน ระดับความเครียด ความยืดหยุ่นในเรื่องเวลาและสภาพแวดล้อมการทำงาน ความคิดสร้างสรรค์ และความง่ายในการเข้าทำงานและก้าวหน้าในสาขานี้[ 24 ]
สาขาย่อย
ปัญญาประดิษฐ์
แพลตฟอร์มที่หลากหลายช่วยให้ AI พัฒนาไปในหลายแง่มุม ตั้งแต่ระบบผู้เชี่ยวชาญเช่นCycไปจนถึงการเรียนรู้เชิงลึกและแพลตฟอร์มหุ่นยนต์ เช่นRoombaที่มีอินเทอร์เฟซแบบเปิด[ 25 ]ความก้าวหน้าล่าสุดในเครือข่ายประสาทเทียมเชิง ลึกและการ ประมวล ผลแบบกระจายได้นำไปสู่การแพร่หลายของไลบรารีซอฟต์แวร์ รวมถึงDeeplearning4j , TensorFlow , TheanoและTorch
จากการศึกษาของ McKinsey Global Instituteในปี 2011 พบว่าขาดแคลนผู้เชี่ยวชาญและผู้จัดการด้านข้อมูลและ AI ที่ได้รับการฝึกฝนมาอย่างดีถึง 1.5 ล้านคน[ 26 ]และค่ายฝึกอบรมเอกชนหลายแห่งได้พัฒนาโปรแกรมเพื่อตอบสนองความต้องการดังกล่าว รวมถึงโปรแกรมฟรี เช่นThe Data Incubatorหรือโปรแกรมแบบเสียค่าใช้จ่าย เช่นGeneral Assembly [ 27 ]
ภาษา
AI เชิงสัญลักษณ์ในยุคแรกเป็นแรงบันดาลใจให้กับLispและ Prolog ซึ่งครอบงำการเขียนโปรแกรม AI ในยุคแรก การพัฒนา AI สมัยใหม่มักใช้ภาษาหลัก เช่นPythonหรือC++ [ 28 ]หรือภาษาเฉพาะกลุ่ม เช่นWolfram Language [ 29 ]
บุคคลสำคัญในประวัติศาสตร์วิศวกรรมซอฟต์แวร์
- ชาร์ลส์ บาคแมน (1924–2017 ) เป็นที่รู้จักเป็นพิเศษจากผลงานของเขาในด้านฐานข้อมูล
- ลาซโล เบลาดี (1928–2021) บรรณาธิการบริหารของวารสาร IEEE Transactions on Software Engineering ในช่วงทศวรรษ 1980
- เฟรด บรูคส์ (1931-2022) เป็นที่รู้จักกันดีในฐานะผู้บริหารการพัฒนาOS/360และผู้เขียนหนังสือ"The Mythical Man-Month "
- ปีเตอร์ เฉิน (เกิดปี 1947) เป็นที่รู้จักในฐานะผู้พัฒนาแบบจำลองความสัมพันธ์ระหว่างเอนทิตี (entity–relationship modeling )
- เอ็ดสเกอร์ ดับเบิลยู. ไดจ์กสตรา (1930–2002) ได้พัฒนากรอบแนวคิดสำหรับรูปแบบหนึ่งของการเขียนโปรแกรมเชิงโครงสร้าง
- เดวิด พาร์นาส (เกิดปี 1941) เป็นผู้พัฒนาแนวคิดเรื่องการซ่อนข้อมูลในการเขียนโปรแกรมแบบโมดูลาร์
- ไมเคิล เอ. แจ็กสัน (เกิดปี 1936) เป็นนักระเบียบวิธีทางวิศวกรรมซอฟต์แวร์ ผู้คิดค้นวิธีการออกแบบโปรแกรมแบบ JSP วิธีการพัฒนาระบบแบบ JSD (ร่วมกับจอห์น คาเมรอน) และแนวทาง Problem Frames สำหรับการวิเคราะห์และจัดโครงสร้างปัญหาในการพัฒนาซอฟต์แวร์
- ริชาร์ด สตอลแมนเป็นผู้สร้างยูทิลิตี้ระบบ GNU และเป็นผู้สนับสนุนซอฟต์แวร์เสรี
ดูเพิ่มเติม
ลิงก์ภายนอก
- บทสัมภาษณ์ประวัติศาสตร์ปากเปล่ากับ บรูซ เอช. บาร์นส์ จากสถาบันชาร์ลส์ แบ็บเบจมหาวิทยาลัยมินนิโซตา บาร์นส์บรรยายถึงมูลนิธิวิทยาศาสตร์แห่งชาติ (NSF) และการสนับสนุนงานวิจัยด้านวิทยาศาสตร์คอมพิวเตอร์เชิงทฤษฎีสถาปัตยกรรมคอมพิวเตอร์วิธีการเชิงตัวเลขและวิศวกรรมซอฟต์แวร์ตลอดจนการพัฒนาระบบเครือข่าย
- การสัมภาษณ์ประวัติศาสตร์ปากเปล่ากับ ลาสโล เอ. เบลาดีสถาบันชาร์ลส์ แบ็บเบจมหาวิทยาลัยมินนิโซตา
สรุปเนื้อหา
ข้อมูลสำคัญจากบทความ
ข้อมูลสำคัญเกี่ยวกับ ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์
ประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์เริ่มต้นขึ้นราวทศวรรษ 1960 การเขียนซอฟต์แวร์ได้พัฒนาไปสู่วิชาชีพที่เกี่ยวข้องกับวิธีการเพิ่มคุณภาพของซอฟต์แวร์ให้สูงสุดและวิธีการสร้างซอฟต์แวร์
ภาพรวม
วิวัฒนาการของวิศวกรรมซอฟต์แวร์นั้นโดดเด่นในหลายด้าน:
ปี 1945 ถึง 1965: จุดเริ่มต้น
การใช้คำว่า วิศวกรรมซอฟต์แวร์ ในยุคแรกๆได้แก่ จดหมายจากประธาน ACM Anthony Oettinger ในปี 1965 [ 6 ] [ 7 ] การ บรรยายของ Douglas T. Ross ที่ MIT ในช่วงทศวรรษ 1950 [ 8 ] Margaret H.
ปี 1965 ถึง 1985: วิกฤตการณ์ซอฟต์แวร์และระบบปฏิบัติการ
วิศวกรรมซอฟต์แวร์ได้รับการกระตุ้นจากสิ่งที่เรียกว่า วิกฤตซอฟต์แวร์ ในช่วงทศวรรษ 1960, 1970 และ 1980 ซึ่งระบุปัญหามากมายของการพัฒนาซอฟต์แวร์ โครงการหลายโครงการใช้งบประมาณและเวลาเกินกว่าที่กำหนด โครงการบางโครงการก่อให้เกิดความเสียหายต่อทรัพย์สิน...
