পাঠ ০৩ · ৫৮-এর মধ্যে · মডিউল ১
Home / Courses / Software Engineering Principles & Git / কোয়ালিটি অ্যাট্রিবিউট

সফটওয়্যার কোয়ালিটি অ্যাট্রিবিউট

Software quality attributes
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • কোয়ালিটি অ্যাট্রিবিউট কী এবং এটি ফিচার/ফাংশনালিটি থেকে কীভাবে আলাদা
  • ছয়টি মূল কোয়ালিটি অ্যাট্রিবিউট — Correctness, Reliability, Usability, Maintainability, Efficiency, Portability
  • কেন এই অ্যাট্রিবিউটগুলো প্রায়ই সাংঘর্ষিক, এবং কেন এর জন্য সচেতন ট্রেড-অফ প্রয়োজন
  • Python দিয়ে একাধিক ডিজাইন সিদ্ধান্তের কোয়ালিটি-স্কোর তুলনা করে এই সংঘাত সরাসরি দেখা

১ · কোয়ালিটি অ্যাট্রিবিউট কী — ফিচার থেকে ভিন্ন

কোয়ালিটি অ্যাট্রিবিউটQuality Attributeএকটি সফটওয়্যার সিস্টেম কতটা ভালোভাবে কাজ করে তা বর্ণনা করে এমন একটি বৈশিষ্ট্য — সিস্টেমটি কী করে (ফিচার) তা নয়, বরং কীভাবে করে তা। বর্ণনা করে একটি সফটওয়্যার সিস্টেম কতটা ভালোভাবে কাজ করে — এটি সিস্টেমের ফিচার (এটি কী কী কাজ করতে পারে) থেকে সম্পূর্ণ ভিন্ন একটি প্রশ্ন। যেমন "ব্যবহারকারী পাসওয়ার্ড রিসেট করতে পারবে" একটি ফিচার — কিন্তু "পাসওয়ার্ড রিসেট প্রক্রিয়াটি কতটা দ্রুত, কতটা নির্ভরযোগ্য, এবং কতটা সহজে ব্যবহারযোগ্য" — এগুলো কোয়ালিটি অ্যাট্রিবিউটের প্রশ্ন। এই ধারণাটি সরাসরি M3-এর non-functional requirementNon-Functional Requirementএকটি রিকোয়ারমেন্ট যা সিস্টেম কী করে তা নয়, বরং কতটা ভালোভাবে করে তা নির্দিষ্ট করে -- কোয়ালিটি অ্যাট্রিবিউটকে একটি লিখিত রিকোয়ারমেন্টে রূপান্তরিত করা হলে এটিই হয়। ধারণার ভিত্তি — সেখানে (L11) আমরা দেখব কীভাবে এই অ্যাট্রিবিউটগুলোকে লিখিত, পরীক্ষাযোগ্য রিকোয়ারমেন্টে রূপান্তর করা হয়।

ফিচার — সিস্টেম কী করে (WHAT) কোয়ালিটি অ্যাট্রিবিউট — কতটা ভালো করে (HOW WELL) সম্পূর্ণ সফটওয়্যার প্রোডাক্ট
একটি সম্পূর্ণ প্রোডাক্টের জন্য ফিচার এবং কোয়ালিটি অ্যাট্রিবিউট — দুটোই প্রয়োজন। শুধু ফিচার থাকলেই যথেষ্ট নয়, যদি সেই ফিচার অনির্ভরযোগ্য বা ব্যবহার-অযোগ্য হয়।

২ · ছয়টি মূল কোয়ালিটি অ্যাট্রিবিউট

