مقدمه: در این نوشته، نگاهی خواهم داشت به بحث تغییر نگرش کیفیت در تولید نرم افزار.

اول: کیفیت نرم افزار: واژه ای که به عنوان هدف مهندسی نرم افزار بکار گرفته می شود و بخش عمده ای از تلاش های متخصصان و متدولوژیست ها، پیدا کردن روشها و ابزارهایی است که بوسیله آن بتوان نرم افزار خوب تری تولید کرد، به عبارت دیگر نرم افزار با پارامترهای کیفی بالاتر.

دوم : تفکر ژاپنی، تفکر چینی: اگر به تاریخ تجاری دنیا نگاهی از منظر کیفیت بیاندازیم، یک تغییر نگرش جالب مشاهده می شود. در ابتدا و پیش از انقلاب صنعتی و آغاز عصر جدید "کیفیت" نه تنها چیز گرانی بود بلکه فقط مخصوص یک طبقه بود، فقط اشراف حق داشتند از کیفیت استفاده کنند، در قرنهای بعد، کیفیت تبدیل شد به یک عامل رقابتی، تولید کنندگان سعی می کردند کالای بهتری تولید کنند تا سهم بیشتری از بازار داشته باشند و به تدریج این باعث شد که همه اقشار جامعه بتوانند به کالای خوب دسترسی پیدا کنند. ژاپنی ها از همین قضیه استفاده کردند و محصولات با کیفیت و در عین حال با قیمت مناسب تولید کردند که در بازار مشتری خوبی پیدا کرد و همین شد که ژاپن هم به جرگه کشورهای ثروتمند و قدرتمند در آمد. به مرور اما ورق برگشت. با افزایش ولع مردم برای خرید کالا و تبدیل شدن جوامع به جوامع مصرفی، کیفیت ارزش خود را از دست داد. مشتریان دوست داشتند زودتر کالای مدل جدید تری بخرند تا اینکه یک کالای قدیمی را که سالم هم باشد استفاده کنند. اینبار چینی ها برنده بودند. هدف را گذاشتند کالای ارزان، در عین حال متنوع اما بی کیفیت. فروش خوبی هم داشتند و دارند، چون آدم ها ترجیح می دادند زودتر خرید جدیدی داشته باشند و خراب شدن قبلی زیاد مهم نبود برایشان.

