Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

مناسب‌ترين روش براي توليد نرم‌افزارهاي کوچک :

  • نویسنده موضوع sting
  • تاریخ شروع
  • Tagged users هیچ

اطلاعات موضوع

Kategori Adı گرایش های کامپیوتر
Konu Başlığı مناسب‌ترين روش براي توليد نرم‌افزارهاي کوچک :
نویسنده موضوع sting
تاریخ شروع
پاسخ‌ها
بازدیدها
اولین پسند ارسالی
Son Mesaj Yazan sting

sting

معـاون ارشـد انجمـن
تاریخ ثبت‌نام
Jun 26, 2013
ارسالی‌ها
27,708
پسندها
5,661
امتیازها
113
محل سکونت
تهـــــــــــران
وب سایت
www.biya2forum.com
تخصص
کیسه بوکس
دل نوشته
اگه تو زندگی یکی از سیم های سازت پاره شد... آهنگ زندگیتو رو جوری ادامه بده هیچکس نفهمه به تو چی گذشت ، حتی اونیکه سیم رو پاره کرد!
بهترین اخلاقم
نــــدارم
سیم کارت
تیم ایرانی مورد علاقه
تیم باشگاهی مورد علاقه
تیم ملی مورد علاقه

اعتبار :

در حقيقت ساختن يک نرم‌افزار فقط نوشتن کدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي کاربران گرفته تا طراحي، نوشتن کد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي کوچک با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي کوچک نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با کيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمرکز استفاده کند. با استفاده از تکنيک‌هايي مفيد، از روش‌هايي مانند XP،Scrum و RUP مي‌توان رويه‌اي مناسب براي توليد نرم‌افزارهاي کوچک به‌وجود آورد.


همچنين مي‌توان از روش‌هايPSP و TSP نيز که براي توليد نرم‌افزارهاي کوچک مناسب هستند استفاده نمود و به‌وسيله اين روش‌ها کيفيت و قابليت‌هاي نرم‌افزارها را بالا برد و در حداقل زمان ممکن نرم‌افزار را تهيه نمود. اين مقاله با بررسي روش‌هاي جديد و متداول امروزي در توليد نرم‌افزار، بهترين و مناسب‌ترين روش توليد نرم‌افزارهاي کوچک را به شما نشان خواهد داد. گفتني است نوشتار حاضر نتايج تحقيقات من در گروه تحقيقاتي مهندسي نرم‌افزار دانشگاه ساندرلند انگلستان است و آمار و نتيجه‌گيري‌هاي آن براساس مصاحبه‌هاي انجام شده با چندين شرکت کوچک و بزرگ توليد نرم‌افزار آن کشور است.


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

انجمن IEEE رويه يا فرايند توليد نرم‌افزار را اين گونه تعريف مي‌کند: رويه توليد نرم‌افزار در واقع شامل مراحلي مانند جمعآ‌وري نيازهاي کاربران ، طراحي سيستم با استفاده از تحليل اين نيازها و نوشتن کدهاي نرم‌افزار با استفاده از طرح نرم‌افزار است. همچنين بر اين‌باور است که از آن جايي که کيفيت و بهره‌وري نيروي کار با کيفيت روند توليد نرم‌افزار ارتباط مستقيم دارد، طراحي و مديريت رويه توليد نرم‌افزار از اهميت شاياني برخوردار است.

براي طراحي يک رويه توليد نرم‌افزار مي توان از روش‌هاي متفاوتي استفاده نمود و از آن جايي که هر پروژه نرم‌افزاري با ديگر پروژه‌ها متفاوت است، مي‌توان گفت که رويه توليد آن پروژه نيز با ديگر پروژه‌ها تفاوت دارد. در واقع مي‌توان گفت: انتخاب اين روش‌ها رابطه مستقيمي با اندازه گروه در پروژه دارد و نرم‌افزارهاي بزرگ و کوچک نياز به رويه‌هاي توليد متفاوت دارند.

در ادامه اين مقاله روش‌هاي توليد نرم‌افزارها، به خصوص نرم‌افزارهاي نسبتاً کوچک که از گروه‌هاي توليد نرم‌افزاري کوچک‌تري استفاده مي‌کنند، بررسي مي‌شوند و مورد ارزيابي قرار مي‌گيرند.

