โมเดลเกลียว (Spiral Model ) เป็น โมเดล กระบวนการพัฒนาซอฟต์แวร์ ที่ขับเคลื่อนด้วยความเสี่ยง โดยอิงจากรูปแบบความเสี่ยงเฉพาะของโครงการนั้นๆ โมเดลเกลียวจะนำทางทีมให้ปรับใช้องค์ประกอบของโมเดลกระบวนการอย่างน้อยหนึ่งแบบ เช่น แบบเพิ่มทีละน้อย(Incremental) , แบบ น้ำตก (Waterfall ) หรือแบบสร้างต้นแบบเชิงวิวัฒนาการ (Evolutionary Prototyping )

แบบจำลองนี้ได้รับการอธิบายครั้งแรกโดยBarry Boehmในบทความปี 1986 ของเขาเรื่อง "แบบจำลองเกลียวของการพัฒนาและปรับปรุงซอฟต์แวร์" ^{[ 2 ]}ในปี 1988 Boehm ได้ตีพิมพ์บทความที่คล้ายกัน^{[ 3 ]}ให้กับกลุ่มผู้อ่านที่กว้างขึ้น บทความเหล่านี้ได้นำเสนอแผนภาพที่ได้รับการทำซ้ำในสิ่งพิมพ์หลายฉบับต่อมาที่กล่าวถึงแบบจำลองเกลียว

เอกสารในช่วงแรกๆ เหล่านี้ใช้คำว่า "แบบจำลองกระบวนการ" เพื่ออ้างถึงแบบจำลองเกลียว (spiral model) รวมถึงวิธีการแบบเพิ่มทีละน้อย (incremental), แบบน้ำตก (waterfall), การสร้างต้นแบบ (prototyping) และวิธีการอื่นๆ อย่างไรก็ตาม ลักษณะเฉพาะของแบบจำลองเกลียวที่ผสมผสานคุณสมบัติของแบบจำลองกระบวนการอื่นๆ โดยคำนึงถึงความเสี่ยงนั้นมีอยู่แล้วในเอกสารก่อนหน้านี้

การแบ่งย่อยตามความเสี่ยงของขั้นตอนโมเดลเกลียวช่วยให้โมเดลสามารถรองรับการผสมผสานที่เหมาะสมของแนวทางการพัฒนาซอฟต์แวร์ที่เน้นข้อกำหนด เน้นต้นแบบ เน้นการจำลอง เน้นการแปลงอัตโนมัติ หรือแนวทางอื่นๆ^{[ 3 ]}

ในสิ่งพิมพ์ต่อมา^{[ 1 ]} Boehm อธิบายโมเดลเกลียวว่าเป็น "ตัวสร้างโมเดลกระบวนการ" โดยที่การเลือกตามความเสี่ยงของโครงการจะสร้างโมเดลกระบวนการที่เหมาะสมสำหรับโครงการ ดังนั้น โมเดลกระบวนการแบบเพิ่มขึ้น แบบน้ำตก แบบสร้างต้นแบบ และแบบอื่นๆ จึงเป็นกรณีพิเศษของโมเดลเกลียวที่เหมาะสมกับรูปแบบความเสี่ยงของโครงการบางโครงการ

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

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

แม้ว่าความเข้าใจผิดเหล่านี้อาจสอดคล้องกับรูปแบบความเสี่ยงของโครงการบางโครงการ แต่ก็ไม่เป็นความจริงสำหรับโครงการส่วนใหญ่

ในรายงานของสภาวิจัยแห่งชาติ^{[ 4 ]}แบบจำลองนี้ได้รับการขยายให้ครอบคลุมถึงความเสี่ยงที่เกี่ยวข้องกับผู้ใช้ที่เป็นมนุษย์

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

การประยุกต์ใช้โมเดลเกลียวอย่างแท้จริงนั้นขับเคลื่อนด้วยวงจรที่แสดงลักษณะหกประการเสมอ โบห์มอธิบายแต่ละอย่างด้วยตัวอย่างของ "เกลียวที่ดูคล้ายกันแต่อันตราย" ซึ่งละเมิดความไม่เปลี่ยนแปลง^{[ 1 ]}

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

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

