مهندسی نرم افزار در فلش

triton

کاربر فعال
سلام بر همه
سوالی که می خوام در اینجا مطرح کنم اینه:" چطور می تونم پروژه فلشی داشته باشم (flex/as) که با اصول مهندسی نرم افزار پیش بره؟"
آقای X سراغ من میاد و پروژه خیلی بزرگی را پیش نهاد می ده و می گه برای مدت مثلا 10 سال هم باید پشتبانی داشته باشی!!!! (منظورم اینه که پروژه ای بزرگ و طولانی داشته باشی)
من هم که پول جلوی چشام را گرفته، سریع قبول می کنم و اینجاست که مشکلات شروع می شه:
این پروژه به چند نفر نیاز داره؟ آیا تنهایی می تونم تمومش کنم؟
چه مدت برای تحویل نسخه اولیه نیاز داریم؟
چه محدودیتها یی دارم؟
اگه کار به صورت تیمی هست چطور مشکلات کار تیمی را حل کنیم؟
ساختار برنامه به چه صورتی باشه که در نسخه های بعدی به مشکل بر نخوریم؟
....
یا بهتر بگم چطور برای پروژه خودمون برنامه ریزی کنیم که بدونیم اولش کجاست، آخرش کجاست؟

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

akherat

مدیر انجمن
این موارد که گفتین رابطه مستقیم با تجربه داره

تخمین درست و مقدار انرژی که قرار بزارین رو کار به توانایی های گروه داره
معمولا یه مدیر میتونه هدایت کنه تیم رو

راجع به گسترش نرم افزار :
هرچه قدر ماژولار و خورد و با کلاس بندی بنویسی میشه بدون مشکل گسترش داد
با این روش باگ کمتر - دیباگ راحت و خوانایی بالا تر دست یافت
و از repository استفاده کنید یا لوکال یا آنلاین - git بهترین بود واسه من

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

triton

کاربر فعال
ممنون دوست عزیز از پاسختون
من می خوام که تمام پروژه هام اصولی پیش بره از کوچیک گرفته تا بزرگ(که فعلا هیچ کدومش موجود نیست!)
بیشتر دنبال یک روندم: از مرحله A به B، از B به C و ...
مثلا برای بحث uml بعد کلی گشتن به یک سری آموزش توی سایت ماکروسافت رسیدم که خیلی ازش استفاده بردم.
حالا هم بعد از این همه گشتن به تفکر Agile و اسکرام رسیدم که هر چی بیشتر می خونم کمتر سر در میارم! حالا اینکه چطور از این تفکر را در فلش استفاده کنم خودش یک مسئله شده ... برای من اینکه حتما از تفکر agile استفاده کنم مطرح نیست ... بلکه من یک سری قواعد می خوام که کارم را اصولی پیش ببره.


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

++Hadi++

