2019 December Tuesday 10

آشتی با توسعه نرم افزار به روش XP

آشتی با توسعه نرم افزار به روش XP

شرح كاربری یك توضیح كوتاه در باره رفتار بخش های اصلی سیستم از نگاه مشتری

 

آشتی با توسعه نرم افزار به روش XP

مراحل تولید نرم افزار در متدولوژی XP

1- برنامه ریزی[1]

1-1- شرح كاربری[2]

 

نوشتن شرح كاربری : شرح كاربری یك توضیح كوتاه در باره رفتار بخش های اصلی سیستم از نگاه مشتری[3] است كه در قالب متنی در سه حدود سه خط توسط مشتری و با زبان وی بدون مطالب فنی بیهوده نوشته می شود. به عبارت ساده تر شرح كاربری خلاصه ترین مقدار اطلاعات لازم برای آن است كه وی بتواند یكی از وظایف سیستم را به صورت مسیری در سیستم برای دیگران ترسیم كند. شرح كاربری باید درباره رفتار خارجی سیستم باشد. یعنی آن بخشی از سیستم كه مشتری آن را مشاهده می كند. همچنین برای هر خصوصیت نرم افزار باید تنها یك شرح كاربری وجود داشته باشد.

شرح كاربری باید تنها داری آن مقدار از جزئیات باشد كه توسعه دهندگان نرم افزار[4] بتوانند یك تخمین كم ریسك و تقریبا صحیح از میزان زمانی كه برای تولید آن بخش لازم است بدست آورند. آنها جزئیات بیشتر را هنگامی كه زمان اجرای آن شرح كاربری رسید در جلسات و مذاكرات مستقیم با مشتری بدست می آورند.

بهتر است كه مشتری شرح كاربری را بر روی كارتهای راهنمای كوچكی[5] بنویسید. مزیت این كار در آن است كه محدودیت كارت وی را وادار می كند تا تلاش كند كه شرح خود را تا حد ممكن بسیار موجز و قابل درك بنویسد.

نوشتن سناریوی تست : پس از آنكه مشتری شرح كاربری را نوشت می بایست برای هر شرح كاربری سناریوهایی را بنویسد كه بعداٌ توسعه دهندگان با استفاده از آن سناریو تست مقبولیت[6] را بنویسند. این سناریو برای آن است كه مشخص كند كه آیا شرح مشتری به درستی عمل می كند و آیا سیستم خصوصیات مورد قبول مشتری را داراست یا خیر. به عبارت دیگر این سناریو برای بررسی این است آیا تمام شرح های كاربری به درستی در سیستم پیاده شده اند یا خیر. برنامه نویس باید از روی این سناریو كدهای مربوط به تست مقبولیت را بنویسد تا هر وقت كه نیاز بود با استفاده از آن به صورت اتوماتیك تست مقبولیت انجام شود.

 

1-2- برنامه ریزی تولید[7]

 

پس از آنكه شرح كاربری و سناریو های تست شرح های كاربری توسط مشتری نوشته شد، تیم توسعه باید هر چه سریعتر برنامه تكرار[8] را به مشتری بدهد. برای تهیه برنامه تكرار باید جلسه برنامه ریزی تولید برگزار شود در این جلسه شرح های كاربری ای كه در صورت پیاده سازی با هم به سرعت یك بخشی را كه دارای عملكردی قابل حس برای مشتری است و امكان تست آن توسط مشتری وجود دارد را ایجاد می كند، در دسته بندی های مجزا قرار داده می شوند. در پایان جلسه برنامه ریزی تولید مشخص می شود كه در هر نسخه منتشر[9] شده از نرم افزار كدامیك از شرح های كاربری می بایست پیاده سازی شوند و چه مقدار زمان از ما می برد. این بدین معناست كه برنامه تولید در واقع شرح های كاربری را كه با هم یك عملكرد كلی سیستم را شكل می دهند در كنار هم قرار می دهد تا با اجرای آن یك نسخه قابل تست از آن عملكرد ایجاد شود. همچنین زمانی كه بر هر دلیلی سرعت پروژه[10] تغییر كند، باید جلسه برنامه ریزی تولید برای تعیین برنامه تولید جدید تشكیل شود.

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

در جلسات برنامه ریزی تولید برنامه نویسان باید زمان لازم برای اجرای هر شرح كاربری را بر اساس هفته ایده آل كاری[11] در صورتی كه تنها یك برنامه نویس قرار باشد كه آن شرح كاربری را اجرا كند تعیین كنند و بر روی كارت های شرح كاربری زمان ایده آل هر شرح را بنویسند. زمان تخمین زده شده برای هر شرح باید چیزی در حدود یك هفته تا سه هفته باشد. ممكن است كه شرح های كاربری وجود داشته باشند كه زمان تخمین زده شده برای آنها كمتر از یك هفته باشد. در اینصورت آن شرح كاربری بسیار جزئی است و باید آن را با شرح های كاربری دیگر ادغام كرد. شرح های كاربری ای را كه زمان تخمین زده شده برای آنها بیش از سه هفته است نیز باید به شرح های كوچكتری شكسته شوند. از زمان تعیین شده برای هر شرح كاربری برای تهیه برنامه تولید استفاده می شود.

برای اینكه مشخص كنیم كه یك مجموعه از شرح های كاربری چه میزان زمان می برد باید مجموع زمان های تخمین زده شده برای هر شرح كاربری را بر سرعت پروژه تقسیم كنیم. این مقدار نشان می دهد كه با توجه به سرعت فعلی پروژه برای انجام یك مجموعه از شرح های كاربری و یا یك تكرار چه میزان زمان لازم است.

در طول فرآیند تولید نرم فزار، توسعه دهندگان باید به طور متناوب نسخه های كوچكی را كه قابل تست و استفاده هستند را تولید كنند و به مشتری ارائه كنند. این باعث می شود كه نرم افزار در معرض دید مشتری باشد و یك معیار بصری خوب برای تعیین میزان پیشرفت پروژه است. ارائه نسخه های كوچك به مشتری امكان راهنمایی بهتر برنامه نویسان برای دستیابی به هدف نهایی را می دهد.

 

1-3- اندازه گیری سرعت پروژه[12]

 

سرعت پروژه نشان می دهد كه یك پروژه با چه سرعتی به پیش می رود. برای اندازه گیری سرعت پروژه شما باید مجموع تخمین زمانی شرح های كاربری و وظایف برنامه نویسی را كه در هر یك بازه زمانی به طور كامل انجام می شود را بر مدت زمان بازه تقسیم كنیم.(بازه زمانی می تواند یك ماه، یا یك تكرار و یا یك مجموع از شرح كاربری ها باشد) به عنوان مثال اگر قرار باشد در یك تكرار شرح كاربری 1 با زمان تخمین 2 هفته، شرح كاربری 2 با زمان 1 هفته و شرح كاربری 3 با زمان 2 هفته انجام شود در واقع زمان این تكرار مجموع تخمین های فوق است، یعنی این تكرار 5 هفته زمان لازم است. اگر بعد از پنج هفته تنها شرح كاربری 1 و 2 به طور كامل انجام شده باشد در اینصورت، زمان تخمینی 3 هفته در 5 هفته انجام شده است پس سرعت این پروژه معادل 5/3 یا 0.6 است.

 

علاوه بر شرح كاربری سرعت پروژه را باید بر اساس وظایف برنامه نویس[13] در طول یك تكرار نیز محاسبه كرد. یعنی مجموع تخمین زمانی وظایف تكمیل شده در یك تكرار به زمان آن تكرار. از این سرعت در برنامه ریزی تكرار استفاده می شود. تغییرات در سرعت پروژه قابل پیش بینی است ولی در اگر این تغییرات خیلی زیاد باشد بهتر است كه جلسه برنامه ریزی تولید تشكیل داد و برنامه ریزی جدید را بر حسب سرعت جدید ایجاد كرد، برای تغییرات كم در سرعت پروژه نیازی به تغییر برنامه پروژه نیست.

 

