تبليغاتX
Softwaring

Softwaring

Software Engineering, Process and Management

 

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

 

 

 

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

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

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

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

 

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

+ نوشته شده در  شنبه 29 تیر1387ساعت 16:35  توسط علی نوبر  | 

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

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

+ نوشته شده در  چهارشنبه 12 تیر1387ساعت 13:57  توسط علی نوبر  | 

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

 

                                               

 

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

+ نوشته شده در  پنجشنبه 6 تیر1387ساعت 11:55  توسط علی نوبر  | 

در باب رعایت امنیت سیستم های نرم افزاری جنبه های مختلفی وجود دارد که شاید یکی از جالبترین آنها که کمتر نیز به آن پرداخته میشود مبحث "مهندسی اجتماعی" یا Social Engineering باشد. طبق تعریف Wikipedia از Social Engineering: مهندسی اجتماعی، فن به کار گیری مردم برای افشای اطلاعات محرمانه است.

کلیه تکنیکهای مهندسی اجتماعی مبتنی بر ویژگیهای تصمیم گیری انسان است که تحت عنوان Cognitive Biasesبه معنی الگویی از انحراف در قضاوت که در موقعیتهای خاصی بروز میکند شناخته میشود. این تصمیم گیریهای غلط را گاهی "اشکال در سخت افزار انسان" گویند. جالب اینجاست که به قول Kevin Mitnick که یکی از مشهورترین متقلبین در این زمینه است: "این روش بسیار ساده تر از نفوذ به سیستم کاربران از راه روشهای متداول Hacking است".

برخی از این تکنیکها به شرح زیر است:

Pretexting: روشی است برای دریافت اطلاعات بر اساس سناریوی از پیش طرح شده ای که معمولا با مطالعه قبلی در مورد قربانی همراه است که این روش عموما از راه تلفن انجام میشود. امروزه به دلیل عدم توانایی ردیابی آسان سیستمهای VOIP، استفاده از این تکنیک آسانتر شده است.

Phishing: فریب قربانی با استفاده از تکنیک جازدن یک Web Page تقلبی که درست مانند مشابه واقعی آن ساخته شده و روی اینترنت قرار میگیرد. تنها کار لازم وادار کردن قربانی برای مشاهده صفحه غیر واقعی است و قربانی نیز به تصور اینکه وارد سایت اصلی شده اطلاعات محرمانه خود مانند اطلاعات کارت بانکی یا رمز عبور خود را وارد می­سازد. پس از آن وب سایت مزبور به سادگی یک پیغام خطا نمایش داده و کاربر را به سایت اصلی هدایت میکند، البته پس از ذخیره اطلاعات محرمانه وارد شده.

Road Apple: تکنیکی که با سواستفاده از کنجکاوی افراد آنها را قربانی مقاصد خود میسازند. در این روش معمولا یک مدیوم فیزیکی مانند یک CD یا Cool Disk با عنوانی اغوا کننده درج شده روی آن مانند "لیست حقوق مدیر عامل" را در سر راه افراد – مثلا در آسانسور یا راه پله – قرار میدهند. این مدیوم حاوی برنامه ای برای ارسال اطلاعات از روی دستگاه میزبان به هکر بوده که به راحتی توسط قربانی در سیستم شخصی خود قرار داده میشود.

این روزها با گسترش روشهای تراکنش الکترونیکی مالی نظیر Internet Payment، Mobile Payment و ... و عدم گسترش فرهنگ رعایت ملاحظات امنیتی آن انتظار میرود این روشهای سرقت اطلاعات بیش از پیش گسترش پیدا کند (به خاطر بیاوریم که هنگام دریافت پول از خودپردازها همیشه چندین جفت چشم مراقب هستند که خدای ناکرده در  فرآیند دریافت پول از دستگاه دچار اشتباه نشویم!)

+ نوشته شده در  شنبه 25 خرداد1387ساعت 17:12  توسط علی نوبر  | 

