مشاهده / بستن موضوعات

مهندسی نیازمندی ها در معماری سرویس گرا برای بانکداری خرد

دسته بندی: کامپیوتر
1683 بازدید

مهندسی نیازمندی ها یکی از ضروری ترین و حیاتی ترین مراحل تولید یک سیستم نرم افزاری است. بدون تعریف نیازمندی ها به صورت مناسب، توسعه دهندگان نمی دانند چه چیزی باید تولید کنند، مشتریان نیز نمی دانند باید چه انتظاری از سیستم داشته باشند و هیچ راهی برای اعتبار سنجی نیازمندی ها وجود نداشته و نمی توان تشخیص داد که سیستم تولید شده دقیقا نیازهای مشتری را تامین می کند.
مهندسي نيازمندي ها، پروسه اي است که اين اهداف و نيازمندي ها را با شناسايي ذينفعان و نيازهاي آنها و مستند سازي اين نيازها به گونه اي که قابل تحليل و پياده سازي باشند، مشخص مي کند.
هم چنین در معماری سرویس گرا، هر چه دسته بندی سرویس ها طبق کارکرد آنها منطقی تر و دقیق تر باشد و ماژولهایی مستقل از هم داشته باشیم که با واسطهای مناسب با یکدیگر تعامل کنند، سرعت تولید برنامه های کاربردی بالاتر رفته و هم چنین مدیریت تغییرات و نگهداری نیز کم هزینه تر می شود. و بدیهی است که دستیابی به چنین هدفی تنها با شناخت دقیق و کامل از سرویس ها و پروسه های کسب و کار به دست می آید که این خود حاصل اعمال پروسه مهندسی نیازمندی ها در یک سیستم سرویس گراست.
هدف از این تحقیق بررسی ضرورت و تاثیر مهندسی نیازمندی ها در یک معماری سرویس گرا و ارائه روشی نظام مند برای اعمال آن به صورتی موثر است.

 

 140صفحه فایل ورد (Word) فونت 14 منابع دارد قیمت 39000 تومان 

 

پس از پرداخت آنلاین میتوانید فایل کامل این پروژه را دانلود کنید

فهرست
1- فصل اول، معرفی 1
1-1- تعریف مساله 1
1-2- پیشینه تاریخی 2
1-3- روش تحقیق 4
1-4- ساختار پایان‌نامه 4
2- فصل دوم، مهندسی نیازمندی ها 6
2-1- مقدمه 7
2-2- نیازمندی چیست؟ 8
2-2-1- انواع نیازمندی ها 9
2-2-1-1- نیازمندی های کارکردی 9
2-2-1-2- نیازمندی های غیر کارکردی 11
2-2-1-3- نیازمندی های کاربر 17
2-2-1-4- نیازمندی های سیستم 19
2-3- پروسه مهندسی نیازمندی ها 20
2-3-1- مدلهاي فازهای پروسه مهندسی نیازمندی ها 21
2-3-1-1- مدل فعالیت Coarse-Grain 21
2-3-1-2- مدل فعالیت آبشاری 21
2-3-1-3- مدل فعالیت مارپيچي يا حلزوني 21
2-3-2- فازهای پروسه مهندسی نیازمندی ها 25
2-3-2-1- امکان سنجی 25
2-3-2-2- استخراج و تحلیل نیازمندی ها 27
2-3-2-3- مستندسازي نيازمندي ها 40
2-3-2-4- اعتبار سنجی نیازمندی ها 40
2-4- مدیریت نیازمندی ها 46
2-5- ضرورت مهندسی نیازمندی ها 48
2-5-1- بررسی تاثیر مهندسی نیازمندی ها بر کیفیت 51
2-5-1-1- کیفیت چیست؟ 51
2-5-1-2- مهندسی نیازمندی ها در کیفیت 53
2-5-2- بررسی تاثیر مهندسی نیازمندی ها در پیچیدگی 63
2-5-2-1- اجزای کلیدی در پیچیدگی نرم‌افزار 63
2-5-2-2- پیچیدگی ضروری در مقابل پیچیدگی عارضی 64
2-5-2-3- انواع پیچیدگی نرم‌افزار 66
2-5-2-4- علل پیچیدگی نرم‌افزار 68
2-5-2-5- مهندسی نیازمندی ها در پیچیدگی 70
2-5-3- بررسی تاثیر مهندسی نیازمندی ها در نگهداری 72
2-5-3-1- نگهداری اصلاحی 72
2-5-3-2- نگهداری تطبیقی 73
2-5-3-3- نگهداری تکمیلی 73
2-5-3-4- نگهداری پیشگیرانه 73
2-5-3-5- مهندسی نیازمندی ها در نگهداری 73
2-5-4- تاثیر مهندسی نیازمندی ها در سطوح مختلف نرم افزار 74
2-6- الزامات مهندسی نیازمندی ها 78
2-6-1- آشنایی با سازمان 78
2-6-2- تفهیم اهمیت و ضرورت مهندسی نیازمندی ها 78
2-6-3- ایجاد زیرساخت لازم و آشناسازی افراد برای مهندسی نیازمندی ها 79
2-6-4- آشنایی با ابزار و انتخاب مناسب 79
3- فصل سوم معماری سرویس گرا 84
3-1- مقدمه 85
3-2- پروسه‌های کسب و کار 90
3-2-1- انواع پروسه‌های کسب و کار 91
3-3- سرویس 94
3-3-1- اجزای تشکیل دهنده سرویس 94
3-3-1-1- قرارداد 95
3-3-1-2- واسط 95
3-3-1-3- پیاده‌سازی 96
3-3-1-4- منطق کسب و کار 96
3-3-2- ویژگی‌های سرویس 96
3-3-2-1- قابلیت استفاده مجدد 96
3-3-2-2- ارائه قرارداد مشترک 97
3-3-2-3- وابستگی کم میان سرویسی 97
3-3-2-4- تجرید 98
3-3-2-5- قابلیت ترکیب 99
3-3-2-6- خودمختاری 99
3-3-2-7- نداشتن وضعیت خاص 100
3-3-2-8- قابلیت کشف 101
3-4- المان های معماری سرویس گرا 102
3-4-1- Application frontend 102
3-4-2- سرویس 102
3-4-3- مخزن سرویس 103
3-4-4- گذرگاه سرویس 103
3-5- متدولوژی‌های معماری سرویس‌گرا 103
3-5-1- نقاط ورودی معماری سرویس‌گرا 104
3-5-2- SIMM (Service Integration Maturity Model) 107
3-5-3- SOM (Service Oriented Modeling Architecture) 107
3-5-4- CBM (Component Business Modeling) 109
3-6- چرخه حیات معماری سرویس‌گرا 110
3-6-1- مدل کردن 111
3-6-2- Assemble 113
3-6-3- استقرار 115
3-6-4- مدیریت 117
3-6-5- حاکمیت 119
3-7- ضرورت گرایش پروژه‌های بزرگ به معماری سرویس‌گرا 121
3-7-1- تقسیم پروژه به زیر پروژه‌های کوچک‌تر 121
3-7-2- رقابت 123
3-7-3- نگهداری 124
3-7-4- جداسازی کسب و کار و واسط کاربر 125
3-7-5- سفارشی‌سازی 126
4- فصل چهارم، مهندسی نیازمندی ها در معماری سرویس گرا 129
4-1- مقدمه 130
4-2- تعامل مهندسی نیازمندی ها و پروسه های کسب و کار 132
4-2-1- تاثیر مهندسی نیازمندی‌ها بر فرایندهای کسب و کار 132
4-2-2- تاثیر فرایندهای کسب و کار در نیازمندی‌ها و مهندسی نیازمندی‌ها 134
4-2-3- چرخه تکاملی تعامل مهندسی نیازمندی ها و فرایندهای کسب و کار 137
4-3- راهکار پیشنهادی 138

فهرست اشکال
شکل ‏2 1.انواع نیازمندی های غیر کارکردی 18
شکل ‏2 2. استفاده کنندگان مستند نیازمندی ها 23
شکل ‏2 3.مدل فعالیت Coarse-Grain 28
شکل ‏2 4. مدل فعالیت مارپيچي يا حلزوني 28
شکل ‏2 5.ورودي ها و خروجي ها 29
شکل ‏2 6. فازهای پروسه مهندسی نیازمندی ها 30
شکل ‏2 7. عملکرد مهندسی نیازمندی ها در استخراج نیازمندی ها 33
شکل ‏2 8. پروسه نمونه سازی 49
شکل ‏2 9. ذینفعان یک سیستم نرم افزاری 53
شکل ‏2 10. جایگاه مهندسی نیازمندی ها در چرخه تولید نرم افزار 54
شکل ‏2 11.ارتباط مدل های کیفیت 56
شکل ‏2 12. چرخه حیات نرم افزار 58
شکل ‏2 13. تاثیر مهندسی نیازمندی ها بر کیفیت 66
شکل ‏2 14. تاثیر مهندسی نیازمندی ها در سطوح مختلف نرم افزار 79
شکل ‏3 1. عوامل معماری سرویس گرا 89
شکل ‏3 2. روابط بین پروسه های کسب و کار و سرویس ها 92
شکل ‏3 3. اجزای تشکیل دهنده سرویس 106
شکل ‏3 4. المان‌های معماری سرویس‌گرا 114
شکل ‏3 5. نقاط ورودی به معماری سرویس گرا 116
شکل ‏3 6. چرخه حیات معماری سرویس گرا 121
شکل ‏3 7. فاز مدلسازی در چرخه حیات معماری سرویس گرا 124
شکل ‏3 8. فاز assemble در چرخه حیات معماری سرویس گرا 126
شکل ‏3 9. فاز استقرار در چرخه حیات معماری سرویس گرا 128
شکل ‏3 10. فاز مدیریت در چرخه حیات معماری سرویس گرا 130

فهرست جداول
جدول ‏3 1. فعالیت های فاز مدل 123
جدول ‏3 2. فعالیت های فاز assemble 125
جدول ‏3 3. فعالیت های فاز استقرار 127
جدول ‏3 4. فعالیت های فاز مدیریت 129

 

 