CorrectnessCorrectnessসিস্টেমটি ঠিক তা করে কিনা যা স্পেসিফিকেশনে বলা হয়েছে।
সিস্টেম কি ঠিক তা-ই করে যা স্পেসিফাই করা হয়েছে?
ReliabilityReliabilityসিস্টেম কি সময়ের সাথে, এমনকি অপ্রত্যাশিত পরিস্থিতিতেও, নির্ভুলভাবে কাজ করতে থাকে?
সময়ের সাথে, এমনকি অপ্রত্যাশিত পরিস্থিতিতেও, নির্ভুলভাবে কাজ চলতে থাকে কিনা — M10-এর টেস্টিং মডিউলের সরাসরি ভিত্তি।
UsabilityUsabilityবাস্তব ব্যবহারকারীরা কতটা সহজে সিস্টেমটি ব্যবহার করতে পারেন।
বাস্তব ব্যবহারকারীরা কতটা সহজে সিস্টেমটি আসলে ব্যবহার করতে পারেন?
MaintainabilityMaintainabilityপরবর্তীতে কতটা সহজে সিস্টেমটি বোঝা, ঠিক করা ও সম্প্রসারণ করা যায়।
পরবর্তীতে কতটা সহজে বোঝা, ঠিক করা ও সম্প্রসারণ করা যায় — M11-এর কোড কোয়ালিটি ও রিফ্যাক্টরিং মডিউলের সরাসরি ভিত্তি।
EfficiencyEfficiencyসিস্টেম রিসোর্স (সময়, মেমরি) কতটা ভালোভাবে ব্যবহার করে।
সময়, মেমরি — এই রিসোর্সগুলো কতটা ভালোভাবে ব্যবহৃত হয়। এর অন্তর্নিহিত পারফরম্যান্স মেকানিক্স গভীরভাবে কভার করে Computer Architecture ও DSA কোর্স।
PortabilityPortabilityবিভিন্ন এনভায়রনমেন্টে সিস্টেমটি কতটা সহজে চালানো যায়।
বিভিন্ন এনভায়রনমেন্টে (অপারেটিং সিস্টেম, হার্ডওয়্যার) সিস্টেমটি কতটা সহজে চালানো যায়?

৩ · একটি বাস্তব সংঘাত — একসাথে সবকিছু সর্বোচ্চ করা যায় না

এই অ্যাট্রিবিউটগুলোর একটি গুরুত্বপূর্ণ, সৎভাবে স্বীকার করার মতো বৈশিষ্ট্য হলো — এগুলো প্রায়ই একে অপরের সাথে সাংঘর্ষিক। উদাহরণস্বরূপ, সর্বোচ্চ efficiency অর্জনের জন্য কোড টাইট ও চতুরভাবে অপ্টিমাইজ করা হলে সেই কোড বোঝা কঠিন হয়ে যায় — অর্থাৎ maintainability কমে যায়। বাস্তব সফটওয়্যার ইঞ্জিনিয়ারিংয়ে তাই লক্ষ্য সবগুলো অ্যাট্রিবিউট একসাথে সর্বোচ্চ করা নয় — বরং নির্দিষ্ট সিস্টেমের অগ্রাধিকার অনুযায়ী সচেতনভাবে ট্রেড-অফ করা। একটি ফ্লাইট-কন্ট্রোল সিস্টেম হয়তো reliability-কে সর্বোচ্চ অগ্রাধিকার দেবে, আর একটি স্টার্টআপের প্রোটোটাইপ হয়তো দ্রুত ডেভেলপমেন্ট গতির জন্য কিছুটা efficiency ছাড় দেবে।

Python
# কয়েকটি টয় ডিজাইন সিদ্ধান্তকে correctness, maintainability ও efficiency -- এই তিনটি
# অ্যাট্রিবিউট অনুযায়ী স্কোর (১-১০) দিয়ে তুলনা করছি, যাতে সাংঘর্ষিক প্যাটার্নটি
# সংখ্যায় স্পষ্ট দেখা যায়।

design_choices = {
    "অপ্টিমাইজড কিন্তু জটিল কোড": {"correctness": 8, "maintainability": 3, "efficiency": 9},
    "পরিষ্কার কিন্তু অপ্টিমাইজ না-করা কোড": {"correctness": 9, "maintainability": 9, "efficiency": 4},
    "ব্যাপক ভ্যালিডেটেড ইনপুট হ্যান্ডলিং": {"correctness": 10, "maintainability": 7, "efficiency": 5},
}

