مجموعه مباحث مهندسی نرم افزار 2

[Y@SiN]

با سلام خدمت تموم عزیزان ..!
از این به بعد در این بخش مطالبی در مورد مهندسی نرم افزار 2 ارائه می کنم..!
امیدوارم مورد توجه همه قرار بگیره.

تهیه و تنظیم : Y@SiN
باشگاه دانشجويان پيام نور

نكته: از دوستان اگر کسی به بحث مهندسی نرم افزار 2 حتی در سطوح دانشگاهی علاقه داره می تونه با دنبال کردن این بخش مرحله ی نخست مهندسی نرم افزار رو با موفقیت طی کنه.

[Y@SiN]

فهرست مطالب:
( فهرست مطالب به زودی اصلاح و کاملتر می گردد )







1. طراحي نرم‌افزار بي‌درنگ

2. طراحي واسط كاربر ui

3. توسعه سريع نرم‌افزار

4. : استفاده مجدد نرم‌افزار

5. مهندسي نرم‌افزار براساس قطعه

6. توسعه سيستمهاي حياتي

7. تكامل نرم‌افزار

8. وارسي و اعتبارسنجي

9. تست نرم‌افزار

10. اعتبارسنجي سيستمهاي حياتي

11. مديريت بر افراد

12. برآورد هزينه نرم‌افزار

13. مديريت كيفيت

14. بهبود فرآيند

15. مديريت پيكربندي

[Y@SiN]

مدل های فرآیند نرم افزار


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


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

مدل های نرم افزاری که قصد بحث در مورد آن ها را دارم عبارتند از :


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


http://pnu-club.com/imported/mising.jpg

2- توسعه تکاملی : این رهیافت، فعالیت های تعیین مشخصات، توسعه و اعتبارسنجی را جایگذاری (Interleave) می کند. یک سیستم اولیه با استفاده از مشخصات انتزاعی ساخته می شود. سپس این سیستم با ورودیهای مشتری اصلاح می شود تا سیستمی ایجاد شود که خواسته های کاربر را برآورده کند.


http://pnu-club.com/imported/mising.jpg


فرآیندهای مبتنی بر مدل آبشاری و توسعه تکاملی، برای توسعه ی سیستم های عملی به کار می روند.


3.مدل افزايشی:
ترکيب مدل خطی و مدل ساخت نمونه اوليه
در انتهاي هر ترتيب خطی يک محصول از نرم افزار ارائه می گردد.اولين محصول با نام محصول هسته ای (Core Product) به نيازمنديهای پايه ای پرداخته و پس از بازنگری توسط کاربر اصلاح و بهينه می گردد.


http://pnu-club.com/imported/2009/08/613.jpg


4.مدل حلزونی(Spiral Model):


http://pnu-club.com/imported/mising.jpg


نسخه اوليه از محصول در اين مدل نسخه ساده ای می باشد که در تکرارهای بعدی کامل می گردد. در اين مدل فعاليتها به شش دسته تقسيم می گرددکه هر کدام از آنها را با نام نواحی کاری(Work Area) می شناسند :
تعامل با مشتری و تعريف نيازمنديها : تعيين خواسته ها از جانب مشتری
برنامه ريزی (Planning) : تعيين اهداف ، آلترناتيوها و محدوديتها
تعيين منابع و ايجاد زمانبندی
آناليز ريسک : تحليل آلترناتيوها ، شناسائی ريسکها و راهکارهای مقابله با آنها
مهندسی (Engineering) : توسعه محصول سطح بعدی
ساخت و ارائه : ساخت ،آزمايش و انتقال ( تحويل مستندات ، آموزش و ...)
ارزيابی مشتری ( Customer Evaluation) : ارزيابی نتايج مهندسی

در تمامی مراحل فوق فعاليتهای چتری نيز به موازات اجرا می گردند.

http://pnu-club.com/imported/mising.jpg

مدل حلزونی برنده برنده(Win-Win):
در بخش تعامل با مشتری نيازمنديها از سوی مشتری می بايست مشخص شوند .جهت اين موضوع لازم است مشتری به يک موازنه (trade off) بين نيازمنديهای خود و تيم توسعه برسد. به عبارت ديگر موازنه ای بين عملکرد ، قابليتهای سيستم و کارائی از طرفی و هزينه و زمان از سوی ديگر برقرار نمايد. در اين شرايط تلاش می گردد اکثر نيازمنديهای مشتری در مقابل زمان و قيمت مناسب جهت تيم توسعه دهنده نرم افزار فراهم گردد(برد-برد). در مدل مذکور به جای بخش تعامل با مشتری و تعيين نيازمنديها قسمتهای زير جايگزين می گردد:
شناسائی واگذارنده و تعيين شرايط برد او
مذاکره جهت حصول به توافق ( در راستای قاعده برد – برد)

[Y@SiN]

انواع متدولوژی های نرم افزار:

1. ساخت یافته

این گروه شامل متدولوژی های زیر می شود...

IE
Jackson
SSADM


2. شی گرا

3. مولفه گرا

RUP

Perspective

