سسٹم ڈویلپمنٹ اور نئی ٹیکنالوجیز

واٹر فال ماڈل (ウォータフォールモデル) ایک ڈویلپمنٹ ماڈل ہے جو آبشار کی طرح مراحل کو اوپر (upstream) سے نیچے (downstream) کی طرف ترتیب وار طے کرتا ہے، اور ہر مرحلے کے حاصلات (成果物) کو حتمی شکل دینے کے بعد ہی آگے بڑھتا ہے۔ مختصر دہرائی جانے والی مدتوں میں بنانا ایجائل ڈویلپمنٹ ہے، پروٹوٹائپس کے ذریعے ضروریات کو حتمی شکل دینا پروٹوٹائپنگ ماڈل ہے، اور موجودہ سروسز کو یکجا کرنا میش اپ کی وضاحت ہے۔

پروٹوٹائپنگ ماڈل (プロトタイピングモデル) کا مقصد یہ ہے کہ جلد ایک پروٹوٹائپ (試作品) بنا کر صارفین کو آزمانے دیا جائے، اور ضروریات کے ابہام اور گاہک (発注者) و ڈویلپرز کے درمیان سمجھ کے فرق کو ابتدائی مرحلے میں ہی دور کیا جائے۔ کوڈ کی سطریں کم کرنا مقصد نہیں، اور اس سے نہ ٹیسٹ چھوڑے جا سکتے ہیں نہ دیکھ بھال ختم ہو سکتی ہے۔

ایجائل ڈویلپمنٹ (アジャイル開発) ایک طریقۂ کار ہے جو ہر مختصر دہرائی (反復) کے ساتھ چلنے والا سافٹ ویئر جمع کرتا جاتا ہے اور اس مفروضے پر لچک کے ساتھ ردعمل دیتا ہے کہ تفصیلات بدلیں گی؛ اسکرم (スクラム) اور XP اس کے نمائندہ طریقے ہیں۔ ایک ہی بار میں تیاری سے پہلے تمام ضروریات کو حتمی شکل دینا، مکمل دستاویزات کا انتظار کر کے کام شروع کرنا، اور صارفین کو صرف آخر میں شامل کرنا واٹر فال کے طریقے کے قریب ہیں اور ایجائل کی خصوصیات نہیں۔

اسپرنٹ (スプリント) وہ مختصر، مقررہ مدت ہے جو اسکرم میں ڈویلپمنٹ کی اکائی بنتی ہے؛ ہر مدت میں منصوبہ بندی کرنے، تیار کرنے، چلنے والا سافٹ ویئر بنانے اور جائزہ (振り返り) لینے کا چکر دہرایا جاتا ہے۔ یہ ضروریات کی تعریف کے مرحلے یا قبولیتی ٹیسٹ کی مدت کی اصطلاح نہیں، اور نہ ہی صرف بگز درست کرنے کے لیے مخصوص مدت ہے۔

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

انکریمنٹل ماڈل (インクリメンタルモデル) سسٹم کو فنکشنل اکائیوں میں تقسیم کر کے مرحلہ وار ڈویلپمنٹ اور ریلیز جمع کرتا جاتا ہے؛ دہرائی پر مبنی (iterative) ڈویلپمنٹ ماڈلز کی طرح اس کا فائدہ یہ ہے کہ کچھ فنکشنز جلد استعمال کیے جا سکتے ہیں۔ واٹر فال پورے سسٹم کو ایک ہی ترتیب وار دور میں تیار کرتا ہے، ساختی تجزیہ (構造化分析手法) DFD وغیرہ استعمال کرنے والا تجزیاتی طریقہ ہے، اور میش اپ موجودہ سروسز کا مجموعہ ہے؛ ان میں سے کوئی بھی موزوں نہیں۔

ڈویلپمنٹ بنیادی طور پر ضروریات کے تجزیے (要求分析) سے شروع ہوتی ہے، جو صارفین کی ضروریات کو منظم کرتا ہے، پھر صارفین کو نظر آنے والے حصوں کے بیرونی ڈیزائن (外部設計)، اندرونی عمل درآمد کے اندرونی ڈیزائن (内部設計)، پروگرامنگ اور ٹیسٹنگ کی طرف بڑھتی ہے۔ ایسی ترتیبیں جن میں ڈیزائن ضروریات کے تجزیے سے پہلے ہو، یا ٹیسٹنگ پروگرامنگ سے پہلے ہو، حاصلات کے باہمی انحصار کے پیشِ نظر قائم نہیں رہ سکتیں۔

