تطوير البرمجيات

📅 آخر تحديث: ٢٢ يوليو ٢٠٢٦
✍️ نُشر في: ٢٢ يوليو ٢٠٢٦
📷 يحتوي على 8 صور
الموسوعة الحرة

جزء من سلسلة عن
تطوير البرمجيات
الأنشطة الأساسية
النماذج والأنماط
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines
  • v
  • t
  • e

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

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

المنهجيات

مخطط انسيابي لنموذج النمذجة التطورية، نموذج التطوير التكراري [2]

كل من المنهجيات المتاحة هي الأنسب لأنواع محددة من المشاريع، بناءً على الاعتبارات الفنية والتنظيمية والمشروعية والفريقية المختلفة. [3]

  • الطريقة الأكثر بساطة هي "الترميز والإصلاح"، والتي يستخدمها عادةً مبرمج واحد يعمل على مشروع صغير. بعد التفكير لفترة وجيزة في غرض البرنامج، يقوم المبرمج ببرمجته وتشغيله لمعرفة ما إذا كان يعمل. عندما ينتهي، يتم إصدار المنتج. هذه الطريقة مفيدة للنماذج الأولية ولكن لا يمكن استخدامها للبرامج الأكثر تفصيلاً. [4]
  • في نموذج الشلال من أعلى إلى أسفل ، تحدث الجدوى والتحليل والتصميم والتطوير وضمان الجودة والتنفيذ بشكل متسلسل بهذا الترتيب. يتطلب هذا النموذج اكتمال خطوة واحدة قبل أن تبدأ الخطوة التالية، مما يتسبب في حدوث تأخيرات ويجعل من المستحيل مراجعة الخطوات السابقة إذا لزم الأمر. [5] [6] [7]
  • مع العمليات التكرارية ، تتداخل هذه الخطوات مع بعضها البعض لتحسين المرونة والكفاءة والجدولة الأكثر واقعية. بدلاً من إكمال المشروع دفعة واحدة، قد يمر المرء بمعظم الخطوات بمكون واحد في كل مرة. يتيح التطوير التكراري أيضًا للمطورين إعطاء الأولوية للميزات الأكثر أهمية، مما يتيح إسقاط الميزات ذات الأولوية الأقل لاحقًا إذا لزم الأمر. [6] [8] Agile هي إحدى الطرق الشائعة، والمخصصة في الأصل للمشاريع الصغيرة أو المتوسطة الحجم، والتي تركز على منح المطورين مزيدًا من التحكم في الميزات التي يعملون عليها لتقليل مخاطر تجاوز الوقت أو التكلفة. [9] تشمل مشتقات Agile البرمجة المتطرفة و Scrum . [9] يستخدم تطوير البرامج مفتوحة المصدر عادةً منهجية Agile مع التصميم والترميز والاختبار المتزامن، بسبب الاعتماد على شبكة موزعة من المساهمين المتطوعين. [10]
  • إلى جانب Agile، تقوم بعض الشركات بدمج عمليات تكنولوجيا المعلومات (IT) مع تطوير البرمجيات، وهو ما يسمى DevOps أو DevSecOps بما في ذلك أمان الكمبيوتر . [11] يشمل DevOps التطوير المستمر والاختبار ودمج الكود الجديد في نظام التحكم في الإصدار ونشر الكود الجديد وأحيانًا تسليم الكود للعملاء. [12] الغرض من هذا التكامل هو تقديم خدمات تكنولوجيا المعلومات بشكل أسرع وأكثر كفاءة. [11]

تركز العديد من منهجيات البرمجة بشكل كبير على فكرة محاولة اكتشاف مشكلات مثل الثغرات الأمنية والأخطاء في أقرب وقت ممكن ( اختبار التحول إلى اليسار ) لتقليل تكلفة تتبعها وإصلاحها. [13]

في عام 2009، قُدِّر أن 32% من مشاريع البرمجيات تم تسليمها في الوقت المحدد والميزانية المحددة، وبكامل الوظائف. وتم تسليم 44% إضافية، ولكنها كانت تفتقر إلى واحدة على الأقل من هذه الميزات. وتم إلغاء الـ 24% المتبقية قبل الإصدار. [14]

خطوات

تشير دورة حياة تطوير البرمجيات إلى العملية المنهجية لتطوير التطبيقات . [15]

الجدوى

