رویکرد ساختاری رویکرد سیستمی به توسعه نرم افزار جنبه های زمانی و "مکانی" رویکرد سیستمی. مدل چرخه عمر نرم افزار Waterfall رویکردهای توسعه نرم افزار

1. آبشار (آبشار انگلیسی) - مدل توسعه استاندارد

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

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

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

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

مزایای اصلی توسعه آبشار:

2. متدولوژی توسعه نرم افزار چابک

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

نتیجه هر مرحله، از جمله چرخه ای از تکرارها، یک پروژه نرم افزاری مینیاتوری است.

چندین روش توسعه چابک وجود دارد که معروف ترین آنها Scrum، Extreme Programming، DSDM است.

مزایای اصلی توسعه چابک:

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

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

اصول توسعه چابک:

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

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

ببینیم چطور پیش میره…

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

توسعه "چگونه کار می کند"

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

متدولوژی های ساختاری

متدولوژی های ساختاری

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

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

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

روش های چابک

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

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

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

برنامه نویسی فوق العاده یا XP (برنامه نویسی شدید)

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

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

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

شفاف مثل شیشه

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

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

ویژگی های کلیدی Crystal Clear:

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

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

توسعه مبتنی بر ویژگی

توسعه ویژگی محور (FDD) بر حسب یک ویژگی یا ویژگی سیستم عمل می کند که تقریباً به مفهوم مورد استفاده RUP نزدیک است. شاید مهم ترین تفاوت یک محدودیت اضافی باشد: "هر تابع باید اجازه اجرای حداکثر در دو هفته را بدهد." یعنی اگر مورد استفاده به اندازه کافی کوچک باشد، می توان آن را یک تابع در نظر گرفت و اگر بزرگ باشد، باید به چندین تابع نسبتا مستقل تقسیم شود.

FDD شامل پنج فرآیند است که دو مورد آخر برای هر ویژگی تکرار می شود:

• توسعه مدل کلی;
• فهرست کردن توابع لازمسیستم های؛
• برنامه ریزی کار بر روی هر عملکرد؛
• طراحی عملکرد؛
• ساخت تابع

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

توسعه دهندگان در FDD به "کارشناس ارشد کلاس" و "برنامه نویس ارشد" تقسیم می شوند. برنامه نویسان اصلی صاحبان کلاس های درگیر را درگیر می کنند تا روی ویژگی بعدی کار کنند. برای مقایسه: در XP هیچ مسئولیت شخصی برای کلاس ها یا متدها وجود ندارد.

ویژگی های مشترک

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

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

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

روش های چابک

GOSTs

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

در حال حاضر، GOST های قدیمی سری 19 و 34 و جدیدتر GOST R ISO IEC 122207 در روسیه در حال اجرا هستند. GOST های سری 19 و 34 به شدت بر روی رویکرد آبشاری توسعه نرم افزار متمرکز شده اند. توسعه مطابق با این GOST ها در مراحلی انجام می شود که هر یک شامل انجام کارهای کاملاً تعریف شده است و با انتشار تعداد نسبتاً زیادی اسناد بسیار رسمی و گسترده به پایان می رسد. بنابراین، رعایت فوری این استانداردها نه تنها منجر به رویکرد آبشاری می شود، بلکه درجه بسیار بالایی از رسمی سازی توسعه را نیز فراهم می کند.

الزامات GOST

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

بنابراین، GOST 12207 امکان توسعه نرم افزار تکراری و کمتر رسمی را فراهم می کند.

مدل‌های بلوغ فرآیند توسعه (CMM، CMMI)

علاوه بر دولت و استانداردهای بین المللی، چندین رویکرد برای صدور گواهینامه فرآیند توسعه وجود دارد. مشهورترین آنها در روسیه ظاهراً CMM و CMMI هستند.

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

الزامات CMM و CMMI

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

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

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

RUP

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

روش RUP

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

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

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

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

در حال حاضر در مهندسی نرم افزار دو رویکرد اصلی برای توسعه نرم افزار IP وجود دارد که تفاوت اساسی بین آنها ناشی می شود راه های مختلفتجزیه سیستم ها: رویکرد عملکردی - مدولار (ساختاری) که مبتنی بر اصل تجزیه عملکردی است که در آن ساختار سیستم از نظر سلسله مراتب عملکردهای آن و انتقال اطلاعات بین عناصر عملکردی منفرد توصیف می شود. رویکرد شی گرا، که از تجزیه شی استفاده می کند، ساختار IS را از نظر اشیا و روابط بین آنها و رفتار سیستم را از نظر پیام رسانی بین اشیاء توصیف می کند.

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

اصول اساسی رویکرد ساختاری عبارتند از:

o اصل " تفرقه بینداز و حکومت کن"؛

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

مهمترین این اصول عبارتند از:

o انتزاع - برجسته کردن جنبه های اساسی سیستم؛

o سازگاری - اعتبار و سازگاری عناصر سیستم؛

o ساختار داده - داده ها باید ساختار یافته و به صورت سلسله مراتبی سازماندهی شوند.

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

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

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

o مشکلات سیستم طراحی شده؛

o کامل بودن لازم توصیف آن؛

o دانش و مهارت شرکت کنندگان در پروژه؛

o زمان اختصاص داده شده برای طراحی

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

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

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

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

3. شناسایی و تجزیه و تحلیل الزامات. نرم افزار مورد نیاز طرح توسعه نیازمندی ها. مدیریت نیازمندی ها

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

5. مدل های فرآیند توسعه. مدل های آبشار و نوار نقاله. مدل های مارپیچی و افزایشی. مدل های فرآیند توسعه انعطاف پذیر

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

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

8. مدل های تیم توسعه. مدل تیم سلسله مراتبی روش تیم جراحی مدل یک تیم برابر.

9. ماهیت برنامه نویسی. علم برنامه نویسی هنر برنامه نویسی. هنر برنامه نویسی. پارادایم های برنامه نویسی. برنامه ریزی ساختاری برنامه نویسی منطقی برنامه نویسی شی گرا.

10. معماری نرم افزار. مدیریت رویداد. معماری کلاینت/سرور. خدمات. معماری سه لایه طراحی برنامه. طراحی مفهومی. طراحی منطقی طراحی دقیق و با جزییات.

1. رویکردهای نویکوف به توسعه نرم افزار” http://window. /window_catalog/files/r60368/itmo307.pdf.

2. برنامه نویسی افراطی. - سن پترزبورگ: پیتر، 2002.

3. تکنولوژی توسعه نرم افزار. - سنت پترزبورگ. : پیتر، 2004.

4. بروکس جونیور. طراحی و ایجاد شده است مجتمع های نرم افزاری. مسکو: ناوکا، 1975; نسخه ترجمه جدید: مرد اسطوره ای ماه. سن پترزبورگ: SYMBOL+، 1999.

5. الگوریتم ها + ساختارهای داده = برنامه ها. م.، میر، 1357.

6. برنامه نویسی سیستماتیک. معرفی. م.: میر، 1977.

7. برنامه نویسی ساخت یافته. م.: میر، 1975.

8. رشته برنامه نویسی. م.: میر، 1978.

9. فن آوری های توسعه نرم افزار. - سن پترزبورگ: پیتر، 2002.

10. برنامه نویسی Terekhov. M.: BINOM، 2006.

11. Rambo J. فرآیند توسعه نرم افزار یکپارچه. سن پترزبورگ: پیتر، 2002.

نظریه اقتصادی برای مدیران

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

دوره ای در تئوری اقتصادی: کتاب درسی برای دانشگاه ها / ویرایش. . -Kirov: "ACA"، 2004. Kolemaev - مدل سازی ریاضی. مدل‌سازی فرآیندها و سیستم‌های اقتصاد کلان: کتاب درسی. M.: UNITY-DANA، 2005. سایبرنتیک باژین. خارکف: کنسول، 2004. کارگاه آموزشی لیوشین در مورد روش های مدل سازی ریاضی: کتاب درسی. ایالت نیژنی نووگورود فن آوری دانشگاه - N. Novorod، 2007. سیاستمداران در مورد اقتصاد: سخنرانی های برندگان جایزه نوبل در اقتصاد. مسکو: اقتصاد و حقوق مدرن، 2005. Cheremnykh. سطح پیشرفته: کتاب درسی.-M.:INFRA-M، 2008. تکامل نهادهای اقتصادی کوچک. موسسه اقتصاد شعبه اورال آکادمی علوم روسیه، - M.: Nauka، 2007.

