Software architecture is designed during the early phases of the development process and it facilitates or constrains the achievement of specific functional requirements, nonfunctional requirements (quality attributes), and business goals; thus, architectural decisions are crucial to the success of a software-intensive project [Falessi et al.2007a; Hofmeister et al. 2007]. Therefore, software architects need a reliable and rigorous process for selecting architectural alternatives and ensuring that the decisions made mitigate risks and maximize profit. In our view, a good decision-making technique is one that guides the user toward better, perhaps optimal, alternatives, and, at the same time, is easy to use. The adoption of a poor decision-making technique may imply several difficulties which in turn provoke the selection of a worse alternative. For example, in complex projects, several designers may have different interests or concerns and therefore different views of the system. As a result, they adopt different vocabularies; for example they might use a single word to define a quality attribute such as performance, which means something specific to them (e.g., worst-case latency), but something different to another stakeholder (e.g., an administrator might interpret performance as the efficient use of system resources, and an end user might understand it as referring to the time it takes to learn the system). These differences in interpretation tend to cause misunderstandings [Gilb and Brodie 2005; Moore et al. 2003]. Such misunderstandings may provoke the selection of a wrong alternative, which in turn causes client dissatisfaction and eventually a major rework to satisfy the real stakeholders’ needs.

 

 

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