اومدیم چین

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

فایرفاکس برای بچه خفن ها

درود بسیار بر دوستان

شده زمان ول چرخی تو اینترنت با خودتون بگین کاش جای دید براتون بیشتر بود ؟ خوب من امروز شما رو با یک سری افزونه های فایرفاکس آشنا می کنم که دقیقا همین کار رو می کنن و یکی دو تا هم قرتی بازی برای رنگ و لعاب و دو تا هم مدیر دانلود که یکیش پیشنهاد خودمه و دیگریش رو آیدین خیلی باهاش حال می کنه. پیش از خوندن دنباله ی داستان توجه شما را به چند نکته جلب می کنم: نخست اینکه پیوندهایی که دادم برای نسخه ی ویندوزی این افزونه هاست. دوم اینکه اگر کاربر لینکوس هستید میتونید اینها رو در گوگل یا سایت افزنه های فایر فاکس جستجو کنید یا اینکه از منوی «Tools» گزینه ی «Add-ons» رو انتخاب کنید و از اون یکی راه نصبشون کنید. از همه مهم تر اینکه آخرین نسخه ی فایر فاکس رو بریزید چون برخی از این افزونه ها روی نسخه های دیگه درست و درمون کار نمی کنند.

فایر فاکس من با همه این داستانها

رفع شر نوار عنوان

نخستین گام اینه که اون نوار کاملا بی مصرف و بی رنگ و بو و خاصیت که بهش میگن «نوار عنوان» رو برداریم. برای این کار افزونه ی

Hide Caption Titlebar Plus

رو نصب کنید

نوار عنوان حذف شده

منوهای فشرده

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

Compact Menu 2

رو نصب کنید و زمانی که درباره ی نمایش دکمه ی منو ازتون پرسید بهش پاسخ «بله» رو بدید . البته اینجا دموکراسیه و می تونید پاسخ دیگری بدید اما بعدا دهنتون آسفالت شد به من چه

نوار منوها تبدیل به یک دکمه شده

تب ها در بالا

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

Tabs on Top

رو نصب کنید

تب ها رفتن بالا

خر خون کثیف

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

Full Flat

رو نصب کنید.

تب های رنگی و نوارپیشرفت به سبک سافاری

وقتی تم رو نصب کردین شاید به نظرتون زیادی مسطح و بی رنگ بیاد. اگر این گونه است افزونه های

Colorfull Tabs

و

Fission

رو هم نصب کنید تا یک رنگ و لعابی به داستان داده باشین.

مدیر دانلود

برای مدیر دانلود پیشنهاد من اینه

DownThemAll

اما اینو بگم که خیلی دنگ و فنگ داره و اگر یک مدیر دانلود حرفه ای نمی خواین باید این یکی رو نصب کنید

Download Statusbar

که خیلی سبک تر و راه دست تره

خوف شبکه – آپی معتبر و نامعتبر

درود بسیار

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

تعریف خدمات دسترسی به اینترنت

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

نشانی آی‌پی معتبر و نامعتبر

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

از کجا بدونم داستان آی‌پی من چیه ؟

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

۱۹۲.۱۶۸.۰.۰/۱۶ (192.168.x.y  0 < x,y < 255 )
10.0.0.0/24    (10.x.y.z 0 < x,y,z < 255)
127.16.0.0/12  (from 127.16.0.0 to 127.31.255.255)

اگر آی‌پی شما توی هر یکی از این بازه‌هاست نامعتبره و نمیشه به شما وصل شد اما در غیر اینصورت معتبره. برای نمونه این نشانی‌های آی‌پی

188.121.131.1۰۰ , 85.198.19.131

معتبر هستند چون در هیچیک از بازه‌های خصوصی نیستند اما اینها همه‌شون نامعتبر هستند چون خصوصی هستند:

۱۹۲.۱۶۸.۰.۱۲, 192.168.23.56, 10.34.0.78, 172.16.23.67

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

http://myipaddress.com

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

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

http://www.canyouseeme.org

http://www.yougetsignal.com/tools/open-ports

نشانی آی‌پی تون رو خود سایت تشخیص میده و باید شماره‌ی پورتی که می‌خواهید رو وارد کنید ( برای‌ نمونه پورت وب یا تورنت ) و ببینید که میشه به شما وصل شد یا خیر. اگر شد که هیچ اگر نشد و تا اینجاشو درست اومده باشین به احتمال بسیار بالا خودتون فایروال‌ی  دارین که داره دسترسی رو میبنده یا اینکه آی‌اس‌پی تون دسترسی رو بسته.

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

