ইটারেটিভ ও ইনক্রিমেন্টাল মডেল
এই পাঠে যা শিখবেন
- ইটারেটিভ মডেল কী এবং এটি কীভাবে পুরো সিস্টেমকে ধাপে ধাপে পরিমার্জিত করে
- ইনক্রিমেন্টাল মডেল কী এবং এটি কীভাবে ব্যবহারযোগ্য অংশ ধাপে ধাপে ডেলিভার করে
- দুটোর মধ্যে সুনির্দিষ্ট পার্থক্য, এবং কেন বাস্তব মেথডোলজি প্রায়ই দুটোকে একসাথে ব্যবহার করে
- Python দিয়ে ক্রমবর্ধমান, ইতিমধ্যে-ব্যবহারযোগ্য ফিচার সেট সিমুলেট করা
১ · ইটারেটিভ মডেল — পুরো জিনিসটাকে বারবার পরিমার্জন
ইটারেটিভ মডেলIterative ModelL04-এর সম্পূর্ণ SDLC সাইকেল বারবার পুনরাবৃত্তি করে, প্রতিটি পুনরাবৃত্তি (iteration) আগেরটির প্রতিক্রিয়ার ভিত্তিতে সামগ্রিক সিস্টেমকে পরিমার্জিত করে। হলো L05-এর ওয়াটারফলের কঠোরতার একটি সরাসরি জবাব। ওয়াটারফলে পুরো সাইকেল একবারই চলে; ইটারেটিভ মডেলে একই L04-এর সাইকেল বারবার চালানো হয় — প্রথম পুনরাবৃত্তি একটি মোটামুটি, অসম্পূর্ণ সংস্করণ তৈরি করে, পরের পুনরাবৃত্তিগুলো আগেরটির উপর ভিত্তি করে ধীরে ধীরে সেটিকে পরিমার্জিত ও উন্নত করে।
২ · ইনক্রিমেন্টাল মডেল — ব্যবহারযোগ্য অংশ ধাপে ধাপে
ইনক্রিমেন্টাল মডেলIncremental Modelসিস্টেমটি আলাদা আলাদা, ব্যবহারযোগ্য অংশে (increment) তৈরি ও ডেলিভার করা হয়, প্রতিটি increment ইতিমধ্যে ডেলিভার হওয়া অংশের সাথে নতুন, কার্যকরী ফাংশনালিটি যোগ করে। এর জোর ইটারেটিভ থেকে সুনির্দিষ্টভাবে ভিন্ন জায়গায়: ইনক্রিমেন্টাল মানে ধীরে ধীরে কার্যকরী স্লাইস ডেলিভার করা (প্রতিটি নতুন ফিচার আগেরগুলোর উপর যোগ হয়, এবং প্রতিটি ধাপেই সিস্টেম ব্যবহারযোগ্য থাকে); ইটারেটিভ মানে ধীরে ধীরে পুরো জিনিসটাকে পরিমার্জিত করা। বাস্তবে অনেক মেথডোলজি (সরাসরি পূর্বাভাস M2/L08-এর অ্যাজাইলের) দুটো ধারণাকেই একসাথে মেশায় — প্রতিটি পুনরাবৃত্তি একটি ব্যবহারযোগ্য increment-ও ডেলিভার করে।
L05-এ আমরা দেখেছিলাম ওয়াটারফলের একটি গুরুতর দুর্বলতা: কার্যকরী সফটওয়্যার দেখা যায় প্রজেক্টের অনেক দেরিতে। ইটারেটিভ ও ইনক্রিমেন্টাল — দুটো মডেলই এর সরাসরি জবাব দেয়: কার্যকরী সফটওয়্যার (হোক তা অসম্পূর্ণ বা রুক্ষ) অনেক আগেই অস্তিত্বে আসে। ফলে কোনো মৌলিক ভুল বোঝাবুঝি থাকলে তা তাড়াতাড়ি ধরা পড়ে, যখন তা ঠিক করা এখনও সস্তা — বরং টেস্টিং ধাপে গিয়ে ধরা পড়ার (ওয়াটারফলের মতো) চেয়ে অনেক ভালো।
# IncrementalProject -- প্রতিটি increment বিদ্যমান, ইতিমধ্যে-ব্যবহারযোগ্য ফিচার সেটের
# উপর নতুন কার্যকরী ফিচার যোগ করে -- ওয়াটারফলের একবারে-সব-শেষে-ডেলিভারির বিপরীতে।
class IncrementalProject:
def __init__(self):
self.delivered_features = []
def deliver_increment(self, feature_name):
self.delivered_features.append(feature_name)
print(f"ইনক্রিমেন্ট ডেলিভার হলো: '{feature_name}'")
print(f" → এখন ব্যবহারযোগ্য মোট ফিচার: {self.delivered_features}")
project = IncrementalProject()
for feature in ["ইউজার লগইন", "প্রোডাক্ট লিস্টিং", "শপিং কার্ট"]:
project.deliver_increment(feature)
print()
print(f"চূড়ান্ত ব্যবহারযোগ্য ফিচার সেট ({len(project.delivered_features)}টি): {project.delivered_features}")
print("তুলনা করুন: ওয়াটারফলে এই তিনটি ফিচারের একটিও ব্যবহারযোগ্য হতো না,")
print("যতক্ষণ না পুরো প্রজেক্ট একসাথে, একেবারে শেষে ডেলিভার হতো।")
deliver_increment() কলের পর delivered_features তালিকাটি
ক্রমবর্ধমানভাবে বড় হচ্ছে, কখনো খালি বা রিসেট হচ্ছে না — প্রথম কলের পর ১টি ফিচার ব্যবহারযোগ্য,
দ্বিতীয় কলের পর ২টি, তৃতীয় কলের পর ৩টি। প্রতিটি ধাপেই যা ইতিমধ্যে ডেলিভার হয়েছে তা সম্পূর্ণ ব্যবহারযোগ্য থাকে
— নতুন increment শুধু তার উপর যোগ হয়, আগেরটাকে ভেঙে দেয় না।
ইটারেটিভ মডেল পুরো সিস্টেমকে ধাপে ধাপে পরিমার্জিত করে; ইনক্রিমেন্টাল মডেল ব্যবহারযোগ্য অংশ ধাপে ধাপে যোগ করে — দুটোই ওয়াটারফলের "কার্যকরী সফটওয়্যার দেরিতে দেখা যাওয়া" সমস্যার সরাসরি জবাব, এবং দুটোই M2-এর পরবর্তী পাঠগুলোর (স্পাইরাল, অ্যাজাইল) ভিত্তি তৈরি করে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি প্রজেক্টে যদি প্রতিটি পুনরাবৃত্তিতে পুরো সিস্টেম পরিমার্জিত হয়, কিন্তু কোনো নতুন ব্যবহারযোগ্য ফিচার যোগ না হয় — এটি কি ইটারেটিভ, ইনক্রিমেন্টাল, নাকি দুটোই?
এটি বিশুদ্ধ ইটারেটিভ, ইনক্রিমেন্টাল নয়। যেমন একটি প্রোটোটাইপের UI বারবার পরিমার্জিত হচ্ছে কিন্তু কোনো নতুন ফিচার যোগ হচ্ছে না — পুরো জিনিসটাই পরিবর্তিত হচ্ছে, ইনক্রিমেন্টাল মডেলের সংজ্ঞা অনুযায়ী নতুন, স্বতন্ত্র ব্যবহারযোগ্য অংশ যোগ হচ্ছে না।
প্র ০২ কেন অনেক বাস্তব মেথডোলজি ইটারেটিভ ও ইনক্রিমেন্টাল দুটো ধারণাকেই একসাথে ব্যবহার করে, শুধু একটি ব্যবহার করে না?
কারণ দুটোই আলাদা সুবিধা দেয় — ইনক্রিমেন্টাল নিশ্চিত করে যে প্রতিটি ধাপে নতুন, বাস্তব ব্যবহারযোগ্য মূল্য ডেলিভার হচ্ছে; ইটারেটিভ নিশ্চিত করে যে আগের প্রতিক্রিয়ার ভিত্তিতে বিদ্যমান কাজ পরিমার্জিত হতে পারে, শুধু স্থির থেকে যায় না। একসাথে ব্যবহার করলে প্রতিটি পুনরাবৃত্তি একটি নতুন, ব্যবহারযোগ্য increment ডেলিভার করে এবং প্রয়োজনে আগেরটাকেও পরিমার্জিত করে — যা M2/L08-এর অ্যাজাইল ঠিক এভাবেই করে।
প্র ০৩
উপরের কোড সেলে যদি তিনটি ফিচার একসাথে ["ইউজার লগইন", "প্রোডাক্ট লিস্টিং", "শপিং কার্ট"] একবারেই delivered_features-এ অ্যাসাইন করা হতো, তাহলে সেটি কি ইনক্রিমেন্টাল ডেলিভারি হতো?
না। ইনক্রিমেন্টাল ডেলিভারির মূল বৈশিষ্ট্য হলো প্রতিটি অংশ আলাদা আলাদা সময়ে, ধাপে ধাপে ব্যবহারযোগ্য হওয়া — একসাথে সবকিছু একবারে অ্যাসাইন করে দেওয়া মানে আসলে ওয়াটারফলের মতোই একটি একক, চূড়ান্ত ডেলিভারি, শুধু কোডের গঠন ভিন্ন। প্রকৃত ইনক্রিমেন্টাল ডেলিভারির জন্য প্রতিটি increment তার নিজস্ব পৃথক সময়ে বাস্তব ব্যবহারকারীদের কাছে পৌঁছানো জরুরি।
অনুশীলন
-
চিন্তা করুন: একটি ই-কমার্স অ্যাপ তৈরি করতে হলে, আপনি কীভাবে সেটিকে ৩-৪টি ইনক্রিমেন্টে ভাগ করবেন যাতে প্রতিটি increment-ই বাস্তবে ব্যবহারযোগ্য হয়?
একটি যুক্তিসঙ্গত ক্রম হতে পারে: (১) প্রোডাক্ট ব্রাউজিং ও সার্চ (ব্যবহারকারী প্রোডাক্ট দেখতে পারে), (২) ইউজার অ্যাকাউন্ট ও লগইন (ব্যবহারকারী ব্যক্তিগতকৃত অভিজ্ঞতা পায়), (৩) শপিং কার্ট ও চেকআউট (ব্যবহারকারী আসলে কিনতে পারে), (৪) অর্ডার হিস্ট্রি ও ট্র্যাকিং। প্রতিটি ধাপের পরই অ্যাপটি বাস্তবে কিছু-না-কিছু কাজে ব্যবহারযোগ্য থাকে — এটিই মূল মানদণ্ড।
-
পরীক্ষা করুন: উপরের কোড সেলে
for feature in [...]লুপে একটি চতুর্থ ফিচার (যেমন"অর্ডার হিস্ট্রি") যোগ করে Run চেপে দেখুন চূড়ান্ত প্রিন্ট হওয়া তালিকা ও ফিচার সংখ্যা কীভাবে বদলায়।delivered_features-এ এখন ৪টি এন্ট্রি থাকবে, এবং চূড়ান্ত প্রিন্ট লাইনেlen(project.delivered_features)৩-এর বদলে ৪ দেখাবে, আর তালিকায়"অর্ডার হিস্ট্রি"ও যুক্ত থাকবে — কারণdeliver_increment()প্রতিবার শুধু তালিকায়appendকরে, আগের কিছু মুছে ফেলে না।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৮টি পাঠ পরবর্তী পাঠ — স্পাইরাল মডেল — ইটারেটিভ পুনরাবৃত্তির সাথে একটি স্পষ্ট রিস্ক-অ্যানালাইসিস ধাপ যোগ করবে।
- পাঠ ০৫ · ওয়াটারফল মডেল আগের পাঠ যে কঠোর, একমুখী মডেলের দুর্বলতার সরাসরি জবাব এই পাঠের ইটারেটিভ ও ইনক্রিমেন্টাল মডেল দেয়।