Big design up front
বিগ ডিজাইন আপ ফ্রন্ট (বিডিইউএফ) হল একটি সফ্টওয়্যার ডেভেলপমেন্ট পদ্ধতি যেখানে প্রোগ্রামের নকশাটি সেই প্রোগ্রামের বাস্তবায়ন শুরু হওয়ার আগে সম্পূর্ণ এবং নিখুঁত করতে হয়। এটি প্রায়শই সফ্টওয়্যার বিকাশের জলপ্রপাত মডেলের সাথে যুক্ত থাকে। বিগ ডিজাইন আপ ফ্রন্ট (বিডিইউএফ)-এর প্রতিশব্দ হল বিগ মডেলিং আপ ফ্রন্ট (বিএমইউএফ) এবং বিগ প্রয়োজনীয়তা আপ ফ্রন্ট (বিআরইউএফ)। এগুলিকে চটপটে সফ্টওয়্যার বিকাশের মধ্যে অ্যান্টি-প্যাটার্ন হিসাবে দেখা হয়। জলপ্রপাত মডেলের প্রবক্তাদের জন্য যুক্তিগুলি যুক্তি দেয় যে নকশায় ব্যয় করা সময় একটি সার্থক বিনিয়োগ, এই আশা সহ যে একটি সফ্টওয়্যার পণ্যের জীবনচক্রের প্রাথমিক পর্যায়ে একটি বাগ ঠিক করার জন্য কম সময় এবং প্রচেষ্টা ব্যয় করা হবে যখন একই বাগ পাওয়া যায় এবং পরে অবশ্যই ঠিক করা উচিত। অর্থাৎ, বাস্তবায়নের পর্যায়ে একই বাগ ঠিক করার চেয়ে প্রয়োজনীয়তার পর্যায়ে একটি বাগ ঠিক করা অনেক সহজ, কারণ বাস্তবায়নের পর্যায়ে প্রয়োজনীয়তার বাগ ঠিক করার জন্য কমপক্ষে কিছু বাস্তবায়ন এবং নকশার কাজ স্ক্র্যাপ করা প্রয়োজন যা ইতিমধ্যে সম্পন্ন হয়েছে। সফ্টওয়্যার বিকাশের জনপ্রিয় অনলাইন ভাষ্যকার জোয়েল স্পলস্কি বড় ডিজাইনের পক্ষে দৃঢ়ভাবে যুক্তি দিয়েছেনঃ "অনেক সময়, জিনিসগুলি আগে থেকে চিন্তা করা আমাদের পরে গুরুতর বিকাশের মাথাব্যথা বাঁচিয়েছিল। ...........................................................। আমরা যদি কোডে এই পরিবর্তন করতাম, তবে এটি সময়সূচীতে সপ্তাহ যোগ করত। আমি আপনাকে বলতে পারি না যে আমি বিগ ডিজাইন আপ ফ্রন্টে কতটা দৃঢ়ভাবে বিশ্বাস করি, যা এক্সট্রিম প্রোগ্রামিংয়ের প্রবক্তারা অভিশাপ হিসাবে বিবেচনা করে। আমি ধারাবাহিকভাবে সময় সাশ্রয় করেছি এবং বিডিইউএফ ব্যবহার করে আরও ভাল পণ্য তৈরি করেছি এবং এক্সপি ধর্মান্ধরা যাই দাবি করুক না কেন, আমি এটি ব্যবহার করতে পেরে গর্বিত। তারা এই বিষয়ে ভুল এবং আমি এর চেয়ে পরিষ্কার কিছু হতে পারি না। " যাইহোক, বেশ কয়েকজন ভাষ্যকার যুক্তি দিয়েছেন যে জোয়েল যাকে সামনে বড় নকশা বলে অভিহিত করেছেন তা এক্সপি এবং অন্যান্য চটপটে সফ্টওয়্যার উন্নয়ন পদ্ধতির সমর্থকদের দ্বারা সমালোচিত বিডিইউএফ-এর সাথে সাদৃশ্যপূর্ণ নয় কারণ তিনি নিজেই বলেছেন যে তাঁর উদাহরণটি স্বীকৃতভাবে সম্পূর্ণ প্রোগ্রাম নকশা বা সম্পূর্ণরূপে সম্পূর্ণ ছিল নাঃ "এই নির্দিষ্টকরণটি কেবল আর্ডভার্ক 1-এর নকশার একটি সূচনা বিন্দু, চূড়ান্ত নীলনকশা নয়। আমরা যখন পণ্যটি তৈরি করতে শুরু করব, তখন আমরা এমন অনেক কিছু আবিষ্কার করব যা ঠিক পরিকল্পনা অনুযায়ী কাজ করবে না। আমরা নতুন বৈশিষ্ট্য উদ্ভাবন করব, আমরা জিনিসগুলি পরিবর্তন করব, আমরা শব্দের পরিমার্জন করব ইত্যাদি। জিনিসগুলি পরিবর্তিত হওয়ার সাথে সাথে আমরা বৈশিষ্ট্যটি আপ টু ডেট রাখার চেষ্টা করব। কোনওভাবেই এই বিশেষত্বকে কোনও ধরনের পবিত্র, ঢালাও আইন হিসাবে বিবেচনা করা উচিত নয়। " সমালোচকদের বিরুদ্ধে যুক্তিগুলি (বিশেষত যারা চটপটে সফ্টওয়্যার বিকাশ অনুশীলন করে) যুক্তি দেয় যে বিডিইউএফ পরিবর্তিত প্রয়োজনীয়তার সাথে খারাপভাবে খাপ খাইয়ে নেয় এবং বিডিইউএফ ধরে নেয় যে ডিজাইনাররা ব্যাপক প্রোটোটাইপিং এবং বাস্তবায়নে কমপক্ষে কিছু বিনিয়োগ ছাড়াই সমস্যার ক্ষেত্রগুলি পূর্বাভাস করতে সক্ষম। উল্লেখযোগ্য প্রকল্পগুলির জন্য, ব্যবহারকারীদের কাছ থেকে প্রয়োজনীয়তাগুলি প্রাথমিক বিতরণযোগ্যতার আলোকে পরিমার্জন করা প্রয়োজন, এবং ব্যবসার চাহিদাগুলি বড় প্রকল্পগুলি সম্পন্ন হওয়ার চেয়ে দ্রুত গতিতে বিকশিত হয়-সিস্টেমটি সম্পন্ন হওয়ার সময় বড় নকশাকে পুরানো করে তোলে। তারা আরও দাবি করে যে পরিকল্পনায় ব্যয় করা সময় এবং কোনও ত্রুটি ঠিক করার জন্য যে সময় আসলে ব্যয় হবে তার মধ্যে ভারসাম্য বজায় রাখার জন্য একটি ওভারহেড রয়েছে। একে কখনও কখনও বিশ্লেষণ পক্ষাঘাত বলা হয়। যদি পরিকল্পনার খরচ ঠিক করার খরচের চেয়ে বেশি হয় তবে পরিকল্পনায় ব্যয় করা সময় নষ্ট হয়। ক্রমাগত স্থাপন, স্বয়ংক্রিয় আপডেট এবং সম্পর্কিত ধারণাগুলি উৎপাদনে ত্রুটির ব্যয়কে যথেষ্ট পরিমাণে হ্রাস করার চেষ্টা করে যাতে তারা শুরুতে পরিকল্পনা করার চেয়ে রান-টাইমে ঠিক করা সস্তা হয়ে যায়। বাস্তবে, রান-টাইম ফিক্সগুলি ডিজাইন ফিক্সগুলির তুলনায় অনেক বেশি ব্যয়বহুল, তাই উন্নয়ন চক্রের সময় সমস্যাগুলি সমাধানের জন্য বিকাশের সময় ঘন ঘন প্রদর্শন এবং ব্যবহারকারীর প্রতিক্রিয়ার মতো চটপটে পদ্ধতিগুলি ব্যবহার করা গুরুত্বপূর্ণ। ব্যবহারকারীর প্রতিক্রিয়ার সুবিধার সাথে সফ্টওয়্যারের উন্নতি করা সাধারণত বিডিইউএফ দিয়ে একটি সিস্টেমের প্রতিটি দিক অনুমান এবং নথিভুক্ত করার চেষ্টা করার চেয়ে কম ব্যয়বহুল। এছাড়াও, বেশিরভাগ প্রকল্পে ব্যাপক লিখিত (এমনকি সুপরিচিত) প্রয়োজনীয়তার উল্লেখযোগ্য অভাব রয়েছে। সুতরাং বিডিইউএফ-এ অনেকগুলি অনুমান করা হয় যা পরে মিথ্যা প্রমাণিত হয় তবে ডিজাইন করা হয় এবং সম্ভবত ইতিমধ্যে কোড করা হয়। বিকল্প একটি বিকল্প পদ্ধতি হল রাফ ডিজাইন আপ ফ্রন্ট (আরডিইউএফ) যেখানে প্রকল্পের অগ্রগতির সাথে সাথে নকশার বিশদে তৈরি করার জন্য একটি কাঠামো সরবরাহ করার জন্য 'পর্যাপ্ত' নকশা সম্পন্ন করা হয়। জোশুয়া কেরিভস্কি একটি অনুরূপ পদ্ধতিকে পর্যাপ্ত নকশা বলে অভিহিত করেছেনঃ "আমি বলতে চাইছি যে আমাদের পণ্যগুলির জন্য উচ্চ নকশার গুণমান এবং সমালোচনামূলক নয় এমন জিনিসগুলির জন্য কম নকশার গুণমান প্রয়োজন।" স্ক্রামের প্রবক্তারা উদীয়মান নকশার ধারণাটি উল্লেখ করেছেনঃ "একটি স্ক্রাম প্রকল্পের পার্থক্য এই নয় যে ইচ্ছাকৃত নকশাটি ফেলে দেওয়া হয়, বরং এটি ক্রমবর্ধমানভাবে (স্ক্রাম প্রকল্পের অন্যান্য সমস্ত কিছুর মতো) করা হয়।" আরও দেখুন সফ্টওয়্যার উন্নয়ন দর্শনের তালিকা রেফারেন্স সফ্টওয়্যার উন্নয়ন প্রক্রিয়া