2.11 سافٹ ویئر معیار

جائزہ اور محرکات

سافٹ ویئر معیار اس بات کا نام ہے کہ نظام بیان کردہ ضروریات اور معقول توقعات کو کتنی اچھی طرح پورا کرتا ہے۔ اس کا مطلب اس سے زیادہ ہے کہ وہ کام کرتا ہے یا نہیں: اس کا مطلب ہے کہ نظام قابل اعتماد، محفوظ، قابل دیکھ بھال، قابل استعمال، کارکردگی والا، اور وقت کے ساتھ اپنے مقصد کے لیے موزوں ہے۔ معیار ٹیسٹنگ سے وسیع ہے۔ ٹیسٹنگ (باب 2.4) ایک سرگرمی ہے جو نقائص سامنے لاتی ہے۔ معیار صحیح چیز کو اچھی طرح بنانے کا، اور شواہد کے ساتھ جاننے کا کہ آپ نے ایسا کیا ہے، پورا نظم و ضبط ہے۔ نظام ہر ٹیسٹ پاس کر کے بھی کم معیار ہو سکتا ہے اگر وہ ناقابل دیکھ بھال، ناقابل رسائی، یا اس سے خراب موزوں ہو جو صارفین کو دراصل چاہیے۔

بڑی ٹیم میں معیار کسی ایک شخص کے ذہن یا کسی ایک ٹیم کی عادتوں میں نہیں رہ سکتا۔ سینکڑوں انجینئروں، متعدد مصنوعات، اور طویل العمر نظاموں کو معیار کی مشترک تعریف، اس کی یقین دہانی کے واضح عمل، اور ایسی پیمائشیں چاہییں جو بتائیں کہ وہ بہتر ہو رہا ہے یا بدتر۔ اس کے بغیر “معیار” مبہم امنگ بن جاتا ہے جو ڈیڈ لائن کے خلاف ہر بحث ہار جاتی ہے، اور نقائص اس وقت تک جمع ہوتے ہیں جب تک تبدیلی سست اور خطرناک نہ ہو جائے۔

انٹرپرائز اور سرکاری ترتیبوں میں داؤ اور بلند ہوتے ہیں۔ ضابطے کے پابند، حفاظت کے لیے اہم، اور شہریوں کا سامنا کرنے والے نظاموں کو معیار صرف دعویٰ کرنے کے بجائے دکھانا پڑتا ہے: دستاویزی عمل، قابل سراغ شواہد، اور آزادانہ توثیق اکثر لازمی ہیں۔ ناقص معیار براہ راست مالی، قانونی اور ساکھ کی لاگت اٹھاتا ہے، اور بعض شعبوں میں لوگوں کو خطرے میں ڈالتا ہے۔ ماڈلز، عمل، پیمائش اور ثقافت سے بنا سوچا سمجھا معیار کا نظم و ضبط ہی معیار کو اتفاق سے منظم نتیجہ بناتا ہے۔

بنیادی اصول

• معیار مقصد کے لیے موزونیت اور تقاضوں کی مطابقت ہے؛ دونوں کو واضح طور پر متعین کریں۔
• معیار بنایا جاتا ہے، ٹیسٹ سے ڈالا نہیں جاتا؛ توثیق نقائص ڈھونڈتی ہے، مگر روک تھام انہیں ہونے سے بچاتی ہے۔
• معیار کی یقین دہانی (کیا ہمارے عمل درست ہیں؟) کو معیار کے کنٹرول (کیا یہ پروڈکٹ اچھی ہے؟) سے الگ کریں۔
• توثیق پوچھتی ہے “کیا ہم نے اسے درست بنایا؟”؛ جائز قرار دینا پوچھتا ہے “کیا ہم نے درست چیز بنائی؟”
• معیار کو چند بامعنی اشاریوں سے ناپیں؛ اشاریوں کو اہداف نہیں، اشارے سمجھیں۔
• نقص کی لاگت اتنی بڑھتی ہے جتنا دیر سے ملے، اس لیے معیار کی سرگرمیاں جلد منتقل کریں۔
• معیار پورے ادارے اور اس کی ثقافت کی خاصیت ہے، آخر میں دروازہ نہیں۔

سفارشات

ISO/IEC 25010 جیسا مشترک معیار کا ماڈل اپنائیں

کوئی تسلیم شدہ پروڈکٹ کے معیار کا ماڈل اپنا کر اپنے ادارے کو معیار کی مشترک لغت دیں۔ ISO/IEC 25010 خصوصیات متعین کرتا ہے جن میں فعلی موزونیت، کارکردگی کی استعداد، مطابقت، قابل استعمال ہونا، قابل اعتمادی، سلامتی، دیکھ بھال کی اہلیت، اور قابل منتقلی ہونا شامل ہیں۔ اسے معیار کو ٹھوس بنانے کے لیے استعمال کریں: ہر نظام کے لیے طے کریں کہ کون سی خصوصیات سب سے زیادہ اہم ہیں اور ہر ایک کے لیے “کافی اچھا” کا مطلب کیا ہے۔ یہ پروڈکٹ کے معیار کی خصوصیات وہی معیار کی صفات ہیں جو فن تعمیر (باب 3.1) کو چلاتی ہیں۔ معیار اور فن تعمیر ایک ہی تشویش کے دو نظارے ہیں، اس لیے انہیں دو مقابل فہرستوں کے بجائے ترجیحات کی ایک مشترک فہرست بانٹنے دیں۔

معیار کی یقین دہانی کو معیار کے کنٹرول سے الگ کریں

معیار کی یقین دہانی (QA) اور معیار کے کنٹرول (QC) کو الگ مگر تکمیلی سرگرمیاں سمجھیں۔ QA عمل پر مبنی اور روک تھام والی ہے: یہ کام کرنے کا طریقہ بہتر کرتی ہے، معیارات، ریویو، مکمل کی تعریفوں اور تربیت کے ذریعے، تاکہ نقائص پہلی جگہ ظاہر ہونے کا امکان کم ہو۔ QC پروڈکٹ پر مبنی اور سراغ لگانے والا ہے: یہ حقیقی کام کی مصنوعات کا معائنہ کرتا ہے، جیسے ٹیسٹنگ، کوڈ ریویو اور آڈٹ، تاکہ وہ نقائص پکڑے جو اندر گھس گئے۔ پختہ ادارہ دونوں میں سرمایہ کاری کرتا ہے، مگر QA کی طرف جھکتا ہے، کیونکہ نقائص روکنا انہیں ڈھونڈ کر ٹھیک کرنے سے سستا ہے۔

معیار کے انتظام کے واضح عمل چلائیں

معیار کو خاموش امید کے بجائے منظم عمل بنائیں۔ اہم کام کے لیے معیار کا منصوبہ لکھیں جو ہدف کی معیار کی خصوصیات، یقین دہانی اور کنٹرول کی سرگرمیاں، قبولیت کے معیار، اور جوابدہ شخص بتائے۔ اسے ان عملوں میں بُنیں جو آپ کے پاس پہلے سے ہیں: کوڈ ریویو (باب 2.5) بطور کنٹرول اور علم بانٹنے کا ذریعہ، ٹیسٹنگ کی حکمت عملی (باب 2.4) بطور خودکار حفاظتی جال، اور اسٹیٹک تجزیہ بطور مسلسل معائنہ۔ معیار کے ڈیٹا کا باقاعدگی سے جائزہ لیں اور رجحانات پر عمل کریں، صرف واقعات پر ردعمل دینے کے بجائے۔

توثیق اور جائز قرار دینے کو الگ نظم و ضبط کے طور پر برتیں

توثیق تصدیق کرتی ہے کہ کام کی مصنوعات اپنی تصریحات پوری کرتی ہیں، یعنی ہر مرحلے کے درست ان پٹس درست آؤٹ پٹس دیتے ہیں، ریویو، اسٹیٹک تجزیہ، اور تقاضوں کے مقابل ٹیسٹنگ سے۔ جائز قرار دینا تصدیق کرتا ہے کہ مکمل نظام واقعی صارف کی ضروریات اور مقصود استعمال پوری کرتا ہے، صارف کی ٹیسٹنگ، قبولیت کی ٹیسٹنگ، پائلٹس، اور میدانی فیڈبیک سے۔ آپ کو دونوں چاہییں۔ نظام ناقص تصریح کے مقابل درست ہو سکتا ہے (توثیق شدہ مگر جائز نہیں)، یا وہ حقیقی ضرورت کو مخاطب کر سکتا ہے جبکہ نقائص رکھتا ہو (جائز مگر توثیق شدہ نہیں)۔ ضابطے کے پابند ماحول میں ڈویلپرز سے الگ فریق کی آزادانہ توثیق اور جائز قرار دینا (IV&V) لازمی ہو سکتا ہے۔

بامعنی اشاریوں سے معیار ناپیں

معیار کے نتائج اور ان کے محرکات کی عکاسی کرنے والے اشاریوں کا چھوٹا سیٹ چنیں اور انہیں وقت کے ساتھ دیکھیں۔ مفید پیمانوں میں نقص کی کثافت، نقص کے فرار کی شرح (پروڈکشن بمقابلہ ریلیز سے پہلے ملے نقائص)، پتہ لگانے اور مرمت کا اوسط وقت، تبدیلی کی ناکامی کی شرح، پیچیدگی اور تکرار جیسے کوڈ کی صحت کے اشارے، اور صارف کی رپورٹ کردہ مسائل اور رسائی پذیری کی مطابقت جیسے توثیق کے اشارے شامل ہیں۔ دکھاوے اور کھیلنے کے قابل اشاریوں سے بچیں: جو اشاریہ ہدف بن جائے وہ حقیقت ناپنا چھوڑ دیتا ہے۔ اعداد کو ریویو اور صارف کے فیڈبیک کے معیاری اشاروں کے ساتھ جوڑیں۔

نقائص کی منظم طور پر خصوصیات متعین کریں اور انہیں سنبھالیں

نقائص کو ڈیٹا سمجھیں، صرف بجھانے کی آگ نہیں۔ انہیں شدت، قسم، اور بنیادی وجہ سے درجہ بند کریں۔ دریافت سے حل تک انہیں ٹریک کریں۔ دہراؤ روکنے کے لیے نمونے ڈھونڈیں۔ ایک بار کی غلطیوں کو نظامی کمزوریوں سے الگ پہچاننے کے لیے بنیادی وجہ کا تجزیہ اور نقص کی درجہ بندی جیسی تکنیکیں استعمال کریں۔ جو آپ سیکھیں اسے QA میں واپس کھلائیں، اپ ڈیٹ شدہ معیارات، شامل کیے گئے ٹیسٹوں، اور بہتر ریویو کے ذریعے، تاکہ نقص کی وہی قسم واپس نہ آئے۔ جس نقص کو اس کی وجہ سمجھے بغیر ٹھیک کیا جائے وہ نقص ہے جسے آپ نے واپس بلایا۔

معیار کی لاگت کو سوچ سمجھ کر سنبھالیں

کلاسیکی زمروں سے معیار کی معاشیات سمجھیں: روک تھام کی لاگتیں (تربیت، معیارات، اچھا ڈیزائن، ٹولنگ)، جانچ کی لاگتیں (ریویو، ٹیسٹنگ، آڈٹ)، اور ناکامی کی لاگتیں (ریلیز سے پہلے اندرونی دوبارہ کام، نیز صارفین کو ملنے والی بیرونی ناکامیاں، جو کہیں زیادہ مہنگی ہیں)۔ اپنی سرمایہ کاری کو روک تھام اور ابتدائی جانچ کی طرف منتقل کریں، کیونکہ وہاں لگایا ہر ڈالر بعد میں ناکامی کی لاگت کے بہت سے ڈالر بچاتا ہے۔ ان لاگتوں کو نظر آنے والا بنائیں، تاکہ “ہمارے پاس معیار کے لیے وقت نہیں” کو وہی سمجھا جائے جو وہ ہے: ناکامی پر زیادہ خرچ کرنے کا انتخاب۔

معیار کی ثقافت بنائیں

معیار کو ہر ایک کی ذمہ داری بنائیں، جس کے مالک سافٹ ویئر بنانے والی ٹیمیں ہوں، نہ کہ نیچے کے QA شعبے کو دیا جائے جو آخر میں اس کا معائنہ کرے۔ رہنماؤں کو معیار کے نتائج کو انعام دینا چاہیے، نقائص اور قریب کی خطاؤں کی رپورٹنگ محفوظ بنانی چاہیے، اور معیار کے ڈیٹا کو ڈنڈے کے بجائے سیکھنے کا آلہ سمجھنا چاہیے۔ نقائص پر بلا الزام طریقہ مسائل کو جلد کھلے میں لاتا ہے۔ الزام والا انہیں اس وقت تک چھپاتا ہے جب تک وہ مہنگے نہ ہوں۔

سمجھوتے: فوائد اور نقصانات

عمل / انتخاب	فوائد	نقصانات
رسمی معیار کا ماڈل (ISO 25010)	مشترک لغت؛ واضح ترجیحات	عقیدے سے لاگو ہو تو بوجھ
بھاری معیار کی یقین دہانی (روک تھام)	کم نقائص؛ کم کل لاگت	آگے کی سرمایہ کاری؛ واپسی دکھانے میں سست
بھاری معیار کا کنٹرول (معائنہ)	وہ نقائص پکڑتا ہے جو پھسل جائیں	مہنگا؛ نقائص دیر سے ملتے ہیں
آزاد IV&V	اعلیٰ یقین دہانی؛ معروضی	مہنگا؛ سست؛ مخالفانہ لگ سکتا ہے
بھرپور معیار کے اشاریے	مرئیت؛ ابتدائی انتباہ	کھیلنے کا خطرہ؛ پیمائش کا بوجھ
مخصوص QA ٹیم	توجہ اور مہارت	ڈویلپرز سے ذمہ داری ہٹا سکتی ہے
ٹیموں کی ملکیت والا معیار	ملکیت؛ تیز فیڈبیک	ہر جگہ نظم و ضبط اور مہارت درکار

مرکزی سمجھوتا سرمایہ کاری بمقابلہ یقین دہانی ہے، جو وقت سے شکل پاتا ہے۔ روک تھام آج پیسہ خرچ کرتی ہے تاکہ بعد کی بڑی ناکامی کی لاگتوں سے بچا جا سکے۔ اس لیے معیار کی معاشی طور پر درست سطح زیادہ سے زیادہ نہیں؛ یہ وہ نقطہ ہے جہاں مزید یقین دہانی کی حدی لاگت اس ناکامی کی لاگت کے برابر ہو جو وہ بچاتی ہے۔ وہ نقطہ حفاظت کے لیے اہم نظاموں کے لیے اونچا اور کم داؤ والے اندرونی ٹولز کے لیے نیچا ہے۔ دوسرا بار بار کا کھنچاؤ ملکیت کا ہے۔ مرکزی QA گروہ مہارت بناتے ہیں مگر ڈویلپرز کو ذمہ داری ہٹانے دے سکتے ہیں۔ ٹیم کی ملکیت والا معیار ملکیت بناتا ہے مگر ہر ٹیم میں مہارت اور نظم و ضبط کا تقاضا کرتا ہے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. جب نقص کی وہی قسم دو بار ظاہر ہو تو کیا ہم بنیادی وجہ کا تجزیہ کرتے ہیں، یا بس دوبارہ ٹھیک کر دیتے ہیں؟ جس نقص کو اس کی وجہ سمجھے بغیر ٹھیک کیا جائے وہ نقص ہے جسے آپ نے واپس بلایا، اور بڑی ٹیم میں وہی بنیادی وجہ کئی سروسز میں سامنے آ سکتی ہے اس سے پہلے کہ کوئی نقطے ملائے۔ نقائص کو ڈیٹا سمجھنا (شدت، قسم اور وجہ سے درجہ بند، پھر نمونوں کے لیے کھنگالا گیا) اس ٹیم میں فرق ہے جو مسلسل زیادہ قابل اعتماد ہوتی جاتی ہے اور اس میں جو وہی غلطی دوبارہ ٹھیک کرنے میں مصروف رہتی ہے۔ اجلاس میں اپنا نقص ٹریکر لائیں اور بار بار آنے والی علامات دیکھیں: حالیہ کتنے واقعات ایسی وجہ بانٹتے ہیں جسے آپ نے نظامی طور پر حل نہیں کیا؟ جواب کو روک تھام کو کھلانا چاہیے، تاکہ بار بار آنے والی وجہ اپ ڈیٹ شدہ معیار، نیا مشترک مددگار، شامل ٹیسٹ، یا بہتر ریویو چیک لسٹ چلائے، کیونکہ اسی طرح ایک جگہ کی اصلاح پوری قسم کو واپس آنے سے روکتی ہے۔

2. کیا ہماری ٹیم میں نقص یا قریب کی خطا کی رپورٹ کرنا محفوظ ہے، اور جو شخص اسے اٹھاتا ہے اس کے ساتھ کیا ہوتا ہے؟ معیار ثقافت کی خاصیت ہے، اور بلا الزام طریقہ مسائل کو جلد کھلے میں لاتا ہے جبکہ الزام والا انہیں مہنگے ہونے تک چھپاتا ہے، جس کا مطلب ضابطے کے پابند یا شہریوں کا سامنا کرنے والے نظام میں عوامی ناکامی یا جرمانہ ہو سکتا ہے۔ یہ بڑے پیمانے پر سب سے زیادہ اہم ہے، جہاں خطرے کے سب سے قریب انجینئر اکثر جونیئر ہوتا ہے اور خاموش رہنے کی ترغیب مضبوط ہے۔ ایماندار اشارے لائیں: کیا قریب کی خطائیں لاگ اور زیر بحث آتی ہیں، یا غائب ہو جاتی ہیں؟ کیا پوسٹ مارٹم وجوہات کا نام لیتے ہیں یا لوگوں کا؟ عمل یہ ہے کہ معیار کے ڈیٹا کو ڈنڈے کے بجائے سیکھنے کا آلہ بنائیں، مسائل سامنے لانے والوں کو انعام دیں، اور بلا الزام پوسٹ مارٹم چلائیں، کیونکہ آپ وہ نہیں روک سکتے جو آپ کی ٹیم رپورٹ کرنے سے ڈرتی ہے۔

3. کیا جائز قرار دینا واقعی ریلیز روک سکتا ہے، اور جب ڈیڈ لائن قریب ہو تو یہ اختیار کس کے پاس ہے؟ توثیق (کیا ہم نے درست بنایا؟) اور جائز قرار دینا (کیا ہم نے درست چیز بنائی؟) الگ نظم و ضبط ہیں، اور جائز قرار دینے میں دانت تبھی ہیں جب ناکام رسائی پذیری کی جانچ، ناکام قبولیت کا ٹیسٹ، یا نقصان دہ صارف کی تحقیق واقعی ریلیز روک سکے۔ انٹرپرائز اور سرکاری ترتیبوں میں یہ اکثر لازمی ہے، کبھی ڈویلپرز سے الگ فریق کی آزادانہ توثیق اور جائز قرار دینے کے ذریعے، اور “ہم نے پھر بھی ریلیز کر دیا” ایسا جواب نہیں جو نگران ادارہ قبول کرے۔ اپنی آخری چند ریلیز لائیں: کیا کسی معیار کے اشارے نے کبھی واقعی ایک کو روکا، یا دروازہ ہمیشہ تاریخ کے آگے جھک جاتا ہے؟ اگر جائز قرار دینے نے کبھی ریلیز نہیں روکی تو وہ آرائش ہے، اور حل یہ ہے کہ قبولیت کے معیار معیار کے منصوبے میں پہلے لکھیں، نام لیں کہ آگے بڑھنے یا نہ بڑھنے کا فیصلہ کس کا ہے، اور اس فیصلے کو ترسیل کے دباؤ سے آزاد حقیقی اختیار دیں۔

4. کیا ہم واقعی اپنے ناقص معیار کی لاگت جانتے ہیں، اور کیا ہم جان بوجھ کر خرچ کو ناکامی سے روک تھام کی طرف منتقل کر رہے ہیں؟ ناقص معیار کی لاگت (COPQ) وہ پیسہ ہے جو اندرونی دوبارہ کام، پروڈکشن واقعات، ہنگامی اصلاحات، سپورٹ کے بوجھ، کھوئے ہوئے صارفین، اور جرمانوں میں جاتا ہے، اور یہ تقریباً ہمیشہ ریویو اور ٹیسٹنگ پر نظر آنے والے خرچ سے بڑا ہوتا ہے۔ بڑی ٹیم میں ناکامی کی لاگتیں واقعات کے چینلز، سپورٹ قطاروں، اور اس دوبارہ کام میں بکھری ہیں جسے کوئی دوبارہ کام کے طور پر لاگ نہیں کرتا، اس لیے وہ کوئی جمع کرنے تک غیر مرئی رہتی ہیں۔ کھنچاؤ یہ ہے کہ روک تھام بجٹ کے چکر میں آج پیسہ خرچ کرتی ہے ان ناکامی کی لاگتوں سے بچنے کے لیے جو بعد میں اور کسی اور کے بجٹ پر پڑتی ہیں، جو سودے کو ہمیشہ کے لیے ٹالنا آسان بناتا ہے۔ حقیقی اعداد لائیں: واقعات کی گنتی اور لاگت، دوبارہ کام کے گھنٹے، فرار شدہ نقص کی شرح، اور روک تھام، جانچ اور ناکامی میں خرچ کی موجودہ تقسیم، پھر فیصلہ کریں کہ کیا امتزاج کو پہلے منتقل ہونا چاہیے۔ انٹرپرائز اور سرکاری نظاموں کے لیے، جہاں زندگی بھر کی لاگت کا بڑا حصہ پہلی ریلیز کے بعد آتا ہے، COPQ ان لوگوں کے سامنے رکھیں جو بجٹ رکھتے ہیں، کیونکہ نگران ادارے کو نظر آنے والا عدد “معیار” کی مبہم اپیل سے کہیں مشکل سے بدلا جا سکتا ہے۔

