إدارة مشاريع البرمجيات

إدارة مشاريع البرمجيات هي عملية تخطيط وقيادة مشاريع البرمجيات. ^{[ 1 ]} وهي فرع من فروع إدارة المشاريع يتم فيه تخطيط مشاريع البرمجيات وتنفيذها ومراقبتها والتحكم فيها.

في سبعينيات وثمانينيات القرن الماضي، شهدت صناعة البرمجيات نموًا سريعًا، إذ سرعان ما أدركت شركات الحاسوب التكلفة المنخفضة نسبيًا لإنتاج البرمجيات مقارنةً بإنتاج الأجهزة والدوائر الإلكترونية. ولإدارة جهود التطوير الجديدة، طبّقت الشركات أساليب إدارة المشاريع الراسخة، إلا أن جداول المشاريع تأخرت خلال التجارب، لا سيما عند حدوث لبس في المنطقة الرمادية بين مواصفات المستخدم والبرمجيات المُسلّمة. ولتجنب هذه المشكلات، ركّزت أساليب إدارة مشاريع البرمجيات على مطابقة متطلبات المستخدم مع المنتجات المُسلّمة، في أسلوب يُعرف الآن بنموذج الشلال .

مع نضوج الصناعة، أظهر تحليل إخفاقات إدارة مشاريع البرمجيات أن الأسباب الأكثر شيوعًا هي: ^{[ 2 ] [ 3 ] [ 4 ]}

1. عدم كفاية مشاركة المستخدم النهائي
2. ضعف التواصل بين العملاء والمطورين والمستخدمين ومديري المشاريع
3. أهداف المشروع غير واقعية أو غير محددة بوضوح
4. تقديرات غير دقيقة للموارد المطلوبة
5. متطلبات ومواصفات النظام غير المحددة بشكل جيد أو غير المكتملة
6. ضعف الإبلاغ عن حالة المشروع
7. المخاطر التي تتم إدارتها بشكل سيئ
8. استخدام التكنولوجيا غير الناضجة
9. عدم القدرة على التعامل مع تعقيد المشروع
10. ممارسات التطوير غير المتقنة
11. سياسات أصحاب المصلحة (مثل غياب الدعم التنفيذي، أو السياسات بين العميل والمستخدمين النهائيين)
12. الضغوط التجارية

تُظهر العناصر الخمسة الأولى في القائمة أعلاه صعوبة تحديد احتياجات العميل بدقة تُمكّن من توفير الموارد المناسبة لتحقيق أهداف المشروع المرجوة. تُعدّ أدوات إدارة مشاريع البرمجيات المتخصصة مفيدة، بل وضرورية في كثير من الأحيان، لكن جوهر إدارة مشاريع البرمجيات يكمن في تطبيق المنهجية الصحيحة، ثم استخدام الأدوات لدعمها. فبدون منهجية، تصبح الأدوات عديمة الفائدة. منذ ستينيات القرن الماضي، طوّرت شركات البرمجيات العديد من منهجيات إدارة مشاريع البرمجيات الخاصة بها لاستخدامها الخاص، كما طوّرت شركات الاستشارات الحاسوبية منهجيات مماثلة لعملائها. واليوم، لا تزال منهجيات إدارة مشاريع البرمجيات في طور التطور، لكن الاتجاه السائد حاليًا هو الابتعاد عن نموذج الشلال، والتوجه نحو نموذج تسليم مشاريع أكثر دورية يُحاكي عملية تطوير البرمجيات.

تركز عملية تطوير البرمجيات بشكل أساسي على الجانب الإنتاجي لتطوير البرمجيات ، وليس على الجانب التقني، مثل أدوات البرمجيات . وتهدف هذه العمليات بالدرجة الأولى إلى دعم إدارة تطوير البرمجيات، وعادةً ما تُركز على تلبية احتياجات العمل. ويمكن إدارة العديد من عمليات تطوير البرمجيات بطريقة مشابهة لعمليات إدارة المشاريع العامة. ومن الأمثلة على ذلك:

