توسعه نرم‌افزار: تفاوت میان نسخه‌ها

محتوای حذف‌شده محتوای افزوده‌شده
پوویا (بحث | مشارکت‌ها)
جزبدون خلاصۀ ویرایش
Leila65 (بحث | مشارکت‌ها)
خط ۵:
==جستارهای وابسته==
*[[کیت توسعه نرم‌افزار]]
دانشگاه آزاد اسلامي واحد گرمسار
نام استاد:آقاي نيكجو
 
 
 
رویکرد مدیریتی کیفیت نرم افزار
 
معصومه یحیی ، سمانه نورآذر ، زينب مشهدی مسلم ، سمیرا وجدان پرست ، لیلا جان بخش
GMAIL:(1)
(2) sa.noorazar@gmail.com
sara.moslemi@yahoo.com (3)
(4) venusb5@yahoo.com
(5) Leila.janbakhsh@gmail.com
 
 
 
چکیده
این مقاله اختصاص به رویکرد مهندسی برای مدیریت کیفیت نرم افزار دارد. این رویکرد به سمت دستیابی به رشد سیستم های نرم افزاری رهبری می شود .اين مقاله شامل موارد زير است:
ویژگی های بارز مدل های اتمام DPS (فرآیند پردازش اطلاعات)- مشکلات دیدگاه جدید مدیریت کیفیت- مدل مورد نیاز در تمامیت(به کمال رسیدن) اجزاء سازنده یک سیستم نرم افزار- عناصر اساسی یک سیستم پیش بینی برای کنترل میزان کیفیت.
در اين ميان پيش بيني نقص با استفاده از مدلهاي گرافيكي به خاطر مزاياي آن در بهبود كيفيت نرم افزار مورد توجه بيشتري قرار گرفته اما اين مبحث در حال رشد است.
امید است در آینده نزدیک شاهد پیشرفت در این زمینه باشیم ما در این مقاله قصد داریم به بررسی چگونگی مديريت كيفيت بپردازیم.
 
واژه های کلیدی: کیفیت سیستم های برنامه- پیش بینی نقص و عیب- شبکه با یسن
 
1- مقدمه
در شرایطی که با رشد سریع صنعت نرم افزاری روبه رو هستیم و رقابت فزاینده ای در بین موسسات سیستم های نرم افزاری وجود دارد، مدیر های پروژه ها نمی توانند تنها به آزمایش و ارزیابی ویژگی های کیفیت نرم افزار ها در پایان پروژه تکیه کنند.
بنابراین ارزیابی کیفیت شاخص های کیفی در خلال همه مراحل از ابتدای مراحل چرخه سیستم های نرم افزاری مهم است که از اضافه کردن فرآیند جدیدی بنام مدیریت کیفیت به همراه مراحل تایید و آزمایش قوانین و همچنین کیفیت مورد تایید قرار می گیرد.[1] آخرین نسخه از استاندارد های بین المللی ISO\IEC12207:2002 در فرآیند های چرخه نرم افزاری کسب شود. برای اجرای چنین مراحلی مدلها و روش های مهندسی کیفیت ضروری است تا از اتخاذ تصمیم در مورد مدیریت کیفیت در همه مراحل سیستم های نرم افزاری پشتیبانی شود.
تعدادی از روش ها برای مدیریت کیفیت سیستم های نرم افزاری شکل می گیرد و یکی از آنها یک روش شناخته شده و ویژه لیپاو است. [2] در این روش برای دستیابی به سیستم های نرم افزاری پیشرفته به همراه تشکیل کیفیت سیستم کنترل بر اساس مجموعه مدلهای مدیریت [3] مراحل طراحی سیستم نرم افزاری پیشرفته در همه مراحل Lc است.
همچنین نشانه های کاربردی موجود سیستم نرم افزاری پیشرفته در خلال مراحل Lc وجود دارد و استفاده از آنها در ارزیابی نهایی از درجه دستیابی بر نشانه های کیفیت در ملزومات سیستم های نرم افزاری پیشرفته تعیین می شود. [4]
روش های کلی در مدیریت کیفیت سیستم های نرم افزاری پیشرفته با استفاده ازساختارCSS در نظر گرفته می شود و مجموعه ویژگی های لازم از مدل کیفیت و روش ها و شیوه های نوین مورد استفاده در مراحل LC مورد استفاده قرار می گیرد تا کیفیت بالای css فراهم شود.
کلیت این روش در یکسان سازی مراحل ارزیابی و کنترل کیفیت و هماهنگی اقدامات کنترل کیفیت است که تهدیدی برای کیفیت محسوب می شود. مشکلات سرویس مدیریت کیفیت مثال طراحی و پیگیری مراحل حصول کیفیت در مراحل LC و آزمایشات کیفیت و آزمایش نسخه آزمایشی CSS و ارزیابی نمونه های کیفیت پایه این نسخه بر اساس مجموع اطلاعات فنی است.
در این مقاله طبقه ویژه ss سیستم های پردازش اطلاعایه نام دارد و رویکرد مدیریت کیفیت آن به سمت اتمام سیستم پیش می رود که ویژگی های کیفیت در اجرای همه اجزای برنامه DPS را تعیین می کند. اختلاف اساسی شیوه جدید تغییر اهمیت کیفیت نگهداری از SS به فرآیند های LC است بروز این نقص را در SS تصدیق می کند .
ویژگی بارز این شیوه در استفاده از تئوری پیش بینی در مهندسی برنامه نه تنها برای تعیین امکان نگهداری سطح ویژه اتمام SS با کمک فرآیند های LC است بلکه برای تعیین محل فرآیندهای LC است.
در فرآیند اتمام SS جنبه های نگهداری کیفیت مراحل LC مورد تحقیق قرار می گیرد. و روابط بین استانداردهای درونی و برونی کیفیت در مدلها بررسی می شود. و روش های پیش بینی مدیر که تهدیدی برای کیفیت هستند شناسایی می شود.
 
