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

المجموعة 1 - متطلبات البرمجيات الجاري تطويرها

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

1. متطلبات تغطية الاختبار

بمعنى آخر، هذا هو عدد الاختبارات لكل متطلبات.

الغرض المتري:تحديد نقاط الضعف في تغطية الاختبار وتسليط الضوء على المخاطر.

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

2. درجة ترابط المتطلبات

يتم حساب المقياس كمتوسط ​​عدد الاتصالات لكل متطلب مع المتطلبات الأخرى.

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

• ستتراوح قيمة هذا المقياس من 0 إلى 1. 1 يعني أن كل متطلب مرتبط بكل متطلب، و0 يعني أنه لا توجد علاقة.
• من الصعب فرض أي قيود على قيم هذا المعامل؛ يعتمد الكثير على تفاصيل الوظيفة والهندسة المعمارية والتقنيات. ومع ذلك، من تجربتي الخاصة، أستطيع أن أقول إنه أمر جيد عندما لا تتجاوز درجة الاتصال 0.2-0.3. وإلا فإن التعديل في إطار أحد المتطلبات سيؤدي إلى سلسلة من التغييرات، وبالتالي الأخطاء المحتملة، في جزء كبير من المنتج.

3. عامل استقرار المتطلبات

الغرض المتري:اعرض عدد المتطلبات التي تم تنفيذها بالفعل والتي يجب إعادة بنائها من إصدار إلى إصدار عند تطوير ميزات جديدة.

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

المجموعة 2 - جودة المنتج الجاري تطويره

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

1. كثافة الخلل

يتم حساب النسبة المئوية للعيوب لكل وحدة فردية أثناء التكرار أو الإصدار.

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

• يمكن أن تكون أسباب العدد الكبير من العيوب في أي وحدة محددة (معامل أكبر من 0.3) مختلفة: متطلبات الجودة الرديئة، ومؤهلات المطور، والتعقيد الفني، وما إلى ذلك. على أية حال، فإن هذا المقياس سوف يلفت انتباهنا على الفور إلى منطقة المشكلة.

2. معامل الانحدار

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

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

3. إعادة فتح معدل الخلل

الغرض المتري:تقييم جودة التطوير وتصحيح العيوب، فضلاً عن مدى تعقيد المنتج أو الوحدة الفردية

• يمكن حساب هذا المقياس للبرنامج بأكمله أو الوحدة الفردية أو الوظيفة. كلما كانت القيمة الناتجة أقرب إلى 0، قل تكرار الأخطاء القديمة أثناء التطوير.
• إذا تبين أن المعامل أكثر من 0.2-0.3، فقد يشير هذا إما إلى التعقيد الفني للوحدة والمتطلبات المرتبطة بها بشكل كبير، أو إلى بنية خرقاء، أو إلى أن الإصلاح السابق تم إجراؤه بشكل سيء.

4. متوسط ​​تكلفة إصلاح الخلل

نسبة مقدار التكاليف التي يتكبدها الفريق عند العمل مع جميع العيوب (على سبيل المثال، كجزء من الإصدار) إلى إجمالي عدد العيوب.

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

• وبطبيعة الحال، لا توجد قيم صحيحة هنا؛ كل شيء سيتم تحديده من خلال تفاصيل حالة معينة

5. عدد العيوب في كود مطور معين

الغرض المتري:تسليط الضوء على الصعوبات المحتملة في فريق التطوير، حيث يفتقر المتخصصون إلى الخبرة أو المعرفة أو الوقت ويحتاجون إلى المساعدة.

• على سبيل المثال، إذا كان 50٪ من جميع العيوب مسؤولاً عن مطور واحد، ويوجد 5 منهم في الفريق، فمن الواضح أن هناك مشكلة. وهذا لا يعني أن هذا المبرمج لا يعمل بشكل جيد، لكنه يشير إلى أنه لا بد من فهم أسباب هذه الحالة.
• يمكن أن يكون المقياس، من بين أمور أخرى، مؤشرًا على وحدة نمطية/وظيفية/نظام يصعب تطويره ودعمه.

المجموعة 3 - قدرة فريق ضمان الجودة وفعاليته

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

1. سرعة فريق ضمان الجودة

يتم حسابها على أنها نسبة نقاط القصة المنفذة (أو المتطلبات، أو قصص المستخدم) على عدة، على سبيل المثال، 4-5 تكرارات (Sprint) إلى عدد التكرارات المحددة.

الغرض المتري:تعبر عددياً عن قدرات وسرعة عمل الفريق لمزيد من التخطيط لنطاق العمل وتحليل اتجاهات التطوير

• يتيح لك المقياس مراقبة سرعة عمل ضمان الجودة ومراقبة العمليات الداخلية أو التأثيرات الخارجية على الفريق التي يمكن أن تؤثر على هذه السرعة.

2. متوسط ​​عمر العيب

إجمالي الوقت الذي تم خلاله اكتشاف العيوب في التكرار أو الإصدار كان مفتوحًا لمجموع العيوب.

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

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

المجموعة 4 - جودة عمل فريق الاختبار

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

1. كفاءة الاختبارات وحالات الاختبار

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

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

2. معدل الأخطاء المفقودة لكل إنتاج

عدد الأخطاء المكتشفة بعد الإصدار \ إجمالي عدد الأخطاء في البرنامج المكتشفة أثناء الاختبار وبعد الإصدار

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

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

3. الوقت الحقيقي الذي يقضيه فريق ضمان الجودة

نسبة الوقت الذي يقضيه الفريق مباشرة في أنشطة ضمان الجودة إلى إجمالي عدد الساعات.