I don't think anybody yet has invented a pastime that's as much fun, or keeps you as young, as a good job. (Frederick Hudson Ecker, Chairman, Metropolitan Life)

+ نوشته شده در  پنجشنبه 23 خرداد1387ساعت 9:47  توسط علی نوبر  | 

 

اشکال تقسیم با ممیز شناور Intel Pentium (1994)

 

معادله زیر را در ماشین حساب PC خود وارد کنید:

 

(4195835 / 3145727) * 3145727 - 4195835

 

در صورتی که پاسخ صفر است پردازنده شما بدون عیب است. در صورتی که هر پاسخ دیگری مشاهده کردید، پردازنده دستگاه شما یک Intel Pentium  قدیمی است که در کلیه پردازنده های سری ساخت پردازنده شما تکرار شده است.

در 30 اکتبر 1994، دکتر Thomas R. Nicely  از کالج Lynchburg (ویرجینیا) در یکی از آزمایشات خود پاسخ غیر منتظره ای در تقسیم معادله مورد آزمایش بر روی Pentium PC خود مشاهده کرد. وی این کشف را بر روی اینترنت قرار داد و پی از آن خیل عظیمی از دیگر افرادی که در محاسبات خود به مشکل مشابه برخورد کرده بودند این مشکل را گزارش کردند. خوشبختانه این مشکل تنها در محاسبات پیچیده­ نمود پیدا می­کرد و بیشتر برنامه های محاسبه ای تجاری نظیر محاسبه مالیات و سود و زیان به چنین مشکلی برخورد نکرده بودند.

چیزی که این داستان را برجسته می سازد نه اشکال یاد شده، بلکه نحوه برخورد Intel با این مشکل بود:

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

·         هنگامی که این مشکل فاش گردید، Intel از طریق رسانه های جمعی سعی در کم اهمیت نشان دادن مشکل مزبور کرد.

·         شرکت Intel تحت فشار رسانه ها و افکار عمومی اعلام کرد که پردازنده های دارای مشکل را تعویض می کند اما به شرطی که دارنده آن بتواند ثابت کند که از این اشکال متاثر شده است.

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

در نهایت Intel از نحوه برخورد خود با این مشکل عذرخواهی کرده و متحمل هزینه ای بالغ بر 400 میلیون دلار برای تعویض پردازنده های معیوب خود گردید. در حال حاضر Intel کلیه مشکلات شناخته شده را بر روی وب سایت خود قرار می دهد و به دقت بازخورد مشتریان خود را در گروههای خبری اینترنتی دنبال می کند.

+ نوشته شده در  دوشنبه 20 خرداد1387ساعت 16:30  توسط علی نوبر  | 

When you reach for the stars, you may not quite get one, but you won't come up with a handful of mud either. (Leo Burnett, Chairman, Leo Burnett Co Inc)

+ نوشته شده در  شنبه 11 خرداد1387ساعت 17:15  توسط علی نوبر  | 

 

کاوشگر مریخ ناسا 1999 (NASA Mars Polar Lander - 1999)

 

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

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

یکی از مهترین مسائل در این فرآیند این است که کاوشگر تشخیص دهد که چه زمانی بر روی سطح مورد نظر فرود آمده تا به موقع موتور فرود خود را خاموش کند. برای این منظور ناسا که در دیگر سفینه های خود از رادارهای گرانقیمتی بهره برده بود تصمیم گرفت که برای کاهش هزینه ها، از مکانیزم ساده تری استفاده کند. به این شکل که در زیر سه پایه فرود کاوشگر سوییچ های تماسی (Contact Switch) تعبیه کردند تا به محض برخورد این سوییچ ها با سطح مریخ، یک بیت ست شده و در اثر قطع شدن سوخت، موتور فرود خاموش شود.

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

