مراحل توسعه برنامه مرحله مقدماتی توسعه نرم افزار

مدیریت نرم افزار

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

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

فرآیند توسعه نرم افزار یکنواخت نیست. یک روش خاص توسعه نرم افزار، به عنوان یک قاعده، برخی از پویایی های استقرار انواع خاصی از فعالیت ها را تعیین می کند، یعنی مدل فرآیند را تعیین می کند.

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

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

شکل 1 - مدل توسعه نرم افزار آبشار اصلاح شده

مدل آبشار اصلاح شده امکان بازگشت به مراحل قبلی را فراهم می کرد.

مدت کوتاهی پس از شروع، مدل آبشاری توسط Winst Royce با در نظر گرفتن وابستگی متقابل مراحل و نیاز به بازگشت به مراحل قبلی که ممکن است به دلیل نیازهای ناقص یا خطا در شکل‌گیری کار ایجاد شود، اصلاح شد. در این شکل "برگشت پذیر"، مدل آبشار برای مدت طولانی وجود داشت و مبنای بسیاری از پروژه ها شد (شکل 1).

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

به منظور رفع نواقص مدل آبشار، یک مدل توسعه نرم افزار V شکل یا مفصلی پیشنهاد شد (شکل 2).

شکل 2- مدل توسعه نرم افزار V شکل

مدل V شکل کنترل بسیار بهتری از نتیجه را از نظر برآورده کردن انتظارات فراهم می کند، زیرا بر روی آزمایش تمرکز دارد.

مدل V شکل به دلیل جهت گیری آن به سمت تست، کیفیت نرم افزار را به میزان قابل توجهی بهبود بخشید و همچنین تا حد زیادی مشکل انطباق محصول ایجاد شده با الزامات تعیین شده را با توجه به مراحل تأیید و صدور گواهینامه در مراحل اولیه حل کرد. توسعه (خطوط چین در شکل نشان دهنده وابستگی مراحل برنامه ریزی / مرحله بندی وظایف و آزمایش / پذیرش است).

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

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

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

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

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

برنج. 3.

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

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

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

شکل 4 - مدل توسعه نرم افزار تکراری

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

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

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

معروف ترین و معتبرترین استاندارد کیفیت را باید مدل بلوغ قابلیت (CMM) در نظر گرفت - مدلی برای ارزیابی سطح بلوغ فرآیندهای توسعه همراه با مشتقات آن. این توسط SEI (موسسه مهندسی نرم افزار)، که توسط وزارت دفاع ایالات متحده تأمین مالی می شود و یک واحد ساختاری از دانشگاه کارنگی ملون است، ایجاد شد. اولین نسخه رسمی استاندارد در سال 1993 منتشر شد، اگرچه کار روی آن خیلی زودتر آغاز شد - مفاد اصلی آن در سال 1986 منتشر شد. عوامل متعددی موفقیت CMM را از پیش تعیین کرده اند. این استاندارد یکی از اولین استانداردهایی بود که در ابتدا ویژگی های توسعه نرم افزار را در نظر گرفت. معلوم شد که بسیار ساده و شفاف است، هم برای درک و هم برای استفاده، و «چه» و نه «چگونه» را تنظیم می‌کند، و بنابراین برای مدل‌های مختلف چرخه زندگی، روش‌شناسی توسعه مناسب است و هیچ محدودیتی برای مستندات اعمال نمی‌کند. استانداردها، ابزارها، محیط و زبان های مورد استفاده در پروژه ها. و شاید عامل اصلی که محبوبیت CMM را از پیش تعیین کرد، همکاری SEI با وزارت دفاع ایالات متحده بود که عملاً به معنای استفاده از استاندارد در اجرای پروژه های سفارش شده توسط این وزارتخانه بود.

مدل CMM (جدول 1) پنج سطح بلوغ را ارائه می دهد که هر کدام مربوط به حوزه های فرآیند کلیدی خاصی است (مناطق فرآیند کلیدی، KPA).

جدول 1-مدل CMM

