2.11 সফটওয়্যারের গুণমান

পরিচিতি ও প্রেরণা

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

বড় দলে গুণমান একজন মানুষের মাথায় বা একটি দলের অভ্যাসে থাকতে পারে না। শত শত ইঞ্জিনিয়ার, একাধিক পণ্য ও দীর্ঘজীবী সিস্টেমের দরকার গুণমানের একটি ভাগ করা সংজ্ঞা, তা নিশ্চিত করার সুস্পষ্ট প্রক্রিয়া, এবং তা ভালো হচ্ছে না খারাপ হচ্ছে তা বলে দেওয়া মাপ। তা ছাড়া “গুণমান” একটি ঝাপসা আকাঙ্ক্ষা হয়ে সময়সীমার বিরুদ্ধে প্রতিটি তর্ক হারে, এবং ত্রুটি জমতে থাকে যতক্ষণ না পরিবর্তন ধীর ও ঝুঁকিপূর্ণ হয়।

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

মূল নীতিসমূহ

• গুণমান হলো উদ্দেশ্যের উপযুক্ততা ও প্রয়োজনীয়তার সঙ্গে সামঞ্জস্য; দুটিই সুস্পষ্টভাবে সংজ্ঞায়িত করুন।
• গুণমান গেঁথে দেওয়া হয়, টেস্ট করে আনা হয় না; যাচাই ত্রুটি খোঁজে, কিন্তু প্রতিরোধ তা এড়ায়।
• গুণমান নিশ্চয়তা (আমাদের প্রক্রিয়া কি সঠিক?) ও গুণমান নিয়ন্ত্রণ (এই পণ্য কি ভালো?) আলাদা করুন।
• যাচাইকরণ জিজ্ঞেস করে “আমরা কি ঠিকভাবে বানিয়েছি?”; বৈধকরণ জিজ্ঞেস করে “আমরা কি সঠিক জিনিস বানিয়েছি?”
• অল্প অর্থপূর্ণ মেট্রিক দিয়ে গুণমান মাপুন; মেট্রিককে সংকেত ভাবুন, লক্ষ্য নয়।
• ত্রুটি যত দেরিতে ধরা পড়ে তার খরচ তত বাড়ে, তাই গুণমানের কার্যকলাপ আরও আগে সরান।
• গুণমান সমগ্র প্রতিষ্ঠান ও তার সংস্কৃতির বৈশিষ্ট্য, শেষে একটি গেট নয়।

সুপারিশ

ISO/IEC 25010-এর মতো একটি ভাগ করা গুণমান মডেল গ্রহণ করুন

একটি স্বীকৃত পণ্য-গুণমান মডেল গ্রহণ করে আপনার প্রতিষ্ঠানকে গুণমানের একটি সাধারণ শব্দভাণ্ডার দিন। ISO/IEC 25010 কার্যকরী উপযুক্ততা, কার্যক্ষমতার দক্ষতা, সামঞ্জস্য, ব্যবহারযোগ্যতা, নির্ভরযোগ্যতা, নিরাপত্তা, রক্ষণাবেক্ষণযোগ্যতা ও বহনযোগ্যতাসহ বৈশিষ্ট্য সংজ্ঞায়িত করে। গুণমানকে সুনির্দিষ্ট করতে এটি ব্যবহার করুন: প্রতিটি সিস্টেমের জন্য ঠিক করুন কোন বৈশিষ্ট্য সবচেয়ে গুরুত্বপূর্ণ এবং প্রতিটির জন্য “যথেষ্ট ভালো” মানে কী। এই পণ্য-গুণমান বৈশিষ্ট্যগুলোই সেই গুণমান বৈশিষ্ট্য, যা স্থাপত্যকে চালায় (অধ্যায় 3.1)। গুণমান ও স্থাপত্য একটি উদ্বেগের দুটি দৃশ্য, তাই দুটি প্রতিদ্বন্দ্বী তালিকার বদলে একটি অগ্রাধিকার তালিকা ভাগ করুন।

গুণমান নিশ্চয়তা গুণমান নিয়ন্ত্রণ থেকে আলাদা করুন

গুণমান নিশ্চয়তা (QA) ও গুণমান নিয়ন্ত্রণ (QC) আলাদা কিন্তু পরিপূরক কার্যকলাপ হিসেবে দেখুন। QA প্রক্রিয়া-ভিত্তিক ও প্রতিরোধমূলক: মান, রিভিউ, “সম্পন্ন”-র সংজ্ঞা ও প্রশিক্ষণের মাধ্যমে কাজ যেভাবে হয় তা উন্নত করে, যাতে ত্রুটি প্রথমেই কম দেখা দেয়। QC পণ্য-ভিত্তিক ও অনুসন্ধানমূলক: টেস্টিং, কোড রিভিউ ও অডিটের মতো প্রকৃত কাজের সামগ্রী পরিদর্শন করে যে ত্রুটি ঢুকে গেছে তা ধরে। একটি পরিণত প্রতিষ্ঠান দুটিতেই বিনিয়োগ করে, কিন্তু QA-র দিকে ঝোঁকে, কারণ ত্রুটি প্রতিরোধ করা তা খুঁজে সারানোর চেয়ে সস্তা।

