تعریف مهندسی نرم افزار

تعریف مهندسی :

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

تعریف نرم افزار:

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

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

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

　نرم افزار

نرم افزار مهندسی می شود.

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

نرم افزار پیچیده است.

نرم افزار مانند یک کارخانه کهنسال است　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　محصولات نرم افزاری　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

عمومی (Generic) – برای فروش به طیف وسیعی ازمشتریان گوناگون تولید می شود.

سفارشی (Bespoke or Custom ) – برای یک مشتری خاص منفرد مطابق مشخصاتی و خصوصیاتی تعیین شده ازسوی او تولید می شود.

 

تفاوت سخت افزار با نرم افزار:

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

　انواع نرم افزارها:

نرم افزارهای سیستمی

real-time software (نرم افزارهای بلادرنگ)

business software (نرم افزارهای تجاری)

engineering/scientific software (نرم افزارهای علمی و مهندسی)

embedded software (نرم افزارهای نهفته یا تعبیه شده)

PC software (نرم افزارهای کامپیوترهای شخصی)

AI software (نرم افزارهای هوش مصنوعی)

Web applications (نرم افزارهای کاربردی تحت وب)

　هزینه های نرم افزار شامل:

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

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

مهندسی نرم افزار، تولید مقرون به صرفه یک نرم افزار را مدنظر دارد.

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

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

اقتصاد تمامی کشورهای توسعه یافته وابسته به نرم افزار است

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

مهندسی نرم افزار شامل تئوری ها، متودها و ابزارهایی برای تولید حرفه ای نرم افزار می باشد.

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

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

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

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

تحلیل، طراحی، پیاده سازی و تست و نگهداری و استقرار

　مدل فرآیند:

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

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

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

　مدل ترتیبی خطی (The Linear Sequential Model)

　مدل نمونه سازی (Prototyping)

　مدل تولید سریع نرم افزار (Rapid Application Development)

　　مدل های تکاملی تولید نرم افزار

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

　مدل حلزونی Win Win

مدل مونتاژ مولفه ها (Component Assembly Model)

مدل توسعه همروند (Concurent Development Model)

مدل روش های رسمی (Formal Methods Model):

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

تکنیک های نسل چهارم (4GT- Forth Generation Tool):

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

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

خصوصیات یک نرم افزار خوب:

　قابلیت نگهداری (Maintainability):

نرم افزار باید تکامل و تحول یابد تا نیازهای تغییر کرده کاربران را برآورده نماید.

قابلیت اطمینان (Dependability):

نرم افزار باید پایا و معتمد و قابل اطمینان باشد.

بهره وری و کارایی (Efficiency):

نرم افزار نباید از منابع سیستم استفاده بی فایده داشته باشد و به اتلاف منابع بیانجامد

قابلیت استفاده (Usability):

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

جلسه دوم: اصول و مفاهیم مدیریت پروژه های نرم افزاری

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

مفاهیم کلی

اندازه گیری

تخمین

　فعالیت های چتری:

　مدیریت پروژه نرم افزاری(Software project management)

مرورهای تکنیکی رسمی(Formal technical reviews)

اطمینان از کیفیت نرم افزار(Software quality assurance)

مدیریت پیکربندی نرم افزار(Software configuration management)

تولید و تدارک مستندات (Document preparation and production)

مدیریت استفاده مجدد(Reusability management)

اندازه گیری(Measurement)

مدیریت ریسک (Risk management)

　مدیر پروژه برای مدیریت چه حوزه هایی را باید پوشش دهد؟

　1)　　　 افراد (People)

2)　　　 محصول (Product)

3)　　　 فرآیند (Process)

4)　　　 پروژه (Project)

　1) افراد (People)

　5 گروه مختلف از افراد درگیر پروژه هستند:

1-1) مدیران ارشد

2-1) مدیر پروژه

3-1) مهندسان – مدیران اجرایی

4-1) مشتری

5-1) کاربر

انواع روشهای همکاری و مشارکت افراد:

1)　　　　 ساختار غیر تیمی

2)　　　　 ساختار تیمی غیر ساخت یافته

3)　　　　 ساختار تیمی ساخت یافته

1-3) دموکراتیک غیر متمرکز(DD)

2-3) کنترل شده غیر متمرکز(CD)

3-3) کنترل شده متمرکز(CC)

　یکی دیگر از انواع ساختارهای تیمی:

1-3) مدل بسته

2-3) مدل تصادفی

3-3) مدل باز

4-3) مدل همزمان

　تفاوت رهبر و مدیر:

　مدیر، به افراد تا جایی اهمیت می دهد که برای پروژه موثر باشند. او افراد موثر را به کار می برد و شرایط را برای هریک فراهم می کند تا پروژه ای خوب و با کیفیت ارائه شود.

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

نقش رهبر بالا بردن رضایت شغلی است.

　مدل MOI:

1)Movitation (انگیزش)

2)Organization (سازماندهی)

3) Ideas (خلاقیت)

　روشهای هماهنگی میان افراد:

1)　　　　 ارتباطات الکترونیک

2)　　　　　 روشهای غیر رسمی میان افراد

3)　　　　　 روشهای رسمی

4)　　　　　 روشخای رسمی غیر شخصی

5)　　　　　 شبکه میان افراد

　　۲) محصول (Product)

مهمترین وظیفه مدیر در این بخش تعیین محدوده نرم افزار و تجزیه آن است.

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

۳)　فرآیند (Process)

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

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

مدیر، در این مرحله جدول ادغام محصول و فرآیند را رسم می کند.

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

4) پروژه (Project)

10 عامل که موجب شکست پروژه می شود:

1) عدم تشخیص نیازهای مشتری

2) مشخص نبودن محدوه نرم افزار

3) مدیریت ضعیف تغییرات

4) تغییر تکنولوژی

5) تغییر نیازهای مشتری

6) مشخص نبودن مهلت ها

7) مقاومت کاربران

8) از بین رفتن حمایت حامیان

9) فقدان افراد با مهارت

10) اجتناب از به کار گیری درس های آموخته شده

　اصل W^۵HH

طبق این اصل پس از طرح یک سری پرسش مدیر آشنایی بیشتری با پروژه پیدا می کند:

1)　　　　? Why: چرا این پروژه کاربرد دارد؟

2)　　　　? What: چه کارهایی باید انجام شود؟

3)　　　　? When: در چه بازه زمانی کار باید انجام شود؟

4)　　　　 ?Where: به لحاظ سازمانی چه جایگاهی دارد؟

5)　　　?Who: چه کسی مسئول یک کار مشخص است؟

6)　　　　? How: از چه فرآیندها، تکنیک ها و تکنولوژی هایی استفاده خواهیم کید؟

7)　　　?How Much: از هر منبع به چه میزان لازم است؟

　اندازه گیری:

یکی دیگر از وظایف مدیر پروژه، اندازه گیری پروژه است.

معیار: با تعیین صفات کمی و نسبت دادن مقدار به آنها یک معیار بدست می آوریم.

شاخص: دیدگاهی از معیارها شاخصی را در اختیار ما قرار می دهد.

　نرمال سازی معیارها:

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

　1)　　　　 نرمال سازی سایزی (تعدا خط کد): تعداد خطاها در هزار خط کد

2)　　　　 نرمال سازی عملکرد گرا: براساس تعداد نقاط عملکردی. محاسبه Fp

　　کیفیت:

یکی دیگر از معیارهای نرم افزار، معیار اندازه گیری کیفیت است. کیفیت نرم افزار را نمی توان مستقیما اندازه گیری نمود بلکه برای این منظور از دو روش استفاده می کنیم:

1)　　مستقیم : به طور مستقیم کیفیت را تعیین می کنیم. که این روش در مهندسی کاربرد ندارد.

2)　غیر مستقیم: براساس عیارهای دیگر آن را تعیین می کنیم

　این معیارها عبارتند از:

1-2) صحت: درجه ای که نرم افزار درست کار می کند

معیار= تعداد خطاها در یک بازه زمانی مشخص

2-2) قابلیت نگهداری: درجه ای که بعدا می توانیم برنامه را تغییر دهیم یا آن را بهبود بخشیم.

معیار= MTTC (میانگین زمان لازم برای تغییر نرم افزار)

3-2) امنیت: هرچه میزان یکپارچگی نرم افزار بیشتر باشد امنیت نیز بیشتر می شود. منظور از یکپارچگی درجه ای است که نرم افزار در برابر تهدیدات خارجی مقاومت نشان می دهد.

4-2) قابلیت استفاده:

مدت زمان لازم برای یادگیریر نرم افزار، میزان مهارت لازم برای استفاده از نرم افزار، افزایش سودمندی نرم افزار در محیط

راه های کنترل ریسک یا برنامه RMMM

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

　مدیریت ریسک

مدیریت پیکربندی

تضمین کیفیت نرم افزار

مدیریت ریسک:

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

　در مورد آینده : چه ریسک هایی باعث نا کارآمدی نرم افزار ما می شود.

تغییرات : شامل تغییرات در خواسته های مشتری و فناوری های توسعه می شود.

انتخاب ها : از کدام روش ها و از چه ابزاری برای تهیه نرم افزار استفاده کنیم.

　مراحل کار:

شناسایی ریسک

اولویت بندی

تهیه برنامه مدیریت ریسک

　انواع　 ریسک:　　

عام : مسائلی که در اکثر پروژه ها به عنوان ریسک در نظر گرفته می شود

خاص : ریسکهایی که خاص محصول پروژه هستند

　انواع ریسک های نرم افزاری

　ریسک های پروژه ای

ریسک های فن

ریسک های تجاری

ریسک های بازاریابی

ریسک های استراتژیک

ریسک های عدم حمایت مدیران ارشد

ریسک های تکنیکی

ریسک های محیط توسعه نرم افزار

　مولفه ها و تاثیر ریسک

مولفه ها

1. کارایی (میزان عدم قطعیت برآورده شدن خواسته ها توسط نرم افزار)

2. هزینه (عدم قطعیت در حفظ بودجه پروژه)

3.　پشتیبانی (عدم قطعیت در سهولت تصحیح، تطبیق و ارتقاء نرم افزار)

4.　زمانبندی (میزان عدم قطعیت در رعایت زمانبندی و تحویل پروژه)

تاثیر

1.　قابل چشم پوشی

2.　کم اهمیت

3.　بحرانی

4.　فاجعه بار

　گام های تحلیل ریسک:

　تعیین موارد ریسک

گروه بندی ریسک ها

احتمال وقوع هر یک از ریسک ها

تاثیر هر ریسک

مرتب سازی جدول بر اساس احتمال و تاثیر

تعیین خط مرزی توسط مدیر پروژه

برنامه ریسک	نوع ریسک	RE	تاثیر ریسک	احتمال ریسک	لیست ریسکها
			4	0.50	Aریسک
			2	0.20	B ریسک

　نکته 2:　 RE= P*C　　　

احتمال ریسک= P　　 　= هزینه ریسکC

　مدیریت پیکربندی نرم افزار

　مدیریت پیکربندی نرم افزار (SCM) یک فعالیت چتری است که در سراسر فرآیند نرم افزار قابل اجرا است.

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

　فعالیت های مدیریت پیکربندی

1) شناسایی اقلام پیکربندی و ایجاد خط مبنا

2) کنترل نسخه

3) کنترل تغییر

1-3) کنترل دسترسی

2-3) کنترل همزمانی

4) بررسی پیکربندی

5) گزارش وضعیت

　1) اقلام پیکربندی(SCI)

　یک قلم پیکربندی هر شی یا محصولی است که در طول پروژه تهیه می شود.

یک SCI می تواند یک سند، مجموعه کامل اجزای آزمایش یا جزئی از آن، یک مولفه نام گذاری شده در برنامه.

این اقلام باید شناسایی شوند و سپس با روش شیء گرا سازماندهی شوند.

خط مبنا (Base Line)

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

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

　2) کنترل نسخه

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

　گراف تکامل نرم افزار:

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

　3) کنترل تغییر:

　1-3) کنترل دسترسی

زمانی که یک قلم پیکربندی به عنوان خط مبنا در مخزن ذخیره می شود و فردی درخولست تغییر می دهد مدیر باید بررسی کند که آیا او اجازه دسترسی به این قلم را دارد یا خیر

　2-3)　کنترل همزمانی

دو نفر به طور همزمان نمی توانند یک قلم پیکربندی را تغییر دهند. برای این منظور با هر دسترسی به یک قلم، آن قلم باید قفل شود.

4) بررسی پیکربندی:

در بررسی وضعیت پیکربندی بررسی می شود که آیا آنچه انجام شده از نظر تکنیکی درست بوده یا خیر؟

یعنی تغییرات اعمال شده مطابق استانداردها انجام شده است یا خیر؟

　5) گزارش وضعیت:

هرگاه درخواست تغییری تصویب شود رکوردی به این گزارش اضافه می شود که نشان می دهد چه زمانی، چه تغییری، توسط چه کسی انجام شده و نتیجه آن چه بوده است؟

فرآیند مدیریت پیکربندی

۱)　تشخیص نیاز برای تغییر

۲) درخواست تغییر از طرف کاربر

　۳) ارزیابی توسط توسعه دهنده

۴) تهیه گزارش تغییر

　۵) تصمیم برای اعمال تغییر

　۱-۵) با درخواست تغییر مخالفت می شود

۲-۵) درخواست برای اجرا در نوبت قرار می گیرد و ECO تولید　می شود به کاربر اطلاع داده می شود.

۱-۲-۵) تخصیص افراد به اشیاء پیکربندی

۲-۲-۵)خارج نمودن اشیاء پیکربندی

۳-۲-۵)　کنترل همزمانی

۴-۲-۵) انجام تغییر

۵-۲-۵) بازبینی، مرور و بررسی تغییر

۶-۲-۵) برقرار نمودن یک خط مبنا برای تست و آزمون

۷-۲-۵) کنترل نسخه قرار دادن در مخزن و باز نمودن قفل

۱-۷-۲-۵) تغییر گراف های تکاملی نرم افزار و اقلام پیکر بندی

۲-۷-۲-۵) کنترل نسخه و قرار دادن در مخزن و بز نمودن قفل

۸-۲-۵) اطلاع به افراد

اطمینان از کیفیت نرم افزار　 (SQA)

　قابلیت اطمینان:

　معیار: MTBF

　MTBF=MTTR+MTTF　　　　 　یا　　　 　Kloc / تعداد خطاها　　　　　 یا　　　 　Fp / تعداد خطاها

　قابلیت در دسترس بودن:

(MTTF/(MTTF+MTTR　

هرچه MTTR 　بیشتر باشد، قابلیت نگهداری بالاتر خواهد بود

　قابلیت امنیت نرم افزار:

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

　احتمال و تاثیر هریک از بحران ها را بررسی میکند و در نهایت نتیجه گیری می کند که برای رفع آنها چه کاری باید انجام شود.

نبود امنیت باعث شکست در پروژه و کنار گذاشتن نرم افزار می شود

تیم FTR 　:

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

تیم SQA:

　این تیم از مهندسین تشکیل شده که کارهای تکنیکی را انجام میدهند.

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

روشهای متداول در مهندسی نرم افزار

بررسی مراحل:

تحلیل، طراحی، پیاده سازی، تست و نگهداری و استقرار

به روش ساخت یافته

　تحلیل ساخت یافته:

محصول تحلیل، مشخصه تحلیل نرم افزار است که شامل:

1)　محدوده اطلاعات نرم افزار

2)　توابع یا عملکرد نرم افزار

3)　رفتار نرم افزار

4) کارایی

5)　محدودیتها

6)　DD فرهنگ داده ها

7)　Help نرم افزار

8) اعتبارسنجی

　مراحل ایجاد مشخصه تحلیل:

1) تشخیص مسئله: جمع آوری اطلاعات

2)　ارزیابی و سنتز راه حل: با ارزیابی هایی که انجام می دهیم راه حلی را انتخاب می کنیم

3) مدلسازی: بعد از انتخاب راه حل، از روی آن مدل می سازیم.

4) مشخصه: ترکیب مدلها مشخصه را ایجاد می کند.

5) مرور FTR

سپس مشخصه تحلیل وارد مخزن می شود.

روشهای جمع آوری اطلاعات:

1)　پرسشنامه

2)　کار کردن و حضور در محیط

3)　مصاحبه

4) مشاهده و مرور مستندات و رویه های کاری

5) FAST

6) QFD

7) نمونه سازی

　در گام تحلیل چه مدل هایی تولید می شود؟

1)　درگام محدوده اطلاعات نرم افزار: مدل　 ERD، CFD+Cspec، DFD+Dspec

2)　در گام توابع یا عملکرد نرم افزار: مدل CFD، DFD

3)　در گام رفتار نرم افزار: مدل STD

　مدل ERD:

1- تشخیص انواع موجودیت ها (موجودیت می تواند داده یا کنترل باشد.)

2- تشخیص ارتباط میان هر زوج موجودیت

3- تشخیص 　انواع ارتباطات میان هر زوج 　موجودیت

4- تشخیص درجه و الزام ارتباط (تشخیص یک به یک، یک به چند، چند به چند بودن ارتباطات)

5-تشخیص صفات موجودیت ها (صفت شناسه ، صفات توصیفی ، صفات ارجاعی)

6- FTR

مدل DFD :

راهنمای علائم به کار رفته در نمودارDFD:

فلش بیانگر داده ،

　دایره بیانگر فرایند ،

　دو خط موازی بیانگر مکان ذخیره سازی،

مستطیل بیانگر موجودیت خارجی می باشد .

سطوح مختلف DFD:

1) DFD سطح صفر: 　بهDFD 　سطح صفر Contex Diagram گفته می شود و یک نمای کلی از سیستم را نشان می دهد . در این سطح موجودیت های داخلی و خارجی را به همراه ورودی و خروجی آورده و از قراردادن مکان ذخیره سازی اجتناب می کنیم

2) DFD سطح 1 : در این سطح می توان در صورت نیاز مکان ذخیره سازی را در دیاگرام رسم کرد. در این سطح سیستم به اجزای کوچکتری شکسته می شود.

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

3) DFD سطح 2 : در این سطح خود زیرسیستم ها نیز به اجزای کوچکتر شکسته می شوند .

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

مدل CFD :

دو روش برای رسم این نمودار وجود دارد:

1) در مدل DFD کنترل یا رخدادها را با خط چین نشان دهیم.

2) روش مرسوم آن است که DFD 　را رسم کنیم سپس تمام داده های ورودی را حذف کنیم و دوباره روی کنترل هایی که در سیستم وجود دارد فکر کنیم.

در این حالت Event های خروجی به هیچ فرآیندی متصل نمی شوند و آن را به Cspec 　متصل می کنیم.

در Cspec 　جدولی به نام Pat وجود دارد که حاوی توضیحات مربوط به کنترل هاست و مشخص می کند که هر کنترل به کدام فرآیند وارد می شود.

توجه کنید که رویداد موجب فعال سازی فرایند نمی شود و مثل داده عمل می کند.

مدل STD :

　این نمودار حالتهای مختلف نرم افزار را نشان می دهد.

از مستطیل برای نمایش حالت پایدار سیستم (State) و از فلش برای حرکت بین حالات استفاده می کنیم .　وقفه باعث رفتن از یک حالت به حالت دیگر می شود.

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