که انواع متدولوژی ها رو در نرم 1 (http://njavan.com/forum/showthread.php?t=530) قبلا توضیح داده ایم.

در بحث متدولوژی های نرم افزار بحث مسئله تجزیه یک سیستم به Object ها پیش می آید که همین امر موجب بوجود آمدن متدولوژی شی گرا شد و همین متدولوژی به سرعت افزایش یافت و به صورت شکل در آمد ...

جنگ روش ها ( Method War ):

در بحث متدولوژی های شی گرا ، تفاهم نظری در بین گروه های کاری مختلف وجود نداشت برای همین هر گروه از روش خاصی برای نمایش متدولوژی های شی گرا جهت تجزیه ی یک سیستم استفاده می کردند که همین امر باعث سر در گمی ناظران خارجی میشد و یک نماد ممکن بود در گروه های 1 و 2 و 3 کاملا متفاوت باشد.

به عنوان مثال ممکن بود گروه اول نماد کلاس را با دایره و گروه دوم نماد کلاس را با لوزی شناسائی کند که این باعث Method War یا جنگ روش ها شد.

OMG ( مرجع بین المللی مقوله های مربوط به شی گرایی برای حل اختلاف ها و ... افتتاح شد.

و متدولوژی RUP برترین متدولوژی بود که در سال 2000 ساخته شد.

[Y@SiN]

متدولوژی RUP


این متدولوژی برترین متدولوژی بود که در سال 2000 ساخته شد.

در این متدولوژی از زبان UML استفاده می شود.

Unified Modeling Language ) UML ) : زبان مدلسازی این متدولوژی است که در دو ورژن موجود می باشد.

در ورژن UML 0.1 ما 9 دیاگرام داریم...

class diagram

Object Diagram

state Chart Diagram

Activity Diagram

Sequence Diagram

Use Case Diagram

Collaboration Diagram

Component Diagram

Deployment Diagram

اما در ورژن 2 UML تعداد 9 دیاگرام به 13 دیاگرام افزایش یافت که 4 دیاگرام جدید به شرح زیر است ...

Interaction Overviwe Diagram

Composition Diagram

Timing Diagram

Package Diagram

نمونه نمودار Timing برای قفل کارتی ...


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 744x411و حجم فایل 22KB استhttp://pnu-club.com/imported/mising.jpg


حالا نمودار ذوزنقه ای برای این است که تعداد حالات بیشتری را می توان نشان داد...


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 744x411و حجم فایل 26KB استhttp://pnu-club.com/imported/mising.jpg

[Y@SiN]

متدولوژی RUP


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

در این متدولوژی نرم افزار در 4 فاز تولید می شود.

1. فاز اول ادراک -Inception

در این فاز درک اولیه ای از سیستم مورد نظر مطرح است که باعث شده این سیستم برای نیازمندی ها و نقش اعظمی از نیازمندی ها ایده آل باشد.

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

2. فاز دوم مهارت - Elaburation

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

3. فاز سوم ساخت - Construction

در این فاز مدلهای طراحی کامل شده و مرحله کد نویسی یا طراحی و ساخت یک نرم افزار انجام می شود. در پایان این مرحله نرم افزار ساخته شده آماده استفاده می شود.

4. فاز چهارم گذار یا انتقال - Transaction

یکی از شاهکارهای متدولوژی RUP این فاز است که بسیار اهمیت دارد.
یک سیستم خوب سیستمی نیست که از نظر Functionality کامل و خوب باشد بلکه باید امکان استقرار در محیط کار ، کاربر را داشته باشد.

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

به عبارتی دیگر باید سیستم را برای آن محیط بومی کنیم.

[Y@SiN]

فعالیت های پایه ای در RUP


1) Bussiness Modeling

2) Requirement

3) Analysis design

4) Duple montation

5) Test

6) Change and Configuration Management

7) Project Management

8) Environment


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

نمودار فعالیتهای پایه ای :


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 775x452و حجم فایل 44KB استhttp://pnu-club.com/imported/mising.jpg


به طور کلی در متدولوژی RUP اولین کاری که باید بکنیم این است که Bussiness Modeling را طراحی می کنیم.

[honey]

سلام
میشه درمورد فعالیتهای طراحی رابط که توی فصل15 کتاب مهندسی نرم افزار آقای پرسمن هست یکم توضیح بدید.برای پروژه ام لازم دارم.:236:
ممنون:172:

[vahidb2007]

لطفا در مورد موارد زیر هم توضیح بدین >>>

تعاریف سیستم , انواع سیستم
تعاریف انواع سیستم
تعاریف فرآیند , نحوه نمایش و مثال هایی از فرآیند در سازمان
مقایسه متدولوزی rup & cdm oracl
تعریف یکپارچگی
انواع متدولوزی در مهندسی نرم افزار
بررسی متدولوزی agile
تعاریف معماری
انواع سیستم های اطلاعاتی
انواع سیستم های اطلاعاتی
مهندسی نیاز
هدایت پروزه های نرم افزاری
1مدیریت
2 کیفیت
3 وارسی اعتبار سنجی
4 پیکربندی

[Borna66]

خب ادامه ی آموزش ...

5 مدل برای ساختن Business Modeling نیاز است:

1. مدلسازی اهداف کسب و کار - Business Goal Modeling
2. مدلسازی منابع کسب و کار - Business Resource Modeling
3. مدلسازی نقش های کسب و کار - Business Role Modeling
4. مدلسازی قواعد کسب و کار - Business Rule Modeling
5. مدلسازی فرایندهای کسب و کار - Business Process Modeling

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

[Borna66]

1. مدلسازی اهداف کسب و کار ( Business Goal Modeling )

در این مدلسازی ما سعی می کنیم سازمان را به بخش ها و شاخه های یک درخت تشبیه کنیم و بر حسب قواعدی این شاخه را هرس کنیم تا به Root Goal برسیم.

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

مدل NFR:

با توجه به تصویر زیر ابتدا با برخی از علائم مدل NFR آشنا میشیم ....

http://pnu-club.com/imported/mising.jpg

همچنین با توجه به جداول زیر داریم ...

http://pnu-club.com/imported/mising.jpg

[Borna66]

2. مدلسازی منابع کسب و کار ( Bussiness Resource Modeling )



منابع و ارتباط بین آنها شناخته می شود و لذا قابلیت کنترل به راحتی فراهم می گردد.



http://pnu-club.com/imported/mising.jpg


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

3. مدل سازی نقش های کسب و کار ( (Business Role Modeling

مکانیزه شدن سیستم بانکی را در نظر بگیرید ، در سیستم امنیتی نگهبان بانک حذف شده و به جایش Network Admin داریم.
همچنین نقش ها به راحتی عوض شده و تحولی دار بانک به دستگاه ATM عوض می شود.

گاهی نیز در وظایف و نقش ها با هم در تعارض هستند که در چیدمان سیستم باید سعی در رفع این تعارضات باشیم و در نتیجه باید تمامی نقش ها همگرا باشد.

در همین جهت ممکن است نقش هایی از بین برود و نقش هایی اضافه شوند و یا نقش هایی تغییر کنند.


4. مدل سازی قواعد کسب و کار ( Business Rule Modeling ):

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

به طور مثال:
دو تیم مسابقه ی روبوت ها را در نظر داشته باشید

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

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

در نتیجه استفاده ی نادرست از قواعد بازی می تواند برای ما مشکل ساز باشد. http://pnu-club.com/imported/2010/08/8.gif

5. مدلسازی فرایند های کسب و کار ( Business Proccess Modeling ):

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



http://pnu-club.com/imported/mising.jpg

[Borna66]

سلام
میشه درمورد فعالیتهای طراحی رابط که توی فصل15 کتاب مهندسی نرم افزار آقای پرسمن هست یکم توضیح بدید.برای پروژه ام لازم دارم.:236:
ممنون:172:



لطفا در مورد موارد زیر هم توضیح بدین >>>

تعاریف سیستم , انواع سیستم
تعاریف انواع سیستم
تعاریف فرآیند , نحوه نمایش و مثال هایی از فرآیند در سازمان
مقایسه متدولوزی rup & cdm oracl
تعریف یکپارچگی
انواع متدولوزیدر مهندسی نرم افزار
بررسی متدولوزی agile
تعاریف معماری
انواع سیستم های اطلاعاتی
انواع سیستم های اطلاعاتی
مهندسی نیاز
هدایت پروزه های نرم افزاری
1مدیریت
2 کیفیت
3 وارسی اعتبار سنجی
4 پیکربندی


اين هم اندكي از پاسخ هاي سوالات شما

معماری و ساختار كلی RUP

فرایند انجام یک پروژه تعریف می‌کند که چه کسی، چه کاری را در چه هنگام و چگونه برای رسیدن به هدف (انجام پروژه) انجام می‌دهد. در مهندسی نرم‌افزار، هدف ساختن یک محصول نرم‌افزاری و یا بهبود یک نمونه‌ی موجود است. هدف از تعیین فرایند، تضمین کیفیت نرم‌افزار، برآورده شدن نیاز‌های کاربر و قابل تخمین بودن زمان و هزینه‌ی تولید می‌باشد. علاوه بر این، تعیین فرایند، روندی جهت تحویل مصنوعات دوران تولید نرم‌افزار به کارفرما و ناظر پروژه ارائه می‌دهد تا از این طریق اطمینان حاصل کنند که پروژه روند منطقی خود را طی می‌کند و نظارت درست بر انجام پروژه ممکن است و از سوی دیگر، معیاری برای ارزیابی پروژه انجام شده می‌باشد. تا كنون متدولوژی‌های مختلفی برای فرآیند تولید نرم‌افزار ارائه شده‌اند كه یكی از مشهورترین آنها RUP است.
RUP ، متدولوژی ارائه شده توسط شرکت Rational ، پرکاربردترین فرآیند تولید و توسعه نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای IT پذیرفته شده است. به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.
مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم‌افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می‌کند. از محاسن دیگر این متدولوژی مبنا قرار دادن نرم‌افزار و تولید یک معماری پایدار در ابتدای کار است، که در نتیجه امکان کشف مشکلات عمده ساختاری، تست و مجتمع سازی ممتد را از ابتدای کار فراهم می‌کند. از دیگر مزایای این روش این است که افراد تیم همزمان با پیشرفت پروژه، مطالب جدیدی فرا می‌گیرند و کیفیت فرآیند تولید نیز به طور مرتب افزایش می‌یابد.
همانطور كه در شكل بالا مشاهده می‌شود، RUP دارای دو بعد است:
1. محور افقی نشان دهنده‌ی زمان است و با پیشرفت خود جنبه‌های چرخه‌ی حیات فرآیند و فازهای RUP را نشان می‌دهد.
2. محور عمودی نمایانگر دیسیپلین‌های RUP است كه فعالیت‌ها را با استفاده از ماهیتشان به صورت منطقی دسته‌بندی می‌كند.
در هر فاز ممكن است یك یا چند تكرار وجود داشته باشد و در هر تكرار عملیات دیسپیلین‌های مختلف انجام می‌گیرند
فازهای RUP

فازها و milestone های یك پروژه در RUP
Inception (آغازین)

هدف اصلی این فاز دستیابی به توافق میان كلیه‌ی ذینفعان بر روی اهداف چرخه‌ی حیات پروژه است. فاز Inception به دلیل تلاشهای تولید و توسعه جدید به صورت پایه‌ای اهمیت فراوانی دارد كه در آن ریسك‌های نیازسنجی و تجاری مهمی وجود دارد كه باید پیش از اینكه اجرای پروژه مورد توجه قرار گیرد، بررسی شوند. برای پروژه‌هایی كه بر توسعه سیستم موجود متمركزند، فاز Inception كوتاهتر است، با اینحال این فاز برای حصول اطمینان از اینكه پروژه ارزش انجام دادن دارد و امكان‌پذیر نیز هست، انجام می‌شود. اهداف اصلی فاز آغازین شامل موارد زیر است:
• بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود
• مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند.
• نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی
• برآورد هزینه و زمان كلی برای كل پروژه
Elaboration (جزییات)

هدف فاز جزئیات تعیین معماری كلی سیستم به منظور فراهم آوردن یك زمینه‌ی مناسب برای قسمت عمده‌ی طراحی و پیاده‌سازی در فاز Construction است. معماری با درنظرگرفتن بیشتر نیازمندی‌های مهم (آن دسته از نیازمندی‌ها كه تأثیر زیادی بر معمار سیستم دارد) و نیز ارزیابی ریسك كامل می‌شود. پایداری معماری از طریق یك یا چند نمونه‌ی اولیه ساختاری ارزیابی می‌‌شود. اهداف اصلی فاز جزئیات شامل موارد زیر است:
• اطمینان از اینكه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی كافی پایدارند و ریسك‌ها به اندازه‌ی كافی كاهش یافته‌اند بطوریكه بتوان هزینه و زمان‌بندی لازم برای تكمیل تولید را پیش‌بینی كرد. برای اكثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یك عملیات سبك و سریع و با ریسك پایین به یك عملیات با هزینه و ریسك بالا همراه با اجبار سازمانی است.
• بیان همه‌ی ریسك‌های پروژه كه از نظر ساختاری اهمیت دارند.
• ایجاد یك معماری پایه، مشتق شده از سناریوهای مهم كه از لحاظ ساختاری اهمیت دارند، كه این معماری ریسك‌های فنی عمده پروژه را نیز مشخص می‌كند.
• تولید یك نمونه‌ی اولیه‌ی تكاملی از مولفه‌های با كیفیت تولیدی خوب، و همچنین یك یا چند نمونه‌ی اولیه‌ی اكتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت كاهش ریسكهای خاص مانند :
o سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی
o استفاده‌ی مجدد از مؤلفه‌ها
o عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و كاربران نهایی
• توضیح اینكه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌كند
• ایجاد یك محیط پشتیبانی كننده
Construction (ساخت)

هدف این فاز واضح سازی نیازمندی‌های باقیمانده و تكمیل تولید سیستم بر اساس معماری مبنا می‌باشد. فاز ساخت به نوعی یك فرآیند ساخت است كه در آن تأكید بر مدیریت منابع و كنترل عملیات به منظور بهینه‌سازی هزینه‌ها، زمان‌بندی‌ها و كیفیت است. در این حالت یك انتقال از تولید یك نمونه‌ی ذهنی در طی فازهای Inception و Elaboration به تولید محصولات قابل استقرار در طی Construction و Transition می‌شود. اهداف اصلی فاز Construction شامل موارد زیر می‌باشد:
• كمینه كردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌كاری غیر ضروری
• دستیابی هرچه سریعتر به كیفیت كافی
• دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست)
• كامل كردن تحلیل، طراحی، تولید و تست كارآیی مورد نیاز
• تولید تكراری و گام به گام یك محصول كامل كه آماده‌ی انتقال به محیط كاربران باشد
• تصمیم در مورد اینكه آیا نرم‌افزار، سایت‌ها و كاربران همه برای استقرار طرح آمادگی دارند
• دستیابی به میزانی از موازی سازی در كار تیم‌های تولید
Transition (انتقال)

تمركز این فاز بر این است كه تضمین نماید نرم‌افزار برای كاربران نهایی آماده می‌باشد. فاز Transition می‌تواند به چندین تكرار تقسیم شود، و شامل تست كردن محصول برای آماده‌سازی جهت انتشار و ایجاد تنظیمات كوچك بر اساس بازخورد كاربر می‌باشد. در این نقطه از چرخه‌ی حیات، بازخورد كاربر باید بطور عمده بر تنظیم دقیق محصل، پیكربندی، نصب و نكات مربوط به قابلیت استفاده تمركز یابد، و همه‌ی نكات ساختاری اصلی باید هرچه زودتر در چرخه‌ی حیات پروژه طرح شوند. با به اتمام رسیدن فاز Transition اهداف چرخه‌ی حیات باید برآورده شده باشند و پروژه در موقعیتی باشد كه بتوان آنرا خاتمه داد. در برخی موارد، پایان چرخه‌ی حیات فعلی ممكن است با آغاز چرخه‌ی حیات بعدی در مورد همان محصول همزمان شود و ما را به سمت تولید یا ویرایش دیگری هدایت كند. برای پروژه‌های دیگر، پایان فاز Transition ممكن است با تحویل كامل خروجی‌ها به گروه سومی كه ممكن است مسؤول عملیات نگهداری و پیشرفت سیستم تحویل دهده شده می‌باشند، همزمان شود. این فاز بر اساس نوع محصول در فاصله‌ی بسیار ساده تا بی‌نهایت پیچیده قرار دارد. نصب یك نسخه‌ی جدید از یك بسته نرم‌افزاری موجود ممكن است بسیار ساده باشد، در حالیكه جایگزینی سیستم كنترل ترافیك هوایی یك كشور ممكن است بسیار پیچیده باشد. فعالیت‌هایی كه در طول یك تكرار در فاز Transition انجام می‌گیرد به هدف بستگی دارند. برای مثال معمولاً در هنگام رفع اشكالات، پیاده‌سازی و تست كافی هستند. با این وجود اگر ویژگیهای جدیدی باید اضافه شوند، این تكرار شبیه به تكراری در فاز Construction می‌شود كه نیازمند تحلیل و طراحی و غیره است. فاز Transition زمانی وارد عمل می‌شود كه یك خط مبنا آنقدر بالغ شده كه بتواند در دامنه‌ی كاربر نهایی استقرار یابد. این امر بطور نمونه نیازمند این است كه تعدادی زیر مجموعه‌ی قابل استفاده از سیستم با كیفیت قابل قبول و مستندات كاربر، كامل شده باشند، تا انتقال به كاربر نتایج مثبتی را برای همه‌ی گروه‌ها در بر داشته باشد. اهداف مهم فاز Transition عبارتند از:
• تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات كاربر
• تست بتا و عملیات موازی همراه با یك سیستم قدیمی كه در حال جایگزینی می‌باشد.
• تبدیل پایگاه‌های داده‌ی عملیاتی
• آموزش كاربران و نگهداری كنندگان
• بازاریابی، توزیع و فروش برای نخستین انتشار محصول
• تنظیم فعالیت‌ها از قبیل رفع اشكال، افزایش كارایی و قابلیت استفاده
• ارزیابی خط مبناهای استقرار در مقایسه با تصویر كلی و معیار قابلیت قابل قبول برای محصول
• دستیابی به موافقت ذینفع در مورد اینكه خط مبناهای استقرار كامل می‌باشند
• دستیابی به موافقع ذینفع در مور اینكه خط مبناهای استقرار با معیار ارزیابی تصویر كلی سازگارند
دیسیپلین‌های RUP

دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام می‌شوند. متدولوژی RUP دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین كمكی (مربوط به تیم و محیط تولید) است كه در ادامه به ترتیب معرفی خواهند شد.
Business Modeling (مدل‌سازی كسب و كار)

هداف مدل‌سازی كسب و كار عبارتند از:
• شناخت ساختار و دینامیك‌های سازمانی كه در آن یك سیستم باید استقرار یابد(سازمان هدف.)
• شناخت مشكلات فعلی در سازمان هدف و تشخیص پتانسیل‌های بهبود
• تضمین اینكه مشتری، كاربر نهایی و تولید كنندگان یك شناخت مشترك از سازمان هدف دارند.
• هدایت نیازمندی‌های سیستم كه برای حمایت از سازمان هدف مورد نیازند.
• دیسیپلین‌ مدل‌سازی كسب و كار توضیح می‌دهد كه برای رسیدن به این هدف چگونه می‌توان یك تصویر كلی از سازمان را تولید نمود، و براساس این تصویر كلی فرآیندها، نقش‌ها و مسؤولیت‌های آن سازمان را در یك مدل Use-case كسب وكار و یك مدل شیء كسب و كار تعریف كرد
Requirements (نیازمندی‌ها)

اهداف دیسیپلین نیازمندی‌ها عبارتند از:
• تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد كارهایی كه سیستم باید انجام دهد.
• فرآهم آوردن شناخت بهتر از نیازمندی‌های سیستم برای تولید كنندگان سیستم
• تعریف مرزهای و حدود سیستم
• فراهم كردن یك پایه برای طرح ریزی مفاهیم تكنیكی تكرارها
• فراهم كردن یك پایه برای تخمین مخارج و زمان تولید سیستم
• تعریف یك واسط كاربر برای سیستم با تمركز بر روی نیازها واهداف كاربران
برای دستیابی به این اهداف، ابتدا فهم تعریف و محدوده‌ی مسأله‌ای كه سعی داریم با این سیستم آن را حل كنیم، حائز اهمیت می‌باشد. قوانین كسب و كارف مدل Use-Case كسب و كار و مدل شیء كسب و كار كه در طول مدل‌سازی كسب و كار تولید شده به عنوان ورودی با ارزشی برای این تلاش خواهند بود. در این راستا ذینفعان تشخیص داده می‌شوند و درخواستهای ذینفعان استخراج، جمع‌آوری و تجزیه و تحلیل می‌شوند. یك مستند تصویر كلی، یك مدل Use-Case ، Use-Case ها و مشخصه‌های تكمیلی برای توضیح كامل سیستم تولید می‌شود. این توضیح درواقع كاری را كه سیستم انجام خواهد داد بیان می‌كند. این مستندات بعنوان منابع مهم اطلاعات تولید می‌شود. در تولید این مستندات باید خواسته‌های همه ذینفعان را در نظر گرفت.
Analysis & Design (تحلیل و طراحی)

اهداف تحلیل و طراحی عبارتند از:
• تبدیل نیازمندی‌ها به طراحی سیستم كه قرار است بوجود آید.
• پیدایش یك معماری مستحكم برای سیستم
• سازگار ساختن طراحی برای هماهنگ شدن با محیط پیاده‌سازی و طراحی آن برای كارایی بهتر
در اوایل فاز Elaboration ، بر ایجاد یك معماری ابتدایی برای سیستم تمركز می‌شود، كه یك معماری كاندیدا برای فراهم كردن یك نقطه‌ی شروع برای تحلیل اصلی ارائه شود. اگر معماری قبلا وجود دارد (یا بدلیل اینكه در تكرارهای قبلی، در پروژه‌های قبلی تولید شده یا از یك چارچوب كاربردی بدست آمده)، تمركز كار برای اصلاح معماری، تحلیل رفتار و ایجاد یك مجموعه‌ی اولیه از عناصر است كه رفتار مناسب را فراهم می‌آورند
Implementation (پیاده‌سازی)

اهداف پیاده‌سازی عبارتند از:
• تعریف سازمان كد، برحسب زیر مجموعه‌ای از مجموعه‌های پیاده‌سازی سازمان یافته در لایه‌ها
• پیاده‌سازی كلاس‌ها و اشیاء بوسیله مؤلفه‌ها (فایل‌های منبع، باینری‌ها، فایل‌های اجرایی و...)
• تست اجزاء تولید شده به عنوان واحد‌ها
• مجتمع‌سازی نتایج تولید شده توسط پیاده سازان فردی‌ (یا تیم‌ها) به صورت یك سیستم قابل اجرا
دیسیپلین پیاده‌سازی مرز خود با تست را به اینكه تك تك كلا‌س‌ها چگونه تست واحد می‌شوند، محدود می‌كند. تست سیستم و تست مجتمع سازی در دیسیپلین تست انجام می‌گیرد.
Test (آزمون)

دیسیپلین تست از بسیاری جهات مانند یك ارائه دهنده خدمات برای سایر دیسیپلین‌ها عمل می‌كند. تمركز اولیه تست كردن بر بررسی و ارزیابی كیفیت‌های محقق شده از طریق كارهای زیر است:
• یافتن و مستند كردن نقایص در كیفیت نرم‌افزار
• آگاهی دادن در مورد كیفیت نرم‌افزار بررسی شده
• اثبات اعتبار فرضیاتی كه در طراحی و مشخصات نیازمندی‌ها ساخته شدند، از طریق نمایش‌های واقعی
• تصدیق عملكردهای محصول نرم‌افزار همانطور كه طراحی شده است.
• تصدیق اینكه نیازمندی‌ها بدرستی پیاده‌سازی شده‌اند
یك تفاوت جالب ولی تاحدی ظریف میان دیسیپلین تست و سایر دیسیپلین‌ها در RUP این است كه تست گرفتن، اساسا وظیفه‌ی یافتن و ارائه ضعف‌ها در محصول نرم‌افزار را داراست. برای اینكه این تلاش موفقیت‌آمیز باشد، لازم است از یك روش نسبتا منفی و مخرب استفاده شود تا روشی سازنده. مسأله‌ای كه بسیار حائز اهمیت می‌باشد این است كه از دو روش اجتناب كنیم : یكی روشی كه بطور مناسب و موثر نرم‌افزار را بكار نگیرد و مشكلات و ضعف‌های آن را نشان ندهد و دیگری روشی كه آنقدر مخرب است كه احتمالا هیچگاه كیفیت محصول نرم‌افزاری را قابل قبول درنظر نمی‌گیرد.
Deployment (استقرار)

دیسیپلین استقرار فعالیت‌هایی را توضیح می‌دهد كه تضمین می‌كنند محصول نرم‌افزاری برای كاربران نهایی‌اش در دسترس می‌باشد. دیسیپلین استقرار سه حالت استقار محصول را توضیح می‌دهد.
• نصب اختصاصی
• آماده فروش كردن محصول نهایی
• دستیابی به نرم‌افزار از طریق اینترنت
در هر نمونه، تأكید روی تست محصول در سایت تولید است و سپس انجام تست بتا، پیش از اینكه محصول نهایتا به مشتری تحویل داده شود. گرچه فعالیت‌های استقرار در فاز Transition به منتها درجه‌ی خود می‌رسند، اما برخی از فعالیت‌ها در فازهای قبلی برای طرح‌ریزی و آمادگی جهت استقرار انجام می‌‌شوند.
Environment (محیط)

دیسیپلین محیط بر فعالیت‌هایی كه برای پیكربندی فرآیند برای یك پروژه لازم و ضروری‌اند، متمركز می‌شود. این دیسیپلین فعالیت‌های مورد نیاز برای تولید رهنمودهایی كه در جهت پشتیبانی از یك پروژه لازم می‌باشند را توضیح می‌دهد. هدف فعالیت‌هایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری كه تیم تولید را پشتیبانی می‌كنند) برای سازمان تولید كننده نرم‌افزار می‌باشد.
جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیكربندی یك فرآیند فراهم می‌كند. این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP می‌شود.
Project Management (مدیریت پروژه)

