<img src="images/no_flash.jpg" alt="Flash_Banner(Required Flash Player 8.0+)" width="990" height="121"/>
     
خدمات نرم افزاری :: مراحل توليد نرم افزار
خدمات نرم افزاری

 

مراحل توليد نرم افزار در متدولوژي 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] است، يعني بر روي هر وظيفه در يك تكرار دو برنامه نويس به طور همزمان و بر روي يك كامپيوتر كار كنند. يكي كد بنويسد و ديگري به بررسي وظيفه و بررسي كد بپردازد و هر از چند گاهي اين دو جايشان را تغيير دهند. همچنين توصيه مي شود كه برنامه نويسان را جابجا كنيد، بدين معني كه يك برنامه نويس فقط وظايف يك بخش از نرم افزار را انجام ندهد و اينكه هميشه دو برنامه نويس مشخص با يكديگر يك برنامه نويسي را تشكيل ندهند. اين كار به خصوص در مواقعي كه در يك بخش به مشكل بر مي خوريم كمك شايان توجهي به ما خواهد كرد. همچنين باعث مي شود كه تمام تيم برنامه نويسي ما از تمام بخش هاي سيستم مطلع باشد و امكان فعاليت تيمي بيشتر مي شود همچنين باعث سهولت در امر يكپارچه سازي بخش هاي سيستم با يكديگر مي شود.

 

 

نماي كلي چرخه بازخورد در روش XP

 

 

 

2- طراحي

 

 

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

 

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

 

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

 

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

 

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

 

 

نمونه كارت 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] P lanning

 

[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)