مهندسی نرم افزار: مدیریت و تحلیل ریسک

صفحه 1:
9 ‎(eg‏ ‏اسلایدهای آموزشی درس مهندسی نرم افزار (۱) ( برگرفته از کتایپرسمن) مدرس : مهندس سهیل افراز دانشگاه پیام نورمرکز اردبیل 

صفحه 2:


صفحه 3:
تحلیل و مدیریت مخاطرات چیست؟ تحلیل ریسک (مخاطره) و مدیریت عبارت است از یک سری از اقدامات که یک تیم نرم افزاری کمک می کند تا عدم قطعيت را دریافته و آنرا مدیریت نمایند. مهدي شتتري 

صفحه 4:
مشکلات زیادی میتوانند برای یک پروژه نرم افزاری ایجاد اشکال .نمايند ريسك يكك مشكل بالقوه است ممكن است اتفاق بيفتد و ممكن است اتفال نيفتد اما صرفنظر از ييامد آن» بهتر است كه آن را شناسايى ۳ ۳ مهدي شتتري 

صفحه 5:
هر کسی که درگیر فرآیند نرم افزاری است در تحلیل و مدیریت .مخاطرات مشار کت دارد + مدیران 5 فهندسین مشتریان نرم افزار مهدي فستقري 

صفحه 6:
جه اقداماتی باید انجام داد؟ آ گاهی از اينکه چه اشالاتی ممکن است پیش آید. اولين گام : شناسایی ریسکک دومیمن گام : باید هر ریسکی تحلیل گردد تا احتمال وقوع آن و میزان خسارتی را که در صورت وقوع به بار می آورد تعیین شود. به محض اینکه این اطلاعات سبک شدند. خطرات بر اساس احتمال وقوع و تاثیر طبقه بندی می شوند. سومین گام : طرحی پیاده می شود تا خطراتی که احتمال وقوع آنها زیاد است وتاثیر آنها بیشتر است مدیریت نماید. 5 مهدي شتتري 

صفحه 7:
چگونه می توانیم اطمینان حاصل کنیم که این کار را درست انجام داده ایم؟ ریسک هایی که تجزیه و تحلیل و کنترل می شوند باید حاصل مطالعه کامل افراد محصول فرآیند و پروژه باشند.در حالیکه پروژه به ما اطمینان می دهد که خطرات بروز نگه داشته می شوند باید 08000001 تحت کنترل دوباره بگیرد.طرح های احتمالی برای کنترل و مدیریت ریسک باید واقعی مهدي شتتري 

صفحه 8:
یک تعریف عقلانی از ریسکك چیست؟ 0- ريسك به وقایع آینده ارتباط دارد. امروز و فردا در ورای مسائل فعال قرار دارند» زیرا ما در زمان حال آنچه را که در گذشته با اعمال خود کاشته ایم درو می کنیم. سئوالی که مطرح می شود این است كه يس آيا ما مى توانيم با تغيير اعمال امروزمان فرصتی برای موقعیت متفاوت و شايد بهتر در آينده ايجاد نماييم. ۲- ریسک مستلزم تغییر است. همچون تغیبر در ذهن» ایده ؛ اعمال و يا مكان ها .... ریسک مستلزم انتخاب و عدم قطعیتی است که انتخاب ایجاب می نماید. بنابیاین شگفت اینکه ریسک همچون مرگ و مالیات یکی از معدود امرهای مسلم زندگی است. مهدي شتتري 

صفحه 9:
سه تعریف زیر بناتی ضمنی چارته: برای ما آینده اهمیت دارد. تغییر برای ما اهمیت دارد. بايد با انتخاب ها دست و پنجه نرم کنیم. مهدي فستقري 

صفحه 10:
نظریه پیتر درا کر : همانگونه که تلاشبرای حذف خطر بی ثمر است. و تلاشبرای کاستن آن سوال برانگیز می باشد» ضروری است خطراتی را که برای آنها وقت صرف می کنیم خطرات بجایی باشند. قبل از اینکه خطرات بجایی را که در طی یک پروژه نرم افزاری به آنها خواهیم پرداخت شناسایی نماییم» حائز اهمیت است که کلیه خطراتی را که هم برای مدیران و هم برای کارورزان مشهود است شناشیی نماییم. مهدي شتتري 

صفحه 11:
راهبرد واکنش بر ریسک اکثریت تیم های نرم افزاری منحصراً بر روی راهبردهای ریسکک واکنش پذیر تکیه دارند. و مهمتر از همه اينکه یک راهبرد واکنش پذیر پروژه را برای خطرات احتمالی تحت کنترل دارد. منابعی برای مقابله با آنها در نظر گرفته می شود. تا زمانی که تبدیل به مشکل واقعی شدند از آنها استفاده شود. معمولا تیم نرم افزاری در مورد ريسكك كارى انجام نمى دهند تا اينكه مشكلى بيش بيايد. در اين حال تيم وارد عمل شده و سریعاً برای حل مشکل اقدام می نماید. این وضعیت غالباض «وضعیت پرواز آتشی؛ نامیده می شود. وقتی که اين کار با شکست مواجه می شود «مدیریت بحران» کنترل را بدست می گیرد که در این حال پروژه با خطر واقعی مواجه می گردد. مهدي فستقري 

صفحه 12:
راهبرد پیش کنش بر ريسك راهبرد پیش کنش خیلی از آنکه کار فنی آغاز گردد شروع می شود. خطرات بالقوه ناسایی شده. احتمال و تاثیر آنها مورد ارزیابی قرار گرفته و سپس بر اساس اهمیت طیقه بندی می شوند. سپس تیم نرم افزاری طرحی را برای کنترل ریسک ارائه می دهد. هدف اولیه عبارت است از جلوگیری از بروز ریسک (خطر) اما از آنجایی که تمام خطرات ناپذیز هستند. تیم یک طرح احتمالی ارائه می دهد تا بتواند به یک روش کنترل شده و موثر واکنش نشان دهد. 3 مهدي شتتري 

صفحه 13:
ريسك هاى نرم افزار 9 عدم قطعيت: رويدادى كه مشخص مى كند آيا ريسكى به وقوع خواهد بيوست يا خير: يعنى هيج ريسكى كه احتمال وقوع لن ۰ باشد وجود ندارد. خسارت : اگر ریسک یک واقعیت باشد. پیامد ها و پا خسارات ناخواسته ای بوقوع خواهد پیوست. 7 مهدي فستقري 

صفحه 14:
وقتی نرم افزاری ساخته می شود» احتمال مواجه شدن با چه خطراتی وجود دارد؟ * ریسک های پروژه طرح پروژه را تهدید می نمایند. " خطرات فنى» كيفيت و به موقع بودن نرم افزار تولیدی را تهدید می نماید. ۰ خطرات تجاری کآرایی نرم افزاری را که قرار است ساخته شود تهدید می ‎wale‏ ۴ منابع اطلاعاتی قابل اعتماد دیگر مخفی نمی مانند. مهدي شتتري 

صفحه 15:
:ریسکت پروژه اگر خطرات پروژه به واقعیت پپیوندند اين احتمال وجود دارد که برنامه پروژه با اشتباه مواجه شود و قیمتها افزایش یابند. ریسکک های پروژه: بودجه برنامه زمان بندی» پرسنل منابع» مشتری بالقوه و مشکلات مربوط به نیازمندی ها و تاثیر آنها را بروی پروژه نرم افزاری شناسایی می کنند. 3 مهدي فستقري 

صفحه 16:
وقتی که خطر فنی به واقعیت می پیوندد پیاده سازی دشوار و یا غیر ممکن مى گردد. خطرات فنی مشکلات بالقوه مربوط به طراحیی پیاده سازی؛ رابط » تعیین صحت و نگهداری را شناسایی می کنند. بعلاوه ابهام مربوط به ویژگی» عدم قطعیت فنی؛ زوال فنی و فناوری «پیشرو» از عوامل و فاکتور مربوط به ریسک هستند. خطرات فنی بدین جهت بوقوع می پیوندند که حل مشکل از آنچه که ما تصور می کنیم دشوارتر می باشد. مهدي شتتري 

صفحه 17:
خطرات تجاری ساخت یک محصول و یا سیستم بسیار عالی که هیچکس واقعاً طالب آن نیست. (ریسک بازار) ساخت محصول که دیگر مناسب راهبرد تجاری کلی برای شرکت. مزبور نمی باشد. (ریسک راهبردی ) ساخت محصولی که نیروهای فروش نمی دانند چگونه آن را بفروشند (ریسک فروش) مدیرت) از دست دادن بودجه و یا تعهد پرسنل (ریسک بودجه) مهدي شتتري 

