بنام آنکه جان را فکرت آموخت

Presentazione sul tema: "بنام آنکه جان را فکرت آموخت"— Transcript della presentazione:

1 بنام آنکه جان را فکرت آموخت
مهندسی نرم افزار منابع: یان سامرویل پرسمن دکتر محمدرضا ملاحسینی دکتر مهسا رضایی تهیه کننده: محسن نصیری

2 فصل 1

3 تعريف فنّاوري اطلاعات فناوری اطلاعات، ترکيبی از فناوری های کامپيوتری (سخت افزار و نرم افزار) و فناوری ارتباطات می باشد.

4 شغل‌های برتر 1- طراحی نرم‌افزار 2- طراحی بازی‌های کامپیوتری
از نگاه سی‌.ان‌.ان در آمریکا:  1- طراحی نرم‌افزار 2- طراحی بازی‌های کامپیوتری 3- واسطه‌گری منابع نفتی 4- مشاوره ثبت اختراع 5- مدیریت بیمارستان 6- مدیریت بهبود روش‌ها 7-پرستاری کلینیک 8- توسعه پایگاه داده‌ها 9- تحلیلگر امنیت اطلاعات

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

6 نرم افزار سخت افزار: هر چیز قابل لمس در کامپیوتر را گویند
نرم افزار: هر چیز غیر قابل لمس در کامپیوتر را گویند نرم افزار، مجموعه ای از برنامه های رایانه ای، رویه ها و مستندات است که انجام کارهای مختلف بر روی یک سیستم رایانه ای را بر عهده دارد.

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

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

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

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

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

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

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

14 مفاهيم مقدماتي سيستم: مجموعه‌اي از اجزا كه براي تبديل وروديها به خروجيهاي قابل استفاده با هم همكاري ميكنند. زيرسيستم: جزيي از يك سيستم كه خود تمام اجزاي مربوطه به سيستم را دارد. سيستم مبتني بر كامپيوتر: سيستمي‌ است كه در آن كامپيوتر به عنوان جزيي از سيستم است.

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

16 ابزار (Tools): ابزارها معمولا انواع نمودارها و نيز برنامه‌هاي كامپيوتري مي‌باشند كه استفاده از تكنيكها را براي ما آسان مي‌كنند و به ما اجازه مي‌دهند كه به صورت بهتري از دستورات و راهنماييهاي ارايه شده در متدولوژي پيروي كنيم.

17 چند واژه ديگر Data حقايق خامي‌كه افراد، اشياء و رخدادها دريك سازمان را توصيف مي‌كنند. Information اطلاعات يا داده پردازش شده Data Flow يك گروه از داده‌ها است كه در داخل يك سيستم جريان دارد و شامل يك توصيف از مبداء و مقصد هركدام از داده ها است.

18 میان افزار چیست؟ اولین نرم افزار مرتبط با سخت افزار، میان افزار است.
 اولین نرم افزار مرتبط با سخت افزار، میان افزار است. میان افزارها را در کارگاه یا کارخانه به وسیله دستگاه هایی به نام Emulator در حافظه های قابل برنامه ریزی و فقط خواندنی موسوم به ROM قرار می دهند. در واقع این حافظه ها را برنامه ریزی می کنند. یک نمونه از انواع این حافظه ها همان بایوس کامپیوتر است

19 انواع روش های برنامه نویسی رایج
تاریخچه نرم افزار انواع روش های برنامه نویسی رایج برنامه نویسی منفرد برنامه نویسی تیمی ایدا لاولیس، نخستین برنامه‌نویس رایانه بوده است

20 مشکلات برنامه نویسی منفرد:
طولانی شدن زمان پروژه افزایش هزینه ها مشکل خطایابی مشکل در ارزیابی میزان پیشرفت

21 فرهنگ کار تیمی یکی از مهمترین کارهایی که باید یک مهندس نرم افزار یاد بگیرد، کار کردن با تیم می باشد.

22 برخي اصول اساسي كار تيمي:
1. داشتن روحيه همكاري ( هم‌افزايي - سينرژي) 2. انعطاف‌پذيري (هدف دست‌يابي به سازگاري گروهي براي تعامل سازنده ميان گروهي است) 3. تعهد و پايبندي به گروه ( تعهد به كار و تيم كاري، ارتباط با استعداد و هوش افراد ندارد، اگر چه سطح دانش و آگاهي‌هاي اعضا، سطح تعهد را بالا و بالاتر مي‌برد) 4. شايستگي و فرهيختگي (شايستگي اكتسابي است، اما بر مبناي استعدادها و قابليت‌هاي افراد، پايه‌ريزي مي‌شود) 5. هدفمندي 6. نظم 7. سخت‌كوشي

23

24

25 دو نوع محصول نرم افزاري:
1 - محصولات کلی: سیستم هاي مستقلی اند که توسط یک سازمان تولید کننده ، تولید می شوند و به بازار عرضه می گردند و مشتریان می توانند برحسب نیاز آنها را تهیه کنند. نظیر: بانکهاي اطلاعاتی ، واژه پردازها ، پکیج هاي طراحی و ابزارهاي مدیریت پروژه و... 2 - محصولات سفارشی: سیستم هایی اند که توسط مشتري خاصی سفارش داده می شوند. این محصولات توسط پیمانکاران نرم افزار براي آن مشتري ایجاد می شوند. نظیر: سیستم هاي کنترلی دستگاههاي الکترونیکی ، سیستم هاي کنترل فرآیند تجاري و ...

26 لغت نامه مهندسی! 1- اين بستگي دارد به يعني: جواب سئوال شما را نمي‌دانم! 2- اين موضوع پس از روزها تحقيق و بررسي فهميده شد. يعني: اين موضوع را به طور تصادفي فهميدم! 3- نحوه عمل دستگاه بسيار جالب است. يعني: دستگاه كار مي‌كند و اين براي ما تعجب‌برانگيز است! 4- ما تصحيحاتي روي سيستم انجام داديم تا آن را ارتقاء دهيم. يعني: تمام طراحي ما اشتباه بوده و ما از اول شروع كرده‌ايم! 5- ما پيشگويي مي‌كنيم يعني: 90 درصد احتمال خطا مي‌رود!

27 6- كل كوشش ما براي اين است كه مشتري راضي شود
6- كل كوشش ما براي اين است كه مشتري راضي شود. يعني: آنقدر از زمانبندي عقبيم كه هر چه به مشتري بدهيم راضي مي‌شود! 7- به علت اهميت تئوري و عملي اين موضوع يعني: به علت علاقه من به اين موضوع! 8- بقيه نتايج در گزارش بعدي ارائه مي‌شود. يعني: بقيه نتايج را تا فشار نياوريد نخواهيم داد! 9- ثابت شده كه يعني: من فكر مي‌كنم كه . . .! 10- اين صحبت شما تا اندازه‌اي صحيح است. يعني: از نظر من صحبت شما مطلقاً غلط است! 11- در اين مورد طبق استاندارد عمل خواهيم كرد. يعني: از جزئيات كار اصلاً اطلاع نداريم!

28 جوان بودن علم كامپيوتر (مقايسه‌ي وضعيت قديم با امروز)
كاربرد‌هاي اوليه: كاربرد‌هاي فعلي: - برنامه‌هاي كوچك - برنامه‌هاي خيلي بزرگ - انجام سريع كل كار توسط يك نفر - انجام كار توسط تيم در زمان طولاني - كاربرد برنامه توسط ايجاد كننده (متخصص) - كاربر غير از ايجادكننده (هردوغير متخصص) - برنامه‌ها براي حل مسائل تكنيكي - كاربرد‌هاي متنوع در زندگي روزمره - ورودي‌ها و خروجي‌ها كلاً عددي - تنوع داده‌هاي ورودي و خروجي - ورودي روي كارت، خروجي روي كاغذ - تنوع وسايل ورودي و خروجي - اجراي off-line برنامه‌ها - اجراي محاوره‌اي - استفاده از دامپ و كنسول براي خطايابي - روش‌هاي اتوماتيك خطايابي Dump برنامه‌ای در سیستم‌عاملهای یونیکس است که برای تهیه نسخه پشتیبان از سیستم فایلها استفاده می‌شود.

29 بررسی وسعت كار ساخت نرم‌افزارهاي امروزي
مثال: 2 ميليون خط اسمبلي سيستم KLM 3/7 ميليون خط كد سيستم عامل UNIX 5000 نفر- سال براي توليد OS360 11 میلیون خط (200 برنامه نویس ) ویندوز 95 50 میلیون خط ( 2000 برنامه نویس) ویندوز ویستا ۴۰ میلیون خط - ویندوز 7  بیشتر شدن کدها در یک برنامه، همیشه به معنی پیچیده‌تر شدن و یا بهتر شدن آن نیست

