بررسی کیفیت نرم افزار و سیستم های مدیریت آن

ضرورت تهیه و تدوین استاندارد لازم برای تولید هر محصول، بر همگان روشن است و نرم افزار رایانه‌ای که به عنوان مقوله ای فراگیر و بسیار مهم در جهان صنعتی و مبتنی بر فناوری اطلاعات و ارتباطات شناخته می شود، از این قاعده مستثنا نبوده و نیست. در طی چند دهه گذشته و در مقابله با بحران موجود در تولید محصولات نرم افزاری، متخصصان و صاحب نظران، با به وجود آوردن علوم مهندسی نرم افزار، تلاش های ارزنده بسیاری را در راستای قوام بخشیدن، برقراری و بهبود نظام تولید نرم افزار و برنامه های رایانه ای به انجام رسانیده اند

در طی چند دهه گذشته و در مقابله با بحران موجود در تولید محصولات نرم افزاری، متخصصان و صاحب نظران، با به وجود آوردن علوم مهندسی نرم افزار، تلاش های ارزنده بسیاری را در راستای قوام بخشیدن، برقراری و بهبود نظام تولید نرم افزار و برنامه های رایانه ای به انجام رسانیده اند؛ اما ویژگی های خاص این صنعت که در اثر رشد فناوری، با جهش سریع و تغییر زودهنگام نسل ها، و نیز با رُشد فزاینده و همه جانبه کاربردهای آن همراه بوده است، زمینه ساز تداوم برخی ابهام ها و پیچیدگی ها و همچنین، به وجود آمدن مسائل جدید در مبانی و امور مرتبط با آن می باشد. با وجود فعالیت های گوناگون توسط مؤسسات استانداردسازی، هنوز استانداردهای جامع و مورد پذیرش جهانی در این زمینه موجود نیست و استانداردها و رهنمودهای حاصل از این فعالیت ها، همچنان سیر تکاملی خود را سپری می نمایند.

مقدمه

کیفیت، به عنوان یکی از مهم ترین مفاهیم در مهندسی نرم افزار، نظر بسیاری از کارشناسان را به خود جلب نموده و تلاش های بسیاری را به خود اختصاص داده است. در این مقوله، همواره دو دیدگاه «کنترل کیفیت محصول نهایی» و «تضمین کیفیت تولید»، به عنوان راهکارهای مستقل و یا مکمل یکدیگر، در نظام کیفیت نرم افزارهای رایانه ای مطرح بوده اند. نتایج فعالیت های مذکور، به صورت مجموعه ای از کتب، استانداردها و رهنمودهای کلی تحت عناوین: تعریف کیفیت، فرایند تضمین کیفیت، ارزیابی و کنترل کیفیت، و یا مهندسی کیفیت، به جامعه کاربران برنامه های رایانه ای عرضه شده است. در بسیاری از متون فنی، این چنین عنوان شده که کیفیت بر مبنای خواسته های مشتری تعریف می شود. اگر چه این نظریه به طور کلی صحیح است، اما به همین دلیل (کلی بودن)، فاقد ارزش عملیاتی و غیرقابل اتکاست؛ زیرا خواسته ها، خود مبتنی و تحت الشعاع پارامترهای مختلف مانند: زمان، مکان، رشد فناوری، توان مالی، ادراک، سلیقه، قدرت پذیرش و دیگر محدودیت های موجود در محیط تولید و استفاده هستند و بنابراین، با تکیه بر این نگرش، کیفیت به مقوله ای نسبی، پارامتری، ناهمگون و تقریباً غیرقابل ارزیابی مبدل می شود. روشن است که گام اوّل در حل این مسئله، تخصیص مقادیر مشخص به پارامترهای فوق، و یا محدود کردن آنها، در حدّ ضرورت یا امکان می باشد؛ به عبارت دیگر، برای به وجود آوردن امکان اظهار نظر درباره کیفیت یک محصول، لازم است که تعریف کاربردی و غیرپارامتری برای آن ارائه شود که قابلیت استفاده در فرایندهای تولید، تضمین و ارزیابی کیفیت را دارا باشد.

تعریف کنترل کیفیت ( Quality control)