الغرض المتري:أولاً، زيادة دقة التخطيط، وثانياً، مراقبة وإدارة أداء فريق معين.

• تشمل الأنشطة المستهدفة التحليل والتصميم والتقييمات والاختبار واجتماعات العمل وغير ذلك الكثير. الآثار الجانبية المحتملة هي التوقف عن العمل بسبب الحواجز، ومشاكل الاتصال، وعدم توفر الموارد، وما إلى ذلك.
• وبطبيعة الحال، لن يكون هذا المعامل مساويا أبدا لـ 1. وتبين الممارسة أنه بالنسبة للفرق الفعالة يمكن أن يكون 0.5-0.6.

4. دقة تقدير الوقت حسب المنطقة\أنواع\أنواع العمل

الغرض المتري:يسمح باستخدام عامل التصحيح للتقييمات اللاحقة.

• يمكن تحديد درجة دقة التقييم للفريق بأكمله أو للمختبرين الفرديين، للنظام بأكمله أو وحدات البرامج الفردية.

5. حصة العيوب غير المؤكدة (المرفوضة).

الغرض المتري:أظهر عدد العيوب التي تم إنشاؤها "في وضع الخمول".

• إذا تجاوزت نسبة العيوب التي تم رفضها 20%، فقد يواجه الفريق عدم التزامن في فهم ما هو عيب وما هو ليس كذلك.

المجموعة 5 - ردود الفعل ورضا المستخدم

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

1. رضا المستخدم عن خدمات تكنولوجيا المعلومات

مسح منتظم لرضا المستخدمين عن خدمات تكنولوجيا المعلومات مع تسجيل النقاط.

الغرض المتري:إظهار ما إذا كان المستخدمون يثقون بفريق تكنولوجيا المعلومات، وما إذا كانوا يفهمون كيف ولماذا يتم تنظيم عمله، ومدى تلبية هذا العمل للتوقعات.

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

2. رضا المستخدم عن المنتج

استطلاع دوري للمستخدمين حول مدى رضاهم عن المنتج.

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

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

3. إشراك أصحاب المصلحة

عدد المبادرات والمقترحات لتحسين العملية والمنتج التي تم تلقيها أثناء التكرار (الإصدار) من أصحاب المصلحة

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

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

المقاييس

تتضمن مجموعة المقاييس المستخدمة ما يلي:

• ترتيب النمو (يعني تحليل الخوارزميات من حيث التحليل المقارب وترميز O)،
• تحليل نقطة الوظيفة,
• عدد الأخطاء لكل 1000 سطر من التعليمات البرمجية،
• درجة تغطية الكود عن طريق الاختبار،
• عدد الفئات والواجهات،
• مقاييس حزمة البرامج من روبرت سيسيل مارتن،

نقد

أوجه القصور المحتملة في النهج الذي يستهدفه النقد:

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

أنظر أيضا

• مقاييس الكود الأساسية: LOC، SLOC، Gilb، McCabe، Halstead، OOP وغيرها

مؤسسة ويكيميديا. 2010.

• عداد المسافات
• سماعة الطبيب

تعرف على "مقاييس البرامج" الموجودة في القواميس الأخرى:

جودة البرمجيات

تقدير تكلفة تطوير البرمجيات- عند تطوير البرمجيات، تعتبر مشكلة تقدير تكاليف المواد و/أو الوقت المستغرق في إكمال المشروع بنجاح أمرًا مهمًا للغاية. هناك العديد من الطرق لإجراء مثل هذا التقييم، من بينها الطرق العامة... ... ويكيبيديا

المقاييس- له عدة معانٍ: في الرياضيات، القياس هو دالة تحدد المسافات في الفضاء المتري. متري هو اسم بديل للموتر المتري، على وجه الخصوص متري موتر الزمكان 4، والذي ... ... ويكيبيديا

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

عدد أسطر الكود- راجع أيضًا: حجم الكود سطور المصدر للكود SLOC هو مقياس برمجي يستخدم لقياس حجمه عن طريق حساب عدد الأسطر في نص الكود المصدري. كقاعدة عامة، ... ... ويكيبيديا

اختبار الإجهاد- (اختبار التحميل باللغة الإنجليزية) تحديد أو جمع مؤشرات الأداء وزمن الاستجابة لنظام أو جهاز برمجي أو جهاز استجابة لطلب خارجي من أجل إثبات الامتثال لمتطلبات نظام معين ... ويكيبيديا

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

سكروم- تطوير البرمجيات عملية تطوير البرمجيات خطوات العملية التحليل التصميم وثيقة البرمجة ... ويكيبيديا

التعقيد السيكلوماتيكي- البرامج (الإنجليزية: التعقيد الدوري للبرنامج) مقياس هيكلي (أو طوبولوجي) لتعقيد البرنامج، يستخدم لقياس جودة البرمجيات، بناءً على طرق تحليل الكود الثابت. DSP يساوي ... ... ويكيبيديا

زابيكس- 1.1 ألفا 6 يعمل بنظام جنو/لينكس... ويكيبيديا

5). قابلية الصيانة

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

تتضمن قابلية الصيانة خصائص فرعية:

- قابلية التحليل - سمة تحدد الجهد المطلوب لتشخيص الأعطال أو تحديد الأجزاء التي سيتم تعديلها؛

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

- الاستقرار - سمة تشير إلى خطر التعديل؛

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

- الاتساق - سمة توضح توافق سمة معينة مع تلك المحددة في المعايير والاتفاقيات والقواعد واللوائح.

