I. সফ্টওয়্যার উন্নয়ন প্রক্রিয়া পরিপক্কতা
সফ্টওয়্যার মানের ভিত্তি উন্নয়ন প্রক্রিয়ার প্রমিতকরণের মধ্যে নিহিত। অটোমোটিভ স্পাইস ক্ষমতার স্তরগুলি বর্তমানে সফ্টওয়্যার প্রক্রিয়া পরিপক্কতার জন্য শিল্পের মাপকাঠি, কিন্তু CL2 বা CL3-এ পৌঁছানো শুধুমাত্র বেসলাইন। সফ্টওয়্যার সরবরাহের গুণমান যা সত্যই নির্ধারণ করে তা হল প্রক্রিয়া সম্পাদনের সময় বিচ্যুতির নিয়ন্ত্রণ। একটি উদাহরণ হিসাবে প্রয়োজনীয়তা ব্যবস্থাপনা গ্রহণ করে, একটি সাধারণ বিচ্যুতি হল যে একটি প্রয়োজনীয়তা পরিবর্তনের পরে, সংশ্লিষ্ট পরীক্ষার কেসগুলি সিঙ্ক্রোনাসভাবে আপডেট করা হয় না। একটি প্রকল্পে, SOP-এর পরে একটি OTA আপগ্রেড ফাংশন পাওয়া গেছে যেখানে একটি সমস্যা আছে যেখানে গাড়ির চার্জ কম থাকা অবস্থায়, OTA ডাউনলোডের কাজটি কোনো ত্রুটি রিপোর্ট না করেই অনির্দিষ্টকালের জন্য স্থগিত করা হবে। মূল কারণ ছিল যে প্রয়োজনীয় নথিতে চার্জ সুরক্ষা যুক্তির নিম্ন অবস্থা যুক্ত করা হয়েছিল, কিন্তু সংশ্লিষ্ট পরীক্ষার ক্ষেত্রে এখনও বাধা এবং পুনরুদ্ধারের পরিস্থিতি অন্তর্ভুক্ত না করে শুধুমাত্র ডাউনলোড ফাংশন যাচাইকরণকে কভার করে। সূচনা থেকে আবিষ্কার পর্যন্ত, এই ত্রুটিটি চারটি পুনরাবৃত্তিমূলক সংস্করণে বিস্তৃত ছিল এবং সংশোধনের খরচ যদি এটি প্রথম দিকে পাওয়া যেত তার চেয়ে প্রায় চল্লিশ গুণ বেশি। প্রয়োজনীয়তা ট্রেসেবিলিটি ম্যাট্রিক্স ক্রমাগত ইন্টিগ্রেশন পাইপলাইনে এমবেড করা প্রয়োজন। যখন একটি প্রয়োজনীয়তার স্থিতি পরিবর্তিত হয়ে যায়, তখন সংশ্লিষ্ট পরীক্ষার ক্ষেত্রে পর্যালোচনার কাজগুলি স্বয়ংক্রিয়ভাবে ট্রিগার করা উচিত এবং যে পরীক্ষাগুলি পর্যালোচনা পাস করেনি সেগুলিকে ব্লকিং আইটেম হিসাবে চিহ্নিত করা উচিত। কোড পর্যালোচনারও পরিমাপ করা দরকার। গবেষণা দেখায় যে কোডের প্রতি হাজার লাইনে দুইটিরও কম পর্যালোচনা মন্তব্য সহ মডিউলগুলির একটি পোস্ট-প্রতি হাজার লাইনে পাঁচটির বেশি মন্তব্য সহ মডিউলের চেয়ে তিন গুণ বেশি রিলিজ ত্রুটির ঘনত্ব রয়েছে৷ যাইহোক, পর্যালোচনা মন্তব্যের সংখ্যা একটি পরম সূচক হিসাবে ব্যবহার করা যাবে না কারণ নিম্নমানের মন্তব্যগুলিও বিদ্যমান। একটি কার্যকর পদ্ধতি হল পর্যালোচনা মন্তব্যগুলিকে পাঁচটি বিভাগে শ্রেণীবদ্ধ করা: যুক্তি ত্রুটি, অনুপস্থিত সীমানা শর্ত, কোড পঠনযোগ্যতা, কর্মক্ষমতা ঝুঁকি এবং নিরাপত্তা ঝুঁকি, দুটি মারাত্মক বিভাগের সনাক্তকরণ হারের উপর বিশেষ ফোকাস সহ: যুক্তি ত্রুটি এবং নিরাপত্তা ঝুঁকি।
২. ক্রমাগত ইন্টিগ্রেশন এবং ক্রমাগত পরীক্ষা
সফ্টওয়্যার পুনরাবৃত্তির ত্বরণের জন্য পরীক্ষাকে বামে স্থানান্তর করা প্রয়োজন, মানে কোড কমিট পর্যায়ে গুণমান যাচাইকরণ চালু করা হয়। ইউনিট টেস্টিং হল প্রতিরক্ষার সবচেয়ে বাম লাইন, কিন্তু প্রকৃত প্রকল্পগুলিতে, ইউনিট পরীক্ষার কোড কভারেজ প্রায়ই স্ফীত মান দ্বারা ভুগে থাকে। একটি নিয়ন্ত্রক প্রকল্পে, ইউনিট পরীক্ষার রিপোর্টে 92% এর লাইন কভারেজ দেখানো হয়েছে, কিন্তু ইন্টিগ্রেশন পরীক্ষার সময় এখনও অনেক মৌলিক ত্রুটি পাওয়া গেছে। পূর্ববর্তী বিশ্লেষণে প্রকাশ করা হয়েছে যে যদিও এই ত্রুটিগুলি সম্বলিত কোডের লাইনগুলি কার্যকর করা হয়েছিল, পরীক্ষার দাবিগুলি প্রাসঙ্গিক আউটপুটগুলি পরীক্ষা করেনি। লাইন কভারেজ শুধুমাত্র নির্দেশ করে যে কোডটি কার্যকর করা হয়েছে, আউটপুট যাচাই করা হয়নি। একটি উন্নতির পদ্ধতি হল মিউটেশন টেস্টিং চালু করা, যা পরীক্ষার ক্ষেত্রে কার্যকারিতা মূল্যায়ন করতে স্বয়ংক্রিয়ভাবে কোড মিউট্যান্ট তৈরি করে। যদি একটি মিউট্যান্টকে হত্যা করা না হয়, তবে এটি পরীক্ষার দাবিতে একটি ফাঁক নির্দেশ করে। ক্রমাগত ইন্টিগ্রেশন পাইপলাইনগুলির আরেকটি বেদনা বিন্দু হল অত্যধিক পরীক্ষা সম্পাদনের সময়। একটি OEM-এর সফ্টওয়্যার সংগ্রহস্থলে, সম্পূর্ণ রিগ্রেশন টেস্ট স্যুটটি চালানোর জন্য 20 ঘন্টারও বেশি সময় লাগে, যার অর্থ কোড জমা দেওয়ার পরে প্রতিক্রিয়া পাওয়ার জন্য বিকাশকারীদের প্রায়ই পরের দিন পর্যন্ত অপেক্ষা করতে হয়। সমাধানগুলির মধ্যে সমান্তরাল পরীক্ষা, পরীক্ষার ক্ষেত্রে অগ্রাধিকার, এবং ক্রমবর্ধমান পরীক্ষা অন্তর্ভুক্ত। সমান্তরাল টেস্টিং পরীক্ষার স্যুটটিকে একাধিক এক্সিকিউশন নোড জুড়ে বিভক্ত করে, এক্সিকিউশন সময়কে প্রায় এক-মূলের দশমাংশে কমিয়ে দেয়। টেস্ট কেস অগ্রাধিকার ঐতিহাসিক ত্রুটি বিতরণের উপর ভিত্তি করে, 20% পরীক্ষার ক্ষেত্রে অগ্রাধিকার দেয় যেগুলি নতুন ত্রুটি সনাক্ত করতে পারে। এই উপসেটটি নতুন ত্রুটির প্রায় 70% ক্যাপচার করতে পারে। ইনক্রিমেন্টাল টেস্টিং শুধুমাত্র বর্তমান কোড পরিবর্তনের সাথে সম্পর্কিত পরীক্ষার ক্ষেত্রে এক্সিকিউট করে, স্থির বিশ্লেষণ ব্যবহার করে পরিবর্তনের প্রভাবের সুযোগ সনাক্ত করে পরীক্ষা স্কোপকে গতিশীলভাবে ফিল্টার করতে।
III. সফ্টওয়্যার ত্রুটি পরিমাপ এবং মূল কারণ বিশ্লেষণ
সফ্টওয়্যার ত্রুটিগুলির জন্য পরিমাপ মেট্রিক্সকে হার্ডওয়্যার ত্রুটিগুলি থেকে আলাদাভাবে বিবেচনা করা দরকার। হার্ডওয়্যারের ত্রুটিগুলি সাধারণত ত্রুটির ঘনত্বের উপর ফোকাস করে, যেমন প্রতি মিলিয়ন অংশে ত্রুটির সংখ্যা। যাইহোক, সফ্টওয়্যার ত্রুটি বিতরণ প্যারেটো নীতি অনুসরণ করে, প্রায় 80% গুরুতর ত্রুটিগুলি 20% মডিউলগুলিতে কেন্দ্রীভূত হয়। অতএব, একটি আরও কার্যকরী মেট্রিক হল মডিউল-স্তরের ত্রুটি অভিসারী প্রবণতা, যার অর্থ পুনরাবৃত্তি জুড়ে প্রতিটি মডিউলের জন্য উন্মুক্ত ত্রুটির নেট পরিবর্তন। যদি একটি মডিউল পরপর তিনটি পুনরাবৃত্তির জন্য উন্মুক্ত ত্রুটিগুলির একটি নেট বৃদ্ধি দেখায়, তবে এটি একটি মৌলিক স্থাপত্য সমস্যা প্রস্তাব করে যার রিফ্যাক্টরিং পর্যালোচনার প্রয়োজন হয়। ত্রুটির মূল কারণ বিশ্লেষণের গভীরতা প্রতিরোধমূলক কর্মের কার্যকারিতা নির্ধারণ করে। একটি সাধারণভাবে ব্যবহৃত শ্রেণীবিভাগ ফ্রেমওয়ার্ক সফ্টওয়্যার ত্রুটির মূল কারণগুলিকে পাঁচটি প্রকারে শ্রেণীবদ্ধ করে: প্রয়োজনীয়তা বোঝার বিচ্যুতি, ডিজাইন লজিক ত্রুটি, কোডিং বাস্তবায়ন ত্রুটি, কনফিগারেশন পরিচালনার ভুল এবং পরিবেশগত নির্ভরতা পার্থক্য। সফ্টওয়্যার প্রকল্পগুলির জন্য কনফিগারেশন পরিচালনার ভুলগুলি একটি অনন্য বিভাগ। সাধারণ উদাহরণগুলির মধ্যে রয়েছে একটি মিডলওয়্যার লাইব্রেরির ভুল সংস্করণ ব্যবহার করা, অসংলগ্ন কম্পাইলার বিকল্প সেটিংস, এবং শাখা একত্রিত করার সময় গুরুত্বপূর্ণ সংশোধনগুলি অনুপস্থিত। একটি প্রকল্পে, একটি ব্রেক লাইট নিয়ন্ত্রণ লজিক ত্রুটি ডেলিভারির আগে পরীক্ষার চূড়ান্ত রাউন্ডের সময় আবিষ্কৃত হয়েছিল। ত্রুটিটি তিন মাস আগে একটি শাখা একত্রিতকরণে ফিরে পাওয়া গিয়েছিল, যেখানে বিকাশকারী ভুলভাবে প্রধান শাখা থেকে বৈশিষ্ট্য কোড মার্জ করার সময় ব্রেক লাইট নিয়ন্ত্রণ মডিউলে সমস্ত পরিবর্তন বাতিল করতে বেছে নিয়েছিলেন। এই কেসটি পরামর্শ দেয় যে শাখা একত্রিত হওয়ার পরে পার্থক্য তুলনা একটি বাধ্যতামূলক গেট হওয়া উচিত, একত্রিতকরণের অনুরোধগুলি পর্যালোচনা করার জন্য দায়ী মনোনীত কর্মীদের সাথে।
IV সফটওয়্যার রিকল এবং ওটিএ ম্যানেজমেন্ট
ওটিএ প্রযুক্তির ব্যাপকভাবে গ্রহণের সাথে, সফ্টওয়্যার ত্রুটিগুলি সংশোধন করার পদ্ধতি একটি মৌলিক পরিবর্তনের মধ্য দিয়ে যাচ্ছে। প্রথাগত সফ্টওয়্যার রিকলের জন্য ফ্ল্যাশিংয়ের জন্য পরিষেবা কেন্দ্রগুলিতে যানবাহনগুলি পরিদর্শন করা প্রয়োজন, যা ব্যয়বহুল, সময়{1}}সাপেক্ষ এবং কম ব্যবহারকারীর সম্মতিতে ভুগতে হয়৷ OTA প্রত্যাহার সরাসরি দূরবর্তী ধাক্কার মাধ্যমে সম্পন্ন করা যেতে পারে, তবে নিয়ন্ত্রক প্রয়োজনীয়তা