https://virgool.ir/feed/@es.shahbaziمتخصص مدیریت محصول با تجربه در فین تک و محصولات مالی. علاقه مند به کشف مسئله، تصمیم گیری محصولی و تبدیل نیازهای واقعی کسب و کار به راه حل های ارزشمند.fa2026-11-11 09:37:07https://files.virgool.ir/upload/users/17581/avatar/CxPibg.pnghttps://virgool.ir/@es.shahbazihttps://virgool.ir/@es.shahbazi/از-درخواست-مبهم-تا-نیازمندی-قابل-تست-چطور-جلوی-برداشت-های-متفاوت-تیم-را-بگیریم-shwuezpwett7تا حالا شده یک تسک بهتون ارجاع بشه که در نگاه اول کاملا مشخص به نظر می رسه، اما هرچی جلوتر میرید سوال های بیشتری براتون ایجاد میشه؟مثلا درخواستی به تیم محصول می رسه:«امکان مسدود کردن حساب مشتری به سامانه اضافه بشه.»توسعه دهنده ممکنه بپرسه: فقط برداشت از حساب باید متوقف بشه یا همه تراکنش ها؟تحلیلگر کسب و کار باید بدونه چه قواعدی برای مسدودی وجود داره.تستر باید مشخص کنه چه حالت هایی رو باید بررسی کنه.مالک محصول هم باید مطمئن بشه چیزی که قراره ساخته بشه، همون رفتاریه که کسب و کار انتظار داره.همه درباره یک قابلیت صحبت می کنن، اما ممکنه هر کدوم تصویر متفاوتی از اون داشته باشن.اینجا مشکل لزوما از عملکرد هیچ کدوم از اعضای تیم نیست. مسئله اینه که قبل از شروع کار، درباره چیزی که باید ساخته بشه به درک مشترک نرسیدیم.وقتی تصمیم های اصلی روشن نباشن، هر عضو تیم ناچار میشه بخشی از ابهام رو با برداشت خودش پر کنه. ممکنه پیاده سازی از نظر فنی درست باشه، تست ها هم با موفقیت انجام بشن، اما خروجی نهایی با انتظار کسب و کار فاصله داشته باشه.نیازمندی مبهم فقط کار توسعه رو سخت نمی کنه؛ می تونه باعث بشه هر عضو تیم، ناخواسته محصول متفاوتی بسازه.مسئولیت PO از کجا شروع میشه؟یکی از مسئولیت های مهم مالک محصول (Product Owner) اینه که درخواست اولیه رو به اندازه کافی بررسی کنه و درباره مسئله و رفتار مورد انتظار محصول شفافیت ایجاد کنه.این مسئولیت به معنی تعیین راه حل فنی نیست.PO قرار نیست به توسعه دهنده بگه چطور کد بزنه یا چه معماری و ساختاری انتخاب کنه. اتفاقا تیم فنی باید برای طراحی و پیاده سازی راه حل از تخصص خودش استفاده کنه.اما یک مرز مهم وجود داره:تیم فنی باید برای پیدا کردن بهترین راه حل تصمیم بگیره، نه اینکه مجبور بشه حدس بزنه محصول دقیقا چه رفتاری باید داشته باشه.برای رسیدن به این شفافیت، قبل از نوشتن Story باید سوال های درستی بپرسیم.قبل از نوشتن Story، از هفت بُعد به درخواست نگاه کنیمبرای بررسی یک درخواست مبهم میشه از یک چارچوب هفت بعدی استفاده کرد.این چارچوب قرار نیست یک پرسشنامه ثابت باشه که همیشه تمام سوال های اون رو به ترتیب بپرسیم. بیشتر شبیه یک نقشه برای فکر کردنه؛ پاسخ هر سوال می تونه سوال بعدی رو مشخص کنه.۱. مسئله و انگیزه؛ اصلا چرا این درخواست مطرح شده؟اول باید بفهمیم چه مشکلی باعث شده چنین درخواستی مطرح بشه.در مثال ما:چه اتفاقی باعث شده کسب و کار درخواست مسدودی حساب بده؟چه مشکلی در فرایند فعلی وجود داره؟چرا راه حل فعلی کافی نیست؟شاید هدف جلوگیری از برداشت غیرمجاز باشه. شاید هم موضوع به یک محدودیت قانونی یا درخواست واحد عملیات مربوط بشه.اگر دلیل درخواست رو ندونیم، ممکنه خیلی زود روی راه حل پیشنهادی متمرکز بشیم و اصل مسئله رو نادیده بگیریم.۲. افراد و نقش ها؛ چه کسانی با این قابلیت درگیر هستن؟باید مشخص کنیم چه کسانی از قابلیت استفاده می کنن و چه کسانی از نتیجه اون تاثیر می گیرن.در مثال مسدودی حساب:چه کسانی مجاز به مسدود کردن حساب هستن؟آیا همه کارشناسان عملیات چنین دسترسی ای دارن؟مشتری بعد از مسدودی چه دسترسی هایی خواهد داشت؟آیا واحد دیگری هم باید از این تغییر مطلع بشه؟شناخت افراد و نقش ها فقط برای طراحی دسترسی نیست؛ کمک می کنه اثر تغییر رو از زاویه افراد مختلف بررسی کنیم.۳. وضعیت فعلی؛ الان کار چطور انجام میشه؟قبل از تغییر یک فرایند باید بدونیم امروز چه اتفاقی میفته.برای مثال:الان حساب مشتری چطور مسدود میشه؟این کار از طریق چه سامانه یا واحدی انجام میشه؟بعد از مسدودی چه اتفاقی برای تراکنش ها میفته؟چه مشکلاتی در روش فعلی وجود داره؟بدون شناخت وضعیت فعلی ممکنه بخشی از قواعد یا وابستگی های مهم رو نبینیم.۴. نتیجه مطلوب؛ دقیقا چه چیزی باید تغییر کنه؟اینجا باید از خودمون بپرسیم بعد از اجرای این قابلیت، چه رفتار یا نتیجه ای انتظار داریم.در مثال ما:آیا فقط ثبت برداشت جدید باید متوقف بشه؟آیا انتقال وجه هم باید مسدود بشه؟آیا مشتری همچنان می تونه وارد سامانه بشه؟آیا باید وضعیت حساب رو مشاهده کنه؟نکته مهم اینه که نتیجه مطلوب رو با راه حل پیشنهادی اشتباه نگیریم.«ساخت قابلیت مسدودی حساب» راه حل پیشنهادی است؛ اما باید بفهمیم دقیقا چه تغییری در رفتار سیستم و تجربه مشتری انتظار داریم.۵. قواعد و محدودیت ها؛ چه شرایطی باید رعایت بشه؟هر قابلیتی در یک محصول واقعی، قواعد و محدودیت هایی داره که باید مشخص بشن.برای مثال:آیا فقط حساب فعال قابل مسدود شدنه؟چه کسی اجازه انجام این عملیات رو داره؟آیا ثبت علت مسدودی الزامیه؟آیا برای انجام عملیات تایید شخص دیگری هم لازمه؟این قواعد ممکنه از نیاز کسب و کار، فرایندهای عملیاتی، الزامات قانونی یا محدودیت های سیستم ناشی بشن.۶. استثناها و پیامدها؛ اگر شرایط عادی نبود چی؟باید فقط مسیر موفق و عادی رو نبینیم.برای مثال:اگر حساب از قبل مسدود شده باشه چه اتفاقی میفته؟اگر هنگام ثبت درخواست خطایی رخ بده چی؟اگر کاربر مجوز لازم رو نداشته باشه چه رفتاری انتظار داریم؟اگر در زمان مسدودی، درخواست برداشت در حال پردازش باشه چه اتفاقی باید بیفته؟بررسی این موارد کمک می کنه رفتار سیستم در شرایط مختلف قابل پیش بینی و قابل تست باشه.۷. شواهد و اطمینان؛ از کجا می دونیم برداشت ما درسته؟این بخش کمک می کنه مطمئن بشیم تصمیم های ما صرفا بر اساس حدس و برداشت شخصی نیستن.برای مثال:قواعد مسدودی رو چه کسی تایید می کنه؟آیا مستند یا دستورالعملی برای این فرایند وجود داره؟آیا می تونیم رفتار فعلی سیستم یا داده های عملیاتی رو بررسی کنیم؟چه کسی اختیار تصمیم گیری درباره این قواعد رو داره؟گاهی چند نفر برداشت متفاوتی از یک درخواست دارن. در این شرایط صرفا توافق اعضای جلسه کافی نیست؛ باید مشخص کنیم منبع معتبر تصمیم کجاست.آیا باید تمام ابهام ها را قبل از توسعه برطرف کنیم؟نه. این یکی از نکات مهم در تحلیل نیازمندی است.قرار نیست برای هر Story تمام حالت های ممکن رو بررسی کنیم یا تا وقتی هیچ سوالی باقی نمونده، توسعه رو شروع نکنیم.کار مهم تر اینه که تشخیص بدیم کدوم ابهام روی رفتار اصلی محصول اثر میذاره و باید تعیین تکلیف بشه.من پیشنهاد می کنم خروجی بررسی ها رو در سه گروه قرار بدیم:۱. تصمیم گرفته شدهموضوع روشنه و افراد مرتبط درباره اون توافق دارن. این موارد می تونن وارد Story و معیارهای پذیرش بشن.۲. نیازمند بررسی بیشترپاسخ هنوز روشن نیست یا درباره اون توافق وجود نداره. اگر روی رفتار اصلی سیستم اثر میذاره، باید قبل از توسعه بررسی بشه.۳. خارج از محدوده فعلیموضوع مهمیه، اما برای تحویل این Story ضروری نیست. میشه اون رو ثبت کرد تا در زمان مناسب بررسی بشه.این تفکیک کمک می کنه نه تصمیم های مهم رو به حدس تیم واگذار کنیم و نه با تحلیل بی پایان، جلوی پیشرفت کار رو بگیریم.حالا چطور این تحلیل را به User Story تبدیل کنیم؟فرض کنیم بعد از بررسی درخواست مسدودی حساب، با واحد کسب و کار و عملیات به توافق های زیر رسیدیم:فقط کارشناس مجاز واحد عملیات می تونه حساب فعال مشتری رو مسدود کنه.بعد از مسدودی، ثبت برداشت جدید از حساب مجاز نیست.مشتری همچنان می تونه وارد سامانه بشه و وضعیت حسابش رو مشاهده کنه.اگر حساب از قبل مسدود شده باشه، سامانه باید وضعیت فعلی رو اعلام کنه.کاربر غیرمجاز اجازه تغییر وضعیت حساب رو نداره.این موارد در یک محصول مالی واقعی، فرض های اولیه هستن و باید با افراد صاحب صلاحیت و مستندات مربوط تایید بشن.حالا می تونیم Story رو بنویسیم:«به عنوان کارشناس مجاز واحد عملیات، میخوام بتونم حساب فعال مشتری رو مسدود کنم تا امکان ثبت برداشت جدید از اون حساب وجود نداشته باشه.»این Story سه بخش اصلی داره:چه کسی؟ کارشناس مجاز واحد عملیاتچه قابلیتی؟ مسدود کردن حساب فعال مشتریبرای چه هدفی؟ جلوگیری از ثبت برداشت جدیداما هنوز یک سوال مهم باقی مونده:از کجا بفهمیم این قابلیت درست پیاده سازی شده؟اینجاست که معیارهای پذیرش وارد میشن.معیار پذیرش؛ رفتار مورد انتظار را قابل تست کنیممعیارهای پذیرش (Acceptance Criteria) مشخص می کنن سیستم در شرایط مختلف چه رفتاری باید داشته باشه تا بتونیم درستی پیاده سازی رو بررسی کنیم.برای مثال، در همین درخواست می تونیم چند سناریوی اصلی تعریف کنیم.سناریوی اول: مسدود کردن حساب فعالبا فرض اینکه کاربر مجاز است و حساب مشتری فعال است،وقتی درخواست مسدود کردن حساب ثبت میشه،وضعیت حساب باید به مسدود تغییر کنه و نتیجه عملیات به کاربر نمایش داده بشه.سناریوی دوم: برداشت از حساب مسدود شدهبا فرض اینکه حساب مشتری مسدود است،وقتی درخواست برداشت جدید ثبت میشه،سامانه باید درخواست رو رد کنه و برداشت جدیدی برای اون حساب ثبت نشه.سناریوی سوم: اقدام کاربر غیرمجازبا فرض اینکه کاربر مجوز مسدود کردن حساب رو نداره،وقتی درخواست مسدودی ثبت می کنه،سامانه باید از انجام عملیات جلوگیری کنه، وضعیت حساب رو تغییر نده و پیام مناسبی نمایش بده.سناریوی چهارم: حسابی که از قبل مسدود شدهبا فرض اینکه حساب مشتری قبلا مسدود شده،وقتی دوباره درخواست مسدودی ثبت میشه،سامانه باید وضعیت فعلی حساب رو اعلام کنه و از تغییر غیرضروری وضعیت جلوگیری کنه.این سناریوها نقطه شروع هستن، نه لزوما تمام حالت های مورد نیاز.بسته به قواعد کسب و کار و سطح ریسک، ممکنه مواردی مثل ثبت تاریخچه عملیات، ثبت علت مسدودی، مدیریت خطاها و نحوه بازگشت از وضعیت مسدود هم لازم باشن.هدف این نیست که از همون ابتدا تمام حالت های ممکن رو مستند کنیم؛ هدف اینه که رفتارهای مهم و مورد توافق، روشن و قابل بررسی باشن.معیار پذیرش با وظیفه فنی فرق داردگاهی در مستندات نیازمندی، جزئیات پیاده سازی با رفتار مورد انتظار سیستم مخلوط میشن.برای مثال:«یک API برای مسدود کردن حساب ایجاد بشه» یک وظیفه فنی است.«در صورت مسدود بودن حساب، درخواست برداشت جدید رد بشه و تراکنش ثبت نشه» یک رفتار مورد انتظار و قابل تست است.تفاوت این سه مفهوم رو در نظر بگیریم:Story: چه کسی چه نیازی داره و چرا؟Acceptance Criteria: سیستم در شرایط مختلف چه رفتاری باید داشته باشه؟Task: تیم فنی برای پیاده سازی اون رفتار چه کارهایی باید انجام بده؟PO باید درباره نیاز و رفتار مورد انتظار شفاف باشه، اما طراحی راه حل فنی رو به تیم فنی بسپاره.تحلیلگر کسب و کار هم می تونه در استخراج قواعد، بررسی فرایندها و مستندسازی سناریوها نقش مهمی داشته باشه. در نهایت، توسعه دهنده و تستر باید بتونن بر اساس یک درک مشترک از نیازمندی، کار خودشون رو پیش ببرن.قبل از تحویل نیازمندی به تیم، این سوال ها را بررسی کنیمآیا می دونیم این درخواست برای حل چه مسئله ای مطرح شده؟آیا افراد و نقش های درگیر مشخص هستن؟آیا وضعیت فعلی و رفتار مورد انتظار رو می شناسیم؟آیا قواعد و محدودیت های مهم روشن شدن؟آیا استثناهای اثرگذار بررسی شدن؟آیا ابهام های مهم تعیین تکلیف شدن؟آیا تیم توسعه و تست برداشت مشترکی از نتیجه مورد انتظار دارن؟آیا می تونیم با سناریوهای مشخص، درستی رفتار سیستم رو بررسی کنیم؟اگر پاسخ چند مورد از این سوال ها هنوز مبهمه، شاید نیازمندی برای شروع توسعه آماده نباشه.در نهایت، کیفیت تحویل از کیفیت تصمیم های قبل از توسعه شروع می شودنوشتن یک جمله با قالب User Story کار سختی نیست. حتی میشه برای هر درخواست چند معیار پذیرش هم نوشت.اما کیفیت تحلیل نیازمندی با تعداد Storyها و معیارهای پذیرش نوشته شده مشخص نمیشه.بخش مهمی از کار قبل از نوشتن اونها اتفاق میفته: فهمیدن مسئله، پرسیدن سوال های درست، روشن کردن قواعد، شناسایی استثناها و ایجاد توافق درباره رفتاری که قراره ساخته بشه.قرار نیست PO همه جواب ها رو از قبل بدونه یا تمام ابهام های ممکن رو حذف کنه. قرار است تشخیص بده کدوم تصمیم ها باید گرفته بشن، کدوم موضوع ها نیازمند بررسی بیشتر هستن و کدوم موارد رو میشه به بعد موکول کرد.تیم فنی باید برای پیدا کردن بهترین راه حل از تخصص خودش استفاده کنه، نه برای حدس زدن اینکه کسب و کار و محصول چه چیزی می خوان.یک نیازمندی خوب فقط به تیم نمیگه چه چیزی بسازه؛ کمک می کنه همه اعضای تیم بفهمن چرا، برای چه کسی و با چه رفتار مورد انتظاری قراره اون رو بسازن.اسماعیل شهبازی نژاداسماعیل شهبازی نژادSun, 01 Nov 2026 17:17:52 +0330https://virgool.ir/@es.shahbazi/کمپین-اجرا-شد-اما-آیا-میدونیم-چه-چیزی-تغییر-کرد-qamsyeyjrsxpکمپین اجرا شد؛ اما آیا میدونیم چه چیزی تغییر کرد؟فرض کنید یک اپراتور تلفن همراه برای تشویق مشتریانش به خرید بسته اینترنت، کمپینی اجرا میکنه. گروه هدف مشخص شده، شرایط دریافت هدیه تعریف شده، پیامک ها آماده اند و فرایند فعال سازی هدیه هم پیاده سازی شده.تیم همه چیز رو طبق برنامه جلو میبره. کمپین در زمان تعیین شده اجرا میشه و گزارش اجرا هم آماده است.اما یک سؤال مهم هنوز باقی مونده:آیا این کمپین باعث شد رفتار مشتری تغییر کنه؟ و اگر تغییر کرد، آیا این تغییر برای کسب و کار هم ارزشمند بود؟این سؤال ساده، تفاوت بین تحویل یک کار و فهمیدن نتیجه اون رو نشون میده.مستندات دقیق، موفقیت کمپین رو ثابت نمیکنندر اجرای کمپین، جزئیات زیادی باید درست باشن: گروه هدف، شرایط واجد شرایط بودن، زمان خرید، قواعد ارسال پیامک، فعال سازی هدیه و مدیریت حالت های استثنا.اگر یکی از این موارد درست کار نکنه، ممکنه پیامک برای مشتری اشتباهی ارسال بشه، هدیه ای فعال نشه یا کمپین مطابق برنامه اجرا نشه. بنابراین، مستندات دقیق و اجرای درست کاملا ضروری اند.اما اینها فقط نشون میدن که کمپین چطور اجرا شده؛ نه اینکه چه نتیجه ای ایجاد کرده.ممکنه همه پیامک ها درست ارسال شده باشن، اما هنوز ندونیم چند مشتری به خاطر کمپین خرید کرده اند، چند نفر حتی بدون دریافت هدیه هم خرید میکردند و هزینه مشوق ها در برابر نتیجه به دست آمده چقدر بوده.اجرای موفق، شرط لازم برای رسیدن به نتیجه است؛ اما به تنهایی اثبات نمیکنه که نتیجه مطلوب به دست آمده.وقتی تعداد کمپین ها زیاد میشه، چه چیزی ممکنه گم بشه؟در محیط هایی که کمپین های زیادی اجرا میشن، طبیعی است که بخش قابل توجهی از انرژی تیم صرف آماده سازی، هماهنگی، بررسی قواعد، تست و تحویل به موقع بشه.این فعالیت ها واقعی و ضروری اند. مسئله از جایی شروع میشه که بعد از اجرای کمپین، کار عملا تمام شده تلقی بشه.اگر فقط تعداد کمپین های اجرا شده، زمان تحویل یا تعداد پیامک های ارسال شده رو گزارش کنیم، تصویری از حجم فعالیت داریم؛ اما لزوما از ارزشی که ایجاد شده نداریم.این حرف به معنی بی اثر بودن کمپین ها نیست. بدون داده نمیشه چنین نتیجه ای گرفت. مسئله اینه که اگر نتیجه رو اندازه نگیریم، حتی ممکنه متوجه نشیم کدوم کمپین ارزش تکرار کردن داره، کدوم نیاز به اصلاح داره و کدوم فقط هزینه و پیچیدگی بیشتری ایجاد کرده.سه مرحله ای که باید از هم جدا بموننبرای ارزیابی یک کمپین، بهتره سه سطح رو از هم تفکیک کنیم.۱. آیا کمپین درست اجرا شد؟در این مرحله، درباره کیفیت اجرا حرف میزنیم:پیامک برای گروه هدف درست ارسال شد؟شرایط دریافت هدیه درست اعمال شد؟هدیه در زمان مناسب فعال شد؟موارد استثنا و خطاها درست مدیریت شدند؟اینها سؤال های مهمی اند و باید پاسخ مشخصی داشته باشن. اما هنوز درباره اثر کمپین چیزی نمیگن.۲. آیا رفتار مشتری تغییر کرد؟حالا باید ببینیم بعد از اجرای کمپین چه اتفاقی افتاده.برای مثال:چند مشتری بسته مورد نظر رو خریدند؟نرخ خرید در گروه هدف چقدر بود؟آیا خرید در بازه مورد نظر بیشتر شد؟آیا مشتریانی که قبلا خرید نمیکردند، به خرید ترغیب شدند؟در این مرحله باید حواسمون باشه که صرفا هم زمان شدن یک اتفاق با کمپین، به معنی ایجاد اون اتفاق توسط کمپین نیست.ممکنه فروش به دلایل دیگری هم افزایش پیدا کرده باشه؛ مثلا تغییر قیمت، تعطیلات، رفتار فصلی مشتریان یا اجرای هم زمان یک برنامه دیگر.اگر امکانش وجود داشته باشه، مقایسه با یک گروه مشابه که کمپین رو دریافت نکرده، میتونه به فهم بهتر اثر واقعی کمپین کمک کنه. البته طراحی چنین مقایسه ای باید متناسب با شرایط و محدودیت های کسب و کار باشه.۳. آیا این تغییر، ارزشمند بود؟حتی اگر کمپین باعث افزایش خرید شده باشه، باز هم یک سؤال باقی میمونه: آیا نتیجه به دست آمده ارزش هزینه و پیچیدگی اجرای کمپین رو داشته؟برای پاسخ، ممکنه لازم باشه هزینه هدیه، هزینه ارسال پیامک، درآمد حاصل از خرید، تکرار خرید در آینده و حتی تجربه مشتری رو بررسی کنیم.برای نمونه، افزایش خرید کوتاه مدت اگر با هزینه بالای مشوق یا نارضایتی مشتری همراه باشه، لزوما به معنی موفقیت بلندمدت نیست.قرار نیست برای هر کمپین یک مدل پیچیده مالی بسازیم. مهم اینه که قبل از اجرا بدونیم دنبال چه تغییری هستیم و بعد از اجرا، متناسب با اهمیت کمپین، نتیجه رو بررسی کنیم.قبل از اجرا، چه سؤال هایی باید جواب داشته باشن؟بخشی از این کار باید پیش از شروع کمپین انجام بشه؛ نه وقتی که کمپین تمام شده و همه منتظر گزارش اند.قبل از اجرا بهتره درباره این سؤال ها به توافق برسیم:مسئله چیه؟ دقیقا چه رفتار یا مشکلی رو میخوایم تغییر بدیم؟مخاطب کیه؟ چرا این گروه از مشتریان انتخاب شده اند؟نتیجه مطلوب چیه؟ انتظار داریم چه اتفاقی بیفته؟از کجا میفهمیم؟ کدوم شاخص نشون میده به هدف نزدیک شده ایم؟هزینه و محدودیت چیه؟ چه هزینه ای برای این تغییر میپذیریم؟بعد از اجرا چه میکنیم؟ چه زمانی نتیجه رو بررسی میکنیم و بر اساس اون چه تصمیمی میگیریم؟لازم نیست همه پاسخ ها از ابتدا قطعی باشن. گاهی کمپین خودش فرصتی برای یادگیریه. اما باید مشخص باشه چه چیزی رو نمیدونیم، چطور میخوایم بررسیش کنیم و نتیجه قراره روی چه تصمیمی اثر بذاره.نقش مدیر محصول فقط تحویل نیستدر چنین موقعیتی، کار مدیر محصول فقط تبدیل درخواست به نیازمندی، هماهنگی با تیم های فنی و اطمینان از اجرای درست نیست.این بخش از کار مهمه؛ اما نگاه محصولی یک قدم جلوتر میره: کمک میکنه تیم بدونه چرا این کار رو انجام میده، انتظار چه تغییری رو داره و چطور قراره نتیجه رو ارزیابی کنه.گاهی مهم ترین سؤال قبل از شروع یک کمپین، این نیست که «چه زمانی آماده میشه؟» بلکه اینه که «اگر این کمپین رو اجرا کنیم، دقیقا چه چیزی باید تغییر کنه؟»و بعد از اجرا، سؤال دوم مطرح میشه: «از کجا میدونیم این تغییر اتفاق افتاده و به هدفمون نزدیک شدیم؟»این سؤال ها قرار نیست فرایند اجرا رو سنگین یا کند کنن. برعکس، کمک میکنن تلاش تیم صرفا به تحویل فعالیت ها محدود نشه و تجربه هر اجرا، مبنایی برای تصمیم بهتر در اجرای بعدی باشه.کمپین تمام شده؛ یادگیری چی؟اجرای دقیق و به موقع مهمه. اما اگر بعد از هر کمپین فقط تیک انجام کار رو بزنیم، فرصت یادگیری رو از دست میدیم.ارزش کار محصول فقط در چیزی نیست که ساخته یا اجرا میشه؛ بخشی از اون در تغییریه که ایجاد میکنه و دانشی که برای تصمیم های بعدی به دست میاد.برای همین، شاید قبل از شروع هر کمپین، بد نباشه یک سؤال رو از خودمون بپرسیم:اگر این کمپین رو بی نقص اجرا کنیم، دقیقا از کجا میفهمیم که ارزشش رو داشته؟دوست دارم تجربه شما رو هم بدونم: در تیم شما، بعد از اجرای یک کمپین یا قابلیت، چقدر فرصت و سازوکار برای بررسی نتیجه و یادگیری وجود داره؟#مدیریت_محصول #ProductManagement #ProductOwner اسماعیل شهبازی نژاداسماعیل شهبازی نژادFri, 23 Oct 2026 00:32:34 +0330https://virgool.ir/@es.shahbazi/چرا-تیم-های-محصول-بیشتر-feature-تحویل-میدن-تا-ارزش-edlck2rnonjbممکنه تیم شما در هر اسپرینت کارهاش رو تحویل بده، برنامه انتشارش عقب نیفته و ذی نفع ها هم از سرعت تیم راضی باشن؛ اما هنوز معلوم نباشه این همه کار چه تغییری در وضعیت مشتری یا کسب وکار ایجاد کرده.فرض کنید یک شرکت پرداخت تصمیم میگیره قابلیت جدیدی به پنل پذیرندگان اضافه کنه: نمایش گزارش تسویه ها.جلسه برگزار میشه، نیازمندی نوشته میشه، تسک ها وارد بک لاگ میشن، توسعه و تست انجام میشه و قابلیت در تاریخ مقرر به محیط عملیاتی میرسه.تیم موفق بوده؟ از نظر تحویل، بله.اما چند سؤال هنوز بی جواب مونده:پذیرنده ها قبل از این قابلیت چه مشکلی داشتن؟چند نفر واقعا برای حل اون مشکل به پشتیبانی مراجعه میکردن؟آیا گزارش جدید پیدا کردن اطلاعات تسویه رو راحت تر کرده؟آیا تماس های پشتیبانی کمتر شده یا فقط یک صفحه جدید به پنل اضافه شده؟اگر جواب این سؤال ها رو ندونیم، میتونیم با اطمینان بگیم قابلیت رو تحویل دادیم؛ اما نمیتونیم با همون اطمینان بگیم ارزش ایجاد کردیم.مشکل از کجا شروع میشه؟به نظرم یکی از دلایل مهم اینه که در بسیاری از سازمان ها، مسیر کار از جایی شروع میشه که راه حل از قبل انتخاب شده.مدیر کسب وکار میگه فلان قابلیت رو میخوایم. تیم محصول جزئیات رو مشخص میکنه. تیم فنی تخمین میزنه. اسکرام مستر جلسات رو جلو میبره و تیم توسعه هم کار رو تحویل میده.همه نقش خودشون رو انجام میدن. حتی ممکنه این فرایند خیلی هم منظم باشه.اما یک سؤال مهم، قبل از همه این فعالیت ها، گم شده:اصلا چرا باید این قابلیت رو بسازیم؟وقتی جواب این سؤال روشن نباشه، تیم به جای حل مسئله، روی اجرای راه حل توافق شده متمرکز میشه. از اون لحظه به بعد، موفقیت بیشتر با تعداد آیتم های تحویل شده، رعایت زمان بندی و بسته شدن تسک ها سنجیده میشه.این همون تفاوت بین Output و Outcome است.Output: چیزی که ساختیم و تحویل دادیم؛ مثلا گزارش جدید تسویه.Outcome: تغییری که در رفتار مشتری یا نتیجه کسب وکار ایجاد شده؛ مثلا کاهش زمان پیدا کردن اطلاعات تسویه یا کاهش تماس های پشتیبانی.تحویل قابلیت لازمه، اما به تنهایی اثبات نمیکنه که مسئله حل شده.چرا این اتفاق در سازمان ها تکرار میشه؟به نظرم چند عامل همدیگه رو تقویت میکنن.۱. درخواست دهنده، راه حل رو هم تعیین میکنهوقتی ذی نفع با یک درخواست مشخص سراغ تیم محصول میاد، طبیعی است که گفتگو سریع به سمت جزئیات اجرا بره.اگر مدیر بگه «گزارش تسویه رو به پنل اضافه کنید»، پرسیدن درباره ستون ها، فیلترها و سطح دسترسی منطقیه. اما هنوز معلوم نیست گزارش جدید بهترین راه برای حل مسئله است یا نه.شاید مشکل این باشه که اطلاعات تسویه دیر در دسترس قرار میگیره. شاید اطلاع رسانی مناسبی وجود نداره. شاید هم اطلاعات هست، اما پیدا کردنش دشواره.هر کدوم از این مسائل ممکنه راه حل متفاوتی داشته باشه.۲. تحویل راحت تر از سنجش ارزش اندازه گیری میشهتعداد قابلیت های تحویل شده، تاریخ انتشار و تعداد تسک های بسته شده به راحتی قابل گزارش اند.اما سنجش ارزش به چیزهای دیگه ای نیاز داره: تعریف مسئله، شناخت رفتار فعلی مشتری، انتخاب شاخص مناسب و پیگیری نتیجه بعد از انتشار.وقتی سازمان برای تحویل پاداش میده، اما برای فهمیدن نتیجه وقت و منابع کافی اختصاص نمیده، طبیعی است که توجه تیم هم به سمت تحویل بره.۳. تیم اختیار حل مسئله رو ندارهگاهی از مالک محصول انتظار میره مسئول ارزش باشه، اما اختیارش محدود به نوشتن نیازمندی، اولویت بندی و پیگیری اجراست.تصمیم اصلی جای دیگه گرفته شده، دسترسی به مشتری وجود نداره و بعد از انتشار هم فرصتی برای بررسی نتیجه در نظر گرفته نشده.در چنین شرایطی، صرفا گفتن اینکه «باید Outcome محور باشیم» مشکل رو حل نمیکنه. مسئولیت باید با اختیار، اطلاعات و امکان آزمودن راه حل همراه باشه.چطور از تحویل قابلیت به حل مسئله نزدیک تر بشیم؟لازم نیست از فردا فرایندهای سازمان رو زیر و رو کنیم. میشه از یک تغییر کوچک شروع کرد.برگردیم به مثال گزارش تسویه.گام اول: مسئله رو قبل از راه حل تعریف کنیم.به جای «ساخت گزارش تسویه»، بنویسیم:«پذیرندگان برای پیدا کردن وضعیت تسویه های خودشون زمان زیادی صرف میکنن و بخشی از اون ها برای دریافت اطلاعات به پشتیبانی مراجعه میکنن.»این جمله هنوز یک فرضیه است؛ باید با داده یا گفتگو بررسی بشه.گام دوم: وضعیت فعلی رو بشناسیم.مثلا بررسی کنیم چند تماس درباره وضعیت تسویه ثبت میشه، پذیرندگان برای پیدا کردن اطلاعات چقدر زمان صرف میکنن و چه اطلاعاتی بیشتر از همه درخواست میشه.گام سوم: قبل از انتخاب راه حل، چند گزینه داشته باشیم.شاید گزارش جدید بهترین گزینه باشه. شاید بهبود گزارش فعلی کافی باشه. شاید هم اطلاع رسانی بهتر درباره وضعیت تسویه، بخش بزرگی از مسئله رو حل کنه.گام چهارم: نتیجه مورد انتظار رو مشخص کنیم.مثلا هدف این باشه که تماس های مرتبط با پیگیری تسویه در یک بازه مشخص کاهش پیدا کنه. مقدار هدف باید بر اساس داده های پایه و اهمیت مسئله تعیین بشه، نه اینکه یک عدد دلخواه انتخاب کنیم.گام پنجم: بعد از انتشار، نتیجه رو بررسی کنیم.اگر قابلیت منتشر شد اما رفتار مورد انتظار تغییر نکرد، نباید صرفا به خاطر تحویل موفق، پروژه رو تمام شده فرض کنیم. باید بفهمیم فرضیه مون کجا اشتباه بوده یا چه چیزی هنوز حل نشده.نقش مالک محصول و اسکرام مستر در این مسیر چیه؟مالک محصول باید کمک کنه مسئله، اولویت و نتیجه مورد انتظار روشن باشه و تیم روی مهم ترین کار تمرکز کنه. این مسئولیت صرفا با نوشتن User Story یا مرتب کردن بک لاگ انجام نمیشه.اسکرام مستر هم میتونه به تیم کمک کنه موانع یادگیری و همکاری رو شناسایی کنه؛ مثلا وقتی همه گفتگوها فقط درباره زمان تحویل اند و هیچ فرصتی برای بررسی نتیجه کار وجود نداره.اما هیچ کدوم از این دو نقش به تنهایی نمیتونن فرهنگ سازمان رو تغییر بدن. اگر مدیران فقط خروجی بخوان، دسترسی به مشتری محدود باشه و تیم اجازه انتخاب راه حل نداشته باشه، حرکت به سمت Outcome محور شدن دشوار میشه.یک سؤال برای تیم شمادفعه بعد که یک قابلیت وارد بک لاگ میشه، قبل از اینکه درباره تخمین و زمان تحویل صحبت کنید، این سؤال رو مطرح کنید:«اگر این قابلیت رو بسازیم و منتشر کنیم، دقیقا چه چیزی باید در وضعیت مشتری یا کسب وکار بهتر بشه تا بگیم کار موفق بوده؟»اگر جواب این سؤال روشن نباشه، شاید هنوز برای تخمین زدن راه حل عجله داریم.تحویل به موقع مهمه. کیفیت اجرا مهمه. اما این ها باید در خدمت حل مسئله باشن، نه اینکه خودشون به تعریف موفقیت تبدیل بشن.این مقاله بخشی از مجموعه ای درباره فاصله بین مفاهیم مدیریت محصول و واقعیت کار در تیم های فناوری ایران است.مطالعه مقاله در ویرگول: https://vrgl.ir/zWOhi اسماعیل شهبازی نژاداسماعیل شهبازی نژادSat, 17 Oct 2026 10:58:24 +0330https://virgool.ir/@es.shahbazi/طراحی-یک-محدود-کننده-نرخ-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 21:10:16 +0430https://virgool.ir/@es.shahbazi/چرخه-حیات-توسعه-سیستم-هاsdlc-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 13:56:33 +0430https://virgool.ir/@es.shahbazi/تکنیک-های-جمع-آوری-نیازمندیهای-پروژه-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 +0430https://virgool.ir/@es.shahbazi/نقش-ها-و-مهارت-های-تحلیل-سیستم-هاsystems-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 19:41:49 +0430https://virgool.ir/@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 15:49:35 +0430