+

GROWTH

۰۰۰۰/۰

۹۱۵۱/۶

۳۶۲۵/۰

AR(1)

F=05255/24 F(P-Value)= 0000/0 DW= 2712/2 R2=8426/0
ADJR2=8076/0

همانطور که از جدول شماره ۴-۳ مشاهده میشود ، آماره F بدست آمده در مدل فوق در سطح اطمینان ۹۹/۰ معنی دار است، بنابراین کل مدل از لحاظ آماری معنادار است. . بدون در نظر گرفتن وقفه بهینه، آماره دوربین- واتسون مقدار ۱۹/۱ را نشان می داد، که بیانگر وجود خودهمبستگی بین خطاهای مدل بود. برای رفع این مشکل ابتدا وقفه بهینه با استفاده از معیار های خطای نهایی پیش بینی شده[۱۰۸]، معیار آکائیک[۱۰۹]، شوارز[۱۱۰] و حنان کوئین[۱۱۱] تعیین گردید که همگی این معیارها وقفه بهینه یک را نمایش دادند بنابراین با در نظر گرفتن وقفه بهینه یک آماره دوربین- واتسون مقدار ۰۷/۲ را نشان می دهد، که بیانگر عدم وجود خودهمبستگی بین خطاهای مدل است. معیار ضریب تعیین تعدیل شده نیز نشان دهنده این است که۷۱/۰ درصد از تغییرات در شاخص افشای اختیاری توسط متغیر های مستقل وارد شده در مدل تبیین میگردد.همانطور که از جدول شماره ۴-۳ مشاهده میشود ، آماره t بدست آمده برای متغیر ریسک برابر با ۳۴/۳- میباشد. با توجه به (p-value) بدست آمده (۰۰۰۹/۰) که مقدار آن کمتر از ۰۱/۰ میباشد، فرضیه اول تحقیق در رابطه با میزان افشای اختیاری در سطح اطمینان ۹۹/۰ تایید می گردد. به عبارت دیگر رابطه معنی داری بین ریسک شرکت و میزان افشای اختیاری وجود دارد. بدین ترتیب می توان اینگونه تفسیر کرد که شرکت های دارای ریسک بالا برای وخیم تر نشدن اوضاع مالی شرکت کمتر افشای اختیاری اطلاعات را در دستور کار خود قرار می دهند و تنها به افشای اطلاعاتی که توسط نهادهای قانون گذاری همچون سازمان بورس و اوراق بهادار ملزم به افشا شده اند اکتفا می نمایند.
۴-۵-۲٫ نتایج حاصل ازآزمون فرضیه دوم
دومین فرضیهی این تحقیق به بررسی رابطه بین ارزش شرکت و افشای اختیاری میپردازد. بنابراین فرضیهی صفر و فرضیهی جانشین به صورت زیر مطرح میگردد.
H0b: ارزش شرکت بر افشای اختیاری شرکتهای پذیرفته شده در بورس اوراق بهادار تهران تاثیر ندارد.
H1b: ارزش شرکت بر افشای اختیاری شرکتهای پذیرفته شده در بورس اوراق بهادار تهران تاثیر دارد.
نتایج حاصل از آزمون چاو و آزمون هاسمن برای مدل مورد استفاده در آزمون فرضیه بالا در جدول ۴-۴ ارائه گردیده است.
جدول ۴-۴: نتایج انتخاب الگو برای آزمون مدل مورد استفاده در آزمون فرضیه دوم

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

