وبلاگ

گاه نوشته های امین رشیدی

CC

کارگاه عملی استخراج نیازمندیها (یوزکیس) – قسمت اول

16th نوامبر ، 2014

در سری آشنایی با یوزکیس، قسمت اول یوزکیس متنی رو معرفی کردم و در قسمت دوم اجزای یک یوزکس رو شرح دادم. حالا میخوایم یک پروژه فرضی رو با این روش به انجام برسونیم. عنوان پروژه اینه: “سیستم ثبت سفارش آنلاین برای یک شرکت چاپی”

برای اینکه توضیحاتم طولانی نشه تمرکز رو روی شناسایی و تکمیل یوزکیسها قرار میدم و سندهای جانبی رو تولید نمیکنم. برای اینکار از روشی که Craig Larman در کتابش معرفی کرده، استفاده می‌کنم:

  1. تشخیص آکتورها
  2. استخراج اهدافی که هر آکتور در سیستم انجام می‌دهد
  3. دسته بندی اهداف گام ۲ در یوزکیسها
  4. بررسی و تشخیص مرز سیستم
  5. توسعه یوزکیسها

آکتور؟ برای یادآوری بگم که آکتور (Actor) یا همون علامت “آدمک”، بصورت خلاصه نقشی هستش که افراد یا سایر سیستمها در رابطه با سیستم مورد نظر ما بازی میکنن. “کاربر نهایی”، “مدیر پروژه”، “مدیر عامل”، “دستگاه بارکد خوان” و “سیستم پشتیبانگیری” همگی در یک سیستم فرضی میتونن آکتور باشن. در کل سه نوع آکتور داریم، آکتورهای “اولیه”، “پشتیبانی” و “خارج از محدوده”. در بحث ما آکتورهای اولیه مهم هستن چون ارتباط اصلی رو با سیستم ما برقرار میکنن.

 

و در نهایت چیزهایی که برای این پروژه کوچک لازمه ولی من بهش کاری ندارم:

  • قرارداد بین شما و کارفرما
  • تعریف کلی سیستم که نتیجه بررسی اولیه شما قبل از شروع کار هستش
  • مدیریت پروژه و فازبندیهای کار
  • مدل سازی نرم افزار
  • طراحی واسط کاربر
  • موارد مربوط به تست سیستم
  • کد نویسی محصول

گام اول استخراج آکتورها و اهداف

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

در نهایت شما جدولی تهیه میکنین که شامل نقش افراد در سیستم (آکتورها) و وظایف این افراد (اهداف) خواهد بود. برای سیستم مورد مثال ما جدول می‌تونه به این صورت باشه:

 

آکتور اهداف نوع آکتور
سفارش دهنده (مشتری) سفارش دادن پشتیبان
سفارش گیرنده (اپراتور) ثبت قرارداد اولیه
منشی شرکت هماهنگی زمان مراجعه مشتری خارج از محدوده
مدیر عامل تأیید سفارش پشتیبان / اولیه ؟
مسئول سفارش چاپ سفارشتحویل سفارش پشتیبان / اولیه ؟
مدیر انبار انجام امور انبار
تحویل گرفتن مواد اولیه سفارش
خارج از محدوده
باربر تحویل نهایی سفارش به مشتری پشتیبان
دستگاه توزین وزن کردن مواد اولیه خارج از محدوده
حسابدار دریافت وجه از مشتریتأیید تحویل پشتیبان
نرم افزار حسابداری انجام امور حسابداری خارج از محدوده

 

بی شک این لیست الان کامل نیست و بعداً ممکنه آکتورها و افراد بیشتری بهش اضافه بشه. دوتا مورد رو مواظب باشین:

  • بجای نقش از اسم افراد استفاده نکنین.
  • نقشهایی رو ذکر کنین که ارزش تجاری دارن. مثلاً “جارو کشیدن” ربطی به کسب و کار نداره.

گام دوم شناسایی اهداف آکتورها

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

در پروژه نمونه ما برای مشخص کردن محدوده سیستم باید آکتورها و اهداف رو تصفیه کنیم برای همین آکتورهای “خارج از محدوده” که در چارت اومدن رو کنار میذاریم و روی  آکتورهای “اولیه” تمرکز می کنیم و نیم نگاهی هم به “پشتیبانی”ها داریم.  من بسته به صلاحدید خودم این اهداف رو انتخاب کردم:

  • ثبت قرارداد
  • تأیید سفارش
  • چاپ سفارش
  • تأیید تحویل
  • تحویل سفارش

مسلماً شما ممکنه پروژه رو بزرگتر درنظر بگیرین و همه کارهای بالا رو بصورت یک سیستم جامع ببینید ولی ببخشید کارفرمای من ۲میلیون بیشتر پول نمیده و تحت وب هم سیستم رو لازم داره پس من نمی‌تونم بیشتر از این چیزی در نظر بگیرم.

خوب این گام تموم شد و ما کارهایی که سیستم باید برای مشتری انجام بده رو داریم. دوباره میگم که شما ممکنه به صلاحدید خودتون در پروژه موارد بیشتر یا کمتری رو در نظر بگیرین.

گام سوم دسته بندی یوزکیسها

