আমাদের অগ্রাধিকার এবং তীব্রতা উভয়ের কেন দরকার?


11

আমি বুঝতে পারছি তারা কী নির্ধারণ করে তবে প্রাপ্ত বিষয়গুলিতে এগুলি নির্ধারণ করা কি সত্যই কার্যকর? মানে, এটি হয় দ্রুত স্থির করা প্রয়োজন বা নাও।

আমি কীভাবে সেগুলি সেট করব, সেগুলি শ্রেণীবদ্ধ করব etc. আমি জানি আইইইই / আইএসওর জন্য এটি করা দরকার। আমি শুধু দেখছি না কেন।


হুম, আমি মনে করি যে ডেটা ক্ষতিগ্রস্থ করবে এমন একটি বাগটি কেবল বিরক্তিকর কিছু বলার চেয়ে আরও গুরুতর যা বলে যে কিছু কার্যকারিতা লোড হতে খুব বেশি সময় নেয়। উভয়ই স্থির করা উচিত তবে উচ্চতর নেতিবাচক প্রভাবযুক্তদের প্রথমে ঠিক করা উচিত।
Thorsten müller

না, আমি যেমন লিখেছি আমি জানি তারা কী বা কীভাবে সেট করা যায়। আমি কেবল এটিকে উপকার করতে চাই না।
পিট্রস


বেশিরভাগ ক্ষেত্রে, না। তবে সর্বদা প্রান্তের কেসগুলি রয়েছে যেখানে এটি দুটি পৃথক করার জন্য অর্থবোধ করে। এই সমস্যাগুলি কেবলমাত্র বিরল ইভেন্টগুলির জন্যই প্রতি ইস্যুটির জন্য বিচ্ছেদ বজায় রাখা উচিত কিনা তা অন্য বিষয়।
বিজিকলপ

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

উত্তর:


24

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


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

5
আমি মনে করি গুরুত্বপূর্ণ বিষয়টি হ'ল কেবল একটি পরিমাপ (অগ্রাধিকার) সরাসরি বিকাশের ক্রমকে নিয়ন্ত্রণ করে। একটি টিম ত্রুটিযুক্ত বর্ণনার অংশ হিসাবে অতিরিক্ত "তীব্রতা" খুঁজে পাওয়ার জন্য অত্যন্ত কার্যকর: এটি কিছুটিকে সহায়ক বলে মনে হতে পারে, @arnaud এর মত অন্যরা মনে করেন এটি "আমলাতন্ত্র" "- উভয় দৃষ্টিকোণই যুক্তিযুক্ত হতে পারে।
ডক ব্রাউন

4
উচ্চ অগ্রাধিকার, নিম্ন তীব্রতা: আপনার অ্যাপ্লিকেশনটির ল্যান্ডিং পৃষ্ঠাটিতে মাসে কয়েক মিলিয়ন ব্যবহারকারী দেখেন, আপনার সংস্থার নামে একটি টাইপ রয়েছে। নিম্ন অগ্রাধিকার, উচ্চ তীব্রতা: পরবর্তী সপ্তাহে অবসর নেওয়া এমন একটি অ্যাপ্লিকেশনটির জন্য প্রারম্ভকালে সিস্টেম 25% সময় ক্রাশ করে।
রোবট

2
তীব্রতা সাধারণত স্বয়ংক্রিয় এবং লাইভ পরীক্ষকগণ দ্বারা বিধি দ্বারা নির্ধারিত হতে পারে। অগ্রাধিকার কেবল ব্যবসায়িক দ্বারা বিষয়গতভাবে মূল্যায়ন করা যেতে পারে।
রোবট

3

তারিখ এবং সময় বাগ

বাগ: বছরের শেষ প্রসেসিং আপনার ডেটাবেসকে পুরোপুরি দূষিত করবে। এটি স্পষ্টত একটি গুরুতর বাগ।

তারিখ: ডিসেম্বর 15. বাগটি খুব উচ্চ অগ্রাধিকার।

তারিখ: ফেব্রুয়ারি 1. বাগ কম অগ্রাধিকার।


ক্ষেপণাস্ত্র বাগের দুর্ঘটনাক্রমে প্রবর্তন

বাগ: আইসিবিএম কন্ট্রোল সফ্টওয়্যার যখন ২৮ শে ফেব্রুয়ারি থেকে মার্চ মাসের মধ্যে ৪ বছরের ব্যবধানে বিভক্ত হয়ে যায়, তখন ফলাফলটি একটি অনাকাঙ্ক্ষিত লঞ্চ।

এটি প্রায় তীব্র ত্রুটি হিসাবে উপস্থিত থাকতে পারে। অগ্রাধিকার খুব কম, যদিও - শর্তটি ট্রিগার হওয়ার সাথে সাথে সফ্টওয়্যারটি ব্যবহারের কোনও বাস্তবসম্মত সুযোগ রয়েছে কি?


স্ক্রিনে অজানা 'খারাপ' শব্দ

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

দুর্ভাগ্যক্রমে, আগামীকাল আপনি এমন একটি উপস্থাপনা করছেন যেখানে বিক্রয় পাওয়াটা কোম্পানির জন্য মেক-অর-ব্রেক। আপনি "বব" নামে কারও কাছে উপস্থাপনা করছেন। তীব্রতা: খুব কম। অগ্রাধিকার: খুব উচ্চ।


আপনি উল্লিখিত 'ওভারফ্লো' এবং 'তারিখের সময়' সম্পর্কিত বাগগুলি সম্পর্কিত - আপনি চাঁদের বাগের পর্যায়টি

0

তুমি লিখেছিলে:

মানে, এটি হয় দ্রুত স্থির করা প্রয়োজন বা নাও।

ঐটা ঠিক. আপনি যদি বেশিরভাগ সংস্থার মতো হন তবে আপনার সংস্থান সীমাবদ্ধ। হয় আপনার কাছে সমস্ত সমস্যা সমাধানের জন্য পর্যাপ্ত লোক নেই বা আপনার কাছে পর্যাপ্ত সময় নেই।

একটি বাগটি হয় তাড়াতাড়ি দ্রুত স্থির করা দরকার বা না হওয়া এবং আপনার প্রচুর বাগ রয়েছে যা ঠিক করার দরকার রয়েছে তা প্রদত্ত কারণে, "অগ্রাধিকার" প্রশ্নের উত্তর দেয় "আমি প্রথমে কোনটি ঠিক করব"?

অন্যদিকে তীব্রতা হল এমন একটি সূচক যা ব্যক্তি অগ্রাধিকার সেট করে। বিকাশকারীর দৃষ্টিকোণ থেকে তীব্রতা একটি মোট পয়েন্ট। কাজের দায়িত্ব নির্ধারণের দিক থেকে, তীব্রতা তথ্যগুলির একটি গুরুত্বপূর্ণ অংশ যা সিদ্ধান্ত গ্রহণের প্রক্রিয়াতে সহায়তা করে।

অবশ্যই, এই সমস্ত খুব সাধারণ তথ্য। আপনি যদি অসম্ভব দীর্ঘ ব্যাকলগযুক্ত একটি দল হয়ে থাকেন তবে অগ্রাধিকার এবং তীব্রতার অর্থ আপনি যদি এমন একটি দলে থাকেন যা আপনার কাছে খালি খালি বাগ ডাটাবেস রয়েছে has

আপনি যদি এমন একটি দলের হয়ে থাকেন যেখানে "উচ্চ তীব্রতা == উচ্চ অগ্রাধিকার" এই বিষয়গুলির কোনওটাই না এবং আপনার উভয় মেট্রিকের প্রয়োজন নেই। দিনের শেষে, এগুলি কেবলমাত্র সরঞ্জাম। আপনার টিমগুলি সেগুলি কীভাবে ব্যবহার করবেন সে সিদ্ধান্ত নেওয়া দরকার। আপনার দলের জন্য এটি উভয় ব্যবহার করা বোধগম্য নয়।


0

আইএমএইচও, অগ্রাধিকার এবং তীব্রতা উভয়ই রাখা কেবল আমলাতন্ত্র।

অনুশীলনে, আপনার কেবল "গুরুত্ব" এর একটি পরিমাপ প্রয়োজন। প্রায়শই, এর জন্য অগ্রাধিকার ব্যবহৃত হয় এবং তীব্রতা তারপরে প্রযুক্তিগত শব্দ হিসাবে ব্যবহৃত হয় "হাই = ক্র্যাশ সিস্টেম বা এটি ব্যবহারযোগ্য নয়", "মাঝারি = বগি আচরণ, সম্ভাব্য ক্ষতিকারক", "নিম্ন = উপদ্রব, বিরক্তিকর কিন্তু ক্ষতিহীন"