• التواصل الفعال وإدارة النزاعات وحلها . يُعد التواصل النشط والمتكرر والصادق العامل الأهم في زيادة احتمالية نجاح المشاريع وتخفيف حدة المشكلات. ينبغي على فريق التطوير السعي لإشراك المستخدمين النهائيين وتشجيعهم على تقديم آرائهم في عملية التطوير. فعدم إشراك المستخدمين قد يؤدي إلى سوء فهم المتطلبات، وعدم مراعاة احتياجات العملاء المتغيرة، وتوقعات غير واقعية من جانب العميل. يحتاج مطورو البرامج والمستخدمون ومديرو المشاريع والعملاء والجهات الراعية للمشروع إلى التواصل بانتظام وبشكل متكرر. تُمكّن المعلومات المُستقاة من هذه المناقشات فريق المشروع من تحليل نقاط القوة والضعف والفرص والتهديدات (SWOT) واتخاذ الإجراءات اللازمة للاستفادة من الفرص وتقليل التهديدات. حتى الأخبار السيئة قد تكون مفيدة إذا تم إبلاغها مبكرًا نسبيًا، لأنه يمكن التخفيف من حدة المشكلات إذا لم يتم اكتشافها بعد فوات الأوان. على سبيل المثال، قد تكشف المحادثات غير الرسمية مع المستخدمين وأعضاء الفريق وأصحاب المصلحة الآخرين عن المشكلات المحتملة في وقت أبكر من الاجتماعات الرسمية. يجب أن تتسم جميع الاتصالات بالنزاهة الفكرية والأصالة، كما أن النقد البناء والمتكرر والعالي الجودة لأعمال التطوير ضروري، شريطة أن يُقدم بأسلوب هادئ ومحترم وبنّاء ، بعيدًا عن الاتهامات والغضب. يُعد التواصل غير الرسمي والمتكرر بين المطورين والمستخدمين النهائيين، وبين مديري المشاريع والعملاء، ضروريًا للحفاظ على أهمية المشروع وفائدته وفعاليته للمستخدمين النهائيين، وضمن حدود ما يمكن إنجازه. يُعد التواصل الفعال بين الأفراد وإدارة النزاعات وحلها مفتاحًا لإدارة مشاريع البرمجيات. لا يمكن لأي منهجية أو استراتيجية لتحسين العمليات التغلب على المشكلات الخطيرة في التواصل أو سوء إدارة النزاعات بين الأفراد. علاوة على ذلك، تتحسن النتائج المرتبطة بهذه المنهجيات واستراتيجيات تحسين العمليات مع تحسين التواصل. يجب أن يركز التواصل على ما إذا كان الفريق يفهم ميثاق المشروع وما إذا كان يحرز تقدمًا نحو تحقيق هذا الهدف. يجب على المستخدمين النهائيين ومطوري البرامج ومديري المشاريع طرح الأسئلة الأساسية والبسيطة بشكل متكرر، والتي تساعد في تحديد المشكلات قبل أن تتفاقم إلى كوارث وشيكة. على الرغم من أن مشاركة المستخدم النهائي والتواصل الفعال والعمل الجماعي ليست كافية بحد ذاتها، إلا أنها ضرورية لضمان تحقيق نتيجة جيدة، وغيابها سيؤدي حتماً إلى نتيجة سيئة. ^{[ 3 ] [ 4 ] [ 5 ]}
• إدارة المخاطر هي عملية قياس أو تقييم المخاطر ، ثم وضع استراتيجيات لإدارتها. تشمل الاستراتيجيات المتبعة عمومًا نقل المخاطر إلى طرف آخر، أو تجنبها، أو الحد من آثارها السلبية، أو قبول بعض أو كل عواقبها. تبدأ إدارة المخاطر في إدارة مشاريع البرمجيات بدراسة جدوى المشروع، والتي تتضمن تحليلًا للتكلفة والعائد ، بالإضافة إلى قائمة بخيارات بديلة في حال فشل المشروع، تُعرف بخطة الطوارئ .
  • يُعدّ إدارة الفرص فرعاً من إدارة المخاطر ، وهو يعني الشيء نفسه، إلا أن نتيجة المخاطرة المحتملة ستكون إيجابية بدلاً من سلبية. ورغم أن التعامل معهما نظرياً يتم بنفس الطريقة، فإن استخدام مصطلح "الفرصة" بدلاً من مصطلح "المخاطرة" الذي يحمل دلالة سلبية نوعاً ما، يُساعد الفريق على التركيز على النتائج الإيجابية المحتملة لأي سجل مخاطر في مشاريعهم، مثل المشاريع الفرعية، والمكافآت غير المتوقعة، والموارد الإضافية المجانية.
