M.A.H.S.A
09-01-2011, 11:04 AM
متدهاي تجزيه و تحليل خطا و آثار ناشي از آن اولين بار در زمان بعد از جنگ جهاني دوم براي سيستم‌هاي مكانيكي و الكتريكي بكار مي‌رفت و آنزمان هنوز سيستم‌هاي نرم افزاري در مغازه‌ها يافت نمي‌شدند. استانداردهاي معمول و خط‌مشي‌هاي امروزي هم حتي مشكلات و خطاهاي موجود در نرم افزارها را بسيار بطور خلاصه بررسي مي‌كنند و همچنين عنوان مي‌دارند كه اين موضوع فقط براي برخي موارد جوابگو و قابل توسعه است. هنوز هيچ راهكار استاندارد جهت ناكارآمدي‌هايي كه توسط خطاهاي سيستم و اثرات مربوط به آنها در FMEA پديد مي‌آيد منتشر نشده است .
FMEA / FMECA عمومي در استاندارد IEC60812 تعريف شده است. نسخة اصلي و كامل آن مربوط به سال 1985 ميشود 2 IECT561/WG البته بر روي نسخة ويرايش شدة آن كار مي‌كنند نسخة پيش نويس كميتة كاري (CD) بين اعضاي كميته در بهار 2001 پخش شد.
FMEA / FMECA عمومي در IEC 60812 با تمامي خط مشي‌هايي كه در قسمت قبل توضيح داده شد به خوبي سازگار است. اين استاندارد نقطة خوبي براي استاندارد نرم افزاري FMEA حساب ميشود. بسته به اهداف و سطوح مختلف اين استاندارد با تمامي نيازهاي ما به صورت كامل قابل تنظيم است. در اين قسمت تمامي موارد و ساختارهاي FMEA گنجانده نشده است در عوض قسمتي از ان كه با حلات خطاي سيستم‌هاي كاربردي اتوماسيون نرم افزاري مربوط است مطرح شده است .
براي بررسي FMEA براي سيستم‌هاي نرم افزاري اتوماسيون بايد هم قسمت سخت افزاري و هم نرم افزاري را كنترل نمود اما براي آنكه بيشتر به مطلب پرداخته شود فقط قسمت نرم افزاري آن مورد بررسي قرار مي‌گيرد.
براي نقطة شروع قدم‌هاي اصلي FMEA به صورت زير تعريف مي‌شوند.
1)تعريف محدودة سيستم براي تجزيه و تحليل
2)شناخت نيازهاي سيستم و نوع كار آن.
3)شروط خطا / موفقيت را تعريف كنيم.
4)سيستم را به عناصر ريزتر تقسيم كنيم
5)تعيين حالات خطاي هر عنصر و آثارشان و ثبت آنها
6)نتايج خطاها را خلاصه كنيد.
7)يافته‌ها را گزارش كنيد.
FMEA در برگه‌هاي ستون بندي شده نوشته ميشود. يك فرم استاندارد FMEA در پيوست ارائه شده است كه به راحتي مي‌تواند با نيازهاي يك فعاليت FMEA هماهنگ شود.
آناليز بحراني بودن يك خصوصيت كمي به FMEA كيفي است. با استفاده از آثار حالت خطاي يافته شده توسط FMEA، هر اثر خطا توسط ميزان خساراتي كه به شخص، وسايل و يا محيط وارد مي‌كند طبقه بندي ميشود. فركانس اينكه آن خطا اثرات خود را به همراه خرابي خود بر جاي بگذارد را بحراني بودن آن مي گويند. مجموعة شدت و تواتر انها به صورت تجزيه و تحليل نتايج انها در ماتريس درجة بحراني مشخص ميشود. در استاندارد SAEY 1739 سومين بعد نيز به بحراني بودن با معرفي مفهوم عدد اولويت ريسك اضافه مي شود كه نتيجه سه مفهوم است. شدت، رويداد و تشخيص.
درجة تحليل
FMEA يك روش BOTTOM-UP است كه در آن ليستي كه مورد تجزيه و تحليل قرار مي‌گيرد به عناصر جداگانه‌اي تقسيم ميشود. اين روش بايد به نمونه‌اي انجام شود كه حالت خطاي اجسام كاري كه در پايين قرار دارند به راحتي شناخته شوند. اثرات ناشي از خطاي لايه پايين به عنوان خطاي لايه بالا جايگزين ميشود.
عواملي كه باعث انتخاب لاية پاييني مناسب ميشود بستگي به هدف تجزيه و تحليل و دسترسي به اطلاعات طراحي دارد.
وقتي صحبت از FMEA در نرم افزارها ميشود اغلب منظور اين است كه بيابيم ايا خطايي در اجزاء سيستم وجود دارند كه بتواند كل سيستم را تحت تاثير خود قرار دهد؟
تحليل وقتي اغاز ميشود اجزاء برنامه به صورت متوالي وپشت سرهم در يك پردازش اجرا مي‌شوند و يا به صورت همزمان و در پردازش‌هاي موازي كنترل مي‌شوند.
در حال حاضر روش معمول براي بررسي امنيت و ايمني سيستم‌هاي اتوماسيون اجراي يك سري عمليات و روية خاص روي برنامه است براي مثال بروي قسمت منطق برنامه (Logic unit) يا قسمتهاي عمومي آن. نرم افزارهاي به اين صورت به دو گروه تقسيم مي‌شوند نرم افزارهاي سيستم (System softward) و برنامه‌هاي كاربردي (Application) نرم افزارهاي سيستمي خود به دو گروه هسته (kemel) و سرويسها تقسيم ميشود. (مترجم: سيستم عامل‌هايي مانند windows داراي يك هسته تكي و يك پارچه هستند ولي در سيستم‌هايي مانند Linux اين هسته از تعداد زياد برنامه‌هاي جدا از هم تشكيل شده است.) كرنل شامل مراحل راه‌اندازي، بارگذاري سيستم، تست عملكرد خود و غيره است. اما سرويسها شامل عملياتي مانند مديريت داده‌ها است. سكوي نرم افزاري شامل كتابخانه استانداردي از كامپوننت‌ها، بلاك‌هاي برنامه (ماژول‌ها) كه برنامه از طريق اتصال به تعداد مورد نيازي از اين بلاك‌ها شكل‌مي‌گيرد است كه در قسمت سرويسها قرار مي گيرد.
سيستم اتوماسيون همچنين شامل يك واسط گرافيكي نيز هست. توسط اين قسمت برنامه اطلاعات كدهاي مورد نظر خود را تبديل به تكه‌هاي كد كرده و سپس به صورت خودكار آنها را اجرا مي‌كند.
به صورت ضمني اين طور به نظر مي‌رسد كه در FMEA نرم افزاري براي شروع تحليل مي‌توان بلوك‌هاي برنامه يا همان رويه‌ها شروع كرد. در عمل اين مورد غير ممكن مي‌نمايد و كار را بسيار پيچيده و سنگين مي‌كند و ثانيا حالات خطاي رويه ها را غير قابل تشخيص مي‌كند.
عنوان شده است كه FMEA نرم افزار فقط در سطح برنامه قابل بررسي است. برنامه‌هاي نرم افزاري از واحدهايي به نام (Blocks of lnstrucion) B1 يا بلوك‌هاي دستورالعمل تشكيل شده است كه با خواص زير شناخته مي‌شوند.
1)يا به صورت مياني اندواز BI هاي كوچكتر تشكيل شده‌اند يا به صورت يك ترمينال جداگانه كه قابل شكسته شدن به BI هاي كوچكتر نيست.
2)آنها فقط يك نقطه خروج دارد. آنها نتايج خروجي را از روي ورودي ايجاد مي‌كنند. برخي از BI ها دسترسي مستقيم به متغيرهاي سخت افزار دارند.
3)آنها زمان اجراي ثابتي دارند.
4)آنهاها داده‌ها را با متغيرهاي حافظه مبادله مي‌كند. متغيرهاي حافظه كه توسط يك B1 ايجاد مي‌شوند توسط يك يا چند BI خوانده ميشود.
حالات خطا
وقتي كه يك راه مناسب جهت تجزيه سيستم مورد تحليل يافت شد قدم بعدي شناخت حالات خطاي حالات خطاي اجزاء است. براي سخت افزار بستگي به تجربه اپراتور و مقايسه با اجزاء مشابه. بسيار راه مستقيم و مشخصي دارد. سازندگان اجزاء سخت افزاري اغلب حالات خطا و فركانس ايجاد انها را ذكر مي‌كنند.
در مورد اجزاي نرم افزار اين اطلاعات وجود ندارند و حالت خطاي انها ناشناخته است (اگر شناخته شده بود قبلا درست مي‌شد) بنابراين شناخت حالات خطا سخت‌ترين قسمت كار SWFMEA است.
تحليلگران بايد دانش خود را دربارة نرم افزار و حالات خطاي مربوط به آن بكار گيرند.
در تحليل سه پروژه نرم افزاري بزرگ به موضوعات خطاي مهم زير بر مي‌خوريم:
1-محاسباتي
2-منطقي
3-ورودي خروجي داده
4-مديريت داده
5-واسط ها
6-تعريف نوع داده
7-پايگاه داده
8-غيره
براي حالات خطاي يك واحد پردازش داريم.
*سيستم عامل متوقف شد.
*برنامه با پيغام واضحي متوقف شد.
*برنامه اجرا شد ولي نتايج كاملا اشتباه تحويل داد.
*برنامه اجرا شد ولي نتايج غلط را علاوه بر نتايج درست تحويل داد.
به صورت خيلي اختصاصي تر براي شكل 6 حالات خطاي زير را عنوان كرده‌اند:
*اجراي BI با نقطة خروج (Exit Point) پايان نمي‌يابد.
*زمان اجراي BI در محدودة خاص نمي گنجد.
• BI فعاليت در نظر گرفته شده را انجام نمي‌دهد و يا فعاليتهاي در نظر گرفته نشده انجام مي‌دهد:
• خروجي مورد نظر را نمي‌دهد.
• متغيرهايي را تغيير مي‌دهد كه نبايد تغيير دهد.
• تعامل مورد نظر را با ورودي / خروجي انجام نمي‌دهد.
• با CPU آنطور كه بايد تعامل ندارد.
• كدهاي حافظه و يا ثابتها را تغيير مي‌دهد.
از نگاه ديگر مي‌توان حالات خطا را به دو گروه داده و پردازش داده تقسيم كرد. براي هر ورودي و خروجي اجزاء نرم افزار چهار حالت خطاي زير را در نظر مي‌گيرند:
*داده‌هاي از دست رفته
*داده‌هاي غلط
*داده‌ها در زمان نادرست رسيده‌اند.
*داده‌هاي زيادي (مترجم: اين مورد مانند Data overflow است كه براي نفوذ به سيستم‌هاي نرم افزاري بسيار زياد مورد استفاده نفوذگران قرار مي‌گيرد. به عنوان مثال براي نرم افزاري مانند win2k هنوز بعد از 5 سال وصله‌هايي براي بهبود آنها پياده سازي مي‌شوند)
از طرف ديگر براي هر رخداد (هر قدم پروسس) 4 حالت زير را در نظر گرفته اند:
*اختلال برنامه hang) كردن)
*رخدادهايي كه عمل نكرده‌اند اما برنامه به كار خود ادامه داده است.
*منطق ناصحيح
زمان بندي و ترتيب انجام.
همچنين كلاسهاي حالات خطاي ديگر نيز شامل:
• Stop نرم / سخت افزاري
• Crash نرم / سخت افزاري
• Hang نرم / سخت افزاري
• پاسخگويي كند.
• عدم اجراي برنامه
• پيام‌هاي غلط
• حجم داخلي از حد مجاز فراتر رفته باشد
• از دست دادن سرويس
• روشهاي شناخت خطا هم مانند موارد زير است:
• استفاده از برنامه مانيتور كردن task ها به اينصورت كه task هايي كه از دست رفته‌اند را شناسايي مي‌كند.
• برنامه مديريت پيام‌ها اعداد پشت سر هم را كنترل مي‌كند تا پيامهايي كه مرتب هستند را شناسايي كند.
• يك فراخوان كنندة متدها كه براي اطينان از حضور همة اعضا است.
• يك چك كنندة پيام‌ها براي شناخت پيامهايي كه دوبار فرستاده شده‌اند.
• مشكل اصلي اينجاست كه IEC60812 بيشتر بر روي حالات خطاي سيستم‌هاي مكانيكي بحث مي‌كند و كمتر به حالات خطاي نرم افزاري مي‌پردازد. FMEA همچنين شامل مشخصه‌هاي براي شناخت دلايل اصلي ايجاد خطا مي‌باشد بنابراين وقتي به جستجوي علل اصلي حالات خطا مي‌پردازيم طراحي پروسه بايد مورد بررسي قرار گيرد. IEC 60812 يك جدول از علل خطا ارائه كرده است كه به صورت گسترده براي SWFMEA مورد استفاده قرار مي‌گيرد.
اطلاعات مورد نياز
استاندارد IEC 60812 به صورت گسترده‌اي اطلاعات موردنياز جهت رويه‌هاي FMEA عمومي را ارائه كرده است. اين استاندارد تاكيد بسياري بر دسترسي آزاد به تمامي اطلاعات مربوطه و مورد احتياج و همچنين همكاري فعال طراح برنامه دارد.
قسمت اصلي اين اطلاعات شامل:
*ساختار سيستم
*فعال شدن، عملكرد، كنترل نگهداري برنامه
*محيط برنامه
*مدل سازي
*مجدوده سيستم
*توضيحات ساختاري برنامه
*ساختار برنامه.
*دياگرام‌هاي كلاس‌ها (مثل نمودارهاي UML)
*اهميت خطاها
يك سيستم نرم افزاري كه به خوبي مستند شده باشد اغلب اين موارد را درون مستندات خود دارد.
آناليز بحراني بودن
همانطور كه قبلا گفته شد، آناليز بحراني بودن يك توسعه كمّي بر روي FMEA كيفي است مبتي بر شدت اثرات ناشي از خطا، فركانس رخداد خطا و احتمال تشخيص آن. براي سيستم‌هاي اتوماسيون شدت اثرات خطا بر حسب اثري كه بر روي پروسة كنترل ميگذارند معين ميشود. حتي اگر سخت باشد،
شدت خطاي يك جزء تكي سطح پايين (low Level) مي‌تواند به صورت عقب گرد با عنصر سطح بالاي خود به صورت مستقيم ادغام شود. شناخت فركانس رخداد بسيار سخت تر است. خطاي ارث برده شده توسط يك نرم افزار فقط به خود ان مربوط نمي‌شودبلكه به محيط عاملي كه در ان نيز اجرا ميشود بستگي دارد. هيچ راه مشخصي جهت شناخت نرخ فركانس ان در يك زمان مشخص وجود ندارد زيرا خطاها هنوزبه صورت كامل و جامع شناخته نشده‌اند به همين خاطر تاكيد زيادي به استفاده از مجموعه مقادير McCabe يا مجموعه اندازه‌هاي Halstead براي تخمين رخداد خرابي نرم افزار شده است.
همچنين تخمين احتمال شناخت خطاها تا وقتي كه فقط جزئي از خطاهاي برنامه توسط روشهاي خودآزمايي مورد كنترل قرار مي گيرند بسيار سخت است.
منبع: وبلاگ مهندسی صنایع
FMEA / FMECA عمومي در استاندارد IEC60812 تعريف شده است. نسخة اصلي و كامل آن مربوط به سال 1985 ميشود 2 IECT561/WG البته بر روي نسخة ويرايش شدة آن كار مي‌كنند نسخة پيش نويس كميتة كاري (CD) بين اعضاي كميته در بهار 2001 پخش شد.
FMEA / FMECA عمومي در IEC 60812 با تمامي خط مشي‌هايي كه در قسمت قبل توضيح داده شد به خوبي سازگار است. اين استاندارد نقطة خوبي براي استاندارد نرم افزاري FMEA حساب ميشود. بسته به اهداف و سطوح مختلف اين استاندارد با تمامي نيازهاي ما به صورت كامل قابل تنظيم است. در اين قسمت تمامي موارد و ساختارهاي FMEA گنجانده نشده است در عوض قسمتي از ان كه با حلات خطاي سيستم‌هاي كاربردي اتوماسيون نرم افزاري مربوط است مطرح شده است .
براي بررسي FMEA براي سيستم‌هاي نرم افزاري اتوماسيون بايد هم قسمت سخت افزاري و هم نرم افزاري را كنترل نمود اما براي آنكه بيشتر به مطلب پرداخته شود فقط قسمت نرم افزاري آن مورد بررسي قرار مي‌گيرد.
براي نقطة شروع قدم‌هاي اصلي FMEA به صورت زير تعريف مي‌شوند.
1)تعريف محدودة سيستم براي تجزيه و تحليل
2)شناخت نيازهاي سيستم و نوع كار آن.
3)شروط خطا / موفقيت را تعريف كنيم.
4)سيستم را به عناصر ريزتر تقسيم كنيم
5)تعيين حالات خطاي هر عنصر و آثارشان و ثبت آنها
6)نتايج خطاها را خلاصه كنيد.
7)يافته‌ها را گزارش كنيد.
FMEA در برگه‌هاي ستون بندي شده نوشته ميشود. يك فرم استاندارد FMEA در پيوست ارائه شده است كه به راحتي مي‌تواند با نيازهاي يك فعاليت FMEA هماهنگ شود.
آناليز بحراني بودن يك خصوصيت كمي به FMEA كيفي است. با استفاده از آثار حالت خطاي يافته شده توسط FMEA، هر اثر خطا توسط ميزان خساراتي كه به شخص، وسايل و يا محيط وارد مي‌كند طبقه بندي ميشود. فركانس اينكه آن خطا اثرات خود را به همراه خرابي خود بر جاي بگذارد را بحراني بودن آن مي گويند. مجموعة شدت و تواتر انها به صورت تجزيه و تحليل نتايج انها در ماتريس درجة بحراني مشخص ميشود. در استاندارد SAEY 1739 سومين بعد نيز به بحراني بودن با معرفي مفهوم عدد اولويت ريسك اضافه مي شود كه نتيجه سه مفهوم است. شدت، رويداد و تشخيص.
درجة تحليل
FMEA يك روش BOTTOM-UP است كه در آن ليستي كه مورد تجزيه و تحليل قرار مي‌گيرد به عناصر جداگانه‌اي تقسيم ميشود. اين روش بايد به نمونه‌اي انجام شود كه حالت خطاي اجسام كاري كه در پايين قرار دارند به راحتي شناخته شوند. اثرات ناشي از خطاي لايه پايين به عنوان خطاي لايه بالا جايگزين ميشود.
عواملي كه باعث انتخاب لاية پاييني مناسب ميشود بستگي به هدف تجزيه و تحليل و دسترسي به اطلاعات طراحي دارد.
وقتي صحبت از FMEA در نرم افزارها ميشود اغلب منظور اين است كه بيابيم ايا خطايي در اجزاء سيستم وجود دارند كه بتواند كل سيستم را تحت تاثير خود قرار دهد؟
تحليل وقتي اغاز ميشود اجزاء برنامه به صورت متوالي وپشت سرهم در يك پردازش اجرا مي‌شوند و يا به صورت همزمان و در پردازش‌هاي موازي كنترل مي‌شوند.
در حال حاضر روش معمول براي بررسي امنيت و ايمني سيستم‌هاي اتوماسيون اجراي يك سري عمليات و روية خاص روي برنامه است براي مثال بروي قسمت منطق برنامه (Logic unit) يا قسمتهاي عمومي آن. نرم افزارهاي به اين صورت به دو گروه تقسيم مي‌شوند نرم افزارهاي سيستم (System softward) و برنامه‌هاي كاربردي (Application) نرم افزارهاي سيستمي خود به دو گروه هسته (kemel) و سرويسها تقسيم ميشود. (مترجم: سيستم عامل‌هايي مانند windows داراي يك هسته تكي و يك پارچه هستند ولي در سيستم‌هايي مانند Linux اين هسته از تعداد زياد برنامه‌هاي جدا از هم تشكيل شده است.) كرنل شامل مراحل راه‌اندازي، بارگذاري سيستم، تست عملكرد خود و غيره است. اما سرويسها شامل عملياتي مانند مديريت داده‌ها است. سكوي نرم افزاري شامل كتابخانه استانداردي از كامپوننت‌ها، بلاك‌هاي برنامه (ماژول‌ها) كه برنامه از طريق اتصال به تعداد مورد نيازي از اين بلاك‌ها شكل‌مي‌گيرد است كه در قسمت سرويسها قرار مي گيرد.
سيستم اتوماسيون همچنين شامل يك واسط گرافيكي نيز هست. توسط اين قسمت برنامه اطلاعات كدهاي مورد نظر خود را تبديل به تكه‌هاي كد كرده و سپس به صورت خودكار آنها را اجرا مي‌كند.
به صورت ضمني اين طور به نظر مي‌رسد كه در FMEA نرم افزاري براي شروع تحليل مي‌توان بلوك‌هاي برنامه يا همان رويه‌ها شروع كرد. در عمل اين مورد غير ممكن مي‌نمايد و كار را بسيار پيچيده و سنگين مي‌كند و ثانيا حالات خطاي رويه ها را غير قابل تشخيص مي‌كند.
عنوان شده است كه FMEA نرم افزار فقط در سطح برنامه قابل بررسي است. برنامه‌هاي نرم افزاري از واحدهايي به نام (Blocks of lnstrucion) B1 يا بلوك‌هاي دستورالعمل تشكيل شده است كه با خواص زير شناخته مي‌شوند.
1)يا به صورت مياني اندواز BI هاي كوچكتر تشكيل شده‌اند يا به صورت يك ترمينال جداگانه كه قابل شكسته شدن به BI هاي كوچكتر نيست.
2)آنها فقط يك نقطه خروج دارد. آنها نتايج خروجي را از روي ورودي ايجاد مي‌كنند. برخي از BI ها دسترسي مستقيم به متغيرهاي سخت افزار دارند.
3)آنها زمان اجراي ثابتي دارند.
4)آنهاها داده‌ها را با متغيرهاي حافظه مبادله مي‌كند. متغيرهاي حافظه كه توسط يك B1 ايجاد مي‌شوند توسط يك يا چند BI خوانده ميشود.
حالات خطا
وقتي كه يك راه مناسب جهت تجزيه سيستم مورد تحليل يافت شد قدم بعدي شناخت حالات خطاي حالات خطاي اجزاء است. براي سخت افزار بستگي به تجربه اپراتور و مقايسه با اجزاء مشابه. بسيار راه مستقيم و مشخصي دارد. سازندگان اجزاء سخت افزاري اغلب حالات خطا و فركانس ايجاد انها را ذكر مي‌كنند.
در مورد اجزاي نرم افزار اين اطلاعات وجود ندارند و حالت خطاي انها ناشناخته است (اگر شناخته شده بود قبلا درست مي‌شد) بنابراين شناخت حالات خطا سخت‌ترين قسمت كار SWFMEA است.
تحليلگران بايد دانش خود را دربارة نرم افزار و حالات خطاي مربوط به آن بكار گيرند.
در تحليل سه پروژه نرم افزاري بزرگ به موضوعات خطاي مهم زير بر مي‌خوريم:
1-محاسباتي
2-منطقي
3-ورودي خروجي داده
4-مديريت داده
5-واسط ها
6-تعريف نوع داده
7-پايگاه داده
8-غيره
براي حالات خطاي يك واحد پردازش داريم.
*سيستم عامل متوقف شد.
*برنامه با پيغام واضحي متوقف شد.
*برنامه اجرا شد ولي نتايج كاملا اشتباه تحويل داد.
*برنامه اجرا شد ولي نتايج غلط را علاوه بر نتايج درست تحويل داد.
به صورت خيلي اختصاصي تر براي شكل 6 حالات خطاي زير را عنوان كرده‌اند:
*اجراي BI با نقطة خروج (Exit Point) پايان نمي‌يابد.
*زمان اجراي BI در محدودة خاص نمي گنجد.
• BI فعاليت در نظر گرفته شده را انجام نمي‌دهد و يا فعاليتهاي در نظر گرفته نشده انجام مي‌دهد:
• خروجي مورد نظر را نمي‌دهد.
• متغيرهايي را تغيير مي‌دهد كه نبايد تغيير دهد.
• تعامل مورد نظر را با ورودي / خروجي انجام نمي‌دهد.
• با CPU آنطور كه بايد تعامل ندارد.
• كدهاي حافظه و يا ثابتها را تغيير مي‌دهد.
از نگاه ديگر مي‌توان حالات خطا را به دو گروه داده و پردازش داده تقسيم كرد. براي هر ورودي و خروجي اجزاء نرم افزار چهار حالت خطاي زير را در نظر مي‌گيرند:
*داده‌هاي از دست رفته
*داده‌هاي غلط
*داده‌ها در زمان نادرست رسيده‌اند.
*داده‌هاي زيادي (مترجم: اين مورد مانند Data overflow است كه براي نفوذ به سيستم‌هاي نرم افزاري بسيار زياد مورد استفاده نفوذگران قرار مي‌گيرد. به عنوان مثال براي نرم افزاري مانند win2k هنوز بعد از 5 سال وصله‌هايي براي بهبود آنها پياده سازي مي‌شوند)
از طرف ديگر براي هر رخداد (هر قدم پروسس) 4 حالت زير را در نظر گرفته اند:
*اختلال برنامه hang) كردن)
*رخدادهايي كه عمل نكرده‌اند اما برنامه به كار خود ادامه داده است.
*منطق ناصحيح
زمان بندي و ترتيب انجام.
همچنين كلاسهاي حالات خطاي ديگر نيز شامل:
• Stop نرم / سخت افزاري
• Crash نرم / سخت افزاري
• Hang نرم / سخت افزاري
• پاسخگويي كند.
• عدم اجراي برنامه
• پيام‌هاي غلط
• حجم داخلي از حد مجاز فراتر رفته باشد
• از دست دادن سرويس
• روشهاي شناخت خطا هم مانند موارد زير است:
• استفاده از برنامه مانيتور كردن task ها به اينصورت كه task هايي كه از دست رفته‌اند را شناسايي مي‌كند.
• برنامه مديريت پيام‌ها اعداد پشت سر هم را كنترل مي‌كند تا پيامهايي كه مرتب هستند را شناسايي كند.
• يك فراخوان كنندة متدها كه براي اطينان از حضور همة اعضا است.
• يك چك كنندة پيام‌ها براي شناخت پيامهايي كه دوبار فرستاده شده‌اند.
• مشكل اصلي اينجاست كه IEC60812 بيشتر بر روي حالات خطاي سيستم‌هاي مكانيكي بحث مي‌كند و كمتر به حالات خطاي نرم افزاري مي‌پردازد. FMEA همچنين شامل مشخصه‌هاي براي شناخت دلايل اصلي ايجاد خطا مي‌باشد بنابراين وقتي به جستجوي علل اصلي حالات خطا مي‌پردازيم طراحي پروسه بايد مورد بررسي قرار گيرد. IEC 60812 يك جدول از علل خطا ارائه كرده است كه به صورت گسترده براي SWFMEA مورد استفاده قرار مي‌گيرد.
اطلاعات مورد نياز
استاندارد IEC 60812 به صورت گسترده‌اي اطلاعات موردنياز جهت رويه‌هاي FMEA عمومي را ارائه كرده است. اين استاندارد تاكيد بسياري بر دسترسي آزاد به تمامي اطلاعات مربوطه و مورد احتياج و همچنين همكاري فعال طراح برنامه دارد.
قسمت اصلي اين اطلاعات شامل:
*ساختار سيستم
*فعال شدن، عملكرد، كنترل نگهداري برنامه
*محيط برنامه
*مدل سازي
*مجدوده سيستم
*توضيحات ساختاري برنامه
*ساختار برنامه.
*دياگرام‌هاي كلاس‌ها (مثل نمودارهاي UML)
*اهميت خطاها
يك سيستم نرم افزاري كه به خوبي مستند شده باشد اغلب اين موارد را درون مستندات خود دارد.
آناليز بحراني بودن
همانطور كه قبلا گفته شد، آناليز بحراني بودن يك توسعه كمّي بر روي FMEA كيفي است مبتي بر شدت اثرات ناشي از خطا، فركانس رخداد خطا و احتمال تشخيص آن. براي سيستم‌هاي اتوماسيون شدت اثرات خطا بر حسب اثري كه بر روي پروسة كنترل ميگذارند معين ميشود. حتي اگر سخت باشد،
شدت خطاي يك جزء تكي سطح پايين (low Level) مي‌تواند به صورت عقب گرد با عنصر سطح بالاي خود به صورت مستقيم ادغام شود. شناخت فركانس رخداد بسيار سخت تر است. خطاي ارث برده شده توسط يك نرم افزار فقط به خود ان مربوط نمي‌شودبلكه به محيط عاملي كه در ان نيز اجرا ميشود بستگي دارد. هيچ راه مشخصي جهت شناخت نرخ فركانس ان در يك زمان مشخص وجود ندارد زيرا خطاها هنوزبه صورت كامل و جامع شناخته نشده‌اند به همين خاطر تاكيد زيادي به استفاده از مجموعه مقادير McCabe يا مجموعه اندازه‌هاي Halstead براي تخمين رخداد خرابي نرم افزار شده است.
همچنين تخمين احتمال شناخت خطاها تا وقتي كه فقط جزئي از خطاهاي برنامه توسط روشهاي خودآزمايي مورد كنترل قرار مي گيرند بسيار سخت است.
منبع: وبلاگ مهندسی صنایع