X
تبلیغات
رایتل

Agile Software Development

یکشنبه 20 اردیبهشت‌ماه سال 1388 ساعت 03:36 ق.ظ

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

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

 

دانلود

طراحی چابکانه - Agile Software Desing (قسمت دوم)

سه‌شنبه 27 اسفند‌ماه سال 1387 ساعت 02:31 ق.ظ

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

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

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

 

لینک دانلود 

طراحی چابکانه - Agile Software Development (قسمت اول)

پنج‌شنبه 22 اسفند‌ماه سال 1387 ساعت 05:20 ق.ظ

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

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

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

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

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

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

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

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

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

 

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

انواع رابطه ها در کلاس دیاگرام و راههای تشخیص

سه‌شنبه 23 مهر‌ماه سال 1387 ساعت 02:22 ق.ظ

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

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

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

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

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

در کلاس دیاگرام چهار نوع رابطه وجود دارد که می توانید آنها را بین کلاسها برقرار کنید . association , dependency, aggregation , generalization

Association رابطه های معنایی بین کلاسها هستند که در نمودار کلاس بوسیله یک خط ساده به هم متصل می شوند .  وقتی یک association دو کلاس را به هم وصل می کند ، هر کلاس می تواند از طریق یک نمودار توالی یا همکاری به کلاس دیگر پیغام بفرستد . association می توانند دو طرفه یا یک طرفه باشند . با یک association ، رز(Rose) صفتها را در کلاسها قرار می دهد . برای مثال اگر یک رابطه association بین یک کلاس خانه و یک کلاس شخص وجود دارد ، Rose یک صفت شخص (Person) را درون خانه (House) قرار می دهد تا به خانه بگوید که چه کسی صاحب آن است و یک صفت خانه را درون شخص قرار می دهد تا به شخص بگوید صاحب چه خانه ای هستند .

 

   

Dependency شبیه به association ها هستند با یک تفاوت که همیشه یک طرفه هستند . Rose در یک رابطه Dependency صفتها را برای کلاسها تولید نمی کند . Dependency ها با فلش خط چین نشان داده می شوند . 

   

Aggregation ها یک فرم قویتر از association  ها هستند . یک Aggregation  یک رابطه بین یک واحد کل و بخشهای آن می باشد . برای مثال رابطه بین یک کلاس ماشین را در نظر بگیرید با یک کلاس موتور یا یک کلاس بدنه . aggregation  ها مانند یک خط با یک لوزی در کنار کلاسی که واحد کل را نمایش می دهد نشان داده می شوند . 

   

Generalization ها برای نشان دادن یک رابطه وراثتی بین کلاسها استفاده می شوند .  

    

پیدا کردن رابطه ها

1)     1) کار را با بررسی نمودارهای توالی و همکاری آغاز کنید . اگر کلاس A از طریق یک نمودار توالی یا همکاری پیامی را به کلاس B  بفرستد ، یک رابطه باید بین آنها وجود داشته باشد . معمولاً رابطه های که با این روش پیدا می کنید ، association یا dependency هستند .

2)    2) کلاسهایتان را بررسی کنید و به دنبال رابطه های کل به جزء بگردید . هر کلاسی که از سایر کلاسها تشکیل شده ، ممکن است در یک aggregation  شرکت کند .

3)    3) کلاس هایتان را بررسی کنید و به دنبال رابطه های generalization  بگردید . سعی کنید کلاسهایی را پیدا کنید که انواع مختلف داشته باشند . مثلاً در یک شرکت ممکن است کارمند به دوصورت ساعتی و حقوقی باشد ، در این صورت ما یک کلاس کارمند ساعتی و یک کلاس کارمند حقوقی داریم که هر کدام از یک کلاس کارمند ارث بری دارند .

4)    4) کلاسها یتان را برای یافتن رابطه های بیشتر generalization  بررسی کنید . سعی کنید کلاسهایی را پیدا کنید که مشترکات بسیار زیادی باهم دارند . مثلاً در یک دانشگاه هم دانشجو و هم استاد و هم کارمند از کلاس انسان ارث بری دارند .

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

