تطوير برمجيات
| صنف فرعي من | |
|---|---|
| يمتهنه | |
| فروع |
| جزء من سلسلة مقالات حول |
| عملية تطوير البرمجيات |
|---|
 |
 بوابة برمجيات |
تعد عملية تطوير البرامج (المعروفة كذلك باسم تطوير التطبيقات أو تصميم البرامج أو برامج التصميم أو تطوير تطبيقات البرامج أو تطوير تطبيقات المؤسسات أو تطوير النظام الأساسي[2][3][4][5]) عبارة عن تطوير منتج برمجية حاسوب. ويمكن استخدام المصطلح «تطوير البرامج» للإشارة إلى نشاط البرمجة، والذي هو عبارة عن عملية كتابة الكود المصدري والاحتفاظ به، ولكن بالتمعن في المصطلح على نطاق أعم فسنجد أنه يشمل على كل ما يفصل بين وضع تصور للبرنامج المطلوب وصولاً إلى الإعلان النهائي عن البرنامج، وذلك في عملية مرتبة ومخطط لها على نحو مثالي.[6] ولذلك، قد تشتمل عملية تطوير البرامج على البحث أو التطوير الجديد أو تصميم القوالب أو التعديل أو إعادة الاستخدام أو إعادة الهندسة أو الصيانة أو أية أنشطة أخرى قد تؤدي لإنتاج منتج برمجي.[7]
يمكن تطوير البرامج لعدة أغراض، والثلاثة الأكثر شيوعًا منها هي تلبية احتياجات خاصة لعميل/شركة معينة (كما هو الحال مع البرامج المخصصة)، أو لتلبية حاجة متوقعة لمجموعة من المستخدمين المحتملين (كما هو الحال مع برمجيات مفتوحة المصدر وتجارية)، أو للاستخدام الشخصي (على سبيل المثال، قد يكتب أحد العلماء برنامجًا لتشغيل برنامج اعتيادي بشكل تلقائي). وتتطلب عملية تطوير البرامج المضمنة، والتي تعني، تطوير برنامج مضمن كذلك الذي يتم استخدامه في التحكم في المنتجات الاستهلاكية، دمج عملية التطوير مع عملية تطوير المنتج المادي الخاضعة للسيطرة.
رفعت الحاجة إلى وجود مراقبة جودة أفضل في عملية تطوير البرامج من قيمة فرع العلم الخاص بـ هندسة البرمجيات، والتي تهدف لتطبيق نهجًا نظاميًا متمثلاً في نموذج الهندسة لعملية تطوير البرامج.
نظرة عامة
[عدل]هناك عدة طرق منهجية لتطوير البرامج، تشبه كثيرًا وجهات النظر المختلفة للأحزاب السياسية حول طريقة حكم البلاد. فالبعض يتبع طريقة منهجية أكثر تنظيمًا وتستند إلى الهندسة لتطوير حلول الأعمال، بينما قد يلجأ الآخرون إلى نهج تدريجي بشكل أكبر، حيث يتطور البرنامج بينما يتم إنشاؤه جزء بعد جزء. وتشترك أغلب الطرق المنهجية في مجموعات معينة من المراحل التالية لتطوير البرامج:
- أبحاث السوق
- جمع المتطلبات الخاصة بحلول الأعمال المقترحة
- تحليل المشكلة
- وضع خطة أو تصميم للحلول التي تستند إلى البرامج
- تنفيذ (كتابة كود) البرنامج
- اختبار البرنامج
- النشر
- الصيانة وتصحيح الأخطاء
غالبًا ما يُشار إلى تلك المراحل معًا باسم دورة حياة تطوير البرمجيات، أو SDLC. وقد تنفذ التوجهات المختلفة لتطوير البرامج تلك المراحل وفق ترتيبات مختلفة، أو تخصيص وقت أقل أو أكثر لمراحل مختلفة. وقد يختلف كذلك مستوى التفصيل للوثائق التي يتم إنتاجها عند كل مرحلة من عملية تطوير البرامج. وقد يتم تنفيذ تلك المراحل بالدور (نهج يستند إلى «الشلال»)، أو قد يتم تكرارها وفق دورات أو تكرارات متنوعة (نهج أكثر «شدة»). وعادةً ما يتضمن النهج الأكثر شدة بإنفاق وقت أقل على عمليتي التخطيط والتوثيق، وإنفاق المزيد من الوقت على كتابة الأكواد وتطوير اختبارات يتم تشغيلها بشكل تلقائي. وتعمل النُهُج الأكثر «شدة» كذلك على تعزيز الاختبارات المستمرة على مدار دورة حياة التطوير، فضلاً عن امتلاك منتج يعمل (بدون أخطاء) طوال الوقت. وتحاول النُهُج التي تستند إلى «الشلال» تقييم غالبية المخاطر ووضع خطة مفصلة للبرنامج قبل بدء تنفيذه (كتابة الأكواد)، وتجنب تغيرات التصميم الهامة وإعادة كتابة الأكواد في مراحل لاحقة من دورة حياة تطوير البرنامج. تمتلك الطرق المنهجية المتنوعة العديد من الميزات والعيوب، وسيعتمد أفضل نهج لحل مشكلة باستخدام برنامج في الغالب على نوع المشكلة. وإذا تم استيعاب المشكلة بشكل جيد والتخطيط لحل بشكل فعال مبكرًا، فقد يعمل التوجه الذي يستند إلى «الشلال» بشكل أكبر على النحو الأمثل. وعلى النحو الآخر، إذا كانت المشكلة فريدة (بالنسبة لفريق التطوير على الأقل) وتعذر وضع تصور لبنية حل البرنامج بسهولة، فيكون عندئذٍ التوجه التدريجي «الشديد» أفضل. وعملية تطوير البرامج عبارة عن بنية يتم دمجها في تطوير منتج برمجي. وتشمل المرادفات كذلك دورة حياة البرنامج أو عملية البرنامج. وهناك العديد من النماذج لتلك العمليات، تصف كل منها التوجهات المؤدية إلى مجموعة متنوعة من المهام أو الأنشطة التي قد تحدث خلال العملية.
التناسق في البرامج
[عدل]لضمان قدرة البرنامج على التطور بطريقة تحافظ على تعدد الأبعاد المتأصل فيه، يجب على الفرد أن يضمن تطور الأبعاد المختلفة معًا بطريقة متناسقة. وتتوفر لدى البرنامج العديد من الأبعاد التي يتعين الجمع بينها داخل إطار عمل واحد، فلا تقوم بالتدوينات المختلفة فحسب بل كذلك لا تتفاعل بشكل هرمي. ويجب عدم توجيه آلية لتناول مشكلة بعينها مثل ضمان تناسق مخطط فئة UML مع الكود المصدري. بل يجب أن تتمتع بدلاً من ذلك بالمرونة الكافية للتعامل مع مجموعة كبيرة من الأبعاد المضمنة بالفعل داخل عملية تطوير البرامج.[1][8]
موضوع تطوير البرامج
[عدل]التسويق
[عدل]تتسم مصادر الأفكار لمنتجات البرامج بالغزارة.[9] وقد تنبع تلك الأفكار من بحث السوق والذي يشمل الأبعاد الديموغرافية للعملاء الجدد المحتملين والعملاء الحاليين أو نظريات المبيعات التي رفضت المنتج أو فريق تطوير البرامج المحلي أو الجهة الخارجية الإبداعية. وعادة ما يتم تقييم أفكار المنتجات البرمجية أولاً بواسطة موظفي التسويق المعنيين بالجدوى الاقتصادية، وذلك لضمان ملاءمتها مع قنوات التوزيع الحالية، ودراسة تأثيراتها المحتملة على مجموعات المنتجات الموجودة، وللتعرف على الميزات المطلوبة، ولضمان ملاءمتها لأهداف التسويق الخاصة بالشركة. وفي مرحلة التقييم للتسويق، يتم تقييم الفرضيات الخاصة بالوقت والتكلفة. ويتم الوصول لقرار في مرحلة مبكرة حول ما إذا كان سيتم المواصلة لتنفيذ المشروع أم لا، وذلك استنادًا إلى المعلومات الأكثر تفصيلاً التي يقدمها فريق التسويق والتطوير. باراناي.[9]
في كتاب "مناظرات برمجية رائعة"، أفصح ألان م ديفيس في الفصل الفرعي الذي حمل عنوان «الحلقة المفقودة في تطوير البرامج» من فصل «المتطلبات» عما يلي
|
يدرس طلاب الهندسة في العادة الهندسة فقط ونادرًا ما يتعرضون للتسويق أو التمويل. بينما يدرس طلاب التسويق في العادة التسويق فقط ونادرًا ما يتعرضون للهندسة أو التمويل. فأغلبنا يتخصص في مجال واحد فقط. ولتعقيد الأمور، يلتقي بعض منها بأفراد ذوي كفاءات متنوعة ضمن قوى العمل، لذا لا تكون هناك فرصة لمحاكاتهم. إلا أن عملية التخطيط للمنتج البرمجي تعد حاسمة بالنسبة لنجاح عملية التطوير وتتطلب بالطبع دراية بفروع علم متعددة.[10] | 
|
نظرًا لأن عملية التطوير البرامج قد تتضمن مخاطرة أو تجاوز ما قد يطلبه العميل، فقد يتفرع مشروع تطوير البرامج إلى مجالات ليست ذات صلة بالمجال التقني مثل الموارد البشرية وإدارة المخاطر والملكية الفكرية وتحديد الميزانية وإدارة الأزمات وما إلى ذلك. وقد تتسبب تلك العمليات في تداخل دور القائمين على تطوير الأعمال مع تطوير البرامج.
الطريقة المنهجية لتطوير البرامج
[عدل]تعد الطريقة المنهجية لتطوير البرامج عبارة عن إطار عمل يتم استخدامه لهيكلة وتخطيط والتحكم في عملية تطوير نظم المعلومات. وقد تطورت مجموعة متنوعة من أطر العمل تلك بمرور السنوات، وتتمتع كل منها بنقاط قوة وضعف. ولا يكون وجود طريقة منهجية واحدة مناسبًا بالضرورة للاستخدام في جميع المشاريع. حيث تكون كل طريقة منهجية متوفرة مناسبة لأنواع معينة من المشاريع، وذلك استنادًا إلى اعتبارات متنوعة ذات صلة بالفريق والمشروع والمؤسسة والتقنية.[11]
انظر أيضاً
[عدل]المراجع
[عدل]- ^ وصلة مرجع: https://www.ideosoftware.com/.
- ^ Application Development White Papers ( Development of Software, Software Design, Designing Software, Software Engineering, Software Application Development, Enterprise Applica... نسخة محفوظة 2021-05-17 على موقع واي باك مشين.
- ^ "Software Development". hayathisolutions.com. مؤرشف من الأصل في 2017-01-23. اطلع عليه بتاريخ 2016-06-07.
- ^ Concepts for Automating Systems Integration NIST 2003. نسخة محفوظة 25 يناير 2017 على موقع واي باك مشين.
- ^ DRM Associates (2002). "New Product Development Glossary". مؤرشف من الأصل في 2018-07-13. اطلع عليه بتاريخ 2006-10-29.
- ^ Application Development (AppDev) Defined and Explained نسخة محفوظة 28 يوليو 2017 على موقع واي باك مشين.
- ^ DRM Associates (2002). "New Product Development Glossary". مؤرشف من الأصل في 2019-05-02. اطلع عليه بتاريخ 2006-10-29.
- ^ Steven P,Reiss. Consistent software Evolution,.
- ^ ا ب Joseph M. Morris (2001). Software Industry Accounting. p.1.10
- ^ Alan M. Davis. Great Software Debates (October 8, 2004), pp:125-128 Wiley-IEEE Computer Society Press
- ^ Selecting a development approach. Revalidated: March 27, 2008. Retrieved 27 Oct 2008. نسخة محفوظة 31 مارس 2010 على موقع واي باك مشين. "نسخة مؤرشفة" (PDF). مؤرشف من الأصل في 2010-03-31. اطلع عليه بتاريخ 2019-09-05.
{{استشهاد ويب}}: صيانة الاستشهاد: BOT: original URL status unknown (link)
| العتاد | |
|---|---|
| بنية الأنظمة | |
| الشبكات | |
| بنية البرمجيات | |
| نظرية لغات البرمجة وأدواتها | |
| تطوير البرمجيات | |
| نظرية الحوسبة | |
| الخوارزميات | |
| رياضيات الحوسبة | |
| نظم المعلومات | |
| الأمن | |
| التفاعل الإنساني الحاسويبي | |
| تزامن | |
| الذكاء الاصطناعي | |
| تعلم الآلة |
|
| رسوميَّات | |
| الحوسبة التطبيقيَّة | |