در ایران، مهندسی نیازمندی ها چندان شناخته شده نیست و متاسفانه بر خلاف قدمت 18 ساله ای که این نظریه دارد، تنها در سال های اخیر شاهد گرایش متخصصان به این مفهوم مهم هستیم.
از اوسط سال 1970، مهندسی نیازمندی‏ها بعنوان یک شاخه متمایز کاری و تحقیقی شناخته شده و تعاریفی برای آن ارائه شد. در ابتدا مهندسی نیازمندی‏ها بصورت مرحله اول مهندسی نرم‏افزار تعریف شد. در طول سال‏ها با تکامل تحقیقات مربوط به مهندسی نیازمندی‏ها، تعریف مهندسی نیازمندی‏ها وسعت یافت به طوری که کل چرخه‏ی حیات را در بر گرفت.
یک چارچوب متعارف برای فرایندهای مهندسی نیازمندی‏ها در قالب چهار فعالیت تکراری استخراج، تحلیل و مذاکره، تعیین مشخصات و تأیید اعتبار است. دیدگاه سنتی مهندسی نیازمندی‏ها بر کارکرد سیستم متمرکز است که به نیازمندی‏های کارکردی منجر می‏شود. اساس این نیازمندی‏ها فقط توابع/سرویس هایی هستند که باید توسط سیستم فراهم شوند. اما بعدها، تأکید بیشتری بر روی نیازمندی‏های غیرکارکردی شد. نیازمندی‏های کارکردی عموماً با استفاده از ورودی‏ها، پردازش، خروجی‏ها، کنترل‏ها، استثناها و موجودیت‏ها مشخص می‏شوند. معمول‏ترین تکنیک‏ها برای مشخص سازی نیازمندی‏های کارکردی عبارتند از: موارد استفاده، سناریوها ، نمودارهای جریان داده ، نمودارهای انتقال حالات. درحال حاضر، موارد استفاده پرکاربردترین تکنیک جمع‏آوری و مشخص‏سازی نیازمندی‏های کارکردی مخصوصاً در توسعه نرم‏افزارهای شی‏گرا است.
تمرکز بیشتر روش‏های سیستماتیکی که با نیازمندی‏های غیرکارکردی سروکار دارند، روی اهداف خاصی نظیر امنیت و کارایی است؛ اما چارچوب NFR می‏تواند روی نیازمندی‏های غیرکارکردی متنوعی اعمال شوند.
موضوعات مهندسی نیازمندی‏ها با اهداف کسب و کار، برنامه‏ریزی، فرایندها، توسعه و تکامل سیستم‏های درگیر دستیابی به مقاصد سازمانی مرتبط هستند. به دلیل ماهیت هدفمند نرم‏افزار و سهامداران چندگانه درگیر در سیستم نرم‏افزاری از روش‏های هدف‏گرا برای انجام مهندسی نیازمندی‏ها استفاده می‏شود. در این دیدگاه روی نیازمندی‏های غیر کارکردی تأکید بیشتری شده است.
از جمله کارهایی که در این زمینه صورت گرفته است، گردآوری مفاهیم مهندسی نیازمندی ها به صورت کلاسیک توسط Sommerville است. مهندسی نیازمندی ها به صورت هدف گرا مورد مطالعه قرار گرفته و مدل هایی نظیر Tropos برای آن پیشنهاد شده است. با گرایش به معماری سرویس گرا اخیرا مهندسی نیازمندی ها در این زمینه نیز مورد توجه قرار گرفته است.
در زمینه های مختلف سرویس گرایی و معماری سرویس گرا فعالیت های مختلفی صورت گرفته است. چرخه های حیات گوناگون، متدولوژی های مختلف و لایه های انتزاعی متفاوتی برای آن پیشنهاد شده است. ایده اصلی معماری سرویس گرا در واقع برگرفته از معماری شئ گرا و معماری مبتنی بر اجزا است. به این صورت که در این معماری توسعه دهندگان به سه گروه مستقل اما در تعامل با هم تقسیم می شوند. این سه گروه عبارتند از: سازندگان برنامه کاربردی یا درخواست کنندگان سرویس ، دلالان سرویس و توسعه دهندگان سرویس یا تامین کنندگان سرویس.
با نگاهی به مقالات و کتابهاي منتشر شده در حوزه معماري سرویس گرا متوجه می شویم که در بحث متدولوژي، بیشترین فعالیت و مطالب مربوط به IBM است. دو دلیل عمده این موضوع یکی سابقه این شرکت در ارائه و پشتیبانی متدولوژي معروف و بی رقیب RUP است و دلیل دوم آن پیشگامی و کیفیت برتر این شرکت در حوزه معماري سیستم هاي اطلاعاتی است.
1-3- روش تحقیق
1-4- ساختار پایان‌نامه
این پایان‌نامه، شامل پنج فصل است:
- فصل اول در رابطه با تعریف صورت مساله، حوزه و ساختار تحقیق بود.
- فصل دوم به معرفی مهندسی نیازمندی‌ها اختصاص دارد. در این فصل به بررسی قازهای پروسه مهندسی نیازمندی‌ها می‌پردازیم و ضرورت و تاثیر آن را روی کیفیت، نگهداری و پیچیدگی محصولات نرم‌افزاری بیان می‌کنیم.
- در فصل سوم به معرفی معماری سرویس‌گرا، اجزای سازنده آن و متدولوژی‌های ارائه شده برای آن می پردازیم. چرخه حیات آن را بررسی می‌کنیم و ضرورت گرایش پروژه‌های بزرگ به این معماری را مورد بررسی قرار می‌دهیم.
- در فصل چهارم به بیان جایگاه و تاثیر مهندسی نیازمندی‌ها در معماری سرویس‌گرا می‌پردازیم و برای امکان اعمال موثر و سیستماتیک مهندسی نیازمندی‌ها در این معماری پیشنهادهایی ارائه می‌دهیم.
- فصل آخر به نتیجه‌گیری و ارائه پیشنهادات برای کارهایی است که در این زمینه قابل انجام است.

 