5. ہمارے معیار کے کون سے اشاریے خاموشی سے اہداف بن گئے ہیں، اور اب وہ کون سا رویہ چلا رہے ہیں؟ جو اشاریہ ہدف بن جائے وہ حقیقت ناپنا چھوڑ دیتا ہے: کوریج کی فیصد کا پیچھا کریں تو آپ کو عدد ہلانے والے ٹیسٹ ملتے ہیں، نقائص پکڑنے والے نہیں۔ بڑے پیمانے پر یہ خطرناک ہے، کیونکہ درجنوں ٹیموں میں مشترک ڈیش بورڈ سب کے لیے ترغیبات طے کرتا ہے، اور قابل کھیل اشاریہ کھیلنے کو ایک ساتھ ہر جگہ پھیلاتا ہے۔ متصادم غور یہ ہے کہ آپ کو پھر بھی پیمائش چاہیے، اس لیے جواب شاذ ہی “اشاریہ چھوڑ دیں” ہے بلکہ “اسے مخالف اشارے کے ساتھ جوڑیں اور ریویو اور صارفین کے معیاری شواہد کے ساتھ پڑھیں” ہے۔ اپنا موجودہ اشاریوں کا سیٹ لائیں اور ہر ایک کے لیے پوچھیں کہ دباؤ میں کوئی معیار بہتر کیے بغیر اسے کیسے ہلا سکتا ہے، اور کیا آپ نے ایسا ہوتے دیکھا ہے۔ ضابطے کے پابند اور شہریوں کا سامنا کرنے والی ترتیبوں میں خاص طور پر ان مطابقت کے اشاریوں سے محتاط رہیں جو سبز نظر آتے ہیں جبکہ بنیادی جائز قرار دینا (رسائی پذیری، صارف کے حقیقی نتائج) کبھی واقعی آزمایا ہی نہ گیا، کیونکہ آڈیٹر آخرکار عدد کے پیچھے کی حقیقت کی جانچ کرے گا۔

6. یہاں معیار کا مالک کون ہے: کوڈ لکھنے والی ٹیمیں، یا آخر میں الگ گروہ، اور ہم دراصل کس کو وسائل دے رہے ہیں؟ ملکیت آگے کی ہر چیز کو شکل دیتی ہے، کیونکہ نیچے کا QA سائلو ڈویلپرز کو اپنے لکھے کوڈ کی ذمہ داری ہٹانے دیتا ہے، جبکہ ٹیم کی ملکیت والا معیار ہر ٹیم میں مہارت اور نظم و ضبط کا تقاضا کر کے ملکیت بناتا ہے۔ بڑی ٹیم پر یہ یا وہ نہیں: پائیدار نمونہ عموماً وہ ہے جہاں ٹیمیں کوڈ ریویو اور خودکار ٹیسٹوں سے معیار کی مالک ہوں، چھوٹے مرکزی گروہ کی مدد سے جو معیارات برقرار رکھے، QA کو عمل کی بہتری کے طور پر چلائے، اور کوچنگ کرے، آخر میں معیار کا معائنہ کرنے کے بجائے۔ ایماندار نقشہ لائیں کہ معیار کا کام اس وقت کہاں ہوتا ہے، نقص کے فرار پر جوابدہ کون ہے، اور بجٹ اور سروں کی گنتی دراصل کہاں بیٹھی ہے بمقابلہ جہاں بیان بازی کہتی ہے کہ معیار رہتا ہے۔ انٹرپرائز اور سرکاری اداروں کے لیے آزاد توثیق اور جائز قرار دینے کا تقاضا شامل کریں: کچھ یقین دہانی کے نظام الگ فریق لازمی کرتے ہیں، اس لیے سوچ سمجھ کر طے کریں کہ کون سے کنٹرول ترسیلی ٹیموں کے ہیں اور کون سے آڈٹ کو مطمئن کرنے کے لیے آزاد رہنے چاہئیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ رفتار رسم سے زیادہ اہم ہے، اس لیے وہ دو یا تین معیار کی خصوصیات کا نام لیں جو واقعی آپ کی پروڈکٹ کی حفاظت کرتی ہیں، عموماً قابل اعتمادی اور دیکھ بھال کی اہلیت، اور پالش کو انتظار کرنے دیں۔ معیار کو پوری ٹیم میں کوڈ ریویو اور معمولی خودکار ٹیسٹ سوٹ سے ملکیت دیں، بجائے الگ QA گروہ بنانے کے جس کا آپ عملہ نہیں رکھ سکتے۔ جب نقص کی وہی قسم دو بار ظاہر ہو تو بنیادی وجہ پر بیس منٹ لگائیں اور ایک مشترک مددگار اور ٹیسٹ شامل کریں، تاکہ روک تھام سستی رہے اور آپ کی تبدیلی کی ناکامی کی شرح کم رہے جب آپ تیز چل رہے ہوں۔

چھوٹا کاروبار۔ معیار کے مخصوص ماہر کے بغیر اور تنگ بجٹ کے ساتھ اس معیار پر انحصار کریں جو ان ٹولز اور پلیٹ فارمز میں بنا ہے جو آپ خریدتے ہیں، بجائے ایسے عمل کے جسے چلانا پڑے۔ جب آپ سافٹ ویئر چنیں تو فروخت کنندہ کے معیار کے شواہد کو خریداری کا حصہ سمجھیں: سلامتی کی حالت، رسائی پذیری، سپورٹ کی جوابدہی، اور ان کی ریلیز کتنی بار ٹوٹتی ہیں۔ پیچیدہ اشاریوں کے پروگرام کے بجائے، جسے برقرار رکھنے والا آپ کے پاس کوئی نہیں، چند سستے، ایماندار اشارے (پروڈکشن واقعات، گاہکوں کی رپورٹ کردہ مسائل، ٹھیک کرنے کا وقت) ٹریک کریں۔