مجموعه ای از فعالیت ها برای ارزیابی و اطمینان از اینکه استانداردها و رویه های کیفی توسط تیم تولید و توسعه پروژه درست انجام گرفته باشد، کنترل کیفیت نام دارد.(1)؛ در حقیقت، کنترل کیفیت به استانداردها آشناست و به آنها آگاهی دارد و اجرای آن را بررسی و نتیجه را مشاهده می کند. مجموعه ویژگی های یک کالا و عرضه کننده آن، از لحاظ کیفی، کمّی، بها و غیره، باعث می شوند آن کالا مورد تقاضا قرار گیرد و فروش رود. کیفیت، در مقابل کمیت نیز قرار دارد. چگونگی و ماهیت یک پدیده یا شیء را کیفیت شیء یا پدیده می نامند و همچنین، محتوا نیز شامل کیفیت می باشد.

کیفیت یک محصول یا خدمت، همان چیزی است که مشتری طلب می کند. اگر محصول یا خدمت ارائه شده در جنبه هایی خاص، کیفیت بسیار بالایی داشته باشد، اما مشتری بدان نیاز نداشته باشد، تنها هزینه ای است که پرداخته شده؛ ولی ارزش افزوده ای ایجاد نکرده است. برای کنترل یک فرآیند و دستیابی به یک فرآیند با کیفیت، مدل ها و تئوری های فراوانی ارائه شده و برای هرکدام از این مدل ها، ابزارهای کنترلی ایجاد شده که به وسیله آنها می توانیم کیفیت فرآیند را زیر نظر بگیریم. کیفیت محصول، برآورده کردن نیاز امروز و فردای مشتری و همچنین، شایستگی آن جهت استفاده و تطابق آن با نیازهای کاربران است. سازمان جهانی استاندارد نیز کیفیت را این گونه تعریف کرده: تمامی ویژگی های یک محصول که در توانایی آن برای برآورده نمودن نیازهای تصریح شده یا تلویحی مؤثر، مثل راحت بودن کار با نرم افزار است. کیفیت یک فرآیند و یک محصول را می توان از زوایای متعددی بررسی کرد؛ اما همان گونه که در تعاریف سنّتی مشاهده کردیم، کیفیت در واقع برآورده کردن نیازهای مشتریان است. از این رو، شناخت و تحلیل نیازهای مشتریان، از جایگاه ویژه ای برخوردار است. در این راستا، مدل ها و روش های مختلفی برای تولید و توسعه نرم افزار وجود دارد؛ مانند: کانو، اجایل، pmbok و نایبلر.

دو نمودار در رابطه با جایگاه کنترل کیفیت وجود دارد که در حال حاضر، اجرایی است :

تعریف بررسی نرم افزار (پروژه) (Software Review)

بررسی نرم افزار، مجموعه ای از فعالیت هاست که امکانات و پیش بینی هایی را که در نرم افزار انجام گرفته تا کار با نرم افزار را آسان کند، بررسی می نماید.(2) در واقع، در بررسی نرم افزار، اعمال اصول و شیوه های استاندارد در یک پروژه انجام می شود تا سیستم با مشکل مواجه نشود. به نظر می رسد، زمانی که کنترل کیفیت بخواهد برای کیفیت نرم افزار تضمین دهد، ناگزیر است که برخی تست های نرم افزار نهایی، نسخه آلفا و بتای محصول را به صورت دستی و توسط شخصی که خود را در جایگاه کاربر نهایی قرار می دهد، انجام دهد.

در متولوژی اجایل، برای بررسی نرم افزار، جایگاه خاصی در نظرگرفته شده است. به صورت واقعی، کاربر نهایی از اوّلین نسخه هایی که نرم افزار بیرون می آید یا در پاره ای از موارد، بعد از تشکیل زیرسیستم ها در اختیار کاربر قرار داده می شود و توسعه بر اساس بازخوردی که از کاربران گرفته می شود، انجام می گردد و این، برتری متدولوژی اجایل نسبت به دیگر متولوژی های مورد استفاده خواهد بود.

اجرای یک برنامه با هدف پیداکردن خطا

- تست خوب: احتمال پیدا کردن خطاهای کشف نشده توسط ارزیابی زیاد است.

- تست موفق: حداقل یک خطای کشف نشده را بیابد. تست فقط وجود خطا را نشان می دهد و نه عدم وجود آن را. پیدا نشدن خطا در تست، به معنای بدون خطا بودن برنامه نیست.

تست از اجزای کوچک شروع می شود؛ ضمن اینکه تست کامل برای مؤثربودن، باید توسط شخص ثالث بی طرف انجام شود.

هدف از به کارگیری محک های کیفیت نرم افزار