فن آوری برای توسعه و اتخاذ تصمیمات مدیریتی [N]

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

I. نظریه تصمیم گیری: کتاب درسی. - م.: امتحان، 2006. - 573 ص. I. تصمیم گیری. تئوری و روشهای توسعه تصمیمات مدیریت. آموزش. - م.: مارس، 2005. - 496 ص. توسعه تصمیم مدیریت - م.: انتشارات دلو، 2004 - 392 ص. G. ارزیابی های کارشناسی و تصمیم گیری - M.: ثبت اختراع، 1996. - 271 ص. طه // مقدمه ای بر تحقیق در عملیات = تحقیق در عملیات: مقدمه. - ویرایش هفتم - M.: "Williams"، 2007. - S. 549-594. جی. تیل. پیش بینی های اقتصادی و تصمیم گیری M.: Progress, 1970. K. D. Lewis. روش های پیش بینی شاخص های اقتصادی M.: "مالی و آمار" 1986. G. S. Kildishev, A. A. Frenkel. تحلیل و پیش بینی سری های زمانی M.: "Statistics" 1973. O. Kim, C. W. Muller, W. R. Klekka et al. تحلیل عاملی، تفکیک کننده و خوشه ای. م.: "مالی و آمار" 1368. مدیر موثر. کتاب 3. تصمیم گیری. - MIM LINK، 1999 توروفسکی و مدیریت یک شرکت حمل و نقل موتوری. - م .: مدرسه عالی، 2005.،؛ ویرایش . تجزیه و تحلیل سیستم در مدیریت: آموزش. - M.: امور مالی و آمار، 2006. تینکوف: کتاب درسی. - M.: KNORUS، 2006.

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

اصول فرآیندهای کسب و کار چیست؟ مشکل توصیف جامع فرآیندهای کسب و کار چیست؟ سیستم چیست، چه ویژگی هایی دارد؟ نقش تجزیه و تحلیل سیستم ها در مدل سازی فرآیندهای کسب و کار؟ فرآیند به عنوان یک موضوع کنترل محیط فرآیند عناصر اساسی فرآیند کسب و کار مزایا و معایب مدیریت عملکردی و فرآیندی. چرخه مدیریت PDCA مراحل چرخه مدیریت فرآیند چرخه PDCA و اجرای الزامات ISO 9001:2008. روش SADT (تکنیک تحلیل ساختاری و طراحی - روشی برای تجزیه و تحلیل و طراحی ساختاری). ذات. مقررات اساسی مدل عملکردی فعالیت در متدولوژی IDEF0 چگونه ارائه شده است؟ آثار موجود در نمودارهای مدل عملکردی به چه معنا هستند، طبق متدولوژی IDEF0 چگونه نمایش داده می شوند؟ فلش های موجود در نمودارهای مدل عملکردی برای چیست، انواع و اقسام آنها چیست؟ روش DFD. ذات. اجزای اصلی نمودارهای DFD. نمودارهای DFD چه ویژگی هایی دارند، چه چیزی در آنها توضیح داده شده است؟ ویژگی های اشیاء نمودار DFD چیست؟ فلش های روی نمودار DFD چه چیزی را نشان می دهند؟ روش IDEF3. ذات. ابزارهای مستندسازی و مدل سازی. نمودارهای IDEF3 چه ویژگی هایی دارند، چه چیزی را توصیف می کنند؟ ویژگی های اشیاء نمودار IDEF3 چیست؟ و تیرانداز؟ طبقه بندی فرآیندها فرآیندهای تجاری معمولی مهندسی مجدد و فناوری آن چه زمانی استفاده از مهندسی مجدد در مدیریت یک شرکت مناسب است؟ نظارت و اندازه گیری فرآیندها. شاخص های فرآیندهای سازمان. ارزیابی عددی و رتبه‌بندی فرآیندها.

