المناهج الأساسية لتطوير البرمجيات. تقنيات التطوير المرنة
1. الترميز
في مرحلة تطوير البرمجيات ، يتم تنفيذ الإجراءات الرئيسية التالية: اختبارات؛ تطوير نظام مرجعي للبرمجيات ؛ إنشاء وثائق المستخدم ؛ إنشاء نسخة وتثبيت البرنامج ،
الترميز هو عملية تحويل نتائج التصميم عالية المستوى ومنخفضة المستوى إلى منتج برمجي نهائي. بمعنى آخر ، عند الترميز ، يتم وصف نموذج PP المترجم عن طريق لغة البرمجة المحددة ، والتي يمكن أن تكون أيًا من اللغات الموجودة. يتم اختيار اللغة إما بناءً على طلب العميل ، أو مع مراعاة المهمة التي يتم حلها والتجربة الشخصية للمطورين.
عند الترميز ، من الضروري اتباع معيار اللغة المختارة ، على سبيل المثال ، بالنسبة للغة C فهي ANSI C ، وبالنسبة لـ C ++ فهي ISO / IEC 14882 "قياسية للغة C ++ ProgrammingLanguage".
بالإضافة إلى المعيار المقبول عمومًا للغة البرمجة ، يمكن للشركة أيضًا استخدام متطلباتها الإضافية لقواعد كتابة البرامج. في الأساس ، تتعلق بقواعد تنسيق نص البرنامج.
يتيح لك اتباع معايير وقواعد الشركة إنشاء برنامج يعمل بشكل صحيح ، ويسهل قراءته ، ومفهومه للمطورين الآخرين ، ويحتوي على معلومات حول المطور ، وتاريخ الإنشاء ، والاسم والغرض ، بالإضافة إلى البيانات اللازمة لإدارة التكوين.
في مرحلة الترميز ، يكتب المبرمج البرامج ويختبرها بنفسه. يسمى هذا الاختبار اختبار الوحدة. تمت مناقشة جميع القضايا المتعلقة باختبار البرامج في الفصل. 10 ، يصف أيضًا تقنية الاختبار المستخدمة في مرحلة تطوير البرامج. هذه التقنية تسمى الاختبار. "صندوق زجاجي" (صندوق زجاجي) ؛أحيانًا يُطلق عليه أيضًا الاختبار "الصندوق الأبيض" (وايت بوكس)على عكس المفهوم الكلاسيكي لـ "الصندوق الأسود" (الصندوق الأسود).
في اختبار الصندوق الأسود ، يتم التعامل مع البرنامج على أنه كائن غير معروف هيكله الداخلي. يقوم المختبر بإدخال البيانات وتحليل النتيجة ، لكنه لا يعرف كيف يعمل البرنامج. عند اختيار الاختبارات ، يبحث المتخصص عن بيانات الإدخال والشروط التي تهمه من وجهة نظره ، والتي يمكن أن تؤدي إلى نتائج غير قياسية. بادئ ذي بدء ، إنه مهتم بممثلي كل فئة من فئات بيانات الإدخال ، حيث من المرجح أن تظهر أخطاء البرنامج قيد الاختبار.
عند اختبار "الصندوق الزجاجي" يكون الوضع مختلفًا تمامًا. يقوم المُختبِر (في هذه الحالة ، المبرمج نفسه) بتطوير الاختبارات بناءً على معرفة الكود المصدري ، الذي يتمتع بحق الوصول الكامل إليه. نتيجة لذلك ، يتلقى الفوائد التالية.
1. اتجاه الاختبار. يمكن للمبرمج اختبار البرنامج على أجزاء ، وتطوير إجراءات فرعية خاصة للاختبار تستدعي الوحدة قيد الاختبار وتمرير البيانات التي تهم المبرمج. من الأسهل بكثير اختبار وحدة واحدة تمامًا مثل "الصندوق الزجاجي".
2. تغطية كاملة للكود. يمكن للمبرمج دائمًا تحديد أجزاء التعليمات البرمجية التي تعمل في كل اختبار. إنه يرى فروع الكود الأخرى التي لم يتم اختبارها ، ويمكنه اختيار الظروف التي سيتم اختبارها بموجبها. يصف ما يلي كيفية تتبع تغطية التعليمات البرمجية للاختبارات التي تجريها.
3. القدرة على التحكم في تدفق الأوامر. يعرف المبرمج دائمًا الوظيفة التي يجب تنفيذها بعد ذلك في البرنامج وما هي حالتها الحالية. لمعرفة ما إذا كان البرنامج يعمل بالطريقة التي يفكر بها ، يمكن للمبرمج تضمين أوامر تصحيح الأخطاء التي تعرض معلومات حول تقدم تنفيذه ، أو استخدام أداة خاصة تسمى مصحح الأخطاء للقيام بذلك. يمكن لمصحح الأخطاء القيام بالكثير من الأشياء المفيدة: تتبع وتغيير تسلسل تنفيذ أوامر البرنامج ، وإظهار محتويات المتغيرات وعناوينها في الذاكرة ، وما إلى ذلك.
4. القدرة على تتبع سلامة البيانات. يعرف المبرمج أي جزء من البرنامج يجب أن يعدل كل عنصر من عناصر البيانات. من خلال تتبع حالة البيانات (باستخدام نفس مصحح الأخطاء) ، يمكنه تحديد الأخطاء مثل تغييرات البيانات من خلال الوحدات النمطية الخاطئة أو تفسيرها غير الصحيح أو المؤسسة غير الناجحة ، ويمكن للمبرمج أتمتة الاختبار بمفرده.
5. رؤية نقاط الحدود الداخلية. في التعليمات البرمجية المصدر ، تكون تلك النقاط الحدودية للبرنامج المخفية عن العرض الخارجي مرئية. على سبيل المثال ، يمكن استخدام عدة خوارزميات مختلفة تمامًا لتنفيذ إجراء معين ، وبدون النظر إلى الكود ، من المستحيل تحديد أي واحدة اختارها المبرمج. مثال نموذجي آخر هو مشكلة تجاوز سعة المخزن المؤقت المستخدمة لتخزين بيانات الإدخال مؤقتًا. يمكن للمبرمج أن يخبر على الفور بكمية البيانات التي سوف يفيض بها المخزن المؤقت ، ولا يحتاج إلى إجراء آلاف الاختبارات.
6. إمكانية الاختبار ، التي تحددها الخوارزمية المختارة. قد تكون هناك حاجة إلى تقنيات خاصة لاختبار معالجة البيانات التي تستخدم خوارزميات حسابية معقدة للغاية. يعتبر تحويل المصفوفة وفرز البيانات أمثلة كلاسيكية. يحتاج المختبِر ، بخلاف المبرمج ، إلى معرفة الخوارزميات المستخدمة بالضبط ، لذلك يتعين على المرء الرجوع إلى الأدبيات المتخصصة.
يعتبر اختبار الصندوق الزجاجي جزءًا من عملية البرمجة. يقوم المبرمجون بهذا العمل طوال الوقت ، ويختبرون كل وحدة بعد كتابتها ، ثم مرة أخرى بعد دمجها في النظام.
عند إجراء اختبار الوحدة ، يمكنك استخدام تقنيات الاختبار الهيكلية أو الوظيفية ، أو كليهما.
الهيكليالاختبار هو نوع واحد من اختبار الصندوق الزجاجي. فكرتها الرئيسية هي الاختيار الصحيح لمسار البرنامج قيد الاختبار. على النقيض منه وظيفيينتمي الاختبار إلى فئة اختبار "الصندوق الأسود". يتم اختبار كل وظيفة من وظائف البرنامج بأخذ مدخلاتها وتحليل المخرجات. في هذه الحالة ، نادرًا ما يتم أخذ الهيكل الداخلي للبرنامج في الاعتبار.
في حين أن الاختبار الهيكلي له أساس نظري أقوى بكثير ، فإن معظم المختبرين يفضلون الاختبار الوظيفي. يفسح الاختبار الهيكلي نفسه بشكل أفضل للنمذجة الرياضية ، لكن هذا لا يعني على الإطلاق أنها أكثر كفاءة. تتيح لك كل تقنية من التقنيات تحديد الأخطاء المفقودة في حالة استخدام الأخرى. من وجهة النظر هذه ، يمكن أن يطلق عليهم نفس الفعالية.
لا يمكن أن يكون هدف الاختبار هو المسار الكامل للبرنامج فقط (تسلسل الأوامر التي ينفذها من البداية إلى النهاية) ، ولكن أيضًا أقسامه الفردية. من غير الواقعي تمامًا اختبار جميع الطرق الممكنة لتنفيذ البرنامج. لذلك ، فإن أخصائيو الاختبار يفردون من جميع المسارات الممكنة تلك المجموعات التي يجب اختبارها بشكل مؤكد. للاختيار ، يستخدمون معايير خاصة تسمى معايير التغطية (Coveragecriteria) ،التي تحدد عددًا حقيقيًا (حتى لو كان كبيرًا جدًا) من الاختبارات. تسمى هذه المعايير أحيانًا معايير التغطية المنطقية ،أو معايير الاكتمال.
3. تطوير نظام مساعدة لمنتج برمجي. إنشاء وثائق المستخدم
يُنصح بتعيين أحد موظفي المشروع كمحرر فني للوثائق. يمكن لهذا الموظف القيام بعمل آخر ، لكن مهمته الرئيسية يجب أن تكون تحليل الوثائق ، حتى لو قام الموظفون الآخرون بتطويرها.
غالبًا ما يعمل العديد من الأشخاص على إنشاء برنامج ، لكن لا أحد منهم مسؤول مسؤولية كاملة عن جودته. نتيجة لذلك ، لا يستفيد البرنامج من حقيقة أن المزيد من الأشخاص يطورونه فحسب ، بل يخسرونه أيضًا ، لأن كل شخص لا شعوريًا ينقل المسؤولية للآخر ويتوقع من زملائه القيام بهذا الجزء أو ذاك من العمل. يتم حل هذه المشكلة عن طريق تعيين محرر مسؤول مسؤولية كاملة عن جودة ودقة الوثائق الفنية.
يتكون نظام مساعدة البرامج على أساس المواد المطورة لدليل المستخدم. النماذج ويخلقها مسؤولة عن أداء هذا العمل. يمكن أن يكون إما محررًا تقنيًا أو أحد المطورين مع محرر تقني.
يتمتع PP الموثق جيدًا بالمزايا التالية.
1. سهولة الاستخدام. إذا كان PP موثقًا جيدًا ، فسيكون تطبيقه أسهل بكثير. يتعلم المستخدمون ذلك بشكل أسرع ، ويرتكبون أخطاء أقل ، ونتيجة لذلك ، يقومون بعملهم بشكل أسرع وأكثر كفاءة.
2. انخفاض تكلفة الدعم الفني. عندما لا يستطيع المستخدم معرفة كيفية تنفيذ الإجراءات التي يحتاجها ، فإنه يتصل بالشركة المصنعة للبرنامج بخدمة الدعم الفني. صيانة مثل هذه الخدمة مكلفة للغاية. من ناحية أخرى ، يساعد الدليل الجيد المستخدمين على حل المشكلات بأنفسهم ويقلل من الحاجة إلى الاتصال بمجموعة الدعم الفني.
3. موثوقية عالية. تجعل الوثائق غير المفهومة أو غير المتقنة البرامج أقل موثوقية ، نظرًا لأن مستخدميها أكثر عرضة لارتكاب الأخطاء ، فمن الصعب عليهم معرفة أسبابها وكيفية التعامل مع عواقبها.
سهولة المرافقة. يتم إنفاق قدر كبير من المال والوقت على تحليل المشكلات الناتجة عن أخطاء المستخدم. غالبًا ما تكون التغييرات التي تم إجراؤها في إصدارات البرامج الجديدة مجرد تغيير في واجهة الوظائف القديمة. يتم تقديمها حتى يتمكن المستخدمون أخيرًا من معرفة كيفية استخدام البرنامج والتوقف عن الاتصال بخدمة الدعم الفني. القيادة الجيدة إلى حد كبير
نماذج تطوير البرامج
نموذج الشلال تحليل المتطلبات تجميع مواصفات المنتج التصميم تجميع بنية المنتج التنفيذ تطوير كود المصدر دمج أجزاء منفصلة من كود المصدر الاختبار واستكشاف الأخطاء وإصلاحها
برمجة متطرفة المتطلبات الأولية تحليل تكامل التصميم اختبار التنفيذ متطلبات جديدة مراجعة / اعتماد / تعديل خطة التطوير إصدار المنتج
النماذج الأولية لواجهة المستخدم إصدار المنتج تطوير البرامج مع مراعاة التغييرات توضيح المتطلبات والمواصفات تعديل النموذج الأولي وتحسين بعض الوظائف الوظيفة الأساسية النموذج الأولي للواجهة المواصفات الأولية
التكرار المتزايد للتنمية 1 التكرار 2…. تحليل المتطلبات ، تصميم التنفيذ ، اختبار التكامل ، اختبار التكامل ، التكرار الكامل ، N
عملية تطوير البرمجيات الموحدة (USDP) Ø نموذج حالة الاستخدام ، يصف الحالات التي سيتم فيها استخدام التطبيق. Ø يصف النموذج التحليلي الفئات الأساسية للتطبيق. Ø يصف نموذج التصميم الاتصالات والعلاقات بين الفئات والكائنات المختارة. Ø يصف نموذج النشر توزيع البرامج عبر أجهزة الكمبيوتر. Ø يصف نموذج التنفيذ التنظيم الداخلي لرمز البرنامج. Ø يتكون نموذج الاختبار من مكونات الاختبار وإجراءات الاختبار وحالات الاختبار المختلفة
متطلبات عملية تطوير البرمجيات الموحدة (USDP) التي تجمع Iter 1…. Iter N Designing Iter 1…. Iter N تنفيذ Iter 1…. Iter N Designing Iter 1…. Iter N اختبار Iter 1…. إيتير ن
مكونات بنية منتج البرامج النموذجية ومتطلبات البرامج النموذجية Ø Ø Ø Ø تنظيم البرنامج فئات النظام الرئيسية تنظيم البيانات قواعد الأعمال واجهة المستخدم إدارة الموارد الأمان قابلية الأداء للتوسع التفاعل مع الأنظمة الأخرى (التكامل) التدويل ، التعريب بيانات المدخلات والمخرجات معالجة الأخطاء
مكونات هندسة منتج البرامج النموذجية ومتطلبات البرامج النموذجية تحمل الأخطاء عبارة عن مجموعة من خصائص النظام التي تعزز موثوقية النظام عن طريق اكتشاف الأخطاء واستردادها وعزل النتائج السيئة للنظام. عند تصميم أي نظام حقيقي لضمان التسامح مع الخطأ ، من الضروري توقع جميع المواقف المحتملة التي يمكن أن تؤدي إلى فشل النظام وتطوير آليات للتعامل مع الأعطال. الموثوقية هي قدرة النظام على تحمل العديد من الإخفاقات والفشل. الفشل هو انتقال النظام نتيجة خطأ إلى حالة غير قابلة للتشغيل تمامًا. الفشل هو خطأ في تشغيل النظام لا يؤدي إلى فشل النظام. كلما قل عدد حالات الفشل والإخفاق لفترة معينة من الوقت ، زادت موثوقية النظام.
المكونات النموذجية لهندسة منتج البرنامج ومتطلبات البرامج النموذجية منحنى الموثوقية N t 1 t وكلما أبعد ، كلما كان من الصعب العثور على خطأ. وكلما زاد تعقيد النظام ، زاد احتمال الفشل والإخفاق.
المكونات النموذجية لبنية منتج البرنامج ومتطلبات البرامج النموذجية Ø إمكانيات تنفيذ البنية المطورة. Ø وظائف مفرطة. Ø اتخاذ قرار بشراء مكونات البرامج الجاهزة. Ø تغيير الاستراتيجية.
قائمة أسئلة تسمح لك باستخلاص استنتاج حول جودة البنية: Ø هل التنظيم العام للبرنامج موصوف بوضوح ؛ Ø Ø Ø ما إذا كانت المواصفات تتضمن نظرة عامة على العمارة وأسبابها المنطقية. هي المكونات الرئيسية للبرنامج محددة بشكل مناسب ، ومجالات مسؤوليتها والتفاعل مع المكونات الأخرى. ما إذا كان يتم تنفيذ جميع الوظائف المحددة في مواصفات المتطلبات بواسطة عدد معقول من مكونات النظام. هي أهم الفئات موصوفة ومبررة. ما إذا كان هناك وصف لتنظيم قاعدة البيانات. هل تم تحديد جميع قواعد العمل؟ هل تأثيرها على النظام موصوف؟
قائمة أسئلة تسمح لك بالتوصل إلى استنتاج حول جودة البنية: Ø هل استراتيجية تصميم واجهة المستخدم موصوفة. Ø ما إذا كانت واجهة المستخدم معيارية بحيث لا تؤثر التغييرات عليها على بقية النظام. Ø ما إذا كان وصف استراتيجية إدخال / إخراج البيانات معطى. Ø ما إذا كان قد تم تنفيذ تحليل أداء النظام الذي سيتم تنفيذه باستخدام هذه البنية. Ø ما إذا كان قد تم إجراء تحليل موثوقية النظام المصمم. Ø ما إذا كان قد تم إجراء تحليل لقضايا قابلية توسيع النظام وقابلية توسيعه.
إعادة بناء البرامج تتضمن إعادة هيكلة البرامج تكييف البرامج مع الأجهزة الجديدة وأنظمة التشغيل الجديدة ، وأدوات التطوير الجديدة ، والمتطلبات الجديدة ، وهندسة البرمجيات ووظائفها. هذا تغيير في الهيكل الداخلي للبرنامج دون تغيير سلوكه الخارجي ، وهو مصمم لضمان تعديل البرنامج. أسباب معقولة لإعادة البناء: الكود متكرر ؛ تنفيذ الطريقة كبير جدًا ؛ الكثير من تداخل الحلقات ، أو أن الحلقة نفسها كبيرة جدًا ؛ الفصل لديه اتصال ضعيف (يجب أن تصف خصائص وأساليب الفصل كائنًا واحدًا فقط) ؛ لا تشكل واجهة الفصل تجريدًا متسقًا ؛ تأخذ الطريقة العديد من المعلمات. يجب أن تحاول الحفاظ على عدد المعلمات عند حد أدنى معقول ؛ تتغير الأجزاء الفردية من الفصل بشكل مستقل عن الأجزاء الأخرى من الفصل ؛
تتطلب إعادة هيكلة البرامج عند تغيير البرنامج تغييرًا متوازيًا لعدة فئات. في حالة ظهور مثل هذا الموقف ، من الضروري إعادة تنظيم الفئات لتقليل أماكن التغييرات المحتملة في المستقبل ؛ يجب تغيير العديد من التسلسلات الهرمية للميراث بالتوازي ؛ يجب عليك تغيير عدة مجموعات حالة. من الضروري تعديل البرنامج بطريقة تجعل تنفيذ كتلة الحالة ، وتسميتها بالعدد المطلوب من المرات في البرنامج ؛ أعضاء البيانات ذات الصلة المستخدمة معًا غير منظمين في فئات. إذا كنت تستخدم نفس مجموعة عناصر البيانات بشكل متكرر ، فمن المستحسن التفكير في دمج هذه البيانات ووضع العمليات التي يتم إجراؤها عليها في فئة منفصلة ؛
تستخدم طريقة إعادة هيكلة البرامج عناصر من فئة أخرى أكثر من تلك الخاصة بها. هذا يعني أن الطريقة تحتاج إلى الانتقال إلى فئة أخرى واستدعائها من الفئة القديمة ؛ تم تحميل نوع البيانات الأولية بشكل زائد. لوصف جوهر العالم الحقيقي ، من الأفضل استخدام فئة بدلاً من التحميل الزائد على أي نوع بيانات موجود ؛ الفصل لديه وظائف محدودة للغاية. من الأفضل التخلص من هذه الفئة عن طريق نقل وظائفها إلى فئة أخرى ؛ يتم تمرير البيانات "الضالة" على طول سلسلة الأساليب. البيانات التي يتم تمريرها إلى طريقة فقط لتمريرها إلى طريقة أخرى تسمى البيانات الضالة. عندما تظهر مثل هذه المواقف ، حاول تغيير بنية الطبقات وطرق التخلص منها.
إعادة هيكلة كائن الوسائط لا تفعل شيئًا. إذا كان دور الفصل هو إعادة توجيه استدعاءات الطريقة إلى الفئات الأخرى ، فمن الأفضل التخلص من هذا الوكيل وإجراء مكالمات إلى الفئات الأخرى مباشرةً ؛ فئة واحدة تعرف الكثير عن فصل آخر. في هذه الحالة ، من الضروري جعل التغليف أكثر صرامة للتأكد من أن الوريث لديه الحد الأدنى من المعرفة بوالدته ؛ الطريقة لها اسم مؤسف ؛ أعضاء البيانات عامة. يؤدي هذا إلى تشويش الخط الفاصل بين الواجهة والتنفيذ ، مما يؤدي حتماً إلى كسر التغليف ، ويحد من مرونة البرنامج ؛ ضع التعليقات في الكود المصدري ؛
تستخدم الفئة الفرعية لإعادة هيكلة البرمجيات جزءًا صغيرًا فقط من أساليب أسلافها. يحدث هذا الموقف عندما يتم إنشاء فئة جديدة فقط لترث بعض الطرق من الفئة الأساسية ، وليس لوصف أي كيان جديد. من أجل تجنب ذلك ، من الضروري تحويل الفئة الأساسية بطريقة تتيح الوصول إلى الفئة الجديدة فقط إلى الطرق التي تحتاجها ؛ يحتوي الكود على متغيرات عالمية. يجب أن تكون المتغيرات التي يتم استخدامها فعليًا من قبل البرنامج بأكمله فقط عالمية. يجب أن تكون جميع المتغيرات الأخرى إما محلية أو يجب أن تصبح خصائص لكائن ما ؛ يحتوي البرنامج على التعليمات البرمجية التي قد تكون مطلوبة في يوم من الأيام. عند تطوير نظام ، من المستحسن توفير الأماكن التي يمكن إضافة كود المصدر إليها في المستقبل.
لذا ، فإن جوهر النهج الهيكلي لتطوير برمجيات EIS يكمن في تحللها (تقسيمها) إلى وظائف آلية: ينقسم النظام إلى أنظمة فرعية وظيفية ، والتي بدورها تنقسم إلى وظائف فرعية ، وتلك إلى مهام ، وما إلى ذلك. تصل إلى إجراءات محددة. في الوقت نفسه ، يحتفظ النظام بنظرة شاملة تكون فيها جميع المكونات المكونة مترابطة. عند تطوير نظام "من أسفل إلى أعلى" ، من المهام الفردية إلى النظام بأكمله ، تفقد النزاهة ، وتظهر المشاكل عند وصف تفاعل المعلومات بين المكونات الفردية.
تستند جميع الأساليب الأكثر شيوعًا للنهج الهيكلي إلى عدد من المبادئ العامة:
1 - مبدأ فرق تسد.
2. مبدأ الترتيب الهرمي - مبدأ تنظيم الأجزاء المكونة للنظام في هياكل شجرية هرمية مع إضافة تفاصيل جديدة في كل مستوى.
اختيار مبدأين أساسيين لا يعني أن المبادئ المتبقية ثانوية ، لأن يمكن أن يؤدي تجاهل أي منها إلى عواقب غير متوقعة (بما في ذلك فشل المشروع بأكمله). أهم هذه المبادئ هي:
1. مبدأ التجريد - إبراز الجوانب الأساسية للنظام والإلهاء عن غير الضروري.
2. مبدأ التناسق والصلاحية والاتساق لعناصر النظام.
3. مبدأ هيكلة البيانات - يجب أن تكون البيانات منظمة ومنظمة بشكل هرمي.
في النهج الهيكلي ، هناك مجموعتان أساسيتان من الأدوات تصف الهيكل الوظيفي للنظام والعلاقات بين البيانات. تتوافق كل مجموعة من الأدوات مع أنواع معينة من النماذج (الرسوم البيانية) ، وأكثرها شيوعًا هي:
· DFD (مخططات تدفق البيانات) - الرسوم البيانية لتدفق البيانات.
SADT (التحليل الهيكلي وتقنية التصميم - منهجية التحليل والتصميم الهيكلي) - النماذج والمخططات الوظيفية المقابلة: الرموز IDEF0 (النمذجة الوظيفية للأنظمة) ، IDEF1x (النمذجة المفاهيمية لقواعد البيانات) ، IDEF3x (أنظمة البناء لتقييم جودة الكائن ؛ وصف رسومي لعمليات التدفق ، والتفاعل بين العمليات والأشياء التي تغيرت من خلال هذه العمليات) ؛
· ERD (الكيان - مخططات العلاقة) - مخططات "علاقة الكيان".
في جميع طرق النهج الهيكلي تقريبًا (التحليل الهيكلي) ، يتم استخدام مجموعتين من أدوات النمذجة في مرحلة تكوين متطلبات البرامج:
1. مخططات توضح الوظائف التي يجب أن يؤديها النظام والعلاقات بين هذه الوظائف - DFD أو SADT (IDEF0).
2. بيانات نمذجة الرسوم البيانية وعلاقاتها (ERD).
يعتمد الشكل المحدد للمخططات المدرجة وتفسير إنشائها على مرحلة دورة حياة البرنامج.
في مرحلة تكوين متطلبات البرامج ، تُستخدم نماذج SADT و DFD لبناء نموذج "AS-IS" ونموذج "TO-BE" ، وبالتالي يعكس الهيكل الحالي والمقترح للعمليات التجارية للمؤسسة والتفاعل بينهما (باستخدام نماذج SADT التي تقتصر عادةً على هذه المرحلة فقط ، نظرًا لأنها لم تكن مخصصة في الأصل لتصميم البرامج). بمساعدة ERD ، يتم تنفيذ وصف البيانات المستخدمة في المنظمة على المستوى المفاهيمي ، بغض النظر عن وسائل تنفيذ قاعدة البيانات (DBMS).
حاشية. ملاحظة: نهج مرن لتطوير البرمجيات ، يتم النظر في المبادئ الأساسية للتطوير المرن. يتم توفير قائمة من التقنيات التي تتوافق ، إلى حد ما ، مع مبادئ تطوير البرمجيات المرنة. يتم تحليل القيم والمبادئ الأساسية للتطوير السريع.
يمكنك تنزيل العرض التقديمي لهذه المحاضرة.
الغرض من المحاضرة:
اكتساب فهم للغرض والمبادئ الأساسية لتطوير البرمجيات الرشيقة.
مقدمة
منهجية تطوير البرمجيات الرشيقةركز على استخدام نهج تكراري ، فيه برمجةيتم إنشاؤه تدريجيًا ، بخطوات صغيرة ، بما في ذلك تنفيذ مجموعة معينة من المتطلبات. من المفترض أن المتطلبات قد تتغير. يتم تشكيل الفرق التي تستخدم منهجيات رشيقة من مطورين متعددي الاستخدامات يقومون بمهام مختلفة في عملية إنشاء منتج برمجي.
عند استخدام المنهجيات الرشيقة ، يتم تقليل المخاطر عن طريق تقليل التطوير إلى سلسلة من الدورات القصيرة تسمى التكراراتيدوم من 2 إلى 3 أسابيع. التكرار هو مجموعة من المهام المجدولة لإكمالها في فترة زمنية محددة. في كل تكرار ، يتم إنشاء إصدار عملي من نظام البرنامج ، حيث تكون الأولوية القصوى (لهذا التكرار) متطلبات العملاء. يؤدي كل تكرار جميع المهام اللازمة لإنشاء برنامج عمل: التخطيط ، وتحليل المتطلبات ، والتصميم ، والترميز ، والاختبار ، و توثيق. في حين أن التكرار الفردي عمومًا لا يكفي لإصدار نسخة جديدة من المنتج ، فمن المفهوم أن الإصدار الحالي برمجةجاهز للإصدار في نهاية كل تكرار. في نهاية كل تكرار ، يقوم الفريق بإعادة ترتيب أولويات متطلبات منتج البرنامج ، وربما إجراء تعديلات على تطوير النظام.
مبادئ التنمية الرشيقة ومعنى
بالنسبة لمنهجية التطوير السريع ، يتم الإعلان عن الافتراضات الرئيسية التي تسمح للفرق بتحقيق أداء عالٍ:
- الناس وتفاعلهم ؛
- تسليم برامج العمل ؛
- التعاون مع العميل ؛
- استجابة للتغيير.
الناس والتفاعل.الناس هم أهم جزء في النجاح. أعضاء الفريق الفرديين والاتصالات الجيدة ضرورية للفرق عالية الأداء. لتسهيل التواصل ، تتضمن الممارسات الرشيقة مناقشات متكررة لنتائج العمل والتغييرات في القرارات. يمكن إجراء المناقشات يوميًا لبضع دقائق وفي نهاية كل تكرار مع تحليل نتائج العمل وأثر رجعي. للتواصل بشكل فعال في الاجتماعات ، يجب على أعضاء الفريق الالتزام بقواعد السلوك الرئيسية التالية:
- احترام رأي كل عضو في الفريق ؛
- كن صادقًا في أي اتصال ؛
- شفافية جميع البيانات والإجراءات والقرارات ؛
- الثقة في أن كل مشارك سوف يدعم الفريق ؛
- الالتزام تجاه الفريق وأهدافه.
بالإضافة إلى فريق فعال واتصالات جيدة ، هناك حاجة إلى أدوات برمجية مثالية لإنشاء فرق عالية الأداء في منهجيات رشيقة.
برنامج العمل أكثر أهمية من التوثيق الشامل.تسلط جميع منهجيات أجايل الضوء على الحاجة إلى تقديم أجزاء صغيرة من برامج العمل للعميل على فترات زمنية محددة مسبقًا. برمجة، كقاعدة عامة ، يجب أن يجتاز مستوى اختبار الوحدة والاختبار على مستوى النظام. يجب أن تبقى كمية الوثائق إلى الحد الأدنى. أثناء عملية التصميم ، يجب على الفريق تحديث مستند قصير يحتوي على الأساس المنطقي للقرار ووصفًا للهيكل.
يعد التعاون مع العميل أكثر أهمية من الاتفاقيات الرسمية بموجب العقد.من أجل إكمال المشروع بنجاح ، من الضروري التواصل المنتظم والمتكرر مع العميل. يجب على العميل المشاركة بانتظام في مناقشة القرارات المتخذة بشأن البرنامج ، والتعبير عن رغباته وتعليقاته. يعد إشراك العميل في عملية تطوير البرامج أمرًا ضروريًا لإنشاء منتج عالي الجودة.
الاستجابة السريعة للتغيير أكثر أهمية من اتباع خطة.تحدد القدرة على الاستجابة للتغيير إلى حد كبير نجاح مشروع البرمجيات. في عملية إنشاء منتج برمجي ، غالبًا ما يتغيرون متطلبات العملاء. غالبًا لا يعرف العملاء بالضبط ما يريدون حتى يروا أنه يعمل. برمجة. تبحث منهجيات Agile عن التعليقات من العملاء في عملية إنشاء منتج برمجي. تعد الاستجابة للتغيير أمرًا ضروريًا لإنشاء منتج يحقق رضا العملاء وقيمة الأعمال.
يتم دعم مبادئ التطوير السريع من خلال 12 مبدأ. منهجيات محددة رشيقة تحدد العمليات والقواعد التي تتوافق إلى حد ما مع هذه المبادئ. تعتمد المنهجيات المرنة لإنشاء منتجات البرامج على المبادئ التالية:
- الأولوية القصوى هي إرضاء رغبات العميل من خلال توصيل برامج مفيدة في وقت قصير ، متبوعة بتحديثات مستمرة. تشمل الممارسات الرشيقة الإصدار الأولي السريع والتحديثات المتكررة. هدف الفريق هو تسليم نسخة عمل في غضون أسابيع قليلة من بدء المشروع. من الآن فصاعدًا ، يجب شحن أنظمة البرامج ذات الوظائف الإضافية كل بضعة أسابيع. يمكن للعميل بدء التشغيل التجاري للنظام إذا رأى أنه يعمل بشكل كافٍ. أيضًا ، يمكن للعميل ببساطة التعرف على الإصدار الحالي من البرنامج ، وتقديم ملاحظات مع التعليقات.
- لا تتجاهل المتطلبات المتغيرة ، حتى في وقت متأخر من التطوير. تسمح العمليات المرنة بأخذ التغييرات في الاعتبار لضمان الميزة التنافسية للعميل. تسعى الفرق التي تستخدم منهجيات رشيقة إلى جعل هيكل البرنامج عالي الجودة ، مع الحد الأدنى من تأثير التغييرات على النظام ككل.
- قم بتقديم إصدارات عمل جديدة من البرنامج بشكل متكرر ، على فترات تتراوح من أسبوع إلى شهرين ، مع تفضيل المواعيد النهائية الأقصر. في الوقت نفسه ، الهدف هو تقديم برنامج يلبي احتياجات المستخدم ، مع الحد الأدنى من الوثائق المصاحبة.
- يجب على العملاء والمطورين العمل معًا طوال فترة المشروع. من المعتقد أنه بالنسبة لمشروع ناجح ، يجب على العملاء والمطورين وجميع أصحاب المصلحة التواصل كثيرًا وبطرق عديدة لتحسين منتج البرنامج بشكل هادف.
- يجب تنفيذ المشاريع من قبل الأشخاص المتحمسين. امنح فريق المشروع بيئة عمل صحية ، وقدم الدعم الذي يحتاجونه ، وثق في أن أعضاء الفريق سينجزون المهمة.
- الطريقة الأكثر فاعلية وإنتاجية لنقل المعلومات إلى فريق التطوير وتبادل الآراء داخلها هي المحادثة وجهًا لوجه. في المشاريع الرشيقة ، يكون الأسلوب الرئيسي للتواصل هو التفاعل البشري البسيط. يتم إنشاء المستندات المكتوبة وتحديثها بشكل تدريجي مع تطوير البرنامج وعند الضرورة فقط.
- برنامج العمل هو المؤشر الرئيسي لتقدم المشروع. يتم الحكم على نهج المشروع السريع حتى الانتهاء من خلال مدى تلبية البرنامج الحالي لمتطلبات العميل.
- تشجع العمليات الرشيقة التنمية طويلة الأجل. يجب أن يكون العملاء والمطورون والمستخدمون قادرين على الحفاظ على وتيرة ثابتة إلى أجل غير مسمى.
- إن التركيز الدؤوب على التميز الهندسي وتصميم الجودة يعزز عائدات التقنيات الرشيقة. يسعى أعضاء فريق أجايل إلى إنشاء كود جودة من خلال إعادة بناء ديون بشكل منتظم.
- البساطة هي فن تحقيق المزيد بعمل أقل. يحل أعضاء الفريق المشكلات الحالية بأكبر قدر ممكن من البساطة والفعالية. إذا كانت هناك مشكلة في المستقبل ، فمن الممكن إجراء تغييرات على رمز الجودة دون تكلفة كبيرة.
- تأتي أفضل الهياكل والمتطلبات والتصاميم من فرق ذاتية التنظيم. في الفرق المرنة ، لا يتم تعيين المهام للأعضاء الفرديين ، ولكن للفريق ككل. يقرر الفريق نفسه أفضل السبل لتنفيذ متطلبات العميل. يعمل أعضاء الفريق بشكل تعاوني في جميع جوانب المشروع. يُسمح لكل مشارك بالمساهمة في القضية المشتركة. لا يوجد عضو في الفريق مسؤول بمفرده عن الهندسة أو المتطلبات أو الاختبارات.
- يجب أن يفكر الفريق بانتظام في كيفية أن يصبح أكثر فاعلية ، ثم يعدل ويضبط سلوكه وفقًا لذلك. يقوم فريق أجايل باستمرار بتعديل تنظيمه وقواعده واتفاقياته وعلاقاته.
تتوافق المبادئ المذكورة أعلاه ، إلى حد ما ، مع عدد من منهجيات تطوير البرمجيات:
| النمذجة الرشيقة | مجموعة من المفاهيم والمبادئ والتقنيات (الممارسات) التي تتيح لك أداء النمذجة والتوثيق بسرعة وسهولة في مشاريع تطوير البرمجيات ؛ |
| عملية موحدة رشيقة (AUP) | نسخة مبسطة من IBM RationalUnifiedProcess (RUP) ، والتي تصف تقريبًا بسيطًا ومفهومًا (نموذجًا) لبناء برامج لتطبيقات الأعمال ؛ |
| افتح | إنها طريقة تكرارية-تدريجية لتطوير البرمجيات. تم وضعه كخيار RUP خفيف الوزن ومرن ؛ |
| طريقة AgileData | مجموعة من أساليب تطوير البرامج التكرارية التي يتم من خلالها تحقيق المتطلبات والحلول من خلال تعاون فرق متعددة الوظائف ؛ |
| DSDM | منهجية لتطوير الأنظمة الديناميكية على أساس مفهوم التطوير السريع للتطبيق (RapidApplicationDevelopment ، RAD). يمثل نهجًا تكراريًا وتدريجيًا يؤكد استمرار مشاركة المستخدم / المستهلك في العملية ؛ |
| البرمجة المتطرفة (XP) | البرمجة المتطرفة؛ |
| تطوير البرمجيات التكيفية (ADD) | تطوير البرمجيات التكيفية؛ |
| التطوير المدفوع بالميزات (FDD) | ركز التطوير على الإضافة التدريجية للوظائف ؛ |
| الحصول على حقيقة | نهج تكراري بدون مواصفات وظيفية مستخدمة لتطبيقات الويب ؛ |
| MSFfogAgileSoftwareDevelopment | منهجية تطوير البرمجيات الرشيقة من مايكروسوفت ؛ |
| سكرم | يضع قواعد لإدارة عملية التطوير ويسمح لك باستخدام ممارسات الترميز الحالية من خلال تعديل المتطلبات أو إجراء تغييرات تكتيكية [ |
1. Cascade (English waterfall) - نموذج التطوير القياسي
نموذج تطوير Cascade - نموذج يتم فيه تنفيذ جميع مراحل التطوير بالتتابع - تبدأ المرحلة التالية بعد اكتمال المرحلة السابقة.
يتضمن هذا النموذج الخطوات التالية في عملية تطوير البرنامج:
بادئ ذي بدء ، يتم تحديد المعلمات الفنية للبرنامج المستقبلي ، ونتيجة لذلك ، تمت الموافقة على قائمة متطلبات البرنامج. يأتي بعد ذلك الانتقال إلى التصميم ، حيث يتم إنشاء الوثائق التي تصف للمبرمجين خطة وطريقة لتنفيذ المتطلبات.
بعد اكتمال التصميم ، يقوم المبرمجون بتنفيذ (بناء) المشروع. في مرحلة التنفيذ ، يتم دمج جميع مكونات المشروع. فقط بعد اكتمال هذه المراحل بالكامل يتم اختبار المنتج النهائي وتصحيحه. علاوة على ذلك ، يمكن تنفيذ منتج البرنامج وتقديم الدعم بعد التنفيذ - إدخال وظائف جديدة وإزالة الأخطاء.
المزايا الرئيسية لتطوير الشلال:
2. منهجية تطوير البرمجيات الرشيقة
مجموعة من منهجيات تطوير البرامج التي تتضمن التعاون بين ممثلي العملاء والمطورين. تعتمد طريقة التطوير السريع على نهج تكراري والتكوين الديناميكي للمتطلبات وتنفيذها في مراحل قصيرة.
نتيجة كل مرحلة ، بما في ذلك دورة التكرارات ، هي مشروع برمجيات مصغر ،
هناك العديد من طرق التطوير الرشيقة أشهرها Scrum و Extreme Programming و DSDM.
المزايا الرئيسية للتطوير السريع:
| تقليل المخاطر زيادة تدريجية في وظائف منتج البرنامج ؛ كمية صغيرة من الوثائق المكتوبة ؛ إطلاق النسخة الأساسية من البرنامج في أسرع وقت ممكن. | |||
هناك أيضًا عيوب: |
|||
| عدم القدرة على تحديد ميزانية المشروع بدقة ؛ استحالة تحديد التوقيت الدقيق لاستعداد المشروع ؛ غير مناسب لمنظمات الدولة والميزانية ؛ يتطلب الدافع من الممثلين المسؤولين للعميل. | |||
بيان تطوير البرمجيات الرشيقةنحن نكتشف باستمرار طرقًا أفضل لتطوير البرامج من خلال التطوير المباشر ومساعدة الآخرين. بفضل العمل المنجز ، تمكنا من إدراك ما يلي: الناس والتفاعلأكثر أهمية من العمليات والأدوات منتج العملأهم من التوثيق الشامل التعاون مع العميلأهم من التفاوض على شروط العقد الاستعداد للتغيير أكثر أهميةباتباع الخطة الأصلية هذا يعني ، دون إنكار أهمية ما هو على اليمين ، ما زلنا نقدر ما هو على اليسار أكثر. |
مبادئ التطوير الرشيقة:
|
رضا العملاء بسبب التسليم السريع والمتواصل للبرامج الضرورية ؛ |
