اکنون که الزامات عملکردی و همچنین نحوه ثبت و تجسم آنها را به طور کامل بررسی کردیم، اجازه دهید نوع بعدی نیازمندی ها، ویژگی های کیفیت، که به عنوان نیازمندی های غیرعملکردی شناخته می شوند را گسترش دهیم.
این نوع الزامات تأثیر مستقیمی بر معماری نرم افزار دارد.
پس بیایید با کمی انگیزه و تعریف رسمی از ویژگی کیفیت شروع کنیم.
مطالعات نشان داده‌اند که سیستم‌ها اغلب بازطراحی و بازسازی می‌شوند، عمدتاً نه به این دلیل که از نظر عملکردی ناقص هستند یا به دلیل نیازهای عملکردی جدید، بلکه به این دلیل که سیستم موجود، همانطور که مطرح می‌شود، یا به اندازه کافی سریع نیست، نمی‌تواند به اندازه کافی مقیاس پذیر باشد. افزایش تعداد کاربران یا حجم داده ها یا ساختار سیستم توسعه، نگهداری یا امنیت را بسیار سخت می کند.
و در بیشتر موارد، پس از چنین طراحی مجدد بزرگ، سیستم یا معادل یا دقیقاً همان عملکرد قبلی را ارائه می دهد.بنابراین، معماری سیستم خود به گونه‌ای که از همان ابتدا ویژگی‌های کیفیت مناسب را در اختیار ما قرار دهد، برای جلوگیری از طراحی‌های مجدد بزرگ بسیار مهم است.
مشخصه های کیفیت سیستم
ویژگی‌های کیفیت، نیازمندی‌های غیرعملکردی هستند که ویژگی‌های کلی سیستم را توصیف می‌کنند.به عبارت دیگر، ویژگی‌های کیفیت نمی‌گویند که سیستم چه کاری انجام می‌دهد، اما در عوض، معیاری برای سنجش کیفیت عملکرد سیستم ما در یک بعد خاص ارائه می‌کنند.
و همانطور که قبلا ذکر کردیم، ویژگی های کیفیت با معماری سیستم ارتباط مستقیم دارند.
بیایید نمونه ای از یک فروشگاه آنلاین را در نظر بگیریم که در آن کاربران می توانند محصولات را بر اساس برخی کلمات کلیدی جستجو کنند.
بنابراین یک نیاز کلی ممکن است این باشد که وقتی کاربر پس از تایپ کلمات کلیدی، روی دکمه جستجو کلیک می‌کند، فهرستی از محصولات در حداکثر 100 میلی‌ثانیه به کاربر ارائه می‌شود.
بنابراین، نیاز عملکردی، اقدامی است که سیستم ما هنگام کلیک کردن کاربر روی دکمه جستجو انجام می‌دهد، و ویژگی کیفیت، در این مورد، در بعد عملکرد، سرعت انجام این عمل را توصیف می‌کند.
مثال دیگری که به یک نیاز کاربردی خاص وابسته نیست، بلکه به کل سیستم ما مربوط می شود، این است که فروشگاه آنلاین ما باید حداقل در 99.9٪ مواقع در دسترس کاربران باشد.
بنابراین در این حالت، این ویژگی کیفیت در بعد در دسترس بودن است.
بیایید یکی دیگر از الزامات کیفیت را در نظر بگیریم، این است که تیم توسعه ما می‌تواند نسخه جدیدی از فروشگاه آنلاین ما را حداقل دو بار در هفته راه‌اندازی کند.
این ویژگی همچنین به کل سیستم ما مربوط می شود و نحوه عملکرد سیستم ما در بعد قابلیت استقرار را توصیف می کند.
بنابراین، اکنون که شهودی برای ویژگی‌های کیفیت سیستم به دست آوردیم، اجازه دهید در مورد طراحی یک سیستم نرم‌افزاری به طور کلی چند ملاحظات بسیار مهم در مورد ویژگی‌های کیفیت بحث کنیم.
یکی از مهم ترین ملاحظات در مورد ویژگی های کیفیت این است که آنها باید قابل اندازه گیری و آزمایش باشند.
اگر نتوانیم به طور عینی اندازه گیری کنیم و به طور مداوم آزمایش کنیم تا ثابت کنیم که سیستم ما ویژگی های کیفی مورد نیاز را برآورده می کند، در واقع نمی توانیم بدانیم که آیا سیستم ما نسبت به آن نیاز عملکرد خوبی دارد یا ضعیف.
به عنوان مثال، اگر نیازی که دریافت می کنیم زمانی است که کاربر روی دکمه خرید کلیک می کند، تأیید خرید باید به سرعت به کاربر نمایش داده شود.
حال اگر سیستمی را طوری طراحی کنیم که در عرض 200 میلی ثانیه تایید را نمایش دهد اکنون، از آنجایی که نمی‌توانیم معنی واقعی کلمه را بسنجیم، نمی‌توانیم بدانیم که 200 میلی‌ثانیه خوب است یا بد.
دومین نکته مهم این است که هیچ معماری واحدی وجود ندارد که بتواند تمام ویژگی های کیفیت را ارائه دهد.
اساساً، اگر چنین معماری وجود داشت، همه از آن برای هر سیستمی استفاده می کردند و شغل یک معمار نرم افزار وجود نداشت.
دلیل غیرممکن بودن آن این است که برخی از ویژگی های کیفیت با یکدیگر در تضاد هستند، بنابراین برخی از ترکیبات ویژگی های کیفیت یا بسیار سخت به دست می آیند یا حتی غیرممکن هستند.
به همین دلیل است که وظیفه ما به عنوان معماران نرم افزار این است که معاوضه درستی انجام دهیم، برخی از ویژگی های کیفیت را بر سایرین ترجیح دهیم و سیستم را به گونه ای طراحی کنیم که بر اساس الزامات کسب و کار بیشترین شانس را برای موفقیت به ما بدهد.
successful
به عنوان مثال، ممکن است دو الزام متناقض برای صفحه ورود به سیستم (Login Page) خود داشته باشیم:
- یکی از الزامات بیان می کند که کاربر باید خیلی سریع به سیستم ما وارد شود، ترجیحاً کمتر از یک ثانیه.
- شرط دیگر به ما می گوید که برای محافظت از حساب کاربر، امنیت را فراهم کنیم.این مستلزم آن است که کاربر برای ورود به سیستم، باید رمز عبور را وارد کند و بعد از آن Google authenticator و یا OTP ارسال گردد اما اتصال به google authenticator و یا ارسال OTP ممکن است پروسه ورود به حساب کاربری را کندتر کند، که مستقیماً در تضاد با اولین نیاز برای انجام سریعترین فرآیند ورود است.
امکان سنجی الزامات سیستم
سومین نکته مهم در خصوص ویژگی های کیفی، امکان سنجی الزامات آنهاست.این به ما، طراحان سیستم بستگی دارد که مطمئن شویم سیستمی که می‌خواهیم طراحی کنیم، قادر است آنچه را که مشتری درخواست می‌کند، ارائه دهد.
در برخی موارد، چون مشتری فنی نیست، ممکن است چیزی بخواهد که یا از نظر فنی غیرممکن است یا اجرای آن بسیار پرهزینه است، و وظیفه ما این است که در مراحل اولیه آن را اعلام کنیم.
یکی از نمونه‌های یک نیاز غیرقابل اجرا، انتظارات غیرواقعی تأخیر کم است.
- به عنوان مثال، اگر تأخیر شبکه بین یک کلاینت در آمریکای جنوبی و نزدیک‌ترین مرکز داده که سیستم خود را در شرق ایالات متحده در آنجا اجرا می‌کنیم، بین 100 یا 150 میلی‌ثانیه باشد، نمی‌توانیم بارگذاری صفحه را کمتر از 100 میلی‌ثانیه تضمین کنیم. در واقع، ما حتی نمی‌توانیم تاخیری نزدیک به آن را تضمین کنیم، زیرا بارگیری یک صفحه با استفاده از HTTP به چندین سفر رفت و برگشت به عنوان بخشی از پروتکل آن و همچنین بارگیری بالقوه دارایی‌های متعدد نیاز دارد.
- مثال دیگر می تواند الزامی برای در دسترس بودن 100٪ سیستم باشد. این اساساً به این معنی است که سیستم ما هرگز نمی تواند از کار بیفتد و ما هرگز فرصتی برای حذف آن برای تعمیر و نگهداری یا ارتقاء نخواهیم داشت.
- نمونه‌های دیگر از الزامات غیرقابل اجرا می‌تواند محافظت کامل در برابر هکرها، پخش فیلم‌های با وضوح بالا در مناطقی که پهنای باند اجازه آن را نمی‌دهد، یا الزام سیستم ما برای افزایش ظرفیت ذخیره‌سازی با سرعت غیرمنطقی باشد.
بنابراین، قبل از تأیید یک نیاز، حتی ممکن است لازم باشد با افراد دارای تخصص دامنه مشورت کنیم تا مطمئن شویم که واقعاً می توانیم آنچه را که قول داده ایم انجام دهیم.
