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

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 فایل ورد کامل مقاله کارآفرینی در شرکت طراحی و تولید بازی‌های رایانه‌ای؛ تحلیل علمی فرآیندهای خلاقیت، فناوری و فرصت‌های اقتصادی دارای ۶۳ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

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

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

---

بخشی از متن فایل ورد کامل مقاله کارآفرینی در شرکت طراحی و تولید بازی‌های رایانه‌ای؛ تحلیل علمی فرآیندهای خلاقیت، فناوری و فرصت‌های اقتصادی :

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

فصل اول
کلیات

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

نام کامل طرح و محل اجرای آن :
شرکت تولید کننده بازی های رایانه ای

مشخصات متقاضی :

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

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

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

 

بنا به اعتقاد فیرلی مدیریت ریسک دارای هفت فاز است:
۱) شناسایی فاکتورهای ریسک؛ ۲) تخمین احتمال رخداد ریسک و میزان تاثیر آن؛ ۳) ارائه راهکارهایی جهت تعدیل ریسک‌های شناسایی شده؛ ۴) نظارت بر فاکتورهای ریسک؛ ۵) ارائه یک طرح احتمالی؛ ۶) مدیریت بحران؛ ۷) احیا سازمان بعد از بحران.

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

موسسه مدیریت پروژه، در راهنمای خود در مورد کلیات دانش مدیریت پروژه (نسخه سال ۲۰۰۰)، برای فرایند مدیریت ریسک پروژه شش فاز را معرفی کرده‌است: ۱) برنامه ریزی مدیریت ریسک، ۲) شناسایی، ۳) تحلیل کیفی ریسک، ۴) تحلیل کمّی ریسک، ۵) برنامه ریزی پاسخ ریسک و ۶) نظارت و کنترل ریسک. کلیم و لودین، برای مدیریت ریسک یک فرایند چهار مرحله‌ای را معرفی کرده‌اند (شناسایی، تحلیل، کنترل و گزارش) که در موازات چهار قدم معروف دمینگ در مدیریت پروژه (برنامه ریزی، اجرا، بررسی و عمل) قرار می‌گیرند.

چاپمن و وارد، یک فرایند مدیریت ریسک پروژه کلی را ارائه کرده‌اند که از نه فاز تشکیل شده‌است:
۱) شناسایی جنبه‌های کلیدی پروژه؛ ۲) تمرکز بر یک رویکرد استراتژیک در مدیریت ریسک؛ ۳) شناسایی زمان بروز ریسک ها؛ ۴) تخمین ریسکها و بررسی روابط میان آنها؛ ۵) تخصیص مالکیت ریسکها و ارائه پاسخ مناسب؛ ۶) تخمین میزان عدم اطمینان؛ ۷) تخمین اهمیت رابطه میان ریسک¬های مختلف؛ ۸) طراحی پاسخها و نظارت بر وضعیت ریسک و ۹) کنترل مراحل اجرا.

کرزنر، مدیریت ریسک را به صورت فرایند مقابله با ریسک تعریف کرده و آن را شامل مراحل چهارگانه زیر می‌داند:
۱) برنامه ریزی ریسک، ۲) ارزیابی (شناسایی و تحلیل) ریسک، ۳) توسعه روشهای مقابله با ریسک و ۴) نظارت بر وضعیت ریسکها.

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

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

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

برای تخصیص مقادیر احتمالی به ریسک‌ها از مقادیر پیشنهادی زیر می‌توانید استفاده کنید :
قریب الوقوع = ۸۵
بالا = ۸۵
محتـــــمل = ۶۰
متوسط = ۵۰
ممــــــکن = ۴۰
پایین = ۱۵
غیرمحتـمل = ۱۵

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

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

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

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

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

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

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

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

مهندسی بازی و تولید بازیی با کیفیت بالا

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

در مهندسی بازی برای ساخت یک سیستم بازیی سه فرآیند مهم تاثیر گذار می باشند:
۱- فرآیند توسعه (Development Process): سازماندهی فعالیت ها است برای ساخت یک سیستم.
۲- فرآیند مدیریت (Management Process): انتخاب افراد، تجهیزات و فرآیند هاست برای توسعه یک سیستم و کنترل و نظارت بر روند اجرای پروژه .
۳- فرآیند پشتیبانی (Maintenance Process): کنترل و پشتیبانی بازی پس از تولید آن.

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

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

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

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

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

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

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

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

وضعیت و میزان اشتغال زایی :

میزان اشتغالزایی این طرح در ابتدای فعالیت ۱۰ نفر است و پیش بینی می شود که در طی ۳ ماه به ۲۰ نفر برسد .

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

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

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