إن مصادر الأفكار الخاصة بمنتجات البرمجيات وفيرة. ويمكن أن تأتي هذه الأفكار من أبحاث السوق بما في ذلك التركيبة السكانية للعملاء الجدد المحتملين، والعملاء الحاليين، وآفاق المبيعات التي رفضت المنتج، وموظفي تطوير البرمجيات الداخليين الآخرين، أو طرف ثالث مبدع. وعادة ما يتم تقييم أفكار منتجات البرمجيات أولاً من قبل موظفي التسويق من أجل الجدوى الاقتصادية، والتوافق مع قنوات التوزيع الحالية، والتأثيرات المحتملة على خطوط المنتجات الحالية، والميزات المطلوبة ، والتوافق مع أهداف التسويق الخاصة بالشركة. وفي مرحلة تقييم التسويق، يتم تقييم افتراضات التكلفة والوقت. [16] ويقدر تحليل الجدوى العائد على الاستثمار للمشروع ، وتكلفة تطويره والإطار الزمني. وبناءً على هذا التحليل، يمكن للشركة اتخاذ قرار تجاري بالاستثمار في مزيد من التطوير. [17] وبعد اتخاذ قرار تطوير البرنامج، تركز الشركة على تسليم المنتج بتكلفة ووقت تقديريين أو أقل، وبمستوى عالٍ من الجودة (أي عدم وجود أخطاء) والوظائف المطلوبة. ومع ذلك، فإن معظم مشاريع البرمجيات تتأخر وأحيانًا يتم تقديم تنازلات في الميزات أو الجودة لتلبية الموعد النهائي. [18]

تحليل

يبدأ تحليل البرمجيات بتحليل المتطلبات لالتقاط احتياجات العمل الخاصة بالبرمجيات. [19] تتمثل التحديات التي تواجه تحديد الاحتياجات في أن المستخدمين الحاليين أو المحتملين قد يكون لديهم احتياجات مختلفة وغير متوافقة، وقد لا يفهمون احتياجاتهم الخاصة، ويغيرون احتياجاتهم أثناء عملية تطوير البرمجيات. [20] في النهاية، تكون نتيجة التحليل عبارة عن مواصفات مفصلة للمنتج يمكن للمطورين العمل من خلالها. غالبًا ما يقوم محللو البرمجيات بتحليل المشروع إلى كائنات أصغر ومكونات يمكن إعادة استخدامها لزيادة فعالية التكلفة والكفاءة والموثوقية. [19] قد يتيح تحليل المشروع تنفيذًا متعدد الخيوط يعمل بشكل أسرع بشكل ملحوظ على أجهزة الكمبيوتر متعددة المعالجات . [21]

أثناء مرحلتي التحليل والتصميم في تطوير البرمجيات، غالبًا ما يتم استخدام التحليل المنظم لتقسيم متطلبات العميل إلى أجزاء يمكن تنفيذها بواسطة مبرمجي البرمجيات. [22] يمكن تمثيل المنطق الأساسي للبرنامج في مخططات تدفق البيانات ، وقواميس البيانات ، والرمز الزائف ، ومخططات انتقال الحالة ، و/أو مخططات علاقات الكيان . [23] إذا كان المشروع يتضمن جزءًا من برنامج قديم لم يتم نمذجته، فقد يتم نمذجة هذا البرنامج للمساعدة في ضمان دمجه بشكل صحيح مع البرنامج الأحدث. [24]

تصميم

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

برمجة

الميزة الأساسية لتطوير البرمجيات هي إنشاء وفهم البرمجيات التي تنفذ الوظيفة المطلوبة. [26] هناك استراتيجيات مختلفة لكتابة التعليمات البرمجية. تحتوي البرمجيات المتماسكة على مكونات مختلفة مستقلة عن بعضها البعض. [19] الاقتران هو الترابط بين مكونات البرمجيات المختلفة، والذي يُنظر إليه على أنه غير مرغوب فيه لأنه يزيد من صعوبة الصيانة . [27] غالبًا، لا يتبع مبرمجو البرمجيات أفضل ممارسات الصناعة، مما يؤدي إلى كود غير فعال أو يصعب فهمه أو يفتقر إلى الوثائق المتعلقة بوظائفه. [28] من المرجح بشكل خاص أن تنهار هذه المعايير في وجود مواعيد نهائية. [29] ونتيجة لذلك، يصبح اختبار التعليمات البرمجية وتصحيح أخطائها ومراجعتها أكثر صعوبة. إعادة هيكلة التعليمات البرمجية ، على سبيل المثال إضافة المزيد من التعليقات إلى التعليمات البرمجية، هو حل لتحسين قابلية فهم التعليمات البرمجية. [30]

