مجموعه مباحث مهندسی نرم افزار 1

[Y@SiN]

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

تهیه و تنظیم : Y@SiN
باشگاه دانشجويان پيام نور

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

[Y@SiN]

بخش اول : مقدمه ای بر مهندسی نرم افزار

فهرست :
بحران نرم افزار
مفهوم مهندسی
تعريف مهندسی نرم افزار
ماهيت نرم افزار و تفاوت مهندسی نرم افزار با ساير رشته های مهندسی
کاربردهای نرم افزار
اهميت مهندسی نرم افزار
ارکان مهندسی نرم افزار
تعريف متدلوژی نرم افزاری

[Y@SiN]

بحران نرم افزار:

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


تفاوت مهندس و محقق علوم:

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

تعريف مهندسی نرم افزار:

تعريف مهندسی نرم افزار از ديد پارناس (Parnas) :
کار چند نفره برای توليد چند نسخه (version) از برنامه
تعريف پارناس به علت قديمی بودن مهندسی نرم افزار را با برنامه سازی يکی می داند.
تعريف مهندسی نرم افزار بنا بر پيشنهاد انجمن IEEE :
مهندسی نرم افزار عبارت است از بکارگيری يک روش سيستماتيک، منظم و قابل اندازه گيری برای توليد و توسعه ، عملياتی کردن و نگهداری نرم افزار . به عبارت ديگر بکارگيری اصول مهندسی در توليد نرم افزار.

تعريف مهندسی نرم افزار (از نگاهی ديگر) :
شامل مجموعه ای از تکنيکها و قواعد معتبر مهندسی بمنظور توليد نرم افزار قابل اطمينان و مقرون بصرفه.

-------------------------------------------------------------------------------------------------------------------------------------------------
ماهيت نرم افزار

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

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

[Y@SiN]

کاربردهای نرم افزار

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

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

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

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

[Y@SiN]

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

متدولوژی:

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

انتظار از متدولوژی:

بازشناسی : دريافت و توصيف نيازمنديها

بازنمايي : قدرت بيان و تشريح (notation)

گذر : دارای تکنيک و دستورالعمل برای گذر از يک مرحله به مرحله ديگر باشد.

[Y@SiN]

فرايند ( Process ):

فهرست:
فرايند
ابزار
فعاليتهای مهندسی نرم افزار
مدل های فرايند

[Y@SiN]

فرايند:

فرايند نرم افزار نقشه راهی (Road Map) است که دو هدف زير را دنبال می نمايد:
کيفيت بالا
زمانبندی مناسب
لايه های مهندسی نرم افزار



اساس مهندسی نرم افزار لايه فرايند می باشد.

فرايند چارچوبی برای مجموعه ای از KPA ها(Key Process Area )ايجاد می نمايد.

KPA :
ايجاد پايه ای جهت کنترل مديريتی پروژه های نرم افزاری
ايجاد بستری جهت انجام روشهای فنی ، توليد محصولات کاری (مدلها، مستندات ، گزارشها ، فرمها ، داده ها و غيره) ، مشخص نمودن مراحل ، حصول اطمينان از کيفيت و مديريت خوب تغييرات

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

ابزار:

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

فعاليتهای مهندسی نرم افزار:

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

[Y@SiN]

مدل فرايند:

تعيين يک راهکار توسعه که شامل لايه های فرايند ، روشها ، ابزار و فازها ( تعريف ، توسعه و پشتيبانی) باشد را الگوی مهندسی نرم افزار يا مدل فرايند می نامند.
مدلهای فرايند نرم افزار عبارتند از :
مدل ترتيبی خطی
مدل ايجاد نمونه اوليه (Prototyping Model)
مدل RAD
مدل افزايشی (Incremental Model)
مدل حلزونی(Spiral Model)
مدل حلزونی برنده - برنده (Win-Win)
مدل توسعه همزمان
مدل توسعه مبتنی بر مولفه ( Component Base Development)
مدل روشهای رسمی (Formal Method)
تکنيکهای نسل چهارم

مدل ترتيبی خطی(مدل آبشاری ، چرخه حيات کلاسيک):

طراحی نرم افزار بر روی چهار مورد زير تمرکز می نمايد :
ساختمان داده ها
معماری نرم افزار
نمايش واسط ها
الگوريتم ها
معايب روش

مدل ساخت نمونه اوليه:

[Y@SiN]

مدل RAD:

مدل توسعه کاربردی سريع (Rapid Application Development) يک فرايند توسعه تدريجی نرم افزار می باشد که بر ساخت مبتنی بر مولفه تاکيد می نمايد .
فازهای مدل مذکور عبارتند از:
مدلسازی کاری
مدلسازی داده ای
مدلسازی فرايند
توليد برنامه کاربردی
آزمايش
چنانچه بتوان سيستم را به چند زير سيستم تقسيم نمود به گونه ای که توسعه هر زير سيستم حداکثر ظرف مدت سه ماه به اتمام برسد ، می توان هر زير سيستم را به يک تيم RAD سپرد و در انتها تمام زير سيستمها را يکپارچه نمود.



