วิธีการพัฒนาซอฟต์แวร์ใดที่สามารถถูกมองว่าเป็นรากฐาน

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

ตัวอย่างเช่นดูที่วิธีการต่อไปนี้:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD

เราสามารถพูดได้
ไหมว่า: การทำต้นแบบการทำซ้ำการวนและน้ำตกเป็น "รากฐาน" สำหรับผู้อื่นหรือไม่?

หรือไม่มีสิ่งเช่น "รากฐาน" และแต่ละวิธีการมีประวัติที่เป็นเอกลักษณ์ของตัวเองหรือไม่?

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

ชื่อในรายการของคุณไม่ใช่วิธีการทั้งหมดและจะขยายตามระดับที่แตกต่างกัน:

• การทำซ้ำเป็นลักษณะเป็นลักษณะที่ใช้ร่วมกันโดยวิธีการและเทคนิคต่าง ๆ การแย่งชิงกันเป็นวิธีการวนซ้ำ TDD เป็นเทคนิคการวนซ้ำ
• ฉันเห็นว่า Agile เป็นวิธีการที่ใช้แทนที่เซ็ตอัพที่ยังคงอยู่ในระดับแนวคิด / ปรัชญา ในการเขียนโปรแกรมเชิงวัตถุคุณสามารถอธิบายว่ามันเป็นนามธรรม - เป็นชุดของค่าและหลักการที่ไม่สามารถสร้างอินสแตนซ์และต้องได้รับและนำไปใช้ นั่นคือสิ่งที่ Scrum และ XP ทำ
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model เป็นวิธีการที่เหมาะสมเช่นกระบวนการพัฒนาซอฟต์แวร์
• การสร้างต้นแบบและ TDD เป็นเทคนิคกิจกรรม TDD เป็นแบบฝึกหัด XP

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

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

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

มีสาม:

1. ไม่มี (การเข้ารหัสคาวบอย aka)
2. น้ำตก
3. การพัฒนาแอพพลิเคชั่นอย่างรวดเร็ว (RAD หรือ Spiral)

ส่วนที่เหลือเป็นสายพันธุ์และการรวมกันของเหล่านี้

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

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

บางทีคุณต้องการพูดถึงวิธีโบราณ (ไม่ใช่ 'ระเบียบวิธี) เช่น:

1. การประมวลผลแบบแบตช์: ส่งสำรับไพ่และรับผลลัพธ์ในวันถัดไป ข้อเสีย: ใช้เวลาระหว่างการส่งมากเกินไป สำหรับการดีบักศึกษาดัมพ์หลัก

2. วิธีการ cli - ใช้ vi หรือ emacs จากนั้นรวบรวม ทั้งหมดจากบรรทัดคำสั่งเช่นเดียวกับที่ทำในเชลล์ลินุกซ์จนถึงทุกวันนี้ ข้อเสีย: ยากต่อการดีบัก (gdb คุณเป็น kiddin 'me?) ปิดบังคำสั่งเชลล์อายุ 40 ปี

แค่ความคิด

คุณสามารถพูดถึงสามวิธีพื้นฐาน ได้แก่ การทำต้นแบบเกลียวและน้ำตก ฉันจะไม่ถือว่า Lean, TDD หรือ Cleanroom เป็นวิธีการ แต่เป็นกระบวนการที่สามารถเป็นส่วนหนึ่งของวิธีการได้