سلام بر دوستان  

این هم یک pdf در رابطه با Agile Software Development که متاسفانه نمی دونم از کیه . به هر حال اون واسه استفاده شما عزیزان گذاشتم و امیدوارم صاحب اثر هم راضی باشه . 

دانلود

با سلام خدمت کلیه دوستان  

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

با سلام مجدد خدمت دوستان  

در ادامه پست قبلی کل مطلب مربوط به طراحی چابکانه را آپلود کرده ام . 

امیدوارم مورد استفاده دوستان واقع شود . 

لینک دانلود 

طراحی نرم‌افزار از سال‌ها پیش در محافل  محققان و مهندسان نرم‌افزار مورد بحث است. معمولاً بحث در مورد این موضوع است که طراحی سیستم نرم‌افزاری بر اساس سورس‌کدهای نرم‌افزار استوار است و دیاگرام‌ها و طرح‌های ابتدایی می‌تواند در پیاده‌سازی نرم‌افزار به ما کمک کند، ولی نمی‌توان گفت تمامی مراحل طراحی یک نرم‌افزار به آن دیاگرام‌ها وابسته است. در واقع این بحث بیان می‌کند که سورس‌کدهای برنامه از دیاگرام‌های UML مجزا نیست.

اگر تا به حال در تیم‌های نرم‌افزاری حضور داشته‌اید و پروژه‌های نرم‌افزاری پیاده‌سازی نموده‌اید، حتماً با اشکالاتی، برخورد کرده‌اید. اگر خیلی خوش‌شانس باشید، در شروع پروژه مشتری یا همان کلاینت، اطلاعات دقیقی را از سیستمی که نیاز دارد در اختیار شما قرار خواهد داد. اگر خیلی زرنگ و باز خوش‌شانس باشید، در همان جلسه اول مصاحبه با مشتری می‌توانید تصویری کلی از نرم‌افزاری که قرار است تهیه شود را در فکر خود تجسم کنید و شروع به طراحی و پیاده‌سازی قسمت ابتدایی برنامه نمایید. با این حال صبر کنید؛ انگار با مشکلی روبه‌رو شده‌اید! بله کوچک‌ترین تغییری از طرف مشتری تمام برنامه شما را با مشکل روبه‌رو می‌سازد و پروژه شما دچار تغییراتی می‌شود. از جمله مشکلاتی که ممکن است برای شما پیش بیاید، می‌توان به موارد زیر اشاره کرد:

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

- کدهای نرم‌افزار ممکن است دچار تکرارهای غیرضروری شوند و قطعه‌ای از کد چندین بار در طول برنامه تکرار شود که در نتیجه باعث سردرگمی برنامه‌نویسان تیم خواهد شد و طبیعتاً تغییرات در برنامه را با مشکلاتی رو‌به‌رو خواهد کرد. مثلاً تصور کنید که در برنامه با اشکالی روبه‌رو شده‌اید و آن را مرتفع کرده‌اید، ولی وقتی برنامه را مجدداً کامپایل می‌کنید، متوجه می‌شوید برنامه باز اشکال دارد. در نتیجه مجبور می‌شوید تمام قسمت هایی را که این اشکال در آن وجود دارد، اصلاح کنید.

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

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

- معمولاً تغییرات در برنامه باعث شکنندگی سیستم نرم‌افزاری می‌شوند.

- معمولاً از آنجا که هر تغییر در برنامه باعث تغییراتی در قسمت‌های مختلف برنامه می‌شود،  تغییرات در سیستم‌های نرم‌افزاری معمولاً دشوار است.  

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

منبع : ماهنامه شبکه - خرداد ۱۳۸۶ شماره 76

سلام خدمت دوستان

"سلام،
از مطالبتون ممنون،
ولی ای کاش در مورد انوع ارتباطات کلاس و اینکه چطور میتوان نوع ارتباط رو تشخیص داد هم توصیح میدادید" 

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

**************************************************

انواع رابطه ها در کلاس دیاگرام 

با سلام  

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

اگر دوستان مایل باشند نظر آنها ذیل نظر مدیر قرار می گیرد .

سوال توسط آرش : 

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

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

 ****************************************************** 

نظر مدیر وبلاگ : 

حرف شما را قبول دارم . من هم این مطلب رو شنیدم . این امر چند دلیل می تواند داشته باشد .

1. باید مشخص بشود که با چه دیدی سیستم دارد تحلیل می شود . اولین نکته ای که من آن را گوش زد می کنم این است که تحلیل تا حدودی یک امر سلیقه ای است و دید افراد مختلف نسبت به یک سیستم هیچ گاه یکسان نیست . مثلاً در یک سیستم حقوق و دستمزد ، دیدی که یک مدیر نسبت به این سیستم دارد با دید یک حسابدار متفاوت است .
2. مهمترین دیدگاهی که در تحلیل سیستم باید به آن توجه کرد ، دید کاربر سیستم است و اگر تحلیل به خوبی انجام شده باشد نباید در تحلیل سیستم میان افراد متفاوت فرق چندانی باشد .
3. معمولاً بچه های نرم افزار از دید برنامه نویسی !!! به یک سیستم نگاه می کنند . یعنی اینکه پیاده سازی سیستم را بیشتر مد نظر دارند . من این مطلب را کاملاً تائید نمی کنم ولی اگر محیط برنامه نتواند به خواسته های کاربر پاسخ بدهد قطعاً سیستم به شکست بر می خورد .
4. تیم های نرم افزار حسب تجربه ای که در تهیه نرم افزار دارند مواردی را در نظر می گیرند که برنامه را کابر پسندتر جلوه می دهد که غالباً بچه های مهندسی صنایع بر آنها واقف نیستند .
5. چیزی دیگه ای که به نظر من می رسد این است که بچه های صنایع با برنامه نویسی و پیاده سازی نرم افزار آشنایی چندانی ندارند . به همین دلیل امکان دارد که در تحلیل خود مواردی را مطرح کنند که برنامه نویس آن را به شیوه دیگری پیاده سازی می کند .

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