সুস্পষ্ট সফটওয়্যার গুণমান ব্যবস্থাপনা প্রক্রিয়া চালান

গুণমানকে নিঃশব্দ আশা নয়, পরিচালিত প্রক্রিয়া করুন। উল্লেখযোগ্য কাজের জন্য একটি গুণমান পরিকল্পনা লিখুন যা লক্ষ্য গুণমান বৈশিষ্ট্য, নিশ্চয়তা ও নিয়ন্ত্রণ কার্যকলাপ, গ্রহণযোগ্যতার মানদণ্ড এবং কে জবাবদিহিযোগ্য তা জানায়। এটি আপনার ইতিমধ্যে থাকা চর্চায় বুনে দিন: নিয়ন্ত্রণ ও জ্ঞান বিনিময় দুটিই হিসেবে কোড রিভিউ (অধ্যায় 2.5), স্বয়ংক্রিয় নিরাপত্তা-জাল হিসেবে টেস্টিং কৌশল (অধ্যায় 2.4), এবং নিরন্তর পরিদর্শন হিসেবে স্ট্যাটিক বিশ্লেষণ। গুণমানের তথ্য নিয়মিত পর্যালোচনা করুন এবং কেবল ঘটনায় প্রতিক্রিয়া না জানিয়ে প্রবণতার ওপর ব্যবস্থা নিন।

যাচাইকরণ ও বৈধকরণকে আলাদা শৃঙ্খলা হিসেবে চর্চা করুন

যাচাইকরণ নিশ্চিত করে কাজের সামগ্রী তাদের স্পেসিফিকেশন পূরণ করে, অর্থাৎ প্রতিটি ধাপের সঠিক ইনপুট সঠিক আউটপুট দেয়, রিভিউ, স্ট্যাটিক বিশ্লেষণ ও প্রয়োজনীয়তার বিপরীতে টেস্টিংয়ের মাধ্যমে। বৈধকরণ নিশ্চিত করে সমাপ্ত সিস্টেম আসলে ব্যবহারকারীর চাহিদা ও তার উদ্দিষ্ট ব্যবহার পূরণ করে, ব্যবহারকারী টেস্টিং, গ্রহণযোগ্যতা টেস্টিং, পাইলট ও মাঠ-ফিডব্যাকের মাধ্যমে। আপনার দুটিই লাগে। একটি সিস্টেম ত্রুটিপূর্ণ স্পেসিফিকেশনের বিপরীতে সঠিক হতে পারে (যাচাই করা কিন্তু বৈধ নয়), অথবা একটি প্রকৃত চাহিদা মেটাতে পারে অথচ ত্রুটি ধারণ করতে পারে (বৈধ কিন্তু যাচাই করা নয়)। নিয়ন্ত্রিত পরিবেশে ডেভেলপারদের থেকে আলাদা কোনো পক্ষের স্বাধীন যাচাইকরণ ও বৈধকরণ (IV&V) আবশ্যক হতে পারে।

অর্থপূর্ণ মেট্রিক দিয়ে গুণমান মাপুন

গুণমানের ফলাফল ও তার চালক প্রতিফলিত করা একটি ছোট মেট্রিকের সেট বেছে নিন এবং সময়ের সঙ্গে নজর রাখুন। কার্যকর মাপের মধ্যে আছে ত্রুটির ঘনত্ব, ত্রুটি পালিয়ে যাওয়ার হার (রিলিজের আগের বনাম প্রোডাকশনে পাওয়া ত্রুটি), শনাক্ত ও মেরামতের গড় সময়, পরিবর্তন-ব্যর্থতার হার, জটিলতা ও পুনরাবৃত্তির মতো কোড-স্বাস্থ্যের সংকেত, এবং ব্যবহারকারী-জানানো সমস্যা ও অভিগম্যতা মান্যতার মতো বৈধকরণ সংকেত। ভ্যানিটি ও কারসাজি-করা-যায় মেট্রিক এড়িয়ে চলুন: লক্ষ্য হয়ে যাওয়া মেট্রিক বাস্তবতা মাপা বন্ধ করে। সংখ্যাগুলোর সঙ্গে রিভিউ ও ব্যবহারকারী ফিডব্যাকের গুণগত সংকেত জুড়ুন।

ত্রুটি পদ্ধতিগতভাবে চিহ্নিত ও পরিচালনা করুন

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

গুণমানের খরচ সুচিন্তিতভাবে পরিচালনা করুন

ক্লাসিক শ্রেণির মাধ্যমে গুণমানের অর্থনীতি বুঝুন: প্রতিরোধ খরচ (প্রশিক্ষণ, মান, ভালো নকশা, টুলিং), মূল্যায়ন খরচ (রিভিউ, টেস্টিং, অডিট), এবং ব্যর্থতার খরচ (রিলিজের আগে অভ্যন্তরীণ পুনঃকাজ, সঙ্গে ব্যবহারকারীদের পাওয়া বাহ্যিক ব্যর্থতা, যার খরচ অনেক বেশি)। আপনার বিনিয়োগ প্রতিরোধ ও আগের মূল্যায়নের দিকে সরান, কারণ সেখানে প্রতিটি ডলার পরে ব্যর্থতার খরচের অনেক ডলার এড়ায়। এই খরচগুলো দৃশ্যমান করুন, যাতে “গুণমানের জন্য সময় নেই” যা তা-ই দেখা যায়: ব্যর্থতায় আরও বেশি খরচ করার একটি পছন্দ।