6). قابلية التنقل– مجموعة متنوعة من المؤشرات التي تشير إلى قدرة البرنامج على التكيف مع العمل في الظروف الجديدة لبيئة التشغيل. يمكن أن تكون البيئة تنظيمية وأجهزة وبرامج. ولذلك فإن نقل البرنامج إلى بيئة تنفيذ جديدة قد يرتبط بمجموعة من الإجراءات التي تهدف إلى ضمان عمله في بيئة مختلفة عن البيئة التي تم إنشاؤها فيها مع مراعاة القدرات البرمجية والتنظيمية والفنية الجديدة.

تتضمن إمكانية النقل خصائص فرعية:

– القدرة على التكيف – وهي السمة التي تحدد الجهود المبذولة للتكيف مع البيئات المختلفة؛

– التخصيص (سهولة التثبيت) – وهي سمة تحدد الجهد المطلوب لتشغيل هذا البرنامج أو تثبيته في بيئة خاصة؛

- التعايش - سمة تحدد إمكانية استخدام برامج خاصة في بيئة نظام التشغيل؛

- إمكانية التبادل - وهي خاصية توفر إمكانية التشغيل البيني عند العمل مع برامج أخرى مع التثبيت أو التكييف الضروري للبرنامج؛

- الاتساق - سمة تشير إلى الامتثال للمعايير أو الاتفاقيات لضمان قابلية نقل البرامج.

9.1.1. مقاييس جودة البرمجيات

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

يتضمن نظام قياس البرنامج مقاييس ونماذج قياس تُستخدم لقياس جودته.

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

وفقًا للمعيار، يتم تحديد المقاييس بواسطة نموذج لقياس سمات البرنامج في جميع مراحل دورة الحياة (المقاييس المتوسطة والداخلية) وخاصة في مرحلة الاختبار أو التشغيل (المقاييس الخارجية) للمنتج.

دعونا نتناول تصنيف مقاييس البرمجيات وقواعد إجراء التحليل المتري وعملية قياسها.

أنواع المقاييس. هناك ثلاثة أنواع من المقاييس:

– مقاييس منتج البرمجيات المستخدمة لقياس خصائصه – خصائصه؛

– مقاييس العملية المستخدمة لقياس خاصية العملية المستخدمة لإنشاء منتج.

- مقاييس الاستخدام.

مقاييس منتجات البرمجياتيشمل:

- مقاييس خارجية تشير إلى خصائص المنتج المرئية للمستخدم؛

- المقاييس الداخلية التي تشير إلى الخصائص المرئية لفريق التطوير فقط.

المقاييس الخارجيةيتضمن المنتج المقاييس التالية:

- موثوقية المنتج، والتي تعمل على تحديد عدد العيوب؛

- الوظيفة التي يتم من خلالها تحديد وجود الوظائف وتنفيذها الصحيح في المنتج؛

– الدعم الذي يتم من خلاله قياس موارد المنتج (السرعة والذاكرة والبيئة)؛

- قابلية تطبيق المنتج، مما يساعد على تحديد درجة إمكانية الوصول للدراسة والاستخدام؛

- التكاليف التي تحدد تكلفة المنتج الذي تم إنشاؤه.

المقاييس الداخليةتشمل مقاييس المنتج ما يلي:

- الأبعاد اللازمة لقياس المنتج باستخدام خصائصه الداخلية؛

- التعقيد المطلوب لتحديد مدى تعقيد المنتج؛

- الأنماط التي تعمل على تحديد الأساليب والتقنيات لإنشاء المكونات الفردية للمنتج ومستنداته.

تقيس المقاييس الداخلية أداء المنتج وتكون ذات صلة بالمقاييس الخارجية.

يتم تعيين المقاييس الخارجية والداخلية في مرحلة تشكيل متطلبات البرنامج وتكون موضوعًا لطرق التخطيط لتحقيق جودة منتج البرنامج النهائي.

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

- متطلبات؛

- السيناريوهات والشخصيات؛

- الكائنات المدرجة في السيناريو، وتوطين المتطلبات لكل سيناريو؛

- معلمات الكائن والعمليات، وما إلى ذلك.

تحدد المواصفة القياسية ISO/IEC 9126–2 الأنواع التالية من المقاييس:

- قياس حجم البرنامج بوحدات قياس مختلفة (عدد الوظائف، الخطوط في البرنامج، حجم ذاكرة القرص، وما إلى ذلك)؛

- مقياس للوقت (عمل النظام، تنفيذ المكونات، وما إلى ذلك)؛

– قياس الجهد (إنتاجية العمل، كثافة العمل، وما إلى ذلك)؛

- التدابير المحاسبية (عدد الأخطاء، عدد حالات الفشل، استجابات النظام، الخ).

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

- العدد الإجمالي للأشياء وعدد الأشياء المعاد استخدامها؛

- العدد الإجمالي للعمليات، والعمليات المعاد استخدامها والجديدة؛

- عدد الفئات التي ترث عمليات محددة؛

- عدد الفئات التي تعتمد عليها هذه الفئة؛

– عدد مستخدمي الفئة أو العمليات، الخ.

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

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

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

وبناء على هذه السمات يمكن حساب زمن البرمجة ومستوى البرنامج (البنية والجودة) ولغة البرمجة (تجريد أدوات اللغة والتوجه لمشكلة معينة) وما إلى ذلك.

مقاييس العمليةتشمل المقاييس:

– التكاليف التي تحدد تكاليف إنشاء منتج أو بنية المشروع، مع مراعاة الأصالة والدعم ووثائق التطوير؛

- تقديرات تكلفة العمل المتخصص للشخص الواحد - أيام أو أشهر؛