انجام تستهای قابلیت کاربرد در فاز آخر – یعنی زمانی که محصول آماده شده‌است – چندان در افزایش کیفیت محصولات تأثیری ندارد و تنها باگهای محدودی را میتواند شناسایی و برطرف کند، در صورتی که استفاده از این روش در چرخه تولید محصول میتواند رضایت مشتریان را تا حد زیادی برآورده کند.
پنج هدف اصلی که در تست قابلیت کاربری مطرح می‌گردد را می‌توان به صورت زیر عنوان کرد:
قابلیت استفاده محصول را القاء می‌کند.
کاربران نهایی را در تست مشارکت می‌دهد.
تعدادی از وظایف مربوطه را به کاربران نهایی واگذار می‌کند.
مسئول تست را قادر می‌سازد فعالیت‌های مشارکت کنندگان را مشاهده و ضبط کند.
مسئول تست را قادر می‌سازد داده‌های به دست آمده را مورد تجزیه و تحلیل قرار دهد و تغییرات متناسب را اعمال کند.
تست قابلیت کاربری بر نیازهای کاربران تمرکز دارد، از معیارهای عملی و طراحی تکرار شونده[۳۷] استفاده می‌کند.
تست قابلیت کاربری محدودیت‌هایی نیز دارد. به طور مثال تمام ویژگی‌های رابط کاربری را در برنمی‌گیرد. این تست در حدود چند ساعت در آزمایشگاه‌های مربوطه انجام می‌شود و به سختی می‌توان
قابلیت اجرای سیستم در چندین هفته و یا ماه را پیش بینی نمود. هم چنین تعداد اندکی از کاربران که
در این تست شرکت می‌نمایند نمی‌توانند معرف تمامی کاربران سیستم باشند. علاوه بر این معمولاً این تست هزینه بر می‌باشد.
این تست در قالب چند تکنیک اجرا می‌شود. معروف‌ترین این تکنیک‌ها تست‌های هیوریستیک[۳۸]و دیسکانت[۳۹] می‌باشند. در ارزیابی هیوریستیک، متخصصین برنامه کاربردی را بازبینی می‌کنند و بر مبنای دانسته‌های خود از جامعه کاربران، مشکلات مربوط به طراحی برنامه را شناسایی می‌نمایند. در ارزیابی دیسکانت، برنامه مورد نظر توسط ۳ تا ۵ کاربر مورد استفاده قرار می‌گیرد و مشکلات آن شناسایی می‌گردد.
با توجه به اهمیت تست قابلیت کاربری در طراحی مبتنی بر کاربران، اگر بتوان مشارکت کارکنان را از مراحل آغازین چرخه حیات سیستم نرم افزاری به کار گرفت، اثرات مثبت این همکاری در نتایج تست قابلیت کاربری مشاهده خواهد شد. در ادامه به تعدادی از مزایا و معایب طراحی مشارکتی اشاره شده‌است.
جدول ۲ – ۲ – مزایا و معایب طراحی مشارکتی

ممکن است اعمال تعدادی از نظرها در طراحی دشوار باشد.

همکاری بین افراد در این فرآیند امکان ارائه راه حل‌های خلاقانه را افزایش می‌دهد.

امکان ارائه‌ایده‌های مربوط به محصولات جدید افزایش پیدا می‌کند.

جنبه‌های مختلف قابلیت کاربری نمی‌تواند پیشرفت کند مگر آنکه راه‌هایی برای تست و اندازه‌گیری آنها وجود داشته باشد. هرنبائک[۴۰] (۲۰۰۶) در تحقیقات خود بیان می‌کند که قابلیت کاربری نمی‌تواند به طور مستقیم اندازه‌گیری شود. او چندین چالش برای اندازه‌گیری قابلیت کاربری را مانند درک ارتباط میان اندازه‌گیری غیر عینی و عینی قابلیت کاربری، اندازه‌گیری قابلیت یادگیری، اندازه‌گیری رضایت از طریق سؤالات در مورد استفاده از نرم افزار و همبستگی میان اندازه‌گیری‌های مختلف را مطرح می‌کند. میلر[۴۱] (۲۰۰۶) تست قابلیت کاربری را به عنوان پروسه‌ای که با شروع پروژه آغاز می‌شود و از طریق نمونه آزمایشی[۴۲] تکمیل شده و حتی بعد از تولید نسخه نرم افزاری ادامه می‌یابد در نظر می‌گیرد و معتقد است که «تمام شدن پروژه به‌این معنی نیست که قابلیت کاربری پروژه پایان یافته است».
ستین و گوکتورک[۴۳] (۲۰۰۸) معتقدند که قابلیت کاربری یک ویژگی کیفی غیر عملیاتی[۴۴]محسوب می‌شود و به عنوان یک موضوع ذهنی به طور مستقیم قابل اندازه‌گیری نیست.

چهارچوب[۴۵] RESPECT