کم کم داریم به بحث شیرین یوزکیس نزدیک می‌شیم. کاری که باید بکنیم این هستش که اهداف خروجی گام اول رو در چند یوزکیس سازماندهی کنیم.

 

اسم یوزکیس هدف آکتور اصلی
ثبت قرارداد ثبت قراردادویرایش قراردادکنسل کردن قرارداد سفارش گیرنده (فردی در واحد سفارشات) / مشتری
انجام سفارش چاپ سفارش مدیر بخش سفارشات
تحویل سفارش تأیید تحویلتحویل سفارش مدیر انبار

 

لازمه چندتا نکته رو بصورت سئوال و جواب توضیح بدم،

 

“ویرایش” و “کنسل کردن” قرارداد از کجا آمد؟

شما خواهی نخواهی لازم هستش که از روی تجربه مواردی رو با تأیید کاربر به چیزی که کاربر میگه اضافه کنین یا حتی تغییر بدین. (در پروژه هایی که شامل تحلیل و طراحی تجاری هم میشه، اصلاً لازمه قبل از هر کاری شما یوزکیسهای تجاری رو بنویسین و تغییرات لازمه رو روی نحوه انجام کسب و کار بدین که خارج از بحث ماست)

 

چرا چند هدف در یک یوزکیس آمده؟

اول بگم تقسیم عملیات در بین یوزکیسها خیلی مهمه و باید دقت کنین یوزکیسها خیلی چاق یا خیلی لاغر نباشن. این مورد رو تحت عنوان Granularity در یوزکیس می‌تونین مطالعه کنین یا اگر خواستین توی کامنت سئوال کنین. برگردیم به سئوال: گاهی برای رعایت Granularity لازمه چند عمل در یک یوزکیس قید بشن در همین رابطه  Alistair Cockburn در کتاب Writing Effective Use Cases بحث میکنه که مثلاً نوشتن عملیات CRUD (منظور ایجاد و حذف و ویرایش) در یک یوزکیس بهتره تا جدا کردن اونها.

 

آکتورهای اصلی چطوری انتخاب شدن؟

این موارد در جلسات با مشتری مشخص میشه مثلاً در جلسات مختلف مطرح میشه که شرکت تمایل داره “مسئولیت” کدوم کار با کدوم بخش باشه و در اون بخش چه کسی (چه نقشی) این کار رو انجام بده. در این سیستم فرضی اینطوری شده که در جدول می‌بینید.

 

آیا جور دیگه ای هم میشه سامان داد؟

بله! هیچ تنها راه درستی در تولید نرم افزار وجود نداره و نسبت به پروژه و مجری متغیر.

 

در قسمت بعد

هفته آینده شروع می‌کنیم به نوشتن یوزکیس، برای اینکار از حالت ساده یوزکیس استفاده می‌کنیم و به مرور به حالت “کامل” می‌رسیم.

ارجاعات

نظرات

  1. مجید مرآتی فشی
    11 نوامبر 2015 در 11:56 ق.ظ - پاسخ

    خیلی مفید بود و کامل. خیلی کمکم کرد. موفق باشید

    • امین
      11 نوامبر 2015 در 10:00 ق.ظ - پاسخ

      خوشحالم که مفید بوده، اگر پیشنهادی دارین ممنون میشم به اشتراک بگذارید.

  2. پریسا رشیدی
    3 مارس 2016 در 7:24 ق.ظ - پاسخ

    امیدوارم موفق باشید

  3. پریسا رشیدی
    3 مارس 2016 در 7:26 ق.ظ - پاسخ

    منتظر مقالات مفید بعدی شما هستیم.

  4. 6 ژوئن 2016 در 1:43 ب.ظ - پاسخ

    خیلی ممنون از توضیحات خوبتان
    ببخشین بخش بعدی اموزش کی بر روی سایتتون قرار میگیره؟؟

    • امین
      5 می 2017 در 1:22 ب.ظ - پاسخ

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

  5. ZIAEI
    10 اکتبر 2016 در 8:12 ق.ظ - پاسخ

    سلام

    مرسی از توضیحات خوبتان
    ادامه این بخش را منتشر نمیکنید؟
    ترجمه ای از کتاب WRITING Effective Use Cases موجود هست؟

    • امین
      5 می 2017 در 1:21 ب.ظ - پاسخ

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

  6. 1 ژانویه 2017 در 7:29 ق.ظ - پاسخ

    خیلی شسته رفته و مفید بود. لطفا در مورد granularity یکم بیشتر توضیح بدید و یه مثال بزنید. سپاس

    • امین
      1 ژانویه 2017 در 7:51 ب.ظ - پاسخ

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

  7. علی
    5 می 2017 در 8:25 ق.ظ - پاسخ

    خیلی خوب
    منتظریم

    • امین
      5 می 2017 در 1:19 ب.ظ - پاسخ

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

  8. 8 آگوست 2018 در 2:54 ب.ظ - پاسخ

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

  9. حسن حمیدی
    12 دسامبر 2019 در 5:51 ق.ظ - پاسخ

    با سلام
    خیلیمطلب جالبیبود اما خیلی وقته که منتظر ادامه ان هستم …