مهندسی سیستم (بخش دوم)
نقش های سیستم و ذینفعان؛ پذیرش سیستم

مهندسی سیستم (بخش دوم)

نقش های سیستم و ذینفعان؛ پذیرش سیستم

 

نویسنده: مهندس آرش حسینی


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

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


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


ذی نفع : فرد یا سازمانی که منافع از پیش تعیین شده ای (دوستانه، رقابتی، یا متخاصم) در خروجی تولید شده از یک سیستم در انجام ماموریت تعیین شده اش دارد.


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


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


زمینه نقش سیستم :


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


نقش ماموریتی :

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

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

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


حال این سوال مطرح می گردد که نقش های سیستمی سازمان چگونه به مهندسی سیستم ارتباط پیدا می کنند ؟


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

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

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


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


پذیرش سیستم :


میزان موفقیت هر سیستم دست ساخته بشر و ماموریتش در شاخص های پذیرش ذیل نهفته است :


  • آیا بازار برای پذیرش سیستم جدید آمادگی دارد ؟ یک نیاز عملیاتی به پنجره ای از موقعیت های جدید

  • درک کاربر از ابزارهای عملیاتی، سازگاری و در دسترس بودن

  • توانایی سیستم در انجام و به ثمر رساندن اهداف کاربر – اثر بخشی سیستم

  • بازگشت سرمایه برای منابع وابسته به عملیات و نگهداری سیستم – به صرفه بودن


بیشتر افراد پذیرش سیستم را از دریچه رضایت زمینه کاری مشتری می بینند. مهندسین غالباً اندازه گیری این موضوع را به بعد از ارائه و توزیع سیستم در بازار محول می کنند. بر اساس چیزی که سازمان از نظرسنجی های پس از تحویل می آموزد، مهندسین ممکن است سیستم یا محصول را اصلاح کنند اگر :


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

  •   پیش بینی های سود بلندمدت سرمایه گذاری داخلی را ارزشمندتر نماید.


شما به عنوان یک مهندس سیستم باید نیازهای عملیاتی کاربر را قبل از توسعه و نظر سنجی درک نمائید، شما باید درک کنید که :


  •  کاربر قرار است چگونه از سیستم یا محصول شما استفاده نماید ؟

  •  چه معیارهایی برای موفقیت باید اعمال شود ؟

  •  پیامد شکست کاربر و به وجود آمدن شاخه های جدید از درجاتی از موفقیت چیست ؟


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

معیارهای ذهنی - یعنی درک از ابزارهای عملیاتی، مناسب بودن و دسترس پذیری، اغلب معیارهای عینی موفقیت سیستم (اثربخشی، به صرفه بودن) را مبهم می نماید.


  • فاکتورهای نگاه ذهنی، حس و درک در جامعه همتایان سیستم  یا منبع سرمایه گذاری قالبا پذیرش موفقیت سیستم از دید کاربر را تا اندازه ای تیره و تار می نماید.

  • در مقابل، کاربر برای همان دلایل ذهنی ممکن است موفقیت عینی یک سیستم را زیر سوال ببرد.


در نهایت، برخی از رویدادها بررسی واقعیت را ممکن می سازد. یک تصمیم برای ادامه کار با یک سیستم ممکن است منجر به ایجاد نیاز به یک به روزرسانی برای تصحیح کمبودها، حذف تدریجی یک سیستم یا جایگزینی آن با یک سیستم جدید گردد.


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


 چالش های کلیدی توسعه سیستم های قابل پذیرش از طرف کاربران :


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


  • آیا زمان معرفی سیستم جدید مناسب است ؟ ایا بازار از نظر حسی و ذهنی آمادگی پذیرش سیستم، محصول یا خدمت جدید که توسط نیازهای کاری و عملیاتی هدایت می شود را دارد؟

  • آیا امکان پذیری سیستم به کفایت به سرمایه گذار کاربران و توسعه دهندگان باز گشت سرمایه را گواهی می دهد ؟

  • آیا سیستم پیشنهادی به صورت عملیاتی ابزاری برای کاربر در ارتباط با ماموریت و اهداف سازمانش می باشد ؟

  • آیا سیستم پیشنهادی به صورت عملیاتی مناسب تمامی ذی نفعان برنامه مورد نظر خود می باشد ؟

  • آیا سیستم پیشنهادی به صورت عملیاتی در هنگام انجام وظائف محوله برای انجام ماموریت در دسترس است ؟

  •  آیا سیستم پیشنهادی به صورت عملیاتی از جهت بودجه و کارایی فنی برای دستیابی به ماموریت برنامه ها و اهداف محوله اش موثر است ؟


امکان پذیری و مقرون به صرفه بودن سیستم :


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


·        کاربر چه چیزی می خواهد ؟

·        نیاز کاربر چیست ؟

·        کاربر از عهده چه چیزی بر می آید ؟

·        برای چه چیزی کاربر حاضر است هزینه پرداخت نماید ؟


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


مقرون به صرفه بودن :


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


·        هزینه گردش کار

·        هزینه کارائی


کارایی سیستم :


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


·        مشخص کردن و محدود کردن دید به سیستم یا یکی از اجزای آن

·        مقایسه کارایی برنامه ریزی شده یا نتایج مورد نظر  و واقعیت


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


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



کنترل واقعیت :


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


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

" پیشنهادی به ما بدهید که طیف و ترکیبی از توانمندی و سطح کاربرد – کارایی سیستم/هزینه را تشریح کرده که قابل استفاده برای تدارک تعداد مشخصی از اهداف یا نیازمندی ها باشد " .


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


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


ارزیابی و صحت سنجی سیستم :


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


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


·        افق دید خود را چگونه به مشخصه هایی جهت تولید سیستم رویایی خود ترجمه می کنند ؟

·        چگونه به این اطمینان خاطر می رسند که سیستم، محصول یا خدمت ارائه شده همان سیستم درست است ؟

·        توانایی این مورد را داشته باشند تا در آینده نسخه های کپی جدیدی از سیستم خود داشته باشند ؟


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




صحت سنجی سیستم :

از میان جریان توسعه مشخصه های چند لایه، تهیه کنندگان و کاربران سیستم باید به این سوال جواب دهند که : آیا ما سیستم درست را که نیازهای عملیاتی کاربر را پوشش می دهد تهیه کرده ایم ؟ این فرآیندی چرخشی است تا نیازمندی ها به درجه ای از پختگی برای شروع تدارک سیستم برسد. زمانی که تدارک سیستم آغاز می گردد، تقاضای پیشنهادی ، دیدگاه های جدیدی را به ما ارائه می دهد.

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

ما به این راه کار طراحی تکاملی سیستم، پیکره بندی توسعه و به فعالیت های کنترلی هنگام توسعه، کنترل و ارزیابی سیستم می گوئیم. در نهایت ، هنگامی که توسعه سیستم یا محصول تکمیل می گردد، مسئولین باید به این سوال پاسخ دهند که : آیا سیستم درست پیاده گردیده ؟

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


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


نویسنده: مهندس آرش حسینی

رزومه 



مهندسی سیستم (بخش دوم)
Fatemeh Shakhsian ۱۴۰۲/۰۲/۲۴ ۱۶:۳۳:۲۶
اشتراک گذاری این پست
بایگانی
ورود برای ارائه نظر
مهندسی سیستم (بخش اول)
تعریف واژه های کلیدی