- عدم موثوقية العملية - عدد العيوب التي لم يتم اكتشافها أثناء التصميم؛

- التكرار، الذي يحدد مدى استخدام المكونات المتكررة.

يمكن أن تتضمن مقاييس العملية وقت التطوير، وعدد الأخطاء التي تم العثور عليها أثناء مرحلة الاختبار، وما إلى ذلك. ويتم استخدام مقاييس العملية التالية عمليًا:

- إجمالي وقت التطوير ووقت منفصل لكل مرحلة؛

- وقت تعديل النموذج؛

- وقت العمل على العملية؛

- عدد الأخطاء المكتشفة أثناء التفتيش؛

- تكلفة مراقبة الجودة؛

- تكلفة عملية التطوير.

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

9.1.2. الطريقة القياسية لتقييم قيم مؤشرات الجودة

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

يُعرّف المعيار ISO/IES 9126-2 مقياس جودة البرمجيات بأنه "نموذج لقياس سمة مرتبطة بمقياس لجودتها". لاستخدام المقاييس عند قياس مؤشرات الجودة، يتيح لك هذا المعيار تحديد أنواع المقاييس التالية:

- مقاييس الحجم في وحدات القياس المختلفة (عدد الوظائف، حجم البرنامج، كمية الموارد، وما إلى ذلك)؛

- قياسات الوقت - فترات من الوقت الحقيقي أو وقت المعالج أو التقويم (وقت تشغيل النظام، وقت تنفيذ المكون، وقت الاستخدام، وما إلى ذلك)؛

- مقاييس الجهد - الوقت الإنتاجي الذي يتم إنفاقه في تنفيذ المشروع (إنتاجية العمل للمشاركين الأفراد في المشروع، وكثافة العمل الجماعي، وما إلى ذلك)؛

- مقاييس الفترات الفاصلة بين الأحداث، على سبيل المثال، الوقت بين حالات الفشل المتعاقبة؛

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

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

تحدد MTBF، باعتبارها سمة موثوقية، متوسط ​​الوقت بين ظهور التهديدات الأمنية وتوفر تقديرًا يصعب قياسه للضرر الناجم عن التهديدات المقابلة.

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

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

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

أولئك. عند تقييم مؤشر فردي باستخدام عناصر التقييم، يتم حساب معامل كبير ك- قياس، ي- فِهرِس، أنا- يصف. على سبيل المثال، كما ي- لنأخذ قابلية النقل كمؤشر. سيتم حساب هذا المؤشر بناءً على خمس سمات ( ط = 1، ...، 5) ، وسيتم ضرب كل منهم بالمعامل المقابل k i .

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

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

لتقديم تقييم قيم مؤشرات الجودة، يتم استخدام معيار يعرض الطرق التالية: القياس والتسجيل والحساب والخبير (وكذلك مجموعات من هذه الطرق).

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

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

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

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

لتقييم قيم مؤشرات الجودة اعتماداً على خصائص الخصائص التي تستخدمها والغرض منها وطرق تحديدها، يتم استخدام المقاييس التالية:

- متري (1.1 - مطلق، 1.2 - نسبي، 1.3 - تكامل)؛

- الترتيبي (الرتبة)، والذي يسمح لك بترتيب الخصائص بالمقارنة مع الخصائص المرجعية؛

- التصنيف، الذي يميز فقط وجود أو عدم وجود الخاصية قيد النظر في البرنامج الذي يتم تقييمه.

تسمى المؤشرات المحسوبة باستخدام المقاييس المترية بالكمية، وتلك المحسوبة باستخدام المقاييس الترتيبية والتصنيفية تسمى بالنوعية.

يتم قياس سمات نظام البرمجيات التي تميز جودته باستخدام مقاييس الجودة. يحدد المقياس قياس السمة، أي. متغير يتم تعيين قيمة له نتيجة للقياس. ولضمان الاستخدام السليم لنتائج القياس، يتم تحديد كل مقياس بواسطة مقياس قياس.

– يعكس المقياس الاسمي فئات خصائص الكائن الذي تم تقييمه دون ترتيبها؛

- يستخدم المقياس الترتيبي لترتيب الخصائص تصاعديا أو تنازليا من خلال مقارنتها بالقيم الأساسية؛

- يحدد مقياس الفاصل الزمني الخصائص الأساسية لكائن ما (على سبيل المثال، تاريخ تقويمي)؛

– يحدد المقياس النسبي قيمة معينة بالنسبة للوحدة المختارة؛

- المقياس المطلق يشير إلى القيمة الفعلية للكمية (مثلا عدد الأخطاء في البرنامج هو 10).

9.1.3. إدارة الجودة PS

تحت إدارة الجودةيُفهم على أنه مجموعة من الهيكل التنظيمي والأشخاص المسؤولين، بالإضافة إلى الإجراءات والعمليات والموارد اللازمة لتخطيط وإدارة تحقيق جودة البرمجيات. إدارة الجودة – تعتمد SQM (إدارة جودة البرمجيات) على تطبيق الأحكام القياسية لضمان الجودة – SQA (ضمان جودة البرمجيات).

الغرض من عملية SQA هو التأكد من أن المنتجات والعمليات متوافقة مع المتطلبات، ومتوافقة مع الخطط وتتضمن الأنشطة التالية:

- تنفيذ المعايير والإجراءات ذات الصلة لتطوير البرمجيات في مراحل دورة الحياة؛

– تقييم مدى الالتزام بأحكام هذه المعايير والإجراءات.

ضمان الجودة هو كما يلي:

- التحقق من اتساق وجدوى الخطط؛

