اشکالات کتاب – بخش دوم

آقای مهندس بابانژاد از عزیزانی است که آشنایی با ایشان جزو اتفاقات نیک زندگی­‌ام است. ایشان اکنون دانشجوی دکترا در یکی از دانشگاه‌های کانادا هستند. برایشان آرزوی بهروزی و تندرستی دارم.

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

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

۱–ص-۱۱۷ – در بخش جایگاه سند چشم انداز در پاراگراف سوم خط دوم ادعا شده که سند چشم انداز مبنایی برای کنترل و تایید پیشرفت و معیاری برای سنجش تصمیمات اتی است. اما چگونگی آن توصیف نشده است. کاملاً درست می­‌فرمایید. همان طور که استحضار دارید به زبان ساده در سند چشم­‌انداز چند اطلاع مهم وجود دارد: مسأله چیست، نیاز (Need) چیست، قیدها(Constraint) و محدودیت­های پذیرش راه حل کدام است و مهم­‌تر، راه حل(Solution) به صورت کلان چیست و محدود (Scope) سیستم کجاست. این داده­‌ها در همه تصمیم­‌گیری­‌های مهم پروژه دخیل خواهند بود.

از طرف دیگر سند چشم­‌انداز بیان می­‌کند که قرار است کجا برسیم و با چه لوازمی، در هر لحظه می­‌توان اندازه گرفت (به سادگی یا به دشواری) که چه قدر به مقصد نزدیک شده­‌ایم.

از زاویه­ دیگری هم می­‌توان به موضوع نگاه کرد. ویژگی­‌ها و نیازمندی­‌های غیرکارکردی موجود در سند چشم­‌انداز بخش مهمی از اقلام کاری-Work Item List در UP- یا به زبان اسکرام Product Backlog را تشکیل می­‌دهند (البته همانطور که استحضار دارید این دو تفاوت ماهوی دارند و مثال برای نزدیک کردن نگرش بیان شده است) که یکی از معیارهای پیشرفت پروژه مقایسه اقلام کاری انجام شده نسبت به اقلام برنامه­‌ریزی شده است.

برای بیان روش و چگونگی آن لازم بود مفاهیمی دیگری از جمله برنامه­‌ریزی و پایش پروژه و مدیریت محدوده توضیح داده شود. از این رو از آن صرف نظر شد.

۲–در ص ۱۵۳ که در ان یک مورد کاربرد مثال می زنیم در یکی از موارد می گوییم : کاربر گزینه تایید را انتخاب می کند به نظرم اینجا کمی بحث مربوط به طراحی وجود دارد بهتر است بگوییم کاربر تایید می کند با شما کاملاً موافق هستم.
اما به تجربه در پروژه­‌ها به این نتیجه رسیده­‌ایم که گاهی وجود این گونه اطلاعات در موردهای کاربرد هر چند مناسب نیست، ولی مفید است. به عبارت دیگر به شخصه توصیه می­‌کنم که این­گونه نوشته شوند تا جایی که زیاد وارد طراحی نشوند. به عنوان مثال در نمونه­‌ای که فرمودید این عبارت به دو دلیل توصیه شده است: یک) کاربر تصور مناسبی از رابط کاربر داشته باشند. دو) مراجعه طراح رابط کاربر به تحلیل­گر کاهش یابد.

۳-ص ۱۹۲ – به نظرم بهتر است در بخش پاسخ به پرسش های تحلیلی برای شناسایی کنشگرها پرسش چه کارهایی به صورت خودکار انجام میگیرند ویا تناوبی هستند و اینکه چه کسانی سیستم را اول بار بالا می اورند اضافه شوند برای شناسایی کنشگرهای زمانی و یا مدیریتینکته به جا و درستی فرمودید. در ویرایش بعدی کتاب لحاظ خواهد شد.

۴-در بخش ۱۰-۳ – سازماندهی مبتنی بر کسب کار، اگر یک مورد کاربرد یا کنشگر در چند بسته قرار بگیرند چه؟در این گونه مواقع از روشهای مرسوم در طبقه­‌بندی استفاده می­‌کنیم به عنوان مثال یک پکیج با نام مشترک یا عمومی ایجاد و موردهای کاربرد یا کنشگرهای مشترک را در آن قرار می­‌دهیم(روش ایجاد). مثال دیگر آن که کنشگر در یکی از پکیج­‌ها که بدان متمایل­‌تر است، قرار داده می­‌شود(روش وزن­‌دهی).

۵-سوال کلی: به نظرم حجم انبوهی از مطالب کتاب به اموزش UML اختصاص داده شده است. آیا به نظرتان این حجم اموزش نیاز بود؟ چرا بخشهایی که مربوط به خود نیازمندیها بود کمتر بدانها پرداخته شد؟ مثلا تکنیک های استخراج نیازمندیهاضمن آن که با شما کاملاً موافق هستم و ایده اولیه مطابق نظر شما بود یعنی فرض شده بود که خواننده تسلط کافی بر UML دارد. محدودیت دیگری نیز وجود داشت که قبول این فرض را تقویت می­‌کرد: محدودیت تعداد صفحات کتاب از طرف ناشر. با این حال به ناچار بخشی کوچکی از کتاب برای توضیح نمودارهای مورد استفاده در تحلیل نیازمندی­‌ها اختصاص یافته است. این تصمیم به دلایل زیر گرفته شده است:

الف) یکی از کمبودهایی که مشاهده کرده­‌ایم این است که با این که همگی عزیزان با UML آشنا هستند اما تسلط آنها به اندازه­‌ای نیست که حداقل مهارت و دانش لازم برای مدل­سازی را داشته باشند. یعنی با این که کسی نیست که UML را نداند، اما توانایی مدلسازی موضوعات تحلیلی در آنها دیده نمی­‌شود. شاهد آن که همه عزیزان می­‌دانند که نمودار فعالیت (Activity Diagram) چیست و حتی می­‌توانند از آن برای مدلسازی موضوعات ساده استفاده کنند، اما موضوع که پیچیده می­‌شود تنها ابزاری که در دست دارند، توضیح (کامنت) گذاشتن در نمودار است. در یکی از مشاوره­‌ها، طرف مشاوره قصد داشت BPMN را جایگزین UML کند. وقتی دلایلش را جویا شدم، بخش زیادی از دلایل فقط مربوط به نادانسته­‌های وی از UML می­‌شد و نه توانایی و ناتوانی BPMN و UML برای رفع نیاز وی.

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

ب) یکی از نکاتی که لازم است تأکید شود، استفاده از نمودارها و اجزای مدلسازی و در اینجا UML برای تحلیل سیستم و ابزار مهندسی است. در حالی که نگرش غالب به مقوله مدلسازی، «ابزار نقاشی» است تا «ابزار مهندسی».

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

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

۶-فرایند کلی که در تعریف کتاب استفاده شده چیست؟ منظورم اینست که ایا فرایند محور فکر کرده اید یا محصول محور؟ یعنی اینکه اول گفتیم چه محصولاتی در مهندسی نیازمندیها وجود دارد و سپس بگوییم چه فعالیت هایی برای تهیه انها نیاز است مثلا سند چشم انداز را وسط قرار می دهیم و سپس نحوه تهیه آنرا مشخص می کنیم. همه سعی­‌مان بر این بوده که کتاب فرایند محور باشد. دلیل این کار در مقدمه کتاب گفته شده است: «یکی دیگر از عوامل بروز چالش‌های مذکور، دشواری نگاشت و اجرای فعالیت‌های فرآیندهایی چون RUP در تیم­ها است. این عامل باعث می‌شود که چارچوب فکری تیم‌ها به جای وظیفه‌محوری (Task Driven) به محصول‌محوری (Work Product Driven) سوق داده شود. به عنوان مثال، تیم توسعه تنها به تدوین محصول‌کاری «سند چشم‌انداز» می‌اندیشد، نه به انجام مجموعه‌ای از وظیفه‌ها و کارها که منجر به این سند می‌شود. چگونگی انجام وظیفه‌ها، ترتیب اجرای آن‌ها و تکنیک‌های مرتبط، منجر به شکل‌گیری چارچوبی ذهنی در تیم می‌گردد که در روش محصول‌محوری کم‌رنگ است. این کتاب در کنار معرفی محصولات‌کاری، بر وظیفه‌ها و تکنیک‌های انجام آن‌ها نیز تأکید دارد.»

فرایند از سه گام اصلی «تحلیل مسأله»، «شناسایی نیازهای ذینفعان» و «تعریف سیستم» تشکیل شده است. گامهای دوم و سوم دارای دو زیر گام هستند.

روش کتاب آموزش گام به گام تحلیل نیازمندی­ها است. به عنوان مثال «تحلیل مسأله» و زیرگامِ اولِ «شناسایی نیازهای ذینفعان» منجر به تهیه سند چشم­‌انداز می­‌گردد. پس از تشریح گامها محصول نهایی –در اینجا سند چشم­‌انداز- معرفی شده است. البته در هر گام به صورت پانویس اشاره شده است که نتیجه این گام چه بخشی از سند چشم­‌انداز خواهد بود.

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

در اجرای این شیوه – تفکر وظیفه محور- برای شناسایی مشخصات تکمیلی-supplementary specification- خیلی مؤفق نبوده­‌ایم و پتانسیل زیادی برای کار مجدد و تکمیل دارد و خودم از این بخش نسبت به سایر بخش­ها رضایت قلبی کمتری دارم.
اگر پیشنهادی برای رفع این عیب دارید، از شنیدن آن خوشحال خواهم شد.

پانوشت: از دریافت ایرادات، نقدها و نظرات عزیزانم در مورد کتاب استقبال کرده و خوشحال می‌شوم.

گزیده:

Write how you want, the critic shall show the world you could have written better.
Oliver Goldsmith, Irish writer, poet, and physician.