نام سطح	حوزه های فرآیندی کلیدی
1 - مبتدی	اگر سازمان در این سطح باشد، هیچ حوزه فرآیندی کلیدی برای آن وجود ندارد.
2 - تکرار	مدیریت تنظیمات نرم افزار تضمین کیفیت محصولات نرم افزاری. مدیریت قرارداد پیمانکاری نظارت بر پیشرفت پروژه ها. برنامه ریزی پروژه های نرم افزاری مدیریت نیازمندی ها
3 - تعریف شده است	ارزیابی های تخصصی هماهنگی تعاملات بین تیم های پروژه. مهندسی یک محصول نرم افزاری مدیریت جامع نرم افزار. برنامه آموزش کارکنان تعیین فرآیند سازمانی. محدوده فرآیند سازمانی
4 - مدیریت شده است	مدیریت کیفیت نرم افزار کنترل کمی فرآیند
5 - قابل بهینه سازی	مدیریت تغییر فرآیند مدیریت تغییرات تکنولوژیکی جلوگیری از نقص

تقسیم به سطوح و تعریف KPA برای هر یک از آنها امکان اجرای مداوم CMM را با استفاده از استاندارد به عنوان راهنما فراهم می کند که می تواند بهبود مستمر فرآیند توسعه را تضمین کند.

استاندارد CMM بسیار موفق بود و متعاقباً یک سری استاندارد بر اساس آن ایجاد شد و نام جدیدی - SW-CMM (مدل بلوغ قابلیت برای نرم افزار) دریافت کرد که با دقت بیشتری موقعیت آن را در یک وضعیت نسبتاً منعکس می کند. خانواده استانداردهای متعدد

با این حال، کاربرد عملی استانداردهای سری CMM نشان داده است که آنها موفقیت بی قید و شرطی را در توسعه نرم افزار ارائه نمی دهند. این استانداردها به خوبی با یکدیگر هماهنگ نبودند - اجرای همزمان اصلاحات مختلف CMM می تواند کار بسیار دشواری باشد و متخصصان سازمان هایی را که با این موضوع مواجه بودند گیج کرده است.

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

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

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

استاندارد جدید SEI - Capability Maturity Model Integrated (CMMI) - برای حل بیشتر مشکلات CMM طراحی شده است - یک مدل یکپارچه برای ارزیابی سطح بلوغ فرآیندهای توسعه. استاندارد CMMI در اصل به گونه ای ایجاد شد که نسخه های موجود CMM را ترکیب کرده و هرگونه تناقض در کاربرد عملی آن در زمینه های مختلف شرکت های با فناوری پیشرفته را از بین ببرد.

به منظور حذف نیاز به "همسویی" فرآیندهای سازمان و سازگاری بیشتر با نیازهای تجاری آن، و نه برعکس، استاندارد CMMI دارای دو شکل ارائه است - کلاسیک، چند سطحی، مطابق با CMM، و جدید، پیوسته ارائه مستمر سطوح بلوغ را در نظر نمی گیرد، بلکه سطوح قابلیت را در نظر می گیرد که برای مناطق فرآیندی (PA) ارزیابی می شوند.

جدول 2 مطابقت بین سطوح بلوغ CMM و سطوح بلوغ ارائه لایه ای CMMI و سطوح قابلیت ارائه مداوم CMMI را نشان می دهد.

جدول 2- مطابقت سطوح سررسید استانداردهای CMM, CMMI

SEI در حال دور شدن از CMM است و در ازای آن به طور فعال CMMI را ترویج می‌کند و قول می‌دهد که کنترل فرآیند صدور گواهینامه را تشدید کند، هزینه‌ها را کاهش دهد و آن را برای سازمان‌های کوچک جذاب‌تر کند. اطمینان از سازگاری با استانداردهای ISO

در شرایط مدرن، وجود گواهی سطح مشخصی از CMM / CMMI مانند چندین سال پیش عامل مهمی نیست و بدون سؤال اضافی پذیرفته می شود، مگر در پروژه هایی که به دستور دولت انجام می شود.

استاندارد ISO/IEC 15504 برای ارزیابی فرآیند توسعه سیستم های اطلاعاتی به ویژه نرم افزار در نظر گرفته شده است. در ابتدا برای همسویی نزدیک با استانداردهای صنعت برای ارزیابی توسعه نرم افزار طراحی شده بود. این نیاز بود که شباهت استاندارد را با اصول اولیه CMM / CMMI تعیین کرد.

مدل بلوغ فرآیند توسعه نرم افزار (CMM) که توسط موسسه مهندسی نرم افزار در دانشگاه کارنگی ملون توسعه یافته است، پنج سطح بلوغ را ارائه می دهد (جدول 3). این به سازمان ها کمک می کند تا بلوغ فرآیندهای توسعه نرم افزار خود را افزایش دهند و سازمان ها را می توان در این سطوح ارزیابی و اعتبار داد.