1. ข้อกำหนดต่างๆ เป็นที่ทราบล่วงหน้าก่อนการดำเนินการ
2. ข้อกำหนดเหล่านี้ไม่มีผลกระทบที่ยังไม่ได้รับการแก้ไขและมีความเสี่ยงสูง เช่น ความเสี่ยงเนื่องจากต้นทุน กำหนดการ ประสิทธิภาพ ความปลอดภัย ส่วนติดต่อผู้ใช้ ผลกระทบต่อองค์กร เป็นต้น
3. ลักษณะของข้อกำหนดจะไม่เปลี่ยนแปลงมากนักในระหว่างการพัฒนาหรือการปรับปรุง
4. ข้อกำหนดเหล่านี้สอดคล้องกับความคาดหวังของผู้มีส่วนได้ส่วนเสียหลักทั้งหมดของระบบ รวมถึงผู้ใช้ ลูกค้า นักพัฒนา ผู้ดูแลระบบ และนักลงทุน
5. เป็นที่เข้าใจกันดีถึงโครงสร้างสถาปัตยกรรมที่เหมาะสมสำหรับการดำเนินการตามข้อกำหนดต่างๆ
6. มีเวลาตามปฏิทินเพียงพอที่จะดำเนินการตามลำดับได้

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

ตัวแปรคงที่นี้ระบุถึงกิจกรรมสี่อย่างที่ต้องเกิดขึ้นในแต่ละรอบของแบบจำลองเกลียว:

1. พิจารณาเงื่อนไขแห่งชัยชนะของผู้มีส่วนได้ส่วนเสียทุกฝ่ายที่มีความสำคัญต่อความสำเร็จ
2. ระบุและประเมินแนวทางทางเลือกต่างๆ เพื่อให้บรรลุเงื่อนไขแห่งชัยชนะ
3. ระบุและแก้ไขความเสี่ยงที่เกิดจากแนวทางที่เลือกใช้
4. ขออนุมัติจากผู้มีส่วนได้ส่วนเสียที่สำคัญต่อความสำเร็จทั้งหมด พร้อมทั้งขอคำมั่นสัญญาว่าจะดำเนินการในรอบต่อไป

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

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

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

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

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

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

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

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

1. วัตถุประสงค์ของวงจรชีวิตโครงการ มีการกำหนดแนวทางทางเทคนิคและการจัดการที่เพียงพอเพื่อตอบสนองเงื่อนไขที่ทุกฝ่ายต้องการหรือไม่? หากผู้มีส่วนได้ส่วนเสียเห็นพ้องต้องกันว่าคำตอบคือ "ใช่" โครงการก็ผ่านพ้นหลักชัยของวงจรชีวิตโครงการนี้ไปแล้ว มิฉะนั้น โครงการอาจถูกยกเลิก หรือผู้มีส่วนได้ส่วนเสียอาจเริ่มต้นวงจรใหม่เพื่อพยายามให้ได้คำตอบว่า "ใช่" อีกครั้ง
2. สถาปัตยกรรมวงจรชีวิต (Life Cycle Architecture: LCA) มีการกำหนดแนวทางที่เหมาะสมที่สุดเพื่อตอบสนองเงื่อนไขแห่งชัยชนะของทุกฝ่ายอย่างเพียงพอหรือไม่ และความเสี่ยงที่สำคัญทั้งหมดถูกกำจัดหรือลดทอนลงแล้วหรือไม่? หากผู้มีส่วนได้ส่วนเสียเห็นพ้องต้องกันว่าคำตอบคือ "ใช่" โครงการก็ผ่านด่านสำคัญของ LCA นี้แล้ว มิเช่นนั้น โครงการอาจถูกยกเลิก หรือผู้มีส่วนได้ส่วนเสียสามารถเริ่มต้นวงจรใหม่เพื่อพยายามให้ได้คำตอบว่า "ใช่" อีกครั้ง
3. ความสามารถในการปฏิบัติงานขั้นต้น (Initial Operational Capability: IOC) มีการเตรียมการด้านซอฟต์แวร์ เว็บไซต์ ผู้ใช้ ผู้ปฏิบัติงาน และผู้ดูแลระบบอย่างเพียงพอหรือไม่ เพื่อให้เป็นไปตามเงื่อนไขที่ทุกฝ่ายต้องการเมื่อเปิดใช้งานระบบ? หากผู้มีส่วนได้ส่วนเสียเห็นพ้องต้องกันว่าคำตอบคือ "ใช่" โครงการก็จะผ่านด่าน IOC และสามารถเปิดใช้งานได้ มิเช่นนั้น โครงการอาจถูกยกเลิก หรือผู้มีส่วนได้ส่วนเสียอาจเริ่มต้นรอบใหม่เพื่อพยายามให้ได้คำตอบว่า "ใช่" อีกครั้ง

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

จุดสำคัญทั้งสามจุดนี้สอดคล้องกับกระบวนการ Rational Unified Process (RUP) อย่างลงตัว โดย LCO เป็นจุดแบ่งระหว่างขั้นตอนการเริ่มต้นและการพัฒนาของ RUP, LCA เป็นจุดแบ่งระหว่างขั้นตอนการพัฒนาและการก่อสร้าง และ IOC เป็นจุดแบ่งระหว่างขั้นตอนการก่อสร้างและการเปลี่ยนผ่าน

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