30 ...... پيشرفت همچنان ادامه داشت!
- عدم آشنايي برنامه نويس با زمينه‌ي كار (استفاده از روش آزمايش و خطا) - افزودن بي‌رويه‌ي نيروي برنامه‌نويس براي پيشبرد پروژه در نتيجه: - عدم تحويل به‌موقع نرم‌افزار - عدم برآورده‌كردن خواسته‌هاي كاربر - عدم امكان اصلاح و تطبيق برنامه‌ها با شرايط - خطا‌هاي زياد بلافاصله پس از تحويل حاصل كار: اعلام اصطلاح ‹بحران نرم‌افزار› براي اين وضعيت

31 - علائم بحران : 1 - هزینه هاي هنگفت تولید نرم افزار
چرا مهندسی نرم افزار ؟ بحران نرم افزار و نظریۀ مهندسی نرم افزار اولین بار در کنفرانسهای (سال 1968 و 1969 ) بصورت جدی مطرح شد. - علائم بحران : 1 - هزینه هاي هنگفت تولید نرم افزار 2 - تاخیر در تولید و تحویل نرم افزار 3 - نگهداري پرهزینۀ نرم افزار 4 - عدم بهره گیري از قدرت سخت افزار 5 - کیفیت پایین و نامطمئن نرم افزارهاي تولید شده 6 - عدم تامین نیازمندیهاي کاربر 7 - ناتوانی روشهاي تولید نرم افزار در پاسخگویی به افزایش تقاضا 8 - افزایش پیچیدگی کاربردها

32 تولد ‹مهندسي نرم‌افزار› با دورنماي زير:
ساختن نرم‌افزار طبق اصول مهندسي مانند ساير رشته‌ها: مطالعات تئوريك، تحليل ، طراحي بر مبناي اصول علمي، پياده سازي مقايسه با ساختن يك پل يا ساختمان، ساختن يك قطعه‌ي مكانيكي ساخت نرم‌افزار بدون رعايت اصول مهندسي معادل: شروع پروژه‌ي ساختمان با كندن زمين- تراش قطعه بدون طرح دقيق

33 فاصله با واقعیت پذیرفتن این که تقریبا دو سوم پروژه های نرم افزاری (IS) به نوعی با شکست مواجه می شوند، دشوار است. تحقیقات نشان داد که: ۲۸ درصد پروژه های IS کاملا شکست خورده اند. ۴۶ درصد با صرف بودجه و زمان اضافی انجام گرفته اند تنها ۲۶ درصد موفق شده اند.

34

35 عوامل شكست پروژه هاي نرم افزاري:
اهداف غير واقعي تخمين نادرست منابع مورد نياز گزارش نادرست از وضعيت پروژه ريسك هاي مديريت نشده ارتباطات ضعيف بين مشتريان، توسعه دهندگان و كاربران استفاده از فنآوري ناكارآمد ناتواني در مديريت پيچيدگي هاي پروژه روش هاي توسعة نادرست مديريت ضعيف پروژه سياست هاي نگهداري فشار هاي مالي

36 در شکل فوق با تقسیم بندی، 66 رابطه به 18 رابطه کاهش پيدا کرده است
نرم افزار پيچيده است. یکی از دلايل متفاوت بودن پروژه های نرم افزاری نسبت به پروژه های دیگر، پیچیدگی آن است. با تفكيك قسمت هاي مختلف سيستم و شكستن آن به قطعه هاي كوچک به نام Object يا حتي قطعه هاي بزرگ به نام Component اين جنبه از پيچيدگي كاهش مي يابد. در شکل فوق با تقسیم بندی، 66 رابطه به 18 رابطه کاهش پيدا کرده است

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

38 تعریف نرم افزار: سیستم نرم افزاري معمولاً مشتمل است بر تعدادي : - برنامه ها - فایلهاي پیکربندي براي تنظیم این برنامه ها - مستندات سیستم براي تشریح ساختار سیستم مستندات کاربر براي تشریح چگونگی کار با سیستم

39 تعریف مهندسی نرم افزار:
بکارگیري یک روش سیستماتیک ، منظم و قابل اندازه گیري براي: - تولید و توسعه - عملیاتی کردن - و نگهداري نرم افزار

40 مقایسه ماهیت نرم افزار با ماهیت سخت افزار (یک محصول فیزیکی): 1- فرآیند توسعۀ نرم افزار ، یک فرآیند مهندسی است و نه یک فرآیند تولید صنعتی :

41 2- نرم افزار با گذشت زمان فاسد می شود اما سخت افزار دچار فرسودگی می گردد.

42 سخت افزار با گذشت زمان دچار فرسودگی می گردد.

43 3 - قطعات سخت افزاري اکثراً از ترکیب مولفه هاي استاندارد تولید می شوند اما این امر در توسعۀ نرم افزار کم رنگتر می باشد. 4 - روشها و ابزارهاي تست نرم افزار متفاوت از روشها و ابزارآزمایش سخت افزار می باشد.

44 نرم‌افزار آزاد Free software
نرم‌افزارهاي آزاد از نرم‌افزاري‌هاي رايگان که براي استفاده، از کاربر پولي دريافت نمي‌کنند، نيز متفاوت‌اند. نرم‌افزاري‌هاي رايگان معمولاً تمامي حقوق نرم‌افزار را براي توليدکننده آن محفوظ داشته و جلوي مهندسي معکوس، ويرايش و يا توزيع مجدد توسط کاربر را مي‌گيرند. بنابراين موضوع اصلي نرم‌افزار آزاد، موضوع آزادي است و نه قيمت آن. کاربران آزادند که هر چه مي‌خواهند با نرم‌افزار انجام دهند.

45 نرم‌افزار آزاد Free software (ادامه)
اين آزادي شامل انتشار مجدد نرم‌افزار به‌صورت رايگان و يا با سود نيز مي‌شود نرم‌افزار آزاد مي‌تواند به صورت رايگان و يا در ازاي دريافت مبلغي پول در اختيار کاربر قرار بگيرد. موسس "بنياد نرم‌افزارهاي آزاد" آقای ريچارد استالمن (۱۹۸۵) می باشد که در حال آغاز پروژه گنو(لینوکس) براي اولين بار از عبارت «نرم‌افزار آزاد» استفاده کرد.

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

47 مثالهايي از نرم‌افزارهاي آزاد کاربردي
لينوکس ، هسته سيستم‌عامل‌هاي گنو/لينوکس و اندرويد داروين، هسته سيستم‌عامل‌هاي OS X و iOS مرورگر وب فايرفاکس و کروميوم مجموعه اداري ليبره‌آفيس و اُپن آفيس ميزکار کي‌دي‌اي (KDE)، گنوم (Gnome)، اکس‌اف‌سي‌ئي (XFCE)، و ال‌اکس‌دي‌ئي (LXDE) برنامه‌هاي حروف چيني مانند تک، لاتک، فارسي تک، و زي‌پرشين نرم‌افزارهاي مديريت محتوا مانند وردپرس (wordpress)، جوملا (Joomla)، پي‌اچ‌پي-نيوک (PHP-Nuke)، زيکولا (Zikula)، مامبو (mambo)، دروپال (drupal) نرم‌افزارهاي ساخت انجمن (Forum) مانند پي‌اچ‌پي‌بي‌بي (phpbb)، اس‌ام‌اف (smf)، ياب (YaBB) و فروم (phorum) ويرايشگرهاي متن ويم و ايمکس تعدادي از سيستم‌عامل‌هاي خانواده بي‌اس‌دي مانند فري‌بي‌اس‌دي، اپن‌بي‌اس‌دي, نت‌بي‌اس‌دي، دراگون‌فلي‌بي‌اس‌دي کامپايلر جي‌سي‌سي، کتابخانه زبان برنامه‌نويسي سي، کامپايلر کلنگ پايگاه‌داده‌هاي رابطه‌اي مانند: mysql، پست‌گر اس‌کيوال، برکلي دي‌بي زبان‌هاي برنامه‌نويسي مانند تي‌سي‌ال، روبي، پايتون، پرل و پي‌اچ‌پي

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

49 يک c برعکس نشانه کپي‌لفت است

50 تمرین: - چرا هزینه هاي تست نرم افزار نسبت به محصولات دیگرکه در بازارها بصورت گسترده بفروش می رسند ، بسیار زیاد است؟

51 فصل 2 فرآیندهاي نرم افزار

52 فرآیند نرم افزار مجموعه اي از فعالیت ها و نتایج مربوط به آنهاست که یک محصول نرم افزاري را تولید می کند. چهار فعالیت اساسی در تمام فرآیندهاي نرم افزار متداول هستند: 1- تعیین مشخصات نرم افزار: وظایف نرم افزار و محدودیت هاي عملیاتی آن باید تعریف شود. 2- توسعۀ نرم افزار: نرم افزاري با مشخصات تعیین شده باید تولید گردد. 3- اعتبارسنجی نرم افزار: نرم افزار باید اعتبار سنجی شود تا تضمین گردد که خواسته هاي مشتري را انجام می دهد. 4- تکامل نرم افزار: نرم افزار باید تکامل یابد تا نیازهاي جدید کاربر را برآورده کند.