الاختبار

الاختبار هو عملية التأكد من أن الكود يتم تنفيذه بشكل صحيح وخالٍ من الأخطاء. يتم تنفيذ تصحيح الأخطاء من قبل كل مطور برامج على الكود الخاص به للتأكد من أن الكود يقوم بما هو مقصود منه. على وجه الخصوص، من الأهمية بمكان أن يتم تنفيذ البرنامج على جميع المدخلات، حتى لو كانت النتيجة غير صحيحة. [31] غالبًا ما تُستخدم مراجعات الكود من قبل مطورين آخرين لفحص الكود الجديد المضاف إلى المشروع، ووفقًا لبعض التقديرات، يقلل بشكل كبير من عدد الأخطاء التي تستمر بعد اكتمال الاختبار. [32] بمجرد تقديم الكود، يقوم قسم ضمان الجودة - وهو قسم منفصل من غير المبرمجين لمعظم الشركات الكبيرة - باختبار دقة منتج البرنامج بالكامل. تعد اختبارات القبول المستمدة من متطلبات البرنامج الأصلية أداة شائعة لهذا الغرض. [31] غالبًا ما يتضمن اختبار الجودة أيضًا فحص الإجهاد والحمل (سواء كان البرنامج قويًا لمستويات عالية من الإدخال أو الاستخدام)، واختبار التكامل (لضمان تكامل البرنامج بشكل كافٍ مع برامج أخرى)، واختبار التوافق (قياس أداء البرنامج عبر أنظمة تشغيل أو متصفحات مختلفة). [31] عندما تتم كتابة الاختبارات قبل الكود، يُطلق على ذلك التطوير الموجه بالاختبار . [33]

إنتاج

الإنتاج هو المرحلة التي يتم فيها نشر البرنامج للمستخدم النهائي. [34] أثناء الإنتاج، قد يقوم المطور بإنشاء موارد الدعم الفني للمستخدمين [35] [34] أو عملية لإصلاح الأخطاء التي لم يتم اكتشافها في وقت سابق. قد يكون هناك أيضًا عودة إلى مراحل التطوير السابقة إذا تغيرت احتياجات المستخدم أو تم فهمها بشكل خاطئ. [34]

المطورون

يتم تنفيذ تطوير البرمجيات من قبل مطوري البرمجيات [36] ، وعادة ما يعملون في فريق. الاتصالات الفعالة بين أعضاء الفريق ضرورية للنجاح. يتم تحقيق ذلك بسهولة أكبر إذا كان الفريق صغيرًا، معتادًا على العمل معًا، ويقع بالقرب من بعضهم البعض. [37] تساعد الاتصالات أيضًا في تحديد المشكلات في مرحلة سابقة من التطوير وتجنب الجهود المكررة. تتجنب العديد من مشاريع التطوير خطر فقدان المعرفة الأساسية التي يمتلكها موظف واحد فقط من خلال ضمان أن يكون العديد من العمال على دراية بكل مكون. [38] يتضمن تطوير البرمجيات محترفين من مجالات مختلفة، ليس فقط مبرمجي البرمجيات ولكن أيضًا الأفراد المتخصصين في الاختبار وكتابة الوثائق والتصميم الجرافيكي ودعم المستخدم والتسويق وجمع التبرعات. على الرغم من أن العاملين في البرمجيات الاحتكارية يتقاضون أجورًا، إلا أن معظم المساهمين في البرمجيات مفتوحة المصدر هم متطوعون. [39] بدلاً من ذلك، قد يتم دفع أجورهم من قبل الشركات التي لا يتضمن نموذج أعمالها بيع البرمجيات، ولكن شيئًا آخر - مثل الخدمات والتعديلات على البرمجيات مفتوحة المصدر. [40]

النماذج والأدوات

هندسة البرمجيات بمساعدة الحاسوب

