آشنایی مهارت های عمومی برنامه نویسی (فصل یازدهم)

آشنایی مهارت های عمومی برنامه نویسی (فصل یازدهم)

فصل یازدهم بازرسی و کنترل درستی انجام کار 

مقدمه

چرا در برخی موارد سیستم هاي اطلاعاتی نیاز متقاضیان را برطرف نمیکند؟ چرا در برخی موارد سیستم هاي اطلاعاتی قابل اصلاح یا تغییر یا ارتقاء نمیباشند؟ راه حل چیست؟ ما از متخصصین سیستم هاي اطلاعتی سخنانی مانند این را زیاد شنیده ایم که : «ما نميتوانیم برنامه را تغییر دهیم زيرا که نمیدانیم چگونه آن را انجام دادیم يا ما نميتوانیم برنامه پایگاه اطلاعاتي را تعیین كنیم زیرا روشي كه آن را طراحي كرده براي ما مشخص نیست یا .....» این شرایط وقتي رخ ميدهد كه سیستمي در حال عمل است و نیاز به تغییرات یا ارتقاء دارد ولي به دلیل نا آشنایي با روشهاي طراحي و برنامه نویسي آنلاین كارها ممكن نميباشد. به اصطلاح در اكثر موارد اصلاح یك سیستم به مراتب سختتر از ایجاد يک سیستم جدید است

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

تحلیل سیستم های اطلاعاتی

تحليل سيستم‌ هاي اطلاعاتي يكي از مراحل پيش نياز براي توسعه سيستم است. در اين مرحله انتظارات و نيازمندي‌ هاي ذي نفعان سيستم شناسايي شده و گردش كار سيستم در قالب مدل‌ ها و نشانه‌ هاي استاندارد مستند ميگردد تا از اين رهگذر توسعه دهندگان سيستم بتوانند به يك شناخت جامع نسبت به سيستم دست يافته و آنرا منطبق بر نيازهاي كاربران و ذينفعان نهايي، طراحي و ايجاد نمايند. به منظور استاندارد نمودن ابزارها و روش‌ هاي مدل سازي و مستند سازي سيستم‌ هاي اطلاعاتي، مجموعه اي از مدل‌ ها و متدولوژي‌ ها ارائه شده اند كه اين مدل‌ ها و متدولوژي‌ ها به عنوان زبان مشترك تحليلگران سيستم و برنامه نويسان به شمار ميآيند. در قالب اين مدل‌ ها و متدولوژي‌ ها مجموعه استانداردي از مستندات تهيه شده تا برنامه نويسان بتوانند با بهره گيري از اين مستندات نيازهاي كاربران را در قالب نرم افزارهاي كاربردي پاسخگو باشند. متدولوژي RUP يكي از متدولوژي‌ هاي تحليل و مدل سازي سيستم‌ هاي اطلاعاتي است كه با رويكرد شيءگرا ارائه شده است. اين متدولوژي از نشانه‌ ها، علائم و مدل‌ هاي زبان مدل سازي UML براي مدل سازي سيستم‌ هاي اطلاعاتي استفاده مينمايد. اين متدولوژي در راحل چندگانه خود مستندات و خروجي‌ هاي مختلفي را ارائه مينمايد كه ميتواند توسط برنامه نويسان و توسعه دهندگان سيستم مورد استفاده قرار گيرد. در قالب اين خدمت، قبل از اقدام براي توسعه يك سيستم اطلاعاتي و يا يك برنامه كاربردي، نيازمندي‌ هاي كاركردي و غيركاركردي سيستم با بهره گيري از متدولوژي RUP تعيينشده و الزامات توسعه آن در قالب مستند RFP ارائه ميشود. در اين حالت سازمان ميتواند با به مناقصه گذاردن موضوع پروژه براساس مستندات RFQ و RFP نسبت به انتخاب پيمانكار مناسب براي توليد و استقرار سيستم اقدام نمايد. 

مستند سازي سيستم اطلاعاتي: مستند سازي یک پروژه ابزاري است براي ثبت و اصلاح و توسعه تصمیمات و فعالیت هاي مختلف که در چرخه حیاتی یک پروژه نقش دارند. مستند سازي ميتواند در هدایت فعالیت ها ورسیدن به اهداف از پيش تعيين شده و نيز ارتقاء مسئوليت پاسخگوئی به مشتریان کمک نماید. مستند سازي در هر مرحله از اجراي پروژه باید به صورت جداگانه تهیه شود به صورتی که بتواند نقطه شروعی براي مرحله بعدي خود قرار گیرد. 