Active Member
سلام
مسلما agile بهتره...
agile شمارو وادار می کنه که منتظر تغییرات باشید و مشتری بشه ارباب شما و اینکه از افرادی در پروژه استفاده کنید که علاقه زیادی به کارشون دارند و خودشون حرفه ای باشند و صاحب نظر و تجربه و علم کافی داشته باشند و اینکه همیشه بین خودتون (همه افراد از فنی تا پشتیبانی ) جلساتی بزارید.جلساتتون درباره اینه:
1- نکات و نقاط قدرت و مشکلات و عقب افتادگی هامون در چه مواردی بود؟
2-چه کارهایی رو از جلسه پیش تا به حال کردیم؟
3-چه کارهایی رو از الان تا جلسه بعد باید انجام بدیم؟
همچنین در این سبک ،باید هر کدوم از مهندسین ،هم آموزش دهنده خوبی باشند تا به خوبی نظرات و فوت و فن هاشونو به هم یاد بدند و به بهترین شکل ممکن ،از هم انتقاد کنند.هر کسی باید بدونه که در انتقاد ،باید خودشو بهتر کنه و نه اینکه در انتقاد ،گارد بگیره و حق به جانبانه فکر کنه فقط خودش درست می گه و کارش درسته...همچنین تا حد امکان افراد دخیل در پروژه به سختی باید کار کنند.
در ضمن ساختار های بهینه و بنیادی طراحی و مهندسی نرم افزار در فاز طراحی دو دید کلی هست: 1- ساختار یافته 2- شی گرا
در روش ساختار یافته ،در فاز طراحی همه چیز رو بالا به پایین می بینیم و در فاز پیاده سازی ،از مدلینگ تا طراحی کد ،همه چیز رو پایین به بالا پیاده سازی می کنیم.در روش OOP این روند دقیقا برعکسه...یعنی در طراحی پایین به بالا می بینیم و در پیاده سازی بالا به پایین...بنده از ساختار یافته استفاده های زیادی بردم...یعنی مثل اینکه اول پروژه رو استارت می زنیم و مثل نقشه گوگل ارث ،همه چیز از نیازها و .... رو از بالا می بینیم و بعد کم کم وارد جزئیات می شیم.در فاز شناسایی باید با همه افرادی که به پروژه و نیازها آشنایی دارند صحبت های حضوری داشته باشیم و تا حد امکان یادداشت برداری کنیم و از همه اهدافشون یه مپ در بیاریم...بعد سعی می کنیم تا از بالا ،بخش های اصلی رو جدا کنیم و روابط بینشونو به عنوان یه سیستم تحلیل کنیم و کم کم وارد جزئیات می شیم و کم کم وارد بخش های هر تکه اصلی می شیم و تا حد الگریتم و ... مدلینگ می کنیم.در فاز پیاده سازی هم باید از جز به کل برسیم.یعنی طراحی جزئیات و نوشتن کد یه بخش ...بعد تست جز به کل کلاسها(در مفهوم کانتینر) و اطمینان از روند درست بودن یه قسمت و کم کم در لول های بالاتر ،تست مجموعه ها در کنار هم و باز هم بالا تر ،تست قسمتهای اصلی در کنار هم ...در نهایت هم افراد غیر برنامه نویس که از نیاز ها و پروژه آشنایی دارند بیان و پروژه رو تست کنند.در سبک OOP و در فاز طراحی از پاین به بالا طراحی می کنیم.یعنی بعد از طراحی پروژه بر حسب نیاز ها ،در ابتدا کلاسهای جزئی رو طراحی می کنیم و به دنبال مفاهیم مشترک اونها می افتیم تا بتونیم اینترفیس ها رو در بیاریم و به یه سری مسایل کلی تر برسیم...معمولا تو برنامه نویسی هم بالا به پایین می یاییم یعنی از پیاده سازی اینترفیس ها و رسیدن به طراحی کلاسهایی که زیر اون اینترفیس ها هستند و ...یونیت تست همیشه به کارم اومده....
در مورد منبع استادمون این ترم ،کتاب مهندسی نرم افزار راجر اس پرسمن رو پیشنهاد دادند که البته بنده ترجمه آقای محمد مهدی سالخورده حقیقی رو خریدم و راضی بودم..در مورد پروژه های این سبکی هم چند نوع روند رو برا پروژه داریم که عبارتند از:
1- آبشاری
2-روند پروسس پروژه به شکل وی (V)
3-روند های تکاملی مثل حلزونی و ...
آبشاری برا وقتی هست که پروژه رو کاملا می شناسید و احتمال تغییرات روند پروژه خیلی کمه..روند V برا وقتی هست که پروژه رو کمتر می شناسید و احتمال تغییرات روند پروژه و نیاز به برگشت به مراحل نیازسنجی و طراحی و مدلینگ و پیاده سازی و تست بالاست...روش سومی هم برا مواقعی هست که پروژه رو اصلا نمی شناسید و احتمال تکاملش هست...برای مثال فرض کنید پروژه های شرکت گوگل رو انجام بدید که شاید تا حالا هیچ کسی مثل اونو انجام نداده ...البته روش های دیگه ای هم هستند...
در مورد انجام پروژه برای شرکت های بزرگ یا افراد بزرگ هم مسلما شک نکنید که استقرار همه افراد داخل پروژه درون شرکت با محوریت فیزیکی مسلم هست البته روشهای دیگه ای برای مدیریت با اسکایپ و ... هست ولی مسلما کنترل پروژه داخل محوریت فیزیکی ارزش مضاعفی رو داره...بهترین روندی رو هم که برای همدلی اعضای پروژه دیدم اینه که افراد مشتاق رو انتخاب کنند که حرفه ای هستند و هر کدومشون ،سود مادی خاصی رو از پروژه ببرند،سودی که شاید از نظر مدیر پروژه ناچیزه ولی برای خودشون با ارزشه...برای مثال شرکت گوگل به نسبت توانایی ها و تاثیرات افراد داخل پروژه ،درصد ناچیزی از سهام و سودشو به صورت درصدی بندی شده به این افراد می بخشید تا با علاقه و پشتکار بیشتری کار کنند...نکات زیاده ولی حتما این کتاب رو تهیه کنید...در ضمن بیشترین مقدار زمان و هزینه پروژه های بزرگ دنیا ،برای مرحله اول یعنی نیازسنجی هست...در مورد دادن زمان و هزینه به صورت نفر ساعت ،بنده شاهد بودم که فرد خبره و حرفه ایش هم اشتباه کرده ولی مسلما انتخاب افراد با تجربه در زمینه خاصش برای این قسمت از اهم واجباته...در مورد نوع پروژه هم فلش و غیر فلش ،چه ID و چه Builder نداریم،انتخاب ابزار مناسب تو همون قسمت اول هست و می تونه فلش باشه و نباشه...
موفق باشید...
 

triton

کاربر فعال
سلام
از زمان آغاز این پست تا حالا خیلی در منابع و ebookها گشتم و بالاخره به نتیجه رسیدم. انتخاب من اسکرام و تفکر agile بود و پس از کلی گشتن به کتاب Essential Scrum رسیدم که کتاب جامع ،و کاملترین منبع برای اسکرام هست و مثل بیشتر کتاب های هم حوزه خودش که بیشتر در دانشگاه های ما هم تدریس میشه، خسته کننده نیست بعد از خوندن شش فصل از این کتاب متوجه شدم که ترجمه ای هم از این کتاب با نام اصول و روش کاربردی اسکرام وجود داره که بر خلاف 99% کتاب های ترجمه شده، ترجمه نسبتا خوبی داره ( با توجه به فصل دوم که برای دانلود گذاشته شده) البته جلد اول این کتاب موجود هست و طبیعتا نصف ترجمه کتاب وجود داره. خوب بعد از اینکه متوجه شدید واقعا اسکرام چی هست (سوالی که زیاد من را درگیر کرد!) خوندن کتاب اسکرام و ایکس پی ساده شده هم در پیاده سازی اسکرام بسیار می تونه کمک کننده باشه.
در هر صورت این تجربه چند وقت اخیر من در مورد این موضوع بود که امیدوارم برای شما مفید و کمک کننده باشه و از دوستانی که به من کمک کردند نیز تشکر می کنم.
 

جدیدترین ارسال ها

بالا