روش SCRUM
در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌کنند که تمامي نيازهاي کاربران سيستم را درک کرده‌اند. اما هميشه نيازهاي کاربران سيستم در ابتدا مشخص نيست و کاربران ممکن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است که برنامه‌نويسان و طراحان سيستم هميشه از آن شکايت مي‌کنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد.

اين مدل حاوي مشکلات فراواني است که به صورت مستقيم به غيرقابل ‌انعطاف‌بودن اين مدل ارتباط دارد. اين مدل مانند يک جاده يک طرفه مي‌باشد که وقتي اتومبيل در آن حرکت مي‌کند، نمي‌تواند مسير خود را تغيير دهد و در جهت ديگري حرکت کند. در ابتداي کار کاربر سيستم ممکن است نظراتي در مورد سيستم داشته باشد ولي نمي‌تواند ببيند که سيستم چگونه کار خواهد کرد و در نتيجه ممکن است وقتي که سيستم آماده شد، از ساختار و کارايي آن راضي نباشد و تقاضاي تغيير در سيستم را بنمايد. در نتيجه اگر بتوانيم کاربر را از ابتدا در جريان ساخت نرم‌افزار قرار دهيم، ممکن است که اين مشکل حل شود؛ زيرا مي‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام کار اعلام کنند و در نتيجه از نرم‌افزار تهيه شده راضي باشد.

امروزه يکي از روش‌هاي توليد نرم‌افزار که به خصوص براي پروژه‌هاي نرم‌افزاري کوچک مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش که روشي به اصطلاح (iterative تکراري يا چرخشي) مي‌باشد، مي‌توان نرم‌افزارهاي کوچک را با کيفيت بالا تهيه نمود. در اين روش که به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد که به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشکل از هشت نفر است که با همکاري بسيار نزديک با يکديگر بازي مي‌کنند).


در اين روش هر عضو از گروه موظف به درک وظيفه خود در پروژه است و بايد يک هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال کند. لازم به ذکر است که در Scrum هر فاز عملياتي سيستم به Sprint مشهور است.

روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يک نقشه مقدماتي و يک معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يک سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند. انجام دادن هر Sprint ممکن است از يک تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار کاملي را به‌وجود ميآورند.

فهرست تکاليف در هر Sprint به Backlog مشهور است که تکاليف تيم عملياتي در هر Sprint را مشخص مي‌کند. اين Backlog در هر Sprint بروز مي‌شود و هر تکليف براساس اهميتي که دارد در فهرست تکاليف تعيين اولويت مي‌گردد. هر فرد در گروه يک کار يا تکليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي که يک Sprint شروع شد، ديگر انجام هيچ تغييري در تکاليف امکان ندارد و حتي درخواست‌کننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت.

البته درخواست‌کننده مي‌تواند از قسمتي از نرم‌افزار که بايد در هر مرحله توليد شود بکاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت که اين کار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد که اين نيز به هماهنگي بيشتر گروه کمک خواهد کرد. در اين جلسات که معمولاً به صورت روزانه است، سه گروه مي‌توانند شرکت کنند: گروه تهيه‌کننده نرم‌افزار، مديريت، و درخواست‌کنندگان نرم‌افزار.

در طول اين جلسات مسئول جلسه که اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد:

1- مسئوليت شما (تکاليف) از جلسه قبلي تاکنون چه بوده است و آيا توانسته‌ايد اين تکاليف را به اتمام برسانيد؟

2- در طول اين دوره به چه مشکلاتي برخورده‌ايد؟

3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟

مدير Scrum در حقيقت مسئوليت شناسايي تکاليف محوله به اعضا، بررسي روند تکميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي کم کردن ريسک در پروژه را داراست.

اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد که در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي کند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌کند که آيا مي خواهد به کار روي پروژه ادامه دهد يا انجام پروژه مذکور غيرممکن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد که در ابتداي پروژه نيازهاي کاربران به صورت دقيق مشخص نباشد و يک گروه کوچک مسئول پروژه نرم افزاري باشد.

نتايج تحقيقاتي که اواخر سال 2005 روي چندين شرکت توليدکننده نرم‌افزار در کشور انگلستان انجام دادم، نشان‌دهنده اين بود که شرکت‌هايي که از Scrum استفاده کرده بودند با حدود چهارصددرصد افزايش در بهره‌وري کار مواجه بودند. البته اين رقم در گروه‌هاي نرم‌افزاري مختلف متفاوت بود و مي‌توان گفت عوامل انساني از جمله مدير پروژه نقش بسيار مهمي در افزايش يا کاهش راندمان پروژه ها دارند.