- تنسيق منتجات العمل الوسيطة مع المؤشرات المخططة؛

- فحص المنتجات المصنعة مقابل المتطلبات المحددة؛

– تحليل العمليات المطبقة للامتثال للعقد والخطط؛

- بيئة وأساليب التطوير متوافقة مع أمر التطوير؛

– التحقق من المقاييس المقبولة للمنتجات والعمليات وطرق قياسها وفقاً للمعايير وإجراءات القياس المعتمدة.

الغرض من عملية إدارة إدارة الجودة الشاملة هو مراقبة الجودة (التحكم المنهجي) للتأكد من أن المنتج سوف يرضي العميل ويتضمن الأنشطة التالية:

– تحديد خصائص الجودة الكمية بناءً على احتياجات المستخدمين المحددة والمتوقعة؛

– إدارة تنفيذ الأهداف الموضوعة لتحقيق الجودة.

يعتمد SQM على ضمان ما يلي:

- يتم تحديد أهداف تحقيق الجودة المطلوبة لجميع منتجات العمل في نقاط مراقبة المنتج؛

– تم تحديد استراتيجية تحقيق الجودة والمقاييس والمعايير والتقنيات ومتطلبات عملية القياس وما إلى ذلك؛

– يتم تحديد وتنفيذ الإجراءات المتعلقة بتزويد المنتجات بخصائص الجودة؛

– يتم تنفيذ مراقبة الجودة (SQA والتحقق والتحقق من الصحة) والأهداف، وإذا لم يتم تحقيقها، فسيتم تنظيم العمليات؛

– تتم عمليات قياس وتقييم المنتج النهائي لتحقيق الجودة المطلوبة.

تسلط الأحكام القياسية الرئيسية لإنشاء منتج عالي الجودة وتقييم مستوى الإنجاز الضوء على عمليتين لضمان الجودة في مراحل دورة حياة PS:

- ضمان (تأكيد) جودة البرنامج نتيجة لأنشطة معينة في كل مرحلة من دورة الحياة مع التحقق من امتثال النظام للمعايير والإجراءات التي تركز على تحقيق الجودة؛

- هندسة الجودة، وهي عملية تزويد المنتجات البرمجية بالخصائص الوظيفية والموثوقية والصيانة وخصائص الجودة الأخرى.

تم تصميم عمليات الجودة من أجل:

أ) إدارة الضمان وتطويره والحفاظ عليه وفقًا للمعايير والإجراءات المحددة؛

ب) إدارة التكوين (تحديد الهوية، ومحاسبة الحالة، وإجراءات المصادقة)، والمخاطر والمشروع وفقًا للمعايير والإجراءات؛

ج) التحكم في الإصدار الأساسي للبرنامج وخصائص الجودة المطبقة فيه.

يتضمن تنفيذ هذه العمليات الإجراءات التالية:

– تقييم المعايير والإجراءات المتبعة عند تطوير البرامج.

– تدقيق إدارة وتطوير وتوفير ضمان جودة البرمجيات، بالإضافة إلى وثائق المشروع (التقارير، جداول التطوير، الرسائل، وما إلى ذلك)؛

- مراقبة عمليات التفتيش والمراجعات الرسمية؛

- تحليل ومراقبة اختبار القبول (اختبار) للمحطة الفرعية.

بالنسبة للمؤسسة التي تقوم بتطوير البرمجيات، بما في ذلك المكونات، يجب أن تكون هندسة جودة البرمجيات مدعومة بنظام جودة , إدارة الجودة (التخطيط والمحاسبة والرقابة).

هندسة الجودةيتضمن مجموعة من الأساليب والأنشطة التي يتم من خلالها فحص المنتجات البرمجية لمطابقتها لمتطلبات الجودة وتزويدها بالخصائص المنصوص عليها في المتطلبات البرمجية.

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

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

في النهج الثاني، يتم تصور التدابير واتخاذها لمنع الأخطاء وتحديدها والقضاء عليها بسرعة، بدءًا من المراحل الأولية لدورة الحياة وفقًا للخطة والإجراءات لضمان جودة البرامج المطورة. يتم تقديم هذا النهج في سلسلة المعايير ISO 9000 و9000-1,2,3. الغرض من المعيار 9000–3 هو تقديم توصيات إلى منظمات التطوير لإنشاء نظام جودة وفقًا للمخطط الموضح في الشكل 9.3.

مشترك

عمل مدير نظام التحكم المسؤول

صفات المقاول من العميل

السياسة العامة

مسؤولية

والقوى

ضوابط

خطة الإنجاز

جودة PS

الشكل 9.3. المتطلبات القياسية لتنظيم نظام الجودة

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

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

الإدارة التشغيليةيتضمن أساليب وأنواع الأنشطة التشغيلية للإدارة المستمرة لعملية التصميم، والقضاء على أسباب الأداء غير المرضي للمحطة الفرعية.

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

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

في غياب خدمات الجودة المناسبة، يجب على مطوري البرمجيات تطبيق وثائقهم التنظيمية والمنهجية الخاصة بهم التي تنظم عملية إدارة جودة البرمجيات لجميع فئات المطورين ومستخدمي منتجات البرمجيات.

9.2. نماذج تقييم الموثوقية

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

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

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

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

برمجة وثيقة

إلخ. شبكة ملونة متوفرة في الكتب المدرسية، يصعب إدراكه وفهمه... استخدامه. مم. بتروخينغو فبو "... مرافق. اليوم في برمجةهندسةهناك طريقتان رئيسيتان للتنمية برمجةرزق ...

تشيرنيكوف أليكسي