53 صفات اساسی نرم افزار خوب
این صفات مستقیماً با آنچه که نرم افزار انجام می دهد سروکار ندارند بلکه رفتار نرم افزار را درحین اجرا و نیز مرتبط با ساختار و سازمان برنامه و منبع Source program مد نظر قرار می گیرد. Maintainability-قابلیت نگهداري کاربر را برآورده نماید. Dependability - قابلیت اتکاي نرم افزار شامل ویژگیهایی نظیر قابلیت اتکا ، اعتماد ، ایمنی و امنیت می باشد. Efficiency - نرم افزار نباید منابع سیستم مثل حافظه و چرخه هاي پردازنده را به هدر بدهد. Usability - نرم افزار باید براي کاربردي که تهیه شده است قابل استفاده باشد. یعنی واسط کاربر مناسب و مستندات کافی داشته باشد.

54 برنامه‌نويسي ساخت‌يافته
يک نوع برنامه‌نويسي است که طبق آن برنامه‌نويس قدم‌ها و روال‌هايي را که لازم است تا برنامه به جواب برسد، مشخص مي‌کند. برنامه‌نويسي ساخت‌يافته در دهه ۱۹۶۰ توسط بوهن Böhm و جاکوپيني Jacopini پديد آمد. در اين روش از برنامه‌نويسي، انجام يک روال به روال‌هاي کوچک‌تر تقسيم مي‌شود و به اين ترتيب يک برنامه با شکسته شدن به ريز برنامه‌هاي کوچک‌تر سعي مي‌کند تا عملکرد مد نظر را پياده‌سازي کند.

55 Divide and Conquer یکی از روش‌های پرکاربرد و محبوب برای طراحی الگوریتم‌ها روش تقسیم و حل (تقسیم و غلبه) است.     در این روش، داده‌ها به دو یا چند دسته تقسیم شده و حل می‌شوند. سپس با ترکیب مناسب نتایج به دست آمده از این زیرمسأله‌ها، مسأله‌ی اصلی حل می‌شود.

56 مواردی که نیاز است در برنامه‌نويسي ساخت‌يافته اجرا شود:
رويه‌ها - routines زير رويه‌ها- subroutines ساختار بلوک - block structures استفاده از حلقه‌هاي for , while حذف Goto که برنامه را به يک کلاف سردرگم و به اصطلاح برنامه نويسي spaghetti code تبديل مي‌کرد (سال ۱۹۶۸) این موارد باعث سادگي آزمودن کدها شده و موجب می شود تا دنبال کردن برنامه و نگه داري از آن تا حد زيادي بهبود يابد.

57 مثال براي نوشتن برنامه‌اي که قراراست اطلاعات نمرات يک محصل را بگيرد و کارنامه آن را چاپ کند، زير رويه‌های ذیل (زير روال‌ها) لازم است: زير روالي اي براي خواندن اطلاعات ورودي زير روالي اي براي جمع‌آوري اطلاعات ورودي و محاسبه معدل زير روالي براي چاپ اطلاعات به صورت يک جدول زير روالي براي اتصال به چاپگر و چاپ گزارش هر زير روال آنقدر کوچک مي‌شود که برنامه‌نويس بتواند راحت تر کار کردن آن را درک کند . هر زير روال معمولاً ۳۰ خط برنامه‌نويسي است.

58 برنامه‌نويس با نوشتن هر زير روال بخشي از برنامه را توليد مي‌کند
برنامه‌نويسان مختلف مي‌توانند بر روي زير روال‌هاي مختلف کار کنند در نهايت با اضافه نمودن آنها به يکديگر برنامه نهايي ساخته شود. در زبان‌هاي ساختار يافته توابع کتابخانه‌اي فراواني وجود دارند که سعي مي‌کنند به برنامه‌نويس در برخي از روال‌ها کمک کنند. برخي از زبان‌هاي ساخت يافته: پاسکال ، C++

59 How Programs Are Usually Written …

60

61

62

63

64 فرآیند نرم افزار (Software Process)
مجموعه اي از فعالیت هاست که منجر به تولید محصولات نرم افزاري می شود. فرآیندهاي نرم افزار پیچیده اند و همانند سایر فرآیندهاي عقلایی به قضاوت انسانها بستگی دارند. بدلیل نیاز به قضاوت و خلاقیت ، تلاش براي خودکارسازي فرآیندهاي نرم افزار با موفقیت همراه نبوده است. یکی دیگر از دلایل محدود بودن حوزة خودکارسازي فرآیندهاي نرم افزار ، تنوع آنهاست. ابزارهاي کیس CASE می توانند بعضی از فعالیتهاي فرآیند نرم افزار را پشتیبانی کنند اما حداقل تا چند سال آینده این امکان وجود ندارد که فرآیندهاي نرم افزار بطور کامل خودکار شوند.

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

66 انواع مدل های (الگوها) فرآیند نرم افزاري :
مدلهاي غیرتکراري : 1 - مدل آبشاري 2- مدل توسعۀ تکاملی 3- مدل مهندسی مبتنی بر مؤلفه مدلهاي پشتیبانی کننده از تکرار : 1 - مدل تحویل تدریجی 2- مدل توسعۀ مارپیچی مدل ترکیبی : 1- مدلRUP

67 مثال: الگوی (مدل) آبشاري( Waterfall )
اولین مدل معروف فرآیند توسعۀ نرم افزار است.

68 الگو آبشاری الگو آبشاری فرایندها را به گونه‌ای نشان می‌دهد که کجا تولید کنندگان نرم‌افزار (برنامه‌نویسان) فازهای زیر را به ترتیب انجام می دهند: مشخصات مورد نیاز (تحلیل نیازمندی‌ها) طراحی نرم‌افزار پیاده‌سازی و یکپارچه‌سازی تست نرم‌افزار (یا اعتبارسنجی) گسترش نرم‌افزار (یا نصب) نگهداری نرم‌افزار

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

70 نحوة سازماندهی فعالیتهاي اصلی فرآیند نرم افزار
1- تعیین مشخصات نرم افزار تعیین مشخصات نرم افزار ( مهندسی خواسته ها ) یک مرحلۀ حیاتی ویژه در فرآیند نرم افزار است چرا که خطاهاي موجود در این مرحله ، منجر به مشکلاتی در طراحی و پیاده سازي سیستم می شود.

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

72 چهار مرحلۀ اساسی در فرآیند مهندسی خواسته ها :
-1 مطالعۀ امکان سنجی -2 استخراج و تحلیل خواسته ها -3 تعیین مشخصات خواسته ها -4 اعتبارسنجی خواسته ها

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

74 فعالیت هاي فرآیند طراحی :
-1 طراحی معماري -2 مشخصات انتزاعی : مشخصات سرویس هاي هر زیرسیستم و محدودیت هاي آن -3 طراحی واسط -4 طراحی مؤلفه -5 طراحی ساختمان داده ها -6 طراحی الگوریتم

75 اعتبار سنجی نرم افزار (V & V ):
سعی می کنند نشان دهند که سیستم با مشخصاتش جور در می آید و وارسی و اعتبارسنجی انتظارات خریدار سیستم را برآورده می کند. وارسی Verification : آیا در حال ساخت محصول درستی هستیم ؟ اعتبارسنجی Validation: آیا محصول را بدرستی ساخته ایم ؟

76 مدل وی نماد یک روش فرآیند تولید نرم افزار است
این مدل ارتباط بین فازهای مختلف چرخه حیات تولید نرم افزار و مراحل پیوسته فاز تست را مشخص می کند.

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

78 ( Alpha test ): تست آلفا تست پذیرش را گاهی تست آلفا نیز می نامند. این نوع تست ، در مکان سازنده توسط مشتري انجام می شود. نرم افزار در شرایطی طبیعی اجرا می شود بطوریکه سازنده ، ناظر بر اجراي آزمون بوده و خطاها را ثبت می کند. : ( Beta test ) تست بتا وقتی سیستمی بعنوان محصول نرم افزاري در بازار ارائه می شود تست بتا بر روي آن انجام می شود. این نوع تست ، در یک یا چند مکان مشتري با کاربر نهایی نرم افزار انجام می شود. سازنده معمولاَ حضور ندارد. مشتري ، مشکلات را تست و آنها را در فاصله هاي زمانی منظم به سازنده گزارش می دهد

79 تکامل نرم افزار تکامل نرم افزار ( نگهداري ) شامل انجام تغییرات پس از بکارگیري آن است. مرز بین توسعه و تکامل نرم افزار ، بتدریج در حال محو شدن است. اکنون ، کمتر سیستمی پیدا می شود که کاملاًً جدید باشد و توسعه و نگهداري را می توان بعنوان یک موضوع پیوسته درنظر گرفت. می توان مهندسی نرم افزار را بعنوان یک فرآیند تکاملی در نظر گرفت که نرم افزار در طول عمرش تغییر می کند تا به خواسته هاي مشتري پاسخ دهد.