صفحه 18:
شناسايى ريسك شناسایی ریسکت عبارت است ازيك تلاش نظام مند براى تعيين تهديدهليى كه متوجه طرح بروؤه هستند (برآوردهاء برنامه هاء تخصیص منابع و غيره ) مهدي فستقري 

صفحه 19:
انواع ریسکث ریسک های محصول ویژه : را تنها می توان توسط کسانی که درک روشنی از فناوری دارنده مردم و محیطی که مختص پروژه در دسترس است شناسایی نمود. ریسک عمومی : ریسک های عمومی تهدید بالقوه ای برای هر نوع پروژه نرم افزاری می باشند. مهدي شتتري 

صفحه 20:
برای شناسایی ریسک های محصول ویژه طرح پروژه و گزارش نرم افزاری از حوزه مورد بررسی قرار گرفته و پاسخی برای سوال زیر داده می شود . چه ویژگی های خاصی از این محصول می تواند طرح پروژه ما را به خطر اندازد؟ مهدي فستقري 

صفحه 21:
یک روش کاربردی برای شناسایی ریسکک ها عبارت است از تهیه یک جكك ليست حاوى موارد ريسكك از جكك ليست مى توان براى شناسايى ريسكك و نقطه عطف مربوط به مسائل فرعى شناخته شده و قابل بيش بينى ريسك استفاده كرد. مهدي فستقري 