بڑا ادارہ۔ کام بہت سی ٹیموں میں یکسانیت ہے: ISO/IEC 25010 جیسا مشترک معیار کا ماڈل اپنائیں، معیار کی یقین دہانی (عمل) کو معیار کے کنٹرول (پروڈکٹ) سے الگ کریں، اور معیار کی لاگت کے جائزے چلائیں جو خرچ کو روک تھام کی طرف منتقل کریں۔ معیار کو ترسیلی ٹیموں کی ملکیت میں رکھیں، چھوٹے مرکزی گروہ کی مدد سے جو معیارات برقرار رکھے اور نقص کے فرار کی شرح، تبدیلی کی ناکامی کی شرح، اور کوڈ کی صحت کے رجحانات کے ڈیش بورڈز رکھے۔ لغت اور دروازوں کو معیاری بنائیں تاکہ گروہ معیار کے عمل کو دوبارہ ایجاد کرنا چھوڑ دیں، جبکہ ٹیموں کو ان معیارات تک اپنے طریقے سے پہنچنے کی جگہ دیں۔

حکومت۔ خریداری، شفافیت اور عوامی جوابدہی فریم طے کرتی ہیں، اس لیے معیار کے تقاضے معاہدوں میں لکھیں اور دعووں کے بجائے دستاویزی، قابل سراغ معیار کے شواہد کا تقاضا کریں۔ ڈویلپرز سے الگ فریق کی آزادانہ توثیق اور جائز قرار دینا، لازمی رسائی پذیری کی مطابقت، اور آڈٹ ٹریل کے حصے کے طور پر شدت اور بنیادی وجہ والے نقص کے ریکارڈ کی توقع رکھیں۔ ناقص معیار کی لاگت کے اعداد (دوبارہ کام، اپیلیں، سروس کی ناکامیاں) نگران اداروں کو رپورٹ کریں، اور جائز قرار دینے کو ایسی ریلیز روکنے کا حقیقی اختیار دیں جو ان شہریوں کو ناکام کرے جو اس پر انحصار کرتے ہیں۔

مثالیں

اسٹارٹ اپ۔ پانچ افراد کا اسٹارٹ اپ طے کرتا ہے کہ اپنی ابتدائی پروڈکٹ کے لیے قابل اعتمادی اور دیکھ بھال کی اہلیت وہ معیار کی خصوصیات ہیں جو اہم ہیں، اور بے عیب پالش کو انتظار کرنے دیتا ہے۔ معیار پوری ٹیم کی ملکیت ہے: کوڈ ریویو اور معمولی خودکار ٹیسٹ سوٹ کنٹرولز ہیں، اور نقائص سونپنے کے لیے الگ QA گروہ نہیں۔ جب نقص کی وہی قسم دو بار ظاہر ہوتی ہے تو وہ تیز بنیادی وجہ کی نظر پر بیس منٹ لگاتے اور ایک مشترک مددگار اور ٹیسٹ شامل کرتے ہیں، تاکہ وہ ہر بار ہاتھ سے دوبارہ ٹھیک ہونے کے بجائے دہرانا بند کر دے۔ روک تھام کی وہ چھوٹی عادت ان کی تبدیلی کی ناکامی کی شرح کم رکھتی ہے جب وہ ابھی تیز چل رہے ہیں۔

بڑا ادارہ۔ ایک بڑی مالیاتی خدمات کی فرم ISO/IEC 25010 کو اپنی معیار کی لغت کے طور پر اپناتی ہے اور ہر پروڈکٹ کے لیے قابل اعتمادی، سلامتی اور دیکھ بھال کی اہلیت کی ہدف کی سطحیں ریکارڈ کرتی ہے۔ ٹیمیں معیار کی مالک ہیں: کوڈ ریویو اور خودکار ٹیسٹ پائپ لائن میں کنٹرولز ہیں، جبکہ چھوٹا مرکزی گروہ معیارات برقرار رکھ کر اور کوچنگ کر کے QA چلاتا ہے۔ معیار کا ڈیش بورڈ نقص کے فرار کی شرح، تبدیلی کی ناکامی کی شرح، اور کوڈ کی صحت کے رجحانات ٹریک کرتا ہے۔ نقائص درجہ بند اور بنیادی وجہ تک پہنچائے جاتے ہیں، اور بار بار آنے والی وجوہات مشترک لائبریریوں اور چیک لسٹوں کی تازہ کاری چلاتی ہیں۔ قیادت سہ ماہی معیار کی لاگت کا ڈیٹا دیکھتی ہے اور خرچ کو روک تھام کی طرف منتقل کر چکی ہے، پروڈکشن واقعات اور انہیں ٹھیک کرنے کی لاگت دونوں گھٹاتے ہوئے۔

حکومت۔ شہریوں کا سامنا کرنے والے فوائد کے پلیٹ فارم کی فراہمی کرنے والی قومی ایجنسی ایسے یقین دہانی کے نظام کے تحت کام کرتی ہے جو دستاویزی معیار کے شواہد مانگتا ہے۔ وہ ہر ریلیز کے لیے معیار کے منصوبے کے ساتھ رسمی معیار کے انتظام کا عمل چلاتی ہے، ساتھ ڈویلپرز سے الگ ٹیم کی آزادانہ توثیق اور جائز قرار دینا۔ توثیق ہر کام کی پروڈکٹ کو پالیسی تک سراغ شدہ تقاضوں کے مقابل جانچتی ہے۔ جائز قرار دینے میں رسائی پذیری کی مطابقت کی ٹیسٹنگ اور حقیقی شہریوں کے ساتھ صارف کی تحقیق شامل ہے، اور دونوں ریلیز روک سکتے ہیں۔ نقائص آڈٹ ٹریل کے حصے کے طور پر شدت اور بنیادی وجہ کے ساتھ ٹریک ہوتے ہیں، اور ناقص معیار کی لاگت کے اعداد (دوبارہ کام، اپیلیں، اور سروس کی ناکامیاں) روک تھام میں مسلسل سرمایہ کاری کا جواز دینے کے لیے نگران اداروں کو جاتے ہیں۔

