⚠️ Lecture 02 · 81 slides · ليه الـ software بيفشل بالتفصيل

Software Crisis & Characteristics

الـ Software Crisis بقاله 50+ سنة ولسه قائم. هنا هنفكك أشهر الكوارث، نشوف ليه حصلت، ونفهم الـ 4 صعوبات الأساسية اللي بتخلي الـ software hard من طبيعته (Brooks 1987).

← All Lectures 🎯 جرب أسئلة الامتحان

Chapters

Failure Cases

Inherent Difficulties

Exam Qs

Software's Chronic Crisis — أزمة مزمنة من 50 سنة

ايه يعني "chronic crisis"؟ ليه الـ software الـ industry الوحيد اللي بيكتب "AS IS, NO WARRANTY"؟

📖 Chronic Crisis — تفكيك المصطلح

🔁 Chronic

Of long duration, continuing
Marked by frequent re-occurrence

⚠️ Crisis

A crucial state of affairs in which a decisive change is impending
Especially one with the possibility of an undesirable outcome

💡 يعني ايه software's chronic crisis؟أزمة طويلة الأمد ومتكررة في صناعة البرمجيات: مشاريع بتفشل تخدم غرضها، tubes overruns في التكلفة والوقت، deliverables ناقصة، ومشاريع كتير بتتلغي قبل ما تشوف النور.

🌍 ليه الأزمة دلوقتي؟ Software في كل حتة

حجم الـ software بيزيد بشكل أسي (exponentially) بسبب الـ hardware اللي بيبقى أسرع وأرخص وأصغر. والـ software دلوقتي موجود في:

System Software

Operating systems, drivers, telecom systems — بيتفاعل مع الـ hardware و users كتير.

Application Software

Office apps — برامج standalone لحاجة محددة.

Business Software

MIS — payroll, inventory, business databases.

Engineering & Scientific

Numerical estimations, simulations.

Web-based

e-commerce, social networks.

Real-time

Response 1ms-1sec — automotive, autopilot.

Embedded

Digital TV, IoT, consumer devices.

AI Software

Robotics, games, pattern recognition.

Mobile Applications

Apps هي اللي بتسيطر على حياتنا.

⚠️ الخطر الكبيرالـ software بقى في safety-critical systems: عربيات، طيارات، محطات نووية. لو فيه bug، ممكن الناس تموت.

📜 اللايسنس اللي بيكشف الأزمة

إحنا الـ industry الوحيدة اللي بنكتب على المنتج "AS IS, NO WARRANTY". تخيل تشتري عربية والشركة تقولك "ماشية كده، مفيش ضمانات أصلاً". ده عادي في الـ software!

MIT License (and basically every SW license)

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY...

🤔 الفكرةلو الـ industry بتاعنا مظبوطة، ما كانش فيه داعي للـ disclaimer ده. وجوده دليل على إن الـ crisis حقيقية.

💀 فشل الـ Software بيكلّف ايه؟

⏱️ Time

أشهر وسنين بتضيع.

💰 Money

بلايين الدولارات.

😡 Satisfaction

عملاء بتسيب الشركة.

⚰️ LIVES

وأحياناً... أرواح بشر.

Wall of Famous Software Failures — معرض الكوارث

12 حالة فشل حقيقية اتسببت في خسائر مادية وبشرية ضخمة. لازم تعرفهم لإن أي واحد ممكن ييجي في الـ MCQ.

1985–1987

⚕️ Therac-25

Computerized radiation therapy machine made by AECL (Atomic Energy Canada). جرعات إشعاع مميتة. السبب: race condition + UI problem.

3 deaths · 3 serious injuries

15 Jan 1990

📞 AT&T Network Crash

Missing break in C switch في 1M LOC. بعد upgrade لـ 114 switching centers في الـ US، كلهم وقعوا في نفس اليوم.

70M calls lost · $1B

25 Feb 1991

🚀 Patriot MIM-104

صاروخ Patriot الأمريكي فشل في اعتراض صاروخ Scud عراقي. السبب: clock skew (cumulative rounding error).

28 US soldiers killed

4 June 1996