গুণমান সংস্কৃতি গড়ুন

গুণমানকে সবার দায়িত্ব করুন, সফটওয়্যার যে দলগুলো গড়ে তাদের মালিকানাধীন, শেষে পরিদর্শন করা কোনো নিম্নধারার QA বিভাগের হাতে তুলে না দিয়ে। নেতাদের গুণমানের ফলাফল পুরস্কৃত করা, ত্রুটি ও কাছাকাছি-ঘটনা জানানো নিরাপদ করা, এবং গুণমানের তথ্য লাঠি নয়, শেখার হাতিয়ার হিসেবে দেখা উচিত। ত্রুটির প্রতি দোষারোপহীন পদ্ধতি সমস্যা আগেই প্রকাশ্যে আনে। দোষারোপের পদ্ধতি তা লুকায় যতক্ষণ না সেগুলো ব্যয়বহুল হয়।

ট্রেড-অফ: সুবিধা ও অসুবিধা

চর্চা / পছন্দ	সুবিধা	অসুবিধা
আনুষ্ঠানিক গুণমান মডেল (ISO 25010)	ভাগ করা শব্দভাণ্ডার; সুস্পষ্ট অগ্রাধিকার	মতবাদীভাবে প্রয়োগ করলে বাড়তি বোঝা
ভারী গুণমান নিশ্চয়তা (প্রতিরোধ)	কম ত্রুটি; কম মোট খরচ	অগ্রিম বিনিয়োগ; প্রতিদান দেখাতে ধীর
ভারী গুণমান নিয়ন্ত্রণ (পরিদর্শন)	যে ত্রুটি পিছলে যায় তা ধরে	ব্যয়বহুল; ত্রুটি দেরিতে খোঁজে
স্বাধীন V&V	উচ্চ নিশ্চয়তা; বিষয়ীগত নয়	ব্যয়বহুল; ধীর; বিরোধপূর্ণ মনে হতে পারে
সমৃদ্ধ গুণমান মেট্রিক	দৃশ্যমানতা; আগাম সতর্কতা	কারসাজির ঝুঁকি; পরিমাপের বাড়তি বোঝা
নিবেদিত QA দল	মনোযোগ ও দক্ষতা	ডেভেলপারদের দায়িত্ব সরিয়ে দিতে পারে
দলের-মালিকানাধীন গুণমান	মালিকানা; দ্রুত ফিডব্যাক	সর্বত্র শৃঙ্খলা ও দক্ষতা লাগে

কেন্দ্রীয় ট্রেড-অফ বিনিয়োগ বনাম নিশ্চয়তা, সময় দ্বারা আকার-পাওয়া। প্রতিরোধ এখন অর্থ খরচ করে পরে বড় ব্যর্থতার খরচ এড়াতে। তাই গুণমানের অর্থনৈতিকভাবে সঠিক স্তর সর্বোচ্চ নয়; তা সেই বিন্দু যেখানে আরও নিশ্চয়তার প্রান্তিক খরচ তা যে ব্যর্থতার খরচ এড়ায় তার সমান। সেই বিন্দু নিরাপত্তা-সংকটপূর্ণ সিস্টেমে উঁচুতে, আর কম-ঝুঁকির অভ্যন্তরীণ টুলে নিচুতে। অন্য পুনরাবৃত্ত টানাপোড়েন মালিকানা। কেন্দ্রীয় QA গোষ্ঠী দক্ষতা গড়ে কিন্তু ডেভেলপারদের দায়িত্ব সরিয়ে দিতে পারে। দলের-মালিকানাধীন গুণমান মালিকানা গড়ে কিন্তু সর্বত্র দক্ষতা ও শৃঙ্খলা দাবি করে।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

2. আমাদের দলে কি ত্রুটি বা কাছাকাছি-ঘটনা জানানো নিরাপদ, এবং যিনি তা তোলেন তাঁর কী হয়? গুণমান সংস্কৃতির বৈশিষ্ট্য, আর দোষারোপহীন পদ্ধতি সমস্যা আগেই প্রকাশ্যে আনে যখন দোষারোপের পদ্ধতি তা লুকায় যতক্ষণ না সেগুলো ব্যয়বহুল হয়, যা নিয়ন্ত্রিত বা নাগরিকমুখী সিস্টেমে প্রকাশ্য ব্যর্থতা বা জরিমানা বোঝাতে পারে। বড় পরিসরে এটি সবচেয়ে বেশি গুরুত্বপূর্ণ, যেখানে ঝুঁকির সবচেয়ে কাছের ইঞ্জিনিয়ার প্রায়ই জুনিয়র এবং চুপ থাকার প্রণোদনা প্রবল। সৎ সংকেত আনুন: কাছাকাছি-ঘটনা কি লগ ও আলোচনা হয়, নাকি উধাও? পোস্টমর্টেম কারণের নাম দেয় নাকি মানুষের? পদক্ষেপ হলো গুণমানের তথ্যকে লাঠি নয়, শেখার হাতিয়ার করা, সমস্যা সামনে আনা মানুষদের পুরস্কৃত করা এবং দোষারোপহীন পোস্টমর্টেম চালানো, কারণ আপনার দল জানাতে ভয় পায় এমন কিছু আপনি প্রতিরোধ করতে পারেন না।