جدول 3-سطوح بلوغ توسعه نرم افزار

سطح 1 - سطح مبتدی	فرآیند توسعه نرم افزار خود به خود است و تنها تعداد کمی از فرآیندها تنظیم می شوند. موفقیت توسعه می تواند به تک تک کارکنان بستگی داشته باشد.
سطح 2 - سطح تکرارپذیری	فرآیندهای مدیریت پروژه پایه برای پیگیری هزینه ها، زمان بندی و عملکرد ایجاد شده اند.
سطح 3 - سطح نظارتی	فرآیند توسعه نرم افزار مستند، استاندارد شده و با فرآیند توسعه نرم افزار استاندارد سازمان برای عملیات مدیریت و توسعه یکپارچه شده است. همه پروژه ها از یک فرآیند استاندارد استفاده می کنند.
سطح 4 - سطح کنترل پذیری	معیارهای دقیق فرآیند توسعه نرم افزار و کیفیت محصول جمع آوری شده است تا فرآیند و محصولات قابل درک و مدیریت باشند.
سطح 5 - سطح بهینه سازی	بهینه‌سازی مداوم فرآیند با بازخورد کمی از فرآیند و ایده‌ها و فناوری‌های نوآوری آزمایشی ارائه می‌شود.

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

قبل از ارائه یک مرور کلی از روند توسعه که در نتیجه انباشت تجربه در سال های گذشته پدیدار شده است، می خواهم چند توضیح کلی را ارائه دهم که برای من ضروری به نظر می رسد.

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

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

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

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

نرم‌افزار تعبیه‌شده همراه با سخت‌افزار عرضه می‌شود و، به طور کلی، مشمول تعمیر و نگهداری نمی‌شود، زیرا فراخوانی دسته‌ای از دستگاه‌ها توسط سازنده بسیار گران است و بنابراین استثنایی است.

توسعه بازدیدهای بازی نیز عملاً شامل مرحله همراهی نمی شود. علاوه بر این، کاربران برنامه های بازی، حتی زمانی که با خطا در بازی مواجه می شوند، به ندرت نسخه به روز شده را دانلود می کنند. بنابراین، توسعه بازی معمولاً اقتصاد و روند توسعه خاص خود را دارد.

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

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

به عنوان نمونه ای از کار بر روی یک پروژه سرمایه گذاری، می توانم توسعه یک سیستم امنیتی یکپارچه را ذکر کنم که ما آن را به عنوان یک محصول "جعبه ای" ایجاد کردیم. تحت رهبری من، چهار نسخه از این سیستم به صورت متوالی منتشر شد که توسط سازمان های تجاری و دولتی مختلفی از جمله شهرداری مسکو، AFK Sistema، بانک ها، مراکز تجاری و البته دفتر خودمان استفاده می شد. نسخه اول چندان موفق نبود، اما ما یک استراتژی توسعه داشتیم که به ما اجازه می داد بازار را با موفقیت تصرف کنیم و از دوران سخت بحران جان سالم به در ببریم. تجربه کار بر روی این و چندین پروژه سرمایه گذاری دیگر نیز در شکل گیری فرآیند توسعه که استفاده کردم در نظر گرفته شد.

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

درک این نکته مهم است که انتقال یک فرآیند از یک مرحله به مرحله دیگر مرز مشخصی ندارد. به عنوان یک قاعده، کار مرحله بعدی با تکمیل 80-90٪ از کار در مرحله قبل شروع می شود. این امر به ویژه برای توسعه نیازمندی ها صادق است، زمانی که در برخی موارد حذف عدم قطعیت تنها در پایان پروژه رخ می دهد. البته وجود چنین بلاتکلیفی در پروژه ریسک قابل توجهی است و باید دائماً رصد شود.

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

بیایید بررسی خود را از روند توسعه با رایج ترین مورد - توسعه نرم افزار سفارشی شروع کنیم. نمودار جریان فرآیند در شکل 1 نشان داده شده است.

شکل 1. فرآیند توسعه نرم افزار سفارشی.

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

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

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

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

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

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

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

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

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

هر پروژه ای در نهایت به پایان می رسد. مرحله پایان پروژه با هدف تجزیه و تحلیل نتایج، ایجاد تغییرات در فرآیند توسعه بر اساس تجربیات به دست آمده، و پر کردن پایگاه دانش توسعه‌دهندگان با راه‌حل‌ها و هشدارهای جدید و همچنین مؤلفه‌های آماده جدید است که می‌توان از آنها استفاده کرد. پروژه های آینده

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

