การพัฒนาซอฟต์แวร์เป็นสาขาวิศวกรรมหรือไม่?

การพัฒนาซอฟต์แวร์ถือเป็นวิศวกรรมได้หรือไม่? หากไม่มีสิ่งใดที่ขาดไปเพื่อให้มีคุณสมบัติเป็นวินัยทางวิศวกรรม ที่เกี่ยวข้องกับการนี้เป็นคำถามนี้ในกองมากเกินเกี่ยวกับความแตกต่างระหว่างโปรแกรมเมอร์และวิศวกรซอฟต์แวร์

มีสถาบันวิศวกรรมซอฟต์แวร์ที่ Carnigie Mellon University ที่กำหนดและรักษามาตรฐาน CMMI นี่เป็นสิ่งที่จะเปลี่ยนการพัฒนาเป็นวิศวกรรมหรือไม่

วิศวกรรมการพัฒนาซอฟต์แวร์เป็นอย่างไร หากไม่มีสิ่งใดที่ขาดไปเพื่อให้มีคุณสมบัติเช่นนี้

ใช่วิศวกรรมซอฟต์แวร์เป็นสาขาวิศวกรรม

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

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

หนังสือที่ดีที่สุดในเรื่องนี้คือสตีฟ McConnell ของการพัฒนาซอฟต์แวร์มืออาชีพ: ตารางเวลาสั้นอุดมศึกษาผลิตภัณฑ์คุณภาพโครงการที่ประสบความสำเร็จมากขึ้นร่วมงานที่เพิ่มขึ้น มันมีลักษณะที่วิศวกรรมซอฟต์แวร์เป็นอาชีพวิวัฒนาการจากฝีมือในการประกอบอาชีพเป็นวิทยาศาสตร์ของการพัฒนาซอฟต์แวร์, ความแตกต่างระหว่างซอฟต์แวร์วิศวกรรมและซอฟต์แวร์วิศวกรรม (ประยุกต์ใช้วิธีการทางวิศวกรรมซอฟแวร์เมื่อเทียบกับวิศวกรที่เกิดขึ้นกับการสร้างซอฟแวร์ที่มีกรณีศึกษาที่ รวมถึงโรงเรียนเก่าของฉัน ) การรับรองและการออกใบอนุญาตและจริยธรรม

Glenn Vanderburg มีชุดของการเจรจาที่เรียกว่า "วิศวกรรมซอฟต์แวร์จริง" ที่ได้รับระหว่าง 2010 และ 2015 ที่จำนวนของการประชุมพร้อมกับการเจรจาที่เกี่ยวข้องสอง "หัตถกรรมวิศวกรรมและสาระสำคัญของการเขียนโปรแกรม" (ให้ในปี 2011 เป็น คำปราศรัยที่ RailsConf) และ "Craft and Software Engineering" (มอบให้ในปี 2011 ที่ QCon London) ฉันคิดว่าการพูดคุยเหล่านี้เป็นเหตุผลที่ครอบคลุมอย่างมากว่าทำไมวิศวกรรมซอฟต์แวร์ถึงมีวินัยทางวิศวกรรม

เหตุผลหนึ่งซึ่ง Vanderburg นำขึ้นในเวลาสั้น ๆ ในการเจรจาของเขาเป็นหนึ่งที่ทำโดยแจ็คดับบลิวรีฟส์ในปี 1992 (และกลับมาเยือนอีกครั้งในปี 2005) ในสิ่งที่ออกแบบซอฟต์แวร์และวิธีรหัสการส่งออกของกิจกรรมการออกแบบทางวิศวกรรมซอฟต์แวร์ ( นี้ยังเป็น กล่าวถึงเรื่อง C2 วิกิ) เมื่อคุณอยู่ห่างจากโรงเรียนเก่า ๆ แห่งความคิดที่ซึ่งข้อมูลจำเพาะและแบบจำลองคือการออกแบบซอฟต์แวร์และการใช้รหัสเป็นการออกแบบซอฟต์แวร์ความสัมพันธ์ระหว่างวิศวกรรมซอฟต์แวร์และสาขาวิชาวิศวกรรมอื่น ๆ นั้นชัดเจนยิ่งขึ้น ความแตกต่างบางประการและสาเหตุของความแตกต่างนั้นชัดเจนยิ่งขึ้นหลังจากที่คุณเห็นว่าเศรษฐศาสตร์ของการพัฒนาซอฟต์แวร์แตกต่างจากสาขาอื่น ๆ มากมาย - การก่อสร้างมีราคาถูก (ฟรีเกือบในหลาย ๆ กรณี) ในขณะที่การออกแบบเป็นส่วนที่มีราคาแพง