هندسة البرمجيات بمساعدة الحاسوب (CASE) هي أدوات للأتمتة الجزئية لتطوير البرمجيات. [41] تمكن CASE المصممين من رسم مخطط لمنطق البرنامج، سواء كان برنامجًا سيتم كتابته، أو برنامجًا موجودًا بالفعل للمساعدة في دمجه مع كود جديد أو هندسته عكسيًا (على سبيل المثال، لتغيير لغة البرمجة ). [42]

التوثيق

تأتي الوثائق في شكلين يتم الاحتفاظ بهما منفصلين عادةً - أحدهما مخصص لمطوري البرامج والآخر متاح للمستخدم النهائي لمساعدتهم على استخدام البرنامج. [43] [44] معظم وثائق المطورين تكون في شكل تعليقات على التعليمات البرمجية لكل ملف وفئة وطريقة تغطي واجهة برمجة التطبيقات (API) - كيف يمكن الوصول إلى جزء البرنامج بواسطة شخص آخر - وغالبًا تفاصيل التنفيذ. [45] هذه الوثائق مفيدة للمطورين الجدد لفهم المشروع عندما يبدأون العمل عليه. [46] في التطوير السريع، غالبًا ما تُكتب الوثائق في نفس وقت كتابة التعليمات البرمجية. [47] غالبًا ما يكتب الكتاب الفنيون وثائق المستخدم . [48]

تقدير الجهد

التقدير الدقيق أمر بالغ الأهمية في مرحلة الجدوى وفي تسليم المنتج في الوقت المحدد وفي حدود الميزانية. غالبًا ما يتم تفويض عملية إنشاء التقديرات من قبل مدير المشروع . [49] نظرًا لأن تقدير الجهد مرتبط بشكل مباشر بحجم التطبيق الكامل، فإنه يتأثر بشدة بإضافة ميزات في المتطلبات - فكلما زادت المتطلبات، زادت تكلفة التطوير. كما أن الجوانب غير المتعلقة بالوظائف، مثل خبرة مطوري البرامج وإمكانية إعادة استخدام التعليمات البرمجية، ضرورية أيضًا للنظر فيها في التقدير. [50] اعتبارًا من عام 2019 ، تم تصميم معظم أدوات تقدير مقدار الوقت والموارد اللازمة لتطوير البرامج للتطبيقات التقليدية ولا تنطبق على تطبيقات الويب أو تطبيقات الهاتف المحمول . [51]

بيئة التطوير المتكاملة

Anjuta ، بيئة تطوير متكاملة للغة C وC++ لبيئة GNOME

تدعم بيئة التطوير المتكاملة (IDE) تطوير البرامج بميزات محسنة مقارنة بمحرر النصوص البسيط . [52] غالبًا ما تتضمن بيئات التطوير المتكاملة التجميع الآلي ، وتسليط الضوء على الأخطاء النحوية ، [53] ومساعدة التصحيح، [54] والتكامل مع التحكم في الإصدار ، والأتمتة شبه الآلية للاختبارات. [52]

التحكم في الإصدار

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

عرض النموذج

مصفوفة وجهات النظر والآراء الخاصة بـ TEAF

نموذج العرض هو إطار عمل يوفر وجهات نظر حول النظام وبيئته ، لاستخدامها في عملية تطوير البرمجيات . وهو عبارة عن تمثيل رسومي للدلالات الأساسية للعرض.

الغرض من وجهات النظر ووجهات النظر هو تمكين المهندسين البشريين من فهم الأنظمة المعقدة للغاية وتنظيم عناصر المشكلة حول مجالات الخبرة . في هندسة الأنظمة المكثفة جسديًا، غالبًا ما تتوافق وجهات النظر مع القدرات والمسؤوليات داخل المنظمة الهندسية. [56]

وظائف اللياقة البدنية

وظائف اللياقة البدنية هي اختبارات آلية وموضوعية لضمان عدم انحراف التطورات الجديدة عن القيود والضوابط وضوابط الامتثال المعمول بها. [57]

الملكية الفكرية

يمكن أن تشكل الملكية الفكرية مشكلة عندما يقوم المطورون بدمج التعليمات البرمجية أو المكتبات مفتوحة المصدر في منتج خاص، لأن معظم تراخيص البرامج مفتوحة المصدر المستخدمة في البرامج تتطلب إصدار التعديلات بموجب نفس الترخيص. كبديل، قد يختار المطورون بديلاً خاصًا أو يكتبون وحدة برمجية خاصة بهم. [58]

