تشير التقديرات إلى أن هناك أكثر من 11 مليون مطور برمجيات محترف في جميع أنحاء العالم اعتبارًا من عام 2014. عندما بدأت العمل كمبرمج في عام 1973 ، قدم لي أحد أصحاب اللحية الرمادية في الشركة الأولى التي عملت بها بعض النصائح. قال: تعلم الأشياء التي لا تتغير.
عندما بدأت دراستي الجامعية قبل ست سنوات في عام 1967 ، لم يكن لدى المدرسة التي التحقت بها تخصص يسمى علوم الكمبيوتر ، ولذا فقد قمت بعملي الجامعي والدراسات العليا في الرياضيات مع أخذ بعض دورات برمجة الكمبيوتر على طول الطريق. كانت هذه هي الطريقة التي بدأ بها الكثير منا كمطورين برمجيات في السبعينيات.
كان مصطلح هندسة البرمجيات جديدًا في ذلك الوقت ، حيث تمت صياغته في مؤتمر الناتو لهندسة البرمجيات عام 1968. كان التفكير في ذلك الوقت هو أننا بحاجة إلى تطبيق الأساليب الهندسية الحالية لتطوير البرمجيات لمعالجة الميزانية المشتركة والجدول الزمني ومشاكل الجودة التي كان يشار إليها في ذلك الوقت باسم “أزمة البرامج”. نتيجة لذلك ، فإن ما يعتقده معظم الناس على أنه هندسة برمجيات يتضمن أنشطة تشبه إلى حد كبير التخصصات الهندسية الأخرى بما في ذلك الهندسة المدنية والميكانيكية والكهربائية.
على السطح ، يبدو أن هذه الفكرة منطقية. عندما تقوم ببناء شيء ما باستخدام التخصصات الهندسية الأخرى (مثل جسر ، مبنى ، قطعة متخصصة من الأجهزة ، لوحة دوائر كهربائية) ، فإنك تحتاج إلى معرفة المتطلبات ، وتصميم حل ، وتنفيذه ، واختباره. كل هذه الخطوات منطقية بالنسبة للبرنامج أيضًا. لذلك يمكن للمرء أن يجادل بالتأكيد من هذا المنظور أن هندسة البرمجيات يجب أن تشبه هذه التخصصات الهندسية الأخرى. ومع ذلك ، عندما تنظر عن كثب إلى ما تعلمناه عن تطوير البرمجيات على مدار الأربعين عامًا الماضية ، وكذلك كيف نعلمه لمطوري البرمجيات اليوم ، فإن هذا القياس ينهار بسرعة.
بحلول الوقت الذي بدأ فيه التسعينيات ، نظرًا لأن برمجة الكمبيوتر أصبحت جزءًا كبيرًا مما كان يسمى علوم الكمبيوتر ، أضافت العديد من الجامعات مقررًا بعنوان “هندسة البرمجيات” إلى مناهج علوم الكمبيوتر الخاصة بهم. تضمنت الكتب المدرسية الشائعة التي تم استخدامها في ذلك الوقت لتدريس هذه الدورات كتاب إيان سومرفيل بعنوان: “هندسة البرمجيات”. من عام 1992 إلى عام 1994 ، استخدمت الإصدار الرابع من هذا الكتاب المدرسي لتدريس هندسة البرمجيات في جامعة بينغهامتون. اليوم ، لا يزال كتاب Ian Sommerville قيد الاستخدام في العديد من الجامعات حول العالم – الآن في نسخته التاسعة. هذا يقودنا إلى سؤال:
لماذا نحتاج إلى مراجعة كتاب مدرسي كل 3-4 سنوات تقريبًا والذي من المفترض أنه يعلم طلابنا أساسيات هندسة البرمجيات؟
إذا نظرت إلى الكتب المدرسية المستخدمة في الهندسة المدنية والهندسة الميكانيكية والهندسة الكهربائية ، فإن الغالبية العظمى من هذه الكتب لا تتطلب مراجعات في كثير من الأحيان. لفهم سبب هذه الحالة ، نحتاج إلى إلقاء نظرة فاحصة على ما يتم تدريسه في معظم الجامعات حول العالم تحت اسم “هندسة البرمجيات”.
عندما تنظر عن كثب ، ستجد أننا ندرس الجيل القادم من محترفي البرمجيات كل ما هو شائع حاليًا من حيث ممارسات وأساليب البرامج. تُعرف ممارسات وأساليب البرامج الشائعة اليوم بالكلمات الطنانة مثل Agile و Use Cases و User Stories و RUP و XP و Scrum Lean و PSP و TSP والقائمة تطول وتطول …
تكمن مشكلة هذا النهج في تدريس هندسة البرمجيات في أن ممارسات وأساليب البرمجيات تأتي وتذهب كثيرًا وستستمر في الظهور والذهاب ولهذا السبب يجب على Sommerville تحديث كتابه المدرسي باستمرار. هذا يقودنا إلى سؤال آخر:
ماذا عن تلك اللحية الرمادية في أول شركة عملت بها في عام 1973 والتي طلبت مني تعلم الأشياء التي لا تتغير أبدًا؟ هل قدم لي نصيحة سيئة؟ إذا لم يكن الأمر كذلك ، فما الذي ندرسه لجيلنا القادم من محترفي البرمجيات فيما يتعلق بالأشياء التي لا تتغير أبدًا في هندسة البرمجيات؟
قبل الإجابة على هذه الأسئلة ، دعنا نتراجع أولاً ونطرح بعض الأسئلة المختلفة:
هل توجد بالفعل مجموعة من الأشياء التي لا تتغير أبدًا في هندسة البرمجيات؟
إذا كانت موجودة ، فهل نعرف ما هي؟
إذا كنا نعرف ماهيتهم ، فهل نقوم بتدريسهم بطريقة متسقة للجيل القادم من محترفي البرمجيات ، لذلك عندما يخرجون من الجامعة يكونون مستعدين للتصرف كمحترفين برمجيات؟
هذه المجموعة من أساسيات هندسة البرمجيات موجودة بالفعل. وقد دفع هذا الاعتقاد مجموعة دولية من المتطوعين لتولي مهمة تدوين تلك الأساسيات. القصد من تعليم هذه الأساسيات لجيلنا القادم من مطوري البرامج للمساعدة في إعدادهم كمحترفين برمجيات حقيقيين.
المتطوعون المشاركون في هذه المبادرة (المعروفة باسم SEMAT – طريقة ونظرية هندسة البرمجيات) يعملون على هذه المهمة منذ عام 2010. في العام الماضي ، حقق SEMAT إنجازًا كبيرًا بإعلان مجموعة إدارة الكائنات ، وهي مجموعة معايير دولية ، أنها اعتمدت “الجوهر” كمعيار OMG رسمي.
هذا يقودنا إلى بعض الأسئلة الأخرى:
ما مدى اختلاف معيار Essence عما يتم تدريسه لمطوري البرمجيات لدينا اليوم ، وما هو مدى الاختلاف بين معيار Essence وما تم تدريسه على مدار الأربعين عامًا الماضية تحت اسم هندسة البرمجيات؟
و:
هل ستساعد الاختلافات حقًا في حل المشكلات التي يعتقد الكثيرون أنها لا تزال تبتلي بها صناعة البرمجيات فيما يتعلق بالميزانية المشتركة وجدولة التجاوزات وجودة البرامج الرديئة؟
من منظور واحد ، ما تلتقطه Essence ليس جديدًا. يتضمن معيار Essence كلمات شائعة مثل ، أصحاب المصلحة ، والفرصة ، والمتطلبات ، ونظام البرنامج ، والفريق ، والعمل ، وطريقة العمل. ولكن من منظور آخر ، فإن ما تلتقطه Essence جديد تمامًا. في الواقع ، يسميها البعض “نقلة نوعية” سيجد الكثير من “الحرس القديم” صعوبة كبيرة حتى في فهمها.
لإعطائك فكرة عن التغييرات التي تم إجراؤها عند استخدام Essence ، أفكر مرة أخرى في أيامي الأولى كمبرمج في أواخر السبعينيات. في تلك الأيام عملت في مجال محاكاة الطيران على تطوير أنظمة برمجية لتدريب الطيارين على قيادة طائرات عالية الأداء. كان أحد مجالات خبرتي هو كتابة البرامج لتوفير إمكانيات التسجيل / التشغيل لمساعدة المدربين في تدريب طياري الطائرات الشباب على مهارات الطيران.
أتذكر مشروعًا واحدًا محددًا عملت عليه ومدربًا رائدًا للعملاء عملت معه. بعد أن أوضح له كيف يمكنه استخدام برنامج التسجيل / التشغيل الخاص بي لمساعدته على أن يوضح للطيارين الطلاب الذين ارتكبوا الأخطاء ، كتب بحماس عددًا من العيوب طالبًا بإجراء تغييرات على برنامجي.
جادلت بشدة مع مدير البرنامج الذي أتعامل معه أن أيا من هذه القضايا لم يكن في الواقع عيوبًا. نظرًا لأنني استغرقت وقتًا لشرح ما كان ممكنًا باستخدام برنامج التسجيل / التشغيل الخاص بي ، بدأ المدرب التجريبي في تصور ميزات إضافية يمكن أن تجعل وظيفته أسهل. لقد كتب أفكاره على شكل خلل على الرغم من أنها كانت جميعها قدرات محسّنة لم نخطط لتقديمها مطلقًا ولم تكن جزءًا من المتطلبات.
لكن مدير مشروعي لا يريد أن يناقش مع العميل ما إذا كانت هذه الطلبات في النطاق أو خارج النطاق أم لا. كانت وجهة نظره – كما هو الحال مع العديد من البرامج التي تم عرضها في ذلك الوقت ولا تزال تعرضها اليوم – أنه من الأسهل تغيير البرامج بدلاً من إشراك العميل في مناقشة.
نظرًا لأن البرامج ناعمة ، فإننا نميل إلى رؤيتها على أنها سهلة التغيير. إنها ليست مثل الأجهزة. لا يتم ثني المعدن بسهولة. يغير هذا المنظور اللعبة بأكملها عندما يتعلق الأمر بالبرمجيات.
هذه القدرة على تغيير رمز البرنامج بسرعة وبطرق لا نهاية لها تغير تمامًا الديناميكيات الموجودة بين مطوري البرامج وأصحاب المصلحة بما في ذلك مديري البرامج والعملاء. تتمثل إحدى الطرق التي يجسد بها هذا الاختلاف في نفسه في أنه عندما يصبح المستخدمون على دراية بالبرنامج ، فإنهم غالبًا ما يرون طرقًا جديدة يمكن أن تؤدي بها التغييرات التي تطرأ على البرنامج إلى تسهيل عملهم كما فعل معلمي التجريبي في أواخر السبعينيات.
نحن نعلم الآن من التجارب أن هناك أبعادًا أخرى لهندسة البرمجيات والتي تعتبر بالغة الأهمية لممارسات هندسة البرمجيات الاحترافية الفعالة. تأخذنا هذه الأبعاد الأخرى إلى ما هو أبعد من مجرد سهولة تغيير الكود. حتى الآن ، لم تتلق هذه الأبعاد الإضافية في أي مكان بالقرب من الاهتمام الذي تستحقه.
عندما تقوم بتغيير الرمز ، فقد تؤثر أيضًا على المتطلبات ، وقد تؤثر أيضًا على إمكانيات أخرى في نظام البرنامج الذي تم اختباره مسبقًا. تغيير الكود يعني عملًا إضافيًا ، واختبارًا إضافيًا ، وربما تغييرات في أدلة المستخدم الداعمة وما إلى ذلك … كل هذا يؤثر على الميزانية والجدول الزمني ، ويقدم مخاطر إضافية على جودة البرنامج.
بينما تجلب القدرة على تغيير رمز البرنامج قوة كبيرة لصناعة البرمجيات من ناحية ، فهذا يعني أيضًا أن محترفي البرمجيات يجب أن يكونوا أكثر انسجامًا مع طريقة عملهم المتفق عليها ، والتأثير والوقت الذي يستغرقونه للقيام بالعمل الإضافي ، والمخاطر عند إجراء تغييرات سريعة غير مخطط لها. قدمت الحركة الرشيقة على مدى السنوات العشر الماضية خدمة رائعة لمساعدة مجتمع البرمجيات على فهم هذا الاختلاف الكبير المتعلق بهندسة البرمجيات بما في ذلك أهمية التفاعل المبكر والمستمر مع أصحاب المصلحة وأهمية تقدير مطوري البرمجيات لتكلفة عملهم.
بينما تعلم مجتمع هندسة البرمجيات الكثير من التخصصات الهندسية الأخرى ، فقد تعلموا أيضًا الأهمية الحاسمة لهذه الأبعاد الأخرى التي تحدث اختلافات عن الخبرات الهندسية السابقة. تعني هذه الاختلافات أن مطوري البرامج يحتاجون إلى التدريب بطرق جديدة ومختلفة ليكونوا محترفين برمجيات فعالين.
بعد وقت قصير من بدء مبادرة SEMAT في مارس 2010 ، أرسل لي أحد الموقعين الأوائل على SEMAT نسخة مسودة من كتاب كان يعمل على مراجعته. أصيب واتس همفري الذي كان يخطط ليكون نشطًا جدًا في أعمال SEMAT المبكرة بالمرض تمامًا كما كان يستعد عمل SEMAT وطُلب مني مساعدته في مواصلة جهوده المخطط لها. في أواخر أغسطس من نفس العام ، أرسل لي واتس الرسالة الإلكترونية التالية قبل أشهر قليلة من وفاته. وافق على أنه يمكنني مشاركة هذا البريد الإلكتروني مع الآخرين:
بول ، من تعليقاتك ، يبدو الأمر كما لو أنك فهمت الهدف من كتابي ، والذي أنا ممتن له …. الإجابة الصحيحة والإجابة التي كنت مهتمًا بمتابعتها مع SEMAT ، تتعلق بكيفية ضمان ذلك يتم تدريب محترفي البرمجيات بشكل صحيح ولديهم مجموعة مناسبة من المواقف والمهارات المهنية قبل أن يصلوا إلى الصناعة. آمل أن تتمكن جهود SEMAT في النهاية من قيادة الدافع لجعل المجتمع الأكاديمي يعيد تركيز برامجهم على محترفي البرامج التعليمية للعمل كمحترفين وإدارة أنفسهم.
عندما يفعلون ذلك ، سيكون خريجوهم قادرين على التفاوض مع إدارتهم والقيام بعمل متفوق …. هذا ما يجب أن يفعله المحترفون … البداية الجيدة في هذا الاتجاه هي إقناعهم بضرورة وجود أشخاص برمجيات قياس عملهم. نظرًا لأن عمل البرامج ، كما قلنا ، هو عمل معرفي ، فإن أي تدابير دقيقة حقًا يجب أن يتخذها متخصصو البرمجيات أنفسهم. … واتس همفري
تمت الإشارة إلى واتس همفري على أنه والد جودة البرمجيات. بعد أن أكمل مسيرته المهنية المتميزة في شركة IBM ، أصبح زميلًا في معهد هندسة البرمجيات مؤسسًا لبرنامج عملية البرمجيات. في عام 2003 حصل على الميدالية الوطنية للتكنولوجيا.
اليوم ، كان من الممكن أن يثلج واتس عمل SEMAT الجاري في المجتمع الأكاديمي. تم تطوير أول دورة جامعية كاملة بناءً على معيار Essence الجديد ويتم تقديمها للطلاب هذا العام من قبل الدكتور كارلوس زاباتا في جامعة Nacional de Columbia في ميديلين ، كولومبيا ، ويتم استخدام Essence في السنة الأولى والثانية دورات هندسة البرمجيات في KTH Royal Institute of Technology في السويد بتوجيه من الدكتورة Mira Kajko-Mattson. كانت هناك أيضًا دراسات ميدانية من Essence أجرتها الدكتورة سيسيل بيريير في جامعة كارنيجي ميلون ويست في الولايات المتحدة مع الطلاب. تتمثل الخطوة التالية لمجتمع SEMAT في توضيح كيف يمكن أن تساعد Essence في الصناعة من خلال نشر دراسات الحالة للاستخدام الفعلي والنتائج المقاسة في المشاريع الصناعية.
