پیچیدگی نرم افزار

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

کار زیادی در مورد منشأ و ماهیت پیچیدگی نرم‏افزار انجام نشده است. بیشتر کارهای انجام شده دراین زمینه به تأثیر پیچیدگی بر پروژه‏های نرم‏افزاری پرداخته‏اند که در رأس آنها کیفیت و هزینه‏های محصول قرار می‏گیرد. توجه مدیران و مهندسان پروژه‏های نرم‏افزاری به پیچیدگی نرم‏افزار برای کنترل و پیش‏بینی کیفیت و بهره‏وری محصول است.

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

۲-تعریف پیچیدگی

وقتی در مورد پیچیدگی نرم‏افزار صحبت می‏کنیم اولین سؤالی که باید پاسخ داده شود این است که: “پیچیدگی چیست؟”. توافق عمومی ‏بر روی چگونگی تعریف پیچیدگی نرم‏افزار وجود ندارد. پیچیدگی نرم‏افزار یک موضوع کلّی، غیراستاندارد و اصطلاحی وابسته است که ترکیب سیستم را توصیف می‏کند. دلیل وابسته بودن این اصطلاح این است که مقدار مطلقی را نمی‏توان به آن نسبت داد. یک سیستم با پیچیدگی نرم‏افزاری بالا ممکن است نسبت به سیستم‏های دیگر پیچیدگی کمتری داشته باشد، پیچیدگی نرم‏افزار اصطلاح غیراستانداردی است زیرا محدوده‏ی آن مشخص نیست و می‏تواند در موارد متفاوت با معانی متفاوت به کار رود. یک سیستم با کد حجیم که چندین پیمانه به ‏هم مرتبط دارد می‏تواند به‏عنوان یک سیستم پیچیده در نظر گرفته شود. از طرفی یک برنامه‏ی کوتاه با الگوریتم سخت را نیز می‏توان پیچیده نامید.

باور عمومی ‏بر این است که پیچیدگی نرم‏افزار را نمی‏توان فقط با استفاده از یک بعد تعریف کرد.

فرهنگ کامپیوتری استاندارد IEEE، “پیچیدگی” را به این صورت تعریف می‏کند : میزان سختی درک یا بازبینی یک سیستم یا مولفه که طراحی یا پیاده سازی شده است.[۱] عبارت “سختی ِدرک” اشاره دارد به اینکه پیچیدگی لزوماً مقیاس مطلقی برای اندازه گیری نیست بلکه نسبی است به این معنی که آنچه برای شخصی پیچیده به نظر می‏رسد می‏تواند برای دیگری براحتی قابل فهم باشد مثلاً، یک مهندس نرم‏افزار که با تئوری سیستم‏های کنترل آشنایی دارد ساختار و سازمان خوب یک سیستم خوش‏طرح کنترلی را تشخیص می‏دهد در حالی که مهندس نا آشنا با تئوری مشکل زیادی در درک طراحی خواهد داشت. مهمتر این که مهندس ناآشنا بدون داشتن دانش پایه به احتمال زیاد توانایی طرح یک سیستم خوش‏ساختار را نخواهد داشت. بنابراین آموزش جزء مهمی‏در رابطه با پیچیدگی نرم‏افزار است.

اندازه‏گیری پیچیدگی نرم‏افزار یکی از زمینه‏های مهندسی نرم‏افزار است که به فاکتورهایی از اندازه‏گیری تأثیرگذار بر هزینه‏های نگهداری و توسعه می‏پردازد. Zuseادعا می‏کند “پیچیدگی نرم‏افزار” به درستی تعریف نشده است و اندازه‏گیری پیچیدگی نرم‏افزار اسم بی مسمّی‏ است. وی برای پیچیدگی نرم‏افزار تعریفی به این صورت ارائه می‏کند: “معنی درست پیچیدگی نرم‏افزار سختی نگهداری، تغییر و درک نرم‏افزار است. پس با پیچیدگی وابسته به روان‏شناسی نرم‏افزار سر و کار دارد”.

