More Related Content Similar to Agile Software Development I: Software crisis (Arabic) (20) Agile Software Development I: Software crisis (Arabic)3. مدخل
• YOU HAVE BEEN ILL SERVED BY THE SOFTWARE INDUSTRY FOR 40 YEARS—NOT
PURPOSELY, BUT INEXTRICABLY. WE WANT TO RESTORE THE PARTNERSHIP.
•مدار على البرمجيات صناعة تقدمها التي الخدمة سوء من عانينا لقد40سنة,قصد عن ليس,الواقع هو هذا لكن و,آن و
ذلك لتغيير األوان[ .بتصرف]
•رَبشوا نِكKEN SCHWABER,منهجية مؤسسي أحد هو وSCRUMالبرمجيات تطوير إدارة في الشهيرة-الـ أحد و17
المرنة البرمجة يسمى لما الرسمي البيان على الموقعين رجالAGILE MANIFESTO
•أزمة؟ في البرمجات صناعة تعيش حقا فهل
4. البرمجيات أزمةSOFTWARE CRISIS
•مصطلح ظهر"البرمجيات أزمة“SOFTWARE CRISISالعشرين القرن ستينات أواخر في,علم تأسيس بدايات في و
النا الصناعة منها تعاني التي المشكالت عن للتعبير البرمجيات هندسةشئة,وقتذاك مالمحها أهم كانت التي و:
•البرمجيات مشاريع تسليم في الكبير التأخر.
•البرمجيات مشاريع في للميزانية الكبير التجاوز.
•المسلمة البرمجيات جودة قلة(للمتطلبات تلبيتها عدم.)
•البرمجيات وتحديث صيانة في البالغة الصعوبة.
8. ستانديش مؤسسة تقاريرSTANDISHسنة حتى2009
•عادة,تعيش البرمجيات صناعة أن يزعمون من يعتمدفي
ستان مؤسسة تصدره الذي الدوري التقرير على أزمةديش
STANDISH GROUPشهيرة بحثية مؤسسة هي و
البرمجيات صناعة حول دورية تقارير تصدر
•التقارير نتائج ملخص
عام حتى2009
•المصدر,كتاب
BEGINNING APPLICATION LIFECYCLE
MANAGEMENT
9. ستانديش مؤسسة تقاريرSTANDISHسنة2009
•القياس معايير:الموعد في التسليمON TIME–المشروع بميزانية االلتزامON BUDGET–الخصائص اكتمال
المرجوةSCOPE
•لسنة التقرير نتائج2009:
•44%متعثرة المشاريع من=تسيمها تأخر,لها ططُخ مما أكثر تكلفت أو,منها المرجوة الخصائص كل ِتوف لم أو
•24%فشلت المشاريع من=تسليمها قبل ألغيت,قط تستخدم لم و لمتُس أو
•32%نجحت المشاريع من=موعدها في لمتُس,لها المخطط بالتكلفة و,المرجوة بالوظائف و
11. ستانديش تقاريرمؤسسة نتائج على مالحظات
•الوقت مع النتائج في تحسن هناك
•هي تقرير آخر في المشروعات نجاح نسبة29%فقط,جدا ضئيلة نسبة هي و,أزمة في تعيش الصناعة أن يوحي قد مما
بالفعل.
•حولنا من شيء كل في التطبيقات نلمس أننا الواقع,فاشلة التطبيقات هذه كل تكون أن يمكن ال و
•للمؤسس بالغة أهمية تمثل و مفيدة أنها إال متعثرة تكون قد المشاريعة,العملية حياتنا في بأعيننا رأيناه هذا و.
•الدراسات هذه مثل مع التعامل في قاعدة:كمؤشرات بها يستأنس أن المرء على ينبغي,الح الواقع هو هذا أن يظن أن القيقي,
عينات على تعتمد الدراسات هذه مثل فإن,النت لهذه الوصول كيفية و البحث آليات عن تفصح ال أنها عن فضالائج...إلخ,هذه و
المؤسسة هذه لتقارير الموجهة االنتقادات من.
12. د مجلة تقارير.دوبزDR. DOBB’S+سوفت آمبي مؤسسة
AMBYSOFT
•منذ2006ستانديش مؤسسة تقارير دقة عدم تبين أخرى دراسات تظهر بدأت,د مجلة تقارير منها.الشهيرة دوبز
•المجلة قراء رأي استطالع نتيجة دورية بصورة تخرج التقارير
*التقارير مصادر(مجمعة غير:)http://ambysoft.com/surveys/
14. المشروعات تعثر تحليل-سنة ستانديش تقرير2013
•مستفاد درس:ك إنهاء أستطع لم إذال
المطلوب,أهم على فركز20%من
المطلوبات هذه,األكثر عادة فإنها
خالل استخداما80%الوقت من!
15. المشروعات تعثر تحليل–مجلة دراسةACMسنة2007
•الميزانية تجاوز نسبة13%
•التسليم موعد تجاوز نسبة20%
•المطلوبة الخصائص في النقص نسبة7%
*حسابية متوسطات
*المصدر:كتابBEGINNING APPLICATION LIFECYCLE MANAGEMENT
17. THE MYTHICAL MAN-MONTH
•البرمجيات أزمة يناقش الكتاب
•سنة األول اإلصدار1975ذكرها التي المشكالت من كثير من تعاني الصناعة زالت ال و م!!
•القراءة يستحق الكتاب,ويكيبيديا على ملخصه قراءة األقل على أو:
HTTPS://EN.WIKIPEDIA.ORG/WIKI/THE_MYTHICAL_MAN-MONTH
الفصل قراءة و19,الكتاب من األول اإلصدار ملخص فإنه!
18. الكالسيكية البرمجيات أزمة تجليات1
•الناس و الوقت تبادلية خرافةTHE MYTHICAL MAN-MONTH
•تأخرا ستزيده المتأخر للمشروع أفراد إضافة
•في يولد الطفل9أشهر,النساء عدد عن النظر بغضالوالدة عن المسئولين!
•وحدةالتصور تماسك أوCONCEPTUAL INTEGRITYاألنظمة تصميم في االعتبارات أهم
•CODING STANDARDS?–UNIFIED TOOLSET-CONSISTENT USABLE USER INTERFACES-...إلخ
•التحديث و الصيانة صعوبة إلى يؤدي التصور وحدة عدم
•الثاني النظام تأثيرSECOND SYSTEM EFFECT
•انتبه!اإلطالق على األخطر هو النوع نفس من بتصميمه تقوم نظام ثاني!ف فيها وقعت التي األخطاء كل تالفي ستحاول ألنكاألول النظام ي,
الالزم عن زائدة هندسته نظاما النتيجة ستكون وOVER-ENGINEERED!
19. الكالسيكية البرمجيات أزمة تجليات2
•بابل متالزمةBABEL SYNDROME
•التواصل ضعف هو الكبيرة المشروعات لفشل األسباب أهم أحدCOMMUNICATIONالتنسيق بالتالي وORGANIZATION
•التغير ثباتTHE ONLY CONSTANCY IS CHANGE ITSELF
•قدومه عدم تتوقع أو التغير تحارب ال,محالة ال قادم فإنه,له استعد و نفسك لأه لكن و
•سيفشل غالبا نظام أول,ضخما سيكون ربما,بطيئا سيكون ربما,االستخدام صعب سيكون ربما,ذلك كل ربما وا المقترحلقديم:نظاما ابن
لالستبدال جاهزا=التجريبي المشروع فكرةPILOT PROJECT.الجديد المقترح:بالتدريج النظام ابن,التجريبية النسخ صارت قد و
BETA VERSIONSاآلن شائعة
•فضية رصاصة توجد الNO SILVER BULLET
•سحرية حلول توجد ال,المشكالت كل يناسب واحد حل أو[األصلية الفكرة من تصرف و بتبسيط]
20. الكالسيكية البرمجيات أزمة تجليات3
•البرمجية األخطاءSOFTWARE BUGSدةوال:!
•FIXING A DEFECT HAS A SUBSTANTIAL (20 TO 50 PERCENT) CHANCE OF INTRODUCING
ANOTHER.ما برمجي خطأ تصحيح عند,كبيرة احتمالية هناك فإن(من20إلى50)%أخرى أخطاء الستحداث!
•المراجعة اختبارات أن التأكد من البدREGRESSION TESTSبرمجي لخطأ تصحيح كل بعد صحيح بشكل تعمل[ !سنة الكالم هذا الحظ
1975!!!]
•الكوارث تفريخHATCHING CATASTROPHES:واحدة دفعة ليس و بالتدريج تحدث الكوارث
•المعلومات من لنوعين يحتاج مدير كل:قرار اتخذا منها يلزم استثنائية معلومات,حالة تقارير وSTATUS REPORTSاإلنذار و للمتابعة
للمشكالت المبكر.
•اآلمنة البيئة,التالوم من الخاليةBLAME-FREE,انسيابي بشكل المعلومات تدفق و الشفافية تضمن(يخف لم إن,ب أوال سيخبركأول)!
•تحديد هو الصحيحة الحالة معرفة لضمان شيء أفضلالتسليم مواعيدDEADLINESااللتزام محاولة وبها.نحو للتقدم المستمرة المتابعة و
التسليم موعد.
21. البرمجيات فشل أسباب
•الواقعية غير أو الغامضة األهداف
•المطلوبة الموارد تقدير في الخطأ
•مستمر بشكل المشروع حالة متابعة عدمPOOR REPORTING OF PROJECT STATUS
•المخاطر إدارة في الفشل
•التواصل ضعفPOOR COMMUNICATION
•ناضجة غير تقنيات على االعتمادIMMATURE TECHNOLOGIES
•المشروع تعقيدات إدارة في الفشل
•التطوير في المتقنة غير أو السيئة الممارساتHACKING-DRIVEN DEVELOPMENT
•اإلداري الفقر أو الضعف
•المصلحة أصحاب سياساتSTAKEHOLDERSالمتعارضة
•السوق ضغط
واحد لسبب عادة الفشل يحدث ال,مجتمعة أسباب لعدة إنما,تنظيمية و إدارية و فنية.
*المصدر:HTTP://SPECTRUM.IEEE.ORG/COMPUTING/SOFTWARE/WHY-SOFTWARE-FAILS
23. المشروع حجم تأثير1
•مجلة أجرتها التي الدراسة فيACMسنة2007
بعنوانTHE IMPACT OF SIZE AND
VOLATILITY ON IT PROJECT
PERFORMANCE
•المشروع حجم زاد كلما,أو تعثره فرص زادت
فشله
•فيه المبذول بالمجهود الحجم قياس.المجهود=
األشخاص عدد×األشهر عدد
24. المشروع حجم تأثير2
•ستانديتش مؤسسة تقرير فيSTANDISH
CHAOS REPORTلسنة2015
•لسنة المشروع حجم قياس معيار أعلم ال20015,لكن
سنة معيار2013تتكل التي المشروعات يعتبر كانف
من أقل1صغيرة دوالر مليون,أكثر تتكلف التي ومن
10كبيرة دوالر مليون
المصدر:http://www.infoq.com/articles/standish-chaos-2015
25. المشروع مواصفات تعقد تأثيرREQUIREMENTS
COMPLEXITY
•م يزيد المشروع فشل أو تعثر احتمال أن إلى يشير السابق التقرير نفستعقده ع.
26. المشروع تنفيذ زمن تأثير
•مجلة أجرتها التي الدراسة فيACMسنة2007
بعنوانTHE IMPACT OF SIZE AND
VOLATILITY ON IT PROJECT
PERFORMANCE
•و تعثره فرص زادت المشروع تنفيذ زمن زاد كلما
فشله
•من أكثر المشروع زمن كان إذا18احتمالية تزيد
جدا الفشل!
27. الفريق حجم تأثير
•مجلة أجرتها التي الدراسة فيACMسنة2007
بعنوانTHE IMPACT OF SIZE AND
VOLATILITY ON IT PROJECT
PERFORMANCE
•عن الفريق حجم زاد إذا20,و تعثره احتمالية زادت
جدا فشله
•من أقل20متقاربة التعثر احتمالية تقريبا
•ف بروكس فريدريك قاله ما مع متوافقة النتائج هذهكتابه ي
THE MYTHICAL MAN-MONTHسنة من
1974:إال تزيده لن المتأخر للمشوع أفراد إضافة
تأخرا!
28. الرؤية وضوح تأثير
•طرديا تتناسب الفشل و التعثر احتمالية أن ذكرت السابقة الدراسة نفسالمتطلبات في التغير معREQUIREMENTS
CHANGING
•كتاب الدراسة مصدر:BEGINNING APPLICATION LIFECYCLE MANAGEMENT
30. المتبعة المنهجية تأثيرPROCESS2
•د مجلة تقرير.دوبز+سنة سوفت آمبي مؤسسة
2013(بتصرف)
•المرنة المنهجات باتباع أعلى النجاح احتماليات
AGILEالتقليدية المنهجيات منTRADITIONAL
االرتجالية أوAD-HOC
•باتباع أقل الفشل و التعثر احتمالياتالمنهجاتالمرنة
AGILEالتقليدية المنهجيات منTRADITIONAL
االرتجالية أوAD-HOC
المصدر:http://www.ambysoft.com/surveys/success2013.html
31. للطميات ال!
•ا البرمجة حركة ظهور قبل مخدومة تكن لم البرمجيات صناعة أن االدعاءلمرنةAGILE SOFTWARE
DEVELOPMENT–العرض بداية في قدمنا كما-خاطيء لكنه و شائع مدخل!
•حقيقية أزمة من تعاني ال البرمجيات صناعة أن تبين اإلحصاءات,جديدة قديمة مشكالت من تخلو لم إن و!
•النجاح أسباب أهم خالصة:
•«سكر تاكل نملة عيش»!!–مصري مثل
•صغير المشروع–صغير فريق–قصير زمن
•GO AGILE!
•اإلحصاءاتبالفعل المرنة البرمجة حركة نجاح تبين,المدخل غير من لكن والخاطيء,األيام هذه العام االتجاه فهي...
32. المرنة؟ البرمجة أساليب شيوع مدى ما1
•د مجلة تجريه الذي االستبيان نتيجة.مؤ مع دوبزسسة
لسنة سوفت آمبي2014
•المصدر:
HTTP://WWW.AMBYSOFT.COM/SUR
VEYS/STATEOFITUNION2014Q2.HT
ML
33. المرنة؟ البرمجة أساليب شيوع مدى ما2
•فورستر مؤسسة نشرتها دراسة فيFORRESTERسنة2011بعنوان:
WATER-SCRUM-FALL IS THE REALITY OF AGILE FOR MOST ORGANIZATIONS TODAY
•الخالصة:
•شائعة المرنة البرمجة أساليب,خالصة ليست لكنهاAGILE IS POPULAR BUT NOT PURE
•الدراسة عليه أطلقت ما هو شيوعا المناهج أكثر:WATER-SCRUM-FALLسقرام أسلوب و التقليدية األساليب من هجين هي وSCRUMو
سيئا أو حسنا ليس هذا
34. تبنتها التي المؤسسات في المرنة البرمجة تطبيق تأثير
•د مجلة تجريه الذي االستبيان نتيجة.مؤ مع دوبزسسة
لسنة سوفت آمبي2014
•المصدر:
HTTP://WWW.AMBYSOFT.COM/SUR
VEYS/STATEOFITUNION2014Q2.HT
ML
Editor's Notes * سبب التسمية «متلازمة بابل» يعود إلى أساطير الأولين!
ففي حين يقول الله تعالى: «يريد الله بكم اليسر و لا يريد بكم العسر» و يقول: «ما يفعل الله بعذابكم إن شكرتم و آمنتم» و يقول: «يريد الله أن يخفف عنكم»...إلخ
نجد أن البهود و النصارى يعتقدون – كما جاء في التوراة, سفر التكوين – أن الإنسان الأول أراد أن يبني برجا يصل إلى السماء, فخاف الرب – تعالى عما يقولون علوا كبيرا – أن لا يقوم لهم شيء إذا بلغوا هذه الدرجة من العلم, فـ»بلبل» ألسنتهم, أي فرقها, فلم يستطيعوا التواصل, ففشل مشروع بناء البرج!
«ذلكم ظنكم الذي ظننتم بربكم أردكم فأصبحتم من الخاسرين»
* سبب التسمية «الرصاصة الفضية»: في أساطير الأولين أن الرصاص المصنوع من الفضة هو الوحيد القادر على قتل الذئاب الضارية!