بیرونی ڈیزائن (外部設計) صارفین اور بیرونی دنیا کو نظر آنے والے حصوں کا احاطہ کرتا ہے — اسکرین کی تفصیلات، رپورٹ (帳票) کی تفصیلات، اور دوسرے سسٹمز کے ساتھ انٹرفیس۔ اندرونی الگورتھم اور طبعی ذخیرہ کاری کی ترتیب طے کرنا اندرونی ڈیزائن اور پروگرام ڈیزائن کا حصہ ہے، اور انفرادی ماڈیولز کی تصدیق یونٹ ٹیسٹنگ کا کام ہے۔

یونٹ ٹیسٹنگ (単体テスト) ٹیسٹنگ کے عمل کا پہلا مرحلہ ہے، جس میں ہر ماڈیول کی الگ الگ جانچ کی جاتی ہے کہ وہ اپنے تفصیلی ڈیزائن کے مطابق کام کرتا ہے۔ ماڈیولز کو یکجا کر کے انٹرفیسز کی جانچ انٹیگریشن ٹیسٹنگ (統合テスト) ہے، گاہک کا قبولیت کا فیصلہ قبولیتی ٹیسٹنگ ہے، اور بھاری بوجھ میں کارکردگی کی جانچ لوڈ اور کارکردگی ٹیسٹنگ کی وضاحت ہے۔

ٹیسٹنگ سب سے چھوٹی اکائیوں سے اوپر کی طرف بنتی ہے: پہلے ہر ماڈیول کا یونٹ ٹیسٹ، پھر ماڈیولز کو یکجا کرنے والے انٹیگریشن ٹیسٹ، پھر پورے سسٹم کی جانچ کرنے والا سسٹم ٹیسٹ (システムテスト)، اور آخر میں گاہک اور صارفین کا قبولیتی ٹیسٹ (受け入れテスト)۔ پورے سسٹم کی جانچ یا قبولیت پہلے کرنے کا مطلب ہوگا کہ اجزاء کے نقائص ابھی موجود ہوتے ہوئے اعلیٰ سطح کے ٹیسٹ چلائے جائیں، جو غیر معقول ہے۔

قبولیتی ٹیسٹنگ (受け入れテスト) آخری مرحلے کا ٹیسٹ ہے جس میں گاہک اور صارفین فراہم کردہ سسٹم کا کاروباری نقطۂ نظر سے جائزہ لیتے ہیں اور فیصلہ کرتے ہیں کہ اسے قبول (検収) کریں یا نہیں۔ اندرونی منطق کی جانچ ڈویلپرز کی یونٹ ٹیسٹنگ (وائٹ باکس ٹیسٹنگ) ہے، چلائے بغیر جانچ اسٹیٹک ٹیسٹنگ ہے، اور ماڈیولز کے کنکشنز کی جانچ انٹیگریشن ٹیسٹنگ ہے؛ ان میں سے کوئی بھی قبولیتی ٹیسٹنگ کی وضاحت نہیں۔

بلیک باکس ٹیسٹنگ (ブラックボックステスト) پروگرام کے اندرونی حصے کو ایک "سیاہ ڈبہ" سمجھتی ہے اور صرف یہ جانچتی ہے کہ اندراج اور آؤٹ پٹ کا تعلق تفصیلات کے مطابق ہے یا نہیں۔ وائٹ باکس ٹیسٹنگ اندرونی شاخوں اور راستوں کا احاطہ کرنے پر توجہ دیتی ہے، اسٹیٹک ٹیسٹنگ پروگرام چلائے بغیر جائزوں کے ذریعے جانچ کرتی ہے، اور ریگریشن ٹیسٹنگ جانچتی ہے کہ اصلاحات نے کچھ اور خراب نہیں کیا۔

یہ جانچنا کہ سسٹم زیادہ بوجھ — بہت سی بیک وقت رسائیاں یا ڈیٹا کی بڑی مقدار — برداشت کر کے اپنی کارکردگی برقرار رکھتا ہے یا نہیں، لوڈ ٹیسٹنگ (負荷テスト) ہے، جو سسٹم ٹیسٹ کے مرحلے میں جوابی وقت وغیرہ کے کارکردگی ٹیسٹس (性能テスト) کے ساتھ کی جاتی ہے۔ یونٹ ٹیسٹنگ انفرادی ماڈیولز کی جانچ کرتی ہے، اسٹیٹک ٹیسٹنگ چلائے بغیر جانچ کرتی ہے، اور وائٹ باکس ٹیسٹنگ اندرونی ساخت پر مرکوز تکنیک ہے۔

