https://virgool.io/feed/@es.shahbazi عاشق ماجراجویی در اعماق معانی هستم. تحلیل و طراحی سیستم، بستر ماجراجویی را برای من هموار می کند. fa 2026-06-16 11:25:29 https://files.virgool.io/upload/users/17581/avatar/tzLcA2.png?height=120&width=120 https://virgool.io/@es.shahbazi https://virgool.io/@es.shahbazi/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%DB%8C%DA%A9-%D9%85%D8%AD%D8%AF%D9%88%D8%AF-%DA%A9%D9%86%D9%86%D8%AF%D9%87-%D9%86%D8%B1%D8%AE-rate-limiter-k43utul7t680 در یک سیستم تحت شبکه، یک محدود کننده نرخ برای کنترل نرخ ترافیک ارسال شده توسط یک کلاینت یا یک سرویس استفاده می شود. در دنیای HTTP، یک محدودکننده نرخ، تعداد درخواست‌های مجاز کلاینت به ارسال در یک دوره مشخص را محدود می‌کند. اگر تعداد درخواست های API از آستانه تعیین شده توسط محدود کننده نرخ بیشتر شود، همه ارتباط های اضافی (excess calls) مسدود می شوند. بطور مثال:• کاربر نمی تواند بیش از 2 پست در ثانیه بنویسد.• می توانید حداکثر 10 حساب در روز از یک آدرس IP ایجاد کنید.• شما نمی توانید بیش از 5 بار در هفته از همان دستگاه پاداش دریافت کنید.مزایای استفاده از یک محدود کننده نرخ API:• جلوگیری از خارج از دسترس شدن منابع، ناشی از حمله بندآوری سرویس Denial of Service (DoS) attac [1]. تقریباً تمام API های منتشر شده توسط شرکت های بزرگ فناوری نوعی محدودیت نرخ را اعمال می کنند. به عنوان مثال، توییتر تعداد توییت ها را به 300 توییت در هر 3 ساعت محدود می کند [2]. API های اسناد Google دارای محدودیت پیش‌فرض زیر هستند: 300 برای هر کاربر در 60 ثانیه برای درخواست‌های خواندن [3]. یک محدودکننده نرخ با مسدود کردن ارتباط های اضافی، از حملات DoS، عمدی یا غیرعمدی جلوگیری می‌کند.• کاهش هزینه. محدود کردن درخواست‌های اضافی به معنای سرورهای کمتر و تخصیص منابع بیشتر به API های با اولویت بالا است. محدود کردن نرخ برای شرکت هایی که از API های شخص ثالث(third-party) پولی استفاده می کنند بسیار مهم است. به عنوان مثال، برای API های خارجی زیر بر اساس هر تماس هزینه دریافت می کند: اعتبار چک، پرداخت، بازیابی سوابق سلامت و غیره. محدود کردن تعداد ارتباط­ها برای کاهش هزینه‌ها ضروری است.• جلوگیری از قرارگیری بار بیش از حد روی سرورها. برای کاهش بار سرور، یک محدود کننده نرخ برای فیلتر کردن درخواست های اضافی ناشی از ربات ها یا رفتار نادرست کاربران استفاده می شود.گام اول: درک مشکل و تعیین محدوده طراحیمحدود کردن نرخ(Rate Limiting) را می توان با استفاده از الگوریتم های مختلف پیاده سازی کرد که هر کدام مزایا و معایب خود را دارند. بررسی سوالات و پاسخ های پیشنهادی کمک می کند تا نوع محدود کننده های نرخ را که می خواهیم بسازیم روشن شود.سوال: قرار است چه نوع محدود کننده نرخی (Rate Limiter) را طراحی کنیم؟ یک محدود کننده نرخ سمت کلاینت یا محدود کننده نرخ API سمت سرور؟پاسخ: ما روی محدود کننده نرخ API سمت سرور تمرکز می کنیم.سوال: آیا محدود کننده نرخ درخواست های API را بر اساس IP، شناسه کاربری یا سایر ویژگی ها کاهش می دهد؟پاسخ: محدود کننده نرخ باید به اندازه کافی انعطاف پذیر باشد تا از مجموعه های مختلف قوانین محدودگر پشتیبانی کند.سوال: مقیاس سیستم چقدر است؟ آیا برای یک استارت آپ یا یک شرکت بزرگ با پایگاه کاربر بزرگ ساخته شده است؟پاسخ: سیستم باید قادر به رسیدگی به تعداد زیادی درخواست باشد.سوال: آیا سیستم در یک محیط توزیع شده کار خواهد کرد؟پاسخ: بله.سوال: آیا محدود کننده نرخ یک سرویس جداگانه است یا باید در کد برنامه پیاده سازی شود؟پاسخ: این یک تصمیم طراحی به عهده شماست.سوال: آیا باید به کاربرانی که محدود هستند اطلاع دهیم؟پاسخ: بله.الزاماتدر اینجا خلاصه ای از الزامات این سیستم آمده است:• محدود کردن درخواست های بیش از حد را به طور دقیق.• زمان ​​تاخیر کم. محدود کننده نرخ نباید زمان پاسخ دهی HTTP را کاهش دهد.• تا حد امکان از حافظه کمتری استفاده کند.• محدود کردن نرخ توزیع شده(Distributed rate limiting). محدود کننده نرخ را بتوان در چندین سرور یا فرآیند به اشتراک گذاشت.• رسیدگی به استثنا(Exception handling). زمانی که درخواست‌های کاربران مسدود می‌شود، استثناهای واضحی را به کاربران نشان دهد.• تحمل خطا بالا(High fault tolerance). اگر مشکلی در محدود کننده نرخ وجود داشته باشد (مثلاً یک سرور کش آفلاین شود)، بر کل سیستم تأثیر نگذارد.گام دوم: طراحی سطح بالا اجازه دهید همه چیز را ساده نگه داریم و از یک مدل اولیه کلاینت و سرور برای ارتباط استفاده کنیم.محدود کننده نرخ را کجا قرار دهیم؟به طور مستقیم، می توانید یک محدود کننده نرخ را در سمت کلاینت یا سمت سرور پیاده سازی کنید.• پیاده سازی سمت کلاینت. به طور کلی، کلاینت مکانی غیرقابل اعتماد برای اعمال محدودیت نرخ است زیرا درخواست های کلاینت می تواند به راحتی توسط عوامل مخرب جعل شود. علاوه بر این، ممکن است کنترلی بر اجرای کلاینت نداشته باشیم.• پیاده سازی سمت سرور. شکل 4-1 یک محدود کننده نرخ را نشان می دهد که در سمت سرور قرار داده شده است.علاوه بر اجرای کلاینت و سمت سرور، یک راه جایگزین نیز وجود دارد. به جای قرار دادن یک محدود کننده نرخ در سرورهای API، ما یک میان افزار محدود کننده نرخ ایجاد می کنیم که درخواست ها را به API های شما همانطور که در شکل 4-2 نشان داده شده است، کاهش می دهد.اجازه دهید از یک مثال در شکل 4-3 استفاده کنیم تا نحوه عملکرد محدود کردن نرخ در این طرح را نشان دهیم. فرض کنید API ما اجازه 2 درخواست در ثانیه را می دهد و یک کلاینت در عرض یک ثانیه 3 درخواست را به سرور ارسال می کند. دو درخواست اول به سرورهای API هدایت می شوند. با این حال، میان‌افزار محدودکننده نرخ سومین درخواست را کاهش می‌دهد و کد وضعیت HTTP 429 را برمی‌گرداند. کد وضعیت پاسخ HTTP 429 نشان می‌دهد که کاربر درخواست‌های زیادی ارسال کرده است.میکروسرویس های ابری(Cloud microservices) [4] به طور گسترده ای محبوب شده اند و محدودیت نرخ معمولاً در یک مؤلفه به نام دروازه(Gatway) API پیاده سازی می شود. دروازه API یک سرویس کاملا مدیریت شده است که از محدود کردن نرخ(rate limiting)، SSL termination، احراز هویت(authentication)، whitelisting IP، سرویس دادن به محتوای ثابت(static content) و غیره پشتیبانی می کند. در حال حاضر، فقط باید بدانیم که دروازه API یک میان افزار(Middlware) است که از محدود کردن نرخ پشتیبانی می کند.در هنگام طراحی یک محدود کننده نرخ، یک سوال مهم که باید از خود بپرسیم این است: محدود کننده نرخ در کجا باید پیاده سازی شود، در سمت سرور یا در یک دروازه؟ هیچ پاسخ مطلقی وجود ندارد. این به پشته فناوری(technology stack) فعلی، منابع مهندسی، اولویت ها، اهداف و غیره شرکت شما بستگی دارد.در اینجا چند دستورالعمل کلی(general guidelines) وجود دارد:- پشته فناوری فعلی خود را ارزیابی کنید، مانند زبان برنامه نویسی، سرویس حافظه پنهان، و غیره. مطمئن شوید که زبان برنامه نویسی فعلی شما برای اجرای محدودیت نرخ در سمت سرور کارآمد است.- الگوریتم محدود کننده نرخ را که متناسب با نیازهای کسب و کار شما است، شناسایی کنید. وقتی همه چیز را در سمت سرور پیاده سازی می کنید، کنترل کامل الگوریتم را در اختیار دارید. با این حال، اگر از دروازه شخص ثالث استفاده کنید، ممکن است انتخاب شما محدود باشد.- اگر قبلاً از معماری میکروسرویس استفاده کرده اید و یک دروازه API در طراحی برای انجام احراز هویت، لیست سفید IP و غیره قرار داده اید، می توانید یک محدود کننده نرخ به دروازه API اضافه کنید.- ایجاد خدمات محدود کننده نرخ خود زمان می برد. اگر منابع مهندسی کافی برای اجرای یک محدود کننده نرخ ندارید، یک دروازه تجاری(commercial API gateway) API گزینه بهتری است.الگوریتم های محدود کردن نرخ(Algorithms for rate limiting)محدود کردن نرخ را می توان با استفاده از الگوریتم های مختلف پیاده سازی کرد و هر کدام مزایا و معایب متمایز(distinct pros and cons) دارند. اگرچه این مطلب بر روی الگوریتم‌ها تمرکز نمی‌کند، درک آنها در سطح بالا به انتخاب الگوریتم یا ترکیبی از الگوریتم‌ها متناسب با موارد استفاده ما کمک می‌کند. در اینجا لیستی از الگوریتم های محبوب وجود دارد:• سطل توکن (Token bucket)• سطل نشتی (Leaking bucket)• شمارنده پنجره ثابت (Fixed window counter)• لاگ پنجره کشویی (Sliding window log)• شمارنده پنجره کشویی (Sliding window counter)الگوریتم سطل توکن (Token bucket)الگوریتم سطل توکن به طور گسترده برای محدود کردن نرخ استفاده می شود. این الگوریتم ساده است، به خوبی درک می شود و معمولاً توسط شرکت های اینترنتی استفاده می شود. هر دو آمازون [5] و Stripe [6] از این الگوریتم برای کاهش درخواست های API خود استفاده می کنند.الگوریتم سطل توکن به صورت زیر عمل می کند:• سطل توکن ظرفی است که دارای ظرفیت از پیش تعریف شده است. توکن ها به صورت دوره ای با نرخ های از پیش تعیین شده در سطل قرار می گیرند. پس از پر شدن سطل، هیچ توکن دیگری اضافه نمی شود. همانطور که در شکل 4-4 نشان داده شده است، ظرفیت سطل توکن 4 است. پرکننده در هر ثانیه 2 توکن را در سطل قرار می دهد. پس از پر شدن سطل، توکن های اضافی سرریز می شوند.• هر درخواست یک توکن مصرف می کند. وقتی درخواستی می رسد، بررسی می کنیم که آیا توکن های کافی در سطل وجود دارد یا خیر. شکل 4-5 نحوه عملکرد آن را توضیح می دهد.• اگر توکن های کافی وجود داشته باشد، برای هر درخواست یک توکن بیرون می آوریم و درخواست انجام می شود.• اگر نشانه های کافی وجود نداشته باشد، درخواست حذف می شود.شکل 4-6 نحوه عملکرد منطق مصرف توکن، پر کردن مجدد و نرخ محدود کننده را نشان می دهد. در این مثال، اندازه سطل توکن 4 است و نرخ پر کردن مجدد 4 در هر 1 دقیقه است.الگوریتم سطل توکن دو پارامتر دارد:• اندازه سطل(Bucket size): حداکثر تعداد توکن های مجاز در سطل• نرخ پر کردن مجدد(Refill rate): تعداد توکن هایی که در هر ثانیه در سطل قرار می گیرندچند سطل نیاز داریم؟ این متفاوت است و به قوانین محدودکننده نرخ بستگی دارد. در اینجا چند نمونه هستند.• معمولاً وجود سطل های مختلف برای نقاط انتهایی API مختلف ضروری است. به عنوان مثال، اگر کاربر مجاز است در هر ثانیه 1 پست بگذارد، 150 دوست در روز اضافه کند و 5 پست در ثانیه لایک کند، 3 سطل برای هر کاربر مورد نیاز است.• اگر بخواهیم درخواست ها را بر اساس آدرس های IP کاهش دهیم، هر آدرس IP به یک سطل نیاز دارد.• اگر سیستم حداکثر 10000 درخواست در ثانیه را مجاز کند، منطقی است که یک سطل عمومی مشترک بین همه درخواست ها وجود داشته باشد.مزایا(Pros):• پیاده سازی الگوریتم آسان است.• حافظه کارآمد (Memory efficient).• سطل توکن اجازه می دهد تا برای مدت کوتاهی از ترافیک عبور کند. تا زمانی که نشانه‌هایی باقی مانده باشد، درخواست می‌تواند انجام شود.معایب(Cons):• دو پارامتر در الگوریتم اندازه سطل و نرخ پر کردن توکن است. با این حال، تنظیم صحیح آنها ممکن است چالش برانگیز باشد.الگوریتم سطل نشت (Leaking bucket algorithm)الگوریتم سطل نشت مشابه سطل توکن است با این تفاوت که درخواست ها با نرخ ثابتی پردازش می شوند. معمولاً با صف اولین ورود، اولین خروج(FIFO) اجرا می شود. الگوریتم به صورت زیر کار میکند:• هنگامی که درخواستی می رسد، سیستم بررسی می کند که آیا صف پر است یا خیر. اگر پر نباشد، درخواست به صف اضافه می شود.• در غیر این صورت درخواست منتفی می شود.• درخواست ها از صف بیرون کشیده می شوند و در فواصل زمانی معین پردازش می شوند. شکل 4-7 نحوه عملکرد الگوریتم را توضیح می دهد.الگوریتم سطل نشت دو پارامتر زیر را می گیرد:• اندازه سطل: برابر با اندازه صف است. صف درخواست ها را برای پردازش با نرخ ثابت نگه می دارد.• نرخ خروج: تعیین می کند که چه تعداد درخواست را می توان با نرخ ثابت، معمولاً در چند ثانیه، پردازش کرد.Shopify، یک شرکت تجارت الکترونیک، از سطل های نشتی برای محدود کردن نرخ استفاده می کند [7].مزایا(Pros):• حافظه کارآمد با توجه به اندازه صف محدود.• درخواست ها با یک نرخ ثابت پردازش می شوند، بنابراین برای موارد استفاده که نرخ خروجی پایدار مورد نیاز است مناسب است.معایب(Cons):• انبوهی از ترافیک، صف را با درخواست های قدیمی پر می کند، و اگر به موقع به آنها رسیدگی نشود، درخواست های اخیر دارای نرخ محدود خواهند بود.• دو پارامتر در الگوریتم وجود دارد. ممکن است تنظیم صحیح آنها آسان نباشد.الگوریتم شمارنده پنجره ثابت(Fixed window counter algorithm)الگوریتم شمارنده پنجره ثابت به صورت زیر عمل می کند:• الگوریتم جدول زمانی را به پنجره های زمانی با اندازه ثابت تقسیم می کند و برای هر پنجره یک شمارنده اختصاص می دهد.• هر درخواست شمارنده را یک عدد افزایش می دهد.• هنگامی که شمارنده به آستانه از پیش تعریف شده رسید، درخواست های جدید حذف می شوند تا زمانی که یک پنجره زمانی جدید شروع شود.اجازه دهید از یک مثال عینی استفاده کنیم تا ببینیم چگونه کار می کند. در شکل 4-8 واحد زمان 1 ثانیه است و سیستم حداکثر 3 درخواست در ثانیه را می دهد. در هر پنجره دوم، اگر بیش از 3 درخواست دریافت شود، درخواست های اضافی همانطور که در شکل 4-8 نشان داده شده است حذف می شوند.مشکل اصلی این الگوریتم این است که یک رگبار ترافیک در لبه‌های پنجره‌های زمانی می‌تواند باعث درخواست‌های بیشتر از حد مجاز شود. مورد زیر را در نظر بگیرید:در شکل 4-9، سیستم حداکثر 5 درخواست در دقیقه را مجاز می‌سازد و سهمیه موجود در دقیقه دور انسان پسند بازنشانی می‌شود. همانطور که مشاهده شد، پنج درخواست بین ساعت 2:00:00 تا 2:01:00 و پنج درخواست دیگر بین ساعت 2:01:00 تا 2:02:00 وجود دارد. برای پنجره یک دقیقه ای بین ساعت 2:00:30 تا 2:01:30، 10 درخواست ارسال می شود. این دو برابر درخواست های مجاز است.مزایا(Pros):• حافظه کارآمد.• آسان برای درک.• بازنشانی سهمیه موجود در پایان یک پنجره زمانی واحد متناسب با موارد استفاده خاص است.معایب(Cons):• افزایش ترافیک در لبه های یک پنجره می تواند باعث درخواست‌های بیشتر از حد مجاز شود.الگوریتم لاگ پنجره کشویی(Sliding window log algorithm)همانطور که قبلاً بحث شد، الگوریتم شمارنده پنجره ثابت یک مشکل اساسی دارد: اجازه می دهد تا درخواست های بیشتری از لبه های یک پنجره عبور کنند. الگوریتم لاگ پنجره کشویی مشکل را برطرف می کند. به صورت زیر عمل می کند:• الگوریتم درخواست ها را بر اساس(timestamps) پیگیری می کند. داده های مهر زمانی(timestamp) معمولاً در حافظه پنهان(Cache) نگهداری می شوند، مانند مجموعه های مرتب شده Redis [8].• وقتی درخواست جدیدی وارد شد، تمام مُهرهای زمانی قدیمی (outdated) را حذف کنید. مهرهای زمانی منسوخ شده (outdated) به عنوان مهرهای قدیمی‌تر از شروع پنجره زمانی فعلی تعریف می‌شوند.• مُهر زمانی (timestamp) درخواست جدید را به گزارش اضافه کنید.• اگر اندازه گزارش یکسان یا کمتر از تعداد مجاز باشد، درخواست پذیرفته می شود. در غیر این صورت مردود است.ما الگوریتم را با مثالی که در شکل 4-10 نشان داده شده است توضیح می دهیم.در این مثال، محدود کننده نرخ اجازه 2 درخواست در دقیقه را می دهد. معمولاً مُهرهای زمانی(timestamp) لینوکس در لاگ ذخیره می‌شوند. با این حال، نمایش زمان قابل خواندن توسط انسان در مثال ما برای خوانایی بهتر استفاده شده است.• هنگامی که یک درخواست جدید در ساعت 1:00:01 می رسد، گزارش خالی است. بنابراین، درخواست مجاز است.• یک درخواست جدید در ساعت 1:00:30 می رسد، مهر زمانی 1:00:30 در گزارش درج می شود. پس از درج، اندازه سیاهه 2 است، نه بزرگتر از تعداد مجاز. بنابراین، درخواست مجاز است.• یک درخواست جدید در ساعت 1:00:50 می رسد و مهر زمانی در گزارش درج می شود. پس از درج، اندازه گزارش 3 است، بزرگتر از اندازه مجاز 2. بنابراین، این درخواست رد می شود حتی اگر مهر زمانی timestamp در گزارش باقی بماند.• یک درخواست جدید در ساعت 1:01:40 می رسد. درخواست‌هایی در محدوده [1:00:40،1:01:40) در آخرین بازه زمانی هستند، اما درخواست‌هایی که قبل از ساعت 1:00:40 ارسال می‌شوند قدیمی هستند. دو مهر زمانی قدیمی، 1:00:01 و 1:00:30، از گزارش حذف می‌شوند. پس از عملیات حذف، اندازه لاگ 2 می شود. لذا درخواست پذیرفته میشودمزایا(Pros):• محدودیت نرخ اجرا شده توسط این الگوریتم بسیار دقیق است. در هر پنجره متحرک، درخواست ها از حد مجاز تجاوز نمی کنند.معایب(Cons):• الگوریتم حافظه زیادی مصرف می کند زیرا حتی اگر درخواستی رد شود، ممکن است مهر زمانی آن همچنان در حافظه ذخیره شود.الگوریتم شمارنده پنجره کشویی(Sliding window counter algorithm)الگوریتم شمارنده پنجره کشویی یک رویکرد ترکیبی است که شمارنده پنجره ثابت و گزارش پنجره کشویی را ترکیب می کند. الگوریتم را می توان با دو رویکرد متفاوت پیاده سازی کرد. ما در این بخش یکی از پیاده سازی ها را توضیح خواهیم داد و در پایان بخش مرجعی را برای اجرای دیگر ارائه می دهیم. شکل 4-11 نحوه عملکرد این الگوریتم را نشان می دهد.فرض کنید محدود کننده نرخ حداکثر 7 درخواست در دقیقه را می دهد و 5 درخواست در دقیقه قبل و 3 درخواست در دقیقه فعلی وجود دارد. برای یک درخواست جدید که در دقیقه جاری به موقعیت 30% می رسد، تعداد درخواست ها در پنجره چرخشی با استفاده از فرمول زیر محاسبه می شود:• درخواست ها در پنجره فعلی + درخواست ها در پنجره قبلی * درصد همپوشانی پنجره متحرک و پنجره قبلی• با استفاده از این فرمول 3 + 5 * 0.7% = 6.5 درخواست دریافت می کنیم. بسته به مورد استفاده، عدد را می توان به بالا یا پایین گرد کرد. در مثال ما به 6 گرد شده است.از آنجایی که محدود کننده نرخ حداکثر 7 درخواست در دقیقه را می دهد، درخواست فعلی می تواند انجام شود. با این حال، پس از دریافت یک درخواست دیگر، به حد مجاز خواهد رسید.به دلیل محدودیت فضا، در اینجا به اجرای دیگر نمی پردازیم. خوانندگان علاقه مند باید به مطالب مرجع [9] مراجعه کنند. این الگوریتم کامل نیست. مزایا و معایب دارد.مزایا(Pros):• جهش های ترافیک را هموار می کند زیرا نرخ بر اساس میانگین نرخ پنجره قبلی است.• حافظه کارآمد.معایب(Cons):این فقط برای نگاه به پشت پنجره نه چندان دقیق کار می کند. این تقریبی از نرخ واقعی است زیرا فرض می کند درخواست های پنجره قبلی به طور مساوی توزیع شده اند. با این حال، این مشکل ممکن است آنقدرها هم که به نظر می رسد بد نباشد. بر اساس آزمایش‌های انجام‌شده توسط Cloudflare [10]، تنها 0.003٪ از درخواست‌ها به اشتباه مجاز هستند یا در بین 400 میلیون درخواست محدود می‌شوند.معماری سطح بالا (High-level architecture)ایده اصلی الگوریتم های محدود کننده نرخ ساده است. در سطح بالا، ما به یک شمارنده برای پیگیری تعداد درخواست ارسال شده از یک کاربر، آدرس IP و غیره نیاز داریم. اگر شمارنده بزرگتر از حد مجاز باشد، درخواست غیرمجاز است.کانترها را کجا ذخیره کنیم؟ استفاده از پایگاه داده به دلیل کندی دسترسی به دیسک ایده خوبی نیست. کش درون حافظه به این دلیل انتخاب شده است که سریع است و از استراتژی انقضا مبتنی بر زمان پشتیبانی می کند. به عنوان مثال، Redis [11] یک گزینه محبوب برای اجرای محدودیت نرخ است. این یک فروشگاه در حافظه است که دو دستور را ارائه می دهد: INCR و EXPIRE.• : در INCR شمارنده ذخیره شده را 1 افزایش می دهد.• در EXPIR: یک بازه زمانی برای شمارنده تعیین می کند. اگر مهلت زمانی منقضی شود، شمارنده به طور خودکار حذف می شود.شکل 4-12 معماری سطح بالا برای محدود کردن نرخ را نشان می دهد و این کار به شرح زیر است:• کلاینت درخواستی را به میان افزار محدود کننده نرخ می فرستد.• میان افزار محدود کننده نرخ(Rate limiting middleware)، شمارنده را از سطل مربوطه(corresponding bucket) در Redis می آورد و بررسی می کند که آیا به حد مجاز رسیده است یا خیر.• در صورت رسیدن به حد مجاز، درخواست رد می شود.• در صورت عدم رسیدن به حد مجاز، درخواست به سرورهای API ارسال می شود. در همین حال، سیستم شمارنده را افزایش می دهد و آن را به Redis ذخیره می کند.گام سوم: بررسی عمیق طراحی (Design deep dive)طراحی سطح بالا در شکل 4-12 به سوالات زیر پاسخ نمی دهد:• قوانین محدود کننده نرخ چگونه ایجاد می شوند؟ قوانین کجا ذخیره می شوند؟• چگونه به درخواست هایی رسیدگی کنیم که دارای نرخ محدود هستند؟در این بخش ابتدا به سوالات مربوط به قوانین محدود کننده نرخ پاسخ می دهیم و سپس به بررسی استراتژی های رسیدگی به درخواست های محدود با نرخ می پردازیم. در نهایت، ما محدودیت نرخ در محیط توزیع شده، طراحی دقیق، بهینه سازی عملکرد و نظارت را مورد بحث قرار خواهیم داد.قوانین محدود کننده نرخ(Rate limiting rules)در اینجا ما درون یکی از کامپوننت های شرکت Lyft، (Lyft open-sourced their rate-limiting component [12]) نگاه می کنیم و نمونه هایی از محدود کردن نرخ را بررسی می کنیم.در مثال بالا، سیستم به گونه ای پیکربندی شده است که حداکثر 5 پیام بازاریابی در روز مجاز باشد.در اینجا یک مثال دیگر وجود دارد:این قانون نشان می دهد که کلاینت ها مجاز به ورود بیش از 5 بار در 1 دقیقه نیستند. قوانین معمولاً در فایل های پیکربندی نوشته شده و روی دیسک ذخیره می شوندوضعیت خارج از محدودیت نرخ (Exceeding the rate limit)در صورتی که درخواستی با نرخ محدود مواجه شود، APIها کد پاسخ HTTP 429 (درخواست‌های بسیار زیاد) را به کلاینت برمی‌گردانند. بسته به موارد استفاده، ممکن است درخواست‌های با نرخ محدود را در نوبت قرار دهیم تا بعداً پردازش شوند. برای مثال، اگر نرخ برخی از سفارش‌ها به دلیل بارگذاری بیش از حد سیستم محدود باشد، ممکن است آن سفارش‌ها را نگه داریم تا بعداً پردازش شوند.هدرهای محدود کننده نرخ(Rate limiter headers)کلاینت چگونه متوجه می شود که در حال ارسال درخواست بیش از حد است؟ و چگونه یک کلاینت تعداد درخواست‌های باقیمانده مجاز را قبل از خنثی شدن می‌داند؟ پاسخ در هدرهای پاسخ HTTP نهفته است. محدود کننده نرخ هدرهای HTTP زیر را به کلاینتان برمی گرداند:- X-Ratelim-Remaining : تعداد باقیمانده درخواست های مجاز در پنجره.• X-Ratelimit-Limit : نشان می دهد که کلاینت می تواند در هر پنجره زمانی چند تماس برقرار کند.• X- Ratelimit-Retry-After : تعداد ثانیه هایی که باید منتظر بمانید تا بتوانید مجدداً درخواستی را بدون درنگ انجام دهد.هنگامی که یک کاربر درخواست های زیادی ارسال کرده است، خطای 429 بیش از حد درخواست و هدر X-Ratelimit-Retry-After به کلاینت برگردانده می شود.طراحی دقیق و با جزییات(Detailed design)شکل 4-13 طراحی دقیق سیستم را نشان می دهد.• قوانین روی دیسک ذخیره می شوند. کارگران(Workers) اغلب قوانین را از دیسک بیرون می کشند و آنها را در حافظه پنهان ذخیره می کنند.• هنگامی که کلاینت درخواستی را به سرور ارسال می کند، ابتدا درخواست به میان افزار محدود کننده نرخ ارسال می شود.• میان افزارهای محدود کننده نرخ قوانین را از حافظه پنهان بارگذاری می کند. شمارنده ها و آخرین زمان درخواست را از کش Redis واکشی می کند. بر اساس پاسخ، محدود کننده نرخ تصمیم می گیرد:- اگر درخواست محدود به نرخ نباشد، به سرورهای API ارسال می شود.-اگر درخواست با نرخ محدود باشد، محدود کننده نرخ 429 خطای درخواست های بسیار زیاد را به کلاینت برمی گرداند. در این بین، درخواست یا حذف می شود یا به صف ارسال می شود.محدود کننده نرخ در یک محیط توزیع شدهساختن یک محدود کننده نرخ که در یک محیط سرور تک کار می کند کار سختی نیست. با این حال، مقیاس بندی سیستم برای پشتیبانی از چندین سرور و رشته های همزمان داستان متفاوتی است. دو چالش وجود دارد:• شرایط مسابقه(Race Condition)• مشکل همگام سازی(Synchronization issue)شرایط مسابقه(Race condition)یک شرط مسابقه زمانی رخ می دهد که دو نخ به طور همزمان به یک متغیر مشترک دسترسی داشته باشند.همانطور که قبلاً بحث شد، محدود کننده نرخ در سطح بالا به شرح زیر عمل می کند:• مقدار شمارنده را از Redis بخوانید.• بررسی کنید که آیا ( شمارنده + 1 ) از آستانه فراتر رفته است یا خیر.• اگر نه، مقدار شمارنده را 1 در Redis افزایش دهید.شرایط مسابقه می تواند در یک محیط بسیار همزمان اتفاق بیفتد همانطور که در شکل 4-14 نشان داده شده است.فرض کنید مقدار شمارنده در Redis 3 باشد. اگر دو درخواست به طور همزمان مقدار شمارنده را بخوانند قبل از اینکه هر یک از آنها مقدار را به عقب بنویسد، هر کدام شمارنده را یک برابر افزایش داده و بدون بررسی رشته دیگر آن را دوباره می نویسند. هر دو درخواست (رشته ها) معتقدند که مقدار شمارنده صحیح 4 را دارند. با این حال، مقدار شمارنده صحیح باید 5 باشد.قفل ها(Locks) واضح ترین راه حل برای حل شرایط مسابقه هستند. با این حال، قفل ها به طور قابل توجهی سرعت سیستم را کاهش می دهند. دو استراتژی معمولا برای حل مشکل استفاده می شود: اسکریپت Lua [13] و ساختار داده مجموعه های مرتب شده در Redis [8]. برای خوانندگان علاقه مند به این استراتژی ها، به منابع مرجع مربوطه [8] [13] مراجعه کنید.مشکل همگام سازی(Synchronization issue)همگام سازی عامل مهم دیگری است که در یک محیط توزیع شده باید در نظر گرفته شود. برای پشتیبانی از میلیون‌ها کاربر، یک سرور محدودکننده نرخ ممکن است برای مدیریت ترافیک کافی نباشد. هنگامی که چندین سرور محدود کننده نرخ استفاده می شود، همگام سازی مورد نیاز است. به عنوان مثال، در سمت چپ شکل 4-15، کلاینت 1 درخواست ها را به محدود کننده نرخ 1 ارسال می کند، و سرویس گیرنده 2 درخواست ها را به محدود کننده نرخ 2 ارسال می کند. از آنجایی که لایه وب بدون حالت است، کلاینتان می توانند درخواست ها را به یک محدود کننده نرخ متفاوت ارسال کنند. در سمت راست شکل 4-15. اگر همگام سازی اتفاق نیفتد، محدود کننده نرخ 1 حاوی هیچ داده ای در مورد کلاینت 2 نیست. بنابراین، محدود کننده نرخ نمی تواند به درستی کار کند.یکی از راه حل های ممکن استفاده از جلسات چسبنده(sticky sessions) است که به کلاینت امکان می دهد ترافیک را به همان محدود کننده نرخ ارسال کند. این راه حل توصیه نمی شود زیرا نه مقیاس پذیر است و نه انعطاف پذیر. یک رویکرد بهتر استفاده از پایگاه داده متمرکز (centralized data stores) مانند Redis است. طرح در شکل 4-16 نشان داده شده است.بهینه سازی عملکرد(Performance optimization)بهینه سازی عملکرد یک موضوع رایج در طراحی سیستم است. ما دو حوزه را برای بهبود پوشش خواهیم داد.اولاً، راه‌اندازی چند مرکز داده برای محدودکننده نرخ بسیار مهم است، زیرا تأخیر برای کاربرانی که دور از مرکز داده هستند بالا است. اکثر ارائه دهندگان خدمات ابری مکان های سرور لبه زیادی در سراسر جهان ایجاد می کنند. به عنوان مثال، از تاریخ 5/20 2020، Cloudflare دارای 194 سرور لبه توزیع شده جغرافیایی است [14]. برای کاهش تأخیر، ترافیک به طور خودکار به نزدیکترین سرور لبه هدایت می شود.دوم، همگام سازی داده ها با یک مدل سازگاری نهایی. اگر در مورد مدل سازگاری نهایی نامشخص هستید، به بخش "ثبات" در "فصل 6: طراحی فروشگاه با ارزش کلیدی" مراجعه کنید.نظارت (Monitoring)پس از نصب محدود کننده نرخ، جمع آوری داده های تحلیلی برای بررسی اینکه آیا محدود کننده نرخ موثر است یا خیر، مهم است. در درجه اول، ما می خواهیم مطمئن شویم:• الگوریتم محدود کننده نرخ موثر است.• قوانین محدود کننده نرخ موثر هستند.برای مثال، اگر قوانین محدودکننده نرخ بسیار سخت‌گیرانه باشد، بسیاری از درخواست‌های معتبر حذف می‌شوند. در این صورت می خواهیم کمی قوانین را آرام کنیم. در مثالی دیگر، متوجه می‌شویم که محدودکننده نرخ زمانی که افزایش ناگهانی ترافیک مانند فروش فلش وجود دارد، بی‌اثر می‌شود. در این سناریو، ممکن است الگوریتمی را برای پشتیبانی از ترافیک پشت سر هم جایگزین کنیم. سطل توکن در اینجا مناسب است.منبع اصلیhttps://systeminterview.com/scale-from-zero-to-millions-of-users.phpسایر منابع[1] Rate-limiting strategies and techniques: https://cloud.google.com/solutions/rate-limiting- strategies-techniques[2] Twitter rate limits: https://developer.twitter.com/en/docs/basics/rate-limits[3] Google docs usage limits: https://developers.google.com/docs/api/limits[4] IBM microservices: https://www.ibm.com/cloud/learn/microservices[5] Throttle API requests for better throughput:https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request- throttling.html[6] Stripe rate limiters: https://stripe.com/blog/rate-limiters[7] Shopify REST Admin API rate limits: https://help.shopify.com/en/api/reference/rest- admin-api-rate-limits[8] Better Rate Limiting With Redis Sorted Sets: https://engineering.classdojo.com/blog/2015/02/06/rolling-rate-limiter/[9] System Design — Rate limiter and Data modelling: https://medium.com/@saisandeepmopuri/system-design-rate-limiter-and-data-modelling- 9304b0d18250[10] How we built rate limiting capable of scaling to millions of domains:https://blog.cloudflare.com/counting-things-a-lot-of-different-things/[11] Redis website: https://redis.io/[12] Lyft rate limiting: https://github.com/lyft/ratelimit اسماعیل شهبازی نژاد اسماعیل شهبازی نژاد Fri, 03 Jun 2022 20:10:16 +0430 https://virgool.io/@es.shahbazi/%DA%86%D8%B1%D8%AE%D9%87-%D8%AD%DB%8C%D8%A7%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7sdlc-rhhyelicdy86 چرخه حیات توسعه سیستم ها( THE SYSTEMS DEVELOPMENT LIFE CYCLE) فرآیند درک این موضوع است که چگونه یک سیستم اطلاعاتی(IS) می تواند با طراحی یک سیستم، ساخت و تحویل آن به کاربران، نیازهای کسب وکار یا سازمان را پشتیبانی کند.چرخه حیات توسعه سیستم ها - متدولوژی Agileشخص کلیدی در SDLC تحلیلگر سیستم است که کسب و کار را تجزیه و تحلیل می کند، فرصت های بهبود را شناسایی کرده و یک سیستم اطلاعاتی برای پیاده سازی آنها طراحی می کند. تجزیه و تحلیل سیستم یکی از شغل های جالب، هیجان انگیز و چالش برانگیز است. تحلیلگران سیستم با افراد متنوعی همکاری می کنند و روش انجام کار خود را همزمان توسعه می دهند. به طور خاص، آنها با تیمی از تحلیلگران سیستم، برنامه نویسان و دیگران در یک مأموریت مشترک کار می کنند. تحلیلگران سیستم با مشاهده تأثیر قابل توجه سیستم های تحلیل و طراحی شده توسط آنها در کسب و کار و سازمان؛ احساس رضایت می کنند، زیرا می دانند مهارت های منحصر به فردشان تحقق این امر را در بر داشته است.با این حال، هدف اولیه یک تحلیلگر سیستم ایجاد یک سیستم فوق العاده نیست. در عوض، ایجاد ارزش برای سازمان است، که برای بیشتر شرکت ها به معنای افزایش سود است (سازمان های دولتی و سازمان های غیر انتفاعی ارزش را متفاوت اندازه گیری می کنند). سیستم های زیادی وجودی دارد که شکست خورده رها شده اند زیرا تحلیلگران سعی کرده اند یک سیستم فوق العاده بسازند بدون اینکه به وضوح درک کنند که چگونه این سیستم با اهداف سازمان، فرآیندهای تجاری فعلی و سایر سیستم های اطلاعاتی برای ارائه ارزش مطابقت دارد. سرمایه گذاری در یک سیستم اطلاعاتی مانند هر سرمایه گذاری دیگری است. هدف دستیابی به ابزار نیست، زیرا ابزار صرفاً وسیله ای برای رسیدن به هدف است. هدف این است که سازمان را قادر سازد تا کار خود را بهتر انجام دهد تا بتواند سود بیشتری کسب کند یا به صورت موثرتر به اعضای خود خدمت کند.ساخت سیستم اطلاعاتی از بسیاری جهات مشابه ساخت خانه است. اول، خانه (یا سیستم اطلاعاتی) با یک ایده اساسی شروع می شود. دوم، این ایده به یک طراحی ساده تبدیل می شود که به مشتری نشان داده می شود و به مرور دقیق تر می شود تا زمانی که مشتری موافقت کند که تصویر آنچه را که می خواهد نشان می دهد. سوم، مجموعه ای از نقشه های اولیه طراحی شده است که اطلاعات بسیار دقیق تری در مورد خانه ارائه می دهد (به عنوان مثال، نوع شیر آب یا محل قرارگیری فیش های تلفن). سرانجام، خانه با پیروی از نقشه ها ساخته می شود، که اغلب با ایجاد تغییراتی توسط مشتری به وجود می آید.این چرخه دارای مجموعه مشابهی از چهار فاز اساسی است: برنامه ریزی، تجزیه و تحلیل، طراحی و پیاده سازی. پروژه های مختلف ممکن است قسمتهای مختلف SDLC را مورد تأکید قرار دهند یا از راه های مختلف به مراحل SDLC نزدیک شوند، اما همه پروژه ها عناصر این چهار فاز را دارند. هر فاز خود از مجموعه ای از مراحل تشکیل شده است که متکی به تکنیک هایی است که محصولات قابل تحویل را تولید می کند (اسناد و فایل های خاصی که درک درستی از پروژه را ارائه می دهند.)برنامه ریزی(Planning)فاز برنامه ریزی فرآیند اساسی درک این مسئله است که چرا باید یک سیستم اطلاعاتی ساخته شود و نحوه کار تیم پروژه برای ساختن آن مشخص شود.این فاز دو مرحله دارد:1. در حین شروع پروژه، ارزش تجاری سیستم برای سازمان مشخص می شود: چگونه هزینه ها را کاهش می دهد یا درآمد را افزایش می دهد؟ بیشتر ایده ها برای سیستم های جدید از خارج از حوزه IS (به عنوان مثال، از بخش بازاریابی، بخش حسابداری) در قالب درخواست سیستم ارائه می شوند. یک درخواست سیستم خلاصه ای از نیازهای تجاری را ارائه می دهد، و توضیح می دهد که چگونه سیستمی که این نیاز را پشتیبانی می کند، ارزش تجاری را ایجاد می کند. بخش IS با فرد یا بخشی که درخواست را ایجاد کرده است (به عنوان کارفرمای پروژه) برای انجام تجزیه و تحلیل امکان سنجی کار می کند.درخواست سیستم و تجزیه و تحلیل امکان سنجی به کمیته تأیید سیستم های اطلاعاتی (که بعضاً به عنوان کمیته راهبری نیز خوانده می شود) ارائه می شود، که تصمیم می گیرد که آیا پروژه انجام شود.2. پس از تصویب پروژه، وارد مدیریت پروژه می شود. در طول مدیریت پروژه، مدیر پروژه یک برنامه کاری ایجاد می کند، پروژه را مدیریت می کند و روشهایی را برای کمک به تیم پروژه در کنترل و هدایت پروژه از طریق کل SDLC ارائه می دهد. مورد تحویل برای مدیریت پروژه یک طرح پروژه است، که نحوه کار تیم پروژه برای توسعه سیستم را توصیف می کند.تحلیل و بررسی(Analysis)فاز تجزیه و تحلیل به این سوالات پاسخ می دهد که چه کسی از سیستم استفاده خواهد کرد، سیستم چه کاری انجام خواهد داد و کجا و چه زمانی استفاده می شود. در طول این مرحله، تیم پروژه هر سیستم (سیستم) فعلی را بررسی می کند، فرصت های بهبود را شناسایی می کند و مفهومی برای سیستم جدید ایجاد می کند.این فاز سه مرحله دارد:1. یک استراتژی تجزیه و تحلیل برای هدایت تلاش های تیم پروژه تدوین شده است. چنین استراتژی معمولاً شامل تجزیه و تحلیل سیستم فعلی (سیستم موجود) و مشکلات آن و سپس راههای طراحی سیستم جدید (به نام سیستم آینده) است.2. مرحله بعدی جمع آوری نیازها است (به عنوان مثال، از طریق مصاحبه یا پرسشنامه). تجزیه و تحلیل این اطلاعات - همراه با دریافت اطلاعاتی از طرف کارفرمای پروژه و افراد دیگر - منجر به توسعه مفهومی برای سیستم جدید می شود. سپس از مفهوم سیستم به عنوان پایه ای برای توسعه مجموعه ای از مدل های تجزیه و تحلیل کسب و کار استفاده می شود، که نحوه عملکرد کسب و کار در صورت استفاده از سیستم جدید توسعه یافته است.3. تجزیه و تحلیل ها، مفهوم سیستم و مدل ها در سندی به نام پیشنهاد سیستم ترکیب می شوند که به کارفرمای پروژه و سایر تصمیم گیرندگان اصلی (مثلاً اعضای کمیته تأیید) ارائه می شود که در مورد ادامه پروژه تصمیم می گیرند حرکت به جلو پیشنهاد سیستم تحویل اولیه است که توصیف می کند سیستم جدید چه نیازهای تجاری را باید برآورده کند.از آنجا که این فاز واقعاً اولین قدم در طراحی سیستم جدید است، برخی از کارشناسان استدلال می کنند که استفاده از اصطلاح "تجزیه و تحلیل"“analysis” به عنوان نام این مرحله نامناسب است. برخی معتقدند که نام بهتر “analysis and initial design” "تجزیه و تحلیل و طراحی اولیه" است. بیشتر سازمانها همچنان از نام تجزیه و تحلیل برای این مرحله استفاده می کنند، بنابراین ما در این کتاب نیز از آن استفاده می کنیم. فقط بخاطر داشته باشید که محصول قابل تحویل از مرحله تجزیه و تحلیل هم یک طراحی اولیه و هم سطح بالایی برای سیستم جدید است.طراحی(Design)فاز طراحی از نظر سخت افزار، نرم افزار و زیرساخت شبکه نحوه عملکرد سیستم را در مورد رابط کاربری، فرم ها و گزارش ها، برنامه ها، پایگاه های داده و موارد و فایل های مورد نیاز تعیین می کند. اگرچه بیشتر تصمیمات استراتژیک در مورد سیستم در توسعه مفهوم سیستم در مرحله تجزیه و تحلیل گرفته شده است، مراحل انجام مرحله طراحی دقیقاً نحوه عملکرد سیستم را تعیین می کند.مرحله طراحی دارای چهار مرحله است:1. استراتژی طراحی(The design strategy) ابتدا تدوین می شود. این روش روشن می کند که آیا سیستم توسط برنامه نویسان شرکت توسعه می یابد، آیا سیستم به شرکت دیگری (معمولاً یک شرکت مشاور) سپرده می شود، یا اینکه این شرکت بسته نرم افزاری موجود را خریداری می کند.2. این امر منجر به توسعه طراحی معماری اساسی برای سیستم می شود که شامل سخت افزار، نرم افزار و زیرساخت شبکه مورد استفاده است. در بیشتر موارد، سیستم زیرساخت های موجود در سازمان را اضافه یا تغییر می دهد. طراحی رابط Navigation کاربران از طریق سیستم (به عنوان مثال، روشهای Navigation مانند منوها و دکمه های روی صفحه) و فرم ها و گزارش هایی را که سیستم استفاده خواهد کرد، مشخص می کند.3. توسعه پایگاه داده ها و مدیریت و توسعه فایل. این موارد دقیقاً مشخص می کنند چه داده هایی ذخیره می شوند و در کجا ذخیره می شوند.4- تیم تحلیل گر طراحی برنامه را توسعه می دهد، که برنامه هایی را که باید نوشته شوند و دقیقاً کاری که هر برنامه انجام می دهد تعریف می کند.این مجموعه قابل تحویل (طراحی معماری، طراحی رابط، مشخصات پایگاه داده و فایل و طراحی برنامه) مشخصات سیستم است که برای پیاده سازی به تیم برنامه نویسی تحویل داده می شود. در پایان مرحله طراحی، تجزیه و تحلیل امکان سنجی و برنامه پروژه مورد بررسی مجدد و بازنگری قرار می گیرد و تصمیم دیگری توسط کارفرمای پروژه و کمیته تصویب پروژه در مورد خاتمه پروژه یا ادامه آن گرفته می شود.پیاده سازی Implementationمرحله نهایی در SDLC مرحله پیاده سازی است که طی آن سیستم در واقع ساخته می شود (یا به صورت بسته نرم افزار خریداری می شود). این مرحله ای است که معمولاً بیشترین توجه را به خود جلب می کند، زیرا برای اکثر سیستم ها طولانی ترین و گرانترین قسمت تک فرآیند است. این فاز سه مرحله دارد:1. ساخت سیستم اولین قدم است. این سیستم برای اطمینان از عملکرد مطابق طراحی، ساخته و آزمایش شده است. از آنجا که هزینه اشکالات می تواند بسیار زیاد باشد، آزمایش یکی از مهمترین مراحل پیاده سازی است. بیشتر سازمانها بیشتر از نوشتن برنامه ها به تست زدن زمان و توجه بیشتری می دهند.2. سیستم نصب شده است. نصب فرآیندی است که در آن سیستم قدیمی خاموش و سیستم جدید روشن می شود. یکی از مهمترین جنبه های تبدیل، تهیه یک برنامه آموزشی برای آموزش نحوه استفاده از سیستم جدید و کمک به مدیریت تغییرات ناشی از سیستم جدید به کاربران است.3- تیم آنالیزور یک طرح پشتیبانی برای سیستم ایجاد می کند. این طرح معمولاً شامل بازبینی رسمی یا غیررسمی پس از اجرا و همچنین روشی سیستماتیک برای شناسایی تغییرات عمده و جزئی مورد نیاز سیستم است.منبع:Systems Analysis and Design: An Object-Oriented Approach with UML, 5th Edition by Dennis, Wixom, and Tegarden اسماعیل شهبازی نژاد اسماعیل شهبازی نژاد Fri, 03 Sep 2021 12:56:33 +0430 https://virgool.io/@es.shahbazi/%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%D8%AC%D9%85%D8%B9-%D8%A2%D9%88%D8%B1%DB%8C-%D9%86%DB%8C%D8%A7%D8%B2%D9%85%D9%86%D8%AF%DB%8C%D9%87%D8%A7%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-hm6m38xdl9y7 استراتژی های تجزیه و تحلیل نیازمندیها(REQUIREMENTS ANALYSIS STRATEGIES)قبل از اینکه تیم پروژه بتواند تعیین کند چه الزاماتی برای یک سیستم معین مناسب است، باید دید روشنی از نوع سیستمی که ایجاد می شود و سطح تغییری که برای سازمان ایجاد می کند وجود داشته باشد. فرآیند اصلی تجزیه و تحلیل به سه مرحله تقسیم می شود: درک سیستم همانطور که هست(as-is system)، شناسایی پیشرفت ها(identifying improvements)، و توسعه الزامات برای سیستم آینده(to-be system).گاهی اوقات مرحله اول (یعنی درک سیستم همانطور که هست) نادیده گرفته می شود یا به صورت گذرا انجام می شود. این موضوع زمانی اتفاق می‌افتد که هیچ سیستم فعلی وجود نداشته باشد، یا اگر سیستم و فرآیندهای موجود به سیستم آینده بی‌ربط باشند، و یا اینکه تیم پروژه از یک روش RAD یا توسعه چابک استفاده می‌کند که در آن سیستم همانطور که هست تاکید نشده است. تحلیلگران از استراتژی های تحلیل نیازمندی ها و تکنیک های جمع آوری نیازمندی ها برای جمع آوری دقیق اطلاعات و الزامات سیستم استفاده می کنند. استراتژی‌های تحلیل نیازمندی‌ها، نوع اطلاعاتی را که جمع‌آوری می‌شود و در نهایت چگونه تجزیه و تحلیل می‌شوند را هدایت می‌کند. استراتژی های تحلیل نیازمندی ها و جمع آوری نیازمندی ها همزمان اتفاق می افتند و فعالیت های مکمل یکدیگر هستند.برای انتقال کاربران از سیستم کنونی به سیستم آینده، یک تحلیلگر به مهارت های تفکر انتقادی قوی نیاز دارد. تفکر انتقادی توانایی تشخیص نقاط قوت و ضعف و بازنویسی یک ایده به شکل بهبود یافته است و برای درک واقعی مسائل و توسعه فرآیندهای تجاری جدید به مهارت های تفکر انتقادی نیاز است. این مهارت‌ها همچنین برای بررسی کامل نتایج جمع‌آوری نیازمندی‌ها، شناسایی نیازمندی‌های تجاری، و تبدیل آن الزامات به مفهومی برای سیستم جدید مورد نیاز است.تجزیه و تحلیل مشکل Problem Analysisساده ترین (و احتمالاً متداول ترین) تکنیک تحلیل نیازمندی ها، تحلیل مسئله است. تجزیه و تحلیل مشکل به معنای درخواست از کاربران و مدیران برای شناسایی مشکلات مربوط به سیستم همانطور که هست و نحوه حل آنها را در سیستم آینده توضیح می دهد. اکثر کاربران ایده بسیار خوبی از تغییراتی که دوست دارند ببینند دارند، و اکثر آنها کاملاً در مورد پیشنهاد آنها صحبت می کنند. بیشتر تغییرات به جای استفاده از فرصت ها به حل مشکلات تمایل دارند، اما دومی نیز امکان پذیر است. بهبودهای حاصل از تجزیه و تحلیل مشکل معمولاً کوچک و تدریجی هستند (به عنوان مثال، فضای بیشتری برای تایپ آدرس مشتری فراهم کنید؛ گزارش جدیدی ارائه کنید که در حال حاضر وجود ندارد).این نوع بهبود اغلب در بهبود کارایی یا سهولت استفاده سیستم بسیار مؤثر است. با این حال، اغلب فقط بهبودهای جزئی در ارزش تجاری ایجاد می کند.بررسی دلیل ریشه ای Root Cause Analysisایده های تولید شده توسط تجزیه و تحلیل مسئله معمولاً راه حلی برای مشکلات هستند. همه راه‌حل‌ها مفروضاتی را درباره ماهیت مسئله ایجاد می‌کنند، فرضیاتی که ممکن است معتبر باشند یا نباشند. در تجربه ما، کاربران (و بیشتر مردم به طور کلی) تمایل دارند بدون در نظر گرفتن کامل ماهیت مشکل، به سرعت به سراغ راه حل ها بروند. گاهی اوقات راه‌حل‌ها مناسب هستند، اما بسیاری از اوقات به نشانه‌های مشکل می‌پردازند، نه خود مشکل واقعی یا علت اصلی را.به عنوان مثال، فرض کنید یک شرکت متوجه می شود که کاربران آن کمبود موجودی انبار را گزارش می کنند. هزینه های موجودی انبار می تواند بسیار قابل توجه باشد. در این مورد، از آنجایی که این اتفاقات مکرر رخ می دهد، مشتریان می توانند منبع دیگری برای اقلامی که از شرکت خریداری می کنند، بیابند. این به نفع شرکت است که علت اصلی را تعیین کند و صرفاً یک واکنش تند و سریع مانند افزایش خودسرانه مقدار موجودی موجود در دسترس را ارائه ندهد. در دنیای تجارت، چالش در شناسایی علت اصلی نهفته است - معدود مشکلات دنیای واقعی ساده هستند. کاربران معمولاً مجموعه ای از دلایل را برای مشکل مورد بررسی پیشنهاد می کنند. راه‌حل‌هایی که کاربران پیشنهاد می‌کنند می‌توانند علائم یا علل ریشه‌ای را برطرف کنند، اما بدون تجزیه و تحلیل دقیق، تشخیص اینکه کدام یک مورد توجه قرار می‌گیرد دشوار است.بنابراین، تحلیل علت ریشه ای بر مشکلات تمرکز می کند، نه راه حل ها. تحلیلگر با ایجاد لیستی از مشکلات سیستم فعلی توسط کاربران شروع می کند و سپس مشکلات را به ترتیب اهمیت اولویت بندی می کند. با شروع از مهم‌ترین، کاربران و/یا تحلیل‌گران تمام دلایل ریشه‌ای ممکن را برای مشکلات ایجاد می‌کنند. هر علت احتمالی ریشه ای بررسی می شود (با محتمل ترین یا ساده ترین بررسی شروع می شود) تا زمانی که علل اصلی واقعی شناسایی شوند. اگر هر یک از علل ریشه ای احتمالی برای چندین مشکل شناسایی شده است، ابتدا باید آن ها را بررسی کرد، زیرا احتمال زیادی وجود دارد که علت اصلی اصلی موثر بر مشکلات علائم باشند. در مثال ما، چندین دلیل احتمالی وجود دارد:■ ممکن است تامین کننده شرکت سفارشات را به موقع به شرکت تحویل ندهد.■ ممکن است در کنترل موجودی شرکت مشکلی وجود داشته باشد.■ سطح سفارش مجدد و مقادیر ممکن است اشتباه تنظیم شوند.گاهی اوقات، استفاده از نمودار سلسله مراتبی برای نشان دادن روابط علی به تحلیل کمک می کند. همانطور که شکل 3-2 نشان می دهد، علل ریشه ای احتمالی زیادی وجود دارد که زمینه ساز علل سطح بالاتر شناسایی شده است. نکته کلیدی در تحلیل علت ریشه ای همیشه به چالش کشیدن چیزهای بدیهی است.تجزیه و تحلیل زمان Duration Cause Analysisتجزیه و تحلیل مدت زمان نیاز به بررسی دقیق مقدار زمان لازم برای انجام هر فرآیند در سیستم فعلی دارد. تحلیلگران با تعیین کل زمان لازم برای انجام مجموعه ای از فرآیندهای تجاری برای یک ورودی معمولی شروع می کنند. سپس هر یک از مراحل (یا زیرفرایندها) در فرآیند کسب و کار را زمان بندی می کنند. سپس زمان تکمیل مرحله اساسی جمع شده و با کل فرآیند کلی مقایسه می شود. تفاوت قابل توجه بین این دو و در تجربه ما، کل زمان اغلب می تواند 10 یا حتی 100 برابر بیشتر از مجموع قطعات باشد - نشان می دهد که این بخش از فرآیند به شدت نیاز به یک تعمیر اساسی دارد.به عنوان مثال، فرض کنید که تحلیلگران در حال کار بر روی یک سیستم وام مسکن خانه هستند و کشف می کنند که به طور متوسط ​​سی روز طول می کشد تا بانک یک وام مسکن را تایید کند. سپس به هر یک از مراحل اساسی فرآیند (به عنوان مثال، ورود داده ها، بررسی اعتبار، جستجوی عنوان، ارزیابی) نگاه می کنند و متوجه می شوند که کل زمان صرف شده برای هر وام مسکن حدود هشت ساعت است. این یک نشانه قوی است که روند کلی به شدت شکسته شده است، زیرا سی روز طول می کشد تا کار یک روز انجام شود.این مشکلات احتمالاً به این دلیل رخ می دهند که فرآیند به شدت پراکنده است. بسیاری از افراد مختلف باید قبل از پایان فرآیند فعالیت های مختلفی را انجام دهند. در مثال وام مسکن، برنامه احتمالاً قبل از پردازش، برای مدت طولانی روی میز بسیاری از افراد می‌نشیند.فرآیندهایی که در آن افراد مختلف روی بخش‌های کوچکی از ورودی‌ها کار می‌کنند، کاندیدهای اصلی برای یکپارچه‌سازی یا موازی‌سازی فرآیند هستند. ادغام فرآیند به معنای تغییر فرآیند اساسی است تا افراد کمتری روی ورودی کار کنند، که اغلب مستلزم تغییر فرآیندها و بازآموزی کارکنان برای انجام طیف وسیع‌تری از وظایف است. موازی سازی فرآیند به معنای تغییر فرآیند به گونه ای است که تمام مراحل منفرد به طور همزمان انجام شوند. به عنوان مثال، در پرونده درخواست وام مسکن، احتمالاً دلیلی وجود ندارد که بررسی اعتباری همزمان با ارزیابی و بررسی عنوان انجام نشود.هزینه یابی مبتنی بر فعالیت Activity-Based Costingهزینه یابی مبتنی بر فعالیت نیز تحلیل مشابهی است. به جای زمان صرف شده، هزینه هر فرایند یا مرحله اصلی در یک فرآیند تجاری را بررسی می کند. .تخصیص هزینه ها از نظر مفهومی ساده است. تحلیلگران به سادگی هزینه مستقیم نیروی کار و مواد را برای هر ورودی بررسی می کنند. هزینه های مواد به راحتی در یک فرآیند تولید تخصیص می یابد، در حالی که هزینه های نیروی کار معمولاً بر اساس مقدار زمان صرف شده برای ورودی و هزینه ساعتی کارکنان محاسبه می شود. با این حال، همانطور که ممکن است از یک دوره حسابداری مدیریت به یاد بیاورید، هزینه های غیرمستقیم مانند اجاره، استهلاک و غیره وجود دارد که می تواند در هزینه های فعالیت لحاظ شود.بنچمارک غیررسمی Informal Benchmarkingبنچمارک به مطالعه چگونگی انجام فرآیندهای کسب‌وکار در سایر سازمانها اشاره دارد تا بدانیم چگونه سازمان می‌تواند کار بهتری انجام دهد. بنچمارک با معرفی ایده هایی به سازمان که پتانسیل ایجاد ارزش افزوده را دارند، که ممکن است هرگز در نظر نگرفته باشند.بنچمارک غیررسمی برای فرآیندهای تجاری customer-facing (یعنی فرآیندهایی که با مشتری در تعامل هستند) نسبتاً رایج است. با بنچمارک غیررسمی، مدیران و تحلیلگران به سازمان های دیگر فکر می کنند یا به عنوان مشتری از آنها بازدید می کنند تا نحوه انجام فرآیند کسب و کار را مشاهده کنند. در بسیاری از موارد، کسب و کار مورد مطالعه ممکن است یک رهبر شناخته شده در صنعت یا به سادگی یک شرکت مرتبط باشد.تجزیه و تحلیل نتیجه Outcome Analysisتجزیه و تحلیل نتیجه بر درک نتایج اساسی تمرکز دارد که ارزشی برای مشتریان فراهم می کند. اگرچه این نتایج به نظر می رسد که باید آشکار باشند، اما اغلب اینطور نیستند. به عنوان مثال، یک شرکت بیمه را در نظر بگیرید. یکی از مشتریانش به تازگی تصادف کرده است. نتیجه اساسی از دیدگاه مشتری چیست؟ به طور سنتی، شرکت های بیمه به این سوال با این فرض پاسخ می دهند که مشتری می خواهد پرداخت بیمه را به سرعت دریافت کند. با این حال، برای مشتری، پرداخت تنها وسیله ای برای نتیجه واقعی است: یک ماشین تعمیر شده. شرکت بیمه ممکن است با گسترش دیدگاه خود در مورد فرآیند کسب و کار از مرزهای سنتی خود بهره مند شود و شامل عدم پرداخت هزینه برای تعمیرات، بلکه انجام تعمیرات یا قرارداد با یک کارگاه معتبر برای انجام آنها باشد.با این رویکرد، تحلیلگران سیستم، مدیران و حامیان پروژه را تشویق می‌کنند تا وانمود کنند که مشتری هستند و به دقت در مورد آنچه که محصولات و خدمات سازمان مشتریان را قادر می‌سازد انجام دهند – و آنچه می‌توانند مشتری را قادر به انجام آن کنند، بیندیشند.تجزیه و تحلیل فناوری (Technology Analysis)بسیاری از تغییرات عمده در کسب و کار از اوایل قرن گذشته توسط فناوری های جدید امکان پذیر شده است. تجزیه و تحلیل فناوری با ایجاد لیستی از فناوری های مهم و جالب توسط تحلیلگران و مدیران شروع می شود. سپس گروه به طور سیستماتیک شناسایی می کند که چگونه هر فناوری می تواند در فرآیند کسب و کار به کار رود و مشخص می کند که چگونه کسب و کار سود می برد. توجه به این نکته مهم است که تجزیه و تحلیل فناوری به هیچ وجه به معنای پذیرش فناوری به خاطر فناوری نیست. بلکه تمرکز بر استفاده از فناوری های جدید برای دستیابی به اهداف سازمان است.اگرچه این استراتژی‌ها تحلیلگر را قادر می‌سازد تا به کاربران کمک کند تا چشم‌اندازی برای سیستم جدید ایجاد کنند، اما برای استخراج اطلاعات در مورد نیازهای تجاری دقیقی که برای ایجاد آن مورد نیاز است، کافی نیستند. بنابراین، تحلیلگران از مجموعه‌ای از تکنیک‌های جمع‌آوری نیازمندی‌ها برای کسب اطلاعات از کاربران استفاده می‌کنند. تحلیلگر تکنیک های زیادی برای انتخاب دارد: مصاحبه، پرسشنامه، مشاهده، توسعه برنامه مشترک (JAD) و تجزیه و تحلیل اسناد. اطلاعات جمع آوری شده با استفاده از این تکنیک ها به طور انتقادی تجزیه و تحلیل شده و برای تهیه گزارش تعریف نیازمندی ها استفاده می شود.تکنیک های جمع آوری نیازمندیها (REQUIREMENTS-GATHERING TECHNIQUES)مصاحبه Interviewاولین قدم در مصاحبه، ایجاد یک برنامه زمان بندی مصاحبه است که با چه کسی، چه موقع و با چه هدفی مصاحبه می شود. این برنامه می تواند یک لیست غیر رسمی باشد که برای کمک به تنظیم زمان جلسات استفاده می شود یا یک لیست رسمی است که در برنامه کاری گنجانده شده است. افرادی که در برنامه مصاحبه حاضر می شوند، براساس نیاز اطلاعاتی تحلیلگر انتخاب می شوند. اسپانسر پروژه، کاربران اصلی کسب و کار و سایر اعضای تیم پروژه می توانند به تحلیلگر کمک کنند تا مشخص کند چه کسی در سازمان می تواند اطلاعات مهم درباره نیازها را به بهترین وجه ارائه دهد. این افراد در برنامه مصاحبه به ترتیب مصاحبه ذکر شده اند. افراد در سطوح مختلف سازمان دیدگاههای مختلفی نسبت به سیستم دارند، بنابراین مهم است كه مصاحبه هم با مدیرانی كه فرایندها را مدیریت می كنند و هم کارکنانی را كه در واقع فرایندها را انجام می دهند، صورت پذیرد؛ تا دیدگاههای سطح بالا و سطح پایین راجع به یك موضوع داشته باشند. همچنین، انواع موضوعات مصاحبه مورد نیاز می توانند با گذشت زمان تغییر کنند.طراحی برنامه مشترک Joint Application Development(JAD)یک فرایند ساختاری است که در آن ده تا بیست کاربر با راهنمایی یک مجری ماهر در فنون JAD با هم ملاقات می کنند. مجری برنامه جلسه را تنظیم می کند و بحث را هدایت می کند اما به عنوان یک شرکت کننده در بحث شرکت نمی کند. وی ایده ها یا نظراتی را درباره موضوعات مورد بحث ارائه نمی دهد تا در طول جلسه خنثی بماند. مجری باید هم در تکنیک های فرآیند گروهی و هم در تجزیه و تحلیل سیستم ها و تکنیک های طراحی متخصص باشد. یک یا دو منشی با ضبط یادداشت، تهیه نسخه و غیره به مجری کمک می کنند. اغلب منشی از رایانه و ابزار CASE برای ثبت اطلاعات در جلسه JAD استفاده می كنند. گروه JAD چندین ساعت، چند روز یا چند هفته جلسه می گذارد تا اینکه در مورد همه مسائل بحث شده و اطلاعات لازم جمع آوری می شود. بیشتر جلسات JAD در یک اتاق جلسات که به طور ویژه آماده شده است، دور از دفاتر شرکت کنندگان برگزار می شود تا در آنها مزاحمت ایجاد نشود. اتاق جلسات معمولاً به شکل U تنظیم می شود تا همه شرکت کنندگان به راحتی یکدیگر را ببینند. در قسمت جلوی اتاق قسمت باز(U)، وایتبورد یا پروژکتور بالای سر برای استفاده توسط مجری که بحث را هدایت می کند، قرار دارد.پرسشنامه Questionariesپرسشنامه مجموعه سوالات مکتوب است که برای بدست آوردن اطلاعات از افراد استفاده می شود. از پرسشنامه ها اغلب در مواردی استفاده می شود که تعداد زیادی از افراد که از آنها اطلاعات و نظرات لازم است، وجود داشته باشد. از نظر ما، پرسشنامه ها یک روش معمول با سیستم هایی هستند که برای استفاده در خارج از سازمان (به عنوان مثال توسط مشتریان یا فروشندگان) در نظر گرفته شده اند یا برای سیستم هایی با کاربران تجاری گسترش یافته اند که در بسیاری از مکان های جغرافیایی پخش شده اند. بیشتر افراد وقتی به پرسشنامه فکر می کنند به طور خودکار به کاغذ فکر می کنند، اما امروزه تعداد بیشتری پرسشنامه به صورت الکترونیکی یا از طریق ایمیل یا از طریق وب توزیع می شود. توزیع الکترونیکی می تواند در مقایسه با توزیع پرسشنامه های کاغذی، مبلغ قابل توجهی صرفه جویی در هزینه ایجاد کند. یک فرایند خوب برای استفاده در هنگام استفاده از پرسشنامه چهار مرحله را دنبال می کند.تحلیل اسناد Document Analysisتیم های پروژه برای درک سیستم موجود معمولاً از تحلیل اسناد استفاده می کنند. در شرایط ایده آل، تیم پروژه ای که سیستم موجود را توسعه داده است، اسنادی را تهیه می کند که سپس توسط تمام پروژه های بعدی به روز می شود. در این حالت، تیم پروژه می تواند با بررسی مستندات و بررسی خود سیستم شروع به کار کند.مشاهده Observationمشاهده، عمل مشاهده فرآیندهای در حال انجام، ابزاری قدرتمند برای جمع آوری اطلاعات در مورد سیستم موجود است زیرا تحلیلگر را قادر می سازد تا واقعیت یک موقعیت را ببیند، نه اینکه به دیگران گوش دهد که آن را در مصاحبه ها یا جلسات JAD توصیف می کنند. چندین پژوهش تحقیقاتی نشان داده است که بسیاری از مدیران واقعاً نحوه کار و نحوه اختصاص زمان خود را به خاطر نمی آورند. (هفته گذشته چند ساعت را برای هر یک از دوره های خود صرف کرده اید؟) مشاهده روش خوبی برای بررسی صحت اطلاعات جمع آوری شده از منابع غیرمستقیم مانند مصاحبه ها و پرسشنامه ها است.فاکتورهای استفاده از تکنیکهاجدول مقایسه فاکتورها و کیفیت های هر تکنیکنوع اطلاعات(Type of information)اولین مشخصه نوع اطلاعات است. برخی از تکنیک ها بیشتر مناسب برای استفاده در مراحل مختلف فرایند تجزیه و تحلیل هستند، خواه درک سیستم موجود(as-is System)، بهبود سیستم(improvments) یا توسعه سیستم آینده(to-be System). مصاحبه و JAD معمولاً در هر سه مرحله مورد استفاده قرار می گیرند. در مقابل، تجزیه و تحلیل(Document Analysis) و مشاهده اسناد(Observation) معمولاً برای درک سیستم موجود بسیار مفید هستند، اگرچه گاهی اوقات اطلاعاتی در مورد مشکلات ارائه می دهند که باید بهبود یابند. از پرسشنامه ها اغلب برای جمع آوری اطلاعات در مورد سیستم موجود و همچنین اطلاعات کلی در مورد پیشرفتها استفاده می شود.عمق اطلاعات(Depth of information)عمق اطلاعات به چگونگی غنی و دقیق بودن اطلاعات معمول هر تکنیک و میزان مفید بودن هر روش برای به دست آوردن نه تنها حقایق و نظرات بلکه همچنین فهم دلیل وجود این حقایق و نظرات اشاره دارد. مصاحبه ها و جلسات JAD برای ارائه عمق اطلاعات غنی و دقیق و کمک به تحلیلگر برای درک دلایل آنها بسیار مفید است. از طرف دیگر، تجزیه و تحلیل و مشاهده اسناد برای به دست آوردن حقایق بیشتر مفید است. پرسشنامه ها می توانند عمق متوسطی از اطلاعات را ارائه دهند و حقایق و نظرات را با درک کمی از علت وجود آنها ارائه دهند.وسعت اطلاعات(Breadth of information)وسعت اطلاعات به دامنه اطلاعات و منابع اطلاعاتی اطلاق می شود که با استفاده از تکنیک انتخاب شده می توان به راحتی جمع آوری کرد. پرسشنامه ها و تحلیل اسناد هر دو به راحتی می توانند طیف وسیعی از اطلاعات را از تعداد زیادی از منابع اطلاعاتی بخواهند. در مقابل، مصاحبه ها و مشاهدات مستلزم آن است که تحلیلگر به طور جداگانه از هر منبع اطلاعاتی بازدید کند و بنابراین به زمان بیشتری نیاز دارد. جلسات JAD در این میانه قرار دارد زیرا بسیاری از منابع اطلاعاتی همزمان جمع می شوند.ادغام اطلاعات(Integration of information)یکی از جنبه های چالش برانگیز جمع آوری نیازها، تلفیق اطلاعات از منابع مختلف است. به زبان ساده، افراد مختلف می توانند اطلاعات متناقضی را ارائه دهند. تلفیق این اطلاعات و تلاش برای حل اختلاف نظرات یا واقعیت ها معمولاً بسیار وقت گیر است زیرا این به معنای تماس با هر منبع اطلاعاتی، توضیح اختلاف و تلاش برای اصلاح اطلاعات است. در بسیاری از موارد، فرد به اشتباه درک می کند که تحلیلگر اطلاعات خود او را به چالش می کشد، در حالی که در واقع کاربر دیگری در سازمان است که این کار را انجام داده است. این می تواند کاربر را به حالت دفاعی درآورد و حل اختلافات را دشوار کند. همه تکنیک ها تا حدی از مشکلات ادغام رنج می برند، اما جلسات JAD برای بهبود یکپارچه سازی طراحی شده اند زیرا تمام اطلاعات هنگام جمع آوری یکپارچه می شوند، نه پس از آن. اگر دو کاربر اطلاعات متضادی ارائه دهند، تضاد بلافاصله آشکار می شود، همانطور که منبع تضاد نیز وجود دارد. ادغام فوری اطلاعات مهمترین مزیت JAD است که آن را از سایر تکنیکها متمایز می کند و به همین دلیل است که اکثر سازمانها از JAD برای پروژه های مهم استفاده می کنند.درگیری کاربر(User involvement)مشارکت کاربر به مقدار زمان و انرژی کاربرانی که سیستم جدید باید برای فرآیند تجزیه و تحلیل اختصاص دهند، اشاره دارد. به طور کلی توافق می شود که هرچه کاربران در فرآیند تحلیل بیشتر درگیر شوند، احتمال موفقیت بیشتر می شود. با این حال، دخالت کاربر می تواند هزینه قابل توجهی داشته باشد و همه کاربران مایل به کمک نیستند. پرسشنامه ها، تجزیه و تحلیل اسناد و مشاهده کمترین بار را بر دوش کاربران می اندازد، در حالی که جلسات JAD بیشترین تلاش را می طلبد.هزینه(Cost)هزینه همیشه یک ملاحظه مهم است. به طور کلی، پرسشنامه، تحلیل اسناد و مشاهده تکنیک های کم هزینه ای هستند (اگرچه مشاهده می تواند بسیار زمانبر باشد). هزینه کم به معنای کم و بیش موثر بودن آنها نسبت به سایر تکنیک ها نیست. مصاحبه ها و جلسات JAD معمولاً هزینه های متوسطی دارند. به طور کلی، جلسات JAD در ابتدا بسیار گران تر است، زیرا به بسیاری از کاربران برای مدت زمان قابل توجهی در دفاتر خود غایب هستند و آنها معمولاً مشاوران بسیار پردرآمد را درگیر می کنند. با این حال، جلسات JAD به طور قابل توجهی زمان صرف شده در یکپارچه سازی اطلاعات را کاهش می دهد و بنابراین می تواند در بلند مدت هزینه کمتری داشته باشد.منبع:Systems Analysis and Design: An Object-Oriented Approach with UML, 5th Edition by Dennis, Wixom, and Tegarden اسماعیل شهبازی نژاد اسماعیل شهبازی نژاد Sat, 21 Aug 2021 14:52:41 +0430 https://virgool.io/@es.shahbazi/%D9%86%D9%82%D8%B4-%D9%87%D8%A7-%D9%88-%D9%85%D9%87%D8%A7%D8%B1%D8%AA-%D9%87%D8%A7%DB%8C-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7systems-analyst-roles-and-skills-iinbgjizqjrv تحلیلگران باید مهارت های فنی برای درک محیط فنی موجود سازمان، فناوری تشکیل دهنده سیستم جدید و روشی که این دو را در یک راه حل فنی یکپارچه قرار دهد، داشته باشند. تحلیلگران هم در سطح پروژه و هم در سطح سازمانی، حل کننده مستمر مشکلات هستند و مهارت های تحلیلی خود را به طور مرتب مورد آزمایش قرار می دهند.تحلیلگران اغلب نیاز دارند که با کاربران و مدیران تجاری (که اغلب تجربه کمی در زمینه فناوری دارند) و با برنامه نویسان (که اغلب تخصص فنی بیشتری نسبت به تحلیلگر دارند) به طور موثر ارتباط برقرار کنند. آنها باید بتوانند به گروه های بزرگ و کوچک ارائه دهند و گزارش بنویسند. آنها نه تنها نیاز به توانایی های بین فردی قوی دارند، بلکه باید افرادی را که با آنها کار می کنند مدیریت کنند و باید فشار و خطرات مرتبط با موقعیت های نامشخص را مدیریت کنند.علاوه بر این شش مجموعه مهارت عمومی، تحلیلگران به بسیاری از مهارت های خاص مرتبط با نقش های انجام شده در یک پروژه نیاز دارند. در روزهای اولیه توسعه سیستم ها، بیشتر سازمان ها انتظار داشتند که یک فرد، تحلیلگر، تمام مهارت های خاص مورد نیاز برای اجرای یک پروژه توسعه سیستم را داشته باشد. برخی از سازمان‌های کوچک هنوز انتظار دارند که یک فرد نقش‌های زیادی را ایفا کند، اما از آنجایی که سازمان‌ها و فناوری پیچیده‌تر شده‌اند، اکثر سازمان‌های بزرگ اکنون تیم‌های پروژه‌ای را شامل چندین فرد با مسئولیت‌های مشخص شده می‌سازند.1. تحلیلگر کسب و کار (Business Analyst)یک تحلیلگر کسب و کار بر روی مسائل تجاری پیرامون سیستم تمرکز دارد. این موضوعات شامل شناسایی ارزشی است که با ایجاد سیستم بوجود می آید، توسعه ایده ها و پیشنهادهایی در مورد چگونگی بهبود فرآیندهای کسب و کار و طراحی فرآیندها و policyهای جدید، از وظایف تحلیلگر سیستم است. این فرد به احتمال زیاد دارای تجربه در شناخت کسب و کارها و نوعی آموزش حرفه ای است. وی منافع و خواسته های اسپانسر و کاربران نهایی سیستم را نمایندگی می کند. یک تحلیلگر کسب و کار در مراحل برنامه ریزی (Planning) و طراحی(Design) کمک می کند اما در مرحله تجزیه و تحلیل(Analysis) فعالیت بیشتری دارد.2. تحلیلگر سیستم (Systems Analyst)یک تحلیلگر سیستم بر روی موضوعات IS پیرامون سیستم متمرکز است. این فرد ایده ها و پیشنهادهایی را جهت بهبود فرآیندهای تجاری (Business Process) با استفاده از فناوری اطلاعات ارائه می دهد، ابتدا با کمک تحلیلگر کسب و کار(Business Analyst) فرآیندهای جدید کسب و کار را طراحی می کند و سپس سیستم اطلاعات جدید را طراحی و حفظ تمام استانداردهای IS را تضمین می کند. یک تحلیلگر سیستم احتمالاً در تجزیه و تحلیل و طراحی ، برنامه نویسی و حتی زمینه های کسب و کار، آموزش و تجربه قابل توجهی دارد. او نماینده منافع گروه IS است و سراسر پروژه فشرده کار می کند، اما شاید در مرحله اجرا کمتر باشد.3. تحلیلگر زیرساخت (Infrastructure Analyst)یک تحلیلگر زیرساخت بر روی موضوعات فنی پیرامون نحوه تعامل سیستم با زیرساخت های فنی سازمان (به عنوان مثال ، سخت افزار ، نرم افزار ، شبکه ها و پایگاه های داده) متمرکز است. وظایف یک تحلیلگر زیرساخت شامل اطمینان از انطباق سیستم اطلاعات جدید با استانداردهای سازمانی و شناسایی تغییرات زیرساختی مورد نیاز برای پشتیبانی از سیستم است. این فرد احتمالاً از آموزش و تجربه قابل توجهی در زمینه شبکه ، مدیریت پایگاه داده و محصولات سخت افزاری و نرم افزاری مختلف برخوردار است. وی نماینده منافع سازمان و گروه IS است که در نهایت بایستی کار و پشتیبانی از سیستم جدید را به عهده بگیرند. یک تحلیلگر زیرساخت در کل پروژه کار می کند اما شاید در مراحل برنامه ریزی و تجزیه و تحلیل کمتر باشد.4. تحلیلگر مدیریت تغییر(Change Management Analyst)یک تحلیلگر مدیریت تغییر بر روی افراد و مسائل مدیریتی پیرامون نصب سیستم متمرکز است. نقش های این شخص شامل اطمینان از در دسترس بودن اسناد و مدارك کافی و پشتیبانی، استفاده از آموزش كاربران در مورد سیستم جدید و ایجاد استراتژی هایی برای غلبه بر مقاومت در برابر تغییر است. این فرد باید آموزش و تجربه قابل توجهی در رفتار سازمانی به طور کلی و مدیریت تغییر به طور خاص داشته باشد. وی نماینده منافع اسپانسر پروژه و کاربرانی است که سیستم برای آنها طراحی شده است. یک تحلیلگر مدیریت تغییر در مرحله پیاده سازی بیشتر فعالانه کار می کند اما در مرحله تجزیه و تحلیل و طراحی شروع به ایجاد زمینه برای تغییر می کند.5. مدیر پروژه (Project Management)یک مدیر پروژه وظیفه دارد اطمینان حاصل کند که پروژه به موقع و در حد بودجه به اتمام رسیده است و سیستم کلیه مزایایی را که اسپانسر پروژه در نظر گرفته است، تحویل می دهد. نقش مدیر پروژه شامل مدیریت اعضای تیم ، تدوین برنامه پروژه ، تخصیص منابع و داشتن نقطه تماس اصلی هنگام تماس با افراد خارج از تیم در مورد پروژه است. این فرد احتمالاً تجربه قابل توجهی در مدیریت پروژه دارد و احتمالاً پیش از این سالها به عنوان تحلیلگر سیستم کار کرده است. وی نماینده منافع سازمان و گروه IS است. مدیر پروژه در تمام مراحل پروژه به شدت کار می کند.منبع:Systems Analysis and Design: An Object-Oriented Approach with UML, 5th Edition by Dennis, Wixom, and Tegarden اسماعیل شهبازی نژاد اسماعیل شهبازی نژاد Wed, 18 Aug 2021 18:41:49 +0430 https://virgool.io/@es.shahbazi/workflow-nfwf0jj6zgsb در این مطلب تعریف گردش کار و اجزای آن ارائه شده است، در آینده نزدیک الگوهای کنترل جریان، تخصیص داده و منابع در گردش کار را ارائه خواهم نمود.تعریف گردش کار(Workflow Defination)یک گردش کار یا یک مدل گردش کار ، توصیف یک فرآیند کسب و کار با جزئیات کافی است که بتواند مستقیماً توسط سیستم مدیریت گردش کار اجرا شود. یک مدل گردش کار از تعدادی وظیفه"Task" تشکیل شده است که به صورت یک گراف جهت دار به هم متصل می شوند. اجزای گردش کار(Workflow Components)اجزای گردش کارمورد(Case)به یک نمونه اجرایی از یک مدل گردش کار ، یک نمونه فرآیند "Process Instance" یا مورد"Case" گفته می شود. ممکن است چندین مورد(Case) وجود داشته باشد که در یک مدل گردش کار (workflow model) خاص به طور همزمان اجرا شود ، اما فرض بر این است که هر یک از اینها وجود مستقلی دارند و آنها معمولاً بدون مراجعه به یکدیگر اجرا می شوند.وظیفه، کار (Task)یک وظیفه(task) مربوط به یک واحد کار(unit of work) است. چهار نوع وظیفه متمایز مشخص شده اند: اتمیک Atomic، بلوکی Block ، چند نمونه ای multi-instance و چند نمونه ای بلوکی multi-instance block. ما از اصطلاح عمومی اجزا (components) گردش کار برای اشاره به همه کارهایی که یک مدل گردش کار مشخص را تشکیل می دهند استفاده می کنیم.- وظیفه اتمی "Atomic Task" وظیفه ای است که دارای یک تعریف ساده و خودشمول باشد (یعنی تعریفی که از نظر سایر وظایف گردش کار توصیف نشده است) و هنگام شروع فقط یک نمونه از آن اجرا می شود.- وظیفه بلوکی "Blocked Task" یک عمل پیچیده است که اجرای آن با توجه به یک گردش کار فرعی توصیف می شود. هنگامی که یک کار بلوک شروع می شود ، آن کنترل را به اولین کار (ها) در گردش زیر کار مربوطه منتقل می کند. این گردش کار فرعی تکمیل می شود و در پایان ، کنترل را دوباره به کار بلوک منتقل می کند.- یک وظیفه چند نمونه ای "multiple-instance task " وظیفه ای است که ممکن است چندین مورد اجرای مجزا بصورت همزمان در همان گردش کار داشته باشد. هر یک از این نمونه ها به طور مستقل اجرا می شوند. فقط وقتی تمام نمونه ها به اتمام می رسند ، وظیفه بعدی آغاز می شود.- یک وظیفه بلوکی چند نمونه ای "multiple-instance block task " ترکیبی از دو سازه قبلی است و وظیفه ای را نشان می دهد که ممکن است دارای چندین نمونه اجرای مجزا باشد که هرکدام از آنها دارای ماهیت بلوکی هستند (به عنوان مثال دارای یک جریان کار فرعی مربوطه است).مورد کار(Work Item)جریان کنترل(Control Flow) بین وظایف (tasks) از طریق کانال کنترل رخ می دهد که با یک پیکان ثابت بین وظایف نشان داده می شود. هر فراخوانی وظیفه(task) که اجرا می شود ، یک مورد کار (Work Item) نامیده می شود.معمولاً برای هر وظیفه (task) در یک مورد(case)، یک مورد کار(work item) آغاز می شود، اما در مورد یک کار چند نمونه(multiple-instance task) ، ممکن است چندین مورد کار(work item) وجود داشته باشد که هنگام شروع کار ایجاد می شوند. به همین ترتیب، در جایی که کاری(task) بخشی از یک حلقه را تشکیل می دهد، برای هر تکرار یک مورد کار(work item) مشخص ایجاد می شود.(1) توزیع کار به منابع (Work Distribution to Resources)از دیدگاه منابع ، نحوه اعلان موارد کار(Work Items) از اهمیت ویژه ای برخوردار است، که در آن مورد کار در نهایت به منابع خاصی برای اجرا، ابلاغ می شود. شکل زیر چرخه حیات یک مورد کار را به شکل نمودار انتقال وضعیت(Transition State Diagram)، از زمان ایجاد یک مورد کار تا تکمیل یا خرابی نهایی نشان می دهد. چرخه حیات یک مورد کار Work Item Lifecycle در ابتدا یک مورد کار در حالت ایجاد شده به وجود می آید. این نشان می دهد که پیش شرط های لازم برای فعال سازی آن برآورده شده و قابلیت اجرا دارد. در این مرحله ، اما مورد کار به منبعی برای اجرا اختصاص نیافته است و تعدادی مسیر ممکن برای این موارد وجود دارد. هر لبه در این نمودار با S یا R با پیشوند مشخص می شود که نشان می دهد انتقال به ترتیب توسط سیستم گردش کار(Workflow System) یا منبع(Resource) آغاز شده است.· the created stateحالت ایجاد شده معمولاً توسط سیستم گردش کار آغاز می شود. آنها بر فعالیت آگاهی بخشیدن به منابع از موارد کاری که نیاز به اجرا دارند ، متمرکز هستند. این ممکن است به یکی از سه روش مشخصی که توسط حالات بعدی مشخص می شوند ، رخ دهد.· offered to a single resource stateیک مورد ممکن است به یک منبع واحد ارائه شود به این معناست که سیستم گردش کار دقیقاً یک منبع را در مورد در دسترس بودن یک مورد کار مطلع کند. این کار ممکن است با ارسال پیام به منبع یا افزودن مورد کار به لیست موارد کار موجود که منبع می تواند مشاهده کند ، انجام دهد. بطور طبیعی این مفهوم سیستم انتخاب یک منبع خاص است که مورد کار باید به آن اعلان شود. این ممکن است به طرق مختلف اتفاق بیفتد - مدل فرآیند ممکن است شامل دستورالعمل های خاصی در مورد هویت منبعی باشد که یک مورد کار خاص باید به آن هدایت شود یا ممکن است بر اساس الزامات عمومی تری مانند استفاده از کمترین مشغله ، ارزانترین یا مناسب ترین منبع واجد شرایط در هر یک از این شرایط ، نیاز به تعیین منابع مناسب و مناسب برای انجام کار موردی و سپس رتبه بندی آنها و انتخاب مناسب ترین مورد وجود دارد.· offered to a multiple resource stateوضعیتی که مورد کار به چندین منبع ارائه می شود ، جایی است که سیستم منابع مختلفی را از وجود یک مورد کار مطلع می کند. در این حالت ، سیستم به تمام منابع مناسب مورد کار اطلاع می دهد. اما تلاش نمی کند تا مشخص کند که کدام یک از آنها باید این کار را انجام دهند.· allocated to a single resource stateتخصیص یافته به یک حالت منبع واحد بیانگر یک مورد کاری است که یک منبع خاص متعهد به اجرای آن در برخی از زمان های آینده شده است. یک مورد کاری ممکن است به این حالت پیشرفت کند زیرا سیستم گردش کار به طور پیش فرض موارد کار تازه ایجاد شده را به یک منبع اختصاص می دهدیا به این دلیل که منبعی داوطلب می شود یک مورد کاری را که ارائه شده است ، انجام دهد.توجه داشته باشید که چرخه حیات مورد کار نشان داده شده در شکل 2 فرض می کند که یک مورد توسط یک منبع انجام می شود ، بنابراین حالتی وجود ندارد که با "تخصیص یافته به چندین منبع" مطابقت داشته باشد.· حالات بعدی در مدل توزیع کار started است، که نشان می دهد منبعی شروع به اجرای مورد کار کرده است ، سپس suspended (به حالت تعلیق درآمده) است که نشان می دهد منبع برای توقف اجرای مورد کار برای یک دوره انتخاب شده است ، اما قصد دارد در آن کار را ادامه دهد اگر انجام نشد ، که مشخص می کند مورد کار نمی تواند تکمیل شود و منبع دیگر روی آن کار نمی کند و completed که یک مورد را مشخص می کند که با موفقیت تا پایان اجرا شده است.منبع: www.workflowpatterns.com اسماعیل شهبازی نژاد اسماعیل شهبازی نژاد Wed, 18 Aug 2021 14:49:35 +0430