Get best of the week

تغيير متطلبات المشروع هو قضية تطوير البرمجيات الرئيسية


خطوات تطوير برنامج كمبيوتر كبير لتسليمه إلى العميل

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

نقوم بتطوير برامج لتلبية احتياجات أي عميل أو مستخدم أو سوق. تتمثل مهمة هندسة البرمجيات كمجال لعلوم الكمبيوتر في جعل هذا التطور متوقعًا وفعالًا من حيث التكلفة.

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

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

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

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

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

المتطلبات تتغير. سيواجه كل مشروع تطوير برامج في هذه المرحلة هذه المشكلة الصعبة.

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

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

محاذاة العملية مع البيئة


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

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

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


لا تقتصر هذه العملية على الخطوات المتتالية. توضيح من مقال بقلم وينستون رويس

الواقعية في تطوير البرمجيات


بمجرد أن نقبل أن تطوير البرمجيات متأصل دائمًا في حالة عدم اليقين من أن المتطلبات لا تتغير أبدًا لفترة طويلة ، يمكننا أن نبدأ في تطوير طرق للتعامل مع التغييرات الحتمية.

ابدأ بقبول أن التغيير أمر لا مفر منه .

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

نتيجة لذلك ، لا ينتهي البرنامج أبدًا ، ولكن يتم التخلي عنه فقط .

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

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

تغيير العملية لتناسب البيئة


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

لا ، هذا ليس حول ذلك. أطروحتنا هي أنه يمكننا أن نصبح مطورين فعالين للغاية إذا أخذنا في الاعتبار الحقائق.

الحقيقة الأولى: على الرغم من أن الكمال في حد ذاته لا يمكن تحقيقه ، إلا أن النجاح الواقعي ممكن تمامًا. جعلت حركة بدء التشغيل LEAN هدفًا مشتركًا للشركات الناشئة MVP ، "الحد الأدنى من المنتجات القابلة للتطبيق". يجب أن نوسع هذه الفكرة إلى جميع التطورات ونقر بأن كل منتج هو في الواقع أفضل منتج - أفضل حل تقريبي لدينا لفهم المشكلة الحالي.

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

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

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

يأتي التطوير الرشيق لإنقاذ


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

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


More articles:


All Articles