تا حالا فکر کرده اید که چرا بسیاری از نرم افزارهای تولید شرکت های معتبر خارجی رو به راحتی خریداری یا دانلود کرده و با کمترین زحمتی اقدام به نصب و استفاده از آن می نمایید؟ در حین کار با مشکلات بسیار کمی مواجه می شوید و در صورت رویارویی با مشکلات (باگ های نرم افزاری)، با استفاده از منابع آنلاین اختصاصی تیم تولید کننده و یا منابع عمومی تر اینترنت مشکل خود را برطرف می نمایید… اگر در حوزه عملکرد نرم افزار مورد استفاده ی خود، متخصص باشید (مثال: اگر پزشک هستید با نرم افزارهای تخصصی پزشکی) به راحتی با نرم افزار ارتباط برقرار می نمایید ولی در مورد اکثر نرم افزارهای تولید داخل چنین نکاتی را نمی یابید. به راستی چرا؟؟ چرا حتی برای نصب نرم افزار، در بسیاری موارد شرکت تولید کننده خود اقدام به نصب نرم افزار در محل مشتری می نماید؟ چرا برقراری ارتباط و درک نرم افزارهای داخلی علیرغم برخورداری از محیط پارسی، دشوارتر می نماید؟ چرا خطاهای نرم افزارهای داخلی و کاستی هایشان این قدر پررنگ به نظر می رسند؟
با این مقدمه، قصد بررسی خیلی سریع و گذرای کاستی های روند تحلیل، تولید، نگهداری و توسعه نرم افزار را خواهیم داشت… برای بررسی دقیق تر این مهم، شناخت روند و فضای تولید امری اجتناب ناپذیر به نظر می رسد، از این رو در اولین سری از این مجموعه مقالات به معرفی مفاهیم کلان تولید نرم افزار خواهم پرداخت و در بخش های بعدی به مسائل کیفی، امنیتی و توسعه.
بیاییم تا مراحل تولید یک نرم افزار سفارش مشتری رو در کشورمون مرور کنیم:
- ابتدا باید نرم افزار تحلیل شود: اگر در بندهای قرارداد مشتری استفاده از RUP را به عنوان متدولوژی تحلیل و تولید ذکر نکرده باشد، به احتمال 90% خود تولیدکننده در بروشورها و متون مربوط به معرفی خود استفاده از این متدولوژی را به عنوان بخش لاینفک کارهای خود ذکر کرده است…
- اگر و تنها اگر نشانه ای از متدولوژی ببینیم، مستنداتی خواهد بود که پس از تولید نرم افزار!!! طی مدت یک هفته توسط یک نیروی جوان و یا طی قراردادی با یک نیروی بیرون از سازمان در قالب use case diagram, State diagram, … تولید خواهد شد.
- بریم سراغ تولید: یک تیم داریم که اگر اغراق نکرده باشیم، از OOP, OOA, OOD, AOP, AOA, SOA و خیلی مسائل دیگه هیچ درک صحیحی ندارند و فقط در دوران دانشجویی یا بعد از اون در دوره های آزاد مطالبی رو که هیچ ارتباط فکری ای نتونسته اند باهاش برقرار کنند شنیده اند.
- Build Integration, Source Control, Code Versioning, Test,… نیز عباراتی غریبه اند و در توجیه پرسش اینکه چرا این ها را ندارید یک جواب میشنویم: این ها برای پروژه های خیلی بزرگ اند نه پروژه های ما!!!!
- محصول با شیوه های سلیقه ای مدیر تیم هدایت و تحلیل و با شیوه های دلخواه برنامه نویس تولید و کد می شود…
- پس از تولید هم خانم منشی موظف خواهند بود تا میان کارهای روزانه فرم های نرم افزار را با دیتای تستی پر کنند و ببینند error می دهد یا خیر…
- نصب، پشتیبانی و کیفیت نرم افزار خود حدیث مجملی است که از مراحل قبل مابقی آن را بخوانید…
چگونه تحلیل، طراحی و تولیدی اصولی را پیش بگیریم؟
امروزه مفاهیم متنوعی در امر تحلیل، طراحی و تولید نرم افزار مورد بررسی قرار می گیرند، مانند:
- متدولوژی تحلیل و تولید: هرگز به دلیل کوچک بودن حجم پروژه و قلت نفرات تیم تولید، استفاده از متدولوژی را ترک نکنید… متدولوژی تنهای محدود به RUP نیست، سعی کنید با توجه به سایز پروژه و تعداد نفرات درگیر در پروسه تحلیل، طراحی و تولید متدولوژی مناسب را انتخاب نمایید.
متدولوژی های Agile برای 80% تیم های تولید نرم افزار در ایران گزینه ای مناسب هستند.(نسبت 80% بر پایه تجربه شخصی نگارنده این متن می باشد) - ابزار تولید: یک پروژه هرچند کوچک ولی در صورت تجهیز به ابزار تولید مناسب، علاوه بر جلوگیری از سردرگمی تیم تولید، تاثیر بسزایی در بهبود کیفی فرایند تولید خواهد داشت، منظور از ابزار تولید سامانه هایی نظیر:
- ابزار Revision Control/ Source Control: استفاده از ابزارهای رایگان، کدباز و یا تجاری متنوعی که به تیم تولید امکان دسترسی به نگارش های قبلی پروژه، مشاهده سیر تغییرات کد، علاوه بر امکان بررسی و مراجعه و کنکاش تغییرات نرم افزار، موجب تعمیق دید مدیرپروژه نسبت به چگونگی و سرعت تولید و عملکرد اعضاء تیم را محیا می سازد. در اینجا می توانید مقایسه و فهرست برخی ابزارهای مدیریت نگارش را مشاهده نمایید.
- ابزار Continuous integration: این دسته از نرم افزارها که به اختصار CI نامیده می شوند، تولید نرم افزار و مدیریت کد را به گونه ای تسهیل می نمایند که بیش از یک برنامه نویس قادر به کار بر روی آن باشند، در ایران Source Safe شناخته شده ترین ابزار CI می باشد که چند سالی است نسل آن منقرض شده و Team Foundation Server جایگزینی برای آن می باشد که علاوه بر نقش CI قبلیت های متعدد دیگری را در اختیار تیم قرار میدهد که در مجال این مقاله نیست، ابزارهای کدباز، تجاری و رایگان دیگری نیز علاوه بر این دو در اختیار برنامه نویسان می باشد که کمک به ممانعت اخلال ناشی از تولید همزمان یک کد توسط چند برنامه نویس در تیم میشود و یا به عبارت ساده تر توسعه ی کد با دید باز سایر کدنویس ها از عملکرد دیگر همکارانشان بر روی پروژه انجام می شود.
- ابزار Test/ Memory profiling/ …: چرا ما تست نرم افزار را یاد نمی گیریم؟ تا کی می خواهیم تست نرم افزار را محدود به پر کردن فرم ها و انتخاب دکمه ثبت و خطاهای نرم افزار را این قدر سطحی می بینیم؟ گاها حین تدریس از کتاب How we test software at Microsoft که به حق کتاب آموزنده ایه یاد می کنم و آرزو می کنم روزی تست نرم افزار در ایران بتونه به امری مهندسی شده و اصولی در بیاد، امکانات خود Visual Studio 2010 فوق العاده مفیده ولی دریغ از حتی آگاهی جمع کثیری از تولید کنندگان نرم افزار ایران با این امکان ویژوال استدیو، به کار بردن آن پیشکش… یافتن میزان استفاده نرم افزار از RAM و یافتن گلوگاه های Performance نرم افزار نیز ابزارهای متنوعی را در اختیار برنامه نویس قرار می دهد.
- ابزار Bug Tracking: یک Bug نرم افزاری چه از طرف اعضاء تیم چه از طرف کاربر نهایی کشف گردد، باید جایی ثبت گردد تا بسته به اهمیت و اولویت آن، توسط تیم تولید برطرف گردد، از این رو نرم افزارهای متعددی در این رابطه تولید شده اند که فرم هایی جهت ذکر خطا، اهیمت آن و میزان دفعات موجهه با آن در اختیار کاربر داده و مدیر تیم و یا خود کاربر امکان پیگیری وضعیت خطا را از طریق این نرم افزارها پیدا می کنند، علاوه بر ارتباط سریع تر و بی واسطه کاربر، تست کننده و… با تیم توسعه، بهبود نرم افزار را تسریع کرده و چشم انداز بهتری را نسبت به کیفیت نرم افزار و رسیدگی و پیگیری تیم تولید نسبت به خطاها در اختیار مدیران تولید قرار می دهد.
آنچه ذکر شد بخشی از ابزارها و فرآیند صحیح تولید نرم افزار بود… نگهداری، توسعه و تحویل نرم افزار نیز دارای مفاهیمی مشابه با رویکرد مربوط به خود می باشند.
به مجموعه روش ها و روندی که مفاهیم فوق را انتخاب و چیدمان می نمایند ALM یا Application Lifecycle Management می گویند. این که چه متدولوژی انتخاب نماییم، از چه نوع تست هایی بهره بگیریم، چگونه نرم افزار را ارزیابی نماییم و فرایند توسعه و نگهداری را چگونه مدیریت نماییم، از جمله مفاهیم موجود در ALM می باشد.
در صورت استقبال از مفاهیم فوق هر یک از ابزارها رو طی پستی مجزا بررسی خواهیم کرد…
یکی از دلایل این سختتر بودنها بر میگرده به کمبود یا نبود امنیت شغلی. زمانیکه راحت میتونند کارت رو بدزند مجبوری کاری کنی که برنامه زمین گیر بشه. سخت بشه. تا نتونند نتیجه زحماتت رو راحت به یغما ببرند و دستت هم به جایی بند نباشه. میدونی بدون کپی رایت کار کردن خیلی سخته تا بتونی خودت رو سرپا نگه داری. بتونی قبض گاز آخر برجت رو پرداخت کنی.
بسیار جالب است اگر امکان دارد در مورد Agile بیشتر توضیح دهید.
با تشکر موفق باشید.
سلام
مطالبی رو که بیان کردین خیلی خوب بود لطفا ادامشون بدین به امید روزی که واقعا این مباحث به صورت اصولی تو تمام شرکت ها رعایت بشه .
Perfect…
سعید عزیز، حرف شما کاملا صحیحه، ولی تجربه ی شخصی من ثابت کرده پروژه ای که پس از تولید بیشترین فراغت رو برای تیم تولید خودش باقی میزاره، در صورتیکه و فقط درصورتیکه تیم تولید افراد خلاق و بی نیاز از امر و نهی مافوق خودشون جهت پیشرفت دادن پروژه یا استارت زدن ایده های جدید باشند، میتونه سود دهی بیشتری داشته باشه و مدیر تیم خواهد فهمید که در صورتیکه این نیروها با این تخصص و دیسیپلین رو از دست بده قطعا متحمل ضرر و زیان قابل توجهی خواهد شد…
لذا این ادبیات و این پست مخاطبان خودش رو میطلبه و یکی از پیش شرط های ورود به این عرصه و این تفکر و نگرش تولید، وجود مدیر و تیم تولید خلاق، صادق و علاقه مند به پیشرفته…
دغدغه هایی که شما فرمودی کاملا درسته و متاسفانه زنجیره ای از عوامل مختلف، از مدیرپروژه تا کارفرمای غیرمتخصص و غیر متعهد همه و همه انگیزه و نگرش برنامه نویس ها رو تحت تاثیر قرار داده اند…
نه تنها مثل همیشه استفاده کردم بلکه بسیار خوشحال شدم که بعد از مدت ها دوباره دست به کیبورد شدین
عالی بود استاد. خوشحالم از اینکه دوباره می نویسید.
یک سوال:
اگه یک نفر بخواد یک محصولی تولید کنه و بعد بدنبال مشتری باشه چی.
یعنی نیازهای مشتری رو درست ندونه و یک نفر باشه.
باز هم نیاز به متدولوژی هست؟ یا اینکه اگه بخواد متدولوژی پیاده کنه، وقتش تلف میشه؟
همچنین در مورد رفع خطا، تست و اون source safe کاملا با شما موافق هستم!!!
به نظر من یک فرد باید به اندازه ای دانش و معلومات در زمینه شغلیه خودش داشته باشه که نگران دزدیده شدن کارش نباشه و مطمئن باشه که خیلی جاها به تخصص او نیاز دارند.
قبل از هر چیزی باید اعتراف کنم که خیلی خوشحال شدم که دوباره رنگ مطالب جدید رو توی این وبلاگ دیدم . مثل همیشه هم آموزنده و عالی بود. مواردی رو که اشاره کردید خیلی جالب و درخور توجه هستند هر چند که فکر می کنم بدلیل ماهیت سفارش کار در ایران و قانون های نانوشته ای که وجود داره خیلی زمان می بره تا شرکت های داخلی به این اصول پایبند شوند.
دانیال عزیز،
سوال کاربردی و مهمی پرسیدی، ازت ممنونم 🙂
یکی از مهمترین نکاتی که متاسفانه در ایران بهش پرداخته نمیشه، امکان سنجی تولید، Requirement Engineering و business study پروژه است، این ها مفاهیم بسیار مهمی و تکنیکالی به شمار میره تا جایی که "مهندسی نیازها" شکل گرفته، این که مشتری داری یا نه {قبل از تولید مهم نیست} بسیاری از محصولات مشتری ای نداشتند ولی پس از تولید سیل مشتریان به سمت خرید و یا استفاده از محصول روانه شده… لذا این مهمه که –> ارزیابی کنی که چه محصولی مورد نیاز بازار و دارای مشتری بالقوه ایه که مسیر بالفعل شدنش با توجه به منابع مالی {خصوصا جهت معرفی و تبلیغات، توسعه بازار و مدل فروش } شما هموار تره…
این ها ترکیبی از علم اقتصاد و مهندسی نرم افزاره که متاسفانه اولی جایی در شرکت های ما در ایران نداره…
سر بعضی کلاس ها، در مبحث مهندسی نرم افزار اشاراتی به برخی سیاست ها، تجربیات و بررسی عملکرد شرکت های بزرگ دنیا در این حوزه داشته ام… خلاصه اینکه برای دوران بازنشستگی کدنویسی یادگیری این علوم جایگزین خوبیه… 🙂
سلام
خیلی متشکرم
به شخصه به عنوان یک برنامه نویس بی تجربه و در ابتدای راه خیلی دوست دارم اصولی کار کنم 🙂
خواهش مندم مانند گذشته تجاربتون رو در اختیار ما قرار بدین.
با توجه به تجربه شما آیا انجام این مراحل فرایند تولید نرم افزار را طولانی نمی کند ؟
۰: سلام
۱: از ابراز محبتتون متشکرم
۲: در نگاه اول شاید استارت تولید نرم افزار کندتر شود، ولی زمانی که می بایست صرف باز کردن گرده های کور، بازخوانی کدهایی که ۲ماه پیش تولید شده و مستلزم زمان می باشد تا برنامه نویس دوباره اشراف روزهای تولید را به دست آورد و کیفیت روند تولید از کیفیت محصول تا شرایط فکری برنامه نویس اگر کوتاه تر هم باشد قطعا با فرسایش بیشتر و رضایت مندی کمتری برخوردار خواهد بود…
تحلیل و طراحی و تولید خودرویی با کیفیت پیکان و یا پراید تولید داخل سریع تر است یا زمانی که صرف طراحی و تولید در تویوتا میشود؟؟
کیفیت و پیروی از مکتب مهندسی نیازمند صرف زمان بیشتر و مطالعه دقیق تر و تحمل سختی بیشتر است… ولی نتیجه ی نهایی و سود ماحصل تولید و بقاء در بازار در گرو این رویه است…
چند شرکت نرم افزاری در ایران طی سال ورشکسته می شوند؟ چند نفر از برنامه نویس های چند سال کار کرده خسته و رنجور از کار خود می باشند و به دنبال تغییر شغل و یا در حسرت امکان تغییر شغل اند؟؟ این ها ماحصل سنجش کیفیت نرم افزار با کیل زمان و زحمت کمتر است…
ابزار های Revision Control/ Source Control و Continuous integrationحتی برای تیم دو نفره حیاتیه
بی نظمی حاکم بر روند توسعه ؛ کندی کار و… عدم تست اصولی و درگیر بودن با بک پروژه برای مدت طولانی و اتلاف انرژی فقط به خاطر تنبلی در یادگیری مطالب جدید!
منتظر توضیحات شما هسنم
قطعا همینطوره، خوشبختانه در ویژوال استدیو نسخه بعدی، Team Foundation Express به صورت کاملا رایگان عرضه شده که در حال حاضر نسخه آزمایشی اون در دسترسه و انصافا خیلی خوبه… حتی برای کدنویسی فردی هم قابل استفاده و مفیده…
سلام
من به عنوان یک برنامه نویس که تجربه کاری دارم باید بگم که یکی از دلایل وجود این همه مشکل در نرم افزار های تولید داخل اینه که اولا فرد یا شرکت می خواد هر چه سریعتر به مرحله دریافت هزینه برسه و ثانیا یه برنامه ریزی دقیق با توجه به واقعیت ها نداره و ثالثا مشکل عمده اینه که تو نرم افزار های داخلی اول اجرا می کنند! بعد تازه متوجه می شن که اول باید یه برنامه ریزی و طراحی دقیق انجام می دادند و بعد اجرا می کردند!