بسمه تعالی
فرآیند تولید نرم افزار در متدولوژیUSDP
2
اهداف جلسه
آشنائی با روش های مدرن توسعه نرم افزار
معرفی فرآیند تولید در متدولوژی USDP
درک تفاوت بین USDP و RUP
معرفی محورهای اصلی USDP
درک محصول بودن RUP
آشنائی با ابعاد RUP
3
فهرست مطالب
فرآیند تولید نرم افزار
روش های مدرن توسعه نرم افزار
روش های سنگین و سبک
مقدمه ای بر فرآیند USDP
محورهای اصلی USDP
RUP بعنوان یک محصول
معرفی ابعاد فرآیندRUP
4
فرآیند تولید نرم افزار
یک فرآیند تولید نرم افزار چهار نقش اساسی دارد
مشخص نمودن ترتیب فعالیت هایی که باید صورت گیرد تا نیازمندی های کاربران به یک محصول واقعی تبدیل شوند
بیان اینکه چه فرآورده هایی باید تولید شوند و در چه زمانی
تعیین روش اداره وظایف توسعه دهندگان منفرد و تیمی، نقش های مورد نیاز در پروژه و انتساب این نقش ها به اعضای تیم
فراهم نمودن معیارهایی (Software Metrics) برای اندازه گیری کیفیت محصولات پروژه و روند پیشرفت فعالیت های آن
5
فرآیند تولید نرم افزار (ادامه)
در فرآیند تولید که
موفقیت بستگی به تلاش طاقت فرسای اعضای تیم دارد
به خوبی مستند شده باشد
به خوبی مستند نشده باشد
نرم افزارهای مورد نیاز به صورت منظم و قابل پیش بینی قابل تولیدند
6
فرآیند تولید نرم افزار خوب
یکی از مشخصات بارز یک فرآیند تولید خوب استفاده از تجربیات بدست آمده از اجرای پروژه های نرم افزاری موفق است
7
تکرار و توسعه تدریجی
فرآیند آبشاری (Waterfall Process)
زمان
8
تکرار و توسعه تدریجی (ادامه)
هزینه ریسک در روش آبشاری
هزینه
زمان
9
تکرار و توسعه تدریجی (ادامه)
T I M E
Iteration 1
Iteration 2
Iteration 3
BM: Business Modeling
R: Requirements Analysis
A/D: Analysis & Design
C: Implementation
T: Test
D: Deployment
روش تکرار و توسعه تدریجی
10
تکرار و توسعه تدریجی (ادامه)
روش تکرار و توسعه تدریجی
11
تکرار و توسعه تدریجی – ویژگیها
تشخیص زود هنگام خطاهایی که در درک مساله، تحلیل یا طراحی رخ می دهند
تشخیص زودهنگام ناسازگاری های موجود بین تحلیل نیازمندی ها، طراحی و پیاده سازی
کاربر می تواند دائما از روند پیشرفت پروژه مطلع گردد
12
تکرار و توسعه تدریجی – ویژگیها (ادامه)
بوسیله این روش می توان روی قسمت های مهمتر پروژه متمرکز شد و از پرداختن به قسمت های کم اهمیت تر پرهیز نمود
آزمایش تکراری و مستمر امکان تشخیص بهتر روند پیشرفت پروژه را به ما می دهد
بارکاری (Workload) تیم ها، بخصوص آزمایش کنندگان، روی چرخه تولید پروژه به صورت متوازن توزیع می شود
13
مدیریت نیازمندی ها
نیازمندی ها عبارتست از شرطی یا قابلیتی که سیستم باید دارای آن باشد
مدیریت نیازمندی ها شامل
1) دریافت، سازماندهی و مستندسازی عملکرد مطلوب
سیستم و محدودیت های موجود
2) اعمال تغییرات مطلوب روی نیازمندی های جمع آوری شده
3) ردیابی و مستندکردن اثرات بوجود آمده و تصمیم های اتخاذ شده
یکی از ثابت ها در دنیای نرم افزار متغیر و پویا بودن نیازمندی هاست
14
مدیریت نیازمندی ها
ویژگیها
یک روش منظم و سیستماتیک برای مدیریت نیازمندی ها
در این روش می توان نیازمندی ها را اولویت بندی، فیلتربندی یا ردیابی نمود
امکان تشخیص واقعی و منصفانه عملکرد و کارایی سیستم وجود دارد
ناسازگاری ها به آسانی قابل کشفند
15
استفاده از معماری مبتنی بر مولفه ها
معماری سیستم عبارتست از تعیین ساختار کلی سیستم و روش هایی که این ساختار را قادر به تامین کلیه ویژگیهای کلیدی سیستم (cross-cutting concerns) می سازد
16
استفاده از معماری… (ادامه)
معماری سیستم شامل تصمیم گیری هایی در سطح کلان در موارد ذیل است:
نحوه سازماندهی سیستم نرم افزاری
انتخاب عناصر ساختاری و واسط های آنها + مشخص نمودن رفتار این عناصر
سازماندهی این عناصر در گروه های بزرگتر (زیرسیستم ها)
سبک معماری مورد استفاده
علاوه بر ساختار و رفتار سیستم، معماری با مواردی از قبیل کارایی، انعطاف پذیری، استفاده مجدد و محدودیت های تکنولوژی و اقتصادی نیز سروکار دارد
17
استفاده از معماری… (ادامه)
یکی از شیوه های مهم معماری نرم افزار، توسعه مبتنی بر مولفه ها است زیرا این روش امکان استفاده مجدد از آنها را به ما می دهد
ویژگیها
کمک در داشتن یک معماری کشسان
افزایش قابلیت استفاده مجدد از مولفه ها و تکنولوژی های موجود
مولفه، پایه خوبی برای مدیریت پیکربندی است
18
مدلسازی تصویری نرم افزار
مدل عبارت از یک توصیف ساده شده، با توجه به یک نگرش معین، از سیستم است
19
مدلسازی تصویری نرم افزار (ادامه)
ویژگیها
امکان توصیف سیستم با میزان دلخواهی از جزئیات
بوسیله مدل ها می توان طراحی سیستم را به صورت روشن و صریح بیان نمود
امکان تشخیص معماری های غیر قابل انعطاف و واحدبندی نشده
نرم افزار خوب حاصل مدل های با کیفیت بالا
20
بررسی کیفیت نرم افزار
هزینه اصلاح خطاها به صورت نمایی رشد می نماید
Cost
Development Deployment
Cost
برای رسیدن به یک نرم افزار با کیفیت قابل قبول باید فرآیند تشخیص کیفیت به صورت مستمر و پیوسته از همان مراحل اولیه تولید نرم افزار به اجرا درآید
21
بررسی کیفیت نرم افزار (ادامه)
ویژگیها
فرآیند تشخیص روند پیشرفت پروژه مبتنی بر واقعیت ها، نه بر حدس ها و محاسبات کاغذی خواهد بود
این فرآیند ناسازگاری های موجود بین نیازمندی ها، طراحی و پیاده سازی را آشکار می سازد
امکان کشف زود هنگام خطاها را به ما می دهد و بدین صورت هزینه اصلاح آنها بشدت کاهش می یابد
22
مدیریت پیکربندی
هنر تشخیص، سازماندهی و کنترل تغییراتی که برای نرم افزار در مدت کارکرد خود (از ابتدای تولید تا خارج شدن از عمل) رخ می دهند
یکی از مشکلات اساسی تولید نرم افزار مدیریت پیکربندی است
این مشکل بویژه در پروژه های بزرگ که در آن تیم های متعددی با یکدیگر بر روی تکرارها، نشرها، محصولات و سکوهای متفاوت کار می کنند، قابل مشاهده است
23
مدیریت پیکربندی (ادامه)
ویژگیها
یک روش سیستماتیک و قابل تکرار برای کنترل تغییرات نرم افزار
کنترل انتشار تغییرات
کاهش تداخل بین کار توسعه دهندگان که به صورت موازی با هم کار می کنند
نرخ تغییر معیار مناسبی برای تشخیص وضعیت فعلی پروژه است
24
متدولوژی های توسعه نرم افزار
متدولوژی های سنگین وزن (Heavyweight)
این نوع متدولوژی ها معمولاً مستندات، محصولات و فرآورده های بیشتری تولید می نمایند
متدولوژی های سبک وزن (Lightweight)
تاکید بر تولید محصول نهایی و نه فرآورده ها و مستندات بسیار است
25
مقایسه متدولوژی های سبک و سنگین
معیارهای مقایسه متدولوژی ها با یکدیگر
روش
معیار موفقیت
اندازه پروژه
سبک مدیریت
نحوه مستندسازی
چرخه ها
اندازه تیم
برگشت سرمایه
26
مقایسه متدولوژی ها – روش
روش های سریع الانتقال بصورت Adaptive یا سازگار عمل می کنند و با شرایط منطبق می شوند
روش های سنگین وزن بصورت پیشگو یا Predictive عمل می کنند و سعی می کنند در آغاز همه چیز را پیش بینی کنند
آیا همه چیز از ابتدا قابل پیش بینی است؟
27
مقایسه متدولوژی ها – معیار موفقیت
معیار موفقیت در روش های سریع الانتقال دستیابی به ارزش کاری (Business Value) است
در روش های سنگین وزن معیار موفقیت پیش رفتن در راستای طرح اولیه است
روش های سنگین وزن از نظر تغییر در فرآیند توسعه در حین پروژه انعطاف پذیری ندارند
28
مقایسه متدولوژی ها – اندازه
اندازه پروژه در روش های سریع الانتقال کوچک است
اندازه پروژه در روش های سنگین وزن می تواند بسیار بزرگ باشد
این مساله از محبوبیت روش های سریع الانتقال نمی کاهد
(آمار نشان می دهد که تعداد پروژه های کوچک بسیار بیشتر است)
29
مقایسه متدولوژی ها – سبک مدیریت
مدیریت در روش های سریع الانتقال بصورت غیرمتمرکز و آزاد است
در روش های سنگین وزن مدیریت بصورت مطلق و استبدادی است
مدیریت غیرمتمرکز امکان تصمیم گیری بهتر را در حین پروژه فراهم می کند
30
مقایسه متدولوژی ها – مستندسازی
مستندسازی در روش های سریع الانتقال بصورت بسیار محدود انجام می شود
در روش های سنگین وزن مستندسازی بصورت کامل و جامع انجام می شود
در بسیاری از موارد مستندسازی های سنگین, کار بسیار دشوار و زمانبری است
31
مقایسه متدولوژی ها – چرخه ها
تعداد چرخه ها (Cycles) در روش های سریع الانتقال بسیار زیاد است اما زمان آنها کوتاه است
در روش های سنگین وزن تعداد چرخه ها کم است ولی زمان آنها بسیار زیاد است
زمانبر بودن چرخه های تولید, موجب طولانی شدن زمان انتظار برای رسیدن به نشرها می شود
32
مقایسه متدولوژی ها – اندازه تیم
در روش های سریع الانتقال اندازه تیم کوچک است (بین 20 تا 30 نفر)
در روش های سنگین وزن اندازه تیم توسعه بزرگ است
خلاقیت و همکاری در تیم کوچک بسیار بیشتر خواهد بود
33
مقایسه متدولوژی ها – برگشت سرمایه
در روش های سریع الانتقال سرمایه خیلی زود در طول پروژه بر می گردد
در روش های سنگین وزن برای برگشت سرمایه باید تا انتهای پروژه صبر کرد
روش های سریع الانتقال از لحاظ اقتصادی بصرفه اند
34
معرفی USDP
یک فرآیند تولید مهندسی نرم افزار است که روشی منظم و سیستماتیک برای ترتیب انجام فعالیت ها در یک پروژه نرم افزاری را پیشنهاد می نماید
دارای یک چارچوب فرآیند (Process Framework) است
همه عناصر لازم برای تولید محصولات نرم افزاری از سیستم های سنتی و معمولی گرفته تا سیستم های هوشمند و سیستم های اطلاعاتی بزرگ را دربردارد
فرآیند USDP از مدل شی گرایی حمایت نموده و پایه روش های مدرن توسعه نرم افزار است
35
محورهای اصلی USDP
سه محور اصلی USDP
راهبری بر مبنای موارد کاربری (Use-Case Driven)
محوریت قرار دادن معماری (Architecture Centric)
استفاده از روش تکرار و توسعه تدریجی
(Iterative and Incremental Development)
36
راهبری بر مبنای موارد کاربری
مورد کاربری عبارت از دنباله ای از عملیات است که یک سیستم انجام می دهد تا یک نتیجه قابل مشاهده و ارزشمند برای کاربر فراهم نماید
سیستم باید چه عملکردهایی از خود را نشان دهد؟
در نگرش سنتی
سیستم، به ازای هر کاربر، باید چه عملکردهایی از خود را نشان دهد؟
در نگرش مبتنی بر موارد کاربری
37
راهبری بر مبنای موارد کاربری (ادامه)
راهبری بر مبنای موارد کاربری یعنی
38
RUP به عنوان یک فرآیند
Unified Software Development Process (USDP)
Rational Unified Process(RUP)
Is Customized to
(By Rational)
My Enterprise Process
Is Customized to
(By My Enterprise)
39
RUP بعنوان یک محصول
چون مستند سازی RUP بوسیله اسناد کاغذی میسر نیست از اسناد HTML استفاده شده است
راهنماهای لازم برای بکارگیری RUP به عنوان یک فرآیند تولید در مراحل مختلف تولید نرم افزار
راهنماهای ابزار (Tools Mentors)
الگوها (Templates)
یک Development Kit که چگونگی تغییر، گسترش و تنظیم ویژه RUP را نشان می دهد
40
RUP بعنوان یک محصول (ادامه)
41
معرفی ابعاد فرآیند RUP
می توان نگاه های ذیل را به فرآیند داشت:
1) جعبه سیاه (Black Box)
2) با توجه به مدت کارکرد مفید سیستم نرم افزاری
42
معرفی ابعاد فرآیند RUP (ادامه)
نرم افزار یک محصول فیزیکی که یک بار تولید و مستهلک می شود نیست، بلکه مانند یک موجود زنده ای که در سازمان تولد و رشد کرده و در دوران حیات خود باید با تغییر نیازهای سازمان و اهداف و ماموریت های آن خود را تطبیق دهد
43
معرفی ابعاد فرآیند RUP (ادامه)
مثال: زندگی انسان!
تولد و مرگ دارد
دارای دوره های گوناگون: کودکی، نوجوانی، جوانی، و پیری
هر دوره دارای ویژگیها و نیازهای مختص خود
در میان دوره ها نیازهای مشترکی زیادی وجود دارد
ولی شیوه برآوردن آنها از یکدیگر متفاوت است
همچنین میزان تاکید روی هرکدام متفاوت است
می توان دوران حیات نرم افزار را به زندگی انسان تشبیه کرد!!!
44
معرفی ابعاد فرآیند RUP (ادامه)
دوران حیات یک سیستم نرم افزاری شامل دوره های گوناگونی است
میان آنها فعالیت های مشترکی وجود دارد
در هر دوره به اندازه معینی روی هر کدام از این فعالیت ها تاکید می شود
هرکدام از این دوره ها می توانند فعالیت های ویژه خود را داشته باشند
45
معرفی ابعاد فرآیند RUP (ادامه)
در RUP دوران حیات یک نرم افزار به چهار مرحله آغازین، تشریح، ساخت و انتقال تقسیم می شود
سه مرحله اول شامل فعالیت های تولید یا توسعه نرم افزار بوده و مرحله چهارم دربردارنده انتقال نرم افزار به محیط واقعی و نگهداری آن است
46
معرفی ابعاد فرآیند RUP (ادامه)
3) دیدگاه دو بعدی
RUP یک فرآیند تولید دو بعدی است (برخلاف فرآیندهای تولید سنتی که یک بعدی هستند)
این ابعاد عبارتند از:
بعد (محور) عمودی: گردش کارهای اصلی را نشان می دهد
بعد (محور) افقی: ساختار چرخه تولید نرم افزار در RUP در بستر زمان را نشان می دهد
47
معرفی ابعاد فرآیند RUP (ادامه)
زمان
در یک تکرار همه گردش کارها اجرا می شوند
فعالیت های مشترک
فرآیند دو بعدی
48
معرفی ابعاد فرآیند RUP (ادامه)
49
پرسش و پاسخ