کاروباری جواز: محرکات، ROI اور TCO

معیار کی واپسی ملکیت کی کم کل لاگت اور مستقل ترسیلی رفتار ہے۔ معیار کی لاگت کے دو پہلو ہیں۔ اچھا خرچ، روک تھام اور جانچ، نظر آنے والا اور قابو میں ہے: ڈیزائن، معیارات، ریویو، ٹیسٹنگ، اور ٹولنگ۔ ناقص معیار کی لاگت (COPQ) بڑی مگر اکثر چھپی ہوئی ہے: اندرونی دوبارہ کام، پروڈکشن واقعات، ہنگامی اصلاحات، گاہک کی سپورٹ، کھوئے ہوئے صارفین، ضابطے کے جرمانے، اور ساکھ کا نقصان۔ Crosby کی “Quality Is Free” تک جاتے مطالعات نے مسلسل پایا کہ ناقص معیار کی کل لاگت اسے روکنے کی لاگت کو بہت پیچھے چھوڑتی ہے، اور نقائص اتنے ہی مہنگے ہوتے ہیں جتنی دیر سے پکڑے جائیں: ڈیزائن میں ملنے والا مسئلہ پروڈکشن میں ملنے والے اسی مسئلے کی لاگت کا ایک حصہ ہے۔

قیادت کے لیے دلیل “معیار پر زیادہ خرچ کریں” نہیں۔ یہ “کل کم خرچ کرنے کے لیے جلد خرچ کریں” ہے۔ اپنے ڈیٹا (واقعات کی گنتی اور لاگت، دوبارہ کام کے گھنٹے، فرار شدہ نقص کی شرح) سے COPQ پر عدد لگائیں اور دکھائیں کہ روک تھام اور ابتدائی جانچ اسے کیسے نیچے لاتی ہیں۔ معیار کو کاروباری نتائج سے جوڑیں: قابل اعتمادی صارفین کو برقرار رکھتی ہے، دیکھ بھال کی اہلیت آئندہ تبدیلی سستی رکھتی ہے، اور سلامتی اور رسائی پذیری آپ کو قانونی مصیبت سے دور رکھتی ہیں۔ طویل العمر انٹرپرائز اور سرکاری نظاموں میں، جہاں لاگت کا زیادہ تر حصہ پہلی ریلیز کے بعد آتا ہے، معیار کے دیکھ بھال کی اہلیت اور قابل اعتمادی کے پہلو زندگی بھر کی لاگت پر غالب ہیں۔ یہ ابتدائی معیار کی سرمایہ کاری کو آپ کے سب سے زیادہ لیوریج والے فیصلوں میں سے ایک بناتا ہے۔

ضد نمونے اور خامیاں

• آخری دروازے کے طور پر معیار: معیار بنانے کے بجائے آخر میں معائنہ کرنا، اس لیے نقائص تب ملتے ہیں جب وہ سب سے مہنگے ہوں۔
• ٹیسٹنگ کو معیار سمجھ لینا: یہ فرض کرنا کہ ٹیسٹ پاس ہونے کا مطلب اعلیٰ معیار ہے، دیکھ بھال کی اہلیت، قابل استعمال ہونے، اور مقصد کی موزونیت کو نظر انداز کرتے ہوئے۔
• الگ سائلو کے طور پر QA: نیچے کی ٹیم جو “معیار کی مالک” ہے، ڈویلپرز کو اپنے لکھے کوڈ کی ذمہ داری ہٹانے دیتی ہوئی۔
• اشاریوں کا تھیٹر: کوریج کی فیصد یا نقائص کی گنتی کو اہداف بنا کر پیچھا کرنا، جو کھیلنے کو دعوت دیتا اور حقیقی معیار چھپاتا ہے۔
• جائز قرار دینے کے بغیر توثیق: تصریح درست بنانا جبکہ کبھی جانچنا نہیں کہ تصریح حقیقی ضروریات پوری کرتی ہے۔
• بنیادی وجہ کا تجزیہ نہیں: نظامی وجہ کو حل کیے بغیر نقائص انفرادی طور پر ٹھیک کرنا، اس لیے وہی قسم دہراتی ہے۔
• ناقص معیار کی لاگت کو نظر انداز کرنا: معیار کو خالص لاگت سمجھنا کیونکہ ناکامی کی لاگتیں چھپی ہوئی اور بغیر ناپی ہیں۔

پختگی کا ماڈل

سطح 1 (آغاز)۔ معیار غیر متعین اور فی البدیہہ ہے۔ یہ انفرادی محنت پر سوار ہے، زیادہ تر آخر میں دستی ٹیسٹنگ سے جانچا جاتا ہے، اور نقائص سامنے آنے پر ردعملی طور پر سنبھالے جاتے ہیں۔ کوئی مشترک ماڈل نہیں، کوئی اشاریے نہیں، اور یقین دہانی اور کنٹرول کے بیچ کوئی لکیر نہیں۔

سطح 2 (ترقی)۔ بنیادی عمل ظاہر ہوتے ہیں: کوڈ ریویو، خودکار ٹیسٹ، اور نقص ٹریکر۔ معیار کا کچھ ڈیٹا جمع ہوتا ہے، مگر ناہموار، اور ہر ٹیم اپنے طریقے سے کرتی ہے۔ معیار کو اب بھی زیادہ تر ٹیسٹنگ سمجھا جاتا ہے، روک تھام کم سے کم ہے، توثیق ہوتی ہے، اور جائز قرار دینا غیر رسمی ہے۔

