تضمین کیفیت نرمافزار
الف) مفهوم کیفیت نرمافزار :
هر
رویکرد مهندسی (از جمله مهندسی نرمافزار) باید مبتنی بر اقدامات سازمانی نسبت به
کیفیت باشد. در فرهنگ لغت American Heritage کیفیت بهعنوان "خصوصیت
یا صفتی از یک چیز"
تعریف میشود. بهعنوان صفت یک شی، کیفیت عبارت است از ویژگیهای قابل اندازهگیری- چیزهایی که
با استانداردهای شناخته شده قابل مقایسهاند- همانند طول، رنگ، خصوصیات الکتریکی و غیره. ولی نرمافزار که تا حد زیادی یک نهاد
فکری است، بهراحتی اشیا فیزیکی نمیتوان مشخص کرد. با این وجود، میزانهایی
برای ویژگیهای یک برنامه وجود دارد. این خواص شامل پیچیدگی سیکلوماتیک، انسجام،
تعداد نقاط عملکرد، تعداد خطوط برنامه و بسیاری از موارد دیگر میشود. هنگامی که
چیزی را بر اساس ویژگیهای قابل اندازهگیری آن بررسی میکنیم، به دو نوع کیفیت
برمیخوریم. کیفیت طراحی و کیفیت مطابقت.
کیفیت طراحی به ویژگیهایی اشاره دارد که طراح برای یک شی
مشخص میکند. پایه مواد اولیه، تولرانسها، و مشخصات کارآیی در کیفیت طراحی
سهیم هستند. اگر محصول طبق
مشخصات ساخته شود، به موازات استفاده از مواد اولیه با پایه بالاتر، تولرانسهای محدودتر، و
مشخص شدن سطوح بالاتری از کارآیی، کیفیت طراحی محصول افزایش مییابد. کیفیت مطابقت حد پیروی از مشخصات
طراحی در اثنای ساخت است. هر چه میزان مطابقت بیشتر باشد، سطح کیفیت
مطابقت بالاتر خواهد بود.
در توسعه نرمافزار، کیفیت طراحی شامل خواسته ها، مشخصهها و طراحی سیستم است. کیفیت مطابقت مسئلهای است که اساساً بر پیادهسازی تاکید دارد.اگر پیاده سازی از طراحی پیروی کند و سیستم حاصل، خواستهها و اهداف کارآیی را برآورده سازد، کیفیت مطابقت بالاست.
بعبارتی دیگر
کیفیت به مشخصهای اطلاق میشود که:
o
تعدادی از نیازمندیها را برآورده کند که بر روی
آنها توافق صورت گرفته است.
o
بهوسیله معیارهای سنجش و اندازهگیری موافقت شده
ارزیابی شود.
o به وسیله فرآیند مورد توافق تولید شود.
ب) کنترل کیفیت (Quality Control (QC)):
کنترل کیفیت مجموعهای از بازبینیها، مرورها و آزمایشهای استفاده شده در طی فرآیند نرمافزار به منظور اطمینان از انطباق محصول با نیازهایی است که برای آن تعریف شده است. کنترل کیفیت شامل حلقههای بازخورد به فرآیندی است که محصول کاری را ایجاد کرده است. ترکیب اندازهگیری و بازخورد این امکان را ایجاد میکند که اگر محصول کاری ایجاد شود و مشخصههای تعریف شده برای آنها فراهم نشود، فرآیند ایجاد آنها تنظیم گردد. فعالیتهای کنترل کیفیت میتواند به صورت خودکار، دستی و یا ترکیبی از ابزارهای خودکار و ارتباط انسان انجام شوند.
ج) تضمین کیفیت (Quality Assurance (QA)) :
همانند هر
سیستم یا رویه کسبوکاری، کیفیت دغدغه اصلی سیستمهای اطلاعاتی است. تضمین
کیفیت، فرآیند اطمینان
از این مسئله است که سیستم اطلاعاتی، حداقل استاندارهای کیفیت را ، همانگونه که
توسط کارمندان پیادهسازی و مدیریت تعیین شده است، برآورده میکند. QA گاهی معادل با یافتن اشکالات در کد برنامه است، ولی
این دیدگاه جزئی و ناقص است. QA
مجموعه ای از فعالیتهاست که در سراسر چرخه حیات توسعه سیستمها (SDLC) برای ساخت صحیح سیستمها از شروع کار تا تشخیص و اصلاح فوری
خطاها انجام میشوند. مشارکت دادن تضمین کیفیت در فعالیتهای اولیه پروژه،
موجب میشود تا از بسیاری از خطاهای برنامهنویسی بطور کامل اجتناب شود. همچنین
اطمینان میدهد که سیستم توسعهیافته، نیازهای کاربران و سازمان را برآورده میکند.
فعالیتهای QA در طی تحلیل، بر شناسایی شکافها یا منسجم نبودن نیازمندیهای سیستم متمرکز است.
فعالیتهای QA در طی طراحی، برای
برآورده کردن نیازمندیهای بیان شده و بر تصمیمگیریهای طراحی که منجر به پیادهسازی
آسان و بدون اشکال برنامهها میشود، متمرکز است. فعالیتهای QA در طی پیادهسازی، مشتمل بر تست اولیه است. به هر حال، طراحی و
پیاده سازی در بیشتر پروژهها همپوشانی دارند. بنابراین فعالیتهای تضمین کیفیت
برای طراحی معمولا با فعالیتهای تست یکپارچه میشوند.
در طی طراحی و
بخصوص پیادهسازی به فعالیتهای QA توجه
زیادی نمیشود. این اشتباه به دلایل متعددی روی میدهد. از جمله:
1)
فشردگیهایی در زمانبندی هنگام پیشرفت پروژه به
وجود میآیند. فعالیتهای QA و تست ممکن است برای تسریع پروژه انجام
نشوند.
2)
فعالیتهای QA نیازمند این است که پرسنل توسعه، کار خود را
برای دیگران توضیح دهند. بیشتر افراد تمایلی به انجام این کار ندارند.
3)
بیشتر افراد،
پرسنل تست را حاملان خبرهای بد میدانند چرا که مورد نقد و بررسی قرار میگیرند و
کنار گذاشتن تست را به بیخبری از خبرهای بد ترجیح میدهند.
راه حل:
روش سادهای برای جلوگیری از اختلال در فعالیتهای
QA که ماحصل طبیعت انسان و فشردگی زمانبندی است،
وجود دارد.بطور رسمی، از ابتدا QA را
در پروژه و زمانبندی یکپارچه کنید و هرگز آن را متوقف نکنید. استانداردهای کیفیت
باید بطور شفاف بیان شود و قابل اندازهگیری باشند. اگر محصولی این استاداردها را
برآورده نکرد، باید اصلاح شود؛ بدون توجه به تاثیری که ممکن است بر زمانبندی یا بودجه
گذارد. این رویکرد در QA نیازمند یک تعهد سازمانی از مدیریت ارشد تا
ایینترین سطح است. متاسفانه، مدیریت ارشد اغلب سبب تلاش برای کوتاه کردن
فعالیتهای QA جهت تسریع در پروژه است.
عامل کلیدی دیگر در انجام قاطعانه QA در فرآیند توسعه، ایجاد محیطی مناسب، همراه با همکاری و توجه
مشارکت کنندگان در پروژه است. پرسنل باید پیشنهادات و انتقادات سازنده را بپذیرند
و نظرات و پیشنهادات و انتقادات خود را نیز به دیگران منتقل کنند. اگر اجازه
انتقادهای مخرب داده شود و یا دیگران را مقصر بدانیم، QA نمیتواند کارآمد باشد.
هزینه اصلاح یک خطا با پیشرفت توسعه یک سیستم،
افزایش پیدا میکند. خطاها در طی تحلیل یا طراحی بهتر شناسایی میشوند؛ پس هرگز
آنها را به کد برنامع واگذار نکنید. اصلاح خطاها در برنامهها در ابتدای مراحل
اولیه پیادهسازی بسیار آسانتر از زمانی است که تست پذیرش انجام میشود یا حتی
بدتر از آن بعد از عملیاتی شدن سیستم. این واقعیت اقتصادی، موجب ارزشمند شدن تلاشهای
QA در سراسر چرخه حیات توسعه سیستم (SDLC) میشود.