فرآیند مهندسی نیازها

فرآیند مهندسی نیازها

اسلاید 1: فرآیند مهندسی نیازهاOmid.Mofidian@gmail.com

اسلاید 2: اهدافدرک فعالیت های اصلی مهندسی نیازها و ارتباط های آنهامعرفی تکنیک هایی برای استخراج و تحلیل نیازهادرک معتبرسازی نیازها و نقش بازبینی نیازهادرک نقش مدیریت نیازها در پشتیبانی فرآیند مهندسی نیازهای دیگر

اسلاید 3: فرآیند مهندسی نیازهافرآیندهای مهندسی نیازها تغییرات گسترده ای بر دامنه ی سیستم، افراد درگیر و نیازهای سازمان ایجاد خواهد کرد.در هر صورت، فعالیت های مشترکی وجود دارداستخراج نیازها؛تحلیل نیازها؛معتبرسازی نیازها؛مدیریت نیازها.

اسلاید 4: فرآیندمهندسی نیازها

اسلاید 5: مهندسی نیازها

اسلاید 6: مطالعات امکان سنجیمطالعه ی امکان سنجی مشخص خواهد کرد که آیا سیستم ارزشمند است یا خیر.مطالعه ای کوتاه برای بررسی هایآیا سیستم اهداف سازمانی را دربرمی گیرد؛آیا سیستم می تواند با استفاده از تکنولوژی و بودجه ی جاری مهندسی شود؛آیا سیستم می تواند با سیستم های دیگر مورد استفاده یکپارچه شود.

اسلاید 7: پیاده سازی مطالعه ی امکان سنجیبراساس ارزیابی اطلاعات (چه درخواست شده)، مجموعه ی اطلاعات و گزارش نوشته شده.سوالاتی از افراد در سازمان مطرح می شودچه سیستمی پیاده سازی نشده است؟چه مشکلاتی وجود دارد؟سیستم چگونه کمک خواهد کرد؟مشکلات یکپارچه سازی چه خواهد شد؟آیا تکنولوژی جدیدی نیاز است؟ چه مهارت هایی؟چه امکاناتی باید برای پشتیبانی سیستم وجود داشته باشد؟

اسلاید 8: استخراج و تحلیلگاهی اوقات استخراج یا کشف نیازها نامیده شده اند.کارکنان تکنیکی همراه با مشتریان دامنه ی برنامه ی کاربردی، سرویس هایی که سیستم باید فراهم نماید و محدودیت های سیستم را مشخص خواهند کرد.می توان کاربران نهایی، مدیران، مهندسان نگهدار، کارشناسان حوزه، اتحادیه ی صنفی را کارفرما نامید.

اسلاید 9: مشکلات تحلیل نیازهاکارفرمایان نمی دانند واقعاً چه می خواهند.کارفرمایان نیازها را با عبارات خود بیان می دارند.ممکن است کارفرمایان مختلف، نیازهای متضادی داشته باشند.ممکن است فاکتورهای سازمانی و سیاسی بر نیازهای سیستمی تاثیر بگذارند.نیازها در طی فرآیند تحلیل تغییر می یابند. ممکن است کارفرمایان جدید بوجودآیند و محیط تجاری تغییر می یابد.

اسلاید 10: نیازهای مارپیچی

اسلاید 11: فعالیت های فرآیندکشف نیازهابرای کشف نیازها با کارفرمایان در رابطه هستند. نیازهای دامنه در این مرحله کشف می شوند.طبقه بندی و سازماندهی نیازهانیازها گروهی و سازمانی را در دسته های منسجم بیان می دارد.اولویت بندی و مذاکرهاولویت و رفع نیازها متضاد.مستندسازی نیازهانیازها مستندسازی شده و در چرخه ی مارپیچی وارد می کند.

اسلاید 12: کشف نیازهانیازهای سیستمی و کاربران از فرآیند گردآوری اطلاعات پیشنهادی و سیستم های موجود، اخذ می گردد.منابع اطلاعاتی شامل مستندات، کارفرمایان سیستم و تعیین مشخصات سیستم های مشابه می باشند.

