در قسمت قبلی نوشتم که علت های زیادی برای توسعه نرم افزار های بی کیفیت وجود دارد.
در این قسمت می خواهم به دسته ی دیگری از مشکلات توسعه نرم افزار بپردازم .
یکی از عمده ترین مشکلات رایج در توسعه نرم افزار ها ، عدم توجه به رده بندی و دسته بندی نرم افزار هاست .
دسته های مختلفی طبق گفته های بهترین مهندسان نرم افزار وجود دارد . از جمله پرسمن و مارتین فاولر و مایک کوهن و ....
البته ببخشید که انگلیسی نوشتم . چون هم اینطوری میشه بهتر در موردشون تحقیق کرد و هم معادل های فارسی آن ها رو نمی تونم درست و حسابی ترجمه کنم .
1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web applications
7) Artificial intelligence software
8) Open-world computing
9) Net-sourcing
10) Open source
اینجا تازه اولین مرحله است که مشخص میشه نرم افزار شما در کدوم دسته قرار داره . بعد از مشخص شدن دسته حالا نوبت به این میرسه که جمع آوری نیاز های مخصوص به همون دسته رو انجام بدیم .
منظورم از جمع آوری نیاز های همون Software Requirement Gathering است . که کتاب های مخصوص به خودش رو طبق هر متودولوژی داره . یعنی اگر می خواهید RUP یا Agile یا Scrum یا Kanban کار کنید باید طبق استاندارد های اون روش ، نیازمندی های مخصوص رو جمع آوری کنید .
در آینده هم در موردشون به طور کامل توضیح میدم .
اما خود این مرحله جمع آوری نیازها ، داستان داره . این که کدوم یکی از نیازها اساسی اند و کدوم یک جزئی . کتاب های زیادی در این باره وجود داره که دوست دارم در پست های جداگانه اونها رو به طورکامل شرح و بسط بدم. پس فعلا از این مرحله می گذریم چون بحث اصلی ما مربوط به کیفیت نرم افزاره نه مراحل اولیه .
عکس زیر رو که ببینید متوجه منظور من میشید .
حالا فرض کنید که نیازها درست جمع آوری شده و طراحی هم طبق متودولوژی مورد نظر می خواد انجام بگیره . اما با توجه به تجربه خودم کسی به این مراحل که حیاتی ترین مراحل ساخت و پاخت نرم افزار هستند ، توجهی نمی کنه.
ساخت و پاخت رو هم در مواقعی به کار میبرم که توجهی به نیاز های حیاتی نمیشه و همین طوری و الله بختکی شروع می کنند به نوشتن نرم افزار .
1) Network intensiveness
البته این نکته رو بگم که این دسته بندی ها رو از روی کتاب Software Engineering پرسمن انتخاب کردم . اگر دوست داشتید می تونید همون کتاب رو بخونید . چون من نسخه کاغذی اون رو دارم نمی تونم بیشتر بنویسم و بیشتر توضیح بدم . اگر هم هر کدوم رو توی خود سایت کتاب پرسمن سرچ کنید ، همه چی دستتون میاد .
شما هم سعی کنید که تا قبل از انتشار مطلب بعدی ، در مورد همون دسته بندی ها یه تحقیقی انجام بدید تا حساب کار دستتون بیاد و در نوشته های بعدی بتونید که منظور من رو کامل متوجه بشید .
این مراحل شامل موارد زیر میشه که هر کدوم برای خودشون دنیایی از Pattern ها و متدها و مهندسی هایی دارند.
1) Network intensiveness
2) Concurrency
3) Unpredictable load
4) Performance
5) Availability
6) Data driven
7) Content sensitive
8) Continuous evolution
9) Immediacy
10) Security
11 ) Aesthetics.
البته این نکته رو بگم که این دسته بندی ها رو از روی کتاب Software Engineering پرسمن انتخاب کردم . اگر دوست داشتید می تونید همون کتاب رو بخونید . چون من نسخه کاغذی اون رو دارم نمی تونم بیشتر بنویسم و بیشتر توضیح بدم . اگر هم هر کدوم رو توی خود سایت کتاب پرسمن سرچ کنید ، همه چی دستتون میاد .
من که وقتی میخوام طراحی رو انجام بدم ، بعضی از اون نیاز ها توی همون مرحله نیازسنجی در نظر میگیرم . تا در آینده کمتر به مشکل بخورم .
برای تحقیق بیشتر در اینترنت کافی است که در ابتدا هر کدوم واژه software رو قرار بدید . برای مثال :
software Data Driven Definition یا Immediacy in software engineering
بعد از طی این مراحل تازه متوجه میشد که نرم افزار شما در کدوم دسته قرار داره و نیازمندی های پایه ی اون چیه .
اما توی شرکت های ایرانی که من تجربه کار توی اون ها رو داشتم ، خیلی خیلی کم به این ها توجه میشه . تازه اگر فرد صاحب شرکت سواد بالایی داشته باشه . با این فرض گفتم .
معمولا روش های توسعه نرم افزار توی ایران ، البته بازهم با توجه به تجربیات خودم ، اینطوریه که همون ابتدا بدون توجه به این مسائل شروع به کد نویسی می کنند . من توی خیلی از پروژه ها شرکت کردم که فقط و فقط به دلیل در نظر نگرفتن یک نیازمندی کوچیک ، مجبور شدیم که از اول کد نویسی کنیم .
اما زمانی که خودم مدیر پروژه نرم افزاری قرارداد های سازمان آب رو بر عهده گرفتم ، تمامی این نیازها رو در نظر گرفتم و توسعه نرم افزار رو با توجه به همین استاندارد ها و قواعد انجام دادم .
این روش باعث شد که ما سه نفر بتونیم نرم افزاری رو بنویسم که سه سال بود که کسی نتوانسته بود حتی 20 درصد اون رو انجام بده .
اما در همون ابتدا یک نکته رو در نظر نگرفته بودم . عدم توجه به تعویض مدیریت در سازمان و عدم قید آن شرط در قرارداد. که باعث شد این پروزه در عین درست و حسابی بودن با شکست رو به رو بشه و مدیر جدید اون رو نخره .
شما هم سعی کنید که تا قبل از انتشار مطلب بعدی ، در مورد همون دسته بندی ها یه تحقیقی انجام بدید تا حساب کار دستتون بیاد و در نوشته های بعدی بتونید که منظور من رو کامل متوجه بشید .
ادامه دارد . ...
