نبدأ بسؤال بسيط ما هو ال Software
الإجابة سهلة : هو برنامج
النتيجة : الإجابة خطأ
البرنامج هو Program ، أما ال Software فله قصة أخرى.
في منتصف القرن الماضي وحينما كان المبرمجون يسيطرون على العالم، كانت تواجههم مشاكل جمة.
السبب أن علم الحاسوب وصناعة البرامج ما زال علما طازجا، ومن يقوم على البرمجة هم علماء الرياضايات، وكانوا يتعاملون مع البرنامج بمنطق علمي بحت.
هذه المشاكل يمر بها اليوم بعض المبرمجون، وملخصها يكمن في أن المبرمج يعتبر Software عبارة عن كود فقط، وأثناء عمله، تجده يغير عشرات المرات على الكود، ولربما ينتهي من البرمجة فيجد نفسه أنه صنع برنامج لا دخل له بما طلبه العميل، فالعميل في واد وما فهمه المبرمج في واد آخر.
وحتى في المستقبل في حالة صيانة وتطوير البرنامج، يكون الأمر صعبا، لأن المبرمج لم يأخذ الأمر بالحسبان، كان عليه فقط أن يكتب كود، ولو أتى مبرمج من بعده فلن يفهم شيء مما كتبته المبرمج السابق، لأن المبرمج السابق كان يعمل من نسج خياله … إلخ إلخ إلخ
من هنا كان لا بد من ولادة هندسة البرمجيات
هندسة البرمجيات، بالمختصر المفيد، هي علم يدرس كيف نصنع Software بخطوات علمية دقيقة، لإخراج ال Software بأبهى صورة وحسب المطلوب، وذلك مرورا بمفاهيم وعمليات معينة.
قرر مهندسوا البرمجيات أن ال Software ليس مجرد برنامج ، ولكنه نظام بمعنى أوسع، له العديد من الأجزاء، لعل آخرها هو الكود، ولربما لا يكون الكود منها أحيانا.
فقبل عملية بدء البرمجة، يجب أن يكون هنالك فترة جمع المتطلبات، وفهمها وتحليلها، وكتابتها، ومراجعتها … إلخ
وهذه تسمى عملية التوثيق Documntation ، وهي أساسية في دورة حياة صناعة البرنامج أو النظام، فبدونها سيعمل المبرمج أي كلام، وسيكتب كود قد لا يكون مناسب للمشكلة القائمة.
أيضا هنالك عملية إدارة المشروع Management، وتحديد وقت البداية ووقت النهاية والمدخلات والموارد.
ومن تحديد الموارد، هنالك الموارد البشرية، واختيار الفريق، سواء كان المبرمجين أو المصممين، أو محللي النظام … إلخ.
أيضا هنالك عدة آليات أثناء كتابة الكود، وبعد كتابته مثل Quality Assurance ، و عملية الاختبار Testing ، أيضا حتى بعد تسليم المشروع هنالك فترة الصيانة، والتي تعتبر من ضمن الSoftware
إذا ما هو ال Software
هو مجموع كل من التوثيق، وإدارة المشروع، والكود، وفحص الجودة والكفاءة، وكافة الاختبارات، وفترة الصيانة
وهذا أدى بدوره إلى بزوغ عصر جديد في البرمجة، أدى لإنتاج هذه البرمجيات الضخمة بشكل خيالي وأيضا بشكل ناجح جدا.
قام مهندسوا البرمجيات، بوضع خطط وآليات حول كيفية سير ال Software ( سأطلق عليه الآن البرنامج )
وهذه الخطط لضمان النجاح الأمثل لدورة حياة البرنامج، وتضمنت العديد من الآليات والنماذج.
سميت هذه الآليات بالنماذج Models ، بها خطة دقيقة وعمليات معينة يجب أن يسير عليها المشروع لضمان نجاحه
لكي لا أطيل، قام المهندسون بوضع بنموذج لإتمام العمل اسمه الشلال waterfall ، هذا النموذج ينص على بعض المفاهيم منها
– يجب كتابة المتطلبات مسبقا قبل البدء بأي خطوة
– يجب مراجعة المتطلبات وتوثيقها بشكل دقيق
– يجب تصميم النظام قبل بدء برمجته
– البدء بعد ذلك بعملية البرمجة
– مراجعة البرمجة وفحصها
– مرحلة الصيانة، وفي حال وجود أخطاء هامة، ندخل في دورة جديدة جديد تشبه السابقة.
هذا النظام كان طفرة، إلا أنه حين تطبيقه على أرض الواقع، واجه عدة عقبات، منها أن كل مرحلة من مراحل هذا النموذج تستغرق وقت، فمرحلة جمع البيانات وتوثيقها قد تستغرق 3 شهور، وحينما نبدأ بالبرمجة، قد نستغرق 6 شهور مع إجراء الاختبارات.
وهذا يعني أنه قد يمر 10 شهور لكي نرى البرنامج جاهز وقبل بدء العمل عليه.
قد يكون خلال ال 10 شهور، تغيرت متطلبات البرنامج، وكان يجب إضافة عمليات أو حذفها من البرنامج، هنا يجب أن نمر بالعملية من جديد، ونستغرق مدة لا بأس بها لتعديل البرنامج، ومن ثم تظهر ضرورة لتعديل جزئية فنعود في دوامة مغلقة، فيقول المدير بعد أن يشد شعره، عودوا للعمل الورقي أرحم.
هنا ظهرت لدى مهندسي البرمجيات، ضرورة ملحة بوجود نماذج عمل أخرى تحاكي مشاريع معينة
مثلا نموذج الشلال مفيد جدا لإنتاج مشروع بناء جسر أو سد، فبناء الجسر أو السد يمر بمراحل الشلال بشكل كامل، فأنت بعد بناء السد ب 100 عام لن يلزمك إضافة أجزاء إضافية، فلو جلست في جمع المتطلبات 3 أعوام لا مشكلة، لأنك لن تعدل عليها.
حينما تعمل برنامج لشركة محاسبية صغيرة، يجب أن تتوقع بعد عامين ستكبر الشركة، وبالتالي سيقومون بإجراء تعديلات على برنامجهم من جديد ليوافي متطلباتهم، وحينما يجب أن تقوم بتعديل التطبيق كل فترة وفترة، وقد تكون الفترة هذه أشهر قليلة، فلن ينفعك السير بنموذج الشلال كثيرا.
قام المهندسون بابتكار نماذج كثيرة ومتنوعة، منها الحلزوني ، ومنها .. ومنها، وكان منها صديقنا ال Agile الذي سأتكلم عنه في مقال منفصل