3. বৈধকরণ কি সত্যিই একটি রিলিজ থামাতে পারে, এবং সময়সীমা ঘনিয়ে এলে সেই কর্তৃত্ব কার? যাচাইকরণ (আমরা কি ঠিকভাবে বানিয়েছি?) ও বৈধকরণ (আমরা কি সঠিক জিনিস বানিয়েছি?) আলাদা শৃঙ্খলা, আর বৈধকরণের দাঁত থাকে কেবল তখন, যখন একটি ব্যর্থ অভিগম্যতা পরীক্ষা, ব্যর্থ গ্রহণযোগ্যতা টেস্ট বা ক্ষতিকর ব্যবহারকারী গবেষণা সত্যিই পাঠানো আটকাতে পারে। এন্টারপ্রাইজ ও সরকারি পরিবেশে এটি প্রায়ই বাধ্যতামূলক, কখনো ডেভেলপারদের থেকে আলাদা পক্ষের স্বাধীন যাচাইকরণ ও বৈধকরণের মাধ্যমে, এবং “আমরা তবু পাঠিয়েছি” এমন উত্তর যা তদারকি সংস্থা মানে না। আপনার শেষ কয়েকটি রিলিজ আনুন: কোনো গুণমান সংকেত কি কখনো সত্যিই একটি রিলিজ থামিয়েছে, নাকি গেট সবসময় তারিখের কাছে নতি স্বীকার করে? বৈধকরণ কখনো রিলিজ আটকে না থাকলে তা সাজসজ্জা, আর সমাধান হলো গুণমান পরিকল্পনায় আগেই গ্রহণযোগ্যতার মানদণ্ড লেখা, যাওয়া/না-যাওয়ার সিদ্ধান্তের মালিকের নাম দেওয়া এবং সরবরাহের চাপ থেকে স্বাধীন প্রকৃত কর্তৃত্ব সেই সিদ্ধান্তকে দেওয়া।

4. আমরা কি আমাদের দুর্বল গুণমানের খরচ আসলে জানি, এবং আমরা কি ব্যর্থতা থেকে প্রতিরোধের দিকে ব্যয় সুচিন্তিতভাবে সরাচ্ছি? দুর্বল গুণমানের খরচ (COPQ) হলো অভ্যন্তরীণ পুনঃকাজ, প্রোডাকশন ঘটনা, জরুরি সংশোধন, সাপোর্টের বোঝা, হারানো ব্যবহারকারী ও জরিমানায় হারানো অর্থ, এবং তা প্রায় সবসময় রিভিউ ও টেস্টিংয়ের দৃশ্যমান ব্যয়ের চেয়ে বড়। বড় দলে ব্যর্থতার খরচ ঘটনা চ্যানেল, সাপোর্ট সারি এবং পুনঃকাজ হিসেবে কেউ লগ করে না এমন কাজে ছড়ানো, ফলে কেউ যোগ না করা পর্যন্ত তা অদৃশ্য। টানাপোড়েন হলো প্রতিরোধ একটি বাজেট চক্রে এখন অর্থ খরচ করে সেই ব্যর্থতার খরচ এড়াতে যা পরে এবং অন্য কারও বাজেটে পড়ে, যা বিনিময়টি চিরকাল পিছিয়ে দেওয়া সহজ করে। প্রকৃত সংখ্যা আনুন: ঘটনার সংখ্যা ও খরচ, পুনঃকাজের ঘণ্টা, পালিয়ে-যাওয়া-ত্রুটির হার, এবং প্রতিরোধ, মূল্যায়ন ও ব্যর্থতায় ব্যয়ের বর্তমান ভাগ, তারপর ঠিক করুন মিশ্রণ আগের দিকে সরা উচিত কি না। যে এন্টারপ্রাইজ ও সরকারি সিস্টেমে জীবনকালের বেশিরভাগ খরচ প্রথম রিলিজের পরে পড়ে, সেখানে COPQ বাজেট ধরে রাখা মানুষদের সামনে আনুন, কারণ তদারকি সংস্থা দেখতে পারে এমন সংখ্যা “গুণমান”-এর অস্পষ্ট আবেদনের চেয়ে বিনিময় করা অনেক কঠিন।