ساختار استاندارد

استانداردهای مهندسی نرم‌‌افزار ESA به سه بخش اصلی تقسیم می‌‌شوند.

۱-بخش اول، استانداردهای محصولProducts :
استانداردها، توصیه‌‌ها، و رهنمودهای مربوط به محصول را شامل می‌‌شود.

۲- بخش دوم، استانداردهای رویه Procedure :
رویه‌‌های مورد استفاده در مدیریت یک پروژه نرم‌‌افزاری را تشریح می‌‌کند.

 

۳-بخش سوم، پیوست‌‌ها Appendices :
شامل خلاصه‌‌ها، جداول، فرمها، و فهرستی از روشهای ضروری می‌‌باشد.

سه گروه روش استاندارد در این مجموعه استفاده شده‌‌اند که عبارتند از :
الف- روشهای ضروری : در این روشها از عبارت “الزامی است” استفاده شده است. از این روشها باید بدون هیچ‌‌گونه استثنایی در کلیه پروژه‌‌های نرم‌‌افزاری پیروی شود.
ب- روشهای توصیه شده : در این روشها از عبارت “می‌‌بایست” استفاده شده است و به روشهای قویاً توصیه شده اشاره می‌‌کند. عدم پیروی از این روشها نیاز به توجیه مناسب دارد.
ج- رهنمودها : در این روشها از عبارت “ممکن است” یا “می‌‌توانند” استفاده شده است و به رهنمودها اشاره می‌‌کنند. عدم پیروی از رهنمودها، نیازی به توجیه ندارد.
استانداردهای مهندسی نرم‌‌افزار ESA ، کاربران را به استفاده از هیچیک از روش‌‌های ویژه مهندسی نرم‌‌افزار و یا ابزار نرم‌‌افزاری وادار نمی‌‌کنند، بلکه تنها روشهای ضروری توصیه شده و رهنمودها را برای پروژه‌‌های مهندسی نرم‌‌افزار تشریح کرده و به هر پروژه امکان می‌‌دهد که بهترین روش را جهت پیاده‌‌سازی انتخاب نماید.
در ادامه، توصیف خلاصه‌‌ای از استانداردهای مهندسی نرم‌‌افزار ESA ارائه می‌‌گردد. همانطور که ذکر گردید این استانداردها در دو بخش ارائه شده است : استانداردهای محصول و استانداردهای رویه که هر کدام به صورت اجمالی معرفی می‌‌گردد.
استانداردهای محصول
این بخش، کلیات چرخه حیات نرم‌‌افزار را تشریح می‌‌کند. در این استانداردها غالباً از عبارت “پروژه نرم‌‌افزاری” استفاده می‌‌شود. واضح است که تولید نرم‌‌افزار جنبه‌‌های سخت‌‌افزاری کامپیوتر را نیز در بر می‌‌گیرد. محصولات نرم‌‌افزاری لازم است با روش معینی طراحی و اجرا گردند. یک “مدل چرخه حیات”، فعالیتهای پروژه را در قالب مراحل مشخص سازماندهی می‌‌کند و تعیین می‌‌نماید کدام یک از فعالیتها باید در کدام مرحله انجام گیرد.

 

بر اساس این استاندارد شش مرحله بایستی در چرخه حیات یک نرم‌‌افزار طی شود که عبارتند از:
مرحله UR : تعیین نیازهای کاربر (User Requirements)
مرحله SR : تعیین نیازهای نرم‌‌افزار (Software Requirements)
مرحله AD : طراحی معماری (Architectural Design)

مرحله DD : طراحی تفصیلی و تولید برنامه (Detailed Design)
مرحله TR : انتقال و واگذاری نرم‌‌افزار برای بهره‌‌برداری (Transfer of the Software)
مرحله OM : بهره‌‌برداری و نگهداری (Operation & Maintenance)
چهار مرحله اول با یک بازبینی خاتمه می‌‌یابند. پنج مقطع کاری مهم، پیشرفت چرخه حیات نرم‌‌افزار را مشخص می‌‌نمایند که این مقاطع در شکل شماره ۱ به صورت مستطیل‌‌های کوچک مشخص شده‌‌اند و عبارتنداز :
• تصویب سند نیازهای کاربر (URD)
• تصویب سند نیازهای نرم‌‌افزار (SRD)