80 فرآیند تکامل سیستم

81 فصل 3 مدیریت پروژه

82 مدیریت پروژة نرم افزاري ، بخش مهمی از مهندسی نرم افزار است.
مدیریت خوب ، تضمین کنندة موفقیت پروژه است و مدیریت بد می تواند منجر به شکست نرم افزار شود بطوریکه : - نرم افزار دیر تحویل داده می شود - هزینه ها بیش از آنچه برآورد شده است خواهد بود - خواسته هاي نرم افزار تأمین نمی شود. از آنجائیکه مهندسی نرم افزارِ حرفه اي به محدودیت هاي بودجه و زمانبندي مربوط می شود لذا به مدیریت پروژه نرم افزار نیاز داریم. شغل مدیر پروژة نرم افزار این است که تضمین کند پروژة نرم افزاري با محدودیتهاي فوق سازگاري دارد و نرم افزاري که تحویل داده می شود اهداف تجاري را برآورده می نماید. وظایف مدیران پروژه : - مسئول برنامه ریزي و زمانبندي توسعۀ پروژه اند. - کار را نظارت می کنند تا از استانداردهاي لازم پیروي نماید. - کنترل می کنند که پروژه به موقع و با بودجۀ مصوب تمام شود.

83 تفاوت هاي مدیریت پروژه هاي نرم افزاري با سایر انواع مدیریت ها:
-1 محصول نرم افزاري ناملموس است -2 فرآیندهاي نرم افزارِ استانداردي وجود ندارند -3 پروژه هاي نرم افزاري بزرگ ، اغلب پروژه هاي منحصربفردي هستند

84 فعالیتهاي مهم مدیریت پروژه :
- برنامه ریزي پروژه - زمانبندي پروژه - مدیریت ریسک - مدیریت بر افراد - برآورد هزینۀ نرم افزار - مدیریت کیفیت

85 جزئیات برنامه ریزي پروژه به نوع پروژه بستگی دارد اما ، اغلب برنامه ریزی ها باید شامل بخش هاي زیر باشد: ١. مقدمه : اهداف پروژه را بطور مختصر توصیف می کند و محدودیتهاي مؤثر بر پروژه را اعلان می نماید ( بودجه ، زمان و ... ) ٢. سازماندهی پروژه : مشخص می کند که تیم پروژه چگونه سازماندهی می شود. افراد سازمان و نقش آنها را مشخص می کند. ٣. تحلیل ریسک : ریسکهاي ممکن در پروژه ، احتمال وقوع این ریسکها و راهبردهاي کاهش ریسک را توصیف می کند. ۴. منابع سخت افزاري و نرم افزاري موردنیاز : سخت افزار و نرم افزار موردنیاز براي انجام کار را مشخص می کند. اگر سخت افزار باید خریداري شود، قیمت آن برآورد گردد و زمانبندي تحویل آن مشخص شود. ۵. توقف کار : توقف کار ، پروژه را بصورت فعالیتهایی توصیف می کند و نقاط عطف و مؤلفه هاي قابل تحویل را در هریک از این فعالیتها مشخص می نماید.

86 ۶. زمانبندي پروژه : وابستگی هاي بین فعالیتها را توصیف می کند ، زمان تقریبی موردنیاز براي
رسیدن به هر نقطۀ عطف و تخصیص نیروي انسانی به فعالیتها را مشخص می نماید. ٧. راهکارهاي نظارت و گزارش : گزارش هاي مدیریتی را توصیف می کند که باید تولید شوند ، مشخص می کند که این گزارش ها کی باید آماده شوند و راهکارهاي نظارت را تعیین می نماید. نکته : برنامه ریزي پروژه باید دائماَ در اثناي پروژه تجدیدنظر شود . بعضی از بخش ها مثل زمانبندي پروژه دائماَ تغییر می کند و بخش هاي دیگر تقریباَ پایدارند. مستندات باید بخوبی سازماندهی شوند.

87 زمانبندي پروژه زمانبندي پروژه از وظایف مدیران نرم افزار است. مدیران ، زمان و منابع موردنیاز براي انجام فعالیتها را برآورد می کنند و آنها را بترتیب منسجمی سازماندهی می کنند. نکته : حتی اگر پروژة جدید شبیه به پروژه هاي قبلی باشد ، زمانبندي پروژه هاي قبلی نمی تواند مبنایی براي پروژه هاي جدید قرار گیرد. زمانبندي پروژه ، کل کار پروژه را به فعالیتهاي جداگانه اي تقسیم می کند و زمان موردنیاز براي کامل کردن این فعالیتها را برآورد می کند

88 - معمولاَ بعضی از فعالیتهاي مذکور بطور موازي انجام می شوند.
- زمانبندي هاي پروژه باید این فعالیتهاي موازي را هماهنگ کنند و کار را طوري سازماندهی نمایند که نیروي کار بطور بهینه مورداستفاده قرار گیرد. نباید وضعیتی بوجود آید که کل پروژه بخاطر عدم اتمام یک وظیفۀ حیاتی به تأخیر افتد. - مدیران ، علاوه بر زمان باید منابع موردنیاز براي تکمیل هر وظیفه را نیز برآورد کنند. منبع اصلی ، منابع انسانی اند. سایر منابع عبارتند از : هزینۀ سفر کارکنان پروژه ، فضاي حافظۀ موردنیاز و ... زمانبندي پروژه معمولاََ بصورت مجموعه اي از نمودارها نمایش داده می شود. ابزارهاي مدیریت نرم افزار نظیر Microsoft Project اکنون براي تولید خودکار نمودارها بکار می روند.

89 مثال : مجموعه اي از فعالیتها را درنظر بگیرید که در جدول زیر آمده اند
مثال : مجموعه اي از فعالیتها را درنظر بگیرید که در جدول زیر آمده اند. این جدول ، فعالیتها ، مدت آنها و وابستگی هاي داخلی فعالیتها را نشان می دهد

90 رسم شبکۀ فعالیت مثال قبل :
کمترین زمان لازم براي اتمام پروژه ها را می توان با در نظر گرفتن طولانی ترین مسیر در گراف فعالیت ( مسیر بحرانی ) در نظر گرفت. در این مثال ، 11 هفته از زمان مصرف شده یا 55 روز کاري است. مسیر بحرانی بصورت دنباله اي از کادرهاي پررنگ نشان داده شده است. کل زمانبندي پروژه به مسیر بحرانی بستگی دارد. هر مشکلی در کامل کردن هر فعالیت بحرانی منجر به تأخیر در پروژه می شود.

91 رسم نمودار میله اي فعالیت مثال قبل:

92 مدیریت ریسک: وظیفۀ مهم مدیر پروژه پیش بینی و اجتناب از ریسکهایی است که ممکن است زمانبندي پروژه ، کیفیت نرم افزار در حال توسعه ، بودجۀ تعیین شده و یا سازمان توسعه دهندة نرم افزار را تحت تأثیر قرار دهد. - ریسک شرایط نامطلوبی است که واقعاََ رخ خواهد داد. - مدیریت ریسک یعنی شناسایی ریسکها و برنامه ریزي براي کمینه کردن اثر آنها بر روي پروژه دسته بندي ریسکها : 1. ریسکهاي پروژه : ریسکهایی هستند که زمانبندي یا منابع را تحت تأثیر قرار می دهند. 2. ریسکهاي محصول : ریسکهایی هستند که کیفیت یا کارایی نرم افزار در حال توسعه را تحت تأثیر قرار می دهند. 3. ریسکهاي کاري : ریسکهایی هستند که سازمان تهیه کننده یا توسعه دهندة نرم افزار را تحت تأثیر قرار می دهند. - نتایج تحلیل ریسک باید به همراه تحلیل اثرات وقوع ریسک در برنامه ریزي پروژه ، مستندسازي شود.

93 نکته : توجه داریم که انواع ریسکها ممکن است با هم همپوشانی داشته باشند.
مدیریت ریسک مخصوصاََ براي پروژه هاي نرم افزاري مهم است زیرا اغلب آنها با عدم قطعیت مواجه اند. دلایل عدم قطعیت : 1. تعریف ضعیف خواسته ها 2. دشواري برآوردکردن زمان و منابع موردنیاز براي توسعۀ نرم افزار 3. وابستگی به مهارتهاي فردي 4. تغییر خواسته ها در اثر تغییر نیازهاي مشتري

94 فصل 4 خواسته هاي نرم افزار

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

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

97 می توان مشخصات را با نشانه گذاریهاي ویژه اي نوشت
می توان مشخصات را با نشانه گذاریهاي ویژه اي نوشت. این نشانه گذاریها عبارتند از : 1 - زبانهاي طبیعی ساخت یافته و داراي سبک 2- مدلهاي گرافیکی خواسته ها نظیر موارد کاربرد( Use Case )