นั่นคือ [CMMI] ที่จะเปลี่ยนการพัฒนาเป็นวิศวกรรมหรือไม่?

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

คุณมีความคิดเห็นอย่างไรกับหลักสูตร / ใบรับรองด้านวิศวกรรมซอฟต์แวร์?

มันคุ้มค่ามากเท่ากับที่คนอื่นใส่เข้าไป มีหลักสูตรที่มีประโยชน์และมีหลักสูตรที่ไร้ประโยชน์ มีใบรับรองที่มีค่าและใบรับรองที่ไม่คุ้มกับกระดาษที่พิมพ์ มีหลายปัจจัยจากผู้ที่รับรองหรือรับรองหลักสูตรหรือผู้ที่ออกใบรับรองให้กับอุตสาหกรรมการจ้างงานปัจจุบันของคุณไปยังงานปัจจุบันของคุณและที่คุณต้องการไป

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

ไม่ว่าคุณจะออกแบบเครื่องบินหรือแอพพลิเคชั่นซอฟต์แวร์สำหรับทั้งสองอย่างคุณต้อง:

• ทำการออกแบบ
• กำหนดระบบย่อยและส่วนประกอบ
• ทำต้นแบบ
• ระบุและดำเนินการทดสอบ
• เป็นต้น

ฉันอ่านบางคำตอบอื่น ๆ ว่าการออกแบบซอฟต์แวร์นั้นแตกต่างกันเพราะคุณไม่ได้ออกแบบทุกอย่างก่อนที่จะเริ่มเขียนโปรแกรม ที่จริงแล้วในระดับที่น้อยกว่านั้นก็เป็นกรณีที่เมื่อคุณออกแบบผลิตภัณฑ์ทางกายภาพ การออกแบบและการสร้างต้นแบบและการทดสอบเป็นกระบวนการที่วนซ้ำ

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

นั่นคือเหตุผลที่ฉันพิจารณาการพัฒนาซอฟต์แวร์ให้เป็นวิศวกรรม

ฉันจะยืนยันว่ามีสิ่งเช่นวิศวกรรมซอฟต์แวร์

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

ความจริงที่ว่านอกจากนี้ยังมีวิธีการลงมือปฏิบัติในการใช้แผนการที่มีอยู่ (การพัฒนาในกรณีนี้) ก็คล้ายกับข้อเท็จจริงที่ว่าในสาขาอื่น ๆ คนอื่นดำเนินแผนเหล่านั้น (เช่นคนงานก่อสร้าง)

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

อย่างไรก็ตามความสามารถในการใช้ภาษาการเขียนโปรแกรมและโปรแกรมไม่ได้เปลี่ยนเป็นวิศวกร: ฉันได้พบกับนักพัฒนาซอฟต์แวร์ของฉันที่ขาดความเข้าใจที่แท้จริงของความซับซ้อนและปัญหานอกรหัสปัจจุบันของพวกเขา

