Software prototyping

📅 آخر تحديث: ٢ أغسطس ٢٠٢٦
✍️ نُشر في: ٢ أغسطس ٢٠٢٦
الموسوعة الحرة

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of, and may be highly different from, the final product.

Prototyping has several benefits: the software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in prototyping have been in development and debate since its proposal in the early 1970s.[1]

Overview

The purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. Software prototyping provides an understanding of the software's functions and potential threats or issues.[2] Prototyping can also be used by end users to describe and prove requirements that have not been considered, and that can be a key factor in the commercial relationship between developers and their clients.[3]Interaction design in particular makes heavy use of prototyping with that goal.

This process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire program first and then working out any inconsistencies between design and implementation, which led to higher software costs and poor estimates of time and cost. The monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can also avoid the great expense and difficulty of having to change a finished software product.

The practice of prototyping is one of the points Frederick P. Brooks makes in his 1975 book The Mythical Man-Month and his 10-year anniversary article "No Silver Bullet".

كان تطبيق مترجم Ada/ED التابع لجامعة نيويورك للغة البرمجة Ada مثالًا مبكرًا على النماذج الأولية للبرمجيات واسعة النطاق . [ 4 ] تم تنفيذه في SETL بهدف إنتاج نموذج دلالي قابل للتنفيذ للغة Ada، مع التركيز على وضوح التصميم وواجهة المستخدم بدلًا من السرعة والكفاءة. كان نظام Ada/ED التابع لجامعة نيويورك أول تطبيق معتمد للغة Ada، حيث تم اعتماده في 11 أبريل 1983. [ 5 ]

مخطط تفصيلي

تتضمن عملية تصميم النماذج الأولية الخطوات التالية:

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

أبعاد

يلخص نيلسن الأبعاد المختلفة للنماذج الأولية في كتابه " هندسة سهولة الاستخدام" :

النموذج الأولي الأفقي

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

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

النموذج الأولي العمودي

النموذج الأولي الرأسي هو تطوير شامل ومُحسّن لنظام فرعي أو وظيفة واحدة. وهو مفيد للحصول على متطلبات تفصيلية لوظيفة معينة، مع المزايا التالية:

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

الأنواع

تتعدد أشكال تصميم النماذج الأولية للبرمجيات. ومع ذلك، فإن جميع هذه الأساليب تعتمد بشكل أو بآخر على شكلين رئيسيين من أشكال تصميم النماذج الأولية: تصميم النماذج الأولية القابلة للاستبدال وتصميم النماذج الأولية التطورية.

نموذج أولي يمكن التخلص منه

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

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

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

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

يُزعم أن النماذج الأولية السريعة الثورية تُعدّ طريقةً أكثر فعاليةً للتعامل مع المشكلات المتعلقة بمتطلبات المستخدم، وبالتالي تُحسّن إنتاجية البرمجيات بشكلٍ عام. إذ يُمكن تحديد المتطلبات ومحاكاتها واختبارها بسرعةٍ أكبر وبتكلفةٍ أقل بكثير عند تجاهل مشكلات قابلية التطوير والصيانة وبنية البرمجيات. وهذا بدوره يُؤدي إلى تحديد المتطلبات بدقة، ومن ثمّ بناء نظامٍ صالحٍ وقابلٍ للاستخدام من وجهة نظر المستخدم، وذلك عبر نماذج تطوير البرمجيات التقليدية. [ 7 ]

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

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

ملخص: في هذا النهج، يُبنى النموذج الأولي على أساس أنه سيتم التخلص منه، وسيتم بناء النظام النهائي من الصفر. خطوات هذا النهج هي:

  1. كتابة المتطلبات الأولية
  2. صمم النموذج الأولي
  3. تجربة المستخدم/استخدام النموذج الأولي، وتحديد المتطلبات الجديدة
  4. كرر ذلك إذا لزم الأمر
  5. اكتب المتطلبات النهائية

النمذجة التطورية

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

عند تطوير نظام باستخدام النماذج الأولية التطورية، يتم تحسين النظام وإعادة بنائه باستمرار.

"...يُقرّ النموذج الأولي التطوري بأننا لا نفهم جميع المتطلبات، ولا يبني إلا تلك التي نفهمها جيدًا." [ 8 ]

تتيح هذه التقنية لفريق التطوير إضافة ميزات أو إجراء تغييرات لم يكن من الممكن تصورها خلال مرحلة المتطلبات والتصميم.