5. আমাদের কোন গুণমান মেট্রিক নিঃশব্দে লক্ষ্য হয়ে গেছে, এবং তারা এখন কোন আচরণ চালাচ্ছে? লক্ষ্য হয়ে যাওয়া মেট্রিক বাস্তবতা মাপা বন্ধ করে: একটি আওতার শতাংশের পেছনে ছুটলে আপনি এমন টেস্ট পান যা ত্রুটি ধরতে নয়, সংখ্যা সরাতে লেখা। বড় পরিসরে এটি বিপজ্জনক, কারণ ডজন ডজন দলে ভাগ করা শিরোনাম ড্যাশবোর্ড তাদের সবার প্রণোদনা ঠিক করে, আর কারসাজি-করা-যায় মেট্রিক একসঙ্গে সর্বত্র কারসাজি ছড়ায়। প্রতিদ্বন্দ্বী বিবেচনা হলো আপনার তবু পরিমাপ দরকার, তাই উত্তর প্রায়ই “মেট্রিক ফেলে দিন” নয়, “এটি একটি পাল্টা-সংকেতের সঙ্গে জুড়ুন এবং রিভিউ ও ব্যবহারকারীদের গুণগত প্রমাণের পাশে পড়ুন”। আপনার বর্তমান মেট্রিকের সেট আনুন এবং প্রতিটির জন্য জিজ্ঞেস করুন চাপে থাকা কেউ গুণমান উন্নত না করেই তা সরাতে কী করতে পারত, এবং আপনি কি তা ঘটতে দেখেছেন। নিয়ন্ত্রিত ও নাগরিকমুখী পরিবেশে সেই সামঞ্জস্যের মেট্রিক সম্পর্কে বিশেষভাবে সতর্ক থাকুন যা সবুজ দেখায় অথচ নিচের বৈধকরণ (অভিগম্যতা, প্রকৃত ব্যবহারকারী ফলাফল) কখনো সত্যিই পরীক্ষা করা হয়নি, কারণ একজন নিরীক্ষক শেষ পর্যন্ত সংখ্যার পেছনের বাস্তবতা পরীক্ষা করবেন।

6. এখানে গুণমানের মালিক কে: যে দলগুলো কোড লেখে, নাকি শেষে একটি আলাদা গোষ্ঠী, এবং আমরা আসলে কাকে সম্পদ দিচ্ছি? মালিকানা পরবর্তী সবকিছু আকার দেয়, কারণ নিম্নধারার QA সাইলো ডেভেলপারদের নিজেদের লেখা কোডের দায়িত্ব সরিয়ে দিতে দেয়, আর দলের-মালিকানাধীন গুণমান প্রতিটি দলে দক্ষতা ও শৃঙ্খলা দাবি করার বিনিময়ে মালিকানা গড়ে। বড় দলে এটি এটা-বা-ওটা নয়: টেকসই ধরন সাধারণত কোড রিভিউ ও স্বয়ংক্রিয় টেস্টের মাধ্যমে গুণমানের মালিক দলগুলো, সহায়তা করে একটি ছোট কেন্দ্রীয় গোষ্ঠী যা মান রক্ষণাবেক্ষণ করে, প্রক্রিয়া উন্নতি হিসেবে গুণমান নিশ্চয়তা চালায় এবং কোচিং দেয়, শেষে গুণমান পরিদর্শন না করে। গুণমানের কাজ বর্তমানে কোথায় ঘটে, ত্রুটি পালিয়ে গেলে জবাবদিহি কার, এবং বাজেট ও লোকবল আসলে কোথায় বসে বনাম বক্তৃতা বলে গুণমান কোথায় বাস করে তার একটি সৎ মানচিত্র আনুন। এন্টারপ্রাইজ ও সরকারি প্রতিষ্ঠানের জন্য স্বাধীন যাচাইকরণ ও বৈধকরণের প্রয়োজন যোগ করুন: কিছু নিশ্চয়তা ব্যবস্থা আলাদা পক্ষ বাধ্যতামূলক করে, তাই সুচিন্তিতভাবে ঠিক করুন কোন নিয়ন্ত্রণ সরবরাহ দলের এবং কোনগুলো অডিট পূরণে স্বাধীন থাকতে হবে।

খাতভেদে দৃষ্টিভঙ্গি

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

ছোট ব্যবসা। কোনো নিবেদিত গুণমান বিশেষজ্ঞ নেই আর বাজেট কম, তাই আপনাকে চালাতে হবে এমন প্রক্রিয়ার বদলে আপনার কেনা টুল ও প্ল্যাটফর্মে ইতিমধ্যে গড়া গুণমানের ওপর ভরসা করুন। সফটওয়্যার বাছার সময় বিক্রেতার গুণমানের প্রমাণকে কেনার অংশ ভাবুন: নিরাপত্তার অবস্থান, অভিগম্যতা, সাপোর্টের দ্রুততা এবং তাদের রিলিজ কত ঘন ঘন ভাঙে। রক্ষণাবেক্ষণ করার লোক নেই এমন বিস্তৃত মেট্রিক কর্মসূচির বদলে মুষ্টিমেয় সস্তা, সৎ সংকেত অনুসরণ করুন (প্রোডাকশন ঘটনা, গ্রাহকের জানানো সমস্যা, সারানোর সময়)।