صفحه 22:
اندازه محصول: ریسک هایی که مرتبط به اندازه ‎YS‏ نرم افزار شناخته شده و یا تغیبر hs 3 مهدي شتتري 

صفحه 23:
تاثیر تجارت : ریسک هایی که مربوط به محدودیت های ناشی از مدیریت و یا بازار تنجازین انستان مهدي شتتري 

صفحه 24:
شتری : ژگی های مشتر ویر 31 ط به پیچید گی ۳2 ای ای مربو ۱ ۱ 1 + 5 : ك روش : | مقترى م اب به يجاد ارتب 5 |= ‎“Cre‏ فتتري مهدي 

صفحه 25:
تدوین فرآیند: ریسک های مربوط به میزان تعریف فرآیند نرم افزار که توسط سازمان توسعه دهنده دنبال می شود. 2 مهدي فستقري 

صفحه 26:
محبط توسعه: ریسک های مربوط به در دسترس بودن و کیفیت ابزار هایی که برای ساخت محصول مورد استفاده قرار می گیرد. 2 مهدي فستقري 

صفحه 27:
فنآوری ساخت: و یسک های مربوط به پیچید گی سیستم ساخته شده و «تاز گی؛ فتآوری که توسط:سیستم ارائه مى شود. مهدي فستقري 

صفحه 28:
اندازه و تجربه کار کنان : ریسک های مربوط به تجربه پروژه فنی کلی مهندسین نرم افزاری که کار را انجام مى دهند. مهدي فستقري 

صفحه 29:
ارزیابی ریسکک کلی پروژه: ‎LT‏ مدیران نرم افزار و مشتری رسماًاقدام به حمایت از پروژه نموده اند؟ ‏آیا مصرف کنندگان نهایی در خصوص پروژه و سیستم / محصول ساختهشده اظهار نظر کرده اند؟ ‏آیا تیم مهندسی نرم افزار و مشتریان آنها نیازمندیها را کاملاً درک می نمایند؟ ‏ايا مشتريان كاملاً در گیر تعریف نیازمندیها هستند؟ ‏آیا مصرف کنند گان نهایی انتظارات واقعی دارند؟ ‏آیا حوزه پروژه ثابت است ؟ ‏مهدي شتتري ‎ ‎ 

صفحه 30:
آیا حوزه پروژه ثابت است ؟ آیا مهندسی نرم افزار تر کیب درستی از مهارت ها دارند؟ آیا نیازمندیها پروژه ثابت است؟ 1 1 يا تیم پروژه تجربه ای در خصوص فنآوری در حال انجام دارند ؟ ‎UT‏ تعداد افراد تیم پروژه برای انجام کار کافی هستند؟ آیا کلیه مشتریان / مصرف کنند گان در خصوص اهمیت پروژه و در خصوص شرایط سیستم/ محصول ساخته شده با هم توافق دارند؟ مهدي شتتري 