98 فرآیند یافتن ، تحلیل ، مستندسازي و کنترل سرویس ها و محدودیت هاي سیستم را مهندسی خواسته ها RE : Requirement Engineering ) ) گویند. خواسته هاي نرم افزار باید در سطوح مختلفی از جزئیات و در قالب سند خواسته ها نوشته شوند، زیرا انواع مختلفی از خوانندگان از آنها به روشهاي مختلفی استفاده می کنند.

99 تعریف خواستۀ کاربر : نرم افزار باید وسیله اي براي نمایش و دستیابی به فایلهاي خارجی ارائه کند که در سایر ابزارها ایجاد شده اند. مشخصات خواسته هاي سیستم: 1 امکاناتی براي کاربر تهیه شود تا نوع فایلهاي خارجی را تعریف کند. 2 هر نوع فایل خارجی ممکن است ابزار خاصی داشته باشد که به فایل اعمال شود. 3 هر نوع فایل خارجی ممکن است بصورت آیکن خاصی در نمایشگر کاربر نشان داده شود. 4 باید امکاناتی براي آیکن نمایش دهندة نوع فایل خارجی که توسط کاربر تعریف می شود ، وجود داشته باشد. 5 وقتی کاربر آیکن نشان دهندة فایل خارجی را انتخاب می کند ، اثر آن انتخاب این است که ابزار مربوط به آن نوع فایل خارجی به فایلی اعمال می شود که توسط آن آیکن نشان داده شده است.

100 فرآیندهاي مهندسی خواسته ها
فصل 5 فرآیندهاي مهندسی خواسته ها

101 مهندسی خواسته ها فرآیندي است که تمام فعالیت هاي موردنیاز براي ایجاد و نگهداري سند خواسته هاي سیستم را در برمی گیرد. - چهار فعالیت برجستۀ مهندسی خواسته ها : -1 مطالعۀ امکان سنجی -2 استخراج و تحلیل خواسته ها -3 مشخصات خواسته ها و مستندسازي آنها -4 اعتبارسنجی خواسته ها نمایی از فرآیند مهندسی در شکل ذیل آمده است. این فرآیند یک فعالیت سه مرحله اي است خواسته ها که فعالیت ها در یک فرآیند تکراري در یک مارپیچ وجود دارند.

102

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

104 مطالعۀ امکان سنجی یک مطالعۀ کوتاه براي پاسخ به بعضی از پرسش هاست :
-1 آیا سیستم کلیۀ اهداف سازمان را در برمی گیرد؟ -2 آیا سیستم با استفاده از فناوریهاي موجود ، هزینه و محدودیتهاي زمانبندي قابل پیاده سازي است؟ -3 آیا سیستم می تواند با سیستم هاي موجود دیگر جامعیت پیدا کند؟

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

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

107 استخراج و تحلیل خواسته ها ممکن است افراد زیادي از سازمان را در برگیرد.
Stakeholder (واگذارنده): این واژه براي کسانی بکار می رود که بطور مستقیم یا غیر مستقیم بر خواسته هاي سیستم تاثیر می گذارند نظیر: کاربران نهایی مهندسین توسعه دهنده نگهدارندة سایر سیستمهاي مرتبط مدیران شرکت خبرگان دامنۀ کاربرد و ...

108 استخراج و تحلیل بدلایل زیر فرآیند دشواري است :
-1 واگذارندگان معمولاً نمی دانند که چه چیزهایی را باید از خبرگان سیستم کامپیوتري درخواست کنند. -2 واگذارندگان مختلف ، خواسته هاي متفاوتی دارند و ممکن است آنها را به روشهاي مختلفی بیان کنند. -3 واگذارندگان معمولاً خواسته هاي خود را براساس اصطلاحات خودشان بیان می کنند. -4 عوامل سیاسی ممکن است در خواسته هاي سیستم مؤثر باشد. -5 محیط اقتصادي و تجاري که تحلیل در آن صورت می گیرد پویا است. این محیط در اثناي فرآیند تحلیل تغییر می کند.

109 -3 مذاکره و اولویت بندي خواسته ها -4 مستندسازي خواسته ها
فعالیت هاي اساسی فرآیند استخراج و تحلیل خواسته ها -1 جمع آوري خواسته ها -2 دسته بندي خواسته ها -3 مذاکره و اولویت بندي خواسته ها -4 مستندسازي خواسته ها

110 ( View Points ) دیدگاه ها:
براي هر سیستم ، دیدگاه هاي متعددي وجود دارد. هر دیدگاه ، زیرمجموعه اي از خواسته هاي سیستم را نشان می دهد. هر دیدگاه ، نماي تازه اي از سیستم را نشان می دهد، اما این نماها کاملاًً مستقل نیستند. ( گاهی همپوشانی دارند بطوریکه خواسته هاي آنها مشترك است ) با شناسایی دیدگاه هاي مختلف ، استخراج خواسته ها و خود خواسته ها را می توان سازماندهی کرد. نقطۀ قوت استفاده از دیدگاه ها ، تشخیص دیدگاه هاي مختلف و چارچوبی براي کشف تضادهاي موجود در خواسته ها است. دیدگاه ها می توانند واگذارندگان و سایر منابع خواسته ها را دسته بندي کنند.

111 نکتۀ 1: براي هر سیستم ، دیدگاه هاي متعددي وجود دارد و از نظر عملی استخراج خواسته ها از تمام آنها غیرممکن است لذا ، سازماندهی دیدگاه ها بصورت سلسله مراتبی مهم است. دیدگاه هاي موجود در یک مسیر ممکن است خواسته هاي مشترکی داشته باشند. نکتۀ 2: وقتی دیدگاه ها شناسایی و سازماندهی شدند ، باید سعی کنید مهم ترین دیدگاه ها را شناسایی نمایید و هنگام استخراج خواسته هاي سیستم آنها را بکار گیرید.

112 دیدگاه ها در سیستم کتابخانه دیجیتال

113 تکنیکهاي استخراج خواسته ها :
مصاحبه سناریوها موارد کاربردی دیگر...

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

115 مصاحبه ها بر دو نوعند: -1 مصاحبه هاي بسته که در آنها واگذارندگان ، به مجموعه اي از پرسشهاي از پیش تعیین شده پاسخ می دهند. -2 مصاحبه هاي باز که در آنها دستور جلسه از پیش تعریف شده وجود دارد. تیم مهندسی خواسته ها، نکاتی را با واگذارندگان مطرح می کنند و با نیازهاي آنها آشنا می شوند. • در عمل ، مصاحبه با واگذارندگان ترکیبی از این دو نوع است. • اطلاعات حاصل از مصاحبه ، سایر اطلاعات بدست آمده از اسناد ، مشاهدات کاربر و ... را تکمیل می کند.

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

117 در حالت کلی ، سناریو ممکن است شامل موارد زیر باشد:
-1 توصیف انتظار سیستم و کاربران پس از شروع سناریو -2 توصیف جریان عادي رویدادها در سناریو -3 توصیف اشتباهات احتمالی و چگونگی ادارة آنها -4 اطلاعاتی راجع به فعالیتهاي دیگري که در همان زمان قابل اجرا هستند -5 توصیف حالت سیستم پس از کامل شدن سناریو

118 سناریوها ممکن است بصورت متن نوشته شوند و با نمودار تکمیل گردند.
از طرف دیگر ، روش ساختیافته تري مثل سناریوهاي مبتنی بر موارد کاربرد ممکن است قابل قبول باشد. مثال ، سناریوي متنی سادة چگونگی استفادة کاربر از کتابخانه(خواستۀ کاربر) : کاربر می خواهد یک کپی شخصی از مقاله موجود در یک ژورنال را بدست آورد. کپی مقاله هاي این ژورنال براي اعضاء رایگان است اما غیراعضاء باید پول بپردازند. کاربر، مقاله ، عنوان و تاریخ انتشار را می داند.

119 مثال ، تکمیل سناریوی سیستم کتابخانه:
کاربر وارد سیستم کتابخانه شده است و ژورنال (مجله) حاوي مقاله را پیدا کرده است. جریان عادي : کاربر مقاله را براي کپی شدن انتخاب می کند. سیستم به کاربر پیام می دهد اطلاعات عضویت را براي ژورنال ارائه کند یا روش پرداخت را مشخص کند. پرداخت ممکن است از طریق کارت اعتباري یا شمارة حساب سازمان صورت گیرد. سپس از کاربر خواسته می شود که فرم کپی رایت را پر کند که حاوي جزئیات معامله و تحویل آن به سیستم کتابخانه مقاله به ناحیۀ کاري در کامپیوتر کاربر کپی می شود و به PDF است. فرم کپی رایت بررسی می شود ، اگر پذیرفته شد ، نسخۀ « فقط چاپ شدنی » کاربر اطلاع داده خواهد شد. از کاربر خواسته می شود چاپگري را انتخاب کند و مقاله چاپ می شود. اگر مقاله باشد پس از کامل شدن چاپ ، از سیستم کاربر حذف می شود.