خب تا اینجاشو داشته باشین تا بعد.

خلاصه

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

• نشانی آی‌پی : ‌‌IP Address
• نشانی آی‌پی خصوصی : Private ip address
• نشانی آی‌پی نامعتبر : Invalid ip address
• نشانی آی‌پی عمومی : Public ip address
• نشانی آی‌پی معتبر : Invalid ip address
• بازه‌ی آی‌پی : IP Range
• برگردان نشانی شبکه : Network Address Translation – NAT
• پروکسی : Proxy
• کش : Cache
• پورت : Port
• تورنت : Torrent
• اشتراک فایل : File Sharing
• دسترسی (اتصال) مستقیم به اینترنت : Direct Internet Access – Connection
• دسترسی (اتصال) غیر مستقیم به اینترنت : Indirect Internet Access – Connection

مهندسی نرم‌افزار – بخش پنجم (فاز تحلیل – مخ‌زنی)

درود بر دوستان. چون بخش چهارم نامش «آشنایی» بود با خودم گفتم این بخش نامش میشه «مخ‌زنی» .شما پس از اینکه آشنا میشین چیکار می‌کنین؟ من که میرم تو کار مخ‌زنی

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

صورت مسئله

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

نیازمندیها

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

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

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

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

نیازمندیهای کارکردی می‌گویند که نرم‌افزار چه کاری انجام می‌دهد و نیازمندیهای غیرکارکردی مشخصات نرم‌افزار را از جنبه‌هایی غیر از کارکردهای آن تعریف می‌کنند

در نوشته‌ی بعدی میگم که چه جوری میشه نیازمندیها رو بدست آورد و اونها رو نوشت و به یوز کیس هم میرسیم انشاء الله

• نیازمندیها :‌ Requirements
• کارکرد : Function
• کارکردهای نرم‌افزار –  کارهایی که انجام میده : ‌Functionality
• نیازمندیهای کارکردی : Functional Requirements
• نیازمندیهای غیر کارکردی : Non-functional Requirements

مهندسی نرم‌افزار – چرا چیزایی که میخونیم رو نمی‌فهمیم؟

اولا که خودت نمی‌فهمی چی داری میخونی! دوما که … حالا مونده‌اش رو بخون شاید این‌بار فهمیدی

درود بسیار بر دوستان گرامی. میدونم تو دلتون چی میگین و کاملا حق با شماست. گرفتار بودم بابا! هم کاری هم احساسی هم غیر کاری و غیر احساسی. حال و حوصله‌ی مقدمه چینی هم ندارم پس میریم سر اصل مطلب.

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

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

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

نتیجه رو براتون کوتاه می‌کنم:

• برخی مفاهیم برای همه جور نرم‌افزاری برقراره (کوچیک و بزرگ) اما برخی مفاهیم تنها برای نرم‌افزارهای بزرگ و پیجیده معنی میده. برخی مفاهیم تنها زمانی معنی میده که کار تیمی کنید و برخی  دیگر زمانی که در تنگنای زمانی باشید یا براستی با یک مشتری سر و کله بزنید.
• اون چیزهایی که برای نرم‌افزار های حقیقی (= بزرگ و پیچیده و احتملا نیازمند کار تیمی) معنی میده رو نمی‌تونید با کتاب خوندن و یا نوشتن پروژه‌های دانشگاهی  و کلیشه‌ای یاد بگیرید
• پس برین برای خودتون پروژه تعریف کنید و با کله برین توش تا بفهمین چی شد

تمدید شرمندگی

دیگه روم نمیشه تو چشمای داش علی نگاه کنم

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

نظر خواهی

درود. برای تنوع چند تا نظر‌خواهی گذاشتم توی سایت. اگر تزی دارین بدین که اونم بگذاریم توی سایت

بازگشت دوباره با خبرهای خوش

درود بسیار بر همه‌ی دوستان

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

مهندسی نرم افزار – بخش چهارم ( فاز تحلیل – آشنایی)

درود بسیار بر دوستان

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

مسئله ای که درست گفته شود نیمی از راه حل را در خود دارد