فرق تحلیل مهندسین صنایع با مهندسین نرم فزار

یکشنبه 31 شهریور‌ماه سال 1387 ساعت 03:33 ق.ظ

با سلام  

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

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

 

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

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

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

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

 

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

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

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

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

 

--------------------------------------------------------------- 

نظر دوست عزیزمان یوسف : 

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

نمونه قرادادهای نرم افزاری

شنبه 30 شهریور‌ماه سال 1387 ساعت 03:23 ب.ظ

با سلام خدمت دوستان و عرض تسلیت به مناسبت ایام سوگواری مولی الموحدین حضرت علی (ع) و قبولی طاعات و عبادات شما عزیزان . 

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

نمونه قرارداد خدمات و نگهداری سخت افزار و نرم افزار  

قواعد اساسی در تنظیم قراردادهای انفورماتیک 

نمونه قرارداد تهیه نرم افزار

حلول ماه مبارک رمضان بر شما مبارک باد

سه‌شنبه 12 شهریور‌ماه سال 1387 ساعت 11:42 ب.ظ

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

حلول ماه مبارک رمضان بر شما مبارک باد . التماس دعا 

موفق باشید .

WSDM ( بخش دوم ) {یک روش طراحی مبتنی بر کاربر برای طراحی سایتها}

سه‌شنبه 22 مرداد‌ماه سال 1387 ساعت 12:41 ق.ظ

3- روش WSDM

          این روش از مراحل زیر تشکیل شده است: مدلسازی کاربر، طراحی مفهومی، طراحی پیاده‏سازی(ارائة طرح پیاده‏سازی) و مرحلة پیاده‏سازی.

مدلسازی کاربر از دو زیرمرحله تشکیل شده است: کلاس‏بندی کاربران و توصیف هر کلاس. طراحی مفهومی نیز دارای دو مرحله است: مدلسازی اشیاء و طراحی ناوبری. شکل 1 دیاگرامی از مراحل مختلف WSDM را نشان می‏دهد.

شکل 1

شکل 1

3-1- مدلسازی کاربر

          کاربران معمولاً وقتی یک سایت وب را ملاقات می‏کنند، سؤالاتی در ذهنشان راجع به این سایت وجود دارد. سایت وب باید این سؤالات را پیش‏بینی کرده و به آنها پاسخ مناسب دهد. لذا در اولین قدم ما روی کاربران بالقوه(آتی) سایت متمرکز می‏شویم.


ادامه مطلب ...

پروژه کامل تقاضای سیستم میکانیزه مطب با SSADM

پنج‌شنبه 17 مرداد‌ماه سال 1387 ساعت 03:31 ق.ظ

سلام دوستان

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

موفق و پیروز و شاد باشید.

دوستان عزیز لینک جدید در تاریخ 1390/03/08 گذاشته شده .

تقاضای سیستم میکانیزه مطب

یک ساله شدن وبلاگ مهندسی نرم افزار

پنج‌شنبه 10 مرداد‌ماه سال 1387 ساعت 02:42 ق.ظ

سلام دوستان

حدود یک سالی است که با این وبلاگ در خدمت شما عزیزان هستم . خدا را سپاسگذارم که در این مدت تونستم تا حدودی بعضی از دوستان را در پروژه هاشون راهنمایی کنم . ولی با این وجود فکر کنم خیلی بهتر از اینها می تونستم فعالیت کنم که متاسفانه درس و مشغله فکری و کاری اجازه نداد . البته سعی کردم به تمام ایمیل ها پاسخ دهم . خوب امیدوارم با نظرات سازنده خود مارا یاری کنید . در پایان از مسئولین بلاگ اسکای تشکر می کنم که این امکانات را فراهم نموده تا ما با سایر دوستان در ارتباط باشیم .

موفق باشید

( تعداد کل: 104 )
<<    1       2       3       4       5       ...       11    >>