এন্টারপ্রাইজ। কাজ বহু দল জুড়ে সামঞ্জস্য: ISO/IEC 25010-এর মতো একটি ভাগ করা গুণমান মডেল গ্রহণ করুন, গুণমান নিশ্চয়তা (প্রক্রিয়া) ও গুণমান নিয়ন্ত্রণ (পণ্য) আলাদা করুন, এবং প্রতিরোধের দিকে ব্যয় সরানো গুণমানের খরচ পর্যালোচনা চালান। গুণমানের মালিক রাখুন সরবরাহ দলগুলোকে, সহায়তায় একটি ছোট কেন্দ্রীয় গোষ্ঠী যা মান এবং ত্রুটি পালিয়ে যাওয়ার হার, পরিবর্তন-ব্যর্থতার হার ও কোড-স্বাস্থ্যের প্রবণতার ড্যাশবোর্ড রক্ষণাবেক্ষণ করে। শব্দভাণ্ডার ও গেট প্রমিত করুন, যাতে গোষ্ঠীগুলো গুণমান চর্চা নতুন করে উদ্ভাবন বন্ধ করে, আর দলগুলোকে সেই মানদণ্ড নিজেদের পদ্ধতিতে পূরণের জায়গা দিন।

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

উদাহরণ

স্টার্টআপ। পাঁচজনের একটি স্টার্টআপ ঠিক করে তাদের প্রাথমিক পণ্যের জন্য নির্ভরযোগ্যতা ও রক্ষণাবেক্ষণযোগ্যতাই গুরুত্বপূর্ণ গুণমান বৈশিষ্ট্য, আর নিখুঁত-পিক্সেল পালিশ অপেক্ষা করতে দেয়। গুণমানের মালিক পুরো দল: কোড রিভিউ ও মাঝারি স্বয়ংক্রিয় টেস্ট স্যুট নিয়ন্ত্রণ, এবং ত্রুটি হস্তান্তর করার মতো আলাদা QA গোষ্ঠী নেই। একই শ্রেণির বাগ দুবার দেখা দিলে তারা দ্রুত মূল-কারণ দেখায় বিশ মিনিট ব্যয় করে এবং একটি ভাগ করা সহায়ক সঙ্গে একটি টেস্ট যোগ করে, তাই তা প্রতিবার হাতে সারার বদলে পুনরাবৃত্তি বন্ধ করে। প্রতিরোধের সেই ছোট অভ্যাস তাদের দ্রুত এগোনোর সময় পরিবর্তন-ব্যর্থতার হার কম রাখে।

এন্টারপ্রাইজ। একটি বড় আর্থিক-সেবা প্রতিষ্ঠান তার গুণমান শব্দভাণ্ডার হিসেবে ISO/IEC 25010 গ্রহণ করে এবং প্রতিটি পণ্যের জন্য নির্ভরযোগ্যতা, নিরাপত্তা ও রক্ষণাবেক্ষণযোগ্যতার লক্ষ্য স্তর লিপিবদ্ধ করে। দলগুলো গুণমানের মালিক: কোড রিভিউ ও স্বয়ংক্রিয় টেস্ট পাইপলাইনে নিয়ন্ত্রণ, আর একটি ছোট কেন্দ্রীয় গোষ্ঠী মান রক্ষণাবেক্ষণ ও কোচিং করে QA চালায়। একটি গুণমান ড্যাশবোর্ড ত্রুটি পালিয়ে যাওয়ার হার, পরিবর্তন-ব্যর্থতার হার ও কোড-স্বাস্থ্যের প্রবণতা অনুসরণ করে। ত্রুটি শ্রেণিবদ্ধ ও মূল-কারণ বিশ্লেষিত হয়, এবং পুনরাবৃত্ত কারণ ভাগ করা লাইব্রেরি ও চেকলিস্ট হালনাগাদ চালায়। নেতৃত্ব ত্রৈমাসিক গুণমানের খরচের তথ্য পর্যালোচনা করে এবং প্রতিরোধের দিকে ব্যয় সরিয়েছে, প্রোডাকশন ঘটনা ও তা সারানোর খরচ দুটিই কমিয়ে।

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

গুণমানের প্রতিদান হলো কম মালিকানার মোট খরচ এবং স্থির সরবরাহ গতি। গুণমানের খরচের দুটি দিক আছে। ভালো ব্যয়, প্রতিরোধ ও মূল্যায়ন, দৃশ্যমান ও নিয়ন্ত্রণযোগ্য: নকশা, মান, রিভিউ, টেস্টিং ও টুলিং। দুর্বল গুণমানের খরচ (COPQ) বড় কিন্তু প্রায়ই লুকানো: অভ্যন্তরীণ পুনঃকাজ, প্রোডাকশন ঘটনা, জরুরি সংশোধন, গ্রাহক সহায়তা, হারানো ব্যবহারকারী, নিয়ন্ত্রক জরিমানা ও সুনামের ক্ষতি। Crosby-র “Quality Is Free” পর্যন্ত ফিরে যাওয়া গবেষণা ধারাবাহিকভাবে পেয়েছে যে দুর্বল গুণমানের মোট খরচ তা প্রতিরোধের খরচকে বামন করে দেয়, এবং ত্রুটি যত দেরিতে ধরা পড়ে তত অনেক বেশি ব্যয়বহুল হয়: নকশায় পাওয়া একটি সমস্যার খরচ প্রোডাকশনে পাওয়া একই সমস্যার ভগ্নাংশ।

