مجله اینترنتی دیپروتد

مجله اینترنتی دیپروتد

ریشه های عمیق اجتماعی و اقتصادی

شنبه، 8 آذر 1399

فروشگاه اینترنتی صنایع دستی صبنگو

11/12 1395

مهندسی نرم افزار : اكتور  یا عامل موجودیتی در تعامل با سیستم به منظور تكمیل یك رویداد است . این تعریف توسط یاكوبسن ارائه شده است.
اکتور ها (عامل ها) در مهندسی نرم افزار

اكتورها
اكتور موجودیتی در تعامل با سیستم به منظور تكمیل یك رویداد است . این تعریف توسط یاكوبسن ارائه شده است. برای نمونه یك متقاضی یا یك مشتری بانك كه تقاضای وام را به بانك
می دهد و یا یك آ ژانس مسافرتی كه صندلی های خالی را از طریق وب مشخص می كند یك اكتور می باشد.

اكتورها لزوماً افراد و یا كاربران سیستم نیستند. یك اكتور ممكن است یك سیستم یا یك وسیله و یا هر موجودیتی كه به نوعی بر طبق تعریف یاكوبسن در تعامل با سیستم قرار گیرد
می باشد . توجه كنید كه هر موجودیت در ارتباط با سیستم، اكتوری برای سیستم نیست بلكه باید این موجودیت به خاطر تكمیل رویدادی كه بر سیستم موثر است در تعامل با سیستم قرارگیرد .
البته كلمه ی گنگ در اینجا رویداد است.

رویداد، عملی است كه سیستم در قبال آن باید از خود واكنش نشان دهد. در واقع رویداد به آن چیزی اطلاق می شود كه زمانگیر نیست، تداوم ندارد و محرك می باشد. برای مثال تقاضای ثبت نام زمانگیر نیست و تداوم ندارد و محرك عملیات ثبت نام است.

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

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

هنگامی كه اكتور های اصلی را مطرح می شود به نكات زیر باید توجه كرد:
1. عملیاتی كه بر حسب وظیفه، اكتور انجام می دهد.
2. مسئولیت ها و نقش های عمده ای كه برعهده ی اكتور است. در واقع شاخص نیاز هایی
كه باید مورداستفاده پاسخگوی آن باشد.
3. نیازهایی كه سیستم باید پاسخگو باشد.

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

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



خصوصیت های اكتور:
با تعیین خصوصیات می توان اكتورها را مشخص كرد. این ها موجودیت هایی هستند كه در عملیات مورداستفاده دخیل می باشند. یك اكتور ممكن است خصوصیت های متفاوت در ارتباط با یك مورداستفاده داشته باشد. انواع ویژگی های اكتور یا انواع شخصیت های اكتور را می توان به صورت زیر مشخص كرد:
اکتور نوع خصوصیت                 رفتار
آغازگر                             عمل مورداستفاده را آغاز می كند (موجب شروع عمل مورداستفاده می شود)
سرویس دهنده ی بیرونی          كمك می كند تا سرویسی توسط مورداستفاده ارائه شود
دریافت كننده                       اطلاعاتی را از مورداستفاده دریافت می كند
تسهیل كننده                      كمك می كند تا اكتورهای دیگر از مورد استفاده بتوانند بهره ببرند



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

بدین ترتیب اكتوری كه كار ورود جزئیات درخواست را برعهده دارد به عنوان یك تسهیل كننده مطرح است چرا كه كمك می كند تا مشتری تقاضای وام خود را به سیستم بدهد .
معمولاً در تشخیص تسهیل كننده ها باید دقت كرد. این ها حالت خاصی دارند در واقع واسط می باشند (واسط ارتباط افراد با سیستم).

تعیین نیاز ها ، مستند مهندسی نیاز ها

نیازها
پس از تعیین چارت عملیاتی می بایست نیازهای عملیاتی و نیازهای كیفی را مشخص كنیم.
انواع نیازها :
معمولاً نیازها را بر اساس شرح وظایف افراد مشخص می كنیم. در واقع، نیازها در قالب (سیستم باید را انجام دهد ) مشخص می شوند . نیازها ، عملیاتی یا غیرعملیا تی هستند . به نیازهای X عمل غیرعملیاتی، نیازهای كیفی گفته می شود. بعد از این كه چارت عملیاتی را تعیین كردیم ، با درنظر گرفتن شرح وظایف، امكانات سیستم كامپیوتری و نیازهای جدید مبادرت به تعیین نیازهای عملیاتی و كیفی می نماییم. هر نیاز را با كدی مشخص می كنیم. برای مثال تمام نیازهای واحد قرض الحسنه، كد واحد قرض الحسنه همراه با شماره و نوع نیاز می گیرد. 

شكل زیر ، نیازهای عملیاتی واحد قرض الحسنه را نشان می دهد.

نیاز عملیاتی واحد قرض الحسنه
كد
نیاز عملیاتی واحد قرض الحسنه
نوع
1-1
سیستم باید قابلیت افتتاح حساب را داشته باشد
E
1-2
سیستم باید قابلیت نشان دادن موجودی مشتری را داشته باشد
E
1-3
سیستم باید قابلیت پذیرش اسناد و دریافت و پرداخت وجوهات را داشته باشد
E
1-4
سیستم باید قابلیت پذیرش چك و واریز مقدار آن به حساب مشتری را داشته باشد
E
1-5
سیستم باید قابلیت بستن حساب را داشته باشد 
E
1-6
سیستم باید قابلیت محاسبه ی بیلان را در هر لحظه داشته باشد
H


قابلیت ها، سرویس هایی هستند كه سیستم در اختیار كاربران قرار می دهد . برای هر نیاز ، كدی مشخص شده است. نوع نیاز عملیاتی می تواند یكی از موارد زیر باشد:
 E ) 1). ضروری
 O ) 2). اختیاری
 H ) 3). پنهان

 

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

 6 _ هزینه: هزینه ی تولید برنامه ها باید حداكثر X ریال شود.

7 _ امنیت: سیستم باید كلمه ی عبور افراد را كنترل یا داده ها را رمزگذاری نماید.


دیدگاه شی گرا چه پیشنهادی برای تعیین نیازها می نماید؟
تعیین نیازها در دیدگاه شی گرا:
برای اینكه سیستم را شناسایی كنیم، ابتدا سرحدات آنرا مشخص می نماییم. یعنی، تعیین می كنیم كه چه افراد، نرم افزار ها یا سازمان هایی از سیستم استفاده می كنند. اینها را در اصطلاح بازیگر 2 می نامند .
یك كاربر یك نوع اكتور است اما كاربر فقط از نتایج كار استفاده می كند. اكتورها هم استفاده كننده هستند و هم كمك می كنند كه عملیات سیستم انجام شود. بنابراین اكتورها را می توان در دو دسته
قرار داد:
Online - 1
Actor - 2


دسته ی اول اكتورهای داخلی و دسته ی دوم اكتورهای خارج از سیستم هستند.

دیپروتد دیاگرام متن سیستم انبار

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

پس، برای شناخت به روش تجزیه و تركیب، ابتدا چارت سازمانی و با ارجاع به پست های سازمانی كه در چارت سازمانی درج شده، شرح وظا یف برای هر پست سازمانی بدست می آید . بر مبنای شرح وظایف، چارت عملیاتی را مشخص می نماییم. سپس برای هر واحد عملیاتی نیازهای كیفی و نیازهای عملیاتی را مشخص می كنیم. اما چه روشی برای شناخت باید داشته باشیم؟
تعیین نیاز در مقوله ی مهندسی نیازها مطرح است. انواع روش ها برای استخراج نیازها به صورت زیر می باشند:
1. مبتنی بر هدف
2. مبتنی بر وظیفه
3. مبتنی بر سرویس
4. مبتنی بر فرآیند

شناخت مبتنی بر هدف رابطه ای است منطقی بین آنچه كه وجود دارد و آنچه كه در آتیه به دست خواهد آمد. در جهت رفع مشكلات، اهداف و برنامه ریزی های راهبردك - بلند مدت و كوتاه مدت - در سازمان ها مطرح می باشد . لذا می توان تعدادی از نیازها را بر مبنای اهداف مشخص نمود . بر اساس فرآیندهای كاری نیز می توان بخش دیگر از نیازها را مشخص كرد. در واقع با شناخت عملیات كه در روش های ساخت یافته رایج بود، سیستم ها را بر اساس عملكرد سیستم ها تجزیه و مورد شناسایی قرار می دادند. همچنین بر اساس عملیاتی كه باید در سیستم كامپیوتری انجام شود نیازها را مشخص می كردند. به این روش در اصطلاح تجزیه ی عملیات می گویند.
شناخت مبتنی بر تجزیه و تركیب و نمودار عملیاتی، روش تجزیه ی سیستم ها بر اساس عملیات می باشد. در واقع، اگر برای مثال عملیات واحد آموزش را در قالب نمودار عملیاتی تجزیه كنیم و به آنجا رسیدیم كه عمل حذف و اخذ به صورت دستی انجام شود، حالا می توانیم بگوییم كه سیستم باید عمل حذف و اخذ را انجام دهد. پس باید ببینیم كه چگونه سیستم كامپیوتری می تواند پاسخگوی مشكلات بوده و عملیات را مكانیزه كند. سپس باید یادداشت كنیم كه نیاز است كه سیستم این عملیات را انجام دهد. شرح وظایف افراد نیز به كمك می كند تا نیازهای دیگر را مشخص كنیم. برای نمونه به شرح وظیفه ی مدیر گروه نگاه كنید. تائید شرایط فارغ التحصیل بودن یكی از وظایف مدیر گروهاست.

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

اكتورهای كاری سرویس گیرنده یا سرویس دهنده هستند. موردهای استفاده از سیستم جاری و اكتورها به صورت زیر مشخص می شود:

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

نرم افزار و مهندسی نرم افزار software Engineering

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

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

نکات مورد توجه در مورد نرم افزار:

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

• نرم افزار، مهندسی (طراحی و ساخته) می شود نه تولید.

• نرم افزار رو به زوال میرود اما کهنه نمی شود.

در حال حاضر اکثر نرم افزارها بصورت خصوصی ساخته شده اند.

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

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

مهندسی نرم افزار software Engineering :

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

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

فاز تعریف - تمرکز دارد بر چه چیز (مهندس اطلاعات، برنامه ریزی پروژه نرم افزار، تحلیل نیازمندیها)

فاز توسعه – تمرکز دارد بر چگونه (طراحی نرم افزار، تولید کد، تست نرم افزار)

فاز پشتیبانی – تمرکز دارد بر تغییرات (نگهداری تصحیحی ، نگهداری وفق دهی، نگهداری تکمیلی و نگهداری پیش گیری)

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

مدل آبشاری : روش قدیمی اما مناسب برای جایی که نیازمندیها از ابتدا کاملا مشخص است.

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

مدل توسعه و کاربرد سریع RAD : از اجزا و قطعات آماده بیشترین استفاده را انجام میدهد و سیکل توسعه بسیار کوتاهی دارد.

مدل افزایشی: نرم افزار را بصورت قسمتهای کوچک اما قابل استفاده ارائه می کند و هر قسمت روی قسمتهای قبلی سوار شده است.

مدل حلزونی: خصوصیت تکراری بودن روش نمونه سازی را با جنبه های سیستماتیک و کنترل شده روش آبشاری ترکیب می کند.

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

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

مدل روشهای فرمال: نمادهایی کاملا ریاضی وار برای مشخص کردن، طراحی و ارزیابی سیستم های رایانهی.

تکنیک های نسل چهارم4GT : ابزاری نرم افزاری که کد منبع رابرای یک نرم افزار از روی یک تعریف خصوصیات سطح بالا تولید می کند.

 






منبع :
لینک :
کد مطلب: 9
تاریخ و زمان انتشار: 12 بهمن 1395, 16:16
لینک کوتاه مطلب:
https://deeprooted.ir/9
آبتین وب فروشگاه اینترنتی قند رژیمی کامور
مهندسی نرم افزار - بخش دوم
فروشگاه اینترنتی صنایع دستی صبنگو
سمت نو
اخبار

رویدادها
فروشگاه اینترنتی صنایع دستی صبنگو
کسب و کار های نوپا

TED

معرفی کتاب

سبک زندگی

معرفی سایت
فروشگاه اینترنتی صنایع دستی صبنگو
File engine/modules/dlefa_stats/index.php not found.