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

12 07 2009

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

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

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

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

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

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

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

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

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





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

30 06 2009

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

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

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

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

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

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

 

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

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

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

نقشها:

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

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

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

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

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

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

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

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

 

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

 

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

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

فاز آزمون:

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

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

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

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

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

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

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

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

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

 

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

 

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




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

5 06 2009

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

پیش درآمد

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

  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

19 05 2009

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

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

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

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

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

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

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

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

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

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

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

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

خودکار سازی

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

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

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

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

  • آزمون : 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 – درس نخست – در مدح مدل

20 04 2009

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

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

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

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

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

مدل و مدلسازی

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

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




ریسک – بخش نخست

10 03 2009

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

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

آشنایی

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

تعریف دقیق تر از ریسک

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

شناس رخداد * پیامد = ریسک

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

مدیریت ریسک

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

پیامدهای مدیریت ریسک نادرست

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

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

  • ریسک : Risk
  • ریسک بزرک یا عمده : Major Risk
  • ریسک کوچک : Minor Risk
  • پیامد ریسک، اثر ریسک : Risk Impact
  • شناس رخداد ریسک : Risk Probability
  • اندازه (اهمیت) ریسک : Risk Magnitude
  • مدیریت ریسک : Risk Management
  • کاهش ریسک : Risk Mitigation – or Reduction
  • حذف ریسک : Risk Elimination
  • روحیه تیم : Team Morale
  • کارایی تیم : Team Productivity
  • زمانبندی : Schedule
  • بالا زدن هزینه و زمان از پیش بینی : Time and Cost Overrun
  • نیروی انسانی : Human Recourse
  • عوامل انسانی : Human Factors




امکان سنجی و اثبات مفهوم – بخش دوم

10 03 2009

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

درنوشتۀ پیشین گفتم دو تا مفهموم ساده اما بسیار مهم در مهندسی نرم افزار هست که اگر به اونها آگاه نباشید و اونها رو بکار نبندید در آیندۀ پروژه تاثیر ناخواسته و بدی داره. نخستینِ اونها را با هم شناختیم و گفتم پیش از دست بردن به هر کاری باید بخشهای تردید برانگیز پروژه رو شناسایی کنید و آنگاه تلاش کنید تا برای اون مسائل راه حلی بیابید. اکنون زمان اون رسیده تا راه حلی که یافتید رو بررسی و آزمایش کنید و ببینید پاسخگو هست یا نه. به این کار میگن :«اثبات مفهوم» و در این نوشته باهاش آشنا میشیم

پس از امکان سنجی

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

نادیده انگاشتن اثبات مفهوم

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

از این تجربه ای که براتون گفتم به جز اهمیت اثبات مفهوم چیز دیگری هم بدست میاد و اون اینه که برای اثبات مفهوم نیازی نیست چیزی رو سرتاسر و با همه جزییات و ریزه کاری هاش اثبات و آزمایش کنید. ایدۀ هسته ای و پایه ای راه حلتون رو شناسایی کنید و سپس با یکی دو آزمون ساده و با کمترین جزییات ممکن اون ایده رو آزمون کنید. البته دقت کنید که منظورم از جزییات چیزهایی هستند که در اثبات اون ایده تاثیری ندارند بنابراین هوشیار باشید که ناخودآگاه چیز مهمی را بجای جزییات حذف نکنید. اگر تردید دارید که چیزی مهم هست یا نه ریک بیخودی نکنید و اون چیز ر هم در آزمون هاتون بگنجونید. یکی دو آزمون بسیار ساده اما کارا ترتیب بدید و اون چیزی که پیشنهاد داید رو آزمایش کنید. اینقدر این کار رو تکرار کنید تا به یک راه حل کارا  درست دست پیدا کنید.

  • اثبات مفهوم : Prove of Concept
  • PoC : Prove of Concept
  • راه حل پیشنهادی : Proposed Solution
  • راه حل پذیرفته شده : Approved Solution
  • راه حل پیاده سازی شده، راه حل بکار بسته شده : Implemented Solution
  • راه حل اثبات شده : Proved (demonstrated) Solution
  • ایده اساسی، ایده کلیدی، ایده پایه ای، ایده مادر : Core (main, key) Idea





امکان سنجی و اثبات مفهوم – بخش نخست

9 03 2009

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

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

امکان سنجی

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

بررسی (مطالعه) و آزمون (تست) امکان سنجی

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

امکان سنجی از زوایای غیر فنی

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

  • کار شدنی : Feasible
  • انجام شدنی بودن : Feasibility
  • بررسی امکان سنجی : Feasibility ُُStudy
  • آزمون امکان سنجی : Feasibility Test
  • ریسک بزرگ، ریسک عمده : Major Risk
  • پر خطر : High Risk
  • بحران : Crisis
  • بعد فنی : Technical Aspect
  • زمان و هزینه : Time and Cost
  • بهره برداری از منابع بیرون سازمانی : Out-sourcing




این «جریان داده» که میگن، جریانش چیه؟

22 01 2008

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