این چهارچوب بر اسـاس چرخه طـراحی ارائه شده در طـراحی مبتـنی بر کاربر استاندارد ISO 13407 می‌باشد که در ادامه نمایش داده شده‌است.
شکل ۲ – ۱ – فعالیت‌های کلیدی طراحی مبتنی بر کاربر (ISO. ISO 9241-11)
RESPECT چهارچوبی فراگیر جهت مهندسی نیازمندی‌ها فراهم میآورد که نیازمندی‌های کاربر را در دست‌یابی به کیفیت مورد نظر در پروسه طراحی مرتفع می‌سازد. RESPECT بر اهمیت فهم کاملی از نیازمندی‌های کاربران تأکید داشته و اعتبار سنجی نیازمندی‌های کاربران را در دنیای واقعی مورد بررسی قرار می‌دهد. روش‌های مهندسی نیازمندی‌های موجود نیز می‌توانند در راستای این روش به کارگرفته شوند. RESPECT هم چنین نیازمندی‌های جدید را مورد بررسی قرار می‌دهد که شامل دو بخش نیازمندی‌های مربوط به زمینه‌های استفاده متفاوت مربوط به سناریوهای استفاده کاربران و اهداف قابلیت کاربرد می‌باشند که موجب می‌شوند کاربران کارا، اثربخش و با رضایت وظایف خود را در سیستم انجام دهند.

گام‌های اصلی چهارچوبRESPECT

سه گام اصلی در چهارچوب نیازمندی‌های کاربر و بخش‌های تشکیل دهنده آنها را می‌توان به صورت
چرخه‌ای پیمایشی نمایش داد که در شکل زیر ارائه شده‌است. هر چرخه شامل تجزیه و تحلیل زمینه
استفاده، تعیین نیازمندی‌های کاربر و توسعه طراحی جهت رسیدن به نیازمندی‌های تعیین شده و تست آنها می‌باشد.
شکل ۲ – ۲ – گام‌های اصلی RESPECT(ISO. ISO 9241-11)
فاز اول: زمینه استفاده سیستم و طراحی اولیه
فاز دوم: تهیه پروتوتایپ و تعیین اهداف تست قابلیت استفاده
فاز سوم:تهیه محصول نهایی

تعاریف، ماهیت و مفهوم اعتماد

در مفاهیم اجتماعی، اعتماد[۴۶] از راه‌های گوناگونی سنجیده می‌شود. مانند تاریخچه تعاملات گذشته، شایعات، گواهی‌نامه شخص ثالث، اعتبار اجتماعی و…
اعتماد به عنوان بخش مهمی از زندگی فردی و اجتماعی بشر در نظر گرفته می‌شود و به کار بستن آن بدون محدودیت فرهنگی یا ملیتی، به عنوان نمونه‌هایی از اصول اولیه اقتصاد (زاک و کناک[۴۷]، ۱۹۹۸;فیش من و خاننا[۴۸] ۱۹۹۹) و یک هنجار اجتماعی و فرهنگی (گلدنر[۴۹]، ۱۹۶۰) پیشنهاد می‌شود و با توجه به اینکه کارایی عملیات اعتماد، نیاز به ساختارهای کنترلی خارجی روشن ندارد، استفاده از آن هزینه تراکنش‌ها و میزان مصرف انرژی منابع را کم می‌کند. (زاک و کناک ۱۹۹۸ ; دلهگ[۵۰] و نیوتن[۵۱] ۲۰۰۳; سیتکین[۵۲] و رت[۵۳] ۱۹۹۳ ; آسلانر، [۵۴] ۲۰۰۲) و می‌تواند باعث آسان شدن و روان شدن رنج متمایزی از تعاملات اجتماعی شود. (استل، [۵۵] ۱۹۹۸)
قابلیت اعتماد ماهیتی چند وجهی دارد و در زمینه‌های مختلف از جمله جامعه شناسی، تاریخ، فلسفه،
علوم کامپیوتر و… به آن پرداخته شده‌است. (مارش[۵۶]، ۱۹۹۶; آنارایانا و تیلر[۵۷]، ۲۰۰۰) و شامل انواع
ویژگی‌های شخصیتی و انواع ساختارهای اجتماعی است. (نایت و چروانی[۵۸]، ۲۰۰۱ )
روانشناسان اعتماد را به صورت یک خصیصه‌ی شخصی، جامعه شناسان آن را به صورت یک ساختار اجتماعی و اقتصاددانان آن را به صورت یک مکانیسم انتخاب اقتصادی مد نظر قرار داده‌اند. (لویکی[۵۹] و دیگران، ۱۹۹۵) طرفداران یک رشته ممکن است نقطه نظر رشته‌های دیگر در مورد اعتماد را درک نکرده و آن را مورد تصدیق قرار ندهند، بنابراین تعاریف موجود، بسیار متفاوت بوده و اغلب در طول یک خط بین رشته‌ای تجمیع می‌شوند.

رویکرد‌های هدف محور