🛰️ Ariane 5 Launcher

Total failure of first flight 37s after liftoff. Number conversion error in inertial reference system (64-bit float → 16-bit int overflow).

$370M+ rocket lost

Sept 1999

🪐 Mars Orbiter

NASA's Mars Climate Orbiter crashed because of metric / English unit confusion بين فريقين كانوا بيستخدموا وحدات مختلفة.

$327M satellite lost

14 Aug 2003

⚡ Northeast Blackout

508 generating units & 256 power plants shut down. Alarm system في الـ Energy Management System فشل فالـ operators معرفوش بالـ overload.

50M people · $6B

1988

🏦 Bank of America MasterNet

شركة بنوك صرفت $23M على نظام محاسبة جديد، وبعدين $600M محاولة تخليه يشتغل. المشروع اتلغي تماماً.

$623M wasted · accounts lost

1982–1993

🛡️ Allstate Insurance

$8M initial budget، مشروع 5 سنين أصبح 10 سنين، التكلفة وصلت $100M. EDS كانت الـ contractor.

$100M · 5x time overrun

1983–1987

🏥 Blue Cross Wisconsin

$200M system اتسلم في الوقت بعد 18 شهر، بس اشتغل غلط — $60M overpayments & duplicate checks. 35K عميل سابوا الشركة.

$60M overpayments · 35K customers

1988–1992

✈️ CONFIRM Project

ARMIS (with Marriot, Hilton, Budget) حاولت تبني نظام حجز فنادق وعربيات. ARMIS كانت بتكدب على status المشروع. اتلغي بعد 4 سنين.

$125M → $160M court settlement

Dec 2013

✈️ Delta Air Lines Glitch

Computer glitch خلى Delta تبيع تذاكر بأسعار رخيصة جداً من 10am لـ noon. الشركة قررت تكرّم التذاكر — خسارة كبيرة.

Glitch active 2 hours

2014

🚓 Surrey Police IT

£15M نظام لتسجيل معلومات الجرائم. الـ oversight اتوصف بأنه "not fit for purpose". مشروع فشل ذريع.

£15M wasted

⚠️ اللي بيتسأل في الامتحانركز على AT&T (missing break), Ariane 5 (overflow), Patriot (miscalculated trajectory), Therac-25 (race condition). دول الأربعة الكلاسيكيين.

Standish CHAOS Reports — أرقام بتدق الجرس

كل سنتين Standish Group بيعمل تقرير بإحصاءات نسبة نجاح مشاريع الـ software حول العالم. الأرقام صادمة.

🎯 A Successful Software Project Is...

4 شروط ولازم كلهم يتحققوا — حسب الـ Standish:

⏱️ On Time

اتسلم في الميعاد المحدد.

💰 On Budget

في حدود الميزانية المحددة.

🎯 On Target

حقق الـ requirements كلها.

😊 Customer Satisfied

العميل مبسوط بالنتيجة.

💡لو واحد من الـ 4 ناقص، المشروع "challenged". لو 2 أو 3 ناقصين، "failed".

📉 1994 CHAOS Report — الصدمة الأولى

الـ US كانت بتصرف $250 Billion على IT projects، النتائج كانت:

16%

Successful

52.7%

Cost = 189% of estimate

31.3%

Cancelled

🔴 $140 Billion ضاعوافي waste — يعني المبلغ ده اتصرف على مشاريع ما نفعت أو ما اتسلمتش.

📈 2004 CHAOS Chronicles — تحسن نسبي

10 سنين بعدين، الأرقام اتحسنت شوية بفضل وعي أكبر بـ SE practices:

34%

Successful (+18%)

51%

Challenged

15%

Failed (−16%)

Cost overrun انخفض من 180% (1994) لـ 43%. Waste من $140B لـ $55B.

📊 2015 CHAOS Report — والتحسن وقف!

للأسف، الأرقام ما اتحسنتش بعد 2011 — وقفت تقريباً نفس النسب:

Category	2011	2012	2013	2014	2015
Successful	29%	27%	31%	28%	29%
Challenged	49%	56%	50%	55%	52%
Failed	22%	17%	19%	17%	19%