• إدارة المتطلبات هي عملية تحديد المتطلبات واستخلاصها وتوثيقها وتحليلها وتتبعها وترتيب أولوياتها والاتفاق عليها، ثم التحكم في التغييرات وإبلاغ أصحاب المصلحة المعنيين. تُعد إدارة المتطلبات، التي تشمل تحليل المتطلبات ، جزءًا أساسيًا من عملية هندسة البرمجيات ، سواءً لأنظمة الحاسوب الجديدة أو المُعدّلة ^{[ 1 ]} . حيث يقوم محللو الأعمال أو مطورو البرمجيات بتحديد احتياجات العميل ومتطلباته، وبعد تحديد هذه المتطلبات، يصبحون قادرين على تصميم الحل.
• إدارة التغيير هي عملية تحديد وتوثيق وتحليل وترتيب أولويات التغييرات في نطاق المشروع (إدارة المشروع) ، ثم التحكم في هذه التغييرات وإبلاغ أصحاب المصلحة المعنيين بها. يُعد تحليل تأثير التغيير على النطاق الجديد أو المُعدَّل، والذي يشمل تحليل المتطلبات على مستوى التغيير، جزءًا أساسيًا من عملية هندسة البرمجيات ؛ حيث يقوم محللو الأعمال أو مطورو البرمجيات بتحديد الاحتياجات أو المتطلبات المُعدَّلة للعميل؛ وبعد تحديد هذه المتطلبات، يصبحون قادرين على إعادة تصميم الحل أو تعديله. نظريًا، يمكن لكل تغيير أن يؤثر على الجدول الزمني وميزانية مشروع البرمجيات، وبالتالي، بحكم التعريف، يجب أن يشمل تحليلًا للمخاطر والفوائد قبل الموافقة عليه.
• إدارة تكوين البرمجيات هي عملية تحديد وتوثيق نطاق المنتج البرمجي قيد التطوير، بما في ذلك جميع المنتجات الفرعية والتغييرات، وتمكين التواصل بشأنها مع الجهات المعنية. وتشمل العمليات المستخدمة عمومًا التحكم في الإصدارات ، واتفاقية التسمية (في البرمجة) ، واتفاقيات أرشفة البرمجيات.
• إدارة الإصدارات هي عملية تحديد وتوثيق وترتيب أولويات إصدارات البرامج والاتفاق عليها، ثم التحكم في جدول الإصدارات وإبلاغ الجهات المعنية. تتيح معظم مشاريع البرامج الوصول إلى ثلاث بيئات برمجية يمكن إصدار البرامج إليها: التطوير، والاختبار، والإنتاج. في المشاريع الضخمة، حيث تحتاج الفرق الموزعة إلى دمج أعمالها قبل إصدارها للمستخدمين، غالبًا ما تتوفر بيئات اختبار إضافية، تُسمى اختبار الوحدة ، أو اختبار النظام ، أو اختبار التكامل ، قبل إصدار البرنامج لاختبار قبول المستخدم (UAT).
  • يُعدّ إدارة البيانات أحد فروع إدارة الإصدارات التي تحظى باهتمام متزايد ، إذ من البديهي أن المستخدمين لا يستطيعون الاختبار إلا باستخدام البيانات التي يعرفونها، والبيانات "الحقيقية" موجودة فقط في بيئة البرمجيات المسماة "بيئة الإنتاج". لذا، لاختبار عملهم، غالبًا ما يضطر المبرمجون إلى إنشاء "بيانات تجريبية" أو "نماذج بيانات". تقليديًا، كانت تُستخدم الإصدارات القديمة من نظام الإنتاج لهذا الغرض، ولكن مع ازدياد اعتماد الشركات على المساهمين الخارجيين في تطوير البرمجيات، قد لا تُتاح بيانات الشركة لفرق التطوير. في البيئات المعقدة، يمكن إنشاء مجموعات بيانات ثم نقلها عبر بيئات الاختبار وفقًا لجدول زمني لإصدار الاختبار، تمامًا كما هو الحال مع جدول إصدار البرمجيات العام.