"مدل سازی فرآیندهای کسب و کار با AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Creating Information Systems with AllFusion Modeling Suite" ed. "Dialogue-MEPhI" 2003 "عمل مدلسازی عملکردی با AllFusion Process Modeler 4.1. (BPwin) کجا؟ چرا؟ چگونه؟ ویرایش "Dialogue-MEPhI" 2004 مدلسازی دوبیکوفسکی با AllFusion Process Modeler (BPwin). ویرایش "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "روش شناسی تحلیل ساختاری و طراحی SADT" کار کلاسیک 1993 در مورد روش شناسی SADT. تجزیه و تحلیل Cheremnykh از سیستم ها: IDEF-فناوری، مدل سازی و تجزیه و تحلیل سیستم ها. فناوری های IDEF کارگاه. M.: مالی و آمار، 2001. "مدل های تجاری ساختاری: فناوری های DFD" http://www. /Level4.asp؟ ItemId=5810 "تئوری و عمل سازماندهی مجدد فرآیند کسب و کار" 2003/ P50.1.. روش مدل سازی عملکردی. مسکو: Gosstandart روسیه، 2000. http://www. IDEF0، IDEF3، DFD http://www. مدل سازی فرآیندهای کسب و کار با استفاده از BPwin http://www. /department/se/devis/7/ IDEF0 در مدیریت مدل‌سازی فرآیند کسب‌وکار http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

ارزیابی اثربخشی محصولات نرم افزاری

1. معماری فناوری اطلاعات

2. حوزه های فرآیندهای مدیریتی.

3. فهرست فرآیندهای حوزه برنامه ریزی و سازماندهی

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

5. فهرست فرآیندها در حوزه عملیات و نگهداری

6. فهرست فرآیندها در حوزه نظارت و ارزیابی

7. مشخص کردن سطوح مدل بلوغ فرآیند

9. KPI و KGI رابطه و هدف آنها

1. 10. کنترل های عمومی فناوری اطلاعات و کنترل های کاربردی. حوزه های مسئولیت و مسئولیت های کسب و کار و فناوری اطلاعات.

Cobit 4.1 نسخه روسی.

مقررات قانونی ایجاد و استفاده از مالکیت معنوی

1. فهرست حقوق مالکیت معنوی نتایج فعالیت های فکری و افشای محتوای آنها.

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

4. مقررات اصلی حمایت قانونی از برنامه رایانه ای را به عنوان موضوع حق چاپ شرح دهید.

5. مفاد اصلی حمایت قانونی پایگاه داده را به عنوان موضوع کپی رایت و به عنوان موضوع حقوق مرتبط با یکدیگر مقایسه کنید.

6.شرایط ثبت اختراع اشیاء حقوق اختراع را شرح دهید: اختراعات. مدل های مفید؛ نمونه های صنعتی

7. محتوای معیارهای ثبت اختراع را گسترش دهید: تازگی. گام مبتکرانه؛ کاربرد صنعتی

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

9. تعریفی از «دانش فنی» ارائه دهید و شرایطی را که حمایت قانونی از اسرار تولید به وجود می آید و انجام می شود فهرست کنید.

10. ابزارهای محافظت شده شخصی سازی را فهرست کنید و ویژگی های مقایسه ای آنها را بیان کنید.

1.، حق مالکیت معنوی در فدراسیون روسیه، کتاب درسی // م، چشم انداز، 2007

2.، حقوق مالکیت فکری، کتاب درسی // M، RIOR، 2009

مدیریت پروژه و توسعه نرم افزار [R]