پیش از آنکه فناوری شیءگرا (Object Oriented) بر فرایندهای تحلیل و طراحی مسلط شود، طراحان و تحلیل‌گران سیستم از روشی به نام «تحلیل و طراحی ساخت‌یافته» (Structured Analysis and Design یا SAD) استفاده می‌کردند و برای کار خود ابزارهایی در اختیار داشنتد که یکی از آنها نمودار جریان داده است. نمودار جریان داده (Data Flow Diagram یا DFD) تلاش می‌کند تا جریان گذر داده‌ها در سیستم را به صورت یک نمودار تصویری نمایش دهد. منظور از جریان گذر داده (Data Flow) مسیری است که یک داده ورودی طی می‌کند تا به یک داده خروجی تبدیل شود. به عبارتی می‌توان گفت که پردازشهایی را که بر روی داده انجام میشود و مسیری که داده از یک پروسه به پروسه دیگر طی می‌کند را نمایش می‌دهد. نمودار جریان داده برای سیستمهایی که پردازشهای سنگین و پیچیده دارند مفید است و به طراح کمک می‌کند تا بدون در نظر گرفتن جزئیات پیاده سازی هریک از زیرفرایند‌ها (یا همان ایستگاههای میانی)، فرایند بزرگتر را به اجزای سازنده و مسیر بین آنها تجزیه کند. وی سپس می‌تواند هر یک از این «فرایند های میانی» را به صورت یک مسئله طراحی جدید حل کند. میزان جزیئات بیان شده در نمودار جریان داده را با «سطح» (Level) آن نمایش می‌دهند. نمودار سطح صفر تشکیل شده از یک (یا چند) منبع داده ورودی، یک (یا چند) مسیر داده خروجی و تنهایک تابع (یا همان فرایند) که آن را دایره و مسیر های ورودی و خروجی را با خط نمایش میدهند. نمودار سطح یک این تابع را به اجزای درونیش تفکیک می‌کند و مسیر داخلی داده را نمایش می‌دهد (که یک مرحله به حل مسئله اصلی نزدیک تر است) و فرایند همینگونه ادامه دارد تا انجایی که تابعهای ترسیم شده براحتی قابل نوشتن باشند.

دو نمودار دیگر با نمودار جریان داده پیوستگی نزدیک دارند که عبارت‌اند از «نمودار زمینه سیستم» (System Context Diagram یا SCD) و «نمودار جریان سیستم» (System Flow Diagram یا SFD). نمودار زمینه سیستم مرزبندی سیستم با محیط یبرون و منابع ورودی و خروجی داده‌ها را نمایش میدهد و بنابر این گونه‌ای از نمودار جریان داده است که مسیرهای ورودی و خروجی داده را نسبت به کل سیستم (و نه یک فرایند خاص در سیستم) نمایش می‌دهد. نمودار جریان سیستم نحوه کارکرد سیستم را نمایش می‌دهد و بیشتر به «جریان کنترل» و «دنباله» رفتاری سیستم مربوط می‌شود تا به جریانی که داده‌ها در سیستم می‌پیمایند.

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

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





سیستم به زبان (خیلی) ساده

13 01 2008

درود بسیار بر یکایک دوستان
توی این مقاله دست و پا زدم تا مفهوم سیستم رو با یه زبون ساده بیان کنم.

سیستم
برای فراگیری مهندسی نرم‌افزار لازم است با مفاهیمی که شالوده کار ما را میسازند آشنا شویم. یکی از این مفاهیم «سیستم» و دیگری «مدل» است. فراگیری UML و RUP و … تا زمانی که به این مفاهیم مسلط نباشم ما را یاری نمیکند. کسی که درک مبهمی از سیستم و مدل دارد نمیتواند آنگونه که سزاوار است از زبان مدلسازی UML استفاده کند یا فرایندهای نرم‌افزاری را بکار ببندد. از سوی دیگر سر و کله زدن با اینگونه نکات «فلسفی» در کار نرم‌افزار، دهن ما را هوشیارتر می‌کند و باعث میشود تا کار خود را هوشمندانه انجام دهیم.

سیستم دقیقا چست؟ خوشبختانه پاسخش بسیار ساده است: سیستم(System) مجوعه ای از اجزاء (Components) است که با هم در ارتباطند (Relation) و هدف مشخصی را دنبال می‌کنند (Objective). هر ترکیبی از چیزها (یا همان موجودیت ها – Entities) که برای رسیدن به یک هدف همکاری (Colaboration) کنند، یک سیستم میسازند. این اجزاء می‌توانند هر چیزی باشند. از انسان‌ها گرفته تا قطعاتی چون پیچ‌ و مهره. هدف سیستم میتواند از اجرای یک نمایشنامه تا تولید نیروی محرکه در اتوموبیل تغییر کند. سیستم می‌تواند فیزیکی (اجزای قابل لمس) یا منطقی (اجزای منطقی) یا ترکیبی از هر دو باشد.برخی سیستم ها ساده (Simple) و برخی نیز پیچیده (Complex) هستند. برخی کوچک (Small) (اجزاء اندک) و برخی بزرگ (Large) (اجزاء بسیار) هستند. سیستم ساده سیستمی است که درک آن ساده و ارتباط اجزایش زیاد پیچیده نباشد. سیستمهای ساده معولا کوچک‌ اند و اهداف ساده ای را دنبال می‌کنند. نقطه مقابل آنها سیستمهای یچیده هستند که چندین هدف را دنبال می‌کنند و اغلب اجزای بسیار با روابط دشوار دارند.

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

