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

[MAHDIAR]

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

[MAHDIAR]

● فرایند تولید نرم‌افزار

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

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

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

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

[MAHDIAR]

● روش SCRUM

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

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

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

[MAHDIAR]

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

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

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

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

[MAHDIAR]

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

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

۲) در طول این دوره به چه مشکلاتی برخورده‌اید؟

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

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

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

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

[MAHDIAR]

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

● معایب روش Scram

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

۱) Scrum روش جدیدی است و با روش‌های مرسوم تفاوت‌های زیادی دارد.

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

۳) از آنجا که مدیر Scrum هم از نظر کیفی و هم کمی باید پروژه را مدیریت کند، Scrum نیاز به مدیریت بسیار قدرتمند دارد.

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

[MAHDIAR]

● روش XP

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

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

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

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

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

ب) طراحی ابتدایی

ج) نوشتن کدهای برنامه

د) امتحان‌کردن کدهای نوشته شده

[MAHDIAR]

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

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

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

[MAHDIAR]

● روشRational Unified Process) ‌RUP)

در این بخش یکی از معروف‌ترین رویه‌های تولید نرم‌افزار که توسط شرکت آی‌بی‌ام طراحی گردیده‌است را معرفی می‌کنیم. این روش با نام Rational Unified Process) ‌RUP) در بسیاری از پروژه‌های نرم‌افزاری به کار گرفته می‌شود.

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

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

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

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

۱) استفاده از USE CASEها که می‌توانند در جمعآوری نیازهای کاربران مفید باشند.

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

۳) استفاده از روش‌های تکمیلی و Iterative برای کنترل بهتر و آسان پروژه نرم‌افزاری‌

۴) استفاده از نمودارهای UML

۵) کنترل تغییرات در نرم‌افزار

۶) کنترل کیفیت نرم‌افزار با توجه به درخواست‌های اولیه کاربران

[MAHDIAR]

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

الف) Inception phase یا مرحله آغازین:

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

ب) Elaboration phase یا مرحله مقدماتی:

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

ج) Construction phase:

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

د) Transition phase یا مرحله تغییرات:

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

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

[MAHDIAR]

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

اما همان‌طور که در ادامه این بحث خواهید دید، اگر بتوانیم رویه‌های ساده‌تر را با یکدیگر ادغام کنیم، شاید بتوانیم راه حلی با کارایی بالاتری داشته باشیم.

● روش های PSP و TSP

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

[MAHDIAR]

● راه‌حل‌های پیشنهادی

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

● روش RUP + Scrum

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

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

[MAHDIAR]

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

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

● روش RUP + XP

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

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

[MAHDIAR]

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

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

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

[MAHDIAR]

● روش Iterative Process

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

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

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

[MAHDIAR]

● نتیجه گیری

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

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

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

http://www.t۳nsm.blogfa.com