التطوير التكراري والتدريجي

التطوير التكراري والتدريجي هو أي مزيج من التصميم التكراري ( أو الطريقة التكرارية) ونموذج البناء التدريجي للتطوير .

بدأ استخدام المصطلح في تطوير البرمجيات ، حيث تم اقتراح مزيج طويل الأمد من المصطلحين التكراري والتزايدي ^{[1] على نطاق واسع لجهود التطوير الكبيرة. على سبيل المثال}، يذكر DOD-STD-2167 لعام 1985 ^[2] (في القسم 4.1.2): "أثناء تطوير البرمجيات، قد يكون هناك أكثر من تكرار لدورة تطوير البرمجيات جارية في نفس الوقت." و"يمكن وصف هذه العملية بأنها نهج "اكتساب تطوري" أو "بناء تدريجي". في البرمجيات، يتم تحديد العلاقة بين التكرارات والزيادات من خلال عملية تطوير البرمجيات الإجمالية .

ملخص

الفكرة الأساسية وراء هذه الطريقة هي تطوير نظام من خلال دورات متكررة (تكرارية) وفي أجزاء أصغر في كل مرة (تزايدية)، مما يسمح لمطوري البرامج بالاستفادة مما تم تعلمه أثناء تطوير الأجزاء أو الإصدارات السابقة من النظام. يأتي التعلم من تطوير النظام واستخدامه، حيث تبدأ الخطوات الرئيسية في العملية، حيثما أمكن، بتنفيذ بسيط لمجموعة فرعية من متطلبات البرنامج وتعزيز الإصدارات المتطورة بشكل متكرر حتى يتم تنفيذ النظام بالكامل. في كل تكرار ، يتم إجراء تعديلات على التصميم وإضافة قدرات وظيفية جديدة. ^[3]

تتكون العملية نفسها من خطوة التهيئة وخطوة التكرار وقائمة التحكم بالمشروع. تعمل خطوة التهيئة على إنشاء نسخة أساسية من النظام. والهدف من هذا التنفيذ الأولي هو إنشاء منتج يمكن للمستخدم التفاعل معه. ويجب أن يقدم عينة من الجوانب الرئيسية للمشكلة ويقدم حلاً بسيطًا بما يكفي لفهمه وتنفيذه بسهولة. لتوجيه عملية التكرار، يتم إنشاء قائمة تحكم بالمشروع تحتوي على سجل لجميع المهام التي يجب تنفيذها. وهي تتضمن عناصر مثل الميزات الجديدة التي يجب تنفيذها ومجالات إعادة تصميم الحل الحالي. يتم مراجعة قائمة التحكم باستمرار نتيجة لمرحلة التحليل.

تتضمن التكرارات إعادة التصميم والتنفيذ، والتي من المفترض أن تكون بسيطة ومباشرة ومقسمة إلى وحدات، مما يدعم إعادة التصميم في تلك المرحلة أو كمهمة مستقبلية تضاف إلى قائمة التحكم في المشروع. ^{[ التوضيح مطلوب ]} لا يتم تحديد مستوى تفاصيل التصميم من خلال النهج التكراري. في مشروع تكراري خفيف الوزن، قد يمثل الكود المصدر الرئيسي لتوثيق النظام؛ ومع ذلك، في مشروع تكراري بالغ الأهمية، يمكن استخدام وثيقة تصميم برمجية رسمية . يعتمد تحليل التكرار على ملاحظات المستخدم ومرافق تحليل البرنامج المتاحة. يتضمن تحليل البنية والوحدات النمطية وقابلية الاستخدام والموثوقية والكفاءة وتحقيق الأهداف. يتم تعديل قائمة التحكم في المشروع في ضوء نتائج التحليل.

المراحل

يقوم التطوير التدريجي بتقسيم وظائف النظام إلى زيادات (أجزاء). في كل زيادة، يتم تسليم جزء من الوظائف من خلال العمل عبر التخصصات ، من المتطلبات إلى النشر . تقوم العملية الموحدة بتجميع الزيادات/التكرارات في مراحل: البداية، والتوسع، والبناء، والانتقال.