120 چه خطاهایی می تواند وجود داشته باشد :
کاربر ممکن است فرم کپی رایت را به درستی پر نکند. در این مورد ، فرم باید دوباره به کاربر نشان داده شود تا اصلاح گردد. اگر این فرم نیز نادرست باشد ، درخواست کاربر رد شود. پرداخت ممکن است توسط سیستم رد شود که در اینصورت تقاضاي کاربر نیز رد خواهد شد. ممکن است کپی کردن مقاله با مشکل مواجه شود که در اینصورت سیستم مجدداً سعی می کند عمل کپی را انجام دهد. این کار ادامه می یابد تا کاربر به اتصال خاتمه دهد. چاپ مقاله ممکن نیست. اگرمقاله « فقط چاپ شدنی » نباشد ، در فضاي کاري کتابخانه باقی می ماند وگرنه مقاله حذف می شود و از حساب کاربر کسر می گردد. فعالیت هاي دیگر : کپی کردن همزمان مقاله هاي دیگر حالت سیستم هنگام کامل شدن : کاربر در سیستم قرار دارد و اگرمقاله « فقط چاپ شدنی » باشد، پس از چاپ حذف خواهد شد.

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

122 در اثناي فرآیند اعتبارسنجی ، انواع مختلفی از کنترل ها باید بر روي سند خواسته ها انجام شود
-1 کنترل هاي اعتباري -2 کنترل هاي سازگاري -3 کنترل هاي تمامیت -4 کنترل هاي واقع گرایی -5 قابلیت وارسی

123 تکنیکهاي وارسی (اعتبارسنجی ) خواسته ها
-1 مرور خواسته ها -2 ساخت نمونۀ اولیه -3 تولید موارد تست

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

125 مدل ها در فرآیند تحلیل ، براي درك سیستم موجود یا مشخص کردن خواسته ها بکار می روند. این مدل ها می توانند سیستم را از ابعاد مختلف نشان دهند : -1 بعد خارجی که حیطه یا محیط سیستم مدلسازي می شود. -2 بعد رفتاري که رفتار سیستم مدلسازي می شود. -3 بعد ساختاري که برای معماري سیستم یا ساختمان داده هایی که توسط سیستم پردازش می شوند ، مدلسازي می گردند.

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

127 مثال: مدل حیطۀ سیستم ATM
نکته : مدل هاي حیطه ، محیط سیستم را توصیف می کنند اما روابط بین سایر سیستم هاي موجود در محیط و سیستمِ در حال توسعه را مشخص نمی کنند. این روابط ممکن است خواسته هاي سیستمِ درحال توسعه را تحت تأثیر قرار دهند و باید در نظر گرفته شوند.

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

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

130 روابط موجود در نمودار موارد کاربرد:
(مفهومی) Association (مشمول) Include (توسعه) Extend (تعمیم) Generalize

131 توضیحات بیشتر برای روابط موجود:
-1 ارتباط مابین عامل و موارد کاربرد راAssociation گویند -2 زمانی که رفتاري را بطور مشابه در دو یا چند مورد جدا از هم داریم براي پیشگیري از تکرار از رابطه include استفاده می کنیم . -3 براي بیان حالت استثنائی یک رفتار عادي ( یک فرم کنترل شده از رفتار عادي ) از رابطه Extend استفاده می کنیم . -4 هنگامی که می خواهیم راههاي متفاوت یک رفتار عادي را توصیف کنیم براي بیان همه این راهکارها از Generalize استفاده می کنیم. نکته 1: روابط 2 تا 4 مابین موارد کاربرد وجود دارد. نکته 2: رابطه 4 می تواند مابین عامل ها هم موجود باشد در اینصورت اشتراکاتی مابین عاملها وجود دارد.

132 موارد کاربرد سیستم ثبت نام دانشگاه

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

134 (ERD ) نمودارهاي موجودیت – رابطه

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

136 مثلا رابطه شماره یک، یک رابطه یک به چند است و مدالیتی آن یک بار ظهور سیستم امنیتی (الزامی) و حداقل یک بار ظهور حسگر (الزامی) است توسعه روابط و کاردینالیتی/مدالیتی

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

138 4. همه پیکانها ودایره ها باید با نامهاي معنی دار نشانه گذاري شوند.
5. پیوستگی جریان داده ها باید از سطحی به سطح دیگر حفظ شود. 6. در هر نوبت یک دایره باید پالایش شود. در شکل یک DFD سطح صفر را براي سیستم SafeHome می بینیم.

139 شکل DFD سطح صفر براي SafeHome

140 در شکل اسلاید قبل همانطور که می بینیم موجودیتهاي خارجی اولیه (مستطیلها) اطلاعاتی
براي استفاده سیستم تولید می کنند و اطلاعات تولید شده توسط آن را مصرف می کند. و پیکانهاي برچسب دار اشیاي داده اي را نشان می دهد. سطح صفر را به سطح یک بسط دهیم؟ DFD چگونه روي شرح پردازشی است که حباب ها را « تجزیه گرامري » یک روش ساده براي این کار توصیف می کند یعنی همه اسمها و فعلها را مشخص می کنیم . در اسلاید بعد شرح کامل خانه امن را ارائه داده ایم با این تفاوت که اولین حضور هر اسم را با حروف درشت و اولین حضور هر فعل با حروف زیرخط دار مشخص شده است

141 نرم افزار SafeHomeصاحبخانه را قادر می سازد تا سیستم امنیتی را پس از این که نصب شد پیکر بندي کند بر همه حسگر هاي متصل شده به سیستم امنیتی نظارت کند و از طریق یک صفحه کلید و کلیدهاي عملیاتی قرار داده شده در تابلوي کنترل با صاحبخانه تعام لداشته باشد. SafeHome براي برنامه ریزي و پیکر بنديسیستم استفاده SafeHome طی نصب از تابلوي کنترل می شود. به هر حسگر یک شماره و نوع نسبت داده می شودو یک کلمه عبور اصلی براي مسلح کردنیا غیر مسلح کردنسیستم داده می شود و شماره تلفن ها براي شماره گیر يوارد می شوند تا هنگام رخداد یکرویداد حسگر استفاده شو

142 هنگامی که یک رویداد حسگر تشخیص داده شدنرم افزار یک آژیر متصل به سیستم را به
صدا در می آورد پس از یکزمان تاخیري که صاحبخانه طی فعالیتهاي پیکر بندي مشخص کرده است نرم افزار شماره تلفن یک سرویس نظارت را می گیرد اطلاعاتی درباره محل رویداد ارائه می دهد و ماهیت رویداد تشخیص داده شده را گزارش می کند. این شماره تلفن هر 20 ثانه یکبار گرفته می شود تا اتصال تلفنی برقرار شود. توسط یکزیر سیستم تعامل با کاربر مدیریت می شود که safe home همه تعاملها با ورودي ارائه شده از طریق کلیدهاي عملیاتی و صفحه کلید را می خواندو پیام هاي به نمایش در می آورد و... LCD هشدار دهنده را بر روي صفحه نمایش

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

144

145 سطح 1 را می توان بازهم به سطوح پایین تري پالایش DFD فرآیندهاي نمایش داده شده در سطح 2 پالایش کرد DFD کرد. براي مثال، فرآیند نظارت بر حسگرها را می توان به یک یک بار دیگر توجه کنید که پیوستگی جریان اطلاعات بین سطوح حفظ می شود. ها آنقدر ادامه می یابد که هر حباب تبدیل به یک وظیفه ساده شود. DFD پالایش

146

147

148

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

150 در تعریف طراحی معماري یک مولفه نرم افزاري می تواند:
یک پیمانه برنامه باشد( تابع یا شی) یک بانک اطلاعاتی «میان افزار » هایی را در برگیرد که پیکر بندي شبکه از متقاضیان و کارگزاران را میسر می سازد. خواص مولفه ها ، آن دسته از ویژگی هایی هستند که براي درك چگونگی تعامل مؤلفه ها با مؤلفه هاي دیگر لازمند. در سطح معماري ، خواص داخلی مشخص نمی شوند. روابط میان مؤلفه ها می تواند فراخوانی یک رویه از پیمانه اي به پیمانه دیگر یا یک پروتکل دستیابی به بانک اطلاعاتی باشد.

151 نکته: معماري آن بخش از نرم افزار نیست که عمل می کند ، بلکه نمایشی است که مهندس نرم افزار را قادر می سازد تا: 1 .کارآمدي طراحی را از نظر برآوردن خواسته هاي بیان شده تحلیل کند. 2. در مرحله اي که تغییر دادن طراحی نسبتا آسان است، معماري هاي متفاوت را در نظر بگیرد. 3. ریسک هاي مرتبط با ساختمان نرم افزار را کاهش دهد.