سوم. کیفیت نرم افزار، تفکر ژاپنی، تفکر چینی: آیا همین اتفاق(تغییر نگرش از تولید با کیفیت ولی گران و کند به تولید سریع و ارزان اما بی کیفیت) رایج شده است (از تفکر ژاپنی به چینی)؟
به نظر می رسد تغییر دید در متدولوژی ها و فرآیند های تولید نرم افزار همین را نشان می دهد. متدولوژی ها از نمونه سازی و الگو سازی و یا مبتنی بر مولقه تبدیل شده است به مدل های کرانه ای (XP) و چابک (Agile). در نگرش های قبلی با تحیلی مداوم ریسک، با ایجاد الگوها (Prototype) و تفکر معماری در نرم افزار در متدولوژی هایی نظیر RUP هدف ساخت یک نرم افزار خوب بود. اما حالا همه آنها را کنار گذاشته ایم و هدف را تولید سریع و ارزان نرم افزار قرار داده ایم. در Agile می گوییم در دوهفته اول باید یک تحویل محصول داشته باشیم، می گوییم نیاز مشتری را در همه زمانها گردن می گیریم. این یعنی نادیده گرفتن خیلی از پارمترهای کیفی.
واقعیت را هم ببینید شرکتهای بزرگ باعث شدند که کاربران مدام با سیستمهای سخت افزاری، سیستم عامل های جدید و پروتکل های شبکه متفاوت مواجه باشند. این عوض شدن مداوم بسترهای نرم افزاری و سخت افزاری باعث شده است، عمر نرم افزارها به شدت کاهش یابد و سازگاری نرم افزار های قدیمی با شرایط جدید از بین برود. از سوی دیگر هم ابزارهای توسعه نرم افزار و محیط های برنامه نویسی هم مداوم در حال تغییر و به روز رسانی هستند اینکار باعث می شود شرکتهای تولید کننده هم به خاطر کاهش هزینه های تولید و پشتیبانی، به صورت پیوسته نرم افزارهای تولید شده خود را ارتقاء دهند. عامل دیگر هم گسترش کاربرد نرم افزارهاست. دیگر خریداران نرم افزار یک گروه از شرکتهای بزرگ و سازمانها نیستند. نرم افزارها در سطح شرکتهای کوچک، مغازه ها و خانه ها گسترش عجیبی پیدا کرده است، به همین دلیل حس نو خواهی کاربران عام هم در تولید تاثیر گذاشته است.
بدین ترتیب است که به نظر من امروز دیگر کیفیت مانند قبل ارزش ندارد. مهم آن است که سریعتر و ارزان تر بسازی، در نهایت مشتری خیلی سریع نیازش تغییر می کند و باز می خواهد خرید جدیدی داشته باشد، پس بحث های معماری و کنترل کیفی گران قیمت دیگر جایگاه ندارد.
لازم می دانم این نکته را ذکر کنم که این استدلال جنبه عمومی دارد. هنوز مشتریان مهمی هستند که به خاطر سیستمهای حیاتیشان پول کیفیت را بپردازند، بانک ها، سازمانهای بزرگ و .... هنور مشتری سیستم گرانتر اما با کیفیت تر هستند.
با این قضایا، تولید کنندگان ایرانی نرم افزار چه راهکاری را باید انتخاب کنند تا در شرایط جدید بازار دوام داشته باشند؟ به این مطلب در آینده خواهم پرداخت
همین

در همشهری امروز (27 آذر) خواندم که هیچ کدام -دقت کنید: هیچکدام- از دانشگاه های کشور در بین 2000 دانشگاه اول دنیا -دقت شود: دو هزار تای اول - وجود ندارد(*). مبارک است!
کاش به اندازه ای که جایگاه ایران در رنکینگ فیفا برایمان مهم است، به اندازه ای که تعداد مدال های بازیهای آسیایی دوحه مهم بود، به اندازه ای که جایگاهمان در صدر فهرست اخبار سیاسی دنیا مهم بود، فکری هم به حال دانشگاه هایمان می کردیم.
خبر را که خواندم پیش خودم فکر کردم، وای بر ما، این جایی که در آن درس می خوانیم و یا می دهیم ، گویا دانشگاه نیست، فقط یک اسم یدک می کشد. پس واقعا دانشگاه چیست؟
دلم برای خودمان می سوزد.

همین!

(*) این خبر اعلام رسمی دبیر کل یونسکو در ایران است .مرجعش هم اطلس جهانی رتبه بندی دانشگاه های دنیا .

در این چند ساله، آدمهایی که می شناسمشان مدام از من می پرسند، چرا هم دانشگاه، هم شرکت؟ بهتر نیست یکی را انتخاب کنی. آدمهای آکادمیک پیشنهاد می کنند به صنعت و تجارت بچسبم و برعکس آدمهای کاری و با سابقه تجاری، دانشگاه را پیشنهاد می کنند، هر کس شغل دیگری را. عجب رسم عجیبی است!
شاید بیشترین کسی که این سوال را از من می پرسد، خودم باشم! مدام از خودم می پرسم که بالاخره چی؟ دانشگاه یا شرکت؟ یکی را انتخاب کن.اما واقعا نمی شود. هر دو را به شکلی دوست دارم و جدا شدن از آنها برایم سخت است.
اما باید یک اعتراف بکنم، هر چند به پای شرکت، زحمت های زیادی کشیده ام و کشیده ایم، دانشگاه برایم چیز دیگر است. می دانم که شاید که نه، حتما، از نظر اقتصادی به هیچ عنوان نمی تواند جای شرکت را بگیرد. اما باز هم سخت است که بپذیرم که بدون آن زندگی کنم. تدریس هر چقدر هم سخت باشد، لذت خودش را دارد برای من.

این روزها به دلیل شلوغی بیش از حد سرم، واقعا درگیر آن هستم که باید یکی را انتخاب کنم. یا شرکت را و یا دانشگاه را. اینطوری نمی شود. خدا را شکر که دیگر فولچارت[!] نیستم و واقعیتش را بخواهید بدانید آن است که تصمیم خودم دومی است. ترجیح می دهم پول کمتری داشته باشم اما در فضای دانشگاه نفس بکشم، شاید مدرس بودنم هم بیشتر به خاطر این است که فعلا نمی توانم دانشجو باشم. مطمئن هستم که اگر با رفع مشکلات فعلیم، بتوانم دانشجو باشم، هم تدریس را و هم کار را رها کنم.
هیچ چیز لذت درس خواندن، مساله حل کردن، امتحان دادن، سر کلاس استاد یواشکی چرت زدن، جزوه کپی کردن های شب امتحان،بی خوابی های زمان پروژه، رقابت های سالم و ناسالم، دودره کردن درس های عمومی، لذت کلاسهای مهندس پوروطن، آقای روحانی، دکتر ناظمی، دکتر رستم آبادی، دکتر رضوی زاده و ... را نمی گیرد. کاش می شد باز شاگرد مهندس پوروطن باشم و آخر ترم پروژه ای به من بدهد که گریه ام را در آورد. کاش می شد باز با رضا فرید یا اشکان اعظمی به خاطر پروژه شب تا صبح نخوابیم. نمی دانم وقتی برای نرم افزاری پول می گیرم، چرا لذت پروژه آخر ترم را به من نمی دهد. حیف دارند صندلی های دانشکده را عوض می کنند، چه حسی داشت نشستن روی این صندلی های گروهی درب و داغان.
نوشته ام خیلی نوستالژیک شد! واقعا علم بهتر است با ثروت باشد! اما اگر نشد، علم خشک و خالی هم بدک نیست.

همین!

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

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

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

- سطح عملیاتی: در این سطح ، معیارها و اندازه گیری ها مرتبط می شود با سنجش عملکرد پرسنل، تعریف معیارهای کیفی برای فرآیند کاری و محصول، سنجش رضایت مندی مشتری (Customer Satisfaction) ، معیار های فعالیت های شخصی و فرم های ارزشیابی تکریم ارباب رجوع و ....
-سطح مدیران میانی: در این سطح که به برنامه های کوتاه مدت سازمان بر می گردد، تدوین معیارهایی که روند حرکت جاری سازمان را مشخص سازد اهمیت ویژه ای دارد.علاوه بر معیارهای فوق، معیارهایی برای کنترل پروژه، سنجش بهره وری، معیارهای مبتنی بر رعایت استانداردهای ISO و سایر استانداردهای مشابه در کنترل کیفی، معیارها و شاخص های مالی ، تدوین نیازسنجی آموزشی و تعریف معیار های مرتبط با آن در پرسنل و .... از جمله معیارهای این گروه می باشد.
- سطح مدیران ارشد: طبیعتا معیارهای این بخش بر خلاف معیارهای قبل که نقش تاکتیکی دارد، نقش استراتژیک و راهبردی پیدا می کند. معیارهایی برای سنجش کارایی عمومی سازمان، Cashflow ، معیارهای مقایسه ای برای سازمانها باهم ، دوره های مختلف باهم و یا ... ، معیارهای اندازه گیری حرکت سازمان به سمت آرمانها و اهداف کلی سازمان، شاخص های استراتژیک ، سود و زیان و .... معیارهایی است که در این بخش تعریف می شوند.

