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

بخشی از مقاله

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

فصل اول
کلیات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

میزان اشتغالزایی این طرح در ابتدای فعالیت 10 نفر است و پیش بینی می شود که در طی 3 ماه به 20 نفر برسد .

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

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

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

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

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

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

2- بخش دوم، استانداردهاي رويه Procedure :
رويه‌‌هاي مورد استفاده در مديريت يك پروژه نرم‌‌افزاري را تشريح مي‌‌كند.

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

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

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

مرحله DD : طراحي تفصيلي و توليد برنامه (Detailed Design)
مرحله TR : انتقال و واگذاري نرم‌‌افزار براي بهره‌‌برداري (Transfer of the Software)
مرحله OM : بهره‌‌برداري و نگهداري (Operation & Maintenance)
چهار مرحله اول با يك بازبيني خاتمه مي‌‌يابند. پنج مقطع كاري مهم، پيشرفت چرخه حيات نرم‌‌افزار را مشخص مي‌‌نمايند كه اين مقاطع در شكل شماره 1 به صورت مستطيل‌‌هاي كوچك مشخص شده‌‌اند و عبارتنداز :
• تصويب سند نيازهاي كاربر (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

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

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

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

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

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

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