فرمت فایل: ورد –Word و قابل ویرایش تعداد صفحات: 152     فهرست مطالب   فصل اول- متغیرهاي محیطی پروژه نرم افزاري متغیرهاي محیطی پروژه نرم افزاري 6 فصل دوم- چرخه معماري نرم افزار 2- 1- جایگاه معماري در فرآیند توسعه نرم افزار ............... 12 2- 2- چرخه حرفه معماري نرم افزار.......... 13 2- 3- طراحی معماري ....... 16 2- 4- مستندسازي معماري ........... 18 2- 5- ارزیابی معماري........ 24 2- 6- برخی روشهاي ارزیابی مبتنی بر سناریو ...... 26 2- 6- 1- روش تحلیل معماري نرم افزار(SAAM) .......... 26 2- 6- 2- روش SAAM مبتنی بر سناریوهاي پیچیده (SAAMCS)....... 28 2- 6- 3- روش توسعه یافته SAAMیکپارچه شده با دامنه (ESAAMI)............ 29 2- 6- 4- روش SAAM براي تکامل و استفاده مجدد ..... 29 2- 6- 5- روش تحلیل معماري با دید تعادلی (ATAM). 30 2- 12- روش تحلیل هزینه و سود(CBAM) ....... 33 فصل سوم- چابکی 3- 1- چابکی در مقابل سنگین وزنی........... 37 3- 2- چابکی و فردگرایی.... 38 3- 3- بیانیه چابک.. 39 3- 4- روشهاي توسعه چابک ........... 40 41 .... Extreme Programming -1-4 -3 41... XP ارزشهاي -1-1-4 -3 3- 4-1-2- فعالیتهاي XP. 43 3- 4-1-3- نقشهایی براي افراد..... 49 فصل چهارم- تلفیق چابکی و معماري 4- 1- استفاده از معماري در روشهاي چابک............53 4- 1- 1- استعاره در XP... 53 4- 1- 2- مدل بالا دستی در FDD ........... 60 4- 1- 3- طراحی سطح بالا در Scrum... 61 4- 2- چابک سازي چرخه معماري ............ 62 4- 2- تزریق چابکی و معماري به روش جدید....... 63 منابع و مراجع....... 67     مقدمه وجود یک روش توسعه مناسب براي یک پروژه ي نرم افزاري از اهمیت ویژه اي برخوردار است. در دهه هاي اخیر تلاشهاي متنوعی براي رسیدن به یک روش توسعه خاص که توان پشتیبانی از انواع محیطهاي توسعه را داشته باشد، صورت پذیرفته است. اما محیطهاي توسعه مختلف، ویژگیهاي متفاوتی دارند که ارائه ي روش توسعه اي که تمام آنها را پوشش دهد، تا حدودي دشوار میشود. براي همین موضوع روش توسعه هاي توسعه براي محیطهاي با شرایط خاص ارائه میشوند [42]. روشهاي طرح رانه و روشهاي چابک دو سبک از روشهاي توسعه هستند که محیطهاي توسعه متفاوتی را مخاطب قرار میدهند و تقریبا در محیطهاي مربوطه شان موفق هستند. اما محیطهایی نیز وجود دارند که تلفیقی از ویژگیهاي این محیطها را شامل میشوند و روش توسعه مناسبی براي آنها گزارش نشده است. در کنار این موضوع، هر دوي روشهاي توسعه طرح رانه و چابک ضعف هایی دارند و به تبع آن برخی از فاکتورهاي اساسی یک پروژه ي نرم افزاري را در نظر نمیگیرند. از دیدگاه Beck این چهار فاکتور کیفیت، زمان، بودجه و حوزه مسئله هستند. در این سمینار در پی بررسی روشهاي توسعه اي براي برآوردن این فاکتورها خواهیم بود. در فصل اول، فاکتورهاي محیطی پروژه را بررسی کنیم. به چرخه معماري نرم افزار در فصل دوم پرداخته میشود. روشهاي چابک در فصل سوم تشریح میشوند و فصل چهارم در برگیرنده ي تلفیق روشهاي چابک و معماري میباشد.     فصل اول   متغیرهاي محیطی پروژه نرم افزاري     متغیرهایی که یک پروژه نرم افزاري با آنها مواجه است، متفاوت هستند. در اینجا، به دیدگاه Beck1 استناد میکنیم. Beck به چهار متغیر اساسی در یک پروژه نرم افزاري اشاره دارد [1] که این متغیرها عبارتند از کیفیت2، بودجه3، زمان4 و حوزه مسئله5. در نتیجه، روشها و تکنیکهاي مورد استفاده در توسعه نرم افزار بایستی به گونه اي باشند که بتوانند از عهده ي این متغیرها که ممکن است سرنوشت پروژه را دستخوش تغییرات کنند، برآیند. در ادامه به بررسی جزئی تر این متغیرها در حیطهي تولید نرم افزار میپردازیم. کیفیت از فاکتورهاي اساسی یک پروژه ي نرم افزاري به حساب میآید. کیفیت معمولا در قالب نیازهاي غیر وظیفه مندي مطرح میشود و از دغدغه هاي کاربران و مشتریان به شمار میرود. محصول نرم افزاري که نیازهاي وظیفه مندي را برآورده کند ولی برآورنده ي نیازهاي غیر وظیفه مندي و کیفی نباشد، معمولا با نارضایتی مشتریان همراه میشود. مثلا نرم افزاري را تصور کنید که از کارآیی و زمان پاسخ مناسبی برخوردار نباشد و یا از نظر امنیتی دچار مشکلات بالقوه اي باشد که سازمان استفاده کننده را با مخاطرات جدي روبرو کند. به احتمال قوي چنین نرم افزاري در سازمان گوشه نشین و بلا استفاده خواهد بود. در سالهاي اخیر، ویژگیهاي کیفی6 در حیطه ي معماري نرم افزار مطرح شده اند [2]. معماري نرم افزار که با پیچیده و حجیمتر شدن نرم افزارها بیشتر از قبل مورد توجه قرار گرفته است، بحث ویژگیهاي کیفیتی نرم افزار را نیز مدنظر قرار می- دهد. البته این بدان معنا نیست که هر روش طراحی معماري الزاما ویژگیهاي کیفی را مدنظر دارد. روشهاي اولیهي ایجاد معماري [3] معمولا بحث ویژگی کیفی را در معماري لحاظ نمی کردند و هدف آنها رسیدن به وظیفه مندي سیستم مورد نظر بود. این روشها معمولا روشهایی پایین به بالا بودند. آنها با استخراج کلاسهاي طراحی بر مبناي مستندات تعریف نیازمندیها و یا موارد کاربري کار خود را آغاز مینموند و سپس با پکیج کردن این کلاسها کار خود را به اتمام میرساندند. نتیجه آن بود که Kent Beck از افراد مطرح در مباحث مهندسی نرم افزار و ابداع کننده ي روش extreme programming میباشد. Quality Budget Time Scope Quality attribute اساس کار بر وظیفه مندي سیستم قرار میگرفت و توجهی به ویژگیهایی همچون تغییر پذیري1، قابلیت حمل2، قابلیت استفاده3 نمیشد. نتیجه ي چنین روشی براي ایجاد معماري یک سیستم ضعیف میباشد. در مقابل روش ویژگی رانه ADD٤ [4] اساس کار خود را بر ویژگیهاي کیفی قرار میدهد و جالب آنجاست که یک رویکرد بالا به پایین را در طراحی معماري دنبال میکند. به طوریکه فرآیند طراحی معماري در ابتدا با یک مولفه ي کلی که همان نرم افزار مدنظر است ، شروع میشود و بنا به نظر معمار نرم افزار به زیرسیستمها شکسته میشود. در فصل بعد ، این روش به طور مفصل تشریح میشود. زمان در پروژه هاي نرم افزاري یکی دیگر از فاکتورهاي اساسی است که بیشتر از دیدگاه مدیریتی به آن توجه میشود. اما نکته آنجاست که در نهایت، تولید و توسعه ي نرم افزار توسط تحلیل گران، طراحان، برنامه نویسان و ... که از عوامل فنی پروژه نرم افزاري محسوب میشوند، انجام میپذیرد. همین موضوع جنبه ي زمانی فعالیتهاي توسعه را نشان میدهد. با توجه به اهمیت تحویل به موقع یک پروژه نرم افزاري و محیط اغلب ناشناخته اي که نرم افزار تحت آن توسعه مییابد که برخی اوقات طرحها و برنامه هاي از پیش تدوین شده را نقض میکند، کنترل زمان و زمان بندي نیازمند توجه نه فقط به طور مدیریتی و در ابتداي پروژه ، بلکه به طور پیوسته و در طول پروژه میباشد. روشهاي توسعه مبتنی بر طرح یکپارچه معمولا به گونه اي هستند که به دلیل زمانبندي ابتدا به ساکن، دچار اشکال در زمانبندي میشوند. روشهاي مبتنی بر تکرار5 تا حدودي بهتر هستند چراکه زمانبندي را به تکرارها میشکنند و سعی در کنترل تاثیر تغییرات بر زمانبندي و تحویل پروژه دارند. بحث بودجه نیز مشابه زمان میباشد. مشکلات هر دوي این متغیرها در عدم ناتوانی در تخمین6 صحیح، ریشه دارند. روشهاي برآورد مختلفی تاکنون براي تخمین پروژه هاي نرم افزاري پیشنهاد شدهاند [5] که برخی تجربی و برآیند پروژه هاي انجام