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

اوایل ZeroTurnaround رو فقط از محصول پر سرو صداش JRebel می شناختم (که البته هیچ وقت قسمت نشد باهاش کار کنم!) ولی از وقتی فید مطالب و مقلاتشون رو هم می خونم خیلی بیشتر ازشون خوشم اومده.

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

شاد باشید.

استفاده از امکانات Subversion در Microsoft Word

در حال حاضر تقریبا تمامی محیط های برنامه نویسی یا بصورت مستقیم و یا با استفاده از plug-in از Subversion پشتیبانی می کنند. مشکلی که من در روزهای گذشته داشتم این بود که می خواستم درون نرم افزار Microsoft Word نیز بتوانم همانند محیط های برنامه نویسی فایل های ویرایش شده را برروی سرور commit و یا update کنم و بتوانم از دستوراتی مانند diff استفاده کنم.
برای این کار قاعدتا باید دنبال plug-in برای Microsoft Word می گشتم ، پس از کمی جستجو msofficesvn را پیدا کردم (البته بدلیل اینکه میزبان این پروژه سایت Google Code می باشد برای ایرانیان قابل دسترسی نیست و باید از پ-ر-و-ک-س-ی استفاده کنید).
این plug-in از نرم افزار TortoiseSVN برای انجام عملیات خود استفاده می کند و مراحل نصب آن نیز سرراست می باشد ، البته امکانات و دستورات این plug-in به اندازه امکانات محیط های برنامه نویسی کامل نمی باشد.

شاد باشید.

open-closed principle in object oriented design

The open-closed principle states that a software module should be:

• Open for extension — It should be possible to alter the behavior of a module or add new features to the module functionality.
  

• Closed for modification — Such a module should not allow its code to be modified.

In a nutshell, the open-closed principle helps in designing software modules whose functionality can be extended without having to modify the existing code.

resource: Software Architecture Design Patterns in Java by Partha Kuchana (April 22, 2004)

فرمول موفقیت در اهداف

این هفته در مجله موفقیت (شماره 167) یک مطلبی تحت عنوان "فرمول موفقیت چیست ؟" خوندم ، نکته های جالبی در این مطلب بود که فکر می کنم برای مدیریت هر پروژه ای مفید است. به نظر من اعضای یک تیم پروژه با رعایت تمامی موارد ذکر شده می توانند یک پروژه را با موفقیت شروع کرده و به اتمام برسانند.
اما این مراحل عبارتند از:

1. تصمیم
2. دانایی
3. نقشه راه
4. عمل
5. پشتکار
6. پایداری
7. احتیاط

البته به نظر بنده بهتر است این مراحل را بصورت تکراری (iterative ) انجام دهیم ، بدین معنی که وقتی یک بار از مرحله اول به مرحله آخر رسیدیم مجددا از مرحله اول شروع کنیم و به بازبینی و اصلاح بپردازیم.

شاد باشید.

use case slice در AO = Aspect Oriented

در توسعه نرم افزار با روش Aspect Oriented مفهومی با نام use case slice وجود دارد که به توسعه دهندگان کمک می کند که پیاده سازی use case ها را از یکدیگر جدا کنند و با این کار use case های درون سیستم با یکدیگر overlap نداشته باشند. بمنظور روشنتر شدن مطلب یک مثال عملی می آوریم:

در روش های (use case driven development) توسعه نرم افزار براساس use case مانند RUP فعالیت های زیر برای رسیدن به یک محصول خوب انجام می شود:
1. پیدا کردن use case ها و مشخص کردن جزئیات هر کدام از آنها.
2. طراحی هر کدام از use case.
3. طراحی و پیاده سازی هر کدام از کلاس ها.
4. آزمایش هر کدام از use case.

در شکل زیر دیاگرام use case سیستم فرضی رزرو هتل را مشاهده می کنید:

 

نکته: برای مشاهده عکس ها در سایز بزرکتر برروی آنها کلیک کنید.
در شکل بعدی مراحل و چگونگی رسیدن به کلاس های سیستم را با استفاده از روش های (use case driven development) توسعه نرم افزار براساس use case مشاهده می کنید:
 

 