لكي يكون النظام مفيدًا، يجب أن يتطور من خلال استخدامه في بيئة التشغيل المقصودة. فالمنتج لا يُعتبر "مكتملًا" أبدًا؛ بل هو دائمًا في طور النضج مع تغير بيئة الاستخدام... غالبًا ما نحاول تعريف النظام باستخدام إطارنا المرجعي الأكثر ألفة - أي وضعنا الحالي. نضع افتراضات حول كيفية إدارة الأعمال والقاعدة التقنية التي سيتم تطبيقها عليها. يتم وضع خطة لتطوير القدرة، وعاجلًا أم آجلًا، يتم تسليم شيء يشبه النظام المتصور. [ 9 ]

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

"ليس من غير المألوف في بيئة النماذج الأولية أن يستخدم المستخدم نموذجًا أوليًا عمليًا أثناء انتظار نسخة أكثر تطورًا... قد يقرر المستخدم أن نظامًا "معيبًا" أفضل من عدم وجود نظام على الإطلاق." [ 6 ]

في عملية النمذجة التطورية، يمكن للمطورين تركيز أنفسهم على تطوير أجزاء من النظام التي يفهمونها بدلاً من العمل على تطوير نظام كامل.

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

النمذجة الأولية التدريجية

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

النماذج الأولية المتطرفة

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

"تسمى هذه العملية بالنمذجة الأولية المتطرفة للفت الانتباه إلى المرحلة الثانية من العملية، حيث يتم تطوير واجهة مستخدم كاملة الوظائف مع إيلاء القليل من الاهتمام للخدمات بخلاف عقدها." [ 11 ]

المزايا

هناك العديد من المزايا لاستخدام النماذج الأولية في تطوير البرمجيات - بعضها ملموس، وبعضها مجرد. [ 12 ]

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

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

العيوب

قد يكون لاستخدام النماذج الأولية، أو ربما إساءة استخدامها، عيوب أيضاً.

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

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

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

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

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

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

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

قابلية التطبيق

لقد طُرحت فكرة استخدام النماذج الأولية، بشكل أو بآخر، بشكل دائم. ومع ذلك، فإن النماذج الأولية تكون أكثر فائدة في الأنظمة التي ستتفاعل بشكل متكرر مع المستخدمين.

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

لا تستفيد الأنظمة ذات التفاعل المحدود مع المستخدم، مثل أنظمة المعالجة الدفعية أو الأنظمة التي تُجري عمليات حسابية في الغالب، استفادةً كبيرة من النماذج الأولية. في بعض الأحيان، قد يكون الترميز اللازم لأداء وظائف النظام مُرهقًا للغاية، وتكون المكاسب المحتملة التي يُمكن أن تُوفرها النماذج الأولية ضئيلة جدًا. [ 6 ]

يُستخدم النموذج الأولي بشكل متكرر كأداة لتصميم واجهات تفاعلية متطورة بين الإنسان والحاسوب . "كان أحد أكثر استخدامات النموذج الأولي السريع إنتاجية حتى الآن هو استخدامه كأداة لهندسة متطلبات المستخدم التكرارية وتصميم واجهات التفاعل بين الإنسان والحاسوب." [ 7 ]

أسلوب تطوير الأنظمة الديناميكية

منهجية تطوير الأنظمة الديناميكية (DSDM) [ 14 ] هي إطار عمل لتقديم حلول الأعمال يعتمد بشكل كبير على النماذج الأولية كتقنية أساسية، وهي معتمدة وفقًا لمعيار ISO 9001. تُوسّع هذه المنهجية نطاق التعريفات الشائعة للنموذج الأولي. فبحسب DSDM، قد يكون النموذج الأولي مخططًا، أو عملية تجارية، أو حتى نظامًا قيد التشغيل. تهدف نماذج DSDM الأولية إلى أن تكون تدريجية، تتطور من أشكال بسيطة إلى أشكال أكثر شمولية.

قد تكون نماذج DSDM الأولية إما مؤقتة أو تطورية . ويمكن تطوير النماذج التطورية أفقيًا (من حيث العرض ثم العمق) أو رأسيًا (حيث يُبنى كل قسم بالتفصيل مع تكرارات إضافية تُفصّل الأقسام اللاحقة). ويمكن لهذه النماذج التطورية أن تتطور في النهاية إلى أنظمة نهائية.