1 المقدمة

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

ولذلك، لحل هذه المشكلة، يتم استخدام أساليب معقدة ومعقدة إلى حد ما، والتي تتطلب مسؤولية عالية في التطبيق ووقت معين للتكيف (ضبط المعاملات).

يمكن استخدام الأنظمة الشاملة الحديثة لتقييم خصائص مشاريع تطوير البرمجيات لحل المشكلات التالية:

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

1 المقدمة
2 المقاييس
2.1 المقاييس الموجهة نحو الأبعاد (مؤشرات تقدير الحجم)
2.1.1 تقييم LOC (أسطر التعليمات البرمجية)
2.1.1.1 مقاييس الأسلوبية وسهولة فهم البرامج
2.1.2 الإجمالي بواسطة SLOC
2.2 مقاييس الصعوبة
2.2.2 مقاييس هالستيد
2.2.4 مقاييس تشابين

2.4 القائمة العامة للمقاييس
2.4 تلخيص
6 موارد الإنترنت

2. المقاييس

تنقسم مقاييس تعقيد البرنامج عادةً إلى ثلاث مجموعات رئيسية:

• مقاييس حجم البرنامج؛
  
• مقاييس تعقيد تدفق التحكم في البرنامج؛
  
• مقاييس تعقيد تدفق بيانات البرنامج.
  

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

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

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

تعتمد مقاييس المجموعة الثالثة على تقييم استخدام البيانات وتكوينها ووضعها في البرنامج. بادئ ذي بدء، يتعلق هذا بالمتغيرات العالمية. تتضمن هذه المجموعة مقاييس Chapin.

2.1 المقاييس الموجهة نحو الأبعاد (مؤشرات تقييم الحجم)

2.1.1 تقييم LOC (أسطر التعليمات البرمجية)

تقوم المقاييس الموجهة نحو الأبعاد بقياس منتج البرنامج وعملية تطويره بشكل مباشر. وتستند هذه المقاييس إلى تقديرات LOC.

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

تُستخدم المقاييس الموجهة للأبعاد على نطاق واسع في ممارسة تطوير البرمجيات. من المعتاد في المنظمات المشاركة في تطوير منتجات البرمجيات تسجيل المؤشرات التالية لكل مشروع:

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

واستنادًا إلى هذه البيانات، يتم عادةً حساب مقاييس بسيطة لتقييم إنتاجية العمل (KLOC/شهر الرجل) وجودة المنتج.

هذه المقاييس ليست عالمية ومثيرة للجدل، خاصة بالنسبة لمؤشر مثل LOC، والذي يعتمد بشكل كبير على لغة البرمجة المستخدمة.

يعد عدد أسطر التعليمات البرمجية المصدر (أسطر التعليمات البرمجية - LOC، أسطر التعليمات البرمجية المصدر - SLOC) الطريقة الأبسط والأكثر شيوعًا لتقدير حجم العمل في المشروع.

في البداية، نشأ هذا المؤشر كوسيلة لتقييم حجم العمل في مشروع يستخدم لغات البرمجة ببنية بسيطة إلى حد ما: "سطر واحد من التعليمات البرمجية = أمر لغة واحد". ومن المعروف أيضًا منذ فترة طويلة أنه يمكن كتابة نفس الوظيفة بأعداد مختلفة من الأسطر، وإذا أخذنا لغة عالية المستوى (C++، Java)، فمن الممكن كتابة 5-6 أسطر من الوظائف في سطر واحد - هذه ليست مشكلة. ولن يكون ذلك سيئًا للغاية: فأدوات البرمجة الحديثة نفسها تولد آلاف الأسطر من التعليمات البرمجية لعملية تافهة.

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

اعتمادًا على كيفية أخذ الكود المماثل في الاعتبار، هناك مؤشران رئيسيان لـ SLOC:

1. يتم تعريف عدد الأسطر "المادية" من الكود - SLOC (الاختصارات المستخدمة هي LOC، SLOC، KLOC، KSLOC، DSLOC) - على أنه إجمالي عدد أسطر الكود المصدري، بما في ذلك التعليقات والأسطر الفارغة (عند قياس المؤشر على عادة ما يتم تقديم حد لعدد الأسطر الفارغة - عند الحساب، يتم أخذ عدد الأسطر الفارغة في الاعتبار، والذي لا يتجاوز 25٪ من إجمالي عدد الأسطر في كتلة التعليمات البرمجية المقاسة).
   
2. عدد الأسطر "المنطقية" من التعليمات البرمجية - SLOC (الاختصارات المستخدمة هي LSI، DSI، KDSI، حيث "SI" هي تعليمات المصدر) - يتم تعريفه على أنه عدد الأوامر ويعتمد على لغة البرمجة المستخدمة. إذا كانت اللغة لا تسمح بوضع أوامر متعددة في سطر واحد، فإن عدد SLOCs "المنطقية" سوف يتوافق مع عدد الأوامر "المادية"، باستثناء عدد الأسطر الفارغة وأسطر التعليق. إذا كانت لغة برمجة تدعم وضع أوامر متعددة في سطر واحد، فيجب احتساب سطر فعلي واحد كخطوط منطقية متعددة إذا كان يحتوي على أكثر من أمر لغة واحد.
   

بالنسبة لمقياس SLOC، هناك عدد كبير من المشتقات المصممة للحصول على مؤشرات المشروع الفردية، وأهمها:

• عدد الأسطر الفارغة
  
• عدد الأسطر التي تحتوي على التعليقات؛
  