2- فصل دوم، مهندسی نیازمندی ها

2-1- مقدمه
دشوارترین بخش ساخت یک سیستم نرم افزاری تصمیم گیری دقیق در مورد این است که چه چیزی باید ساخته شود. استنباط ، تحلیل ، و خوب نوشتن نیازمندیها سخت ترین بخشهای مهندسی نرم افزار هستند. و اگر اشتباهی در آن رخ دهد، از آنجایی که نتیجه این اشتباه در فازهای پایانی تولید محصول خود را نشان می دهد یا به طور کل باعث شکست پروژه می شود و یا هزینه سنگینی جهت اصلاح به همراه خواهد داشت.
در این فصل ابتدا به تعریف نیازمندی ها و انواع آن می پردازیم، سپس ضمن معرفی پروسه مهندسی نیازمندی ها به بیان ضرورت آن می پردازیم. 
2-2- نیازمندی چیست؟
نیازمندی های یک سیستم ، شرح و توصیف خدماتی است که انتظار می رود آن سیستم ارائه دهد . این نیازمندی ها، بازتاب احتیاجات مشتریان است که باید توسط سیستم برآورده شوند. کلمه "نیازمندی" در صنعت نرم افزار همواره به یک معنی به کار نمی رود. برخی مواقع نیازمندی یک تعریف کلی و ساده از یک سرویس است که سیستم باید فراهم کند ویا محدودیت های سیستم است. گاهی نیز بیانگر عملکرد سیستم با جزئیات زیاد و به صورت رسمی است.
نکته حائز اهمیت این است که نیازمندی ها از دید ذینفعان و کارگزاران مختلف ، متفاوت است. دسته ای از نیازمندی ها ، تعریفی است که مشتریان از سیستم دارند و معمولا به زبانی ساده است و همراه دیاگرام هایی توضیح می دهد که سیستم چه سرویس هایی را باید فراهم کند و تحت چه محدودیت هایی باید چه عملکرد هایی داشته باشد. دسته دیگر از نیازمندی ها، نیازمندی های سیستم است که کارکردها، سرویس ها و محدودیت های عملکردی سیستم را با جزئیات بررسی می کند. مستند نیازمندی های سیستم باید کاملا دقیق باشد و تعریف کند که دقیقا چه چیزی باید پیاده سازی شود. این مستند ممکن است قسمتی از قرارداد بین مشتری و تولیدکنندگان نرم افزار باشد.
در کل دسته بندی و گروه بندی نیازمندی ها و سطوح متفاوت در بیان کردن جزئیات اهمیت زیادی دارد چراکه مخاطبین مختلفی به طور متفاوت با آن ها سرو کار دارند. برای مثال در مورد کسانی که نیازمندی های مشتریان را بررسی می کنند نحوه پیاده سازی سیستم مهم نیست در حالیکه کسانی که نیازمندی های سیستم را مطالعه می کنند نیاز به اطلاعات کامل و دقیق از عملکرد سیستم دارند. چراکه باید بدانند سیستم باید دقیقا چه business rule هایی را پیاده سازی کند.