فرآیند توسعه نرم افزار سرمایه گذاری

روند توسعه نرم افزار سرمایه گذاری از این جهت متفاوت است که می توان کار موازی را روی چندین نسخه از محصول به طور همزمان انجام داد: در حالی که نسخه اول نگهداری می شود، نسخه دوم در حال حاضر اجرا شده است و الزامات برای نسخه سوم تدوین شده است. فرآیند در شکل 2 نشان داده شده است.

شکل 2. فرآیند توسعه نرم افزار سرمایه گذاری.

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

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

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

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

در مورد فرآیند توسعه نرم افزار سرمایه گذاری، باید بدانید که کار بر روی چندین نسخه دارای تعدادی وابستگی متقابل آشکار و پنهان بین شاخه های موازی فرآیند است.

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

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

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

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

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

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

همانطور که در بالا ذکر شد، سیستم عامل با سیستم عامل سفارشی تفاوت دارد زیرا نگهداری از آن بسیار دشوار است.

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

بنابراین، هنگام توسعه نرم افزارهای جاسازی شده، چندین محدودیت مهم به طور همزمان ایجاد می شود.

اولا، تحویل تنها در چارچوب یک مرحله انجام می شود: هیچ کس یک برنامه نیمه کاره را در دستگاه ها تعبیه نمی کند.

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

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

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

فرآیند توسعه سیستم عامل در شکل 3 نشان داده شده است.

شکل 3. فرآیند توسعه نرم افزار تعبیه شده.

روند توسعه بازی

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

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

این عوامل بر روند توسعه نرم افزار بازی تاثیر می گذارد. فرآیند در شکل 4 نشان داده شده است.

شکل 4. فرآیند توسعه نرم افزار بازی.

باید به ویژگی های زیر در فرآیند توسعه نرم افزار بازی اشاره کرد.

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

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

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

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

نتیجه

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

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

مراحل توسعه نرم افزار

فرآیند توسعه نرم افزار را می توان به مراحل (فاز) تقسیم کرد:

- توسعه یک مدل و انتخاب یک روش راه حل.

- توسعه یک الگوریتم برای حل مسئله؛

- کدگذاری الگوریتم؛

- تدوین برنامه؛

- تست برنامه؛

- ایجاد اسناد؛

- نگهداری و بهره برداری

در نتیجه این مرحله از کار، سندی به نام "تکالیف توسعه نرم افزار (تکلیف فنی)" تنظیم می شود. موارد زیر را بیان می کند:

- نام کار تعریف مختصری از مشکلی که باید حل شود ارائه شده است، نام بسته نرم افزاری، سیستم برنامه نویسی برای اجرای آن و الزامات سخت افزاری مشخص شده است.

- شرح. بیان مسئله، هدف و هدف مشکل، مکان و ارتباط آن با سایر مشکلات، محتوای عملکردهای پردازش اطلاعات ورودی در هنگام حل مشکل، الزامات فراوانی حل مسئله به تفصیل ارائه شده است.

- کنترل حالت های عملکرد برنامه. الزامات اساسی برای روش تعامل بین کاربر و برنامه (رابط کاربر-رایانه) فرموله شده است.

- داده های ورودی. داده‌های ورودی، محدودیت‌هایی که می‌توانند در آن تغییر کنند، مقادیری که نمی‌توانند بگیرند و غیره، و همچنین منبع داده، یعنی. دستگاهی که قرار است با آن به برنامه منتقل شوند.

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

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

- نمونه ای از کار بسته نرم افزاری. یک یا چند نمونه از عملیات پیچیده برنامه ارائه شده است که در ساده ترین موارد، اشکال زدایی و آزمایش می شود.

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

توسعه یک الگوریتم برای حل مسئله... در این مرحله ساختار کلی بسته نرم افزاری شکل می گیرد. الگوریتم – این سیستمی از قوانین دقیق فرموله شده است که فرآیند تبدیل داده های ورودی مجاز (اطلاعات ورودی) به یک نتیجه دلخواه (اطلاعات خروجی) را در تعداد محدودی از مراحل تعیین می کند.

در فرآیند توسعه یک الگوریتم، می توان از روش های مختلفی برای توصیف آن استفاده کرد: نمادگذاری شفاهی، نمودارهای بلوکی، شبه کد، نمودارهای ساختاری و غیره.

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

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

