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

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

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

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

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

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

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

 

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

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

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

نقشها:

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

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

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

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

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

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

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

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

 

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

 

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

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

فاز آزمون:

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

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

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

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

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

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

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

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

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

 

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

 

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