Big design up front
بگ ڈیزائن اپ فرنٹ (بی ڈی یو ایف) ایک سافٹ ویئر ڈویلپمنٹ اپروچ ہے جس میں پروگرام کے ڈیزائن کو اس پروگرام کے نفاذ سے پہلے مکمل اور مکمل کیا جانا ہے۔ یہ اکثر سافٹ ویئر ڈویلپمنٹ کے آبشار ماڈل سے وابستہ ہوتا ہے۔ بگ ڈیزائن اپ فرنٹ (بی ڈی یو ایف) کے مترادف بگ ماڈلنگ اپ فرنٹ (بی ایم یو ایف) اور بگ ریکوریٹیز اپ فرنٹ (بی آر یو ایف) ہیں۔ ان کو فرتیلی سافٹ ویئر ڈویلپمنٹ کے اندر اینٹی پیٹرن کے طور پر دیکھا جاتا ہے۔ واٹر فال ماڈل کے حامیوں کے لیے دلائل کا کہنا ہے کہ ڈیزائننگ میں گزارا گیا وقت ایک قابل قدر سرمایہ کاری ہے، اس امید کے ساتھ کہ سافٹ ویئر پروڈکٹ کے لائف سائیکل کے ابتدائی مراحل میں کسی بگ کو ٹھیک کرنے میں اس وقت کے مقابلے میں کم وقت اور کوشش خرچ کی جائے گی جب وہی بگ مل جائے گی اور اسے بعد میں ٹھیک کرنا ہوگا۔ یعنی، عمل درآمد کے مرحلے میں اسی بگ کو ٹھیک کرنے کے مقابلے میں ضروریات کے مرحلے میں کسی بگ کو ٹھیک کرنا بہت آسان ہے، کیونکہ عمل درآمد کے مرحلے میں ضروریات کے بگ کو ٹھیک کرنے کے لیے کم از کم کچھ عمل درآمد اور ڈیزائن کے کام کو ختم کرنے کی ضرورت ہوتی ہے جو پہلے ہی مکمل ہو چکے ہیں۔ سافٹ ویئر ڈویلپمنٹ پر ایک مشہور آن لائن مبصر، جوئل اسپولسکی نے بڑے ڈیزائن کے حق میں سختی سے دلیل دی ہے: "کئی بار، چیزوں کو پہلے سے سوچنے سے ہمیں بعد میں ترقی کے سنگین سر درد سے بچایا گیا۔ . [ایک مخصوص تفصیلات میں تبدیلی کرنے پر]۔ تفصیلات میں اس تبدیلی کو کرنے میں ایک یا دو گھنٹے لگے۔ اگر ہم نے کوڈ میں یہ تبدیلی کی ہوتی تو اس نے شیڈول میں ہفتوں کا اضافہ کر دیا ہوتا۔ میں آپ کو یہ نہیں بتا سکتا کہ میں بگ ڈیزائن اپ فرنٹ پر کتنا پختہ یقین رکھتا ہوں، جسے ایکسٹریم پروگرامنگ کے حامی ناگوار سمجھتے ہیں۔ میں نے مسلسل وقت بچایا ہے اور بی ڈی یو ایف کا استعمال کرتے ہوئے بہتر مصنوعات بنائی ہیں اور مجھے اسے استعمال کرنے پر فخر ہے، چاہے ایکس پی کے جنونیوں کا دعوی کچھ بھی ہو۔ وہ اس نکتے پر بالکل غلط ہیں اور میں اس سے زیادہ واضح نہیں ہو سکتا۔ " تاہم، کئی مبصرین نے استدلال کیا ہے کہ جوئل نے جسے بگ ڈیزائن اپ فرنٹ کہا ہے وہ بی ڈی یو ایف سے مشابہت نہیں رکھتا ہے جس پر ایکس پی اور دیگر فرتیلی سافٹ ویئر ڈویلپمنٹ کے طریقوں کے حامیوں نے تنقید کی تھی کیونکہ وہ خود کہتے ہیں کہ ان کی مثال نہ تو تسلیم شدہ طور پر مکمل پروگرام ڈیزائن تھی اور نہ ہی مکمل طور پر مکمل تھی: "یہ وضاحت محض آرڈورک 1 کے ڈیزائن کا ایک نقطہ آغاز ہے، نہ کہ حتمی خاکہ۔ جیسے ہی ہم پروڈکٹ بنانا شروع کریں گے، ہم بہت سی ایسی چیزیں دریافت کریں گے جو بالکل منصوبہ بندی کے مطابق کام نہیں کریں گی۔ ہم نئی خصوصیات ایجاد کریں گے، ہم چیزیں تبدیل کریں گے، ہم الفاظ کو بہتر بنائیں گے، وغیرہ۔ جیسے جیسے چیزیں بدلتی جائیں گی ہم قیاس آرائیوں کو تازہ ترین رکھنے کی کوشش کریں گے۔ کسی بھی طرح سے آپ کو اس قیاس کو کسی قسم کا مقدس، کاسٹ ان اسٹون قانون نہیں سمجھنا چاہیے۔ " ناقدین کے خلاف دلائل (خاص طور پر وہ لوگ جو فرتیلی سافٹ ویئر ڈویلپمنٹ پر عمل کرتے ہیں) کا کہنا ہے کہ بی ڈی یو ایف بدلتی ہوئی ضروریات کے لیے ناقص طور پر موافقت پذیر ہے اور یہ کہ بی ڈی یو ایف یہ فرض کرتا ہے کہ ڈیزائنرز وسیع تر پروٹو ٹائپنگ اور نفاذ میں کم از کم کچھ سرمایہ کاری کے بغیر مسئلہ کے علاقوں کی پیش گوئی کرنے کے قابل ہیں۔ کافی منصوبوں کے لیے، صارفین کی ضروریات کو ابتدائی ڈیلیوری ایبلز کی روشنی میں بہتر بنانے کی ضرورت ہوتی ہے، اور کاروبار کی ضروریات بڑے منصوبوں کے مکمل ہونے کے مقابلے میں تیزی سے تیار ہوتی ہیں-جس سے نظام مکمل ہونے تک بگ ڈیزائن پرانا ہو جاتا ہے۔ وہ اس بات پر بھی زور دیتے ہیں کہ منصوبہ بندی میں گزارے گئے وقت اور اس وقت کے درمیان توازن برقرار رکھنے کے لیے ایک اوور ہیڈ ہے جس میں کسی عیب کو ٹھیک کرنے میں اصل میں لاگت آئے گی۔ اسے بعض اوقات تجزیہ فالج کہا جاتا ہے۔ اگر منصوبہ بندی کی لاگت فکسنگ کی لاگت سے زیادہ ہے تو منصوبہ بندی میں خرچ ہونے والا وقت ضائع ہو جاتا ہے۔ مسلسل تعیناتی، خودکار اپ ڈیٹس، اور متعلقہ خیالات پیداوار میں نقائص کی لاگت کو کافی حد تک کم کرنے کی کوشش کرتے ہیں تاکہ وہ شروع میں منصوبہ بندی کرنے کے مقابلے رن ٹائم پر ٹھیک کرنے کے لیے سستے ہو جائیں۔ حقیقت میں، رن ٹائم فکسز ڈیزائن فکسز کے مقابلے میں بہت زیادہ مہنگے ہوتے ہیں، لہذا ترقیاتی چکر کے دوران مسائل کو حل کرنے کے لیے ترقی کے دوران بار بار مظاہرے اور صارف کے تاثرات جیسے فرتیلی طریقوں کا استعمال کرنا بہت ضروری ہے۔ صارف کے فیڈ بیک کے فائدے کے ساتھ سافٹ ویئر کو بہتر بنانا عام طور پر بی ڈی یو ایف کے ساتھ سسٹم کے ہر پہلو کی توقع اور دستاویز کرنے کی کوشش سے کم مہنگا ہوتا ہے۔ اس کے علاوہ، زیادہ تر منصوبوں میں جامع تحریری (یا یہاں تک کہ معروف) ضروریات کی نمایاں کمی ہے۔ لہذا بی ڈی یو ایف میں بہت سارے مفروضے بنائے جاتے ہیں جو بعد میں غلط ثابت ہوتے ہیں لیکن ڈیزائن کیے گئے ہوتے ہیں اور ممکنہ طور پر پہلے ہی کوڈ کیے گئے ہوتے ہیں۔ متبادل ایک متبادل نقطہ نظر رف ڈیزائن اپ فرنٹ (آر ڈی یو ایف) ہے جس میں 'کافی' ڈیزائن کو سامنے سے مکمل کیا جاتا ہے تاکہ ایک فریم ورک فراہم کیا جا سکے جس پر پروجیکٹ کی ترقی کے ساتھ ساتھ ڈیزائن کی تفصیل میں تعمیر کی جائے۔ اسی طرح کے نقطہ نظر کو جوشوا کیریوسکی نے کافی ڈیزائن کہا ہے: "میں یہ کہہ رہا ہوں کہ ہمیں ان چیزوں کے لیے اعلی ڈیزائن کے معیار کی ضرورت ہے جو ہماری مصنوعات کے لیے اہم ہیں اور ان چیزوں کے لیے کم ڈیزائن کے معیار کی ضرورت ہے جو اہم نہیں ہیں۔" اسکرم کے وکلاء ابھرتے ہوئے ڈیزائن کے تصور کا حوالہ دیتے ہیں: "اسکرم پروجیکٹ پر فرق یہ نہیں ہے کہ جان بوجھ کر ڈیزائن کو باہر پھینک دیا جاتا ہے، بلکہ یہ کہ یہ (اسکرم پروجیکٹ پر موجود ہر چیز کی طرح) بڑھتا ہوا کیا جاتا ہے۔" سافٹ ویئر ڈویلپمنٹ فلسفوں کی فہرست بھی دیکھیں حوالہ جات سافٹ ویئر ڈویلپمنٹ کا عمل