این تعاریف پیچیدگی نرم‏افزار را به پیچیدگی وابسته روان‏شناسی مر بوط می‏کند. سه نوع مشخص از پیچیدگی وابسته به روانشناسی که بر درک برنامه‏نویس از نرم‏افزار اثر می‏گذارد عبارتنداز: پیچیدگی مسأله، پیچیدگی طراحی سیستم و پیچیدگی رویه‏ای. پیچیدگی مسأله، تابعی از دامنه مسأله است. به بیان ساده، فرض بر این است که درک مسائل پیچیده برای برنامه‏نویس مشکل‏تر از درک مسائل ساده است. از آنجا که این نوع از پیچیدگی غیر قابل کنترل است عموماً در مهندسی نرم‏افزار نادیده گرفته می‏شود. پیچیدگی سیستمی‏ نگاشتِ فضای مسأله به یک نمایش مشخص است. پیچیدگی داده‏ای و پیچیدگی ساختاری دو نوع از پیچیدگی طراحی سیستم است که برای سیستمهای ساخت یافته تعریف می‏شود[۲]. پیچیدگی ساختاری به مفهوم اتّصال اشاره دارد. اتّصال، وابستگیِ بین پیمانه‏های کد منبع را اندازه‏گیری می‏کند، بعنوان مثال، توابع C سایر توابع C را فراخوانی می‏کنند. هر چه اتّصال بین پیمانه‏ها بیشتر باشد درک پیمانه برای برنامه‏نویس مشکلتر خواهد بود. پیچیدگیِ داده‏ای مفهوم چسبندگی را تداعی می‏کند چسبندگی، وابستگی در درون پیمانه را اندازه‏گیری می‏کند. در این حالت، هر چه پیمانه چسبنده‏تر باشد درک آن برای برنامه‏نویس آسانتر است[۳]. پیچیدگیِ داده‏ای و ساختاری، میزانهای مبتنی بر fan-in، fan-out پیمانه و تعداد متغیرهای ورودی/خروجی هستند.

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

پیچیدگیِ رویه‏ای به ساختار منطقی برنامه مربوط می‏شود. این روش اندازه‏گیری پیچیدگی، طول برنامه (تعداد نشانه ‏ها یا تعداد خط کد برنامه) یا تعداد ساختمانهای منطقی (ترتیب، تصمیم‏گیریها یا حلقه‏ها) را که برنامه شامل می‏شود بعنوان پیچیدگی برنامه در نظر می‏گیرد.

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

ایده‏ی پشتِ تمام تعاریف پیچیدگی این است که هرچه عبارت یا مدلی حاوی اطلاعات بیشتری باشد، پیچیده‏تر است. اطلاعات چیزی است مثل محتوای یک پیغام که بین فرستنده و گیرنده ارتباط برقرار می‏کند و روی حامل اطلاعاتی مثل مجموعه‏ای از عبارات زبانی و نمادها منتقل می‏شود.

۳- ماهیت پیچیدگی

در مرکزِ موضوع پیچیدگی، مسأله شناخت قرار می‏گیرد[۴]. زمانیکه نرم‏افزار تأخیر دارد، ناقص است، بدرستی معیّن نشده یا بطور دقیق قیمت گذاری نمی‏شود ممکن است به این دلیل باشد که توسعه‏دهندگان نرم‏افزار در یک حوزه ناشناخته و پویا کار می‏کنند که کورمال دنبال شناخت دقیق و کامل موضوعاتی هستند که نرم‏افزار باید اداره کند. وقتی نرم‏افزار براحتی قابل استفاده مجدّد نیست یا نگهداری و عملیاتی شدن آن سخت است بدلیل کنار هم قرار گرفتن پیچیدهی بخشهایی با تعامل بالایی است که شناخت نرم‏افزار را مشکل می‏کند. علت بی دوامی نرم‏افزار یا بروز اتفاقات غافلگیرکننده ناخوشایند نبودن شناخت کامل است که به مصالحه و انعطاف ناپذیری منجر شده وتغییر و انحراف از استفاده معمول خطرناک می‏شود. در هر حالت، پیامدِ پیچیدگی خسارتی است که بدلیل عدم شناخت می‏پردازیم. بنابراین پیچیدگی میزانی برای دشواری شناخت و درک یک چیز است.

۴- اجزاءی کلیدی در پیچیدگی

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

پیچیدگی چند جزء کلیدی دارد:

مقیاس: تعداد اجزاءی سیستم نرم‏افزاری

تنوّع: گستره‏ اجزاءی متفاوتی که سیستم را تشکیل می‏دهند.

اتّصال: ارتباطات بین مولفه‏ها

چرا این اجزاءء پیچیدگی دشواریِ درک سیستم را موجب می‏شوند؟

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

تنوّع، تعداد انواع اجزاءیی را که باید تحلیل شوند افزایش می‏دهد هر چه تنوّع بیشتر باشد تلاش بیشتری برای درک هر جزء و ترکیبی از اجزاء لازم است.

اتّصالات نیز دشواریِ درک یک سیستم را بیشتر می‏کنند. با افزایش مقیاس تعامل بین اجزاء بصورت نمایی افزایش می‏یابد.

۵- عملکردِ ضروری در مقابل پیچیدگی عارضی