• النسبة المئوية للتعليقات (نسبة سطور التعليمات البرمجية إلى سطور التعليق، والمقياس الأسلوبي المشتق)؛
  
• متوسط ​​عدد الأسطر للوظائف (الفئات، الملفات)؛
  
• متوسط ​​عدد الأسطر التي تحتوي على الكود المصدري للوظائف (الفئات، الملفات)؛
  
• متوسط ​​عدد الصفوف للوحدات النمطية.
  

2.1.1.1 مقاييس الأسلوبية وسهولة فهم البرامج

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

Fi = SIGN (Ncomm.i / Ni – 0.1)

جوهر المقياس بسيط: يتم تقسيم الكود إلى أجزاء متساوية العدد ويتم تحديد Fi لكل منها

2.1.2 الإجمالي بواسطة SLOC

العيوب المحتملة لـ SLOC التي تستهدفها الانتقادات:

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

والشيء الرئيسي الذي يجب تذكره: لا يعكس مقياس SLOC كثافة اليد العاملة لإنشاء البرنامج
.

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

أوافق، من الغباء حساب تكاليف العمالة باستخدام هذا المقياس - من الضروري إجراء تقييم شامل...

2.2 مقاييس الصعوبة

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

2.2.1 المقاييس الموجهة للكائنات

في الظروف الحديثة، يتم إنشاء معظم مشاريع البرمجيات على أساس نهج OO، وبالتالي هناك عدد كبير من المقاييس التي تسمح بتقييم مدى تعقيد المشاريع الموجهة للكائنات.

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

2.2.2 مقاييس هالستيد

يشير مقياس Halsted إلى المقاييس المحسوبة بناءً على تحليل عدد الأسطر والعناصر النحوية للكود المصدري للبرنامج.

يعتمد مقياس هالستيد على أربع خصائص برنامجية قابلة للقياس:

• NUOprtr (عدد عوامل التشغيل الفريدة) - عدد عوامل تشغيل البرنامج الفريدة، بما في ذلك الأحرف الفاصلة وأسماء الإجراءات وعلامات التشغيل (قاموس المشغل)؛
  
• NUOprnd (عدد المعاملات الفريدة) - عدد معاملات البرنامج الفريدة (قاموس المعامل)؛
  
• Noprtr (عدد المشغلين) - إجمالي عدد المشغلين في البرنامج؛
  
• Noprnd (عدد المعاملات) - إجمالي عدد المعاملات في البرنامج.
  

بناءً على هذه الخصائص، يتم حساب الدرجات:

• قاموس البرنامج
  (مفردات برنامج هالستيد، HPVoc): HPVoc = NUOprtr + NUOprnd؛
  
• طول البرنامج
  (طول برنامج هالستيد، HPLen): HPLen = Noprtr + Noprnd؛
  
• نطاق البرنامج
  (حجم برنامج هالستيد، HPVol): HPVol = HPLen log2 HPVoc؛
  
• تعقيد البرنامج
  (صعوبة هالستيد، HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd)؛
  
• بناءً على مؤشر HDiff، يُقترح تقييم جهود تطوير المبرمج باستخدام مؤشر HEff (Halstead Effort): HEff = HDiff × HPVol.
  

2.2.3 مقاييس التعقيد السيكلوماتي لمكابي

يعد مؤشر التعقيد السيكلوماتي أحد المؤشرات الأكثر شيوعًا لتقييم مدى تعقيد مشاريع البرمجيات. تم تطوير هذا المؤشر من قبل العالم مكابي في عام 1976، وهو ينتمي إلى مجموعة المؤشرات لتقييم مدى تعقيد تدفق التحكم في البرنامج ويتم حسابه على أساس الرسم البياني المنطقي للتحكم في البرنامج (الرسم البياني لتدفق التحكم). تم إنشاء هذا الرسم البياني في شكل رسم بياني موجه، حيث يتم تمثيل العوامل أو التعبيرات الحسابية كعقد، ويتم تمثيل نقل التحكم بين العقد كأقواس.

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

الصيغة المبسطة لحساب التعقيد السيكلوماتي هي كما يلي:

ج = ه – ن + 2،

أين ه –عدد الأضلاع ، و ن –عدد العقد
على الرسم البياني منطق التحكم.

عادةً، لا يتم أخذ العوامل المنطقية في الاعتبار عند حساب التعقيد السيكلوماتي.

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

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

يمكن حساب مؤشر التعقيد الدوري لوحدة وطريقة ووحدات هيكلية أخرى للبرنامج.

هناك عدد كبير من التعديلات على مؤشر التعقيد السيكلوماتي.

• التعقيد الدوري "المعدل" - لا يأخذ في الاعتبار كل فرع من فروع عامل الاختيار المتعدد (المفتاح)، ولكن المشغل بأكمله ككل واحد.
  
• التعقيد الدوري "الصارم" - يشمل العوامل المنطقية.
  
• الحساب "المبسط" للتعقيد الدوري - لا يتضمن الحساب على أساس رسم بياني، ولكن على أساس حساب عوامل التحكم.
  

2.2.4 مقاييس تشابين

هناك عدة تعديلات عليه. دعونا نفكر في نسخة أبسط وفعالة جدًا من هذا المقياس من وجهة نظر الاستخدام العملي.

يتمثل جوهر الطريقة في تقييم قوة المعلومات لوحدة برمجية واحدة من خلال تحليل طبيعة استخدام المتغيرات من قائمة المدخلات والمخرجات.

يتم تقسيم المجموعة الكاملة للمتغيرات التي تشكل قائمة الإدخال/الإخراج إلى أربع مجموعات وظيفية.