صفحه 31:
اجزاء و مح ركك های سیستم: ريسك عملكرد : مديران عدم قطعى كه به كمكك آن نيازمنديهاى يروزه برآورده مى شود و مناسب مصرف مورد نظر مى باشد. زینه : میزان عدم قطعیتی که به کمک آن بودجه پروژه تامین می گردد. ان: میزان عدم قطعیتی که اصلاح» تطابق و تقویت نرم افزار حاصل آسان می شود. ریسک برنامه : میزان عدم قطعیتی که زمانبندی پروژه رعایت شود و محصول بموقع ارائه می گردد. مهدي فستقري 

صفحه 32:
ارزیایی تاثیرات ‎BOESY]‏ "are vol a operational days shdvriereaed cont ith expected ale of Sto S00 Somesboringat | Potie 0 تسم ‎LOC‏ | مومس كديب ملاعم مام رط ا | ۳۹ ‘Slice ‏تست‎ ‎‘atl 0 مه سس مهدي فستقري پشتیبالی عملکرد Fair to weet he Fequrement sul reat inion fare ‎Roars‏ | سود ‎degradation | Cor‏ ‏اه دیون ‎Te‏ ‏ل | شمه که ‎performance ‎Fare to 0610 ‏ل‎ degrade ‎Srtemperormance to point ‘here miion een ‎۳ ‎7 ‎ ‎0 ‏لم | مس‎ ۳ Fae fomeet herequimeat, woud esl degradation Jecondary mision ‏اس‎ ‎support ‎ ‎allure to met The ruins vould creat inconveniene oF ‎pact ‎enoperatona ‎No reduction | Easily ‏ام‎ | supportable performance | software ‎ ‎ ‏مؤلقيها ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 33:
برآورد ريسك : برآورد ريسكك » كه تخمين ريسكك نيز ناميده مى شود. به دو روش ارزيابى میشود. * _ احتمال و یا امکان اینکه ریسک و مخاطره واقعیت یابد. + مخاطرات روی دهند و پیامدها و مشکلاتی که در صورت روی دادن ‎OT‏ ‏مخاطده که پروز می ‎AS‏ 3 مهدي هنتري 

صفحه 34:
فعالیت های بر آورد ریسکت: ایجاد مقیاسی که منعکس کننده احتمال مشاهده شده یک ریسکک است. مشخص کردن پیامد های ریسک . برآورد تاثیر ریسکک بر روی پروژه و محصول توجه به صحت و دقت کلی برآورد ریسک بطوری که هیچ دركك نادرستی وجود نداشته باشد. مهدي فستقري 

صفحه 35:
ساخت و توسعه یک جدول ريسكك: یک تیم پروژه با فهرست بندی تمام ریسک ها (صرفنظر از فاصله زمانی وقوع آن) در اولین ستون جدول آغاز می گردد. 1 هر ريسكك در ستون دوم طبقه بندی شده است. احتمال وقوع هر ریسکك در ستون بعدی جدول آمده است.میزان احتمال هر ریسکک را اعضای تیم می توانند تخمین بزنند. میانگین مقوله های هر چهار جزء ریسک - عملکرد پشتیبانی » هزینه و برنامه زمانی - برای تعیین ارزش کلی تاثیر برآورده می گردد. مهدي فستقري 