فارغ از این سطح بندی، مدل هایی وجود دارد که با بهره گیری از آن می توان کلیت سازمان را در همه سطوح و یا در سطوح مشحصی مدل سازی نموده و با تعریف معیارهای کمی، پارامترهای کیفی سازمان را بهبود بخشید.
مدلهایی نظیر TQM ، EFQM و یا BSC از اینجمله اند. مدلهایی که بسیار کاربرد دارند و فارغ از جنبه تخصصی هر سازمان، عمومیت دارند. از سوی دیگر مدل هایی نظیر PAEM نیز که یک مدل داخلی است قابل تعریف است.
دقت کنید که همانگونه که در اصول اندازه گیری گفتیم، یک معیار منفرد برای اندازه گیری یک چیز نداریم و مدلهای فوق هر یک از جنبه های مختلف، معیارهایی را تعریف و اندازه گیری می کنند.
در نوشته های بعدی برخی از این مدل ها را معرفی می کنم...
همین!

آقای گودمن در کتاب خود، 6 اصل را برای اندازه گیری-خصوصا در مورد معیارهای نرم افزار- نام برده است که ذکر آن در ادامه سلسه مطالب اندازه گيری خالی از فایده نیست.

اصول اندازه گیری:
1- مصالحه و مصلحت گرایی (Pragmatism & compromise) :  تعیین دقیق محدوده اندازه گیری، نه کم (عدم دقت) و نه زیاد (اثر مخرب)
2-اندازه گیری آدم ها، هرگز! (!Measuring Peaple-Dont) : اندازه گیری افراد باعث کاهش بهره وری و ایجاد تفرقه می شود.

3-مدل سازی= ساده سازی (Modeling=Simplification) : یک معیار برای اندازه گیری همه چیز وجود ندارد. پس باید مدل سازی کرد و معیار های مختلف را روی آن تعریف کرد. در سطح ساده سازی باید دقت کرد.
4- نپرسید برای چه کسی، به پرسید چرا؟ (Ask not for whom the bell tolls ask Why) : اندازه گیری زمانی خوب است که بعد از آن با جمع آوری اطلاعات دیگر تحلیلش کنیم و دلایل را بفهمیم.
5-مجموع کل بزرگتر از هر جزء است. (The sum of whole is greater than the constituent parts) : کنارهم گذاشتن چند معیار اندازه گیری (تشکیل یک نمایشگر)، اطلاعات بیشتری از مشاهده تک تک معیار ها به ما می دهد.
6-شک فرهنگی (Culture Shock) : اندازه گیری معیارها باعث تغییر در رفتار و کار آدمها می شود.
برای کسب اطلاعات بیشتر مراجعه کنید به

Goodman,Paul, "Software Metrics: Best Pracices for Successfull IT Management",Rothstein Associates,2004

ادامه دارد ....
همین!

خبر: سرعت اینترنت کشور باز هم کاهش یافت.
دلیل اعلام شده: یکی از کابلهای اتصالی از بندر جاسک به کشورهای عربی قطع شده است! پس همه پهنای باند به خطوط دیگر منتقل شده است و در نتیجه سرعت ..... معلوم است!
سابقه: هر وثت یک مشکلی برای اینترنت کشور پیش می آید، از زبان مسؤولان ، تازه چند روز بعد از بروز واقعه، می شنویم که این خط زیر دریا قطع شده است، یک بار لنگر کشتی، یک بار توفان یک بار نمی دانم شاید اره ماهی[!] باعث پاره شدن این فیبر نوری می شوند و حداقل یک هفته ای سرعت اینترنت مورچه وار می شود.
یک نظر شخصی: نمی دانم کشور های دیگر هم این مشکل را دارند که که کابل های ارتباطی زیردریایشان مدام قطع می شود، یا این فقط مختص ماست!؟ نمی دانم دوستان مخابراتی ، توجیه دیگری نمی توانند بیاورند یا نه!؟ نمی دانم این خلیج فارس و دریای عمان فقط با ما مشکل دارد یا نه!؟ نمی دانم این بادی که می وزد فقط برای ماست یا برای بقیه هم هست!؟ همه اینها را نمی دانم، فقط کاش عزیزان مسؤول یا فکری برای محکم کردن کابل ها می کردند که تند تند، با یک لنگر کشتی پاره نشود و یا دنبال توجیه دیگری می گشتند، این یکی دیگر خیلی تکراری شده است. اگر مشکل نرم افزاری، سخت افزاری و یا کاربری دیگری پیش آمده گناهش را گردن دریا نیاندازند.

