ویژگی‌های امنیتی به چه معنا است مفید هستند اما در فهماندن میزان اهمیت آن دارایی، مفید نیست. سناریوهای مختلف باید تا حد امکان به فرم موارد سوءمصرف مستند شوند.
همه پروسه‌های سیستم باید شرح داده شوند بنابراین خبرگان قابلیت کاربری و پیاده سازان سیستم باید باهم همکاری داشته باشند تا مطمئن شوند پروسه‌ها روی قابلیت کاربری و امنیت سیستم اثر منفی نداشته باشد.
قابلیت کاربری به سرعت سیستم در انتخاب مکانیزم‌های امنیتی نیز وابسته است. تعداد گام‌های تعامل کاربر با مکانیزم‌های امنیتی روی قابلیت کاربری ابزار اثر دارد. پیشنهادهای رابط کاربری باید بدون اتکا به مکانیزم‌های امنیتی پیچیده و خلاصه در نظر گرفته شود.
طراحی و پیاده سازی معماری امنیت باید براساس استراتژی امنیت باشد. با اینحال بالاترین سطح امنیت قابل دسترس باید با توجه به نیازهای کاربر پیاده سازی شود. بنابراین پیشنهاد می‌شود تا کاربران هدف به فاز پیاده سازی و طراحی برای اجتناب از اشتباه فهمیدن، هرچه زودتر توجه کنند.
اهداف امنیتی باید کاملاً با روند اهداف اصلی برای ایجاد امنیت ضمنی یکپارچه باشد. استخراج اطلاعات در مورد استثناهای امنیتی تعامل نرمال کاربر با رابط کاربری، ما را برای به حداقل رساندن یا کاهش نیاز به وظایف امنیتی ثانویه توانا می‌سازد.
افزودن امنیت در انتهای کار، معمولاً به ندرت مؤثر است و به قابلیت کاربری ضرر می‌رساند. در نظر گرفتن نيازهاي كاربران باعث داشتن كاربراني می‌شود كه سهوا با سطوح امنيتي ابزار امنيتي مصالحه نمی‌کنند و از ارتباط خود با مکانیزم‌های امنیتی آگاه هستند. با توجه به توضیحات داده شده، می‌توان از
مدل زیر برای آنالیز ریسک و استخراج نیازمندی‌های امنیتی استفاده کرد.
شکل 4 – 3 – مدل آنالیز ریسک
4-5- طراحی نمونه آزمایشی و تست و ارزیابی آن
تنها بعد از آنکه کاربران فرصتی برای دیدن و ایجاد بازخورد روی مدل‌ها با استفاده از نمونه آزمایشی داشته باشند، می‌توانند در مورد سیستم اظهار نظر کنند. طراحی رابط کاربری می‌تواند بر اساس بازخورد واقعی کاربران تنظیم شده باشد و تکنیک‌های نمونه آزمایشی نیز همواره می‌تواند کمک کند.
نیازمندی‌ها، می‌تواند پس از نمونه آزمایشی دوباره ارزیابی شود که باعث می‌شود نیازمندی‌ها، بیشتر در نظر گرفته شده، شناسایی شود و رضایت کاربران را جلب کنند. نمونه آزمایشی خام و شبیه سازی سیستم برای جلوگیری از طراحی تکراری، لازم است. اگرچه رنجی از روش‌های نمونه آزمایشی، توصیف شده‌اند، هدف به کارگیری همه آنها نیست. پروسه نمونه آزمایشی تکراری، نیازمند ویژگی‌های نمونه آزمایشی است و باید نیازمندی‌های کلیدی و طبیعت مشکلات شناسایی شده را خطاب قرار دهد و تغییرات به درستی مستند شده باشد، که اجازه می‌دهد تا راه حل تکراری، مناسب مدیریت شده باشد.
یک تفاوت نمونه آزمایشی کاغذ محور، ضبط ویدئویی تست رابط کاربری به عنوان عنصری که توسط اعضای تیم طراحی حذف شده و تغییر می‌یابد است و گاهی به آن نمونه آزمایشی ویدئویی269 گویند. کاربران نهایی، تعامل مستقیمی با نمونه آزمایشی کاغذ محور ندارند. اما بعد می‌توانند ارائه ویدئویی را ببینند. این رویکرد می‌تواند برای توضیح طرح کلی رابط کاربری و جایگزین‌های ایستا مفید باشد.
این رویکرد برای نمونه آزمایشی کردن، از شبیه سازی کامپیوتری برای فراهم کردن مدل واقع گرایانه از سیستم استفاده می‌کنند. این روش واقع گرایی بیشتری نسبت به روش قبل دارد.
این روش می‌تواند توسط شبیه سازی محیط کاری و نمونه آزمایشی کردن ارتباطات و روال اطلاعات میان کاربران و نقش‌های مختلف به وجود آید. نقش‌ها ممکن به وسیله کاربران نهایی آینده، اعضای تیم طراحی و مشتریان پر شود. نمونه آزمایشی سیستم‌های کامپیوتری ممکن است استفاده شده باشد، اگرچه ممکن است در مراحل ابتدایی لازم نباشد.
خبرگان با آشنایی با ویژگی‌های کاربر، طبیعت کار و محیط کاربری از طریق بحث با تیم طراحی و یا نمایندگان کاربران شروع به کار می‌کنند. سپس نمونه آزمایشی یا توصیف سیستم را مطالعه خواهند کرد. آنها ممکن است سیستم را با توجه به اصول یا رهنمودهای بنا نهاده شده، ارزیابی کنند و آنها را به ترتیب اولویت دسته بندی می‌کنند. برتری اصلی سنجش ارزیاب این است که‌این روش سریع و راحت برای بدست آوردن بازخورد و پیشنهاد است و عیب آن این است که خبرگان معمولاً تمایل شخصی به ویژگی‌های طراحی ویژه‌ای دارند.
4-6- طراحی رابط کاربری و اقدامات امنیتی
طوفان ذهنی، مجموعه‌ای از خبرگان طراحی و وظیفه را دور هم جمع می‌کند، تا الهام بخش یکدیگر در فاز تولید ایده و پروسه حل مشکل باشد. طوفان ذهنی، به ویژه در فاز طراحی، زمانیکه مقدار کمی از طراحی واقعی شناخته شده و نیاز به ایده جدیدی وجود دارد، مفید است. اغلب برای طراحی مفاهیم سیستمی، جلسات طراحی موازی که در آن طراحان مختلف طراحی‌های ممکن را ایجاد می‌کنند، مفید است.
در استفاده از این رویکرد، چندین گروه کوچک طراحی به صورت مستقل کار می‌کنند و هدف از آن
برنامه نویسی و ارزیابی ایده‌های سیستمی متفاوت قبل از تنظیم یک راه حل یکتا است. اما مهندسي قابليت كاربري بر روش طراحي رابط كاربري تمركز دارد و روي تعامل و اثر تعامل روي پروسه طراحي معماري امنيت و پياده سازي آن توجه ندارد و اگر اين پروسه از نظر عمليات امنيتي مناسب نباشد، کاربرپسندی رابط كاربري از ميان می‌رود و با توجه به ویژگی‌های منحصر به فرد امنيت، مهندسي قابليت كاربري براي آن خيلي كلي است.
4-7- پیاده سازی سیستم
در این فاز، با استفاده از تکنیک‌های مختلف پیاده سازی سیستم‌های نرم افزاری و متناسب با نیازمندی‌های مختلف عملیاتی و امنیتی، اقدام به پیاده سازی سیستم می‌شود.
4-8- تست و ارزیابی محصول نهایی
هدف از تست وارزیابی یافتن مشکلات قابلیت کاربری در طراحی است. اگرچه تعدادی از روش‌ها، مسائلی شبیه به دقت مشکلات قابلیت کاربری را در سراسر طراحی خطاب قرار می‌دهند.
تعداد زیادی از روش‌های ارزیابی خود را به ارزیابی رابط کاربری معطوف کرده‌اند که لزوماً نباید پیاده سازی شده باشد که بدین معنی است که مهندسی قابلیت کاربری می‌تواند در مراحل ابتدایی چرخه
حیات انجام شود.
معماری سیستم و رابط کاربری می‌تواند جداگانه با روش‌های مخصوص به خود تست شود. در یک پروسه تکراری هر دو تست می‌شوند تا برای اینکه با هم قرار گیرند آماده شوند.
ممکن است هدف بدست آوردن داده‌های متریک باشد. در این مورد محیط کاری جهان واقعی و محصول پیاده سازی شده تا جای ممکن شبیه سازی می‌شود.
برای فهمیدن اینکه چگونه کاربران موفق با کارکردن کلی سیستم خواهد بود، تست کاربر کنترل شده مورد نیاز است. این تست می‌تواند برای ارزیابی اینکه آیا نیازمندی‌های قابلیت کاربری بدست آمده مثلاً با اندازه‌گیری‌های زیر استفاده شود: رضایت، بهره وری، اثربخشی
تست کاربر محور، می‌تواند در محیط آزمایشگاهی کنترل شده یا در محل کار کاربر انجام شود. هدف جمع آوری اطلاعات در مورد کارایی کاربر، نظرات کاربر و عکس‌العمل آن بعد از تست و مشاهدات ارزیاب‌ها است.
آنالیز‌های مطالعات قابلیت کاربری اخیر (نلسون270 و لنداور271، 1993) نشان می‌دهند که 85% از مشکلات قابلیت کاربری می‌توانند توسط تست 5-8 نفر شناسایی شوند. اگرچه تحقیقات اخیر (اسپول272 و اسچرودر273، 2001) نشان می‌دهد که برای سیستم‌های پیچیده، این تعداد کاربر کم است.
4-9- تحویل به مشتری
تحویل به مشتری، مرحله بسیار مهمی در این پروسه است. در حقیقیت، اگر محصول به صورت مناسب به مشتری تحویل داده نشود و ویژگی ها و امکانات آن به مشتری به نفضیل ارائه نشود، زحمات پروسه تولید نرم افزار از ابتدا تا انتها، به هدر می رود. برای تحویل مناسب به مشتری، روش های مختلفی مانند ارائه راهنمای کاربری و برگزاری جلسات مختلف با ذینفعان و کاربران سیستم وجود دارد.
راهنماهای کاربری ارائه شده، باید با تغییر در محصول، به روز رسانی شود. در جلسات تحویل به مشتری، باید همه ویژگی ها و جنبه های مختلف سیستم به طور کامل برای مشتری شرح داده شود تا به طور کامل توسط او قابل استفاده باشد. البته این آخرین مرحله از پروسه تولید نرم افزار و انتهای عمر محصول نیست. بازخوردهای دیگری در طول استفاده از محصول در محیط مشتری به وجود خواهد آمد که منجر به تست دوباره محصول و تغییر در آن و یا ایجاد ویژگی های جدید می شود. در نتیجه، محصولی پویا که با توجه به نیازهای جدید مشتری به روز می شودخواهیم داشت. البته فراموش نشود که میزان تغییرات محصول، به نحوه پیاده سازی سیستم و زیرساخت آن نیز بستگی دارد.
4-10- جمع بندی
در این فصل با توجه به مطالعات انجام شده در فصل ادبیات موضوعی و تجربیات به دست آمده، مدلی ارائه شد که ابتدا مراحل مختلف تولید نرم افزار از ابتدا تا انتها به تصویر کشیده شد و با توجه به اهمیت مراحل جمع آوری و آنالیز نیازمندی ها و انالیز ریسک در طراحی سیستم های با قابلیت کاربری و اعتماد بالا، این مراحل جداگانه به تصویر کشیده شدند و عوامل و فاکتورهای مؤثر در آنها بررسی شد. حال نیاز به اعتبارسنجی مدلارائه شده است که در فصول بعدی به آن خواهیم پرداخت.
فصل 5
تحلیل نتایج
5-1- مقدمه
همان‌طور که در فصل قبل مطالعه کردید، مدلی برای طراحی سیستم‌های قابل کاربرد و قابل اعتماد طراحی شد. در این فصل برای ارزیابی و اعتبار سنجی مدل مذکور، سؤالاتی طرح شده و نشان داده شده‌است که پاسخ مثبت به‌این سؤالات از یک مدل موفق بدست می‌آید.
برای مشخص شدن دقیق عوامل مؤثر بر طراحی سیستمی قابل کاربرد و قابل اعتماد، فاکتورهای معرفی شده در مدل، مورد بررسی قرار گرفته و مشخص شده است که چه عواملی و به چه میزان از نظر خبرگان قابلیت کاربری و قابلیت اعتماد مهم هستند.
سپس پرسشنامه‌ای تهیه شده‌است که اولویت این عوامل را از خبرگان این حوزه سؤال کرده، تا با استفاده از پاسخ‌ها، مدل ارائه شده ارزیابی شود. پرسشنامه تهیه شده در پیوست “الف” قابل مشاهده است.
در فصل 3 برای انتخاب موضوع و حوزه تحقیق سعی بر این شد که با بررسی مقالات و تزهای دانشگاهی، اکثر مباحث و فاکتورهای طراحی سیستم‌های قابل کاربرد و قابل اعتماد، بررسی شود. این مقالات هر کدام جنبه‌ای از طراحی سیستم‌های مذکور را مد نظر قرار داده بودند و در فصل قبل، از این فاکتورها در طراحی مدل ارائه شده استفاده شد و برای اعتبار سنجی مدل، هر سؤال متناسب با یک رابطه در مدل
ارائه شده می‌باشد که پاسخ به سؤلات به صورت پاسخ‌های 5 گزینه‌ای (خیلی کم، کم، متوسط، زیاد، خیلی زیاد) است که از شماره 1 تا 5 میزان اهمیت رابطه عناصر موجود در مدل و طراحی سیستم قابل کاربرد و قابل اعتماد، را مشخص می‌کند.
5-2- ساختار پرسشنامه
برای بدست آوردن ذهنیت جمعیت مورد مطالعه، بایستی سؤالاتی مطرح شوند که بتوانند تصویری از عوامل تأثیر گذار در طراحی سیستم قابل کاربرد و قابل اعتماد و میزان تأثیرآنها رانمایان سازند. همان‌طور که در بخش‌های قبل توضیح داده شد. این عوامل، روابط میان آنها و میزان اهمیت عوامل و روابط، در قالب سؤالات 5 گزینه‌ای که از خیلی کم تا خیلی زیاد طبقه بندی شده‌اند پرسیده شده‌اند.
با توجه به‌اینکه پاسخ به‌این سؤالات برای سازمانها و شرکت‌های مختلف تولید سیستم‌های نرم افزاری تفاوتی ندارد، سؤالی در مورد خصوصیات سازمان و شرکت‌هایی که افراد مورد بررسی در آنجا مشغول به کارهستند، پرسیده نشده‌است.
پرسشنامه تدوین شده،

دسته بندی : No category

دیدگاهتان را بنویسید