صفحه 36:
مثالی از مخاطرات پیش از مرتب سازی ۱ مبن.ت مدیریت - نظارت - تخفیف (6000) ‎jCUzezks‏ ینت3 08 تجارى لا8 كار كنان . محيط توسعه ‏مقادير تاثير : ۱- فاجعه ۲- مرزی ۳- بحرانی 6- قابل اغماض ‏منت رسک ‎ ‏مهدي فستقري ‎ ‏تلیر ‎ ‎٩ ۴‏ 5 5 5 5 5 5 ۶ 8 ۶ و ‎ ‎ ‏مخاطرات (ربسكها. ی ‎low‏ ‎Lager umber of ss tan plamed ‘ese rese than pled; ‎End urs resis stem ‎Delivery deslin willbe tend Fndng willbe est 3 (Coomer wil change eqirerets Techology wil ot meet ‏سسوم ‎Lackof wining ols‏ ‎Stained‏ ‏ی ‎willbe igh‏ مس کم ‎ ‎ ‎ ‎ ‎ 

صفحه 37:
مدیر پروژه جدول مرتب شده حاصل را مورد بررسی قرار داده و یک خط فرضی (برشی) تعریف مى كند «خط فرضى؛ بيانكر اين است كه فقط به ريسك هایی که در بالاى خط قرار كرفته اند توجه بيشترى مى شود. ريسك هايى كه در يايين خط قرار مى كيرند مجدداً مورد بررسى قرار مى كيرند تا اولويت بندى مرحله دوم انجام يذيرد. شکل ۲۶ ریسک وامورمدیریتی مهدي فستقري 

صفحه 38:
تمام ریسکک هایی که در بالای خط فرضی قرار می گیرند باید کنترل گردند. ستونی که تحت عنوان م.نست ریسک نام گرفته دارای نشانگری است به طرف تخفیف و تعدیل » کنترل و نظارت و مدیریت ریسک و یا بعبارت دیگر مجموعه ای از چند صفحه اطلاعات در خصوص ریسک که برای کلیه ریسک های که در بالای خط فرضی قرار گرفته اند در نظر گرفته شده اند . شکل ۲۶ ریسک ولمور مديريتي 2 مهدي شتتري 

صفحه 39:
* احتمال ریاضی که با هر یک از اين مقادیر کیفی قابل پیوند خواهد بود . مهدي فستقري 

صفحه 40:
ارزیابی میزان اثر: ماهیت : ماهیت ریسک بیانگر مشکلاتی است که در صورت وقوع ری از خواهند نمود. حوزه : سختی آن را با پراکندگی و توزیع کلی ‎OT‏ تلفیق می نماید. زمان: بیانگر این است که چه وقت و برای چه مدتی تاثیر آن محسوس خواهد بود. مهدي فستقري 

صفحه 41:
در بیشتر موارد یک مدیر پروژه خواهان این است که «خبر های ناخوشایند » هرچه زودتر برسد . اما در برخی مواقع ترجیح می دهند که این خبرها دبرتر برسند. مهدي شتتري 

صفحه 42:
در معرض ریسک قرار گرفتن كلى را 0802 ناميده مى شود و مى توان با استفاده از رابطه زير تعيين كرد. RE= P*C a بيائكر هزينه وارده به بروزه در صورت وقوع ريسك بيائكر احتمال وقوع يك ريسك 9 مهدي فستقري 

صفحه 43:
ارزیایی ریسک: در ان نقطه از فررآیند مدیریت ریسک ‏ ما یک مجموعه سه تایی به شکل زیر ایجاد نموده ایم . #«ث۳] مهدي شتتري 

صفحه 44:
سطوح ارجاعی: برای اینکه ارزیابی سودمند واقع شود باید یک سطح ارجاعی برای ریسک تعریف نمود . در مورد بیشتر پروژه های نرم افزاری» اجزاء ریسک » (یعنی عملکرده هزينه؛ پشتیبانی و زمان بندی)نیز بیانگر سطوح ارجاعی ریسک می باشند . یعنی برای تضییع عملکرد بالا رفتن هزینه» اشکال در پشتیبانی و یا کم و کاستی در برنامه سطحی وجو دارد. .0 مهدي فستقري 

صفحه 45:
سطوح ارجاعی که سیب توقف پروژه می گردد اگر ترکیبی ازریسکها سیب ایجاد مشکلاتی شوند که منجر به ار حد گذشتن این سطوح ارجاعی گردد. کار متوقف خواهد شد. ارجاعی ریسکک دارای نقطه منفردی است که نقطه اجاعی و با نقطه شکست امیده می شود. که در ان نقطه تصمیم گیری برای ادامه پروژه و یا ختم آن (مشکلاتی که خیل بزرگگ هستند) اهمیت یکسانی دارد. ‎ry‏ تجاوز از زمان بندی پروژه تجاوز از هزینه پروژه شکل ۴۶ سطح معرق ریسک مهدي فستقري 

صفحه 46:
زمان ازریابی ریسک : سطوح ارجاعی ریسکک را برای پروژه تعیین نمایید. سعى كنيد بين هر (4,,<4» و هر يكك از سطوح ارجاعى يكك رابطه ایجاد کنید. مجموعه از نقاط ارجاعى را بيش بينى كنيد و تعيين كننده يكك ناحيه يايان است و بوسيله يكك منحنى و يا نواحى عدم قطعيت محدود مى شود. سعى كنيد بيش بينى نمائيد تركيب هاى اجزاء ريسكك ها جكونه سطح ارجاعى را تحت تاثير قرار خواهند داد. مهدي فستقري 

صفحه 47:
‎ob‏ ریسکك: پاتقزایط ‎Sag Vt) © Ethie fad IT SE By‏ ‏وضعیت فرعی ۱: اجزاء ویه قابل استفاده مجدد توسط شخص ثالثی که آگاهی از استاندارد های طراحی ندارد ساخته شده اند. ‏وضعیت فرعی ۲:طرح استاندارد برای سطوح مشترک اجزاء هنوز به حالت یکپارچه در نیامده است و ممکن است با اجزاء خاص قابل استفاده مجدد موجود سا زگاری پیدا نکند. ‏وضعیت فرعی ۳: اجزاء خاص قابل استفاده در زمانی بکار گرفته شده است که در محیط هدف مورد پشتیبانی قرار نگرفته است. ‏مهدي فستقري ‎ ‎ 

صفحه 48:
تخفیف. نظارت و مدیریت ریسکت: یک راهبرد موثر و کارا باید سه مسثله را در نظر بگیرد. * اجتناب از ريسكك * كنترل:ريسكق مديريت ريسكك برنامه ريزى احتياطى 3 چه تیم نرم افزاری یک روش پیش کنش برای رسک انتخاب کند؛ بهترین راهبرد خواهد بود. این کار از طریق اائه طرح برای تعدیل و تخفیف ریسک امکان پذیر است. 4۸ مهدي فستقري 

صفحه 49:
مخاطرات و ریسک های ایمنی ريسك تنها به بروزه نرم افزارى محدود نمى شود. ریسک ها ممکن است يس از اينكه بروزه با موفقيت انجام شده و تحویل مشتری گردید بروز کنند. اين ريسكك ها غالباً مربوط به پیامدهای عدم موفقعیت نرم افزار در میدان مورد نظر است. 6 مهدي فستقري 

صفحه 50:
خطها[اصل حول کوچکا ]اد رال ن رال شباه )لبط راب روز امیلل ‎HO‏ ‎O00‏ ‏خطاهایی که در کنترل قراردادی سخت افزار مي توان نادیده گرفت و بر آنها سرپوش گذاشت بهنگام استفاده از نرم افزار نادیده گرفتن آنها بسیار دشوارتر خواهد بود. ایمنی نرم افزار و تحلیل خطر : عبارتند از فعالیت های مربوط بهطمینان از کیفیت نرم افزار که په شناسایی و ارزیابی خطرات بالقوه ای می پردازد که می تواند نرم افزار را بطور منفى تحت تاثير قرار داده و سیب بروز نقص در یکک سیستم کامل گرد اگر بتوان خطرات را در ابتدای ف رآیند مهندسی نر افزار شناسایی نموده ویژگی های طراحي نرم افزار را می توان بگونهای تعیین نمود سبب حذف با کنترل خطرات بالقوه گردد. مهدي شتتري 

صفحه 51:
RMMM ‏طرح‎ یک راهبرد مدیریت ريسك را می توان در طرح پروژه نرم افزاری گنجاند و يا مراحل مدیریت ریسک را می توان بصورت یک طرح تعدیل » کنترل و یا مدیریت سازماندهی نمود. طرح ‎ROOD‏ }3 مام كارهايى كه به عنوان بخشى از تحليل ريسك انجاممى یداو توسط مدیر پروژه بعنوان بخشی از طرح پروژه کلی بکار می رود گزارش مستند يمي ‎lala‏ مهدي شتتري 

صفحه 52:
قالب 35 در شکل زير نمایش داده شده است. a a ‏كدر مق‎ | 5301 ل ۳ ‎vn nf, beteptelino te pte Te ang‏ rl eee ten ‘Reformat este: Sibcnison 1 Cin ruble capone developed by hid ay who kong feral sin ‘Sitenbie 2 The esi snd fect nics nt bese aad shot con tai ing tle سس سما ‎Sibceion 3: Cana reuters‏ ‎mplinedin x Inguge tt stot pce est‏ ‎‘Migs aon:‏ 1. Cone ted par oder ere ib sigh ore 2.Pres fine sada epi ‏مومه سام‎ scars desing on ie pel 3 Check denine congestion sepa ick ‏لسع سید نا‎ ‘Managinentcentipocy pan Wig RE compu tobe 20200 Ae i anc wii poet esting cot. Deve essed el eight 8 ‘sion hase tbe eso a eae talc ‏سل وه موه اقا روز‎ of TH شكل 8-7 نمونه ى لرصقحه اطلاعات ديسك (805) [9:157]. مهدي فستقري 

صفحه 53: