পাঠ ০৪ · ৫৮-এর মধ্যে · মডিউল ১
Home / Courses / Software Engineering Principles & Git / SDLC ওভারভিউ

SDLC ধারণা ওভারভিউ

The SDLC concept overview
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • SDLC কী এবং এর ছয়টি মানক ধাপ — রিকোয়ারমেন্ট থেকে মেইনটেন্যান্স পর্যন্ত
  • প্রতিটি ধাপ কোর্সের কোন পরবর্তী মডিউলে বিস্তারিতভাবে কভার হবে তার একটি ম্যাপ
  • কেন এটি একটি এককালীন লিনিয়ার সিকোয়েন্স নয়, বরং সত্যিকারের একটি পুনরাবৃত্ত "লাইফ সাইকেল"
  • Python দিয়ে একটি প্রজেক্টকে একটি সম্পূর্ণ সাইকেল এবং দ্বিতীয় সাইকেলের শুরু পর্যন্ত সিমুলেট করা

১ · SDLC-এর ছয়টি মানক ধাপ

SDLCSoftware Development Life Cycleএকটি সফটওয়্যার প্রজেক্ট প্রাথমিক আইডিয়া থেকে শুরু করে চূড়ান্ত অবসর পর্যন্ত যে সুনির্দিষ্ট ধাপগুলোর মধ্য দিয়ে যায়, তার একটি কাঠামোবদ্ধ ক্রম। হলো L01-এর ফ্লো-ডায়াগ্রামে যে ধারণাটি অস্পষ্টভাবে দেখানো হয়েছিল, তার একটি সুনির্দিষ্ট, নামকরণকৃত সংস্করণ। প্রতিটি সফটওয়্যার প্রজেক্ট, তা যত ছোট বা বড় হোক না কেন, মোটামুটি এই ছয়টি ধাপের মধ্য দিয়ে যায়:

১. রিকোয়ারমেন্ট অ্যানালিসিস
কী তৈরি করতে হবে তা বের করা — বিস্তারিতভাবে কভার হবে M3-এ।
২. ডিজাইন
কীভাবে তৈরি করা হবে — আর্কিটেকচার, ক্লাস স্ট্রাকচার — বিস্তারিতভাবে কভার হবে M4-M6-এ।
৩. ইমপ্লিমেন্টেশন
আসলে কোড লেখা — এখানেই M7-M9-এর Git দক্ষতা প্রয়োগ হয়।
৪. টেস্টিং
এটি সঠিকভাবে কাজ করে কিনা যাচাই করা — বিস্তারিতভাবে কভার হবে M10-এ।
৫. ডিপ্লয়মেন্ট
বাস্তব ব্যবহারকারীদের জন্য রিলিজ করা।
৬. মেইনটেন্যান্স
রিলিজের পরের ফিক্স/আপডেট — L02-এর "বেশিরভাগ খরচ এখানেই যায়" পরিসংখ্যানের সরাসরি সংযোগ।

২ · কেন "লাইফ সাইকেল" — "প্রসেস" নয়

একটি গুরুত্বপূর্ণ, প্রায়ই উপেক্ষিত সূক্ষ্মতা হলো নামকরণ নিজেই: এটিকে "সফটওয়্যার ডেভেলপমেন্ট প্রসেস" না বলে "লাইফ সাইকেল" বলা হয় ইচ্ছাকৃতভাবে। বাস্তব সফটওয়্যার এই ছয়টি ধাপের মধ্য দিয়ে একবারই যায় না — মেইনটেন্যান্স ধাপে নতুন বাগ ধরা পড়া, ব্যবহারকারীর নতুন চাহিদা, বা বাজারের পরিবর্তনের কারণে প্রায়ই নতুন রিকোয়ারমেন্ট তৈরি হয়, যা পুরো সাইকেলটিকে আবার প্রথম ধাপ থেকে শুরু করায়। এটিই সরাসরি M2-এর ইটারেটিভ ও অ্যাজাইল মডেলগুলোর (L06, L08) পূর্বাভাস — সেই মডেলগুলো এই পুনরাবৃত্তিকে সরাসরি গ্রহণ করে, বরং M2/L05-এর ওয়াটারফল মডেল যা করে না — এটিকে একটি এককালীন, লিনিয়ার সিকোয়েন্স হিসেবে ট্রিট করে, যা পরবর্তী পাঠের একটি গুরুত্বপূর্ণ বৈসাদৃশ্য তৈরি করবে।

