หนึ่งในแนวทางที่เป็นไปได้ในการพัฒนาซอฟต์แวร์ภายในกรอบของแบบจำลองวงจรชีวิตแบบเกลียวคือแนวทางที่ได้รับ เมื่อเร็วๆ นี้การใช้ระเบียบวิธี RAD (Rapid Application Development) อย่างแพร่หลาย คำนี้มักจะหมายถึงกระบวนการพัฒนาซอฟต์แวร์ที่มีองค์ประกอบ 3 ประการ:
ทีมโปรแกรมเมอร์กลุ่มเล็ก (ตั้งแต่ 2 ถึง 10 คน)
ตารางการผลิตสั้น แต่จัดทำอย่างรอบคอบ (ตั้งแต่ 2 ถึง 6 เดือน)
วงจรที่เกิดซ้ำซึ่งนักพัฒนาเมื่อแอปพลิเคชันเริ่มเป็นรูปเป็นร่าง ร้องขอ และนำไปใช้ ข้อกำหนดของผลิตภัณฑ์ที่ได้รับจากการมีปฏิสัมพันธ์กับลูกค้า
ทีมพัฒนาควรเป็นกลุ่มผู้เชี่ยวชาญที่มีประสบการณ์ในด้านการวิเคราะห์ การออกแบบ การสร้างโค้ด และการทดสอบซอฟต์แวร์โดยใช้เครื่องมือของ CASE สมาชิกในทีมจะต้องสามารถแปลคำแนะนำของผู้ใช้ปลายทางให้เป็นต้นแบบที่ใช้งานได้
วงจรชีวิตซอฟต์แวร์ตามวิธี RAD ประกอบด้วยสี่ระยะ:
ขั้นตอนการวิเคราะห์และวางแผนความต้องการ
ขั้นตอนการออกแบบ
ขั้นตอนการก่อสร้าง
ขั้นตอนการดำเนินการ
ในขั้นตอนของการวิเคราะห์และการวางแผนความต้องการ ผู้ใช้ระบบจะกำหนดฟังก์ชันที่จะต้องดำเนินการ ระบุลำดับความสำคัญสูงสุดที่ต้องมีการพิจารณาอย่างละเอียดก่อน และอธิบายความต้องการข้อมูล การกำหนดข้อกำหนดส่วนใหญ่ดำเนินการโดยผู้ใช้ภายใต้คำแนะนำของนักพัฒนาผู้เชี่ยวชาญ ขอบเขตของโครงการมีจำกัด และกรอบเวลาสำหรับแต่ละระยะต่อมาจะถูกกำหนด นอกจากนี้ยังกำหนดความเป็นไปได้ในการดำเนินการด้วย ของโครงการนี้ภายในขีดจำกัดเงินทุนที่กำหนดไว้ บนฮาร์ดแวร์ที่กำหนด ฯลฯ ผลลัพธ์ของระยะนี้ควรเป็นรายการและลำดับความสำคัญของฟังก์ชันต่างๆ ของ IS ในอนาคต แบบจำลองการทำงานและข้อมูลเบื้องต้นของ IS
ในระหว่างขั้นตอนการออกแบบ ผู้ใช้บางรายมีส่วนร่วมในการออกแบบทางเทคนิคของระบบภายใต้คำแนะนำของนักพัฒนาผู้เชี่ยวชาญ เครื่องมือ CASE ใช้เพื่อสร้างต้นแบบแอปพลิเคชันที่ทำงานได้อย่างรวดเร็ว ผู้ใช้โต้ตอบโดยตรงกับพวกเขา ชี้แจงและเสริมข้อกำหนดของระบบที่ไม่ได้ระบุไว้ในระยะก่อนหน้า มีการกล่าวถึงกระบวนการของระบบโดยละเอียด แบบจำลองการทำงานได้รับการวิเคราะห์และปรับเปลี่ยนหากจำเป็น แต่ละกระบวนการได้รับการพิจารณาอย่างละเอียด หากจำเป็น จะมีการสร้างต้นแบบบางส่วนสำหรับแต่ละกระบวนการเบื้องต้น ได้แก่ หน้าจอ กล่องโต้ตอบ รายงานที่ขจัดความคลุมเครือหรือความกำกวม มีการกำหนดข้อกำหนดสำหรับการจำกัดการเข้าถึงข้อมูล ในขั้นตอนเดียวกัน จะมีการกำหนดชุดเอกสารที่จำเป็น
หลังจากกำหนดรายละเอียดขององค์ประกอบของกระบวนการแล้ว จำนวน องค์ประกอบการทำงานระบบที่กำลังได้รับการพัฒนาและมีการตัดสินใจที่จะแบ่ง IS ออกเป็นระบบย่อยที่ทีมนักพัฒนาหนึ่งทีมสามารถนำไปใช้ได้ในเวลาที่ยอมรับได้สำหรับโครงการ RAD - ประมาณ 60 - 90 วัน การใช้เครื่องมือ CASE โปรเจ็กต์จะถูกกระจายไปยังทีมต่างๆ (แบ่งโมเดลการทำงาน) ผลลัพธ์ของระยะนี้ควรเป็น:
ทั่วไป รูปแบบข้อมูลระบบ;
โมเดลการทำงานของระบบโดยรวมและระบบย่อยที่ดำเนินการโดยทีมพัฒนาแต่ละทีม
อินเทอร์เฟซที่กำหนดไว้อย่างแม่นยำระหว่างระบบย่อยที่พัฒนาอัตโนมัติโดยใช้เครื่องมือ CASE
สร้างต้นแบบของหน้าจอ รายงาน กล่องโต้ตอบ
จะต้องได้รับแบบจำลองและต้นแบบทั้งหมดโดยใช้เครื่องมือของ CASE ที่จะใช้ในอนาคตเมื่อสร้างระบบ ข้อกำหนดนี้เนื่องจากในแนวทางดั้งเดิม เมื่อถ่ายโอนข้อมูลเกี่ยวกับโครงการจากขั้นตอนหนึ่งไปยังอีกขั้นตอนหนึ่ง อาจเกิดการบิดเบือนข้อมูลที่ไม่สามารถควบคุมได้ การใช้สภาพแวดล้อมที่เป็นหนึ่งเดียวในการจัดเก็บข้อมูลโครงการช่วยให้คุณหลีกเลี่ยงอันตรายนี้ได้
แตกต่างจากวิธีการแบบดั้งเดิมซึ่งใช้เครื่องมือสร้างต้นแบบเฉพาะที่ไม่ได้ออกแบบมาเพื่อสร้างแอปพลิเคชันจริงและต้นแบบที่ถูกทิ้งไปหลังจากที่ใช้เพื่อวัตถุประสงค์ในการขจัดความคลุมเครือในการออกแบบ ในแนวทาง RAD แต่ละต้นแบบจะได้รับการพัฒนาเป็นส่วนหนึ่ง ระบบในอนาคต- ดังนั้นข้อมูลที่ครบถ้วนและเป็นประโยชน์จึงถูกถ่ายโอนไปยังขั้นตอนต่อไป
ขั้นตอนการก่อสร้างคือช่วงที่การพัฒนาแอปพลิเคชันเกิดขึ้นอย่างรวดเร็ว ในขั้นตอนนี้ นักพัฒนาจะสร้างระบบจริงซ้ำๆ ตามแบบจำลองที่ได้รับในขั้นตอนก่อนหน้า รวมถึงข้อกำหนดที่ไม่สามารถใช้งานได้ โค้ดโปรแกรมถูกสร้างขึ้นบางส่วนโดยใช้ตัวสร้างอัตโนมัติที่รับข้อมูลโดยตรงจากคลังเครื่องมือ CASE ในขั้นตอนนี้ ผู้ใช้จะประเมินผลลัพธ์ที่ได้รับและทำการปรับเปลี่ยนหากระบบไม่ตรงตามข้อกำหนดที่กำหนดไว้ก่อนหน้านี้อีกต่อไปในระหว่างกระบวนการพัฒนา การทดสอบระบบจะดำเนินการโดยตรงในระหว่างกระบวนการพัฒนา
หลังจากเสร็จสิ้นการทำงานของทีมพัฒนาแต่ละทีมแล้ว จะมีการบูรณาการส่วนนี้ของระบบกับส่วนที่เหลืออย่างค่อยเป็นค่อยไป โดยสมบูรณ์ รหัสโปรแกรมการทดสอบจะดำเนินการเพื่อทดสอบว่าส่วนนี้ของแอปพลิเคชันทำงานร่วมกับส่วนอื่นๆ อย่างไร จากนั้นจึงทดสอบระบบโดยรวม การออกแบบทางกายภาพของระบบเสร็จสมบูรณ์:
กำหนดความจำเป็นในการกระจายข้อมูล
มีการวิเคราะห์การใช้ข้อมูล
มีการออกแบบทางกายภาพของฐานข้อมูล
กำหนดข้อกำหนดสำหรับทรัพยากรฮาร์ดแวร์
มีการกำหนดวิธีเพิ่มผลผลิต
การพัฒนาเอกสารโครงการเสร็จสิ้นแล้ว
ผลลัพธ์ของขั้นตอนคือระบบที่เสร็จสมบูรณ์ซึ่งตรงตามข้อกำหนดที่ตกลงกันไว้ทั้งหมด
ในระหว่างขั้นตอนการดำเนินงาน จะมีการดำเนินการฝึกอบรมผู้ใช้ การเปลี่ยนแปลงองค์กร และควบคู่ไปกับการดำเนินการ ระบบใหม่งานจะดำเนินการกับระบบที่มีอยู่ (จนกว่าจะมีการใช้งานระบบใหม่อย่างสมบูรณ์) เนื่องจากขั้นตอนการก่อสร้างค่อนข้างสั้น การวางแผนและการเตรียมการสำหรับการดำเนินงานจึงต้องเริ่มต้นตั้งแต่เนิ่นๆ โดยปกติจะอยู่ระหว่างขั้นตอนการออกแบบระบบ โครงการพัฒนาไอเอสที่ให้มานั้นยังไม่สมบูรณ์ มีตัวเลือกต่าง ๆ ที่เป็นไปได้ ขึ้นอยู่กับเงื่อนไขเริ่มต้นที่ดำเนินการพัฒนา เช่น ระบบใหม่ทั้งหมดกำลังได้รับการพัฒนา มีการสำรวจวิสาหกิจแล้วและมีรูปแบบของกิจกรรมอยู่ องค์กรมี IP บางส่วนอยู่แล้วที่สามารถใช้เป็นต้นแบบเริ่มต้นหรือต้องรวมเข้ากับอันที่กำลังพัฒนา
อย่างไรก็ตาม ควรสังเกตว่าวิธีการของ RAD ไม่สามารถอ้างได้ว่าเป็นสากล เช่นเดียวกับวิธีอื่นๆ แต่วิธีนี้ดีสำหรับโครงการขนาดเล็กที่พัฒนาขึ้นสำหรับลูกค้าเฉพาะรายเป็นหลัก หากมีการพัฒนาระบบมาตรฐานซึ่งไม่ใช่ผลิตภัณฑ์สำเร็จรูป แต่เป็นส่วนประกอบมาตรฐานที่ซับซ้อน ได้รับการดูแลจากส่วนกลาง ปรับให้เข้ากับแพลตฟอร์มซอฟต์แวร์และฮาร์ดแวร์ DBMS โทรคมนาคม คุณลักษณะเชิงองค์กรและเศรษฐกิจของวัตถุการใช้งาน และบูรณาการกับการพัฒนาที่มีอยู่ สิ่งต่อไปนี้มาถึงก่อน: ตัวชี้วัดโครงการเช่นความสามารถในการจัดการและคุณภาพซึ่งอาจขัดแย้งกับความเรียบง่ายและรวดเร็วของการพัฒนา จำเป็นสำหรับโครงการดังกล่าว ระดับสูงการวางแผนและวินัยในการออกแบบที่เข้มงวด การยึดมั่นอย่างเคร่งครัดกับโปรโตคอลและอินเทอร์เฟซที่พัฒนาไว้ล่วงหน้า ซึ่งจะช่วยลดความเร็วของการพัฒนา
วิธีการ RAD ไม่สามารถใช้ได้กับการสร้างโปรแกรมการคำนวณที่ซับซ้อน ระบบปฏิบัติการ หรือโปรแกรมควบคุมยานอวกาศ เช่น โปรแกรมที่ต้องเขียนโค้ดที่ไม่ซ้ำกันจำนวนมาก (หลายแสนบรรทัด)
แอปพลิเคชันที่ไม่มีส่วนอินเทอร์เฟซที่กำหนดไว้อย่างชัดเจนซึ่งกำหนดตรรกะของระบบอย่างชัดเจน (เช่น แอปพลิเคชันแบบเรียลไทม์) และแอปพลิเคชันที่ความปลอดภัยของมนุษย์ขึ้นอยู่กับ (เช่น การควบคุมเครื่องบินหรือโรงไฟฟ้านิวเคลียร์) ไม่เหมาะ สำหรับการพัฒนาโดยใช้วิธี RAD เนื่องจากเป็นแนวทางซ้ำๆ จึงถือว่าเวอร์ชันแรกๆ อาจจะทำงานได้ไม่เต็มที่ ซึ่งในกรณีนี้จะไม่รวมอยู่ในกรณีนี้
ขนาดของแอปพลิเคชันประเมินตามองค์ประกอบที่เรียกว่าองค์ประกอบการทำงาน (หน้าจอ ข้อความ รายงาน ไฟล์ ฯลฯ) การวัดนี้ไม่ขึ้นอยู่กับภาษาการเขียนโปรแกรมที่ดำเนินการพัฒนา ขนาดของแอปพลิเคชันที่สามารถดำเนินการได้โดยใช้วิธีการ RAD สำหรับสภาพแวดล้อมการพัฒนา IC ที่ได้รับการยอมรับอย่างดีพร้อมการนำส่วนประกอบซอฟต์แวร์กลับมาใช้ใหม่ได้สูงสุด ถูกกำหนดดังนี้:
โดยสรุป เราจะแสดงรายการหลักการสำคัญของระเบียบวิธี RAD:
การพัฒนาแอปพลิเคชันในการวนซ้ำ
ทางเลือกของการทำงานให้เสร็จสิ้นในแต่ละขั้นตอนของวงจรชีวิต
การมีส่วนร่วมของผู้ใช้ในกระบวนการพัฒนา IS;
การใช้เครื่องมือ CASE ที่จำเป็นเพื่อรับรองความสมบูรณ์ของโครงการ
การใช้เครื่องมือการจัดการการกำหนดค่าที่อำนวยความสะดวกในการเปลี่ยนแปลงโครงการและการบำรุงรักษาระบบที่เสร็จสมบูรณ์
การใช้ตัวสร้างโค้ดที่จำเป็น
การใช้การสร้างต้นแบบเพื่อทำความเข้าใจและตอบสนองความต้องการของผู้ใช้ให้ดีขึ้น
การทดสอบและ การพัฒนาโครงการดำเนินการไปพร้อมกับการพัฒนา
พัฒนาโดยทีมงานมืออาชีพขนาดเล็กที่มีการจัดการที่ดี
การบริหารจัดการการพัฒนาระบบ การวางแผนและการควบคุมการปฏิบัติงานที่ชัดเจน
การพัฒนาผลิตภัณฑ์ซอฟต์แวร์รู้วิธีที่คุ้มค่าหลายประการ กล่าวคือ แนวทางปฏิบัติที่ดีที่สุดที่กำหนดไว้ ทางเลือกขึ้นอยู่กับลักษณะเฉพาะของโครงการ ระบบงบประมาณ ความชอบส่วนตัว และแม้กระทั่งอารมณ์ของผู้จัดการ บทความนี้จะอธิบายวิธีการที่เราพบเป็นประจำที่ Edison
1. “น้ำตกจำลอง” (แบบจำลองน้ำตก หรือ “น้ำตก”)
หนึ่งในที่เก่าแก่ที่สุด เกี่ยวข้องกับการผ่านขั้นตอนตามลำดับ ซึ่งแต่ละขั้นตอนจะต้องทำให้เสร็จสมบูรณ์ก่อนที่จะเริ่มครั้งต่อไป โมเดล Waterfall ทำให้การจัดการโปรเจ็กต์เป็นเรื่องง่าย ด้วยความแข็งแกร่ง การพัฒนาจึงดำเนินไปอย่างรวดเร็ว ต้นทุนและกำหนดเวลาจึงถูกกำหนดไว้ล่วงหน้า แต่นี่เป็นดาบสองคม แบบจำลองน้ำตกจะให้ ผลลัพธ์ที่ยอดเยี่ยมเฉพาะในโครงการที่มีข้อกำหนดและวิธีการปฏิบัติที่ชัดเจนและกำหนดไว้ล่วงหน้าเท่านั้น ไม่มีทางที่จะย้อนกลับไปได้ การทดสอบจะเริ่มขึ้นหลังจากการพัฒนาเสร็จสมบูรณ์หรือเกือบจะเสร็จสมบูรณ์แล้วเท่านั้น ผลิตภัณฑ์ที่พัฒนาตามรุ่นนี้โดยไม่มีตัวเลือกที่สมเหตุสมผลอาจมีข้อบกพร่อง (รายการข้อกำหนดไม่สามารถปรับเปลี่ยนได้ตลอดเวลา) ซึ่งเป็นที่รู้จักในตอนท้ายเท่านั้นเนื่องจากลำดับการกระทำที่เข้มงวด ค่าใช้จ่ายในการเปลี่ยนแปลงสูงเนื่องจากต้องรอจนกว่าโครงการทั้งหมดจะเสร็จสมบูรณ์จึงจะเริ่มดำเนินการได้ อย่างไรก็ตาม ต้นทุนคงที่มักจะมีมากกว่าข้อเสียของแนวทางนี้ การแก้ไขข้อบกพร่องที่เกิดขึ้นในระหว่างกระบวนการสร้างนั้นเป็นไปได้ และจากประสบการณ์ของเรา จำเป็นต้องมีข้อตกลงเพิ่มเติมหนึ่งถึงสามข้อตกลงในสัญญาที่มีข้อกำหนดทางเทคนิคเล็กน้อย
โดยใช้ โมเดลน้ำตกเราได้สร้างโครงการตั้งแต่เริ่มต้นมากมายรวมถึงการพัฒนาข้อกำหนดทางเทคนิคเท่านั้น โปรเจ็กต์ที่เขียนเกี่ยวกับHabré: ขนาดกลาง - ไมโครโตโมกราฟีเอ็กซ์เรย์, เล็ก - อัปเดตบริการ Windows อัตโนมัติบน AWS
เมื่อใดจึงควรใช้วิธีน้ำตก
- เฉพาะเมื่อทราบ เข้าใจ และบันทึกข้อกำหนดเท่านั้น ไม่มีข้อกำหนดที่ขัดแย้งกัน
- ไม่มีปัญหากับความพร้อมของโปรแกรมเมอร์ที่มีคุณสมบัติตามที่กำหนด
- ในโครงการที่ค่อนข้างเล็ก
2. “วีโมเดล”
สืบทอดโครงสร้าง “ทีละขั้นตอน” จากโมเดลแบบเรียงซ้อน รุ่นรูปตัว V ใช้ได้กับระบบที่การทำงานอย่างต่อเนื่องมีความสำคัญเป็นพิเศษ ตัวอย่างเช่น การประยุกต์ใช้โปรแกรมในคลินิกเพื่อติดตามผู้ป่วย ซอฟต์แวร์บูรณาการสำหรับกลไกการควบคุมถุงลมนิรภัยฉุกเฉินใน ยานพาหนะและอื่น ๆ คุณสมบัติพิเศษของรุ่นนี้คือมุ่งเป้าไปที่การตรวจสอบและทดสอบผลิตภัณฑ์ที่อยู่ในขั้นตอนเริ่มต้นของการออกแบบอย่างละเอียดแล้ว ขั้นตอนการทดสอบจะดำเนินการพร้อมกันกับขั้นตอนการพัฒนาที่เกี่ยวข้อง เช่น การทดสอบหน่วยจะถูกเขียนระหว่างการเขียนโค้ด
ตัวอย่างงานของเราตามวิธี V - แอพมือถือสำหรับชาวยุโรป ผู้ให้บริการมือถือซึ่งช่วยประหยัดค่าใช้จ่ายในการโรมมิ่งเมื่อเดินทาง โครงการนี้ดำเนินการตามข้อกำหนดที่ชัดเจน แต่จะรวมถึงขั้นตอนการทดสอบที่สำคัญ: ความสะดวกของอินเทอร์เฟซ การทำงาน โหลด และรวมถึงการบูรณาการ ซึ่งควรยืนยันว่าส่วนประกอบต่างๆ มาจาก ผู้ผลิตต่างๆพวกเขาทำงานร่วมกันอย่างมั่นคง การขโมยเงินและเงินกู้เป็นไปไม่ได้
ควรใช้รุ่น V เมื่อใด?
- หากจำเป็นต้องมีการทดสอบผลิตภัณฑ์อย่างละเอียด โมเดล V จะพิสูจน์ความคิดที่มีอยู่: การตรวจสอบความถูกต้องและการทวนสอบ
- สำหรับโครงการขนาดเล็กและขนาดกลางที่มีการกำหนดและแก้ไขข้อกำหนดไว้อย่างชัดเจน
- ในสภาวะความพร้อมของวิศวกรที่มีคุณสมบัติที่จำเป็นโดยเฉพาะผู้ทดสอบ
3. “แบบจำลองส่วนเพิ่ม” (แบบจำลองส่วนเพิ่ม)
ในรูปแบบที่เพิ่มขึ้น ข้อกำหนดครบถ้วนให้กับระบบแบ่งออกเป็นชุดประกอบต่างๆ คำศัพท์นี้มักใช้เพื่ออธิบายการประกอบซอฟต์แวร์ทีละขั้นตอน วงจรการพัฒนาหลายรอบเกิดขึ้นและรวมกันเป็นหนึ่งเดียว วงจรชีวิต"น้ำตกหลายสาย" วงจรนี้แบ่งออกเป็นโมดูลที่เล็กกว่าและสร้างขึ้นได้ง่าย แต่ละโมดูลต้องผ่านขั้นตอนต่างๆ ของการกำหนดข้อกำหนด การออกแบบ การเขียนโค้ด การนำไปใช้ และการทดสอบ กระบวนการพัฒนาส่วนเพิ่มเกี่ยวข้องกับการเปิดตัวในครั้งแรก เวทีใหญ่ผลิตภัณฑ์ในฟังก์ชันพื้นฐาน จากนั้นจึงเพิ่มฟังก์ชันใหม่ตามลำดับ ที่เรียกว่า "ส่วนเพิ่ม" กระบวนการจะดำเนินต่อไปจนกว่าจะสร้างระบบที่สมบูรณ์
แบบจำลองส่วนเพิ่มจะใช้ในกรณีที่คำขอเปลี่ยนแปลงแต่ละรายการมีความชัดเจน และทำให้เป็นทางการและนำไปปฏิบัติได้อย่างง่ายดาย ในโครงการของเรา เราใช้มันเพื่อสร้างโปรแกรมอ่าน DefView จากนั้นจึงสร้างเครือข่าย ห้องสมุดอิเล็กทรอนิกส์วิวัลดี.
เป็นตัวอย่าง เราจะอธิบายสาระสำคัญของการเพิ่มขึ้นทีละครั้ง เครือข่ายห้องสมุดอิเล็กทรอนิกส์ของวิวาลดีเข้ามาแทนที่ DefView DefView เชื่อมต่อกับเซิร์ฟเวอร์เอกสารเดียวและสามารถเชื่อมต่อกับหลายเซิร์ฟเวอร์ได้แล้ว มีการติดตั้งเซิร์ฟเวอร์จัดเก็บข้อมูลที่ไซต์ของสถาบันที่ต้องการเผยแพร่เนื้อหาไปยังผู้ชมเฉพาะกลุ่ม ซึ่งเข้าถึงเอกสารได้โดยตรงและแปลงเป็นรูปแบบที่ต้องการ องค์ประกอบรากของสถาปัตยกรรมได้ปรากฏขึ้น - เซิร์ฟเวอร์กลางวิวาลดีแสดงเป็นโสด เครื่องมือค้นหาข้ามเซิร์ฟเวอร์จัดเก็บข้อมูลทั้งหมดที่ติดตั้งในสถาบันต่างๆ
เมื่อใดจึงจะใช้แบบจำลองส่วนเพิ่ม?
- เมื่อมีการกำหนดและทำความเข้าใจข้อกำหนดพื้นฐานของระบบไว้อย่างชัดเจน ในขณะเดียวกันรายละเอียดบางอย่างอาจได้รับการปรับปรุงเมื่อเวลาผ่านไป
- จำเป็นต้องมีการแนะนำผลิตภัณฑ์ออกสู่ตลาดตั้งแต่เนิ่นๆ
- มีลักษณะหรือเป้าหมายที่มีความเสี่ยงหลายประการ
4. “RAD Model” (โมเดลการพัฒนาแอปพลิเคชันอย่างรวดเร็วหรือการพัฒนาแอปพลิเคชันอย่างรวดเร็ว)
โมเดล RAD เป็นโมเดลส่วนเพิ่มประเภทหนึ่ง ในโมเดล RAD ส่วนประกอบหรือฟังก์ชันต่างๆ ได้รับการพัฒนาโดยทีมงานที่มีทักษะสูงหลายทีมไปพร้อมๆ กัน เช่นเดียวกับมินิโปรเจ็กต์หลายรายการ กรอบเวลาของหนึ่งรอบมีจำกัดอย่างเคร่งครัด โมดูลที่สร้างขึ้นจะถูกรวมเข้าเป็นต้นแบบการทำงานเดียว Synergy ช่วยให้คุณสามารถมอบสิ่งที่ดำเนินการเพื่อตรวจสอบเพื่อรับให้กับลูกค้าได้อย่างรวดเร็ว ข้อเสนอแนะและทำการเปลี่ยนแปลง
รูปแบบการพัฒนาแอปพลิเคชันอย่างรวดเร็วประกอบด้วยขั้นตอนต่อไปนี้:
- การสร้างแบบจำลองธุรกิจ: การกำหนดรายการกระแสข้อมูลระหว่างแผนกต่างๆ
- การสร้างแบบจำลองข้อมูล: ข้อมูลที่รวบรวมในขั้นตอนก่อนหน้าใช้เพื่อกำหนดวัตถุและเอนทิตีอื่น ๆ ที่จำเป็นสำหรับการไหลเวียนของข้อมูล
- การสร้างแบบจำลองกระบวนการ: การไหลของข้อมูลวัตถุลิงก์เพื่อให้บรรลุเป้าหมายการพัฒนา
- สร้างแอปพลิเคชัน: ใช้เครื่องมือประกอบอัตโนมัติเพื่อแปลงโมเดล CAD ให้เป็นโค้ด
- การทดสอบ: มีการทดสอบส่วนประกอบและอินเทอร์เฟซใหม่
สามารถใช้ได้เฉพาะกับสถาปนิกที่มีคุณสมบัติสูงและมีความเชี่ยวชาญสูงเท่านั้น งบประมาณโครงการมีมากพอที่จะจ่ายให้กับผู้เชี่ยวชาญเหล่านี้พร้อมกับค่าใช้จ่าย เครื่องมือสำเร็จรูปการประกอบอัตโนมัติ สามารถเลือกแบบจำลอง RAD ได้ด้วยความรู้ที่มั่นใจ ธุรกิจเป้าหมายและความจำเป็นเร่งด่วนในการผลิตระบบภายใน 2-3 เดือน
5. “Agile Model” (วิธีการพัฒนาแบบยืดหยุ่น)
ในวิธีการพัฒนาแบบ "เปรียว" หลังจากการทำซ้ำแต่ละครั้ง ลูกค้าสามารถสังเกตผลลัพธ์และเข้าใจว่าสิ่งนี้ทำให้เขาพึงพอใจหรือไม่ นี่คือข้อดีประการหนึ่งของโมเดลแบบยืดหยุ่น ข้อเสียรวมถึงข้อเท็จจริงที่ว่าเนื่องจากขาดสูตรเฉพาะของผลลัพธ์ จึงเป็นการยากที่จะประเมินต้นทุนค่าแรงและต้นทุนที่จำเป็นสำหรับการพัฒนา การเขียนโปรแกรมสุดขีด(XP) เป็นหนึ่งในแอปพลิเคชันที่เป็นที่รู้จักมากที่สุดของโมเดล Agile ในทางปฏิบัติ
ประเภทนี้อิงตามการประชุมรายวันระยะสั้น - "การต่อสู้" และการประชุมที่เกิดซ้ำเป็นประจำ (สัปดาห์ละครั้ง ทุกสองสัปดาห์หรือเดือนละครั้ง) เรียกว่า "Sprint" ในการประชุมรายวัน สมาชิกในทีมจะหารือเกี่ยวกับ:
- รายงานงานที่ทำตั้งแต่ Scrum ครั้งล่าสุด
- รายการงานที่พนักงานต้องทำก่อนการประชุมครั้งถัดไป
- ความยากลำบากที่พบในระหว่างการทำงาน
เมื่อใดจึงควรใช้ Agile?
- เมื่อความต้องการของผู้ใช้เปลี่ยนแปลงตลอดเวลาในธุรกิจที่มีการเปลี่ยนแปลงตลอดเวลา
- การเปลี่ยนแปลงแบบ Agile จะดำเนินการด้วยต้นทุนที่ต่ำกว่าเนื่องจากการเพิ่มขึ้นบ่อยครั้ง
- ต่างจากโมเดล Waterfall ตรงที่โมเดล Agile ต้องการการวางแผนเพียงเล็กน้อยในการเริ่มโปรเจ็กต์
6. “แบบจำลองวนซ้ำ” (แบบจำลองวนซ้ำหรือวนซ้ำ)
แบบจำลองวงจรชีวิตซ้ำไม่จำเป็นต้องมีข้อกำหนดข้อกำหนดที่สมบูรณ์ตั้งแต่แรก แต่การสร้างจะเริ่มต้นด้วยการนำฟังก์ชันการทำงานไปใช้ ซึ่งกลายเป็นพื้นฐานสำหรับการกำหนดข้อกำหนดเพิ่มเติม กระบวนการนี้ซ้ำแล้วซ้ำอีก เวอร์ชันอาจไม่สมบูรณ์แบบ สิ่งสำคัญคือใช้งานได้ ด้วยการทำความเข้าใจเป้าหมายสุดท้าย เราจึงมุ่งมั่นเพื่อให้ทุกขั้นตอนมีประสิทธิภาพ และทุกเวอร์ชันสามารถใช้งานได้
แผนภาพแสดง "พัฒนาการ" ซ้ำๆ ของโมนาลิซา อย่างที่คุณเห็น ในการวนซ้ำครั้งแรกมีเพียงภาพร่างของโมนาลิซ่า ในวินาทีที่สีปรากฏขึ้น และการวนซ้ำครั้งที่สามจะเพิ่มรายละเอียด ความอิ่มตัว และทำให้กระบวนการเสร็จสมบูรณ์ ในแบบจำลองส่วนเพิ่ม การทำงานของผลิตภัณฑ์จะถูกสร้างขึ้นทีละชิ้น ผลิตภัณฑ์จะประกอบด้วยชิ้นส่วนต่างๆ ต่างจากแบบจำลองวนซ้ำ แต่ละชิ้นแสดงถึงองค์ประกอบที่สมบูรณ์
ตัวอย่างของการพัฒนาซ้ำคือการจดจำเสียง การวิจัยและการเตรียมอุปกรณ์ทางวิทยาศาสตร์ครั้งแรกเริ่มขึ้นเมื่อนานมาแล้ว ครั้งแรกในความคิด จากนั้นบนกระดาษ ด้วยการทำซ้ำใหม่แต่ละครั้ง คุณภาพการจดจำก็ดีขึ้น อย่างไรก็ตาม ยังไม่ได้รับการรับรู้ที่สมบูรณ์แบบ ดังนั้น ปัญหาจึงยังไม่ได้รับการแก้ไขอย่างสมบูรณ์
เมื่อใดจึงเหมาะสมที่สุดที่จะใช้แบบจำลองวนซ้ำ?
- ข้อกำหนดในการ ระบบสุดท้ายกำหนดไว้ชัดเจนและเข้าใจล่วงหน้า
- โครงการมีขนาดใหญ่หรือใหญ่มาก
- จะต้องกำหนดวัตถุประสงค์หลัก แต่รายละเอียดการดำเนินการอาจมีการพัฒนาเมื่อเวลาผ่านไป
7. “โมเดลเกลียว” (โมเดลเกลียว)
“แบบจำลองเกลียว” นั้นคล้ายคลึงกับแบบจำลองส่วนเพิ่ม แต่เน้นที่การวิเคราะห์ความเสี่ยง ทำงานได้ดีในการแก้ปัญหาทางธุรกิจที่สำคัญ เมื่อความล้มเหลวไม่สอดคล้องกับกิจกรรมของบริษัท ในบริบทของการเปิดตัวผลิตภัณฑ์ใหม่ สายผลิตภัณฑ์, ในกรณีที่จำเป็น การวิจัยทางวิทยาศาสตร์และการทดสอบภาคปฏิบัติ
โมเดลเกลียวประกอบด้วย 4 ขั้นตอนในแต่ละเทิร์น:
- การวางแผน;
- การวิเคราะห์ความเสี่ยง;
- ออกแบบ;
- การประเมินผลลัพธ์ และหากคุณภาพเป็นที่น่าพอใจ ให้เปลี่ยนไปสู่ขั้นตอนใหม่
มาสรุปกัน
สไลด์นี้แสดงให้เห็นถึงความแตกต่างระหว่างวิธีการทั่วไปสองวิธี
ใน การปฏิบัติที่ทันสมัยรูปแบบการพัฒนา ซอฟต์แวร์หลายตัวแปร ไม่มีรูปแบบที่เหมาะสมสำหรับทุกโครงการ เงื่อนไขการเริ่มต้น และรูปแบบการชำระเงิน แม้แต่ Agile ซึ่งเป็นที่รักของพวกเราทุกคนก็ไม่สามารถนำไปใช้กับทุกที่ได้เนื่องจากลูกค้าบางรายไม่ได้เตรียมตัวไว้หรือไม่สามารถยืดหยุ่นทางการเงินได้ วิธีการบางส่วนทับซ้อนกันในวิธีการและบางส่วนคล้ายคลึงกัน แนวคิดอื่นๆ บางส่วนใช้เพื่อโปรโมตคอมไพเลอร์ของตนเองเท่านั้น และไม่ได้นำสิ่งใหม่มาสู่การปฏิบัติ
เกี่ยวกับเทคโนโลยีการพัฒนา:
อีกครั้งเกี่ยวกับวิธีการพัฒนาหลักเจ็ดประการ
ข้อผิดพลาดหลัก 10 ประการในระบบการปรับขนาด
หลักการวางแผนพัฒนา 8 ประการที่ทำให้ชีวิตง่ายขึ้น
ความเสี่ยงหลัก 5 ประการในการพัฒนาซอฟต์แวร์แบบกำหนดเอง
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมการสำรวจได้ , โปรด.
หนึ่งในแนวทางในการพัฒนาซอฟต์แวร์ภายในกรอบของแบบจำลองวงจรชีวิตแบบเกลียวคือวิธีการ (เทคโนโลยี) ที่ใช้กันอย่างแพร่หลายสำหรับการพัฒนาแอปพลิเคชันอย่างรวดเร็ว RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว) โมเดลนี้เหมาะมากกับการพัฒนาหลักสูตรเพราะว่า ประกอบด้วยสามองค์ประกอบ:
Ø ทีมโปรแกรมเมอร์กลุ่มเล็ก (ตั้งแต่ 2 ถึง 10 คน)
Øกำหนดการผลิตสั้น ๆ แต่จัดทำอย่างรอบคอบ (ตั้งแต่ 2 ถึง 6 เดือน)
Ø วงจรวนซ้ำซึ่งนักพัฒนาเมื่อแอปพลิเคชันเริ่มเป็นรูปเป็นร่าง ร้องขอ และนำไปใช้กับผลิตภัณฑ์ตามข้อกำหนดที่ได้รับผ่านการโต้ตอบกับลูกค้า
ลองพิจารณาดู รุ่นนี้ในรายละเอียด ทีมพัฒนาควรเป็นกลุ่มผู้เชี่ยวชาญที่มีประสบการณ์ในด้านการวิเคราะห์ การออกแบบ การสร้างโค้ด และการทดสอบซอฟต์แวร์โดยใช้เครื่องมือของ CASE สามารถโต้ตอบกับผู้ใช้ได้ดี และเปลี่ยนคำแนะนำให้เป็นต้นแบบที่ใช้งานได้ วงจรชีวิตของซอฟต์แวร์ตามวิธี RAD ประกอบด้วย สี่เฟส(ภาพที่ 21):
1. การวิเคราะห์และการวางแผนข้อกำหนด
2. การออกแบบ;
3. การก่อสร้าง;
4. การนำไปปฏิบัติ
บน ระยะแรก การวิเคราะห์และการวางแผนความต้องการผู้ใช้ระบบจะกำหนดฟังก์ชันที่ควรดำเนินการ เน้นลำดับความสำคัญสูงสุดที่ต้องอธิบายรายละเอียดก่อน และอธิบายความต้องการข้อมูล (การเชื่อมต่อ) การกำหนดความต้องการของระบบส่วนใหญ่ดำเนินการโดยผู้ใช้ภายใต้คำแนะนำของนักพัฒนาผู้เชี่ยวชาญ ขอบเขตของโครงการมีจำกัด และมีการกำหนดกรอบเวลาสำหรับแต่ละระยะต่อๆ ไป นอกจากนี้ความเป็นไปได้ในการดำเนินโครงการอีกด้วย ขนาดที่กำหนดการจัดหาเงินทุนบนฮาร์ดแวร์ที่มีอยู่ ฯลฯ
ผลลัพธ์ของเฟสควรเป็น:รายการฟังก์ชันที่จัดลำดับความสำคัญของ PS ในอนาคต รูปแบบการทำงานเบื้องต้นของ PS รูปแบบข้อมูลเบื้องต้นของ PS
บน ระยะที่สอง ออกแบบ ผู้ใช้บางรายมีส่วนร่วม การออกแบบทางเทคนิคระบบภายใต้การแนะนำของนักพัฒนาผู้เชี่ยวชาญ และโต้ตอบกับพวกเขา ชี้แจงและเสริมข้อกำหนดของระบบที่ไม่ได้ระบุไว้ในระยะก่อนหน้านี้ พูดคุยในรายละเอียดเพิ่มเติม กระบวนการของระบบ- หากจำเป็น มีการปรับเปลี่ยนโมเดลการทำงาน สร้างต้นแบบบางส่วน: หน้าจอ รายงาน ขจัดความคลุมเครือหรือความคลุมเครือ ข้อกำหนดได้รับการจัดตั้งขึ้น ข้อ จำกัด การเข้าถึงข้อมูล- ในขั้นตอนเดียวกันจะมีการกำหนดเอกสารที่จำเป็น หลังจากการกำหนดองค์ประกอบของกระบวนการอย่างละเอียดแล้ว จะมีการประเมินจำนวนองค์ประกอบการทำงานของระบบที่กำลังพัฒนาและตัดสินใจแบ่งระบบออกเป็นระบบย่อย
ผลลัพธ์ของระยะนี้ควรเป็น:รูปแบบข้อมูลทั่วไปของระบบ แบบจำลองการทำงานของระบบโดยรวมและระบบย่อย อินเทอร์เฟซที่กำหนดไว้อย่างแม่นยำระหว่างระบบย่อยที่พัฒนาขึ้นโดยอัตโนมัติ สร้างต้นแบบของหน้าจอ รายงาน กล่องโต้ตอบ
แตกต่างจากวิธีการแบบดั้งเดิมซึ่งใช้เครื่องมือสร้างต้นแบบเฉพาะที่ไม่ได้ออกแบบมาสำหรับการสร้างแอปพลิเคชันในโลกแห่งความเป็นจริง และทิ้งต้นแบบหลังจากที่ได้ทำหน้าที่เพื่อล้างความคลุมเครือของการออกแบบแล้ว ในแนวทางของ RAD แต่ละต้นแบบได้รับการพัฒนาให้เป็นส่วนหนึ่งของระบบแห่งอนาคต- ดังนั้นข้อมูลที่ครบถ้วนและเป็นประโยชน์จึงถูกถ่ายโอนไปยังขั้นตอนต่อไป
บน ระยะที่สาม การก่อสร้าง การพัฒนาแอปพลิเคชั่นอย่างรวดเร็ว (การนำระบบย่อยไปใช้) นั้นดำเนินการโดยตรง ในขั้นตอนนี้ นักพัฒนาจะสร้างระบบจริงซ้ำๆ ตามแบบจำลองที่ได้รับในขั้นตอนก่อนหน้า รวมถึงข้อกำหนดที่ไม่สามารถใช้งานได้ ในขั้นตอนนี้ ผู้ใช้จะประเมินผลลัพธ์ที่ได้รับและทำการปรับเปลี่ยนหากระบบไม่ตรงตามข้อกำหนดที่กำหนดไว้ก่อนหน้านี้อีกต่อไปในระหว่างกระบวนการพัฒนา การทดสอบระบบจะดำเนินการในระหว่างกระบวนการพัฒนา
หลังจากการพัฒนาระบบย่อยเสร็จสิ้น ส่วนนี้ของระบบจะค่อยๆ รวมเข้ากับส่วนที่เหลือ รหัสโปรแกรมที่สมบูรณ์จะถูกสร้างขึ้น และระบบโดยรวมได้รับการทดสอบ การออกแบบทางกายภาพของระบบเสร็จสมบูรณ์: กำหนดความจำเป็นในการกระจายข้อมูล มีการวิเคราะห์การใช้ข้อมูล มีการออกแบบทางกายภาพของฐานข้อมูล กำหนดข้อกำหนดสำหรับทรัพยากรฮาร์ดแวร์ มีการกำหนดวิธีเพิ่มผลผลิต การพัฒนาเอกสารโครงการเสร็จสิ้นแล้ว
ผลลัพธ์ของเฟสเป็น ระบบพร้อมเป็นไปตามข้อกำหนดที่ตกลงกันไว้ทั้งหมด
บน ระยะที่สี่ การดำเนินการ การฝึกอบรมผู้ใช้ การเปลี่ยนแปลงองค์กรจะดำเนินการ และควบคู่ไปกับการนำระบบใหม่ไปใช้ งานจะดำเนินการด้วย ระบบที่มีอยู่(จนกว่าจะมีการดำเนินการใหม่อย่างสมบูรณ์) เนื่องจากขั้นตอนการก่อสร้างค่อนข้างสั้น การวางแผนและการเตรียมการสำหรับการดำเนินการจึงต้องเริ่มต้นตั้งแต่เนิ่นๆ ซึ่งโดยปกติจะอยู่ระหว่างขั้นตอนการออกแบบระบบ
เทคโนโลยี RAD (เช่นเดียวกับเทคโนโลยีอื่นๆ) ไม่สามารถอ้างได้ว่าเป็นเทคโนโลยีสากล แต่โดยหลักแล้วจะดีสำหรับโครงการขนาดเล็กที่พัฒนาขึ้นสำหรับลูกค้าเฉพาะราย มันใช้ไม่ได้กับการพัฒนา ระบบปฏิบัติการ- โปรแกรมการคำนวณที่ซับซ้อนซึ่งมีโค้ดโปรแกรมจำนวนมากและอัลกอริธึมการควบคุมเฉพาะที่ซับซ้อน แอปพลิเคชันที่ไม่มีส่วนอินเทอร์เฟซที่กำหนดไว้อย่างชัดเจนซึ่งกำหนดตรรกะของระบบอย่างชัดเจน (แอปพลิเคชันแบบเรียลไทม์) เนื่องจากวิธีการวนซ้ำถือว่าสองสามเวอร์ชันแรกจะไม่ตรงตามข้อกำหนดอย่างสมบูรณ์
โดยสรุปเราแสดงรายการ หลักการพื้นฐานของเทคโนโลยี RAD:
Ø การพัฒนาแอปพลิเคชันในการวนซ้ำ
Ø การทำงานเสริมให้เสร็จสิ้นในแต่ละขั้นตอนของวงจรชีวิต
Ø การมีส่วนร่วมของผู้ใช้ในขั้นตอนการพัฒนา
Ø การใช้ต้นแบบเพื่อชี้แจงและตอบสนองทุกความต้องการ ผู้ใช้;
Ø การทดสอบและพัฒนาโครงการไปพร้อมกับการพัฒนา
Ø การจัดการการพัฒนาที่มีความสามารถ การวางแผนที่ชัดเจน และการควบคุมการปฏิบัติงาน
คำถามควบคุมถึงบทที่ 3:
1. การกำหนดมาตรฐานและการรับรองผลิตภัณฑ์ซอฟต์แวร์คืออะไร?
2. มีมาตรฐานประเภทใดบ้าง?
3. แสดงรายการมาตรฐานวงจรชีวิตที่มีชื่อเสียงที่สุดที่ใช้ในการพัฒนาซอฟต์แวร์?
4. วงจรชีวิตของซอฟต์แวร์คืออะไร?
5. แสดงรายการขั้นตอนหลักของวงจรชีวิตซอฟต์แวร์ กระบวนการ การกระทำ งาน คืออะไร?
6. คุณจำกระบวนการและกระบวนการเฉพาะประเภทใดได้บ้าง?
7. อธิบายกระบวนการทางวิศวกรรมพื้นฐานของวงจรชีวิตของซอฟต์แวร์
8. โมเดลวงจรชีวิตของซอฟต์แวร์คืออะไร? ให้คำจำกัดความแนวคิดพื้นฐานที่เกี่ยวข้องกับแนวคิด “แบบจำลอง”
9. คุณรู้จักรุ่นประเภทใดบ้าง? ข้อดีข้อเสียขอบเขตของการบังคับใช้คืออะไร?
10.คุณสามารถพูดอะไรเกี่ยวกับคุณลักษณะของแบบจำลองวงจรชีวิตของน้ำตกได้บ้าง?
11. อะไรคือความแตกต่างระหว่างโมเดลคาสเคดทั่วไปและโมเดลพื้นฐาน?
12. คุณจะพูดอะไรเกี่ยวกับคุณลักษณะของแบบจำลองวงจรชีวิตแบบก้นหอย?
13.ทำรายการส่วนประกอบของเทคโนโลยี RAD เทคโนโลยี RAD สามารถใช้ซอฟต์แวร์ประเภทใดในการพัฒนาได้
14.อธิบายขั้นตอนหลักของวงจรชีวิตของเทคโนโลยี RAD
15.ระบุหลักการพื้นฐานของเทคโนโลยี RAD
บรรณานุกรม
1. Aptekar M.D., Ramazanov S.K., Freger G.E. ประวัติกิจกรรมทางวิศวกรรม – เคียฟ, 2003. – 204 น. : ป่วย.
2. Archibald R. แบบจำลองวงจรชีวิตของโครงการที่มีเทคโนโลยีสูง http://www.pmprofy.ru/content/rus/107/1073-article.html
3. Brooks F. มนุษย์เดือนในตำนานหรือวิธีการสร้างมันขึ้นมา ระบบซอฟต์แวร์- - เซนต์ปีเตอร์สเบิร์ก. : Symbol-plus, 1999. – 321 น. : ป่วย.
4. Butch G. การออกแบบเชิงวัตถุพร้อมตัวอย่างการใช้งาน – อ.: คองคอร์ด, 1992. – 586 หน้า : ป่วย.
5. Butch G. การวิเคราะห์เชิงวัตถุและการออกแบบเชิงวัตถุใน C ++ – อ.: บินอม, – 2001. – 558 หน้า : ป่วย.
6. เทคโนโลยี Vendrov A. M. CASE วิธีการที่ทันสมัยและเครื่องมือออกแบบระบบสารสนเทศ – อ.: การเงินและสถิติ, – 1999. – 256 น. : ป่วย.
7. Wirth N. Algorithms + โครงสร้างข้อมูล = โปรแกรม: Transl. จากอังกฤษ – อ.: มีร์, 1985. – 406 หน้า: ป่วย.
8. Dahl O., Dijkstra E., Hoor K. การเขียนโปรแกรมแบบมีโครงสร้าง: การแปล จากอังกฤษ – อ.: มีร์, 1975. – 247 หน้า. : ป่วย.
9. Dzerzhinsky F.Ya., Kalinichenko I.M. สาขาวิชาการเขียนโปรแกรม: แนวคิดและประสบการณ์ในการใช้เครื่องมือระเบียบวิธีของวิศวกรรมซอฟต์แวร์ – อ.: สถาบันวิจัยสารสนเทศและการวิจัยทางเทคนิคและเศรษฐกิจกลางในด้านวิทยาศาสตร์และเทคโนโลยีนิวเคลียร์, 2531 – 245 หน้า : ป่วย.
10. เทคโนโลยีการเขียนโปรแกรม Zhogolev E. A. – อ.: โลกวิทยาศาสตร์, 2547. – 216 น. : ป่วย.
11. กฎหมายของสหพันธรัฐรัสเซียหมายเลข 149-FZ ลงวันที่ 29 กรกฎาคม 2549 “เกี่ยวกับข้อมูล เทคโนโลยีสารสนเทศและการปกป้องข้อมูล”// Rossiyskaya Gazeta, ฉบับที่ 165, วันที่ 27 กรกฎาคม 2549
12. เทคโนโลยีการเขียนโปรแกรม Ivanova G. S.: หนังสือเรียนสำหรับมหาวิทยาลัย – ฉบับพิมพ์ครั้งที่ 2 แบบเหมารวม. – อ.: สำนักพิมพ์ของ MSTU im. น.อี. บาวแมน, 2546. – 320 หน้า: ป่วย
13. Kalyanov G. N. CASE: การวิเคราะห์ระบบโครงสร้าง (อัตโนมัติและการใช้งาน) – อ.: “ลอริ”, 1996. – 356 หน้า. : ป่วย.
14. Korablin M. A. การเขียนโปรแกรมเชิงวัตถุ: หนังสือเรียน. – Samara: สำนักพิมพ์ SSAU, 1994. – 94 น.
15. Leonenkov A.V. คู่มือการใช้งาน UML – เซนต์ปีเตอร์สเบิร์ก: VHV เซนต์ปีเตอร์สเบิร์ก – 2001 – 304 หน้า : ป่วย.
16. คุณภาพของซอฟต์แวร์ Lipaev V.V. – อ.: การเงินและสถิติ, 2526. – 263 น. : ป่วย.
17. การดีบัก Lipaev V.V โปรแกรมที่ซับซ้อน: วิธีการ วิธีการ เทคโนโลยี –ม. : Energoatomizdat, 1993. – 384 หน้า : ป่วย.
18. Lipaev V.V., Filippov E.N. การเคลื่อนย้ายโปรแกรมและข้อมูลแบบเปิด ระบบข้อมูล- – อ.: หนังสือวิทยาศาสตร์, 2540 – 297 หน้า : ป่วย.
20. Ozhegov S.I. พจนานุกรมภาษารัสเซีย – อ.: สันติภาพและการศึกษา, 2549 – 1328 หน้า
21. เทคโนโลยีสำหรับการออกแบบโปรแกรมคอมเพล็กซ์ระบบควบคุมอัตโนมัติ / V. V. Lipaev, L. A. Serebrovsky, P. G. Gaganov ฯลฯ ; เอ็ด Yu. V. Afanasyeva, V. V. Lipaeva – อ.: วิทยุและการสื่อสาร, 2526. – 256 น. : ป่วย.
22. Hyvenen E., Seppanen J. โลกแห่ง LISP: การแปล จากภาษาฟินแลนด์ ใน 2 เล่ม T.1: ความรู้เบื้องต้นเกี่ยวกับภาษาเสียงกระเพื่อมและ การเขียนโปรแกรมเชิงฟังก์ชัน.– อ.: มีร์ 1990. – 447 หน้า : ป่วย.
23. Hyvenen E., Seppanen J. โลกแห่ง LISP: การแปล จากภาษาฟินแลนด์ ใน 2 เล่ม ต.2: วิธีการและระบบการเขียนโปรแกรม – M.: Mir, 1990. – 319 น. : ป่วย.
24. Boehm B. “A Spiral Model of Software Development and Enhancement,” IEEE Computer, ฉบับที่ 21, เลขที่. 5, หน้า. 61–72, 1988.
25. Courtois P. มิถุนายน 1985 การสลายตัวตามเวลาและพื้นที่ของโครงสร้างที่ซับซ้อน การสื่อสารของ ACM เล่ม 28(6), หน้า 596
26. เกณฑ์การประเมินซอฟต์แวร์ ISO TC97/SC7 #383
27. Dijktra E. 1979. การเขียนโปรแกรมถือเป็นกิจกรรมของมนุษย์ คลาสสิกในวิศวกรรมซอฟต์แวร์ นิวยอร์ก รัฐนิวยอร์ก: Yourdon Press
28. http://www.pmi.ru/glossary/
29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm
30. ไมโครซอฟต์ คอร์ปอเรชั่น. หลักการออกแบบและพัฒนาซอฟต์แวร์ หลักสูตรการฝึกอบรม MCSD: การแปล จากอังกฤษ – อ.: สำนักพิมพ์และซื้อขายบ้าน “ฉบับรัสเซีย”, 2543. –608 หน้า : ป่วย.
31. Parnas D., Clements P., Weiss D. 1983. การปรับปรุงการใช้ซ้ำด้วยการซ่อนข้อมูล การประชุมเชิงปฏิบัติการเรื่องการใช้ซ้ำในการเขียนโปรแกรม สแตรตฟอร์ด, CT: การเขียนโปรแกรม ITT หน้า 241
32. Rechtin E. ตุลาคม 1992 ศิลปะแห่งสถาปัตยกรรมระบบ สเปกตรัม IEEE, เล่ม 29(10), หน้า 66
33. รอยซ์ ดับเบิลยู.ดับเบิลยู. การจัดการการพัฒนาระบบซอฟต์แวร์ขนาดใหญ่ http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.
34. Shaw M. ตุลาคม 1984 เทคนิคนามธรรมในภาษาโปรแกรมสมัยใหม่ ซอฟต์แวร์ IEEE เล่ม 1 (4)
35. Simon H. 1982. วิทยาศาสตร์แห่งการประดิษฐ์. เคมบริดจ์ แมสซาชูเซตส์: สำนักพิมพ์ MIT – หน้า 218.
36. Sommerville I. วิศวกรรมซอฟต์แวร์. – บริษัทสำนักพิมพ์แอดดิสัน-เวสลีย์, 1992. หน้า 87.
37. Tesler L. สิงหาคม 1981 สภาพแวดล้อม Smalltalk ไบต์ เล่ม 6(8), หน้า 142
38. Yonezawa A., Tokoro M. 1987. การเขียนโปรแกรมพร้อมกันเชิงวัตถุ เคมบริดจ์ แมสซาชูเซตส์: สำนักพิมพ์ MIT
รายการข้อกำหนด
การเลือกวิธีการพัฒนาแอปพลิเคชันจะกลายเป็นภารกิจที่ 1 ตามเงื่อนไข การเติบโตอย่างรวดเร็วตลาด. จากการศึกษาพบว่า มีการใช้จ่ายเงิน 310 พันล้านดอลลาร์สหรัฐในซอฟต์แวร์ระดับองค์กรทั่วโลกในปี 2558 การพัฒนาแนวคิดRAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว)กลายเป็นพื้นฐานในการสร้างความคล่องตัว ระบบการปรับตัวการพัฒนาแอปพลิเคชันซึ่งจะเป็นการถ่วงดุลกับโมเดล "น้ำตก" ที่เข้มงวด
RAD เป็นรูปแบบการพัฒนาแอปพลิเคชันที่รวดเร็วซึ่งมุ่งเน้นไปที่ความเร็วและความง่ายในการเขียนโปรแกรม
การเกิดขึ้นของ RAD
เราขอขอบคุณความไม่สมบูรณ์แบบของโมเดลตระกูลสำหรับการพัฒนาแอปพลิเคชันที่รวดเร็ว น้ำตกเมื่อสร้างซอฟต์แวร์ ประเด็นก็คือว่าในตอนแรกระบบการพัฒนาน้ำตกนั้นใช้แบบจำลองทางวิศวกรรมแบบดั้งเดิมที่ใช้ สำหรับงานออกแบบและก่อสร้างอาคารและสะพาน
แม้ว่า Waterfall จะขึ้นอยู่กับโครงสร้างที่เข้มงวดของกิจกรรมการพัฒนาตามลำดับ การเกิดขึ้นของ RAD คือความพยายามที่จะสร้างกระบวนการที่ยืดหยุ่นซึ่งสามารถใช้ความรู้ที่ได้รับในระหว่างวงจรชีวิตของโครงการ
RAD เวอร์ชันแรกถูกสร้างขึ้นโดย Barry Boehm ในปี 1986 ซึ่งเรียกมันว่า "แบบจำลองเกลียว"การหมุนวนแต่ละครั้งจะแบ่งออกเป็น 4 ส่วนและสอดคล้องกับการพัฒนาชิ้นส่วนหรือเวอร์ชันซอฟต์แวร์ ในแต่ละรอบใหม่ จะมีการชี้แจงเป้าหมายและข้อกำหนดเฉพาะของโครงการให้ชัดเจนยิ่งขึ้น เป็นผลให้สามารถเลือกตัวเลือกที่มีข้อมูลได้
โดยใช้แนวคิดของแบร์รี่ Briton James Martin พัฒนาระบบ RAD ของเขาขณะที่ทำงานที่ IBM ในช่วงทศวรรษ 1980 และในที่สุดก็ได้กำหนดเป็น "Rapid Application Development" ในปี 1991
จริงอยู่ มีความสับสนเกี่ยวกับความหมายของคำว่า "RAD" แม้แต่ในหมู่ผู้เชี่ยวชาญด้านไอทีก็ตาม ท้ายที่สุดแล้ว เรากำลังพูดถึงสองแนวคิด: RAD เป็นทางเลือกที่มีประสิทธิภาพแทนน้ำตกและ RAD เป็นวิธีการเฉพาะที่พัฒนาโดย Martinส่วนหลังได้รับการปรับให้เข้ากับระบบธุรกิจที่ใช้ UI มาก
ต่อมาได้มีการพัฒนาและปรับปรุงแนวคิดต่างๆ ผู้บุกเบิก RAD James Kerr และ Richard Hunterในการทำงานร่วมกัน “Inside RAD” ซึ่งบันทึกการเดินทางของผู้จัดการโครงการในขณะที่เขาเรียนรู้และใช้วิธีการพัฒนาแอปพลิเคชันอย่างรวดเร็วในชีวิตจริงสำหรับโครงการจริง
แบบจำลองเกลียวเป็นกระบวนการพัฒนาซอฟต์แวร์ที่ผสมผสานการออกแบบและการสร้างต้นแบบทีละขั้นตอน
พื้นฐาน (หลักการ) ของการพัฒนาแอปพลิเคชันอย่างรวดเร็ว
หลักการของ RAD มุ่งเน้นไปที่การมอบประโยชน์หลักของการพัฒนาแอปพลิเคชันอย่างรวดเร็ว:
- เพิ่มความเร็วในการพัฒนา
- ราคาถูก
- คุณภาพสูง.
กับ จุดสุดท้ายปัญหาส่วนใหญ่เกิดขึ้นเพราะนักพัฒนาและลูกค้ามองเรื่องการพัฒนาต่างกัน
เพื่อขจัดปัญหานี้และปัญหาอื่นๆ เจมส์ มาร์ตินและผู้ติดตามของเขาได้ระบุหลักการของ RAD ต่อไปนี้:
- ลดค่าใช้จ่ายด้านเวลา— ชุดเครื่องมือควรมุ่งเป้าไปที่การลดเวลาในการพัฒนา
- การสร้างต้นแบบ— การสร้างต้นแบบเพื่อระบุความต้องการของลูกค้า
- การพัฒนาแบบวัฏจักร— ผลิตภัณฑ์ใหม่แต่ละเวอร์ชันขึ้นอยู่กับการประเมินผลงาน รุ่นก่อนหน้าลูกค้า
- ความร่วมมือ— ทีมพัฒนาต้องมีปฏิสัมพันธ์อย่างใกล้ชิด สมาชิกแต่ละคนต้องพร้อมที่จะรับผิดชอบหลายอย่าง
- วิธีการทำซ้ำเพื่อการพัฒนา
- การผสมผสานการทดสอบและพัฒนาระบบ
หลักการของ RAD ไม่เพียงแต่ใช้ในระหว่างการนำไปปฏิบัติเท่านั้น แต่ยังขยายไปถึงทุกขั้นตอนของวงจรชีวิต โดยเฉพาะอย่างยิ่ง ไปจนถึงขั้นตอนการสำรวจองค์กร การสร้างความต้องการ การวิเคราะห์ และการออกแบบ
วงจรชีวิตของซอฟต์แวร์ตาม RAD
ในระหว่างกระบวนการ RAD การสมัครจะผ่านสี่ขั้นตอน
ขั้นตอนการวิเคราะห์และวางแผนความต้องการ
มีการกำหนดข้อกำหนด ฟังก์ชันแอปพลิเคชัน และลำดับความสำคัญ โดยอธิบายความต้องการข้อมูล ขั้นตอนนี้ดำเนินการโดยผู้ใช้โดยมีส่วนร่วมของนักพัฒนาเป็นหลัก ในขั้นตอนนี้ ขนาดของโครงการ เวลาและกรอบทางการเงิน และแพลตฟอร์มสำหรับการเปิดตัวซอฟต์แวร์ก็จะถูกระบุด้วย
บริษัท Beverly Flowers ต้องการแอปพลิเคชันสำหรับสั่งดอกไม้ออนไลน์ถึงบ้านของคุณ ระยะเวลาในการสร้างคือ 50 วัน งบประมาณอยู่ที่ 3,000 ดอลลาร์ขั้นตอนการออกแบบ
ผู้ใช้บางรายมีส่วนร่วมในการออกแบบทางเทคนิคของระบบภายใต้คำแนะนำของนักพัฒนา กลุ่ม RAD หรือกลุ่มย่อยในระยะนี้โดยทั่วไปจะใช้เทคนิคผสมผสานกันกับ การพัฒนาแอปพลิเคชันร่วมกัน (JAD) และ เครื่องมือกรณี เพื่อแปลความต้องการของผู้ใช้ให้เป็นโมเดลการทำงาน
JAD (การพัฒนาแอปพลิเคชันร่วม) เป็นแนวคิดของการพัฒนาแอปพลิเคชันร่วมกัน โดยมีปฏิสัมพันธ์อย่างใกล้ชิดระหว่างลูกค้าและผู้ปฏิบัติงานให้เกิดประโยชน์สูงสุด โซลูชั่นที่มีประสิทธิภาพปัญหาที่เกี่ยวข้องกับซอฟต์แวร์ที่กำลังพัฒนา
Case คือชุดเครื่องมือและวิธีการในการออกแบบซอฟต์แวร์เพื่อให้แน่ใจว่าผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพสูง ปราศจากข้อผิดพลาด และบำรุงรักษาง่าย
ในระหว่างขั้นตอนการออกแบบ ผู้ใช้สามารถเข้าใจ ปรับเปลี่ยน และกำหนดรูปแบบการทำงานของระบบที่เหมาะสมกับความต้องการของตนได้ แต่ละกระบวนการได้รับการพิจารณาอย่างละเอียดและสร้างขึ้นหากจำเป็นต้นแบบบางส่วน .
เป็นผลให้มีการสร้างเฟส:
- รูปแบบข้อมูลทั่วไปของแอปพลิเคชัน
- โมเดลการทำงานของระบบและระบบย่อย
- ต้นแบบการทำงานของหน้าจอ รายงาน และกล่องโต้ตอบ
หากเครื่องมือพัฒนาต้นแบบไม่เพียงพอในรุ่นก่อนๆ การใช้งานจริงและพวกเขาก็ไม่ได้ใช้อีกต่อไปแล้ว ที่ RAD แต่ละต้นแบบจะกลายเป็นส่วนหนึ่งของระบบในอนาคต
ดังนั้นในแอปพลิเคชัน Beverly Flowers ผู้ใช้ควรสามารถเข้าถึงตัวเลือกต่อไปนี้: “หน้าแรก”, “ค้นหาดอกไม้”, “ดูรายการดอกไม้”
ฟรีแวร์ SpringToolSuite ได้รับเลือกให้เป็นแพลตฟอร์มการพัฒนาซึ่งมีตัวอย่างจำนวนมากให้เลือกใช้ - เป็นโค้ดที่เป็นลายลักษณ์อักษร
ในฐานะเซิร์ฟเวอร์ - อาปาเช่ ทอมแคท 6.0.
ขั้นตอนการก่อสร้าง
ในขั้นตอนนี้ การพัฒนาอย่างรวดเร็วในทันทีจะเกิดขึ้นตามผลลัพธ์ที่ได้รับในระยะก่อนหน้า โดยที่ผู้ใช้ยังคงมีส่วนร่วมต่อไป ในการพัฒนาระบบ เสนอแนะ การเปลี่ยนแปลงและปรับปรุงแอพพลิเคชั่น การทดสอบแอปพลิเคชันเกิดขึ้นในระหว่างการพัฒนาด้วย
แอปพลิเคชั่น "Beverly Flowers" ประกอบขึ้นจากองค์ประกอบการทำงานสามประการ - การเปลี่ยนไปใช้ผู้ใช้ " หน้าแรก", "เรียกดูสี" และ "ดูรายการสี"
เพื่อการพัฒนา รูปแบบการทำงานใช้เวลาผู้เชี่ยวชาญ 1 คนและ 8 วัน
ระยะการดำเนินการ
ครอบคลุมการฝึกอบรมผู้ใช้ การทดสอบ และ ทดแทน ระบบเก่าสำหรับอันใหม่- การเตรียมการสำหรับระยะนี้เริ่มต้นด้วยขั้นตอนการออกแบบ
ก่อนหน้านี้ Beverly Flowers รับคำสั่งซื้อโดยตรงที่จุดขายและทางโทรศัพท์
โดยบันทึกข้อความเกี่ยวกับความเป็นไปได้ในการสั่งซื้อผ่านทาง แอปพลิเคชั่นพิเศษและด้วยการวางแผงข้อมูล ณ จุดขาย ในเวลา 2 สัปดาห์ เราก็สามารถเปลี่ยนผู้ซื้อบางรายไปใช้ได้ ช่องใหม่ฝ่ายขาย
ในขณะเดียวกัน ส่วนแบ่งการสั่งซื้อทางโทรศัพท์ก็ลดลงตามสัดส่วน ซึ่งหมายความว่าสามารถลดพนักงานของผู้จัดการฝ่ายบริการลูกค้าลงได้
เป็นที่น่าสังเกตว่า วงจรชีวิตของโครงการตามวิธี RAD นั้นไม่เหมือนกับ Waterfall ตรงที่จะไม่เข้มงวด จำนวนเฟสอาจลดลงรวมถึงการเติมทั้งนี้ขึ้นอยู่กับเงื่อนไขการเริ่มต้น
ข้อดีและข้อเสียของการพัฒนาแอปพลิเคชันอย่างรวดเร็วในบริษัทของคุณ
จะใช้ Rapid Application Development หรือไม่ ส่วนใหญ่ขึ้นอยู่กับเงื่อนไขการเริ่มต้น ความต้องการของลูกค้า และประเภทของแอปพลิเคชัน
ข้อดีที่ชัดเจนของ RAD ได้แก่:
- คุณภาพสูง.การโต้ตอบของผู้ใช้กับต้นแบบช่วยเพิ่มฟังก์ชันการทำงานของโครงการพัฒนาแอปพลิเคชันที่รวดเร็ว ซอฟต์แวร์ดังกล่าวอาจตอบสนองความต้องการของลูกค้า (ผู้ใช้ปลายทาง) ได้ดีกว่าการใช้วิธี Agile/Waterfall
- การควบคุมความเสี่ยง- แม้ว่า ส่วนแบ่งของสิงโต เนื้อหาเกี่ยวกับ RAD มุ่งเน้นไปที่ ความเร็วและ การมีส่วนร่วมผู้ใช้เป็น คุณสมบัติที่สำคัญข้อได้เปรียบที่สำคัญประการที่สามไม่สามารถตัดทิ้งได้ — การลดความเสี่ยง.
สิ่งที่น่าสนใจคือ Boehm ซึ่งเป็นผู้สร้าง RAD เวอร์ชันแรก อธิบายว่าโมเดลเกลียวเป็นแบบอิงตามความเสี่ยง
การใช้การพัฒนาแอปพลิเคชันอย่างรวดเร็วช่วยให้คุณมุ่งเน้นไปที่ปัจจัยเสี่ยงหลักและปรับตัวให้เข้ากับปัจจัยเหล่านั้นได้ตั้งแต่ระยะแรก - โครงการเพิ่มเติมจะแล้วเสร็จต่อหน่วยเวลาภายในงบประมาณ- เนื่องจาก RAD หมายถึง รูปแบบการพัฒนาส่วนเพิ่มโอกาสสำหรับ ข้อผิดพลาดที่สำคัญซึ่งมักเกิดขึ้นในโครงการน้ำตกขนาดใหญ่ก็ลดลง
หากในโครงการระบบ Waterfall การดำเนินโครงการเป็นไปได้หลังจากการวิเคราะห์และพัฒนาเป็นเวลาหกเดือนขึ้นไป ข้อมูลที่จำเป็นทั้งหมดจะถูกเปิดเผยใน RAD ก่อนหน้านี้ในระหว่างกระบวนการสร้างแอปพลิเคชัน
รูปแบบการพัฒนาส่วนเพิ่มคือรูปแบบการพัฒนาซอฟต์แวร์ที่เกี่ยวข้องกับการแบ่งผลิตภัณฑ์ออกเป็นส่วนประกอบที่ค่อนข้างอิสระ ส่วนหลังได้รับการพัฒนาและนำไปใช้งานแยกกัน
ไม่ใช่โดยไม่มีข้อบกพร่อง
ข้อเสียของการพัฒนาแอปพลิเคชั่นอย่างรวดเร็ว ได้แก่ :
- ความเสี่ยงของ "ความแปลกใหม่"— สำหรับบริษัทไอทีส่วนใหญ่ RAD เป็นผลิตภัณฑ์ใหม่ที่ต้องคิดใหม่เกี่ยวกับวิธีการทำงานตามปกติ การต่อต้านสิ่งใหม่ๆ และความจำเป็นในการเรียนรู้เครื่องมือและเทคนิคตั้งแต่เริ่มต้น นำไปสู่ข้อผิดพลาดระหว่างการใช้งานครั้งแรกของการพัฒนาแอปพลิเคชันอย่างรวดเร็ว
- หากผู้ใช้ไม่สามารถมีส่วนร่วมในกระบวนการพัฒนาอย่างต่อเนื่องตลอดวงจรชีวิตทั้งหมด สิ่งนี้อาจส่งผลเสียต่อผลิตภัณฑ์ขั้นสุดท้ายได้ คุณลักษณะของ RAD คือการเพิ่มปฏิสัมพันธ์ระหว่างผู้ใช้และนักพัฒนา ซึ่งแตกต่างจากโมเดล Waterfall ที่บทบาทของผู้ใช้ลดลงเพื่อกำหนดข้อกำหนด . ต่อไปผู้พัฒนาจะสร้างระบบเอง
- การควบคุมลดลง— ความยืดหยุ่น ความสามารถในการปรับตัวตามกระบวนการเป็นหนึ่งในข้อดีของ RAD ซึ่งหมายถึงความสามารถในการปรับตัวเข้ากับทั้งปัญหาและโอกาสได้อย่างรวดเร็ว
น่าเสียดาย, คุณจะต้องให้ความสำคัญกับสิ่งหนึ่ง - ความยืดหยุ่นหรือการควบคุมในกรณีหลัง วิธีการพัฒนาแอปพลิเคชันแบบรวดเร็วจะไม่สามารถทำได้ - การออกแบบเบาบาง- การมุ่งเน้นไปที่ต้นแบบในบางกรณีนำไปสู่วิธีการ "แฮ็กและทดสอบ" ซึ่งนักพัฒนา ทำการเปลี่ยนแปลงเล็กๆ น้อยๆ อย่างต่อเนื่องวี แต่ละองค์ประกอบและเพิกเฉยต่อปัญหาสถาปัตยกรรมระบบ
- ขาดความสามารถในการขยายขนาด— RAD ถูกใช้โดยทีมงานโครงการขนาดเล็กและขนาดกลางเป็นหลัก ข้อบกพร่องของวิธีการพัฒนาแอปพลิเคชันอย่างรวดเร็วนั้นเด่นชัดเป็นพิเศษเมื่อใช้การพัฒนาแอปพลิเคชันอย่างรวดเร็วในการทำงานในโครงการขนาดใหญ่
วิธีการ RAD เหมาะสำหรับโครงการของคุณหาก:
- ความเร็วและความสะดวกในการพัฒนาเป็นสิ่งสำคัญสำหรับเขา
- กำหนดไว้อย่างชัดเจน พื้นที่ลำดับความสำคัญการพัฒนาโครงการ
- แอปพลิเคชันจะต้องได้รับการพัฒนาในเวลาอันสั้น
- โครงการนี้ดำเนินการภายใต้งบประมาณที่จำกัด
- เกณฑ์หลักคือส่วนต่อประสานกับผู้ใช้
- สามารถแบ่งโครงการออกเป็นองค์ประกอบการทำงานได้
วิธีการพัฒนาแอปพลิเคชันอย่างรวดเร็วจะไม่เหมาะกับโครงการของคุณ หาก:
- คุณภาพและการควบคุมเป็นสิ่งสำคัญสำหรับเขา
- เรากำลังพูดถึงการสร้าง โครงการขนาดใหญ่- ที่ควร เวลาสูงสุดเวลาในการพัฒนาแอปพลิเคชันคือ 60-90 วัน และเมื่อเขียนโค้ดโปรแกรมหลายแสนบรรทัด แทบจะเป็นไปไม่ได้เลยที่จะปฏิบัติตามข้อจำกัดดังกล่าว
- ที่สำคัญต่อการดำเนินการคือการวางแผนระดับสูงและ วินัยการออกแบบที่เข้มงวดการปฏิบัติตามโปรโตคอลและอินเทอร์เฟซที่พัฒนาไว้ล่วงหน้าอย่างเข้มงวด
- ความปลอดภัยของผู้คนขึ้นอยู่กับการใช้งานในระดับหนึ่ง
คำตัดสิน
แนวคิดของการพัฒนาแอปพลิเคชันอย่างรวดเร็ว (ตัวย่อ RAD สำหรับการพัฒนาแอปพลิเคชันอย่างรวดเร็ว) เป็นรูปแบบของการพัฒนาซอฟต์แวร์แบบส่วนเพิ่มประเภทหนึ่ง
พารามิเตอร์หลักที่ RAD ทำงานคือ:
ความเร็วและความง่ายในการเขียนโปรแกรม
วิธีการจะกลายเป็น ทางเลือกที่ยอดเยี่ยมเพื่อนำไปปฏิบัติ โครงการขนาดเล็กที่มีงบประมาณจำกัดซึ่งจำเป็นต้องได้รับการพัฒนา ในเวลาอันสั้น- สำหรับระบบขนาดใหญ่ด้วย ความต้องการสูงในการควบคุมและวางแผนควรเลือกรูปแบบการพัฒนาซอฟต์แวร์อื่นจะดีกว่า
Rapid Application Development (RAD) เป็นวงจรกระบวนการออกแบบที่ออกแบบมาเพื่อให้บรรลุผลสำเร็จมากขึ้น ความเร็วสูงการพัฒนาและคุณภาพของซอฟต์แวร์เกินกว่าจะเป็นไปได้ด้วยวิธีการออกแบบแบบดั้งเดิม
แนวคิด RAD เป็นการตอบสนองต่อวิธีการพัฒนาซอฟต์แวร์ในช่วงทศวรรษปี 1970 และต้นทศวรรษ 1980 เช่น "แบบจำลองน้ำตก" วิธีการเหล่านี้เกี่ยวข้องกับกระบวนการที่ช้าในการสร้างโปรแกรมซึ่งบ่อยครั้งแม้แต่ข้อกำหนดสำหรับโปรแกรมก็ยังมีเวลาที่จะเปลี่ยนแปลงก่อนสิ้นสุดการพัฒนา ผู้ก่อตั้ง RAD ถือเป็นพนักงานของ IBM James Martin ผู้ซึ่งในช่วงทศวรรษ 1980 ได้กำหนดหลักการพื้นฐานของ RAD ตามแนวคิดของ Barry Boym และ Scott Schultz และในปี 1991 มาร์ตินตีพิมพ์หนังสือชื่อดังซึ่งเขาได้สรุปรายละเอียดเกี่ยวกับแนวคิดของ RAD และความเป็นไปได้ของการประยุกต์ใช้ ปัจจุบัน RAD กำลังกลายเป็นโครงการที่เป็นที่ยอมรับโดยทั่วไปสำหรับการสร้างเครื่องมือพัฒนาซอฟต์แวร์
RAD สันนิษฐานว่าการพัฒนาซอฟต์แวร์ดำเนินการโดยทีมนักพัฒนากลุ่มเล็กๆ ในช่วงเวลาประมาณสามถึงสี่ครั้ง โดยใช้เครื่องมือสร้างแบบจำลองและการพัฒนาด้วยภาพ เทคโนโลยี RAD จัดให้ การมีส่วนร่วมอย่างแข็งขันลูกค้าอยู่ในระยะเริ่มต้นแล้ว - การสำรวจองค์กร การพัฒนาข้อกำหนดของระบบ วิธีการของ RAD เป็นหนึ่งในแนวทางในการพัฒนาซอฟต์แวร์ภายในแบบจำลองวงจรชีวิตแบบก้นหอย
วงจรชีวิตซอฟต์แวร์ตามวิธี RAD ประกอบด้วยสี่ระยะ:
ขั้นตอนการวิเคราะห์และวางแผนความต้องการ
ขั้นตอนการออกแบบ
ขั้นตอนการก่อสร้าง
ขั้นตอนการดำเนินการ
ในขั้นตอนการวิเคราะห์และการวางแผนความต้องการ ผู้ใช้ดำเนินการต่อไปนี้:
การกำหนดหน้าที่ที่ระบบควรปฏิบัติ
เน้นฟังก์ชั่นที่มีลำดับความสำคัญสูงสุดที่ต้องอธิบายรายละเอียดก่อน
คำอธิบายความต้องการข้อมูล
การกำหนดความต้องการของระบบส่วนใหญ่ดำเนินการโดยผู้ใช้ภายใต้คำแนะนำของนักพัฒนาผู้เชี่ยวชาญ นอกจากนี้ ในขั้นตอนนี้งานต่อไปนี้จะได้รับการแก้ไข:
ขอบเขตของโครงการมีจำกัด
กรอบเวลาจะถูกกำหนดไว้สำหรับแต่ละขั้นตอนต่อๆ ไป
มีการกำหนดความเป็นไปได้ในการดำเนินโครงการภายในจำนวนเงินทุนที่กำหนดโดยใช้ฮาร์ดแวร์ที่มีอยู่ ฯลฯ ผลลัพธ์ของสเตจควรเป็น:
รายการฟังก์ชันที่จัดลำดับความสำคัญของซอฟต์แวร์ IS ในอนาคต
รุ่นซอฟต์แวร์เบื้องต้น
ในขั้นตอนการออกแบบ ผู้ใช้บางรายมีส่วนร่วมในการออกแบบทางเทคนิคของระบบภายใต้คำแนะนำของนักพัฒนาผู้เชี่ยวชาญ เพื่อให้ได้ต้นแบบแอปพลิเคชันที่ทำงานได้อย่างรวดเร็ว จึงใช้เครื่องมือที่เหมาะสม (เครื่องมือ CASE) ผู้ใช้โต้ตอบโดยตรงกับนักพัฒนา ชี้แจงและเสริมข้อกำหนดของระบบที่ไม่ได้ระบุไว้ในขั้นตอนก่อนหน้า ในขั้นตอนนี้จะมีการดำเนินการดังต่อไปนี้:
กระบวนการของระบบได้รับการตรวจสอบอย่างละเอียดมากขึ้น
หากจำเป็น จะมีการสร้างต้นแบบบางส่วนสำหรับแต่ละกระบวนการเบื้องต้น (รูปแบบหน้าจอ บทสนทนา รายงาน การขจัดความคลุมเครือหรือความคลุมเครือ)
มีการกำหนดข้อกำหนดสำหรับการจำกัดการเข้าถึงข้อมูล
กำหนดองค์ประกอบของเอกสารที่จำเป็น
จากนั้นโครงการจะกระจายไปยังทีมพัฒนาต่างๆ ในกรณีของการใช้เครื่องมือ CASE นี่หมายถึงการแบ่งแบบจำลองการทำงานของระบบ (แผนภาพการไหลของข้อมูลสำหรับแนวทางที่มีโครงสร้าง หรือแผนภาพกรณีการใช้งานสำหรับแนวทางเชิงวัตถุ) ผลลัพธ์ของขั้นตอนนี้ควรเป็น:
รูปแบบข้อมูลทั่วไปของระบบ
โมเดลการทำงานของระบบโดยรวมและระบบย่อยที่ดำเนินการโดยทีมพัฒนาแต่ละทีม
อินเทอร์เฟซที่กำหนดไว้อย่างแม่นยำระหว่างระบบย่อยที่พัฒนาขึ้นโดยอัตโนมัติ
สร้างต้นแบบของแบบฟอร์มหน้าจอ รายงาน กล่องโต้ตอบ
จะต้องได้รับแบบจำลองและต้นแบบทั้งหมดโดยใช้เครื่องมือของ CASE ที่จะใช้ในอนาคตเมื่อสร้างระบบ ข้อกำหนดนี้มีสาเหตุมาจากความจำเป็นในการหลีกเลี่ยงการบิดเบือนข้อมูลที่ไม่สามารถควบคุมได้เมื่อถ่ายโอนข้อมูลเกี่ยวกับโครงการจากขั้นตอนหนึ่งไปอีกขั้นตอนหนึ่ง
ในขั้นตอนการดำเนินการ การพัฒนาแอปพลิเคชันอย่างรวดเร็วจะดำเนินการ:
นักพัฒนาสร้างระบบจริงซ้ำๆ ตามแบบจำลองที่ได้รับในขั้นตอนก่อนหน้า รวมถึงข้อกำหนดที่ไม่สามารถใช้งานได้ (ข้อกำหนดด้านความน่าเชื่อถือ ข้อกำหนดด้านประสิทธิภาพ ฯลฯ)
ผู้ใช้ประเมินผลลัพธ์ที่ได้รับและทำการปรับเปลี่ยนในระหว่างกระบวนการพัฒนา หากระบบไม่ตรงตามข้อกำหนดที่กำหนดไว้ก่อนหน้านี้อีกต่อไป การทดสอบระบบจะดำเนินการในระหว่างกระบวนการพัฒนา
หลังจากเสร็จสิ้นการทำงานของทีมพัฒนาแต่ละทีมแล้ว จะมีการดำเนินการบูรณาการส่วนนี้ของระบบกับส่วนที่เหลืออย่างค่อยเป็นค่อยไป สร้างโค้ดโปรแกรมที่สมบูรณ์ขึ้น การทดสอบการทำงานร่วมกันของส่วนนี้ของแอปพลิเคชัน จากนั้นระบบจะเป็นดังนี้ มีการทดสอบทั้งหมด การนำระบบไปใช้จะเสร็จสมบูรณ์โดยดำเนินการดังต่อไปนี้:
มีการวิเคราะห์การใช้ข้อมูลและกำหนดความจำเป็นในการกระจายข้อมูล
มีการออกแบบทางกายภาพของฐานข้อมูล
มีการกำหนดข้อกำหนดสำหรับทรัพยากรฮาร์ดแวร์
มีการกำหนดวิธีการเพิ่มผลผลิต
การพัฒนาเอกสารโครงการเสร็จสิ้นแล้ว ผลลัพธ์ของขั้นตอนคือระบบที่เสร็จสมบูรณ์ซึ่งตรงตามข้อกำหนดที่ตกลงกันไว้ทั้งหมด
ในขั้นตอนการนำไปใช้ จะมีการฝึกอบรมผู้ใช้และการเปลี่ยนแปลงองค์กร
แนะนำให้ใช้เทคโนโลยี RAD เมื่อ:
โครงการจะต้องแล้วเสร็จภายในกรอบเวลาอันสั้น (90 วัน)
ข้อกำหนดซอฟต์แวร์ไม่ได้กำหนดไว้อย่างชัดเจน
โครงการนี้ดำเนินการภายใต้ข้อจำกัดด้านงบประมาณ
ส่วนติดต่อผู้ใช้ (GUI) เป็นปัจจัยหลัก
โครงการมีขนาดใหญ่ แต่สามารถแบ่งออกเป็นองค์ประกอบการทำงานที่เล็กลงได้
ซอฟต์แวร์ไม่มีความซับซ้อนในการคำนวณสูง
เทคโนโลยี RAD ไม่เป็นสากลนั่นคือไม่แนะนำให้ใช้เสมอไป เช่นในโครงการที่มีข้อกำหนดสำหรับ ผลิตภัณฑ์ซอฟต์แวร์มีการกำหนดไว้อย่างชัดเจนและไม่ควรเปลี่ยนแปลง ลูกค้าไม่จำเป็นต้องมีส่วนร่วมกับกระบวนการพัฒนา และการพัฒนาแบบลำดับชั้น (วิธีแบบเรียงซ้อน) จะมีประสิทธิภาพมากขึ้น เช่นเดียวกับโครงการ ซอฟต์แวร์ ความซับซ้อนที่กำหนดโดยความจำเป็นในการดำเนินการ อัลกอริธึมที่ซับซ้อนและบทบาทและปริมาณ หน้าจอผู้ใช้เล็ก.
รูปที่ 1 - การเปรียบเทียบวิธี RAD และ Cascade
