What is SDLC ? Complete Software Development Life Cycle Guide in bengali
A
Ankan Das
April 8, 2026
SDLC explained simply: 7 phases from Requirements to Maintenance. Learn models + real Food App example. Essential for developers & QA beginners! learn from ankandas.me blog
সফটওয়্যার ডেভেলপমেন্ট শুণ্য থেকে শুরু হয় না। একটি আইডিয়া মাথায় আসার পর সেটাকে বাস্তবে রূপ দিতে হলে অনেকগুলো ধাপ পেরোতে হয়। এই ধাপগুলোর সমষ্টিকেই আমরা বলি Software Development Life Cycle বা সংক্ষেপে SDLC।আমি যখন প্রথমবার একটি রিয়েল প্রোজেক্টে কাজ করতে গিয়েছিলাম, তখন বুঝতে পারিনি কেন আমাদের টিম লিড এতো সময় ধরে মিটিং করছেন, কেন ডকুমেন্টেশন লিখতে হচ্ছে, কেন কোড লেখার আগে এতো আলোচনা। পরে বুঝলাম এই প্রক্রিয়াগুলো ছাড়া বড় কোনো সফটওয়্যার টিকে থাকতে পারে না। আজ আমি আমার অভিজ্ঞতা থেকে SDLC-এর প্রতিটি ধাপ ধরে ধরে ব্যাখ্যা করছি।
সফটওয়্যার ডেভেলপমেন্ট শুণ্য থেকে শুরু হয় না। একটি আইডিয়া মাথায় আসার পর সেটাকে বাস্তবে রূপ দিতে হলে অনেকগুলো ধাপ পেরোতে হয়। এই ধাপগুলোর সমষ্টিকেই আমরা বলি Software Development Life Cycle বা সংক্ষেপে SDLC।
আমি যখন প্রথমবার একটি রিয়েল প্রোজেক্টে কাজ করতে গিয়েছিলাম, তখন বুঝতে পারিনি কেন আমাদের টিম লিড এতো সময় ধরে মিটিং করছেন, কেন ডকুমেন্টেশন লিখতে হচ্ছে, কেন কোড লেখার আগে এতো আলোচনা। পরে বুঝলাম এই প্রক্রিয়াগুলো ছাড়া বড় কোনো সফটওয়্যার টিকে থাকতে পারে না। আজ আমি আমার অভিজ্ঞতা থেকে SDLC-এর প্রতিটি ধাপ ধরে ধরে ব্যাখ্যা করছি।
SDLC কেন এতো গুরুত্বপূর্ণ?
আমার প্রথম প্রোজেক্টে আমরা SDLC মেনে চলিনি। ফলাফল? মিডল অফ দ্য প্রোজেক্টে আমরা বুঝতে পারলাম ক্লায়েন্ট আসলে চাইছিলেন অন্য কিছু। পুরো দুই মাসের কাজ বৃথা গেল। এরপর থেকে আমি বুঝি SDLC শুধু একটি মেথডোলজি নয়, এটি একটি বাঁচার কৌশল।SDLC ব্যবহার করলে যে সুবিধাগুলো পাওয়া যায়:প্রথমত, কাজগুলো সুসংগঠিত হয়। প্রত্যেকটা সদস্য জানে কখন কী করতে হবে। দ্বিতীয়ত, ভুল কম হয়। যখন প্রতিটি ধাপে রিভিউ থাকে, তখন ভুল ধরা পড়ে আগেভাগেই। তৃতীয়ত, সময় ও খরচ নিয়ন্ত্রণে থাকে। বাজেট ওভাররানের ঝুঁকি কমে। চতুর্থত, টিমের মধ্যে সমন্বয় ভালো হয়। সবাই একই পেজে থাকে। সবশেষে, প্রোডাক্টের কোয়ালিটি নিশ্চিত হয়। ব্যবহারকারীরা একটি পরিপূর্ণ, বাগমুক্ত সফটওয়্যার পায়।
আমার প্রথম প্রোজেক্টে আমরা SDLC মেনে চলিনি। ফলাফল? মিডল অফ দ্য প্রোজেক্টে আমরা বুঝতে পারলাম ক্লায়েন্ট আসলে চাইছিলেন অন্য কিছু। পুরো দুই মাসের কাজ বৃথা গেল। এরপর থেকে আমি বুঝি SDLC শুধু একটি মেথডোলজি নয়, এটি একটি বাঁচার কৌশল।
SDLC ব্যবহার করলে যে সুবিধাগুলো পাওয়া যায়:
প্রথমত, কাজগুলো সুসংগঠিত হয়। প্রত্যেকটা সদস্য জানে কখন কী করতে হবে। দ্বিতীয়ত, ভুল কম হয়। যখন প্রতিটি ধাপে রিভিউ থাকে, তখন ভুল ধরা পড়ে আগেভাগেই। তৃতীয়ত, সময় ও খরচ নিয়ন্ত্রণে থাকে। বাজেট ওভাররানের ঝুঁকি কমে। চতুর্থত, টিমের মধ্যে সমন্বয় ভালো হয়। সবাই একই পেজে থাকে। সবশেষে, প্রোডাক্টের কোয়ালিটি নিশ্চিত হয়। ব্যবহারকারীরা একটি পরিপূর্ণ, বাগমুক্ত সফটওয়্যার পায়।
SDLC-এর সাতটি ধাপ:
বিস্তারিত ব্যাখ্যা:
১. রিকোয়ারমেন্ট গ্যাদারিং (Requirement Gathering)
এটি হলো সবচেয়ে গুরুত্বপূর্ণ এবং একইসাথে সবচেয়ে উপেক্ষিত ধাপ। অনেক দল ভাবে, "কোড লিখতে গিয়েই সব বুঝে যাবো।" কিন্তু বাস্তবতা হলো, যদি শুরুতেই ভুল বুঝে কাজ শুরু করেন, তাহলে শেষে গিয়ে সেটা আরও ভয়াবহ হয়ে দাঁড়ায়।এই ধাপে আমরা ক্লায়েন্ট বা স্টেকহোল্ডারদের সাথে বসি। জানতে চাই:- এই সফটওয়্যারটি আসলে কী সমস্যা সমাধান করবে?
- কোন কোন ফিচার অবশ্যই থাকতে হবে?
- কারা এই সফটওয়্যার ব্যবহার করবে? তাদের টেকনিক্যাল স্কিল কেমন?
- বাজেট ও সময়সীমা কী?
- কোনো নির্দিষ্ট টেকনোলজি বা প্ল্যাটফর্ম প্রেফারেন্স আছে কিনা?
বাস্তব উদাহরণ: আমরা যখন একটি ই-কমার্স সাইট বানাচ্ছিলাম, তখন ক্লায়েন্ট প্রথমে বলেছিলেন শুধু প্রোডাক্ট লিস্টিং চান। কিন্তু আমরা যখন গভীরভাবে কথা বললাম, তখন বুঝতে পারলেন তিনি আসলে একটি পূর্ণাঙ্গ মার্কেটপ্লেস চান যেখানে মাল্টিপল ভেন্ডর নিজের প্রোডাক্ট আপলোড করতে পারবে। এই তথ্য যদি আমরা শুরুতেই না জানতাম, তাহলে আর্কিটেকচার সম্পূর্ণ ভিন্ন হতো।এই ধাপের আউটপুট হলো Software Requirement Specification (SRS) ডকুমেন্ট। এটি ভবিষ্যতে সবার রেফারেন্স পয়েন্ট হয়ে দাঁড়ায়।
এটি হলো সবচেয়ে গুরুত্বপূর্ণ এবং একইসাথে সবচেয়ে উপেক্ষিত ধাপ। অনেক দল ভাবে, "কোড লিখতে গিয়েই সব বুঝে যাবো।" কিন্তু বাস্তবতা হলো, যদি শুরুতেই ভুল বুঝে কাজ শুরু করেন, তাহলে শেষে গিয়ে সেটা আরও ভয়াবহ হয়ে দাঁড়ায়।
এই ধাপে আমরা ক্লায়েন্ট বা স্টেকহোল্ডারদের সাথে বসি। জানতে চাই:
- এই সফটওয়্যারটি আসলে কী সমস্যা সমাধান করবে?
- কোন কোন ফিচার অবশ্যই থাকতে হবে?
- কারা এই সফটওয়্যার ব্যবহার করবে? তাদের টেকনিক্যাল স্কিল কেমন?
- বাজেট ও সময়সীমা কী?
- কোনো নির্দিষ্ট টেকনোলজি বা প্ল্যাটফর্ম প্রেফারেন্স আছে কিনা?
বাস্তব উদাহরণ: আমরা যখন একটি ই-কমার্স সাইট বানাচ্ছিলাম, তখন ক্লায়েন্ট প্রথমে বলেছিলেন শুধু প্রোডাক্ট লিস্টিং চান। কিন্তু আমরা যখন গভীরভাবে কথা বললাম, তখন বুঝতে পারলেন তিনি আসলে একটি পূর্ণাঙ্গ মার্কেটপ্লেস চান যেখানে মাল্টিপল ভেন্ডর নিজের প্রোডাক্ট আপলোড করতে পারবে। এই তথ্য যদি আমরা শুরুতেই না জানতাম, তাহলে আর্কিটেকচার সম্পূর্ণ ভিন্ন হতো।
এই ধাপের আউটপুট হলো Software Requirement Specification (SRS) ডকুমেন্ট। এটি ভবিষ্যতে সবার রেফারেন্স পয়েন্ট হয়ে দাঁড়ায়।
২. প্ল্যানিং (Planning)
রিকোয়ারমেন্ট জেনে ফেললেই কাজ শুরু করা যায় না। এখন প্রশ্ন হলো, কীভাবে কাজটা করবো? এই ধাপে প্রজেক্ট ম্যানেজার, টেক লিড এবং সিনিয়র ডেভেলপাররা মিলে একটি রোডম্যাপ তৈরি করেন।প্ল্যানিং ফেজে আমরা নির্ধারণ করি:- প্রোজেক্টের স্কোপ কী? কী করা হবে এবং কী করা হবে না?
- টাইমলাইন কেমন হবে? মাইলস্টোন কী কী?
- কতজন ডেভেলপার লাগবে? কার কী দক্ষতা প্রয়োজন?
- বাজেট বরাদ্দ কীভাবে হবে?
- কী কী রিস্ক থাকতে পারে এবং সেগুলো মোকাবেলার প্ল্যান কী?
- কোন মেথডোলজি ব্যবহার করবো Waterfall, Agile, নাকি অন্য কিছু?
আমার অভিজ্ঞতায়, এই ধাপে যতো বেশি সময় দেওয়া যায়, পরে ততো কম সমস্যা হয়। একবার আমরা একটি প্রোজেক্টে মাত্র একদিন প্ল্যানিং করে কোডিং শুরু করেছিলাম। রেজাল্ট? মিড-প্রোজেক্টে আমাদের ডাটাবেস স্কিমা পুরোপুরি বদলাতে হয়েছিল, কারণ শুরুতে স্কেলাবিলিটি নিয়ে ভাবিনি।
রিকোয়ারমেন্ট জেনে ফেললেই কাজ শুরু করা যায় না। এখন প্রশ্ন হলো, কীভাবে কাজটা করবো? এই ধাপে প্রজেক্ট ম্যানেজার, টেক লিড এবং সিনিয়র ডেভেলপাররা মিলে একটি রোডম্যাপ তৈরি করেন।
প্ল্যানিং ফেজে আমরা নির্ধারণ করি:
- প্রোজেক্টের স্কোপ কী? কী করা হবে এবং কী করা হবে না?
- টাইমলাইন কেমন হবে? মাইলস্টোন কী কী?
- কতজন ডেভেলপার লাগবে? কার কী দক্ষতা প্রয়োজন?
- বাজেট বরাদ্দ কীভাবে হবে?
- কী কী রিস্ক থাকতে পারে এবং সেগুলো মোকাবেলার প্ল্যান কী?
- কোন মেথডোলজি ব্যবহার করবো Waterfall, Agile, নাকি অন্য কিছু?
আমার অভিজ্ঞতায়, এই ধাপে যতো বেশি সময় দেওয়া যায়, পরে ততো কম সমস্যা হয়। একবার আমরা একটি প্রোজেক্টে মাত্র একদিন প্ল্যানিং করে কোডিং শুরু করেছিলাম। রেজাল্ট? মিড-প্রোজেক্টে আমাদের ডাটাবেস স্কিমা পুরোপুরি বদলাতে হয়েছিল, কারণ শুরুতে স্কেলাবিলিটি নিয়ে ভাবিনি।
৩. ডিজাইন (Design)
এখন বুঝতে হবে সফটওয়্যারটি দেখতে কেমন হবে এবং ভেতরে কীভাবে কাজ করবে। এই ধাপে দুই ধরনের ডিজাইন হয়:হাই-লেভেল ডিজাইন (HLD): সিস্টেমের আর্কিটেকচার কেমন হবে, কোন কোন মডিউল থাকবে, কীভাবে একটার সাথে আরেকটা যোগাযোগ করবে। যেমন মাইক্রোসার্ভিস আর্কিটেকচার নাকি মনোলিথিক, কোন ক্লাউড প্ল্যাটফর্ম ব্যবহার করবো, কীভাবে লোড ব্যালেন্সিং করবো।লো-লেভেল ডিজাইন (LLD): প্রতিটি মডিউলের ভেতরের কাজ কীভাবে হবে, ক্লাস ডায়াগ্রাম, সিকোয়েন্স ডায়াগ্রাম, API স্পেসিফিকেশন।UI/UX ডিজাইন: ব্যবহারকারীরা স্ক্রিনে কী দেখবেন, কীভাবে নেভিগেট করবেন, কোথায় কোন বাটন থাকবে। ওয়্যারফ্রেম, মকআপ এবং প্রোটোটাইপ এই ধাপে তৈরি হয়।আমি ব্যক্তিগতভাবে মনে করি, ডিজাইন ফেজে ডেভেলপারদের ইনভলভ করা উচিত। কারণ যারা কোড লিখবে, তারা যদি আর্কিটেকচার না বোঝে, তাহলে ইমপ্লিমেন্টেশনে গ্যাপ তৈরি হয়। আমাদের টিমে আমরা ডিজাইন রিভিউ মিটিং রাখি, যেখানে সিনিয়র ডেভেলপাররা টেক লিডের সাথে বসে ডিজাইন নিয়ে আলোচনা করেন।
এখন বুঝতে হবে সফটওয়্যারটি দেখতে কেমন হবে এবং ভেতরে কীভাবে কাজ করবে। এই ধাপে দুই ধরনের ডিজাইন হয়:
হাই-লেভেল ডিজাইন (HLD): সিস্টেমের আর্কিটেকচার কেমন হবে, কোন কোন মডিউল থাকবে, কীভাবে একটার সাথে আরেকটা যোগাযোগ করবে। যেমন মাইক্রোসার্ভিস আর্কিটেকচার নাকি মনোলিথিক, কোন ক্লাউড প্ল্যাটফর্ম ব্যবহার করবো, কীভাবে লোড ব্যালেন্সিং করবো।
লো-লেভেল ডিজাইন (LLD): প্রতিটি মডিউলের ভেতরের কাজ কীভাবে হবে, ক্লাস ডায়াগ্রাম, সিকোয়েন্স ডায়াগ্রাম, API স্পেসিফিকেশন।
UI/UX ডিজাইন: ব্যবহারকারীরা স্ক্রিনে কী দেখবেন, কীভাবে নেভিগেট করবেন, কোথায় কোন বাটন থাকবে। ওয়্যারফ্রেম, মকআপ এবং প্রোটোটাইপ এই ধাপে তৈরি হয়।
আমি ব্যক্তিগতভাবে মনে করি, ডিজাইন ফেজে ডেভেলপারদের ইনভলভ করা উচিত। কারণ যারা কোড লিখবে, তারা যদি আর্কিটেকচার না বোঝে, তাহলে ইমপ্লিমেন্টেশনে গ্যাপ তৈরি হয়। আমাদের টিমে আমরা ডিজাইন রিভিউ মিটিং রাখি, যেখানে সিনিয়র ডেভেলপাররা টেক লিডের সাথে বসে ডিজাইন নিয়ে আলোচনা করেন।
৪. ডেভেলপমেন্ট (Development)
এটিই সেই ধাপ যেখানে সবচেয়ে বেশি মানুষের আগ্রহ থাকে কোডিং ফেজ। কিন্তু এটি SDLC-এর শুধু একটি অংশ মাত্র। এই ধাপে ডেভেলপাররা ডিজাইন অনুযায়ী কোড লিখেন, ফিচার ইমপ্লিমেন্ট করেন, এবং মডিউলগুলো একত্রিত করেন।ডেভেলপমেন্ট ফেজে যা করা হয়:- ফ্রন্টএন্ড ডেভেলপমেন্ট: ইউজার ইন্টারফেস তৈরি, রেসপন্সিভ ডিজাইন ইমপ্লিমেন্ট করা
- ব্যাকএন্ড ডেভেলপমেন্ট: সার্ভার-সাইড লজিক, API ডেভেলপমেন্ট, ডাটাবেস ইন্টিগ্রেশন
- ডাটাবেস ডেভেলপমেন্ট: স্কিমা ডিজাইন, কুয়েরি অপ্টিমাইজেশন
- থার্ড-পার্টি ইন্টিগ্রেশন: পেমেন্ট গেটওয়ে, SMS গেটওয়ে, সোশ্যাল লগইন ইত্যাদি
এই ধাপে ভার্সন কন্ট্রোল (Git), কোড রিভিউ, এবং কন্টিনিউয়াস ইন্টিগ্রেশন (CI) অনেক গুরুত্বপূর্ণ। আমরা সাধারণত দৈনিক স্ট্যান্ড-আপ মিটিং করি, যেখানে প্রত্যেকে নিজের প্রগ্রেস শেয়ার করেন এবং যে কোনো ব্লকার নিয়ে আলোচনা করেন।একটি কথা মনে রাখতে হবে—ভালো কোড লেখা শুধু কম্পাইল হওয়া নয়, যেটা অন্য ডেভেলপাররা পড়তে পারবে এবং ভবিষ্যতে মেইনটেইন করতে পারবে।
এটিই সেই ধাপ যেখানে সবচেয়ে বেশি মানুষের আগ্রহ থাকে কোডিং ফেজ। কিন্তু এটি SDLC-এর শুধু একটি অংশ মাত্র। এই ধাপে ডেভেলপাররা ডিজাইন অনুযায়ী কোড লিখেন, ফিচার ইমপ্লিমেন্ট করেন, এবং মডিউলগুলো একত্রিত করেন।
ডেভেলপমেন্ট ফেজে যা করা হয়:
- ফ্রন্টএন্ড ডেভেলপমেন্ট: ইউজার ইন্টারফেস তৈরি, রেসপন্সিভ ডিজাইন ইমপ্লিমেন্ট করা
- ব্যাকএন্ড ডেভেলপমেন্ট: সার্ভার-সাইড লজিক, API ডেভেলপমেন্ট, ডাটাবেস ইন্টিগ্রেশন
- ডাটাবেস ডেভেলপমেন্ট: স্কিমা ডিজাইন, কুয়েরি অপ্টিমাইজেশন
- থার্ড-পার্টি ইন্টিগ্রেশন: পেমেন্ট গেটওয়ে, SMS গেটওয়ে, সোশ্যাল লগইন ইত্যাদি
এই ধাপে ভার্সন কন্ট্রোল (Git), কোড রিভিউ, এবং কন্টিনিউয়াস ইন্টিগ্রেশন (CI) অনেক গুরুত্বপূর্ণ। আমরা সাধারণত দৈনিক স্ট্যান্ড-আপ মিটিং করি, যেখানে প্রত্যেকে নিজের প্রগ্রেস শেয়ার করেন এবং যে কোনো ব্লকার নিয়ে আলোচনা করেন।
একটি কথা মনে রাখতে হবে—ভালো কোড লেখা শুধু কম্পাইল হওয়া নয়, যেটা অন্য ডেভেলপাররা পড়তে পারবে এবং ভবিষ্যতে মেইনটেইন করতে পারবে।
৫. টেস্টিং (Testing)
কোড লেখা শেষ মানেই কাজ শেষ নয়। এখন দেখতে হবে সেটা ঠিকভাবে কাজ করে কিনা। এই ধাপে QA ইঞ্জিনিয়াররা বিভিন্ন ধরনের টেস্ট করেন:ইউনিট টেস্টিং: প্রতিটি ছোট ফাংশন আলাদাভাবে টেস্ট করা। ডেভেলপাররা সাধারণত নিজেরাই এটি করেন।ইন্টিগ্রেশন টেস্টিং: বিভিন্ন মডিউল একসাথে কাজ করছে কিনা দেখা।সিস্টেম টেস্টিং: পুরো সিস্টেম এন্ড-টু-এন্ড টেস্ট করা।ইউজার অ্যাকসেপটেন্স টেস্টিং (UAT): ক্লায়েন্ট বা রিয়েল ইউজাররা টেস্ট করে দেখেন যে তাদের রিকোয়ারমেন্ট মিট হচ্ছে কিনা।পারফরম্যান্স টেস্টিং: লোড টেস্টিং, স্ট্রেস টেস্টিং দিয়ে দেখা যে অনেক ইউজার একসাথে ব্যবহার করলে সিস্টেম কীভাবে রিঅ্যাক্ট করে।সিকিউরিটি টেস্টিং: ভলনারেবিলিটি স্ক্যান, পেনেট্রেশন টেস্টিং।আমার মতে, টেস্টিং ফেজে ডেভেলপারদের অংশগ্রহণ খুবই জরুরি। বাগ রিপোর্ট আসলে ডেফেন্সিভ না হয়ে কিউরিয়াস হতে হবে—"কেন এই বাগ হলো, কীভাবে এড়ানো যায়?" এই মনোভাব নিয়ে কাজ করলে ভবিষ্যতে একই ভুল কম হয়।
কোড লেখা শেষ মানেই কাজ শেষ নয়। এখন দেখতে হবে সেটা ঠিকভাবে কাজ করে কিনা। এই ধাপে QA ইঞ্জিনিয়াররা বিভিন্ন ধরনের টেস্ট করেন:
ইউনিট টেস্টিং: প্রতিটি ছোট ফাংশন আলাদাভাবে টেস্ট করা। ডেভেলপাররা সাধারণত নিজেরাই এটি করেন।
ইন্টিগ্রেশন টেস্টিং: বিভিন্ন মডিউল একসাথে কাজ করছে কিনা দেখা।
সিস্টেম টেস্টিং: পুরো সিস্টেম এন্ড-টু-এন্ড টেস্ট করা।
ইউজার অ্যাকসেপটেন্স টেস্টিং (UAT): ক্লায়েন্ট বা রিয়েল ইউজাররা টেস্ট করে দেখেন যে তাদের রিকোয়ারমেন্ট মিট হচ্ছে কিনা।
পারফরম্যান্স টেস্টিং: লোড টেস্টিং, স্ট্রেস টেস্টিং দিয়ে দেখা যে অনেক ইউজার একসাথে ব্যবহার করলে সিস্টেম কীভাবে রিঅ্যাক্ট করে।
সিকিউরিটি টেস্টিং: ভলনারেবিলিটি স্ক্যান, পেনেট্রেশন টেস্টিং।
আমার মতে, টেস্টিং ফেজে ডেভেলপারদের অংশগ্রহণ খুবই জরুরি। বাগ রিপোর্ট আসলে ডেফেন্সিভ না হয়ে কিউরিয়াস হতে হবে—"কেন এই বাগ হলো, কীভাবে এড়ানো যায়?" এই মনোভাব নিয়ে কাজ করলে ভবিষ্যতে একই ভুল কম হয়।
৬. ডেপ্লয়মেন্ট (Deployment)
সব টেস্ট পাস হলে এখন সফটওয়্যারটি লাইভ করার পালা। এই ধাপে কাজগুলো হয়:- প্রোডাকশন সার্ভার প্রস্তুত করা
- কোড ডিপ্লয় করা (ম্যানুয়ালি বা CI/CD পাইপলাইনের মাধ্যমে)
- ডাটাবেস মাইগ্রেশন করা
- ডোমেইন এবং SSL কনফিগার করা
- মনিটরিং টুল সেটআপ করা
ডেপ্লয়মেন্ট সবসময় স্মুথ হয় না। একবার আমরা একটি প্রোজেক্ট ডেপ্লয় করার পর দেখলাম প্রোডাকশনে ডাটাবেস কানেকশন টাইমআউট হচ্ছে। স্টেজিং এনভায়রনমেন্টে সব ঠিক ছিল, কিন্তু প্রোডাকশনে ডাটা ভলিউম বেশি হওয়ায় সমস্যা দেখা দিল। তাই ব্লু-গ্রিন ডেপ্লয়মেন্ট বা ক্যানারি রিলিজের মতো স্ট্র্যাটেজি ব্যবহার করা উচিত, যাতে সমস্যা হলেও দ্রুত রোলব্যাক করা যায়।
সব টেস্ট পাস হলে এখন সফটওয়্যারটি লাইভ করার পালা। এই ধাপে কাজগুলো হয়:
- প্রোডাকশন সার্ভার প্রস্তুত করা
- কোড ডিপ্লয় করা (ম্যানুয়ালি বা CI/CD পাইপলাইনের মাধ্যমে)
- ডাটাবেস মাইগ্রেশন করা
- ডোমেইন এবং SSL কনফিগার করা
- মনিটরিং টুল সেটআপ করা
ডেপ্লয়মেন্ট সবসময় স্মুথ হয় না। একবার আমরা একটি প্রোজেক্ট ডেপ্লয় করার পর দেখলাম প্রোডাকশনে ডাটাবেস কানেকশন টাইমআউট হচ্ছে। স্টেজিং এনভায়রনমেন্টে সব ঠিক ছিল, কিন্তু প্রোডাকশনে ডাটা ভলিউম বেশি হওয়ায় সমস্যা দেখা দিল। তাই ব্লু-গ্রিন ডেপ্লয়মেন্ট বা ক্যানারি রিলিজের মতো স্ট্র্যাটেজি ব্যবহার করা উচিত, যাতে সমস্যা হলেও দ্রুত রোলব্যাক করা যায়।
৭. মেইনটেন্যান্স (Maintenance)
মনে করবেন না সফটওয়্যার লাইভ হলেই কাজ শেষ। আসল কাজ তখনই শুরু হয়। ব্যবহারকারীরা নতুন নতুন সমস্যা খুঁজে বের করবে, নতুন ফিচার চাইবে, অপারেটিং সিস্টেম বা ব্রাউজার আপডেট হলে কম্প্যাটিবিলিটি ইস্যু দেখা দেবে।মেইনটেন্যান্স ফেজে যা করা হয়:- বাগ ফিক্সিং: ইউজাররা যে সমস্যাগুলো রিপোর্ট করেন সেগুলো সমাধান করা
- পারফরম্যান্স অপ্টিমাইজেশন: স্লো কুয়েরি ফিক্স করা, ক্যাশিং ইমপ্লিমেন্ট করা
- ফিচার এনহান্সমেন্ট: নতুন ফিচার যোগ করা, বিদ্যমান ফিচার ইমপ্রুভ করা
- সিকিউরিটি আপডেট: নতুন ভলনারেবিলিটি প্যাচ করা
- টেকনিক্যাল ডেব্ট রিডাকশন: পুরনো কোড রিফ্যাক্টর করা
আমি মনে করি, একটি সফল সফটওয়্যারের ৭০ শতাংশ জীবনকাল মেইনটেন্যান্স ফেজে কাটে। তাই কোড লেখার সময়ই মেইনটেইনেবিলিটির কথা মাথায় রাখা উচিত।![]()
মনে করবেন না সফটওয়্যার লাইভ হলেই কাজ শেষ। আসল কাজ তখনই শুরু হয়। ব্যবহারকারীরা নতুন নতুন সমস্যা খুঁজে বের করবে, নতুন ফিচার চাইবে, অপারেটিং সিস্টেম বা ব্রাউজার আপডেট হলে কম্প্যাটিবিলিটি ইস্যু দেখা দেবে।
মেইনটেন্যান্স ফেজে যা করা হয়:
- বাগ ফিক্সিং: ইউজাররা যে সমস্যাগুলো রিপোর্ট করেন সেগুলো সমাধান করা
- পারফরম্যান্স অপ্টিমাইজেশন: স্লো কুয়েরি ফিক্স করা, ক্যাশিং ইমপ্লিমেন্ট করা
- ফিচার এনহান্সমেন্ট: নতুন ফিচার যোগ করা, বিদ্যমান ফিচার ইমপ্রুভ করা
- সিকিউরিটি আপডেট: নতুন ভলনারেবিলিটি প্যাচ করা
- টেকনিক্যাল ডেব্ট রিডাকশন: পুরনো কোড রিফ্যাক্টর করা
আমি মনে করি, একটি সফল সফটওয়্যারের ৭০ শতাংশ জীবনকাল মেইনটেন্যান্স ফেজে কাটে। তাই কোড লেখার সময়ই মেইনটেইনেবিলিটির কথা মাথায় রাখা উচিত।
SDLC মডেলের প্রকারভেদ
বিভিন্ন ধরনের প্রোজেক্টের জন্য বিভিন্ন ধরনের SDLC মডেল উপযোগী:Waterfall Model: পুরনো এবং ঐতিহ্যবাহী। এক ধাপ শেষ না হলে পরের ধাপে যাওয়া যায় না। তবে রিকোয়ারমেন্ট স্পষ্ট এবং পরিবর্তনের সম্ভাবনা কম এমন প্রোজেক্টে এখনো কাজে লাগে।Agile Model: বর্তমানে সবচেয়ে জনপ্রিয়। ছোট ছোট স্প্রিন্টে কাজ হয়, প্রতি সপ্তাহে বা দুই সপ্তাহে একটি কাজিং ভার্সন দেওয়া হয়। রিকোয়ারমেন্ট পরিবর্তন স্বাভাবিকভাবে গ্রহণ করা হয়। স্ক্রাম বা কানবান পদ্ধতি ব্যবহার করা হয়।Spiral Model: বড় এবং রিস্কি প্রোজেক্টের জন্য। প্রতিটি ধাপে রিস্ক অ্যানালাইসিস করা হয়।V-Model: Waterfall-এর মতোই, কিন্তু প্রতিটি ডেভেলপমেন্ট ধাপের সাথে প্যারালাল একটি টেস্টিং ধাপ থাকে।DevOps Model: ডেভেলপমেন্ট এবং অপারেশনকে একত্রিত করে। CI/CD, অটোমেশন, এবং কন্টিনিউয়াস মনিটরিং এর মূল ভিত্তি।আমার পরামর্শ হবে, শুরুতে Agile এবং DevOps-এর উপর ফোকাস করুন। বর্তমান ইন্ডাস্ট্রিতে এগুলোর চাহিদা সবচেয়ে বেশি।
বিভিন্ন ধরনের প্রোজেক্টের জন্য বিভিন্ন ধরনের SDLC মডেল উপযোগী:
Waterfall Model: পুরনো এবং ঐতিহ্যবাহী। এক ধাপ শেষ না হলে পরের ধাপে যাওয়া যায় না। তবে রিকোয়ারমেন্ট স্পষ্ট এবং পরিবর্তনের সম্ভাবনা কম এমন প্রোজেক্টে এখনো কাজে লাগে।
Agile Model: বর্তমানে সবচেয়ে জনপ্রিয়। ছোট ছোট স্প্রিন্টে কাজ হয়, প্রতি সপ্তাহে বা দুই সপ্তাহে একটি কাজিং ভার্সন দেওয়া হয়। রিকোয়ারমেন্ট পরিবর্তন স্বাভাবিকভাবে গ্রহণ করা হয়। স্ক্রাম বা কানবান পদ্ধতি ব্যবহার করা হয়।
Spiral Model: বড় এবং রিস্কি প্রোজেক্টের জন্য। প্রতিটি ধাপে রিস্ক অ্যানালাইসিস করা হয়।
V-Model: Waterfall-এর মতোই, কিন্তু প্রতিটি ডেভেলপমেন্ট ধাপের সাথে প্যারালাল একটি টেস্টিং ধাপ থাকে।
DevOps Model: ডেভেলপমেন্ট এবং অপারেশনকে একত্রিত করে। CI/CD, অটোমেশন, এবং কন্টিনিউয়াস মনিটরিং এর মূল ভিত্তি।
আমার পরামর্শ হবে, শুরুতে Agile এবং DevOps-এর উপর ফোকাস করুন। বর্তমান ইন্ডাস্ট্রিতে এগুলোর চাহিদা সবচেয়ে বেশি।
একটি বাস্তব উদাহরণ: ফুড ডেলিভারি অ্যাপ
চলুন একটি ফুড ডেলিভারি অ্যাপ বানানোর কথা ভাবি:Requirement: ব্যবহারকারীরা রেস্তোরাঁ ব্রাউজ করবে, খাবার অর্ডার করবে, রিয়েল-টাইম ট্র্যাকিং দেখবে, এবং ক্যাশঅন ডেলিভারি বা অনলাইন পেমেন্ট করতে পারবে। রেস্তোরাঁ মালিকরা তাদের মেনু ম্যানেজ করতে পারবে এবং অর্ডার দেখতে পারবে। ডেলিভারি বয়দের জন্য আলাদা অ্যাপ লাগবে যেখানে তারা অর্ডার পিকআপ এবং ডেলিভারি স্ট্যাটাস আপডেট করতে পারবে।Planning: তিন মাসের মাইলস্টোন সেট করলাম। প্রথম মাসে ইউজার অ্যাপ এবং ব্যাকএন্ড, দ্বিতীয় মাসে রেস্তোরাঁ এবং ডেলিভারি পার্টনার অ্যাপ, তৃতীয় মাসে টেস্টিং এবং ডেপ্লয়মেন্ট। দলে দুই জন ফ্লটার ডেভেলপার, দুই জন Node.js ডেভেলপার, এক জন UI/UX ডিজাইনার, এবং এক জন QA ইঞ্জিনিয়ার।Design: UI/UX টিম ওয়্যারফ্রেম তৈরি করলো। ব্যাকএন্ড টিম API স্পেসিফিকেশন লিখলো। আর্কিটেকচার হিসেবে মাইক্রোসার্ভিস চূড়ান্ত হলো—অর্ডার সার্ভিস, ইউজার সার্ভিস, নোটিফিকেশন সার্ভিস আলাদা আলাদা হবে যাতে স্কেল করা সহজ হয়।Development: প্রথম স্প্রিন্টে ইউজার অথেন্টিকেশন এবং রেস্তোরাঁ লিস্টিং কমপ্লিট হলো। দ্বিতীয় স্প্রিন্টে কার্ট এবং অর্ডার প্লেসমেন্ট। তৃতীয় স্প্রিন্টে পেমেন্ট ইন্টিগ্রেশন এবং ট্র্যাকিং।Testing: ইউনিট টেস্টের পর ইন্টিগ্রেশন টেস্টিং হলো। তারপর ১০ জন বেটা ইউজার দিয়ে UAT করা হলো। পেমেন্ট গেটওয়ের স্যান্ডবক্সে মাল্টিপল ট্রানজাকশন টেস্ট করা হলো।Deployment: AWS-এ ডিপ্লয় করা হলো। ডোকার কন্টেইনার ব্যবহার করা হলো। CloudWatch দিয়ে মনিটরিং সেটআপ করা হলো। Maintenance: লাইভ হওয়ার পর দেখা গেলো পিক আওয়ারে সার্ভার লোড বেশি হচ্ছে। অটো-স্কেলিং কনফিগার করা হলো। ইউজাররা ক্যাশঅন ডেলিভারি নিয়ে কনফিউশন জানালেন, তাই UI-এ কিছু পরিবর্তন করা হলো।
চলুন একটি ফুড ডেলিভারি অ্যাপ বানানোর কথা ভাবি:
Requirement: ব্যবহারকারীরা রেস্তোরাঁ ব্রাউজ করবে, খাবার অর্ডার করবে, রিয়েল-টাইম ট্র্যাকিং দেখবে, এবং ক্যাশঅন ডেলিভারি বা অনলাইন পেমেন্ট করতে পারবে। রেস্তোরাঁ মালিকরা তাদের মেনু ম্যানেজ করতে পারবে এবং অর্ডার দেখতে পারবে। ডেলিভারি বয়দের জন্য আলাদা অ্যাপ লাগবে যেখানে তারা অর্ডার পিকআপ এবং ডেলিভারি স্ট্যাটাস আপডেট করতে পারবে।
Planning: তিন মাসের মাইলস্টোন সেট করলাম। প্রথম মাসে ইউজার অ্যাপ এবং ব্যাকএন্ড, দ্বিতীয় মাসে রেস্তোরাঁ এবং ডেলিভারি পার্টনার অ্যাপ, তৃতীয় মাসে টেস্টিং এবং ডেপ্লয়মেন্ট। দলে দুই জন ফ্লটার ডেভেলপার, দুই জন Node.js ডেভেলপার, এক জন UI/UX ডিজাইনার, এবং এক জন QA ইঞ্জিনিয়ার।
Design: UI/UX টিম ওয়্যারফ্রেম তৈরি করলো। ব্যাকএন্ড টিম API স্পেসিফিকেশন লিখলো। আর্কিটেকচার হিসেবে মাইক্রোসার্ভিস চূড়ান্ত হলো—অর্ডার সার্ভিস, ইউজার সার্ভিস, নোটিফিকেশন সার্ভিস আলাদা আলাদা হবে যাতে স্কেল করা সহজ হয়।
Development: প্রথম স্প্রিন্টে ইউজার অথেন্টিকেশন এবং রেস্তোরাঁ লিস্টিং কমপ্লিট হলো। দ্বিতীয় স্প্রিন্টে কার্ট এবং অর্ডার প্লেসমেন্ট। তৃতীয় স্প্রিন্টে পেমেন্ট ইন্টিগ্রেশন এবং ট্র্যাকিং।
Testing: ইউনিট টেস্টের পর ইন্টিগ্রেশন টেস্টিং হলো। তারপর ১০ জন বেটা ইউজার দিয়ে UAT করা হলো। পেমেন্ট গেটওয়ের স্যান্ডবক্সে মাল্টিপল ট্রানজাকশন টেস্ট করা হলো।
Deployment: AWS-এ ডিপ্লয় করা হলো। ডোকার কন্টেইনার ব্যবহার করা হলো। CloudWatch দিয়ে মনিটরিং সেটআপ করা হলো।
Maintenance: লাইভ হওয়ার পর দেখা গেলো পিক আওয়ারে সার্ভার লোড বেশি হচ্ছে। অটো-স্কেলিং কনফিগার করা হলো। ইউজাররা ক্যাশঅন ডেলিভারি নিয়ে কনফিউশন জানালেন, তাই UI-এ কিছু পরিবর্তন করা হলো।
শেষ কথা
SDLC শুধু একটি থিওরি নয়, এটি সফটওয়্যার ইন্ডাস্ট্রির বাস্তব অভিজ্ঞতার সংকলন। যে দলগুলো SDLC মেনে চলে, তাদের প্রোজেক্ট সফল হওয়ার সম্ভাবনা অনেক বেশি। যারা ডেভেলপার হতে চান বা QA ইঞ্জিনিয়ার হতে চান, তাদের জন্য SDLC-এর প্রতিটি ধাপ ভালোভাবে বোঝা অত্যন্ত জরুরি।আমার ব্যক্তিগত পরামর্শ—শুধু পড়ে যাবেন না, নিজে ছোট ছোট প্রোজেক্টে এই ধাপগুলো ফলো করার চেষ্টা করুন। একটি সিম্পল টু-ডু অ্যাপ বানান, কিন্তু SRS ডকুমেন্ট লিখুন, ডিজাইন ডকুমেন্ট করুন, টেস্ট কেস লিখুন। দেখবেন, ধীরে ধীরে আপনার কাজের মান এবং পেশাদারি দক্ষতা বেড়ে যাবে।আপনি যদি QA-এর দিকে আগ্রহী হন, তাহলে SDLC-এর সাথে সাথে STLC (Software Testing Life Cycle) নিয়েও পড়াশোনা করুন। STLC হলো SDLC-র টেস্টিং ফেজের বিস্তারিত রূপ, যা QA ইঞ্জিনিয়ারদের জন্য বিশেষভাবে গুরুত্বপূর্ণ।
SDLC শুধু একটি থিওরি নয়, এটি সফটওয়্যার ইন্ডাস্ট্রির বাস্তব অভিজ্ঞতার সংকলন। যে দলগুলো SDLC মেনে চলে, তাদের প্রোজেক্ট সফল হওয়ার সম্ভাবনা অনেক বেশি। যারা ডেভেলপার হতে চান বা QA ইঞ্জিনিয়ার হতে চান, তাদের জন্য SDLC-এর প্রতিটি ধাপ ভালোভাবে বোঝা অত্যন্ত জরুরি।
আমার ব্যক্তিগত পরামর্শ—শুধু পড়ে যাবেন না, নিজে ছোট ছোট প্রোজেক্টে এই ধাপগুলো ফলো করার চেষ্টা করুন। একটি সিম্পল টু-ডু অ্যাপ বানান, কিন্তু SRS ডকুমেন্ট লিখুন, ডিজাইন ডকুমেন্ট করুন, টেস্ট কেস লিখুন। দেখবেন, ধীরে ধীরে আপনার কাজের মান এবং পেশাদারি দক্ষতা বেড়ে যাবে।
আপনি যদি QA-এর দিকে আগ্রহী হন, তাহলে SDLC-এর সাথে সাথে STLC (Software Testing Life Cycle) নিয়েও পড়াশোনা করুন। STLC হলো SDLC-র টেস্টিং ফেজের বিস্তারিত রূপ, যা QA ইঞ্জিনিয়ারদের জন্য বিশেষভাবে গুরুত্বপূর্ণ।