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

في هذه السلسلة رح نتعرف أكثر على أشهر هذه الإطارات وميزاتها

#برمجة #هندسة_البرمجيات #swe https://t.co/TCNMPxW4F4

في نهايات القرن الماضي .. كانت أغلب إطارات التطوير تنتمي للـ plan-driven models وأشهرها طبعاً الـ waterfall model .. واللي يركز بشكل أساسي على تقسيم حياة تطوير السوفتوير إلى عدة مراحل منفصلة تماماً بحيث ما تبدأ أي مرحلة جديدة بدون الانتهاء من المرحلة القديمة بشكل كلي

تتمحور الـ plan-driven models حول نقطتين أساسية .. الأولى (من إسمها) ممكن تلخيصها بعبارة مشهورة وهي

(plan your work .. work your plan)

بمعنى لازم تركز بشكل مكثف على عملية الـ planning بحيث تطلع بخطة تشمل المرحلة اللي رح تشتغلوا عليها بالكامل من بدايتها وحتى نهايتها https://t.co/LyGX2SQBUW

النقطة الثانية هي الـ documentation .. واللي يعتبر أهم النقطتين .. الـ waterfall model يقدس شي إسمه documentation وإنه لازم يكون عملك منظم ومدروس .. بحيث قبل ما تبدأ تشتغل على المرحلة الأهم وهي مرحلة البرمجة .. يكون عندك نظرة شاملة على السوفتوير من عدة جوانب مهمة

الكلام هذا جميل .. لكن بدأت تظهر مشاكل الـ waterfall model لما بدأنا نحسب تكلفة إضافة أو تغيير requirement معين حتى لو كان بسيط .. لأنه هذا التغيير رح يكلفك أكثر كونه رح يرجعك للبداية وتضطر على الأقل تعيد دراسة الـ components اللي رح تتأثر بإضافة هذا الـ requirement