مراجع

  1. ^ دولي 2017، ص 1.
  2. ^ دولي 2017، ص 12.
  3. ^ منهجيات تطوير النظام للتجارة الإلكترونية المعتمدة على الويب: إطار عمل للتخصيص ليندا في. نايت (جامعة دي بول، الولايات المتحدة الأمريكية)، وتيريزا أ. شتاينباخ (جامعة دي بول، الولايات المتحدة الأمريكية) وفينس كيلين (بلو وولف، الولايات المتحدة الأمريكية)
  4. ^ دولي 2017، ص 8-9.
  5. ^ دولي 2017، ص 9.
  6. ^ ab Langer 2016، ص 2-3، 5-6.
  7. ^ تاكر وموريلي ودي سيلفا 2011، ص. 8.
  8. ^ دولي 2017، ص 11.
  9. ^ ab Dooley 2017، ص 13.
  10. ^ تاكر وموريلي ودي سيلفا 2011، ص 41-42.
  11. ^ ab Vishnu 2019، ص 1-2.
  12. ^ Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). "المشاكل والأسباب والحلول عند اعتماد التسليم المستمر - مراجعة منهجية للأدبيات". تكنولوجيا المعلومات والبرمجيات . 82 : 55-79. doi : 10.1016/j.infsof.2016.10.001 .
  13. ^ وينترز، مانشريك ورايت 2020، ص 17.
  14. ^ تاكر وموريلي ودي سيلفا 2011، ص. 6.
  15. ^ سيف 2019، ص 46-47.
  16. ^ موريس 2001، ص 1.10.
  17. ^ لانجر 2016، ص 7.
  18. ^ دولي 2017، ص 3، 8.
  19. ^ abcd Langer 2016، ص 8.
  20. ^ لانجر 2016، ص 2-3.
  21. ^ دولي 2017، ص 193-194.
  22. ^ لانجر 2016، ص 103-104.
  23. ^ لانجر 2016، ص 117، 127، 131، 137، 141.
  24. ^ لانجر 2016، ص 106.
  25. ^ دولي 2017، ص 142.
  26. ^ تاكر، موريلي ودي سيلفا 2011، ص. 31.
  27. ^ لانجر 2016، ص 8-9.
  28. ^ تاكر وموريلي ودي سيلفا 2011، ص 31-32.
  29. ^ تاكر وموريلي ودي سيلفا 2011، ص 34-35.
  30. ^ تاكر، موريلي ودي سيلفا 2011، الصفحات من 31 إلى 32، 35.
  31. ^ abc Langer 2016، ص 9.
  32. ^ دولي 2017، ص 272.
  33. ^ تاكر وموريلي ودي سيلفا 2011، ص. 9.
  34. ^ abc Langer 2016، ص 10.
  35. ^ تاكر وموريلي ودي سيلفا 2011، ص. 37.
  36. ^ "ما هو تطوير البرمجيات؟ | IBM". www.ibm.com . 14 يوليو 2021 . تم الاسترجاع في 29 سبتمبر 2024 .
  37. ^ دولي 2017، ص 2.
  38. ^ وينترز، مانشريك ورايت 2020، ص 30-31.
  39. ^ تاكر وموريلي ودي سيلفا 2011، ص. 7.
  40. ^ تاكر وموريلي ودي سيلفا 2011، ص 14-15.
  41. ^ لانجر 2016، ص 22.
  42. ^ لانجر 2016، ص 108-110، 206.
  43. ^ تاكر وموريلي ودي سيلفا 2011، ص. 243.
  44. ^ وينترز، مانشريك ورايت 2020، ص 192.
  45. ^ وينترز، مانشريك ورايت 2020، ص 193-195.
  46. ^ تاكر وموريلي ودي سيلفا 2011، ص. 143.
  47. ^ تاكر، موريلي ودي سيلفا 2011، ص. 144.
  48. ^ وينترز، مانشريك ورايت 2020، ص 204.
  49. ^ سيف 2019، ص 50-51.
  50. ^ سيف 2019، ص 52-53.
  51. ^ سيف 2019، ص45.
  52. ^ أب تاكر، موريلي ودي سيلفا 2011، ص. 68.
  53. ^ دولي 2017، ص 236.
  54. ^ دولي 2017، ص 239.
  55. ^ دولي 2017، ص 246-247.
  56. ^ إدوارد جيه باركماير (2003). مفاهيم لأتمتة تكامل الأنظمة مؤرشف من الأصل في 25 يناير 2017 على موقع واي باك مشين NIST 2003.
  57. ^ أساسيات هندسة البرمجيات: نهج هندسي . أوريلي ميديا. 2020. ISBN 978-1492043454.
  58. ^ لانجر 2016، ص 44-45.