2- ویژگی های بارز مدل های اتمام DPS (فرآیند پردازش اطلاعات)
با تعریف استاندارد DSTU کیفیت از مجموعه ویژگی های سیستم نرم افزاری تشکیل شده است که توانایی براوردن نیاز های ویژه و مورد انتظار را بر اساس هدف آن را دارا باشد.[5]
ویژگی های معمول به همراه کیفیت آن لحاظ می شود یعنی شکل کیفیت آن بستگی به ویژگی های بارز موضوع و اهداف SS و طبقه بندی ها کاربر آن و همچنین به هدف نهایی کیفیت از دیدگاه طراحان دارد. در این مقاله ما ویژگی های کیفیت مدل های سیستم های نرم افزاری پردازش اطلاعات را مورد بررسی قرار می دهیم که از چندین برنامه کاربردی تشکیل شده است که در یک چهار چوب گسترش می یابد که به ایمنی عملکرد آن مربوط نمی باشد.[6,7]
ویژگی های مهم کیفیت App تمامیت آن است . به عبارت دیگر ویژگی اجتناب از عیب در وقتی عیوب نهان در سیستم وجود دارد. این تمامیت مدیریت کیفیت نام دارد . هدف مدل ها بهینه کردن کنترل پروژه برای معیارهای کیفیت است که برای مدیر پروژه ضروری است.
برای مدیریت کیفیت کارآمد بر اساس یک ویژگی ویژه یا مجموعه ای از ویژگی ها یک مدل از کیفیت تهیه می شود که رابطه بین معیار و معیارهای درونی و بیرونی را اندازه گیری می کند.
اولین مراحل تهیه SS و میزان معیار بیرونی میزان رسیدن به تراز کیفیت در خلال آزمایش SS و سپس تعیین معیار درونی مناسب است و اجرای مرحله به مرحله ملزومات برونی برای کیفیت طراحی می شود. واضح است که ملزومات برونی کیفیت SS از نقطه نظر چنین محصولات نرم افزاری تهیه می شود.[8]
در تمامیت SS شاخص کیفیت درونی با عیب آن معلوم می شود شاخص بیرونی نقایص آن و شاخص عملکرد آن با نقص کلی از عملکرد سیتم سنجیده می شود. مدل سه مرحله ای کیفیت رابطه بین معیار درونی و بیرونی و کیفیت عملکرد را پیشنهاد می دهد.
 
شکل (1)
 
D0 تعداد عیب در هر قسمت SS R(t) عملکرد بدون عیب هر قسمت SS در زمان داده شده oSS میزان کیفیت عملی SS است که معرف رضایت کلی کاربران بوسیله عملکرد بدون نقص SS و ویژگی های کیفیت SS است. این شکل ساختار دو سطحی ویژگی های کیفیتی و ویژگی های فرعی در مدلهای کیفیت در طرف چپ و فهرست ویژگی ها عملی SS و به همراه تاثیر مفرط سیستم بر کاربر است در طرف راست را ارائه می دهد.
 
شکل (2)
 
وسط شکل، مدل سه مرحله ای کیفیت برای ریز مشخصه ها، برای مثال تمامیت بدست آمده می باشد. به این معنا که مدل کیفیت بسیار موثر و کار آمد است. استحکام متریک (اندازه گیری بر حسب متر) کیفیت در سه مرحله و نزدیک شدن به مدیریت کیفیت که بر اساس این معیار های متریک توسعه پیدا کرده است.
 