نکته: برای مشاهده عکس ها در سایز بزرکتر برروی آنها کلیک کنید.
همانطور که در شکل بالا مشاهده می کنید پس از پایان مرحله سوم و پیاده سازی کلاس های سیستم ، مشاهده می کنیم که کلاس های سیستم overlap زیادی دارند بدین معنی که مثلا پیاده سازی یک use case مانند Reserve Room در چهار کلاس مختلف پخش شده است که این امر Modularity سیستم را پایین می آورد و اصلاح سیستم در آینده را دشوار می سازد.
اما در توسعه نرم افزار با روش Aspect Oriented پس از پیدا کردن use case های سیستم و Realize کردن آنها ، با استفاده از مفهوم use case slice و AOP = Aspect Oriented Programming ، جداسازی use case در زمان پیاده سازی بطور کامل رعایت می شود. برای روشنتر شدن مطلب به شکل زیر توجه کنید:
 

 

نکته: برای مشاهده عکس ها در سایز بزرکتر برروی آنها کلیک کنید.
همانطور که در شکل بالا مشاهده می کنید در واقع use case slice ها همان تکه های طراحی یک use case هستند که در کلاس های مختلف پخش شده بودند.
حال با استفاده از مفهوم aspect در AOP = Aspect Oriented Programming (مثال زیر با AspectJ است) که معادل با use case slice است ، هر کدام از use case slice های بدست آمده در مرحله قبل را پیاده سازی می کنیم.
 

 

نکته: برای مشاهده عکس ها در سایز بزرکتر برروی آنها کلیک کنید.
البته برای درک بهتر تکه کد بالا شما نیاز به اطلاعات ابتدایی در باره برنامه نویسی AspectJ دارید.
این یکی از مزیت های توسعه نرم افزار با استفاده از Aspect Oriented است که در حال حاضر بسیاری از شرکت های بزرگ برای تولید نرم افزارهای خود از آن استفاده می کنند (برای مثال : IBM برای تولید IBM WebSphere و Apple برای تولید Mac OS)
برای اطلاعات بیشتر کتاب Aspect-Oriented Software Development with Use Cases یک کتاب عالی در این زمینه می باشد که نویسندگان آن Ivar Jacobson, Pan-Wei Ng می باشند .

منبع:

Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series) by Ivar Jacobson and Pan-Wei Ng

شاد باشید.

 

معرفی کتاب Service Oriented Architecture (SOA) Compass IBM Press

Service Oriented Architecture (SOA) Compass IBM Press

تعداد صفحات: 272

قیمت: 44.99$

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

اطلاعات بیشتر

شاد باشید.

چگونگی راه اندازی سرور Subversion و استفاده از آن در Netbeans IDE

سیستمهای version control بمنظور مدیریت نسخه های مختلف هر گونه واحد اطلاعاتی جزو اساسی ترین ابزارها برای توسعه نرم افزار می باشد.
Subversion یکی از قوی ترین و محبوبترین سیستمهای version control می باشد. برای راه اندازی یک سیستم version control در محیط توسعه خود احتیاج به یک نسخه سرور و یک نسخه کلاینت subversion دارید و همچنین یک نرم افزار در سمت کلاینت که بتواند با استفاده از دستورات و کتابخانه های نسخه کلاینت subversion با نسخه سرور subversion تحت پروتکل های مختلف (در اینجا ما از پروتکل HTTP استفاده می کنیم) ارتباط برقرار کند.
مراحل راه اندازی :

1. دانلود نسخه سرور VisualSVN از سایت http://www.visualsvn.com/server/ و نصب آن برروی سرور. این توزیع subversion یک محیط ویژوال برای تعریف repository ، role ، user در اختیار شما قرار می دهد و کار با آن فوق العاده آسان می باشد.
2. اگر شما محیط توسعه یک نفره دارید و سرور Subversion برروی همان سیستمی که Netbeans نصب است نصب شده است نیازی به نصب CollabNet Subversion Command-Line Clientرا ندارید در غیر اینصورت آن را از سایت http://www.collab.net/downloads/subversion/ دانلود کنید و بروی سیستم خود نصب کنید.
3. در محیط Netbeans از منوی Tools گزینه Options را انتخاب کنید سپس در زبانه Miscellaneous زبانه versioning را انتخاب کنید در قسمت Subversion در جعبه متن Path to the executable file شاخه bin دایرکتوری نصب CollabNet Subversion Command-Line Client را وارد کنید (اگر محیط توسعه شما تک کاربره است و CollabNet Subversion Command-Line Client را نصب نکرده اید شاخه bin دایرکتوری نصب VisualSVN را بدهید)