ضروریات کی تعریف کی دستاویز (要件定義書) ضروریات کے تجزیے کے نتیجے کے طور پر ان فنکشنز، کارکردگی اور پابندیوں کو مرتب کرتی ہے جو سسٹم کو فراہم کرنی ہیں، اور گاہک اور ڈویلپر کے درمیان اس پر اتفاق ہوتا ہے، اور یہ بعد کے ڈیزائن، ٹیسٹنگ اور قبولیت کے لیے بنیادی معیار بنتی ہے۔ آپریشن مینوئل صارفین کے لیے طریقۂ استعمال کی دستاویز ہے، یونٹ ٹیسٹ رپورٹ ٹیسٹ کے نتائج کا ریکارڈ ہے، اور نیٹ ورک ڈایاگرام ایک ڈیزائن خاکہ ہے؛ ان میں سے کوئی بھی متفقہ بنیادی دستاویز نہیں۔

WBS ایک تکنیک ہے جو پروجیکٹ کے حاصلات (成果物) اور ان کے لیے درکار کام کو درجہ وار تقسیم کر کے ساخت دیتی ہے، جس سے کام چھوٹ جانے سے بچاؤ ہوتا ہے اور تخمینے اور ذمہ داری سونپنے کی اکائیاں واضح ہو جاتی ہیں۔ شیڈول کو افقی پٹیوں کی صورت میں دکھانا گینٹ چارٹ ہے، ارنڈ ویلیو مینجمنٹ EVM ہے، اور رسک کا جائزہ لینا رسک کے تجزیے کی وضاحت ہے۔

گینٹ چارٹ (ガントチャート) ہر کام کے منصوبہ بند آغاز اور اختتام کو افقی پٹیوں کی صورت میں دکھاتا ہے اور شیڈول اور پیش رفت کو نمایاں کرنے کے لیے وسیع پیمانے پر استعمال ہوتا ہے۔ ڈیٹا فلو ڈایاگرام ڈیٹا کے بہاؤ کو، E-R ڈایاگرام اینٹیٹیز کے درمیان تعلقات کو، اور یوز کیس ڈایاگرام سسٹم اور اس کے صارفین کے درمیان تعاملات کو دکھاتا ہے؛ ان میں سے کوئی بھی شیڈول کا چارٹ نہیں۔

2 راستے ہیں: A→B→D→F (3 + 5 + 4 + 2 = 14 دن) اور A→C→E→F (3 + 4 + 6 + 2 = 15 دن)۔ چونکہ F کو دونوں راستوں کے مکمل ہونے کا انتظار کرنا پڑتا ہے، اس لیے کم از کم مجموعی مدت لمبے راستے والی، یعنی 15 دن ہے۔ یہ سب سے لمبا راستہ A→C→E→F کریٹیکل پاتھ (クリティカルパス) ہے۔ 14 دن صرف A→B→D→F والے حصے کو دیکھنے کا نتیجہ ہے، اور 12 اور 13 دن کسی راستے کے مجموعے سے مطابقت نہیں رکھتے۔

3 راستے ہیں: A→B→D→F (2 + 4 + 3 + 1 = 10 دن)، A→C→D→F (2 + 6 + 3 + 1 = 12 دن)، اور A→C→E→F (2 + 6 + 4 + 1 = 13 دن)۔ سب سے لمبا، یعنی 13 دن والا A→C→E→F، کریٹیکل پاتھ (クリティカルパス) ہے۔ 10 اور 12 دن دوسرے راستوں کے مجموعے ہیں، اور 14 دن کسی سے مطابقت نہیں رکھتا۔ کریٹیکل پاتھ کے کاموں (A، C، E، F) میں کوئی بھی تاخیر پورے پروجیکٹ کو اتنی ہی تاخیر کا شکار کر دیتی ہے۔

