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

انواع پیچیدگی:

intelleictually intractivility (تمردپذیری و اجازه پذیرفتن برای آشفتگی):

پیچیدگی بطور ذاتی در ساخت سیستم وجود دارد، پیچیدگی ممكن است از بزرگی سیستم ، یا از واسینگیها، بدعت‌ها و پیاده‌سازی تكنولوژی و . . . بوجود آید.

Management intractivility (تمرد پذیری مدیریتی):

پیچیدگی در سازمان و فرآیند بكار گرفته شده در ساخت سیستم، ممكن است از اندازة پروژه (تعداد افردی كه در تمام جهات ساخت سیستم درگیر هستند)، وابستگیهای پروژه، فاصله جغرافیایی سیستمها و . . .  بعبارتی عوامل تولید كننده نرم افزار غیر قابل كنترل هستند چون سازمان، افراد و فرآیند هستند و ماشین نیستند كه كنترل شوند و سرمایه‌های اولیه برای تولید نرم افزار الزاماً ماشین، سرمایه و پول نیست بلكه یكسری عوامل انسانی متغیری هستند كه تحت مدیریت قرار می‌گیرند.

راهكارهای معماری

حق مشكل I : معماری نرم افزری می‌بایست سیستم را قابل هضم و بطور هوشمند قابل مدیریت بوسیله مهیا كردن تجریدی كه بدون نیاز به جزئیات، مهیا كننده مفاهیم ساده و یكسان باشند تجزیه سیستم و . . . 

حل مشكل IF : معماری نرم افزاری نمی‌بایست توسعه سیستم را آسانتر برای مدیریت بوسیله ارتقای ارتباطات، مهیا كرن بهتر با جدا كردن كار با كاهش زیاد وابستگیهای قابل مدیریت و غیره.

اما مسائل جدید پیدا شده مرتبط با تجزیه سیستم برای حل پیچیدگی بایست توسط معماری بررسی شوند.

چگونه سیستم را به قطعات بشكنیم، یك تجزیه خوب اصل از بین رفتن كوپلاژ بین مؤلفه‌ها (یا قطعات) را بوسیله واسطهای واضح و توانمند، ساده كردن بوسیله تقسیم به قطعات منتقل قابل استدلال كه دوباره می‌توانند جدا شوند، ارضا می‌كند.

آیا تمام قطعات مورد نیاز را داریم ساختار می‌بایست وظیفه مندی و یا سرویس‌های مورد نیاز سیستم را پشتیبانی كند بنابراین رفتار دینامیكی سیستم زمان طراحی معماری می‌بایست بحساب آید. همینطور می‌بایست زیربنای ضروری برای پشتیبانی این سرویس‌ها را داشته باشیم.

آیا این قطعات با هم بدرسیت كار می‌كنند؟ این موضوع واسط و رابطه‌های بین قطعات می‌باشد. اما تطابق خوبی كه جامعیت سیستم را مدیریت می كند و همچنین با شرایط سیستم كار كند زمانیكه این قطعات تركیب می‌شود خصوصیات خوب داشته باشند.