สำหรับคำถามของคุณเกี่ยวกับ CMU: การประยุกต์ใช้มาตรฐานหรือแบบฝึกหัด (เช่น CMMI) จะไม่เปลี่ยนงานของคนให้เป็นวิศวกรรมโดยอัตโนมัติ อย่างไรก็ตามความจริงที่ว่ามีการจัดระเบียบที่ดำเนินการวิจัยทางวิทยาศาสตร์เพื่อให้การปฏิบัติใหม่เป็นสัญญาณอีกครั้งว่ามีสิ่งเช่นวิศวกรรม

ไม่มันไม่ใช่วิศวกรรม เราไม่ใช่นักวิทยาศาสตร์และเราไม่จำเป็นต้องผ่านการทดสอบทางวิศวกรรมใด ๆ เลย ในความเป็นจริงมันผิดกฎหมายที่จะเรียกตัวเองว่า "วิศวกร" ซอฟต์แวร์ในบางสถานที่เนื่องจากขาดการทดสอบ

IMHO คำว่า 'วิศวกรรมซอฟต์แวร์' ได้รับการประกาศเกียรติคุณเพื่อพยายามอธิบายสิ่งต่าง ๆ ที่นักพัฒนาทำมากกว่าเพียงแค่เป็น 'โปรแกรมเมอร์' (ซึ่งมีความซับซ้อนของกระบวนการกลไกด้วยความคิดหรือความคิดสร้างสรรค์เพียงเล็กน้อย)

โดยส่วนตัวแล้วฉันชอบการเปรียบเทียบที่เกิดขึ้นใหม่ของนักพัฒนาในฐานะ 'ช่างฝีมือ' ที่ได้รับการสนับสนุนจากโปรแกรมเมอร์ที่ใช้งานจริงและอื่น ๆ

ในอดีตผู้คนพยายามที่จะสร้างการผลิตซอฟต์แวร์แบบอะนาล็อก ผมคิดว่าแจ็ครีฟส์ทำอาร์กิวเมนต์ที่ดีงามที่จะทำลายความคิดนี้ในบทความของเขาคืออะไรการออกแบบซอฟแวร์

จาก Wiki:

วิศวกรรม:

วิศวกรรมซอฟต์แวร์คือการประยุกต์ใช้วิธีการที่เป็นระบบมีระเบียบวินัยเชิงปริมาณเพื่อการพัฒนาการดำเนินงานและการบำรุงรักษาซอฟต์แวร์และการศึกษาวิธีการเหล่านี้ นั่นคือการประยุกต์ใช้ทางวิศวกรรมกับซอฟต์แวร์

การพัฒนาซอฟต์แวร์

การพัฒนาซอฟต์แวร์เป็นชุดของกิจกรรมที่ก่อให้เกิดผลิตภัณฑ์ซอฟต์แวร์ การพัฒนาซอฟต์แวร์อาจรวมถึงการวิจัยการพัฒนาใหม่การดัดแปลงการใช้ซ้ำการทำวิศวกรรมซ้ำการบำรุงรักษาหรือกิจกรรมอื่นใดที่ส่งผลให้เกิดผลิตภัณฑ์ซอฟต์แวร์ [1]

โดยเฉพาะในระยะแรกของกระบวนการพัฒนาซอฟต์แวร์อาจเกี่ยวข้องกับหลายแผนกรวมถึงการตลาดวิศวกรรมการวิจัยและพัฒนาและการจัดการทั่วไป

ดังนั้นพวกมันจึงค่อนข้างคล้ายกันและอาจหมายถึงสิ่งเดียวกัน

จาก Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

–noun 1. ศิลปะหรือวิทยาศาสตร์ในการประยุกต์ใช้ความรู้ทางวิทยาศาสตร์บริสุทธิ์ในทางปฏิบัติเช่นฟิสิกส์หรือเคมีเช่นเดียวกับในการสร้างเครื่องยนต์สะพานอาคารเหมืองเรือเรือและโรงงานเคมี

ฉันจะบอกว่าการสร้างซอฟต์แวร์เป็นแอพพลิเคชั่นที่ใช้งานได้จริงของคณิตศาสตร์และวิทยาการคอมพิวเตอร์