فنکشن پوائنٹ طریقہ (ファンクションポイント法) فنکشنز — اندراجات، آؤٹ پٹس، استفسارات (照会)، اندرونی فائلیں وغیرہ — کی تعداد اور پیچیدگی کو اسکور دے کر سافٹ ویئر کے حجم کا تخمینہ لگاتا ہے، اور کوڈ کی سطروں پر انحصار کیے بغیر ڈویلپمنٹ کے ابتدائی مرحلے میں لاگو کیا جا سکتا ہے۔ LOC سطروں کی تعداد پر مبنی ایک مختلف پیمانہ ہے، ڈیلفی طریقہ ماہرین سے بار بار سروے کر کے آراء کو یکجا کرتا ہے، اور KJ طریقہ خیالات پیدا کرنے کی ایک تکنیک ہے جو معلومات کو کارڈز پر منظم کر کے گروہوں میں بانٹتی ہے۔

رسک مینجمنٹ اس ترتیب سے آگے بڑھتا ہے: رسک کی شناخت (リスク識別)، جو رسکس کو سامنے لاتی ہے؛ رسک کا تجزیہ (リスク分析) (کیفیتی اور مقداری)، جو امکان اور اثر کا جائزہ لیتا ہے؛ رسک کے ردعمل کی منصوبہ بندی (リスク対応計画)، جو جوابی اقدامات طے کرتی ہے؛ اور رسک کی نگرانی اور کنٹرول، جو عمل درآمد کے دوران صورتحال پر نظر رکھتا ہے۔ شناخت سے پہلے ردعمل کی منصوبہ بندی یا نگرانی کام نہیں کر سکتی، کیونکہ زیرِ بحث رسکس ابھی طے ہی نہیں ہوئے۔

تفصیلات میں تبدیلیاں تبدیلی کے کنٹرول (変更管理) کے عمل کے مطابق ہوتی ہیں: شیڈول، لاگت اور معیار پر اثر کا جائزہ لیا جاتا ہے، اور تبدیلی کنٹرول بورڈ (変更管理委員会، CCB) منظوری یا مستردگی کا فیصلہ کرتا ہے۔ غیر مشروط قبولیت تاخیر اور معیار میں گراوٹ کو دعوت دیتی ہے، جبکہ سب کچھ مسترد کرنے سے ضروری تبدیلیاں بھی ضائع ہو جاتی ہیں۔ انفرادی عملے کی موقع پر کی گئی اصلاحات کنفیگریشن اور دستاویزات سے عدم مطابقت پیدا کرتی ہیں اور کنٹرول ختم کر دیتی ہیں۔

اسٹیک ہولڈرز (ステークホルダ) ان افراد اور اداروں کا مجموعی نام ہے جن کا پروجیکٹ کے نتیجے میں مفاد ہو — گاہک، صارفین، ڈویلپرز، انتظامیہ وغیرہ — اور ان کی توقعات کو سمجھنا اور ان میں ہم آہنگی پیدا کرنا پروجیکٹ مینجمنٹ کی ایک اہم سرگرمی ہے۔ شیڈول کا چارٹ گینٹ چارٹ ہے، درجہ وار تقسیم WBS ہے، اور رسکس کی فہرست رسک رجسٹر (リスク登録簿) کے مطابق ہے۔

SLA کسی سروس کے فراہم کنندہ اور صارفین کے درمیان دستیابی کی شرح (稼働率)، خرابی سے بحالی کے وقت اور سپورٹ کے اوقات جیسی سروس کے معیار کی سطحوں پر ایک معاہدہ ہے، اور چلتی ہوئی سروس کی جانچ کا بنیادی معیار بنتا ہے۔ کاپی رائٹ کا تحفظ لائسنس معاہدہ ہے، کام کی تقسیم کا چارٹ WBS ہے، اور آلات کرائے پر لینا لیز ہے؛ ان میں سے کوئی بھی SLA نہیں۔

ITIL (Information Technology Infrastructure Library) دستاویزات کا ایک مجموعہ ہے جو IT سروسز کے آپریشن اور انتظام کی بہترین روایات (ベストプラクティス) کو منظم شکل دیتا ہے، اور انسیڈنٹ مینجمنٹ (障害管理)، تبدیلی کے انتظام (変更管理)، سروس ڈیسک وغیرہ کا احاطہ کرنے والے سروس مینجمنٹ کے فریم ورک کے طور پر وسیع پیمانے پر حوالہ دیا جاتا ہے۔ پروگرامنگ زبانوں کے معیارات، نارملائزیشن کا نظریہ اور وائرلیس LAN کے معیارات دوسرے شعبوں سے تعلق رکھتے ہیں۔