طراح پروژه : یکی از مهمترین مراحل در ایجاد یک سیستم اطلاعاتی طرح پروژه میباشد که سندي رسمی است که براي اداره و کنترل و اجراي پروژه مورد استفاده قرار میگیرد و رئوس اهداف سیستم را نشان میدهد طرح پروژه ممکن است در طول زمان طراحی و ایجاد پروژه تعدیل گردد.

مرحله اجراي پروژه: در مرحله اجراي پروژه چندین گزارش تولید خواهد شد که بر چگونگی روش انجام فعالیت ها و چگونگی استانداردهاي کیفیت مورد نیاز و چگونگی برنامه فعالیت و بودجه پروژه تأکید مینماید.

مرحله کنترل و تغییر: در این مرحله طرح پروژه به روز یا تعدیل شده و آینده پروژه پیشبینی میگردد.

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

نقش مستند سازي سیستم هاي اطلاعاتی 

* مستند سازي یک سیستم اطلاعاتی به عنوان یکی از فعالیت هاي پر هزینه و زمان بر در اجراي پروژه درنظر گرفته میشود و لذا با وجود عقاید مختلف متخصصان در مورد نقش مستند سازي سیستم هاي اطلاعاتی، در اینجا لیست مزایاي این جزء از ساختار سیستم را بیان میکنیم :

_ وسیله روشن کردن جنبه هاي خاص سیستم در حال ارتقاء و یافتن پاسخ هایی براي مسائل مختلف که ممکن است در طول پروژه اتفاق بیفتد.

* نوعی قرارداد بین اعضاي تیم پروژه و ذینفعان سیستم و یا بین تیم پروژه و مدیریت سازمان در مورد نوع احتیاجاتی که سیستم باید برآورده کند یا میتواند برآورده کند. 

_ وسیله ارتباطی بین اعضاي تیم پروژه که اجزائی ضروري براي انجام فعالیت هاي مختلف خاص هر مرحله از چرخه توسعه سیستم هستند. در این خصوص میتوان گفت از طریق یک مستند سازي.

_ اعضاي هر مرحله مشکلات و نیازهاي اعضاي مراحل قبلی و بعدي رامطلع میگردند.

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

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

_ مستند سازي سیستم هاي اطلاعاتی باید هر زمانیکه اجزاي سیستم اولیه تغییر میکند، تعدیل شود.

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

اثرات نواقص مستند سازي سیستم هاي اطلاعاتی 

نقص در جدول زمانی اولیه پیشرفت پروژه : به این صورت که ما نمیتوانیم زمان مورد نیاز براي طراحی سیستم را در نظر بگیریم ونیز با در دست داشتن کل زمان موجود به تخصیص زمان براي مراحل مهمتر بپردازیم. 

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

نبود سندي روشن و قطعی از اجزاي سیستم اطلاعاتی 

*فقدان سیاست ها و استاندارد ها و فرآیند هاي مورد نیاز که میبایست در طول طراحی و اجراي سیستم مورد نظر قرارگیرند.

*عدم امکان پاسخگوئی پشتیبانه اي سیستم اطلاعاتی در مواقع مورد نیاز به اصلاح و تغییرات.

_ امکان وقوع اشتباه و خطا در بازسازي یا اصلاح یا تغییر سیستم اطلاعاتی. 

_ دوره زمانی طوالنی تر براي تحلیل سیستم موجود: با توجه به عدم وجود شرحی از قواعد سیستم بین کاربران و پشتیبان برنامه نیاز به وقت بیشتر دارد.

_ از قلم افتادن برخی نیازها و تقاضاهاي کاربر. 

مشکلات در آموزش سیستم 

ارتقاء سیستم اطلاعاتی یک موضوع پیچیده است که میبایست هم از بعد اجزائی که باید شامل باشد و هم از بعد مسئولیت پاسخگوئی در مقابل استفاده کنندگان سیستم باید به آن توجه شود:

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

