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