مدیریت پروژه نرم‌افزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسك و غلبه بر محدودیت‌ها برای تحویل موفقیت آمیز محصولی است كه هم نیازهای مشتریان ( كسانی كه برای سیستم پول می‌پردازند) و هم نیازهای كاربران را برآورده كند. این حقیقت كه پروژه‌های بسیار كمی هستند كه واقعا موفقیت‌آمیزند برای توضیح سخت بودن این كار، كافی می‌باشد
اهداف این دیسیپلین عبارتند از:
• فراهم كردن یك چارچوب برای مدیریت پروژه‌های صرفاً نرم‌افزاری
• فراهم كردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژه‌ها
• فراهم كردن یك چارچوب برای مدیریت ریسك
• با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست. برای مثال این دیسیپلین موارد زیر را پوشش نمی‌دهد :
* مدیریت افراد : استخدام، آموزش، رهبری
* مدیریت بودجه : تعیین، تخصیص و غیره
* مدیریت قراردادها :‌ با پشتیبانی كنندگان و مشتریان
این دیسیپلین بطور عمده روی جنبه‌های مهم یك فرآیند تكراری تمركز می‌كند كه عبارتند از :
* مدیریت ریسك
* طرح ریزی برای یك پروژه‌ی تكراری، از طریق چرخه‌ی حیات و برای یك تكرار بخصوص
* نظارت بر پیشرفت یك پروژه‌ی تكراری و متریك‌ها
Configuration & Change Management (مدیریت پیكربندی و تغییرات)