اسلاید 13: کارفرمایان ATM مشتریان بانکنماینده های بانک های دیگرمدیران بانککارمندان باجه هامدیران بانک اطلاعاتیمدیران امنیتبازاریابیمهندسین نگهدار سخت افزار و نرم افزارناظران بانک

اسلاید 14: دیدگاه هادیدگاه، ساختار نیازها از نقطه نظرهای مختلف کارفرمایان می باشد. ممکن است کارفرمایان دیدگاه های متفاوت را طبقه بندی کنند.تحلیل از چند نظر مهم است.

اسلاید 15: انواع دیدگاه هادیدگاه های تعاملیافراد یا سیستم های دیگر بصورت مستقیم با سیستم تعامل دارند. در ATM، مشتری و بانک اطلاعاتی دیدگاه های تعاملی دارند.دیدگاه های غیرمستقیمکارفرمایانی از سیستم استفاده نمی کنند اما بر نیازها تاثیر می گذارند. در ATM، مدیران و کارمند امنیت دیدگاه های غیرمستقیم دارند.دیدگاه های دامنهویژگی های و محدودیت های دامنه، نیازها را تحت تاثیر قرار می دهند. در ATM، ارتباطات درونی بانک استاندارد خواهد شد.

اسلاید 16: تعریف دیدگاهشناسایی انواع دیدگاه ها تامین کنندگان و دریافت کنندگان سرویس های سیستم؛سیستم هایی که بطور غیرمستقیم با سیستم رابطه دارند؛قوانین و استانداردها؛منابع تجاری و نیازهای کیفی؛مهندسینی که سیستم را توسعه داده و نگهداری می کنند؛بازاریابی و دیدگاه های تجاری دیگر.

اسلاید 17: دیدگاه سلسله مراتبی LIBSYS

اسلاید 18: مصاحبهدر مصاحبه های رسمی و غیررسمی، تیم مهندسی نیازها سوالاتی را برای کارفرمایان سیستم که استفاده کنندگان یا توسعه دهندگان سیستم هستند، مطرح می کند.دو شیوه برای مصاحبه وجود داردمصاحبه های بسته – به سوالاتی ازپیش تعریف شده پاسخ داده می شود.مصاحبه های باز – موارد بحث، ازپیش تعریف شده نبوده و با کارفرمایان به نتایجی می رسند.

اسلاید 19: مصاحبه ها در عملبطور طبیعی مخلوطی از مصاحبه های بسته و باز هستند.مصاحبه ها برای درک بیشتر مفید هستند، اینکه کارفرمایان چه می کنند و چطور با سیستم تعامل دارند.مصاحبه ها برای درک نیازهای دامنه مناسب نمی باشدمهندسین نیازها نمی توانند واژگان دامنه ی خاص را درک کنند.برخی با دانش دامنه به حدی آشنا هستند که بسختی در مورد آن مساله حرف زده یا فکر می کنند که نیاز به حرف زدن ندارد.

اسلاید 20: مصاحبه گرهای موثرمصاحبه ها باید روشنفکرانه بوده، به کارفرمایان گوش کنند و نباید در مورد نیازها پیش داوری کرد.مصاحبه گر باید با یک سوال یا گزارش بحث را شروع کند و نباید بسادگی با سوال ”می خواهید چه کار کنید“ پاسخ را بپذیرد.

اسلاید 21: سناریوهاسناریوها نمونه هایی از چگونگی استفاده ی سیستم در جهان واقع می باشد.باید شاملتوصیفی از راه حل آغازین؛توصیفی از رویدادهای طبیعی؛توصیفی از اشتباهات احتمالی؛اطلاعاتی در مورد فعالیت های همزمان دیگر؛توصیفی از حالت خاتمه ی سناریوها.

اسلاید 22: سناریو 1 LIBSYS

اسلاید 23: LIBSYS سناریو 2

اسلاید 24: موارداستفادهمورداستفاده سناریویی مبتنی بر تکنیکی در UML است که اکتورها را در یک محاوره شناسایی کرده و محاوره را بیان می دارد.مجموعه ای از موارداستفاده باید تمامی محاوره های ممکن را با سیستم توصیف نماید.ممکن است دیاگرام توالی برای افزودن جزییات به موارداستفاده بکار رود. فرآیند توالی رویداد در سیستم نشان داده می شود.

اسلاید 25: مورداستفاده ی چاپ مقاله

اسلاید 26: موارداستفاده ی LIBSYS

اسلاید 27: چاپ مقاله

اسلاید 28: توالی چاپ مقاله

اسلاید 29: فاکتورهای اجتماعی و سازمانیسیستم های نرم افزاری در محتوای اجتماعی و سازمانی بکار می روند. می تواند نیازهای سیستم را تحت تاثیر قرار دهد.فاکتورهای اجتماعی و سازمانی دیدگاه منفردی نبوده اما تمامی دیدگاه ها را تحت تاثیر قرار می دهند.تحلیل های خوب باید به این فاکتورها حساس باشد اما معمولاً روش اصولی برای تحلیل نیست.

اسلاید 30: مطالعه ی علمیدانشمندان اجتماعی زمان قابل توجهی برای مشاهده و تحلیل افرادی که واقعاً کار می کنند صرف می نمایند.افراد کار را توصیف نمی کنند.ممکن است اهمیت فاکتورهای اجتماعی و سازمانی مشاهده گردد.معمولاً مطالعه ی علمی، کار مدل های ساده ی سیستم را باشکوه تر و پیچیده تر نشان می دهد.

اسلاید 31: تمرکز مطالعه ی علمیدر مطالعه ی پروژه ی فرآیند کنترل ترافیک توسعه داده شده.ترکیب مطالعه ی علمی با نمونه سازی اولیه.توسعه ی نمونه سازی اولیه به سوالات بدون پاسخ تحلیل مطالعه ی علمی پاسخ می دهد.مشکل مطالعه ی علمی این است که ممکن است بر پایه ی سلسله مراتبی باشد اما نباید طولانی باشد.

اسلاید 32: مطالعه ی علمی و نمونه سازی اولیه

اسلاید 33: حوزه ی مطالعه ی علمینیازهایی که از افراد درگیر ناشی می شود به شیوه ایی که تعریف شده کار می کنند.نیازهایی که از مساعی و همکاری افراد دیگر ناشی می شود.

اسلاید 34: معتبرسازی نیازهادغدغه این است که نیاز های سیستم با آنچه مشتری می خواهد مطابقت داشته باشد.هزینه های خطای نیازها بیشتر است بنابراین معتبرسازی بسیار مهم می باشدتثبیت خطای یک نیاز بعد از تحویل ممکن است هزینه ای 100 مرتبه بیشتر از خطای پیاده سازی دارد.

اسلاید 35: بررسی نیازهااعتبار. آیا سیستم توابعی را فراهم می نماید که بهترین پشتیبان نیازهای مشتری باشد؟سازگاری. آیا در نیازها تضاد وجود دارد؟کمال. آیا تمامی توابع توسط مشتری درخواست شده است؟واقع بینی. آیا می توان نیازها را با بودجه و تکنولوژی موجود پیاده سازی نمود؟اثبات پذیری. آیا می توان نیازها را بررسی کرد؟

اسلاید 36: تکنیک های معتبرسازی نیازهامرور نیازهاتحلیل اصولی (سیستماتیک) نیازهانمونه سازی اولیهبکارگیری مدل قابل اجرای سیستم برای بررسی نیازها.تولید حالت تستتوسعه ی تست نیازها برای بررسی قابلیت تست.

اسلاید 37: مرور نیازهاتا زمانیکه تعریف نیازها تنظیم شده باشد بازبینی های باقاعده باید صورت پذیرد.متقاضی و پیمانکار باید در مرورها همکاری داشته باشند.ممکن است مرورها رسمی (با مستندات کامل) یا غیررسمی باشند. ارتباط های مناسب بین توسعه دهنده ها، مشتریان و کاربران می تواند حل مشکلات را تسریع نماید.

اسلاید 38: بررسی های مرورقابلیت اثبات. آیا نیازهای قابلیت تست واقعی را دارد؟قابلیت درک. آیا نیازها به درستی درک شده اند؟قابلیت ردیابی. آیا نیازهای مبدا به درستی گفته شده است؟قابلیت سازگاری. آیا می توان نیاز را بدون تاثیر بر نیازهای دیگر تغییر داد؟

اسلاید 39: مدیریت نیازهامدیریت نیازها فرآیند مدیریت تغییر نیازها در طی فرآیند مهندسی نیازها و توسعه ی سیستم می باشد.نیازها بناچار ناقص و متناقص هستندنیازهای جدید در طی یک فرآیند ناشی می شود بنابراین نیازهای تجاری تغییر کرده و درک بهتری از سیستم حاصل می گردد.دیدگاه های متفاوت نیازهای مختلفی داشته و غالباً متناقضند.

اسلاید 40: تغییر نیازهااولویت نیازها از دیدگاه های مختلف در طی فرآیند توسعه تغییر می یابد.مشتریان سیستم ممکن است نیازهای تجاری ای را تعیین کنند که با نیازهای کاربر نهایی متضاد است.محیط های تکنیکی و تجاری در طی توسعه، تغییر می یابد.

اسلاید 41: ارزیابی نیازها

اسلاید 42: نیازهای پایدار و سستنیازهای پایدار. نیازهای ثابت از فعالیت سازمانی مشتری نشات می گیرد. برای نمونه در یک بیمارستان همیشه دکترها، پرستاران و غیره وجود دارند بطوریکه ممکن است از مدل های دامنه ناشی شوند.نیازهای سست. نیازهایی که در طی توسعه یا حین استفاده ی سیستم تغییر می یابند. در بیمارستان، نیازهایی که از سیاست بهداشتی ناشی می شود.

اسلاید 43: طبقه بندی نیازها

اسلاید 44: برنامه ی مدیریت نیازهادر طی فرآیند مهندسی نیازها، برنامه ریزی زیر خواهید داشت:شناسایی نیازهاچه نیازهایی منحصراً شناسایی شده است؛فرآیند مدیریت تغییرزمانیکه نیازها تغییر یابد فرآیند دنبال می شود؛سیاست های قابلیت ردیابیاطلاعاتی د رمورد ارتباط نیازها یی که اصلاح شده است؛ابزار پشتیبانی CASEابزار پشتیبان برای مدیریت تغییر نیازها درخواست می شود؛

اسلاید 45: قابلیت ردیابیقابلیت ردیابی دغدغه ی ارتباط بین نیازها، منابع و طراحی سیستم را داردقابلیت ردیابی منبعبرقرار ارتباط بین نیازها با کارفرمایان؛قابلیت ردیابی نیازهابرقراری ارتباط بین نیازهای وابسته؛قابلیت ردیابی طراحیبرقراری ارتباط از نیازها به طراحی؛

اسلاید 46: ماتریس قابلیت ردیابی

اسلاید 47: ابزار پشتیبان CASEذخیره ی نیازهانیازها باید در یک منبع ذخیره و مدیریت شوند. مدیریت تغییرفرآیند مدیریت تغییر فرآیند جریان کاری است که می تواند جریان اطلاعات را بین مراحی مختلف بصورت خودکار تعریف و ذخیره نماید.مدیریت ردیابیبازیابی ارتباط بین نیازها بطور خودکار انجام می پذیرد.

اسلاید 48: مدیریت تغییر نیازهاباید تمامی تغییرات نیازها پیشنهاد شود.مراحل اصلیتحلیل مشکل. مشکل نیازها و تغییر بیان می شود؛تحلیل و هزینه ی تغییر. تاثیر تغییر روی نیازهای دیگر ارزیابی می شود؛پیاده سازی تغییر. مستند نیازها و مستندات دیگر وابسته به تغییر اصلاح می شود.

اسلاید 49: مدیریت تغییر