تدوین برنامه.پس از تکمیل کدنویسی (نوشتن برنامه به زبان برنامه نویسی) و وارد شدن کد منبع برنامه به حافظه کامپیوتر، برنامه کامپایل می شود، یعنی. ترجمه متن منبع به کد ماشین این فرآیند توسط یک برنامه ویژه - یک کامپایلر انجام می شود. شکل 1 نموداری از آماده سازی یک برنامه اجرایی را نشان می دهد.

ابتدا برنامه منتقل می شود پیش پردازندهکه اجرا می کند بخشنامه هاموجود در متن آن (به عنوان مثال، #include - شامل یک فایل در متن برنامه).

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

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

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

ایجاد مستندات.مستندات بر اساس هدف خود طبقه بندی می شوند و می توان آنها را به چند گروه تقسیم کرد: توضیحات برنامه، راهنمای کاربر، کتابچه راهنمای برنامه نویس.

توضیحات برنامه- مشخصات کلی محصول نرم افزاری و دامنه کاربرد آن، الزامات نرم افزار پایه، مجموعه ای از ابزارهای پردازش فنی.

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

راهنمای برنامه نویسبرای توسعه دهندگان نرم افزار و متخصصانی که آن را همراهی می کنند در نظر گرفته شده است. این راهنما به عنوان اسناد کلیدی شامل موارد زیر است:

تکلیف توسعه نرم افزار (تکالیف فنی)؛

مشخصات؛

متون منبع اظهار نظر (فهرست) ماژول های برنامه و ماژول کنترل.

طرح تقسیم بسته نرم افزاری به ماژول های نرم افزاری؛

نمودار جریان داده بسته نرم افزاری؛

طرح تعامل ماژول های نرم افزار.

طرح ها و داده ها برای آزمایش بسته نرم افزاری؛

مواد دیگری که پروژه را نشان می دهند، به عنوان مثال: بلوک دیاگرام های بسته نرم افزاری و ماژول های نرم افزار.

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

یک استاندارد دولتی وجود دارد که مراحل توسعه برنامه‌ها و اسناد نرم‌افزاری را برای رایانه‌ها، مجتمع‌ها و سیستم‌ها بدون توجه به هدف و زمینه کاربرد آنها تعیین می‌کند.

فرآیند توسعه نرم افزار را می توان به مراحل (فاز) که در شکل 1 نشان داده شده است، تقسیم کرد. 15.

برنج. 15. مراحل توسعه نرم افزار

کار بر روی نرم افزار با تهیه پیش نویس سندی به نام "تکالیف توسعه نرم افزار (تکالیف فنی)" آغاز می شود.

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

وظیفه فنی

شرایط مرجع شامل سه مرحله است: 1) توجیه نیاز به توسعه یک برنامه. 2) انجام کارهای تحقیقاتی؛ 3) توسعه و تصویب مشخصات فنی.

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

در نتیجه کار تحقیقاتی، ساختارهای داده های ورودی و خروجی تعیین می شود، انتخاب اولیه روش ها برای حل مسئله انجام می شود و امکان اساسی حل مسئله اثبات می شود.

توسعه و تایید مشخصات فنی شامل:

تعیین الزامات برنامه؛

توسعه یک مطالعه امکان سنجی برای توسعه برنامه؛

تعیین مراحل، مراحل و شرایط توسعه برنامه و مستندسازی آن؛

انتخاب زبان های برنامه نویسی؛

تعیین نیاز به کار تحقیقاتی در مراحل بعدی؛

هماهنگی و تایید مشخصات فنی.

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

ورودی چه چیزی باید باشد؟

کدام داده صحیح و کدام اشتباه است؟

چه کسی از نرم افزار استفاده خواهد کرد و رابط (وسایل ارتباط با کاربر) چگونه باید باشد؟

چه ساده سازی ها، مفروضات و مفروضاتی را می توان در رابطه با برنامه ها انجام داد؟

خروجی باید چقدر باشد؟

الزامات قابلیت اطمینان، ارائه عملکرد قابل اعتماد برنامه را تعریف می کند. خطاهایی که باید شناسایی شوند و پیام هایی که در صورت وجود خطا به کاربر نمایش داده شود مشخص می شود. تمام موقعیت های خاص که نیاز به حسابداری اضافی و توجه ویژه دارند فهرست شده اند.

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

طرح

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

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

1) او ابزاری برای تعامل با محیط خارجی دارد.

