fighters

هل تريد التفاعل مع هذه المساهمة؟ كل ما عليك هو إنشاء حساب جديد ببضع خطوات أو تسجيل الدخول للمتابعة.
fighters

    الحلقه الأولى : صنعة البرمجيات ضد هندسة البرمجيات

    fighter
    fighter
    الـمـديـرالـعـام
    الـمـديـرالـعـام


    عدد الرسائل : 226
    العمر : 34
    مزاجى : الحلقه الأولى : صنعة البرمجيات ضد هندسة البرمجيات 463436386
    تاريخ التسجيل : 16/04/2008

    الحلقه الأولى : صنعة البرمجيات ضد هندسة البرمجيات Empty الحلقه الأولى : صنعة البرمجيات ضد هندسة البرمجيات

    مُساهمة من طرف fighter الأربعاء أبريل 30, 2008 6:10 pm


    كتاب Software Craftsmanship, The New Imperative هو كتاب تم وضعه من فترة في المنتدى لكني لم أجد الرابط له

    الكتاب
    اكثر من رائع و عندما بدأت في قراءته وجدته مسلي جداً بالرغم انه ليس موجه
    للمبرمجين و لكن للمدراء و صناع القرار في شركات البرمجة و يكفي اني قرأت
    منه 6 فصول في جلستين..
    لكي احصل على اقصى افادة منه قررت البدء في تلخيصه فوراً..

    الكتاب
    يتناول نظرة مختلفة للبرمجة هي software craftsmanship او صنعة(حرفة)
    البرمجيات في مقابل الsoftware engineering او هندسة البرمجيات.

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

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

    3. تعتمد
    هندسة البرمجيات على وضع التصميم كاملاً على الورق قبل العمل بينما يرى ان
    عملية التصميم ستكون افضل اذا صاحبها التكويد و الاختبار بصورة مستمرة
    بحيث تصل الى التصاميم النهائية و البرنامج في وقتين متقاربين. بالمناسبة
    هذا التصور جعل الكثيرون من المبرمجين يتبنون صنعة البرمجيات فور ظهورها
    لان التكويد من وجهة نظرهم هو افضل الطرق لتوضيح الافكار و ليس مجرد
    تصاميم على الورق.

    4. هندسة البرمجيات تقوم بالفصل بين الادوار
    المختلفة في عملية التطوير يعني هناك محللي النظام analysts و المصممين
    logic designers و المكودين programmers و حتى المكودين هناك الاختبار
    testing و الصيانة maintenance و غيرها.. ستجد ان من يحلل النظام ليس هو
    من يكتب الكود و ان من يكتب الكود ليس هو من يقوم بعملية الصيانة. هندسة
    البرمجيات تفسر ذلك باهمية التخصص و ان شخصاً واحداً لا يمكنه تغطية نظام
    باكمله.
    اما صنعة البرمجيات فتعتمد على التداخل و كلنا نعلم ان افضل من
    يقوم بعملية الصيانة هو من كتب الكود في البداية مهما كانت جودة التوثيق و
    وضوح الكود. و تعارض هندسة البرمجيات بأن صنعة البرمجيات تصر على ان مبرمج
    واحد يمكنه استيعاب و فهم نظام بأكمله و في ذلك توفير وقت و مجهود رهيبين
    كانوا يضيعون في هندسة البرمجيات لنقل المعلومة عبر الاوراق و المستندات
    من مهندس لاخر.
    فمثلاً مشاريع المصدر المفتوح او open source تجدون ان
    بداية المشروع تكون دائماً مجموعة صغيرة تقوم بجميع الادوار و الناتج
    النهائي لهذه المجموعة الصغيرة يكون مشروعاً مميزاً يجذب الكثير من
    المتطوعين اليه.. لكن تظل دائماً عملية الصيانة لقلب المشروع هي مهمة هذه
    المجموعة الصغيرة و بالتالي فان الصيانة هنا هي شهادة بجودة المبرمج اما
    في هندسة البرمجيات فتجد من الشائع ان يقوم بالصيانة اجدد المنضمين..
    لذلك فصنعة البرمجيات اقل تأثراً بمراحل في حالة رحيل احد المطورين مهما كانت اهميته لان النظام اولاً و اخيراً معروف من الجميع.
    سيناريو
    آخر هو تعديل متطلب من متطلبات النظام.. هذا التعديل رغم كونه شائع جداً
    في السوق لكنه يعتبر كابوس في هندسة البرمجيات.. لأن عملية التعديل تتطلب
    التعديل في مئات المستندات و الأوراق من محللي النظام ثم تمرير هذه
    المستندات إلى المصممين الذين يقومون بدورهم بالبحث عن التغييرات الواجبة
    في تصاميمهم و إعادة صياغة مستنداتهم و تمريرها إلى المكودين.. و حتى في
    هذا المرحلة ففرق الاختبار ستبذل مجهود مضاعف لمعرفة ما هي المناطق في
    البرنامج الذي لم يشاركوا في كتابته التي ستسبب أخطاء بسبب الكود الجديد
    الذي لم يشاركوا في كتابته أيضاً. و بالتالي تميل هندسة البرمجيات الى
    تجميد المتطلبات بمجرد الموافقة عليها.
    أما في صنعة البرمجيات فعملية
    تغيير المتطلبات أسهل بكثير لأن جميع اعضاء الفريق يلمون بالنظام تماماً و
    ليس هناك الحاجة لاعادة كتابة و تعديل مئات المستندات الورقية قبل البدء
    في العمل.. بل على العكس فإن صنعة البرمجيات تعتمد تماماً على إعادة تحديد
    المتطلبات بصورة دائمة حسب ما يراه المستخدمون .. ثم عند الحاجة لتعديل شئ
    ما فالمستخدم يشير الى البرنامج الذي لديه و يحدد التغييرات التي يريدها.

    5.
    تعتمد هندسة البرمجيات على خرافة : "مقاس واحد يناسب الجميع" و تصل
    للمثالية اذا استطعت ان تطور كل برامجك فقط بالتوصيل بين مكونات تم
    تطويرها لديك من قبل. لكن عملية إعادة الاستخدام نفسها صعبة للغاية الا
    اذا كنت تحصل على بعض هذه المكونات من شركات اخرى كنظام قواعد بيانات من
    اوراكل و نظام لتنصيب برامجك من Setup factory و هكذا..
    أحد المشاكل
    التي تواجه اعادة الاستخدام هي ان الهاردوير نفسه يتطوّر سريعاً جداً و
    بمعدل الضعف كل 18 شهر و بالتالي المكون الذي استخدمته من 5 سنوات على
    جهاز 300 ميجاهرتز و ويندوز 98 لن يكون مناسباً على الاطلاق لجهاز 2 جيجا
    هرتز و ويندوز xp .
    مثال: سبب فشل رحلة الفضاء آريان 5 كان اعادة
    استخدام نظام آريان 4 الناجح جداً.. هل تعرفون ماذا كانت المشكلة؟ المشكلة
    هي ان متغير جديد تمت اضافته للنظام من نوع Number 64 bits سبب خطأ
    overflow عند تحويله الى متغير من نوع Number 16 bits و الذي كان مناسباً
    للهاردوير الخاص بآريان 4 .

      مواضيع مماثلة

      -

      الوقت/التاريخ الآن هو الخميس مارس 28, 2024 9:37 am