1-4- برنامه ریزی مراحل تكرار[14]

 

برنامه اجرای یك بخش كاربردی از نرم افزار كه در برنامه تولید مشخص شده است باید به مراحل تكراری كه زمانشان در حدود یك تا سه هفته است تقسیم شوند. جلسات برنامه ریزی تكرار ها در ابتدای هر تكرار برای مشخص كردن وظایف هر برنامه نویس در آن تكرار و انتخاب شرح های كاربری كه قرار است در این تكرار تكمیل شوند برگزاری می شود. در این جلسه مشتری شرح های كاربری را كه قرار است در این تكرار پیاده سازی شوند را انتخاب می كند. مشتری این شرح های كاربری را از برنامه تولید و براساس الویت های خود انتخاب می كند. این شرح های كاربری باید به صورت وظایف برنامه نویس در آیند و به زبان برنامه نویسی بر روی كارتهای راهنما نوشته شوند. همچنین در این مرحله مشخص می شود كه هر وظیفه را كدام برنامه نویسان انجام می دهند، همچنین برنامه نویسان تخمین زمانی برای اجرای هر وظیفه را بر روی كارتهای راهنمای آن وظیفه می نویسند. هر وظیفه باید بین 1 تا 3 روز ایده آل كاری در صورتی كه تنها یك برنامه نویس آن را انجام دهد باید زمان ببرد. در مورد وظایف كاربر نیز بهتر است وظایفی كه كمتر از یك روز زمان می برند با هم تلفیق شوند و آنهایی كه بیش از 3 روز زمان لازم دارند به وظایف كوچكتر شكسته شوند.

تعداد شرح كاربری ها و وظایف با توجه به سرعت پروژه در تكرار قبلی انتخاب می شوند. بدین معنی كه مجموع تخمین زمانی شرح های كاربری و یا وظایف برنامه نویس انتخاب شده نباید باعث شوند كه سرعت پروژه در این تكرار از سرعت پروژه در تكرار قبلی بیشتر یا كمتر باشند. برای این منظور باید وظایف دیگری را انتخاب كرده و یا برخی از وظایف را از تكرار حذف كرد.

این روش باعث می شود كه كاربران اگر در این تكرار وظایف خود را با سرعت بیشتری انجام دادند. بتوانند به تجدید نیرو بپردازند. همچنین اگر سرعت پروژه پائین باشد می توانند از مشتری بخواهند تا شرح كاربری های جدیدی را به آنها بدهد و جلسه برنامه ریزی تكراری را ایجاد كنند بدین ترتیب سرعت پروژه افزایش پیدا خواهد كرد.

همچنین در طول پروسه تكرار ممكن است نیاز باشد كه برنامه نویسان با مشتری گفتگو كنند كه این گفتگو منجر به اصلاحاتی در شرح كاربری و یا وظایف خواهد شد و یا حتی ممكن است شرح كاربری های جدیدی به سیستم اضافه شود كه در این صورت نیاز كه در یك جلسه برنامه ریزی تولید بررسی شده و برنامه تولید اصلاح شود.

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

یكی از توصیه های مهم در روش XP جفت برنامه نویس[15] است، یعنی بر روی هر وظیفه در یك تكرار دو برنامه نویس به طور همزمان و بر روی یك كامپیوتر كار كنند. یكی كد بنویسد و دیگری به بررسی وظیفه و بررسی كد بپردازد و هر از چند گاهی این دو جایشان را تغییر دهند. همچنین توصیه می شود كه برنامه نویسان را جابجا كنید، بدین معنی كه یك برنامه نویس فقط وظایف یك بخش از نرم افزار را انجام ندهد و اینكه همیشه دو برنامه نویس مشخص با یكدیگر یك برنامه نویسی را تشكیل ندهند. این كار به خصوص در مواقعی كه در یك بخش به مشكل بر می خوریم كمك شایان توجهی به ما خواهد كرد. همچنین باعث می شود كه تمام تیم برنامه نویسی ما از تمام بخش های سیستم مطلع باشد و امكان فعالیت تیمی بیشتر می شود همچنین باعث سهولت در امر یكپارچه سازی بخش های سیستم با یكدیگر می شود.

 

