حملات ناخواسته و اشتباهات امنیتی کاربران جلوگیری کند. روال‌ها، هشدارها و راهنماهای امنیتی با توجه به ویژگی‌های فیزیکی، شناختی، نگرشی و میزان مهارت، دانش و تجربه کاربران طراحی می‌شود. میزان توانایی کاربران و ویژگی‌های فیزیکی آنها روی روش حملات آنها و شیوه اعلام هشدارها و راهنماهای امنیتی تأثیر گذار خواهد بود. تمهیدات امنیتی اعمال شده برای خبرگان امنیت و کاربرانی که میزان مهارت، دانش و تجربه کمی در زمینه امنیت دارند نیز متفاوت خواهد بود. نوع فرهنگ و ویژگی‌های نگرشی کاربران نیز در طراحی تمهیدات امنیتی بی تأثیر نیست.
یکی از روش‌های شناسایی و مدیریت حملات امنیتی، استفاده از موارد سوء کاربرد و نوشتن سناریو‌های متناظر با آنها است که به تفصیل در فصل قبل، به بررسی آنها پرداخته شده‌است. هر منبع ممکن است از طریق چند سوء کاربرد مورد حمله قرار گیرد. هر سوء کاربرد شامل مراحلی است که ممکن است به سیستم آسیب برساند و در مقابل یک مورد کاربرد عادی سیستم قرار می‌گیرد و آن را نقض می‌کند. در حقیقت هر سوء کاربرد روی یک مورد کاربرد تأثیر دارد و روند عادی مورد کاربرد را نقض می‌کند.
با بررسی این موارد می‌توان راه حل‌های مبارزه با موارد سوء مصرف را در طراحی امنیت درنظر گرفت. استخراج نیازمندی‌های امنیتی هر یک از دارایی‌ها، از طریق قضاوت شرکت کنندگان در جلسات تصمیم گیری ذینفعان و با توجه به ویژگی‌های امنیتی که در بالا تعریف شد، بدست می‌آید.
ویژگی‌های امنیتی هر یک از منابع باید شناسایی شده و سپس طبقه بندی شوند. ما استفاده از یک سیستم طبقه بندی کیفی بر اساس زبان طبیعی که انعطاف لازم در طبقه بندی دارایی‌ها را داراست پیشنهاد می‌دهیم. البته پذیرش یک سیستم طبقه بندی کمی نیز امکان پذیر است.
رویکرد کیفی به شرکت کنندگان اجازه استفاده از کلمات خودشان را برای تعریف میزان اهمیت دارایی می‌دهد و به وسیله رتبه بندی نتایج به صورت سلسله مراتبی، تفکیک ویژگی‌های امنیتی مهم برای
دارایی‌ها می‌تواند شناسایی شود.
تجربه نشان داده که سناریوها در فهماندن اینکه ویژگی‌های امنیتی به چه معنا است مفید هستند اما در فهماندن میزان اهمیت آن دارایی، مفید نیست. سناریوهای مختلف باید تا حد امکان به فرم موارد سوءمصرف مستند شوند.
همه پروسه‌های سیستم باید شرح داده شوند بنابراین خبرگان قابلیت کاربری و پیاده سازان سیستم باید باهم همکاری داشته باشند تا مطمئن شوند پروسه‌ها روی قابلیت کاربری و امنیت سیستم اثر منفی نداشته باشد.
قابلیت کاربری به سرعت سیستم در انتخاب مکانیزم‌های امنیتی نیز وابسته است. تعداد گام‌های تعامل کاربر با مکانیزم‌های امنیتی روی قابلیت کاربری ابزار اثر دارد. پیشنهادهای رابط کاربری باید بدون اتکا به مکانیزم‌های امنیتی پیچیده و خلاصه در نظر گرفته شود.
طراحی و پیاده سازی معماری امنیت باید براساس استراتژی امنیت باشد. با اینحال بالاترین سطح امنیت قابل دسترس باید با توجه به نیازهای کاربر پیاده سازی شود. بنابراین پیشنهاد می‌شود تا کاربران هدف به فاز پیاده سازی و طراحی برای اجتناب از اشتباه فهمیدن، هرچه زودتر توجه کنند.
اهداف امنیتی باید کاملاً با روند اهداف اصلی برای ایجاد امنیت ضمنی یکپارچه باشد. استخراج اطلاعات در مورد استثناهای امنیتی تعامل نرمال کاربر با رابط کاربری، ما را برای به حداقل رساندن یا کاهش نیاز به وظایف امنیتی ثانویه توانا می‌سازد.
افزودن امنیت در انتهای کار، معمولاً به ندرت مؤثر است و به قابلیت کاربری ضرر می‌رساند. در نظر گرفتن نیازهای کاربران باعث داشتن کاربرانی می‌شود که سهوا با سطوح امنیتی ابزار امنیتی مصالحه نمی‌کنند و از ارتباط خود با مکانیزم‌های امنیتی آگاه هستند. با توجه به توضیحات داده شده، می‌توان از
مدل زیر برای آنالیز ریسک و استخراج نیازمندی‌های امنیتی استفاده کرد.
شکل ۴ – ۳ – مدل آنالیز ریسک

طراحی نمونه آزمایشی و تست و ارزیابی آن