مدل افزايشی:
ترکيب مدل خطی و مدل ساخت نمونه اوليه
در انتهاي هر ترتيب خطی يک محصول از نرم افزار ارائه می گردد.اولين محصول با نام محصول هسته ای (Core Product) به نيازمنديهای پايه ای پرداخته و پس از بازنگری توسط کاربر اصلاح و بهينه می گردد.



مدل حلزونی(Spiral Model):



نسخه اوليه از محصول در اين مدل نسخه ساده ای می باشد که در تکرارهای بعدی کامل می گردد. در اين مدل فعاليتها به شش دسته تقسيم می گرددکه هر کدام از آنها را با نام نواحی کاری(Work Area) می شناسند :
تعامل با مشتری و تعريف نيازمنديها : تعيين خواسته ها از جانب مشتری
برنامه ريزی (Planning) : تعيين اهداف ، آلترناتيوها و محدوديتها
تعيين منابع و ايجاد زمانبندی
آناليز ريسک : تحليل آلترناتيوها ، شناسائی ريسکها و راهکارهای مقابله با آنها
مهندسی (Engineering) : توسعه محصول سطح بعدی
ساخت و ارائه : ساخت ،آزمايش و انتقال ( تحويل مستندات ، آموزش و ...)
ارزيابی مشتری ( Customer Evaluation) : ارزيابی نتايج مهندسی

در تمامی مراحل فوق فعاليتهای چتری نيز به موازات اجرا می گردند.



مدل حلزونی برنده برنده(Win-Win):
در بخش تعامل با مشتری نيازمنديها از سوی مشتری می بايست مشخص شوند .جهت اين موضوع لازم است مشتری به يک موازنه (trade off) بين نيازمنديهای خود و تيم توسعه برسد. به عبارت ديگر موازنه ای بين عملکرد ، قابليتهای سيستم و کارائی از طرفی و هزينه و زمان از سوی ديگر برقرار نمايد. در اين شرايط تلاش می گردد اکثر نيازمنديهای مشتری در مقابل زمان و قيمت مناسب جهت تيم توسعه دهنده نرم افزار فراهم گردد(برد-برد). در مدل مذکور به جای بخش تعامل با مشتری و تعيين نيازمنديها قسمتهای زير جايگزين می گردد:
شناسائی واگذارنده و تعيين شرايط برد او
مذاکره جهت حصول به توافق ( در راستای قاعده برد – برد)

[Y@SiN]

مدل توسعه همزمان (مهندسی همزمانی):

در اين مدل هر فعاليت دارای چندين حالت می باشد که با تعريف مجموعه ای از رخدادها شاهد گذار از حالتی به حالت ديگر خواهيم بود. به بيان ديگر تمامی فعاليتها بصورت همزمان وجود دارند ليکن در حالتهای متفاوتی قرار می گيرند.

به عنوان مثال بعد از اتمام فعاليت تعامل با کاربر اين فعاليت در حالت هيچ(none) رفته و فعاليت تحليل از حالت هيچ به حالت توسعه وارد می گردد و حالتهای بعدی خود را طی می نمايد. چنانچه کاربر احتياج به انجام تغييرات در نيازمنديهای خود داشته باشد فعاليت تحليل به حالت انتظار می رود.

مدل توسعه مبتنی بر مولفه ( Component Base Development):

اين مدل بر اساس الگوی شیء گرائی استوار است.

الگوی شیء گرائی بر روی مفهومی به نام کلاس که تلفيقی از ساختمان داده و الگوريتم است تاکيد می نمايد.

مدل مذکور بصورت تکاملی بوده و اغلب ويژگيهای مدل حلزونی را شامل می گردد . ليکن در اين مدل ساخت سيستم بر مبنای مولفه ها (بعنوان مثال کلاس) شکل می گيرد .

اين مدل قابليت استفاده مجدد از نرم افزار را افزايش می دهد.

انجمن QSM associates در گزارشی ضمن تاکيد بر قابليت استفاده مجدد از نرم افزار برخی از مزايای آن را به شرح زير بيان می نمايد:
مونتاژ مولفه ها :
باعث کاهش 70 درصدی زمان توسعه سيستم می گردد .
موجب کاهش 48 درصدی هزينه های توليد سيستم می گردد.
سبب افزايش ضريب بهره وری می گردد.


فرايند توسعه نرم افزار يکنواخت (Unified Software Development Process) بعنوان نماينده مدلهای CBD پيشنهاد گرديده است.

این تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 768x386

مدل روشهای رسمی (Formal Method):

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

تکنيکهای نسل چهارم:

محور اصلی اين روش استفاده از ابزارهای مهندسی نرم افزار است. مهندس نرم افزار يک مشخصه از نرم افزار را در سطح بالا تعريف نموده (معمولا با استفاده از نمادها و مدلها) سپس اين ابزار کد لازم را توليد می نمايند.
با تلفيق اين تکنيک و روش ” توسعه مبتنی بر مولفه“ می توان به توانائی بالائی جهت توسعه نرم افزار دست يافت.