صفحه 1:
صفحه 2:
5 اهداف جلسه
* تقسیمبندی متدولوژيهای توسعه نرمافزار
* معیارهای مقایسه متدولوژيها با یکدیگر
* مقایسه متدولوژيها بر اساس معیارهای مطرح شده
* اصول بنیادی متدولوژيهای چابک
* معرفی چند روش چابك
صفحه 3:
a متدولوژي توسعه نرمافزار
* فرآیند تولید و توسعه نرمافزار ذاتاً يك فرآیند بينظم و ير هرج
و مرج است. براي نظم دادن به اين فرآیند. متدولوژيهاي
توسعه نرمافزار مطرح شدند
* متدولوژي توسعه نرمافزار مشخص ميکند. چه فر آوردهاي
(۲۷۲۵۲) توسط جه كسي (۲۷۷0) و در چه زماني Ji (When)
شود.
صفحه 4:
|“ تقسیم بندی متدولوژيهای توسعه نرمافزار
5 متدولوژيهای سنگین وزن (Heavyweight)
* فازها بطور كامل اجرا شده و مستندات کامل ایجاد ميشود
* متدولوژيهای سبک 534 (Lightweight)
* فازها به صورت کوتاه و مستندات به اندازه ایجاد ميشوند
* متدولوژیهای چابک در دسته دوم قرار دارند
صفحه 5:
متدولوژی سنگین وزن
* در 25 سال اخیر روشهاي بسیار زبادي براي توسعه نرمافزار
معرفي شدند اما امروزه تعداد بسیار اندكي از آنها مورد استفاده
قرار ميگیرد!
* متدولوژيهاي فعلي بیش از اندازه ماشین گرا و مکانیزه هستند
و بصورت فرآيندي وارد جزئیات غيرضروري ميشوند. به همین
دلیل این نوع متدولوژها را سنگین وزن مينامند
صفحه 6:
a مشکلات متدولوژيهاي سنگین وزن
* مشتریان نرمافزارها حاضر نیستند که براي دست یافتن به
نرمافزارهاي مورد نیاز خود مدت زيادي منتظر بمانند
* رقاپت پسیار شدید شركتهاي تولید نرمافزار براي ارائه خدمات
نرمافزاري به کاربران
" تغييرپذيري بسیار زیاد نرمافزارهاي امروزي انکارناپذیر است
صفحه 7:
1 لزوم تغییرات در توسعه ate
( Op Oko!
De are creeds rurcratky hetee.
"sid wi
Der wa ard 7
3
صفحه 8:
1 لزوم تغییرات در توسعه ate
( We Oko!
(Der are abroad rurcratcny kate.
1 aed cent ony chit.
Dee worked bard te preven رجات
f=
De N
A
صفحه 9:
1 لزوم تغییرات در توسعه نرمافزار
صفحه 10:
5 معیارهای مقایسه متدولوژيها با یکدیگر
روش
معيار موفقيت
اندازه پروژه
سبک مدیریت
نحوه مستندسازی
چرخهها
اندازه تیم
برگشت سرمایه
صفحه 11:
هه یمن دهد
1
صفحه 12:
* معیار موفقیت در روشهای چابک دستیابی به ارزش کاری
cow! (Business Value)
oe درا ۴
12
صفحه 13:
1" اندازه پروژه
* اندازه پروژه در روشهای چابک کوچک است
این مسأّله از محبوبیت روشهای چابک نمی کاهد !!!
(آمار نشان میدهد که تعداد پروژههای کوچک بسیار بیشتر است)
18
صفحه 14:
a | سبك مدیر یت
* مدیریت در روشهای چابک بصورت غیرمتمرکز و آزاد است
14
صفحه 15:
نحوه مستندسازی
* مستندسازی در روشهای چابک بصورت بسیار محدود انجام
میشود
15
صفحه 16:
جرخهها
«
" تعداد جرخدها (07:6165)) در روشهاى جابك بسيار زياد است
اما زمان آنها کوتاست
16
صفحه 17:
7 اندازه تیم
* در روشهای Sule اندازه تیم کوچک است (بین 20 تا 30 نفر)
17
صفحه 18:
at برگشت سرمایه
* در روشهای چابک سرمایه خیلی زود در طول پروژه بر میگردد
صفحه 19:
مقایسه متدولوژيهاي سبک و سنگین
ile Method: He:
‘Adaptive
Business Value Conformation to
plan
Small Large
Decentralized ‘Autocratic
Low Heavy
People-Oriented Process-Oriented
"Numerous "Limited
Unpredictable/ Predictable |
Exploratory
‘Small/Creative_ Large
صفحه 20:
۷" بیانیه روشهای جابک
* در سال 2001 متخصصان روشهاي چابک بانيهاي را منتشر
کردند و این روشها را در چهار اصل كلي به دنياي نرمافزار
معرفي نمودند که عبارتند از:
* فردگرايي و تعامل برتر از فر آیندها و ابزارها
* نرمافزار قابل اجرا بهتر از مستندات مفمومي
۴ همكاري با مشتریان بهتر از مذاکرات قراردادگرا
* پاسخ به تغییر بهتر از دنبالهروي از طرح
صفحه 21:
ai معروفترین روشهاي چابک
= XP (Extreme Programming)
= Scrum
= Crystal Family
= FDD (Feature Driven Development)
= Dynamic System Development
= Adaptive Software Development
= Open Source Software Development
21
صفحه 22:
AP (Extreme (539) 9
Programming) B®
* بر مبنای اصول سادگی» همگاری و بازخورد سریع استوار است
* ایده این روش توسطع13061 10۳1 در سال 2000 ارائه شده
است
" مبتنی بر آزمایش (Test-Driven)
* نقش مشتریان بسیار پررنگ است
* فرآیند آن شامل 12 فعالیت و 5 فاز است
صفحه 23:
متدولوژی 26۳ - چرخه حیات
EXPLORATION | PLANNING ITERATIONS TO
PHASE | PHASE RELEASE PHASE
PHASE
PRODUCTIONZING
fa 1
yt
1 ‘CONTINUOUS
INTEGRATION
— — ! 0
“ro ۵ ۱ سوم ۱ coutccm {
Gs) ۳ نت ارس
سود
= yo! aS
صفحه 24:
۷" متدولوژی 2۳ - فازها
* چرخه حیات 2۳ شامل پنج فاز است
صفحه 25:
1 متدولوژی 2۳ - نقشها و مسئولیتها
* برنامهنویس
م
شتوی
* آزمایشکننده
(Tracker) oS پيگيري a
i
* مربي —
Lo هيا
* مدیر (رئیس ارشد)
صفحه 26:
+ متدولوژی 2۳ - فر آوردهها
User Stories *
© معمولاً بشکل متنی بوده و توسط مشتریان نوشته میشوند
" از طریق آنها نيازمنديهای سیستم مشخص میشود
Iteration Plan *
* مجموعهای از 51015 ۲/50۲ هاست که توسط مشتری انتخاب میشوند
* در یک تکرار که معمولاً دو هفته طول میکشد. تولید میشود
" طرحهای نگرار پا توجه په اولویت مشخص شده توسط مشتری اجرا
میشوند
" انتخاب پراساس بودچه نعپینشده توسط توسحهدهندگان خواهد بود
26
صفحه 27:
۷" متدولوژی XP — فر آور دهها «دام)
Release Plan "
* مجموعهای از طرحهای تکرار را در قالب یک نقشه کلی برای رسیدن
به نشرها نمایش میدهد
Task *
" زیرمجموعهای از 5101۲ 7567] ها هستند
7 ا5ههاز سظر تسکنیکیو کایواولویتسیشترودایندو بسایدسریع
لنجام شوند
* عاك هآهادر (Iteration Planning, \ Sig pat pe ale ya
مشخصميشوند
27
صفحه 28:
|“ متدو لو زى -XP فر آور دهها رداس)
Metaphore *
* نشاندهنده یک تصوير کلی از سیستم است
* برای هر عنصر در سیستم یک نام در نظر گرفته میشود
" ارتباط بین عناصر در كير در سيستم از طريق 14612212076 مشخص
مى شود
Spike =
(Spike Solution) .p3 Joely Sy” پرنامه سادهایست که پوسیله
آن میتوان راهحلهای پالقوه را کشف گرد
" در مواردی که User Story ها حساس و مهمند از آن استفاده میشود
صفحه 29:
a متدولوژی XP — عملیات
Planning Game *
" یک تعامل محصور Gyshe Qe (Close Interaction) 9
پرنامهوپس پدست میآید
* پرنامهنویس کار لازم برای پیادهسازی گزارشهای مشنری را تخمین
میزند و مشتری در مورد حوزه و زمان نشرها تصمیمگیری میکند
Simple Design *
* تأکید اصلی در این روش بر روی طراحی سادهترین راهحل ممکن است
و پيچيدگيهای غیرضروری و کدهای اضافی به سرعت حذف میشوند
29
صفحه 30:
6 متدو لو زى ۳ - عملیات رد
Testing "
" توسعه نرمافزار یک فرآیند آزمایشگراست (91۲-0776ع۲)
" قبل از اینکه برنامهنویس یک خاصیت را اضافه کند. برای آن یک تست طراحی
میکند که بصورت پیوسته اجرا میگردد
Refactoring "
* بازسازی سیستم با حذف موارد تکراری. بهبود ارتباطات. سادهسازی و
افزايش انعطاف پذپری سیستم
Pair Programming "
" دونفر کد را روی یک کامپیوتر مینوبسند (بک کدنوپس و یک
متخصص استراتژی)
صفحه 31:
6 متدو لو زى ۳ - عملیات رد
Collective Ownership "
* هر فردی میتواند کد را در هر زمانی تغییر دهد
Continuous Integration "
* كد چدید در حداقل زمان ممکن به کد اولیه میپیوندد. بنابراین
سیستم دفعات زیادی در روز یکپارچه شده و ساخته میشود
* ۷۷۵۵۱40 ۲۲۵0۱۲
" حداکثر چهل ساعت کار در هفته کافی است
* این مورد اجباری است و بیشتر از این ساعات کار مجاز نمیباشد
31
صفحه 32:
59 متدو لو زى ۳ - عملیات رد
On- Site Customer *
* مشتری باید بصورت تمام وقت برای تیم توسحه در دسترس باشد
Coding Standards *
" قواعد كدنويسى بايد توسط برنامهنويسان رعایت شود و ارتباط بين
كدها مورد نوجه قرار كيرد
32
صفحه 33:
FDD (Feature Driven متدولوژی
Development 5
" نمام فرآيند توسعه نرم افزار را يوشش نمىدهد و بيشتر روى دو
فاز طراحی و پیادهسازی متمرکز میشود
* برای استفاده بهمراه سایر فعالیتهای یک پروژه توسعه نرمافزار
طراحی شده است و هیچ مدل فرآبند خاصی لازم ندارد
© مبتنی بر توسعه تکراری با انتخاب بهترین و موثرترین
فعالیتهاست
* روی جنبههای کیفتی تأکید دارد و شامل نشرهای محسوس و
پیگیری دقیق پیشرفت پروژه است
صفحه 34:
1 فر آیندهای ۳۳۳
* شامل پنج فرآیند ترتیبی است که از طریق آنها فعالیتهای
طراحی و پیادهسازی انجام میشود
Develop Butta a
an Overall {fm Features [tm Pin PY 1b Design Dy | ye} Bulla BY
سا tun Feature Feature Feature
* قسمت تکراری فرآبند ۳110 (طراحی و ساخت) از توسعه
چابک حمایت میکند
* هر تکرار از یک خاصیت. معمولاً 2 تا 3 هفته زمان میبرد
صفحه 35:
۷" متدولوژی (۲1(1 - نقشها
* 171210 نسقشایخود را بسه سه هسته کسلیتسقسیممیکسند
* نقشهای کلیدی
* نقشهای حمایتی
* ای ای ©
صفحه 36:
۷" متدولوژی (۲۲(1 - نقشهاي كليدي
مدير يروزه
معمار ارشد
مدير توسعه
بجي ۰
مالك كلاس (Class Owner)
: al Manager) متخصص دامنه
صفحه 37:
عمدو نورى TAD سسهاي
حمایتی
(Release Manager) yi مدير "
(Language Guru) (43 )9lio *
(Build Engineer) مهندس ساخت *
* مسئول ابزار («لاتسع1001)
" مدير سيستم 402151721019 درره:
37
صفحه 38:
7 متدولوژی FDD - نقشهاي اضافي
* سه نقش اضافی که در همه پروژهها وجود دارند
(Tester) 09335, $203) *
* مستقر کننده (Deployer)
* نویسنده فني ۱۷۲/۶۵ آههتصطه۲۵)
* هر عضو میتواند چندین نقش بازی کند و هر نقش ممکن است
به چند عضو نسبت داده شود
صفحه 39:
1 متدولوژی (۲1(1] - بهتوین تجربیات
Domain Object Modeling *
" شامل استخراج و توضیح دامنه مسأله میباشد
Developing By Feature "
" توسحه و بررسی میزان پیشرفت پروژه از طریق دنبال کردن
پیادهسازی ليست وظايف و خواص مشخص شده
Individual Class Ownership *
" برای هر کلاس شخصي وجود داشته باشد که مسئول سازگاری. کارایی
و صحت آن باشد
صفحه 40:
1 متدولوژی (۲1(1] - بهتوین تجربیات
Feature Teams *
" تیم كوچكي که بهصورت پویا شکل گرفتهاند
Inspection *
" استفاده از معروفترین و بهترین مکانيزهاي شناسايي خطاها
Regular Builds *
" تضمین اینکه هميشه يك سپستم قابل اجرا و قابل نمایش دادن
(126720) وجود دارد
Configuration Management *
* داشتن تاریخچه تفییرات و نسخههاي مختلف (پهمراه کد منبع)
صفحه 41:
a متدولوژی (1(1] - بهتوین تجربیات
Progress Reporting *
* روند اجراي فعالیتها به صورت کامل و در سطوح مختلف سازماني
گزارش شود
صفحه 42:
5 متدو لوژی 50۳۰
* از یک استراتژی در بازی راگبي اقتباس شده است
* تأکید روی اصول انعطافپذیری. سازگاری و سودمندی است
* تمرکز: جكونه اعضاى تيم بايد عمل كنند تا سيستم تولید شده. در
.يك محيط كاملاً تغييريذير. انعطاف يذيرى كافى داشته باشد
* ايده اصلى: توسعه سيستمها شامل جندين متغير محيطى و تكنيكى
است (نيازهاء زمان. منابع و تكنولوزى)كه احتمالاً در طول فرآيند
* این موضوع فرآیند توسعه را پیچیده و غیرقابل پیشبینی میکند
42
صفحه 43:
1" متدو لوژی 50۲۳0 - فر آوردهها
* فرآوردههای 5071270 به سه دسته اصلی تقسیم میشوند
Product Backlog *
Sprint Backlog *
~=_ Sprint BurnDown Chart *
لا
6
صفحه 44:
Scrum - Products 59) 9
Backlog
* شامل یک صف اولویتبندی شده است که در آن
وظیفهمنديهای تکنیکی و حرفه نمایش داده شدهاند که باید
توسعه داده شوند
* برای هر مورد مشخص شده در این فرآورده. خواصی مانند
وضعیت. اولوبت و تخمین کاری وجود دارد
صفحه 45:
متدولوژی] 50۲۱0 - ما5
Backlog
* مجموعهای از موارد حرفه و فني که برای تکرار جاری
(صمناه16۲] ۳۲۵1)) زمانبندی شدهاند در این فرآورده
نمایش داده میشوند
* نیازها در این فرآورده به وظایف تبدیل می شوند
* برای هر وظیفه یک شرح کوناه وجود دارد و مشخص میشود که
چه کسی مسئول انجام آن است و همچنین وضعیت و تعداد
ساعات باقیمانده تا تکمیل شدن هر وظیفه در اين فرآروده
مشخص میشود
صفحه 46:
Scrum - Sprint BurnDown متدولوزى
هن
* ساعات باقیمانده برای تکمیل شدن همه وظایف مربوط به یک
Sprint را در قالب یک گراف بصورت برجسته نمایش میدهد
Work Remaining (hous)
o 68 8 8 8 8 8 8
7 2 35 4 5 8 7 8 8 1011121314 15 16 47 18 19.20.24 22 20.24 25 26-27 28 29 30
‘Serum Day
صفحه 47:
۷" متدو لوژی 50۱1۳0 - نقشها
Scrum Master
Product owne: "i
Scrum team we 2 ج حا See
Manager معو
0
ory
1+41
صفحه 48:
Crystal oolgil& متدولوژیهای 4
* شامل مجموعهای از متدولوژيهای متفاوت است که مناسبترین
آنها برای هر پروژه منحصر به فرد انتخاب میشود
* دارای اصولی است که متدولوژیها را برای شرایط مختلف
موجود در پروژهها سفارشی میکند
Crystal (9) * پیشنهاد میکند که یک متدولوژی مناسب
براساس اندازه و میزان بحرانیبودن پروژه انتخاب شود
صفحه 49:
5 متدولوژيهاي خانواده ۲۱5۵1 (ادامه)
" هر عضواز خانواده 01375121 با يى رنك مشخص مى شود كه
ميزان سنكينى متدولوزى را نشان مىدهد. رنك تاريكتر نشان
دهنده متدولوزى سنكين تر است
C: Comfort
D: Discretionary
Money
E: Essential
Money
L: Life
of
شالك تالت
of the
system
49
صفحه 50:
5 متدولوژيهاي خانواده ۲۷5۵1 (tot)
* تمامی پروژهها از توسعه افزایشی با بازه زمانی حداکثر 4 ماه
استفاده میکنند
* تأکید روی ارتباطات و همکاری بین افراد درگیر در پروژه است
* هیچ فعالیت با ابزاری را برای توسعه محدود نمیکند
* مثلاً میتوان از فعالیتهای 26۳ و 962۳90 با هم در این روش استفاده
کرد
صفحه 51:
at مزایای روشهای سریع الانتقال
* تأکید روی شرکتدادن مشتری در پروژهها است که در
پروژههای کاربردی بسیار مفید است
* تأکید روی کارگروهی و ارتباط متقابل که در بالا بردن راندمان
کاری نقش مهمی دارد
۴ همه افراد درگیر در پروژه در قبال کیفیت محصول مسئولند
* سنجش مستمر کارهای انجام شده از مزابای بسیار مفید این
روشها است
51
صفحه 52:
at مزایای روشهای سریع الانتقال (داس)
* توسعه افزایشی که با روشهای مدرن توسعه نرمافزار سازگار
است
* طراحی ساده و روشن برای فرآیند توسعه
* بازبینیهای مستمر که به بالا رفتن کیفیت کار برنامهنوبسان
کمک میکند
صفحه 53:
5 معایب روشهای سریع الانتقال
* بدليل كمبود فعاليتهاى طراحى در اين روشهاء اكر كد بيش از
جند هزار خط باشد ممكن است فرآيند توسعه با موانع
خطرناكى برخورد كند
" كمبود مستندات مربوط به طراحى در اين روشها آنها را به
پروژههای کوچک محدود میکند و قابلیتهای استفاده مجدد را
در آنها محدود میکند
* کمبود فرآیندهای بازبینی ساختیافته
صفحه 54:
5 معایب روشهای سریع الانتقال «دامه)
" كمبود فرآيند طراحى منظم و استفاده از بازبينىهاى غير
ساخت يافته باعث اتلاف زمان و هزينه مى شود
" كمبود طرح كيفيت. در اين روشها هيج نوع طرح استانداردى
برای ارزیابی کیفیت وجود ندارد
* کمبود راهنماهای آموزشی برای استفاده از این روشها