সাধারণত, অগ্রাধিকার তীব্রতার সাথে এক সাথে যায়। কয়েকটি পাল্টা উদাহরণ হ'ল "উপদ্রব যেখানে সবাই সর্বদা অভিযোগ করে" বা "বিদেশী পরিবেশে একবার ক্র্যাশ ঘটেছিল"।

... তবে, শেষ পর্যন্ত, একজন বিকাশকারী (বা পরিচালক ইত্যাদি) হিসাবে আপনাকে কেবল ঠিক কীভাবে জিনিসগুলি ঠিক করতে / উন্নত করতে হবে তা জানতে হবে, এগুলিই। সুতরাং একটি পরিমাপ যথেষ্ট।

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

আমি এমনকি এটি ক্ষতিকারক বলে মনে করি কারণ এটি কী বাগটি বেশি গুরুত্বপূর্ণ তা কম স্পষ্ট করে তোলে:

  • কেউ কেউ ভাবেন যে "উচ্চ-অগ্রাধিকার" বাগের চেয়ে "সমালোচনামূলক" বাগের উচ্চ অগ্রাধিকার রয়েছে।
  • কিছু ব্যবহারকারী ত্রুটি রিপোর্টকারী তীব্রতা এবং অগ্রাধিকারকে বিভ্রান্ত করতে পারে
  • ... সামগ্রিকভাবে, এটি বাগগুলি কীভাবে মোকাবেলা করা উচিত তা নিয়ে বিভ্রান্তি যুক্ত করে

1
এবং ডেভেলপাররা কি একমাত্র লোকের জন্য গুরুত্বপূর্ণ?
বিজিকলপ

2
@ বিজিক্লপ নোপ, আপনি ঠিকই বলেছেন, এটি আমার একটি খারাপ গঠন ছিল। এটি সবার জন্য ধারণ করে: ম্যানেজার ইত্যাদির জন্য কী গুরুত্বপূর্ণ, প্রথমে যা ঠিক করা উচিত এবং কোনটি কম গুরুত্বপূর্ণ। তার জন্য, একটি পরিমাপ যথেষ্ট।
ডাগলিনিগুলি

1
ভাল, এটি ঝুঁকি ব্যবস্থাপনার দৃষ্টিকোণ থেকে ভুল - অগ্রাধিকার = তীব্রতা * ঘটনার হার। সামনের বয়সে টাইপো কি মারাত্মক সার্ভার ক্রাশের চেয়ে কম অগ্রাধিকারের হয় যা যদি ব্যবহারকারীর শেষ নাম 46 টি অক্ষরের বেশি হয়?
পিট্রস

1
@ পিট্রস: ভাল, আপনি এটি পিন করেছেন: কোনটি প্রথমে মোকাবেলা করা উচিত? নিম্ন অগ্রাধিকার সেভার ক্র্যাশ বা উচ্চ অগ্রাধিকারের উপদ্রব? আপনি কীভাবে অগ্রাধিকার দেবেন? কে এই রায় কল? সবাই তালিকার দিকে তাকিয়ে আছে? শুধুমাত্র একটি অগ্রাধিকারের পরিমাপ ব্যবহার করার সময়, এটি একবারে অগ্রাধিকার দেওয়া হয়, তারপরে এটি সম্পন্ন হয়। প্রভাব এবং তীব্রতা যেভাবেই হোক বাগ রিপোর্টে বর্ণিত হয়েছে।
ডাগলিনিগুলি

"তীব্রতা" সম্পর্কে জিনিসটি আপনি খুব সহজেই "ক্র্যাশ = উচ্চ, টাইপো = কম" বলতে পারেন। এটি উপলব্ধি করতে চিন্তিত হয় যে কোনও টাইপ যা হোমপৃষ্ঠায় 'কাউন্ট' শব্দের বাইরে 'ও' ছেড়ে যায়, পৃষ্ঠাটি একেবারে লোড করতে অস্বীকার করার চেয়ে ফিক্স করা বেশি অগ্রাধিকার।
রোবট

0

অন্যান্য উত্তরের পাশাপাশি, এই দৃশ্যটি বিবেচনা করুন: বাগ এটিকে ঠিক করতে 30 মিনিট সময় লাগবে এবং এর 'কম' তীব্রতা রয়েছে; বাগ বিটিকে 'উচ্চ' তীব্রতা ঠিক করতে 2+ সপ্তাহ সময় লাগতে পারে। তদ্ব্যতীত, ডি বি এবং সম্ভবত দলের বাইরে সম্ভবত বাগ বি অনেক আলোচনা এবং সমন্বয় নিতে পারে; বাগ এটিকে তত্ক্ষণাত একক দেব দ্বারা স্থির করা যেতে পারে। এটি বাগের উপর উচ্চ অগ্রাধিকার সেট করা পুরোপুরি ঠিক

অবশ্যই 'তীব্রতা' এবং 'অগ্রাধিকার' বিভিন্ন উপায়ে ব্যাখ্যা করা যেতে পারে।

একটি ছোট বাগ ট্র্যাকারে আমি নিজের ব্যবহারের জন্য তৈরি করেছিলাম পরিবর্তে আমি 'অসুবিধা' এবং 'অগ্রাধিকার' পছন্দ করতাম যেখানে উচ্চ তীব্রতার সমস্যাগুলি সর্বদা সর্বোচ্চ অগ্রাধিকার পায় এবং আমি অসুবিধার উপর ভিত্তি করে তাদের উপর কাজ করতে বিলম্ব করার সিদ্ধান্ত নিতে পারি।

'তীব্রতা' সম্পর্কে আমি যে জিনিসটি পছন্দ করি না তা হ'ল এটি কেবল বাগগুলিতে প্রয়োগ হয় এবং বৈশিষ্ট্যগুলি নয়। অগ্রাধিকার এবং অসুবিধা অনুসারে অর্ডার করা সমস্ত ইস্যুর একটি তালিকা থাকলে আরও ভাল হতে পারে যেহেতু 'আমি কী নিয়ে কাজ করব?' পরবর্তী সিদ্ধান্ত নেওয়া আরও সরাসরি সহায়ক।


0

আমি একটি সফ্টওয়্যার সংস্থায় প্রসেস ডিজাইন ও প্রয়োগ করেছি যা ISO9001: 2007 অনুমোদিত হয়েছে। 2007 থেকে স্ট্যান্ডার্ডে আপডেট হয়েছে তাই অতিরিক্ত প্রয়োজনীয়তা থাকতে পারে যা সম্পর্কে আমি অবগত নই ... তবে:

ISO9001 স্ট্যান্ডার্ডটি নিশ্চিত করা যায় যে পণ্য এবং প্রক্রিয়া ত্রুটিগুলি চিহ্নিত করার সময় আপনার সংস্থাটি প্রক্রিয়াগুলি উন্নত করার জন্য প্রতিক্রিয়ার লুপগুলি তৈরি করে এবং এমন প্রক্রিয়াগুলি প্রয়োগ করে।

নকশা পর্যায়ে প্রয়োজনীয়তাগুলি প্রস্তাবিত সমাধানটি সঠিকভাবে প্রয়োগ করা হলে আসলে ডিজাইনের সংক্ষিপ্ত (বৈধতা) সমাধান করে কিনা এবং বাস্তবায়নের ত্রুটি (যাচাইকরণ) ব্যতীত বাস্তবায়ন বাস্তবায়িত হয়েছে কিনা তা যাচাই করে on

প্রতিক্রিয়ার লুপে, যখন ত্রুটিগুলি চিহ্নিত করা হয়, এগুলি রেকর্ড করা যথেষ্ট নয়। ত্রুটির তীব্রতার জন্যও মূল্যায়ন করা দরকার এবং পুনর্নির্মাণকে অগ্রাধিকার দেওয়া হয়েছিল।

মূল অংশটি হ'ল আপনার নির্দিষ্ট সংস্থা কীভাবে তার তীব্রতা নির্ধারণ করার সিদ্ধান্ত নেয় এবং অগ্রাধিকার সম্পর্কে সিদ্ধান্তগুলি আইএসও মান দ্বারা সংজ্ঞায়িত হয় না। এটি সংস্থার সিদ্ধান্ত এবং নথির জন্য বাণিজ্যিক এবং প্রশাসনিক সমস্যা।

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

