سمینار کارشناسی ارشد
مهندسی کامپیوتر - مهندسی نرم افزار
مقدمه
وجود یک روش توسعه مناسب برای یک پروژه ی نرم افزاری از اهمیت ویژه ای برخوردار است. در دهه های اخیر تلاشهای متنوعی برای رسیدن به یک روش توسعه خاص که توان پشتیبانی از انواع محیطهای توسعه را داشته باشد، صورت پذیرفته است. اما محیطهای توسعه مختلف، ویژگیهای متفاوتی دارند که ارائه ی روش توسعه ای که تمام آنها را پوشش دهد، تا حدودی دشوار میشود. برای همین موضوع روش توسعه های توسعه برای محیطهای با شرایط خاص ارائه میشوند [42].
روشهای طرح رانه و روشهای چابک دو سبک از روشهای توسعه هستند که محیطهای توسعه متفاوتی را مخاطب قرار میدهند و تقریبا در محیطهای مربوطه شان موفق هستند. اما محیطهایی نیز وجود دارند که تلفیقی از ویژگیهای این محیطها را شامل میشوند و روش توسعه مناسبی برای آنها گزارش نشده است. در کنار این موضوع، هر دوی روشهای توسعه طرح رانه و چابک ضعف هایی دارند و به تبع آن برخی از فاکتورهای اساسی یک پروژه ی نرم افزاری را در نظر نمیگیرند. از دیدگاه Beck این چهار فاکتور کیفیت، زمان، بودجه و حوزه مسئله هستند. در این سمینار در پی بررسی روشهای توسعه ای برای برآوردن این فاکتورها خواهیم بود.
در فصل اول، فاکتورهای محیطی پروژه را بررسی کنیم. به چرخه معماری نرم افزار در فصل دوم پرداخته میشود. روشهای چابک در فصل سوم تشریح میشوند و فصل چهارم در برگیرنده ی تلفیق روشهای چابک و معماری میباشد
فصل اول
متغیرهای محیطی پروژه نرم افزاری
متغیرهایی که یک پروژه نرم افزاری با آنها مواجه است، متفاوت هستند. در اینجا، به دیدگاه Beck1 استناد میکنیم. Beck
به چهار متغیر اساسی در یک پروژه نرم افزاری اشاره دارد [1] که این متغیرها عبارتند از کیفیت2، بودجه3، زمان4 و حوزه
مسئله5. در نتیجه، روشها و تکنیکهای مورد استفاده در توسعه نرم افزار بایستی به گونه ای باشند که بتوانند از عهده ی این
متغیرها که ممکن است سرنوشت پروژه را دستخوش تغییرات کنند، برآیند. در ادامه به بررسی جزئی تر این متغیرها در
حیطهی تولید نرم افزار میپردازیم.
کیفیت از فاکتورهای اساسی یک پروژه ی نرم افزاری به حساب میآید. کیفیت معمولا در قالب نیازهای غیر وظیفه مندی
مطرح میشود و از دغدغه های کاربران و مشتریان به شمار میرود. محصول نرم افزاری که نیازهای وظیفه مندی را برآوردهکند ولی برآورنده ی نیازهای غیر وظیفه مندی و کیفی نباشد، معمولا با نارضایتی مشتریان همراه میشود. مثلا نرم افزاری را
تصور کنید که از کارآیی و زمان پاسخ مناسبی برخوردار نباشد و یا از نظر امنیتی دچار مشکلات بالقوه ای باشد که سازمان
استفاده کننده را با مخاطرات جدی روبرو کند. به احتمال قوی چنین نرم افزاری در سازمان گوشه نشین و بلا استفاده خواهد
بود.
در سالهای اخیر، ویژگیهای کیفی6 در حیطه ی معماری نرم افزار مطرح شده اند [2]. معماری نرم افزار که با پیچیده وحجیمتر شدن نرم افزارها بیشتر از قبل مورد توجه قرار گرفته است، بحث ویژگیهای کیفیتی نرم افزار را نیز مدنظر قرار میدهد. البته این بدان معنا نیست که هر روش طراحی معماری الزاما ویژگیهای کیفی را مدنظر دارد. روشهای اولیهی ایجاد معماری [3] معمولا بحث ویژگی کیفی را در معماری لحاظ نمی کردند و هدف آنها رسیدن به وظیفه مندی سیستم مورد نظر بود. این روشها معمولا روشهایی پایین به بالا بودند. آنها با استخراج کلاسهای طراحی بر مبنای مستندات تعریف نیازمندیها و یا موارد کاربری کار خود را آغاز مینموند و سپس با پکیج کردن این کلاسها کار خود را به اتمام میرساندند. نتیجه آن بود که Kent Beck از افراد مطرح در مباحث مهندسی نرم افزار و ابداع کننده ی روش extreme programming میباشد.
اساس کار بر وظیفه مندی سیستم قرار میگرفت و توجهی به ویژگیهایی همچون تغییر پذیری1، قابلیت حمل2، قابلیت
استفاده3 نمیشد. نتیجه ی چنین روشی برای ایجاد معماری یک سیستم ضعیف میباشد.
در مقابل روش ویژگی رانه ADD٤ [4] اساس کار خود را بر ویژگیهای کیفی قرار میدهد و جالب آنجاست که یک رویکرد بالا
به پایین را در طراحی معماری دنبال میکند. به طوریکه فرآیند طراحی معماری در ابتدا با یک مولفه ی کلی که همان نرم
افزار مدنظر است ، شروع میشود و بنا به نظر معمار نرم افزار به زیرسیستمها شکسته میشود. در فصل بعد ، این روش به طور
مفصل تشریح میشود.
زمان در پروژه های نرم افزاری یکی دیگر از فاکتورهای اساسی است که بیشتر از دیدگاه مدیریتی به آن توجه میشود. اما نکته آنجاست که در نهایت، تولید و توسعه ی نرم افزار توسط تحلیل گران، طراحان، برنامه نویسان و ... که از عوامل فنی پروژه نرم افزاری محسوب میشوند، انجام میپذیرد. همین موضوع جنبه ی زمانی فعالیتهای توسعه را نشان میدهد.
با توجه به اهمیت تحویل به موقع یک پروژه نرم افزاری و محیط اغلب ناشناخته ای که نرم افزار تحت آن توسعه مییابد که برخی اوقات طرحها و برنامه های از پیش تدوین شده را نقض میکند، کنترل زمان و زمان بندی نیازمند توجه نه فقط به طور مدیریتی و در ابتدای پروژه ، بلکه به طور پیوسته و در طول پروژه میباشد. روشهای توسعه مبتنی بر طرح یکپارچه معمولا به
گونه ای هستند که به دلیل زمانبندی ابتدا به ساکن، دچار اشکال در زمانبندی میشوند. روشهای مبتنی بر تکرار5 تا حدودی
بهتر هستند چراکه زمانبندی را به تکرارها میشکنند و سعی در کنترل تاثیر تغییرات بر زمانبندی و تحویل پروژه دارند.
بحث بودجه نیز مشابه زمان میباشد. مشکلات هر دوی این متغیرها در عدم ناتوانی در تخمین6 صحیح، ریشه دارند. روشهای
برآورد مختلفی تاکنون برای تخمین پروژه های نرم افزاری پیشنهاد شدهاند [5] که برخی تجربی و برآیند پروژه های انجام
شده در گذشته هستند و برخی نیز از اساس تئوریک بهره میبرند. در نهایت آنکه، با توجه به اینکه آینده و حوادث آن را
تاکنون نتوانسته ایم پیش بینی کنیم، مسئله ی برآورد زمان و بودجه نیز به عنوان متغیرهای چالشی باقی میمانند و بایستی
از روشهای منعطف تری در توسعه استفاده شود که تحمل کننده ی تغییرات در برنامه ریزیها و شرایط باشد.
فاکتور چهارمی که Beck به آن اشاره دارد و از متغیرهای تاثیرگذار پروژه میباشد، موضوع حوزه ی مسئله1 است. حوزه ی
مسئله چالش همیشگی مهندسان نرم افزار بوده است و دلیل اصلی آنجاست که معمولا مشتریان نمیدانند دقیقا در پی چه
هستند. ارتباط با مشتری و مهندسی نیازمندیهای2 او از بحثها و دشواریهای مهندسان نرم افزار است. عدم فهم صحیح از آنکه
مشتری واقعا چه میخواهد، باعث برنامه ریزی غلط، برآورد اشتباه و با احتمالاتی شکست پروژه را موجب میشود. نمونه
سازی3 و روشهای تکاملی4 پاسخی به این چالش به حساب میآیند.
در چند سال گذشته و به خصوص از سال 2000 میلادی ، توجه فراوانی به روشهای توسعه چابک5 به عنوان راه حل مقابله با
تغییرات در محیط متلاطم حرفه صورت گرفته است. از جمله ی این روشها، Scrum ،FDD ،XP و ... میباشند. این روشها با
توجه بیشتر به نظرات مشتری سعی در کنترل تغییرات و کسب سود حرفه دارند. یکی از تکنیکهایی که مورد استفاده در این
روشهاست، حضور مشتری به طور فعال در کنار تیم توسعه است. مشتری در برخی روشها به عنوان یک نقش فرآیند توسعه
میباشد و بخشی از کار به عهده ی اوست. با درگیر کردن مشتری تا این حد در توسعه ی سیستم ، یکی از فاکتورهای اصلی
ایجاد کننده ی تغییرات به جای مقابل تیم توسعه قرار گرفتن، در کنار تیم قرار میگیرد و از نظرات او به طور مکرر استفاده
میشود.
این چهار متغیر همانطوریکه گفته شده وابستگیهایی نیز با یکدیگر دارند مثلا تاثیر عدم شناخت حوزه مسئله در برآورد پروژه
مشخص است و یا هرچقدر تلاش برای رسیدن به کیفیت را افزایش دهیم، متعاقبا نیازمند زمان و بودجه ی بیشتری خواهیم
بود. وجود چنین وابستگیهایی ارائه ی راه حلهایی برای مهار این متغیرها را سخت تر و نیازمند توجه به تصمیمات اتخاذ شده
برروی فاکتورهای دیگری است که از آن راه حل متاثر میشوند و معمولا راه حلها در پی ایجاد یک تعادل6 بین فاکتورهای
مطرح شده میباشند.
با توجه به مطالب بالا، یکی از اهداف دست اندرکاران پروژه موفقیت در مهار این متغیرها میباشد. موفقیتی که در گرو استفاده از روشهایی است که توانایی لازم را در این خصوص داشته باشند. در مورد کیفیت به معماری نرم افزار اشاره نمودیم. در فصل دوم به طور مفصل به معماری نرم افزار و چرخه ی آن خواهیم پرداخت. روشهای چابک نیز تلاش خود را برای کنترل تغییرات و مقابله با تاثیرات آن دارند به همین جهت در فصل سوم به این روشها خواهیم پرداخت. در فصل چهارم نیز به بررسی امکان تلفیق این دو تکنیک؛ معماری نرم افزار و روشهای چابک برای پوشش دادن به چالشهای ذکر شده، میپردازیم.
فصل دوم چرخه معماری نرم افزار
در ابتدای این فصل به جایگاه معماری در فرآیند توسعه نرم افزار و سپس فعالیتهای معمارانه ی استفاده شده در چرخه معماری را بررسی و برخی از آنها را به جزء تشریح میکنیم.
1,2. جایگاه معماری در فرآیند توسعه نرم افزار
فرآیند توسعه ی نرم افزار به طور نوعی از فعالیتهای زیر تشکیل میشود که در شکل 2-1 نیز مشخص است.
تحلیل سیستم[1]
طراحی سیستم[2]
کد نویسی[3]
آزمون4
نگهداشت
(تصاویر و نمودار در فایل اصلی موجود است)
که فعالیتهای ایجاد و ارزیابی معماری معمولا در ابتدای طراحی سیستم انجام میشود. با نگاهی دیگر، معماری میتواند پر
کننده ی فاصله ی بین مرحله ی تحلیل و طراحی باشد. مرحله ی تحلیل که بیشتر به شناخت حرفه و نیازمندیهای مشتری
تاکید میورزد و طراحی که به طراحی سیستم مورد نظر اشاره دارد. این فاصله توسط معماری قابل پوشش است. همچنین
میتوان به معماری به صورت یک طراحی سطح بالا نگریست که برقراری ارتباط با آن به دلیل کمی جزئیات آسان میباشد.
معماری در مراحل مختلف توسعه نرم افزار قابلیت ایفای نقش دارد. طراحان سیستم به عنوان یک نگرش کلی و جهت دهنده
به تصمیمات طراحی بدان مینگرند. همانطوریکه قابل استنباط است، تصمیمات معماری، طراحی سیستم را تحت الشعاع قرار
میدهند. آزمون گران سیستم بر اساس معماری و پیشرانهای آن به آزمون سیستم نرم افزاری توسعه یافته، همت میگمارند تا
بررسی کنند سیستم توسعه یافته با معیارهای مورد انتظار تطابق کافی را داشته باشد. نگهدارندگان سیستم نیز به عنوان
نقشهایی که پس از انتشار و استقرار سیستم وظیفه ی نگهداشت را به عهده دارند، از مستندات معماری در این جهت بهره
میبرند.
در همین رابطه SEI[1] چرخه ی حیات حرفه معماری را ارائه میدهد که به موضوع معماری در توسعه سیستم های نرم افزاری و
نقش معمار نرم افزار میپردازد. در ادامه به تشریح این چرخه میپردازیم.
2,2. چرخه حرفه معماری نرم افزار[2]
فعالیتهایی که در به وجود آمدن معماری نرم افزار موارد زیر هستند.[3]
ایجاد مورد حرفه برای سیستم.
درک نیازمندیها.
ایجاد یا انتخاب معماری.
مستندسازی معماری و برقراری ارتباط با آن.
تحلیل یا ارزیابی معماری.
پیاده سازی سیستم بر مبنای معماری.
اطمینان از انطباق پیاده سازی با معماری.
در ادامه بطور مختصر به تشریح موارد بالا میپردازیم. ایجاد مورد حرفه برای سیستم . ایجاد مورد حرفه بیش از ارزیابی نیاز بازار میباشد بلکه مرحله ای در ارائه ی نیازمندیهای
آینده و مقید نمودن آنهاست. چقدر بایستی هزینه ی محصول باشد؟ بازار هدف چیست؟ زمان مورد نظر بازار چه موقع است؟
آیا نیاز به برقراری ارتباط با دیگر سیستمها میباشد؟ آیا محدودیتهایی هستند که سیستم بایستی در قالب آنها کار کند؟
این سوالاتی است که بایستی معمار سیستم در پاسخگویی به آنها نقش داشته باشد. اگر چه معمار به تنهایی نمیتواند به این
پرسشها پاسخ دهد اما عدم مشورت با معمار در این رابطه رسیدن به یک مورد حرفه مطلوب که برآورنده ی اهداف حرفه باشد
را دشوار و تا حدی غیر ممکن میکند.
درک نیازمندیها. گستره ای از تکنیکها برای شناخت و درک نیازمندیها وجود دارد، به عنوان نمونه میتوان به سناریوهای کاربری در تحلیل شئ گرا یا همان موارد کاربری[4] اشاره نمود. سیستمهایی که ایمنی در آنها از اهمیت ویژه ای برخوردار هستند از رویکردهای دقیق تری مانند ماشینهای حالت محدود[5] یا زبانهای مشخصات رسمی[6] برای این موضوع بهره میبرند.
تکنیک دیگری که در درک نیازمندیها میتواند کمک کننده باشد، تهیه ی نمونه میباشد. از آنجا که شناخت نیازمندیها
معمولا با اشکالاتی روبروست، این تکنیک چون مدلی واقعی از سیستم ارائه میدهد، میتواند کمک سرشاری به شناخت بهتر
برای توسعه دهندگان برساند.
با درک و شناخت نیازمندیها که نیازمندیهای غیر وظیفه مندی که ویژگیهای کیفی نیز نامیده میشوند، را نیز در بر میگیرد،
معمار نرم افزار میتواند تاکتیکهای مناسب را برای رسیدن به این ویژگیهای کیفی اتخاذ و در معماری سیستم لحاظ کند.
ایجاد یا انتخاب معماری. با توجه به اینکه مشتریان و کاربران از سیستم چه میخواهند، معمار نرم افزار بایستی یک نقشه
معماری برای سیستم تهیه کند. این معماری میتواند معماری یک سیستم مشابه باشد و معمار از آن بهره مند شود و یا آنکه
معماری سیستم از ابتدا طراحی شود. حال این سوال مطرح است که چگونه میتوان معماری یک سیستم نرم افزاری را طراحی
نمود؟ در بخش بعدی به تفصیل در این رابطه بحث میشود.
مستندسازی معماری و برقراری ارتباط با آن. زمانی که معماری سیستم ایجاد شد و به عنوان طراحی محوری پروژه در نظر گرفته شد میبایست ذینفعان سیستم، آن را مورد استفاده قرار دهند. بدین منظور معماری بایستی مستندسازی شود تا از یک مدل ذهنی و یا غیر رسمی در نزد معمار، به یک مستند رسمی در اختیار کلیه ذینفعان قرار گیرد و آنها بتواند با توجه به نوع مسئولیت و نیازشان از این مستند بهره ببرند. طراحان براساس این طرح بالادستی از سیستم به طراحی سیستم می پردازند. آزمون کنندگان نیز بر مبنای آن به طراحی موارد آزمون مناسب اقدام میکنند و باقی ذینفعان نیز فعالیتهای مشابهی را صورت میدهند.