View in Telegram
Microfrontend.ir
به محض اینکه صحبت از کاهش هزینه‌ها می‌شود، مدیر پروژه می‌پرسد: «آیا واقعاً به این نیاز داریم؟» و برای «این» هر چیز مهم و ضروری که در سیستم لازم است، جایگزین می‌شود؛ از جمله مجوزهای نرم‌افزاری، سرورهای اضافی، پشتیبان‌گیری‌های خارج از سایت یا منابع برق.   در…
تعریف دقیق نیازمندی‌ها در معماری نرم‌افزار حیاتی و عباراتی مانند «سریع»، «پاسخگو» یا «قابل گسترش» به خودی خود کافی نیستند؛ زیرا معیاری برای سنجش آن‌ها وجود ندارد. با این حال، کاربران همچنان این ویژگی‌ها را می‌خواهند. نقش معمار این است که این ویژگی‌ها را تا حد امکان فراهم کرده و بین تضادهای احتمالی آن‌ها تعادل ایجاد کند.
 
اگر این نیازها به‌طور مشخص و قابل اندازه‌گیری بیان نشوند، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود نخواهد داشت و راهنمایی ارزشمندی از مهندسان در حین کار گرفته می‌شود. در نتیجه، معماران باید تلاش کنند این نیازها را با سوالاتی مانند «چقدر؟»، «در چه مدت زمانی؟»، «چند بار؟»، «چقدر سریع؟» و غیره به مقادیر دقیق تبدیل کنند. اگر این اطلاعات در برنامه تجاری سیستم نیست، باید علت آن را جستجو کرد و آن‌ها را دریافت.
 
همچنین باید نیازمندی‌های نامشخص را به‌صورت محدوده‌ای تعریف کرد: حداقل، مطلوب، و حداکثر. اگر این محدوده‌ها مشخص نشوند، یعنی رفتار مورد نظر سیستم به‌درستی درک نشده است. این کار ممکن است وقت‌گیر و هزینه‌بر باشد، اما اگر هیچ‌کس به‌اندازه کافی به عملکرد اهمیت ندهد که هزینه تست‌های عملکرد را بپردازد، احتمالاً عملکرد مهم نیست و می‌توان روی جنبه‌های دیگر تمرکز کرد.
 
برای مثال، نیازمندی‌هایی مثل: «باید به ورودی کاربر در حداکثر ۱۵۰۰ میلی‌ثانیه پاسخ دهد. تحت بار عادی (تعریف شده به‌عنوان...) زمان پاسخگویی بین ۷۵۰ تا ۱۲۵۰ میلی‌ثانیه باشد. پاسخگویی زیر ۵۰۰ میلی‌ثانیه توسط کاربر قابل تشخیص نیست، بنابراین برای کمتر از این مقدار هزینه نخواهیم کرد»، نیازمندی‌های واقعی هستند.  ‏"نیازمندی‌هایی مثل 'سریع' و 'قابل گسترش' بدون معیار مشخص بی‌فایده‌اند. برای تعریف درست، اعداد و محدوده‌ها را مشخص کنید: چقدر سریع؟ چند کاربر؟ چه زمانی؟ اگر برای تست عملکرد هزینه نمی‌شود، شاید اصلاً مهم نباشد."
#TIP-10

〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
Telegram Center
Telegram Center
Channel