I. سافٹ ویئر ڈویلپمنٹ کے عمل کی پختگی
سافٹ ویئر کے معیار کی بنیاد ترقی کے عمل کو معیاری بنانے میں ہے۔ آٹوموٹیو اسپائس کی صلاحیت کی سطحیں فی الحال سافٹ ویئر کے عمل کی پختگی کے لیے صنعت کا معیار ہیں، لیکن CL2 یا CL3 تک پہنچنا صرف بنیادی بات ہے۔ جو چیز صحیح معنوں میں سافٹ ویئر کی ترسیل کے معیار کا تعین کرتی ہے وہ عمل کے عمل کے دوران انحرافات کا کنٹرول ہے۔ ضروریات کے انتظام کو مثال کے طور پر لیتے ہوئے، ایک عام انحراف یہ ہے کہ ضرورت میں تبدیلی کے بعد، متعلقہ ٹیسٹ کیسز کو ہم وقت سازی سے اپ ڈیٹ نہیں کیا جاتا ہے۔ ایک پروجیکٹ میں، SOP کے بعد ایک OTA اپ گریڈ فنکشن پایا گیا جس میں ایک مسئلہ تھا جہاں گاڑی کے چارج کی کم حالت میں، OTA ڈاؤن لوڈ ٹاسک کو بغیر کسی خرابی کی اطلاع دیے غیر معینہ مدت کے لیے معطل کر دیا جائے گا۔ اس کی بنیادی وجہ یہ تھی کہ مطلوبہ دستاویز میں چارج پروٹیکشن منطق کی کم حالت کا اضافہ کیا گیا تھا، لیکن متعلقہ ٹیسٹ کیسز میں اب بھی صرف ڈاؤن لوڈ فنکشن کی تصدیق کا احاطہ کیا گیا ہے بغیر کسی رکاوٹ اور بحالی کے منظرناموں کو شامل کیے بغیر۔ تعارف سے لے کر دریافت تک، یہ خرابی چار تکراری ورژن پر پھیلی ہوئی ہے، اور اصلاح کی لاگت اس کے مقابلے میں تقریباً چالیس گنا زیادہ تھی اگر اسے ابتدائی طور پر پایا جاتا۔ ٹریس ایبلٹی میٹرکس کی ضروریات کو مسلسل انضمام پائپ لائن میں شامل کرنے کی ضرورت ہے۔ جب ضرورت کی حیثیت تبدیل ہو جاتی ہے، تو متعلقہ ٹیسٹ کیسز کے لیے جائزے کے کام خود بخود متحرک ہو جانا چاہیے، اور ایسے ٹیسٹ کیسز جنہوں نے جائزہ پاس نہیں کیا ہے انہیں بلاکنگ آئٹمز کے بطور نشان زد کیا جانا چاہیے۔ کوڈ کا جائزہ لینے کی بھی مقدار درست کرنے کی ضرورت ہے۔ تحقیق سے پتہ چلتا ہے کہ ہر ہزار لائنوں کے کوڈ میں دو سے کم جائزے والے تبصرے والے ماڈیولز میں پوسٹ-ریلیز کی خرابی کی کثافت تین گنا زیادہ ہوتی ہے جس میں ہر ہزار لائنوں میں پانچ سے زیادہ تبصرے ہوتے ہیں۔ تاہم، جائزے کے تبصروں کی تعداد کو مطلق اشارے کے طور پر استعمال نہیں کیا جا سکتا کیونکہ کم{14}}معیار کے تبصرے بھی موجود ہیں۔ ایک مؤثر طریقہ نظرثانی کے تبصروں کو پانچ زمروں میں درجہ بندی کرنا ہے: منطق کی غلطیاں، حدود کی کمی، کوڈ پڑھنے کی اہلیت، کارکردگی کے خطرات، اور حفاظتی خطرات، خاص طور پر دو مہلک زمروں کی کھوج کی شرح پر توجہ مرکوز کرتے ہوئے: منطق کی خرابیاں اور حفاظتی خطرات۔
II مسلسل انضمام اور مسلسل جانچ
سافٹ ویئر کے اعادہ کی سرعت کے لیے ٹیسٹنگ کو بائیں منتقل کرنے کی ضرورت ہوتی ہے، یعنی کوڈ کمٹ مرحلے پر کوالٹی کی تصدیق متعارف کرائی جاتی ہے۔ یونٹ ٹیسٹنگ دفاع کی سب سے بائیں لائن ہے، لیکن اصل منصوبوں میں، یونٹ ٹیسٹ کوڈ کی کوریج اکثر فلائی ہوئی اقدار کا شکار ہوتی ہے۔ ایک کنٹرولر پروجیکٹ میں، یونٹ ٹیسٹ کی رپورٹ نے 92% کی لائن کوریج ظاہر کی، لیکن انٹیگریشن ٹیسٹنگ کے دوران بڑی تعداد میں بنیادی خامیاں اب بھی پائی گئیں۔ سابقہ تجزیے سے یہ بات سامنے آئی کہ اگرچہ ان غلطیوں پر مشتمل کوڈ کی لائنوں پر عمل درآمد کیا گیا تھا، لیکن ٹیسٹ کے دعووں نے متعلقہ نتائج کی جانچ نہیں کی۔ لائن کوریج صرف اس بات کی نشاندہی کرتی ہے کہ کوڈ پر عمل درآمد کیا گیا ہے، نہ کہ آؤٹ پٹ کی تصدیق کی گئی ہے۔ ایک بہتری کا طریقہ یہ ہے کہ میوٹیشن ٹیسٹنگ متعارف کروائی جائے، جو ٹیسٹ کیسز کی تاثیر کا اندازہ لگانے کے لیے خود بخود کوڈ اتپریورتی پیدا کرتا ہے۔ اگر ایک اتپریورتی کو ہلاک نہیں کیا جاتا ہے، تو یہ ٹیسٹ کے دعووں میں فرق کی نشاندہی کرتا ہے۔ مسلسل انضمام پائپ لائنوں میں ایک اور درد کا نقطہ حد سے زیادہ ٹیسٹ پر عملدرآمد کا وقت ہے۔ ایک OEM کے سافٹ ویئر ریپوزٹری میں، مکمل ریگریشن ٹیسٹ سوٹ کو چلانے کے لیے 20 گھنٹے سے زیادہ کا وقت درکار ہوتا ہے، یعنی ڈویلپرز کو اکثر کوڈ جمع کرانے کے بعد فیڈ بیک حاصل کرنے کے لیے اگلے دن تک انتظار کرنا پڑتا ہے۔ حل میں متوازی جانچ، ٹیسٹ کیس کی ترجیح، اور اضافی جانچ شامل ہیں۔ متوازی ٹیسٹنگ ٹیسٹ سویٹ کو ایک سے زیادہ ایگزیکیوشن نوڈس میں تقسیم کرتی ہے، جس سے عمل درآمد کا وقت تقریباً ایک-اصل کے دسویں حصے تک کم ہو جاتا ہے۔ ٹیسٹ کیس کی ترجیح تاریخی خرابی کی تقسیم پر مبنی ہے، 20% ٹیسٹ کیسز کو ترجیح دیتے ہیں جن میں نئے نقائص کا پتہ لگانے کا زیادہ امکان ہوتا ہے۔ یہ ذیلی سیٹ تقریباً 70% نئے نقائص کو پکڑ سکتا ہے۔ انکریمنٹل ٹیسٹنگ صرف موجودہ کوڈ کی تبدیلی سے متعلق ٹیسٹ کیسز کو انجام دیتی ہے، ٹیسٹ کے دائرہ کار کو متحرک طور پر فلٹر کرنے کے لیے تبدیلی سے اثرات کے دائرہ کار کی شناخت کے لیے جامد تجزیہ کا استعمال کرتے ہوئے۔
III سافٹ ویئر کی خرابی کی پیمائش اور جڑ کی وجہ کا تجزیہ
سافٹ ویئر کے نقائص کے لیے پیمائش کی پیمائش کو ہارڈ ویئر کے نقائص سے مختلف طریقے سے علاج کرنے کی ضرورت ہے۔ ہارڈ ویئر کے نقائص عام طور پر نقائص کی کثافت پر توجہ مرکوز کرتے ہیں، جیسے فی ملین حصوں میں نقائص کی تعداد۔ تاہم، سافٹ ویئر کی خرابی کی تقسیم Pareto کے اصول کی پیروی کرتی ہے، جس میں تقریباً 80% شدید نقائص 20% ماڈیولز میں مرتکز ہوتے ہیں۔ اس لیے، ایک زیادہ موثر میٹرک ماڈیول-لیول ڈیفیکٹ کنورجنسی ٹرینڈ ہے، یعنی ہر ماڈیول کے اعادہ کے لیے کھلے نقائص میں خالص تبدیلی۔ اگر کوئی ماڈیول لگاتار تین تکرار کے لیے کھلے نقائص میں خالص اضافہ دکھاتا ہے، تو یہ ایک بنیادی تعمیراتی مسئلہ کی تجویز کرتا ہے جس میں ری فیکٹرنگ کا جائزہ لینے کی ضرورت ہوتی ہے۔ خرابی کی جڑ کے تجزیہ کی گہرائی سے بچاؤ کے اقدامات کی تاثیر کا تعین ہوتا ہے۔ عام طور پر استعمال ہونے والا درجہ بندی کا فریم ورک سافٹ ویئر کی خرابی کی بنیادی وجوہات کو پانچ اقسام میں درجہ بندی کرتا ہے: ضرورت کو سمجھنا انحراف، ڈیزائن کی منطق کے نقائص، کوڈنگ پر عمل درآمد کی غلطیاں، کنفیگریشن مینجمنٹ کی غلطیاں، اور ماحولیاتی انحصار کے فرق۔ کنفیگریشن مینجمنٹ کی غلطیاں سافٹ ویئر پروجیکٹس کے لیے ایک منفرد زمرہ ہیں۔ عام مثالوں میں مڈل ویئر لائبریری کا غلط ورژن استعمال کرنا، کمپائلر آپشن کی متضاد سیٹنگز، اور برانچ انضمام کے دوران اہم اصلاحات کا غائب ہونا شامل ہیں۔ ایک پروجیکٹ میں، ڈیلیوری سے پہلے ٹیسٹنگ کے آخری دور کے دوران بریک لائٹ کنٹرول منطق کی خرابی دریافت ہوئی۔ خرابی کا پتہ تین ماہ قبل برانچ کے انضمام میں پایا گیا تھا، جہاں ڈویلپر نے مرکزی برانچ سے فیچر کوڈ کو ضم کرتے وقت بریک لائٹ کنٹرول ماڈیول میں ہونے والی تمام تبدیلیوں کو مسترد کرنے کا غلط انتخاب کیا تھا۔ اس کیس سے پتہ چلتا ہے کہ برانچ انضمام کے بعد فرق کا موازنہ ایک لازمی گیٹ بننا چاہیے، انضمام کی درخواستوں کا جائزہ لینے کے لیے ذمہ دار نامزد اہلکاروں کے ساتھ۔
چہارم سافٹ ویئر ریکال اور OTA مینجمنٹ
OTA ٹیکنالوجی کے بڑے پیمانے پر اپنانے کے ساتھ، سافٹ ویئر کی خرابیوں کو دور کرنے کے طریقہ کار میں بنیادی تبدیلی آ رہی ہے۔ روایتی سافٹ ویئر ریکالز کے لیے گاڑیوں کو چمکانے کے لیے سروس سینٹرز کا دورہ کرنے کی ضرورت ہوتی ہے، جو کہ مہنگا، وقت- خرچ ہوتا ہے، اور صارف کی کم تعمیل کا شکار ہوتا ہے۔ او ٹی اے کی یادیں براہ راست ریموٹ پش کے ذریعے مکمل کی جا سکتی ہیں، لیکن ریگولیٹری ضروریات