تاريخ هندسة البرمجيات
تطورت كتابة البرمجيات منذ بدايتها في الستينيات إلى مهنة تهتم بأفضل طرق زيادة جودة البرمجيات وكيفية إنشائها. يمكن أن تشير الجودة إلى مدى قابلية البرمجيات للصيانة، وإلى ثباتها، وسرعتها، وسهولة استخدامها، وقابلية الاختبار، وسهولة القراءة، وحجمها، وتكلفتها، وأمنها، وعدد العيوب أو «الأخطاء»، بالإضافة إلى خصائص أقل قابلية للقياس مثل الأناقة، والإيجاز، ورضا العملاء، من بين العديد من الخصائص الأخرى. تشكل أفضل طرق إنشاء برمجيات عالية الجودة مشكلة منفصلة ومثيرة للجدل تغطي مبادئ تصميم البرمجيات، وتسمى «أفضل الممارسات» لكتابة التعليمات البرمجية، بالإضافة إلى مسائل إدارية أوسع مثل حجم الفريق الأمثل، والعملية، وأفضل طريقة لتقديم البرمجيات في الوقت المحدد وفي أسرع وقت ممكن، و«ثقافة» مكان العمل وممارسات التوظيف، وما إلى ذلك. يندرج كل هذا تحت العنوان الواسع لهندسة البرمجيات.[1]
تاريخ هندسة البرمجيات |
نظرة عامة
يُلاحظ تطور هندسة البرمجيات في عدة مجالات:
- ظهورها كمهنة: بحلول أوائل الثمانينات، ظهر احتراف هندسة البرمجيات، إلى جانب علوم الحاسوب والهندسة التقليدية.[2]
- دور المرأة: قبل عام 1970، غالبًا ما فوّض الرجال الذين شغلوا الأدوار المرموقة والأعلى أجرًا في هندسة المكونات المادية للحاسوب، النساء في كتابة البرمجيات، وشغلت أساطير مثل جريس هوبر أو مارجريت هاملتون العديد من وظائف برمجة الحاسوب.[3][4] يعمل عدد قليل من النساء اليوم في هندسة البرمجيات مقارنةً بالمهن الأخرى، وهي مشكلة لم يحدد سببها بوضوح. تعتبر العديد من المنظمات الأكاديمية والمهنية هذه المشكلة غير متوازنة وتحاول جاهدةً لحلها.[5]
- العمليات: أصبحت العمليات جزءًا كبيرًا من هندسة البرمجيات. ويُشاد بها لقدرتها على تحسين البرمجيات لكنها انتُقدت بشدة لأنها قد تقييد المبرمجين.
- تكلفة الأجهزة المادية: تغيرت التكلفة النسبية للبرمجيات مقابل الأجهزة المادية كثيرًا خلال الخمسين عامًا الماضية. عندما كانت الحواسيب الكبيرة باهظة الثمن وتحتاج إلى فريق دعم كبير، وكانت المنظمات القليلة التي تشتريها لديها أيضًا الموارد اللازمة لتمويل مشاريع هندسة برمجيات مخصصة وكبيرة ومكلفة. أصبحت الحواسيب الآن أكثر عددًا وأقوى، ولها تأثيرات عديدة على البرمجيات. يمكن للسوق الكبيرة دعم المشاريع الكبيرة لإنشاء برمجيات تجارية جاهزة، كما فعلت بعض الشركات مثل مايكروسوفت. تسمح الآلات الرخيصة لكل مبرمج بامتلاك طرفية قادرة على تجميع سريع نسبيًا. يمكن أن تستخدم هذه البرامج تقنيات مثل جامع القمامة، التي تجعلها أسهل وأسرع للمبرمج في الكتابة. من ناحية أخرى، تهتم بعض المؤسسات بتوظيف مبرمجين للمشاريع البرمجية الكبيرة المخصصة، بدلاً من استخدام برمجيات تجارية جاهزة.
الأصول: 1945 إلى 1965
تتضمن الأصول المزعومة لمصطلح هندسة البرمجيات خطاب عام 1965 من رئيس رابطة الآلات الحاسوبية أنتوني أوتنجر، حاضر فيه دوغلاس تي روس في معهد ماساتشوستس للتكنولوجيا عام 1950، قائلًا: مارغريت هاملتون «هي الشخص الذي توصل إلى فكرة تسمية هذا التخصص، هندسة البرمجيات، كوسيلة لمنحه الشرعية.»[6][7][8][9][10]
رعت اللجنة العلمية للناتو مؤتمرين حول هندسة البرمجيات عام 1968 (غارميش، ألمانيا) وعام 1969، مما أعطى المجال دفعة أولية. يعتقد الكثيرون أن هذه المؤتمرات تمثل البداية الرسمية لمهنة هندسة البرمجيات.[11][12]
أزمة البرمجيات: 1965 إلى 1985
حُفزت هندسة البرمجيات بما يسمى أزمة برمجيات الستينيات والسبعينيات والثمانينيات، والتي حددت العديد من مشاكل تطوير البرمجيات. تجاوزت العديد من المشاريع الميزانية والجدول الزمني. وتسببت أخرى في أضرار في الممتلكات. وتسببت بعضها في خسائر في الأرواح. عُرّفت أزمة البرمجيات في الأصل من ناحية الإنتاجية، ولكنها تطورت لتؤكد على الجودة. استخدم البعض مصطلح «أزمة البرمجيات» للإشارة إلى عدم قدرتهم على توظيف عدد كافٍ من المبرمجين المؤهلين.[13]
- تجاوزات التكلفة والميزانية: يعد نظام التشغيل OS/360 مثالاً كلاسيكيًا. أنتج هذا المشروع الذي استمر عقدًا من الزمان من ستينيات القرن العشرين، أحد أكثر أنظمة البرمجيات تعقيدًا في ذلك الوقت. كان نظام OS/360 أحد أوائل المشاريع البرمجية الكبيرة (1000 مبرمج). يزعم فريد بروكس في كتابه شهر الإنسان الأُسطوري أنه ارتكب خطأ بعدة ملايين الدولارات بعدم تطوير بنية متماسكة قبل بدء التطوير.
- الأضرار في الممتلكات: قد تتسبب عيوب البرمجيات أضرارًا في الممتلكات. يسمح الأمن السيئ للبرمجيات لمخترقين بسرقة الهويات ويكلف هذا الوقت والمال والسمعة.
- الحياة والموت: يمكن للعيوب البرمجية أن تقتل. فقد فشلت بعض الأنظمة المضمنة المستخدمة في آلات العلاج بالأشعة بشكل كارثي لدرجة أنها أعطت جرعات إشعاع مميتة للمرضى. أشهر حالات الفشل هذه هي حادثة ثيراك 25.[14]
احتفظ بيتر جي. نيومان بقائمة معاصرة للمشاكل والكوارث البرمجية.[15] تلاشت أزمة البرمجيات عن الأنظار، لأنه من الصعب للغاية من الناحية النفسية البقاء في وضع الأزمة لفترة طويلة (أكثر من 20 عامًا). ومع ذلك، لا تزال البرمجيات -وخاصةً برمجيات الوقت الحقيقي المُضمنة- خطرة ومنتشرة، والأهم أنها لا تحظى بالرضا. خلال السنوات العشر إلى الخمس عشرة الماضية، كتب مايكل إيه. جاكسون بإسهاب عن طبيعة هندسة البرمجيات، وحدد المصدر الرئيسي لصعوباتها أنه النقص في التخصص، واقترح أن توفر أطر مشاكله الأساس «لممارسة طبيعية». لهندسة البرمجيات، وهي شرط أساسي لتصبح هندسة البرمجيات علمًا هندسيًا.[16]
«لا يوجد حل سحري»: 1985 إلى 1989
شكّل حل أزمة البرمجيات أهمية بالغة للباحثين والشركات المنتجة للأدوات البرمجية لعقود من الزمان. كانت تكلفة امتلاك البرامج وصيانتها في الثمانينيات تساوي ضعف تكلفة تطوير البرمجيات.
- خلال التسعينيات، زادت تكلفة الملكية والصيانة بنسبة 30% عما كانت عليه في الثمانينيات.
- في عام 1995، أظهرت الإحصاءات أن نصف مشاريع التطوير التي شملها الاستطلاع كانت شغّالة، لكنها لم تعتبر ناجحة.
- تجاوز المشروع البرمجي المتوسط جدوله الزمني بمقدار النصف.
- كانت ثلاثة أرباع المنتجات البرمجية الكبيرة التي تُسلم للعميل فاشلة ولا تُستخدم على الإطلاق، أو لا تلبي متطلبات العميل.
ظهور الإنترنت: 1990 إلى 1999
أدى ظهور الإنترنت إلى نمو سريع للغاية في الطلب على أنظمة عرض المعلومات/البريد الإلكتروني الدولية على شبكة الويب العالمية. توجب على المبرمجين التعامل مع الرسوم التوضيحية والخرائط والصور الفوتوغرافية وغيرها من الصور، بالإضافة إلى الرسوم المتحركة البسيطة، بمعدل لم يسبق له مثيل، مع عدد قليل من الطرق المعروفة لتحسين عرض/ تخزين الصور (مثل استخدام الصور المصغرة).
أدى نمو استخدام متصفح الويب، الذي يعمل على لغة ترميز النص الفائق (HTML)، إلى تغيير طريقة تنظيم عرض المعلومات واسترجاعها. أدت اتصالات الشبكة الواسعة النطاق إلى نمو فيروسات الحاسوب الدولية وبرامج الوقاية منها على الحواسيب التي تعمل بنظام إم إس ويندوز، وأصبح الانتشار الواسع لرسائل البريد الإلكتروني غير المرغوب فيها مشكلة تصميم رئيسية في أنظمة البريد الإلكتروني، وغمرت قنوات الاتصال، وتطلبت إجراء فحص مسبق شبه تلقائي. تطورت أنظمة البحث بكلمة أساسية إلى محركات بحث على شبكة الإنترنت، وتوجب إعادة تصميم العديد من أنظمة البرمجيات، للبحث الدولي، اعتمادًا على تقنيات تحسين محركات البحث (سيو). كان هناك حاجة إلى أنظمة ترجمة للغات الطبيعية البشرية لمحاولة ترجمة تدفق المعلومات بلغات أجنبية متعددة، مع تصميم العديد من أنظمة البرمجيات للاستخدام متعدد اللغات، استنادًا إلى مفاهيم التصميم من المترجمين البشريين. انتقلت قواعد مستخدمي الكمبيوتر النموذجية غالبًا من مئات أو آلاف المستخدمين إلى عدة ملايين المستخدمين الدوليين.
انظر أيضًا
مراجع
- ^ "CS302: Jared King's "The History of Software"". learn.saylor.org (بen-us). Archived from the original on 2018-11-19. Retrieved 2018-02-17.
{{استشهاد ويب}}: صيانة الاستشهاد: لغة غير مدعومة (link) - ^ "Software engineering … has recently emerged as a discipline in its own right." Sommerville، Ian (1985) [1982]. Software Engineering. Addison-Wesley. ISBN:978-0-201-14229-7. مؤرشف من الأصل في 2022-06-24.
- ^ Abbate، Janet (2012). Recoding Gender. Cambridge, MA: MIT Press. ص. 39. ISBN:978-0262534536. مؤرشف من الأصل في 2022-04-11.
- ^ Ensmenger، Nathan (2012). The Computer Boys Take Over. Cambridge, MA: MIT Press. ISBN:978-0262517966.
- ^ "Episode 576: When Women Stopped Coding". NPR Planet Money. 17 أكتوبر 2014. مؤرشف من الأصل في 2019-10-30. اطلع عليه بتاريخ 2018-06-27.
- ^ 2018 International Conference on Software Engineering celebrating its 40th anniversary, and 50 years of Software engineering. "ICSE 2018 - Plenary Sessions - Margaret Hamilton". مؤرشف من الأصل في 2019-04-28. اطلع عليه بتاريخ 2018-06-09.
- ^ Rayl، A.J.S. (16 أكتوبر 2008). "NASA Engineers and Scientists-Transforming Dreams Into Reality". NASA 50th anniversary website. ناسا. مؤرشف من الأصل في 2019-05-06. اطلع عليه بتاريخ 2016-11-25.
- ^ Meyer، Bertrand (4 أبريل 2013). "The origin of "software engineering"". مؤرشف من الأصل في 2018-06-12. اطلع عليه بتاريخ 2016-11-25.
- ^ Tadre، Matti (3 ديسمبر 2014). The Science of Computing. CRC Press. ص. 121. ISBN:978-1-4822-1770-4.
- ^ Mahoney، Michael. "The Roots of Software Engineering" (PDF). CWI Quarterly. ج. 3 ع. 4: 325–334. مؤرشف من الأصل (PDF) في 2017-08-28. اطلع عليه بتاريخ 2015-06-04.
- ^ King، Jared (2016). "Jared King's "The History of Software"". CS302: Software Engineering. Saylor.org. مؤرشف من الأصل في 2018-11-19. اطلع عليه بتاريخ 2016-11-25.
- ^ Brian Randell (2001). "NATO Software Engineering Conferences". ncl.ac.uk. مؤرشف من الأصل في 2019-11-22. اطلع عليه بتاريخ 2016-11-25.
- ^ ثيراك 25
- ^ Leveson، N.G.؛ Turner، C.S. (1 يوليو 1993). "An investigation of the Therac-25 accidents". Computer. ج. 26 ع. 7: 18–41. CiteSeerX:10.1.1.372.412. DOI:10.1109/MC.1993.274940. ISSN:0018-9162.
- ^ "RISKS-LIST: RISKS-FORUM Digest". The Risks Digest. مؤرشف من الأصل في 2019-10-28.
- ^ {Michael Jackson, "Engineering and Software Engineering" in S Nanz ed, The Future of Software Engineering, Springer Verlag 2010; Michael Jackson, Problem Frames: Analyzing and Structuring Software Development Problems; Addison-Wesley, 2001}
