نموذج الشلال تحليل المتطلبات اختبار تكامل تنفيذ التصميم صياغة مسودة مواصفات المنتج صياغة بنية المنتج تطوير كود المصدر دمج أجزاء كود المصدر الاختبار واستكشاف الأخطاء وإصلاحها

يصف نموذج حالة استخدام عملية تطوير البرامج الموحدة (USDP) الحالات التي سيتم فيها استخدام التطبيق. يصف النموذج التحليلي الفئات الأساسية للتطبيق. يصف نموذج التصميم الاتصالات والعلاقات بين الفئات والكائنات المخصصة ، ويصف نموذج النشر توزيع البرامج عبر أجهزة الكمبيوتر. يصف نموذج التنفيذ التنظيم الداخلي لرمز البرنامج. يتكون نموذج الاختبار من مكونات الاختبار وإجراءات الاختبار وحالات الاختبار المختلفة.

مكونات بنية منتج البرامج النموذجية ومتطلبات البرامج النموذجية تنظيم البرنامج فئات النظام الرئيسية تنظيم البيانات قواعد الأعمال واجهة المستخدم إدارة الموارد قابلية تطوير الأداء الأمني ​​التفاعل مع الأنظمة الأخرى (التكامل) التدويل ، التعريب ، بيانات المدخلات والمخرجات معالجة الأخطاء

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

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

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

قائمة أسئلة تسمح لك بالتوصل إلى استنتاج حول جودة البنية: هل استراتيجية تصميم واجهة المستخدم موصوفة. ما إذا كانت استراتيجية تصميم واجهة المستخدم موصوفة أم لا. ما إذا كانت واجهة المستخدم معيارية بحيث لا تؤثر التغييرات عليها على بقية النظام. ما إذا كانت واجهة المستخدم معيارية بحيث لا تؤثر التغييرات عليها على بقية النظام. ما إذا كان قد تم توفير وصف لاستراتيجية الإدخال / الإخراج أم لا. ما إذا كان قد تم توفير وصف لاستراتيجية الإدخال / الإخراج أم لا. ما إذا كان قد تم إجراء تحليل أداء للنظام الذي سيتم تنفيذه باستخدام هذه البنية. ما إذا كان قد تم إجراء تحليل أداء للنظام الذي سيتم تنفيذه باستخدام هذه البنية. هل تم إجراء تحليل موثوقية النظام المصمم؟ هل تم إجراء تحليل موثوقية النظام المصمم؟ هل تم إجراء تحليل لقابلية النظام للتوسع؟ هل تم إجراء تحليل لقابلية النظام للتوسع؟

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

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

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

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

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

يوجد الآن في هندسة البرمجيات طريقتان رئيسيتان لتطوير برمجيات نظم المعلومات ، والفرق الأساسي بينهما يرجع إلى طرق مختلفة لتحلل الأنظمة: نهج وظيفي معياري (هيكلي) ، والذي يقوم على مبدأ التحلل الوظيفي ، حيث يتم وصف هيكل النظام من حيث التسلسل الهرمي لوظائفه ونقل المعلومات بين العناصر الوظيفية الفردية ، و نهج وجوه المنحى ، الذي يستخدم تحليل الكائنات ، ويصف بنية IS من حيث الكائنات والعلاقات بينها ، وسلوك النظام من حيث المراسلة بين الكائنات.

لذا ، فإن جوهر النهج الهيكلي لتطوير برمجيات نظم المعلومات يكمن في تحللها إلى وظائف مؤتمتة: ينقسم النظام إلى أنظمة فرعية وظيفية ، والتي بدورها تنقسم إلى وظائف فرعية ، وتنقسم إلى مهام ، وما إلى ذلك حتى محددة. إجراءات. في الوقت نفسه ، يحافظ IS على سلامة التمثيل ، حيث تكون جميع المكونات مترابطة. عند تطوير نظام "من الأسفل إلى الأعلى" ، من المهام الفردية إلى النظام بأكمله ، تفقد السلامة ، وتظهر المشاكل عند وصف تفاعل المعلومات بين المكونات الفردية.

