روش های سریع الانتقال (چابک) توسعه نرم افزار
اسلاید 1: بسمه‌تعاليروش‌های سريع الانتقال (چابک) توسعه نرم افزارفصل دوازدهم
اسلاید 2: 2اهداف جلسهتقسيم‌بندی متدولوژي‌های توسعه نرم‌افزارمعيارهای مقايسه متدولوژي‌ها با يکديگرمقايسه متدولوژي‌ها بر اساس معيارهای مطرح شدهاصول بنيادی متدولوژي‌های چابکمعرفی چند روش چابك
اسلاید 3: 3متدولوژي توسعه نرم‌افزارفرآيند توليد و توسعه نرم‌افزار ذاتاً يك فرآيند بي‌نظم و پر هرج و مرج است. براي نظم دادن به اين فرآيند، متدولوژي‌هاي توسعه نرم‌افزار مطرح شدندمتدولوژي توسعه نرم‌افزار مشخص مي‌کند، چه فرآورده‌اي (What) توسط چه کسي (Who) و در چه زماني (When) توليد شود.
اسلاید 4: 4تقسيم بندی متدولوژي‌های توسعه نرم‌افزار متدولوژي‌های سنگين وزن (Heavyweight)فازها بطور کامل اجرا شده و مستندات کامل ايجاد مي‌شودمتدولوژي‌های سبک وزن (Lightweight)فازها به صورت کوتاه و مستندات به اندازه ايجاد مي‌شوندمتدولوژيهای چابک در دسته دوم قرار دارند
اسلاید 5: 5متدولوژي سنگين وزندر 25 سال اخير روش‌هاي بسيار زيادي براي توسعه نرم‌افزار معرفي شدند اما امروزه تعداد بسيار اندكي از آنها مورد استفاده قرار مي‌گيرد!متدولوژي‌هاي فعلي بيش از اندازه ماشين‌گرا و مكانيزه هستند و بصورت فرآيندي وارد جزئيات غيرضروري مي‌شوند، به همين دليل اين نوع متدولوژها را سنگين وزن مي‌نامند
اسلاید 6: 6مشکلات متدولوژي‌هاي سنگين وزنمشتريان نرم‌افزارها حاضر نيستند كه براي دست يافتن به نرم‌افزارهاي مورد نياز خود مدت زيادي منتظر بمانندرقابت بسيار شديد شركت‌هاي توليد نرم‌افزار براي ارائه خدمات نرم‌افزاري به كاربرانتغييرپذيري بسيار زياد نرم‌افزارهاي امروزي انكارناپذير است
اسلاید 7: 7لزوم تغييرات در توسعه نرم‌افزارbig cheese CustomerCost of changePromised dateNo Change!We are already running late. I need to meet my date.We worked hard to prevent change at the start.
اسلاید 8: 8لزوم تغييرات در توسعه نرم‌افزارbig cheese CustomerCost of changePromised dateNo Change!We are already running late. I need to meet my date.We worked hard to prevent change at the start.Change & Rework happens at the most expensive timeSpec signed off here
اسلاید 9: 9لزوم تغييرات در توسعه نرم‌افزارNo Change!Change! big cheese CustomerConflict*Meet Schedule Best Product Successful Project
اسلاید 10: 10معيارهای مقايسه متدولوژي‌ها با يکديگر روشمعيار موفقيتاندازه پروژهسبک مديريتنحوه مستندسازیچرخه‌هااندازه تيم برگشت سرمايه
اسلاید 11: 11روشروش‌های چابک بصورت Adaptive يا سازگار عمل می‌کنند يعنی با شرايط منطبق می‌شوندروش‌های سنگين وزن بصورت پيشگو يا Predictive عمل می‌کنند يعنی در آغاز همه چيز را پيش‌بينی می‌کنندآيا همه چيز از ابتدا قابل پيش‌بينی است؟Process DisciplineRigid, Highly StructuredAd hoc,ChaoticAgile ProcessesRUPCMM - SW
اسلاید 12: 12معيار موفقيتمعيار موفقيت در روش‌های چابک دستيابی به ارزش کاری (Business Value) استدر روش‌های سنگين وزن معيار موفقيت پيش رفتن در راستای طرح اوليه استروش‌های سنگين وزن انعطاف‌پذيری ندارند
اسلاید 13: 13اندازه پروژهاندازه پروژه در روش‌های چابک کوچک استاندازه پروژه در روش‌های سنگين وزن می‌تواند بسيار بزرگ باشداين مسأله از محبوبيت روش‌های چابک نمی‌کاهد !!!(آمار نشان می‌دهد که تعداد پروژه‌های کوچک بسيار بيشتر است)
اسلاید 14: 14سبک مديريتمديريت در روش‌های چابک بصورت غيرمتمرکز و آزاد است در روش‌های سنگين وزن مديريت بصورت مطلق و استبدادی است مديريت غيرمتمرکز امکان تصميم‌گيری بهتر را فراهم می‌کند
اسلاید 15: 15نحوه مستندسازیمستندسازی در روش‌های چابک بصورت بسيار محدود انجام می‌شوددر روش‌های سنگين وزن مستندسازی بصورت کامل و جامع انجام می‌شوددر بسياری از موارد مستند سازي‌های سنگين, کار بسيار دشوار و زمانبری است
اسلاید 16: 16چرخه‌هاتعداد چرخه‌ها (Cycles) در روش‌های چابک بسيار زياد است اما زمان آنها کوتاست در روش‌های سنگين وزن تعداد چرخه‌ها کم است ولی زمان آنها بسيار زياد استزمانبر بودن چرخه‌های توليد, موجب طولانی شدن زمان انتظار برای رسيدن به نشرها می‌شود
اسلاید 17: 17اندازه تيمدر روش‌های چابک اندازه تيم کوچک است (بين 20 تا 30 نفر)در روش‌های سنگين وزن اندازه تيم توسعه بزرگ استخلاقيت و همکاری در تيم کوچک بسيار بيشتر خواهد بود
اسلاید 18: 18 برگشت سرمايه در روش‌های چابک سرمايه خيلی زود در طول پروژه بر می‌گردددر روش‌های سنگين وزن برای برگشت سرمايه بايد تا انتهای پروژه صبر کردروش‌های چابک از لحاظ اقتصادی بصرفه‌اند
اسلاید 19: 19مقايسه متدولوژي‌هاي سبک و سنگين
اسلاید 20: 20بيانيه روش‌هاي چابکدر سال 2001 متخصصان روش‌هاي چابک بيانيه‌اي را منتشر كردند و اين روش‌ها را در چهار اصل كلي به دنياي نرم‌افزار معرفي نمودند كه عبارتند از: فردگرايي و تعامل برتر از فرآيندها و ابزارها نرم‌افزار قابل اجرا بهتر از مستندات مفهومي همکاري با مشتريان بهتر از مذاکرات قراردادگرا پاسخ به تغيير بهتر از دنباله‌روي از طرح
اسلاید 21: 21معروفترين روش‌هاي چابکXP (Extreme Programming)ScrumCrystal FamilyFDD (Feature Driven Development)Dynamic System DevelopmentAdaptive Software DevelopmentOpen Source Software Development
اسلاید 22: 22متدولوژی XP (Extreme Programming)بر مبنای اصول سادگی، همکاری و بازخورد سريع استوار استايده اين روش توسطKent Beck در سال 2000 ارائه شده استمبتنی بر آزمايش (Test-Driven)نقش مشتريان بسيار پررنگ استفرآيند آن شامل 12 فعاليت و 5 فاز است
اسلاید 23: 23متدولوژی XP – چرخه حيات
اسلاید 24: 24متدولوژی XP – فازهاچرخه حيات XP شامل پنج فاز است ExplorationPlanningIterations To ReleaseProduct TionizingMaintenance and Dead
اسلاید 25: 25متدولوژی XP – نقش‌ها و مسئوليت‌هابرنامه‌نويسمشتريآزمايش‌کنندهپي‌گيري کننده (Tracker)مربيمشاور مدير (رئيس ارشد)
اسلاید 26: 26متدولوژی XP – فرآورده‌هاUser Storiesمعمولاً بشکل متنی بوده و توسط مشتريان نوشته می‌شونداز طريق آنها نيازمندي‌های سيستم مشخص می‌شودIteration Planمجموعه‌ای از User Story هاست که توسط مشتری انتخاب می‌شوند در يک تکرار که معمولاً دو هفته طول می‌کشد، توليد می‌شودطرح‌های تکرار با توجه به اولويت مشخص شده توسط مشتری اجرا می‌شوندانتخاب براساس بودجه تعيين‌شده توسط توسعه‌دهندگان خواهد بود
اسلاید 27: 27متدولوژی XP – فرآورده‌ها (ادامه)Release Plan مجموعه‌ای از طرح‌های تکرار را در قالب يک نقشه کلی برای رسيدن به نشرها نمايش می‌دهدTask زيرمجموعه‌ای از User Story ها هستندTaskها از نظر تکنيکی و کاری اولويت بيشتری دارند و بايد سريع انجام شوندTaskها در مرحله طرح‌ريزی تکرارها (Iteration Planning) مشخص می‌شوند
اسلاید 28: 28متدولوژی XP – فرآورده‌ها (ادامه)Metaphoreنشان‌دهنده يک تصوير کلی از سيستم استبرای هر عنصر در سيستم يک نام در نظر گرفته می‌شودارتباط بين عناصر درگير در سيستم از طريق Metaphore مشخص می‌شودSpikeيک راه‌حل ضربتی (Spike Solution)، برنامه ساده‌ايست که بوسيله آن می‌توان راه‌حل‌های بالقوه را کشف کرددر مواردی که User Story ها حساس و مهمند از آن استفاده می‌شود
اسلاید 29: 29متدولوژی XP – عملياتPlanning Gameيک تعامل محصور (Close Interaction) بين مشتری و برنامه‌نويس بدست می‌آيدبرنامه‌نويس کار لازم برای پياده‌سازی گزارش‌های مشتری را تخمين می‌زند و مشتری در مورد حوزه و زمان نشرها تصميم‌گيری می‌کندSimple Designتأکيد اصلی در اين روش بر روی طراحی ساده‌ترين راه‌حل ممکن است و پيچيدگي‌های غيرضروری و کدهای اضافی به سرعت حذف می‌شوند
اسلاید 30: 30متدولوژی XP – عمليات (ادامه)Testingتوسعه نرم‌افزار يک فرآيند آزمايش‌گراست (Test-Driven)قبل از اينکه برنامه‌نويس يک خاصيت را اضافه کند، برای آن يک تست طراحی می‌کند که بصورت پيوسته اجرا می‌گرددRefactoringبازسازی سيستم با حذف موارد تکراری، بهبود ارتباطات، ساده‌‍سازی و افزايش انعطاف‌پذيری سيستمPair Programmingدو نفر کد را روی يک کامپيوتر می‌نويسند (يک کدنويس و يک متخصص استراتژی)
اسلاید 31: 31متدولوژی XP – عمليات (ادامه)Collective Ownershipهر فردی می‌تواند کد را در هر زمانی تغيير دهدContinuous Integrationکد جديد در حداقل زمان ممکن به کد اوليه می‌پيوندد، بنابراين سيستم دفعات زيادی در روز يکپارچه شده و ساخته می‌شود40 Hour Weekحداکثر چهل ساعت کار در هفته کافی استاين مورد اجباری است و بيشتر از اين ساعات کار مجاز نمی‌باشد
اسلاید 32: 32متدولوژی XP – عمليات (ادامه)On- Site Customerمشتری بايد بصورت تمام وقت برای تيم توسعه در دسترس باشدCoding Standardsقواعد کدنويسی بايد توسط برنامه‌نويسان رعايت شود و ارتباط بين کدها مورد توجه قرار گيرد
اسلاید 33: 33متدولوژی FDD (Feature Driven Development)تمام فرآيند توسعه نرم افزار را پوشش نمی‌دهد و بيشتر روی دو فاز طراحی و پياده‌سازی متمرکز می‌شودبرای استفاده بهمراه ساير فعاليت‌های يک پروژه توسعه نرم‌افزار طراحی شده است و هيچ مدل فرآيند خاصی لازم ندارد مبتنی بر توسعه تکراری با انتخاب بهترين و موثرترين فعاليت‌هاستروی جنبه‌های کيفتی تأکيد دارد و شامل نشرهای محسوس و پيگيری دقيق پيشرفت پروژه است
اسلاید 34: 34 فرآيندهایFDD شامل پنج فرآيند ترتيبی است که از طريق آنها فعاليت‌های طراحی و پياده‌سازی انجام می‌شودقسمت تکراری فرآيند FDD (طراحی و ساخت) از توسعه چابک حمايت می‌کندهر تکرار از يک خاصيت، معمولاً 2 تا 3 هفته زمان می‌برد
اسلاید 35: 35متدولوژی FDD – نقش‌هاFDD نقش‌های خود را به سه دسته کلی تقسيم می‌کندنقش‌های کليدینقش‌های حمايتینقش‌های اضافی
اسلاید 36: 36متدولوژی FDD – نقش‌هاي کليديمدير پروژهمعمار ارشدمدير توسعه برنامه‌نويس ارشدمالك كلاس (Class Owner)متخصص دامنه (Domain Manager)
اسلاید 37: 37متدولوژی FDD – نقش‌هاي حمايتيمدير نشر (Release Manager)مشاور زبان (Language Guru)مهندس ساخت (Build Engineer)مسئول ابزار (Toolsmith)مدير سيستم (System Administrator)
اسلاید 38: 38متدولوژی FDD – نقش‌هاي اضافيسه نقش اضافی که در همه پروژه‌ها وجود دارندآزمايش‌کننده (Tester)مستقرکننده (Deployer)نويسنده فني (Technical Writer)هر عضو می‌تواند چندين نقش بازی کند و هر نقش ممکن است به چند عضو نسبت داده شود
اسلاید 39: 39متدولوژی FDD – بهترين تجربياتDomain Object Modelingشامل استخراج و توضيح دامنه مسأله می‌باشدDeveloping By Featureتوسعه و بررسی ميزان پيشرفت پروژه از طريق دنبال کردن پياده‌سازی ليست وظايف و خواص مشخص شدهIndividual Class Ownershipبرای هر کلاس شخصي وجود داشته باشد که مسئول سازگاری، کارايی و صحت آن باشد
اسلاید 40: متدولوژی FDD – بهترين تجربياتFeature Teamsتيم كوچكي كه به‌صورت پويا شكل گرفته‌اندInspectionاستفاده از معروفترين و بهترين مكانيزهاي شناسايي خطاهاRegular Buildsتضمين اينكه هميشه يك سيستم قابل اجرا و قابل نمايش دادن (Demo) وجود داردConfiguration Managementداشتن تاريخچه تغييرات و نسخه‌هاي مختلف (بهمراه كد منبع)
اسلاید 41: متدولوژی FDD – بهترين تجربياتProgress Reportingروند اجراي فعاليت‌ها به صورت كامل و در سطوح مختلف سازماني گزارش شود
اسلاید 42: 42 متدولوژيScrum از يک استراتژی در بازی راگبي اقتباس شده است تأکيد روی اصول انعطاف‌پذيری، سازگاری و سودمندی استتمرکز: چگونه اعضای تيم بايد عمل کنند تا سيستم توليد شده، در يک محيط کاملاً تغييرپذير، انعطاف‌پذيری کافی داشته باشدايده اصلی: توسعه سيستم‌ها شامل چندين متغير محيطی و تکنيکی است (نيازها، زمان، منابع و تکنولوژی)که احتمالاً در طول فرآيند توسعه تغيير می‌کننداين موضوع فرآيند توسعه را پيچيده و غيرقابل پيش‌بينی می‌کند
اسلاید 43: 43 متدولوژيScrum - فرآورده‌هافرآورده‌های Scrum به سه دسته اصلی تقسيم می‌شوند Product Backlog Sprint Backlog Sprint BurnDown Chart
اسلاید 44: 44 متدولوژيScrum - Product Backlogشامل يک صف اولويت‌بندی شده است که در آن وظيفه‌مندي‌های تکنيکی و حرفه نمايش داده شده‌اند که بايد توسعه داده شوند برای هر مورد مشخص شده در اين فرآورده، خواصی مانند وضعيت، اولويت و تخمين کاری وجود دارد
اسلاید 45: 45 متدولوژيScrum - Sprint Backlogمجموعه‌ای از موارد حرفه و فني که برای تکرار جاری (Current Iteration) زمانبندی شده‌اند در اين فرآورده نمايش داده می‌شوند نيازها در اين فرآورده به وظايف تبديل می شوند برای هر وظيفه يک شرح کوتاه وجود دارد و مشخص می‌شود که چه کسی مسئول انجام آن است و همچنين وضعيت و تعداد ساعات باقيمانده تا تکميل شدن هر وظيفه در اين فرآروده مشخص می‌شود
اسلاید 46: 46 متدولوژيScrum - Sprint BurnDown Chartساعات باقيمانده برای تکميل شدن همه وظايف مربوط به يک Sprint را در قالب يک گراف بصورت برجسته نمايش می‌دهد
اسلاید 47: 47 متدولوژيScrum - نقش‌هاScrum MasterProduct ownerScrum teamManager
اسلاید 48: 48متدولوژي‌هاي خانواده Crystalشامل مجموعه‌ای از متدولوژي‌های متفاوت است که مناسبترين آنها برای هر پروژه منحصر به فرد انتخاب می‌شوددارای اصولی است که متدولوژي‌ها را برای شرايط مختلف موجود در پروژه‌ها سفارشی می‌کندروش Crystal پيشنهاد می‌کند که يک متدولوژی مناسب براساس اندازه و ميزان بحرانی‌بودن پروژه انتخاب شود
اسلاید 49: 49متدولوژي‌هاي خانواده Crystal (ادامه)هر عضو از خانواده Crystal با يک رنگ مشخص می‌شود که ميزان سنگينی متدولوژی را نشان می‌دهد. رنگ تاريکتر نشان دهنده متدولوژی سنگين‌تر استC: ComfortD: Discretionary MoneyE: Essential MoneyL: Life
اسلاید 50: 50متدولوژي‌هاي خانواده Crystal (ادامه)تمامی پروژه‌ها از توسعه افزايشی با بازه زمانی حداکثر 4 ماه استفاده می‌کنندتأکيد روی ارتباطات و همکاری بين افراد درگير در پروژه استهيچ فعاليت يا ابزاری را برای توسعه محدود نمی‌کندمثلاً می‌توان از فعاليت‌های XP و Scrum با هم در اين روش استفاده کرد
اسلاید 51: 51مزايای روش‌های سريع الانتقالتأکيد روی شرکت‌دادن مشتری در پروژه‌ها است که در پروژه‌های کاربردی بسيار مفيد استتأکيد روی کارگروهی و ارتباط متقابل که در بالا بردن راندمان کاری نقش مهمی داردهمه افراد درگير در پروژه در قبال کيفيت محصول مسئولندسنجش مستمر کارهای انجام شده از مزايای بسيار مفيد اين روش‌ها است
اسلاید 52: 52مزايای روش‌های سريع الانتقال (ادامه)توسعه افزايشی که با روش‌های مدرن توسعه نرم‌افزار سازگار استطراحی ساده و روشن برای فرآيند توسعه بازبينی‌های مستمر که به بالا رفتن کيفيت کار برنامه‌نويسان کمک می‌کند
اسلاید 53: 53معايب روش‌های سريع الانتقالبدليل کمبود فعاليت‌های طراحی در اين روش‌ها، اگر کد بيش از چند هزار خط باشد ممکن است فرآيند توسعه با موانع خطرناکی برخورد کندکمبود مستندات مربوط به طراحی در اين روش‌ها آنها را به پروژه‌های کوچک محدود می‌کند و قابليت‌های استفاده مجدد را در آنها محدود می‌کندکمبود فرآيندهای بازبينی ساخت‌يافته
اسلاید 54: 54معايب روش‌های سريع الانتقال (ادامه)کمبود فرآيند طراحی منظم و استفاده از بازبينی‌های غير ساخت‌يافته باعث اتلاف زمان و هزينه می‌شودکمبود طرح کيفيت. در اين روش‌ها هيچ نوع طرح استانداردی برای ارزيابی کيفيت وجود نداردکمبود راهنماهای آموزشی برای استفاده از اين روش‌ها
اسلاید 55: 55پرسش و پاسخ
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.