2-2-1- انواع نیازمندی ها
نیازمندی های سیستم را می توان به دو دسته کلی کارکردی و غیر کارکردی تقسیم کرد. نیازمندی های کارکردی به تشریح سرویس هایی که سیستم باید فراهم کند می پردازد و توضیح می دهد که سیستم باید چه رفتاری در قبال ورودی های مختلف داشته باشد ، وچگونه باید در شرایطی بخصوص رفتار کند. حتی در برخی مواقع ممکن است مشخص نماید که سیستم چه کاری نباید انجام دهد.
نیازمندی های غیر کارکردی، در واقع محدودیت ها و قیدهای روی سرویس ها و عملکرد سیستم هستند. این نیازمندی ها شامل محدودیت های زمانی و یا قیود قوانینی روی چرخه توسعه نرم افزار و استاندارد هستند. نیازمندی های غیر کارکردی معمولا مختص سرویس خاصی نیستند و به صورت یک چتر روی کل چرخه حیات یک نرم افزار قرار می گیرند و کلیه مراحل و قسمت ها را پوشش می دهند. باید توجه داشت در واقعیت ، مرزی به مشخصی و وضوح آن چه در بالا گفته شد بین نیازمندی های کارکردی و غیرکارکردی نیست. برای مثال طبق تعاریف بالا ، امنیت یک نیازمندی غیرکارکردی است. از طرفی وقتی بیشتر دقت می کنیم در توسعه نرم افزار برای تامین این نیازمندی ، نیازمندی های جدیدی که مشخصا کارکردی هستند ایجاد می شوند، مثلا نیاز به اهراز هویت و یا ایجاد امکانی برای کنترل سطوح دسترسی متفاوت کاربران متفاوت.
2-2-1-1- نیازمندی های کارکردی
نیازمندی های کارکردی توضیح می دهند که سیستم چه کاری باید انجام دهد. این نیازمندیها به نوع نرم افزار، به اینکه کاربران نرم افزار چه کسانی هستند و به نگرش و چارچوب کلی شرکت در نحوه نگارش نیازمندی ها بستگی دارد. این نیا.........................

 

 

 


2-2-1-4- نیازمندی های سیستم
نیازمندی های سیستم در واقع نسخه گسترش یافته نیازمندی های کاربر هستند که توسط مهندسین نرم افزار به عنوان نقطه آغازین برای طراحی سیستم استفاده می شوند. آن ها شامل جزئیات و شرح نحوه فراهم آوردن نیازمندی های کاربر توسط سیستم هستند.
شرح این نیازمندی ها باید دقیق بوده و برای کاهش ابهام این نیازمندی ها باید با یک زبان طبیعی و "ساخت یافته" که قابلیت دربرگیری جداول و مدل های سیستم را دارد بیان شوند

2-3- پروسه مهندسی نیازمندی ها
مهندسي نيازمندي ها مربوط است به شناسائي، مدلسازي، مرتبط سازي و مستندسازي نيازمندي ها براي يك سيستم و همچنين زمينه اي كه در آن سيستم به كار گرفته خواهد شد. نيازمندي ها چيزي را كه بايد انجام شود تشريح مي كنند ولي چگونگي پياده سازي آن را مشخص نمي كنند.
به طور کلی این پروسه چهارفاز دارد که مشخص می کنند آیا سیستم برای کسب و کار مفید است یا خیر و اگر هست نیازمندی های آن را کشف کرده و آن ها را به یک فرم استاندارد وتبدیل می کنند و در نهایت بررسی می کنند که آیا این نیازمندی ها واقعا سیستمی که مشتری خواسته است را تعریف می کند یا خیر.
امکان سنجی ، استخراج نیازمندی ها و تحلیل آن ها ، مشخصه سازی و مستندسازی نیازمندی ها و اعتبار سنجی . آن هاست
این فازها مي توانند در مدلهاي مختلف ارائه شوند. ابتدا چند مدل را به صورت اجمالی معرفی می کنیم و سپس در ادامه به تفصیل به شرح هرفاز می پردازیم.

2-3-1- مدلهاي فازهای پروسه مهندسی نیازمندی ها
متداول ترین مدل ها برای فازهای پروسه مهندسی نیازمندی ها به صورت زیر هستند که هر سازمانی معمولا با توجه به معیارهای داخلی نظیر تخصص کارکنان، نوع سیستمی که توسعه می دهد و استاندارهایی که استفاده می کند، این مدل ها را شخصی سازی می کند.
2-3-1-1- مدل فعالیت Coarse-Grain
اين مدل در شكل 2-3 نشان داده شده است. در شكل 2-3 نشانه هاي ابري شكل دلالت بر اين موضوع دارند كه مرز مشخصي بين فعاليت ها وجود ندارد.........................

 

