مناسب ترین روش برای تولید نرم افزارهای كوچك

​

اشاره :
در حقیقت ساختن یك نرم افزار فقط نوشتن كدهای برنامه نیست. رویه ساخت نرم افزارها مراحل متعددی را دربرمی گیرد؛ از جمع آوری نیازهای كاربران گرفته تا طراحی، نوشتن كد و در آخر امتحان نرم افزار. روش تولید نرم افزارهای كوچك با نرم افزارهای بزرگ متفاوت است و طبعاً رویه تولید نرم افزارهای كوچك نیز متفاوت خواهد بود. البته این رویه نباید سنگین و حجیم باشد، باید مستقیماً به تمامی فعالیت های لازم برای تولید نرم افزاری با كیفیت بالا نظارت داشته باشد و از تمامی رویه های آسان و متمركز استفاده كند. با استفاده از تكنیك هایی مفید، از روش هایی مانند 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 گروه موظف است روزانه جلساتی جهت بررسی روند پیشرفت و قابلیت های نرم افزار داشته باشد كه این نیز به هماهنگی بیشتر گروه كمك خواهد كرد. در این جلسات كه معمولاً به صورت روزانه است، سه گروه می توانند شركت كنند: گروه تهیه كننده نرم افزار، مدیریت، و درخواست كنندگان نرم افزار .
در طول این جلسات مسئول جلسه كه اغلب مدیر پروژه است، از تمامی اعضای تیم سه سؤال می پرسد :
مسئولیت شما (تكالیف) از جلسه قبلی تاكنون چه بوده است و آیا توانسته اید این تكالیف را به اتمام برسانید؟
در طول این دوره به چه مشكلاتی برخورده اید؟
بر طبق فهرست وظایف، مسئولیت شما از حالا تا جلسه بعدی چه خواهد بود؟
مدیر Scrum در حقیقت مسئولیت شناسایی تكالیف محوله به اعضا، بررسی روند تكمیلی ساخت نرم افزار، بررسی قابلیت های اعضای گروه و فعالیت در راستای كم كردن ریسك در پروژه را داراست .
اما چه تفاوتی بین Scrum و دیگر روش های تولید نرم افزار وجود دارد؟ در جواب این سؤال باید یادآورشد كه در Scrum هر مرحله یا Sprint قسمتی از نرم افزار را آماده می كند. در این روش می توان پیشرفت در تولید نرم افزار را در هر مرحله به خوبی احساس نمود. علاوه بر این، گروه می تواند پس از اتمام هر Sprint تصمیم گیری كند كه آیا می خواهد به كار روی پروژه ادامه دهد یا انجام پروژه مذكور غیرممكن است. روش Scrum وقتی می تواند بیشتر مفید باشد كه در ابتدای پروژه نیازهای كاربران به صورت دقیق مشخص نباشد و یك گروه كوچك مسئول پروژه نرم افزاری باشد .
نتایج تحقیقاتی كه اواخر سال 2005 روی چندین شركت تولیدكننده نرم افزار در كشور انگلستان انجام دادم، نشان دهنده این بود كه شركت هایی كه از Scrum استفاده كرده بودند با حدود چهارصددرصد افزایش در بهره وری كار مواجه بودند. البته این رقم در گروه های نرم افزاری مختلف متفاوت بود و می توان گفت عوامل انسانی از جمله مدیر پروژه نقش بسیار مهمی در افزایش یا كاهش راندمان پروژه ها دارند .
شاید این سؤال در ذهن شما به وجود آید كه چرا Scrum ممكن است برای تولید نرم افزارهای كوچك راه حل خوبی باشد؟ در جواب می توان گفت، از آن جایی كه در تیم های كوچك، اعضای گروه باید از تمامی مسائل پروژه آگاه باشند و در Scrum تمامی مراحل ساخت توسط تمامی اعضای گروه قابل مشاهده است. لذا این روش می تواند روش مناسبی باشد .
معایب روش Scram
مزایای استفاده از Scrum بسیار است، اما این روش چند اشكال نیز دارد. از جمله :
Scrum روش جدیدی است و با روش های مرسوم تفاوت های زیادی دارد .
برخی از برنامه نویسان حرفه ای ممكن است از تكالیفی كه مدیر Scrum به ایشان می دهد راضی نباشند و بخواهند روش قدیمی خود را اجرا نمایند و در صورت اجبار، در روند اجرای پروژه كارشكنی كرده و مشكل آفرینی كنند .
از آنجا كه مدیر Scrum هم از نظر كیفی و هم كمی باید پروژه را مدیریت كند، Scrum نیاز به مدیریت بسیار قدرتمند دارد .
Scrum را می توان به عنوان روش تولید نرم افزار نام برد، اما این روش بیشتر روش مدیریت پروژه هوشمند خوبی است و نمی توان آن را به صورت منفرد استفاده نمود و می توان گفت برای حصول اطمینان از موفقیت پروژه های نرم افزاری (به خصوص در سطح كوچك) باید این روش را با روش های دیگر ادغام نمود . Scrum را از آن جهت می توان روش خوبی برشمرد كه روشی تحقیقی براساس تخمین، اولویت بندی، عملكرد گروه و بررسی نتایج است كه اگر به صورت صحیح مورد استفاده قرار گیرد و قبل از استفاده به صورت كامل آموزش داده شود، می تواند راندمان پروژه های نرم افزاری، به خصوص تولید نرم افزارهای كوچك را به صورت بسیار محسوسی بالا ببرد .
روش XP
اشتباه نكنید! منظور از روش اكس پی، ویندوزاكس پی نیست. اكس پی مخفف Extreme Programming یا برنامه نویسی سریع می باشد كه مانند Scrum روشی هوشمند در تولید نرم افزار است. در اكس پی دو برنامه نویس كار را انجام می دهند و قبل از اتمام برنامه آن را چندین بار امتحان می كنند. اكس پی در حقیقت روشی از تولید نرم افزار است كه براساس آسانی، ارتباط، واكنش و تصمیم گیری سریع استوار است. شكل 2 اصول روش اكس پی را نشان می دهد .
در روش اكس پی اعضای گروه (كه كاربر سیستم نیز عضوی از آن است) در ابتدا جلسه ای تشكیل می دهند و اولویت های پروژه را مشخص می كنند. این گروه ممكن است از چند برنامه نویس، امتحان كننده نرم افزار یا Tester و تحلیلگر سیستم تشكیل شود كه با هم از ابتدا تا انتهای پروژه همكاری می كنند. معمولاً در اكس پی برنامه نویسان در گروه های دوتایی قرار می گیرند و وظیفه تكمیل قسمتی از برنامه را برعهده می گیرند و هر دوی این برنامه نویسان در مورد هر كدام از نیازهای كاربران با هم بحث می كنند و قدم به قدم كلاس های برنامه را آماده می كنند .
بدین ترتیب كه در ابتدا كلاسی را به صورت ابتدایی و بدون هیچ طراحی اولیه به وجود می آورند و این كلاس را امتحان می كنند. در صورتی كه این كلاس فاقد هر گونه اشكال باشد، كد اصلی برنامه را بر آن اساس می نویسند . وقتی یكی از برنامه نویسان مشغول نوشتن قسمتی از برنامه است، برنامه نویس دیگر وظیفه كنترل صحت این كدها را عهده دار است و در صورت مشاهده هر گونه اشكال، نویسنده كد را مطلع می كند .
مانند Scrum ، در اكس پی نیز اعضای گروه می توانند روند تكمیلی تولید نرم افزار را مشاهده كنند و در جریان كار قرار گیرند.اكس پی روش مناسبی برای مدیریت پروژه های كوچك می باشد كه از دو تا ده برنامه نویس تشكیل شده است.
اگر چه اصولاً اكس پی هیچ رویه خاص و مراحل پیوسته ای را مشخص نكرده اما می توان گفت كه اكس پی داری چهار مرحله اصلی می باشد :
مرحله زمانبندی پروژه: در این مرحله اعضای گروه با توجه به اندازه نرم افزار و كارایی آن برنامه زمانبندی را با هم تنظیم می كنند .
طراحی ابتدایی
نوشتن كدهای برنامه
امتحان كردن كدهای نوشته شده
مطابق تحقیقاتی كه توسط نویسنده انجام شد، مشخص گردید كه اكس پی در پروژه های بزرگ با تعداد اعضای بالای ده نفر اصلاً موفق نخواهد بود و تنها می تواند برای پروژه های كوچك مفید باشد. دلیل آن را نیز می توان در طبیعت این روش دانست؛ زیرا مستندات چندانی برای نرم افزار وجود ندارد و فقط دو نفر یا حداكثر چهار نفر می توانند در مورد قسمتی از نرم افزار اطلاعاتی داشته باشند. همچنین نرم افزار تولیدشده توسط این روش هیچ گونه طراحی سازمان یافته ای ندارد كه این موضوع می تواند برای مراحل پس از نصب یعنی تعمیرات و نگهداری سیستم باعث بروز مشكلاتی گردد .
از جمله مزایای اكس پی می توان به این نكته اشاره نمود كه از آن جایی كه یك برنامه نویس به صورت مستقیم كدهای برنامه را كنترل می كند، می توان گفت كه كیفیت نرم افزار تولیدی بالا می رود. همچنین می توان گفت از آن جایی كه دو برنامه نویس با هم كار می كنند، آموزش كمتری نیاز است و در نتیجه هزینه تولید نرم افزار پایین خواهد آمد. اما این روش مشكلات خاص خود را نیز دارد. مثلاً تصوركنید اگر در یك گروه، یك برنامه نویس تمایلی برای كار با برنامه نویس دیگری را نداشته باشد یا در یك روز یكی از دو عضو گروه غایب باشد یا ... در نتیجه چون نمی توان با یك برنامه نویس به ادامه كار پرداخت، اتمام پروژه با تأخیر مواجه خواهد شد .
طبق نتایج تحقیقات به عمل آمده، وقتی یك برنامه نویس در كدهای برنامه به دنبال اشكال می گردد، حداكثر می تواند ده تا پانزده درصد از اشكالات برنامه را پیدا كند. اما وقتی در روشی مثل اكس پی دو برنامه نویس با هم كار می كنند و یكی از این برنامه نویسان كدها را كنترل می كند، بیست تا چهل درصد از اشكالات ساختاری برنامه خود را نشان می دهد. اما با استفاده از روش های PSP و TSP كه در ادامه این مقاله توضیح داده می شوند حتی می توان تا هشتاددرصد اشكالات برنامه (كه رقم بسیار خوبی است) را قبل نهایی شدن برنامه شناسایی و رفع كرد .
روشRational Unified Process (RUP)
در این بخش یكی از معروف ترین رویه های تولید نرم افزار كه توسط شركت آی بی ام طراحی گردیده است را معرفی می كنیم. این روش با نام Rational Unified Process (RUP) در بسیاری از پروژه های نرم افزاری به كار گرفته می شود .
در حقیقت هدف اصلی RUP مطمئن شدن از این موضوع مهم است كه آیا نرم افزار تولیدشده نیازهای كاربرانش را به صورت كامل، با كیفیت بالا ، در زمان معین و با بودجه مشخص برآورده كرده است یا خیر .
مطابق تحقیقات انجام شده، از آن جایی كه RUP به تمامی اعضای تیم، اطلاعاتی مشترك می دهد و تمامی اعضای گروه با یك زبان مشترك با هم مرتبط هستند، بازده كاری گروه را بالا می برد .
RUP دارای سه جزء اصلی است. جزء اول از مجموع راه حل های خوب كه در رویه می تواند مورد استفاده قرار گیرد تشكیل شده است. جزء دوم همان مراحل تهیه نرم افزار است و جزء آخر قسمت های تشكیل دهنده این رویه می باشد .
RUP شش راه حل خوب كه می تواند در مراحل مختلف این رویه به ما كمك كند را معرفی كرده است.
از آن جمله :
استفاده از USE CASEها كه می توانند در جمعآوری نیازهای كاربران مفید باشند .
استفاده از معماری نرم افزار قابل تغییر ( component reuse)
استفاده از روش های تكمیلی و Iterative برای كنترل بهتر و آسان پروژه نرم افزاری
استفاده از نمودارهای UML
كنترل تغییرات در نرم افزار
كنترل كیفیت نرم افزار با توجه به درخواست های اولیه كاربران
شكل 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 modeler را عرضه كرده كه به مدیران پروژه ها اجازه می دهد تا برخی از اصول 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 كه می تواند در تمامی پروژه ها استفاده شود تشریح شد و در ادامه سه روش مناسب برای تولید نرم افزارهای كوچك ارائه گردید. اما همان طور كه بحث شد، داشتن یك روش مناسب به تنهایی نمی تواند ضامن موفقیت در پروژه باشد، بلكه انتخاب منابع انسانی مناسب و با تجربه می تواند راه را برای موفقیت پروژه های نرم افزاری هموارتر سازد .