مهندسی کیفیت نرم افزار

نمی دانم که بحث را از کجا شروع کنم ؟ فقط این را بدانید که در این نوشته نظم و ترتیبی رعایت نشده است و این نوشته بیانی از تجربیات خودم می باشد.

ابتدا باید با چند سوال شروع کنم :

چرا نرم افزار درست و حسابی و با کیفیت ندارم ؟

علت وجود نرم افزارهای بی کیفیت آن هم به تعداد زیاد در بازار چیست ؟

چرا اکثر نرم افزار ها در ابتدا با شکست های سنگینی مواجه می شوند ؟

اصلا کیفیت نرم افزار به چه معناست ؟

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

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

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

خلاصه وار بگویم که کیفیت در هر مرحله بدین معناست که؛

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

جمله معروف مارتین فاولر اینست که :

هر ابلهی می تواند کدی بنویسد که کامپیوتر آن را بفهمد . برنامه نویس خوب کسی است که کدی بنویسد که هر شخصی بتواند آن را بخواند و درک کند . (منظور از شخص فرد سواد دار است نه بی سواد و نامربوط به کامیپوتر و دنیای نرم افزار )

خب با این اوضاع و تفاسیر چه کنیم ؟ یعنی چه میتوانیم بکنیم ؟

اکثر شرکت هایی که برای مشتریان خود برنامه می نویسند ، این لفظ را به کار می برند

" یه چیزی بنویس که کار کنه . دیگه بقیه اش مهم نیست . مگه چقدر پول میده تا من این کارها رو براش انجام بدم ؟ "

در طول 9 الی ده سالی که در شرکت ها و سازمان های مختلف کار کرده ام ، این را به وضوح هر چه تمام تر شنیده ام و بعضی اوقات هم وضع و اوضاع از این بدتر هم شده است . بگذریم .

در اولین قدم ( البته نظر شخصی من است ) ، متوجه میشوم که فرد صاحب سرمایه یا مدیر مسئول سواد کمی در نرم افزار و توسعه آن دارد .

اگر این افراد بدانند که در آینده چه ضررهایی می کنند و در قبال آن چه هزینه هایی را باید پرداخت کنند ، دیگر این کارهای اشتباه را تکرار نمی کنند .

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

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

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

چه میشود که در اول این مشکل ها ، جزئی و ناچیز پنداشته می شود و در جایی از کار مشخص می شود که ، نه خیر جزئی نبوده و یک مشکل اساسی است .

حال منشاء این دسته از مشکلات چیست ؟

با توجه به تجربیات خودم و مطالعاتم در این زمینه ، به این نتیجه میرسم که عوامل زیادی وجود دارد که دوست دارم مهمترین آن ها را بیان کنم و در ادامه بحث ها در آینده به تحلیل و بررسی هر چه بهتر و بیشتر آن ها خواهم پرداخت .

مهمترین عامل عدم مطالعه و عدم آشنایی با تکنولوژی ها جدید است .

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

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

بعد خیلی جالب است که گله های این مدیران را می شنوی که می گویند " کار کن در بازار نیست " اخه مدیر عزیز تو سواد خودت و تکنولوژی ات مربوط به بیست سال پیشه . چطور انتظار داری کسانی پیدا بشن که با همون تکنولوژی عهد بوق جناب عالی کار کنند ؟

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

دسته های مختلفی طبق گفته های بهترین مهندسان نرم افزار وجود دارد . از جمله پرسمن و مارتین فاولر و مایک کوهن و ....

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

12345678  System software
  Application software
  Engineering/scientific software
  Embedded software
  Product-line software
  Web applications
  Artificial intelligence software
  Open-world computing

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

منظورم از جمع آوری نیاز های همون Software Requirement Gathering است . که کتاب های مخصوص به خودش رو طبق هر متودولوژی داره . یعنی اگر می خواهید RUP یا Agile یا Scrum یا Kanban کار کنید باید طبق استاندارد های اون روش ، نیازمندی های مخصوص رو جمع آوری کنید .

در آینده هم در موردشون به طور کامل توضیح میدم .

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

عکس زیر رو که ببینید متوجه منظور من میشید .

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

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

این مراحل شامل موارد زیر میشه که هر کدوم برای خودشون دنیایی از Pattern ها و متدها و مهندسی هایی دارند.

1234567891011Network intensiveness
Concurrency
Unpredictable load
Performance
Availability
Data driven 
Content sensitive
Continuous evolution
 Immediacy 
 Security 
 Aesthetics

البته این نکته رو بگم که این دسته بندی ها رو از روی کتاب Software Engineering پرسمن انتخاب کردم . اگر دوست داشتید می تونید همون کتاب رو بخونید . چون من نسخه کاغذی اون رو دارم نمی تونم بیشتر بنویسم و بیشتر توضیح بدم . اگر هم هر کدوم رو توی خود سایت کتاب پرسمن سرچ کنید ، همه چی دستتون میاد .

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

برای تحقیق بیشتر در اینترنت کافی است که در ابتدا هر کدوم واژه software رو قرار بدید . برای مثال :

software Data Driven Definition یا Immediacy in software engineering

بعد از طی این مراحل تازه متوجه میشد که نرم افزار شما در کدوم دسته قرار داره و نیازمندی های پایه ی اون چیه .

اما توی شرکت های ایرانی که من تجربه کار توی اون ها رو داشتم ، خیلی خیلی کم به این ها توجه میشه . تازه اگر فرد صاحب شرکت سواد بالایی داشته باشه . با این فرض گفتم .

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

اما زمانی که خودم مدیر پروژه نرم افزاری قرارداد های سازمان آب رو بر عهده گرفتم ، تمامی این نیازها رو در نظر گرفتم و توسعه نرم افزار رو با توجه به همین استاندارد ها و قواعد انجام دادم .

این روش باعث شد که ما سه نفر بتونیم نرم افزاری رو بنویسم که سه سال بود که کسی نتوانسته بود حتی 20 درصد اون رو انجام بده .

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

دامه دارد..