Softwaring

دو مفهوم صحت و دقت در شکل زیر به خوبی به تصویر کشیده شده اند:

·         شکل پایین – چپ: شلیک ها نه صحیح و نه دقیق است. تیرها به شکل غیر مجتمع بوده و به مرکز هدف نیز نزدیک نیست.

·         شکل پایین – راست: شلیک ها صحیح است اما از دقت کافی برخوردار نیست.

·         شکل بالا – چپ: شلیک ها به شکل مجتمع و دقیق انجام شده اما با هدف فاصله دارد. لذا دارای دقت و فاقد صحت است.

·         شکل بالا – راست: شلیک ها هم از ویژگی دقت و هم صحت برخوردار است.

در آزمون نرم افزار، هر چند واضح است که یک آزمون دارای صحت و دقت ایده آل است، اما با توجه به هزینه بالای اجتماع این دو ویژگی، گاهی باید با توجه به ماهیت و نیازمندیهای نرم افزار، یکی از این دو مفهوم را به شکل کم  رنگ تر به کار گرفت.

نام ادوارد دمینگ (1993-1900) را احتمالا شنیده اید. برخی ادوارد دمینگ را "پدر علم مدیریت کیفیت" و برخی وی را با لقب "پدر مدیریت کیفیت ژاپن" می شناسند. ژاپنی ها به آقای ادوارد دمینگ احترام فراوان می کنند چرا که بخشی از پیشرفت کشور خود را مدیون او هستند. خلاصه فلسفه دمینگ در فرمول ساده زیر خلاصه می شود:

هنگامی که افراد و سازمانها بر کیفیت تمرکز کنند، کیفیت در طول زمان افزایش یافته و هزینه پایین می آید.

اما هنگامی که افراد و سازمانها بر هزینه تمرکز کنند (که عموما غالب بوده و رفتار معمول انسان اینگونه است)، در طول زمان هزینه ها (به علت غفلت از میزان کار انجام شده، عدم تلاش برای کمینه کردن ضایعات، عدم رفع سریع مناقشات، عدم توجه به پیشرفت محصول یا خدمت و همچنین از دست دادن وفاداری مشتری در طول زمان) افزایش پیدا کرده و کیفیت کاهش می یابد.

برای دستیابی به اهداف مطرح شده در این فلسفه، دمینگ 14 توصیه دارد که به برخی از آنها در زیر اشاره می شود:

-          ایجاد هدف باثبات در راستای پیشرفت محصول و خدمت با تمرکز بر رقابتی شدن، باقی ماندن در کسب و کار و کارآفرینی

-          عدم وابستگی به بازرسی و معاینه برای دستیابی به کیفیت و ایجاد کیفیت در محصول/خدمت در گام اول

-           عدم ارزش گذاری به محصول/خدمت بر اساس برچسب قیمت آن و در عوض آن تلاش برای کاهش قیمت تمام شده. حرکت به سمت یک تامین کننده به ازای هر جزء از سیستم بر مبنای ارتباط، وفاداری و اعتماد به تامین کنندگان

-          بهبود ثبات و پایداری تولید سیستم به منظور بهبود کیفیت و بهره وری و همچنین کاهش هزینه ها

-          ایجاد آموزش حین کار

-          برطرف کردن هراس به هدف کارایی بیشتر افراد در سازمان

-          شکستن موانع ارتباطی میان بخش ها و دپارتمان های مختلف سازمان و انجام کار به شکل تیمی

-          القای روح حرکت به سوی تغییر و دگرگونی در همه افراد سازمان و پذیرش تغییرات با آغوش باز

چندی پیش داشتم در مورد نحوه طراحی و تولید کالاهای مختلف فکر می کردم. در خطوط تولید جدید لوازم الکترونیکی مانند تلفن همراه کلیه قطعات روی یک سینی با رنگ مخالف چیده می شود در نتیجه مونتاژکاران هرگز قطعه ای را دیده نشده رد نمی کنند. کابلهای مختلف امروزه طوری طراحی می شود که در سوکت نادرست جای نگرفته و حتی بر خلاف جهت درست خود وارد نمی شوند. پرسهای صنعتی با فشار دو دکمه فعال می شود و در نتیجه احتمال قرار گرفتن دست کارگر در زیر آن وجود ندارد. قفل در اتوموبیل ها امروزه به شکلی است که دیگر امکان جاماندن سوئیچ داخل اتوموبیل وجود ندارد و صدها مثال دیگر که با اندکی دقت در اطراف می توان یافت.

هر چند ماهیت نرم افزار با دیگر انواع محصولات تاحدی متفاوت است (در جایی خواندم که اجرای ساختمان را به ساخت لگو و تولید نرم افزار را به درست کردن شکلی با خمیر بازی کودکان تعبیر کرده بود)، اما آیا می توان طراحی نرم افزار را طوری انجام داد که احتمال خطای کاربر به صفر برسد؟ آیا در سطح تولید نرم افزار می توان خط تولید را طوری طراحی کرد که احتمال خطای تیم توسعه منتفی گردد؟