مستند سازي سیستم اطلاعاتی باید براي هر گروه ازمتقاضیان به صورت جداگانه تهیه و نوشته شود. 

مدیریت هر پروژه اي مسئول گرد هم آوري و ترکیب مستند هاي سیستم باشد. 

مستند سازي سیستم همواره باید در هر مرحله از تغییرات در سیستم، تعدیل شود. 

آشنايي با روشهاي debug و trace کردن برنامه

Debugger

Debugger برنامه ای است که به توسعه دهنده (Developer )اجازه میدهد برنامه را در حال اجرا مشاهده نماید. دو ویژگی مهم آنها قرار دادن Breakpoint و همچنین Trace کردن برنامه ها میباشد. این ویژگی ها به توسعه دهنده اجازه میدهد خطاهای برنامه را یافته و در جهت اصلاح آنها اقدام کند. Debugger یکی از مهم ترین ابزارهای مهندسی معکوس بوده که از یک Disassembler برای برگرداندن کدها به زبان اسمبلی استفاده می نماید.

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

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

debugger studio visual این برنامه به همراه تمامی نسخه های ویژوال استودیو منتشر شده است و امکانات زیادی دارد که میتوان از میان آنها به موارد زیر اشاره کرد:

1 -یکسان کردن سورس و سمبل کدها به طور کامل

2 -اضافه شدن به پردازش های در حال اجرای روی سیستم برای اشکال زدایی (از این روش به منظور اشکال زدایی سرویس های ویندوزی نوشته شده در ویژوال استودیو استفاده میشود.)

3 -امکان اشکال زدایی برنامه های نوشته شده در دات نت و برنامه های محلی نوشته شده در ++C  

4-امکان اشکال زدایی به صورت از راه دور

5 -قابلیت های ویژه و حرفه ای برای گذاشتن نقطه توقف(breakpoint )

6 -نمایش داده ها و وضعیت آنها.حال که با برخی از ویژگی های دیباگر ویژوال استودیو آشنا شدیم، نحوه استفاده از آن را در محیط ویژوال استودیو با هم مرور خواهیم کرد: در بخش منوها، با انتخاب گزینه debug ،میتوانید برنامه خود را در مود اشکال زدا یا بدون اشکال زدا اجرا کنید. اما تفاوت این دو حالت در چیست؟ در حالت اشکال زدا یک فایل شامل سیمبل های برنامه در کنار فایل کامپایل شده ایجاد میشود. با استفاده از این فایل میتوان دوباره برنامه را اشکال زدایی کرد و حتی امکان سوءاستفاده از آن را به هکرها خواهید داد. ولی در حالت بدون اشکالزدا یا عرضه )release )فایل شامل سیمبل ها فعال نخواهد شد و گزینه های بهینه سازی کامپایلر فعال میشوند و از نظر حجم فایل ایجاد شده کوچک تر از فایل اصلی خواهد بود و سرعت اجرا شدن در این دو حالت در بعضی از الگوریتم ها تفاوت زیادی خواهند داشت. 

جلوگیری از Debug کردن نرم افزار 

CRC چيست؟  

معمول ترین آن CRC32 بوده که یک عدد 32 بیتی است و برای هر دادهای قابل محاسبه میباشد از فایل گرفته تا یک مقدار رشته ای یا حتی یک قسمت از حافظه. همانطور که میدانید داده ها به صورت رشتهای از بایت ها قابل نمایش بوده که مقدار CRC هر بایت قابل محاسبه میباشد. الگوریتم های مختلفی برای محاسبه CRC وجود دارد ولی نکته قابل توجه این است که تمام آنها برای یک داده ثابت مقدار یکسانی را تولید میکنند. توجه داشته باشید که اگر برای یک داده مقدار CRC چند بار محاسبه شود مقادیر به دست آمده یکسان هستند و هر دادهای مقدار CRC مختص به خود را دارد به عبارت دیگر مقدار CRC هیچ دو دادهای با هم یکسان نیست. به طور معمول برای استفاده از قفل های سختافزاری یا نرم افزاری برای ارتباط با قفل باید از DLL یا ActiveX استفاده نمود. به دلیل ماهیت خاص این نوع Object ها، آنها قابل جایگزین شدن بوده و با این کار میتوان اداره نرم افزار را در دست گرفت. پیشنهاد میشود در صورت امکان با استفاده از روش های مختلف محاسبه CRC قبل از استفاده از متدهای یک DLL یا ActiveX مشخص نمایید که آیا این Object، Object اصلی است یا خیر؟


 Before using object//