2- طراحی

2-1- استعاره های سیستم[16]

 

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

نامی كه هر برنامه نویسان برای كلاس ها و یا متد هایش انتخاب می كند برای درك برنامه و برای اینكه تیم بتواند مانند هم كار كرده و فرآیند یكپارچه سازی[17] به سادگی انجام شود بسیار مهم است. به همین دلیل این نام ها در سراسر پروژه باید یكسان باشند. مجموعه نام ها و اصطلاحاتی را كه در پروژه به كار گرفته می شود در فرهنگ استعاره های سیستم تعریف می شود. در اینصورت اشیاء ، كلاس ها و بخش های برنامه دارای نام های واحد بوده و در مكالمات بین برنامه نویسان و یا برنامه نویسان و مشتری كمك زیادی به فهم بیشتر می كند.

 

2-2- طراحی سیستم

 

متدلوژی XP برخلاف سایر متدلوژی ها روش پیچیده ای را برای طراحی كل سیستم آنهم در ابتدای پروژه پیشنهاد نمی كند. بلكه پیشنهاد XP سادگی طراحی است. در XP نیاز به آن نیست كه كل سیستم را در ابتدا طراحی و شبیه سازی كنیم بلكه هر بخش از سیستم را در موقع نیاز باید طراحی كرد. متدولوژی XP علاوه بر آنكه طراحی ساده را پیشنهاد می كند، استفاده از ابزار های ساده را نیز برای طراحی مناسب تر می داند. یكی از این ابزار های ساده كه XP آن را توصیه می كند كارتهای CRC و مدل فلش های دوسره برای طراحی سیستم است.

 

یكی از مهمترین نكاتی كه متد XP در طراحی مطرح می كند این است كه بخش هایی را كه امروز به آن نیازی ندارید طراحی نكنید و اینكه اگر بخشی از طراحی پیچیده بود آن را با یك طراحی ساده تر جایگزین كنید.

مزیت استفاده از روش پیشنهادی XP، یعنی كارتهای CRC این است كه باعث می شود كه افراد از تفكر رویه ای خارج شده و بیشتر به صورت شیء گرا به سیستم نگاه كنند. از كارتهای CRC برای نمایش یك شیء در سیستم استفاده می شود. اسم كلاس این شیء باید در بالای كارت نوشته شود. وظایف كلاس در زیر و سمت چپ لیست می شود و كلاس های مرتبط با آن نیز در سمت راست كارت نوشته می شود.

در هنگام تهیه كارتهای CRC یك نفر سیستم را با حرف زدن راجع به اشیاء و ارتباط آنها و با هم شبیه سازی می كند. در این میان اشیاء سیستم و ارتباط آنها با هم نمایان می شود، همچنین وجود نقص و مشكل در فرآیند نیز از این طریق ملموس تر می گردد.

در انتخاب نام ها باید از استعاره های سیستم استفاده كرد و تمام نام هایی كه در كارتهای CRC قرار می گیرند باید در استعاره سیستم باشند در غیر انیصورت باید آن را به استعاره سیستم اضافه كرد.

 

3- كد نویسی[18]

3-1- نوشتن كد تست در ابتدا

 

وقتی شما پیش از نوشتن كد، تست برنامه را بنویسید، نوشتن كد بسیار ساده تر و سریعتر خواهد شد. نوشتن كد تست واحد پیش از نوشتن كد برنامه به برنامه نویس كمك می كند تا دقیقا بداند كه چه كاری باید انجام دهد.همچنین این كار باعث می شود كه به محض اتمام كد شما بازخورد كد را متوجه شوید. همچنین وقتی ما تست را در ابتدا بنویسیم، آنگاه می توانیم متوجه شویم كه چه موقع كار تمام شده است، كد زمانی تكمیل است كه تست واحد آن را 100% تایید كند. شما ابتدا تست را می نویسد و سپس كدی می نویسید كه این تست آن 100% جواب بدهد و این كار را تا زمانی انجام می دهید كه چیزی برای تست كردن وجود نداشته باشد.