152 بس و همکاران سه دلیل کلیدي براي اهمیت معماري نرم افزار عنوان می کنند:
نمایش هاي معماري نرم افزار، برقراري ارتباط میان کلیه دست اندرکاران علاقمند به توسعه سیستم کامپیوتري را میسر می سازد. معماري، تصمیم گیریهاي طراحی اولیه اي را که اثري عمیق بر کلیه کارهاي بعدي مهندسی نرم افزار دارند و بر موفقیت نهایی سیستم به عنوان یک نهاد عمل کننده اثر می گذارند، پررنگ می کند. معماري یک مدل نسبتا کوچک و قابل درك از چگونگی سازمان دهی سیستم و چگونگی کارکردن مؤلفه ها با یکدیگر را تشکیل می دهد.

153 سبکهاي معماري براي توصیف منزلی استفاده می کند اکثر « سبک ویلالایی » هنگامی که یک بنّا از عبارت به چه « نماي کلی ساختمان » افرادي که با نوع خانه سازي آشنا هستند می توانند حدس بزنند صورت خواهد بود و احتمالاً نقشه پلان منزل چگونه خواهد بود. بنّا از یک سبک معماري بعنوان راهکاري توصیفی جهت متمایز کردن این ساختمان از سبکهاي دیگر استفاده می کند. مهمتر آنکه، سبک معماري، الگویی براي ساخت بشمار می رود.

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

155 الف) معماري داده محوري یک محل نگهداري داده ها( مثلا یک فایل یا بانک اطلاعاتی ) در مرکز این معماري واقع شده است و مؤلفه هاي دیگري که داده هاي آن را بهنگام سازي، اضافه یا حذف می کنند،به کرّات به آن دستیابی دارند. یک مخزن مرکزي دستیابی دارد. در برخی موارد مخزن داده ها ( Client ) نرم افزار مشتري است. یعنی، نرم افزار مشتري، مستقل از هرگونه عملیاتی که توسط ( Passive ) انفعالی نرم افزارهاي مشتري دیگر انجام می شود یا تغییرات اعمال شده روي داده ها، به آنها دستیابی دارد.

