3.9 سسٹمز انجینئرنگ

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

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

یہ سافٹ ویئر فن تعمیر سے مختلف ہے۔ سافٹ ویئر فن تعمیر (باب 3.1) طے کرتا ہے کہ سافٹ ویئر کے اجزا کیسے ترتیب پاتے ہیں اور آپس میں کیسے بات کرتے ہیں۔ سسٹمز انجینئرنگ ایک سطح اوپر بیٹھتی ہے۔ وہ پوچھتی ہے کہ پورے نظام کو کیا کرنا ہے، سافٹ ویئر اور ہارڈ ویئر اور انسانی آپریٹرز کام کیسے بانٹتے ہیں، اور آپ کیسے ثابت کریں گے کہ تیار شدہ چیز کام کرتی ہے۔ اس کا پیشہ ورانہ گھر INCOSE ہے، International Council on Systems Engineering، اور اس کا بنیادی معیار ISO/IEC/IEEE 15288 ہے، جو نظام کی زندگی کے عمل متعین کرتا ہے۔

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

یہ باب سافٹ ویئر کے تقاضوں (باب 2.8)، فن تعمیر کی بنیادوں (باب 3.1)، سافٹ ویئر کے ماڈلز اور طریقوں (باب 2.12)، باہمی عملیت اور کھلے معیارات (باب 3.8)، اور پراجیکٹ مینجمنٹ (باب 10.6) سے جڑتا ہے۔

بنیادی اصول

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

سفارشات

نظام کے پورے زندگی کے چکر کو منظم کریں

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

اصحاب مفاد کی ضروریات گرفت میں لیں اور سراغ پذیری کے ساتھ تقاضے مختص کریں

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

انٹرفیسز کو واضح طور پر منظم کریں

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

انضمام کریں، پھر توثیق اور تصدیق کریں

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

ماڈل پر مبنی سسٹمز انجینئرنگ اپنائیں

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

ابھرتے رویے پر نظاموں کی سوچ لاگو کریں

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

ہارڈ ویئر اور سافٹ ویئر کی مشترکہ انجینئرنگ کریں

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مثالیں

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

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

حکومت۔ ایک قومی فضائی نیویگیشن کی اتھارٹی اپنے فضائی ٹریفک کے انتظام کے نظام کو جدید کرتی ہے، حفاظت کے لیے نازک نظاموں کا نظام جو ریڈارز، کنٹرولر ورک اسٹیشنز، مواصلات، اور سافٹ ویئر پر پھیلا ہے اور چوبیس گھنٹے چلتا ہے۔ پروگرام پورے زندگی کے چکر میں ISO/IEC/IEEE 15288 کی پیروی کرتا ہے۔ توثیق ثابت کرتی ہے کہ ہر ذیلی نظام اپنی تفصیل پوری کرتا ہے، اور حقیقی کنٹرولرز کے ساتھ سمیولیشن سے تصدیق ثابت کرتی ہے کہ مربوط نظام کسی بھی زندہ ٹریفک کے اس پر انحصار کرنے سے پہلے محفوظ آپریشنز کو سہارا دیتا ہے۔ سخت V&V اتھارٹی کو ہر قدم پر فال بیک کے ساتھ مراحل میں کٹ اوور کرنے دیتی ہے، کیونکہ یہاں غیر ٹیسٹ شدہ ابھرتی ناکامی عوامی حفاظت کا واقعہ ہے۔

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

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

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

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

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

پختگی کا ماڈل

سطح 1: آغاز۔ سسٹمز انجینئرنگ فی البدیہہ اور ردعملی ہے۔ تقاضے بکھری دستاویزات میں رہتے ہیں، انٹرفیسز انضمام پر دریافت ہوتے ہیں، اور توثیق وہ ہے جو ٹیسٹنگ اتفاق سے ہو جائے۔ بڑے پروگرام باقاعدگی سے حد سے بڑھتے اور ٹیم کو دیر سے حیران کرتے ہیں۔

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

سطح 3: معیار بندی۔ سسٹمز انجینئرنگ دستاویزی، ادارے بھر کا نظم و ضبط ہے جو ISO/IEC/IEEE 15288 سے ہم آہنگ اور ٹیموں میں نافذ ہے۔ پورے زندگی کے چکر کی منصوبہ بندی ہے، سراغ پذیری شروع سے آخر تک برقرار ہے، انٹرفیسز رسمی طور پر کنٹرول ہیں، اور توثیق اور تصدیق الگ اور منصوبہ بند ہیں۔ پیچیدہ پروگراموں پر MBSE استعمال ہوتی ہے۔

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

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

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

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

اہم نکات

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

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

• INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
• ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
• ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
• Sanford Friedenthal, Alan Moore, and Rick Steiner, A Practical Guide to SysML: The Systems Modelling Language
• NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
• Andrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management
• Dennis M. Buede and William D. Miller, The Engineering Design of Systems: Models and Methods
• Donella H. Meadows, Thinking in Systems: A Primer
• Eberhardt Rechtin and Mark W. Maier, The Art of Systems Architecting
• U.S. Department of Defence, Defence Acquisition Guidebook (systems engineering guidance)