১. রিকোয়ারমেন্ট ২. ডিজাইন ৩. ইমপ্লিমেন্টেশন ৪. টেস্টিং ৫. ডিপ্লয়মেন্ট ৬. মেইনটেন্যান্স নতুন রিকোয়ারমেন্ট ট্রিগার হলে
মেইনটেন্যান্স থেকে ডান পাশের লুপ-ব্যাক তীরটিই SDLC-কে একটি লিনিয়ার সিকোয়েন্স নয়, বরং একটি সত্যিকারের "সাইকেল" বানায় — M2-এর ইটারেটিভ ও অ্যাজাইল মডেলগুলো এই লুপকে কেন্দ্র করেই তৈরি।
SDLC মডেল বনাম SDLC ধাপ — একটি গুরুত্বপূর্ণ পার্থক্য

এই পাঠের ছয়টি ধাপ প্রতিটি SDLC মডেলই ভাগাভাগি করে — কিন্তু M2-এর প্রতিটি পাঠ (ওয়াটারফল, ইটারেটিভ, স্পাইরাল, অ্যাজাইল) এই একই ধাপগুলোকে ভিন্নভাবে সংগঠিত করে। ধাপগুলো নিজেই স্থির; মডেলগুলো ভিন্ন হয় সেগুলো কীভাবে সাজানো, পুনরাবৃত্ত করা, বা সময়মতো নির্ধারণ করা হয় তাতে।

Python
# একটি প্রজেক্ট SDLC-এর ছয়টি ধাপ পার হয়ে মেইনটেন্যান্সে পৌঁছানো, তারপর নতুন
# রিকোয়ারমেন্ট এসে দ্বিতীয় সাইকেল শুরু হওয়া -- এটিই "লাইফ সাইকেল" ধারণার প্রমাণ।

class SDLCProject:
    PHASES = ["Requirements", "Design", "Implementation", "Testing", "Deployment", "Maintenance"]

    def __init__(self):
        self.current_phase = self.PHASES[0]
        self.cycle_count = 1

    def advance_phase(self):
        idx = self.PHASES.index(self.current_phase)
        if idx >= len(self.PHASES) - 1:
            raise ValueError("ইতিমধ্যে সর্বশেষ ধাপে -- trigger_maintenance_cycle() ব্যবহার করুন")
        self.current_phase = self.PHASES[idx + 1]

    def trigger_maintenance_cycle(self):
        if self.current_phase != "Maintenance":
            raise ValueError("শুধু Maintenance ধাপ থেকেই নতুন সাইকেল শুরু করা যায়")
        self.cycle_count += 1
        self.current_phase = self.PHASES[0]

project = SDLCProject()
print(f"সাইকেল {project.cycle_count} শুরু -- বর্তমান ধাপ: {project.current_phase}")
for _ in range(5):
    project.advance_phase()
    print(f"  → {project.current_phase}")

project.trigger_maintenance_cycle()
print(f"\nমেইনটেন্যান্স থেকে নতুন রিকোয়ারমেন্ট এলো -- সাইকেল {project.cycle_count} শুরু -- বর্তমান ধাপ: {project.current_phase}")
project.advance_phase()
print(f"  → {project.current_phase}")

    
লক্ষ্য করুন প্রথম সাইকেলে ৫টি advance_phase() কল Requirements থেকে Maintenance পর্যন্ত নিয়ে যায় (৬টি ধাপ, ৫টি ট্রানজিশন)। তারপর trigger_maintenance_cycle() শুধুমাত্র Maintenance ধাপ থেকেই কাজ করে (নইলে ValueError রেইজ করত) — এবং cycle_count ১ থেকে ২-এ বেড়ে যায়, আর ধাপ আবার Requirements-এ ফিরে যায়। শেষ লাইনে আরেকটি advance_phase() দেখায় দ্বিতীয় সাইকেলও ঠিক প্রথম সাইকেলের মতোই স্বাভাবিকভাবে এগোতে থাকে — এটিই "সাইকেল," এককালীন সিকোয়েন্স নয়।
মূল কথা · Key takeaway

SDLC-এর ছয়টি ধাপ — রিকোয়ারমেন্ট, ডিজাইন, ইমপ্লিমেন্টেশন, টেস্টিং, ডিপ্লয়মেন্ট, মেইনটেন্যান্স — প্রতিটি SDLC মডেলের ভিত্তি। কিন্তু আসল অন্তর্দৃষ্টি হলো এটি একটি সাইকেল: মেইনটেন্যান্স প্রায়ই নতুন রিকোয়ারমেন্ট তৈরি করে পুরো প্রক্রিয়া আবার শুরু করে। M2-এর পরবর্তী পাঠগুলো দেখাবে বিভিন্ন মডেল এই একই ধাপ ও এই একই সাইকেলিক বাস্তবতাকে কীভাবে ভিন্নভাবে সামলায়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি প্রজেক্ট কি টেস্টিং ধাপ শেষ না করেই সরাসরি ডিপ্লয়মেন্টে যেতে পারে বলে আপনার মনে হয়? এর সম্ভাব্য পরিণতি কী?