تحدد البداية نطاق المشروع ومتطلباته (الوظيفية وغير الوظيفية) والمخاطر على مستوى عالٍ ولكن بتفاصيل كافية بحيث يمكن تقدير العمل.
يقدم التطوير بنية عمل تعمل على تخفيف المخاطر الكبرى وتلبية المتطلبات غير الوظيفية.
يقوم البناء بملء الهندسة المعمارية بشكل تدريجي باستخدام الكود الجاهز للإنتاج والذي تم إنتاجه من خلال التحليل والتصميم والتنفيذ واختبار المتطلبات الوظيفية.
يقوم الانتقال بتسليم النظام إلى بيئة التشغيل الإنتاجية.

يمكن تقسيم كل مرحلة إلى تكرار واحد أو أكثر، والتي تكون عادةً محددة بوقت وليس بميزة. يعمل المهندسون والمحللون قبل المطورين والمختبرين بتكرار واحد للحفاظ على تراكم منتجات العمل الخاصة بهم ممتلئًا.

الاستخدام/التاريخ

تم تقديم العديد من الأمثلة على الاستخدام المبكر في مقال كريج لارمان وفيكتور باسيلي "التطوير التكراري والتدريجي: تاريخ موجز"، ^[4] حيث كان أحد أقدم هذه الأمثلة هو مشروع ميركوري التابع لوكالة ناسا في ستينيات القرن العشرين .

قام بعض مهندسي ميركوري فيما بعد بتشكيل قسم جديد داخل شركة آي بي إم ، حيث "كان هناك مثال مبكر ومذهل آخر لنجاح كبير في IID [كان] جوهر برنامج مكوك الفضاء التابع لوكالة ناسا - نظام برمجيات الطيران الأساسي، والذي [قاموا] ببنائه من عام 1977 إلى عام 1980. طبق الفريق IID في سلسلة من 17 تكرارًا على مدار 31 شهرًا، بمتوسط حوالي ثمانية أسابيع لكل تكرار. كان دافعهم لتجنب دورة حياة الشلال هو أن متطلبات برنامج المكوك تغيرت أثناء عملية تطوير البرنامج." ^[4]

تفضل بعض المنظمات، مثل وزارة الدفاع الأمريكية، المنهجيات التكرارية، بدءًا من MIL-STD-498 "التي تشجع بشكل واضح الاستحواذ التطوري وIID".

أشارت تعليمات وزارة الدفاع رقم 5000.2 الصادرة في عام 2000 إلى تفضيل واضح لنظام IID:

هناك طريقتان للوصول إلى القدرة الكاملة، الطريقة التطورية والطريقة ذات الخطوة الواحدة [الشلال]. ويفضل اتباع الطريقة التطورية... [في هذه الطريقة]، يتم تقسيم القدرة النهائية المقدمة للمستخدم إلى كتلتين أو أكثر، مع زيادة تدريجية في القدرة... ويتعين على تطوير البرمجيات أن يتبع عملية تطوير حلزونية متكررة حيث تعتمد الإصدارات المتوسعة باستمرار من البرمجيات على التعلم من التطوير السابق. ويمكن أيضًا القيام بذلك على مراحل.

لم تعد المراجعات الأخيرة لـ DoDI 5000.02 تشير إلى "التطوير الحلزوني"، لكنها تؤيد النهج العام كخط أساس لبرامج التطوير/المشتريات التي تعتمد على البرمجيات بشكل مكثف. ^[5] بالإضافة إلى ذلك، تستخدم الوكالة الأمريكية للتنمية الدولية (USAID) أيضًا نهجًا تطويريًا تكراريًا وتدريجيًا لدورة برمجتها لتصميم ومراقبة وتقييم وتعلم وتكييف مشاريع التنمية الدولية مع نهج إدارة المشاريع الذي يركز على دمج استراتيجيات التعاون والتعلم والتكيف لتكرار وتكييف البرمجة. ^[6]

التباين مع تطوير الشلال

السبب الرئيسي لفشل مشاريع تطوير البرمجيات هو اختيار النموذج، لذلك يجب أن يتم ذلك بعناية كبيرة. ^{[ غامض ]}^[7]

على سبيل المثال، يكمل نموذج تطوير الشلال منتجات العمل الخاصة بكل تخصص على مستوى المشروع في خطوة واحدة قبل الانتقال إلى التخصص التالي في خطوة لاحقة. يتم تقديم القيمة التجارية دفعة واحدة، وفي نهاية المشروع فقط، في حين أن التراجع ^{[ بحاجة لتوضيح ]} ممكن في نهج تكراري. عند مقارنة النهجين، تبدأ بعض الأنماط في الظهور: ^{[ بحاجة لمصدر ]}