Q = a1P + a2M + a3C + a4T، حيث a1، a2، a3، a4 هي معاملات الترجيح.

س = ف + 2M + 3C + 0.5T.

2.3 تقييم أولي يعتمد على الأساليب الإحصائية حسب مراحل تطوير البرنامج

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

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

دعونا نسلط الضوء على المراحل النموذجية في تطوير البرنامج:

• تطوير مواصفات متطلبات البرنامج؛
  
• تعريف العمارة؛
  
• تطوير الهيكل المعياري للبرنامج، وتطوير الواجهات بين الوحدات. تطوير الخوارزميات.
  
• تطوير الكود واختباره.
  

الآن دعونا نحاول إلقاء نظرة على عدد من المقاييس التي غالبًا ما تستخدم للتقييم الأولي في المرحلتين الأوليين.

2.3.1 تقييم أولي لتعقيد البرنامج في مرحلة تطوير مواصفات متطلبات البرنامج

لتقييم نتائج هذه المرحلة يمكن استخدام مقياس العدد المتوقع للمشغلين Nprog للبرنامج:

Nprog =NF*Nunit

حيث: NF - عدد الوظائف أو المتطلبات في مواصفات المتطلبات للبرنامج الجاري تطويره؛
Ned – قيمة واحدة لعدد عوامل التشغيل (متوسط ​​عدد عوامل التشغيل لكل دالة أو متطلب متوسط). قيمة Ned إحصائية.

2.3.2 تقييم التعقيد الأولي في مرحلة تعريف العمارة

Si = NI / (NF * NIed * Ksl)

أين:
NI - العدد الإجمالي للمتغيرات المرسلة عبر الواجهات بين مكونات البرنامج (إحصائية أيضًا)؛
NIed – قيمة واحدة لعدد المتغيرات المنقولة عبر الواجهات بين المكونات (متوسط ​​عدد المتغيرات المنقولة عبر الواجهات لكل متوسط ​​وظيفة أو متطلب)؛
Ksl هو معامل تعقيد البرنامج الذي يتم تطويره، ويأخذ في الاعتبار زيادة تعقيد وحدة البرنامج (التعقيد لكل وظيفة واحدة أو متطلبات مواصفات متطلبات البرنامج) للبرامج الكبيرة والمعقدة مقارنة بالبرنامج المتوسط.

2.4 القائمة العامة للمقاييس

يحتوي الجدول 1 على وصف موجز للمقاييس التي لم يتم تضمينها في الوصف التفصيلي أعلاه، ولكن مع ذلك، فإن هذه المقاييس ضرورية ومهمة، ولكنها أقل شيوعًا من الناحية الإحصائية.

لاحظ أيضًا أن الغرض من هذه المقالة هو إظهار المبدأ، وليس وصف جميع المقاييس الممكنة في العديد من المجموعات.

مجموعات جديدة من المواد للتحميل! لقد قمنا بجمع حزم من المواد حول المواضيع الحالية، بما في ذلك عروض الخبراء والندوات عبر الإنترنت والمقالات وأمثلة التنفيذ وما إلى ذلك.
لتنزيل المواد، انقر على الزر المناسب:

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

وبالتالي، يمكن استخدام متطلبات دليل ISO 9000-3 لتقييم جودة عملية التطوير في المؤسسة الخاصة أو في منظمة المقاولين. حاليًا، يتم استخدام إصدار 2000 من المعيار في كل مكان، حيث يكون التحكم في العمليات في المقدمة، ومع ذلك، في هذا الإصدار من المعيار لا توجد خصوصية تتعلق بتطوير البرمجيات.

من عيوب معيار ISO 9000 هو صعوبة قياس مستوى جودة عملية تطوير البرمجيات وفقًا لنموذج الجودة المقترح.

بين مطوري البرمجيات، وخاصة في الخارج (بشكل أساسي في الولايات المتحدة الأمريكية)، يتم تصنيف نموذج الجودة البديل بدرجة عالية: CMM - SEI. تم تطوير نموذج الجودة هذا في معهد هندسة البرمجيات تحت رعاية وزارة الدفاع الأمريكية. في البداية، تم استخدام نموذج الجودة هذا من قبل المؤسسات الحكومية، وخاصة العسكرية، عند تقديم طلبات تطوير البرمجيات. يُستخدم المعيار الآن على نطاق واسع لتحليل واعتماد عمليات تطوير البرمجيات للشركات التي تنتج برامج معقدة في مجالات التطبيقات المهمة. تتمثل المزايا المهمة لنموذج CMM في التداخل الهرمي لنماذج الجودة، والذي يسمح لك بقياس ومقارنة مستويات جودة العملية في المؤسسات المختلفة وضمان التحسين الفعال لجودة العملية.

كما طورت ISO الآن نموذجًا للجودة لقياس الجودة وتحسينها.

في احترام معين، تكون نماذج الجودة CMM وISO قابلة للتبادل، ومع ذلك، في جوهرها، لا تتعارض مع بعضها البعض، لأنها تعتمد على نفس نموذج الجودة - إدارة الجودة الشاملة - إدارة الجودة الشاملة.

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

جودة منتجات البرمجيات

جودة مكونات البرمجيات

يعتمد تطوير أنظمة البرمجيات الكبيرة الحديثة بشكل متزايد على تطوير المكونات (Component Base System - CBS). يمكن لتكنولوجيا البناء CBS أن تقلل بشكل كبير من التكلفة ووقت التطوير. وفي الوقت نفسه، تزداد المخاطر المرتبطة باستخدام مكونات البرامج التي طورتها الشركات المصنعة المختلفة في النظام.

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

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