print("ডিজাইন সিদ্ধান্তের কোয়ালিটি-স্কোর তুলনা (১-১০):\n")
for choice, scores in design_choices.items():
    print(f"{choice}")
    print(f"  Correctness: {scores['correctness']}/10   "
          f"Maintainability: {scores['maintainability']}/10   "
          f"Efficiency: {scores['efficiency']}/10")

best_efficiency = max(design_choices, key=lambda c: design_choices[c]["efficiency"])
best_maintainability = max(design_choices, key=lambda c: design_choices[c]["maintainability"])

print("\nসর্বোচ্চ efficiency ও সর্বোচ্চ maintainability আলাদা আলাদা সিদ্ধান্তে দেখা যাচ্ছে:")
print(f"  সর্বোচ্চ efficiency      → {best_efficiency} ({design_choices[best_efficiency]['efficiency']}/10)")
print(f"  সর্বোচ্চ maintainability → {best_maintainability} ({design_choices[best_maintainability]['maintainability']}/10)")

    
লক্ষ্য করুন প্রিন্ট হওয়া ফলাফলে: "অপ্টিমাইজড কিন্তু জটিল কোড" সর্বোচ্চ efficiency (৯/১০) পেয়েছে, কিন্তু তার maintainability সবচেয়ে কম (৩/১০)। উল্টোদিকে "পরিষ্কার কিন্তু অপ্টিমাইজ না-করা কোড" সর্বোচ্চ maintainability (৯/১০) পেয়েছে, কিন্তু তার efficiency সবচেয়ে কম (৪/১০)। কোনো একক সিদ্ধান্তই দুটোতেই সর্বোচ্চ স্কোর পায়নি — এটিই সাংঘর্ষিক অ্যাট্রিবিউটের প্যাটার্ন বাস্তব সংখ্যায় প্রমাণিত।
মূল কথা · Key takeaway

কোয়ালিটি অ্যাট্রিবিউট সিস্টেমের "কী করে" নয়, "কতটা ভালো করে" তা বর্ণনা করে। ছয়টি মূল অ্যাট্রিবিউট — Correctness, Reliability, Usability, Maintainability, Efficiency, Portability — এই কোর্সের বাকি অংশে বারবার ফিরে আসবে। এবং যেহেতু এগুলো প্রায়ই সাংঘর্ষিক, বাস্তব ইঞ্জিনিয়ারিং সিদ্ধান্ত মানে সচেতন ট্রেড-অফ — একটি "নিখুঁত" সমাধান খোঁজা নয়।

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

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

প্র ০১ একটি সিস্টেমের সব ফিচার সঠিকভাবে কাজ করলেও কি সেটি "ভালো সফটওয়্যার" বলা যায়?

অগত্যা না। সব ফিচার সঠিকভাবে কাজ করা (correctness) একটি প্রয়োজনীয় শর্ত, কিন্তু যথেষ্ট নয়। যদি সিস্টেমটি ব্যবহার করা কঠিন হয় (কম usability), মাঝে মাঝে ক্র্যাশ করে (কম reliability), বা প্রতিটি নতুন ফিচার যোগ করা এক সপ্তাহ লাগে (কম maintainability) — তাহলে ব্যবহারকারী ও ডেভেলপার উভয়ের জন্যই এটি বাস্তবে একটি দুর্বল সফটওয়্যার প্রোডাক্ট।

প্র ০২ একটি হাসপাতালের লাইফ-সাপোর্ট সিস্টেম আর একটি সাধারণ ব্লগ ওয়েবসাইট — এই দুটোর কোয়ালিটি অ্যাট্রিবিউট অগ্রাধিকার কীভাবে ভিন্ন হবে বলে আপনার মনে হয়?