مشاركة المستخدم : في نموذج الشلال، يشارك المستخدم في مرحلتين من النموذج، أي اختبار المتطلبات والقبول، وربما إنشاء مواد تعليمية للمستخدم. بينما في النموذج التدريجي، يشارك العميل في كل مرحلة.
التنوع : يتم تسليم البرنامج للمستخدم فقط بعد اكتمال مرحلة البناء من دورة الحياة، وذلك لاختبار قبول المستخدم. من ناحية أخرى، يتم تسليم كل زيادة للمستخدم وبعد موافقة المستخدم، يُسمح للمطور بالانتقال إلى الوحدة التالية.
الموارد البشرية : في النموذج التدريجي، من المحتمل أن يكون هناك حاجة إلى عدد أقل من الموظفين مقارنة بنموذج الشلال.
الحدود الزمنية : يتم تسليم المنتج التشغيلي بعد أشهر بينما في النموذج التدريجي يتم تسليم المنتج للمستخدم في غضون أسابيع قليلة.
حجم المشروع : نموذج الشلال غير مناسب للمشاريع الصغيرة في حين أن النموذج التدريجي مناسب للمشاريع الصغيرة والكبيرة.

المبادئ التوجيهية للتنفيذ

تتضمن المبادئ التوجيهية التي تحكم تنفيذ البرامج وتحليلها ما يلي: ^{[ بحاجة لمصدر ]}

إن أي صعوبة في التصميم أو الترميز أو اختبار التعديل يجب أن تشير إلى الحاجة إلى إعادة التصميم أو إعادة الترميز.
يجب أن تتناسب التعديلات بسهولة مع الوحدات المعزولة وسهلة العثور عليها. وإذا لم يكن الأمر كذلك، فقد تكون هناك حاجة إلى إعادة التصميم.
يجب أن يكون إجراء التعديلات على الجداول سهلاً بشكل خاص. إذا لم يتم إجراء أي تعديل على الجدول بسرعة وسهولة، فيُنصح بإعادة التصميم.
يجب أن تصبح التعديلات أسهل مع تقدم التكرارات. وإذا لم يكن الأمر كذلك، فهناك مشكلة أساسية مثل عيب في التصميم أو انتشار التصحيحات .
يجب أن يُسمح عادةً بوجود التصحيحات لتكرار واحد أو اثنين فقط. قد تكون التصحيحات ضرورية لتجنب إعادة التصميم أثناء مرحلة التنفيذ.
ينبغي تحليل التنفيذ الحالي بشكل متكرر لتحديد مدى ملاءمته لأهداف المشروع.
ينبغي استخدام مرافق تحليل البرنامج عندما تكون متاحة للمساعدة في تحليل التنفيذات الجزئية.
ينبغي طلب ردود أفعال المستخدمين وتحليلها بحثًا عن مؤشرات على وجود أوجه قصور في التنفيذ الحالي.

الاستخدام في الأجهزة والأنظمة المضمنة

على الرغم من أن مصطلح التطوير التكراري والتدريجي بدأ في صناعة البرمجيات، فإن العديد من جهود تطوير الأجهزة والبرامج المضمنة تستخدم تقنيات تكرارية وتدريجية.

يمكن رؤية أمثلة على ذلك في عدد من الصناعات. أحد القطاعات التي تأثرت مؤخرًا بشكل كبير بهذا التحول في التفكير هو صناعة إطلاق الفضاء ، مع وجود قوى تنافسية جديدة كبيرة في العمل ناجمة عن الابتكار التكنولوجي الأسرع والأكثر شمولاً الذي تم جلبه من خلال تشكيل شركات خاصة تسعى إلى إطلاق الفضاء. تقدم هذه الشركات، مثل SpaceX ^[8] و Rocket Lab ^[9] الآن خدمات الإطلاق المداري التجارية في العقد الماضي ، وهو ما لم تفعله سوى ست دول قبل عقد من الزمان ^[10] . الابتكار الجديد في أساليب تطوير التكنولوجيا، والتسعير، وعروض الخدمة - بما في ذلك القدرة التي كانت موجودة فقط منذ عام 2016 على الطيران إلى الفضاء على مرحلة معززة تم إطلاقها سابقًا (قابلة لإعادة الاستخدام) - يقلل بشكل أكبر من سعر الحصول على الوصول إلى الفضاء. ^[11]^[8]