🔑 ملحوظة مهمة جداً: حجم المشروع بيؤثر

Project Size	Successful	Challenged	Failed
Grand (huge)	6%	51%	43%
Large	11%	59%	30%
Medium	12%	62%	26%
Moderate	24%	64%	12%
Small	61%	32%	7%

💡 الـ takeawayكل ما المشروع أكبر، كل ما الفشل أعلى. Small projects بتنجح 61% من المرات، Grand projects بتنجح 6% بس! ده ليه الـ Agile بيكسر المشروع لـ sprints صغيرة.

Ariane 5 — تشريح كامل للكارثة

قصة كاملة: ليه الكود فشل، ليه ماتم اكتشافه قبل الإطلاق، وايه الـ lessons learned اللي لازم تحفظها.

📜 الخلفية — Ariane 4 vs Ariane 5

✅ Ariane 4 (الـ successor)

Smaller rocket
Lower initial acceleration
Lower horizontal velocity build-up
Launched 100 times successfully

💥 Ariane 5 (الـ new)

Heavier rocket, heavier payload
Higher horizontal velocity من البداية
كان شايل 4 satellites قيمتهم بـ enormous engineering effort
Self-destructed 37s بعد الإقلاع

🔍 What Went Wrong — السبب الفني

الـ altitude والـ trajectory للصاروخ بيتقاسوا بنظام computer-based.
Number conversion error — تحويل من 64-bit floating point لـ signed 16-bit integer. حصل overflow.
مفيش exception handler للتحويل ده.
الـ system exception management facilities اتفعّلت → shut down الـ software.
الـ backup software اشتغل نفس الكود فعمل نفس الغلط واتقفل.
الصاروخ خرج عن مساره → incorrect signals للـ engines → swivel → unsustainable stresses → break up.

😤 ليه كانت قابلة للتجنب؟ (Avoidable Failure)

الجزء المُحبط أوي: الكود ده كان reused من Ariane 4. والحساب اللي عمل overflow مش مطلوب أصلاً في Ariane 5.

قرارات اتاخدت بالغلط:

❌ Not to remove the unused facility — خوفاً من إن الإزالة تدخل faults جديدة.
❌ Not to test for overflow exceptions — لأن الـ processor كان "heavily loaded" وعايزين spare CPU capacity.

🔴 الدرس الكبيرPerformance لا يبرر التخلي عن safety. الـ overflow check كان هيكلف ms أو اتنين بس على CPU، وكان هينقذ صاروخ بـ $370M.

🤔 ليه Ariane 4 ما فشلتش بنفس الكود؟

الخصائص الفيزيائية لـ Ariane 4:

Smaller vehicle → lower initial acceleration
Lower horizontal velocity build-up
قيمة المتغير على A4 ما توصلش أبداً لحد بيسبب overflow خلال فترة الإطلاق

💡 الدرسالكود اللي شغّال في environment معين مش بالضرورة هيشتغل في environment تاني. Re-testing لـ reused code إجباري.

🧪 فشل الـ Validation

هنا فيه سلسلة من القرارات الغلط:

الـ facility اللي فشلت مش مطلوبة في Ariane 5 → مفيش requirement مرتبط بيها.
مفيش requirement → مفيش tests اتعملت ليها.
مفيش tests → مفيش chance لاكتشاف المشكلة.
خلال الـ system testing، استخدموا simulators للـ inertial reference system computers.
الـ simulators ما generateetش الـ error (لأن مفيش requirement أصلاً).

⚠️هنا اللي مرتبط بـ Winter 2025 Q1.22: ايه القاسم المشترك بين Ariane 5 و London Ambulance System؟ Testing was inadequate.

👁️ فشل الـ Code Review

الـ design والـ code لكل software المفروض يتعمل لهم review أثناء التطوير. هنا حصل واحد من اتنين:

إما الـ inertial reference system code ما اتمراجعش لأنه كان مستخدم في version قديمة.
أو الـ review اتعمل بس فشل في كشف المشكلة.

📚 Lessons Learned — اللي لازم تحفظهم