برای تأویل و تفسیر ”مدل بلوغ قابلیت“ انستیتو مهندسی نرم‌افزار( SEI CMM )، مدیریت پیكربندی و درخواست تغییر، تغییرات را به سمت خروجی‌های یك پروژه كنترل می‌كند و همچنین صحت و تمامیت خروجی‌های پروژه را حفظ می‌كند.
مدیریت پیكربندی و درخواست تغییر ( CRM, CM ) شامل موارد زیر می‌باشند:
• تشخیص موارد پیكربندی
• محدود كردن تغییرات آن موارد
• رسیدگی به تغییراتی كه برای آن موارد ساخته شده
• تعریف و مدیریت پیكربندی آن موارد
متدها، فرآیندها و ابزاری كه برای ایجاد تغییر و مدیریت پیكربندی برای یك سازمان استفاده می‌شوند، می‌توانند بعنوان سیستم CM سازمان مورد توجه قرار گیرند.
سیستم مدیریت پیكربندی و درخواست تغییر (سیستم CM ) برای یك سازمان اطلاعات كلیدی در مورد تولید محصول را نگهداری می‌كند. این اطلاعات عبارتند از : ‌ترفیع، استقرار و فرآیندهای نگهداری. بعلاوه یك پایگاه داده محصولاتی را كه بصورت بالقوه قابل استفاده مجدد می‌باشند، نگهداری می‌كند.
یك سیستم CM برای كنترل خروجی‌های متعدد تولید شده توسط افراد زیادی كه روی یك پروژه كار می‌كنند، ضروری است. كنترل، به اجتناب از اغتشاشِ پرهزینه كمك می‌كند و تضمین می‌نماید كه خروجی‌های بدست آمده با توجه به برخی انواع مسائل و مشكلاتی كه در زیر آمده‌اند ناسازگار نیستند.
• به روز رسانی همزمان
• توجه دادن محدود شده
• نسخه‌های چندگانه

[Borna66]

آزمون نرم افزار ( Software Testing ):
در مباحث آزمون نرم افزار دو نوع روش داریم ...

که این دو نوع روش هر کدام به سه نوع آزمون مجزا نیز تقسیم می شوند ...

1. روش های مبتنی بر White Box
- آزمون مسیرهای پایه ( Basic Path Testing )
- آزمون شرط ( Condition Testing )
- آزمون حلقه ها ( Loop Testing )

2. روش های مبتنی بر Black Box
- افراز به مجموعه های معادل ( Equivalent Partitioning )
- تحلیل مقادیر مرزی ( Boundry Value Analysis )
- آزمون مقایسه ای ( Compairison Testing )

در روش مبتنی بر White Box ما فرض می کنیم کل سیستم در یک جعبه ی شیشه ای قرار دارد که تمامی جزئیات سیستم برای ما قابل مشاهده و لمس است. ( در این روش هزینه ، زمان و دانش بالائی نیاز است )

در روش مبتنی بر Black Box ما فرض می کنیم تمامی سیستم در داخل جعبه ی تاریک قرار دارد و هیچ کدام از جزئیات آن قابل مشاهده نیست و ما برای تست تنها باید با توجه به دادن ورودی های بخصوص و دریافت خروجی ها بررسی کنیم که ورودی مربوطه با خروجی دریافتی یکسان است یا نه ...! ( در این ورش هزینه ، زمان و دانش پائینی نیاز دارد )

