ความแตกต่างระหว่างวิธีการที่เพิ่มขึ้นและซ้ำไปสู่การพัฒนาซอฟต์แวร์คืออะไร?


16

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

การออกแบบซ้ำ (Iterative Design ) เป็นวิธีการออกแบบโดยใช้กระบวนการวงจรการสร้างต้นแบบการทดสอบการวิเคราะห์และการปรับแต่งผลิตภัณฑ์หรือกระบวนการ จากผลของการทดสอบซ้ำล่าสุดของการออกแบบการเปลี่ยนแปลงและการปรับแต่งจะทำ กระบวนการนี้มีวัตถุประสงค์เพื่อปรับปรุงคุณภาพและการทำงานของการออกแบบในที่สุด ในการออกแบบซ้ำจะใช้การโต้ตอบกับระบบที่ออกแบบมาเป็นรูปแบบของการวิจัยเพื่อแจ้งและพัฒนาโครงการเป็นเวอร์ชันต่อเนื่องหรือมีการดำเนินการวนซ้ำของการออกแบบ

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

ความแตกต่างที่แท้จริงระหว่างสองวิธีในการออกแบบซอฟต์แวร์คืออะไร

เป็นไปได้อย่างไรที่จะรวมสองวิธีนี้เพื่อสร้างวิธีการออกแบบซ้ำและเพิ่มขึ้น

คำตอบ:


13

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

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

วิธีย้ำไม่มีจำนวนชุดของขั้นตอนการพัฒนาค่อนข้างจะทำในรอบ

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


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

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

tl; dr - หากคุณกำลังเขียนเรียงความภายใต้แบบจำลองเพิ่มเติมคุณจะพยายามเขียนมันอย่างสมบูรณ์ตั้งแต่ต้นจนจบหนึ่งประโยคในเวลา หากคุณเขียนมันภายใต้ Iterative Model คุณจะต้องทำการร่างแบบคร่าวๆอย่างรวดเร็วและพยายามปรับปรุงมันผ่านชุดของเฟสการแก้ไข


ปรับปรุง:

ฉันแก้ไขคำจำกัดความของฉันสำหรับ 'วิธีการเพิ่มเติม' เพื่อให้พอดีกับตัวอย่างที่ใช้งานได้จริงมากขึ้น

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

ขั้นตอนดำเนินการดังนี้:

  • รางวัลสัญญา
  • ทบทวนการออกแบบเบื้องต้น
  • รีวิวการออกแบบที่สำคัญ
  • ข้อกำหนดตรึง
  • พัฒนาการ
  • ฟีลดิง / บูรณาการ
  • การตรวจสอบ
  • การทดสอบความน่าเชื่อถือ

PDR และ CDR คือตำแหน่งที่สร้างและแก้ไขข้อมูลจำเพาะ เมื่อข้อมูลจำเพาะเสร็จสมบูรณ์ควรจะถูกแช่แข็งเพื่อป้องกันการคืบของขอบเขต การรวมเกิดขึ้นหากใช้ซอฟต์แวร์เพื่อขยายระบบที่มีอยู่แล้ว การยืนยันใช้สำหรับตรวจสอบว่าแอปพลิเคชันตรงกับข้อกำหนด ความน่าเชื่อถือเป็นการทดสอบเพื่อพิสูจน์ว่าแอปพลิเคชันจะมีความน่าเชื่อถือในระยะยาวซึ่งสามารถระบุได้เช่น SLA (Service Level Agreement) ซึ่งระบบจะต้องรักษาเปอร์เซ็นต์การทำงานต่อเนื่อง (เช่น 99% uptime เป็นเวลา 3 เดือน) )

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

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


+1 สำหรับตัวอย่างที่ดีถึงแม้ว่าคำอธิบายที่เพิ่มขึ้นดูเหมือนว่าฉันจะผิด
Basilevs

@Basilevs นั้นดีขึ้นหรือไม่
Evan Plaice

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

0

เช่นเดียวกับคำคุณศัพท์ใด ๆ และส่วนใหญ่ในการพัฒนาซอฟต์แวร์ ... มันขึ้นอยู่กับ!

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

ดังนั้นการตอบเฉพาะเป็นการพัฒนาซอฟต์แวร์ ..

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

การพัฒนาซอฟต์แวร์ซ้ำโดยธรรมชาติของมันเพิ่มขึ้น การพัฒนาซอฟต์แวร์เพิ่มเติมไม่จำเป็นต้องวนซ้ำ

การเพิ่มขึ้นเป็นการเคลื่อนไหวเล็ก ๆ หวังว่าจะส่งต่อ เป็นวิธีการอ้างถึงแต่ละขั้นตอนของงานที่ดำเนินการ

การวนซ้ำเป็นวัฏจักรของการทำงาน

ดังนั้นการวนซ้ำหมายถึงวัฏจักรการพัฒนาโดยรวมที่ใช้ การเพิ่มขึ้นหมายถึงแต่ละขั้นตอนของการทำงาน การวนซ้ำจะสร้างการเพิ่มขึ้นซึ่งประกอบด้วยการเพิ่มขึ้นจริงหนึ่งครั้งหรือมากกว่ากับซอฟต์แวร์ (โดยปกติจะมากกว่า)

สรุปแล้ว...

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

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

และในที่สุดแน่นอนขึ้นอยู่กับความหมายของคำว่าเมื่อใช้ซึ่งมักแตกต่างกันอย่างมากโดยผู้พูดเวลาของเดือนและอื่น ๆ !

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

หวังว่านี่จะช่วยได้

บทความนี้อธิบายได้ดีพร้อมตัวอย่าง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.