বাগের তীব্রতা কেবল একটি ডেটা পয়েন্ট। গ্রাহক প্রভাব আরেকটি ডেটা পয়েন্ট। এছাড়াও সংস্থাটির সিদ্ধান্ত গ্রহণের অন্তর্ভুক্ত করার সিদ্ধান্ত নিয়েছে, বয়সকে ত্রুটিযুক্ত করা, পণ্যটিতে বাণিজ্যিক জীবন বাকি থাকা এবং অন্য যে কোনও কারণের সিদ্ধান্ত নেওয়া হয়েছে। এটিকে "অগ্রাধিকার সিদ্ধান্ত নিতে পণ্য পরিচালকের কাছে উপস্থিত ত্রুটি" হিসাবে লেখা উচিত নয় কারণ এটি সিদ্ধান্ত নেওয়ার কর্তৃত্বকে কেবল সংজ্ঞায়িত করে এবং তারা সিদ্ধান্ত গ্রহণের জন্য যে প্রক্রিয়াটি অনুসরণ করে তা সংজ্ঞায়িত করে না।

আমার অগ্রাধিকারের জন্য একটি অগ্রাধিকার রয়েছে যা একটি উচ্চ হারকে ছোট এবং গুরুত্বপূর্ণ পরিবর্তনগুলি সরবরাহ করার দিকে পক্ষপাতদুষ্ট, কারণ এটি সামগ্রিক পণ্যের নির্ভরযোগ্যতার সেরা উত্সাহ সরবরাহ করে বলে মনে হয়। এর অর্থ হ'ল একটি গুরুতর ত্রুটি যা ঠিক করতে অনেক কাজ নেবে তার তফসিলের জন্য পর্যাপ্ত অগ্রাধিকার পেতে তার কাজটি ছোট ছোট খণ্ডে ভেঙে পড়তে হবে।


-3

অগ্রাধিকার এবং তীব্রতার সাথে দৃ strongly়ভাবে পৃথক হওয়ার কারণে:

একটি সহজ উদাহরণ। আপনার সংকীর্ণ স্থানটি কেসটি কল্পনা করুন যা আপনার সিস্টেমের স্কেলিং প্রতিরোধ করে - কিছু অ্যালগরিদমের জটিলতা O (N ^ 3) রয়েছে, যেখানে এন ক্লায়েন্টের স্টোরের গণনা। ক্লায়েন্ট বলছেন যে এটি পরের বছর 200 টি নতুন স্টোর খুলবে, এবং প্রয়োজনীয় গণনাগুলি (পণ্য বিতরণ, পরিবহন পরিকল্পনা ইত্যাদি) সময়মতো শেষ হবে না। তবে, বর্তমানে এই ক্লায়েন্টের কেবল 30 টি স্টোর রয়েছে এবং সংস্থানগুলি যথেষ্ট। এই অ্যালগরিদমকে (ও (এন ^ 2) বা আরও ভাল) অনুকূলকরণের কাজটি অবশ্যই গুরুত্বপূর্ণ (আপনি বাস্তবায়িত না হলে ক্লায়েন্টকে হারাবেন), তবে সম্ভবত জরুরি নয়: নতুন অ্যালগরিদম বাস্তবায়নের জন্য আপনার কাছে কয়েক মাস রয়েছে।

উদাহরণ 2: একটি অ্যাপ্লিকেশন পদ্ধতিগতভাবে ক্র্যাশ হয়েছে তবে আপগ্রেড বা স্থানান্তরিত হওয়ার কারণে এই সংস্করণটি কয়েক দিনের মধ্যে ব্যবহারের বাইরে চলে যায়। ফিক্সিং জরুরি, কারণ ক্র্যাশগুলি সত্যই ব্যবহারকারীর অভিজ্ঞতাকে প্রভাবিত করে, তবে এটির গুরুত্ব কম।

অবশ্যই, উভয় প্যারামিটারগুলি স্বল্প-মেয়াদী কাজের পরিকল্পনা তৈরি করতে কিছু মেট্রিক (প্রথাগত বা অনানুষ্ঠানিক) ব্যবহার করে একীভূত, কারণ পরেরটি একক-মাত্রিক (কার্যক্রমের ক্রম)। তবে দীর্ঘমেয়াদে তারা একীভূত হবে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.