به همین راحتی شما صاحب یک سیستم version control شده اید پس از تعریف repository در VisualSVN می توانید در محیط Netbeans و با استفاده از منوی versioning/subversion ازمزایای سیستم version control بهره ببرید.

نکته: برنامه نویسان .Net که از محیط visual studio استفاده می کنند با دانلود نسخه کلاینت VisualSVN می توانند از مزایای سیستم version control در محیط visual studio بهره ببرید.

شاد باشید.

لیست مخاطرات و ریسک ها در RUP (قسمت دوم)

انواع ریسک :

1. ریسک های مستقیم : ریسک هایی هستند که تحت حوزه فعالیت ما می باشند وبرای ارائه راه حل برای کنترل آنها می توانیم از حوزه اختیارات خود استفاده کنیم .
2. ریسک های غیرمستقیم : ریسک هایی هستند که تحت کنترل مستقیم ما نمی باشند و ارائه راه حل برای کنترل آنها نمی تواند مستقیم از سمت ما انجام شود .

استراتژی برخورد با ریسک :

1. اجتناب از ریسک : سازماندهی مجدد پروژه بطوری که پروژه تحت تاثیر ریسک ها شناخته شده قرار نگیرد .
2. انتقال ریسک : سازماندهی مجدد پروژه بطوری که مدیریت ریسک بر عهده چیزی یا کسی دیگر از اجزای پروژه باشد (مشتری و ...) این روش یک استراتژی خاص از نوع اجتناب از ریسک است .
3. پذیرش ریسک : تصمیم به زندگی با ریسک بعنوان یک موضوع محتمل الوقوع . کنترل دلایل ریسک و تصمیم گیری درمورد اینکه اگر ریسک بوقوع پیوست چه طرحی برای کنترل ریسک باید اجرا شود و همچنین ارائه طرح های پیشگیرانه .

----------------------------------------
مطالب مرتبط :
لیست مخاطرات و ریسک ها در RUP (قسمت اول)
----------------------------------------

لیست مخاطرات و ریسک ها در RUP (قسمت اول)

لیست ریسک ها (Risk List) یک محصول (Artifact) در RUP می باشد که شامل یک لیست مرتب (بصورت نزولی) شده از ریسک ها و مخاطرات شناخته شده در پروژه است . این لیست همچنین شامل راه حل های احتمالی برای کاهش هر کدام از ریسک ها می باشد .

وظیفه تهیه این محصول بر عهده مدیر پروژه می باشد و در ابتدای فاز Inception تهیه می شود و در ادامه فازهای پروژه ویرایش می شود . پیشنهاد می شود حداقل در انتهای هر Iteration این محصول مورد بازبینی قرار گیرد.
این محصول یکی از مهمترین محصولات RUP می باشد و به هیچ وجه حذف آن از فرایند تولید نرم افزار توصیه نمی شود . در مورد اهمیت این محصول همین بس که این محصول بعنوان ورودی برای 18 فعالیت RUP معرفی شده است .
این محصول خروجی فعالیت های زیر در RUP می باشد :

1. تشخیص و ارزیابی ریسک ها (Identify and Access Risks)
2. ارزیابی وضعیت پروژه (Monitor Project Status)
----------------------------------------
مطالب مرتبط :
ادامه مطلب (قسمت دوم)
----------------------------------------

TIOBE Programming Community

Hi

This is useful site for comparing programming language popularity .

TIOBE Programming Community

User Interface Prototype

Hi friends

User interface prototype is one of the most important artifact i have ever seen because this artifact is useful for almost all member of project team member . this artifact impact to the other artifact.
for example requirements specifiers can use this artifact for better gathering requirement of the project .
For creating user interface prototype we have to use Storyboard artifact and they have to be the same .

What is difference between Discipline & Workflow?

Hi friends

RUP mentions that Discipline is a concept for organizing Software Engineering Process and says a discipline is a collection of related activities that are related to a major 'area of concern' within the overall project and it helps to us for better understanding and easily management the process .
But RUP mentions that Workflow is a tool for expressing Software Engineering Process and a Workflow is a sequence of activities that produces a result of observable value . Workflow is useful for better understanding our task .

please insert ur comment .

bye

RUP defination ?

Hi friends

It is important that we know about RUP definition and use cases .

RUP definition : The Rational Unified Process, or RUP, is a software engineering process framework developed and marketed by Rational Software .