پیش از حل کردن هر مسئله ای باید نخست صورت اون مسئله رو فهمید. قبل از گشتن به دنبال پاسخ یک پرسش باید خوب پرسش رو درک کرد. نرم افزار هم از این قانون جدا نیست و پیش از دست بردن به هر کاری نخست باید ببینیم مشتری چی میخواد و چی قراره نوشته بشه، سپس بریم تو کار طراحی و بعدش هم برنامه نویسی. همین چهار تا واژه ی به ظاهر ساده ای که گفتم خودش میشه یک فاز. فاز «تحلیل». درسته که ساده و سر راست به نظر میاد اما تنها به نظر میاد و در کار یکی از خفن ترین فازهاست و ریسک های فاز تحلیل ریشه ی نرم افزار رو خشک می کنند. تحلیل گر ها بیشتر از همه ی نقش های دیگر پول می گیرند و مسولیتی که به عهده ی اونهاست از همه بیشتره. فاز تحلیل خوب نیمی از پیروزی رو تضمین می کنه و فاز تحلیل بد بی برو برگرد به شکست پروژه خواهد انجامید. اگر تو فاز تحلیل به اندازه ی یک دلار خطا کنید برای جبران همون خطا تو فاز طراحی باید 10 دلار و در فاز پیاده سازی 100 دلار و در فاز آزمون 1000 دلار پیاده بشید. اما چرا ؟ خیلی ساده است چون فاز تحلیل صورت مسئله رو برای همه ی دیگر نقشها و فازها تعریف می کنه واگر اینجا خطایی رخ بده دیگه رفت تا زمانی که گندش در بیاد. اینجا همون «خشت اول» هستش که گر نهد معمار کج، تا عباس آباد می رود اوتوبان کج.

ارزش افزوده – دلیل وجود صنعت نرم افزار

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

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

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

باشین تا بعد میرسیم به مونده ی ماجرا.

مهندسی نرم افزار – بخش سوم (مدل آبشاری، فازها)

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

 چی هست این روش آبشاری؟

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

۱ – فاز «تحلیل» : در این فاز مهندس نرم‌افزار تلاش میکنه تا مشخصات و کارکردهای نرم‌افزار محصول رو تعریف و مشخص کنه. در این فاز حرف حرف مشتریه و در حقیقت می‌خواهیم بفهمیم مشتری دقیقا از ما چی‌میخواد و دوست داره نرم‌افزاری که می‌سازیم دقیقا چی کار کنه و خلاصه نکاتی از این دست رو بهشون توجه می‌کنیم. در این فاز برامون مهم نیست که برای رسیدن به اون کارکردهای لازم چه طرحی خوبه یا چه جوری پیاده سازی میشه. تنها چیزی که برامون مهمه اینه که مشخصات نرم‌افزار بدست بیاد.

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

۳- فاز «پیاده سازی»: اینجا دیگه آخر خطّه اخوی (یا هم شیره). چرا؟ آها! چون مشخصات محصول پایانی بدست اومده و طرحش هم ریخته شده و زمانی که اجرا شد نتیجه‌اش میشه همون چیزی که می‌خوایم و تنها چیزی که مونده اینه که یه سری برنامه نویس و پایگاه داده بساز و گرافیست و … بیان و طرح رو اجرا کنند. اجرای طرح نرم‌افزار یعنی همون برنامه نویسی و کدنویسی. برنامه نویس باید طرح رو بخونه و کدش رو بنویسه.

 

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

تحلیل – طراحی –  پیاده سازی

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

نقشها:

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

تحلیلگر : کسی که نقش کلیدی رو در فاز تحلیل بازی میکنه. تحلیلگر وظیفه داره فاز تحلیل رو آغازکنه و به پایان برسونه. تحلیل گر باید مهارتهای انسانی و منطقی زیادی داشته باشه و مدلسازی هم بلد باشه. تا اندازه‌ای هم از دامنه کاری مشتری سر در بیاره.

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

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

این ارتباطات رو بیاد داشته باشید:

فاز تحلیل -> تحلیلگر

فاز طراحی -> طرّاح

فاز پیاده‌سازی -> برنامه نویس

 

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

 

فازها و نقشهای افزونه‌ای

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

فاز آزمون:

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

فاز برپایی (نصب):

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

فاز پشتیبانی:

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

فاز گردآوری نیاز (جمع آوری نیاز):

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

فاز تحلیل دامنه:

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

 

خوبُ شر و ور زیاد گفتیم. بخونید که در نوشته‌ی بعد میزنیم به قلب ماجرا.

 

• فاز:Phase
• تحلیل:Analysis
• پیاده سازی:Implementation
• برپایی:Deployment
• دامنه:Domain
• تحلیل دامنه:Domain Analysis
• تحلیلگر:Analyst
• تحلیلگر دامنه:Domain Analyst
• مهنسی دامنه:Domain Engineering
• نقش:Role
• نقش کلیدی:Key Role
• نقش اصلی:Main Rolepan
• نقش جنبی:Subsidiary Role
• مدل آبشاری:Waterfall Model