کارگاه سه روزه تحلیل نیازمندی‌های سیستمی در تاریخهای ۹ تا ۱۱ آذر برگزار می‌شود. برای اطلاعات بیشتر به این آدرس مراجعه فرمایید.

گزیده:
شما همه چیز‌ها را آن‌گونه که هست می‌بینید و می‌پرسید که “چرا” و من چیزها را آن‌گونه که هیچ‌وقت نبوده‌اند تصور می‌کنم و می‌پرسم “چرا که نه؟” جورج برنارد شاو

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

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

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

۱–ص-۱۱۷ – در بخش جایگاه سند چشم انداز در پاراگراف سوم خط دوم ادعا شده که سند چشم انداز مبنایی برای کنترل و تایید پیشرفت و معیاری برای سنجش تصمیمات اتی است. اما چگونگی آن توصیف نشده است. کاملاً درست می­‌فرمایید. همان طور که استحضار دارید به زبان ساده در سند چشم­‌انداز چند اطلاع مهم وجود دارد: مسأله چیست، نیاز (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.

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

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

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

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

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

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

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

گزیده:
«جلوگیری از تکرار تاریخ کاری بیهوده است زیرا شخصیت آدمی طوری است که اجتناب از تکرار را غیر ممکن می‌سازد.» مارک تواین

“Self-organizing teams can decide everything by themselves. So they don’t need an architect.” writes Samudra Kanankearachchi on the Software Architecture group of LinkedIn.

This feels to me like one of these strange agile koans. If you repeat it often and long enough, it will gradually become the truth.
Self-organizing teams have very little to do with the architecture of your system. Self-organizing teams are about: task allocation, collaboration, communication, accountability, … it may have to do with time-boxing and therefore what gets accomplished in a certain time-frame. Architecture is about making decisions (choices) about the structure, composition, organization of the software system. It also feels like “architect” is necessarily not a member of the team. Not my personal experience or recommendation. Architect is a role, not necessarily a person (whose only role is to be an architect, though these exist in large organizations.)

Most systems tackled by small agile teams have a pre-defined stable architecture. So yes, they do not need to have anyone playing the role of architect. For novel complex systems, where architectural decisions need to be made, if they are made “by the team”, it means that the team plays the role of architect, and hopefully they have the knowledge and experience to do so. Like some teams have a scrummaster and a product owner, such teams should have an architecture owner, who drives the discovery of architectural issues and their resolution. Because an architecture is not going to gradually emerge out of weekly refactorings (another agile koan), unless this emergence is guided somehow.
Philippe Kruchten

P.S.: Agile Architecture by Scott Ambler

Quote:
Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
Dave Quick

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

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

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

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

گزیده:
هرناندو دو سوتو در كتاب پر آوازه‌ي خود يعني «راز سرمايه» (يا چرا سرمایه داری در غرب موفق می‌شود و در جاهای دیگر شکست می‌خورد)، بخشي را به اهميت مستندسازي و مكتوب كردن اطلاعات و ثبت و ضبط دانش اختصاص داده است. دو سوتو با مطالعه‌ي كشورهاي توسعه‌يافته و كشورهاي در حال توسعه و مقايسه‌ي آنها در مي‌يابد يكي از رموز اصلي پيشرفت كشورهاي غربي را، وجود انواع مستندات و مكتوبات قابل اعتنا و معتبر در زمينه‌هاي مختلف و در دسترس بودن آنها براي عموم مي‌داند.
مرجع: وبلاگ شهروند دردمند