🚫 Don't run software in critical systems unless it is actually needed.
🧪 As well as testing what the system should do, you also have to test what it should NOT do.
⛔ Don't default to system shut-down on exception in systems with no fail-safe state.
🎯 In critical computations, return best-effort values even if absolutely correct values can't be computed.
🔧 Wherever possible, use real equipment, not simulations.
👥 Improve the review process — include external participants and review all assumptions.

Therac-25 — لما الـ bug بيقتل مرضى

1985-1987. أكتر مثال drastic عن خطورة الـ software في الـ safety-critical systems.

⚕️ ايه الـ Therac-25؟

Computerized radiation therapy machine بتاع AECL (Atomic Energy Canada Limited). كان "improved" version بيقدر يطلع نوعين إشعاع:

Low-power electron beam (beta particles) — للأنسجة السطحية.
X-rays — للأنسجة العميقة، عن طريق ضرب electrons بقوة عالية على metal target بين الـ electron gun والمريض.

🐛 الـ Bug القاتل — Race Condition

الـ bug الـ "subtle":

الـ operator بيختار mode (electron أو X-ray) من على keyboard.
لو الـ operator كان سريع جداً في الكتابة (quick-fingered typist)...
الـ machine ممكن تتظبّط على high-power mode (X-ray)...
بس الـ metal X-ray target يكون لسه out of position!
النتيجة: المريض ياخد electron beam بقوة X-ray مباشرةً في جسمه.

💀 النتيجةجرعات إشعاع مميتة. 6 مرضى ماتوا أو اتأذوا بشدة بين يونيو 1985 ويناير 1987.

⏳ ايه اللي حصل بعد كده؟

الـ bug خد سنتين علشان يتلاقى.
الشركة (AECL) أنكرت في الأول إن المشكلة في الجهاز/الكود.
بعد الفضيحة، AECL سابت سوق الـ medical equipment بالكامل.

📚 Lessons Learned

❌ AECL ignored safety aspects of software.
❌ Confused reliability with safety — الـ machine reliable في 99.9%، بس الـ 0.1% بتقتل.
❌ Lack of defensive design — مفيش checks بتمنع الـ config الخاطئ.
❌ Inadequate reporting — حادثة Ontario ما اتعملش لها explanation/follow-up.
❌ Inadequate SE practices:
- Specs as afterthought (مش من البداية)
- Complex architecture
- Dangerous coding patterns
- Little testing
- Careless HCI design

💡 الفرق بين Reliability و SafetyReliable = بيشتغل كتير من غير ما يقع. Safe = حتى لو وقع، مش بيأذي حد. Therac-25 كان reliable بس مش safe.

Software Werewolves & No Silver Bullet

Brooks 1987 — مفيش حل سحري واحد هيحل مشاكل الـ software.

🌕 Werewolves في الميثولوجيا

من كل وحوش الماضي، الـ werewolves كانوا الأكتر إخافة. ليه؟

لإنهم بيتغيروا شكلهم بدون إنذار. واحد ساعتها بيبان عادي زي أي إنسان، وفي اللحظة التانية بيبقى وحش مرعب بفك ضخم.

💻 Software Werewolf — Brooks Metaphor

الـ Software زي الـ werewolf — بيبان عادي لحد ما القمر يطلع، وبعدين يتحول لوحش:

📅 Missed deadlines
💸 Blown budgets
🐛 Buggy software

🪙 No Silver Bullet — مفيش حل سحري

في 1987، Frederick P. Brooks كتب مقالة مشهورة:

"No Silver Bullet: Essence and Accidents of Software Engineering"

Frederick P. Brooks · 1987

الحجة الأساسية: مفيش silver bullet (الرصاصة الفضية اللي بتقتل الـ werewolf) واحدة هتحل كل مشاكل الـ software. لأن الـ software عنده essence (طبيعة جوهرية) صعبة، وفيها 4 صعوبات اساسية هنشوفهم تحت.

📌 Winter 2025 Q1.21"Werewolves" في Brooks metaphor تمثل projects that seem normal but become complex and problematic. مش الـ bugs، مش الـ engineers، مش الـ tools — الـ projects نفسها.

