تجربیات و اشتباهات پروژه های بزرگ رو با هم به اشتراک بگذاریم

[Asad.Safari]

با سلام

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

تعاریف :

پروژه بزرگ : منظور از پروژه بزرگ , پروژه ای است حداقل 30 تا فرم یا صفحه داشته باشد [به قول بیل گیتس , درسته نمیشه بزرگی برنامه رو با تعداد کد ها سنجید اما منظور من از تعداد صفحات و یا فرم این است که اگر ما یه اشتباهی در طراحی داشته مجبور شدیم تو همه این 30 تا فرم تغییراتی داشته باشیم و این یعنی اشتباه بزرگ ] و حداقل به صورت گروهی و چند نفره انجام شده باشد .

البته اینجا میشه از تعریف Enterprise Application کمک گرفت و گفت :

* سایز نرم افزار و یا محصول تون بزرگ باشد .(Large of Size)
* می تواند به صورت توزیع شده باشد .(Distributed)
* نرم افزار تون امن باشد . (Secure)
* قابل گسترش باشد (Scalable)
* همیشه در دسترس باشد (High Availability)


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


همانطور که مستحضر می باشید نرم افزار ها در دو سطح اختصاصی (Proprietary ) و عمومی (Public ) منتشر می شوند که به نظر من اشتباهات در نرم افزار هایی که به صورت عمومی منتشر می شوند محلک تر و کشنده تر می باشند (منظور از کشنده : یعنی از هم پاشیدن کمپانی شماو یا از کار برکنار شدن شما ) .

پس ما پست ها مون رو در دو سطح کلی دسته بندی خواهیم کرد 1- اختصاص 2- عمومی .

من پیشنهاد میکنم پست هامون رو در قالب خاصی مثل قالب زیر پست کنیم تا در آینده بشه اینها رو دسته بندی کرد و یا به صورت یک مرجع درآورد :

* قالب نرم افزار : عمومی یا اختصاصی

* عنوان محصول و یا درج گروه محصول : حسابدرای تحت وب

* بروز مشکل از سطح : مدیریت پروژه , آنالیز ها , طراح ها , مدیر پایگاه داده , برنامه نویس و ...

* شرح مشکل : #

* راه حل مشکل : #

* عاقبت پروژه : با تاخیر # ماهه به مشتری تحویل داده شد , پروژه شکست خورد و # ریال هزینه سربار شرکت شد .

* نتیجه گیری : #


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


اگر دوستان با کلیت بحث موافق باشند , شروع به کار کنیم .

موفق باشید

[hamidinejad]

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

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

[MM_Mofidi]

* قالب نرم افزار: اختصاصی

* عنوان محصول : سیستم ره گیری خودرو به صورت بر خط و ارائه گزارشات تحلیلی

* بروز مشکل از سطح : آنالیز ها , مدیر پایگاه داده

* شرح مشکل : به واسطه عدم بررسی دقیق حجم داده های حاصله برای ناوگانهای بزرگ در گزارش گیری ،سیستم عملا امکان کار را از دست خواهد داد.داده های پایه این پروژه با نرخ وحشتناکی رشد می نمایند لذا مدیریت این رکوردهای اطلاعاتی معضل بزرگی است

* راه حل مشکل : سیستم ارائه شده در مرحله از کار بسته و محدود به کاربری برای حداکثر ناوگانی با تعداد N متحرک گردید و دوباره نویسی سیستم جهت ناوگانهای حجیم تر در دستور کار قرار گرفت

* عاقبت پروژه : با لاخره به مشتری تحویل داده شد .(بهتر بگم تحویل دادونده شد) با انواع ضمانتها برای بهینه سازی و رفع عیوب در فاز بعد

* نتیجه گیری : درسته که تحلیل پروژه همیشه لازم و جزء لاینفک پروژه است اما همین تحلیل اگر فاقد پیشبینی های لازم برای اندازه نهایی پروژه یا فاقد Target مشخص جهت Scale باشد ممکن است ضربات شدیدی بخورد حتی اگر سیستم اصلا تکه تکه و قابل رشد طراحی شده باشد.

[Asad.Safari]

MM_Mofidi , بسیار ممنون که شروع گر این بحث شدین .

* قالب نرم افزار: عمومی

* عنوان محصول : سیستم حسابداری عمومی

* بروز مشکل از سطح : مدیریت پروژه و تست تر ها