دریا موجه... کاکا ..... دریا موجه! (با لهجه بندری بخوانید!)

همین! 

Software Metrics

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

اما بعد ...

معیارهای نرم افزار (Software Metrics)  را می توان چنین تعریف کرد: "کاربردی پیوسته از تکنیک های اندازه گیری در فرآیند توسعه نرم افزار در فراهم کردن به موقع اطلاعات مدیریتی معنادار به همراه بکارگیری این تکنیک ها در بهبود فرآیند و محصولاتش"

با این تعریف محدوده کاربردی معیارهای نرم افزار ترسیم می شود:

- تخمین اندازه و هزینه (مهمترین کاربرد) در ابتدای پروژه و بعد از آن با بهره گیری از مدل های مطرحی نظیر cocomo و .... که نتیجه آن فراهم کردن امکانات کنترل پروژه، عقد قراردادها ، همکاری ها و همچنین Outsourcing می شود.
-تعیین سطح کیفی نرم افزارها
- اندازه گیری مقداری در طراحی نرم افزار
-تاثیر مسائل محیطی در فرآیند توسعه
- توجه کردن به تغییرات
-مقایسه دو سازمان تولید کننده با یکدیگر (برای مثال benchmarking )
-مدیریت اصلاحات : افزایش بهره وری، کارائی و اثربخشی فعالیت ها

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

در مورد هر کدام از این موارد می توان نمایشگر ها یا شاخص هایی تعیین نمود تا دیدگاهی مناسب برای هر محدوه تعیین نمایند. این دیدگاه می تواند در تصمیم گیری های مدیران پروژه نرم افزاری مؤثر باشند. اما باید در اندازه گیری اصولی را رعایت کرد...
به این اصول در مطالب بعد اشاره خواهم کرد.
همین!

چند واژه یا اصطلاح است که قبل از ورود به بحث اصلی اندازه گیری نرم افزار و سازمانها بایستی تعریف شوند:
-اندازه یا سنجه ، Measure : یک نمایشگر یا شاخص کمی برای یک اندازه ، مقدار، سایز ، حجم یا .... به که به صورت عددی در یک واحد خاص نمایش داده می شود.
-اندازه گیری، Measurement : فرآیند تشخیص یک اندازه
-معیار، Metric:  یک اندازه کمی برای نمایش درجه دارا بودن یک صفت برای یک سیستم، مؤلفه یا پردازش
-نمایشگر یا شاخص، Indicator : یک یا ترکیبی از چند معیار که با یک دیگر یک دیدگاه از یک فرآیند، پروژه، نرم افزار، محصول و .... را ایجاد می کنند.
-میانگین وزنی: ترکیبی از معیارهای مختلف با درنظر گرفتن ضرایب خاص هر کدام که نسبت تاثیر آن معیار را در میانگین وزنی بدست آمده روشن می کنند.

پرسمن (Roger S. Pressman ) در کتاب مهندسی نرم افزار خود، چهار دلیل برای اندازه گیری بیان می کند:
1- برای مشخص سازی (to Characterize) : برای فهم یک موضوع (فرآیند، محصول، منبع یا ... ) و ایجاد یک مبنا و پایه برای بررسی های بعدی
2- برای ارزیابی (to Evaluate) : تشخیص وضعیت جاری نسبت به برنامه ریزی ها و اندازه گیری های اولیه و تعیین میزان انحراف
3- برای پیش بینی (to Predict) : برای ایجاد امکان برنامه ریزی
4- برای بهبود (to Improve) :ارتقاء هر چیز و تشخیص کاستی های یک چیز و حرکت در جهت اصلاح آنها
در مطلب های بعدی این موضوع تکمیل می گردد.
همین!

"اگر بتواني چيزي را اندازه گيري کني مي تواني آن را مديريت کني!"
(!If you can mesure it you can manage it)

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