الفئات الأربع للنماذج الأولية كما أوصت بها منهجية DSDM هي:

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

تتمثل دورة حياة نموذج DSDM الأولي فيما يلي:

  1. تحديد النموذج الأولي
  2. الموافقة على خطة
  3. أنشئ النموذج الأولي
  4. مراجعة النموذج الأولي

النماذج الأولية التشغيلية

اقترح آلان ديفيس نموذجًا تشغيليًا أوليًا كوسيلة لدمج النماذج الأولية المؤقتة والتطورية مع تطوير الأنظمة التقليدي. "إنه يوفر أفضل ما في عالمي التطوير السريع والتقليدي بطريقة منطقية. يطور المصممون فقط الميزات المفهومة جيدًا عند بناء الأساس التطوري، بينما يستخدمون النماذج الأولية المؤقتة لتجربة الميزات غير المفهومة جيدًا." [ 8 ]

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

تتبع المنهجية المحددة الخطوات التالية: [ 8 ]

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

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

تطوير الأنظمة التطورية

تطوير الأنظمة التطورية هو فئة من المنهجيات التي تسعى إلى تطبيق النماذج الأولية التطورية بشكل رسمي. وقد وصف جون كرينيون في كتابه " تطوير الأنظمة التطورية" نوعًا محددًا يُسمى " صناعة الأنظمة" .

تم تصميم Systemscraft كمنهجية "نموذجية" يجب تعديلها وتكييفها لتناسب البيئة المحددة التي تم تنفيذها فيها.

لم يُصمم برنامج Systemscraft كمنهجية جامدة أشبه بـ"وصفة جاهزة" لعملية التطوير. ومن المسلّم به الآن أن المنهجية الجيدة ينبغي أن تكون مرنة بما يكفي لتكون قابلة للتعديل لتناسب جميع أنواع البيئات والظروف... [ 6 ]

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

التطور السريع التطوري

تم تطوير Evolutionary Rapid Development (ERD) [ 15 ] بواسطة اتحاد إنتاجية البرمجيات، وهو وكيل تطوير وتكامل التكنولوجيا لمكتب تكنولوجيا المعلومات التابع لوكالة مشاريع البحوث الدفاعية المتقدمة (DARPA).

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

للحصول على آراء العملاء/المستخدمين، تُعقد اجتماعات دورية منتظمة وأخرى طارئة مع أصحاب المصلحة. كما تُجرى عروض توضيحية لإمكانيات النظام بهدف جمع الملاحظات قبل اتخاذ قرارات التصميم والتنفيذ النهائية. وتُتاح إصدارات تجريبية دورية (مثل الإصدارات التجريبية ) للاستخدام بهدف توفير رؤى حول كيفية تحسين النظام لتلبية احتياجات المستخدمين والعملاء. وهذا يضمن تطور النظام باستمرار لتلبية احتياجات المستخدمين الحالية.

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

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

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

أدوات

يتطلب الاستخدام الفعال للنماذج الأولية أن تمتلك المؤسسة الأدوات المناسبة وفريق عمل مدرب على استخدامها. تتنوع الأدوات المستخدمة في النماذج الأولية، بدءًا من الأدوات الفردية، مثل لغات البرمجة من الجيل الرابع المستخدمة في النماذج الأولية السريعة، وصولًا إلى أدوات CASE المتكاملة والمعقدة . تُستخدم لغات البرمجة المرئية من الجيل الرابع ، مثل Visual Basic و ColdFusion، بكثرة نظرًا لانخفاض تكلفتها وشهرتها وسهولة استخدامها وسرعته نسبيًا. غالبًا ما تُطوّر أو تختار المؤسسات العسكرية أو الكبيرة أدوات CASE التي تدعم تحليل المتطلبات، مثل بيئة هندسة المتطلبات (انظر أدناه). كما يجري تطوير أدوات كائنية التوجه، مثل LYMB من مركز GE للأبحاث والتطوير. يمكن للمستخدمين تصميم نماذج أولية لعناصر التطبيق بأنفسهم باستخدام جداول البيانات .

مع تزايد شعبية تطبيقات الويب، تطورت أيضاً أدوات تصميم النماذج الأولية لهذه التطبيقات. توفر أطر عمل مثل Bootstrap و Foundation و AngularJS الأدوات اللازمة لإنشاء نموذج أولي سريع . تتألف هذه الأطر عادةً من مجموعة من عناصر التحكم والتفاعلات وإرشادات التصميم التي تُمكّن المطورين من تصميم نماذج أولية لتطبيقات الويب بسرعة.