روش شناسی چیست، چرا به آن نیاز است. ساختار کلی روش شناسی، عناصر اصلی روش شناسی. اصول طراحی روش شناسی خود نمونه هایی از مصنوعات مختلف، نقش ها، شایستگی ها، شرایط مرزی. ساختار روش شناسی کابوری، معیارهای روش شناسی. معیارهای پروژه Cowburn معیارهای انتخاب روش، ماتریس Cowburn. چرخه عمر پروژه آبشار و مدل‌های چرخه زندگی تکراری محدودیت های کاربردی برای مدل های آبشاری و تکراری. RUP به عنوان نمونه ای از روش شناسی تکراری. مفاهیم اولیه RUP، محدودیت های کاربردی. نقش انسان در توسعه نرم افزار روش شناسی چابک، اصول اساسی روش شناسی چابک. منشاء متدولوژی های چابک. اسکرام به عنوان نمونه ای از روش شناسی چابک. نقش ها، مصنوعات، فعالیت ها در اسکرام. محدودیت های کاربردی اسکرام برنامه نویسی شدید (XP) ایده ها، ارزش ها، شیوه های اساسی، محدودیت های کاربردی. شباهت ها و تفاوت های اسکرام و XP. جمع آوری و مدیریت نیازمندی ها. شیوه های اساسی، اصطلاحات، اصول. رویکردهای مستندسازی پروژه و محصول، انواع اصلی اسناد. نمونه هایی از شیوه های مدیریت نیازمندی ها از روش های مورد بحث در دوره. برنامه ریزی توسعه نرم افزار. انواع طرح ها، مدیریت ریسک، ریسک های رایج. نمونه هایی از شیوه های برنامه ریزی توسعه از روش های مورد بحث در این دوره. تست در توسعه نرم افزار. مفهوم مونتاژ (ساخت) یک محصول نرم افزاری. روش های تست اولیه، اصطلاحات. نمونه هایی از روش های آزمایش از روش های مورد بحث در دوره. مفهوم اسمبلی (build)، راه های ذخیره سازی کد، ابزار. دو اصل برای سازماندهی کار با سیستم کنترل نسخه. ویژگی های فرآیند انتشار/طرح بندی محصول برای دسته های مختلف محصول، نمونه هایی از شیوه ها. مفاهیم مدرن معماری نرم افزار، معماری های چند سطحی، معیارهای معماری. فهرست کنید تصمیمات لازمهنگام طراحی نرم افزار، رویکردهایی برای انتخاب یک سیستم ذخیره سازی.

کنت بک - برنامه نویسی افراطی فردریک بروکس - ماه انسان اسطوره ای یا نحوه خلق آنها سیستم های نرم افزاری. تام د مارکو - مهلت. رمانی در مورد مدیریت پروژه تام دی مارکو، تیموتی لیستر - والس با خرس ها. تام دی مارکو، تیموتی لیستر - عامل انسانی_ پروژه ها و تیم های موفق. Alistair Cowburn - هر پروژه متدولوژی خاص خود را دارد. Alistair Cowburn - افراد به عنوان غیرخطی و مهمترین مؤلفه ها در توسعه نرم افزار. آندری اورلوف - یادداشت های یک خودکار. اعتراف حرفه ای فیلیپ کراختن - مقدمه ای بر فرآیند یکپارچه عقلایی. هنریک کنیبرگ - اسکرام و ایکس پی: یادداشت هایی از خط مقدم. ارائه سخنرانی های دوره

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

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

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

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

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

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

چک لیستی از سوالات که به شما امکان می دهد در مورد کیفیت معماری نتیجه گیری کنید: آیا استراتژی طراحی رابط کاربری شرح داده شده است؟ اینکه آیا استراتژی طراحی رابط کاربری توضیح داده شده است یا خیر. آیا انجام شده است رابط کاربریماژولار به طوری که تغییرات آن بر بقیه سیستم تاثیری نداشته باشد. این که آیا رابط کاربری ماژولار ساخته شده است تا تغییرات آن بر بقیه سیستم تأثیری نداشته باشد. آیا شرحی از استراتژی I/O ارائه شده است یا خیر. آیا شرحی از استراتژی I/O ارائه شده است یا خیر. آیا تجزیه و تحلیل عملکرد سیستمی که با استفاده از این معماری پیاده سازی خواهد شد انجام شده است یا خیر. آیا تجزیه و تحلیل عملکرد سیستمی که با استفاده از این معماری پیاده سازی خواهد شد انجام شده است یا خیر. آیا تحلیل قابلیت اطمینان سیستم طراحی شده انجام شده است؟ آیا تحلیل قابلیت اطمینان سیستم طراحی شده انجام شده است؟ آیا تحلیلی از مقیاس پذیری و توسعه پذیری سیستم انجام شده است؟ آیا تحلیلی از مقیاس پذیری و توسعه پذیری سیستم انجام شده است؟

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

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

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

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

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