View
1.235
Download
0
Category
Preview:
Citation preview
AGILE SOFTWARE DEVELOPMENT I:
SOFTWARE CRISISالبرمجيات صناعة تعاني هل
أزمة؟ دعبس من سامح
الفهرس
مدخل•البرمجيات • SOFTWARE CRISISأزمةالمشروعات • فشل و نجاح نسب حول تقارير و دراساتالمشروعات • تعثر تحليلالمشروعات؟ • تفشل أو تتعثر لماذاالمشروعات؟ • تنجح لماذا•!! للطميات الللـ • الصحيح AGILE SOFTWARE DEVELOPMENTالمدخل
مدخل
• 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رجال
أزمة؟ • في البرمجات صناعة تعيش حقا فهل
البرمجيات SOFTWARE CRISISأزمة
• “ البرمجيات " أزمة مصطلح , SOFTWARE CRISIS ظهر في و الـعشرين القرن ستينات أواخر في , و الناشئة الصناعة منها تعاني التي المشكالت عن للتعبير البرمجيات هندسة علم تأسيس بدايات
: وقتذاك مالمحها أهم كانت التي•. البرمجيات مشاريع تسليم في الكبير التأخر•. البرمجيات مشاريع في للميزانية الكبير التجاوز•.) للمتطلبات ) تلبيتها عدم المسلمة البرمجيات جودة قلة•. البرمجيات وتحديث صيانة في البالغة الصعوبة
البرمجيات هزلية – أزمة صورة
تاريخية – أمثلة البرمجيات HALL OF SHAME - أزمة
: http://spectrum.ieee.org/computing/software/why-software-failsالمصدر*
أزمة؟ من تعاني البرمجيات صناعة الزالت فهل
ستانديش مؤسسة سنة STANDISHتقارير 2009حتىالبرمجيات, • صناعة أن يزعمون من يعتمد عادة
تصدره الذي الدوري التقرير على أزمة في تعيشستانديش هي STANDISH GROUPمؤسسة و
حول دورية تقارير تصدر شهيرة بحثية مؤسسةالبرمجيات صناعة
التقارير • نتائج ملخصعام 2009حتى
كتاب, • المصدر BEGINNING APPLICATION LIFECYCLE MANAGEMENT
ستانديش مؤسسة 2009سنة STANDISHتقارير
• : الموعد في التسليم القياس المشروع– ON TIMEمـعايير بميزانية – ON BUDGETااللتزامالمرجوة الخصائـص SCOPEاكتمال
لسنة • التقرير :2009نتائج•44% , , الخصائص = كل توفِّ لم أو لها ُخطط مما أكثر تكلفت أو تسيمها تأخر متعثرة المشاريع من
منها المرجوة•24% , قط = تستخدم لم و ُسلمت أو تسليمها قبل ألغيت فشلت المشاريع من•32% , , المرجوة = بالوظائف و لها المخطط بالتكلفة و موعدها في ُسلمت نجحت المشاريع من
ستانديش مؤسسة STANDISH : 2011- 2015تقارير
•: القياس معاييرالموعد التسليم• فيالمشروع • بميزانية االلتزامالعميل • رضا
السابقة • التقارير عن تغيرت
HTTP://WWW.INFOQ.COM/ARTICLES/STANDISH-CHAOS-2015 :المصدر *
ستانديش تقاريرمؤسسة نتائج على مالحظات
الوقت • مع النتائج في تحسن هناكهي • تقرير آخر في المشروعات نـجاح , 29نسبة , أن% يوحي قد مما جدا ضئيلة نسبة هي و فقط
. بالفعل أزمة في تعيش الصناعة• , فاشلة التطبيقات هذه كل تكون أن يمكن ال و حولنا من شيء كل في التطبيقات نلمس أننا الواقع•. , العملية حياتنا في بأعيننا رأيناه هذا و للمؤسسة بالغة أهمية تمثل و مفيدة أنها إال متعثرة تكون قد المشاريع
• , : أن يظن أن ال كمؤشرات بها يستأنس أن المرء على ينبغي الدراسات هذه مثل مع التعامل في قاعدة , , آليات عن تفصـح ال أنها عن فضال عينات على تعتمد الدراسات هذه مثل فإن الحقيقي الواقع هو هذا
. , ... المؤسسة هذه لتقارير الموجهة االنتقادات من هذه و إلخ النتائج لهذه الوصول كيفية و البحث
. دوبز د مجلة آمبي+ DR. DOBB’Sتقارير مؤسسةAMBYSOFTسوفت
. 2006منذ • , د مجلة تقارير منها ستانديش مؤسسة تقارير دقة عدم تبين أخرى دراسات تظهر بدأتالشهيرة دوبز
المجلة • قراء رأي استطالع نتيجة دورية بصورة تخرج التقارير
:) مجمعة* ) غير التقارير //:مصادر . / /http ambysoft com surveys
مجلة 2007سنة ACMدراسة
قاربت • المشروعات نجاح % !!!!67نسبة
: كتاب* BEGINNING APPLICATION LIFECYCLE MANAGEMENTالمصدر
سنة - ستانديش تقرير المشروعات تعثر 2013تحليل
• : أستطع لم إذا مستفاد درس , فركز المطلوب كل إنهاء
أهم هذه% 20على مناألكثر, عادة فإنها المطلوبات
خالل من% 80استخداماالوقت!
مجلة – دراسة المشروعات تعثر 2007سنة ACMتحليل
الميزانية • تجاوز %13نسبةالتسليم • موعد تجاوز %20نسبةالمطلوبة • الخصائص في النقص %7نسبة
حسابية* متوسطات : كتاب* BEGINNING APPLICATION LIFECYCLE MANAGEMENTالمصدر
تفشل؟ أو المشروعات تتعثر لماذا
THE MYTHICAL MAN-MONTHالبرمجيات • أزمة يناقش الكتابسنة • األول المشكالت 1975اإلصدار من كثير من تعاني الصناعة زالت ال و م
!! ذكرها التي•: , ويكيبيديا على ملخصه قراءة األقل على أو القراءة يستحق الكتاب
://HTTPS . . / / _ _ -EN WIKIPEDIA ORG WIKI THE MYTHICAL MAN MONTHالفصل قراءة !19و الكتاب, من األول اإلصدار ملخص فإنه
الكالسيكية البرمجيات أزمة 1تجليات
الناس • و الوقت تبادلية THE MYTHICAL MAN-MONTHخرافةتأخرا • ستزيده المتأخر للمشروع أفراد إضافةفي • يولد !9الطفل , الوالدة عن المسئولين النساء عدد عن النظر بغض أشهر
التصور • تماسك أو األنظمة CONCEPTUAL INTEGRITYوحدة تصميم في االعتبارات أهم•CODING STANDARDS? – UNIFIED TOOLSET - CONSISTENT USABLE USER INTERFACES... - إلخالتحديث • و الصيانة صعوبة إلى يؤدي التصور وحدة عدم
الثاني • النظام SECOND SYSTEM EFFECTتأثير• ! وقعت! التي األخطاء كل تالفي ستحاول ألنك اإلطالق على األخطر هو النوع نفس من بتصميمه تقوم نظام ثاني انتبه
, الالزم عن زائدة هندسته نظاما النتيجة ستكون و األول النظام في !OVER-ENGINEEREDفيها
الكالسيكية البرمجيات أزمة 2تجليات
بابل • BABEL SYNDROMEمتالزمةالتواصل • ضعف هو الكبيرة المشروعات لفشل األسباب أهم التنسيق COMMUNICATIONأحد بالتالي ORGANIZATIONو
التغير • THE ONLY CONSTANCY IS CHANGE ITSELFثبات• , , له استعد و نفسك أهّل لكن و محالة ال قادم فإنه قدومه عدم تتوقع أو التغير تحارب ال• , , , , ذلك كل ربما و االستخدام صعب سيكون ربما بطيئا سيكون ربما ضخما سيكون ربما سيفشل غالبا نظام المقترح أول
التجريبي: = المشروع فكرة لالستبدال جاهزا نظاما ابن , PILOT PROJECTالقديم : قد. و بالتدريج النظام ابن الجديد المقترحالتجريبية النسخ اآلن BETA VERSIONSصارت شائعة
فضية • رصاـصة توجد NO SILVER BULLETال•] [ , األصلية الفكرة من تصرف و بتبسيط المشكالت كل يناسب واحد حل أو سحرية حلول توجد ال
الكالسيكية البرمجيات أزمة 3تجليات
البرمجية • !: SOFTWARE BUGSاألخطاء واّلدة •FIXING A DEFECT HAS A SUBSTANTIAL (20 TO 50 PERCENT) CHANCE OF INTRODUCING ANOTHER .عند
( , من كبيرة احتمالية هناك فإن ما برمجي خطأ !50إلى 20تصحيح أخرى%( أخطاء الستحداثالمراجعة • اختبارات أن التأكد من ! ] REGRESSION TESTSالبد هذا الحظ برمجي لخطأ تصحيح كل بعد صحيح بشكل تعمل
سنة [!!!1975الكالمالكوارث • واحدة: HATCHING CATASTROPHESتفريخ دفعة ليس و بالتدريج تحدث الكوارث
• , : حالة تقارير و قرار اتخذا منها يلزم استثنائية معلومات المعلومات من لنوعين يحتاج مدير و STATUS REPORTSكل للمتابعة. للمشكالت المبكر اإلنذار
• , التالوم من الخالية اآلمنة , BLAME-FREEالبيئة أوال, ) سيخبرك يخف لم إن انسيابي بشكل المعلومات تدفق و الشفافية تضمنبأول!(
التسليم • مواعيد تحديد هو الصحيحة الحالة معرفة لضمان شيء . DEADLINESأفضل المستمرة المتابعة و بها االلتزام محاولة و. التسليم موعد نحو للتقدم
البرمجيات فشل أسبابالواقعية • غير أو الغامضة األهدافالمطلوبة • الموارد تقدير في الخطأمستمر • بشكل المشروع حالة متابعة POOR REPORTING OF PROJECT STATUSعدمالمخاطر • إدارة في الفشلالتواصل • POOR COMMUNICATIONضعفناضجة • غير تقنيات على IMMATURE TECHNOLOGIESاالعتمادالمشروع • تعقيدات إدارة في الفشلالتطوير • في المتقنة غير أو السيئة HACKING-DRIVEN DEVELOPMENTالممارساتاإلداري • الفقر أو الضعفالمصلحة • أصحاب المتعارضة STAKEHOLDERSسياساتالسوق • ضغط
. , , تنظيمية و إدارية و فنية مجتمعة أسباب لعدة إنما واحد لسبب عادة الفشل يحدث ال : HTTP://SPECTRUM.IEEE.ORG/COMPUTING/SOFTWARE/WHY-SOFTWARE-FAILSالمصدر*
المشروعات؟ تنجح لماذا
المشروع حجم 1تأثيرمجلة • أجرتها التي الدراسة ACMفي
THE IMPACT OFبـعنوان 2007سنة SIZE AND VOLATILITY ON IT
PROJECT PERFORMANCE• , فرص زادت المشروع حجم زاد كلما
فشله أو تعثره• . فيه المبذول بالمجهود الحجم قياس
األشهر = × عدد األشخاص عدد المجهود
المشروع حجم 2تأثير
ستانديتش • مؤسسة تقرير STANDISHفيCHAOS REPORT 2015لسنة
لسنة • المشروع حجم قياس مـعيار أعلم السنة, 20015 معيار يعتبر 2013لكن كان
من أقل تتكلف التي مليون 1المشروعات , من أكثر تتكلف التي و صغيرة 10دوالر
ـكبيرة دوالر مليونhttp//:المصدر: . . / / - -2015www infoq com articles standish chaos
المشروع مواصفات تعقد REQUIREMENTSتأثيرCOMPLEXITY
•. تعقده مع يزيد المشروع فشل أو تعثر احتمال أن إلى يشير السابق التقرير نفس
المشروع تنفيذ زمن تأثيرمجلة • أجرتها التي الدراسة سنة ACMفي
THE IMPACT OF SIZEبعنوان 2007AND VOLATILITY ON IT PROJECT
PERFORMANCEفرص • زادت المشروع تنفيذ زمن زاد كلما
فشله و تعثرهمن • أكثر المشروع زمن كان تزيد 18إذا
! جدا الفشل احتمالية
الفريق حجم تأثيرمجلة • أجرتها التي الدراسة سنة ACMفي
THE IMPACT OF SIZE ANDبعنوان 2007VOLATILITY ON IT PROJECT
PERFORMANCEعن • الفريق حجم زاد احتمالية, 20إذا زادت
جدا فشله و تعثرهمن • متقاربة 20أقل التعثر احتمالية تقريبافريدريك • قاله ما مع متوافقة النتائج هذه
كتابه في -THE MYTHICAL MANبروكسMONTH سنة للمشوع: 1974من أفراد إضافة
! تأخرا إال تزيده لن المتأخر
الرؤية وضوح تأثير
المتطلبات • في التغير مع طرديا تتناسب الفشل و التـعثر احتمالية أن ذكرت السابقة الدراسة نفسREQUIREMENTS CHANGING
• : كتاب الدراسة BEGINNING APPLICATION LIFECYCLE MANAGEMENTمصدر
المتبعة المنهجية PROCESS 1تأثيرستانديتش • مؤسسة تقرير
STANDISH CHAOS REPORT 2015لسنة
المتبعة المنهجية PROCESS 2تأثير• + . سنة سوفت آمبي مؤسسة دوبز د مجلة تقرير
2013) بتصرف )المرنة • المنهجات باتباع أعلى النجاح احتماليات
AGILE التقليدية المنهجيات TRADITIONALـمناالرتجالية AD-HOCأو
المنهجات • باتباع أقل الفشل و التعثر احتمالياتالمنهجيات AGILEالمرنة من
االرتجالية TRADITIONALالتقليدية -ADأوHOC
http://www.ambysoft.com/surveys/success2013.htmlالمصدر:
! للطميات ال
المرنة • البرمجة حركة ظهور قبل مخدومة تكن لم البرمجيات صناعة أن AGILE SOFTWAREاالدعاءDEVELOPMENT! خاطيء – - لكنـه و شائع مدخل العرض بداية في قدمنا كما
•! , جديدة قديمة مشكالت ـمن تخلو لم إن و حقيقية أزمة من تعاني ال البرمجيات صناعة أن تبين اإلحصاءات•: النجاح أسباب أهم خالصة
مصري !! – • مثل سكر« تاكل نملة »عيشقصير – – • زمن صغير فريق صغير المشروع
•GO AGILE!• , , هذه العام االتجاه فهي الخاطيء المدخل غير من لكن و بالفعل المرنة البرمجة حركة نجاح تبين اإلحصاءات
األيام...
المرنة؟ البرمجة أساليب شيوع مدى 1ما• . مع دوبز د مجلة تجريه الذي االستبيان نتيجة
لسنة سوفت آمبي 2014مؤسسة
HTTP//:المصدر: •. . / /WWW AMBYSOFT COM SURVEYS S
2014 2.TATEOFITUNION Q HTML
المرنة؟ البرمجة أساليب شيوع مدى 2مافورستر • مؤسسة نشرتها دراسة :2011سنة FORRESTERفي بعنوان
WATER-SCRUM-FALL IS THE REALITY OF AGILE FOR MOST ORGANIZATIONS TODAYالخالصة: •
• , خالصة ليست لكنها شائعة المرنة البرمجة AGILE IS POPULAR BUT NOT PUREأساليب• : الدراسة عليه أطلقت ما هو شيوعا المناهج و WATER-SCRUM-FALLأكثر التقليدية األساليب من هجين هي و
سقرام سيئا SCRUMأسلوب أو حسنا ليس هذا و
تبنتها التي المؤسسات في المرنة البرمجة تطبيق تأثير• . مع دوبز د مجلة تجريه الذي االستبيان نتيجة
لسنة سوفت آمبي 2014مؤسسة
HTTP//:المصدر: •. . / /WWW AMBYSOFT COM SURVEYS S
2014 2.TATEOFITUNION Q HTML
#EndOfText ;-)
Recommended