The 4 Essential Difficulties of Software ⭐

أهم slide في الـ lecture. Brooks قال إن الـ software ليه 4 صعوبات في طبيعته الجوهرية (essence). احفظهم بترتيب: C-C-C-I.

🧠 Mnemonic: C - C - C - I

الأربعة بحرف C ما عدا واحد:

Complexity
Conformity
Changeability
Invisibility

⚠️المفروض تعرف كل واحدة معناها وأمثلة عليها. الـ doctor بيحب يسأل "ايه ال خاصية اللي بتعمل كذا؟".

🧩 Complexity

الـ Software systems مالهاش regular structures — مفيش identical parts بتتكرر. مفيش حسابات أو data structures متطابقة بتترّر.

على عكس الـ hardware: memory chip بيكرر نفس الـ basic structure ملايين المرات.

والـ software systems عندها very high number of discrete states، والتعقيد بيزيد worse than linearly مع الـ size.

🔌 Conformity

الـ Software لازم يتكيف مع الـ environment بتاعه، مش العكس.

مثلاً: الـ software هو اللي بيتكيف مع الـ hardware interfaces، مش الـ hardware اللي بيتغير علشان الـ software.

وفي معظم الوقت، أي software جديد لازم يتعامل (interface) مع نظام قديم موجود (legacy system).

🔄 Changeability

الـ Software سهل التغيير، على عكس الـ hardware.

Intel Pentium bug كلف نص بليون دولار علشان استبدال chips. لكن Microsoft لما يطلع bug فالـ Windows، التحديث download مجاني — كلفة zero.

بس ده مش بالضرورة advantage! الـ pressure على التغيير بيخلي الـ software يتغير كتير ويبعد عن الـ initial design (راجع Q1.03 Winter 2023).

👻 Invisibility

الـ Software invisible وunvisualizable — مش زي المبنى أو السيارة اللي بتقدر تشوفهم.

Complete views بتكون incomprehensible (معقدة جداً)، و partial views بتكون misleading.

الـ engineering disciplines التانية بتستخدم geometric abstractions (floor plans, blueprints) لكن الـ software ملوش geometric representation طبيعي.

📊 الـ Complexity بالأرقام — LOC Table

عدد سطور الكود في systems مشهورة:

Windows XP

40M LOC

40,000,000

Netscape

17,000,000

Space Shuttle

10,000,000

Boeing 777

7,000,000

Linux

1,500,000

🤯 fun factعربية جديدة دلوقتي فيها أكتر من الكود اللي استخدمته NASA علشان توصل أبولو للقمر!

⚖️ Changeability is NOT really an Advantage

ممكن تفكر إن سهولة التغيير ميزة. غلط. ليه؟

السهولة دي بتخلق pressure مستمر على إن الـ software يتغير.
التغيير المستمر بيخلي الـ software يبعد عن الـ initial design.
الإصدارات الجديدة بتضيف features، تدعم hardware جديد، تصلح bugs — كله بيراكم تعقيد.
النتيجة: technical debt بيتراكم، والـ system بيبقى أصعب في الصيانة.

⚠️ Winter 2023 Q1.03الإجابة الصح لـ "what is true about changeability" هي "It has advantages AND disadvantages" + "leads to frequent modifications and deviations from initial design".

Surviving in the AI Era — Bonus

الـ doctor بيقول لازم تتعلم حاجات معينة علشان تتفوق في سوق الشغل وقت AI dominance.

🤖 AI Tools اتعلمهم

GitHub Copilot — code completion
Google Codey / Gemini
اتعلم تستخدمهم بسرعة
اتعلم تدمج AI في الـ apps بتاعتك (chatbots, ML)
Secure coding
Data analysis & visualization

🚀 Trending Technologies

Serverless (AWS Lambda, Azure Functions)
Microservices architecture
Containers & Docker / Kubernetes
Blockchain
Low-Code / No-Code (LCNC) — مثل MS Power Platform
IT Business knowledge

💼 الـ ideaكل ما توسّع الـ arsenal بتاعك، كل ما تبقى أقل قابلية للإستبدال بـ AI.

