Borna66
03-13-2009, 06:46 PM
اشاره :
در حقيقت ساختن يك نرم‌افزار فقط نوشتن كدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي كاربران گرفته تا طراحي، نوشتن كد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي كوچك با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي كوچك نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با كيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمركز استفاده كند. با استفاده از تكنيك‌هايي مفيد، از روش‌هايي مانند 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 كه مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي كوچك ارائه گرديد. اما همان‌طور كه بحث شد، داشتن يك روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلكه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد.
منبع: ماهنامه شبکه
:104:
گردآونده:طه-Borna66
در حقيقت ساختن يك نرم‌افزار فقط نوشتن كدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي كاربران گرفته تا طراحي، نوشتن كد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي كوچك با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي كوچك نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با كيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمركز استفاده كند. با استفاده از تكنيك‌هايي مفيد، از روش‌هايي مانند 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 كه مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي كوچك ارائه گرديد. اما همان‌طور كه بحث شد، داشتن يك روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلكه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد.
منبع: ماهنامه شبکه
:104:
گردآونده:طه-Borna66