كانت شركة سبيس إكس صريحة بشأن جهودها لإدخال ممارسات التصميم التكراري في صناعة الفضاء، وتستخدم هذه التقنية في المركبات الفضائية، ومركبات الإطلاق، والإلكترونيات والطيران، وعمليات تشغيل أجهزة الطيران التشغيلية. ^[12]

ومع بدء تغير الصناعة، بدأت شركات الإطلاق المنافسة الأخرى في تغيير ممارسات التطوير الطويلة الأجل مع الوكالات الحكومية أيضًا. على سبيل المثال، بدأت شركة United Launch Alliance (ULA) وهي شركة كبيرة تقدم خدمات الإطلاق في الولايات المتحدة في عام 2015 مشروعًا لمدة عشر سنوات لإعادة هيكلة أعمال الإطلاق الخاصة بها - تقليص عدد مركبات الإطلاق إلى مركبة واحدة - باستخدام نهج تكراري وتدريجي للوصول إلى نظام إطلاق قابل لإعادة الاستخدام جزئيًا وأقل تكلفة بكثير على مدى العقد المقبل. ^[13]

انظر أيضا

ملحوظات

^ Larman, Craig (June 2003). "التطوير التكراري والتزايدي: تاريخ موجز" (PDF) . Computer . 36 (6): 47–56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. كنا نقوم بالتطوير التزايدي منذ عام 1957، في لوس أنجلوس، تحت إشراف بيرني ديمسديل [في شركة ServiceBureau Corporation التابعة لشركة IBM]. كان زميلاً لجون فون نيومان ، لذا ربما تعلمه هناك، أو افترض أنه طبيعي تمامًا. أتذكر أن هيرب جاكوبس (أساسًا، على الرغم من مشاركتنا جميعًا) قام بتطوير محاكاة كبيرة لشركة موتورولا، حيث كانت التقنية المستخدمة، بقدر ما أستطيع أن أقول ...'
^ DOD-STD-2167 تطوير برمجيات أنظمة الدفاع (04 يونيو 1985) على everyspec.com
^ فارسيك، فيكتور (21 يناير 2014). "نماذج تطوير البرمجيات: التطوير التكراري والتدريجي". محادثات التكنولوجيا .
^ ab التطوير التكراري والتدريجي: تاريخ موجز، كريج لارمان وفيكتور باسيلي، معهد مهندسي الكهرباء والإلكترونيات للكمبيوتر، يونيو 2003
^ كيندال، فرانك؛ جيلمور، ج. مايكل؛ هالفورسن، تيري (2017-02-02). "تشغيل نظام المشتريات الدفاعية" (PDF) . إصدارات وزارة الدفاع . وكيل وزارة الدفاع للمشتريات والتكنولوجيا والخدمات اللوجستية. ص. 12-14. مؤرشف من الأصل (PDF) في 2017-08-09 . تم الاسترجاع في 2017-08-09 .
^ USAID. "ADS Chapter 201 Program Cycle Operational Policy" Archived 2019-10-23 at the Wayback Machine . Retrieved April 19, 2017
^ Kudryashov, Alexey (29 فبراير 2024). "النموذج التدريجي مقابل النموذج المتتالي في تطوير البرمجيات". Cyfrania: تطوير البرمجيات المخصصة والاستشارات . قد يؤدي اختيار النموذج التدريجي للمشاريع ذات المتطلبات المستقرة إلى توسع النطاق وزيادة التعقيد، في حين قد يؤدي اختيار نموذج المتتالي إلى الجمود وعدم الكفاءة في التكيف مع التغييرات.
^ ab Belfiore, Michael (9 December 2013). "The Rocketeer". Foreign Policy . مؤرشف من الأصل في 10 ديسمبر 2013 . تم الاسترجاع 11 نوفمبر 2018 .
^ "نظرة حصرية من الداخل على مصنع روكيت لاب الجديد الذي كان سريًا في السابق!". Everyday Astronaut . 11 أكتوبر 2018. مؤرشف من الأصل في 12 أكتوبر 2018 . تم الاسترجاع 11 نوفمبر 2018 .
^ كلارك، ستيفن (28 سبتمبر 2008). "نجاح ساحر أخيرًا لصاروخ فالكون 1". سبيس فلايت ناو . تم الاسترجاع في 11 نوفمبر 2018. أول صاروخ يعمل بالوقود السائل تم تطويره بشكل خاص يصل إلى مداره بنجاح.
^ بيرغر، إريك (2018-06-25). "صاروخ بروتون الروسي، الذي سبق أبولو، سيتوقف أخيرًا عن الطيران. المشاكل التقنية، وصعود سبيس إكس هي عوامل مساهمة". arsTechica . تم الاسترجاع في 2018-06-26 . أدى الارتفاع السريع للبدائل منخفضة التكلفة مثل صاروخ فالكون 9 التابع لسبيس إكس إلى انخفاض عدد عمليات إطلاق بروتون في عام معين من ثمانية أو نحو ذلك إلى واحد أو اثنين فقط.
^ فرنهولز، تيم (21 أكتوبر 2014). "ما الذي تطلبه الأمر من شركة سبيس إكس التابعة لإيلون ماسك لتعطيل بوينج، والقفز فوق وكالة ناسا، والتحول إلى شركة فضاء جادة". كوارتز . تم الاسترجاع في 11 نوفمبر 2018. لكن سبيس إكس كانت تعتقد دائمًا أنها شركة تقنية، وغالبًا ما اتخذت صداماتها مع وكالة ناسا شكلًا من أشكال مطوري الكمبيوتر - أو أي شخص على دراية بالطرح المضطرب لـ healthcare.gov - من شأنه أن يعترف بأنه جيلي. اتبعت سبيس إكس عملية تصميم تكرارية، حيث عملت باستمرار على تحسين النماذج الأولية استجابة للاختبار. تتطلب إدارة المنتجات التقليدية خطة قوية يتم تنفيذها حتى اكتمالها، وهي وصفة لتجاوز التكاليف.
^ جروس، مايك (2015-04-24). "تطور الخطة: يشرح المسؤولون التنفيذيون في ULA المنطق وراء اختيارات تصميم Vulcan". أخبار الفضاء . تم الاسترجاع في 25 أبريل 2015. إعلان ULA في 13 أبريل أنها ستطور صاروخًا يُدعى Vulcan باستخدام نهج تدريجي يكون تكراره الأول في الأساس عبارة عن Atlas 5 مجهز بمرحلة أولى جديدة.