مولدات الشاشة، وأدوات التصميم، ومصانع البرمجيات

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

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

تعريف التطبيق أو برنامج المحاكاة

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

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

بيئة هندسة المتطلبات

"توفر بيئة هندسة المتطلبات (REE)، التي يجري تطويرها في مختبر روما منذ عام 1985، مجموعة أدوات متكاملة لتمثيل وبناء وتنفيذ نماذج الجوانب الحرجة للأنظمة المعقدة بسرعة." [ 17 ]

تستخدم القوات الجوية الأمريكية حاليًا بيئة هندسة المتطلبات لتطوير الأنظمة. وهي:

مجموعة متكاملة من الأدوات تُمكّن محللي النظم من بناء نماذج أولية وظيفية، ونماذج واجهة المستخدم، ونماذج أداء لمكونات النظام بسرعة. تُجرى أنشطة النمذجة هذه لاكتساب فهم أعمق للأنظمة المعقدة وتقليل تأثير مواصفات المتطلبات غير الدقيقة على التكلفة والجدولة أثناء عملية تطوير النظام. يمكن إنشاء النماذج بسهولة، وبمستويات متفاوتة من التجريد أو التفصيل، اعتمادًا على الجوانب السلوكية المحددة للنموذج قيد الدراسة. [ 17 ]

يتألف نظام REE من ثلاثة أجزاء. الأول، ويُسمى proto، هو أداة CASE مصممة خصيصًا لدعم النماذج الأولية السريعة. أما الجزء الثاني، فيُسمى نظام النماذج الأولية للواجهات السريعة (RIP)، وهو عبارة عن مجموعة من الأدوات التي تُسهّل إنشاء واجهات المستخدم. أما الجزء الثالث من REE، فهو واجهة مستخدم رسومية لنظامي RIP وproto، مصممة لتكون سهلة الاستخدام.

كان هدف شركة Rome Laboratory، مطورة برنامج REE، هو دعم منهجية جمع المتطلبات الداخلية الخاصة بها. تتكون هذه المنهجية من ثلاثة أجزاء رئيسية:

  • استخلاص المعلومات من مصادر متنوعة (المستخدمون، وواجهات الأنظمة الأخرى)، وتحديد المواصفات، والتحقق من الاتساق
  • أظهر التحليل أن احتياجات المستخدمين المتنوعين مجتمعة لا تتعارض وأنها ممكنة تقنياً واقتصادياً
  • التحقق من أن المتطلبات المستمدة بهذه الطريقة تعكس بدقة احتياجات المستخدم. [ 17 ]

في عام 1996، تعاقدت شركة Rome Labs مع شركة Software Productivity Solutions (SPS) لزيادة تحسين REE لإنشاء "REE بجودة تجارية تدعم تحديد المتطلبات والمحاكاة ونمذجة واجهة المستخدم ورسم خرائط المتطلبات على بنى الأجهزة وتوليد التعليمات البرمجية ..." [ 18 ] يُطلق على هذا النظام اسم محطة عمل هندسة المتطلبات المتقدمة أو AREW.

بيئات غير علائقية

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

PSDL

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

