نوار کناری
درس:۴۰۴۰۴
آز مهندسی نرم‌افزار
Software Engineering Lab
| شماره درس: ۴۰۴۰۴ | تعداد واحد: ۱ |
| مقطع: کارشناسی | نوع درس: عملی |
| پیش‌نیاز: – | هم‌نیاز: مهندسی نرم‌افزار |
اهداف درس
این درس برای دانشجویان کارشناسی ارائه می‌شود و هدف از آن پرداختن به مباحث کاربردی مهندسی نرم‌افزار است. در این درس روش‌های مهندسی در قالب پروژه‌های عملی تجربه می‌شوند. کار آزمایشگاه در پنج حوزه‌ی اصلی مهندسی نرم‌افزار شامل مهندسی نیازمندی‌ها، تحلیل، طراحی، پیاده‌سازی و آزمون انجام می‌پذیرد. آزمایشگاه از ۱۰ جلسه‌ی سه ساعته تشکیل می‌شود. به هر گروه یک پروژه تخصیص داده می‌شود که کار خود را تا پایان ترم برروی آن پروژه و مستندات آن انجام خواهد داد.
ریز مواد
- معرفی درس، گروه‌بندی، تعیین پروژه و سایر مباحث اولیه‌ی درس
- مهندسی نیازمندی‌ها
- تحلیل (قسمت ۱)
- معرفی کلی بحث تحلیل و جایگاه آن نسبت به دو فعالیت مهندسی نیازمندی‌ها و طراحی
- پرداختن به چیستی به جای چگونگی
- نمودار فعالیت سطح بالا مربوط واقعیت بخشی به موارد کاربرد
- نحوه‌ی شناسایی کلاسهای تحلیل و نمودار کلاسها
- الگوهای تحلیل (در صورت امکان، فعالیت اضافه)
- تحلیل (قسمت ۲)
- نمودار ترتیب و استفاده از آن در تحلیل
- Package Diagram
- الگوهای تحلیل (در صورت امکان، فعالیت اضافه)
- طراحی (قسمت ۱)
- معرفی کلی بحث طراحی
- الگوها و معیار‌های GRASP: کتاب Larman فصل ۱۷ و ۲۵ بعلاوه ارائه کامل مثال ارائه شده در فصل ۱۷.۸ این کتاب با جزئیات آن
- طراحی (قسمت ۲)
- انواع Coupling و Cohesion با ذکر مثال
- نمودار کلاسها با همه جزئیات آن
- منبع: پوشش کامل از مطالب فصلهای ۳ و ۵ از کتاب UML Distilled ویرایش سوم
- پیاده‌سازی: Rafactoring
- معرفی بحث Refactoring:
- منبع: کتاب Refactoring نوشته‌ی Martin Fowler
- ارائه‌ی یک مثال از کد پیاده‌سازی شده و Rafactoring در آن
- منبع: پوشش کامل فصل ۱ کتاب Refactoring نوشته‌ی Martin Fowler
- معرفی بو‌های بد در کد (Bad Smells)
- منبع: فصل ۳ کتاب Refactoring نوشته Martin Fowler
- آزمون (قسمت ۱): Unit Testing
- مفاهیم Unit Testing
- معرفی کلی چارچوب‌های موجود در این زمینه برای زبان‌ها و محیط‌های برنامه‌سازی مختلف
- معرفی کامل JUnit و ابزار جانبی مرتبط با آن و پشتیبانی‌های IDEها از آن
- ارائه‌ی یک مثال از نحوه‌ی استفاده از JUnit و اجرای آن
- آزمون (قسمت ۲): ISP and PPC Testing Techniques
- Input Space Partitioning
- Graph Based Prime Path Coverage (Based on Source Code)
- جلسه‌ی پایانی و جمع‌بندی
- ارائه‌های اختیاری
- ابزارهای مدیریت پیکربندی نرم‌افزار (Software Configuration Management Tools)
- ابزارهای ارزیابی پوشش آزمون به همراه ارائه‌ی یک مثال عملی (Test Coverage Tools)
نحوه‌ی اداره‌ی آزمایشگاه
- آزمایشگاه از ۱۰ جلسه‌ی ۳ ساعته تشکیل می‌شود.
- کار آزمایشگاه در پنج حوزه‌ی اصلی مهندسی نرم‌افزار شامل مهندسی نیازمندی‌ها، تحلیل، طراحی، پیاده‌سازی و آزمون انجام می‌پذیرد.
- برنامه‌ی هر جلسه آزمایشگاه:
- ارزیابی فردی کار گروه‌های دیگر: ۲۰ دقیقه
- ارائه کار انجام شده گروه‌ها و دفاع از طرح خود: در مجموع ۴۰ دقیقه
- ارائه مفاهیم و ابزار (مربوط به موضوع آن جلسه) توسط گروه‌ها: ۴۰ دقیقه
- تکمیل مباحث مفاهیم و ابزار در صورت نیاز توسط TA + استراحت: ۲۰ دقیقه
- انجام کار گروهی در کلاس: مرور، بازبینی و اصلاح مدل‌ها و کارهای قبلی خود: ۴۰ دقیقه
- ارائه‌ی پیش‌نویس مدل‌های اصلاح شده و نتایج کار گروهی در آزمایشگاه به TA
- تهیه گزارش کار آزمایشگاه تا هفته‌ی بعد توسط گروه‌ها و ارسال آن به اعضای کلاس/آوردن در کلاس
جزئیات کار جلسات آزمایشگاه
- ارائه‌ها:
- با توجه به پنج حوزه‌ی اصلی مهندسی نرم‌افزار پوشش داده شده در آزمایشگاه، هر هفته یک گروه می‌بایست مفاهیم و ابزار مرتبط با آن مبحث را در مدت حدود ۴۰ دقیقه ارائه نماید.
- گروه‌های دو و سه نفره، یک ارائه خواهند داشت. گروه‌های چهار نفره ممکن است دو بار ارائه داشته باشند که این موضوع براساس نظر TA تعیین می‌شود.
- ارائه‌های هر گروه توسط TA ارزیابی شده و نمره‌ی آن مربوط به کل گروه ارائه دهنده خواهد بود.
- در برخی مباحث که دانشجویان ممکن است آشنایی کمتری با مباحث مورد نظر داشت باشند، مانند موضوع آزمون نرم‌افزار، بخشی از ارائه توسط TA انجام می‌پذیرد.
- مباحثی که در هر ارائه می‌بایست پوشش داده شود عبارتند از:
- بیان مفاهیم موضوع مورد ارائه از نظر تئوری
- نمودار‌های مرتبط UML و مباحث مربوط به آن
- الگوها و نمونه‌های موفق مرتبط با موضوع (مثلا الگوهای تحلیل، طراحی، معماری و …)
- معیار‌های اندازه‌گیری و ارزیابی کار‌ها و چگونگی تشخیص کار قوی و ضعیف
- بو‌های بد و پاد‌الگو‌ها
- ابزار مرتبط برای انجام کار، قابلیت‌ها و چگونگی عملکرد
- مثلاً ابزار مدل‌سازی، ابزار تولید کد، ابزار آزمون، …
- ابزار معرفی‌شده می‌بایست برای دانشجویان قابل دسترسی و استفاده باشد.
- اسلاید‌ها و نام و لینک منابع مرتبط، می‌بایست توسط گروه ارائه دهنده، تا ۲۴ ساعت بعد از ارائه برای همه اعضای کلاس به صورت ایمیل ارسال گردد.
- اسلاید‌ها، منابع و ابزار ارائه شده توسط هر گروه، می‌بایست در قالب CD در همان جلسه ارائه، به TA درس داده شود.
- چگونگی انجام کار گروهی آزمایشگاه
- نحوه گروه بندی و اختصاص پروژه‌ها
- حتی‌الامکان کلاس به گروه‌های حداکثر ۴ نفره تقسیم می‌شود.
- همه افراد، پروژه‌های درس تحلیل و طراحی (SAD) یا طراحی شی‌گرا (OOD) با همه جزئیات و مستندات وپیاده سازی را ارسال می‌کنند.
- پروژه‌هایی که برای انجام کارگروهی مورد نظر مناسب باشند، توسط TA انتخاب شده و به گروه‌ها تخصیص داده می‌شود.
- به هر گروه یک پروژه (حتی المقدور پروژه یکی از اعضای همان گروه) تخصیص داده می‌شود که کار خود را تا پایان ترم برروی آن پروژه و مستندات آن انجام خواهند داد.
- سعی می‌شود در مجموع، دو صورت مسئله (با پیاده‌سازی‌های متفاوت) به عنوان پروژه‌های گروه‌ها انتخاب شود تا از پراکندگی تعاریف مسئله جلوگیری شود.
- تخصیص پروژه‌ها حداکثر تا پایان جلسه اول کلاس انجام می‌پذیرد.
- کار گروهی در کلاس
- هر جلسه‌ی کلاس، به یک موضوع از مباحث مهندسی نرم‌افزار اختصاص دارد که ارائه نیز در همان موضوع انجام شده است.
- کار گروهی هر جلسه‌ی آزمایشگاه، مرور کار انجام شده قبلی گروه (از مستندات پروژه تخصیص داده شده به هر گروه)، ارزیابی نقاط قوت و ضعف آن و بازبینی و اصلاح آن است.
- به عنوان مثال، در جلسه مربوط به طراحی، مستندات طراحی قبلی مرور شده و با توجه به دانش دانشجویان و ارائه انجام شده و معیار‌های ارزیابی و …، نقطا قوت و ضعف آن طراحی استخراج شده و در تعامل گروهی، آن را اصلاح می‌نمایند و مدل طراحی جدیدی توسط گروه ارائه می‌شود.
- این کار بین ۳۰ دقیقه تا یک ساعت می‌تواند به طول بیانجامد.
- در زمان انجام کار گروهی، هر گروه می‌تواند یک notebook داشته باشد و از آن استفاده نماید.
- پس از پایان کار گروهی یا پایان ساعت آزمایشگاه، پیش‌نویسی از کار گروهی انجام شده حاوی نتیجه کار (مدل جدید)، عناوین معیار‌ها و الگوهای مورد استفاده و نقاط قوت مدل جدید نسبت به قبلی (فقط عناوین آن) به TA ارائه می‌گردد.
- این پیش‌نویس در پایان کلاس می‌بایست به TA ارائه گردد که می‌تواند به صورت فایل الکترونیکی و یا کاغذ دستنویس باشد.
- در صورت نیاز، TA می‌تواند یک کپی از این کاغذ پیش‌نویس را در اختیار تیم قرار دهد (برای انجام گزارش کار آزمایشگاه)
- نتیجه‌ی کار کلاس و پیش‌نویس تهیه شده، توسط TA ارزیابی خواهد شد و بخش مهمی از نمره آن کلاس را تشکیل می‌دهد.
- تهیه‌ی گزارش کار آزمایشگاه
- هر گروه تا هفته آینده، فرصت دارد کار گروهی انجام شده در کلاس خود را تکمیل نماید و نواقص احتمالی آن را برطرف کرده و نتیجه‌ی نهایی کار خود را در قالب یک گزارش کار آزمایشگاه ارائه دهد.
- گزارش کار آزمایشگاه می‌بایست مطالب زیر را شامل شود:
- مدل قبلی (کار اولیه مطابق مستندات پروژه تخصیص داده شده به هر گروه)
- مدل (کار) جدید (پس از بازنگری)
- روش انجام کار: معیار‌ها، الگوهای مورد استفاده، روش کار گروهی، ابزار مورد استفاده
- نقاط ضعف مدل قبلی
- نقاط قوت مدل جدید
- نقاط ضعف احتمالی مدل جدید (در tradeoff)
- راه‌حل‌های جایگزین (احتمالی)
- گزارش‌های کار می‌بایست در قالب گزارش علمی باشد، فصل‌بندی مناسب داشته باشد، به زبان فارسی باشد و از فونت ۱۲ در کاغذ A۴ برای تهیه آن استفاده شده باشد.
- گزارش کار آزمایشگاه، توسط TA ارزیابی می‌شود.
- گزارش کار آزمایشگاه، توسط دانشجویان نیز در ابتدای جلسهٔ بعد، ارزیابی می‌شود.
- از آنجا که گزارش کار هر گروه می‌بایست در جلسهٔ بعد توسط اعضای گروه‌های دیگر ارزیابی شود و این ارزیابی فردی (تک نفره) خواهد بود، هر گروه می‌بایست گزارش کار آزمایشگاه خود را حداکثر تا ساعت ۲۴ دو روز قبل از برگزاری جلسه‌ی بعد، به همه اعضای کلاس خود و TA به صورت ایمیل ارسال نماید. موارد استثناء از طرف TA اعلام خواهد شد.
- به عنوان مثال، دانشجویانی که چهارشنبه ظهر کلاس دارند، گزارش کار خود را می‌بایست تا دوشنبه شب ارسال نمایند.
- گروه‌هایی که به هر دلیل موفق به ارسال گزارش خود تا زمان مقرر نشوند، می‌بایست ۸ عدد کپی از گزارش کار کامل خود را به صورت پرینت‌شده به کلاس بیاورند. در غیر این‌صورت، نمره‌ی گزارش کار را از دست خواهند داد.
- فعالیت ارزیابی کار سایر گروه‌ها در کلاس
- در ۲۰ دقیقه ابتدای هر جلسه، هر فرد می‌بایست گزارش کار تهیه شده توسط دو گروه دیگر (غیر از گروه خودش) را ارزیابی نماید.
- این ارزیابی براساس معیارهایی که دانشجو در جلسه قبل، انجام کار گروهی و طول هفته گذشته آموخته است، انجام می‌پذیرد.
- این که هر فرد، کار کدام گروه‌ها را می‌بایست ارزیابی نماید، حداکثر تا ۴۸ قبل از تشکیل کلاس، از طریق ایمیل، به اطلاع هر فرد خواهد رسید.
- هر فرد در صورت تمایل، می‌تواند قبل از تشکیل کلاس، فعالیت ارزیابی خود را انجام داده و نتیجه آن را به کلاس بیاورد. البته این کار در صورتی امکان‌پذیر است که گروه‌های مربوطه، گزارش خود را در مهلت مقرر ارسال کرده باشند.
- ارزیابی تنها در ۲۰ دقیقه‌ی اول کلاس و براساس مستندات مکتوب (گزارش کار) انجام می‌پذیرد و پس از آن، نتیجه‌ی ارزیابی از کسی پذیرفته نخواهد شد. لذا اعضای کلاس می‌بایست از ابتدای کلاس حضور داشته باشند.
- ارزیابی هر فرد، دانش وی در موضوع مورد ارزیابی را نشان می‌دهد. بنابراین ارزیابی هر فرد، توسط TA کلاس ارزیابی خواهد شد و بخشی از نمره‌ی آن جلسه را به خود اختصاص خواهد داد.
- نتایج ارزیابی‌ها، در نمره‌ی گزارش کار مورد ارزیابی نیز موثر خواهد بود.
- در زمان ارزیابی، همه‌ی اعضای کلاس در صورت تمایل می‌توانند از کامپیوتر شخصی خود استفاده نمایند.
- مشورت در زمان ارزیابی، مجاز می‌باشد.
- پس از ۲۰ دقیقه ابتدائی کلاس، هر گروه ۱۰ دقیقه فرصت خواهد داشت تا کار خود را به طور مختصر ارائه داده و از کار خود در برابر انتقادات مطرح شده توسط سایر دانشجویان، دفاع نماید.
مراجع
- M. Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1996.
- M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
- M. Fowler. UML Distilled. 3rd Edition, Addison-Wesley, 2004.
- E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
- C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3rd Edition, Prentice-Hall, 2004.
درس/۴۰۴۰۴.txt · آخرین ویرایش: 2019/12/26 01:59 (ویرایش خارجی)