নেতৃত্বের জন্য যুক্তি “গুণমানে বেশি ব্যয় করুন” নয়। এটি “মোট কম ব্যয় করতে আগে ব্যয় করুন”। নিজের তথ্য থেকে COPQ পরিমাণযোগ্য করুন (ঘটনার সংখ্যা ও খরচ, পুনঃকাজের ঘণ্টা, পালিয়ে-যাওয়া-ত্রুটির হার) এবং দেখান কীভাবে প্রতিরোধ ও আগের মূল্যায়ন তা কমায়। গুণমানকে ব্যবসায়িক ফলাফলের সঙ্গে যুক্ত করুন: নির্ভরযোগ্যতা গ্রাহক ধরে রাখে, রক্ষণাবেক্ষণযোগ্যতা ভবিষ্যৎ পরিবর্তন সস্তা রাখে, এবং নিরাপত্তা ও অভিগম্যতা আপনাকে আইনি ঝামেলার বাইরে রাখে। দীর্ঘজীবী এন্টারপ্রাইজ ও সরকারি সিস্টেমে, যেখানে বেশিরভাগ খরচ প্রথম রিলিজের পরে পড়ে, সেখানে গুণমানের রক্ষণাবেক্ষণযোগ্যতা ও নির্ভরযোগ্যতার মাত্রা জীবনকালের খরচে প্রধান। তাই আগের গুণমান বিনিয়োগ আপনার নেওয়া সর্বোচ্চ-লিভারেজ সিদ্ধান্তগুলোর একটি।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• চূড়ান্ত গেট হিসেবে গুণমান: গুণমান গেঁথে দেওয়ার বদলে শেষে পরিদর্শন করে আনা, ফলে ত্রুটি সবচেয়ে ব্যয়বহুল সময়ে ধরা পড়ে।
• টেস্টিংকে গুণমানের সঙ্গে গুলিয়ে ফেলা: উত্তীর্ণ টেস্ট মানে উচ্চ গুণমান ধরে নেওয়া, রক্ষণাবেক্ষণযোগ্যতা, ব্যবহারযোগ্যতা ও উদ্দেশ্যের উপযুক্ততা উপেক্ষা করে।
• আলাদা সাইলো হিসেবে QA: একটি নিম্নধারার দল যে “গুণমানের মালিক”, ডেভেলপারদের নিজেদের লেখা কোডের দায়িত্ব সরিয়ে দিতে দেয়।
• মেট্রিক থিয়েটার: লক্ষ্য হিসেবে আওতার শতাংশ বা ত্রুটির সংখ্যার পেছনে ছোটা, যা কারসাজি আমন্ত্রণ করে এবং প্রকৃত গুণমান লুকায়।
• বৈধকরণ ছাড়া যাচাইকরণ: স্পেসিফিকেশন ঠিকভাবে গড়া, অথচ স্পেসিফিকেশন প্রকৃত চাহিদা মেটায় কি না কখনো যাচাই না করা।
• মূল-কারণ বিশ্লেষণ নেই: পদ্ধতিগত কারণ সম্বোধন না করে ত্রুটি আলাদা করে সারানো, ফলে একই শ্রেণি পুনরাবৃত্ত হয়।
• দুর্বল গুণমানের খরচ উপেক্ষা: গুণমানকে নিখাদ খরচ ভাবা কারণ ব্যর্থতার খরচ লুকানো ও অপরিমিত।

পরিপক্বতা মডেল

স্তর ১ (সূচনা)। গুণমান অসংজ্ঞায়িত ও তাৎক্ষণিক। এটি ব্যক্তিগত অধ্যবসায়ে চলে, বেশিরভাগ শেষে হাতে-করা টেস্টিংয়ে যাচাই হয়, এবং ত্রুটি প্রতিক্রিয়াশীলভাবে সামলানো হয় যখন দেখা দেয়। কোনো ভাগ করা মডেল নেই, কোনো মেট্রিক নেই, এবং নিশ্চয়তা ও নিয়ন্ত্রণের মধ্যে কোনো রেখা নেই।

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

স্তর ৩ (মানসম্মতকরণ)। প্রতিষ্ঠান একটি ভাগ করা গুণমান মডেল (যেমন ISO/IEC 25010) গ্রহণ করে, QA ও QC আলাদা করে, এবং গুণমান পরিকল্পনা ও গ্রহণযোগ্যতার মানদণ্ডসহ গুণমান ব্যবস্থাপনা প্রক্রিয়া চালায়, নথিবদ্ধ এবং দলগুলো জুড়ে সামঞ্জস্যপূর্ণভাবে প্রযুক্ত। যাচাইকরণ ও বৈধকরণ আলাদা ও সুচিন্তিত, এবং ত্রুটি একটি সম্মত পরিকল্পনা অনুযায়ী শ্রেণিবদ্ধ ও মূল-কারণ বিশ্লেষিত হয়।

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