کیفیت نرم افزار، درجه ای است که به اندازه آن، محصول نرم افزاری، دارای ترکیب دلخواهی از ویژگی هاست. این ترکیب دلخواه، باید به روشنی تعریف شود؛ در غیر این صورت، برآورد آن به صورت منطقی امکان پذیر نخواهد بود. انتخاب مجموعه ای مناسب از محک ها که با عوامل و خصوصیات انتخابی مرتبط هستند، گام بعدی استفاده کننده از این مجموعه استانداردها می باشد.

هدف از به کارگیری محک های نرم افزاری، ایجاد امکان برآورد در چرخه حیات است؛ به گونه ای که میزان برآورده شدن نیازمندی های کیفی قابل تشخیص گردد. اگرچه محک های نرم افزاری، با فراهم آوردن یک پایه کمّی (مقداری)، امکان تصمیم گیری نسبی در مورد کیفیت نرم افزار را فراهم می آورند، اما استفاده از آنها، قضاوت انسانی را در ارزیابی کیفیت نرم افزار حذف نمی نماید. انتظار می رود، با توجه به آشکار نمودن جزئیات پنهان و ویژگی های خاص محصولات نرم افزاری، استفاده از محک های نرم افزاری در یک سازمان یا یک پروژه، کوششی مؤثر و مفید باشد.

استانداردهای بررسی نرم افزار

در توسعه یک نرم افزار مجموعه فعالیت هایی داریم که بروز اشتباهات انسانی در آنها غیرقابل اجتناب است. پس از آنکه کد منبع تولید شد، نرم افزار باید برای خطاهای احتمالی و موجود مورد ارزیابی قرار گیرد. بنابراین، هدف، طراحی حالاتی است که نرم افزار تحت آنها تست گردد و احتمال یافتن خطا توسط آنها زیاد باشد. تحت این تکنیک ها منطق درونی قطعات نرم افزار و همچنین، دامنه های ورودی و خروجی به کل نرم افزار مورد بررسی قرار می گیرد. در مراحل اوّلیه، مهندسان نرم افزار این کار را انجام می دهند و با توسعه بیشتر، متخصصان تست.

معیارهای تست پذیر بودن نرم افزار(4)

این معیارها عبارت اند از:

1.قابلیت اجرا (Operability): هرچه نرم افزار بهتر کار کند و در محیط های بیشتری قابل اجرا باشد، n بهتر قابل ارزیابی است.

2.مشاهده پذیری (Observability): قابلیت مشاهده نتایج ارزیابی.

3.کنترل پذیری (Controlability): قابلیت اجرای تست های خودکار؛ مثل امکان اجرای خودکار تست های واحد توسط jUnit برای زبان جاوا.

4.تجزیه پذیری (Decomposability): ارزیابی می تواند هدفمندتر شود.

5.سادگی (Simplicity): کاهش پیچیدگی معماری و منطق برنامه.

6.پایداری (Stability): برای ارزیابی، تغییرات کمی بخواهد.

7.درک پذیری (Understandability): قابلیت درک طراحی و وابستگی های بین اجزا.

سطوح مختلف تست

این سطوح عبارت اند از:

1.تست واحد (Unit testing)؛

2.تست یکپارچه سازی (Integration testing)؛

3.تست سیستم (System testing)؛

4.تست پذیرش (Acceptance testing):

- تست آلفا (Alpha test)؛

- تست بتا (beta test).

* تست واحد

تست واحد یا micro level، پایین ترین سطح تست است. هر کد تست واحد، یک قطعه کد یا یک تابع (متد) خاص را تست می کند. این تست، نیاز به دانش در مورد طراحی و شیوه عملکرد داخلی تابع یا قطعه کد دارد. این نوع تست، توسط برنامه نویس انجام می شود؛ نه تست کننده.

* تست یکپارچه سازی افزایشی

تست یکپارچه سازی افزایشی با افزوده شدن قابلیت جدید به نرم افزار، اجرا می شود. هدف این تست، بررسی درستی نرم افزار پس از افزوده شدن امکان جدید است. امکانات نرم افزار باید از هم استقلال داشته باشند تا بتوان پیش از تکمیل کل نرم افزار و به صورت افزایشی، نرم افزار را تست کرد. این فرایند، توسط برنامه نویس یا تیم تست انجام می شود.

* تست یکپارچه سازی

این تست، حاصل از کنار هم قرار گرفتن قطعات مختلف نرم افزار به منظور بررسی درستی عملکرد آن است و این نرم افزار یکپارچه شده، شامل قطعه کدها، یعنی ماژول هایی از کد برنامه های مجزاست که در کنار هم، برنامه اصلی را تشکیل می دهند. برنامه های مشتری ـ کارگزارِ عمل کننده در یک شبکه، پس از تست واحد انجام می شود.