المبادئ الأساسية للنهج الهيكلي هي:

يا مبدأ " فرق تسد "؛

يا المبدأ الترتيب الهرمي - مبدأ تنظيم النظم المكونة في هياكل شجرية هرمية مع إضافة تفاصيل جديدة في كل مستوى. لا يعني اختيار مبدأين أساسيين أن المبادئ المتبقية ثانوية ، لأن تجاهل أي منها يمكن أن يؤدي إلى عواقب غير متوقعة.

أهم هذه المبادئ هي:

س التجريد - إبراز الجوانب الأساسية للنظام ؛

يا الاتساق - صحة واتساق عناصر النظام ؛

o هيكلة البيانات - ينبغي تنظيم البيانات وتنظيمها بشكل هرمي.

الأسس المنهجية لتقنيات تطوير البرمجيات

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

النماذج الرسومية (المرئية) هي أدوات لتصور ووصف وتصميم وتوثيق بنية النظام. يعتمد تكوين النماذج المستخدمة في كل مشروع محدد ، ودرجة تفصيلها في الحالة العامة ، على العوامل التالية:

o صعوبات النظام المصمم ؛

o الاستيفاء الضروري لوصفه ؛

o معرفة ومهارات المشاركين في المشروع.

o الوقت المخصص للتصميم.

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

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

1. Cascade (English waterfall) - نموذج التطوير القياسي

نموذج تطوير Cascade - نموذج يتم فيه تنفيذ جميع مراحل التطوير بالتتابع - تبدأ المرحلة التالية بعد اكتمال المرحلة السابقة.

يتضمن هذا النموذج الخطوات التالية في عملية تطوير البرنامج:

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

بعد اكتمال التصميم ، يقوم المبرمجون بتنفيذ (بناء) المشروع. في مرحلة التنفيذ ، يتم دمج جميع مكونات المشروع. فقط بعد اكتمال هذه المراحل بالكامل يتم اختبار المنتج النهائي وتصحيحه. علاوة على ذلك ، يمكن تنفيذ منتج البرنامج وتقديم الدعم بعد التنفيذ - إدخال وظائف جديدة وإزالة الأخطاء.

المزايا الرئيسية لتطوير الشلال:

2. منهجية تطوير البرمجيات الرشيقة

مجموعة من منهجيات تطوير البرامج التي تتضمن التعاون بين ممثلي العملاء والمطورين. تعتمد طريقة التطوير السريع على نهج تكراري والتكوين الديناميكي للمتطلبات وتنفيذها في مراحل قصيرة.

نتيجة كل مرحلة ، بما في ذلك دورة التكرارات ، هي مشروع برمجيات مصغر ،

هناك العديد من طرق التطوير الرشيقة أشهرها Scrum و Extreme Programming و DSDM.

المزايا الرئيسية للتطوير السريع:

مبادئ التطوير الرشيقة:

لذا ، فإن جوهر النهج الهيكلي لتطوير برمجيات 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).

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. موثوقية عالية. تجعل الوثائق غير المفهومة أو غير المتقنة البرامج أقل موثوقية ، نظرًا لأن مستخدميها أكثر عرضة لارتكاب الأخطاء ، فمن الصعب عليهم معرفة أسبابها وكيفية التعامل مع عواقبها.

سهولة المرافقة. يتم إنفاق قدر كبير من المال والوقت على تحليل المشكلات الناتجة عن أخطاء المستخدم. غالبًا ما تكون التغييرات التي تم إجراؤها في إصدارات البرامج الجديدة مجرد تغيير في واجهة الوظائف القديمة. يتم تقديمها حتى يتمكن المستخدمون أخيرًا من معرفة كيفية استخدام البرنامج والتوقف عن الاتصال بخدمة الدعم الفني. القيادة الجيدة إلى حد كبير