• تصویب سند طراحی معماری (ADD)
• تصویب سند طراحی تفصیلی (DDD)، راهنمای کاربر نرم‌‌افزار (SUM) ، اعلام آمادگی جهت پذیرش آزمونهای پذیرش موقت
• اعلام پذیرش موقت و تحویل سند انتقال نرم‌‌افزار (STD)
آخرین مرحله کاری، نه در پایان این مرحله، بلکه در پایان دوره تضمین، خاتمه می‌‌یابد. این مقاطع به‌‌عنوان حداقل مراحل لازم جهت یک ارتباط کاری که باید در کلیه پروژه‌‌ها ارائه گردند انتخاب شده‌‌اند. در ادامه، هر یک از مراحل شش‌‌گانه بطور مختصر شرح داده ‌‌می‌‌شود.

مرحله UR : تعیین نیازهای کاربر
مرحله UR را می‌‌توان “مرحله تعریف مسئله” چرخه حیات نامید. هدف این مرحله تدقیق یک فکر در مورد کاری که باید انجام گیرد در قالب تعریفی است از آنچه که از یک سیستم کامپیوتری انتظار می‌‌رود. نتیجه مرحله UR، سند نیازهای کاربر (URD) است. این سند برای کل پروژه نرم‌‌افزار سند مهمی به شمار می‌‌آید. زیرا مفاهیم اساسی که بر پایه آنها نرم‌‌افزار مورد پذیرش قرار می‌‌گیرد را تعریف می‌‌نماید.

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

ب- فعالیت‌‌ها
دریافت نیازهای کاربر
تعیین محیط عملیاتی
تشخیص نیازهای کاربر
بازبینی‌‌ها

ج-خروجی‌‌ها
سند نیازهای کاربر
طرح‌‌های آزمون پذیرش
طرح مدیریت پروژه برای مرحله SR (محدوده پروژه، برآورد هزینه و طرح مدیریت)
طرح مدیریت پیکربندی برای مرحله SR (روالهای مدیریت، ابزارهای CASE)
طرح وارسی و اعتبار سنجی برای مرحله SR
طرح تضمین کیفیت برای مرحله SR

مرحله SR : تعیین نیازهای نرم‌‌افزار
مرحله SR را می‌‌توان “مرحله تحلیل مسئله” چرخه حیات نامید. یک بخش ضروری در این مرحله، ساخت الگویی است که بیانگر آن باشد که نرم‌‌افزار چه کاری را باید انجام دهد، نه اینکه چگونه باید آنرا انجام دهد. در این حالت ممکن است ساخت نمونه‌‌های اولیه به منظور روشن نمودن نیازهای نرم‌‌افزار ضروری باشد.

الف- ورودی‌‌ها
تمامی خروجیهای مرحله قبل به عنوان ورودی در این مرحله استفاده می‌‌شوند.

ب- فعالیت‌‌ها
ساخت مدل منطقی
تشخیص نیازهای نرم‌‌افزار
بازبینی‌‌ها

ج-خروجی‌‌ها
سند نیازهای نرم‌‌افزار

طرح‌‌های آزمون سیستم
طرح مدیریت پروژه برای مرحله AD
طرح مدیریت پیکربندی برای مرحله AD
طرح وارسی و اعتبارسنجی برای مرحله AD
طرح تضمین کیفیت برای مرحله AD

مرحله AD : طراحی معماری
هدف مرحله طراحی معماری، تعیین ساختار نرم‌‌افزار است. الگوی ساخته شده در مرحله SR نقطه شروع این مرحله است. این الگو با تخصیص وظیفه‌‌مندی‌‌ها به مؤلفه‌‌های نرم‌‌افزار و تعیین گردش اطلاعات و عملیات بین آنها به طرح معماری نرم‌‌افزار تغییر می‌‌یابد. در این مرحله ممکن است طرح چندین بار تکرار شود. در واقع امکان استفاده از مدلهای مختلف آبشاری، افزایشی و ; در این مرحله وجود دارد. در این مرحله ممکن است نمونه‌‌سازی بخش‌‌های حساس نرم‌‌افزار جهت تأیید فرضیات طرح اصلی ضروری باشد.

الف- ورودی‌‌ها
کلیه خروجیهای مرحله SR

ب- فعالیت‌‌ها
ساختار مدل فیزیکی شامل ( تجزیه نرم‌‌افزار به مولفه ها ، پیاده‌‌سازی الزامات غیر وظیفه‌‌مندی، معیارهای کیفیت طرح ، بررسی مزیت‌‌های نسبی مابین طرحهای جایگزین)
ساختار مدل معماری شامل (تعیین وظیفه مؤلفه‌‌ها، تعیین ساختمان داده‌‌ها، تعیین میزان استفاده از منابع کامپیوتری ، انتخاب زبان برنامه‌‌نویسی، بازبینی طرح)
ج-خروجی‌‌ها
سند طراحی معماری

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

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

الف- ورودی‌‌ها
تمامی خروجیهای مرحله AD به عنوان ورودی استفاده می‌‌شود.

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

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

الف- ورودی‌‌ها
همه خروجیهای مرحله DD

ب- فعالیت‌‌ها
نصب
آزمونهای موقت

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

الف -ورودی‌‌ها
خروجیهای مرحله TR

ب- فعالیت‌‌ها
پذیرش نهایی
نگهداری

ج-خروجی‌‌ها
اعلامیه‌‌پذیرش نهایی
سند تاریخچه پروژه
سیستم نرم‌‌افزاری پذیرفته شده نهایی

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

۱- مدیریت پروژه نرم‌‌افزار
مدیریت پروژه نرم‌‌افزار (SPN: Software Project Management) “فرآیند طراحی، سازماندهی، تعیین کارکنان، نظارت، کنترل، رهبری و هدایت یک پروژه نرم‌‌افزاری” می‌‌باشد که در استاندارد ANSI/IEEE Std 1058.1-1987 تعریف شده است.
فعالیت‌‌ها
سازماندهی پروژه
رهبری پروژه
مدیریت ریسک
مدیریت فنی
برنامه‌‌ریزی، زمانبندی و بودجه‌‌بندی کار
گزارش پیشرفت پروژه
طرح مدیریت پروژه نرم‌‌افزار سندی است که مدیریت یک پروژه نرم‌‌افزاری را کنترل می‌‌کند و به چهار قسمت شامل طرحهای مدیریت مراحل SR ، AD ، DD و TR تقسیم می‌‌گردد که جزئیات مندرجات آن در استاندارد درج گردیده است.

۲- مدیریت پیکربندی نرم‌‌افزار
مدیریت پیکربندی نرم‌‌افزار عبارت است از نظام به‌‌کارگیری مسیر فنی و اجرایی و نظارت بر :
تعیین و مستندسازی مشخصات فیزیکی و وظیفه‌‌مندی یک عنصر پیکربندی
کنترل تغییرات حاصله در مشخصات مزبور
ثبت گزارش فرآیند تغییرات و وضعیت پیاده‌‌سازی
بررسی پذیرش محصول با توجه به نیازهای تعیین شده
تشخیص پیکربندی
ذخیره‌‌سازی عنصر پیکربندی
کنترل و نظارت بر تغییر پیکربندی
گزارش وضعیت پیکربندی
طرح مدیریت پیکربندی نرم‌‌افزار به چهار قسمت برای مراحل SR ، AD ، DD ، و TR تقسیم می‌‌شود

۳- وارسی و اعتبار سنجی نرم‌‌افزار
اصطلاح “وارسی” بسته به مفهومی که از آن انتظار می‌‌رود، دارای معانی متعددی است که سه معنای متداول آن عبارتند از :
عمل بازبینی، بازرسی، آزمون، بررسی، ممیزی و به عبارت دیگر تصدیق و مستندکردن آنکه آیا عناصر فرآیندها، خدمات یا مستندات منطبق با نیازهای تعیین شده هستند یا خیر.
فرآیند ارزیابی یک سیستم یا یک مؤلفه به منظور تعیین آنکه آیا محصولات یک مرحله تولید مشخص ، شرایط وضع شده آغازین آن مرحله را ارضا می‌‌نمایند یا خیر
اثبات رسمی صحت برنامه
اعتبارسنجی نیز بنا بر تعریف ANSI/IEEE عبارت است از “ارزیابی نرم‌‌افزار در پایان تولید به منظور حصول اطمینان از رعایت نیازهای کاربر” . بنابراین اعتبارسنجی، وارسی نهایی است.
فعالیت‌‌ها
بازبینی‌‌ها و بررسی‌‌های فنی و بازرسی‌‌های نرم‌‌افزار
بررسی اینکه نیازهای نرم‌‌افزار متناسب با خواسته‌‌های کاربر قابل ردیابی هستند
بررسی اینکه مؤلفه‌‌های طراحی متناسب با نیازهای نرم‌‌افزار قابل ردیابی هستند
بررسی تأییدیه‌‌های رسمی و الگوریتم‌‌ها
آزمون واحدها
آزمون یکپارچگی
آزمون سیستم
آزمون پذیرش
ممیزی
طرح وارسی و اعتبار سنجی نرم‌‌افزار در هفت بخش که شامل برنامه‌‌های وارسی برای مراحل SR ، AD ، DD و شرح مشخصات آزمون‌‌های واحد، یکپارچگی، سیستم و پذیرش می‌‌باشند تقسیم می‌‌گردد.