توسعه نرم‌افزار فرایند شناخت یک نیاز، طراحی راه‌حل، ساخت، آزمون و نگهداری برنامه‌ای است که کار مشخصی را برای کاربر انجام می‌دهد. حاصل آن می‌تواند نرم‌افزار حسابداری، اپلیکیشن موبایل، سامانه تحت وب یا برنامه کنترل یک دستگاه باشد. برای فهمیدن این فرایند، باید هم نحوه کار برنامه را ببینیم و هم مسئله‌ای را که قرار است حل کند.
فرض کنید یک شرکت خدماتی، درخواست تعمیر مشتریان را در تماس تلفنی و چند فایل پراکنده ثبت می‌کند. مدیر شرکت می‌خواهد بداند هر درخواست دست چه کسی است و چه زمانی تمام می‌شود. توسعه نرم‌افزار از روشن‌کردن همین نیاز شروع می‌شود؛ انتخاب زبان و نوشتن کد، بعد از شناخت جریان کار معنا پیدا می‌کند.
توسعه نرم‌افزار چه تفاوتی با برنامه‌نویسی دارد؟
برنامه‌نویسی، نوشتن دستورهایی است که رایانه اجرا می‌کند. توسعه نرم‌افزار، فعالیت‌های بیشتری را در بر می‌گیرد: مشخص‌کردن نیاز کاربران، طراحی داده و رابط کاربری، برنامه‌نویسی، بررسی کیفیت، انتشار و رسیدگی به مشکلات پس از استفاده. در تعریف IBM از توسعه نرم‌افزار نیز ساخت، طراحی، استقرار و پشتیبانی در کنار هم آمده‌اند.
برای مثال، می‌توان کدی نوشت که یک درخواست تعمیر را ذخیره کند. اما محصول قابل استفاده باید به پرسش‌های بیشتری پاسخ دهد: چه اطلاعاتی اجباری است؟ چه کسی اجازه دیدن شماره تماس مشتری را دارد؟ اگر درخواست دوبار ارسال شد چه اتفاقی می‌افتد؟ کارشناس چگونه پایان کار را اعلام می‌کند؟ این تصمیم‌ها بخشی از توسعه همان نرم‌افزارند.
چه نوع نرم‌افزارهایی ساخته می‌شوند؟
محیط اجرا و نوع استفاده، بخشی از انتخاب‌های فنی را مشخص می‌کنند. چند نمونه آشنا عبارت‌اند از:
- نرم‌افزار تحت وب: کاربر با مرورگر به آن دسترسی دارد؛ مانند پنل پیگیری درخواست‌ها یا فروشگاه اینترنتی. این برنامه می‌تواند روی اینترنت عمومی یا شبکه داخلی سازمان در دسترس باشد.
- اپلیکیشن موبایل: برای استفاده در تلفن و تبلت طراحی می‌شود؛ مانند برنامه کارشناس تعمیر برای مشاهده مأموریت و ثبت عکس.
- نرم‌افزار دسکتاپ: روی رایانه اجرا می‌شود؛ مانند ابزار طراحی مهندسی یا برنامه‌ای برای کار با تجهیزات محلی.
- نرم‌افزار نهفته: بخشی از یک دستگاه است؛ مانند برنامه کنترل یک حسگر یا تجهیز صنعتی.
این دسته‌ها مرز کاملاً جدا ندارند. یک محصول می‌تواند پنل وب، اپلیکیشن و بخش پردازش مشترک داشته باشد. برای شناخت بخش مرورگر و سرور، مقاله توسعه وب چیست؟ تفاوت اجزای یک محصول تحت وب را توضیح می‌دهد.
مراحل توسعه نرم‌افزار؛ از نیاز تا استفاده واقعی
به مجموعه فعالیت‌های ساخت و نگهداری محصول، چرخه عمر توسعه نرم‌افزار یا SDLC می‌گویند. نام و تفکیک مراحل در منابع مختلف یکسان نیست؛ اما برنامه‌ریزی، تحلیل، طراحی، توسعه، آزمون، انتشار و نگهداری اجزای رایج آن‌اند. این دسته‌بندی در راهنمای چرخه توسعه مایکروسافت هم توضیح داده شده است.
در جدول زیر، همان شرکت خدماتی را دنبال می‌کنیم تا خروجی هر مرحله روشن باشد.
| مرحله | کار اصلی | نمونه خروجی |
|---|---|---|
| شناخت مسئله و برنامه‌ریزی | تعیین کاربران، هدف و محدوده اولیه | کاهش درخواست‌های گم‌شده با ثبت و پیگیری در یک محل |
| تحلیل نیازها | روشن‌کردن قواعد و حالت‌های استثنایی | مشخص‌بودن اطلاعات درخواست و مسئول هر وضعیت |
| طراحی | طراحی مسیر کاربر، داده‌ها و اجزای سیستم | نمونه فرم ثبت و ارتباط مشتری، درخواست و کارشناس |
| پیاده‌سازی | ساخت قابلیت‌ها و اتصال اجزا | ثبت درخواست و نمایش آن در فهرست کارشناس |
| آزمون | بررسی رفتار عادی، خطا و سطح دسترسی | جلوگیری از دسترسی کارشناس به درخواست دیگران |
| انتشار | آماده‌سازی محیط و تحویل نسخه قابل استفاده | دسترسی گروه اولیه کاربران و راهنمای شروع |
| نگهداری و بهبود | رسیدگی به خطاها و بازخورد استفاده | رفع مشکل اعلان‌ها و اصلاح جست‌وجوی درخواست‌ها |
نیاز دقیق را با یک سناریوی قابل بررسی بنویسید
عبارت «یک پنل کامل می‌خواهیم» برای تصمیم‌گیری کافی نیست. نیاز روشن‌تر این است: «مسئول پذیرش بتواند نام مشتری، راه تماس و شرح مشکل را ثبت کند؛ سپس مدیر، درخواست را به یک کارشناس بسپارد.» این جمله هم کاربر را مشخص می‌کند، هم عمل او را و هم ادامه جریان را.
کنار هر قابلیت، معیار پذیرش بنویسید. مثلاً اگر شماره تماس خالی بود، درخواست ثبت نشود و پیام قابل فهمی نمایش داده شود. معیار پذیرش به سفارش‌دهنده و تیم کمک می‌کند درباره انجام‌شدن کار، با یک تعریف مشترک صحبت کنند.
پیش از ساخت کامل، مسیر کار را قابل دیدن کنید
با یک طرح ساده فرم و فهرست درخواست‌ها می‌توان درباره ترتیب اطلاعات گفتگو کرد. ممکن است پذیرش بگوید نشانی مشتری باید زودتر دیده شود یا کارشناس به دکمه تماس نیاز دارد. این بازخوردها پیش از ساخت کامل رابط، تصمیم‌گیری را آسان‌تر می‌کنند. طرح اولیه برای بررسی جریان کار است؛ نباید آن را با نرم‌افزار آماده اشتباه گرفت.
قابلیت‌ها را به صورت یک جریان قابل استفاده بسازید
در نسخه اول این مثال، می‌توان مسیر «ثبت درخواست، ارجاع به کارشناس و اعلام پایان کار» را کامل کرد. افزودن گزارش‌های متعدد، باشگاه مشتریان و حسابداری، تصمیم‌های جداگانه‌ای هستند. وقتی همه این موارد هم‌زمان وارد محدوده شوند، ارزیابی پیشرفت و دریافت بازخورد دشوارتر می‌شود.
نسخه کوچک هم باید اطلاعات را درست نگه دارد و دسترسی کاربران را رعایت کند. کوچک‌کردن محدوده، مجوز کنارگذاشتن کیفیت بخش‌های ضروری نیست.
چه کسانی در تیم توسعه نقش دارند؟
برای یک پروژه کوچک، ممکن است یک نفر چند مسئولیت داشته باشد. در پروژه بزرگ‌تر، نقش‌ها میان افراد تقسیم می‌شوند. مهم این است که مسئول هر تصمیم مشخص باشد:
- مسئول محصول یا نماینده کسب‌وکار: نیازها را اولویت‌بندی و درباره محدوده و پذیرش قابلیت‌ها تصمیم‌گیری می‌کند.
- تحلیلگر: فرایند فعلی، قواعد و ارتباط اطلاعات را روشن می‌کند؛ مثلاً تعیین می‌کند چه کسی اجازه لغو درخواست را دارد.
- طراح تجربه و رابط کاربری: مسیر انجام کار و شکل صفحات را طراحی و با کاربر بررسی می‌کند.
- توسعه‌دهنده: قابلیت‌ها و ارتباط اجزا را پیاده‌سازی می‌کند. در محصول تحت وب، مسئولیت‌های فرانت‌اند و بک‌اند ممکن است جدا باشند.
- مسئول آزمون و کیفیت: سناریوهای بررسی را تنظیم و رفتار محصول را در حالت‌های مختلف ارزیابی می‌کند.
- مسئول استقرار و عملیات: محیط اجرا، انتشار نسخه، پایش و فرایند بازیابی را مدیریت می‌کند.
صرف داشتن این عنوان‌ها، کیفیت پروژه را ثابت نمی‌کند. در مثال شرکت خدماتی، باید روشن باشد خطای ثبت درخواست را چه کسی بررسی می‌کند، تأیید نهایی با چه کسی است و در زمان اختلال، کاربران با کدام فرد تماس می‌گیرند.
ابزارهای توسعه نرم‌افزار چه کاری انجام می‌دهند؟
ابزار را بر اساس کار انتخاب می‌کنند. ویرایشگر یا محیط توسعه برای نوشتن و اجرای برنامه است. پایگاه داده، اطلاعاتی مثل مشتری و درخواست را نگه می‌دارد. ابزار آزمون، بخشی از بررسی رفتار برنامه را تکرار می‌کند. ابزار پایش هم وضعیت اجرای محصول و رخدادهای خطا را قابل مشاهده می‌کند.
Git برای ثبت تاریخچه تغییرات فایل‌ها به کار می‌رود؛ تیم می‌تواند تفاوت نسخه‌ها را ببیند و علت یک تغییر را دنبال کند. GitLab و GitHub خدماتی برای میزبانی مخزن و همکاری ارائه می‌کنند. این‌ها جای مستندات محصول، مدیریت دسترسی یا پشتیبان‌گیری از داده‌های مشتریان را نمی‌گیرند.
زبان و چارچوب هم بخشی از ابزارند. انتخاب آن‌ها به محیط اجرا، ارتباط با سامانه‌های موجود، نیازهای محصول و توان تیم نگهداری بستگی دارد. محبوب‌بودن یک فناوری به‌تنهایی دلیل کافی برای انتخاب آن در همه پروژه‌ها نیست.
آزمون و امنیت از چه زمانی وارد کار می‌شوند؟
از زمان تعریف نیاز باید درباره اطلاعات حساس و دسترسی‌ها تصمیم گرفت. چارچوب توسعه امن NIST SSDF نیز بر ادغام فعالیت‌های امنیتی با چرخه توسعه تأکید دارد. بررسی امنیت را نباید به روز تحویل موکول کرد.
برای سامانه درخواست تعمیر، چند بررسی مشخص داریم:
- کاربرِ واردنشده نتواند اطلاعات مشتری را ببیند.
- کارشناس با تغییر شناسه در آدرس، به درخواست خارج از دسترسی خود نرسد.
- قطع ارتباط هنگام ارسال فرم، وضعیت نامشخص یا ثبت تکراری ایجاد نکند.
- برای داده‌های مهم، پشتیبان تهیه و روش بازیابی عملاً بررسی شود.
آزمون‌ها باید هم اجزای کوچک را پوشش دهند و هم مسیر کامل کاربر را. درست‌کارکردن یک تابع، به‌تنهایی نشان نمی‌دهد پذیرش می‌تواند یک درخواست را از ابتدا تا پایان ثبت و پیگیری کند.
چرا کار با انتشار نسخه اول تمام نمی‌شود؟
پس از استفاده، جزئیاتی دیده می‌شوند که در جلسه طراحی روشن نبوده‌اند. شاید کارشناس در محل مشتری اینترنت ضعیفی داشته باشد یا مسئول پذیرش با نام خانوادگی جست‌وجو کند. این بازخوردها باید ثبت و بررسی شوند؛ هر درخواست تازه هم لزوماً اولویت انتشار بعدی نیست.
همچنین ممکن است سرویس پیامک، کتابخانه‌های برنامه یا نیازهای دسترسی تغییر کنند. نگهداری شامل رسیدگی به این تغییرات، رفع خطا و بررسی وضعیت محصول است. بهتر است پیش از شروع، مسئولیت پشتیبانی، تحویل کد و دسترسی‌ها، مالکیت داده و شیوه ثبت درخواست تغییر مشخص شود.
برای شروع یادگیری یا سفارش نرم‌افزار، از کجا اقدام کنیم؟
اگر می‌خواهید توسعه‌دهنده شوید
یک مسئله کوچک انتخاب کنید؛ مثلاً برنامه‌ای که نام کار، موعد و وضعیت انجام آن را نگه دارد. ابتدا نسخه ساده آن را بسازید، سپس ذخیره اطلاعات، رسیدگی به ورودی اشتباه و راهنمای اجرا را اضافه کنید. زبان اولیه را با توجه به نوع خروجی انتخاب کنید و پیش از رفتن سراغ ابزار بعدی، رفتار نسخه فعلی را بفهمید.
در مسیر یادگیری توسعه نرم‌افزار؛ از پایه تا اولین پروژه، تمرین‌ها و معیار عبور از هر مرحله جداگانه آمده‌اند. برای شروع، به دانستن همه شاخه‌ها یا ساخت یک محصول بزرگ نیاز ندارید.
اگر برای کسب‌وکارتان نرم‌افزار می‌خواهید
یک فرایند پرتکرار را انتخاب و مراحل فعلی آن را بنویسید. مشخص کنید چه کسی کار را آغاز می‌کند، چه اطلاعاتی وارد می‌شود، چه تأییدهایی لازم است و خروجی قابل قبول چیست. سپس بررسی کنید آیا نرم‌افزار آماده این نیاز را پوشش می‌دهد یا قواعد و اتصال‌های خاص، ساخت محصول اختصاصی را توجیه می‌کنند.
برای آماده‌کردن این اطلاعات، چک‌لیست نیازمندی‌های نرم‌افزار اختصاصی را ببینید. در صفحه توسعه نرم‌افزار اختصاصی داپا هم می‌توانید با حوزه اجرای این خدمات آشنا شوید.
پرسش‌های متداول
آیا برای هر نرم‌افزار باید همه‌چیز را از صفر نوشت؟
خیر. تیم می‌تواند از کتابخانه، چارچوب، سرویس و اجزای آماده استفاده کند. موضوع مهم، تناسب این اجزا با نیاز، مجوز استفاده، امنیت و امکان نگهداری آن‌هاست. اختصاصی‌بودن محصول به معنی نوشتن دوباره تمام ابزارهای پایه نیست.
توسعه یک نرم‌افزار چقدر طول می‌کشد؟
تا وقتی محدوده، نقش کاربران، اتصال‌ها و معیار پذیرش روشن نشده‌اند، زمان دقیق قابل اتکا نیست. نسخه ساده ثبت درخواست با محصولی که به حسابداری، پیامک و برنامه کارشناسان متصل است، کار یکسانی ندارد. برآورد باید همراه فرض‌ها و موارد خارج از محدوده ارائه شود.
هوش مصنوعی می‌تواند کل فرایند را انجام دهد؟
ابزارهای هوش مصنوعی می‌توانند در تهیه پیش‌نویس کد، پیشنهاد آزمون یا توضیح خطا کمک کنند. فهم نیاز کاربر، بررسی دسترسی‌ها و تأیید رفتار محصول همچنان به ارزیابی نیاز دارد. کدی که اجرا می‌شود، ممکن است در شرایط واقعی رفتار نادرست یا ناامن داشته باشد.