چون معمولا توانایی این رو نداریم که سیستم رو کاملا به صورت White Box تست کنیم بنابراین بخش هایی رو به صورت White Box و بخش هایی رو با روش Black Box تست می کنیم که به آن روش Hybrid می گویند.

مقوله ی 80-20: مقوله ای در مهندسی نرم افزار هست که می گوید معمولا همیشه 20 در صد از بخش های نرم افزار 80 درصد از خطاها را دارند و 80 درصد باقیمانده تنها 20 درصد از خطاها را دارند.

در مباحث بعدی به ترتیب آزمون های Black Box و White Box را به ترتیب تک تک بررسی و نحوه ی تست نرم افزاری را آموزش می دهیم ... http://pnu-club.com/imported/2010/08/8.gif

[Borna66]

آزمون های مبتنی بر White Box


1. آزمون های مسیرهای پایه:

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

http://pnu-club.com/imported/mising.jpg


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


http://pnu-club.com/imported/mising.jpg

برای پیدا کردن تعداد مسیرهای پایه در گراف بدست آمده سه روش موجود است ...

1. تعداد مسیرهای پایه = تعداد یالها - تعداد گره ها +2

در مثال بالا بدست می آید ...
9-8+2 = 3

2. تعداد مسیرهای پایه = تعداد گره های شرطی +1

