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

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

لمحة عامة

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

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

يمكن تعريف المشروع في إدارة المشاريع حسب كل من دورة حياة المشروع (بّي إل سي) ودورة حياة تطوير الأنظمة حيث تحدث نشاطات مختلفة شيئًا ما. حسب تايلور (2004): «تحيط دورة حياة المشروع بكل نشاطات المشروع، بينما تركز دورة حياة تطوير الأنظمة على تحقيق متطلبات المنتج».[5]

تستخدم دورة حياة تطوير الأنظمة (إس إل دي سي) خلال تطوير مشروع تقنية معلومات (مشروع آي تي)، تصف الدورة المراحل المختلفة للمشروع من لوح الرسم وحتى إنهاء المشروع.

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

التاريخ والتفاصيل

تصف دورة حياة المنتج عملية بناء أنظمة المعلومات بطريقة مقصودة ومنهجية ومحددة الهيكلية، بإعادة تكرار كل مرحلة من حياة المنتج. بدأت دورة حياة تطوير الأنظمة، وفقًا لإليوت وستراتشان ورادفورد (2004) «في ستينيات القرن العشرين، لتطوير أنظمة أعمال عملية على نطاق كبير في عصر التكتلات الكبيرة للشركات. تمحورت أنشطة أنظمة المعلومات حول إجراءات روتينية ثقيلة لمعالجة البيانات ومعالجة الأعداد».[7]

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

تحليل غرضي التوجه

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

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

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

بعض أدوات الدخل التقليدية (ولكن هذا لا يعمم على كل أنواع التحليل التصميمي) للبرمجة غرضية التوجه:

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

دورة حياة تطوير برمجيات يسِّر

تتضمن مجموعة من الإجراءات والأساليب الخاصة بدورة حياة تطوير البرمجيات SDLC والتي حددها وطبقها برنامج «يسِّر» في كل المشاريع والبرمجيات ذات العلاقة داخل البرنامج. وتهدف دورة حياة تطوير البرمجيات SDLC لتفصيل الإجراءات والأساليب المتبعة لحوكمة وضبط عمل فريق تطوير البرمجيات في برنامج «يسِّر»

ويساعد تنفيذ دورة حياة تطوير البرمجيات SDLC على تحقيق عدد من النتائج الإيجابية كما يلي:

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

نظرة عامة عن أهميتها

بدون نموذج SDLC لاتباعه، المطورون لديهم الحرية لتطوير البرمجيات، يوجد العديد من البرامج التي تم برمجتها برؤية احتياجية عوضا عن اتباع نموذج معين. كل ما يحتاجوه هو خطة عمل تخدم النموذج الذي سيتم بناء البرنامج من خلاله.

و مع ذلك، تطوير هذه البرمجيات لا يمتلك رؤية واضحة ولا يمكن ان يكون قابل للتطبيق في نموذج العمل.

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

مراجع
  1. SELECTING A DEVELOPMENT APPROACH. Retrieved 17 July 2014. نسخة محفوظة 19 ديسمبر 2019 على موقع واي باك مشين.
  2. Parag C. Pendharkara؛ James A. Rodgerb؛ Girish H. Subramanian (نوفمبر 2008)، "An empirical study of the Cobb–Douglas production function properties of software development effort"، Information and Software Technology، 50 (12): 1181–1188، doi:10.1016/j.infsof.2007.10.019.
  3. "Systems Development Life Cycle from"، FOLDOC، مؤرشف من الأصل في 19 أغسطس 2017، اطلع عليه بتاريخ 14 يونيو 2013.
  4. "Software Development Life Cycle (SDLC)"، مؤرشف من الأصل في 30 مارس 2019.
  5. Taylor, James (2004)، Managing Information Technology Projects، ص. 39.
  6. "What is Scrum?"، 24 ديسمبر 2019، مؤرشف من الأصل في 9 نوفمبر 2020.
  7. Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology. p.87.
  • بوابة تقنية المعلومات
  • بوابة علم الحاسوب
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.