2) یک واحد نرم افزار مستقل است که عملکردهای خاصی را انجام می دهد.

جریان های داده بخشی از رابط هستند. هنگام تشریح آنها برای هر ماژول، لازم است به سؤالات زیر پاسخ دهید:

چه داده هایی را می توان قبل از شروع اجرا به ماژول ارسال کرد؟

چه ساده سازی ها، مفروضات و مفروضاتی در رابطه با ماژول انجام شده است؟

پس از اتمام کار ماژول چه اتفاقی برای داده ها خواهد افتاد؟

در شکل 16 نمونه ای از توصیف یک ماژول را نشان می دهد که برای مرتب سازی اعداد صحیح استفاده می شود.

برنج. 16. نمونه ای از مشخصات ماژول

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

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

پیش نویس کاری

پروژه کاری شامل توسعه برنامه و مستندات برنامه و همچنین آزمایش برنامه است.

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

کدنویسی باید ساده باشد. اصل به اصطلاح KISS باید رعایت شود: Keep It Simple, Stupid (ساده نگه دار، ای احمق!). هنگام اشکال زدایی و اصلاح یک برنامه، برنامه نویسی پیچیده می تواند پرهزینه باشد. کدنویسی غیرمعمول (مثلاً بهره برداری از قابلیت های پنهان دستگاه) اغلب مانع از اشکال زدایی برنامه می شود و البته استفاده از آن را برای برنامه نویسان دیگر دشوار می کند.

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

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

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

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

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

برای یک برنامه ساده، آزمایش می تواند ساده باشد. آزمایش برنامه های بزرگ دشوار است. حذف احتمالی خطاها در مرحله عملیات.

می‌توانیم نمونه‌هایی از خطاهایی در مجموعه‌های نرم‌افزاری که در حین توسعه ایجاد شده‌اند و در طول آزمایش شناسایی نشده‌اند، ارائه کنیم.

در "مرجع Microsoft Works" در راهنمای آنلاین بسته پردازش اطلاعات یکپارچه Works 2.0، تابع IF به شرح زیر است.

IF (شرط، مقدار نادرست، ارزش واقعی).

با این حال، در واقعیت، عملکرد این تابع باید به صورت زیر باشد: IF (شرط، ValueTrue، ValueFalse). راهنمای کاربر Works 3.0 Microsoft Works برای ویندوز این مشکل را برطرف می کند.

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

50 i = 12.525 را انجام دهید

در واقع باید اینطور به نظر می رسید:

50 i = 12.525 را انجام دهید

عوارضی که در هنگام بازگشت خدمه شوروی-افغانستان و شوروی-فرانسه به زمین به وجود آمد، ناشی از خطاهای نرم افزاری رایانه های داخلی بود.

در سال 1983، سیل در جنوب غربی ایالات متحده رخ داد. دلیل آن این بود که داده های آب و هوای نادرست به رایانه وارد شد، در نتیجه سیگنال اشتباهی به دروازه هایی که رودخانه کلرادو را مسدود می کردند، می داد.

برای جلوگیری از وارد شدن کاربران به موقعیتی که برنامه کار می کند، اما کاری را که باید انجام نمی دهد، برای شناسایی خطاهای "پنهان" آزمایش انجام می شود. آزمایش از طرح ها و داده هایی استفاده می کند که قبلاً در مرحله طراحی توسعه یافته اند. لازم است در کل دوره توسعه برنامه در مورد آزمایش فکر کنید (جدول 2).

جدول 2

انواع و علل خطاها

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

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

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

پیاده سازی

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

نمونه ای از افزودن توابع جدید به بسته نرم افزاری ویرایشگر متن Lexicon 1.3 است. این نسخه از واژه پرداز 1.2 با گنجاندن توابع - وارد کردن فایل های گرافیکی با فرمت PCX به فایل های متنی در آن به دست آمده است.

مستندات

در شکل 15 مستطیلی که هر مرحله از توسعه برنامه را نشان می دهد به مستطیل "سند" متصل می شود. در این حالت، فلش ها در هر دو جهت هدایت می شوند. ایده‌ها و راه‌حل‌های مورد استفاده در هر مرحله بر مستندات همراه با مرحله تأثیر می‌گذارند، همانطور که مستندسازی بر ایده‌ها و راه‌حل‌ها تأثیر می‌گذارد.

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

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

شرایط مرجع باید شامل بخش های زیر باشد:

معرفی؛