লাইফ-সাপোর্ট সিস্টেমে reliability ও correctness প্রায় নিরঙ্কুশ অগ্রাধিকার পাবে — এমনকি ধীর গতি বা বেশি খরচ হলেও, কারণ ব্যর্থতার পরিণতি জীবন-মৃত্যুর প্রশ্ন। একটি সাধারণ ব্লগ ওয়েবসাইটে হয়তো efficiency ও দ্রুত ডেভেলপমেন্ট গতি (কম maintainability খরচেও) বেশি গুরুত্বপূর্ণ, কারণ একটি সাময়িক বাগ বা ডাউনটাইমের পরিণতি তুলনামূলকভাবে অনেক কম গুরুতর। এটিই দেখায় "সঠিক অগ্রাধিকার" নির্দিষ্ট সিস্টেমের প্রেক্ষাপটের উপর নির্ভরশীল।

প্র ০৩ উপরের কোড সেলে কোনো একক ডিজাইন সিদ্ধান্তই কেন সবগুলো অ্যাট্রিবিউটে সর্বোচ্চ স্কোর পায়নি?

কারণ ডেটাসেটটি ইচ্ছাকৃতভাবে এমনভাবে তৈরি করা হয়েছে যা বাস্তব সাংঘর্ষিক সম্পর্ক প্রতিফলিত করে — যে সিদ্ধান্ত efficiency-তে সর্বোচ্চ স্কোর পেয়েছে (অপ্টিমাইজেশনের কারণে) সেটিই কোডকে জটিল করে তুলেছে, ফলে maintainability কমেছে। এটি কোনো কাকতালীয় ব্যাপার নয় — বাস্তব সফটওয়্যার প্রজেক্টেও এই একই সম্পর্ক বারবার দেখা যায়, যে কারণেই এই পাঠের মূল প্রতিপাদ্য।

অনুশীলন

  1. চিন্তা করুন: আপনার ব্যবহৃত একটি অ্যাপ বা ওয়েবসাইটের কথা ভাবুন যা আপনার কাছে "ভালো" মনে হয় না। এটি কোন কোয়ালিটি অ্যাট্রিবিউটে দুর্বল বলে আপনার মনে হয় — reliability, usability, নাকি efficiency?

    সঠিক উত্তর ব্যক্তিভেদে ভিন্ন হবে, তবে ভালো একটি উত্তর নির্দিষ্ট একটি অ্যাট্রিবিউট চিহ্নিত করবে এবং কেন তা ব্যাখ্যা করবে — যেমন "অ্যাপটি প্রায়ই ক্র্যাশ করে" (reliability), "মেনু খুঁজে পাওয়া কঠিন" (usability), বা "স্ক্রিন লোড হতে অনেক সময় লাগে" (efficiency)। এই অনুশীলনের লক্ষ্য বিমূর্ত টার্মগুলোকে বাস্তব, পরিচিত অভিজ্ঞতার সাথে যুক্ত করা।

  2. পরীক্ষা করুন: উপরের কোড সেলে design_choices-এ একটি চতুর্থ এন্ট্রি যোগ করুন — যেমন "ন্যূনতম ডকুমেন্টেশন সহ দ্রুত লেখা কোড" — নিজের বিচারে যুক্তিসঙ্গত স্কোর দিয়ে, এবং Run চেপে দেখুন এটি সর্বোচ্চ efficiency বা maintainability-র হিসাব বদলায় কিনা।

    যদি নতুন এন্ট্রির maintainability স্কোর ৯-এর কম হয় (যা যুক্তিসঙ্গত, কারণ "ন্যূনতম ডকুমেন্টেশন" প্রায়ই কম maintainability বোঝায়), তাহলে best_maintainability অপরিবর্তিত থাকবে। কিন্তু যদি এর efficiency স্কোর ৯-এর বেশি হয়, তাহলে best_efficiency নতুন এন্ট্রিতে বদলে যাবে — দেখায় কীভাবে max() ফাংশনটি সত্যিকারভাবে ডেটার উপর ভিত্তি করে ফলাফল গণনা করে, হার্ডকোড করা নয়।

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

আগের পাঠ
সফটওয়্যার ক্রাইসিস ও কেন ইঞ্জিনিয়ারিং শৃঙ্খলা প্রয়োজন