این كار همچنین كمك می كند كه شما عملكردهای اضافی در كد قرار ندهید و باید كد را به گونه ای بنویسید كه تست را 100% قبول كند، این باعث می شود كه كد شما كاملاٌ ساده باشد.

 

3-2- جفت برنامه نویسی [19]

 

در روش XP هر كدام از كد ها باید توسط جفت برنامه نویسانی كه همراه با هم بر روی یك دستگاه روی كد كار می كنند تولید شود. تحقیقات تجربی زیادی نشان داده است كه جفت برنامه نویسی منجر به تولید نرم افزار بهتر و یا مشابه ولی با هزینه كمتر نسبت به زمانی است كه یك برنامه نویس به تنهایی كد را بنویسد.

جفت برنامه نویسی همچنین باعث می شود كه كد ها به طور همزمان مرور شوند. همچنین وقتی برنامه نویس حس كند یكی در بالای سرش كدش را مرور می كند بیشتر سعی می كند تا كدش را ابتدا تست كند و به صورت استاندارد بنویسد.

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

 

3-3- بازتولید[20]

 

بازتولید تكنیكی است برای تغییر ساختار داخلی یك كد، بدون آنكه تاثیری در خروجی آن داشته باشد. در طول چرخه تولید برنامه شاید نیاز باشد كه در كدهای قبلی تغییراتی را به وجود اوریم این تغییرات می تواند شامل حذف كد های تكراری، ساده سازی كد، حذف توابع غیر ضروری و یا تغییر الگوریتم هایی كه قدیمی شده و روش های جدیدی برای آن ایجاد كرده ایم، باشد. این تغییرات در واقع باعث می شوند كه برنامه باز تولید شود و ساختار آن تغییر كند اگر چه این تغییر ساختار تاثیری در عملكرد آن نخواهد داشت. بازتولید باعث می شود كه طراحی و كد تا اندازه ممكن ساده بوده و باعث تمیز ماندن كدها می شود تا راحتتر قابل فهم و توسعه باشند.

 

3-4- یكپارچه سازی كد به طور مداوم و توسط یك جفت برنامه نویس

 

یكپارچه سازی به هم پیوند دادن كدها و قابلیت های سیستم برای رسیدن به نسخه نهایی است. در هر مرتبه از یكپارچه سازی نرم افزار به شكل نهایی خود بیشتر نزدیك می شود. فرآیند یكپارچه سازی نیز نیازمند تست واحد است، این تست قبل و بعد از یكپارچه سازی باید انجام شود. پیش از یكپارچه سازی برای آنكه از صحت كدهایی كه قرار است یكپارچه شوند اطلاع حاصل كنیم و پس از آن برای انكه از صحت آنها واینكه آیا كدها در كنار هم درست كار خواهند كرد. همچنین در این مرحله باید تست مقبولیت نیز انجام شود تا مطمئن شویم سیستم وظایفی را كه باید در این مرحله انجام دهد به طور كامل می تواند انجام دهد. بدون این كنترل و تست ها ممكن است به مشكلات عدیده ای در نرم افزار برخورد كنیم،چرا كه به دلیل یكپارچه سازی موازی كدها، تركیبی از كدها به وجود می آید كه پیش از این تست نشده اند.

برنامه نویسان موظفند كه به طور مداوم (بهتر است هر چند ساعت)، و هر وقت كه ممكن بود كدهای خود را یكپارچه كرده و در منبع كدها قرار دهند. هر جفت برنامه نویس مسئول یكپارچه سازی كد های خود هستند. یكپارچه سازی باید در زمانی كه تست واحد 100% تایید شد و یا در زمانی كه بخشی از عملكرد سیستم در برنامه به اتمام رسید انجام شود. پس از اتمام یكپارچه سازی هر بخش باید تست واحد مربوطه نیز اجرا گردد تا از صحت یكپارچه سازی و سازش كدها اطمینان حاصل شود.

 