* شرح مشکل : به دلیل اینکه ما یه نرم افزار عمومی رو به بیرون دادیم و میشه گفت بزرگترین مشکل برنامه هایی که به صورت عمومی عرضه میشند بحث release محصول می باشد . ما در اینجا یه اشتباه مهلکی که کردیم به صورت کامل نرم افزار تست نشد (فقط توسط حدود 10 نفر افراد غیر متخصص فقط تست شد) و برنامه رو به صورت Acceptance test تست نکردیم و دومین اشتباه مون این بود که محصول بیرون داده شد و بعد از مدتی تلفن ها شروع کردند به زنگ زدند و پشتیبانی شروع کرد به یادداشت باگ ها و تیم توسعه شروع کرد به رفع باگ ها ... ولی اینجا یه اشتباهی که کردیم این بود که هر بار چند باگ رفع می شد برنامه رو دوباره release میکردیم و به مشتری های جدید برنامه جدید داده می شد و در هربار شکل و شمایل و اصلا تغییرات در دیتابیس ایجاد می شد ولی بعضی از مدتی مشتریان قدیمی اودند سراغمون و از باگ های برنامه شکایت کردند ولی ما عملا نمی دونستیم که کدوم یک از release هامون دستشون است و اصلا دیتابیس شون ماله کدام تاریخه و کدام یک از تغییرات رو نداره ... . فرضا ما نمی دونستیم که تو دیتابیس برنامه که دست آقای X است فلان فیلد هست یا نه ؟؟؟ یعنی ما اشتباهمون این بود که تغییرات در دیتابیس (چه Table ها چه Stored procedure ها چه View ها و چه فانکشن ها) در هر بار Release رو یه جایی ثبت نکرده بودیم .


* عاقبت پروژه : به بعضی مشتری ها که زیاد اطلاعات وارد برنامه نکرده بودند مجبورشون کردیم که برنامه جدید رو نصب بکنند و برای بعضی که زیاد داده روش زده بودند مجبور شدیم که یکی یکی با برنامه محصول RedGate دیتابیس را مقایسه و اصلاح کنیم .

* نتیجه گیری : اگر ما Release ها رو طبق برنامه انجام می دادیم و برای هر Release می دونستیم که چه جاهایی از دیتابیس تغییر کرده می تونستیم به راحتی برنامه های مشتری ها رو آپدیت کنیم .

موفق باشید

[JaguarXF]

MM_Mofidi , بسیار ممنون که شروع گر این بحث شدین .

* قالب نرم افزار: عمومی

* عنوان محصول : سیستم حسابداری عمومی

* بروز مشکل از سطح : مدیریت پروژه و تست تر ها

* شرح مشکل : به دلیل اینکه ما یه نرم افزار عمومی رو به بیرون دادیم و میشه گفت بزرگترین مشکل برنامه هایی که به صورت عمومی عرضه میشند بحث release محصول می باشد

موفق باشید

یک سیستم SVN همراه با نسخه بندی نرم افزار همراه با داکیومنت کردن تغییرات و ذخیره اون با هر ریلیز همراه با دیتابیسی که حاوی همه گزارشات خطا به برنامه از کاربران باشه میتونه "تا حدی" مشکل رو حل کنه .

مثال: مشتری زنگ میزنه میگه نسخه 3.1 رو دارم و این مشکل رو داره . برنامه نویس از SVN کد ریلیز 3.1 رو دانلود میکنه ( ممکنه الان آخرین نسخه تون 4.5 باشه ) ، و اون رو روی سیستمش اجرا میکنه تا بقولی طبق سناریوی کاربر بتونه باگ رو Reproduce کنه و ظروع به خطایابی کنه . در عین حال باید توی اون دیتابیس رو هم سرچ کنه تا ببینه آیا این خطا قبلا هم گزارش شده یا نه ، و اگر شده در چه ریلیزی مرتفع شده . خیلی مواقع اگر خوش شانس باشه با یک Diff کردن سورس کدها میتونه خطا رو سریع درست کنه( تجربه سه شنبه هفته قبل خودم! ) ولی خیلی مواقع هم کلی متد و پراپرتی جدید در نسخه جدیدی که اون باگ رو هم نداره تعریف شده - که اغلب اینطوره- که در نسخه قدیمی هیچ کدومشون وجود نداره . تصمیم گیری اینکه حالا چکار کنم هم مهمه ! چون ممکنه اینها مربوط به امکانات جدیدی باشه که مشتری قدیمی پولی برای خریدنشون نداده ! بنابراین نمیشه اونها رو استفاده کرد!
درهر حال وقتی داره کدی رو عوض میکند باید یک داکیومنت هم همراه با کدش ، چک این کنه . در این داکیومنت باید ذکر شده باشه که برای باگ شماره فلان ( که اکنون قابل سرچ کردن در اون دیتابیس هست ) ، این دیزاین رو انجام دادم . این متد ها رو اضافه کردم و غیره .
دو کار باقیمونده شامل این هست که در همون دیتابیس داخلی ، ذکر بشه که مثلا برای این خطا ، کد تصحیح در 3.2 موجود است . نهایتا مثلا خطا در report.DLL بوده و اکنون برطرف شده . به مشتری اطلاع داده میشه که حاجی! این dll جدید رو دانلود و استفاده کن!