• تُعدّ الصيانة والتحديث عمليةً أساسيةً تُراعي متطلبات العملاء واحتياجاتهم. فمن المؤكد أنهم سيكتشفون أخطاءً برمجية، وقد يطلبون ميزاتٍ جديدةً ووظائفَ مختلفةً وتحديثاتٍ إضافية. لذا، يجب التحقق من جميع هذه الطلبات وتلبيتها بما يضمن رضا العملاء.

يهدف تخطيط المشروع إلى تحديد نطاقه، وتقدير حجم العمل المطلوب، ووضع جدول زمني له . يبدأ تخطيط المشروع بتحديد المتطلبات التي تُعرّف البرمجيات المراد تطويرها. ثم تُوضع خطة المشروع لوصف المهام اللازمة لإنجازه. أما تنفيذ المشروع فهو عملية إنجاز المهام المحددة في خطة المشروع.

يهدف رصد المشروع والتحكم فيه إلى إبقاء الفريق والإدارة على اطلاع دائم بتقدم المشروع. في حال انحراف المشروع عن الخطة، يمكن لمدير المشروع اتخاذ الإجراءات اللازمة لتصحيح المشكلة. يشمل رصد المشروع والتحكم فيه اجتماعات دورية لمتابعة سير العمل مع الفريق. وعند الحاجة إلى إجراء تغييرات، يُستخدم نظام إدارة التغيير لضمان تحديث المنتجات باستمرار.

في مجال الحوسبة، يُشير مصطلح "المشكلة" إلى وحدة عمل تهدف إلى تحقيق تحسين في النظام. ^{[ 6 ]} قد تكون المشكلة خطأً برمجيًا ، أو ميزة مطلوبة ، أو مهمة، أو نقصًا في التوثيق ، وما إلى ذلك.

على سبيل المثال، كان موقع OpenOffice.org يُطلق على نسخته المُعدّلة من Bugzilla اسم IssueZilla. اعتبارًا من سبتمبر 2010ويطلقون على نظامهم اسم "متتبع المشكلات". ^{[ 7 ]}

باعتبارها فرعاً من فروع إدارة المشاريع، ينظر البعض إلى إدارة تطوير البرمجيات على أنها شبيهة بإدارة التصنيع ، والتي يمكن أن يقوم بها شخص يمتلك مهارات إدارية، لكنه يفتقر إلى مهارات البرمجة. ويعارض جون سي. رينولدز هذا الرأي، ويجادل بأن تطوير البرمجيات هو عمل تصميمي بحت ، ويقارن بين المدير الذي لا يجيد البرمجة ورئيس تحرير صحيفة لا يجيد الكتابة . ^{[ 12 ]}

عام

• 16326:2019(E) - معيار دولي ISO/IEC/IEEE - هندسة النظم والبرمجيات - عمليات دورة الحياة - إدارة المشاريع . 2019. doi : 10.1109/IEEESTD.2019.8932690 . ISBN 978-1-5044-6299-0.
• 1058-1998 - معيار IEEE لخطط إدارة مشاريع البرمجيات . 1998. doi : 10.1109/IEEESTD.1998.88822 . ISBN 978-0-7381-1448-4.
• جالوت، بانكاج (2002). إدارة مشاريع البرمجيات عمليًا . أديسون-ويسلي. ISBN 0-201-73721-3.
• مورالي شيموتوري، توماس إم. كاجلي الابن (2010). إدارة مشاريع البرمجيات: أفضل الممارسات والأدوات والتقنيات . دار نشر جيه. روس. رقم ISBN 978-1-60427-034-1.

• الوسائط المتعلقة بإدارة مشاريع البرمجيات على ويكيميديا ​​كومنز

• روبرت فريز (16 ديسمبر 2003). "نجاح المشاريع وفشلها: ما هو النجاح، وما هو الفشل، وكيف يمكنك تحسين فرص نجاحك؟" . جامعة ميسوري - سانت لويس . تاريخ الاسترجاع: 13 مايو 2015 .