3- مشکلات دیدگاه جدید مدیریت کیفیت
فرآیند تصمیم گیری در مدیریت کیفیت شامل راه حلی در راستای مجموعه ای از مشکلات می باشد.
1- تعریف میزان مشخصه های کیفیت انتخاب شده، میزان مطلوب از کیفیت یک SS که به عنوان مقیاسی برای تطابق SS با احتیاجات مصرف کننده بکار برده شده است.
2- پیش بینی قابلیت حصول یک میزان ثابت کیفیت در جریان روند فرآیند ها و محصولات توسعه یافته در پروژه نرم افزار در نظر گرفته می شود.تحقیق و بررسی تصمیمات متوالی محتمل برای دستیابی به میزان مطلوب به شرط رفع تنگنا ها در فرآیند های LCC امکان پذیر است. اگر رسیدن به یک میزان از کیفیت دست نیافتنی باشد باید در تطابق SS با احتیاجات مشتری تجدید نظر شود.( بخش 1را ملاحظه فرمایید.)
3- انتخاب یک تصمیم که از نظر قابلیت حصول میزان ثابت کیفیت بهترین است و احتمال کاربرد آن در چهارچوب پروژه با در نظر گرفتن منابع کمیاب تخمین زده می شود.اگر ضرورت داشته باشد میزان مورد نظر باید تجدید نظر گردد.(بخش 1را ملاحظه فرمایید.)
4- تعریف استراتژی ها،روش ها، و دستیابی به کیفیت اجزاء سازنده SS و همچنین بررسی صحت و درستی محصولات تولید شده SS که برای نیاز های ثابت کیفیت و منابع محدود مناسب هستند. سازماندهی گرد آوری اطلاعات بر روند اجرای پروژه، مراحل عملیات ، منابع و محصولات توسعه یافته SS با یک دیدگاه از تجربه های جمع آوری شده انجام می گردد.
5- بررسی تجربه های گرد آوری شده ، بازبینی درک اهمیت بعضی عوامل موفق از میزان ثابت کیفیت و یا اصلاح در روند اجرای پروژه می باشد. امور مهم قسمت 1و یا قسمت 2 در صورت ضرورت مکررا" اجرا شود.
این دیدگاه مدیریت کیفیت راه حل مشکلات نامبرده را تنظیم می کند و می تواند بطور خلاصه ترکیب یک مدل فرضی در تصمیم گیری برمدیریت کیفیت مبتنی بر اساس مشخصه های انتخاب شده را نشان می دهد. (شکل 2)
این مدل فرضی شامل مدل های توصیف شده ای در بخش های بعدی و روش های توسعه یافته در چهار چوب نائل شدن به مدیریت کیفیت می شود.
 
4-مدل مورد نیاز در تمامیت(به کمال رسیدن) اجزاء سازنده یک سیستم نرم افزار
منوط بر درجه یک سیستم کثرت استفاده از قطعات بتنی بوسیله مصرف کنندگان در طبقات مختلف در کارهای بازرگانی ،پیامد های خرابی بعضی از App همچنین دیگر عوامل (هزینه توسعه، خسارت خرابی ها و غیره ) نیازمندی به تمامیت قطعات مجزای SS می تواند تغییر کند.[9]
برای اطلاعات پردازشی سیستم نرم افزار ، یک طرح از نیاز ها برای به کمال رسیدن اجزاء سازنده SS پیشنهاد شده است که بر پایه در نظر گرفتن دیدگاه های مختلف آنها و ضرورت بیشترین حد رضایت عمومی مشتری شکل یافته است که بوسیله تحویل محصولات پرداختی نرم افزار در بدست آوری و تثبیت میزان موردنظر از به کمال رسیدن اجزاء سازنده SS در تناسب با احتیاجات مصرف کننده مشخص می گردد.
اندازه گیری کیفیت عملیات یک SS (در مرحله بالایی از کیفیت مدل)بوسیله یک عمل سودمند از = Qss مشخص شده است ، که ai میزان اهمیت ساختار ith برای عملیات های تجاری است و Ri قابلیت اطمینان (عملیات بدون نقص) پشتیبانی از میزان فعالیت بدست آمده و مدت بدست آوردن t را در سیستم نشان می دهد.
اجرای بدون خرابی در ساختار یک SS می تواند تنها در طول آزمایش و بهره برداری از SS تخمین زده شود. که هر کدام بسیار دیرینه تر از دیدگاه مدیریت کیفیت می باشند. بنابراین مشکل پیدا کردن و رسیدن به یک میزان مطلوب از اطمینان در میان 4 مرحله سلسله وار SS به شرح زیر توزیع شده است:
طرح های برنامه00000 برنامه های کاربردی0000 فعالیت های ss00000ss
 