مراجع

الدكتور أليستير كوكبيرن (مايو 2008). "استخدام التطوير التدريجي والتكراري" (PDF) . STSC CrossTalk . 21 (5). مركز دعم تكنولوجيا البرمجيات التابع للقوات الجوية الأمريكية : 27-30. ISSN 2160-1593. مؤرشف من الأصل (PDF) في 2012-05-26 . تم الاسترجاع في 2011-07-20 .
كريج لارمان، فيكتور ر. باسيلي (يونيو 2003). "التطوير التكراري والتزايدي: تاريخ موجز" (PDF) . IEEE Computer . 36 (6). IEEE Computer Society: 47–56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. تم الاسترجاع في 2009-01-10 .

Original text

Rate this translation

Your feedback will be used to help improve Google Translate

[1] Larman, Craig (June 2003). "التطوير التكراري والتزايدي: تاريخ موجز" (PDF) . Computer . 36 (6): 47–56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. كنا نقوم بالتطوير التزايدي منذ عام 1957، في لوس أنجلوس، تحت إشراف بيرني ديمسديل [في شركة ServiceBureau Corporation التابعة لشركة IBM]. كان زميلاً لجون فون نيومان ، لذا ربما تعلمه هناك، أو افترض أنه طبيعي تمامًا. أتذكر أن هيرب جاكوبس (أساسًا، على الرغم من مشاركتنا جميعًا) قام بتطوير محاكاة كبيرة لشركة موتورولا، حيث كانت التقنية المستخدمة، بقدر ما أستطيع أن أقول ...'

[2] DOD-STD-2167 تطوير برمجيات أنظمة الدفاع (04 يونيو 1985) على everyspec.com

[3] فارسيك، فيكتور (21 يناير 2014). "نماذج تطوير البرمجيات: التطوير التكراري والتدريجي". محادثات التكنولوجيا .

[ieee2003-4] التطوير التكراري والتدريجي: تاريخ موجز، كريج لارمان وفيكتور باسيلي، معهد مهندسي الكهرباء والإلكترونيات للكمبيوتر، يونيو 2003

