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

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

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

مهندسی نرم افزار

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

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

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

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

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

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

دوست داشتم که مهندسی فرایند و معماری نرم افزار را هم وارد کنم اما بدبختانه با سادگی مقاله مغایرت دارد ساعت هم شش صبح است (نمیکشه).

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

چگونه میتوان پیوسته نرم افزار خوب ساخت؟

امروز داشتم (دوباره) فصل اول کتاب “Head First: Object Oriented Analysis And Design” رو میخوندم که با خودم گفتم بد نیست مطالبش رو خالصه کنم چون هم به خودم کمک میکنه اونها رو طبقه بندی کنم هم اینه پاسخ بسیاری از پرسشهای دوستان برنامه نویس هم هست. لحن رسمی مقاله برای اینه که بامداد گیر داده سایت باید کلاس خودشو حفظ کنه

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

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

در مقاله‌ای دیگر ویژگیهای نرم‌افزار خوب (انعطاف پذیری، کارایی، سادگی نگهداری، توانایی گسرش و …) را تعریف خواهیم کرد و راههای رسیدن به آنها را نیز بررسی میکنیم.