پاورپوینت کامل مهندسی نرم افزار: بحران نرم افزار ۸۶ اسلاید در PowerPoint

توجه : این فایل به صورت فایل power point (پاور پوینت) ارائه میگردد

 پاورپوینت کامل مهندسی نرم افزار: بحران نرم افزار ۸۶ اسلاید در PowerPoint دارای ۸۶ اسلاید می باشد و دارای تنظیمات کامل در PowerPoint می باشد و آماده ارائه یا چاپ است

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

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

توجه : در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل می باشد و در فایل اصلی پاورپوینت کامل مهندسی نرم افزار: بحران نرم افزار ۸۶ اسلاید در PowerPoint،به هیچ وجه بهم ریختگی وجود ندارد

بخشی از مطالب داخلی اسلاید ها

پاورپوینت کامل مهندسی نرم افزار: بحران نرم افزار ۸۶ اسلاید در PowerPoint

اسلاید ۴: مشخص شدن وسعت کار ساخت نرم‌افزارهای امروزی – چند نمونه- دو میلیون خط اسمبلی سیستم KLM- 3/7 میلیون خط کد سیستم عامل UNIX- 400 میلیون خط کد مقصد شاتل، ۱/۳۰ ساترن- ۵۰۰۰ مرد-سال برای تولید OS360توجه . . . پیشرفت همچنان ادامه دارد!- عدم آشنایی برنامه نویس با زمینه‌ی کار (استفاده از روش آزمایش و خطا)- افزودن بی‌رویه‌ی نیروی برنامه‌نویس برای پیشبرد پروژه (MILLION-MONKEY)نتیجه:- عدم تحویل به‌موقع نرم‌افزار- عدم برآورده‌کردن خواسته‌های کاربر- عدم امکان اصلاح و تطبیق برنامه‌ها با شرایط- خطا‌های زیاد بلافاصله پس از تحویل

اسلاید ۵: حاصل کار: اعلام اصطلاح ‹بحران نرم‌افزار› برای این وضعیتدو کنفرانس ناتو در ۱۹۶۸ و ۱۹۶۹ تحت همین عنوانتولد ‹مهندسی نرم‌افزار› با دورنمای زیرساختن نرم‌افزار طبق اصول مهندسی مانند سایر رشته‌ها:مطالعات تئوریک، تحلیل ، طراحی بر مبنای اصول علمی، پیاده سازیمقایسه با ساختن یک پل یا ساختمان، ساختن یک قطعه‌ی مکانیکیساخت نرم‌افزار بدون رعایت اصول مهندسی معادل:شروع پروژه‌ی ساختمان با کندن زمین، تراش قطعه بدون طرح دقیق

اسلاید ۶: دلایل سرمایه گذاری در ساخت نرم افزار- استفاده‌ی اجتناب ناپدیر (عابربانک)- جایگزینی تکنولوژی جدید (حروف چینی، ساخت تراشه)- افزایش کیفیت سرویس (کتابخانه)- تقلیل هزینه‌ها (کنترل انبار)بهره‌دهی اقتصادی، مهم‌ترین هدف در غالب مواردآمار مبین درجه‌ی اهمیت صنعت تولید نرم‌افزار- ۱۹۸۰: ۴۰ میلیون دلار سرمایه‌گذاری در آمریکا معادل ۲% تولید ناخالص ملی- ۱۹۸۵: ۷۰ میلیون دلار سرمایه‌گذاری در آمریکا، ۱۴۰ میلیون دلار در دنیا – مقایسه‌ی هزینه‌های نرم‌افزار و سخت‌افزار، تقلیل شدید مورد اخیر- ۱۲% افزایش سالانه‌ی تقاضا – ۴% رشد سالانه‌ی نیروی متخصص نرم‌افزار- ازدیاد روزافزون فاصله بین عرضه و تقاضا (مثال: . . . )

اسلاید ۷: اهمیت تولید نرم‌افزار کیفی، خطرناک بودن خطا‌ها در نرم افزار- اخطار اشتباهی حمله‌ی شوروی در ۶ و ۹ ژوئن ۱۹۸۰ در DoD- ضرر ۵۰ میلیون دلاری شرکت هواپیمایی، اعلام اشتباهی پر شدن صندلی‌های ارزان- اعلام اشتباهی بیماری لاعلاج یک زن توسط شرکت بیمه، برائت او در قتل دخترشافزایش روز به روز درصد ریسک در استفاده از کامپیوتر در هر زمینهاهمیت فوق‌العاده‌ی مهندسی نرم‌افزار برای تقلیل ریسکنیاز به روش‌ها و تکنیک‌های پیشرفته‌تر در ساخت نرم‌افزار برای:- صرفه‌جویی‌های اقتصادی – افزایش کارآیی روش‌ها – برآورده کردن دقیق‌تر خواسته‌های کاربران- افزایش درجه‌ی اعتماد کاربران به نرم‌افزار و محیط حاوی آن کیفیت و سودمندی (Q & P) دو عامل مهم در مهندسی نرم‌افزار

اسلاید ۸: ناتو: تبیین و استفاده از اصول مناسب مهندسی برای تولید نرم‌افزار‌های مقرون به صرفه، قابل اعتماد و دارای کارآیی بالا هنگام استفاده روی ماشین‌های واقعیIEEE: برخورد سیستماتیک با روند تولید، عملکرد، نگهداری و کنارگذاشتن نرم‌افزارفازی بودن تعاریف . . .خصوصیات اصلی مهندسی نرم‌افزار:۱- ارتباط با ایجاد برنامه‌های خیلی بزرگ Programming-In-The- Small در مقابل Programming-In-the- Large- برنامه‌ی مثلاً ۱۰۰ خطی – برنامه‌ی مثلاً ۵۰۰۰۰ خطی- یک نفر برنامه‌نویس، مدت کوتاه – گروه برنامه نویس، مدت طولانی (۶ ماه)- تکنیک‌ها و ابزار‌های معمولی – عدم امکان تطبیق با تکنیکها و ابزار‌ها‌یPITS- مطرح بودن فقط برنامه – یک سیستم متشکل از برنامه‌های وابسته به‌هم

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

اسلاید ۱۰: ۵- اهمیت حیاتی کارآیی مراحل ساخت نرم‌افزار- بالا بودن هزینه و زمان برای ساخت و نگهداری- تفوق نیاز به نرم‌افزار‌های جدید بر منابع انسانی موجود، فاصله‌ی عرضه با تقاضا (مثال …)- نیاز به ابزار‌ها و روش‌های بهتر برای ساخت نرم‌افزار منطبق با اصول مهندسی ۶- نیاز به پشتیبانی موثر از کاربران – نیاز به تطبیق عملکرد نرم‌افزار با نحوه‌ی کار کاربر (پیشگیری از اعلام سریع خواسته‌های جدید یا مقابله با آن)- نه فقط ساخت درست سیستم بلکه ساخت سیستم درست- اهمیت دریافت درست خواسته‌های عملیاتی- درنظر گرفتن قابلیت استفاده و اعتماد، پاسخ‌دهی و کاربرپسندی (فاکتور‌های کیفیت)- عدم احتساب فقط برنامه‌ها به‌عنوان نرم‌افزار، بلکه احتساب مستندات کاربر، آموزش و نگهداری، ایجاد شرایط محیط حاوی نرم‌افزار، آثار جانبی نرم‌افزار

اسلاید ۱۱: وجود جنبه‌های مختلف در مهندسی نرم‌افزار- برنامه‌نویسی بخش مهمی از آن ولی نه کل آن- جنبه‌های ریاضی برای اثباط صحت نرم‌افزار- جنبه‌های مهندسی برای تولید محصول درست و مفید- جنبه‌های روانشناسی برای ارتباط درست انسان و ماشین- جنبه‌های مدیریتی برای کنترل پروژه با توجه به حجم کارمقایسه‌ی ساخت نرم‌افزار با ساخت پل (فهم بهتر مهندسی نرم‌افزار) – مجموعه خواسته‌های عملیاتی- کاربرد خلاق روش‌های علمی و مهندسی – انجام کار طی فاز‌های مختلف- نیاز به برنامه‌ریزی دقیق انجام فاز‌ها – رسیدگی ممتد به روند انجام کار‌- پیاده سازی بر مبنای طرح دقیق و حساب شدهامکان فروریختن پل (استثنا)، ضعف دانش و تخمین دوراز واقعیت قاعده شدن تخمین‌های مشابه (به جای استثنا) در ساخت نرم‌افزار

