لوحة المتصدرين

يتوجه العالم بخطى حثيثة نحو حقبة ما بعد الثورة الرقمية، فقد غيرت هذه الثورة طريقة رؤيتنا للواقع والمستقبل ودفعتنا إلى حدود جديدة في شتى المجالات العلمية والاقتصادية والاجتماعية. لهذا تسعى الفعاليات البشرية بكافة أشكالها إلى التماشي مع هذه الثورة والاستفادة مما تتيحه من تقنيات لتطوير قدراتها الذاتية ومكاسبها في نفس الوقت. لقد أضحت عملية التحول الرقمي والتطوير المستمر لوسائل العمل والاتصال ميزة هذه الحقبة وأساسها، وغدت صناعة البرمجيات وتطوير الأنظمة المعلوماتية المحرك الأساسي لهذه المرحلة جنبًا إلى جنب مع تطور البنية التحتية لتقديم الخدمات الرقمية بالشكل الأكفأ والأسرع. ولهذا السبب أخذت هذه الصناعة بالنضوج اعتمادًا على مفاهيم ومسارات واستراتيجيات مدروسة وواضحة في التخطيط لها وتحليل متطلباتها ثم تصميمها وتنفيذها ضمن حلقة متكاملة من المراحل المتلاحقة لتلبي الغرض من بنائها وإنشائها. ونظرًا لاعتماد الأعمال بكل أشكالها على صناعة البرمجيات وتطوير الأنظمة الرقمية فلن يكون أمام هذه الصناعة هامش للخطأ مهما صَغُر لأن التكلفة على الصعيدين المادي والزمني ستكون باهظة جدًا. تحدثنا في مقال "مدخل إلى تطوير البرمجيات" عن المجال وعملية تطوير البرمجيات عمومًا، وأما الهدف من هذا المقال هو الوقوف على دورة الحياة التي يجب أن تسلكها عملية تطوير البرمجيات حتى يكون المنتج النهائي فعالًا ومحققًا للغاية التي صُمم لأجلها بأدنى هامش للخطأ انطلاقًا من الفكرة وحتى التنفيذ والصيانة. كما سيبحث في أهم الاستراتيجيات المتبعة في إدارة دورة حياة تطوير البرمجيات Software Development Life Cycle واختصارًا SDLC. كما يساعدك هذا المقال في تنمية معارفك ومهاراتك في تحليل الأنظمة إن كنت تفكر فيها كمهنة مستقبلية. من أين تأتي الأفكار؟ فما يخلق البرمجيات هو الحاجة لها، وتظهر الحاجة إلى بناء نظام معلوماتي جديد لإدارة نشاط معين عندما يبدأ هذا النشاط أو العمل بالمعاناة جراء أسباب متنوعة منها: انخفاض الحصة السوقية لمنتجاته. ضعف في الخدمات التي يقدمها لعملائه. ظهور منافسين جدد يستغلون تقنيات أحدث في إدارة أعمالهم. مشاكل في المنظومة القائمة وانخفاض كفاءتها. وقد تكون الحاجة إلى المنظومة الجديدة رؤية مستقبلية لواقع العمل والرغبة في تحسين واقعه: الرغبة في الوصول إلى عملاء جدد أو أسواق جديدة. مواكبة أكثر التقنيات انتشارًا وأحدثها كالحوسبة السحابية ومنصات البيانات الضخمة أو الانتقال إلى تطبيقات الهواتف الذكية. تقديم ابتكارات واختراقات ثورية تبقي الشركات التقنية في حيز المنافسة والهيمنة على الصناعة. لا يمكن لأي كان أن يتخذ قرار تطوير برمجيات المنظومة المعلوماتية القائمة as-is system أو استبدالها بمنظومة جديدة to-be system في الجهة التي تحتاج إلى ذلك، بل يأتي هذا القرار عادة عن أشخاص تقنيين أو غير تقنيين على تماس مباشر مع المنظومة ومع أصحاب القرار. يُدعى هؤلاء بالمعنيين أو أصحاب المصلحة stakeholders في بناء أو تطوير المنظومة وقد يكون هؤلاء: مالكو أنظمة مشرفون على تشغيل أنظمة مبرمجون مصممو ومحللو أنظمة مستشارون أو مزودون للخدمات المعلوماتية يمتلك هؤلاء الخبرة والدراية التي تؤهلهم لمعرفة الإيجابيات والسلبيات في المنظومات القائمة واستشعار الفرص الجديدة التي قد يأتي بها التغيير. دورة إدارة تطوير المنتجات احترف إدارة تطوير المنتجات الرقمية بدءًا من التخطيط وتحليل السوق وحتى إطلاق منتج مميز وناجح اشترك الآن هل نبدأ بكتابة الشيفرة مباشرة؟! عندما نتحدث عن تطوير منظومة برمجية لا نتحدث عن تطبيق بسيط لعرض منتجات أو لإجراء اتصال مع قاعدة بيانات بسيطة، بل منظومة متكاملة تضم عددًا كبيرًا من الحزم البرمجية التي تنفذ مهام مختلفة وتتكامل مع بعضها لتلبي المتطلبات المتوقعة من هذه المنظومة. وفي هذا السياق، لا يمكن بأي شكل من الأشكال أن تعتبر عملية بناء المنظومات البرمجية عملية بديهية سهلة التنفيذ. يتطلب بناء المنظومات المركبة عملًا هائلًا وتخطيطًا دقيقًا للمتطلبات التي ينبغي لهذه المنظومة تنفيذها في المراحل المبكرة قبل اتخاذ القرار النهائي بالمضي في العمل. فهناك قاعدة ذهبية لا بد من إدراكها تنص على أنّ التكلفة ستزداد بشكل أسي مع كل تغيير في متطلبات منظومة برمجية أثناء التنفيذ. والأسوأ من ذلك كله تسليم منظومة غير مكتملة إلى العميل. لم تأتي هذه القاعدة من فراغ، بل من الإخفاقات التي عانتها الكثير من الشركات العالمية، وإليك بعض الأمثلة من الواقع: الشركة العام المنظومة البرمجية الخسارة بالدولار فورد موتورز الأمريكية 2004 شراء منظومة جرى التخلي عنها بعد نشرها مباشرة 400 m$ هيوليت باكارد الأمريكية 2004 منظومة برمجية لتخطيط الموارد كثُرت فيها الأخطاء m160‏$ HRM Inland البريطانية 2004 أخطاء برمجية في المنظومة قادت إلى تحميل ضرائب إضافية 3.45 m$ Sainsburys البريطانية 2004 منظومة لإدارة سلسلة المزودين فشلت بعد النشر مباشرة 527 m$ وزارة الصحة البريطانية 2006 منظومة متكاملة لإدارة الصحة الوطنية وتسجيل المرضى لم تنجح بعد 4 سنوات من التأخير ولم ينجز أكثر من 80% منها. 20 b$ وزارة العدل البريطانية 2007 التخلي عن منظومة لتسجيل ومراقبة المدانين 245 m$ وكالة الحدود البريطانية 2009 تأخير في تسليم منظومة إدارة الحدود الإلكترونية حتى 2015 1.7 b$ BBC البريطانية 2014 فشل مشروع رقمنة أرشيف الإذاعة نظرًا للتخبط وضعف التخطيط. 153 m$ فالبدء إذًا في كتابة الشيفرة بمجرد أن تستشف فكرة المشروع سيقودك إلى الفشل لا محالة. لهذا لا بدّ من أن يمر مشروعك ضمن سلسلة من المراحل التي ينضج فيها وتتخذ القرارات التحليلية والتصميمة الصحيحة. دورة حياة البرمجيات تمر البرمجيات والأنظمة المعلوماتية عمومًا أثناء تطويرها بأربعة مراحل رئيسة وفي كل مرحلة مجموعة من الخطوات. ينتج عن كل مرحلة مجموعة من المخرجات deliveries تُبنى عليها مراحل لاحقة. هذه المراحل الأربعة هي: التخطيط planning التحليل analysis التصميم design التنفيذ implementation سنتحدث باختصار عن كل مرحلة وسنتكلم بإسهاب عن كل مرحلة في مقالات لاحقة. مرحلة التخطيط لبناء منظومة برمجية لا بد في هذه المرحلة من الإجابة على الأسئلة التالية: لم علينا بناء هذه المنظومة أو هذا البرنامج؟ ما الذي ستقدمه هذه المنظومة إلى الفعالية التي طلبتها أو للجهة التي تنتجها؟ هل يمكننا بناء هذه المنظومة؟ كم يستغرق بناؤها؟ وكما أشرنا سابقًا أن لكل مرحلة مجموعة من الخطوات التي تمر بها حتى تكتمل، وعادة ما تضم مرحلة التخطيط خطوتين أساسيتين هما: تهيئة المشروع Project initiation: يٌقصد بتهيئة المشروع هو التخطيط المبدئي له، وتضم هذه الخطوة مجموعة خطوات فرعية هي: تحديد أهمية المشروع وضرورة بنائه بالنسبة للعميل أو صاحب المصلحة المعني مباشرة بتطويره. دراسة جدوى المشروع Project feasibility بالتشاور المباشر بين محلل الأنظمة والعميل وتكون الدراسة على ثلاثة أصعدة تقنية تحدد إمكانية بناء المنظومة، واقتصادية تحدد ما إن كان ضروريًا بناء المنظومة الجديدة أو تحسين القديمة، وتنظيمية تحدد ما إن كان سيلقى المنتج الجديد ترحيبًا من مستخدميه وهل يتماشى مع أسلوب العمل في الجهة التي طلبت بناءه. دراسة المخاطر، وتختلف طريقة دراسة المخاطر من شركة إلى أخرى إلا أنها تسعى عمومًا إلى تحديد مصدر الخطر واحتمالية وقوعه وأثره المتوقع على المنظومة وطريقة تفادي الخطر أو التخفيف من أثره. إدارة المشروع Project management: وهي عملية التحكم بتطوير المشروع خلال مدة محددة بأقل تكلفة للحصول على المنظومة المطلوبة صحيحة وفعالة. يراقب مديرو المشروع عادة العمل ككل ويتحكمون بكل المهمات ويحددون الأدوار الوظيفية وينسقون بينها وتضم هذه الخطوة الخطوات الفرعية التالية: تحديد عدد الموظفين سواء محللي نظم أو مصممين أو مبرمجين. البحث عن المهارات اللازمة لإنجاز كل مهمة من مهام المنظومة. تحفيز فريق العمل لتحقيق الأهداف. الحد بين النزاعات والخلافات وتقريب وجهات النظر في فريق العمل. اقتراح التقنيات اللازمة لإنجاز العمل. وضع خطة عمل تعتمد على الاستراتيجية المتبعة في إدارة دورة حياة المنظومة. أما مخرجات هذه المرحلة فتأتي في مستندين الأول يضم خطة العمل والثاني مستند دراسة الجدوى والمخاطر ويعرض على الشخص المسؤول أو على لجنة القبول acceptance committee فإما أن يُقبل أو يُرفض أو يؤجل وفقًا للفائدة المضافة موازنة بالمخاطر. مرحلة تحليل المنظومة لا بد أن تتمكن هذه المرحلة من الإجابة عن الأسئلة التالية: ماذا نتوقع من المنظومة؟ ما هو المطلوب منها؟ من سيستخدم المنظومة الجديدة أو المطوّرة؟ أين ومتى ستُستخدم المنظومة الجديدة؟ تضم هذه المرحلة خطوتين رئيسيتين: تحديد متطلبات المنظومة بناء نماذج تحليلية للمنظومة تحديد متطلبات المنظومة define requirements وهي أكثر خطوات هذه المرحلة (إن لم يكن دورة التطوير بأكملها) أهمية وحساسية. إذ يمكن أن نناقش في هذه المرحلة ماهو المطلوب من المنظومة البرمجية وفقًا لرؤية المعنيين بتطويرها على مختلف المستويات والمرجعيات. فالنقاش في هذه المرحلة ووضع التصورات والنماذج سيكون متاحًا إلى أقصى الحدود دون أي آثار سلبية موازنة بالتغييرات التي يُضطر فريق العمل إلى إجرائها في مرحلة التنفيذ، إذ سيرفع ذلك من نسبة فشل المشروع إلى أكثر من 50%. وتتميز هذه المرحلة بأنها تدريجية أي يجري تطوير نماذج عن متطلبات المنظومة تدريجيًا وليس دفعة واحدة كما تتميز بأنها تكرارية أي يكون تحسين النماذج بالتكرار. ما هو المتطلب؟ المتطلب هو تصريح عما يُراد من المنظومة فعله أو تصريح عن الخصائص التي تتمتع بها المنظومة التي نريد بناءها. هنالك نوعان من المتطلبات: متطلبات وظيفية functional ومتطلبات غير وظيفية nonfunctional. أما المتطلبات الوظيفية functional، فتضم التصريحات التي تحدد ما على المنظومة فعله أو تحدد إمكانياتها. وكمثال على المتطلب الوظيفي هو أن تسمح المنظومة للمستخدم مثلًا بتسجيل دخوله إليها فهذا المتطلب يتعلق مباشرة بطريقة عمل المنظومة وبالتالي هو متطلب وظيفي. وأما المتطلبات غير الوظيفية nonfunctional، فتضم تصريحات عن ميزات هذه المنظومة التي لا تتعلق بطريقة عملها. وكمثال عليها أن تعمل المنظومة مثلًا على الحواسب وأن تعمل أيضًا على الهواتف الذكية. كما تجد أحيانًا متطلبات إضافية مثل: متطلبات عمل: وهو تصريح عما يحتاجه العميل. متطلبات مستخدمين: وتضم تصريحات عن طريق استخدام المنظومة. متطلبات منظومة: وتضم تصريحات عن أسلوب وطريقة بناء المنظومة. ينتج عن مرحلة تحديد المتطلبات مستند يُدعى "تصريح تحديد المتطلبات requirements definition statement"ويضم المتطلبات الوظيفية وغير الوظيفية على شكل قائمة مفصّلة قد تُعطى فيها الأولوية لمتطلبات على أخرى إضافة إلى بعض المعلومات الضرورية للخطوات القادمة، كما يحدد هذا المستند ما يُدعى بنطاق عمل أو إطار عمل المنظومة system domain الذي ينبغي العمل في حدوده دون رفع أو تخفيض المتطلبات. بناء نماذج تحليلية للمنظومة يحاول فريق العمل خلال هذه المرحلة بناء نماذج models عن المتطلبات الوظيفية. وتوصِّف هذه المتطلبات مداخل ومخارج كل متطلب وطريقة تنفيذه. وغالبًا ما تُستخدم نماذج حالات الاستخدام use-case model التي توصّف كل وظيفة من وظائف المنظومة ومن سيشارك في إنجاز هذه الوظيفة سواء وظائف أخرى أو مستخدم خارجي، كما تُستخدم نماذج النشاط Activity models لتوصيف تسلسل تنفيذ العمليات التي تحقق وظيفة محددة وطريقة التفاعل المتبادل بين الوظائف المختلفة في المنظومة. فلو كان لدينا مثلًا منظومة برمجية لإدارة صراف آلي ATM ستكون إحدى حالات الاستخدام هو "سحب نقود" وسترتبط حالة الاستخدام هذه بحالة استخدام أخرى "التحقق من هوية المستخدم" ولا بد من وجود مشارك خارجي وهو "مستخدم الصراف". إن ما يمثّل هذه الترابطات هو مخطط حالات الاستخدام أما بالنسبة لمخطط النشاط فسيوُصف على الشكل التالي مثلًا: الصراف: يعرض رسالة ترحيب. المستخدم: يدخل البطاقة. الصراف: يحلل البطاقة ويعرض للمستخدم قائمة الخيارات. المستخدم: يضغط زر "سحب النقود". الصراف: يعرض قائمة بالمبالغ التي يمكن سحبها. المستخدم: يختار المبلغ المطلوب. الصراف: يعدّ النقود ويخرجها. تمثل هذه النماذج على شكل ملف يُدعى توصيف حالات الاستخدام use-case description أو عن طريق مخططات UML -لغة النمذجة الموحدة unified mark language- تُعرف بمخططات حالات الاستخدام ومخططات النشاط. تُبنى بعد تكوين النماذج الوظيفية أيضًا النماذج البنوية التي تستفيد من نماذج حالات الاستخدام وملفات توصيفها في توصيف المتطلبات على شكل أصناف لها خصائص (سمات attributes) وطرق methods وذلك إن كانت استراتيجية التحليل هي استراتيجية كائنية التوجّه object oriented strategy وهي الاستراتيجية الأكثر شيوعًا. تمثّل هذه الأصناف ضمن مخططات تُدعى مخططات الأصناف ويُستفاد منها لاحقًا في عملية برمجة المتطلب الوظيفي. وأخيرًا تُبنى النماذج السلوكية behavioral models وهي نماذج تعبّر عما يجري داخليًا خلف الستار حتى تؤدي المنظومة الوظائف المطلوبة منها ظاهريًا أي كما يراها المستخدم الخارجي. تتشكل هذه النماذج انطلاقًا من النماذج البنيوية والوظيفية لأنها تعبير عن التفاعل بين النماذج البنيوية (الكائنات التي تشكل المنظومة). وتُمثّل النماذج السلوكية باستخدام مخططات UML منها مخطط التتابع sequence diagram التي تمثل تتابع الرسائل بين الكائنات، ومخططات الاتصال communication diagram التي تمثل الطرق التي تسلكها تلك الرسائل ومخططات التوقيت timing diagrams. ينتج عن هذه المرحلة ورقة تُدعى "اقتراح المنظومة system proposal" وتضم تفاصيل عن وظائف المنظومة الجديدة وطريقة إنجازها مُدعّمًا بالنماذج والمخططات التي بنيت في هذه المرحلة وتُرفع إلى لجنة القبول لاتخاذ القرار بالمضي أو إعادة تحليل المتطلبات. مرحلة تصميم المنظومة البرمجية وتجيب هذه المرحلة عن سؤال مهم وهو كيف سنبني المنظومة؟ إذ تُقرر في هذه المرحلة نوعية العتاد الصلب التي ستُستخدم والبرمجيات اللازمة والبنية التحتية لشبكات الاتصالات وواجهات المستخدم وقواعد البيانات ونماذج إرسال البيانات والتقارير. تضم هذه المرحلة الخطوات التالية: وضع استراتيجية التصميم: وفيها يجيب فريق العمل بالتعاون مع الجهة المعنية عن الأسئلة التالية: هل ستُطوّر المنظومة محليًا في الجهة التي تحتاج المنظومة اعتمادًا على كوادرها الخاصة؟ هل ستطور المشروع شركة مختصة أخرى؟ هل ستشتري الشركة حزم برمجية جاهزة تحقق متطلبات مرحلة التحليل؟ تطوير المعمارية الأساسية للمنظومة: بما في ذلك العتاد الصلب والبرمجي وواجهة المستخدم والبنية التحتية لشبكة الاتصال وهل سيتم البناء على البنية التحتية السابقة أم تحتاج المنظومة الجديدة إلى بنية تحتية جديدة كليًا. تطوير مواصفات لقواعد البيانات والملفات: أي تحديد طبيعة البيانات التي تُخزن وحجمها وأين وكيف ستُخزن. تصميم البرمجيات التي ستُبنى: أي ما هي البرامج التي ينبغي للمبرمجين العمل عليها وما وظيفة كل برنامج وما هي علاقته بغيره. ينتج عن هذه المرحلة مجموعة المخرجات التالية: مستندات تصميم المعمارية. مستندات تصميم واجهة المستخدم. مستندات مواصفات قواعد وملفات البيانات. مستند تصميم البرامج. تستخدم هذه المستندات لاحقًا في توجيه مرحلة إنجاز المنظومة. مرحلة إنجاز المنظومة وهي المرحلة الأخيرة من دورة تطوير البرمجيات، وتحظى هذه المرحلة بكامل الانتباه لأنها تعد المرحلة الأطول والأكثر تكلفة. تضم هذه المرحلة الخطوات التالية: بناء المنظومة اختبار المنظومة توثيق المنظومة تركيب المنظومة إدارة التغيير التدريب على استخدام المنظومة الصيانة ودعم المنظومة التقييم الراجع للمشروع بناء المنظومة ويقصد فيها برمجة كل وظيفة من وظائف المنظومة والربط بين هذه البرمجيات وتعتمد بشكل كامل على مخرجات مرحلتي التحليل والتصميم. تُعد هذه المرحلة بأنها الأقل خطرًا على فشل المنظومة ولا يأتي فشل المنظومة نتيجة لضعف البرمجة بل لضعف مخرجات عمليتي التحليل والتصميم. تجري في هذه المرحلة أيضًا عملية توثيق الإجرائيات بدقة للاستفادة منها في خطوات الاختبار والصيانة. اختبار المنظومة تهدف هذه الخطوة إلى كشف أكبر قدر ممكن من العيوب التي قد تتسبب في إخفاق البرنامج، وعادة ماتكون الخطوة الأطول والأكثر تركيزًا في هذه المرحلة لأنه من الصعب إنشاء منظومة خالية تمامًا من العيوب، كما أن عملية البحث والاستقصاء عن جميع العيوب أمر مرهق زمنيًا وماديًا. لتلك الأسباب يجري اختبار المنظومة على مبدأ ما الذي تقدمه فعليًا موازنةً مع ما يتوجب عليها فعله. يختبر فريق متخصص المنظومة بواحدة أو بجميع الطرق التالية: اختبارات الوحدات unit tests: ويجري على دالة أو صنف أو جزء محدد من وحدة برمجية للتأكد من أن الدخل الصحيح يعطي الخرج المطلوب. اختبارات التكامل integration tests: يختبر التفاعل المتبادل بين مجموعة محددة من الأصناف لإنجاز وظيفة محددة. اختبارت المنظومة system tests: يختبر تفاعل جميع الأصناف مع بعضها لإعطاء وظيفة متكاملة للمنظومة دون أخطاء، وهو مشابه لاختبار التكامل لكن على صعيد أوسع. اختبارات القبول acceptance tests: وينفذها المستخدمون النهائيون للمنظومة تحت إشراف عضو أو أكثر من فريق العمل وذلك لتقييم قبول المستخدم لهذه المنظومة الجديدة. توثيق المنظومة وهي عملية ممتدة عبر جميع المراحل لكنها تُنظم في هذه الخطوة وتضم توثيق عن المنظومة بما يساعد المبرمجين والمحللين في بناء وصيانة المنظومة وتوثيق المستخدم الذي يساعده على استثمار المنظومة. وقد يكون التوثيق مرجعيًا لمساعدة المستخدم على إنجاز مهمة محددة أو إجرائيًا لوصف إنجاز خطوة ما أو مواد تعليمية. تركيب المنظومة وتتضمن هذه الخطوة تثبيت العتاد الصلب والبرمجيات اللازمة وفقًا لمعايير المعيارية المقترحة. إدارة التغيير لا يجري الانتقال إلى استخدام المنظومة الجديدة مباشرة بل على مراحل لمساعدة المستخدمين النهائيين على التأقلم معها بأقل توتر ممكن. ولأن لكل تغيير مقاومة لا بد أن يتشارك محللو المنظومة وأصحاب القرار ومديرو المشروع في إدارة مرحلة التحوّل وتوجيه المستخدمين وتحفيزهم على تبني المنظومة الجديدة. التدريب على استخدام المنظومة لا بد في هذه المرحلة من تقديم المهارات اللازمة لاستثمار النظام دون الافتراض المسبق بأن المنظومة سهلة التعلّم. كما ينبغي التركيز في هذه المرحلة على مساعدة المتدرب على تنفيذ المهام الموكلة إليه فقط دون الغوص في تفاصيل وميزات المنظومة الجديدة، فهنا تأتي أهمية وجود توثيق شامل. الصيانة ودعم المنظومة وهي عملية تحسين المنتج البرمجي كي يلبي دائمًا متطلبات العمل، وقد تكون خطوة الصيانة ذات تكلفة عالية. يُكلف بعملية الصيانة عادة محللو الأنظمة والمبرمجون المبتدئون. ويأتي دعم المنظومة عبر خيارات عدة منها: التدريب عند الطلب أو الحاجة. الدعم المباشر عبر الإنترنت: من خلال التوثيق والأسئلة أكثر شيوعًا وحتى المحادثة المباشرة. مكاتب الدعم: وذلك لاستشارة الخبراء مباشرة حول مشاكل محددة بناء على مواعيد مسبقة. التقييم الراجع للمشروع أي تقييم نجاح المشروع أو فشله والطرق الكفيلة بتحسينه وتطويره وأخذ العبر منه. وتنفذ هذه الخطوة عادة وفق مسارين: مراجعة منظومة: والهدف هو موازنة التكلفة والفائدة الحقيقية موازنة مع التكلفة والفوائد المقدرة في مرحلتي التخطيط والتحليل. مراجعة فريق العمل: إذ يقيِّم كل فرد من أفراد فريق العمل أخطاءه ونجاحاته في إنجاز المهام الموكلة إليه. يمكن بعد ذلك لمدير المشروع أن يجمع التقييمات ويضيف إليها بعض التوضيحات والشروحات ليخرج بملف يُدعى "دروس تعلمناها lesson learned" والتي تلعب دورًا مهمًا في تدريب وتعليم الأعضاء الجدد وفي تفادي أية أخطاء مماثلة في مشاريع مستقبلية. خاتمة تعرفنا في هذا المقال على الأساسيات المتبعة في التخطيط لتطوير البرمجيات أو المنظومات المعلوماتية عمومًا ورأينا أهمية التخطيط التدقيق والتحليل لمتطلبات البرمجيات للوصول إلى منتج قادر على الصمود والمنافسة. كما تعرفنا على المراحل الأساسية الأربعة لعملية تطوير المنتجات البرمجية وهي مراحل التخطيط والتحليل والتصميم والتنفيذ، وتعرفنا على مجموعة الأعمال التي ينبغي القيام بها في كل مرحلة والمخرجات التي تنتج عن كل منها وصولًا إلى المنتج النهائي وصيانته ودعمه. اقرأ أيضًا كيف تتجنب كارثة الاستعانة بفريق خارجي في تطوير البرمجيات دليل المبتدئين لمنهجية أجايل Agile الأخطاء السبع القاتلة لأيّ مشروع برمجيات