[แก้ไข] FWIW ฉันไม่เรียกตัวเองว่าเป็นวิศวกรซอฟต์แวร์ แต่เป็นนักพัฒนาซอฟต์แวร์ดังนั้นฉันจึงไม่มีส่วนร่วมในเรื่องนี้

ในมุมมองของฉันวิศวกรซอฟต์แวร์และนักพัฒนาซอฟต์แวร์เป็นสองสิ่งที่แตกต่างกัน

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

พัฒนาซอฟต์แวร์จะเกี่ยวข้องอย่างใกล้ชิดกับโปรแกรมเมอร์ แต่มีทักษะมากขึ้นในพื้นที่อื่น ๆ เช่นการจัดการฐานข้อมูล ฯลฯ ..

สิ่งหนึ่งที่น่าสนใจที่จะนำมาขึ้นเป็นสถาปัตยกรรม คนที่มีส่วนร่วมในการหาฮาร์ดแวร์ / ซอฟต์แวร์ที่จำเป็นสำหรับวงจรชีวิตของโครงการ

ฉันจะไปกับ "ไม่" ที่นี่ พี่ชายของฉันเป็นวิศวกรเครื่องกลและเขาอธิบายวิศวกรรมว่า "ศิลปะแห่งการถูก":

"วิศวกรที่มีความกังวลมากขึ้นกับการรับสิ่งที่กระทำให้เร็วที่สุดเท่าที่เป็นไปได้ที่ต้นทุนต่ำสุดที่เป็นไปได้ด้วยวัสดุที่น้อยที่สุดที่เป็นไปได้. "

โดยทั่วไปแล้วฉันได้อธิบายการพัฒนาซอฟต์แวร์ (ไม่ใช่วิศวกรรมซอฟต์แวร์ - พวกเขามีพื้นฐานที่แตกต่างกันสองประการ) ในฐานะ "The Art of Being Efficient":

"นักพัฒนาที่มีความกังวลมากขึ้นกับการรับสิ่งที่กระทำให้เร็วที่สุดเท่าที่เป็นไปได้ที่ต้นทุนต่ำสุดที่เป็นไปได้ที่มีจำนวนน้อยที่สุดของการทำซ้ำที่เป็นไปได้. "

ความแตกต่างอยู่ในส่วนสุดท้ายของประโยคเหล่านั้น

วิศวกรรมการพัฒนาซอฟต์แวร์เป็นอย่างไร

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

ฉันเห็นวิศวกร (เครื่องกลโครงสร้างซอฟต์แวร์) เป็นคนที่ออกแบบผลิตภัณฑ์ขึ้นกับความต้องการที่เข้าใจและความเข้าใจในสิ่งที่และวิธีการใช้วัสดุเพื่อรองรับความต้องการที่ต้องการ

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

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

ฉันเปรียบเสมือนความแตกต่างระหว่างคนงานก่อสร้างและวิศวกรโครงสร้างกับความแตกต่างระหว่างโปรแกรมเมอร์และวิศวกรซอฟต์แวร์

เพื่อความกระจ่างแจ้งฉันมีประกาศนียบัตรวิทยาลัยเท่านั้นจึงไม่สามารถเรียกตัวเองว่าวิศวกร

ฉันไม่คิดว่าคำว่า "วิศวกรรม" เป็นคำที่เหมาะสมที่สุดในการอธิบายการพัฒนาซอฟต์แวร์ด้วยเหตุผลหลัก 2 ข้อ:

• มันบ่งบอกถึงความคิดเก่า ๆ แนวคิดและสิ่งที่เรียกว่า "กฎทอง" ที่มีต้นกำเนิดในสาขาวิชาวิศวกรรมแบบดั้งเดิมเช่นอุตสาหกรรมโยธาพลเรือนทหารเรือหรือวิศวกรรมเครื่องกล ฉันกำลังพูดถึงกฎระเบียบในแผนกแรงงานกระบวนการผลิตมาตรฐานคุณภาพ ... ส่วนใหญ่มักใช้กับซอฟต์แวร์เพียงเล็กน้อยเท่านั้น

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

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

