چرخه حيات نرم افزار

كليه پروژه هاي نرم افزاري الزامي است داراي يك رهيافت چرخه حيات باشند:

• مرحله UR - بيان نيازهاي كاربر User Requirements

• مرحله SR - بيان نيازهاي نرم افزار Software Requirements

• مرحله AD - طراحي معماري Architectural Design

• مرحله DD - طراحي تفصيلي و توليد برنامه Detailed Design

• مرحله TR - انتقال و واگذاري نرم افزار براي بهره برداري Transfer of the software

• مرحله OM - بهره برداري و نگهداري Operations & Maintenance

چهار مرحله اول با يك بازبيني كه بوسيله نشانه “R/” نمايش داده شده است خاتمه مي يابند (به عنوان مثال UR/R بازبيني نيازهاي كاربر است). خواه پروژه توسط كاركنان داخلي و يا از طريق شركتها و پيمانكاران صنعت
نرم افزار انجام شود، اين مراحل با توجه به اندازه، كاربرد (مثلا علمي،‌اداري، بلادرنگ، دسته اي)، سخت افزار، سيستم عامل يا زبان برنامه نويسي استفاده شده انجام مي پذيرند، هر چند كه هر يك از اين عوامل رهيافت توليد، شيوه ومحتوي اقلام تحويل دادني را تحت تاثير قرار مي دهند.

تعيين نيازهاي كاربر - مرحله UR

• مرحله UR مرحله تعريف مسئله در يك پروژه نرم افزاري است.

• دامنه و وسعت سيستم بايد مشخص گردد.

• نيازهاي كاربر بايد تعيين گردد. اين امر مي تواند بوسيله مصاحبه، بازديد و بررسي و يا ساخت نمونه هاي اوليه صورت پذيرد.

• خواسته هاي مشخص كاربر بايد تعيين شده و در سند نيازهاي كاربر (URD) نوشته شوند.

ميزان درگيري توليدكنندگان نرم افزار در اين مرحله بستگي به آشنايي كاربر با نرم افزار دارد. بعضي از كاربران مي توانند URD مطلوب و با كيفيت بالا تهيه نمايند در حاليكه ديگر كاربران ممكن است نيازمند كمك توليدكنندگان باشند.

URD هميشه بايد تهيه شود.

• بازبيني URD توسط كاربران، مهندسين نرم افزار و سخت افزار و مديران ذيربط صورت مي پذيرد.

• URD تصويب شده ورودي مرحله بعد (SR) مي باشد.

E پيش از تكميل بازبيني نيازهاي كاربر (UR/R) طرح مديريت پروژه نرم افزار حاوي رئوس مطالب كل پروژه بايد بوسيله توليد كننده نرم افزار تهيه شود. أين طرح بايد شامل برآورد هزينه پروژه باشد. همچنين طرحهاي تفصيلي تر براي مرحله تعيين نيازهاي نرم افزار نيز بايد تهيه شوند.

تعيين نيازهاي نرم افزار - مرحله SR

• مرحله SR مرحله تحليل پروژه نرم افزاري است.

• يك بخش ضروري فعاليت تحليل، ساخت ” الگويي” است كه بيانگر آن باشد كه نرم افزار چه كاري را بايد انجام دهد،‌نه اينكه چگونه بايد آن را انجام دهد. در اين حالت ممكن است ساخت نمونه هاي اوليه به منظور روشن نمودن نيازهاي نرم افزار ضروري باشد.

E تحويل دادني اصلي در اين مرحله سند نيازهاي نرم افزار (SRD) است . SRD هميشه بايد برا ي هر پروژه نرم افزاري توليد گردد. اصطلاحات پياده سازي مي بايست از SRD حذف شود. أين سند بايد رسما” توسط كاربر، مهندسين نرم افزار و سخت افزار كامپيوتر و مديران ذيربط در حين بازبيني نيازهاي نرم افزار (SR/R) مورد بررسي قرار گيرد.

• در طول مرحله SR در قسمت طرح مديريت پروژه نرم افزار، رئوس مطالب باقيمانده پروژه بايد بروز آورده شود.

• طرح بايد شامل برآورد مجموع هزينه هاي پروژه باشد. همچنين طرحهاي تفصيلي تر براي مرحله طراحي معماري نيز بايد تهيه شود.

طراحي معماري - مرحله AD

• هدف مرحله طراحي معماري (AD) تعيين ساختار نرم افزار است.

• الگوي ساخته شده در مرحله SR نقطه شروع اين مرحله است. اين ا لگو با تخصيص كاركردها به مولفه هاي نرم افزار و تعيين گردش اطلاعات و عمليات بين آنها به طرح معماري نرم افزار تغيير مي يابد.

• در اين مرحله ممكن است طرح چندين بار تكرار شود. مشكلات تكنيكي و يا قسمتهاي بحراني و حساس طرح بايد مشخص گردد. ممكن است نمونه سازي بخشهاي حساس نرم افزار جهت تائيد فرضيات طرح اصلي ضروري باشد. در اين مرحله طرحهاي جانشين نيز مي توان در نظر گرفت كه نهايتا”‌يكي از آنها بايد انتخاب شود.

Eعنصر تحويل دادني كه خروجي اصلي اين مرحله به شمار مي آيد، سند طراحي معماري (ADD) است. ADD همواره بايد براي هر پروژه نرم افزاري توليد گردد. ADD بايد رسما” بوسيله مهندسين نرم افزار و سخت افزار كامپروتر، كاربران و مديران ذيربط در حين بازبيني طرح معماري (AD/R) مورد بررسي قرار گيرد.

· در طول مرحله AD طرح مديريت پروژه نرم افزار حاوي رئوس مطالب باقيمانده بايد تهيه شود. اين طرح بايد شامل برآورد هزينه پروژه (حداكثر 10% خطا بسيار مطلوب است) باشد. همچنين طرحهاي جزئي تر براي مرحله طراحي تفصيلي ( DD ) نيز مي بايد تهيه شود.

طراحي تفصيلي و توليد - مرحله DD

• هدف اين مرحله طراحي تفصيلي نرم افزار، برنامه نويسي، مستندسازي و آزمون آن است.

• سند طراحي تفصيلي ( DDD: Detailed Design Document ) و راهنماي كاربر نرم افزار ( SUM: Software User Manual ) همزمان با برنامه نويسي و آزمون آن توليد مي شود. در آغاز DDD و SUM بخشهاي متناظر با سطوح فوقاني سيستم را در بر مي گيرند. در پايان اين مرحله، مستندات تكميل مي شوند و به همراه برنامه ها عناصر تحويل دادني اين مرحله را تشكيل مي دهند.

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

E سه عنصر تحويل دادني (برنامه، DDD و SUM) كه مستلزم بازريني هاي مرحله أي در طول مرحله DD مي باشند بايد رسما” توسط مهندسين نرم افزار و مديرت ذيربط در حين بازبيني طرح تفصيلي (DD/R) مورد بررسي قرار گيرد. در پايان فرآيند بازبيني، نرم افزار جهت آزمونهاي پذيرش موقت آماده است.

انتقال - مرحله TR

• هدف اين مرحله تائيد آن است كه نرم افزار كليه خواسته هاي كاربر را كه در سند نيازهاي كاربر (URD) مطرح و تنظيم گرديده اند، برآورد مي نمايد. اين امر بوسيله نصب نرم افزار و اجراي آزمون پذيرش انجام
مي شود.

• زماني كه نرم افزار جهت ارائه قابليتهاي مورد نياز نمايش داده مي شود،‌نرم افزار مي تواند موقتا” مورد پذيرش قرار گرفته و بهره برداري از آن آغاز شود.

Eسند انتقال نرم افزار (STD) بايد به منظور مستند ساختن انتقال نرم افزار به گروه بهره برداري در حين مرحله TR تنظيم شود.

بهره برداري و نگهداري - مرحله OM

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

• هنگامي كه نرم افزار كليه آزمونهاي پذيرش را با موفقيت گذراند، مي تواند مورد پذيرش نهايي قرار گيرد.

E سند تاريخچه پروژه ( PHD: Project History Document ،) اطلاعات مديريتي مهم جمع آوري شده در طول جريان پروژه را خلاصه مي نمايد.اين سند بايد پس از پذيرش نهايي صادر شود. اين سند مي بايست در پايان چرخه حيات، به همراه ساير اطلاعات گردآوري شده در مرحله بهره برداري و نگهداري مجددا” منتشر و اعلام گردد.

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

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

روشهاي چرخه حيات
روش آبشاري

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

تحويل سيستم كامل تنها در يك مقطع مهم در پايان مرحله TR انجام مي پذيرد. اين روش امكان ساده شدن ارتباطات قراردادي و پيمان هاي منعقد شده را فراهم مي آورد.

روشهاي چرخه حياتروش تحويل افزايشي

روشهاي چرخه حيات روش تحويل افزايشي

· يكي از معايب روش تحويل افزايشي انجام آزمون بازگشتي جهت حصول اطمينان از قابليت هاي موجود نرم افزار در هر يك از نسخه هاي جديد است. افزايش تعداد آزمون هاي لازم موجب افزايش هزينه نرم افزار مي گردد.

روشهاي چرخه حياتروش توليد تكاملي

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

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

روشهاي چرخه حيات روش توليد تكاملي

دلايل استفاده از روش توليد تكاملي از اين قبيل است:

· تجربه كاربران جهت پالايش و تكميل خواسته ها لازم است (اين امر توسط خطوط خط چين درون چارچوب هاي OM نشان داده شده است)

· بخش هايي از پياده سازي ممكن است به دسترس بودن تكنولوژي آينده بستگي دادشه باشد.

· بعضي از خواسته هاي كاربر پيش بيني شده اند اما هنوز دقيقا” شناخته شده نيستند.

· برخي از خواسته ها در مقايسه با سايرين ممكن است دشوارتر باشند، در چنين حالتي نباشد اجازه داد كه آنها موجب تاخير در تحويل يك نسخه قابل استفاده شوند.

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

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

چرخه حيات نرم افزارساخت نمونه اوليه

• نمونه اوليه سازي، فرآيند ساخت اولين نمونه است.

• ساخت نمونه اوليه در يك مرحله مفيد است و موجب كاهش خطر در يك پروژه با استفاده از تجربه هاي عملي مي شود.

• نتيجه نهايي ساخت نمونه اوليه نرم افزار، دانشي است كه از پياده سازي و يا استفاده از آن حاصل مي گردد.

• پيس از آغاز فرايند ساخت نمونه اوليه مي بايست هدف اين فعاليت به وضوح مشخص گردد.

• ساخت نمونه اوليه جهت تعيين خواسته ها را نمونه سازي اكتشافي مي گويند و تحقيق در مورد عملي بودن راه حل پيشنهادي را نمونه سازي تجربي مي نامند.

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

چرخه حيات نرم افزاربررسي تغيير خواسته ها

• سند نيازهاي كاربر (URD) و سند نيازهاي نرم افزار (SRD) بايد سندهاي كاملي باشند. اين بدان معني است كه كليه احتياجات شناخته شده بايد هنگام توليد اين اسناد در آنها گنجانده شوند. با اين وجود،‌امكان بروز خواسته هاي جديد پس از تصويب URD و SRD نيز هست. در نتيجه روال هاي سازماندهي احتياجات جديد نيز
مي بايست از ابتداي پروژه در نظر گرفته شود.

•يكپارچگي طرح هنگامي كه خواسته هاي جديد عنوان مي شوند نمي بايست به مخاطره بيافتد.

روال هاي لازم جهت بررسي نيازهاي جديد كاربر:

• توليد پيش نويس جديد براي سند نيازهاي كاربر

• بازبيني نيازهاي كاربر و در صورت قبول تغييرات انجام گام هاي بعدي

• تكرار مراحل AD , SR و DD جهت درج نيازهاي جديد و اثرات آنها

چرخه حيات نرم افزاربررسي تغيير خواسته ها

-كيفيت كاري را كه در مراحل تعيين نيازهاي كاربر و نيازهاي نرم افزار انجام مي شود مي توان به وسيله تعداد خواسته هايي كه در مراحل بعد پديدمي آيند سنجيد . نكته بسيار مهم تناوب تمايل به خواسته هاي جديد است. تمايل روز افزون به خواسته هاي جديد نشانه حتمي عدم موفقيت نرم افزار است.

- هنگامي كه نهايي كردن خواسته ها امكان پذير نيست، جهت جلوگيري از تاخيرات جدي، استفاده از ابزار مهندسي نرم افزار كه خواسته هاي جديد را مجاز مي شمارند و تغييرات را به سرعت شبيه سازي و طراحي مي نمايند ضروري است.

چرخه حيات نرم افزار

مطالب مشابه :

دانلود پروژه مهندسی نرم افزار 2

نمونه سوال مهندسی نرم افزار2

فرایند نرم افزار و معیارهای پروژه

نمونه سوال مهندسی نرم افزار2

مجموعه کتاب های مورد نیاز رشته مهندسی صنایع

نمونه سوال مهندسی نرم افزار2

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

بررسي و شناخت متدولوژي RUP

چرخه حيات نرم افزار