این سلسله تعیین پارامترهای طرحی از احتیاجات را با در نظر گرفتن اهمیت عملیاتی بی نقص در هر یک از اجزاء سازنده SS در این فعالیت سلسله مراتبی فراهم می کند.این یک فرض است که اهمیت ساختار های بتنی در عموم فعالیت های بازرگانی یک تشکیلات بوسیله مصرف کنندگان ss تخمین زده می شود. و اینکه اهمیت برنامه های کاربردی برای اجرای ساختار های SS (و همچنین تخمین اهمیت اجرای طرح برای همه App) بوسیله توسعه گران SS تخمین زده می شود.
اهمیت طرح ها در زمینه احتمال ریسک خرابی طرح در عملکرد سیستم تخمین زده می شود. یک مشکل در تعیین یک میزان مطلوب از به کمال رسیدن هر یک از اجزاء سازنده سیستم وجود دارد که بیشترین سودمندی فعالیت Qss را با در نظر گرفتن منابع محدود و تکنیکی در پروژه SS را فراهم می کند.
ما فرض می کنیم کهui ضریب وابسته وزن در فعالیت Fi برای دستیابی کیفیت قابل استفاده Qss است و 1=I000 ،k، Vij ضریب وابسته وزن Appکه اجرای ساختارith را فراهم می کند. 1=u00000، kو 1= j،00000l می باشد.
Wjs ضریب وابسته وزن بعضی از طرح ها می باشد که هجرای برنامه کاربردی jth را فراهم می کند.
Rs یک عملیات بدون نقص از طرح Ms که در طول یک دوره از عملیات t می باشد.
Ej مجموعه ی تعدادی از همه طرح ها است که برای اجرای jth یک Ms ضروری می باشد.
As کران پایین از یک عملیات بی نقص(شکست ناپذیر) از طرح Ms است.
Bsکران بالای یک عملیات بی نقص (شکست ناپذیر) از طرح Ms است.
G قیمت مخارج کلی یک SS است.
Cهزینه اولیه ساختن یک SSاست که بوسیله یک مرکز توسعه مشخص می گردد.
Cs مخارج کلی متصل با توسعه یک طرح Ms را نشان می دهد.
Dsهزینه های ضروری برای دستیابی به یک عملیات شکست ناپذیر از طرح Ms را نشان می دهد. ( با اکتساب و یا بدون در نظر گرفتن هزینه ها برای آزمایش و همچنین تخفیف غیر مستقیم برای بهبود زمان )
سهم بسزایی در قیمت SS دارد .
میزان مورد نظر یک عملیات بدون نقص در مدل r1…..rm برای هر یک از ساختار های ضروری Qssآمده به شرح زیر است:
 
 
(1) max..........( . ( Qss(r1…..rm) =
 
 
(2) 0<as≤rs≤Bs≤1, s=1,…….,m
 
 
(3) G. .cs+ ds . rs ≤ (1-∂)
 
(4) ≤ C
مشکل بهینه سازی خطی با بند های (4) و (2) تقریبا" به کمک بسته های ریاضی MATLAB حل شده است. پارامتر های ui, vij , wjs (u=1,….., k;j=1,…,l; s=1,……m) بوسیله روش بررسی سلسله مراتبی (MAH) یافت می شوند که بوسیله مقایسه زوجی و تعیین متوالی و ارجحیت مکانی اجزاء سازنده SS در چهار چوب هر یک مراحل سلسله وار با احترام به اجزاء مراحل قبلی تعیین می گردند. بند های (2) خصوصا" پایین ترین as قابل قبول و بالا ترین Bs کران های عملیات شکست ناپذیر در طرح هایی بر پایه تخمین اهمیت هر یک ازآنها بنا گذاشته شده است.بند های (3) رابطه متقابلی مابین هزینه های کلی برای توسعه یک طرح برقرار می کنند. از یک سو بخشی از قیمت یک سیستم G از این طرح که با در نظر گرفتن توزیع قابلیت اطمینان در کارکرد سیستم و از سوی دیگر سهم بسزاء ∂ در توسعه محاسبه می گردد. یک رابطه خطی ما بین هزینه طرح و میزان کارکرد بدون نقص قابل قبول است. بند (4)رابطه متقابلی مابین هزینه های کلی برای توسعه همه طرح ها و هزینه های اولیه ساختن یک SS را برقرار می کند. هزینه هایی برای توسعه یک طرح شامل مخارج کلی (غیر مستقیم) و هزینه های مستقیم این توسعه می گردد. بنابراین با کمک این طرح ، نیاز ها به تمامیت هر یک از برنامه های کاربردی احراز شده است. میزان مطلوب به کمال رسیدن مشخص شده است که دستیابی هر کدام در طول اجرای پروژه برای همه App ها باید کنترل شده باشد.
 
5- عناصر اساسی یک سیستم پیشبینی برای کنترل میزان کیفیت
کنترل قابلیت حصول در میزان مطلوب تمامیت qi برای هر یک از App ها برقرار شده است که بر اساس ترکیب ترکیب پیش بینی ها بر دو نوع پایه ریزی شده است : یک پیش بینی اکتشافی که مقصودش تعیین احتمالات در دستیابی به مباحث فورمول بندی شده تحت شرایط اجرای پروژه، و دیگری یک پیش بینی اصولی است برای تعریف تحت شرایطی که مباحث فورمول بندی شده را بتواند بدست آورد.برای تحقق هر یک از پیش بینی ها روش ها و طرح هایی که بخش های سازنده سیستم پیش بینی هستند توسعه می یابند برای مثال:
(1) یک مدل برای پیش بینی اولیه یک عملکرد بدون شکست و خرابی از یک App ( کیفیت ظاهری متریک در یک SS در زمینه تمامیت )
(2) یک مدل برای پیش بینی اولیه نقص های نهفته در یک App (کیفیت داخلی متریک در یک SS در زمینه تمامیت
(3) یک مدل برای بررسی تناوبی و دستیابی به میزان مطلوبی از کیفیت در یک SS
(4) یک مدل برای تعیین زمان مطلوب آزمایش قطعات یک SS که خطر شکست و خرابی در آن نیز باید در نظر گرفته شود.
 
1-5پیش بینی اولیه عملکرد بدون نقص در یک برنامه کاربردی
ما تمایز ما بین دو بخش پیش بینی کارکرد بدون نقص را پیشنهاد می کنیم. برای مثال پیش بینی اولیه (قبل از آغاز آزمایش) و پیش بینی سنتی گذشته[11]
پیش بینی اولیه کارکرد بدون نقص یک SS شامل ترکیب طرح ریزی مقادیر اندازه گیری عملکرد بدون نقص می باشد که از اندازه گیری متریک داخلی در یک Lcc معین و مقادیر محاسبه شده متریک خارجی در مرحله بعدی و در پایان توسعه SS بدست آمده است. هدف از پیش بینی اولیه تعیین پیشرفت در روش های استفاده شده و فر آیند های توسعه یک SS است بطوریکه کمترین چگالی نقص را در لحظه شروع آزمایش سیستم فراهم کند. پیش بینی اخیر از کارکرد بدون نقص یک SS با کاربرد مدل های تحلیلی اطمینان در مرحله ای از آزمایش سیستم بعد از گرد هم آوردن یک میزان مشخص از اطلاعات از نقص های SS متصل است. در حقیقت همه مدل های افزایش اطمینان شناخته شده SS ها را در مدت پیش بینی اولیه پوشش می دهند در هنگامی که قابلیت اطمینان در نتیجه آزمایش و رفع نقص ها افزایش پیدا می کند.[12]
پیش بینی کارکرد بدون نقص یک App طرحی را برای فر آیند خرابی بوسیله عملیات نا متجانس Poisson می سازد.[13]
برای مدل هایی با قابلیت اطمینان Poisson و ساختار مشروط قابل اطمینان R(t\T) بوسیله فورمول
R(t\T) = exp(-(m(T+t)-m(T))) مشخص شده است از جایی که R(t\T) مشروط بر اینکه طول زمان بدست آمده t از بهره برداری یک App تحت شرایط معین محیطی بدون تنظیم اطلاعات ورودی بوجود امده باشد.
که اگر App در طول زمان T آزمایش شده باشد و m(t) ساخت افزایش دهنده قابلیت اطمینان معادل میانگین تعداد نقص های مشخص در App در طول فر آیند ساخت برای زمان (t) باشد منجر به خرابی و شکست می شود. بررسی های قابل مقایسه بعضی از مدل های Poisson از نظر بازدهی آنها برای پیش بینی اولیه عملیات بدون نقص App ها سودمندی استفاده از مدل تشریحی D.musa [14] را مشخص می نماید.
بر خلاف دیگر مدل ها افزایش دهنده اطمینان موثر App ها در شروع آزمایش سیستم مناسب است.دستورالعمل رشد قابلیت اطمینان m(t) برای این مدل بوسیله فورمول زیر مشخص می گردد.
 
(5)m(t)= N0{ 1- exp((- λ0 / N0).t}
 
 
N0 تعداد نقص نهفته در یک App در شروع آزمایش سیستم است . 0 میزان خرابی است که برای App در آغاز آزمایش سیستم بوسیله فورمول زیر مشخص می گردد:
(6) {λ0 = N0 .{ (P.K)/(I .φ)
P شدت اجرای دستورالعمل می باشد (سرعت پردازش)
10 k=4 . ضریب تاثیر تمرکز نقص ها را نشان می دهد (که هر کدام در مدل Musa ثابت هستند.) I تعداد دستورات دستورالعمل های منبع را نشان می دهد
∂ ضریب اجرای دستور العمل را مشخص می کند. سپس قابلیت اطمینان شرطی در ساختار App به شکل زیر است.
 
(7)
 
 
بویژه اگر ما T=0 داشته باشیم مرحله آزمایش سیستم برای App افت می کند سپس ما فورمول زیر را بدست می آوریم:
 
(8)
 
 
D0=N0/Iچگالی نقص نهفته در شروع آزمایش می باشد. فورمول های (5) و (6) مقیاس اندازه گیری متریک پیش بینی شده اولیه عملیات بدون نقص یک App هستند و زمان در این آزمایش باید در نظر گرفته شود. اندازه App در واحد های استاندارد بوسیله یکی از روش های علم اصول FPA مشخص می شود و ارزش بدست آمده می تواند معرف Ksloc باشد.[15]برای پیش بینی نقص چگالی احتمالی برای یک App در نقطه شروع آزمایش سیستم مدل های فزاینده مانند آزمایشگاه رم می تواند مورد استفاده قرار گیرد.[16] به هر حال اول اینکه اکثریت آنها به سمت آبشارمایل است دوما" اطلاعات قبلی برای تنظیم چنین مدل هایی در گروههای پروژهای گرد آوری نمی شود. در این شرایط ما استفاده از نوع جدیدی از مدل ها بنام مدل های گرافیک را پیشنهاد می کنیم.[17]
 
2-5 پیش بینی نقص چگالی در برنامه کاربردی مدل های گرافیکی:
آهنگ سریع توسعه صنعت نرم افزاری و تغییر احتیاجات کاربران و شرایط اجرای پروژه ابداع وسیع مدلهای LC و اتخاذ روش شناسی های جدید را ترویج بخشید(که اصطلاحا" روش شناسی سریع برای مثال برنامه نهانی) در پروژه های SS و LC بر اساس مدل ها ی آبشاری جایگزین شده با LC پویا بر اساس مدلها سبک سنگین کردن- عمل متقابل- آموزش کاربر دارد. اتخاذ تصمیم در این پروژه بعنوان یک قانون روش های شهودی و دلایل احتمالی بر اساس دانش دست اول مدیر پروژه استفاده می شود. تاثیر برخی از فاکتورهای کیفیت تولید نهایی نرم افزار از اهمیت برخوردار است. تصدیق گفته های بالا نیاز به استفاده مکانیسم اصلاح نظرات برای مدیریت کیفیت در این فر آیند دارد.
روش های ایجاد نظرات ثابت با احتمال بازبینی مجدد آنها باید در نظر گرفته شود و اطلاعات جدید فراهم شده بوسیله روش بایسن می تواند نه تنها شالوده مدیریت کیفیت باشد بلکه در پروژه های نرم افزاری بطور کلی از اهمیت بر خوردار است به هر حال کاربرد مستقیم آن در حل مسائل مهندسی برنامه بوسیله مقادیر زیادی از محاسبه احتمالات مشروط برای مدت زیادی بغرنج می شود. در حقیقت تنها با ورود شبکه بایسن نه تنها در این مورد نیاز به مفهوم و اهمیت عملی است بلکه در دیگر روش های علمی نیز کاربرد دارد.[18]
با کمک مدل های گرافیکی بر اساس شبکه بایسن رابطه بین کیفیت فاکتورهای مطلق و سپس اطلاعات مشاهدتی می تواند در این شبکه انتشار یابد.
مزیت مهم استفاده از مدل گرافیکی بایسن برای مدیریت کیفیت از شامل تقویت پیش بینی ناقص و شیوه های تشخیص دلایل احتمالی وقوع آنها و همچنین به تسهیل اصلاح و تغییر و تبدیل با کمک الگوریتم های مناسب و ابزار در دسترس است.[19]
مدل های پیش بینی ناقص در شکل 3 نشان داده شده است. این مدل از بالاترین سطح است و می تواند در برخورد اصلی بردارها شرح داده شود این مدل نتیجه تعریف یک مجموعه فاکتورهای کیفیت و تحلیل رابطه بین علت و معلول و ترکیب ارزیابی کمی و کیفی تاثیرات آن بر کمبود چگالی و همچنین محدودیت انتخاب ابزار های در دسترس هاگین لایت G.5 است .[20]
توصیف معانی گره ها شبکه بایسن درجدول 1 آمده است. اگر شرایط گسترش این مدل در ابتدای پروژه کنونی این مدل امکان پیش بینی کمبود چگالی در App را فراهم می کند که میزان پیش بینی شده کمبود چگالی برای تعیین میزان احتمالی پیش بینی شده Ri از عملکرد بدون نقص App بکار می رود.
 
3-5 تجزیه تحلیل ثانوی تراز کیفیت هدف
تجزیه تحلیل ثانوی از تراز مطلوب اتمام برنامه کاربردی R1(t) بر اساس مقایسه میزان عملکرد بدون نقص Ri(t) با میزان مقرر شده است. برای اجرای این تجزیه تحلیل معیار های زیر برای اتخاذ تصمیم در مورد مدیریت کیفیت I ام App باید از قبل تعریف شود.=qi تراز مطلوب عملکرد بدون نقص i ام App. Dr = حد اثر میزان کمبود چگالی در App که مانعی برای بدس آوردن تراز مطلوب qi نیست. qi (ترازمطلوب کمبود در App) که در معادله زیر نشان داده شده است:
 
(9)
 
 
L0 حداقل میزان پیش بینی شده کمبود چگالی (تراز قابل اطمینیان مدیر پروژه )
شکل (3)
 
شکل (4)
 
 
Rð =میزان پیش بینی شده عملکرد بدون نقص Ri(t) از میزان هدف qi
Rð = میزان پیش بینی شده کمبود چگالی Ri(t) از میزان qi
 
ðd = بیشترین احتمال بدست آمده از میزان پیش بینی شده از کمبود چگالی L(D0) از L0 قابل قبول.
ما فرض می کنیم که q1>Ri(t) است و D0>Di در مرحله اول LC است لیست ثانوی زیر برای عملکرد های موفقیت آمیز نگهداری کیفیت iام App را فراهم و تعیین می کند.
1- اگر پیش بینی تراز قابل قبول (D0i) – L0>ðp میزان بدست آمده را فراهم کند داریم :
پس اجرای پروژه ادامه دارد |q0 – R0(t)|≤5r اگر (a) |qi – Ri (t) |>5 اگر (b)
پس تخمین منابع پروژه مخصوصا" زمان تکمیل زمان و هزینه ی نیروی کار برای آزمایش سیستم و امکان اتمام LC در فر آیند های SS باید مد نظر قرار گیرد.
2- اگر تراز اطمینان پیش بینی |L(Di ) – L |<5p باشد تصمیم در مورد وضعیت توسعه پروژه ارائه نمی کند و محاسبه Ri(t) در دامنه محدود Di و ارزیابی انحراف مربوط به Ri(t) از qi از هر کدام از آنها و محاسبات D0 که کمبود چگالی در App است را در نظر باید گرفت. این دامنه در واحد های متعارف عاملیت محاسبه می شود به عبارت دیگر دامنه واقعی این مقدار از Ri(t) می تواند گسترده تر شود.
3- اگر تراز اطمینان پیش بینی L0- L (Di)>ðp باشد به عبارت دیگر امکان انتشار میزان Di زیر تراز اطمینان قابل قبول است یا فرضیه اولیه LC App از آغاز پروژه تجاوز می کند سپس نقص مدل های گرافیکی استفاده شده تایید می شود و نیاز به اصلاح دارد.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
جدول (1)
نام گره توصیف گره های شبکه و رابطه بین متغیرها
نقص های باقیمانده تفاوت بین شدت نقص ایجاد شده توسط انسان در نسخه AP P وشدت نقص های تصحیح شده
نقص های ایجاد شده توسط انسان شدت نقص های جدید ایجاد شده به پیچیدگی مسائل حل شده درObp و کیفیت مرحله پیشرفت بستگی دارد.
نقص های قدیمی باقیمانده شدت نقص ها با پیش بینی است که در AP P در مرحله پیشرفت آشکار نشده است(نقص های باقیمانده در حقیقت منهای نقص های رفع شده هستند)
نقص های حذف شده شدت نقص های حذف شده به شدت نقص های آشکار در AP P و اغلبببب به دقت حذف بستگی دارد.قانون لفظی توزیع متغیرها در گره عامل دیگری است.
نقص های آشکار شدت نقص های آشکار به شدت نقص های ایجاد شده تئسط بشرو کیفیت کنترل بستگی دارد.
دقت تصحیح توانایی پیشرفت به رفع نقص های تصحیح بستگی دارد.ارزش بیشتر توانایی بالاتر
کیفیت کنترل توانایی تغییر نقص ها در Ap p .ارزش بیشتر توانایی بالاتر
کیفیت توسعه توانایی پیشرفت برای جلوگیری دقیق از معرفی نقص ها طی پیشرفت ap p است.ارزش بیشتر توانایی بالاتر.
نقص های ایجاد شده توسط انسان
 
 
پیچیدگی مسئله شدت نقص های جدید ایجاد شده و شدت نقص های باقیمانده ازمراحل قبلی
 
پیچیدگی مسئله در رابطه با خطر پروژه در مقوله پیچیدگی تشخیص نیازمندی ها برای AP P است. ارزش بیشتر تخمین ِ پیچیدگی بیشتر مسئله است.
 
 
 
اگر طی اجرای پروژه بعد از تثبیت کد نا ام AP P (به عنوان پیشرفت نزدیک تکمیل) تمایل کاهش شدت نقص کم باشد (ارزشهای مشاهده شده مراحل پیشرفت از قبیل (طراحی ِبرنامه ریزی و اثبات) کامل می شود.
تصحیح ممکن نظریه AP P برای گروه آزمایش است.[21]
مسئله آزمایش در تعیین منابع (به خصوص زمان و منابع پولی ) برای اهمیت AP P مناسب است و حدس هایی برای کار کردن کامل سیستم و حل مسئله کاهش کامل سیستم موجود است.برای حل مسئله ِ برای مثال : دستاورد علمی- خطر میتواند بر مبنای توزیع زمان آزمایش در بین مدلهای سیستم طی نگهداری سیستم استفاده شود.[22]
 
 
 
 
 
 
نتیجه گیری
استفاده از مدل گرافیکی بایسن برای مدیریت کیفیت براي تقویت پیش بینی نقايص و شیوه های تشخیص دلایل احتمالی وقوع آنها و همچنین تسهیل اصلاح و تغییر و تبدیل با کمک الگوریتم های مناسب در هر سيستم نرم افزاري گام بزرگي در جهت افزايش كيفيت نرم افزاربر ميدارد.
اما هنوز اغلب شركت ها از اندازه گيري هاي سيستماتيك نرم افزار براي برآورد كيفيت نرم افزار استفاده نمي كنند.يك دليل اين است كه در اغلب شركت ها فرآيند نرم افزار به طور ضعيف تعريف و كنترل مي شوند
و به اندازه اي رشد نكردند كه از اندازه گيري ها استفاده كنند. علت ديگر اين است كه استانداردي براي معيارها وجود ندارد و در نتيجه , ابزارهاي محدودي براي پشتيباني جمع آوري و تحليل داده ها وجود دارد.اغلب شركت ها تا زماني كه اين استانداردها و ابزارها فراهم نشدند, آمادگي معرفي اندازه گيري ها را ندارند.
اميد واريم در آينده نزديك اين محدوديتها را به حداقل برسانيم و شاهد پيشرفت در اين زمينه باشيم.
 
در پایان از استاد امیر محمد نیکجو که در گرد اوری این مقاله به ما کمک کرده اند تشکر و قدردانی می کنيم.
 
منابع
 
[1] 12207/FPDAM 1.2. Software Engineering: Life Cycle Processes, ISO/IEC JTC1/SC7 N2413, Software & System Engineering Secretariat, Canada (2001).
[2] V. V. Lipaev, Methods of Quality Maintenance of Large-Scale Software Tools [in Russian], SINTEG, Moscow (2003).
[3] ISO/IEC 9126–1:2001, Software Engineering — Product Quality. Part 1. Quality Model.
[4] V. V. Lipaev, Quality of Software Tools: Methodical Recommendations [in Russian], A. A. Polyakov (ed.), Yanus-K, Moscow (2002).
[5] DSTU 2844–94 Software Tools of Computers. Quality Maintenance: Terms and Definitions, Derzhstandart Ukrainy, Kyiv (1994).
[6] E. M. Lavrishcheva, “Integration paradigm in program engineering,” Problemy Programmirovaniya, Nos. 1–2, 351–360 (2000).
[7] V. N. Grishchenko and E. M. Lavrishcheva, “Methods and tools of component programming,” Cybernetics and Systems Analysis, No. 1, 39–55 (2003).
[8] ISO/IEC TR 9126–4:2004. Software Engineering: Product Quality. Part 4. Quality in using metrics.
[9] G. I. Koval and G. B. Moroz, “Modeling of requirements to the quality of software systems of data processing,” Problemy Programmirovaniya, Nos. 2–3, 237– 244 (2006).
[10] F. Zahedi and N. Ashrafi, “Software reliability allocation based on structure, utility, price, and cost,” IEEE Trans. On Softw. Eng., 17, No. 4, 345–356 (1991).
[11] G. I. Koval, “An approach to the prediction of the reliability of software support during project management,” in: Proc. Conf. UkrPROG’2002, Kiev (2002), pp. 282–290.
[12] G. B. Moroz and E. M. Lavrishcheva, “Reliability Growth models of software tools,” in: Prepr. V. M. Glushkov Cybernetics Inst. of AS of Ukraine, No. 92–38, Kiev (1992).
[13] G. B. Moroz, “Poisson reliability growth models of software tools and their application: An analytical review,” USiM, Nos. 1–2, 69–85 (1996).
[14] J. D. Musa, A. Iannino, and K. Okumoto, Software Reliability Measurement, Prediction, and Application,
McGraw-Hill, New York (1987).
[15] G. I. Koval, “Methods of determination of program sizes,” Problemy Programmirovaniya, No. 1, 63– 71 (1999).
[16] P. B. Lakey and A. M. Neufelder, System and Software Reliability Assurance Notebook, Rome Lab. Rep., Griffiss Air Force Base, Rome NY (1997).
[17] N. E. Fenton and M. Neil, “A critique of software defect prediction models,” IEEE Trans. on Soft. Eng., 25, No. 5, 675–689 (1999).
[18] Yu. V. Kapitonova, N. M. Mishchenko, O. D. Felizhanko, and N. N. Shchegoleva, “Using Bayesian networks for monitoring computer users,” Cybernetics and Systems Analysis, No. 6, 3–14 (2004).
[19] G. I. Koval, “Bayesian networks as a method of estimation and prediction of software quality,” Problemy
Programuvannya, No. 2, 15–23 (2005).
[20] Hugin Lite 6.5. Hugin Expert Product, www.hugin.com/products_Services/products/Demo/Download/.
[21] T. M. Korotun and E. M. Lavrishcheva, “Construction of a process of testing software systems,” Problemy Programmirovaniya, Nos. 1–2, 272–281 (2002).
[22] G. B. Moroz and T. M. Korotun, “Risk-operational approach to the solution of the problem of optimum release of software systems,” Problemy programmirovaniya, Nos. 2–3, 231–236 (2006).
 
==منابع==