شايد اين سؤال در ذهن شما به وجود آيد که چرا Scrum ممکن است براي توليد نرم‌افزارهاي کوچک راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي که در تيم‌هاي کوچک، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد.

معايب روش Scram
مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشکال نيز دارد. از جمله:

1- Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد.

2- برخي از برنامه‌نويسان حرفه‌اي ممکن است از تکاليفي که مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه کارشکني کرده و مشکل‌آفريني کنند.

3- از آنجا که مدير Scrum هم از نظر کيفي و هم کمي بايد پروژه را مديريت کند، Scrum نياز به مديريت بسيار قدرتمند دارد.

4- Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح کوچک) بايد اين روش را با روش‌هاي ديگر ادغام نمود. Scrum را از آن جهت مي‌توان روش خوبي برشمرد که روشي تحقيقي براساس تخمين، اولويت‌بندي، عملکرد گروه و بررسي نتايج است که اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت کامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي کوچک را به صورت بسيار محسوسي بالا ببرد.

روش XP
اشتباه نکنيد! منظور از روش اکس‌پي، ويندوزاکس‌پي نيست. اکس‌پي مخفف Extreme Programming يا برنامه‌نويسي سريع مي‌باشد که مانند Scrum روشي هوشمند در توليد نرم‌افزار است. در اکس‌پي دو برنامه‌نويس کار را انجام مي‌دهند و قبل از اتمام برنامه آن را چندين‌بار امتحان مي کنند. اکس‌پي در حقيقت روشي از توليد نرم‌افزار است که براساس آساني، ارتباط، واکنش و تصميم‌گيري سريع استوار است. شکل 2 اصول روش اکس‌پي را نشان مي‌دهد.

در روش اکس‌پي اعضاي گروه (که کاربر سيستم نيز عضوي از آن است) در ابتدا جلسه‌اي تشکيل مي‌دهند و اولويت‌هاي پروژه را مشخص مي‌کنند. اين گروه ممکن است از چند برنامه‌نويس، امتحان‌کننده نرم‌افزار يا Tester و تحليلگر سيستم تشکيل شود که با هم از ابتدا تا انتهاي پروژه همکاري مي‌کنند. معمولاً در اکس‌پي برنامه‌نويسان در گروه‌هاي دوتايي قرار مي‌گيرند و وظيفه تکميل قسمتي از برنامه را برعهده مي‌گيرند و هر دوي اين برنامه نويسان در مورد هر کدام از نيازهاي کاربران با هم بحث مي کنند و قدم به قدم کلاس هاي برنامه را آماده مي‌کنند.

بدين ترتيب که در ابتدا کلاسي را به صورت ابتدايي و بدون هيچ طراحي اوليه به وجود مي‌آورند و اين کلاس را امتحان مي‌کنند. در صورتي که اين کلاس فاقد هر گونه اشکال باشد، کد اصلي برنامه را بر آن اساس مي‌نويسند. وقتي يکي از برنامه‌نويسان مشغول نوشتن قسمتي از برنامه است، برنامه‌نويس ديگر وظيفه کنترل صحت اين کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نويسنده کد را مطلع مي‌کند.

مانند Scrum، در اکس‌پي نيز اعضاي گروه مي‌توانند روند تکميلي توليد نرم‌افزار را مشاهده کنند و در جريان کار قرار گيرند.اکس‌پي روش مناسبي براي مديريت پروژه‌هاي کوچک مي‌باشد که از دو تا ده برنامه‌نويس تشکيل شده است. اگر چه اصولاً اکس‌پي هيچ رويه خاص و مراحل پيوسته‌اي را مشخص نکرده اما مي توان گفت که اکس‌پي داري چهار مرحله اصلي مي باشد:

الف: مرحله زمانبندي پروژه: در اين مرحله اعضاي گروه با توجه به اندازه نرم‌افزار و کارايي آن برنامه زمانبندي را با هم تنظيم مي کنند.

ب: طراحي ابتدايي

ج: نوشتن کدهاي برنامه

د: امتحان‌کردن کدهاي نوشته شده

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

از جمله مزاياي اکس‌پي مي‌توان به اين نکته اشاره نمود که از آن جايي که يک برنامه‌نويس به صورت مستقيم کدهاي برنامه را کنترل مي کند، مي‌توان گفت که کيفيت نرم‌افزار توليدي بالا مي‌رود. همچنين مي‌توان گفت از آن جايي که دو برنامه‌نويس با هم کار مي‌کنند، آموزش کمتري نياز است و در نتيجه هزينه توليد نرم‌افزار پايين خواهد آمد. اما اين روش مشکلات خاص خود را نيز دارد. مثلاً تصورکنيد اگر در يک گروه، يک برنامه‌نويس تمايلي براي کار با برنامه نويس ديگري را نداشته باشد يا در يک روز يکي از دو عضو گروه غايب باشد يا ... در نتيجه چون نمي‌توان با يک برنامه‌نويس به ادامه کار پرداخت، اتمام پروژه با تأخير مواجه خواهد شد.

طبق نتايج تحقيقات به عمل آمده، وقتي يک برنامه‌نويس در کدهاي برنامه به دنبال اشکال مي گردد، حداکثر مي‌تواند ده تا پانزده‌درصد از اشکالات برنامه را پيدا کند. اما وقتي در روشي مثل اکس‌پي دو برنامه‌نويس با هم کار مي کنند و يکي از اين برنامه‌نويسان کدها را کنترل مي‌کند، بيست تا چهل‌درصد از اشکالات ساختاري برنامه خود را نشان مي‌دهد. اما با استفاده از روش‌هاي PSP و TSP که در ادامه اين مقاله توضيح داده مي‌شوند حتي مي‌توان تا هشتاددرصد اشکالات برنامه (که رقم بسيار خوبي است) را قبل نهايي‌شدن برنامه شناسايي و رفع کرد.

روشRational Unified Process) ‌RUP)

در اين بخش يکي از معروف‌ترين رويه‌هاي توليد نرم‌افزار که توسط شرکت آي‌بي‌ام طراحي گرديده‌است را معرفي مي‌کنيم. اين روش با نام Rational Unified Process) ‌RUP) در بسياري از پروژه‌هاي نرم‌افزاري به کار گرفته مي‌شود.
در حقيقت هدف اصلي RUP مطمئن‌شدن از اين موضوع مهم است که آيا نرم‌افزار توليدشده نيازهاي کاربرانش را به صورت کامل، با کيفيت بالا‌، در زمان معين و با بودجه مشخص برآورده کرده است يا خير.

مطابق تحقيقات انجام شده، از آن جايي که RUP به تمامي اعضاي تيم، اطلاعاتي مشترک مي‌دهد و تمامي اعضاي گروه با يک زبان مشترک با هم مرتبط هستند، بازده کاري گروه را بالا مي‌برد.

RUP داراي سه جزء اصلي است. جزء اول از مجموع راه‌حل‌هاي خوب که در رويه مي‌تواند مورد استفاده قرار گيرد تشکيل شده است. جزء دوم همان مراحل تهيه نرم‌افزار است و جزء آخر قسمت‌هاي تشکيل‌دهنده اين رويه مي باشد.

‌ ‌ RUP شش راه‌حل خوب که مي‌تواند در مراحل مختلف اين رويه به ما کمک کند را معرفي کرده است. از آن جمله:

1- استفاده از USE CASEها که مي‌توانند در جمعآوري نيازهاي کاربران مفيد باشند.

2- استفاده از معماري نرم‌افزار قابل تغيير‌ (‌component reuse)

3- استفاده از روش‌هاي تکميلي و Iterative براي کنترل بهتر و آسان پروژه نرم‌افزاري‌

4- استفاده از نمودارهاي UML

5- کنترل تغييرات در نرم‌افزار

6- کنترل کيفيت نرم‌افزار با توجه به درخواست‌هاي اوليه کاربران

شکل 3 رويه RUP را نمايش مي‌دهد. همان‌طور که در اين شکل مشخص شده است چرخه توليد نرم‌افزار به چهار قسمت اصلي تقسيم شده است:

الف: Inception phase يا مرحله آغازين:
در اين مرحله اهداف پروژه مشخص شده و درخواست‌هاي اوليه کاربران تعريف مي‌شود. از خروجي‌هاي اين مرحله مي‌توان به مدل اوليه Use Case، آزمون ريسک در پروژه و برنامه زمانبندي پروژه اشاره کرد.

ب: Elaboration phase يا مرحله مقدماتي:
در اين مرحله نيازهاي کاربران تحليل و بررسي شده و راه‌حل کلي طراحي سيستم ترسيم مي‌شود. از خروجي‌هاي اين مرحله مي‌توان از مدل کامل شده Use Case، فهرست نيازهاي کامل کاربران و طرح کلي سيستم نام برد.

ج: Construction phase:
يا مرحله ساخت و توسعه: در اين مرحله نرم‌افزار طراحي شده ساخته مي‌شود و به اصطلاح، کد برنامه نوشته شده و قسمت‌هاي مرتبط به هم ارتباط داده مي‌شوند. از خروجي اين مرحله مي‌توان از نرم‌افزار، راهنماي استفاده از نرم‌افزار و مستندات سيستم نام برد.

د: Transition phase يا مرحله تغييرات:
در اين مرحله اگر نرم‌افزار به وجود آمده در مرحله ساخت دچار مشکل شود، مشکل رفع خواهد شد.

تمامي مراحل توسط خطوط عمودي از همديگر جدا شده‌اند و هر مرحله با يک milestone يا نقطه مهم تمام مي‌شود. روش RUP با استفاده از مدل‌هاي مختلف همچنين مشخص مي‌کند چه کسي، چگونه و چه وقت چه کاري را انجام خواهد داد.

همان‌طور که در اين قسمت ذکر شد، روش RUP روشي انعطاف پذير، قابل تغيير و پيشرفته است که مي‌تواند در صورت استفاده صحيح، باعث افزايش کارايي و کيفيت نرم‌افزار توليدي گردد. اما آيا RUP مي‌تواند رويه خوبي براي توليد نرم‌افزارهاي کوچک باشد؟ در جواب بايد گفت که RUP را طوري طراحي کرده‌اند که بتواند براي انواع پروژه‌هاي نرم‌افزاري در هر اندازه مفيد باشد و از آن جايي که از ابزارهاي خوبي مثل UML نيز استفاده مي‌کند، UML) در گروه‌هاي کوچک که نرم‌افزارهاي کوچک طراحي مي‌کنند ابزار مدلي خوبي است) مي‌تواند باعث همکاري و هماهنگي بيشتر گروه گردد.

اما همان‌طور که در ادامه اين بحث خواهيد ديد، اگر بتوانيم رويه‌هاي ساده‌تر را با يکديگر ادغام کنيم، شايد بتوانيم راه حلي با کارايي بالاتري داشته باشيم.
روش هاي PSP و TSP
PSP يا Personal Software Process در حقيقت روش توليد نرم‌افزار نيست بلکه روشي است نوين که با ملزم نمودن اعضاي گروه پروژه‌هاي نرم‌افزاري به رعايت اصولي مشخص و استفاده از فرم‌ها و تکاليفي مشخص به آن‌ها کمک مي‌کند کارايي و بهره‌وري کاري خود را بالا ببرند. اين روش همچنين حاوي تکنيک‌هاي خوبي براي کنترل، ا‌ندازه‌گيري و تشخيص اشکالات مي‌باشد که مي‌تواند به شخص (مثلاً برنامه‌نويس) کمک کند تا مثلاً با اندازه‌گيري نرم‌افزار، يادداشت ميزان فعاليت روزانه و ساعات هدر رفته، و اشکالات به وجود آمده، مشکلات را حل کند و در نتيجه بهره‌وري خود را بالاتر ببرد. TSP يا Team Software Process مانند PSP است، ولي براي يک تيم طراحي شده و با طرح روش‌هاي منظم جهت کنترل و جمع‌آوري اطلاعات روزانه به اعضاي تيم کمک مي‌کند تا کارايي خود را بالا ببرند.

راه‌حل‌هاي پيشنهادي
تا اين قسمت با برخي از روش‌هاي توليد نرم‌افزار آشنا شديم. اگر دقت کنيد تمامي اين روش‌ها و رويه‌ها مي‌توانستند براي توليد نرم‌افزارهاي کوچک مورداستفاده قرار گيرند، اما در ادامه مقاله با چند روش‌ جديد آشنا خواهيد شد که در چندين گروه نرم‌افزاري کوچک مورد آزمايش قرار گرفته‌اند و در تمامي موارد بازدهي درخور داشته‌اند. در واقع نمي‌توان گفت تمامي روش‌هاي زير روش‌هاي جديدي هستند، بلکه برخي از آن‌ها از ادغام روش‌هاي بالا به وجود آمده‌اند.

روش RUP + Scrum
همان‌طور که قبلاً اشاره شد، روش Scrum روشي آسان براي توليد نرم‌افزار است که مديريت پروژه و نظم موجود در آن مي‌تواند بسيار کارگشا باشد. حال تجسم کنيد که روش RUP را اجرا و قسمت‌هايي از Scrum را در آن ادغام کنيم. پس از اين کار متوجه خواهيد شد که روش RUP مي‌تواند از مدل Scrum کمک بگيرد و با ادغام اين دو مي‌توان پروسه‌اي منظم براي توليد نرم‌افزارهاي کوچک سازماندهي کرد. اما همان‌طور که مي‌دانيد نمي‌توان دو رويه ناهمگون را با هم ترکيب نمود. آيا RUP و Scrum با هم شباهت‌هايي دارند؟

همان‌طور که قبلاً بيان شد، هر دو رويه ساخت نرم‌افزار روش حلقه‌اي تکرارکننده يا Iterative را خط مشي خود قرار داده‌اند(البته در RUP تعريف بهتر و کامل‌تري از Iterative شده است). در Scrum تعريف نيازهاي کاربران توسط اعضاي تيم انجام مي‌پذيرد، اما در RUP تنها يک شخصRequirement Engineer) يا مهندس مسئول نيازهاي کاربران) است که اين مسئوليت را برعهده دارد. در زمينه مدل سيستم اگر چه Scrum مسئوليت انجام اين کار را به تمامي اعضاي گروه داده است، اما هر دو روش از مدل UML پشتيباني مي‌کنند و استفاده از آن را پيشنهاد مي‌دهند.

ضمناً هر دوي اين روش‌ها روش‌هاي هوشمند و Iterative هستند که مديريت و اندازه گيري کيفيت نرم‌افزار در تمامي مراحل اين رويه‌ها به خوبي ديده مي‌شود. همچنين هر دوي اين روش‌ها انجام تغييرات را در طول پروژه مجاز مي‌دانند. البته همان‌طور که در قسمت Scrum توضيح داده شد، اين روش تغييرات را در طول مراحل Sprint مجاز نمي‌داند، اما مدير Scrum مي‌تواند تغييرات درخواستي توسط کاربران را جمعآوري و در جلسه بعدي مطرح نمايد.

به تازگي RUP نيز ابزارهاي جديدي مانند RUP Builder و RUP modeller را عرضه کرده که به مديران پروژه‌ها اجازه مي‌دهد تا برخي از اصول Scrum را درRUP اجرا کنند. در نتيجه اين دو پروسه توليد نرم‌افزار مي‌توانند به کمک بيايند و روشي مناسب براي توليد نرم‌افزارها به‌خصوص در اندازه کوچک باشند.


روش RUP + XP
روش دومي که مورد آزمايش قرار گرفت، تلفيقي بود از اکس‌پي و RUP. ولي مي‌توان گفت ادغام اين دو رويه بسيار متفاوت است.

RUP رويه‌اي بسيار سنگين و اکس‌پي روشي بسيار سبک است. مي‌دانيد که RUP را مي‌توانيم تقريباً براي تمامي نرم‌افزارهاي کوچک و بزرگ به کار برد. اکس‌پي نيز همانند RUP براساس Iterationها يا مراحل پيوسته مانند تحليل، طراحي و امتحان نرم‌افزار استوار است.

از آن جايي که RUP و اکس‌پي از اساس با هم تفاوت‌هاي زيادي دارند و اکثراً تصور مي‌کنند که RUP راه‌حلي براي توليد نرم‌افزارهاي بزرگ و اکس‌پي براي توليد نرم‌افزارهاي کوچک است، ممکن شما هم تصور کنيد که استفاده همزمان از هر دوي اين روش‌ها کاردرستي نيست.

اما مطابق تحقيقات انجام شده به نظر مي‌رسد که براي توليد نرم‌افزارهاي کوچک روشي بين RUP و اکس‌پي نياز است.در نتيجه با اضافه‌کردن برخي از تکنيک‌هاي اکس‌پي به RUP مي‌توان به رويه‌اي مناسب‌تردست يافت. قبلاً نيز محققاني روي RUP کار کرده‌اند تا آن را براي پروژه‌هاي کوچک مناسب سازند. مثلاً در سال 2000 يک نسخه از RUP به نام dX معرفي گرديد که RUP مختصر شده‌اي بود. براي نرم‌افزارهاي کوچک (که اعضاي پروژه اغلب در يک محيط کار مي‌کنند) اکس‌پي مي‌تواند روشي بسيار خوب باشد، اما اگر اعضاي تيم پراکنده باشند و سيستم بخواهد توسعه يابد، اکس‌پي قادر به جوابگويي نيست و مي‌توان گفت که با استفاده از قسمت‌هايي از روش قدرتمند RUP مي‌توان به اکس‌پي کمک نمود.

براي تلفيق اين دو روش تصورکنيد که پروژه‌اي شروع شده است. در مرحله Inception يا آغازين مي‌توان از تکنيک‌هاي اکس‌پي در زمينه برنامه‌ريزي زماني و جمع آوري نيازهاي سيستم استفاده نمود. البته نمي‌توان گفت که هميشه اين دو روش با هم سازگار هستند. مثلاً در اکس‌پي مرحله‌اي به نام طراحي يا Design Phase وجود ندارد. در صورتي که RUP يک مرحله مجزا براي اين قسمت دارد.

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

رويه Iterative يکي از اين روش‌ها است. با استفاده از اين رويه دو نوع محصول به نام‌هاي Actual و by-product توليد مي‌گردد. در واقع محصولاتي که در موفقيت پروژه نقش اساسي بازي مي‌کنند، Actulas و آن دسته که به وجود آمدن Actualsها کمک مي‌کنند را By-Product مي‌گويند (مثلاً طرح اوليه سيستم). در اين مدل هر عضو از گروه مسئول انجام‌دادن قسمتي از کار مي‌شود و اين مدل شامل هشت مرحله يا فاز است.

اولين مرحله اين رويه جمعآوري اطلاعات از کاربر است. در مرحله بعدي سيستم به صورت جامع تحليل و آناليز مي‌گردد تا اعضاي تيم با مدل کلي سيستم آشنا گردند. سپس در مرحله تحليل، نرم‌افزار به صورت کلي مورد بررسي قرار مي‌گيرد و پس از آن که مرحله معماري سيستم نام دارد، اجزاي تشکيل‌دهنده سيستم مشخص مي‌شوند و کارايي‌هاي سيستم مشخص مي‌گردند. در مرحله طراحي تمامي اجزاي سيستم طراحي مي‌شوند و در مرحله بعد کدهاي سيستم نوشته مي‌شود.

وقتي اين مرحله تمام شد و کدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع‌بندي کدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي‌کنند. در مرحله آخر نيز اعضاي گروه را امتحان مي‌کنند تا اولاً نيازهاي کاربران را تأمين کرده باشد و ثانياً فاقد هرگونه اشکال باشد. اگر نرم‌افزار فاقد اشکال باشد، رويه توليد نرم‌افزار به آخر خواهد رسيد. در غير اين صورت، اعضاي گروه به دنبال منبع مشکل در مراحل قبلي مي‌گردند و مجدداً رويه را از آن جايي که فکر مي‌کنند باعث بروز اشکال شده است، ادامه مي‌دهند.

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

از جمله اين رويه‌هاي ساده مي‌توان از Scrum نام برد. Scrum يک تکنيک مديريت پروژه است که مي‌تواند به تيم‌هاي نرم‌افزاري کوچک که روي پروژه‌هاي کوچک نرم‌افزاري کار مي‌کنند کمک کند راندمان و کارايي بالاتري در کار داشته باشند. اما اگر اين روش‌ها را با روش‌هاي مناسب ديگر ادغام کنيم، مي‌توانند بيشتر مفيد واقع گردند.

پس از Scrum، روش اکس‌پي توضيح داده شد و به عنوان بهترين راه براي توليد نرم‌افزارهاي کوچک از آن نام برده شد. اما اين روش به تنهايي کارايي چنداني نخواهد داشت. سپس RUP که مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي کوچک ارائه گرديد. اما همان‌طور که بحث شد، داشتن يک روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلکه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد.​







 
بالا پایین