دستیابی کی شرح (稼働率) کا حساب MTBF ÷ (MTBF + MTTR) سے کیا جاتا ہے۔ 570 ÷ (570 + 30) = 570 ÷ 600 = 0.95۔ MTBF خرابیوں کے درمیان اوسط چلنے کا وقت (平均故障間隔) ہے، اور MTTR مرمت کا اوسط وقت (平均修理時間) ہے۔ 0.90 اور 0.98 شمار کنندہ اور نسب نما کو آپس میں بدل دینے پر بھی مطابقت نہیں رکھتے، اور 0.93 کسی حساب سے مطابقت نہیں رکھتا۔

کیپیسٹی مینجمنٹ (キャパシティ管理) مستقبل کے استعمال — ڈیٹا کی مقدار، رسائیوں کی تعداد — کی پیش گوئی کرتی ہے اور سرور، اسٹوریج اور نیٹ ورک کی گنجائش کو منصوبہ بندی کے ساتھ یقینی بناتی اور بڑھاتی ہے، تاکہ کارکردگی میں کمی اور گنجائش کی قلت کو پیش آنے سے پہلے ہی روکا جا سکے۔ خرابیوں کے لیے رابطے کا ڈھانچہ انسیڈنٹ اور ہنگامی انتظام سے، پاس ورڈ کا انتظام یوزر مینجمنٹ سے، اور لائسنسوں کی تعداد سافٹ ویئر اثاثوں کے انتظام سے تعلق رکھتی ہے۔

سرور ورچوئلائزیشن (サーバ仮想化) ایسی ٹیکنالوجی ہے جس میں ورچوئلائزیشن سافٹ ویئر 1 طبعی سرور پر متعدد ورچوئل مشینیں (仮想マシン) چلاتا ہے، جس سے سرورز کے یکجا ہونے کے ذریعے وسائل کا استعمال بہتر ہوتا ہے اور ترتیب میں تبدیلی اور بحالی میں لچک ملتی ہے۔ طبعی تقسیم اور چھوٹے ڈھانچے ہارڈ ویئر کے معاملات ہیں، اور کاغذ پر ذخیرہ کرنے کا ورچوئلائزیشن سے کوئی تعلق نہیں۔

SaaS (Software as a Service) ایپلیکیشن کو ہی نیٹ ورک کے ذریعے بطور سروس فراہم کرتا ہے، جس سے صارفین سافٹ ویئر انسٹال کیے بغیر کام کر سکتے ہیں۔ IaaS سرورز جیسا انفراسٹرکچر فراہم کرتا ہے، اور PaaS ایپلیکیشن کے چلنے کے ماحول (実行環境) تک سب کچھ فراہم کرتا ہے۔ آن پریمیسز (オンプレミス) کا مطلب ہے آلات کو اپنے ادارے کے اندر رکھنا اور چلانا، جو کلاؤڈ کی فراہمی کا ماڈل نہیں۔

Society 5.0 ایسے معاشرے کا تصور ہے جو IoT وغیرہ کے ذریعے حقیقی دنیا کا ڈیٹا سائبر اسپیس (サイバー空間) میں جمع کرتا ہے، اس کا تجزیہ کرتا ہے، اور نتائج حقیقی دنیا کو لوٹاتا ہے — سائبر اسپیس اور طبعی اسپیس (フィジカル空間) کا ایک اعلیٰ درجے کا امتزاج جو معاشی ترقی اور سماجی مسائل کے حل کو ایک ساتھ حاصل کرنا چاہتا ہے۔ حقیقت پر معلومات چڑھانا AR ہے، حساب کی تقسیم تقسیم شدہ پروسیسنگ ہے، اور پروجیکٹ مینجمنٹ کے علم کا مجموعہ PMBOK کی وضاحت ہے۔

زیرِ نگرانی سیکھنا (教師あり学習) ماڈل کو درست لیبلز والا ڈیٹا دیتا ہے اور اسے اندراج سے جواب کی پیش گوئی کرنے کی تربیت دیتا ہے؛ یہ تصاویر کی درجہ بندی اور عددی پیش گوئی کے لیے استعمال ہوتا ہے۔ جوابات دیے بغیر ڈیٹا میں ساخت یا گروہ تلاش کرنا بغیر نگرانی سیکھنا (教師なし学習) ہے۔ لوگوں کو تربیت دینا مشین لرننگ نہیں، اور بے ترتیب آؤٹ پٹس پیدا کرنے کا سیکھنے سے کوئی تعلق نہیں۔