مبنای توسعه؛

هدف توسعه؛

الزامات برنامه و محصول نرم افزاری؛

الزامات اسناد نرم افزاری؛

شاخص های فنی و اقتصادی؛

مراحل و مراحل توسعه؛

مراحل کنترل و پذیرش

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

مشخصات سند اصلی برنامه است و مطابق با GOST تهیه شده است. مشخصات جدولی متشکل از ستون‌هایی است: "تعیین"، "نام"، "توجه". در ستون "تعیین"، نامگذاری اسناد و برنامه های فهرست شده ثبت می شود. در ستون "اسناد" نام و نوع سند یا برنامه را مشخص کنید. در ستون "یادداشت" - اطلاعات اضافی مربوط به برنامه های ثبت شده در مشخصات.

توضیحات برنامه شامل:

- متون منبع اظهار نظر (فهرست) ماژول های برنامه و ماژول کنترل.

- طرح تقسیم مجموعه نرم افزاری به ماژول های نرم افزاری؛

- نمودار جریان داده بسته نرم افزاری؛

- طرح تعامل ماژول های نرم افزار؛

- طرح ها و داده ها برای آزمایش بسته نرم افزاری؛

- مواد دیگری که پروژه را نشان می دهند، به عنوان مثال، نمودارهای الگوریتم.

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

رشته برنامه نویسی عامل مهمی در موفقیت توسعه نرم افزار است. اصول برنامه نویسی در فصل آخر برای زبان های برنامه نویسی رویه ای و زبان های شی گرا اعمال می شود.

نسخه 6.0 توربو پاسکال که در سال 1990 منتشر شد، به وضوح مزایای فناوری برنامه نویسی شی گرا را نشان داد. بسته تحویل نسخه جدید شامل کتابخانه Turbo Vision است که بر روی آن هزاران برنامه نویس بر اصول OOP تسلط دارند. در مدت کوتاهی، بسیاری از برنامه های تجاری مبتنی بر Turbo Vision ظاهر شدند. این کتابخانه واقعاً انقلابی در فرآیند توسعه نرم‌افزار تعاملی ایجاد می‌کند، زمان تحویل را به حداقل می‌رساند و نرم‌افزار با بالاترین کیفیت را ارائه می‌دهد.

تکامل سخت افزار رایانه شخصی منجر به جایگزینی گسترده سیستم عامل قدیمی خوب MS - DOS با سیستم های ویندوزی بسیار قدرتمندتر شده است که برنامه نویسی برای آنها بسیار پیچیده تر از برنامه نویسی برای MS - DOS است. با انتشار Borland Pascal with Objects، Borland ابزارهای توسعه و اشکال زدایی بسیار کارآمدی را در اختیار برنامه نویسان قرار داده است که برای اجرا تحت سیستم عامل ویندوز طراحی شده اند. اما هنوز، چند سال پیش، یک برنامه نویس معمولی فقط می توانست رویای ایجاد برنامه های خود را برای ویندوز داشته باشد.

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

برنج. 26.1.

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

این مرحله همچنین محیطی را که برنامه در آن اجرا می شود تعیین می کند: الزامات سخت افزاری، سیستم عامل استفاده شده و سایر نرم افزارها.

بیان مسئله با ایجاد به پایان می رسد مشخصات فنی،و سپس مشخصات برنامه خارجی،که شامل:

■ شرح داده های ورودی و نتایج (انواع، فرمت ها، دقت، روش انتقال، محدودیت ها).

■ شرح وظایف انجام شده توسط برنامه.

■ راه دسترسی به برنامه.

■ شرح شرایط اضطراری احتمالی و خطاهای کاربر.

بنابراین، برنامه به عنوان یک "جعبه سیاه" در نظر گرفته می شود که یک تابع و داده های ورودی و خروجی برای آن تعریف شده است.

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

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

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

■ ارائه داده های مورد نیاز چقدر دقیق است؟

■ مقادیر داده ها در چه محدوده ای هستند؟

■ آیا حداکثر مقدار داده محدود است؟

■ آیا ذخیره همزمان آنها در برنامه ضروری است؟

■ چه اقداماتی باید روی داده ها انجام دهید؟

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

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

طرح.زیر طراحی برنامهتعریف ساختار کلی و تعامل ماژول ها درک شده است.

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

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

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

توجه

مرحله طراحی باید امکان تغییرات آتی برنامه را در نظر بگیرد و سعی کند برنامه را به گونه ای طراحی کند که تغییرات تا حد امکان آسان باشد.