در کل TakeBack کردن میتونه مکافاتی باشه واسه خودش:عصبانی++:

[Asad.Safari]

همراه با داکیومنت کردن تغییرات و ذخیره اون با هر ریلیز همراه با دیتابیسی که حاوی همه گزارشات خطا به برنامه از کاربران باشه میتونه "تا حدی" مشکل رو حل کنه .


آها این لوپ مطلبه ... اگر این کار انجام بشه شما دیگه به مشکلی برخورد نخواهید کرد ...

موفق باشید

[JaguarXF]

آها این لوپ مطلبه ... اگر این کار انجام بشه شما دیگه به مشکلی برخورد نخواهید کرد ...

موفق باشید

البته این موضوع از قلم نیفته که Bug هم Life Cycle داره! و باید نگهداریش کرد و ...
بجای اینکه من تایپ کنم ، سیستمهایی مثل Bug Zilla و دهها مورد مشابهش رو پیشنهاد میکنم . که حداقل یکی شون رو استفاده کنید.

http://www.bugzilla.org/

یعنی یک "شرکت" نرم افزاری ، باید سیستمی برای تریس کردن باگهای نرم افزارهاش از لحظه گزارش تا لحظه تصحیص و ریلیز جدید رو داشته باشه وگرنه پس از چند سال : الفاتحه!.

ورک فلو هم سادست و موثر :
http://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Bugzilla_Lifecycle_color-aqua.svg/270px-Bugzilla_Lifecycle_color-aqua.svg.png
شکل برگرفته از : http://en.wikipedia.org/wiki/Bugzilla

[ب- تات]

قالب نرم افزار: عمومي

* عنوان محصول : سیستم حسابداری دولتي (طرح ملي)

* بروز مشکل از سطح : به روز رساني ها

* شرح مشکل : يه تجربه عملي توي كاري كه مشتري هاش هر كدوم يه جاي ايران بودن پيدا كردم كه البته نوع مشكل مشابه مشكل پستهاي قبلي دوستان هست اما راه حل براي سه سال پر كار نرم افزارم كاملا جواب داد. داستان از اينجا شروع شد كه يكي تماس ميگرفت ومشكلي داشت. اين مشكل براي ديگر كاربران در استانهاي ديگر هم بود. پس اينجا مسئله 2 تا بود . يكي ارسال مجدد exe يا dll ديگري تغييرات جديد در ديتابيس. اما امكان داشت يكي dll , exe رو جايگزين كنه اما به ديتابيس كاري نداشته باشه يا برعكس.اينجا بود كه 2 كار كردم . اول كليه update ها رو براي انتقال به سيستم مشتري بصورت يك پكيج جدا و كوچيك ساختم تا خيالم راحت باشه همه بصورت يكسان update ميكنن دوم براي هر نسخه exe مشخص كردم چه update هايي رو بايد اجرا كرده باشه. در غير اينصورت اخطار ميداد كه نسخه برنامه يا ديتا بيس همخواني ندارد. گفتم update بزارين همين جا توضيح اين قسمت رو هم بدم. براي تغييرات در ديتابيس هر بار كه يه چيز به ديتابيس اضافه ميكردم يا تغيير ميدادم سريعا SCRIPT اون رو مينوشتم و بصورت سريالي ذخيره ميكردم در نهايت در ديتابيس معلوم بود هر نسخه exe بايد تا چه شماره script اجرا كرده باشه.خوب از اون طرف هم اين فايلها در فولدر مشخصي درون برنامه كپي ميشدند (توسط پكيج كوچك)و بصورت اتوماتيك پس از اولين اجراي كاربر بر روي ديتابيس لحاظ ميشدند. لذا هيچ كسي از روند چگونگي و پيچيدگي تغييرات مطلع نميشد.

* نتيجه : چيزي جز تشكر و سرعت حل مشكلات از سوي كاربران نبود.