نظر خواهی

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

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

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

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

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

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

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

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

پیش از حل کردن هر مسئله ای باید نخست صورت اون مسئله رو فهمید. قبل از گشتن به دنبال پاسخ یک پرسش باید خوب پرسش رو درک کرد. نرم افزار هم از این قانون جدا نیست و پیش از دست بردن به هر کاری نخست باید ببینیم مشتری چی میخواد و چی قراره نوشته بشه، سپس بریم تو کار طراحی و بعدش هم برنامه نویسی. همین چهار تا واژه ی به ظاهر ساده ای که گفتم خودش میشه یک فاز. فاز «تحلیل». درسته که ساده و سر راست به نظر میاد اما تنها به نظر میاد و در کار یکی از خفن ترین فازهاست و ریسک های فاز تحلیل ریشه ی نرم افزار رو خشک می کنند. تحلیل گر ها بیشتر از همه ی نقش های دیگر پول می گیرند و مسولیتی که به عهده ی اونهاست از همه بیشتره. فاز تحلیل خوب نیمی از پیروزی رو تضمین می کنه و فاز تحلیل بد بی برو برگرد به شکست پروژه خواهد انجامید. اگر تو فاز تحلیل به اندازه ی یک دلار خطا کنید برای جبران همون خطا تو فاز طراحی باید 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

 

 

UML – درس نخست – در مدح مدل

درود بسیار بر دوستان. بلاخره زمانش شد که بریم سراغ «یو.ام.ال» اما برای یاد گرفتن «یو.ام.ال» نخست باید مدلسازی شیءگرا رو بدونیم و برای اینکار باید تا اندازه ای (اونم اندازه ای زیاد)  مدل و مدلسازی رو بدونیم که هر کدوم از اینها برای خودشون دنیایی دارن که بیا و ببین. من تلاش میکنم خیلی سه سوته بحث مدل و مدلسازی رو یه جوری ببندم که نه سیخ به فاک بره نه کباب تا برسیم به «یو.ا.م.ال». شاید فکر کنید که بحث مدل رو کاملا بلدید و خوندن این مقدمات کمکی بهتون نمیکنه اما  من پیشنهاد  میکنم به هیچ وجه ازش رد نشید. حتی اکر صد ساله دارین مدلسازی میکنین باز هم این بخش ها رو بخونید. اگر درک درستی از این مفاهیم پایه ای نداشته باشید چیزی از «یو.ام.ال» دستگیرتون نمیشه.

نرم افزار های ساده و نرم افزارهای پیچیده

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

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

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

مدل و مدلسازی

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

• یو.ام.ال. : زبان مدلسازی یکچارچه
• مدل : Model
• مدلسازی : Modeling
• مدلساز : Modeler
• طرح : Design
• طراح : Designer
• نمودار : Chart, Diagram
• مدل نوشتاری :  Textual Model
• مدل گرافیکی : Graphical Model
• مدل دیداری : Visual Model
• پیچیدگی : Complexity
• سادگی : Simplicity

گزارش پیشرفت کار

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

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

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

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

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

بزودی ادامه مطلب ریسک و چند مطلب نو (از جمله شبکه بازی) رو براتون مینویسم

دوری و دوستی

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

بگذریم …

 به جون مادرم آلان دو هفته است میخوام چند تا مطلب توپ بذارم تو بلاگ اما نمیتونستم وارد بخش مدیریت بشم. کلی این در و اون در زدم تا دیگه نوید (از بچه های ردیف وردپرس فارسی و همکار پیشین و دوست کنونی ام) به دادم رسید که تونستم در این ساعت فرخنده وارد سایت بشم. آلانم اگر به الهام زنگ نزنم فردا کلّه ام رو میکنه تنها اینو بدونید که مشکلی نیست و به کوری چشم دشمنان مدّرس هنوز زنده است