* تست سیستم

این تست به منظور بررسی عملکرد نرم افزار روی پلتفرم های مختلف و نرم افزارهای پلتفرم OS انجام می شود. سخت افزار و نرم افزار، یعنی موارد کاربردی مورد نیاز، به منظور اطمینان از این امر است که برنامه با مؤلفه های دیگر محیط اجرایش به خوبی کار می کند و نیز جهت اطمینان از اینکه نرم افزار ارائه شده در محیط مورد نظر قابل استفاده است. نمونه مشکل حاصل از انجام ندادن تست سیستم نرم افزار، بازی شیر شاه دیزنی (Disney's Lion King Game) در پاییز سال ۱۹۹۴ است. شرکت دیزنی اوّلین CD بازی خود تحت عنوان شیر شاه Lion King را که بر اساس کارتونی به همین نام ساخته شده بود، وارد بازار کرد. بسیاری از شرکت های دیگر تا آن زمان اقدام به ساخت بازی های رایانه ای کرده بودند؛ اما این اوّلین بار بود که شرکت دیزنی وارد این تجارت شده بود. دیزنی برای فروش این بازی، دست به تبلیغات گسترده ای زد و در نتیجه، این محصول با فروش بسیار بالایی مواجه شد؛ اما اتفاقات پس از آن، تبدیل به کابوسی برای این شرکت شد. در ۲۶ دسامبر، روز پس از کریسمس، تلفن های بخش پشتیبانی مشتریان شرکت دیزنی شروع کرد به زنگ زدن، زنگ زدن و زنگ زدن! متصدیان پاسخگویی به تماس ها با خیل عظیمی از والدین عصبانی با بچه های گریان مواجه شدند که ادعا می کرند نرم افزار مزبور کار نمی کند. این خبر به سرعت در مطبوعات و تلویزیون نیز پخش شد و کریسمس آن سال را برای بسیاری از پرسنل دیزنی تلخ کرد. علت چه بود؟ پس از بررسی مشخص شد که دیزنی نرم افزار خود را روی بسیاری از مدل های PC تست نکرده بود و در نتیجه، تنها روی سیستم هایی کار می کرد که برنامه نویسان دیزنی روی آن سیستم ها نرم افزار خود را توسعه داده بودند و نه دستگاه های متداولی که عموم مردم از آن استفاده می کردند.

* تست پذیرش

تست پذیرش به منظور بررسی اینکه نرم افزار نیازهای مشتری را برآورده می کند، انجام می شود و بعد از تست سیستم انجام می شود. این نوع تست، شامل موارد ذیل است:

- تست آلفا: در پایگاه توسعه دهنده نرم افزار و در اغلب موارد، توسط n کارمندان داخلی و گاهی نیز، توسط مشتری تعدادی از کاربرانش که به محل دعوت می شوند، انجام می گیرد.

- تست بتا: در این تست، نسخه هایی از نرم افزار در اختیار تعدادی از کاربران قرار می گیرد تا در بازه ای با آن کار کنند و خطاها را گزارش دهند.

روش های ارزیابی

1.روش جعبه سفید: دانستن شیوه کار داخلی برنامه، امکان تأیید چگونگی عمل هر تکه کد و مسیر اجرا مراحل اولیه ارزیابی.

2.روش جعبه سیاه: دانستن عمل مورد انتظار و مطلوب، و امکان تأیید کاری که سیستم باید انجام دهد. مراحل انتهایی ارزیابی استراتژی تست نرم افزار، توصیفی رسمی است از اینکه نرم افزار چگونه تست خواهد شد. هدف استراتژی تست، تعریف همه مراحل برای فرایند تست نرم افزار است که شامل برنامه ریزی آزمایش، طراحی ابزار آزمایش، اجرای آزمایش و جمع آوری و ارزیابی داده های به دست آمده باشد.

استراتژی جعبه سیاه

این آزمایش، جایگزین آزمایش جعبه سفید نمی باشد؛ بلکه مکمل آن است و خطاهایی متفاوت با آن را تست می کند. شما نرم افزاری را که به آن نیاز داشتید، تهیه می کنید و روی سیستم خود نصب می کنید. در بیشتر موارد بعد از نصب برنامه، فقط یک نسخه اجرایی آن را در سیستم خود خواهید داشت و هیچ دسترسی به سوریس کد و منابع دیگر برنامه ندارید. سیستم نرم افزاری موجود، برای شما مانند یک جعبه سیاه است که نمی توانید دورن آن را مشاهده کنید و به آن دسترسی داشته باشید. استراتژی جعبه سیاه، دقیقاً از این دیدگاه برنامه را مورد آزمایش قرار می دهد؛ یعنی با این پیش فرض که شما هیچ اطلاعاتی از کد و طراحی داخلی برنامه ندارید. حال که هیچ اطلاعاتی از کد و طراحی برنامه در اختیار ما نیست، چگونه می توان به صحت کارکرد برنامه پی بُرد؟ جواب، خیلی ساده است؛ با تمرکز بر ورودی ها و خروجی‌ها، برای اینکار آزمایش کننده نرم افزار به مستندات نرم افزار مراجعه می کند تا مشخص کند که سیستم در مقابل یک عمل خاص، چه پاسخی باید بدهد. سپس، داده ها را برای هر کدام از عملیات انتخاب می کند و رفتار سیستم را در مقابل آن داده ها با رفتار واقعی سیستم که در مستندات وجود دارد، مقایسه و بررسی می کند.

در یک استراتژی آزمایش جعبه سیاه، عموماً موارد زیر را مورد بررسی و آزمایش قرار می دهیم:

- بررسی مقادیر مرزی برای متغیرها: به یک متغیر، مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند، می دهیم و سیستم را در این شرایط تست می کنیم.

- بررسی خروجی های سیستم: مجموعه ای از ورودی های صحیح با خروجی های مربوط به آن را تهیه می کنیم و سپس، ورودی ها را به سیستم وارد می کنیم و خروجی هایی را که توسط سیستم داده می شود، با خروجی های واقعی مقایسه می کنیم و رفتار سیستم را در برابر پردازش ورودها و پرس و جو های بزرگ و سنگین بررسی نماییم.

استراتژی جعبه سفید

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

در یک استراتژی آزمایش جعبه سفید، عموماً موارد زیر را مورد توجه و بررسی قرار می دهیم:

ـ بررسی سطر به سطر کد (Code coverage): در این حالت، باید سیستم را به گونه ای اجرا و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجرا شده است.

ـ بررسی همه انشعاب ها در کد برنامه (branch): در کد برنامه باید تمام عبارت های شرطی (if elseها و Switch caseها) را تک به تک مورد بررسی قرار داد؛ به این صورت که در یک عبارت if else، هم قسمت if و هم قسمت else هرکدام به صورت مجزا یکبار اجرا شوند.

ـ بررسی همه حلقه ها در برنامه: حلقه ها، در نرم افزار نقش اساسی دارند؛ چون می توانند با اشتباه جزئی، مقدار بسیاری از منابع را مصرف کنند؛ برای مثال، شرط خروج از حلقه، به اشتباه هیچ وقت True نشود؛ برای نمونه، حلقه ها را با ورودی بزرگ تر از شرط خروج حلقه چک کنید؛ یعنی حلقه اصلاً اجر نشود. تستی طراحی کنید که حلقه دقیقاً یکبار اجرا شود و یا حلقه در یک بازه خاص اجرا گردد.

ـ مدیریت خطای مطلوب: بررسی اینکه اگر به یک روش یک ورودی نامعتبر وارد شود، شیوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد.

ـ بررسی امنیت: سیستم را در برابر دسترسی های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند، مورد بررسی قرار می دهد. در اینجا ما باید مکان هایی از کد را که داده ها را اعتبارسنجی و مدیریت می کنند و یا دسترسی به منابع و عملیات مهم و حیاتی را انجام می دهند، بررسی نماییم.

پی نوشت ها:

1. جوران، خروج از بحران.

2. پارسا، سعید، مهندسی نرم افزار.

3. پایگاه اینترنتی ویکی پدیا، ذیل عنوان «Software Review».

4. ـــــ . ذیل عنوان «تست نرم افزار».

منابع:

1. حسنی، فرنود. «چالش های مدیریتی تولید نرم افزار درایران»، نشریه کتاب ماه کلیات، مهر و آبان 84، ش 94 و 95.

2. کاظمی، علی. «تأثیر رهبری معنوی اسلامی بر عملکرد سازمانی مورد مطالعه شرکت گاز استان لرستان»، نشریه مدیریت اسلامی، بهار و تابستان 92، ش 5.

3. پارسا، سعید. مهندسی نرم افزار. انتشارات علم و صنعت، اسفند 1391ش.

منبع: فصلنامه ره آورد نور، شماره 55