یكپارچه سازی به طور مداوم از بروز مشكلات عدم سازش كدها جلوگیری می كند و یا اگر چنین مشكلی وجو داشته باشد كمك می كند تا سریعتر آن را تشخیص بدهیم.

برنامه نویسان باید تغییرات را روی آخرین نسخه هر كد بدهند و تغییر بر روی كدهای كهنه باعث مشكل در یكپارچه سازی می شود. به همین دلیل بهتر است كه در هر لحظه فقط یك جفت برنامه نویس در حال یكپارچه كردن كد هایشان با سیستم باشند این كار باعث جلوگیری از ناسازگاری در سیستم می شود.به همین منظور XP پیشنهاد می كند كه عمل یكپارچه سازی بر روی یك دستگاه كامپیوتر مستقل انجام شود. هر جفت برنامه نویسی كه قصد یكپارچه كردن كد هایشان را با سیستم دارند بر روی آن دستگاه این كار را انجام دهند و در همانجا تست واحد و مقبولیت را نیز اجرا كرده و اگر به طور 100% تایید شد، آنگاه تغییرات را نهایی كنند و در غیر اینصورت در همانجا رفع عیب كرده و یا كد را برای اصلاح به كامپیوتر خود منتقل كنند. این كار همچنین كمك می كند كه بدانیم كدام تیم برنامه نویس در چه زمانی كار یكپارچه سازی كدهایش با سیستم را انجام داده است.

 

3-5- مالكیت جمعی[21]

 

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

همچنین هر برنامه نویس می تواند ایده های خود را در مورد هر خط از هر كدام از كدها مطرح كند و تغییرات لازم را روی هر كدی بدهد.

هر برنامه نویس زمانی كه كد خود را می نویسد به همراه آن تست آن واحد را نیز در مخزن كدها اضافه می كند. مخزن كد ها در اختیار همه برنامه نویسان قرار دارد و همه می توانند كدهای دیگران را خوانده و در ساختار كلاس ها و الگوریتم آن تغییراتی را اعمل كنند. در زمانی كه مرحله یكپارچه كردن كدها آغاز می شود، برنامه نویس باید تغییر در یك كد را اعلام كند.

مالكیت جمعی كدها بدین معناست كه همه برنامه نویسان در مقابل كدها مسئول هستند. در این صورت همه علاوه بر آنكه در مقابل برنامه مسئولیت دارند نسبت به كل سیستم نیز آگاهی لازم را بدست می آورند.

یكی از مهمترین كارهایی كه در راستای مالكیت جمعی در XP انجام می شود برنامه نویسی جفت است، اما این كار به تنهایی كافی نیست. تغییر مداوم و زود جفت های برنامه نویسی و تغییر تركیب گروه ها ( چند بار در روز اگر امكانش باشد ) یكی دیگر از كارهای لازم برای كمك به مالكیت جمعی است همچنین دانش و تخصص را به طور یكنواخت در اعضای تیم بالا می برد. مالكیت جمعی همچنین باعث می شود كه یك برنامه نویس در روز فقط بر روی یك بخش كار نكند و اینكار مانع از خسته شدن وی خواهد شد. این امر كه همه تمام كدها را بدانند باعث می شود كه مشكلات به وجود آمده در كد نویسی به راحتی قابل حل باشد.

 

4- تست

4-1- تست واحد[22]

 

تست واحد یكی از مهمترین اجزاء روش XP است. در تست واحد در روش XP شما باید چهار چوب تست واحد را ایجاد كرده (و یا آن را دانلود كنید) در این صورت قادر خواهید بود كه مجموعه تست های واحد را ایجاد كنید. سپس شما باید تمام كلاس های موجود در سیستم را تست كنید و پس از آن كد تست بخش های برنامه را بنویسید تا از روی آن كد بخش مربوطه تولید شود.

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

