สร้างหนึ่งเพื่อทิ้งไปกับเอฟเฟกต์ระบบที่สอง

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

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

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

ฉันเชื่อว่า "แนวทางปฏิบัติที่ดี" เหล่านี้ได้รับการส่งเสริมเป็นครั้งแรกในหนังสือน้ำเชื้อThe Mythical Man-Monthโดย Fred Brooks

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

สร้างจากการโยนทิ้งมาจาก "ไม่รู้ว่าคุณไม่รู้อะไร" ตอนเริ่มต้นดังนั้นคุณเรียนรู้เมื่อคุณไปในสิ่งที่ควรทำเมื่อเริ่มต้น

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

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

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

ปัญหาที่คุณอ้างถึงหมายความว่ามีหลายสิ่งที่ข้ามไปดังนั้นระบบผลลัพธ์จึงผิดพลาด ให้ฉันอธิบายขั้นตอนที่ขาดหายไปบางส่วน:

การจัดการคุณภาพ - ทำถูกต้องในครั้งแรก! อย่าใช้แฮ็กชั่วคราวหรือประนีประนอมชั่วคราว จะไม่มีการทำใหม่ที่จำเป็น ทรัพยากรทั้งหมดถูกใช้อย่างมีประสิทธิภาพและทุกสิ่งที่คุณทำคือการมีส่วนร่วมในโครงการอย่างเหมาะสม

การวิเคราะห์ความเป็นไปได้ - ค้นหาความต้องการทางธุรกิจ สร้างกรณีธุรกิจสำหรับโครงการ

แผนโครงการ - กำหนดขอบเขตเริ่มต้นของคุณอย่างชัดเจนวางแผนว่าจะส่งมอบโซลูชันสร้างพื้นฐานทำตามแผน อย่าใช้เวลากับสิ่งใดก็ตามที่ไม่ได้อยู่บนเส้นทางวิกฤติ

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

การออกแบบซอฟต์แวร์ - แปลกรณีการใช้งานและรูปแบบโดเมนไปยังการออกแบบส่วนประกอบและสถาปัตยกรรมโซลูชัน ส่วนประกอบทั้งหมดจะต้องเชื่อมโยงกับข้อกำหนดจาก RE

การติดตั้งใช้งาน - กำหนดรหัสซอฟต์แวร์ตามที่ออกแบบไว้ รหัสทั้งหมดจะต้องเชื่อมโยงกับส่วนประกอบจาก SD

การตรวจสอบความถูกต้อง - การทดสอบหน่วย, การทดสอบการรวม, ประสิทธิภาพ, ... (ทุกกรณีการใช้งานจาก RE จะต้องถูกทดสอบ)

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

ค้นหาคำศัพท์เหล่านี้เพื่อสร้างซอฟต์แวร์ที่ดีขึ้นและทำให้ถูกต้องในครั้งแรก:

• การวิเคราะห์ความเป็นไปได้ (โดยเฉพาะการสร้างกรณีศึกษาทางธุรกิจ)
• การจัดการโครงการ (โดยเฉพาะแผนโครงการและการลงทะเบียนความเสี่ยงด้วยการลดความเสี่ยง)
• วิศวกรรมความต้องการ (elicitation การวิเคราะห์ข้อมูลจำเพาะการตรวจสอบ)
• การออกแบบซอฟต์แวร์ (UML และวิศวกรรมซอฟต์แวร์ที่อิงองค์ประกอบ)
• การสร้างซอฟต์แวร์ (รูปแบบการออกแบบกรอบการเขียนโปรแกรมการป้องกัน)
• การตรวจสอบซอฟต์แวร์ (การทดสอบหน่วย, UAT, ฯลฯ )