156 در شکل دیگري از این روش، مخزن به یک تخته سیاه تبدیل می شود که درصورت تغییر
( 7 - داده هاي مورد نظر نرم افزار مشتري ، پیامی به آن ارسال می کند.( شکل 1 معماري داده محوري، باعث بهبود قابلیت جامعیت می شود. یعنی، مؤلفه هاي موجود را می توان تغییر داد یا مؤلفه هاي مشتري جدیدي را به معماري افزود، بدون آنکه نیازي به در نظر گرفتن مشتریان دیگر باشد( زیرا مؤلفه هاي مشتري مستقل از هم کار می کنند) بعلاوه داده ها را می توان با استفاده از راهکار تخته سیاه در میان مشتریان مبادله کرد( یعنی مؤلفه تخته سیاه به هماهنگ سازي انتقال اطلاعات بین مشتریان کمک می کند) مؤلفه هاي مشتري فرآیندهایی هستند که مستقل از هم اجرا می شوند.

157

158 ب) معماري جریان داده ها این سبک هنگامی بکار برده می شود که قرار است داده هاي ورودي از طریق یک سري مؤلفه هاي محاسباتی یا دستکاري کننده، به داده هاي خروجی تبدیل شوند، الگوي لوله و فیلتر، داراي مجموعه اي از قطعات موسوم به فیلتر است که توسط لوله هایی به هم متصل می شوند؛ وظیفه این لوله ها انتقال داده ها از مؤلفه اي به مؤلفه ي بعدي است. هر فیلتري مستقل از مؤلفه هاي دیگر عمل می کند؛ براي پذیرش داده هاي ورودي با شکل خاص طراحی شده است؛ و داده هاي خروجی ( براي فیلتر بعدي) را با شکلی خاص تولید می کند .

159 ب) معماري جریان داده ها (ادامه):
( 7 - ولی این فیلتر از نحوة کار فیلترهاي مجاور خود هیچ اطلاعی ندارد .( شکل 2 اگر جریان داده ها تا حد یک خط تبدیل تنزل باید آن را دنباله اي دسته اي می نامند . این الگو، یک دسته از داده ها را پذیرفته سپس از یک سري مؤلفه هاي ترتیبی ( فیلتر ) براي ( 7- تبدیل آن استفاده می کند.( شکل

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

161 1- معماري برنامه اصلی/ زیر برنامه ها:
در این ساختار کلاسیک برنامه، عملکرد به یک سلسله مراتب کنترلی تجزیه می شود که چند قطعه برنامه را اجرا می کند و آنها نیز به نوبۀ خود قطعات « اصلی » در آن برنامه دیگر از برنامه را فراخوانی می کنند

162 2 - معماري فراخوانی روالهاي راه دور
مؤلفه هاي معماري برنامه اصلی/زیر برنامه ها، در میان چند کامپیوتر شبکه توزیع می شوند .

163

164 د) معماري شی گرا در این سیستم ها، داده ها و عملیاتی را که باید براي دستکاري آنها اجرا شوند، پنهان سازي می کنند. برقراري ارتباط و هماهنگ سازي میان مؤلفه ها از طریق مبادله پیام انجام می شود.

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

166

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

168 برخی اصول طراحی استقلال عملیاتی با توسعه دادن :(Functional Independence) -1 استقلالال عملیاتی پیمانه هایی حاصل می شود که حداکثر یک عمل را انجام دهند. چرا استقلال داراي اهمیت است؟ - نرم افزارهایی با پیمانه هاي مستقل را آسانتر می توان توسعه داد. - نگهداري (و آزمایش) پیمانه هاي مستقل نیز آسانتر است زیرا: اثرات جانبی ناشی از اصلاح طراحی/ کد محدود می شود؛ انتشار خطا کاهش می یابد. - قابلیت استفاده مجدد پیمانه ها افزایش می یابد. خلالاصه اینکه استقلالال عملیاتی، کلید طراحی خوب، و طراحی کلید کیفیت نرم افزار است.

169 میزان همبستگی بین وظایف داخلی یک پیمانه. :(Cohesion) -2 انسجام
میزان ارتباط و اتصال میان پیمانه ها در یک ساختار نرم افزاري :(Coupling) -3 پیوستگی است.

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

171 ارائه می شود) به ساختار برنامه، بعنوان بخشی DFD گذار از جریان اطلاعات ( که در قالب
از یک فرآیند شش مرحله اي انجام می شود: -1 نوع جریان اطلاعات تعیین می شود؛ -2 مرزهاي جریان مشخص می شود؛ به یک ساختار برنامه اي نگاشت می شود؛ DFD -3 -4 سلسله مراتب کنترلی تعریف می شود؛ -5 ساختار حاصل با استفاده از موازین و اصول طراحی مورد پالایش قرار می گیرد؛ -6 توصیف معماري مورد پالایش قرار گرفته، تعیین می شود.

172 نکته: نوع جریان اطلاعات، تعیین کننده روش نگاشت مورد نیاز براي مرحله 3
است. دو نوع جریان را در نظر می گیریم : -1 جریان تبدیلی -2 جریان تراکنشی

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

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

175 جریان تراکنشی جریان اطلاعات غالباً توسط یک عنصر داده اي منفرد مشخص می شود، که به آن تراکنش می گویند و همین عنصر موجب می شود تا داده ها در مسیرهاي دیگري جریان یابند. 7 باشد ، جریان تراکنشی وجود دارد . - مانند شکل 6 DFD هنگامی که جریان تراکنشی با حرکت داده ها در مسیر ورودي مشخص می شود که اطلاعات دنیاي خارج را به یک تراکنش تبدیل می کند. این تراکنش ارزیابی می شود و براساس ارزشی که دارد ، در راستاي یکی از چند مسیر کنش ایجاد شده جریان می یابد . گذرگاه جریان اطلاعات که چندین مسیر کنش از آن منشعب می شوند ، مرکز تراکنشنام دارند.

176

177 براي سیستم هاي بزرگ، جریان DFD نکته: لازم به ذکر است که در یک
تبدیلی و جریان تراکنشی، هر دو ممکن است وجود داشته باشد. براي مثال، در یک جریان تراکنشی، جریان اطلاعات در راستاي یک مسیر کنش، ممکن است داراي خصوصیات جریان تبدیلی باشد.

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

179 مثال: بر جهان واقعی نظارت می کند و به تغییراتی که با آنها SafeHome سیستم امنیتی مواجه می شود، واکنش نشان می دهد. همچنین از طریق یکسري ورودي تایپی و صفحه نمایش هاي حرفی عددي با کاربر تعامل دارد. نمودار جریان داده اي که در سطح صفر 7 نشان داده شده است. - تهیه شده است در شکل 7 SafeHome براي

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

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

182 نرمال سازی معیارها در صورتی که معیارها نرمال شوند می توان معیارهای نرم افزاری ایجاد کرد که قابل مقایسه برای سازمان های متفاوت باشد. دو روش نرمال سازی Size Oriented Function Oriented معیارهای پروژه مهندسی نرم افزار

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

184 معیارهای کیفیت نرم افزار
صحت (Correctness) : قابلیت نگهداری(Maintainability): برنامه باید صحیح عمل کند و گرنه برای کاربر ارزشی نخواهد داشت. درستی عملکرد درجه ای است که نرم افزار عملکرد مورد نیاز خود را بروز می دهد. از معمول ترین معیارهای درستی عملکرد می توان به تعداد خرابی در هر 1000 خط اشاره کرد. خرابی (شکست) بعنوان عدم تطابق مشاهده شده با نیازها تعریف می شود. نگهداری امکانی است که توسط آن در صورت بروز خطا می توان یک برنامه را اصلاح نمود و یا در صورت تغییر محیط آن را با محیط تطبیق داد و یا در صورتی که مشتری خواهان تغییری در نیازها باشد امکاناتی به آن اضافه کرد. معیارهای پروژه مهندسی نرم افزار

185 دلايل سرمايه گذاري در ساخت نرم افزار
- استفاده‌ي اجتناب ناپدير (عابربانك) - جايگزيني تكنولوژي جديد (حروف چيني، ساخت تراشه) - افزايش كيفيت سرويس (كتابخانه) - تقليل هزينه‌ها (كنترل انبار) بهره‌دهي اقتصادي، مهم‌ترين هدف در غالب موارد آمار مبين درجه‌ي اهميت صنعت توليد نرم‌افزار - 1980: 40 ميليون دلار سرمايه‌گذاري در آمريكا معادل 2% توليد ناخالص ملي - 1985: 70 ميليون دلار سرمايه‌گذاري در آمريكا، 140 ميليون دلار در دنيا - مقايسه‌ي هزينه‌هاي نرم‌افزار و سخت‌افزار، تقليل شديد مورد اخير - 12% افزايش سالانه‌ي تقاضا - 4% رشد سالانه‌ي نيروي متخصص نرم‌افزار - ازدياد روزافزون فاصله بين عرضه و تقاضا

186 اهميت توليد نرم‌افزار كيفي، خطرناك بودن خطا‌ها در نرم افزار
- اخطار اشتباهي حمله‌ي شوروي در 6 و 9 ژوئن 1980 در DoD - ضرر 50 ميليون دلاري شركت هواپيمايي، اعلام اشتباهي پر شدن صندلي‌هاي ارزان - اعلام اشتباهي بيماري لاعلاج يك زن توسط شركت بيمه، برائت او در قتل دخترش افزايش روز به روز درصد ريسك در استفاده از كامپيوتر در هر زمينه اهميت فوق‌العاده‌ي مهندسي نرم‌افزار براي تقليل ريسك نياز به روش‌ها و تكنيك‌هاي پيشرفته‌تر در ساخت نرم‌افزار براي: - صرفه‌جويي‌هاي اقتصادي - افزايش كارآيي روش‌ها - برآورده كردن دقيق‌تر خواسته‌هاي كاربران - افزايش درجه‌ي اعتماد كاربران به نرم‌افزار و محيط حاوي آن كيفيت و سودمندي (Q & P) دو عامل مهم در مهندسي نرم‌افزار

187 خصوصيات اصلي مهندسي نرم‌افزار: 1- ارتباط با ايجاد برنامه‌هاي خيلي بزرگ
فازي بودن تعاريف . . . خصوصيات اصلي مهندسي نرم‌افزار: 1- ارتباط با ايجاد برنامه‌هاي خيلي بزرگ Programming-In-The- Small در مقابل Programming-In-the- Large - برنامه‌ي مثلاً 100 خطي - برنامه‌ي مثلاً خطي - يك نفر برنامه‌نويس، مدت كوتاه - گروه برنامه نويس، مدت طولاني (6 ماه) - تكنيك‌ها و ابزار‌هاي معمولي - عدم امكان تطبيق با تكنيكها و ابزار‌ها‌يPITS - مطرح بودن فقط برنامه - يك سيستم متشكل از برنامه‌هاي وابسته به‌هم

188 2- تسلط يافتن بر پيچيدگي به عنوان تم اصلي
- نياز به تجزيه‌ي مسئله‌ي پيچيده براي ايجاد امكان مديريت مسائل محدودتر - پيچيدگي نه در ذات مسئله بلكه در اثر تعدد فاكتور‌هايي كه بايد درنظر گرفته شود 3- همكاري منظم بين افراد - بخش عمده از PITL - نياز به ترتيبات لازم براي توزيع كار، روش‌هاي ارتباط، مسئوليت‌ها، . . . - نياز به ابزار‌ها و استاندارد‌هاي مناسب براي كنترل عملكرد افراد - نظم و انضباط به عنوان كليد موفقيت پروژه‌هاي نرم‌افزاري 4- ساخت نرم‌افزار به‌صورت تكامل تدريجي - مدلي از واقعيت، نياز به تكامل منطبق با جهان واقع براي ادامه‌ي حيات - درنظر گرفتن تكامل و هزينه‌هاي آن در دوران بعد از تحويل - نياز به درنظر گرفتن تكامل‌هاي آتي در طول ساخت

189 5- اهميت حياتي كارآيي مراحل ساخت نرم‌افزار
- بالا بودن هزينه و زمان براي ساخت و نگهداري - برتری نياز به نرم‌افزار‌هاي جديد بر منابع انساني موجود، فاصله‌ي عرضه با تقاضا - نياز به ابزار‌ها و روش‌هاي بهتر براي ساخت نرم‌افزار منطبق با اصول مهندسي 6- نياز به پشتيباني موثر از كاربران - نياز به تطبيق عملكرد نرم‌افزار با نحوه‌ي كار كاربر (پيشگيري از اعلام سريع خواسته‌هاي جديد يا مقابله با آن) - نه فقط ساخت درست سيستم بلكه ساخت سيستم درست. - اهميت دريافت درست خواسته‌هاي عملياتي - درنظر گرفتن قابليت استفاده و اعتماد، پاسخ‌دهي و كاربرپسندي (فاكتور‌هاي كيفيت) - عدم احتساب فقط برنامه‌ها به‌عنوان نرم‌افزار، بلكه احتساب مستندات كاربر، آموزش و نگهداري، ايجاد شرايط محيط حاوي نرم‌افزار، آثار جانبي نرم‌افزار

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

191 دلايل وجود ديد متفاوت بين ساخت نرم‌افزار با ساخت محصول فيزيكي
- وجود هزينه در مراحل ساخت (development) و نه در مراحل توليد (production) - غير ملموس (غيرفيزيكي)بودن نرم‌افزار - امكان تكثير نرم‌افزار تقريباً بدون هزينه - استهلاك ملموس محصول فيزيكي - هزينه‌هاي نرم‌افزار دراثر تغيير خواسته‌ها - حصول قابليت اعتماد بر مبناي خطا‌هاي يافت شده و نه شكستگي و پارگي دو خصيصه‌ي مهم منتح به پيچيده شدن زياد مديريت نرم‌افزار - قابل رويت نبودن: وجود امكان ديدن روند بالا رفتن ساختمان ولي نه ساخت نرم‌افزار - بيماري 90% تكميل در ساخت نرم‌افزار - پيوسته نبودن: تعييرات جزئي در خواسته‌هاي يك پروژه‌ي فيزيكي منجر يه تغييرات جزئي در محصول فيزيكي ولي نه در محصول نرم‌افزاري - تاثير وحشتناك خطا‌هاي جزيي در نتيجه‌ي كار (گم شدن مارينر در زهره) مهندسي نرم‌افزار و علم كامپيوتر، ساير مهندسي‌ها و علوم پايه

192 مقايسه با مراحل ساخت يك خانه
- وجود مراحل مشابه در ساخت نرم‌افزار شامل: تعريف مسئله، تبيين و تحليل دقيق خواسته‌ها، طراحي بر مبناي خواسته‌ها، پياده‌سازي (برنامه‌نويسي)، آزمون، نگهداري، . . . - نمايش مراحل به‌صورت process model كلي - وجود مراحل جزئي‌تر تشكيل دهنده‌ي هر مرحله‌ي كلي - ترتيبي نبودن مراحل، وجود هم‌پوشاني و برگشت به عقب - عدم وجود مرز دقيق بين مراحل جزئيات مرحله‌ي تبيين و تحليل خواسته‌ها (مهندسي خواسته‌ها) - عملكرد مورد نياز نرم‌افزار - توسعه هاي آتي - نوع و حجم مستندات مورد نياز - رمان پاسخ مورد درخواست - امكان سنجي: بررسي وجود راه حل مقرون به صرفه و قابل پياده‌سازي از نظر فني - حاصل اين مرحله: مشخصه‌ي خواسته‌ها (RS) - شرح اين مرحله در ترم قبل، اهميت درستي آن براي درستي مراحل بعدي

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

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