ใช่เราควรจะสามารถนำมาตรฐานและหลักการมาใช้กับผลิตภัณฑ์ที่เหมาะสม สิ่งที่ทำให้มันยากคือความคิดของลูกค้า (มันเป็นแค่รหัส - มันไม่ควรค่าใช้จ่ายมากนักที่จะเปลี่ยนแปลง) ความยากลำบากอย่างมากในการกำหนดสิ่งที่ผลิตภัณฑ์ควรทำในรหัสเครื่อง (พูด / เขียนภาษาเป็นรหัส) และปริมาณ " คุณภาพ". คำจำกัดความเรื่องคุณภาพของคุณไม่ใช่ของฉัน

นอกจากนี้ยังทำซ้ำได้ นำชุดของข้อกำหนดและมอบให้กับสองทีม เมื่อคุณสามารถทำสิ่งเดียวกัน (โดยไม่มีทีมพูดคุยกัน) คุณค่อนข้างใกล้เคียงกับวิศวกรรม

สาขาวิศวกรรมอื่น ๆ ก็มีบทลงโทษและมีการทบทวนและเซ็นชื่ออย่างเข้มงวด การรับผิดชอบ

ไม่วิศวกรรมซอฟต์แวร์ไม่ใช่วิศวกรรม ในความคิดของฉันความแตกต่างคือปริมาณของความคิดสร้างสรรค์ที่เกี่ยวข้อง ยกตัวอย่างเช่นในสาขาวิศวกรรมโยธาอาจมีความคิดสร้างสรรค์น้อยมากหรือไม่มีเลยก็ได้ นี่เป็นสิ่งที่ดี

ในการสร้างสะพานคุณมีข้อกำหนดจำนวนหนึ่ง (ฉันต้องได้จำนวนรถยนต์จากฝั่งนี้ของแม่น้ำนี้ไปอีกด้านหนึ่ง)

จากนี้ฉันสามารถอนุมาน:

1. จำนวนถนนที่ฉันต้องการ (ใช้การคำนวณมาตรฐานที่กำหนดโดยรัฐบาล)
2. โหลดฉันจะต้องสนับสนุน (ใช้การคำนวณที่กำหนดโดยรัฐบาล)
3. วัสดุที่ฉันต้องใช้เพื่อรองรับการโหลดเหล่านั้น (ใช้วัสดุมาตรฐานอย่างใดอย่างหนึ่งซึ่งฉันได้รับจากซัพพลายเออร์จำนวนมากหรือวัสดุที่ไม่ได้มาตรฐานซึ่งฉันต้องพิสูจน์ว่ามีคุณสมบัติที่ถูกต้อง)

จากนั้นฉันจะต้องได้รับการอนุมัติการออกแบบและตรวจสอบโดยบุคคลที่สาม (บริษัท อื่น) เพื่อให้แน่ใจว่าฉันได้ทำการคำนวณอย่างถูกต้องแล้ว

จากนั้นเมื่อสร้างสะพานจริงแล้วงานจะทำโดยคนที่มีคุณสมบัติตามมาตรฐาน พวกเขาจะทำงานที่พวกเขาทำหลายร้อยอาจหลายพันครั้งก่อน

อย่าเข้าใจฉันผิดทุกโครงการวิศวกรรมโยธาแตกต่างกัน แต่ดูเหมือนว่าทุกครั้งที่ฉันพัฒนาแอปพลิเคชัน / เว็บไซต์ใหม่

ใช่ฉันเดาว่าการพัฒนาเป็นส่วนหนึ่งของวิศวกรรม:

• วิศวกรรมซอฟต์แวร์รวมถึงข้อกำหนดเบื้องต้น ("เราต้องการซอฟต์แวร์ประเภทใดที่นี่") ซึ่งนำหน้าการพัฒนาเนื้อหา
• "วิศวกรรม" อาจรวมถึงการกำหนดกระบวนการประกันคุณภาพซึ่งเกี่ยวข้องกับการพัฒนาอย่างแน่นอน แต่อาจอยู่นอกขอบเขตของ 'การก่อสร้าง' ด้วย

Code Completeให้คำจำกัดความ "การก่อสร้าง" ว่ามีความหมายเหมือนกันกับการเข้ารหัสและการดีบัก (และการแสดงความคิดเห็น) รวมถึงการออกแบบที่มีรายละเอียดก่อนมือและด้วยการทดสอบหน่วยและการรวมระบบในภายหลัง บทที่ 1 ยินดีต้อนรับสู่การสร้างซอฟต์แวร์ (PDF)เริ่มต้นด้วยการแสดงรายการหัวข้อต่าง ๆ ในวงจรการพัฒนาซอฟต์แวร์โดยรวม (รวมถึงคำจำกัดความปัญหาสถาปัตยกรรมซอฟต์แวร์การบำรุงรักษาแก้ไข ฯลฯ ) จากนั้นพูดว่า

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

การพัฒนาซอฟต์แวร์เป็นวิศวกรรม

ข้อโต้แย้งเล็กน้อยจากผู้อื่นเพราะเหตุใดวิศวกรรมซอฟต์แวร์จึงไม่เป็นไปตามมาตรฐานของวิศวกร:

บางคนบอกว่าวิศวกรอยู่ในธุรกิจของการออกแบบ "สิ่งของ" เพื่อประโยชน์สาธารณะ - คือ ICBMs, รถถังและอื่น ๆ ในงานสาธารณะ? บางคนก็บอกว่าใช่ (ความผิดที่ดีเป็นการป้องกันที่ดี) คนอื่น ๆ ก็บอกว่าไม่ อย่างไรก็ตามฉันไม่คิดว่าใครจะไม่เห็นด้วยว่าคนที่ออกแบบระบบกำหนดเป้าหมายรถถังรุ่นต่อไปคือวิศวกร ผลิตภัณฑ์สาธารณะอาจเป็นอัตนัย ซอฟต์แวร์จำนวนมากอยู่ในระดับดีในที่สาธารณะดังนั้นประเด็นก็คือสิ่งที่สงสัยเช่นกัน

บางคนบอกว่าวิศวกรออกแบบพวกเขาไม่ได้สร้าง ฉันเคยเห็น "วิศวกรเครื่องกลไม่เชื่อม" หลายความคิดเห็น ฉันขอยืนยันว่าวิศวกรเครื่องกลสร้างพิมพ์เขียว - การออกแบบที่มีรายละเอียดซึ่งใช้อย่างอื่น หากวิศวกรเครื่องกลผลิตพิมพ์เขียวและป้อนเข้าเครื่อง CNC นั้นทำให้พวกเขาไม่ได้เป็นวิศวกรเครื่องกลอีกต่อไป - เพราะเครื่องจักรทำการติดตั้งใช้งานแทนบุคคลหรือไม่? ฉันจะยืนยันว่าซอร์สโค้ดเป็นพิมพ์เขียวโดยละเอียดที่ป้อนให้กับเครื่องจักรที่ใช้งานและฉันไม่สามารถดูได้ว่ามันแตกต่างจาก MechE ให้อาหารโค้ดกับเครื่องซีเอ็นซีอย่างไร และตอนนี้เรามีเครื่องพิมพ์ 3 มิตินั่นหมายถึงจุดสิ้นสุดของวิศวกรเครื่องกลหรือไม่? ตอนนี้พวกเขาเป็นนักพัฒนาเครื่องกลหรือไม่?

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