نتیجه فاجعه بار بود اما علت ساده. کاوشگر توسط تیم های مختلفی مورد آزمایش قرار گرفته بود که هر تیم مسئول تست بخشی از عملکرد کاوشگر بودند. یک تیم فرآیند باز شدن پایه ها را مورد آزمایش قرار داده بود و تیم دیگر فرآیند فرود را از زمان باز شدن پایه ها. تیم اول آزمایش نکرده بود که آیا بیت مورد نظر ست شده است یا خیر. تیم دوم نیز همواره کامپیوتر را Reset می کرده و بیت مورد نظر را به مقدار اولیه برمی گردانده و سپس آزمایش خود را به انجام می رسانده است.

هر دو تیم به طور مجزا کار خود را بدون نقص انجام داده بود اما اشکال مزبور تنها هنگامی بروز میکرد که دو تیم باهم ترکیب شوند  (Integration Test).

 

(منبع: Software Testing,Ron Patton, Sams Publishing, 2005)

+ نوشته شده در  پنجشنبه 9 خرداد1387ساعت 12:58  توسط علی نوبر  | 

You can't build a reputation on what you are going to do. (Henry Ford)

+ نوشته شده در  سه شنبه 7 خرداد1387ساعت 17:50  توسط علی نوبر  | 

شاید شما هم مثل من فکر کنید: تست نرم افزار حلقه مظلوم و مهجور فرآیند تولید نرم افزار است. بیشتر مدیران به آن علاقه ندارند چون هزینه زیادی می طلبد بدون آنکه خروجی قابل تحویلی به کارفرما داشته باشد و بیشتر برنامه نویسان از آن فراری هستند چرا که آنرا کاری تکراری و خسته کننده میدانند (در نوشته های آتی اشاره خواهم کرد که اساسا این کار نباید توسط مجری تولید نرم افزار انجام شود – البته به استثنای آزمون هایی معدود). هر چه اهمیت و گستردگی استفاده از نرم افزار بیشتر باشد، لزوم به کارگیری آزمونهای مختلف بیشتر احساس می شود. در این نوشته و نوشته های آینده به چند نمونه جالب (و البته دردناک) از اثرات مخرب آزمون ناکافی یا با رویکرد نادرست اشاره خواهم کرد:

 

نرم افزار بازی شیر شاه دیزنی (Disney’s Lion King Game)

در پاییز سال 1994 شرکت دیزنی اولین CD بازی خود تحت عنوان شیر شاه (Lion King) که بر اساس کارتونی به همین نام ساخته شده بود را وارد بازار کرد. بسیاری از شرکتهای دیگر تا آن زمان اقدام به ساخت بازیهای رایانه ای کرده بودند اما این اولین بار بود که شرکت دیزنی وارد این تجارت شده بود. دیزنی برای فروش این بازی دست به تبلیغات گسترده ای زد و در نتیجه این محصول با فروش بسیار بالایی مواجه شد. اما اتفاقات پس از آن تبدیل به کابوسی برای این شرکت شد. در 26 دسامبر، روز پس از کریسمس تلفن های بخش پشتیبانی مشتریان شرکت دیزنی شروع کرد به زنگ زدن و زنگ زدن و زنگ زدن! متصدیان پاسخگویی به تماس ها با خیل عظیمی از والدین عصبانی با بچه های گریان مواجه شدند که ادعا می کرند نرم افزار مزبور کار نمی کند. این خبر به سرعت در مطبوعات و تلویزیون نیز پخش شد و کریسمس آن سال را برای بسیاری از پرسنل دیزنی تلخ کرد.

علت چه بود؟ پس از بررسی مشخص شد که دیزنی نرم افزار خود را بر روی بسیاری از مدل های PC تست نکرده بود و در نتیجه تنها بر روی سیستمهایی کار می کرد که برنامه نویسان دیزنی روی آن سیستم ها نرم افزار خود را توسعه داده بودند و نه دستگاههای متداولی که عموم مردم از آن استفاده می کردند.

 

(منبع: Software Testing,Ron Patton, Sams Publishing, 2005)

 

 

+ نوشته شده در  سه شنبه 7 خرداد1387ساعت 17:20  توسط علی نوبر  |