কারিগরিভাবে সম্ভব, কিন্তু ঝুঁকিপূর্ণ — টেস্টিং ধাপের উদ্দেশ্যই হলো রিলিজের আগে বাগ ও ত্রুটি ধরা। এটি বাদ দিলে অসংশোধিত বাগ সরাসরি বাস্তব ব্যবহারকারীদের কাছে পৌঁছাতে পারে, যা L02-এর "রক্ষণাবেক্ষণ খরচ" আরও বাড়িয়ে দেয় — কারণ প্রোডাকশনে বাগ ফিক্স করা টেস্টিং ধাপে ধরা পড়া বাগ ফিক্স করার চেয়ে সাধারণত অনেক বেশি ব্যয়বহুল।

প্র ০২ মেইনটেন্যান্স ধাপ থেকে "নতুন রিকোয়ারমেন্ট" ঠিক কীভাবে তৈরি হতে পারে — কয়েকটি বাস্তব উদাহরণ ভাবুন।

কয়েকটি সম্ভাবনা: ব্যবহারকারীরা রিলিজের পর একটি নতুন ফিচারের অনুরোধ করেন যা আগে ভাবা হয়নি; একটি বাগ ফিক্স করতে গিয়ে দেখা যায় আসল ডিজাইনেই একটি ফাঁক ছিল, যা নতুন করে ডিজাইন রিকোয়ারমেন্ট তৈরি করে; বাজারে প্রতিযোগী একটি নতুন সুবিধা চালু করে যা মেলাতে নতুন রিকোয়ারমেন্ট দরকার হয়; অথবা একটি নিয়ন্ত্রক (regulatory) পরিবর্তন নতুন কমপ্লায়েন্স রিকোয়ারমেন্ট বাধ্যতামূলক করে।

প্র ০৩ উপরের কোড সেলে যদি trigger_maintenance_cycle() কে current_phase এখনও "Testing"-এ থাকা অবস্থায় কল করা হতো, তাহলে কী হতো এবং কেন?

একটি ValueError রেইজ হতো, কারণ ফাংশনটির শুরুতেই স্পষ্টভাবে চেক করা আছে if self.current_phase != "Maintenance" — অর্থাৎ নতুন সাইকেল শুধুমাত্র Maintenance ধাপ থেকেই শুরু করা যায়, অন্য কোনো ধাপ থেকে নয়। এটি ইচ্ছাকৃত একটি নিয়ন্ত্রণ — বাস্তবে নতুন রিকোয়ারমেন্ট সাইকেল তখনই যৌক্তিক যখন বর্তমান সিস্টেমটি ইতিমধ্যে ডিপ্লয় ও ব্যবহৃত হচ্ছে (অর্থাৎ Maintenance ধাপে পৌঁছেছে)।

অনুশীলন

  1. চিন্তা করুন: SDLC-এর ছয়টি ধাপের মধ্যে কোনটি আপনার কাছে সবচেয়ে কম গুরুত্বপূর্ণ মনে হয়, এবং সেটি বাদ দিলে বাস্তবে কী সমস্যা হতে পারে বলে আপনি মনে করেন?

    বাস্তবে প্রতিটি ধাপেরই একটি নির্দিষ্ট উদ্দেশ্য আছে যা বাদ দিলে সরাসরি পরিণতি হয় — রিকোয়ারমেন্ট বাদ দিলে ভুল জিনিস তৈরি হওয়ার ঝুঁকি (L10-এর "requirements gap"); ডিজাইন বাদ দিলে দুর্বল আর্কিটেকচার (L14-এর কাপলিং/কোহেশন সমস্যা); টেস্টিং বাদ দিলে অনির্ভরযোগ্য প্রোডাকশন কোড। এই অনুশীলনের লক্ষ্য প্রতিটি ধাপের প্রকৃত উদ্দেশ্য বোঝা, শুধু মুখস্থ তালিকা নয়।

  2. পরীক্ষা করুন: উপরের কোড সেলে project.trigger_maintenance_cycle()-এর ঠিক পরে (ধাপ Requirements-এ ফেরার পরপরই, advance_phase() কল করার আগে) আরেকটি project.trigger_maintenance_cycle() কল যোগ করে Run চেপে দেখুন কী হয়।

    একটি ValueError রেইজ হবে, কারণ ওই মুহূর্তে current_phase হলো "Requirements", "Maintenance" নয় — আর trigger_maintenance_cycle() শুধু Maintenance ধাপ থেকেই কাজ করার জন্য ডিজাইন করা। এটি দেখায় কোডটি সত্যিই নিয়মটি প্রয়োগ করে, শুধু কমেন্টে বলা কোনো নিয়ম নয়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
সফটওয়্যার কোয়ালিটি অ্যাট্রিবিউট