🎯

Exam Question Bank — Lecture 2

8 أسئلة حقيقية تتمحور حول Software Crisis والـ Characteristics · من امتحانات 2021 → 2025

Question 1 Fall 2021–22 · Q1.03

In the case of AT&T long-distance phone network crash (15/1/1990) — what was the reason behind the failure?

A Bad UI design that confuses the operator

B A number conversion error

C Delay in software delivery by the contractor

D Missing break statement in C switch statement

✅ الإجابة الصح: D — Missing break in C switch في 114 switching center اتعمل لهم upgrade وكلهم اتأثروا بنفس السطر الغلط. 70 مليون مكالمة ضاعت في يوم واحد، AT&T خسرت بليون دولار.

ليه باقي الإجابات غلط: A — مفيش UI involved، ده failure في الـ network logic. · B — Number conversion overflow ده حكاية Ariane 5. · C — التسليم تم بالفعل والكود اشتغل لمدة فترة، المشكلة في الكود نفسه مش في التسليم.

Question 2 Fall 2021–22 · Q1.04

Which of these items is NOT included in the definition of software crisis?

A Software fails to serve the purpose or may cause harm

B Project delivers reduced functional deliverables

C Project cost overruns and schedule delays

D Project staff leave the project before completion

✅ الإجابة الصح: D — Project staff leave الـ chronic crisis ليه 3 مظاهر بس: fails purpose · reduced functionality · cost & schedule overruns. سيبان الموظفين دي مشكلة HR في أي صناعة، مش مرتبطة بفشل الـ software تحديداً.

A, B, C كلهم جزء من التعريف الرسمي.

Question 3 Winter 2021 · Q1.03

In the case of Patriot MIM-104, a software bug caused the system to:

A Not being able to see the attacking missile

B Not showing the trajectory of the attacking missile on the screen

C Miscalculate the trajectory of the attacking missile

D Fail to fire at the attacking missile

✅ الإجابة الصح: C — Miscalculate the trajectory Patriot رصد الـ Scud، وأطلق عليه صاروخ اعتراضي. بس بسبب clock skew (cumulative rounding error)، النظام حسب موقع الـ Scud بشكل غلط فالـ صاروخ المعترض راح في مكان خاطئ. 28 جندي ماتوا.

A/B — الـ Patriot شاف الصاروخ على الـ radar. · D — الـ Patriot أطلق فعلاً، بس الـ trajectory المحسوبة غلط فما أصابش الهدف.

Question 4 Winter 2021 · Q1.04

Which line of code caused the failure of AT&T telephone network?

A Line 2

B Line 13

C Line 6

D Line 12

E Line 10

✅ الإجابة الصح: E — Line 10 الـ break في السطر 10 موجود داخل else برّه الـ if الداخلي، وبالتالي بيخرج من الـ switch كله بدل ما يخرج من الـ if فقط. بكده ما بيوصلش لـ process incoming message.

B (line 13) — break الطبيعي للخروج من الـ case، مش هو السبب. · الـ خيارات التانية: مش هي السطور اللي فيها bug.

Question 5 Winter 2023 · Q1.02

Software failures stem from...
I. Poor management decisions or lack of decisions
II. Poor software development practices
III. Limited budget for the software project
IV. Overconfidence in the software performance

A Only I & III

B Only II, III & IV

C Only I, II & III

D Only III & IV

E Only I, II & IV

✅ الإجابة الصح: E — Only I, II & IV الأسباب الحقيقية للفشل: Poor management + Poor practices + Overconfidence. الميزانية المحدودة (III) مش سبب رئيسي — Therac-25 ما فشلش بسبب ميزانية، فشل بسبب practices سيئة.

أي إجابة فيها III غلط.

Question 6 Winter 2023 · Q1.03

Software changeability...
I. It has advantages and disadvantages
II. It means that software is intangible and lacks a physical presence
III. It means that software must adapt to existing hardware interfaces
IV. It often leads to frequent modifications and deviations from the initial design

A Only I & III

B Only I, II & III

C Only I & IV

D Only II & IV

E Only III & IV