( If (CalculateCRC object) = (MainCRC 

 } 

 you can use methods of object //

{ 

استفاده از کدهای نامعلوم و نامشخص: Debug نرم افزار را مشکل ساخته و زمان بیشتری برای Crack کردن نرم افزار باید صرف شود. در واقع این کدها در نرم افزار عمل خاصی را انجام نداده و فقط در بخشهایی از نرم افزار که قرار است کلمه عبور یا شماره سریال وارد شود قرار گرفته و کار Debug را مشکلتر میکند. برای مثال دستوراتی به زبان اسمبلی وجود دارد (Macro )که با قرار دادن آنها در بین دستورات برنامه باعث میشود بعضی از Debugger ها را با مشکل مواجه شوند. 

 غیر فعال نکردن منوها و دکمه ها در نرمافزارهای Trial : اگر قرار است یک نرم افزار را به صورت Trial منتشر نمایید، منوها و دکمه ها را غیر فعال نکرده و کد اصلی را به طور مستقیم در نرم افزار قرار ندهید بعضی از ابزارهای نرم افزار سازی امکاناتی را در اختیار قرار داده تا بتوانید فقط کد های مورد نظر را Compile نمایید :

{DEFINE Trial$} 

{IFDEF Trial$}

 No Action //

{ELSE$}

 No Compile Operation //

{ENDIF$}

استفاده نکردن از رویدادها به طور مستقیم در BorlandDelphi : به علت ماهیت خاص (VCL ( VisualComponent Library در Delphi یافتن Event ها از طریق Decompile کردن فایل EXE کار ساده ای میباشد بنابراین پیشنهاد میشود که برنامه نویسان دلفی از رویداد های آن به طور مستقیم استفاده نکرده و به روش زیر عمل کنند :

Method1:=Button1.OnClick 

Code Checksum - CRC Calculate 

محاسبه CRC برای بخشی از کد یا تمام فایل در زمان اجرا، راه مناسبی برای جلوگیری از Debug میباشد. زیرا Debugger ها به منظور قرار دادن Breakpoint در برنامه باید در کد تغییر ایجاد کنند. در این لحظه با محاسبه مجدد CRC برای متدهای درون برنامه میتوان مشخص نمود که کد تغییر کرده است یا خیر. این روش نهتنها در مقابل Debugger ها مؤثر است بلکه میتوان در مقابل Patching Code نیز از آن استفاده نمود. 

 Calculate CRC in memory //

if (Func1CRC)!= MainCRC 

 }

  Do an action to stop your progra//

{

Trace کردن برنامه: تست نرم ً افزار عموما در چهار سطح مختلف صورت میگیرد که این چهار مرحله به صورت ترتیبی انجام میپذیرند و عبارتند از :

تست واحد (testing Unit )

تست مجتمع سازی (Testing Integration )

تست سیستم (Testing System )

تست پذیرش (Testing Acceptance)

تست واحد (testing Unit) :یک واحد کوچک ترین قسمت قابل تست یک نرم افزار میباشد. که این واحد در برنامه نویسی شیءگرا میتواند یک متد باشد و در برنامه نویسی رویه ای میتواند کل برنامه (در زبانی مانند کوبول) یا یک تابع و ... باشد. هدف در این سطح از تست این است که آیا واحد مورد نظر به تنهایی کاری را که باید انجام بدهد میدهد یا نه. 

تست مجتمع سازی (Testing Integration) :تست واحد را برای هر کدام از واحدها به صورت جداگانه انجام دادید و از صحت عملکرد آنها مطمئن شدید. همه واحدها به صورت منفرد به طور صحیح وظایف خود را انجام میدهند، آیا نیازی به تست اینکه وقتی واحدها کنار هم قرار گرفتند و ارتباط برقرار کردند وظایفشان را به شکل صحیح انجام میدهند هست یا نیست. فرض کنید 2 نفر مشغول کاری هستند هنگامیکه موارد مورد نیاز برای انجام کار به طور کامل مهیا باشد هر کدام از آن 2 فرد میتوانند کارشان را به شکل کامل انجام بدهند. اما اگر موارد مورد نیاز برای یکی از آنها توسط دیگری تأمین شود ممکن است موارد تهیه شده دقیقا چیزی نباشد که فرد دوم نیاز دارد، یا زمانی زیاد برای تحویل آن موارد مورد نیاز باشد که عملکرد فرد دوم را با مشکل روبرو کند. پس ما نیاز داریم تا مطمئن شویم که آیا واحدها در کنار هم کار میکنند، به درستی فراخوانی میشوند، و داده های درستی را در زمان مناسبی از طریق واسط های آنها عبور میدهند. (تست مجتمع سازی یکی از مهمترین و شاید مهمترین سطح از تست باشد، به خصوص زمانیکه سیستم تغییرات زیادی دارد بعد از انجام تغییرات هرگز این مرحله را فراموش نکنید. پس روش های مختلف تست مجتمع سازی را بررسی و مطالعه کنید.)

 

تست سیستم (Testing System) :تست مجتمع سازی را برای نرم افزار مورد نظر انجام دادید و از این مطمئن شدید که تمام قطعات در کنار هم میتوانند قرار بگیرند و بدون هیچ مشکلی وظایفشان را انجام دهند. قطعات در کنار هم مجتمع شده اند و پیکره اصلی نرم افزار تشکیل شد، ولی نرم افزار خود جزئی از یک سیستم است و نیاز است که با عناصر دیگر این سیستم مانند سخت افزارها ارتباط برقرار کند و با آنها مجتمع شود. پس نیاز داریم تا مطمئن شویم که سیستم به عنوان یک واحد به طور کامل عمل خواهد کرد و نیازمندی های سیستم را برآورده میکند. این سطح از تست آخرین سطحی است که توسط توسعه دهندگان صورت میگیرد تا قبل از تحویل نرم افزار به کاربر نهایی برای تست از عملکرد آن مطمئن شویم. برای نمونه موارد زیر در تست سیستم مورد بررسی قرار میگیرد: 

تست امنیت (Testing Security) : فرض کنید سیستم باید اطلاعات حساس و حیاتی را پردازش و مدیریت کند و افرادی هستند که به دنبال دسترسی غیرمجاز به این اطلاعاتو سوءاستفاده از آن هستند. برای اطمینان از عملکرد سیستم در برابر نفوذگران ما باید مکانیزم امنیتی ایجاد شده در سیستم را بررسی کنیم تا مطمئن شویم که سیستم میتواند نفوذهای غیر قانونی را تشخیص دهد و در برابر آنها عکس العمل نشان دهد. 

تست بازیابی (Testing Recovery) : در این نوع آزمایش باعث ایجاد مشکل و از کار افتادن سیستم به روش های مختلف میشویم و بررسی میکنیم که آیا سیستم میتواند خود را به طور خودکار بازیابی کند و به فعالیت خود ادامه دهد.

تست پذیرش (Testing Acceptance) :نرم افزار به طور کامل توسط توسعه دهندگان در تمام سطوح تست، با موفقیت تست شد، اما آیا نرم افزار واقعا به طور کامل (آنگونه که کاربر نهایی میخواهد) کار میکند. آیا تمام نیازهای فعلی کاربر نهایی را برآورده میکند. پس ما به آزمایشی نیاز داریم که توسط کاربران نهایی، مشتریان و نه توسعه دهندگان صورت میگیرد و هدف آن است که کاربر مشخص کند عملیاتی که برنامه انجام میدهد نیازمندی های آنها را برآورده میکند یا نه. تست پذیرش دارای انواع مختلفی است که میتوان به موارد زیر اشاره کرد:

تست آلفا: تست آلفا در سایت توسعهدهنده نرم افزار و در اغلب موارد توسط کارمندان داخلی و در بعضی از موارد توسط مشتری انجام میگیرد.

تست بتا: تست بتا در سایت مشتریان و توسط مشتریان که از سیستم استفاده خواهند کرد صورت میگیرد و مشکلات مشاهده شده را به توسعه دهندگان گزارش میکنند.

خلاصه فصل 

تحليل سيستم‌ هاي اطلاعاتي يكي از مراحل پيش نياز براي توسعه سيستم است. در اين مرحله انتظارات و نيازمندي‌ هاي ذينفعان سيستم شناسايي شده و گردش كار سيستم در قالب مدل‌ ها و نشانه‌ هاي استاندارد مستند ميگردد تا از اين رهگذر توسعه دهندگان سيستم بتوانند به يك شناخت جامع نسبت به سيستم دست يافته و آنرا منطبق بر نيازهاي كاربران و ذينفعان نهايي، طراحي و ايجاد نمايند. 

مستند سازي یک پروژه ابزاري است براي ثبت و اصلاح و توسعه تصمیمات و فعالیت هاي مختلف که در چرخه حیاتی یک پروژه نقش دارند. مستند سازي ميتواند در هدایت فعالیت ها و رسیدن به اهداف از پيش تعيين شده و نيز ارتقا مسئوليت پاسخگوئی به مشتریان کمک نماید. 

Debugger برنامهای است که به توسعهدهنده (Developer )اجازه میدهد برنامه را در حال اجرا مشاهده نماید. دو ویژگی مهم آنها قرار دادن Breakpoint و همچنین Trace کردن برنامه ها میباشد. این ویژگی ها به توسعه دهنده اجازه میدهد خطاهای برنامه را یافته و در جهت اصلاح آنها اقدام کند. Debugger یکی از مهمترین ابزارهای مهندسی معکوس بوده که از یک Disassembler برای برگرداندن کدها به زبان اسمبلی استفاده مینماید. تست نرم افزار عموما در چهار سطح مختلف صورت میگیرد که این چهار مرحله به صورت ترتیبی انجام میپذیرند و عبارتند از : 

تست واحد (testing Unit )

تست مجتمع سازی (Testing Integration )

تست سیستم (Testing System )

تست پذیرش (Testing Acceptance)

تست واحد (testing Unit: )یک واحد کوچک ترین قسمت قابل تست یک نرم افزار میباشد که این واحد در برنامه نویسی شیءگرا میتواند یک متد باشد و در برنامه نویسی رویه ای میتواند کل برنامه (در زبانی مانند کوبول) یا یک تابع و ... باشد. هدف در این سطح از تست این است که آیا واحد مورد نظر به تنهایی کاری را که باید انجام بدهد میدهد یا نه.

در تست مجتمع سازی(Testing Integration )ما نیاز داریم تا مطمئن شویم که آیا واحدها در کنار هم کار میکنند، به درستی فراخوانی میشوند، و داده های درستی را در زمان مناسبی از طریق واسط های آنها عبور میدهند.

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

و نیازمندی های سیستم را برآورده میکند. در این سطح تست سیستم انجام میشود. 

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

 

 

آشنایی مهارت های عمومی برنامه نویسی (فصل اول)

آشنایی مهارت های عمومی برنامه نویسی (فصل دوم)

آشنایی مهارت های عمومی برنامه نویسی (فصل سوم)

آشنایی مهارت های عمومی برنامه نویسی (فصل چهارم)

آشنایی مهارت های عمومی برنامه نویسی (فصل پنجم)

آشنایی مهارت های عمومی برنامه نویسی (فصل ششم بخش 1)

آشنایی مهارت های عمومی برنامه نویسی (فصل ششم بخش 2)

آشنایی مهارت های عمومی برنامه نویسی (فصل هفتم)

آشنایی مهارت های عمومی برنامه نویسی (فصل هشتم بخش 1)

آشنایی مهارت های عمومی برنامه نویسی (فصل هشتم بخش 2)

آشنایی مهارت های عمومی برنامه نویسی (فصل نهم بخش 1)

آشنایی مهارت های عمومی برنامه نویسی (فصل نهم بخش 2)

آشنایی مهارت های عمومی برنامه نویسی (فصل 10)

 

امیدواریم از این مقاله بهره کافی را برده باشید وبرای شما مفید بوده باشد.

سؤالات خود در رابطه با این مقاله و همچنین انتقادات و پیشنهادات خود را در قسمت نظرات با ما در میان بگذارید


این مقاله فایلی برای دانلود ندارد
برای ارسال نظر نیاز است وارد سایت شوید. در صورت نداشتن حساب کاربری عضو شوید.