در مثال بالا بدست می آید ...
2 + 1 = 3

3. تعداد مسیرهای پایه = تعداد مسیرهای بسته + 1

در مثال بالا بدست می آید ...
2 + 1 = 3

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

آدرس مسیر اول : 1 --> 2 --> 3 --> 8
آدرس مسیر دوم : 1 --> 2 --> 3 --> --> 4 --> 5 --> 7 --> 3 --> 8
آدرس مسیر سوم: 1 --> 2 --> 3 --> 4 --> --> 6 --> 7 --> 3 -->8

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

همچنین مسیر های جدید با توجه به یالهای پیمایش نشده حساب می شود. ( یعنی تا زمانی که یال پیمایش نشده موجود باشد یعنی مسیر جدید باید داشته باشیم ).

پس با توجه به فرمولهای بالا و با توجه روش عملی دیدیم که تعداد مسیرهای پایه در گراف بدست آمده به راحتی با توجه به سه فرمول ارائه شده قابل محاسبه است ...

[bahar_7]

با سلام خواهشا ادامه تکنیک های آزمون نرم افزار را بر روی سایت قرار دهید!
نیاز فوری

[Borna66]

با سلام خواهشا ادامه تکنیک های آزمون نرم افزار را بر روی سایت قرار دهید!
نیاز فوری
با سلام
چشم دوست عزيز اگر مجالي بايد حتما:172:
اما شما مي تونيد براي دريافت اطلاعات بيشتر در اين زمينه كتاب الكترونيك زير كه كم حجم هم بوده و د مورد مباحث آزمون در مهندسي نرم افزار 2 دانلود و استفاده نمايد:109:
لينك دانلود (http://powerpoint.pnu.ac.ir/dbs/Computer/Mohandesi%20Narm%20Afzar%202/Ahmad%20Farahi/MOHANDESI_NARMAFZAR%28Farahi%29.ppt)

موفق باشيد

روزگار خوش

[sun88313]

سلام
لطف می کنید در مورد سناریو آز مهندسی پروژه دفتر داری دبیرستان برام توضیح بدید

[imanbajelan]

سلام
اگه لطف کنید مثالی در مورد درخت اهداف
زمانبندی پروژه با مدل کوکومو2
رو برامون توضیحی بدهید
ممنون

[Borna66]

سلام
اگه لطف کنید مثالی در مورد درخت اهداف
زمانبندی پروژه با مدل کوکومو2
رو برامون توضیحی بدهید
ممنون

با سلام
اين هم موارد درخواستي شما دوست گرامي

از ادرس زير اين مورد را دريافت كنيد

زمانبندی با استفاده از معادلات کوکوموی 2 (http://forum.2rood.ir/showthread.php?tid=14398)


روزگار خوش