[DoDI_5000.02_rev2017-02-02-5] كيندال، فرانك؛ جيلمور، ج. مايكل؛ هالفورسن، تيري (2017-02-02). "تشغيل نظام المشتريات الدفاعية" (PDF) . إصدارات وزارة الدفاع . وكيل وزارة الدفاع للمشتريات والتكنولوجيا والخدمات اللوجستية. ص. 12-14. مؤرشف من الأصل (PDF) في 2017-08-09 . تم الاسترجاع في 2017-08-09 .

[6] USAID. "ADS Chapter 201 Program Cycle Operational Policy" Archived 2019-10-23 at the Wayback Machine . Retrieved April 19, 2017

[7] Kudryashov, Alexey (29 فبراير 2024). "النموذج التدريجي مقابل النموذج المتتالي في تطوير البرمجيات". Cyfrania: تطوير البرمجيات المخصصة والاستشارات . قد يؤدي اختيار النموذج التدريجي للمشاريع ذات المتطلبات المستقرة إلى توسع النطاق وزيادة التعقيد، في حين قد يؤدي اختيار نموذج المتتالي إلى الجمود وعدم الكفاءة في التكيف مع التغييرات.

[fp20131209-8] Belfiore, Michael (9 December 2013). "The Rocketeer". Foreign Policy . مؤرشف من الأصل في 10 ديسمبر 2013 . تم الاسترجاع 11 نوفمبر 2018 .

[eda20181111-9] "نظرة حصرية من الداخل على مصنع روكيت لاب الجديد الذي كان سريًا في السابق!". Everyday Astronaut . 11 أكتوبر 2018. مؤرشف من الأصل في 12 أكتوبر 2018 . تم الاسترجاع 11 نوفمبر 2018 .

[sfn20080928-10] كلارك، ستيفن (28 سبتمبر 2008). "نجاح ساحر أخيرًا لصاروخ فالكون 1". سبيس فلايت ناو . تم الاسترجاع في 11 نوفمبر 2018. أول صاروخ يعمل بالوقود السائل تم تطويره بشكل خاص يصل إلى مداره بنجاح.

[arstech20180625-11] بيرغر، إريك (2018-06-25). "صاروخ بروتون الروسي، الذي سبق أبولو، سيتوقف أخيرًا عن الطيران. المشاكل التقنية، وصعود سبيس إكس هي عوامل مساهمة". arsTechica . تم الاسترجاع في 2018-06-26 . أدى الارتفاع السريع للبدائل منخفضة التكلفة مثل صاروخ فالكون 9 التابع لسبيس إكس إلى انخفاض عدد عمليات إطلاق بروتون في عام معين من ثمانية أو نحو ذلك إلى واحد أو اثنين فقط.

[qz20141021-12] فرنهولز، تيم (21 أكتوبر 2014). "ما الذي تطلبه الأمر من شركة سبيس إكس التابعة لإيلون ماسك لتعطيل بوينج، والقفز فوق وكالة ناسا، والتحول إلى شركة فضاء جادة". كوارتز . تم الاسترجاع في 11 نوفمبر 2018. لكن سبيس إكس كانت تعتقد دائمًا أنها شركة تقنية، وغالبًا ما اتخذت صداماتها مع وكالة ناسا شكلًا من أشكال مطوري الكمبيوتر - أو أي شخص على دراية بالطرح المضطرب لـ healthcare.gov - من شأنه أن يعترف بأنه جيلي. اتبعت سبيس إكس عملية تصميم تكرارية، حيث عملت باستمرار على تحسين النماذج الأولية استجابة للاختبار. تتطلب إدارة المنتجات التقليدية خطة قوية يتم تنفيذها حتى اكتمالها، وهي وصفة لتجاوز التكاليف.

[sn20150424-13] جروس، مايك (2015-04-24). "تطور الخطة: يشرح المسؤولون التنفيذيون في ULA المنطق وراء اختيارات تصميم Vulcan". أخبار الفضاء . تم الاسترجاع في 25 أبريل 2015. إعلان ULA في 13 أبريل أنها ستطور صاروخًا يُدعى Vulcan باستخدام نهج تدريجي يكون تكراره الأول في الأساس عبارة عن Atlas 5 مجهز بمرحلة أولى جديدة.

اللغة	العربية (RTL)
روابط موسوعية	30 رابطاً
المصدر الأصلي	ويكيبيديا ↗