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

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

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

صورت مسئله

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

نیازمندیها

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

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

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

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

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

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

• نیازمندیها :‌ 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

سیاسی بازی

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

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

مهندسی نرم افزار به زبان (واقعا) ساده – بخش دوّم

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

پیش درآمد

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

1. نرم‌افزار هم مانند هر محصول دیگری برای اینکه درست و با کیفیت ساخته بشه نیاز به مهندسی داره بنابر این هدف از مهندسی نرم‌افزار اینه که تیم نرم‌افزاری بتونه در زمان و هزینه‌ی پیش بینی شده نرم‌اقزاری با کیفیت بسازه.
2. نرم‌افزاری «با کیفیت» خوانده میشه که : 1) نیازمندی‌های مشتری رو برآورده کنه. یعنی همون کاری رو بکنه که مشتری براش پول داده و 2) در آینده هم بسادگی بتونه نیازمندیهای جدید رو برآورده کنه
3. این کیفیت باید در زمان بندی و هزینه‌ای که سرش توافق شده بدست بیاد نه ده سال بعد با سوبل هزینه !

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

مهندسی نرم افزار (همچون هر شاخه‌ی دیگر مهندسی) یک کار تضمین کیقیت است

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

روش‌های مهندسی نرم‌افزار

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

درد و دل

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

 پایان درد ودل

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

فاز ها و روش (های) کلاسیک – آشنایی

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

فاز ها و روش (های) کلاسیک – بی‌نظمی و نیاز به روش 

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

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

1. نخستین شیوه ساخت نرم‌افزار به نام «کد بزن و درست کن» شناخته میشه و هسته اصلیش رو «بی‌نظمی» میسازه. این بی‌نظمی در مراحل مختلف کار (همون فاز ها) خودشو به ریخت اشکالات متفاوتی نشون میده.
2. بی نظمی در نخستین گامهای کار(فاز های اولیه – نیازمندی‌ها و تحلیل) باعث میشه که برنامه نویس نیاز مشتری رو درست نفهمه که خودش باعث میشه هم تخمین نادرست باشه و هم کدی که نوشته میشه برای مشتری ارزش نداشته باشه و اثرات یرانگر بسیاری رو فازهای بعدی داره.کلا خطا در فازهای نخستین هزینه گزافی رو بر فازهای بعدی تحمیل کینه.
3.  بی‌نظمی درگامهای بعدی (فازهای  طراحی  و پیاده سازی) باعث میشه برنامه‌ای نوشته بشه که به مرور زمان به سوی زوال پیش میره و در پایان نه تنها به زمانبندی و هزینه نمیرسه بلکه نیاز مشتری رو هم برآورده نمیکنه و قابل نگهداری هم نیست.
4. نتیجه همه اینا اینه که کیفیت از دست میره و این شیوه به هیچ رو نباید بکار بسته بشه.

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

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

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

•  بی‌نظمی : Entropy
• آشوب، اغتشاش (همان بی‌نظمی اما به زبان غیر فنی): Chaos
• نظم : Discipline
• «کد بزن و درست کن» یا «کد بزن و درستش کن»: Code and Fix
• فاز: Phase
• مرحله، قدم، گام: Step
• روش: Method
• فرآیند (برای ما همون معنی روش رو میده): Process
• روشهای مهندسی نرم افزار (همون روش)  : Software Engineering Methods
• فرآیندهای مهندسی نرم افزار (همون روش اما شیک تر) : Software Engineering Processes
• روشهای ساخت (توسعه، گسترش) نرم‌افزار (همون روش اما آکادمیک تر و دانشگاهی تر)  : Software Development Methods , Software Development Methologies
• فرآیند‌های  ساخت (توسعه، گسترش) نرم‌افزار (دیگه خودت حساب کن دیگه!) : Software Development Processes, Software Processes

 

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

آزمون نرم افزار – Software Testing

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

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

تعریف آزمون نرم افزار

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

بیشترین خطاها را هر چه زودتر و با صرف منابع هر چه کم تر بیابیم.

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

آزمودن نرم افزار از جمله کارهایی است که برای تضمین کیفیت آن انجام میشود و احتملا مهمترین آنها هم هست.

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

روشهای آزمودن نرم افزار

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

آزمون جعبه سفید با توجه به پیاده سازی وآزمون جعبه سیاه بدون توجه به آن انجام میشود

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

خودکار سازی

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

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

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

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

• آزمون : Test
• آزمودن: Testing
• آزماینده: Tester
• کیفیت:Quality
• تضمین کیفیت: Quality Assurance
• کارهای تضمین کیفیت: Quality Assurance Activities
• آزمودن به شیوه جعبه سیاه:  Black-box Testing
• آزمودن به شیوه جعبه سفید: White-box Testing
• آزمون یکانی: Unit Testing
• یکان: Unit
• آزمون پسرفتی: Regression Testing
• آزمون یکپارچه سازی: Integration Testing
• آزمون سیستمی: System Testing  
•  تغییر کد: Code Modification
• مورد آزمون:  Test Case
• گروه آزمون: Test Suite  or Test Group
• چفت و بست: Fixture
• افسار آزمون: Test Harness
• خودکار سازی آزمون:Test Automation