سطح 3 (معیار بندی)۔ ادارہ مشترک معیار کا ماڈل (جیسے ISO/IEC 25010) اپناتا ہے، QA کو QC سے الگ کرتا ہے، اور معیار کے منصوبوں اور قبولیت کے معیار کے ساتھ معیار کے انتظام کے عمل چلاتا ہے، جو دستاویزی اور ٹیموں میں مستقل لاگو ہیں۔ توثیق اور جائز قرار دینا الگ اور سوچے سمجھے ہیں، اور نقائص متفقہ اسکیم کے مطابق درجہ بند اور بنیادی وجہ تک پہنچائے جاتے ہیں۔

سطح 4 (انتظام)۔ معیار کو بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ بامعنی اشاریوں کا چھوٹا سیٹ وقت کے ساتھ ٹریک ہوتا ہے (نقص کی کثافت، نقص کے فرار کی شرح، پتہ لگانے اور مرمت کا اوسط وقت، تبدیلی کی ناکامی کی شرح، اور پیچیدگی اور تکرار جیسے کوڈ کی صحت کے اشارے)، اور معیار کی لاگت روک تھام، جانچ اور ناکامی میں مقدار میں بیان کی جاتی ہے۔ قبولیت اور معیار کے دروازے رائے کے بجائے شواہد پر نافذ ہیں، رجحانات کا مقررہ تال پر جائزہ ہوتا ہے، اور جائز قرار دینا واقعی ریلیز روک سکتا ہے۔

سطح 5 (ہم آہنگی)۔ معیار مسلسل بہتر، ثقافتی طور پر ملکیت والا نظم و ضبط ہے جو کاروبار اور خطرے کی منصوبہ بندی سے مربوط ہے۔ روک تھام پر زور ہے، معیار کی لاگت کا ڈیٹا سرمایہ کاری کی رہنمائی کرتا ہے، اور بنیادی وجہ کے نتائج نظامی طور پر دہراؤ روکتے ہیں۔ ٹیمیں شروع سے آخر تک معیار کی مالک ہیں، اشاریے مسلسل بہتری کو کھلاتے ہیں، اور مصنوعات، خطرات اور ضابطے بدلنے کے ساتھ ادارہ اپنے معیار کا عمل ڈھالتا ہے۔ یہ باب 10.8 کے پختگی کے ماڈلز کی اعلیٰ سطحوں سے ہم آہنگ ہے۔

بحث کے لیے خیالات

• آپ کے نظاموں کے لیے ISO/IEC 25010 کی کون سی معیار کی خصوصیات سب سے زیادہ اہم ہیں، اور ہر ایک کے لیے “کافی اچھا” کیا ہے؟
• روک تھام، جانچ اور ناکامی کے خرچ کے امتزاج میں آپ کا ادارہ کہاں بیٹھتا ہے، اور کیا اسے منتقل ہونا چاہیے؟
• کیا آپ عملاً توثیق کو جائز قرار دینے سے الگ کرتے ہیں، یا دونوں کو “ٹیسٹنگ” میں سمیٹ دیتے ہیں؟
• کیا معیار کے مالک سافٹ ویئر بنانے والی ٹیمیں ہیں، یا الگ گروہ کو سونپا گیا ہے، اور اگر آپ اسے منتقل کریں تو کیا بدلے گا؟
• آپ کے ناقص معیار کی اصل لاگت کیا ہے، اور کیا آپ اسے کاروباری دلیل بنانے کے لیے کافی اچھی طرح ناپ سکتے ہیں؟
• آپ کے معیار کے کون سے اشاریے حقیقی اشارے ہیں، اور کون سے کھیلنے کے قابل اہداف بن گئے ہیں؟

اہم نکات

• معیار ٹیسٹنگ سے وسیع ہے: یہ قابل اعتمادی، سلامتی، اور دیکھ بھال کی اہلیت جیسی خصوصیات میں مقصد کی موزونیت اور مطابقت ہے۔
• مشترک معیار کا ماڈل (ISO/IEC 25010) استعمال کریں تاکہ معیار کی صفات واضح ہوں اور فن تعمیر (باب 3.1) سے ہم آہنگ ہوں۔
• معیار کی یقین دہانی (روکنا، عمل) کو معیار کے کنٹرول (پتہ لگانا، پروڈکٹ) سے الگ کریں، اور روک تھام کی طرف جھکیں۔
• توثیق (درست بنایا) اور جائز قرار دینا (درست چیز بنائی) کو الگ نظم و ضبط کے طور پر برتیں۔
• معیار کو چند بامعنی اشاریوں سے ناپیں، اور دہراؤ روکنے کے لیے نقائص کی شدت اور بنیادی وجہ سے خصوصیات متعین کریں۔
• معیار کی لاگت کو سنبھالیں: روک تھام اور ابتدائی جانچ ناکامی سے کہیں سستی ہیں، خاص طور پر طویل العمر نظاموں میں۔
• بلا الزام معیار کی ثقافت بنائیں جہاں ٹیمیں معیار کی مالک ہوں، کوڈ ریویو (باب 2.5) اور ٹیسٹنگ کی حکمت عملی (باب 2.4) کی مدد سے۔

حوالہ جات اور مزید مطالعہ

• IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Quality knowledge area.
• ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models.
• ISO/IEC 25000 series (SQuaRE), Software product quality requirements and evaluation.
• Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain.
• W. Edwards Deming, Out of the Crisis.
• Capers Jones and Olivier Bonsignour, The Economics of Software Quality.
• Gerald Weinberg, Quality Software Management.
• ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (quality assurance and V&V process context).