سیستم‌های نرم‌افزاری
آیا متوان نرم‌افزار را سیستم دانست؟ بیایید آنرا بررسی کنیم! یک نرم‌افزار هر چقدر هم که ساده باشد (در حد یک برنامه Hello World) هنوز از اجزاء ساده‌تری ساخته شده (تابع هاُ، بلوک‌هاُ و …). این اجزاء با هم ارتباط ویژه‌ای دارند (منطق برنامه) که در مجموع کاری را انجام می‌دهند (خروجی). در واقع نرم‌افزار چیزی نیست جز ترکیبی منطقی از اجزای نرم‌افزاری کوچکتر؛ بنابراین نرم‌افزار حقیقتا یک سیستم است. برخی محصولات نرم‌افزاری سیستمهای بسیار پیچیده‌ای هستند که خود از چندین زیر سیستم دیگر (که خودشان پیچیدگی بسیار دارند) ساخته شده‌اند. برای نمونه نرم‌افزار اتوکد محصول شرکت اتودسک یا سیستم عامل ویندوز محصول مایکروسافت را در نظر بگیرید. یک بررسی ساده نشان می‌دهد که هر یک از این محصولات براستی یک سیستم پیچیده است. یک چنین سیستمی را که اجزایش نرم‌افزاری هستند یک «سیستم نرم‌افزاری» (Software System) می‌خوانند. سیستم نرم‌افزاری همه ویژگی‌های سیستم های دیگر را دارد با این تفاوت که اجزایش نرم‌افزاری هستند و جسم فیزیکی ندارند؛ به همین خاطر نرم‌افزار در واقع یک سیستم «منطقی» است. در مقابل آن سیستمهای سخت‌افزاری هستند که اجزایش فیزیکی هستند و یک سیستم «الکترونیکی – مکانیکی» را می‌سازند. آنگاه که یک سیستم نرم‌افزاری یک سیستم سخت‌افزاری را تحت کنترل دارد، مجموعه آنها را «سیستم کامپیوتری» مینامند. شناخت و درک ماهیت سیستمی نرم‌افزار و زیر سیستمهای سازنده آنها و منطق ارتباط آنها با یکدیگر بخش اساسی و جدانشدنی مهندسی نرم‌افزار است. در حقیقت مهندسی نرم‌افزار با مهندسی سیستم آغاز میشود و هدف از آن بررسی نرم‌افزار از دید سیستمی است.

برای اینکه مقاله کامل شده باشد، برخی مفاهیم و مهارتهای سیستمی را در ارتباط با نرم‌افزار مرور می‌کنیم:

تحلیل سیستم (System analysis) یا همان تحلیل (Analysis): هدف از تحلیل نرم‌افزار (سیستم) شناخت و درک سیستم و اجزای آن و روابط بین آنهاست. «تحلیل گر سیستم» (System Analyst) می‌کوشد تا سیستم را بشناسد؛ به معنی که اهدافش را درک کند و مشخصاتش را تشخیص دهد، زیر سیستمهای مهم را بیابد و دید درستی از منطق سیستم (ارتباط اجزا و زیر سیستمها با یکدیگر) بدست بیاورد. برای این منظور او برخی اوقات سیستم را می‌شکند و اجزایش را میشکافد (تجزیه و تحلیل – Analysis) وبرخی اوقات اجزا را ترکیب می‌کند و زیر سیستم میسازد (ترکیب – Synthesis). هر کاری که به شناخت بهتر سیستم بیانجامد به نوعی تحلیل شمرده می‌شود. واژگانی همچون «تحلیل‌گر سیستم»، «تحلیل‌گر نرم‌افزار» و «تحلیل‌گر» همه همان معنی را دارند. برخی اوقات اصولا هنوز سیستمی ساخته نشده است که بخواهد تحلیل شود و در واقع هدف این است که سیستمی نو ساخته شود. در این صورت کار تحلیل گر بسیار مهم و تا اندازه‌ای متفاوت است. او باید سیستم آینده را بشناسد و در حقیقت او خواهد گفت که این سیستم چه خواهد بود. نتیجه کار تحلیل، مشخصات و ویژگی‌های سیستمی است که باید ساخته شود (System Specifications) . اهداف سیستم و محدودیتهای آن به همراه قالب ورودی و خروجی سیستم ار بخشهای مهم مشخصات سیستم هستند. تحلیلگر به جزپیات کار طراحی و ساخت سیستم کاری ندارد. او میگوید که «چه چیزی» قرار است ساخته و این «چه» همان «مشخصات سیستم» است.

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

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