عملکردِ ضروری از نیازمندی‏ها بر می‏خیزد و در حقیقت ماهیت آنچه سیستم باید انجام دهد را مشخص می‏کند و می‏تواند مثلاً از سخت‏افزار به نرم‏افزار منتقل شود ولی نمی‏تواند حذف شود مگر با حذف نیازمندی‏های غیر ضروری. پیچیدگی ضروری ذاتی و غیر قابل اجتناب است و در حقیقت از چیزی که سیستم باید انجام دهد ناشی می‏شود. پیچیدگی ذاتی با پیچیدگی الگوریتم سر و کار دارد و به مدل محاسباتی استفاده شده برای حلّ مسأله وابسته است که به صورت کمینه، پیچیدگی در بین تمام الگوریتم‏هایی که به‏عنوان راه‏حل ارائه شده‏اند، تعریف می‏شود. پیچیدگی ذاتی عموماً، برحسب زمان و فضای مورد نیاز برای اجرا اندازه‏گیری می‏شود. کیفیت و کارایی طراحی و هزینه‏ی کلّی پروژه در بهترین حالت از طریق پیچیدگی ذاتی تعیین می‏شود. امّا پیچیدگی عارضی از برنامه‏های کامپیوتری یا از فرایند توسعه (برنامه‏نویسی کامپیوتری) یا از انتخاب‏های صورت گرفته در ساخت یک سیستم ناشی می‏شود مثلاً از معماری نرم‏افزار، طراحی ساختمان‏داده، زبان برنامه‏نویسی و راهبردهای کد نویسی نشأت می‏گیرد. انتخابهای عاقلانه‏تر می‏توانند پیچیدگی عارضی را کاهش دهند. پس پیچیدگی عارضی در حقیقت نتیجه چگونگی ساخت نرم‏افزار است. بنابراین بهترین راه برای مقابله با پیچیدگی این است که ابتدا مسأله (چه چیز) را درست تعریف کنیم سپس دنبال ایجاد یا انتخاب راه حلی (چگونگی) مناسب برای حلّ مسأله باشیم. این نوع پیچیدگی با توسعه سیستم سر و کار دارد و شامل ویژگی‏هایی نظیر اندازه‏ی سیستم، تعداد پیمانه‏ها، تعداد توابع در درون سیستم و اتّصال بین پیمانه‏ها می‏باشد.[۵]

فاکتورهای پیچیدگی ضروری با داشتن نیازمندیهای صحیح، غیر مبهم، ضروری، کامل و با ثبات هم‏ارز است. بدیهی است که بزرگترین موضوع پیچیدگی ضروری مهندسی نیازها و تحلیل است. امّا، در پیچیدگی عارضی تعداد و محدوده موضوعات بسیار متنوّع و گسترده‏ای شامل فرایند، سازمان، استاندارد و غیره را در بر می‏گیرد.

پیچیدگی عارضی با تصمیم‏گیری‏های درست قابل کاهش است و هدف اکثر پیشنهادهای مطرح شده است.

فاکتورهای دخیل در پیچیدگیِ عارضی می‏توانند انتخاب معماری نرم‏افزار، تجربه و مهارت تیم نرم‏افزار، ابزارهای توسعه بکار رفته، منابع و فرصت آماده کردن مناسب بجای آماده سازی سریع باشند. پیچیدگی عارضی می‏تواند با افزایش پیچیدگی ضروری افزایش یابد.

به عبارتی پیچیدگی به دو دسته تقسیم می‏شود:

پیچیدگی مسأله: (پیچیدگی ذاتی یا پیچیدگی ضروری) که در طول فازِ نیازمندیها ایجاد می‏شود.

پیچیدگی راه‏حل: (پیچیدگی افزوده یا پیچیدگی عارضی) که بعد از پیچیدگی مسأله مطرح می‏شود. این نوع از پیچیدگی اساساً، در مراحل توسعه نرم‏افزار بعد از فاز نیازمندیها در فازهای طراحی و تولید کد ایجاد می‏شود.

این نوع دسته بندیها به مهندسان نرم‏افزار کمک می‏کند تا تعیین کنند که کی و چگونه پیچیدگی وارد پروژه می‏شود، همچنین آگاه می‏شوند که روی کدام مرحله‏ از چرخه حیات نرم‏افزار باید تمرکز کنند تا قادر باشند پیچیدگی نرم‏افزار را کنترل و کاهش دهند.

این پیچیدگی با منابع مورد نیاز پروژه ارتباط دارد. با این رویکرد پیچیدگی یک مسأله را می‏توان بصورت مقدار منابع مورد نیاز برای یک راه‏حل بهینه برای مسأله تعریف کرد، پس پیچیدگی یک راه‏حل می‏تواند بصورت منابع مورد نیاز برای پیاده‏سازی یک راه‏حل خاص درنظر گرفته ‏شود. این منابع از دو جنبه بررسی می‏شود زمان، بعنوان مثال زمان کامپیوتر و ساعات پرسنل و فضا بعنوان مثال حافظه کامیپوتر، پشتیبانی نرم‏افزار و غیره.

پیچیدگی نرم افزار

مطالب مشابه :

مقایسه بین صفحات HTML و ASP

پیچیدگی نرم افزار

پروتکل TCP و نسخه های مختلف آن