✅ الإجابة الصح: C — Only I & IV Changeability ليها مميزات (سهولة التحديث) وعيوب (الـ pressure للتغيير بيؤدي لانحراف عن الـ initial design). الاتنين صحيحين.

II — "intangible" = Invisibility، صعوبة تانية من الـ 4. · III — "adapt to existing hardware interfaces" = Conformity، صعوبة تالتة. الـ doctor بيخلط بين الـ 4 difficulties في الـ MCQ.

Question 7 Winter 2025 · Q1.21

In Brooks' metaphor, what do "werewolves" represent in software engineering?

A Bugs that are difficult to track

B Projects that seem normal but become complex and problematic

C Magical tools that promise to fix everything

D Software engineers who over-complicate systems

✅ الإجابة الصح: B — Projects that seem normal but become complex الـ werewolf في الميثولوجيا بيتغير شكله بدون إنذار. كده المشاريع: تبدأ بسيطة وفجأة بتبقى وحش. الـ "silver bullet" هو اللي بيقتل الـ werewolf، فالـ projects هم الـ werewolves.

A — Bugs مش الـ werewolves. · C — الـ silver bullet هو الـ tool، الـ werewolf هو الضحية/المشكلة. · D — Brooks ركز على الـ projects مش الـ engineers.

Question 8 Winter 2025 · Q1.22

What is common between the cases of software failure in Ariane 5 and London Ambulance System (LAS)?

A The company developing the software had no prior experience in this type of software

B A number conversion to a smaller type caused overflow and hence system failure

C Testing was inadequate and insufficient

D The decision to release the system was done on political not technical reasons

✅ الإجابة الصح: C — Testing was inadequate and insufficient Ariane 5: الكود من A4 ما اتعملش له re-testing على البيئة الجديدة (الـ horizontal velocity الأعلى). الـ simulators ما generateetش الـ error لأن مفيش requirement أصلاً. LAS: launched without load testing كافي. الـ common factor = inadequate testing.

A — الشركتين كان عندهم خبرة في الـ domain. · B — overflow ده Ariane 5 بس، مش LAS. · D — قرارات سياسية مش العامل المشترك.

📋

Cheat Sheet — مذاكرة سريعة لليلة الامتحان

كل اللي محتاجه: الأرقام · الأسماء · التواريخ · الأسباب · الـ 4 صعوبات.

💥 Famous Failures (الأهم)

AT&T 1990

Missing break in C switch (line 10). 70M calls. $1B.

Patriot 1991

Clock skew (cumulative rounding) → miscalculated Scud trajectory. 28 deaths.

Ariane 5 1996

64-bit float → 16-bit int overflow. Code reused from A4. No exception handler. Exploded 37s after liftoff.

Therac-25 1985-87

Race condition + UI bug. X-ray target out of position. 6 victims, 3 deaths.

Mars Orbiter 1999

Metric/English unit confusion. $327M lost.

Blackout 2003

Alarm system في EMS فشل. 50M people. $6B.

⭐ The 4 Inherent Difficulties (Brooks)

1. Complexity

No regular structure · high # discrete states · grows worse than linearly

2. Conformity

SW conforms to HW interfaces (not vice versa) · must interface w/ existing systems

3. Changeability

Easy to change · BUT pressure leads to deviation from initial design

4. Invisibility

No geometric/physical representation · complete views incomprehensible · partial views misleading

Mnemonic

C-C-C-I · Brooks 1987 "No Silver Bullet"

📊 CHAOS Stats

1994

16% success · 53% challenged · 31% cancelled · $140B waste

2004

34% success · 51% challenged · 15% failed · $55B waste

2015

29% success · 52% challenged · 19% failed

Project size

Small = 61% success · Grand = 6% success

Success = 4 things

On Time · On Budget · On Target · Customer Satisfied

🔢 LOC Quick Reference

Windows XP

40 million LOC

Netscape

17 million LOC

Space Shuttle

10 million LOC

Boeing 777

7 million LOC

Linux

1.5 million LOC

Modern car

> Apollo moon mission code

🧠 Concepts Don't Mix Up

Reliability