قراءة إضافية

  • كوندي، دان (2002). إدارة منتجات البرمجيات: إدارة تطوير البرمجيات من الفكرة إلى المنتج إلى التسويق إلى المبيعات . كتب أسباتوري. رقم ISBN 1587622025.
  • ديفيس، إيه إم (2005). إدارة المتطلبات الكافية: حيث يلتقي تطوير البرمجيات بالتسويق . شركة دورست هاوس للنشر، المحدودة. رقم ISBN 0932633641.
  • دولي، جون ف. (2017). تطوير البرمجيات وتصميمها وترميزها: باستخدام الأنماط وتصحيح الأخطاء واختبار الوحدات وإعادة الهيكلة . أبريس. رقم ISBN 978-1-4842-3153-1.
  • كيت، إدوارد (1992). اختبار البرمجيات في العالم الحقيقي. أديسون ويسلي بروفيشنال. رقم ISBN 0201877562.
  • هاستيد، إدوارد (2005). البرمجيات التي تبيع: دليل عملي لتطوير وتسويق مشروع البرمجيات الخاص بك . دار وايلي للنشر. رقم ISBN 0764597833.
  • هوهمان، لوك (2003). ما وراء بنية البرمجيات: خلق الحلول الناجحة واستدامتها . أديسون ويسلي بروفيشنال. رقم ISBN 0201775948.
  • Horch, John W. (مارس 1995). "اتجاهان حول كيفية العمل مع الكائنات". IEEE Software . 12 (2): 117–118. ProQuest  215832531.
  • لانجر، آرثر م. (2016). دليل تطوير البرمجيات: تصميم وإدارة دورة الحياة . سبرينغر. رقم ISBN 978-1-4471-6799-0.
  • مكارثي، جيم (1995). ديناميكيات تطوير البرمجيات. مطبعة مايكروسوفت. رقم ISBN 1556158238.
  • موريس، جوزيف م. (2001). محاسبة صناعة البرمجيات (الطبعة الثانية). جون وايلي وأولاده . OCLC  53863959.
  • ريتنجهاوس، جون (2003). إدارة مخرجات البرمجيات: منهجية إدارة تطوير البرمجيات . ديجيتال بريس. رقم ISBN 155558313X.
  • سيف، سيد محسن (2019). "تقدير جهد البرمجيات لتطوير تطبيقات برمجية ناجحة". في فيشنو، بينديالا (المحرر). أدوات وتقنيات لتطوير البرمجيات في المنظمات الكبيرة: البحوث والفرص الناشئة: البحوث والفرص الناشئة . IGI Global. ص 45-97. ISBN 978-1-7998-1865-6.
  • تاكر، ألين؛ موريللي، رالف؛ دي سيلفا، شاميندرا (2011). تطوير البرمجيات: نهج مفتوح المصدر . دار نشر سي آر سي. رقم ISBN 978-1-4398-8460-7.
  • فيشنو، بينديالا (2019). "تطور هندسة التكامل والبناء والاختبار والإصدار في DevOps وDevSecOps". في فيشنو، بينديالا (المحرر). أدوات وتقنيات لتطوير البرمجيات في المؤسسات الكبيرة: الأبحاث والفرص الناشئة: الأبحاث والفرص الناشئة . IGI Global. ص 1-20. ISBN 978-1-7998-1865-6.
  • Wiegers, Karl E. (2005). المزيد عن متطلبات البرمجيات: القضايا الشائكة والنصائح العملية . Microsoft Press. ISBN 0735622671.
  • وينترز، تيتوس؛ مانشريك، توم؛ رايت، هيروم (2020). هندسة البرمجيات في جوجل: الدروس المستفادة من البرمجة على مر الزمن . أوريلي ميديا، إنك. رقم ISBN 978-1-4920-8276-7.
  • ويسوكي، روبرت ك. (2006). إدارة فعالة لمشاريع البرمجيات . وايلي. ISBN 0764596365.
  • الوسائط المتعلقة بتطوير البرمجيات في ويكيميديا ​​كومنز
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_development&oldid=1248470662"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate