بررسي و شناخت
متدولوژي RUP
زیر نظر استاد : دکتر ناصر مدیری
دانشجو : ليلا
خدابين
چکیده :
Rational Unified Process نام کاملترين فرآيند توسعه نرم افزار مي باشد که از ترکيب چند فرآيند ومتد
ديگر ايجاد شده و به اختصار به آن
RUP گفته مي شود. اين فرآيند بستر مناسبي براي توسعه مکانيزمهاي مديريتي در اختيار کسب و کارها
قرار مي دهد. با توسعه آن نسبت به نظام بهره مندي از تجربيات ديگر افراد و سازمانها
، فرآيند
ISRUP بستري مناسب براي بهبود مستمر کسب و کارها ايجاد مي کند.
براي تحليل طراحي و پيادهسازي سيستم مورد نظر از متدولوژي
RUP استفاده ميشود.
RUP يك فرآيند مهندسي نرمافزار است. اين فرآيند يك روش نظاممند براي تخصيص كارها و مسئوليتها
در يك تيم توسعه نرمافزار ميباشد و هدف آن توليد نرمافزار با كيفيت بالاست كه
نيازهاي كاربران نهايي را توسط يك برنامه و با بودجه قابل پيشبيني تأمين نمايد.
RUP يك فرآيند محصول
( Process
Product ) است كه
توسط شركت
Rational، تهيه و پشتيبان شده است. تيم توليد
RUP به منظور كسب آخرين تجارب و
تكاملهاي روز از نزديك با مشتريان و شركاء كار ميكنند. فرآيند
RUP بهرهوري تيم را با فراهم نمودن دسترسي تمام افراد تيم به
يك پايگاه دانش سهلالوصول به همراه راهنماها، الگوها و ابزارهاي كمكي براي همه
فعاليتهاي بحراني توسعه، افزايش ميدهد. با تأمين دسترسي همه اعضاي تيم به يك
پايگاه دانش، افراد در هر قسمت از يك زبان، فرآيند و ديد مشترك براي توسعه
نرمافزار برخوردار هستند. درفعاليتهاي
RUP، بجاي تمركز بر روي توليد
مستندات بزرگ كاغذي، مدلهايي توليد ميشوند كه بخوبي سيستم در حال توسعه را ارائه
مينمايند. فرآيند
RUP، راهنمايي براي استفاده
مؤثر از زبان يكپارچه مدلسازي،
UML ميباشد.
UML، زباني استاندارد براي تبادل شفاف نيازها، معماري و طراحي
است. زبان
UML در ابتدا توط شركت رشنال
ايجاد شد و هم اكنون توسط موسسه استانداردهاي
OMG ( Object Management Group ) پيشتيباني ميشود. فرآيند
RUP توسط ابزارهايي پشتيباني
ميشود كه هر يك بخشهاي بزرگي را فرآيند را به صورت خودكار انجام ميدهند. آنها
براي استفاده و نگهداري از محصولات متنوع- مخصوصاً مدلها- در فرآيند مهندسي
نرمافزار مورد استفاده قرار ميگيرند. فرآيند
RUP فرآيندي قابل شكلدهي است.
هيچ فرآيند واحدي براي همه نرمافزارها مناسب نميباشد فرآيندRUP، همانطور كه براي سازمانهاي بزرگ توسعه نرمافزار مناسب
ميباشد، براي تيمهاي كوچك نيز مفيد است. اين فرآيند ميتواند براي تطبيق موقعيتهاي
مختلف سازش پيدا كند. فرآيندRUP، چگونگي استفاده مؤثر
روشهاي تجاري براي توسعه نرمافزاري در گروههاي نرمافزاري را بيان ميكند. اين
روشها كه بهترين تمرينها(
Best
Practices ) ناميده
ميشوند به طور مشترك در همة صنايع مورد استفاده قرار ميگيرند.
کلمات کليدی :
RUP, Rational Unified Process,USDP, Unified Software Development Process, ISRUP,UML
مقدمه :
فرآيند توسعه ، يک چارچوب عمومي است که براي کليه پروژه ها صرف نظر از اندازه و
ميزان پيچيدگي آنها امکاناتي فراهم مي کند.
RUP يک فرآيند بزرگ صنعتي
( مخصوصا براي توسعه سيستمهاي نرم افزاري ) است که براي سهولت تفهيم آن،
کلياتي از آن بدون نام شرکت
Rational و بدون محرز کردن جريانهاي کاري مربوط
به فعاليتهاي حمايتي توليد نرم افزار و مدلسازي کسب و کار و بدون اشاره به قدرت
RUP که همان ابزارهاي حمايت کننده آن مي باشند در قالب فرآيند توسعه توسعه نرم
افزار يکنواخت شده (USDP) در دانشگاههاي معتبر جهان ظهور کرده
است در واقع مي توان گفت که
RUP نسخه پياده سازي شده اي از
USDP است.
USDP بعنوان يک فرآيند شي گراي توليد و توسعه سيستمها، داراي مدل فرآيندي است که
روند کلي توسعه را مشخص مي کند يک فرآينده توسعه سيستم حداقل بايد داراي ويژگيهاي
زير باشد :
● مشخص کردن ترتيب فعاليتها
● مشخص شود که چه محصولاتي در چه زماني توليد مي شود. ( محصولات مياني و نهايي
)
● مديريت وظايف توسعه دهندگان اعم از افراد يا تيمها معين باشد. ( نقشهاي مورد
نياز تيمها )
● معيارهايي براي اندازه گيري کيفيت محصولات پروژه و روند پيشرفت فعاليتهاي آن
فراهم باشد.
● امکانات بهرمندي از تجربيات موفق و ناموفق افراد و پروژه هاي ديگر در آن
فراهم باشد.
RUP چيست؟
با پيشرفت
تكنولوژي كامپيوتر، نياز هرچه بيشتر به گسترش علم نرم افزاري نيز احساس ميشد كه با
پيدايش متدولوژيهاي همانند
SSADM و روش آبشاري
آغاز شد. در ابتدا، اين روشها مناسب بود و جوابگوي نيازهاي
آن زمان بودند ولي با افزايش دادهها و پيدايش مفاهيمي همچون شبكه،
Web و ... ديگر كارآيي لازم را
جهت پيادهسازي و هدايت پروژههاي نرم افزاري نداشتند. پس مفاهيم برنامه نويسي
شيءگرا پا به عرصه وجود گذاشت و در سال 1991 بطور جدي مورد مطالعه و بحث قرار گرفت.
استفاده از اين روشها و متدهاي برنامه نويسي قدرت و انعطاف بسياري را به برنامهها
داد و شركتهاي نرم افزاري توانستند با كاهش هزينهها و بهينه سازي كدهاي خود، نرم
افزارهاي قويتري را به بازار عرضه كنند ولي اين روش جديد نيز نياز به مديريت و
يكپارچگي داشت. پس روشها و متدولوژيهاي جديدي مطرح شد كه شامل
Booch،
OMT،
OSE و ... ميباشد. در سال 2000
شركت
Rational روشي را تحت عنوان
(Rational Unfied Process) RUP مطرح ساخت
كه بعد از روش
MSF شركت مايكروسافت به دنياي
نرم افزار عرضه شد و امروزه از طرفداران بسياري برخوردار است.
Rational Unified Process :RUP
پالاينده
يكپارچه
Rational در اصل يك متدولوژي است كه در جهت كنترل و انجام پروژههاي
نرم افزاري در نظر گرفته شده است. در اصل اين چارچوبي در جهت انجام صحيح و موفق
پروژههاي نرم افزاري ميباشد كه كليه مراحل انجام يك پروژه كه با معماري و آناليز
سازمان شروع شده و به تست نرم افزار و ارائه
Gold Release ختم
ميشود را دربرميگيرد.
چرا ميگوييم يكپارچه:
به سه علت
RUP را
يكپارچه مينامند:
1 – اين
متدولوژي از يكپارچه سازي سه متدولوژي معروف ديگر بوجود آمده است كه شامل
Booch،
OMT و
OSE ميباشد.
2 – از
UML در جهت كارهاي خود استفاده
ميكند. در واقع ميتوان گفت
UML خود ثمره
RUP ميباشد و اين خود بسيار خوب است كه متدولوژيي با خودش
گسترش يابد.
3 -
مفاهيمي از قبيل
Object،
Class و ... مفاهيم ساده و ثابتي
هستند ولي قبلاً متدولوژيها علامتهاي خاصي داشتند كه اكنون همه آنها يكسان شدهاند.
منظور از
Process چيست؟
به ما
بگويند چه كسي، چه كاري را انجام دهد و چگونه انجام دهد. اين تعريف در حالت عمومي
ميباشد ولي از نظر علمي چه كسي تحليل را انجام دهد؟ چگونه تحليل كند؟ چه
Documentهايي را توليد كند.
Jack Hopson پالايند را بصورت ديگري تعريف ميكند :
Process عبارت است از يكسري فعاليتها كه نيازهاي خاص
كاربر را به يك محصول نرم افزاري ميرساند در اصل فرآيند نرم افزاري كه ما داريم از
يكسري پارامترها گرفته شده كه شامل موارد زير ميباشد:
·
تكنولوژي: منظور اين است كه 10 سال قبل چگونه بوده است و ما چه قابليتها و نيازهايي
داشتهايم و بعد چه امكاناتي بوجود آمده و در اختيار ما قرار گرفته و اكنون چه
نيازمنديهايي داريم؟
·
افرادي كه در پروژه يا سازمان ما كار ميكنند.
·
خود سازماني كه در حال توليد محصول ميباشد بايد نيازها و امكانات و معماري آن مشخص
شود.
RUP سالي دوبار توسط
Rational به روز ميشود. از مزاياي
RUP ميتوان به اين موضوع اشاره
نمود كه چون ميتواند بر پايه
Web باشد پس قابل
Customize ميباشد و ميتوان آنرا جهت استفاده همگان بر روي سايت
قرارداد. از طرفي مثل هر نرم افزار شيءگراي ديگري با
UML كاركرده و رشد ميكند.
براي تحليل طراحي و پيادهسازي سيستم مورد نظر
از متدولوژي
RUP استفاده ميشود.
RUP يك فرآيند مهندسي نرمافزار است. اين فرآيند يك روش نظاممند براي تخصيص كارها و مسئوليتها
در يك تيم توسعه نرمافزار ميباشد و هدف آن توليد نرمافزار با كيفيت بالاست كه
نيازهاي كاربران نهايي را توسط يك برنامه و با بودجه قابل پيشبيني تأمين نمايد.
RUP يك
فرآيند محصول ( Process
Product ) است كه
توسط شركت
Rational، تهيه و پشتيبان شده است. تيم توليد
RUP به منظور كسب آخرين تجارب و
تكاملهاي روز از نزديك با مشتريان و شركاء كار ميكنند.
فرآيند
RUP بهرهوري تيم را با فراهم نمودن دسترسي تمام افراد تيم به
يك پايگاه دانش سهلالوصول به همراه راهنماها، الگوها و ابزارهاي كمكي براي همه
فعاليتهاي بحراني توسعه، افزايش ميدهد. با تأمين دسترسي همه اعضاي تيم به يك
پايگاه دانش، افراد در هر قسمت از يك زبان، فرآيند و ديد مشترك براي توسعه
نرمافزار برخوردار هستند.
درفعاليتهاي
RUP، بجاي تمركز بر روي توليد مستندات بزرگ كاغذي، مدلهايي
توليد ميشوند كه بخوبي سيستم در حال توسعه را ارائه مينمايند.
فرآيند
RUP، راهنمايي براي استفاده مؤثر از زبان يكپارچه مدلسازي،
UML ميباشد.
UML، زباني استاندارد براي
تبادل شفاف نيازها، معماري و طراحي است. زبان
UML در ابتدا توط شركت رشنال ايجاد شد و هم اكنون توسط موسسه
استانداردهاي
OMG ( Object Management Group ) پيشتيباني ميشود.
فرآيند
RUP توسط ابزارهايي پشتيباني ميشود كه هر يك بخشهاي بزرگي را
فرآيند را به صورت خودكار انجام ميدهند. آنها براي استفاده و نگهداري از محصولات
متنوع- مخصوصاً مدلها- در فرآيند مهندسي نرمافزار مورد استفاده قرار ميگيرند.
فرآيند
RUP فرآيندي قابل شكلدهي است. هيچ فرآيند واحدي براي همه
نرمافزارها مناسب نميباشد فرآيندRUP، همانطور كه براي سازمانهاي
بزرگ توسعه نرمافزار مناسب ميباشد، براي تيمهاي كوچك نيز مفيد است. اين فرآيند
ميتواند براي تطبيق موقعيتهاي مختلف سازش پيدا كند.
فرآيندRUP، چگونگي استفاده مؤثر روشهاي تجاري براي توسعه نرمافزاري
در گروههاي نرمافزاري را بيان ميكند. اين روشها كه بهترين تمرينها(
Best Practices ) ناميده ميشوند به طور مشترك در همة صنايع مورد استفاده
قرار ميگيرند. فرآيند
RUP براي هر يك از اعضاي تيم،
راهنماها، الگوها و ابزارهايي مهيا ميكند كه تيم بهترين استفاده را از بهترين
تمرينهاي زير ببرد:
توسعه تكراري نرمافزار
مديريت نيازها
• استفاده از معماري مبتني بر مؤلفه
• مدل كردن تصويري نرمافزار
• بازبيني كيفيت نرمافزار
• كنترل تغييرات در نرمافزار
توسعه تكراري نرمافزار:
در سيستمهاي پيچيده امروزي انجام مراحل
تعيين تمام مسأله، طراحي تمام راهحل و ساخت تمام نرمافزا و در انتها تست كامل آن
به صورت متوالي ممكن نيست. در اينجا نياز به فرآيندي مكرر است كه اجازه فهم افزايشي
مسأله به همراه پيرايش آن و تكامل راهحل مؤثر را در طول چندين تكرار بدهد.RUP از روش، تكرار استفاده مي:ند كه اجزاء با ريسك بالا در هر
مرحله از چرخه حيات مشخص ميكند، و اين باعث كاهش ريسك ميشود. فرآيند تكراري
مقابله با ريسك را با نمايش پيشرفت فرآيند و نسخههاي اجرايي كه امكان درگيري و
بازخورد از كاربران، فراهم ميكند. همچنين فرآيند تكراري قابليت انجام تغييرات
تاكتيكي در نيازها، قابليتها و برنامهها را سبب ميشود.
مديريت نيازها:
فرآيند
RUP طريقة استخراج، سازماندهي و
مستند كردن عملكرد و شرايط مورد نياز دنبال كردن و مستند كردن موازنهها و
تصميمگيري و مبادله آسان نيازهاي كاري را بيان ميكند. همچنين اثبات شده است كه
ورش نمادي كه در آن مورد كاربرد وسناريوها مدل ميشوند، راهي مناسب براي گرفتن
نيازهاي كار كردي و اطمينان از تأمين نيازهاي كاربران توسط نهايي، ميباشد. مزيت
ديگر آن ايجاد رشتههايي منسجم و قابل رديابي درون سيستم در حال توسعه و تحويل شده
ميباشد.
استفاده از معماري مبتني بر مؤلفه:
مؤلفهها، ماژولها يا زير سيستمهاي هستند كه كاركردهاي مشخصي دارند.
RUP روشي سيستماتيك براي تعريف معماري با استفاده از مؤلفههاي
جديد و موجود ايجاد ميكند كه توسط يك معماري خوش ساخت، كه ميتواند بصورت
ad hoc و يا در يك چارچوب مؤلفهاي مانندCORBA و
COM سر هم شوند، ايجاد ميكند.
مدل كردن تصويري نرمافزار:
اين فرآيند چگونگي مدل كردن بصري نرمافزار به منظور ساختار و رفتار معماري و
مؤلفهها را نشان ميدهد. اين روش امكان پنهان كردن جزئيات و نوشتن كد توسط
سنگبناهاي گرافيكي را فراهم مينمايد.
بازبيني كيفيت نرمافزار:
دو عامل مهم و مشتركي كه امروزه سبب عدم پذيرش نرمافزارها ميشوند، قابليت اطمينان
پايين و كارآيي ضعيف ميباشد. فرآيندRUP در ايجاد برنامهريزي،طراحي
، پياده سازي و ارزيابي آزمايشهايي كه بر جنبههاي مختلف نرمافزار نظارت داشته
باشند، كمك مؤثري ميباشد.
ساختار
RUP
ساختار
RUP پيرامون چند منطق ساده و مرتبط به هم سازماندهي شده است:
-
RUP نقشهايي را تعريف
ميكند كه بايد در پروسه وجود داشته باشد و بر مبناي آن، صلاحيتها، تخصصها و
مسئوليتهاي افرادي كه بايد پيشرفت پروژه را محقق سازند، مشخص ميشود.
-
RUP كارهايي را كه هر يك از افراد بايد در
عمل انجام دهند، به طور گام به گام تشريح ميكند.
- اين عمليات با استفاده از
ابزارهايي واقعي مانند مدلها، كدها، اسناد و گزارشها اداره ميشوند.
- در
RUP به وفور با راهنماييهاي مربوط به
نقشهايي كه افراد بايد به عهده بگيرند، فعاليتهايي كه بايد انجام شوند و مصنوعات
مورد نياز برخورد خواهيد نمود كه در قالب خطوط راهنما، الگوها، مثالها و معلمهاي
ابزاري ارائه ميشوند كه چگونگي به وقوع پيوستن دستهاي از فعاليتها توسط يك ابزار
بخصوص را شرح ميدهند.
- تمامي اين المانهاي توصيف پروسه
در قالب منظومههايي سازماندهي شدهاند.
RUP مقدماتي نه منظومه، بيش از چهل نقش و صد
محصول را تعريف ميكند و حاوي بيش از هزار صفحه راهنما است. همچنين ميتوانيد به پروسههاي
الحاقي متعددي كه وظايف و مندرجات بيشتري را به
RUP اضافه ميكند، دسترسي پيدا كنيد. برخي
از منتقدين
RUP آنرا پروسهاي بسيار سنگين تصور نموده و آنرا به كرگدني تشبيه ميكنند كه توان
انجام تعداد نامحدودي عمل غير معمول را براي شما فراهم ميآورد؛ با اين وجود نگاه
ما به
RUP همانند لوح باشكوهي از معارف است كه ميتوانيد آنچه را كه نياز داريد، از داخل
آن برگزينيد.
اجازه بدهيد مقايسهاي انجام دهيم. اگر فرهنگ لغات مناسبي از 800 لغت را انتخاب
كرده باشيد، ميتوانيد در خيلي از نقاط دنيا و در بسياري شرايط، گليم خود را از آب
بكشيد؛ ولي با انتخاب فرهنگ لغات حجيمي چون
Webster ، اولاً هيچكس شما را مجبور به استفاده
از لغاتي كه در فرهنگ لغات وجود دارد نميكند، ثانياً ميتوانيد سطح ناطقه خود را
براي انطباق با وضعيتهاي مختلف ارتقا بخشيد و ثالثاً ميتوانيد فرهنگ لغات خود را
بهبود بخشيد. فرهنگ لغت800 لغتي بايد فقط زيرمجموعهاي از يك فرهنگ لغات باشد.
انطباق با
RUP
RUP يك اصل عقيدتي يا يك آيين مذهبي نيست. ساختار
RUP ساختار خشكي نيست كه بخواهد همه چيز را
براي توليد نرمافزار در قالب خود درآورد. نه، نيازي نيست كه حداقل چهل نفر را براي
تكميل پروسهاي كه چهل نقش در آن تعريف شده است، به خدمت بگيريد و نيازي نداريد كه
بيش از صد محصول مختلف را پرورش دهيد. اگر سعي خود را به انجام اين كار معطوف
سازيد، خيلي زود در معرض آشفتگي قرار خواهيد گرفت. اين المانها در
RUP و در فرم الكترونيكي براي فراهمآوردن انعطافپذيري مورد نياز براي انطباق با
تقاضايي ارائه شدهاند كه به شرايط محيطي كه درآن به سر ميبريد، بستگي دارد.
RUP تمرينات
توليد نرمافزار ثابت شده فراواني را دربر دارد. شركت
Rational ميدان ديد
بالايي را براي موارد زير، ارائه ميدهد:
- توسعه مكرر
- مدلسازي بصري
- مديريت ملزومات تغييرات كنترل
- بازبيني مداوم كيفيت
- استفاده از معماري بر مبناي اجزا
همچنين
URP بر مبناي ديگر اصول كليدي ديگري كه كمتر قابل مشاهده هستند و سادهتر به محاق
فراموشي سپرده ميشوند،
استوار شده است كه فقط براي يادآوري اشارهاي به آنها مينماييم:
- منحصراً آنچه را كه مورد نياز است، پرورش دهيد.
-
روي نتايج ارزشمند تمركز كنيد، نه روي چگونگي حصول نتايج
- كاغذبازي را به حداقل برسانيد.
- نعطافپذير باشيد.
- از اشتباهات خود عبرت بگيريد.
- به طور منظم، مخاطرات محتمل را مورد بازبيني قرار دهيد.
- براي پروسه موردنظر معيارهاي قابل اندازهگيري و علمي را بدون موضعگيري شخصي
استوار كنيد.
- از گروههاي كوچك و توانمند استفاده كنيد.
طرحي را در ذهن داشته باشيد.
ذهنيت كليدي در سازگار شدن و سازگار كردن
RUP
قالب توسعه (Development Case)
ميباشد. يك قالب توسعه نمونهاي از
RUP است كه براي پروژه ويژهاي كه مد نظرتان است، مناسب باشد. با
مراجعه به ساختار
RUP به توضيح پروسهاي دست مييابيد كه
موارد زير را تعريف نموده و شناسايي ميكند.
- چه چيزي توسعه داده خواهد شد؟
- به چه مصنوعاتي واقعاً نياز
داريم؟
- چه الگوهايي بايد مورد استفاده
قرار بگيرند؟
- كدام مصنوعات در حال حاضر وجود
دارند؟
- به چه نقشهايي نياز داريم؟
- چه فعاليتهايي انجام خواهند شد؟
- كدام خطوط راهنما، استانداردهاي
پروژه و ابزارهايي مورد استفاده قرار خواهند گرفت
در بسياري از شركت ها
حدود 30 تا 50 درصد هزينه توليد نرم افزار صرف تست آن مي شود.، هنوز هم خيلي از
افراد اعتقاد دارند كه نرم افزارها قبل از انتشار، به درستي تست نمي شوند. اين
شرايط به دو دليل به وجود ميآيد. اول اين كه تست نرم افزار امري بسيار مشكل است.
دوم اين كه تست معمولا" بدون متدولوژي مشخص و ابزار لازم انجام مي گيرد.
آنچه كه باعث مي شود تا
شركتها هزينه زيادي صرف تست نرم افزارها كنند، چيزي جز دستيابي به كيفيت مطلوب
نيست.
خصوصیتهای
RUP :
1-
مبتنی بر موارد قابل کاربرد
مدل موار قابل کاربرد بعنوان نمونه ای از مدل خواسته ها ، علاوه بر آنکه کل
وظیفه مندی سیستم را شرح میدهد ، اساس فعالیتهای بعدی یعنی طراحی ، پیاده سازی
و آزمون را نیز ایجاد میکند. بهمجموعه
ای از فعالیتهای قابل انجام که یک سیستم انجام میدهد تا یک نتیجه ی قابل مشاهده به
یک کاربر یا یک سیستم خارجی بدهد ، مورد قابل کاربرد می گوییم این موارد قابل
کاربرد، قابلیت استفاده و کاربرد مجدد و بهرمندی از سرویسها در سیستمهای همگون را
افزایش میدهد. ممکن است در این توالی فعالیتها ، دگرگونیهائی نیز وجود داشته باشد.
کاربر یا سیستم خارجی را عامل می نامیم . مدل مورد قابل کاربرد شامل عاملهای ،
موارد قابل کاربرد و ارتباطات بین آنهاست . این مدل همچنین شرح میدهد که سیستم برای
کاربران خود تحت شرایط متفاوت چه عملکردهایی می تواند داشته باشد.
2-
مبتنی بر معماری
معماری نرم افزار همانند معماری ساختمان است . معماری در حوزه ای بر بهره مندی
از تلفیق علم ، هنر و تجربه ، تکیه دارد. معماری نرم افزار مطابق نظر آقای
Kruchen
در معماری
4+1 از دیدگاههای
مختلف شامل دیدگاه مورد قابل کاربرد ، دیدگاه منطقی ، دیدگاه فرآیندها ، دیدگاه
استقرار و دیدگاه پیاده سازی تشکیل شده است .
3-
تکرار شونده و افزایشی
تکرار یعنی یکبار انجام دادن همه نظامهای یک فرآیند توسعه . یک پروژه
را به چندین پروژه کوچک ( مینی پروژه ) تقسیم نموده و در هر تکرار یکی از مینی
پروژه ها را تولید می کنیمو همانگونه که در شکل زیر دیده میشود .
RUP از دو بعد قابل بررسی می باشد: فازها و
نظامها ( جریانهای
کاری )
Workflow :
مجموعه
فعاليتهايي كه ما انجام ميدهيم تا به يك هدف تجاري كاري برسيم.
RUP به اين
Workflowها وابسته است و در هر مرحله نقش موثري را دارند.
اهداف فازهای
RUP
:
چنانکه در شکل بالا دیده میشود اگر از چپ به راست حرکت کنیم در راستای فازها
حرکت کرده ایم و چنانچه دیده میشود دارای چهار فاز آغازین ، تعیین ، ساخت و انتقال
است که هر فاز ممکن است از چندین تکرار تشکیل شده باشد. در ادامه به اهم اهداف
فازها به صورت خلاصه می پردازیم .
فاز آغازین :
اهداف اساسی این فاز عبارتند از :
·
مشخص
نمودن محدوده ی نرم افزار پروژه
·
مشخص
نمودن موارد قابل کاربرد و سناریوهای بسیار مهم
·
پیشنهاد
یک معماری کاندید برای موارد قابل کاربرد معرفی شده
·
تخمین
هزینه کلی و زمان پروژه
·
تعیین
ریسکهای بالقوه
·
فراهم
نمودن محیط و شرایط برای پشتیبانی پروژه
·
مشخص
نمودن محیط توسعه و تولید با توجه به الگوها.
فاز تعیین :
اهداف اساسی این فاز عبارتند از :
·
اطمینان
حاصل نمودن از اینکه معماری ، خواسته ها و تصمیمات به اندازه کافی پایدار شده اند
·
مشخص
نمودن ریسکهایی که از نظر معماری مهم اند.
·
ایجاد یک
معماری پایدار از سناریوهای اساسی و مهم
·
ایجاد یک
نمونه ی اولیه ثابل تکمیل شدن
·
بیان
اینکه معماری پیشنهاد شده خواسته های سیستم را با هزینه و زمان معقول پشتیبانی می
کند
·
فراهم
نمودن محیط برای پشتیبانی توسعه
·
تعیین
الگوهای موجود و الگوهایی که باید تهیه شوند در
CCB (Change Conrol
Board)
فاز ساخت :
اهداف اساسی این فاز عبارتند از :
·
به حداقل
رساندن هزینه های ایجاد با بهبود بخشیدن منابع و جلوگیری از دوباره کاری با بهرمندی
از الگوها
·
بدست
آوردن کیفیت کافی از طریق بهبود مستمر
·
رسیدن به
نسخه های مفید ( آلفا ، بتا و دیگر نسخه های آزمون )
·
تکمیل
تحلیل ، طراحی ، پیاده سازی و آزمون همه ی وظیفه مندیهای خواسته شده با توجه به
الگوها
·
ایجاد یک
محصول کامل با روش تکرار و افزایش و بهبود
·
تصمیم
گیری آنکه آیا نرم افزار ، سایتها ، کاربران برای تحویل محصول آماده هستند
·
دستیابی
به درجات بالای کار کردن بصورت گرئهی و موازی
فاز انتقال:
اهداف اساسی این فاز عبارتند از :
·
آزمون
بتا
·
انجام
عملیات موازی در مقایسه با سیستم قدیمی با توجه به ضد الگوهای مربوط به استقرار
سیستمهای جدید
·
تبدیل
پایگاه داده های عملیاتی
·
آموزش
کاربران و مسئولان مراقبت و نگهداری
·
بازاریابی با توجه به الگوها و چارچوبهای بازاریابی
·
هماهنگ
کردن فعالیتهائی مانند اصلاح عیبها، افزودنها بخاطر عملکرد و قابلیت استفاده ی
بالاتر
·
ارزیابی
آنچه مستقر شده در مقایسه با آنچه در چشم انداز مستند شده است.
·
تعلیم
کاربران به حدی که خود بتوانند سیستم را پشتیبانی کنند
·
کسب
تایید و رضایت افراد ذینفع پروژه.
جریانهای کاری
RUP :
RUP دارای 9 نظام است .
هر ترکیب متوالی یا موازی از آن فعالیتها به عنوان یک جریان کاری می تواند در قالب
یک نمودار فعالیت
UML نشان داده شود. اگر در نظامهای
RUP از بالا به پائین حرکت کنیم ، در راستای
جریانهای کاری ، یعنی بعد دیگر فرآیند حرکت کرده ایم. در هر جریان کاری تعدادی
فعالیت انجام میشود تا به یک مجموعه فرآورده های خاص برسیم . هر جریان کاری از یک
سری جزء فرآیند تشکیل شده است . این جزء فرآینده ها به ترتیب خاصی و گاه به صورت
موازی انجام میگیرد تا اهداف نظامهای مربوطه حاصل شود. بازنمایی توالی و توازی
انجام گرفتن جزءفرآیندها را نیز با یک نمودار فعالیت نشان خواهیم داد.
یک جزء فرآیند بیان میکند که چه فعالیتی توسط چه کسی انجام میگیرد و کدام
فرآورده ها تولید می شوند یعنی در یک جزءفرآیند ، نقشها ، فعالیتها و فرآورده های
مشخصی وجوددارد .
1-
جریان کاری مدلسازی فعالیتهای کسب و کار
چنانچه در شکل زیر دیده میشود جزء فرآیندهای موجود در این جریان کاری عبارتند
از :
1-
وضعیت
کسب و کار فعلی را ارزیابی کنید
2-
وضعیت
کسب و کار فعلی را تشریح کنید
3-
فرآیندهای کسب و کار را شناسائی کنید
4-
الگوهای
کسب و کار متناسب با حوزه کاری را تعیین کنید.
5-
فرآیند
های کسب و کار را بهبود دهید
6-
محقق
سازی فرآیندهای کسب و کار فعلی را طراحی کنید
7-
نقشها و
مسئولیتها را بهبود دهید
8-
در مورد
اتوماسیون فرآینده های کسب و کار تحقیق کنید
9-
به جای
انجام دادن جزء فرآینده های فوق می توانید مدل دامنه کسب و کار را ایجاد کنید و
آنرا توسعه دهید.
2-
جریان کاری مدیریت خواسته ها
مطابق شکلهای فوق ، جزء فرآینده های موجود در این جریان کاری عبارتند از :
1-
مساله را
تحلیل کنید
2-
خواسته
هاس افراد ذینفع را با استفاده از
IFD ( یاگرام جریان اطلاعات ) شناسائی کنید
3-
سیستم را
توصیف کنید
4-
محدوده ی
سیستم را مدیریت کنید
5-
توصیف
سیستم را بصورت تطبیقی بهبود دهید
6-
خواسته
های تغییر کننده را مدیریت کنید.
3-
جریان کاری تحلیل و طراحی
مطابق شکل زیر جزء فرآینده های موجود در این جریان کاری عبارتند از :
1-
یک
معماری کاندید از چارچوبهای موجود و قابل توسعه برای نرم افزار معرفی کنید
2-
رفتار را
تحلیل کنید
3-
اجزاء را
با بهره گیری از الگوها طراحی کنید
4-
اجزاء بی
درنگ را طراحی کنید
5-
پایگاه
داده را طراحی کنید
6-
معماری
نرم افزار را با توجه به قابلیت استفاده مجدد پالایش کنید.
4-
جریان کاری پیاده سازی
مطابق شکل فوق ، جزء فرآینده های موجود در این جریان کاری عبارتند از :
1-
مدل
پیاده سازی را ساختاردهی کنید
2-
در مورد
مجتمع سازی(Integration) تصمیم گیری کنید
3-
حتی
الامکان با استفاده از
idiom ها اجزاء را پیاده سازی کنید
4-
هر زیر
سیستم را مجتمع سازی کنید
5-
سیستم را
مجتمع سازی کنید.
5- جریان کاری آزمون
مطابق شکل زیر جزءفرآینده های موجود در این جریان کاری عبارتند از :
1-
در مورد
آزمون تصمیم گیری کنید
2-
آزمون را
زراحی کنید
3-
آزمون را
پیاده سازی کنید
4-
آزمون را
مجتمع سازی کنید
5-
آزمون
سیستمی را اجرا کنید
6-
آزمون را
ارزیابی کنید
6-
جریان کاری استقرار (Deployment)
مطابق شکل زیر جزءفرآینده های موجود در این جریان کاری عبارتند از :
1-
در مورد
استقرار ، تصمیم گیری کنید.
2-
موارد
قابل پشتیبانی را معین کنید
3-
آزمون
پذیرش را در سایت ایجاد مدیریت کنید ( در صورت رخ دادن درخواست تغییر)
4-
واحد
استقرار را با توجه به نحوه قرارگیری مولفه های نرم افزاری روی مولفه های سخت
افزاری ایجا کنید.
5-
در مرحله
ی آزمون بتا ، محصول آزمون بتا را تولید کنید.
6-
برای
تحویل به مشتری یکی از اعمال زیر را انجام دهید:
-
آزمون
پذیرش را در سایت نصب مدیریت کنید
-
محصول را
بسته بندی کنید
-
امکان
دسترسی به سایت را برا گرفتن نرم افزار فراهم کنید ( اگر محصول برای گرفتن از روی
سایت ایجاد شده است )
7-
جریان کاری مدیریت پروژه
مطابق شکل زیر جزءفرآینده های موجود در این جریان کاری عبارتند از :
1-
پروژه
جدید را درک کنید
2-
ریسکهای
عمومی پروژه ها را در نظر بگیرید
3-
ریسکهای
خاص پروژه و محدوده ی آنها را ارزیابی کنید
4-
مستند
توسعه نرم افزار را تولید کنید
5-
پروژه را
کنترل و مانیتور کنید
6-
برای
تکرار بعدی تصمیم گیری کنید
7-
تکرار را
مدیریت کنید
8-
فاز را
ببندید ( در انتهای فاز )
9-
پروژه را
ببندید ( در انتهای پروژه )
8-
جریان کاری مدیریت پیکربندی و تغییرات
مطابق شکل زیر جزءفرآینده های موجود در این جریان کاری عبارتند از :
1-
درباره
پیکربندی پروژه و کنترل تغییرات ، تصمیم بگیرید
2-
محیط و
شرایط مدیریت پیکربندی پروژه را فراهم کنید
3-
برای
محیط های توسعه با پراکندگی فیزیکی می توان از الگوهای مدیریت پیکربندی استفاده
کرد.
4-
فقره های
پیکربندی را تغییر داده و تحویل دهید
5-
نسخه ها
و خطوط پایه را مدیریت کنید
6-
وعیت
پیکربندی را در نظر داشته باشید و گزارش کنید
7-
درخواستهاس تغییر را مدیریت کنید.
9-
جریان کاری آماده سازی محیط
مطابق شکل زیر جزءفرآینده های موجود در این جریان کاری عبارتند از :
1-
محیط و
شرایط را برای بکارگیری بانک الگو در پروژه آماده کنید
2-
محیط و
شرایط را برای یک تکرار آماده کنید
3-
خطوط کلی
را برای یک تکرار آماده کنید
4-
محیط را
در طول یک تکرار پشتیبانی کنید
مفهوم تکرار :
در هر تکرار یکبار همه جریانهای کاری که هر کدام فعالیتهای مخصوص خود را دارا
می باشند انجام می گیرند. این نکته قابل توجه است که میزان تمرکز روی جریانهای کاری
در هر تکرار متفاوت است .
در هر تکرار ، توسعه دهندگان خواسته ها مربوطه را شناسایی و مشخص میکنند ، آنها
را با استفاده از راهنماییهایی که معماری انتخاب شده در اختیار قرار می دهد، طراحی
می کنند سپس طراحیها را بصورت اجزاء پیاده سازی نموده و صحت آنکه آیا اجزاء ایجاد
شده ، موارد قابل کاربرد را پیاده سازی می کنند یا خیر را بررسی می نمایند. در
تکرار بعدی ، توسعه دهندگان به سراغ موارد قابل کاربرد دیگری رفته و برای آنها نیز
یکبار اعمال فوق را انجام میدهند . هر فاز ممکن است دارای چند تکرار باشد ولی بطور
نوعی ، فاز آغازین دارای یک تکرار و فازهای تعیین و ساخت دارای تکرارهای بیشتری
هستند.
مفهوم معماری :
چرا قبلاً معماري نداشتيم:
1 – تعريف
دقيقي از آن وجود نداشت.
2 – ابزار
مناسبي نبود.
3 –
فرآيندي نداشتيم كه به ما حكم كند و ما را وادار به استفاده كند.
تعيين
معماري و نيازهاي سازمان جزء مهمترين بخشهاي هر متدولوژي مهندسي نرم افزار ميباشد
كه هدف و جهت حركت پروژهها ار مشخص ميكند.
معماري سه لايه
اين معماري
كه در اصل ميتوان گفت بعد از معماري
Client/Server بوجود آمد برگرفته شده از
ايده معماري چند لايه (Multi tire) ميباشد.
در اين معماري بر خلاف مدل دو لايه كه باعث افزايش ترافيك بر روي شبكه و كاهش شديد
انعطاف پذيري در سيستمها ميشود، پروژههاي نرم فازاري در سه لايه اصلي بنام
User Layer و
Business
Layer و
Data Layer طراحي و
پياده سازي ميشوند. اين سه لايه هر كدام وظايف جداگانه و خاص خود را دارند و
برگرفته شده از ايده
ICها در مدارات الكترونيكي ميباشد. زيرا در چنين سيستمهايي
كارشناسان ميتوانند در صورت تغييرات كه ميتواند كوچك يا بزرگ باشد در هر لايه اين
تغييرات را اعمال نمايند بدون اينكه نياز به تغيير در لايههاي ديگر باشد يا كمترين
تغييرات متوجه لايه ديگر ميشود. بعنوان مثال امروزه در سيستمهاي مدرن بانكي قوانين
تغييرات زيادي را دارند كه اگر از معماري دو لايه استفاده شود جهت اعمال اين
تغييرات نياز هه تغييرات فراواني در فايلهاي اجرايي (Clientها) يا بانك اطلاعاتي و نصب مجدد آنها براي تمامي كاربران در
شبكه ميباشد ولي در روش سه لايه اگر به فرض نرخ ارز يا فرمول محاسبه سود تغيير كند
با اعمال تغيير در لايه مياني (Business) و عوض كردن اين لايه با ويرايش جديد تمامي سيستمها بدون
آنكه متوجه تغيير شون و يا نياز به نصب مجدد داشته باشند ميتواند با سيستم جديد
ارتباط برقرار كنند.
User
Layer
:
لايه كاربر
در اصل همان برنامههايي ميباشند كه كاربران بصورت
Native يا
Web
Base با آنها ارتباط برقرار ميكنند تا نيازهاي خود را به سيستم
جهت اعمال تغييرات يا گرفتن گزارش ارائه دهند. اين لايه بطور كلي از قوانين موجود
در سيست مجدا ميباشد تنها كاربران ليستي از دادهها را ميبينند و يا دادههاي
جديد را به اين لايه توسط برنامههاي خد ارائه ميدهند و وظيفه اين لايه ميباشد كه
با دو لايه ديگر بنابر نياز ارتباط برقرار كرده و تقاضاي كاربران را به آنها تحويل
دهد يا نتيجه را از آنها بگيرد.
Business
Layer
:
اين لايه
شامل قوانين موجود در سيستم ميباشد. وظيفه اين لايه گرفتن اطلاعات از لايه كاربر و
كنترل آنها با قوانين يا اعمال قوانين بر روي آنها و ترجمه آنها به اطلاعات قابل
فهم براي لايه بانك اطلاعات (Data Layer) جهت ذخيره و بازيابي در
سيستم ميباشد. در واقع اين لايه نقش يك لايه ميانه را بازي ميكند.
Data
Layer
:
اين لايه
نقش ذخيره، بازيابي و بروزرساني اطلاعات را برعهده دارد كه دادهها را از لايه
Bussiness يا كاربر گرفته يا اطلاعات
درخواستي را با آنها تحويل ميدهد. البته كار با لايه كاربر در تئوري وجود دارد و
در عمل ثابت شده است كه هم از جهت امنيت و هم كارآيي سيستم را دچار مشكل ميكند
بنابراين در اين سيستمها ارتباط با لايه
Business ميباشد.ويژگي ديگر معماري
سه لايه امكان گسترش آن ميباشد. بدين معنا كه سرويس دهنده ما توان سرويس دهي به
100 گروه (Client) را داشته باشد ولي پس از مدتي ما به 200 گروه نياز داشته
باشيم بعلت جدابودن سرويس دهنده لايه مياني از لايه بانك اطلاعاتي ميتوان دو سرويس
دهنده لايه مياني را در شبكه قرارداد كه هر كدام به 100 كاربر امكانات ارائه
ميكنند كه اين از افزايش سربار و ترافيك در شبكه و تداخل اطلاعات كاربران تا حدود
زيادي جلوگيري ميكند
محوریت معماری یکی از ویژگیهای اصلی
RUP می باشد . در این فرآینده وقتی صحبت از
معماری می کنیم ، منظور ما متفاوت از ساختار می باشد . معماری سیستمهای نرم افزاری
در موارد زیر نفش ایفا میکند و تصمیم گیرنده می باشد:
·
ساختار
سیستم نرم افزاری
·
عناصر ساختار و واسط های آنها که سیستم را
تشکیل می دهند بعلاوه ی رفتار آنها که بصورت همکاریهای بین آن عناصر مشخص می شوند.
·
ترکیبی از عناصر ساختاری و رفتاری در زیر
سیستمهای بزرگ
·
روش معمارانه که ساختار ساختار را هدایت می
کند : عناصر و رابط های آنها ، همکاریهای آنها و ترکیب آنها.
·
ضریب تغییرات در مدلها.
به طور خلاصه معماری نرم افزار نه تنها مرتبط با ساختار و رفتار است ، بلکه به
استفاده ، وظیفه مندی ، عملکرد ، قابلیت استفاده ی مجدد ، قابل فهم بودن ،
محدودیتهای اقتصادی و تکنولوژیکی ، موازنه ها و زیباییهای نرم افزار نیز مربوط می
شود.
تعریف خواسته های نرم افزاری در
RUP :
خواسته ها همانهائی هستند که مشتری برای آنها عجله بیشتری دارد . اما تنها
خواسته ها نیستند که معماری را مورد اثر قرار میدهند بلکه فاکتورهای زیر نیز
موثرند:
·
نرم
افزار ما بر اساس کدام محصول نرم افزاری سیستمی ( مثلا سیستم عامل و یا یک سیستم
مدیریت پایگاه داده ای رابطه ای ) ساخته می شود.
·
کدام
محصول میان افزار (Middleware) را می خواهیم استفاده کنیم.
·
کدام یک
از سیستمهای قدیمی را می خواهیم در سیستم خود استفاده کنیم .
·
خود را
با کدام استاندارد ها و قواعد شرکت باید وفق دهیم
·
خواسته
ها ی غیر وظیفه مندی مانند قابلیت استفاده ، زمان یابی ، استفاده از حافظه و یا
خواسته های امنیتی چه هستند.
·
خواسته
های پراکندگی ( توزیع شدگی ) که مشخص میکنند ، سیستم چگونه پراکنده می شود کدامند.
تعریف موجود در
RUP از یک خواسته نرم افزاری به طور خلاصه به شرح زیر است ، یک قابلیت نرم افزاری
مورد نیاز کاربر برای حل یک مساله یا رسیدن به هدف .
به کار گیری مدیریت خواسته ها :
برای ساختن یک سیستم که بدرستی خواسته های مشتریان را در برگیرد، تیم پروژه باد
اول مساله را برای حل شدن توسط سیستم تعریف کند سپس تیم باید ذینفع ها را با توجه
به نیازهای کاربر و نیازهای کاری که استخراج شده اند ، توصیف شده اند و الویت بندی
شده اند معین کند . از این مجموعه از انتظارات با نیازهای
سطح بالا ، یک مجموعه از خصوصیات سیستم یا محصول باید مورد توافق واقع شود.
خواسته های نرم افزاری باید به شکلی نوشته شوند که بوسیله هر دوی مشتری و تیم
توسعه دهنده قابل درک باشند. می توان از زبان مشتری برای توصیف آن خواسته های نرم
افزاری استفاده کرد که به تبع نسبت به درک و توافق آنها موثرتر خواهد بود.
خواسته های نرم افزاری سپس
به صورت ورودی برای مشخصات طراحی سیستم استفاده می شوند . به همان خوبی که برای
طرحها و روالهای آزمایش مورد نیاز هستند برای پیاده سازی و بررسی صحت نیز استفاده
میشوند. همچنین خواسته هاس نرم افزاری باید طراحی و برنامه ریزی مستندات جهت تعلیم
کاربر ابتدایی را نیز مهیا کنند.
برای سهولت بخشیدن به مسائل بهره وری بیشتر مربوط به مدیریت خواسته ها ، تیم
پروژه باید موارد زیر را در نظر داشته باشند و آنها را رعایت کنند:
1-
روی یک
مجموعه لغات عمومی برای پروژه توافق داشته باشند.
2-
استراتژی
توسعه یک سیستم در قالب چشم اندازی از سیستم به همراه ویژگیهای آن
3-
استخراج
نیازهای ذینفعها در حداقل پنج فضای مهم زیر :
وظیفه مندی ، قابلیت استفاده ، قابلیت اطمینان ، کارایی و قابلیت حمایت
4-
تعیین
انواع خواسته های مورد استفاده
5-
انتخاب
صفات و ارزشهایی برای هر نوع از خواسته ها
6-
انتخاب
قالبهایی که خواسته ها در آنها تشریح
شده اند
7-
معین
کردن اعضای تیم که می توانند تهیه کنندگان یا در واقع کسانی هستند که یک یا بیشتر
نوع از خواسته ها را بتوانند مشاهده کنند
8-
تصمیم
گیری اینکه چه مکانیزم ردیابی مورد نیاز است.
9-
بنا
نهادن یک رویه برای ارضاء هدف ، بررسی و انجام تغییرات برای خواسته ها
10-
توسعه یک
مکانیزم برای حفظ ردیابی سابقه خواسته ها
11-
ایجاد
گزارشهای حالت و وضعیت ÷یشرفت برای اعضاء تیم و مدیریت
این فعالیتهای ضروری مدیریت خواسته ها مستقل از صنعت و نوع کسب و کار ،
متدولوژی توسعه یا ابزارهای حامی خواسته ها هستند. همچنین آنها قابل انعطاف هستند،
چنانچه مدیریت خواسته ها کارائی را در محیطهای توسعه برنامه های کاربردی خیلی سریع
و قابل اندازه گیری می سازد.
معرفی چارچوب :
چارچوب یک مجموعه عناصر از قبل تعریف شده برای مدلسازی است که برای مدلسازی یک
نوع سیستم خاص بکار می رود. چارچوبها امکان مشخص کردن ، گروه بندی و استفاده ی مجدد
عناصر را بطرز موثری در سیستمهای نرم
افزاری خاص فراهم میکنند. از طرفی دیگر در تعاریف چارچوب بعنوان الگوی
معمارانه جهت ساخت مطرح شده است . یعنوان مثال اگر بخواهیم سیستمهایی اجاد کنیم که
در آنها همواره وظیفه مندی مدیریت حسابها ، تهیه صورتحسابها و پرداخت وجود داشته
باشد دو راه حل وجود دارد: می توان همواره سیستم را از صفر شروع کرد و بخشهای
مدیریت حسابها ، تهیه صورت حسابها و پرداخت را بازنویسی کرد. که این منجر به حجم
بالایی از دوباره کاریها می شود و هم می توان قسمتهای مدیریت حساب تهیه صورتحسابها
و پرداخت را از پیاده سازیهای قبلی خود با دیگران گرفته و از آنها با توجه به
ویژگیهای مود نیاز جدید استفاده ی مجدد کرد. چارچوبهای موجود در ابزار
IBM Rational
Rose شانس استفاده یمجدد
رسمی تر و بهتر این چنین موقعیتهایی را می دهد . اما تعریف چارچوب به صورت ریر می
باشد:
چارچوب بستر قابل مدیریتی برای قراردادن مدلهای ایجاد شده در طول یک فرآیند
توسعه است .
البته که چارچوب می تواند نرم
افزاری باسد در این صورت چارچوب بستر قابل مدیریتی برای قراردادن مدلهای ایجاد شده
در طول یک فرآیند توسعه نرم افزاری است .یک چارچوب ممکن است به دو روش اساسی مورد
استفاده قرار بگیرد. در روش اول ، چارچوب برای برپا کردن مجموعه ای از اجزاء با
قابلیت استفاده یمجدد استفاده می شود. در روش دوم ، یک چارچوب بعنوان قالبی برای
ساختن مدلهای جدید یا تعریف کردن معماری گونه های خاصی از سیستمها بکار می رود.
رویکرد اول را کتابخانه ای و دومی را رویکرد بعنوان قالب گویند. هر رویکرد
فوایدخودش را داراست و ایجاد آنها نیازمند تلاش و حوصله خاصی می باشد.
رویکرد در چارچوب بعنوان کتابخانه :
این رویکرد ساده است زیرا شبیه استفاده از کتابخانه هاست . بعلاوه ی اینکه
کنابخانه در مدل قابل دیدن است . در
Rose ، چارچوبهای بیشتری با این رویکرد وجود
دارد مانند
JDK, MFC و
Oracle ...
رویکرد چارچوب بعنوان قالب :
این نوع چارچوبها از مدلی که شامل قطعات کنار هم گذاشته شده از یک سیستم نوعی
است ساخته می شوند. ایجاد یک سیستم جدید به سادگی با استفاده از این چارچوبها
بعنوان اساس مدل جدید و سپس پرکردن جاهای خالی امکان پذیر است .واضح است که ایجاد
چنین قالبی از قراردادن تعدادی کلاس در یک کتابخانه سخت تر است و نیازمند کار بیشتر
و تصمیم گیریهای پیشرفته تری می باشد . در عوض این قبیل چارچوبها ، امکان استفاده
مجدد در سطح بالاتری را فراهم می کنند چرا که نه تنها از کد استفاده مجدد می شود ،
بلکه دانش با ارزش و کلیدی معماری سیستم نوعی را نیز مورد استفاده ی مجدد قرار
میگیرد.
چارچوب با رویکرد قالبی امکان ایجاد سریعتر و با کیفیت تضمین شده ی سیستمهای
جدید را فراهم می کند.
چارچوب فرآیند
RUP :
در
Rose چارچوبی با رویکرد قالبی برای ایجاد کاربردها با طی مراحل فرآیند
RUP وجود دارد که چارچوب
RUP
نام دارد . این چارچوب یک مدل از اجزاء
منسجم شده و در واقع مکملی برای
RUP می باشد.
الگوها :
فعالیتهای موجود در
RUP بسترهای توسعه الگوها هستند . پتانسیل زیادی در این فرآیند رو به رشد دیده می
شود. اگر در نظر بگیریم که هم اکنون قسمتهای هدایت کننده زبادی از جمله ، مقدمه ،
هدف ، توضیحات اضافی ، مثالها، شرح و مثال فعالیتها و چارچوبهای فرآورده ها و ...در
هر جریان از
RUP
وجود دارد
براحتی می تون الگوهایی را در هر جریان کاری معینی تدوین و تکمیل کرد و در بستر
" تکرار_افزایش" قرار داد تا سیستمی که از آنها بهرمند می شود در بستر " تکرار –
افزایش – بهبود " قرار گیرد.
تعریف الگوی فرآیند :
یک الگوی فرآیند تولید نرم افزاری مجموعه ای از تکنیکهای عمومی است که از
ارتباط فعالیتهای مختلف موجود بین جریانهای کاری مختلف جهت حل مسائل دامنه فرآیند
توسعه نرم افزار استفاده می کند.
این ارتباط می تواند توالی ، تقدم
و تاخر ، وابستگیهای مختلف ، تکرارها و بهبودها نسبت به فعالیتها باشد و در حقیقت
وجود فعالیتهای حداقل دو جریان کاری در هر الگوی فرآیند الزامی است . به عنوان
نمونه ای از الگوهای فرآیند منطبق بر تعریف فوق ، ارتباط بین دو جریان کاری
Requirment و
Change & Configiguration Management
را می توان در نظر گرفت .
سرعت عمل با
RUP
چه چيز ميتواند يك پروسه توليد نرمافزار
سريعالانتقال را توصيف كند؟ آيا منظور از سرعت عمل، آمادهسازي سريعتر نرمافزار
براي ارائه در بازار است؟ مسلماً در هر كاري هر چه سرعت بيشتر باشد، بهتر است و از
نظر اقتصادي نيز مقرون به صرفهتر؛ ولي چنانچه سرعت زياد موجب آسيبديدن به كيفيت
شود، لزوما چيز با ارزشي نيست. آيا منظور از سرعت عمل به حداقل رساندن حجم پروسهاي
است كه براي توليد يك نرمافزار مورد استفاده قرار ميگيرد؟ واقعاً خير. اگر با اين
منطق در اين زمينه فكر كنيم، پروسهاي كه حجم آن صفر باشد، يعني اصلاً وجود نداشته
باشد بهترين پروسه است.
براي يك شركت توليد نرمافزار، سرعت عمل عبارت است از توانايي سازگاري و
عكسالعمل سريع و به موقع براي پاسخگويي به تقاضا و شرايط اجتماعي موجود است.
يك پروسه چابك، پروسهاي است كه هميشه آماده در آغوش كشيدن درخواستهاي جامعه
بوده و اين درجه از سازگاري را دارا
باشد. بنابراين منظور از سرعت عمل، فقط كاستن از حجم پروسه توليد نرمافزار يا سرعت
ارائه آن به بازار نيست؛ بلكه منظور، انعطافپذيري است. مطلبي كه در اين مقاله قصد
توضيح آن را داريم، اين است كه
RUP (Rational Unified Process) ساختار پروسهاي است كه امكان
انعطافپذيري را براي توليدكنندگان نرمافزار فراهم ميآورد.
کیفیت :
كيفيت چيزي است كه ما
در توليدات، فرايندها و خدمات به دنبال آن هستيم. كيفيت يك ويژگي منحصر به فرد
نيست، بلكه يك مشخصهي چند بعدي است و مي تواند در يك فرايند يا محصول وجود داشته
باشد.
كيفيت به مشخصه اي
اطلاق مي شود كه :
·
تعدادي
از نيازمنديهاي توافق شده را برآورده كند.
·
به وسيله
معيارهاي سنجش و اندازه گيري توافق شده ارزيابي شود.
·
به وسيله
فرآيند مورد قبولي توليد شود.
كيفيت نرم افزار را
ميتوان به دو دسته تقسيم كرد:
كيفيت محصول و كيفيت
فرآيند
:
كيفيت محصول در مورد كيفيت محصولي كه به وسيله فرآيندها توليد مي شود، بحث و نتيجه گيري مي
كند.
كيفيت فرآيند به ميزان مقبوليت و كيفيت يك فرآيند كه براي توليد يك محصول اجرا مي شود،
اشاره مي كند. اگر ما يك فرايند با كيفيت داشته باشيم، ريسك توليد محصول با كيفيت
پايين بسيار كم مي شود، در حالي كه خلاف اين مورد معمولا" درست نيست. يعني داشتن يك
محصول نهايي با كيفيت بالا، دليل بر وجود يك فرآيند با كيفيت بالا نيست.
ابعاد مختلف كيفيت
همان طور كه اشاره شد،
كيفيت داراي ابعاد مختلفيست.
در
RUP براساس مدل
FURPS+ كيفيت به صورت زير دسته بندي ميشود:
·
كاركردي(
Functionality )
·
قابليت
استفاده (
Usability )
·
قابليت
اعتماد (
Reliability )
·
عملكرد(
Performance )
·
قابليت
پشتيباني(
Supportability )
براي هركدام از اين
ابعاد مختلف كيفيت، چند نوع تست، درمراحل متفاوت اجرا مي شود.
|
ابعاد كيفيت |
نوع تست |
|
كاركرد |
تست
كاركرد ( Function )
و تست حجم ( Volume ) |
|
قابليت
استفاده
|
تست
قابل استفاده بودن ( Usability ) :
اين تست سيستم را
ازديد كاربر نهايي
بررسي مي كند |
|
اعتبار
و قابليت اعتماد |
تست
جامعيت ( Integrity )، تست
ساختار(
Structure )
و تست
فشار ( Stress ) |
|
عملكرد |
تست Benchmark
، تست Contention
، تست Load
و Performance Profile |
|
قابليت
پشتيباني
|
تست
پيكربندي ( Configuration )
و تست نصب ( Installation ) |
در واقع تست به عنوان
يك عامل مهم و موثر بر همه ابعاد كيفي محصول شناخته مي شود.
مديريت كيفيت در
RUP
مديريت كيفيت به سه
دليل انجام مي شود:
1.
مشخص
كردن مقياسهاي مناسب براي كيفيت قابل قبول.
2.
مشخص
كردن مقياسهاي مناسب براي استفاده در ارزيابي كيفيت.
3.
مشخص
كردن و نشان دادن موضوعاتي كه بر روي كيفيت اثر گذاشته اند و يا احتمالا" اثر
خواهند گذاشت.
مديريت كيفيت در همه
گردش هاي كاري (
Workflows ) انجام مي شود.
اندازه گيري كيفيت در
طول چرخه حيات محصول، به منظور مديريت كيفيت، اندازه گيري و ارزيابي كيفيت محصول و
فرآيند انجام مي شود .
اندازه گيري كيفيت
احتياج به جمع آوري و تجزيه و تحليل اطلاعات دارد كه معمولا به شكل اندازه ها (
Measurements ) و متريكها نمايان مي شوند،
اندازه ها اصولا" براي
كنترل پروژه مورد استفاده قرار مي گيرند. موارد استفاده ديگر آنها ارزيابي ميزان
انطباق وضعيت پروژه با شرايط تعيين شده در برنامه ريزي اوليه مي باشد. اين شرايط
عبارتند از: معيارهاي اتمام پروژه، معيارهاي كيفي، معيارهاي پذيرش ،معيارهاي
برآورده شدن نيازمنديها و غيره ... .
متريك ها براي دو هدف
اصلي مورد استفاده قرار ميگيرند : آگاهي (
Knowledge ) و تغيير(
Change )
اهداف مربوط به آگاهي:
اين اهداف با افعالي
مانند : پاييدن(
Monitor ) ؛ ارزيابي كردن(
Evaluate ) و پيش بيني كردن (
Predict )بيان مي شوند. هميشه يكي از اهداف مديريت، بهتر فهميدن فرآيند انجام كار است.
به عنوان مثال، تشخيص كيفيت محصول ؛ تشخيص كيفيت فرآيند تست ؛ پايش پوشش دهي تست و
يا پيگيري (
Tracking )تغييرات مربوط به نيازمنديها نمونه هايي از اين اهداف است.
اهداف مربوط به تغيير:
اين اهداف با افعالي
مانند: افزايش يافتن (
Increase )؛كاهش يافتن (
Reduce )؛ بهبود دادن (
Improve )؛ و
Achieve بيان مي شوند.
به عنوان مثال بهبود
دادن زمان انجام كار يك پروژه نسبت به پروژه هاي قبلي يك نمونه از اين اهداف است.
اين متريكهاي به دست
آمده به اندازه گيري كيفيت محصول و فرآيند كمك مي كنند.
ارزيابي كيفيت معمولا
زماني كه يك رويداد مهم رخ مي دهد، مثلا در انتهاي يك مرحله از توليد يا زمان
انتشار محصول نهايي، انجام مي شود.
مقطع پاياني تست زمان
مناسبي براي ارزيابي نهايي كيفيت محصول قبل از انتشار است. ارزيابي خطاها و نواقصي
كه در تست پيدا شده اند، بهترين شاخص براي كيفيت نرم افزار و يا ارزيابي محصول است.
ارزيابي نواقص بايد مبتني بر متدهايي باشد كه از تعداد خطاهاي ساده به مدل سازي
آماري حركت كند.
اين ارزيابي ها از يك
فرض درباره نرخ كشف خطاها در طول فرآيند تست استفاده مي كنند. معمولا اين نرخ از
توزيع پواسون تبعيت مي كند. سپس، اطلاعات واقعي درباره نرخ پيدا شدن خطاها در مدل
گنجانده مي شود. نتايج ارزيابي قابليت اعتماد نرم افزار كنوني را تخمين مي زند و
نيز پيش بيني مي كند كه قابليت اعتماد نرم افزار در صورت ادامه روند تست و برطرف
كردن خطا چگونه رشد خواهد .( انتظار مي رود كه با پيشرفت تست نرخ پيدا شدن خطاها كم
شود.) اين ارزيابي به عنوان مدل رشد قابليت اعتماد نرم افزار بيان مي شود.
منابع :
آشنائی با RUP. مولف : دکتر سید محسن
هاشمی
http://www.informit.com/articles/article.asp?p=169549
http://www.dcs.ed.ac.uk/teaching/cs2/online/Lectures/CS2Ah/SoftEng/se02-slides.PDF
http://portal.acm.org/citation.cfm?id=518604&dl=ACM&coll=portal
http://www.coast.com/pdf/webTestingAndRational.pdf
http://www.selectbs.com/products/solutions/rup.htm