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

مقیاس به تنهایی مسأله نیست. اگر ساختار سیستم با قاعده باشد بصورت تحلیلی تعیین می‏شود و اگر تعداد اجزاء

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

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

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

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

 

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

عملکردِ ضروری از نیازمندی‏ها بر می‏خیزد و در حقیقت ماهیت آنچه سیستم باید انجام دهد را مشخص می‏کند

 و می‏تواند مثلاً از سخت‏افزار به نرم‏افزار منتقل شود ولی نمی‏تواند حذف شود مگر با حذف نیازمندی‏های غیر ضروری.

پیچیدگی ضروری ذاتی و غیر قابل اجتناب است و در حقیقت از چیزی که سیستم باید انجام دهد ناشی می‏شود.

 پیچیدگی ذاتی با پیچیدگی الگوریتم سر و کار دارد و به مدل محاسباتی استفاده شده برای حلّ مسأله وابسته است

 که به صورت کمینه، پیچیدگی در بین تمام الگوریتم‏هایی که به‏عنوان راه‏حل ارائه  شده‏اند، تعریف می‏شود. پیچیدگی

 ذاتی عموماً، برحسب زمان و فضای مورد نیاز برای اجرا اندازه‏گیری می‏شود. کیفیت و کارایی طراحی و هزینه‏ی کلّی

 پروژه در بهترین حالت از طریق پیچیدگی ذاتی تعیین می‏شود. امّا پیچیدگی عارضی از برنامه‏های کامپیوتری یا از فرایند

 توسعه (برنامه‏نویسی کامپیوتری) یا از انتخاب‏های صورت گرفته در ساخت یک سیستم ناشی می‏شود مثلاً از معماری

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

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

 بهترین راه برای مقابله با پیچیدگی این است که ابتدا مسأله (چه چیز) را درست تعریف کنیم سپس دنبال ایجاد یا انتخاب

 راه حلی (چگونگی) مناسب برای حلّ مسأله باشیم. این  نوع پیچیدگی با توسعه سیستم سر و کار دارد و شامل

 ویژگی‏هایی نظیر اندازه‏ی سیستم، تعداد پیمانه‏ها، تعداد توابع در درون سیستم و اتّصال بین پیمانه‏ها می‏باشد.

 

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

 بدیهی است که بزرگترین موضوع پیچیدگی ضروری مهندسی نیازها و تحلیل است. امّا، در پیچیدگی عارضی

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

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

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

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

 با افزایش پیچیدگی ضروری افزایش یابد.

 

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

 

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

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

این نوع از پیچیدگی اساساً، در مراحل توسعه نرم‏افزار بعد از فاز نیازمندیها در فازهای طراحی و تولید

 کد ایجاد می‏شود. این نوع دسته بندیها به مهندسان نرم‏افزار کمک می‏کند تا تعیین کنند که کی و

 چگونه پیچیدگی وارد پروژه می‏شود، همچنین آگاه می‏شوند که روی کدام مرحله‏ از چرخه حیات

 نرم‏افزار باید تمرکز کنند تا قادر باشند پیچیدگی نرم‏افزار را کنترل و کاهش دهند. این پیچیدگی با

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

مورد نیاز برای یک راه‏حل بهینه برای مسأله تعریف کرد، پس پیچیدگی یک راه‏حل می‏تواند بصورت

 منابع مورد نیاز برای پیاده‏سازی یک راه‏حل خاص درنظر گرفته ‏شود. این منابع از دو جنبه بررسی

 می‏شود زمان، بعنوان مثال زمان کامپیوتر و ساعات پرسنل و فضا بعنوان مثال حافظه کامیپوتر،

پشتیبانی نرم‏افزار و غیره..