Download
1 / 19
230 likes | 448 Vues
فصل نهم: تحليل خواسته‌ها (جلسه10). مهندسي خواسته‌ها: شامل تحصيل خواسته‌ها و سپس تحليل خواسته‌ها - اولين قدم در جهت ساخت نرم‌افزار ( يا ارائه‌ي راه حل براي مسئله‌ي DP ) - تعيين و مستند كردن خواسته‌هاي كاربر براي سيستم آينده - مشكل اصلي وجود فاصله‌ي فرهنگي بين استفاده كننده و ايجاد كننده
E N D
فصل نهم: تحليل خواسته‌ها (جلسه10) • مهندسي خواسته‌ها: شامل تحصيل خواسته‌ها و سپس تحليل خواسته‌ها - اولين قدم در جهت ساخت نرم‌افزار ( يا ارائه‌ي راه حل براي مسئله‌ي DP) - تعيين و مستند كردن خواسته‌هاي كاربر براي سيستم آينده - مشكل اصلي وجود فاصله‌ي فرهنگي بين استفاده كننده و ايجاد كننده • خواسته‌هاي عملياتي: نحوه‌ي انجام فعاليت‌هاي سيستم • خواسته‌هاي غيرعملياتي: عملكرد، قابليت اعتماد، نحوه‌ي مستندسازي، آموزش، هزينه • تشخيص WHAT و نه HOW (نام‌گذاري specification به‌صورت ناقص) • محصول اين مرحله: مشخصه‌ي خواسته‌ها (Req Spec) يا گزارش مهندسي خواسته‌ها - تدوين در قالب formal، غير formal يا تلفيقي، لزوم قابل فهم بودن توسط كاربر - تفاهم بين كاربر و ايجاد كننده روي مسئله - مبناي قرارداد رسمي و ملاك تحويل سيستم در خاتمه‌ي پروژه - مبناي انجام مرحله‌ي بعدي يعني طراحي سيستم مهندسي نرم‌افزار محمد داورپناه جزي
تحليل خواسته‌ها (دنباله) • خصوصيات مرحله‌ي طراحي (شرح كامل در فصل بعدي) در مقايسه با مرحله‌ي مهندسي خواسته‌ها - مبناي انجام طراحي مشخصه‌ي خواسته‌ها يا گزارش مهندسي خواسته‌ها - طراحي مقدماتي برمبناي RS و سپس طراحي تفصيلي برمبناي گزارش طراحي مقدماتي - امكان تغيير خواسته‌ها دراثر فعاليت‌هاي اين مرحله - عدم وجود مرز بين دو مرحله - formality بيشتر در مستندات در مقايسه با RS - استفاده از روش‌هايي چون SADT و DFD مهندسي نرم‌افزار محمد داورپناه جزي
تحليل خواسته‌ها - ارائه‌ي يك مثال • مثال سيستم دستي كتابخانه‌ي دانشگاه - كشو‌هاي حاوي كارت كاتالوگ، يك كارت براي هر كتاب حاوي مشخصات آن - ترتيب معمولاً روي نام نويسنده، مشكل در صورت عدم اطلاع از نام نويسنده - امكان ساخت چند كاتالوگ، پرهزينه و خطاپرور • راه حل: ساخت نرم‌افزار كتابخانه - DB حاوي مشخصات كتاب‌ها با امكان وجود انواع ترتيب - برنامه‌ها و UIهاي كاربرپسند از طريق ترمينال‌هاي موجود در سطح دانشگاه • بعضي خواسته‌هاي سيستم فوق - ايجاد، حذف و اصلاح ركورد‌هاي كتاب‌ها و اعضا - ليست كتاب‌هاي يك نويسنده‌ي خاص - ليست كتاب‌هايي حاوي كلمه‌ي خاصي در عنوان آن‌ها - ليست كتاب‌هاي در مورد يك موضوع خاص - ليست كتاب‌هاي رسيده بعد از يك تاريخ خاص مهندسي نرم‌افزار محمد داورپناه جزي
تحليل خواسته‌ها (دنباله) • ملاحظات در تعريف خواسته‌ها - مشكل كاربر در تبيين خواسته‌هايش، احتمال تاكيد روي خواسته‌هاي غيرحياتي (مورد آخر) - لزوم اولويت بندي خواسته‌ها از حياتي تا لوكس - تبيين خواسته‌هاي غيرحياتي براي آينده ولي درنظر گرفتن آثار آن در سيستم فعلي • نمونه‌ي خواسته‌هاي غير حياتي در سيستم كتابخانه - ليست كتاب‌هاي سفارش داده شده و واصل نشده - اطلاعات كتاب‌هاي داراي ديركرد براي ارسال اخطار • بحث بالا خواسته‌هاي عملياتي (FR)، حالا خواسته‌هاي غيرعملياتي (NFR) 1- نوع كامپيوتر، نوع OS، نوع DBMS، تعداد و نوع ترمينال، . . . 2- طبقه‌بندي كاربران، دسته‌بندي عمليات سيبستم، محدوديت‌ها و مجوز‌هاي كاربران (مثال) 3- حجم DB و درصد رشد آن (كتابخانه‌ي دانشگاه در مقابل كتابخانه‌ي كنگره يا منچستر) 4- زمان پاسخ در مقايسه با رجوع به قفسه، تعداد سوال‌هاي قابل انتظار در واحد زمان 5- هزينه‌هاي سيستم شامل: ساخت، تبديل داده‌ها، آموزش و ساير هزينه‌هاي پنهان مهندسي نرم‌افزار محمد داورپناه جزي
تحليل خواسته‌ها - ساير ملاحظات • درنظر گرفتن محيط حاوي سيستم و رابطه‌ي سيستم با آن، لزوم توجه به جنبه‌هاي غير تكنيكي علاوه بر جنبه‌هاي تكنيكي - آثار غيرمنتظره در سازمان مثل تغيير وظايف افراد و بيكار شدن بعضي كاركنان - ارتباط با ساير سيستم‌ها مثل ارتباط مكانيزم جريمه‌ي ديركرد با امور مالي - شكست خيلي از پروژه‌ها به دليل عدم توجه به اين جنبه‌ها • توجه به امكان‌پذيري راه حل ارائه شده براي ساخت سيستم - امكان‌پذيري فني، قابل حصول بودن عملكرد درخواستي از سخت‌افزار و نرم‌افزار - امكان‌پذيري تامين داده‌ها، وجود زمان كافي (معمولا طولاني) براي تبديل و رساندن داده‌ها - كاربرد تحليل‌هاي آماري براي فركانس درخواست‌ها، زمان CPU لازم، تعداد I/O، . . . - مثلاً CPU مناسب براي حصول زمان پاسخ 2 ثانيه در 80% موارد - امكان نياز به دو برابر قدرت پردازشي براي حصول 85% - عدم وجود امكانات فني براي حصول 95% (مثال تاريخچه‌ي DMC) - وجود پروژه‌هاي شكست خورده‌ي زياد به دليل عدم امكان‌پذيري فني (تحريم اقتصادي) مهندسي نرم‌افزار محمد داورپناه جزي
تحليل خواسته‌ها - ساير ملاحظات (دنباله) • توجه به امكان‌پذيري (دنباله) - امكان‌پذيري اقتصادي، هزينه در مقابل در‌آمد، نقطه‌ي سر به سر سرمايه - پيش‌بيني تقريبي هزينه‌ها در آغاز، دقيق‌تر شدن اعداد و ارقام با پيشرفت پروژه - مشكل بودن برآورد كمي بعضي منافع، معدل موجودي پايين‌تر و درصد موجود بودن بالاتر در سيستم انبار، ارائه‌ي سرويس بهتر به اعضاي كتابخانه (مشكل‌تر از قبلي) • روند مطالب بعدي - تحليل خواسته‌ها در يك سيستم ايزوله بدون توجه به محيط حاوي آن - ادامه‌ي كار با تحليل خواسته‌ها با توجه به سازمان حاوي سيستم - احتساب مواردي چون شرايط مرزي و ارتباط با ساير سيستم‌ها - توجه روي محصول مورد تحويل (WHAT) و نه روند ساخت آن (برنامه‌ي پروژه، ف 2) - مفهوم UoD و لزوم آشنايي كافي ايجادكننده از طريق كاربران متخصص - احتمال مواجهه با جنگ قدرت و خواسته‌هاي متضاد، نياز به شركت در ساخت UOD جديد - روند مستندسازي و V & V در اين مرحله مهندسي نرم‌افزار محمد داورپناه جزي
9-1 مشخصه‌ي خواسته‌ها • محصول مرحله‌ي مهندسي خواسته‌ها - مبناي ايجاد ارتباط بين طرفين پروژه و اعضاي هر طرف - استفاده از انواع رسانه‌ها (متن، صوت، تصوير، گرافيك، . . . ) براي افراد مختلف - لزوم وجود خلاصه‌سازي در سطوح مختلف براي مديريت هر طبقه • خصوصيات لازم در مشخصه‌ي خواسته‌ها - سليس و روان و دقيق بودن و قابليت فهم (مستندات فرمال در مقابل متن و گرافيك) - عدم وجود ابهام (توجه به مبهم بودن زبان‌هاي طبيعي) - كامل بودن، احتساب موضوعات عملياتي، عملكردي، محدوديتي، . . . ؛ عكس‌العمل در مقابل ورودي‌هاي غلط (علاوه بر درست)، اجتناب از “بعداً معلوم مي‌شود” يا تعيين زمان آن - سازگاري، عدم وجود خواسته‌هاي متضاد چه از نظر منطقي و چه از نظر زماني - قابليت تغيير، در اثر تغييرات جهان واقع، سهولت اصلاح مستندات، اجتناب از افزونگي - قابليت رديابي، امكان رديابي ساير مستندات به خواسته‌ي مربوطه (شماره‌گذاري درست) - قابليت استفاده، عدم حفظ ضمني داده‌ها و امكان استفاده از RS در زمان كار سيستم مهندسي نرم‌افزار محمد داورپناه جزي
مشخصه‌ي خواسته‌ها (استاندارد IEEE) • استاندارد 830 ANSI/IEEE ش9-1 ص145، شرح در آپانديس E - ارائه‌ي يك ساختار و قالب كلي (عدم پيشرفت كافي در مرز‌هاي دانش) - امكان تغيير مفاهيم و ترتيب موارد ارائه شده براي پروژه‌هاي مختلف - تناسب بيشتر با روش كلاسيك تحليل خواسته‌ها (آبشاري) - افزودن عناوين مناسب براي استفاده در ساير روش‌ها - مثلاً افزودن اولويت‌ها براي نمونه‌سازي، شروع با يك هسته‌ي اوليه، افزودن موارد جديد - وابستگي مورد 3 (خواسته‌هاي خاص) به موضوع پروژه، نمونه در ش 9-2 ص 146 • ساير ملاحظات در مشخصه‌ي خواسته‌ها - ساخت سيستم درست‌تر برمبناي مشخصه‌ي دقيق‌تر - توجه به عدم پيوستگي، بازنويسي 95% كد در يك سيستم براي حصول خواسته‌هاي واقعي - سيستم كتابخانه، اسپل اسامي غير لاتين، فصل مشترك كاربران(اعضا و كاركنان)، شناسه‌ي ISBN و نسخه‌هاي متعدد، بولي نبودن حالت كتاب (درقفسه، امانت، درصحافي، . . .) - تاثير درجه‌ي آشنايي ايجادكننده با UoD مهندسي نرم‌افزار محمد داورپناه جزي
تكليف دوم - مهلت يك هفته • هدف‌ها • هدف 1: آشنايي با نحوه‌ي تدوين مشخصه‌ي خواسته‌ها • هدف 2: انجام يك كارآموزي براي تدوين گزارش مرحله‌ي دوم پروژه • موارد تكليف: • بررسي متن ارائه شده در ش 9-3 ص 148 • ترجمه‌ي كامل متن به فارسي و اطمينان از فهم مطالب • پر كردن جاهاي خالي در بخش سوم گزارش به صورت منطقي بر مبناي دانش شما از سيستم كتابخانه • اهميت تميزي و خوانايي جواب مهندسي نرم‌افزار محمد داورپناه جزي
9-2 انسان‌ها به عنوان منابع اطلاعات • مفهوم تئوريك RS: ش 9-4، يك محصول قابل تعريف به‌طور صريح و مشخص • RS در واقعيت: اغلب مسئله‌اي غيرقابل تعريف به صورت واضح و روشن و حالت فازي • هدف RA: استخراج حدود و محتويات مسئله با شرايط بالا (conceptual modeling) - مدلسازي UoD به عنوان بخشي از جهان واقع (مثال . . . ) - ايجاد يك مدل مفهومي صريح (ECM) قابل فهم براي طرفين - مدل مزبور حاوي اطلاعات مرتبط و عاري از اطلاعات غيرمرتبط (abstraction يا تجريد) - ذهن افراد درگير در UoD حاوي مدل مفهومي غير صريح، نياز به انتقال آن به مدل صريح - عدم انتقال كامل، حاوي عادات، مهارت‌ها، تعصب‌ها و تناقض‌ها • مسئله‌ي تحليل: عدم انتقال و تدوين كامل، نياز به گذشت زمان، فاصله‌ي فرهنگي • مسئله‌ي سازش: مقابله‌ي كاربران با امر تحليل، تفاوت در مدل ذهني افراد، درگيري كاربران با مديران مهندسي نرم‌افزار محمد داورپناه جزي
انسان‌ها به عنوان منابع اطلاعات (دنباله) • جزئيات مسئله‌هاي فوق - لزوم انتقال دانش UoD بين دو فرهنگ مختلف، لزوم آگاهي ايجاد كننده - پراكندگي دانش UoD در ذهن‌هاي مختلف، مسئله‌ي هماهنگي و يكپارچه‌سازي - بديهي فرض شدن بعضي خواسته‌ها (مثل اسپل اسامي غير لاتين در سيستم كتابخانه) - كامل فرض شدن خواسته‌ها توسط ايجاد كننده (وجود نتايج خطرناك) - سيستم دفاع موشكي آمريكا و اشتباه گرفتن ماه با موشك! - محدوديت در قابليت‌هاي انسان‌ها و تشديد آن در اثر مواردي چون - پيچيدگي و تنوع خوسته‌هاي قابل اعمال در نرم‌افزار - تفاوت پيشينه‌ي فرهنگي بين كاربر و ايجاد كننده - موضوع حافظه‌‌هاي كوتاه و بلند مدت و حافظه‌ي خارجي در انسان‌ها (موضوع 2±5) - نقص در خواسته‌هاي مستخرج از فقط حافظه‌ي كوتاه مدت - باقي ماندن خواسته‌هاي مربوط به وقايع اخير در ذهن انسان‌ها مهندسي نرم‌افزار محمد داورپناه جزي
انسان‌ها به عنوان منابع اطلاعات (دنباله) • جزئيات مسئله‌هاي فوق (دنباله) - درخواست اتوماسيون به دليل نارضايتي از وضعيت فعلي، ولي ريشه‌ي مسئله سازماني - ظهور خواسته‌هاي جديد پس از اتوماسيون وضع فعلي، بار زياد در نگهداري - اميد به اخذ خواسته‌هاي كامل و نياز به پيش‌بيني همه‌ي خواسته‌هاي آينده (غير ممكن!) - نياز به روش‌ها و ابزار مناسب براي اجتناب از مسائل فوق، نياز به تجربه در هر دو طرف • چهار استراتژي ديويس در اخذ اطلاعات لازم (انتخاب درست بسيار مهم) 1- پرسش در قالب مصاحبه، پرسشنامه يا brainstorming (مشكلات هر يك) 2- مطالعه‌ي يك سيستم مشابه و تبيين اصلاحات لازم 3- تركيب مشخصات محيط، بررسي عمليات، استاندارد‌ها و تصميم‌ها در محيط 4- نمونه سازي (مشكل ولي ممكن)، شروع از يك هسته‌ي اصلي و توسعه‌ي آن (سناريو‌ها) - اهميت فوق‌العاده‌ي انتخاب استراتژي درست - اجتناب از خوش‌بيني بيش از حد مهندسي نرم‌افزار محمد داورپناه جزي
انسان‌ها به عنوان منابع اطلاعات (دنباله) • ملاحظات در انتخاب استراتژي - هر استراتژي براي شرايط خاص، اطمينان پايين در 1 و اطمينان بالا در 4 - مصاحبه: مسئله تفهيم شده، ايجاد كننده مجرب، محيط تثبيت شده - نمونه‌سازي: مسئله نامفهوم، ايجاد كننده مبتدي، محيط در حال تغيير - داستان مزرعه‌‌ي مكانيزه، چيپ در گوش گاو‌ها، بعد خوك‌ها و سپس بز‌ها! - فرض تيلوري بودن روش‌هاي ساخت نرم‌افزار، تيلور و اصول مديريت علمي اوايل قرن قبل - تجزيه‌ي سلسله مرتبي هر كار، وجود يك بهترين راه حل براي هر كار نهايي (نياز به يافتن) - ديد تيلوري: تحصيل خواسته‌ها و انجام ادامه‌ي كار بدون نياز به كاربر!، ديد فقط تكنيكي - ديد جديد: مناسب و بهترين نبودن ديد فوق، احتساب روابط انساني علاوه بر جنبه‌هاي فني - ديد م د ج: آموزش روش مناسب و ساده به كاربران، بيان خوسته‌ها در قالب ساختيافته، درنظر گرفتن جنبه‌هاي انساني و سازماني، مشاركت كاربران در ساخت مشخصه‌ي خواسته • سند RS: شرح دقيق قابليت‌هاي سيستم براي كاربر، مبناي طراحي براي ايجادكننده - مشكل ايجاد RS براي دو فرهنگ، متني براي كاربران، گرافيكي و فرمال براي ايجاد كنندگان - باتوجه به تحقيقات، زبان كاربر بهترين مبنا براي تدوين RS مهندسي نرم‌افزار محمد داورپناه جزي
9-3 ابزار‌هاي مستندسازي خواسته‌ها • معايب زبان طبيعي از ديد مِي‌ير 1- وجود نويز يا اجزاي خالي از اطلاعات، افزونگي يا تكرار يك مطلب به شكل‌هاي متفاوت، جملات معكوس مثل “ليست كتاب‌هاي توسط يك نويسنده” بدون توجه به خالي بودن آن 2- مسكوت گذاشتن بعضي مطالب مثل عدم توجه به “وجود دو نويسنده در مواردي” 3- مشخصه‌ي بيش از حد، توضيح راه حل به‌جاي مسئله، مثل “اعلام نوع ترتيب كتاب‌ها” 4- تضاد در زمان شرح مكرر يك موضوع در جاهاي مختلف متن 5- ابهام و دوپهلو بودن در بعضي عبارات، اصطلاحات زمينه‌اي (مثال فايل و كتاب) 6- ارجاع‌هاي به مطالب بعدي به دليل عدم وجود ساختار درست (ناساختيافتگي زبان طبيعي) 7- تفكرات رويايي منجر به عدم امكان يا پيچيدگي در يافت راه حل قابل اعمال • روش‌هاي قابل استفاده - راه حل مي‌ير: ايجاد يك مدل فرمال و سپس ترجمه به زبان طبيعي، زمان‌بر و مشكل اصلاح - عدم وجود روش‌هاي مناسب، تاكيد روش‌ها روي مراحل بعدي با مبناي ساخت نرم‌افزار - جوان بودن زمينه‌ي RE در دنيا، برنامه‌نويسي --› طراحي --› تحليل --› مهندسي خواسته‌ها - راه حل م د ج: ايجاد مدل ساختيافته گرافيكي و متني توسط كاربر، روش و چارچوب مناسب مهندسي نرم‌افزار محمد داورپناه جزي
9-3-1 ابزار SADT • روش SADT شامل SA براي تحليل و DT براي طراحي - حاوي زبان گرافيكي به‌اضافه‌ي متن و توصيه‌هايي براي نحوه‌ي مصاحبه و بازبيني - استفاده از حدود 40 جزء گرافيكي براي بيان مفاهيم مختلف، نمونه در ش 9-5 ص 158 - ايده‌اي مشابه نقشه‌هاي ساختمان و راديو، كاربرد هر جزء در جاي خودش - ساخت شرح فعاليت‌هاي سيستم يا functional architecture در مرحله‌ي تحليل به صورت سلسله‌مراتبي و واحدمند - ساخت system architecture بر مبناي FA در مرحله‌ي طراحي • ساختار سلسله‌مراتبي بالا به پايين - قالب كلي در ش 9-6 ص 160 - مدلسازي از ديد‌هاي مختلف (مثل ساختمان)، ديد عمل‌ها (كاربرد بيشتر)، ديد داده‌ها، . . . - ش9-7 ص160 يك عمل، ورودي از چپ، خروجي از راست، محدوديت از بالا، وسيله از زير - دياگرام سطح بالا حاوي ارتباطات سيستم با محيط - ش 9-8 ص 161، سه طبقه از بخشي از مدل كتابخانه‌ي مكانيزه (مسئله‌ي فهم كاربران) مهندسي نرم‌افزار محمد داورپناه جزي
9-3-2 ابزار PSL/PSA • دو بخش اصلي از پروژه‌ي ISDOS - Problem Statement Language براي تعريف عمليات سيستم (شرح مسئله)، what - Problem Statement Analyzer براي تحليل مسئله‌ي نوشته شده در PSL - PSL يك زبان متني با ساختار‌هاي كافي - مثال ش 9-9 ص 163 بخشي از كتابخانه، شامل شي‌ها (موجوديت‌ها، داده‌ها و عمل‌ها) و رابطه‌هاي بين آن‌ها (is-a, part-of, consist-of) - حاوي16نوع شي و66 نوع رابطه براي تبيين همه‌ي جنبه‌هاي سيستم - بروز مشكل در سيستم‌هاي بزرگ (قابليت فهم براي كاربران؟) - ذخيره‌ي PSL در يك DB و امكان پرس و جو - گزارشات مفصل مثلاً ليست اصلاحات، اشيا، صفات و روابط يك شي -گزارشات خلاصه مثل سلسله‌مراتب سيستم - گزارشات تحليلي مثل جاهاي خالي و شي‌هاي مازاد - قدرت اين روش در PSA، ذخيره و تحليل مشخصه‌ي خواسته‌ها، جزء AWB (ف15) مهندسي نرم‌افزار محمد داورپناه جزي
9-3-3 روش تحليل برمبناي زبان Ada • توسط DoD، جزء محيط پشتيبان براي همه‌ي مراحل ساخت (ف12) - لزوم حصول 12 خصوصيت براي استفاده از اين محيط (ص 164 و 165) - روش ARM حالت خاصي از آن با چهار مرحله: 1- DFD براي خواسته‌هاي عملياتي 2- تشريح خواسته‌هاي غير عملياتي 3- بيان خواسته‌هاي مربوط به همزماني 4- تدوين همه ي خواسته‌ها در RS مهندسي نرم‌افزار محمد داورپناه جزي
9-4 V & V در مرحله‌ي مهندسي خواسته‌ها • V & V براي اطمينان از درستي نتيجه و درستي كار - بستگي به نحوه‌ي بيان خواسته‌ها - بازرسي و بازبيني براي اطمينان از لحاظ كردن همه‌ي جنبه‌هاي مورد نطر - درنظر گرفتن كامل بودن، درستي، سازگاري، دقت، خوانايي، قابليت آزمون - در نظر گرفتن ارتباط با محيط (سخت‌افزار، نرم‌افزار و انسان) - يك روش: بازسازي سناريو‌ها با شركت كاربران واقعي - اجتناب از موارد فازي: سيتم انعطاف‌پذير، كاربرپسند، سريع، . . .، همه غير قابل آزمون - تدوين برنامه‌ي آزمون براي آزمون سيستم در پايان، شامل اجزا و خصوصيات قابل آزمون، مراحل آزمون، افراد درگير - برنامه‌ي آزمون سيستم و آزمون تحويل - سهولت كار درصورت وجود امكانات اتوماتيك مانند PSA - شرح كامل در ف 13، ترم آينده انشاله . . . مهندسي نرم‌افزار محمد داورپناه جزي
روش مورد استفاده در پروژه - روندنما‌هاي رويداد مهندسي نرم‌افزار محمد داورپناه جزي
