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

مقدمه

بدلیل تفاوت ذاتی بین نرم افزار و سخت افزار پیچیدگی خاصی در ابعاد مختلف از جمله تعریف نرم افزار، طراحی و پیاده‌سازی، تست و نگهداری آن وجود دارد كه:
با پیچیدگی سیستم‌های طبیعی و محصولات فیزیكی ساخت است بشر متفاوت است.
یك خاصیت ذاتی سیستمهای نرم افزاری بزرگ
بنابراین نمی‌توان این پیچیدگی را از بین برد بلكه باید آنرا كنترل نمود.
انواع پیچیدگی:
intelleictually intractivility (تمردپذیری و اجازه پذیرفتن برای آشفتگی):
پیچیدگی بطور ذاتی در ساخت سیستم وجود دارد، پیچیدگی ممكن است از بزرگی سیستم ، یا از واسینگیها، بدعت‌ها و پیاده‌سازی تكنولوژی و . . . بوجود آید.
Management intractivility (تمرد پذیری مدیریتی):
پیچیدگی در سازمان و فرآیند بكار گرفته شده در ساخت سیستم، ممكن است از اندازه پروژه (تعداد افردی كه در تمام جهات ساخت سیستم درگیر هستند)، وابستگیهای پروژه، فاصله جغرافیایی سیستمها و . . .  بعبارتی عوامل تولید كننده نرم افزار غیر قابل كنترل هستند چون سازمان، افراد و فرآیند هستند و ماشین نیستند كه كنترل شوند و سرمایه‌های اولیه برای تولید نرم افزار الزاماً ماشین، سرمایه و پول نیست بلكه یكسری عوامل انسانی متغیری هستند كه تحت مدیریت قرار می‌گیرند.
راهكارهای معماری
حق مشكل I : معماری نرم افزری می‌بایست سیستم را قابل هضم و بطور هوشمند قابل مدیریت بوسیله مهیا كردن تجریدی كه بدون نیاز به جزئیات، مهیا كننده مفاهیم ساده و یكسان باشند تجزیه سیستم و . . . 
حل مشكل IF : معماری نرم افزاری نمی‌بایست توسعه سیستم را آسانتر برای مدیریت بوسیله ارتقای ارتباطات، مهیا كرن بهتر با جدا كردن كار با كاهش زیاد وابستگیهای قابل مدیریت و غیره.
اما مسائل جدید پیدا شده مرتبط با تجزیه سیستم برای حل پیچیدگی بایست توسط معماری بررسی شوند.
چگونه سیستم را به قطعات بشكنیم، یك تجزیه خوب اصل از بین رفتن كوپلاژ بین مؤلفه‌ها (یا قطعات) را بوسیله واسطهای واضح و توانمند، ساده كردن بوسیله تقسیم به قطعات منتقل قابل استدلال كه دوباره می‌توانند جدا شوند، ارضا می‌كند.
آیا تمام قطعات مورد نیاز را داریم ساختار می‌بایست وظیفه مندی و یا سرویس‌های مورد نیاز سیستم را پشتیبانی كند بنابراین رفتار دینامیكی سیستم زمان طراحی معماری می‌بایست بحساب آید. همینطور می‌بایست زیربنای ضروری برای پشتیبانی این سرویس‌ها را داشته باشیم.
آیا این قطعات با هم بدرسیت كار می‌كنند؟ این موضوع واسط و رابطه‌های بین قطعات می‌باشد. اما تطابق خوبی كه جامعیت سیستم را مدیریت می كند و همچنین با شرایط سیستم كار كند زمانیكه این قطعات تركیب می‌شود خصوصیات خوب داشته باشند. مورد لزوم است.
شكل  زیر وسعت تصمیم و تأثیرات مستقیم را معین می‌كند. بخشیی از تصمیمات در حوزه محدود به توسعه‌های محلی (Local) است و اثری روی معماری ندارد و در سطح تك تك مؤلفه‌ها است و از نوع غیر معماری می‌باشد.
بخش دیگر Local نیست ولی تأثیر زیادی ندارد. از خود تقسیم‌بندی سیستماتیك و Local می‌باشد. خود سیستماتیك شامل Highimpaet می‌باشد كه ما بدنبال Highimpnet می‌باشیم