স্তর ৫ (সমন্বয়)। গুণমান নিরন্তর উন্নত, সাংস্কৃতিকভাবে মালিকানাধীন শৃঙ্খলা, যা ব্যবসা ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত। প্রতিরোধই গুরুত্বের কেন্দ্র, গুণমানের খরচের তথ্য বিনিয়োগ কোথায় যায় তা পথ দেখায়, এবং মূল-কারণের পর্যবেক্ষণ পদ্ধতিগতভাবে পুনরাবৃত্তি ঠেকায়। দলগুলো শুরু থেকে শেষ পর্যন্ত গুণমানের মালিক, মেট্রিক নিরন্তর উন্নতিকে জোগান দেয়, এবং পণ্য, ঝুঁকি ও নিয়ন্ত্রণ সরলে প্রতিষ্ঠান তার গুণমান চর্চা খাপ খাইয়ে নেয়। এটি অধ্যায় 10.8-এর পরিপক্বতা মডেলের উচ্চতর স্তরের সঙ্গে সামঞ্জস্যপূর্ণ।

আলোচনার ভাবনা

• আপনার সিস্টেমের জন্য কোন ISO/IEC 25010 গুণমান বৈশিষ্ট্য সবচেয়ে গুরুত্বপূর্ণ, এবং প্রতিটির জন্য “যথেষ্ট ভালো” কী?
• প্রতিরোধ-মূল্যায়ন-ব্যর্থতা ব্যয়ের মিশ্রণে আপনার প্রতিষ্ঠান কোথায় আছে, এবং তা কি সরা উচিত?
• আপনি কি বাস্তবে যাচাইকরণকে বৈধকরণ থেকে আলাদা করেন, নাকি দুটিকেই “টেস্টিং”-এ ভেঙে ফেলেন?
• গুণমানের মালিক কি যে দলগুলো সফটওয়্যার গড়ে, নাকি আলাদা কোনো গোষ্ঠীকে দেওয়া, এবং তা সরালে কী বদলাবে?
• আপনার প্রকৃত দুর্বল-গুণমানের খরচ কত, এবং ব্যবসায়িক যুক্তি দাঁড় করানোর মতো যথেষ্ট ভালোভাবে কি তা মাপতে পারেন?
• আপনার কোন গুণমান মেট্রিক প্রকৃত সংকেত, আর কোনগুলো কারসাজি-করা-যায় লক্ষ্য হয়ে গেছে?

প্রধান শিক্ষা

• গুণমান টেস্টিংয়ের চেয়ে বিস্তৃত: এটি নির্ভরযোগ্যতা, নিরাপত্তা ও রক্ষণাবেক্ষণযোগ্যতার মতো বৈশিষ্ট্য জুড়ে উদ্দেশ্যের উপযুক্ততা ও সামঞ্জস্য।
• গুণমান বৈশিষ্ট্য সুস্পষ্ট এবং স্থাপত্যের (অধ্যায় 3.1) সঙ্গে সারিবদ্ধ করতে একটি ভাগ করা গুণমান মডেল (ISO/IEC 25010) ব্যবহার করুন।
• গুণমান নিশ্চয়তা (প্রতিরোধ, প্রক্রিয়া) ও গুণমান নিয়ন্ত্রণ (শনাক্তকরণ, পণ্য) আলাদা করুন, এবং প্রতিরোধের দিকে ঝুঁকুন।
• যাচাইকরণ (ঠিকভাবে বানিয়েছি) ও বৈধকরণ (সঠিক জিনিস বানিয়েছি) আলাদা শৃঙ্খলা হিসেবে চর্চা করুন।
• কয়েকটি অর্থপূর্ণ মেট্রিক দিয়ে গুণমান মাপুন, এবং পুনরাবৃত্তি ঠেকাতে ত্রুটি তীব্রতা ও মূল কারণ দিয়ে চিহ্নিত করুন।
• গুণমানের খরচ পরিচালনা করুন: প্রতিরোধ ও আগের মূল্যায়ন ব্যর্থতার চেয়ে অনেক সস্তা, বিশেষত দীর্ঘজীবী সিস্টেমে।
• একটি দোষারোপহীন গুণমান সংস্কৃতি গড়ুন যেখানে দলগুলো গুণমানের মালিক, কোড রিভিউ (অধ্যায় 2.5) ও টেস্টিং কৌশল (অধ্যায় 2.4) দ্বারা সমর্থিত।

তথ্যসূত্র ও আরও পড়ার জন্য

• IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), সফটওয়্যার গুণমান জ্ঞান-ক্ষেত্র।
• ISO/IEC 25010, Systems and software engineering: Systems and software Quality Requirements and Evaluation (SQuaRE): System and software quality models।
• ISO/IEC 25000 সিরিজ (SQuaRE), Software product quality requirements and evaluation।
• Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain।
• W. Edwards Deming, Out of the Crisis।
• Capers Jones ও Olivier Bonsignour, The Economics of Software Quality।
• Gerald Weinberg, Quality Software Management।
• ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (গুণমান নিশ্চয়তা ও V&V প্রক্রিয়ার প্রেক্ষাপট)।