شغّال كتير من غير ما يقع

Safety

حتى لو وقع، مش بيأذي حد. Therac-25 كان reliable مش safe.

Changeability

سهولة التعديل (essence #3)

Conformity

التكيف مع HW/legacy (essence #2)

Invisibility

ملوش شكل فيزيائي/هندسي (essence #4)

🚀 Ariane 5 — Why It Failed

Code source

Reused from Ariane 4

Why no overflow check?

Performance — CPU was "heavily loaded"

Why no test?

No requirement (feature not used in A5) → no test

Backup software

Same code → same crash

Simulators?

Used in testing, but didn't generate the error

⚡

Rapid Revision — مراجعة آخر ساعة

Flashcards على الـ 4 صعوبات والكوارث · Common Mistakes · What the doctor loves to ask.

🎴 اضغط على أي card علشان تشوف الإجابة

ايه الـ 4 inherent difficulties في الـ software (Brooks)؟

tap to flip

Complexity · Conformity · Changeability · Invisibility

ايه سبب فشل Therac-25؟

tap to flip

Race condition + UI problem

ايه سبب فشل Mars Orbiter 1999؟

tap to flip

Metric / English unit confusion

ايه الشروط الـ 4 لـ successful SW project؟

tap to flip

On Time · On Budget · On Target · Customer Satisfied

ليه Ariane 4 ما فشلتش بنفس الكود؟

tap to flip

Smaller rocket → lower horizontal velocity → value never reached overflow

ايه الفرق بين Reliability و Safety؟

tap to flip

Reliable = doesn't fail often. Safe = doesn't harm even when it fails.

ايه نسبة نجاح Small projects vs Grand projects (CHAOS 2015)؟

tap to flip

Small = 61% success · Grand = 6% success

ايه Brooks' famous 1987 paper title؟

tap to flip

"No Silver Bullet: Essence & Accidents of SE"

Changeability ميزة ولا مش ميزة؟

tap to flip

عندها مميزات وعيوب — الـ pressure للتغيير بيخلي SW يبعد عن الـ initial design

🚨 Common Mistakes

1. خلط الـ 4 difficulties Conformity = adapt to existing systems · Invisibility = no physical form · Changeability = easy to change · Complexity = no regular structure. الـ doctor بيستخدم تعريف صعوبة واحدة كـ distractor في سؤال عن صعوبة تانية.

2. خلط أسباب الكوارث AT&T = missing break · Ariane 5 = number overflow · Patriot = clock skew (miscalculated trajectory) · Therac-25 = race condition · Mars Orbiter = metric/English units. كل واحدة سببها مختلف، ما تخلطش بينهم.

3. Changeability = advantage فقط؟ لأ. Brooks قال صراحة إنها essential difficulty. الـ pressure على التغيير بيخلي الـ SW يبعد عن الـ design الأصلي ويراكم technical debt.

4. Reliability = Safety؟ لأ، مختلفين. Therac-25 كان reliable (شغّال كتير من غير ما يقع) بس مش safe (لما وقع، قتل ناس). الفرق ده ممكن ييجي في MCQ مفصّل.

5. القاسم المشترك بين Ariane 5 و LAS مش الـ overflow (ده Ariane بس) ولا الـ political decision. هو inadequate testing. ركز.

⭐ What Dr. El-Ramly Loves to Ask

🔥 الأسئلة المتكررة على Lec 2

اسم الـ failure + سببها — كل امتحان لازم فيه سؤال زي ده.
"What is NOT in the definition of software crisis" — متكرر جداً.
One of the 4 essential difficulties — بيختار خاصية ويسأل ايه التعريف بتاعها (أو العكس).
"What causes software failures" — Poor mgmt + Poor practices + Overconfidence.
Brooks' werewolves — مرة كل سنة.
الـ common factor بين 2 failure cases — testing inadequate في معظم الأحيان.

🎯 نصيحة أخيرة ركز على الـ keywords: missing break · number conversion overflow · race condition · clock skew · metric/English · alarm system · Brooks 1987 · No Silver Bullet · C-C-C-I · inadequate testing · safety ≠ reliability.