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

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

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

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

یکی بودن عنوان دوره با عنوان کتاب، تهدید جدی است چرا که مخاطب تصور خواهد کرد که مطالب دوره همان مطالب کتاب است. با علم به این تهدید، این عنوان انتخاب شد.

با توجه به تجارب گذشته، نسبت به نتایج برگزاری دوره بسیار خوش‌بین هستم. در زیر سرفصل مطالب را آورده‌ام. مطالب بیشتر درباره دوره را می‌توانید در اینجا مشاهده فرمایید.

گزیده:
سفر راستين براي كشف كردن، رفتن به مكان‌هاي تازه نيست، بلكه يافتن نگاهي تازه است. ارسل پروست

Introduction
Requirements: An Introduction
The Role of Requirements in Software Development
Definition, Classification and Levels of Requirements

Analyze the Problem
Problem and Problem Analysis
Problem Analysis in Software Development
Case Study

Understand Stakeholder Needs
Understand Needs
Identify Features in Software System
Using Business Modeling for Needs and Features Identifications
The Importance of Vision
The Role of Business Rules in Software Development
Elicit and Document the Business Rules
Case Study

Define the System
Use Case Model: An Introduction
Develop Use Case Model: Step by Step
Using Business Modeling for Use Case Development
Using UML for Use Case Model
System Wide Requirements
Workshop
Case Study

Object Oriented Analysis- Domain Modeling
Defining the Analysis Model and Its Role in Software Process
Analysis Model Development Approaches
Techniques for Develop the Analysis Model
Workshop
Case Study

Supplementary Topics
Requirements Elicitation Techniques
Requirements in Iterative Process Model
System Analyst Competency Model

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

این گونه کدها را «کد دوست‌داشتنی» می‌خوانیم.
توصیه می‌شود که در تیم‌های کاری یا دانشگاهی این ایده را پیاده کنید. خوشحال خواهم شد از نتایج آن آگاه شوم.

پرسش: شما چگونه کدی را دوست می‌دارید؟

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

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

می خوام تجزیه و تحلیل شی گرا کار کنم. به نظر شما چه کتاب هایی در این زمینه مفید هستد و به چه ترتیبی اونها رو مطالعه کنم»

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

گزیده:

Three sentences for getting success: Know moe than other, Work more than other, Expect less than other; William Shakespeare

Grady Booch, a chief scientist at IBM Research, and his wife Jan have launched a project to tell the story of computing in an 11-episode TV series similar to Carl Sagan’s Cosmos.

I need your help in telling a story, the story of the technology that has changed humanity: computing.

Why Is Computing Important?
Because the story of computing is the story of humanity.
Computing is a story of ambition, passion, invention, creativity, vision, avarice, and serendipity, powered by a refusal to accept the limits of our bodies and our minds. From the abacus to the iPad, from Gutenberg to Google, from Enigma to GPS, we have created computers to count the uncountable, remember beyond our own experiences, and see the invisible as well as the unforeseeable. To explore computing is the 21st Century equivalent of Cousteau exploring the sea, of Hughes exploring modern art, and of Burns exploring the American experience through the Civil War, baseball, and jazz.
In just one or two generations – an imperceptible time in the timeless sweep of the universe – we have created a technology that has the power to extend us, to transform us, to define us, perhaps even to destroy us.

Who Are We?
I am Grady Booch an IBM Fellow, co-creator of UML and Object Oriented Programming – and general braniac and onscreen presenter/host. I know that I cannot do a project this big by myself and so I have gathered around me other people smarter and more creative than me. My wife Jan is a theologian and psychotherapist; she is my co-creator and advisor whose job is to keep it real. Seth Friedman is an award-winning writer and creative director; he is our co-creator and scriptwriter.

More:
http://www.kickstarter.com/projects/1747241049/computing-a-documentary-of-the-human-experience?ref=card

http://www.eweek.com/c/a/IT-Infrastructure/IBM-Chief-Scientist-to-Launch-TV-Series-on-Computing-340515/

Quote:
The amateur software engineer is always in search of magic. Grady Booch

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

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

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

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

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

نکته چهارم: موضوع حائز اهمیت این است که کاری را که قبلاْ انجام نداده‌اید، نمی‌توانید برآورد کنید. فرقی نمی‌کند کدام طرف میز باشید. چه بسیار جلسات مشترک کارفرما، مجری و ناظر(که اتفاقاْ همه مشخصات اشاره شده دوست عزیزمان را دارد) بر سر اندازه‌گیری حجم و زمان انجام یک کار به چالش کشیده شده است. اگر فرض را بر این بگذارید که در مناقصه‌های ایجاد نرم‌افزار، کارفرما به دنبال پیدا کردن پیمانکاری است که این کار را قبلاً انجام داده باشد، این پرسش مطرح می‌شود که آیا به لحاظ قلمرو مسأله، مشخصات تکنولوژیُ، افراد درگير و پارامترهای دیگر، همه پروژه‌های به مناقصه گذاشته شده، مشابه قبلی داشته‌اند؟ چند وقت پیش با تیمی کار می‌کردم و از آنها خواستم که برآورد خود را از کار (به لحاظ فلمرو مسأله، بسیار ساده) ارائه دهند، بندگان خدا گفتند نمی‌توانیم، وقتی دلیلش را پرسیدم گفتند که به تکنولوژی ساخت محصول آشنایی ندارند، حق با آنها بود يا تيم بايد عوض مي‌شد يا گفته‌شان پذيرفته.

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

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

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

نکته آخر: شاید کمی مضحک به نظر آید اما در دیدگاهم متدولوژی‌ها، تکنولوژی‌ها و ابزارها مانند فرزندانی هستند که هر چند خلقیات متفاوت و گاه متضاد دارند، اما همگی آنها دوست داشتنی‌اند.

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

گزیده:
ندارد.

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

دکتر سوکراتس از معدود فوتبالیست‌هایی بود که تحصیلات دانشگاهی داشت. او پزشک بود و کاپیتان تیم ملی فوتبال برزیل در جامهای جهانی ۱۹۸۲ و ۱۹۸۶. گلهای فنی او که با استپ سینه، استپ زانو و بعد شوت محکم همراه بود-به خصوص گلی که به شوروی در جام جهانی ۱۹۸۲ زد-، از او یک چهره ماندگار در فوتبال ساخت.
او جزو ۱۰۰ بازیکن برتر تاریخ فوتبال به انتخاب فیفا و مرد سال آمریکای جنوبی در سال ۱۹۸۳ و یکی از ۶۱ بازیکن برتر قرن بیستم به انتخاب ورلد ساکر بود.
دکتر سوکراتس دیروز در سن ۵۷ سالگی در بیمارستان آلبرت انشتین سائو پائولو از دنیا رفت.
پیشنهاد می‌کنم که مصاحبه با وی را در اینجا ببینید.
گزیده:

“Someone said ‘football is more important than life and death to you’ and I said ‘Listen, it’s more important than that’.” Bill Shankly

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

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

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

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

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

هر کدام بر اساس این دو خصلت (ارتباطات و یادآوری) نیازهای خاص خود را خواهند داشت و نمی‌توان با یک شیوه و نگرش نیازهای آنها را مرتفع نمود.

یکی از سوءتفاهم‌های شایع در مورد متدهای چابک و نظم‌گرا(دیسیپلین)، موضوع نگرش آنها در مورد مدل‌سازی است. گروهی متدهای چابک را با «مستندسازی نکردن» و متدهای نظم‌گرا را «مستندسازی حجیم» می‌شناسند.

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

گزیده:
مدل نمی‌کنیم که مدل کرده باشیم.