مراجع

  1. ↑ تود غريم: الحالة الإنسانية: مبرر للنماذج الأولية السريعة. تقنيات ضغط الوقت، المجلد 3، العدد 3. شركة التقنيات المعجلة، مايو 1998. الصفحة 1.
  2. ↑ "نمذجة البرمجيات - INGSOFTWARE" . ingsoftware.com . تم الاطلاع عليه بتاريخ 27-06-2018 .
  3. ↑ سميث إم إف، نمذجة البرمجيات: التبني والممارسة والإدارة . ماكجرو هيل، لندن (1991).
  4. ↑ ديوار، روبرت ب.ك.؛ فيشر الابن، جيرالد أ.؛ شونبرغ، إدموند؛ فروليش، روبرت؛ براينت، ستيفن؛ غوس، كلينتون ف.؛ بيرك، مايكل (نوفمبر 1980). "مترجم ومفسر لغة آدا في جامعة نيويورك". وقائع ندوة ACM-SIGPLAN حول لغة برمجة آدا - SIGPLAN '80 . المجلد 15. الصفحات 194-201 . doi : 10.1145/948632.948659 . ISBN   0-89791-030-3. S2CID 10586359 . 
  5. ↑ شركة سوفتيك (11 أبريل 1983). "تقرير ملخص التحقق من صحة مُترجم لغة آدا: NYU Ada/ED، الإصدار 19.7 V-001" . مؤرشف من الأصل بتاريخ 12 مارس 2012. تم الاطلاع عليه بتاريخ 16 ديسمبر 2010 .
  6. ١ ٢ ٣ ٤ ٥ ٦ جون كرينيون: تطوير الأنظمة التطورية، دليل عملي لاستخدام النماذج الأولية ضمن منهجية الأنظمة الهيكلية. دار بلينوم للنشر، نيويورك، ١٩٩١. صفحة ١٨.
  7. 1 2 3 إس. بي. أوفرماير: النماذج الأولية السريعة الثورية مقابل النماذج الأولية السريعة التطورية: الموازنة بين إنتاجية البرمجيات واعتبارات تصميم التفاعل بين الإنسان والحاسوب. مركز التميز في القيادة والسيطرة والاتصالات والاستخبارات (C3I)، جامعة جورج ماسون، 4400 طريق الجامعة، فيرفاكس، فيرجينيا.
  8. 1 2 3 آلان إم. ديفيس: النماذج الأولية التشغيلية: منهج تطوير جديد. مجلة IEEE للبرمجيات، سبتمبر 1992. الصفحة 71.
  9. 1 2 اتحاد إنتاجية البرمجيات: التطوير السريع التطوري. وثيقة SPC رقم SPC-97057-CMC، الإصدار 01.00.04، يونيو 1997. هيرندون، فرجينيا. الصفحة 6.
  10. ↑ ديفيس. الصفحات 72-73. نقلاً عن: إي. بيرسوف وأ. ديفيس، تأثيرات نماذج دورة حياة إدارة تكوين البرمجيات. مجلة الاتصالات ACM، أغسطس 1991، الصفحات 104-118
  11. ↑ كوماتينيني، ساتيا. "إعادة تشكيل تنفيذ مشاريع تكنولوجيا المعلومات من خلال النماذج الأولية المتطرفة" . مؤرشف من الأصل في 2016-12-06.
  12. ↑ مقتبس من: سي. ميليسا ماكليندون، لاري ريجوت، جيري أكيرز.
  13. ↑ جوزيف إي. أوربان: تصميم النماذج الأولية للبرمجيات وهندسة المتطلبات. مختبر روما، روما، نيويورك.
  14. ↑ اتحاد منهجية تطوير الأنظمة الديناميكية. https://web.archive.org/web/20060209072841/http://na.dsdm.org/
  15. ↑ مقتبس من اتحاد إنتاجية البرمجيات. PPS 10–13.
  16. ↑ كيف يمكن لبرامج المحاكاة تبسيط تطوير التطبيقات؟ رابط قديم مؤرشف بتاريخ ٢٢ يوليو ٢٠١٢ على archive.today
  17. 1 2 3 د. رامون أكوستا، كارلا بيرنز، ويليام رزبكا، وجيمس سيدوران. تطبيق تقنيات النماذج الأولية السريعة في بيئة هندسة المتطلبات. معهد مهندسي الكهرباء والإلكترونيات، 1994.
  18. ↑ شركة حلول إنتاجية البرمجيات. محطة عمل هندسة المتطلبات المتقدمة (AREW). 1996.
  19. ↑ لوكي؛ بيرزينز، ييه (أكتوبر 1988). "لغة نموذجية لبرمجيات الوقت الحقيقي" (ملف PDF) . معاملات IEEE في هندسة البرمجيات . 14 (10): 1409-1423 . doi : 10.1109/32.6186 . hdl : 10945/39162 . S2CID 35348234 . 
  20. ↑ لوكي؛ كتابجي (مارس 1988). "نظام النماذج الأولية بمساعدة الحاسوب". IEEE Software . 5 (2): 66–72 . doi : 10.1109/52.2013 . hdl : 10945/43616 . S2CID 15541544 . 
  21. ↑ لوكي (مايو 1989). "تطور البرمجيات من خلال النماذج الأولية السريعة" . مجلة IEEE Computer . 22 (5): 13-25 . doi : 10.1109/2.27953 . hdl : 10945/43610 . S2CID 1809234 .