اسلاید ۱۲: دلایل وجود دید متفاوت بین ساخت نرم‌افزار با ساخت محصول فیزیکی- وجود هزینه در مراحل ساخت (development) و نه در مراحل تولید (production) – غیر ملموس (غیرفیزیکی)بودن نرم‌افزار – امکان تکثیر نرم‌افزار تقریباً بدون هزینه- استهلاک ملموس محصول فیزیکی- هزینه‌های نرم‌افزار دراثر تغییر خواسته‌ها- حصول قابلیت اعتماد بر مبنای خطا‌های یافت شده و نه شکستگی و پارگیدو خصیصه‌ی مهم منتح به پیچیده شدن زیاد مدیریت نرم‌افزار – قابل رویت نبودن: وجود امکان دیدن روند بالا رفتن ساختمان ولی نه ساخت نرم‌افزار – بیماری ۹۰% تکمیل در ساخت نرم‌افزار – پیوسته نبودن: تعییرات جزئی در خواسته‌های یک پروژه‌ی فیزیکی منجر یه تغییرات جزئی در محصول فیزیکی ولی نه در محصول نرم‌افزاری- تاثیر وحشتناک خطا‌های جزیی در نتیجه‌ی کار (گم شدن مارینر در زهره)مهندسی نرم‌افزار و علم کامپیوتر، سایر مهندسی‌ها و علوم پایه

اسلاید ۱۳: مقایسه با مراحل ساخت یک خانه- وجود مراحل مشابه در ساخت نرم‌افزار شامل: تعریف مسئله، تبیین و تحلیل دقیق خواسته‌ها، طراحی بر مبنای خواسته‌ها، پیاده‌سازی (برنامه‌نویسی)، آزمون، نگهداری، . . . – نمایش مراحل به‌صورت process model کلی در ش ۱-۲ ص ۱۰- وجود مراحل جزئی‌تر تشکیل دهنده‌ی هر مرحله‌ی کلی- ترتیبی نبودن مراحل، وجود هم‌پوشانی و برگشت به عقب- عدم وجود مرز دقیق بین مراحلجزئیات مرحله‌ی تبیین و تحلیل خواسته‌ها (مهندسی خواسته‌ها) – عملکرد مورد نیاز نرم‌افزار- توسعه های آتی – نوع و حجم مستندات مورد نیاز- رمان پاسخ مورد درخواست – امکان سنجی: بررسی وجود راه حل مقرون به صرفه و قابل پیاده‌سازی از نظر فنی- حاصل این مرحله: مشخصه‌ی خواسته‌ها (RS)- شرح این مرحله در ترم قبل، اهمیت درستی آن برای درستی مراحل بعدی

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

اسلاید ۱۵: بر اساس بودجه تعیین شدهبر اساس جدول زمان‌بندی تعیین شدهبا کیفیت لازممتناسب با نیازهای کاربرهدف مهندسی نرم افزار تولید محصول :

اسلاید ۱۶: How Programs Are Usually Written …

اسلاید ۱۷: How Programs Are Usually Written … The requirements specification was defined like this The developers understood it in that wayThis is how the problem was solved before. This is how the problem is solved nowThat is the program after debuggingThis is how the program is described by marketing departmentThis, in fact, is what the customer wanted … 😉

اسلاید ۱۸:

اسلاید ۱۹:

اسلاید ۲۰:

اسلاید ۲۱:

اسلاید ۲۲:

اسلاید ۲۳: Preliminary Investigation – Information problems or needs are identified. Systems Analysis – Present system is studied in depth and new requirements are specified. Systems Design