2-5-2- بررسی تاثیر مهندسی نیازمندی ها در پیچیدگی
هنگامی که در مورد پیچیدگی نرم‌افزار صحبت می‌شود، اولین سوالی که باید پاسخ داده شود این است که «پیچیدگی چیست؟».
در حالت کلی، پیچیدگی نرم‌افزار میزان کار فکری مورد نیاز برای درک نرم‌افزار را مشخص می‌کند. پیچیدگی در فاز توسعه نرم‌افزار، تلاش مورد نیاز برای آزمون و اشکال‌زدایی برنامه، ماژول‌ها و زیرسیستم‌ها را به شدت تحت تاثیر قرار می‌دهد. در فاز نگهداری نرم‌افزار، پیچیدگی دشواری مکان‌یابی و تصحیح خطاهای کشف نشده‌ی پیاده‌سازی و همچنین میزان تلاش مورد نیاز برای تغییر ماژول‌هایی از برنامه که باید تصحیح شوند را مشخص می‌کند.
طبق تعریف IEEE، پیچیدگی، میزان سختی درک یا بازبینی یک سیستم یا مولفه که طراحی یا پیاده‌سازی شده است. عبارت سختی درک اشاره به این نکته دارد که پیچیدگی لزوماً مقیاس مطلق برای اندازه‌گیری نیست بلکه مقیاسی نسبی است، به این معنی که آنچه برای شخصی پیچیده بنظر می‌رسد می‌تواند برای دیگری براحتی قابل فهم باشد.
2-5-2-1- اجزای کلیدی در پیچیدگی نرم‌افزار
پیچیدگی برچسبی است که به متغیرهای وابسته زیاد در یک سیستم موجود داده می‌شود. هر چه متغیرها زیاد و وابستگی بین آنها زیادتر باشد سیستم پیچیده‌تر می‌شود. اتصال بین متغیرها ما را مجبور می‌کند که در آن واحد ویژگی‌های بسیار زیادی را در نظر بگیریم. به علاوه، غیرممکن است که بتوان فقط مسئولیت یک عمل را در سیستمی پیچیده عهده‌دار شد.
پیچیدگی چند جزء کلیدی دارد:
- مقیاس: تعداد اجزای سیستم نرم‌افزاری
- تنوع: گستره‌ی اجزای متفاوت تشکیل‌دهنده‌ی سیستم
- اتصال: ارتباطات بین مولفه‌ها
در پیچیدگی، مقیاس به تنهایی مطرح نیست. اگر ساختار سیستم با قاعده باشد، تعداد اجزای سیستم بصورت تحلیلی تعیین می‌شود و اگر تعداد اجزاء به اندازه کافی زیاد باشد بصورت آماری می‌توان آن را تعیین کرد. بنابراین مقیاس در کنار اجزاء دیگر پیچیدگی، درک سیستم نرم‌افزاری را دشوارتر می‌کند.
تنوع، تعداد انواع اجزایی را که باید تحلیل شوند افزایش می‌دهد. هر چه تنوع بیشتر باشد تلاش بیشتری برای درک هر جزء و ترکیبی از اجزاء لازم است.
اتصالات نیز دشواری درک یک سیستم را بیشتر می‌کنند. باافزایش مقیاس، تعامل بین اجزاء بصورت نمایی افزایش می‌یابد.
2-5-2-2- پیچیدگی ضروری در مقابل پیچیدگی عارضی
عملکرد ضروری، ناشی از نیازمندی‌هاست و در حقیقت مشخص‌کننده‌ی ماهیت چیزی است که سیستم باید انجام دهد. عملکرد ضروری می‌تواند مثلاً از سخت‌افزار به نرم‌افزار منتقل شود ولی نمی‌تواند حذف شود مگر با حذف نیازمندی‌های غیرضروری.
پیچیدگی ضروری، ذاتی و غیرقابل اجتناب است و در حقیقت از عملی نشات گرفته است که سیستم باید انجام دهد. پیچیدگی ذاتی با پیچیدگی الگوریتم سرو کار دارد و به مدل محاسباتی استفاده شده برای حل مسئله وابسته است که بصورت کمینه، پیچیدگی در بین تمام الگوریتم‌هایی که بعنوان راه‌حل ارائه شده‌اند، تعریف می‌شود. پیچیدگی ذاتی عموماً برحسب زمان و فضای مورد نیاز برای اجرا اندازه‌گیری می‌شود. کیفیت و کارایی طراحی و هزینه‌ی کلی پروژه در بهترین حالت از طریق پیچیدگی ذاتی تعیین می‌شود. فاکتورهای پیچیدگی ضروری با داشتن نیازمندی‌های صحیح، غیرمبهم، ضروری، کامل و با ثبات هم‌ارز است. بدیهی است که بزرگترین موضوع پیچیدگی ضروری، مهندسی نیازها و تحلیل است. اما در پیچیدگی عارضی تعداد و محدود موضوعات بسیار متنوع و گسترده‌ای از جمله فرآیند، سازمان، استاندارد و ... را دربرمی‌گیرد.
اما پیچیدگی عارضی از برنامه‌های کامپیوتری، فرآیند توسعه (برنامه‌نویسی کامپیوتری) یا از انتخاب‌های صورت گرفته در ساخت یک سیستم ناشی می‌شود. بعنوان مثال این نوع پیچیدگی می‌تواند از معماری نرم‌افزار، طراحی ساختمان داده، زبان برنامه‌نویسی و راهبردهای کدنویسی نشأت بگیرد. پیچیدگی عارضی با تصمیم‌گیری‌های درست قابل کاهش و هدف اکثر پیشنهادهای مطرح شده است. انتخاب‌های عاقلانه‌تر نیز می‌توانند در کاهش پیچیدگی عارضی موثر واقع شود.
پیچیدگی عارضی در حقیق نتیجه چگونگی ساخت نرم‌افزار است. بنابراین بهترین راه برای مقابله با پیچیدگی این است که ابتدا مسئله (چه چیز) را درست تعریف کرده و سپس بدنبال ایجاد یا انتخاب راه‌حلی (چگونگی) مناسب برای حل مسئله باشیم. این نوع پیچیدگی با توسعه سیستم سر و کار دارد و ویژگی‌هایی نظیر اندازه‌ی سیستم، تعداد ماژول‌ها، تعداد توابع در درون سیستم و اتصال بین ماژول‌ها می‌باشد.
فاکتورهای دخیل در پیچیدگی عارضی می‌توانند انتخاب معماری نرم‌افزار، تجربه و مهارت تیم نرم‌افزار، ابزارهای توسعه بکار رفته، منابع و فرصت آماده کردن مناسب بجای آماده‌سازی سریع باشند.
پیچیدگی عارضی می‌تواند با افزایش پیچیدگی ضروری افزایش یابد.
به عبارتی پیچیدگی به دو دسته زیر تقسیم می‌شود:
پیچیدگی مسئله: (پیچیدگی ذاتی یا پیچیدگی ضروری) که در طول فاز نیازمندی‌ها ایجاد می‌شود.
پیچیدگی‌ راه‌حل: (پیچیدگی افزوده یا پیچیدگی عارضی) که بعد از پیچیدگی مسئله مطرح می‌شود. این نوع از پیچیدگی، اساساً در مراحل توسعه نرم‌افزار بعد از فاز نیازمندی‌ها و در فازهای طراحی و تولید کد ایجاد می‌شود.......................

 

بلافاصله بعد از پرداخت موفق میتوانید فایل کامل این پروژه را با سرعت و امنیت دانلود کنید

قیمت اختصاصی و استثنایی این پروژه : تنها , 39000 تومان

 

 

 

 

 

قیمت قبلی : 490000 ریال

قیمت جدید : 39000 تومان  |   جهت خرید محصول بر روی تصویر روبرو کلیک نمایید :

خرید آنلاین این مطلب





0 نظر
نام:*
ایمیل:*
متن نظر:
پررنگ کج خط دار خط دار در وسط | سمت چپ وسط سمت راست | قرار دادن شکلک قراردادن لینکقرار دادن لینک حفاظت شده انتخاب رنگ | پنهان کردن متن قراردادن نقل قول تبدیل نوشته ها به زبان روسی قراردادن Spoiler
کد را وارد کنید: *