مهندسی نیازمندی‌های هدف محور[۲۱۷] به استفاده از اهداف برای استخراج نیازمندی‌ها، ارزیابی، مذاکره، پیچیدگی ساختار بندی، مستند سازی، آنالیز و تکامل تدریجی اشاره دارد. (لمسوئیرد[۲۱۸]، ۲۰۰۹)
در این بخش یک نمونه را که روی کشف اهداف و نیازمندی‌ها تمرکز دارد و با چهارچوب KAOS مشخص شده‌است، بازبینی می کنیم.
 
 
 
 

KAOS

روش[۲۱۹]KAOS (داردنه[۲۲۰] و دیگران، ۱۹۹۳) یک رویکرد سیستماتیک برای آنالیز، شناسایی و ساختاربندی اهداف و نیازمندی‌ها است. این رویکرد بر اساس مدل کردن اهداف به صورت بالا به پایین[۲۲۱] و پایین به بالا[۲۲۲] استوار است.
KAOS، هدف را به عنوان قصد و نیتی که سیستم باید از طریق مشارکت عواملش به آنها دست یابد تعریف می‌کند. (لمسوئیرد، ۲۰۰۹) این عوامل ممکن است کامپوننت‌هایی از یک سیستم بزرگ یا بشر یا ماشین باشند.
هدف می‌تواند رفتاری[۲۲۳]یا نرم[۲۲۴] باشد. اهداف رفتاری، رفتارهای سیستم را تعیین می‌کنند و ممکن است اهداف دست یافتنی یا پشتیبانی باشند. اهداف دست یافتنی رفتارهایی که سیستم باید دیر یا زود به آنها دست یابد را معرفی می‌کند. در حالیکه اهداف پشتیبانی رفتارهایی از سیستم که همیشه باید وجود داشته باشد را تعیین می‌کند. اهداف نرم ترجیحات میان رفتارهای سیستم را تعیین می‌کنند و معمولاً با کلمات کلیدی مانند افزایش یا کاهش به جای دست یافتنی یا پشتیبانی معرفی می‌شوند.
یک مدل هدف KAOS یک گراف تفسیری هدف است که از طریق لینک‌های و/یا[۲۲۵] بهم مرتبط شده‌اند، برای مثال در مورد لینک‌های”و”، همه زیر اهداف لینک شده به هدف پدر، باید قبل از برآورده شدن هدف پدر برآورده شوند.
اهداف ممکن است به وسیله ویژگی‌های دامنه پالایش شوند. اهداف همچنین می‌توانند به وسیله عملیات سیستم که تغییرات در وضعیت سیستم ایجاد می‌کنند عملیاتی شوند. (اسپیوی[۲۲۶]، ۱۹۹۲)
 
 
 
 
 

معایب KAOS

KAOS منکر پروسه استخراج نیازمندی‌ها و مدل کردن زمینه‌ای است. ضعف استخراج نیازمندی‌ها در KAOS عمیق‌تر شده‌است زیرا استفاده از بحث امنیت (هالی و دیگران، ۲۰۰۸) و آنالیز ریسک (چمیت[۲۲۷]، ۲۰۱۰) چند راه برای چک کردن سلامت داده‌ها قبل از مدل کردن را ارائه می‌دهد. اما با KAOS، ارزیابی پروسه مدل کردن اهداف هیچ پشتگرمی در مورد اعتبار اهداف نمی‌دهند.

رویکردهای عامل محور[۲۲۸]

آغاز رویکردهای عامل محور به کار چانگ و دیگران[۲۲۹]روی چهارچوب NFR[230] (چانگ، ۲۰۰۷) باز می‌گردد. اساس چهارچوب NFR طراحی سیستم‌هایی است که با نیازمندی‌های غیر عملکردی مانند امنیت، دقت و کارائی درگیر می‌باشد.
چانگ و دیگران تقویت استخراج نیازمندی‌های عملیاتی، با فعالیت‌هایی در جهت شناسایی، تجزیه و تحلیل و عملیاتی کردن اهدافی که مشکلات غیر عملکردی را منعکس می‌کنند را پیشنهاد می‌کنند. اگرچه نیازمندی‌های غیرعملکردی اغلب کامل مشخص نیستند و ممکن است به عنوان اثرات جانبی دیگر اهداف شناسایی شوند.
 
 
 

I*

چهارچوب I*^[231] یک رویکرد عامل محور در مهندسی نیازمندی‌ها است. I* برای تمرکز روی مهندسی نیازمندی‌ها در مراحل ابتدایی

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

فصل ۴

ارائه مدل

مقدمه

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

فهمیدن و شناسایی زمینه استفاده

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

جمع آوری و آنالیز نیازمندی‌ها

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