تست واحد به مالكیت جمعی كمك می كند، بدین ترتیب كه وقتی كه كد شما دارای تست واحد مربوط به خودش باشد، دیگر كسی نمی تواند به گونه ای در آن تغییر ایجاد كند، كه در عملكرد كد تاثیری داشته باشد، یعنی هر تغییر در كد توسط سایرین باید به گونه ای باشد كه كد بازهم تست واحدش 100% موفقیت آمیز باشد. تست واحد در واقع از كدها محافظت می كند، و دیگر كدها نیازی به مالك برای محافظت از انها ندارند.

همچنین تست واحد در هنگام بازتولید كد، كمك می كند، كه بدانیم تغییر ساختار تاثیری در كارآئی سیستم نداشته باشد. همچنین تست واحد كمك می كند كه پس از اتمام كد و در صورتی كه تست آن 100% موفق بود، به سرعت آن را با بقیه سیستم یكپارچه كنیم.

گاهی اوقات تغییر در كد، باعث می شود كه كد تست واحد را نیز تغییر دهیم. اگر اینكار انجام نشود ممكن است كه كد برنامه درست باشد ولی به دلیل اشتباه بودن كد تست، و تغییر ندادن آن باعث شود كه تست آن رد شود.

 

4-2- تست مقبولیت یا تست كارآئی[23]

 

تست مقبولیت برای این انجام می شود كه بدانیم آیا یك سیستم همانطور كه باید كار می كند. اگر تست مقبولیت جوابش مثبت باشد در این صورت نرم افزار شرح كاربری ها را به درستی انجام می دهد. تست مقبولیت برای تعیین میزان صحت و دقت و كامل بودن نرم افزار نسبت به آنچیزی است كه در شرح كاربری توضیح داده شده است و توسط سناریوی آن توسط خود مشتری نوشته می شود و همراه با شرح كاربری ها به برنامه نویس رائه می گردد.

یك شرح كاربری ممكن است یك یا چند تست مقبولیت داشته باشد. تست مقبولیت نوعی تست جعبه سیاه[24] است. هر تست انتظار پاسخ های مشخصی را از سیستم دارد. مشتری در قبال صحت و كامل بودن این تست ها مسئول است و موظف است.

تست های مقبولیت، پس از آنكه سناریوی آنها توسط مشتری نوشته شد باید توسط برنامه نویسان به كد های تست اتوماتیك تبدیل شوند ، تا بتوان آنها را هر موقع نیاز بود به سرعت اجرا كرد. نتیجه تست مقبولیت به تیم ارائه می شود و تیم موظف است كه برای رفع ان زمانبندی كند.

تضمین كیفیت[25] یكی از مهمترین اجزاء روش XP است. در برخی از پروژه ها یك تیم جدا و مستقل مسئول تضمین كیفیت هستند و در برخی دیگر اینكار بر عهده خود تیم توسعه نرم فزار است. در هر صورت در روش XP بهتر است كه اعضای تیم در مورد تضمین كیفیت اطلاعات لازم را داشته باشند.

مرجع: http://www.extremeprogramming.org

——————————————————————————–

 

[1] Planning

 

[2] User Stories

 

[3] Customer

 

[4] Developer

 

[5] Index Cards

 

[6] Acceptance Test

 

[7] Release Planning

 

[8] Iteration Plane

 

[9] Released

 

[10] Project Velocity

 

[11] Ideal Week

 

[12] Project Velocity

 

[13] Programmer’s Task

 

[14] Iteration Planning

 

[15] Pair Programming

 

[16] System Metaphors

 

[17] Integration

 

[18] Coding

 

[19] Pair Programming

 

[20] Refractoring

 

[21] Collective Ownership

 

[22] Unit Test

 

[23] Acceptance Test

 

[24] Black Box Test

 

[25] Quality assurance (Q.A

Share

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Rating*

fa_IRفارسی
en_USEnglish fa_IRفارسی