از آنجایی که معلوم نیست چه تغییراتی باید ایجاد شود، این آرزو یادآور ایجاد یک "نظریه کلی همه چیز" است. در عمل، لازم است خود را به سازش های معقول محدود کنیم. برنامه نویس بر اساس تجربه و عقل سلیم خود تصمیم می گیرد که کدام ویژگی های برنامه ممکن است در آینده نیاز به تغییر یا بهبود داشته باشد.

فرآیند طراحی تکراری است، زیرا در برنامه‌های با اندازه واقعی نمی‌توان در اولین بار به همه جزئیات فکر کرد.

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

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

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

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

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

مراحل طراحی و برنامه نویسی در زمان با هم ترکیب می شوند: در حالت ایده آل، ابتدا سطح بالا طراحی و کدگذاری می شود، سپس سطح بعدی و غیره. این استراتژی به این دلیل استفاده می‌شود که هزینه خطا را کاهش می‌دهد، زیرا ممکن است نیاز باشد تغییراتی در طول فرآیند کدگذاری اعمال شود که بر ماژول‌های سطح پایین‌تر تأثیر می‌گذارد.

تست از بالا به پاییناین مرحله آخرین مرحله ثبت می شود، اما این بدان معنا نیست که آزمایش در مراحل قبلی انجام نشود. هم طراحی و هم برنامه نویسی باید همراه با نوشتن باشد مجموعه تست – داده های ورودی اعتبارسنجی و مجموعه واکنش های مرجع مربوطه.

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

دو استراتژی تست وجود دارد: جعبه سیاه و جعبه سفید. هنگام استفاده از اولی، ساختار داخلی برنامه در نظر گرفته نمی شود و تست ها به گونه ای طراحی می شوند که عملکرد برنامه را بر روی تأثیرات ورودی صحیح و نادرست به طور کامل بررسی کنند.

استراتژی "جعبه سفید" شامل آزمایش تمام شاخه های الگوریتم است. تعداد کل شعب با ترکیب همه گزینه ها در هر مرحله تعیین می شود. این یک عدد محدود است، اما می‌تواند بسیار بزرگ باشد، بنابراین برنامه به قطعات تقسیم می‌شود، پس از آزمایش کامل آن‌ها به عنوان گره‌های ابتدایی شاخه‌های طولانی‌تر در نظر گرفته می‌شوند. علاوه بر داده هایی که اجرای عبارات را به ترتیب مورد نیاز تضمین می کند، آزمون ها باید شامل باشند بررسی وضعیت مرزی(به عنوان مثال، انتقال بر اساس شرط ایکس> 10 باید برای مقادیر بزرگتر، کمتر و مساوی 10 بررسی شود. واکنش برنامه به داده های اولیه اشتباه

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

توجه

ایده آزمایش از بالا به پایین فرض می‌کند که آزمایش یک برنامه قبل از تکمیل طراحی آن آغاز می‌شود. این به شما این امکان را می دهد که رابط های اصلی میان ماژول را زودتر امتحان کنید و همچنین مطمئن شوید که برنامه اساساً نیازهای کاربر را برآورده می کند. تنها پس از آن که هسته منطقی آنقدر آزمایش شد که به صحت اجرای رابط های اصلی اطمینان حاصل شد، شروع به کدنویسی و تست سطح بعدی برنامه می کنند.

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

مرحله اشکال زدایی پیچیده در سطح سیستم در طراحی از بالا به پایین زمان کمتری نسبت به طراحی از پایین به بالا دارد و شگفتی های کمتری را به همراه دارد زیرا احتمال اشکالات جدی که بیشتر سیستم را تحت تأثیر قرار می دهد بسیار کمتر است. علاوه بر این، برای هر ماژول متصل به سیستم، محیط آن قبلا ایجاد شده است و خروجی ماژول های اشکال زدایی شده می تواند به عنوان ورودی برای تست دیگران استفاده شود که فرآیند تست را تسهیل می کند. این بدان معنا نیست که ماژول باید کاملاً "خام" به سیستم متصل شود؛ گاهی اوقات انجام بخشی از آزمایش به طور مستقل راحت است، زیرا تولید همه گزینه های لازم برای آزمایش یک ماژول جداگانه در ورودی سیستم دشوار است.

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

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

برنج. 26.2.

• انواع و فرمت ها به معنای انواع زبان برنامه نویسی نیست.