تنها بعد از آنکه کاربران فرصتی برای دیدن و ایجاد بازخورد روی مدل‌ها با استفاده از نمونه آزمایشی داشته باشند، می‌توانند در مورد سیستم اظهار نظر کنند. طراحی رابط کاربری می‌تواند بر اساس بازخورد واقعی کاربران تنظیم شده باشد و تکنیک‌های نمونه آزمایشی نیز همواره می‌تواند کمک کند.
نیازمندی‌ها، می‌تواند پس از نمونه آزمایشی دوباره ارزیابی شود که باعث می‌شود نیازمندی‌ها، بیشتر در نظر گرفته شده، شناسایی شود و رضایت کاربران را جلب کنند. نمونه آزمایشی خام و شبیه سازی سیستم برای جلوگیری از طراحی تکراری، لازم است. اگرچه رنجی از روش‌های نمونه آزمایشی، توصیف شده‌اند، هدف به کارگیری همه آنها نیست. پروسه نمونه آزمایشی تکراری، نیازمند ویژگی‌های نمونه آزمایشی است و باید نیازمندی‌های کلیدی و طبیعت مشکلات شناسایی شده را خطاب قرار دهد و تغییرات به درستی مستند شده باشد، که اجازه می‌دهد تا راه حل تکراری، مناسب مدیریت شده باشد.
یک تفاوت نمونه آزمایشی کاغذ محور، ضبط ویدئویی تست رابط کاربری به عنوان عنصری که توسط اعضای تیم طراحی حذف شده و تغییر می‌یابد است و گاهی به آن نمونه آزمایشی ویدئویی^[۲۶۹] گویند. کاربران نهایی، تعامل مستقیمی با نمونه آزمایشی کاغذ محور ندارند. اما بعد می‌توانند ارائه ویدئویی را ببینند. این رویکرد می‌تواند برای توضیح طرح کلی رابط کاربری و جایگزین‌های ایستا مفی

د باشد.
این رویکرد برای نمونه آزمایشی کردن، از شبیه سازی کامپیوتری برای فراهم کردن مدل واقع گرایانه از سیستم استفاده می‌کنند. این روش واقع گرایی بیشتری نسبت به روش قبل دارد.
این روش می‌تواند توسط شبیه سازی محیط کاری و نمونه آزمایشی کردن ارتباطات و روال اطلاعات میان کاربران و نقش‌های مختلف به وجود آید. نقش‌ها ممکن به وسیله کاربران نهایی آینده، اعضای تیم طراحی و مشتریان پر شود. نمونه آزمایشی سیستم‌های کامپیوتری ممکن است استفاده شده باشد، اگرچه ممکن است در مراحل ابتدایی لازم نباشد.
خبرگان با آشنایی با ویژگی‌های کاربر، طبیعت کار و محیط کاربری از طریق بحث با تیم طراحی و یا نمایندگان کاربران شروع به کار می‌کنند. سپس نمونه آزمایشی یا توصیف سیستم را مطالعه خواهند کرد. آنها ممکن است سیستم را با توجه به اصول یا رهنمودهای بنا نهاده شده، ارزیابی کنند و آنها را به ترتیب اولویت دسته بندی می‌کنند. برتری اصلی سنجش ارزیاب این است که‌این روش سریع و راحت برای بدست آوردن بازخورد و پیشنهاد است و عیب آن این است که خبرگان معمولاً تمایل شخصی به ویژگی‌های طراحی ویژه‌ای دارند.

طراحی رابط کاربری و اقدامات امنیتی

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

پیاده سازی سیستم

در این فاز، با استفاده از تکنیک‌های مختلف پیاده سازی سیستم‌های نرم افزاری و متناسب با نیازمندی‌های مختلف عملیاتی و امنیتی، اقدام به پیاده سازی سیستم می‌شود.

تست و ارزیابی محصول نهایی

هدف از تست وارزیابی یافتن مشکلات قابلیت کاربری در طراحی است. اگرچه تعدادی از روش‌ها، مسائلی شبیه به دقت مشکلات قابلیت کاربری را در سراسر طراحی خطاب قرار می‌دهند.
تعداد زیادی از روش‌های ارزیابی خود را به ارزیابی رابط کاربری معطوف کرده‌اند که لزوماً نباید پیاده سازی شده باشد که بدین معنی است که مهندسی قابلیت کاربری می‌تواند در مراحل ابتدایی چرخه
حیات انجام شود.
معماری سیستم و رابط کاربری می‌تواند جداگانه با روش‌های مخصوص به خود تست شود. در یک پروسه تکراری هر دو تست می‌شوند تا برای اینکه با هم قرار گیرند آماده شوند.
ممکن است هدف بدست آوردن داده‌های متریک باشد. در این مورد محیط کاری جهان واقعی و محصول پیاده سازی شده تا جای ممکن شبیه سازی می‌شود.
برای فهمیدن اینکه چگونه کاربران موفق با کارکردن کلی سیستم خواهد بود، تست کاربر کنترل شده مورد نیاز است. این تست می‌تواند برای ارزیابی اینکه آیا نیازمندی‌های قابلیت کاربری بدست آمده مثلاً با اندازه‌گیری‌های زیر استفاده شود: رضایت، بهره وری، اثربخشی
تست کاربر محور، می‌تواند در محیط آزمایشگاهی کنترل شده یا در محل کار کاربر انجام شود. هدف جمع آوری اطلاعات در مورد کارایی کاربر، نظرات کاربر و عکس‌العمل آن بعد از تست و مشاهدات ارزیاب‌ها است.
آنالیز‌های مطالعات قابلیت کاربری اخیر (نلسون^[۲۷۰] و لنداور^[۲۷۱]، ۱۹۹۳) نشان می‌دهند که ۸۵% از مشکلات قابلیت کاربری می‌توانند توسط تست ۵-۸ نفر شناسایی شوند. اگرچه تحقیقات اخیر (اسپول^[۲۷۲] و اسچرودر^[۲۷۳]، ۲۰۰۱) نشان می‌دهد که برای سیستم‌های پیچیده، این تعداد کاربر کم است.

تحویل به مشتری