سیستم های تکنیکی اجتماعی

صفحه 1:
سيستم هاى تكنيكى اجتماعى Omid.Mofidian@qmail. com 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 2:
re RV.) ا ا ل ا ل ال ل 9[ بيان ويؤكى هاى مبرم سيستم مانند قابليت اطمينان و امنيت ‎at rom erate od‏ | مفهوم سیستم های قدیمی 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 3:
| ‏ا‎ Reo Cee od aes) PANS | Db ee rn Se eee morn gor) ‏مكانيكى و الكتريكى باشد كه توسط افراد مختلف بكار كرفته مى شود.‎ ‏ا ل ا ا‎ eae ge) ‏ل‎ re ‏ا ا ا ا‎ ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 4:
1 Cn | RC es * _ سیستم هایی که شامل سخت افزار و نرم افزار بوده اما اپراتورها ۱۳ | at erence Coe poe Corer peepee cae EC on rene ‏رنده ی سیستم های تکنیکی بوده اما فرآیندهای‎ ‏عملیاتی و افرادی هستند که سیستم تکنیکی را مورد استفاده قرار می‎ ‏سیستم های تکنیکی اجتماعی با سیاست های سازمانی و قوانین کنترل‎ ‏مى شود.‎ ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 5:
enone Se) Rese coe Relea ses cere et core CCS 8) ‏غیرقطعی بودن‎ * وقتى ورودى يكسان عرضه شود هميشه خروجى مشابه ت بخخاطرايتكه رقتار سيسقم. بها ابراتورظاق اتساتى وابسقه اسك 00 الكت 0 لك 0 كسترش اقذاك«سازمانن ,يكتبائى سبيستم ببة خوخ اسيستم:وابسحه نمى بياغد. ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 6:
ویژگی های مبرم | tee we eS he on ene SS) ‏قطعات سیستم ناشی شود ترجیح داده می شود‎ ویژگی های مبرم نتیجه ی ارتباطات پین قطعات سیستم می باشد ا ا ا ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 7:
نمونه هایی از ویژگی های مبرم Description ‘The viume ofa system (the total spae occuied)vaties depening othowthe canponetasembliesare arangedndonneted System eliabiity dependsoomponetweliability bu unexpetedinterections can catse nevype of falure andthaefor afed thereiialility of thesygan Thesecuwiyy of thesystem (its alility to resstattack) is a canplexpropety tha. cannbbeeasly masued Atlacls maybedewsedtha wer nd anticipated byhe syslem cesignes andso maydded bult-n safeguals Ths popeyy refleds howeasyitis to fix a problem with thesystem oncathasbeen discoveed. Edepend leing ale to dagnee the proliem, acces thecomponets thd are filly andmodfy orrepacethesamponets This propery refleds howeasyitis to we the system Itdepembnthetechiicd system compornts, its opeators ands opeating enivormert. 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 8:
لك ی sls cb Shs *؟ وقتى ظاهر مى شوند كه تمامى بخش هاى سيستم با هم در جهت هدفى مشخص کار کنند. برای مثال؛ یکبار قطعات دوچرخه اسمبل شده و ویژگی عملياتى آن وسيله ى حمل و نقل است. ویژگی های مبرم غیرعملیاتی - کیفی *_ نمونه های لّن قابلیت اطمینان؛ کارآیی, ایمنی و امنیت می باشد. این ها به ا ‎et ee ne een‏ ال ا الت 00 این ویژگی ها سبب غیرقابل استفاده شدن سیستم می شود. 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 9:
prow ‏اا‎ بدلیل وابستگی درونی قطعات. عیوب می تواند در سیستم منتشر شود. خرابى ‎Bone rents‏ ا ‎le ee eee‏ رخ می دهد. oa FS | Earp ese re Oe ce rm eR جش 5 اطمينان نرم افزار ممكن است تصوير نادرستى از قابليت | 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 10:
قابلیت اطمینان و نفوذپذیری * قابليت اطمينان سخت افزار *؟ احتمال خرابى سخت افزار جقدر است و ترميم قطعه جقدر طول مى كشد؟ ا ا 00 | معمولا خرابى نرم افزار متمايز از خرابى سخت افزارى است. * قابلیت اطمینان اپراتور Cm pret Sc nan ei Ceo Pe ‏ا‎ 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 11:
[1 olbLi,! *؟ خرابى سخت افزارى مى تواند منجر به سيكنال هاى كاذب شود كه در خارج از محدوده ی ورودی های مورد انتظار نرم افزار است. بدلیل استرس و خطای اپراتور. نرم افزار می تواند خطاها را با آلارم هایی ۳ بح | باشد: 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 12:
ویژگی های نباید 1 pe] Bice el Cn SS BU CURgCS LECT] pe meee ye CRN aw OPC WS WS is Poe ايمنى- سيستم نبايد به شيوه اى ناامن رفتار كند؛ ل ول ‎Sa‏ | eS Sie lon 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 13:
مهندسی سستم ها 0 CITES RITE eS Rp bres ‏ا‎ ‏سيستم هاى تكنيكى اجتماعى.‎ با سرویس هایی از سیستم سروکار دارند که در ساخت. عملیات و روش ‎DEONT‏ ا 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 14:
۳ ‎Roe‏ ا ا ا ا ل لت 0 00 9 كزان است: نرم ,افزارممكن امت" ثاؤان فشكلات,سختت افزارئ .را بدهد. * مهندسان دركير سياست هاى مختلف كارى مى شوند ‎aris ere ene Stee ey Peery errr en‏ | ‎Baten reer BO] RN TI Fats| Ore COPD MOE FOS PIP oe‏ ‏2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 15:
6 ‏کاجه نان‎ System definition decommissionit ۳ System \\ aa لومساعي١‏ موی / Sub-systeny Eee System \daelopmen§ \_instaltion /) (System) \Uintegtion J Sonesta Se ee Cent eR ec tad 

صفحه 16:
۱۳ peal cote el tere | Softae | | Electnic | Mechanical } engineering | engineering’ engineering Zoe Structuat 1 ATC systems: | User interfadg engineering} engineering | design cwil ‏ا‎ Electrical 1 1 0 Architecter engineering’ | _ engineering ل 0 ممههم صها 

صفحه 17:
تعریف نیا زهای سیستم ‎٠.‏ سه نوع نیازمندی تعریف شده است ‎ ‎a ee a ae ee eC ‏است؛‎ ‏لل ا ل ا ا ل ‏ل ا ا ا ا ‎ee Ee‏ ‏ا 2 ‏ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه ‎ 

صفحه 18:
57 | RY. | ‎٠.‏ باید تعریف شود که چرا یک سیستم به محیطی خاص نیاز دارد. * اهداف عملياتى ا ا ا ا ا ا ا ا داخلى و خارجى را براى آتش سوزى يا ورود سارقين اعلام كند. ؟ اهداف سازمانى ‎ *‏ تضمین می کند که کارهای عادی در ساختمان انجام شده توسط رویدادهایی ‎1 ren Tare ‏2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق ‎ 

صفحه 19:
مشكلات نيازمندى هاى سيستم ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 20:
فر آيند طراحى سيستم ا نا ا ‎Denes ene‏ تعريف زيرسيستم 5 ل ا 0 درب ركيرند. 0 ۱ تا ree Cae Cn Sierras ‏تعريف رابط هاى زيرسيستم‎ ۴ . فعالیت های بحرانی برای توسعه ی موازی زیرسیستم ها. 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 21:
1۲3۳0007 ۱ (Pefine sub-system, \ equiements ‏إر‎ \ interfaces ‏زر‎ Ly Identify (Specify sub-system, \__ sub-systems \_- functionality J 3 5 i 8 / Assignequiements to sub-systems | 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 22:
مشکلات طراحی سیستم | OE eR he eS CES ote ‏مشكلات مختلف طراحى بسهولت با كمك نرم افزار حل مى شوند.‎ * ‏مشكلات سخت افزارى ممكن است براى نيازهاى نرم افزارى نامناسب‎ * ‏باشند برای اینکه نرم افزار باید آن را جبران کند.‎ 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 23:
طراحی و نیازها مهندسى نيازها و طراحى سيستم با هم مرتبطند. م ا ا اا ا ‎fey yalirereel) ewe:‏ 1 د در طراحی اولیه ممکن است ساختار نیازمندی ها ضروری باشد. 5 ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 24:
نیازمندی ها/طراحی مدل حلزونی Requirements Elctation and Analysis architectural Design Problem Review and Definition Assessment SO ne Cent eR ec ae} 

صفحه 25:
مدلسازی سیستم Ny pee LS Se pee 5 SI ele PPC RUE eer On ne ‏نشان می دهد‎ RW UR anemones Borer EU Rc teas me keee I oe معمولا بصورت یک بلاک دیاگرام نشان داده می شود ممکن است انواع مختلفی از قطعات عملیاتی در مدل تعریف شود 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 26:
Door sensors Alam contoller I External ۲ contol cenér| Voice ‘Telephone synthesis caller | 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 27:
Description Detets manent inthe rons monitowdby the sytan_ Detets cboropering in the extemaldoors 6 the building Controls fhe operaton of thesystem Emitsan audible waming whenanintruderis sspeded Synthesizesa voicemessayegiving the location d'tle sspededirtruder Makes extenal cals notify secuity, the police et. See Cent me Rec ‏«ماوحطه‎ 2 Subsytem Movenert sensors Door sensas Alarmoontnoller Siren Voicesynbesizer ‘Tdezhone aller 000 CeL Ty 

صفحه 28:
۹ SOR Cent eR econ ary 

صفحه 29:
توسعه ی زیرسیستم ل ‎ORCS OE Sans bok‏ ا ا ‎acer‏ ل ل ري ‎trea we‏ 00 ne CPR Sea Re eT تغییر در بروکراسی و مکانیزم کند به معنی زمانبندی توسعه است زیراکه نياز به دوباره كارى دارد. ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 30:
یگپار حکی سیسنم ‎eres Se SEE ee en oe Bip oe ara cele)‏ نت ‎BUDO ee eee s wee Seat ret een‏ ‎Cece LCE Meena Hw ces Cows rer‏ 0 *» ممكن است مشكلات با ناهماهنكى قطعات سيستم همراه باشئد. ‏ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 31:
قبل از تکمیل. سیستم در محیط مشتری نصب شود *؟ فرضيات محيطى ممكن است نادرست ب 0 ‎eee coe‏ ا ل ل ل *؟ء ممكناست مشكلات فيزيكى نصب (مشكلات كابلى) بوجودآيد؛ ‎sewed eee SY el‏ 0م ‎eras PLS See Cent me Rec ‏«ماوحطه‎ 2 ‎ 

صفحه 32:
0 ol) سیستم های قدیمی عمری طولانی داشتند. باید تغییر نیاز انجام شود. ۴ تکامل ذاتاً گران است تغیبرات باید از ددگاه های تکنیکی و تجاری تحلیل شود؛ رسيستم ها مى توانند مشكلات بيش بينى نشده داشته باشند؛ تصميمات طراحى بندرت وجود دارد؛ تا بوجود آيد. سيستم هاى موجودى كه بايد نكهدارى شود كاهى اوقات سيستم هاى | 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 33:
تجزيه ى سيستم ۴ سیستم ها قبل از دوره ی استفاده کنارگذارده می شوند. *؟ ممكن است نياز به حذف موادى (شيميايى) باشد كه در محيط است ‎erased‏ ا ا ل ا ل ا ل ا ا ا ا ا ا ا باشد: ‏2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق ‎ 

صفحه 34:
سازمان ها /افراد /سیستم ها 00 Pe, res reece ea ‏تجارى يا سازمانى عمل مى نمايد.‎ ‏بر‎ ‏لك‎ SSRIS ‏ل‎ eae eee ewe) ‏می گیرد.‎ 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 35:
۰ آیا کاربران ناوارد یک محیط باعث تغییر در شیوه ی کاری می شوند؟ ؟ تغييرات سازمانى آيا سيستم ساختار قدرت را در يك سازمان تغيير مى دهد؟ ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 36:
فر آيندهاى سازمانى 0 ‏ا ا‎ pene cele) ‏ف رآيندهاى سازمانى فرآيندهاى دركير در بكاركيرى سيستم مى باشد.‎ ‏در سيستم هاى جديدء به عنوان بخشى از طراحى سيستم تعريف مى‎ Mig فرآنید سازمانی باید برای انعطاف پذیری طراحی شود و نباید ‎em re oye pe Cmte Pe mn Cael Oe RO‏ 50 صورت مشکل ارات ان 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 37:
ف رآيندهاى توسعه /تهيه Procureme: process Developme’ process Operationa process Coser PLS See Cent me Rec ‏«ماوحطه‎ 2 

صفحه 38:
تهیه ی سیستم بدست آوردن یک سیستم برای یک سازمان ا ل 0 از تهیه 00000 5ك ۱ *؟ ممكن است براى قرارداد تجارى استاندارد تعبين مشخصات لازم باشد. معمولاً توسعه ارزانتر است * سيستم هاى ييجيده ى قديمى شامل مخلوطى از قطعات استاندارد و طراحى شده ى خاص است. فرايندهاى تهيه براى اين نوع از قطعات معمولا متفاوتند. ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 39:
Of-the-shelf systenwailble 7 5 Choose /Assueaquest\ (Choose system J *\ forbids ‏ار‎ supplier Surey méet 6r existing systems, /(Issueaquest ») Select ( Negotte (Tet conact 6r = = ليا ‎to tender tender "conta \_ development,‏ __\ ‎Custom system‏ requind See Cent me Rec ‏«ماوحطه‎ 2 

صفحه 40:
1 ۳ [1 ‏ل ل‎ aie ate Ce COCR S ‏شوند.‎ تعیین مشخصات نیازها ممکن است بخشی از قرارداد برای توسعه ی سيستم باشد. 7 ا ل 1 موافقت تغییرات انجام می شود 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 41:
ييمانكاران و زيرييمانكاران * تهيه ى سيستم سخت افزاری/نرم افزاری بزرگ معمولا پر اساس ‎es we‏ ال *؟ زيرييماتكاران بخشى هايى از سيستم را براى يشتيبانى به كاريردازان ديكر می دهند. مشتریان با زیریمانکاران سروکار دارند. 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 42:
‎tee!‏ ا ‎System } customer ‎Principal ‎contractor ‎| ‎۱ Subcontactor 1 | Subcontactor 2 | Subcontactor 3 ‎ ‎TEC ent eR Tec ee‏ 0 عللنصمههمک صها ‎ ‎ 

صفحه 43:
۱۳ yd 2 roe a acne CO eae ‏قدیمی توسعه يافتند.‎ ا ا ا ا ا ل پالاشت ی ۳ | ees e Cts “OMT icutlp pean wean! ات ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 44:
Embeds knowledge of Uses r | Support softwéire Application {|__| Business policifis software and rules ۳ Runs-on Uses \e Constrain System Application Business hardware data processes 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

صفحه 45:
ا 10 سخت افزار- ممكن است سخت افزار منسوخ باشد. رب ‎entre by‏ | 0000 نرم افزارهای کاربردی- ممکن است در زبان ‎sh‏ پرنامه نویسی منسوخ نوشته شده داده هاى كاربردى- غالباً ناكامل و ناجور است. 1 قوانین و سیاست های تجاری- ممکن است ضمنی و جاسازی شده در نرم افزار سيستم باشد ا ‎See Cent me Rec‏ 4 6 للتتعسصره5 ممه 

صفحه 46:
Application software Support software Hardware 2 «ماوحطه ‎See Cent me Rec‏ 4 مللزنعههه5 صعاق 

سیستم های تکنیکی اجتماعی Omid.Mofidian@gmail. com ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 اهداف ‏ ‏ ‏ ‏ درک سیستم تکنیکی اجتماعی و تفاوت آن با سیستم مبتنی بر کامپیوتر بیان ویژگی های مبرم سیستم مانند قابلیت اطمینان و امنیت آشنایی با فعالیت های سازمانی مفهوم سیستم های قدیمی ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 سیستم چیست؟ ‏ ‏ ‏ ‏ مجموعه ای از قطعات به هم مرتبط که جهت رسیدن به هدفی مشترک کار می کنند. ممکن است یک سیستم شامل نرم افزار ،سخت افزار الکترونیکی، مکانیکی و الکتریکی باشد که توسط افراد مختلف بکار گرفته می شود. ممکن است قطعات یک سیستم به قطعات سیستم دیگر وابسته باشند. ویژگی ها و رفتار قطعات سیستم باهم آمیخته است. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 طبقه بندی های سیستم های نرم افزاری ‏ سیستم های تکنیکی مبتنی بر کامپیوتر • ‏ سیستم هایی که شامل سخت افزار و نرم افزار بوده اما اپراتورها و فرآیندهای عملیاتی بخشی از سیستم مشروحه نمی باشد .سیستم خودآگاهانه نیست. سیستم های تکنیکی اجتماعی • سیستم هایی که دربرگیرنده ی سیستم های تکنیکی بوده اما فرآیندهای عملیاتی و افرادی هستند که سیستم تکنیکی را مورد استفاده قرار می دهد. سیستم های تکنیکی اجتماعی با سیاست های سازمانی و قوانین کنترل می شود. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 مشخصات سیستم تکنیکی اجتماعی ‏ ویژگی های مبرم • ‏ غیرقطعی بودن • ‏ ویژگی های سیستم به کل قطعات سیستم و ارتباطشان وابسته است. وقتی ورودی یکسان عرضه شود همیشه خروجی مشابه تولید نمی شود بخاطراینکه رفتار سFیستم به اپراتورهای انسانی وابسته است. ارتباطات پیچیده با اهداف سازمانی • گسترش اهداف سازمانی پشتیبانی سیستم به خود سیستم وابسته نمی باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 ویژگی های مبرم ‏ ‏ ‏ ویژگی های کل سیستم به ویژگی هایی که می تواند از ویژگی های قطعات سیستم ناشی شود ترجیح داده می شود ویژگی های مبرم نتیجه ی ارتباطات بین قطعات سیستم می باشد می توان سازگاری یک قطعه را در سیستم سنجش کرد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 نمونه هایی از ویژگی های مبرم Property Description Volume The vo lume of a system (the total spac e occup ied) varies depend ing onhowthe componen t assembliesare arrangedandconnec ted. Reliability System reliability depends oncomponen t reliability but unexpectedinteractions can cause newtypes of failure andtherefore affect thereliability of thesystem. Security Thesecurity of thesystem (its ability to resist attack) is a complex proper ty that canno t beeasily measured. Attacks may bedevisedthat were not anticipated bythe system designers andso may defeat built-in safegua rds. Repairability This property reflects howeasyit is to fix a problem with thesystem onceit hasbeen discovered. It depends on being ab le to diagno se the problem, acce ss thecomponen ts that are faulty andmodify or replacethesecomponen ts. Usability This property reflects howeasyit is to use the system. It depend s onthetechnical system compon ents, its operators andits operating env ironment. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 انواع ویژگی ها ‏ ویژگی های عملیاتی • ‏ وقتFی ظاهFر مFی شونFد کFه تمامFی بخFش های سFیستم بFا هFم در جهFت هدفی مشخFص کار کنند .برای مثال ،یکبار قطعات دوچرخFه اسFمبل شده و ویژگی عملیاتی آن وسیله ی حمل و نقل است. ویژگی های مبرم غیرعملیاتی – کیفی • نمونFه های آFن قابلیFت اطمینان ،کارآیFی ،ایمنFی و امنیFت مFی باشد .ایFن هFا به رفتار سFیستم در محیFط عملیاتFی وابسFته اند .ایFن هFا در واقFع برای سیستم های مبتنFی بر کامپیوتFر بحراتFی بوده بطوریکFه سFطح پاییFن ایFن ویژگFی هFا سبب غیرقابل استفاده شدن سیستم می شود. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 مهندسی قابلیت اطمینان سیستم ‏ ‏ ‏ ‏ بدلیل وابستگی درونی قطعات ،عیوب می تواند در سیستم منتشر شود. خرابی های سیستم بدلیل ارتباطات پیش بینی نشده درونی بین قطعات رخ می دهد. شاید پیش بینی تمامی ارتباطات قطعات امری محال باشد. سنجش قابلیت اطمینان نرم افزار ممکن است تصویر نادرستی از قابلیت اطمینان سیستم ارائه دهد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 قابلیت اطمینان و نفوذپذیری ‏ قابلیت اطمینان سخت افزار • ‏ قابلیت اطمینان نرم افزار • ‏ احتمال خرابی سخت افزار چقدر است و ترمیم قطعه چقدر طول می کشد؟ احتمال اینکFه قطعFه ی نرم افزاری خروجFی نامناسFبی تولیFد کنFد چقدر است؟ معموالً خرابی نرم افزار متمایز از خرابی سخت افزاری است. قابلیت اطمینان اپراتور • احتمال اینکه اپراتور یک سیستم خطا کند چقدر است؟ ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 ارتباطات قابلیت اطمینان ‏ ‏ ‏ خرابی سخت افزاری می تواند منجر به سیگنال های کاذب شود که در خارج از محدوده ی ورودی های مورد انتظار نرم افزار است. بدلیل استرس و خطای اپراتور ،نرم افزار می تواند خطاها را با آالرم هایی نشان دهد. محیط نصب یک سیستم می تواند قابلیت اطمینان داشته باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 ویژگی های نباید ‏ ‏ ویژگی هایی مانند کارآیی و قابلیت اطمینان می تواند سنجیده شود. برخی از ویژگی ها ،ویژگی هایی هستند که سیستم نباید نمایش بدهد • • ‏ ایمنی -سیستم نباید به شیوه ای ناامن رفتار کند؛ امنیت -سیستم نباید دسترسی غیرمجاز بدهد. سنجش یا تخمین این ویژگی ها بسیار دشوار است. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 مهندسی سیستم ها ‏ ‏ تعیین مشخصات ،طراحی ،پیاده سازی ،معتبرسازی ،گسترش و نگهداری سیستم های تکنیکی اجتماعی. با سرویس هایی از سیستم سروکار دارند که در ساخت ،عملیات و روش های مورد استفاده ی آنها محدودیت وجود دارد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیند مهندسی سیستم ‏ معموالً از مدل آبشاری پیروی می کنند چون احتیاج به توسعه ی موازی بخش های مختلف سیستم دارند • ‏ محدوده ی کوچکی از تکرار بین فازها بخاطر تغییرات سخت افزاری بسیار گران است .نرم افزار ممکن است تاوان مشکالت سخت افزاری را بدهد. مهندسان درگیر سیاست های مختلف کاری می شوند • سوءتفاهم های بسیاری وجود دارد .سیاست های مختلف ،نیاز به مذاکرات بسیار و استفاده از واژگان متفاوت دارد .مهندسان باید آن را محقق کنند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیند مهندسی سیستم ها Requir ements definition System decommissioning System design System evolution Sub-system development System installa tion System integr ation ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 نظام های داخلی کنترل ترافیک هوایی Software engineering Structur al Electr onic engineering Mechanical engineering ATC systems User interface engineering engineering design Civil engineering Electrical engineering Architectur e ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 تعریف نیازهای سیستم ‏ سه نوع نیازمندی تعریف شده است • • • ‏ نیازهای عملیاتی انتزاعی .عملیات سیستم در شیوه ای انتزاعی تعریف شده است؛ ویژگی های سیستم .نیازهای کیفی سیستم هستند. مشخصات نامطلوب .رفتار غیرقابل قبول سیستم مشخص شده است. باید مطابق با اهداف سازمانی باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 اهداف سیستم ‏ ‏ باید تعریف شود که چرا یک سیستم به محیطی خاص نیاز دارد. اهداف عملیاتی • ‏ تهیه ی یک سیستم ضدسرقت و آتش سوزی برای ساختمان که اخطارهای داخلی و خارجی را برای آتش سوزی یا ورود سارقین اعالم کند. اهداف سازمانی • تضمین می کند که کارهای عادی در ساختمان انجام شده ،توسط رویدادهایی مثل آتش سوزی و سرقت مختل نمی گردد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 مشکالت نیازمندی های سیستم ‏ معموالً سیستم های پیچیده مسائل دشواری دارند • • ‏ ‏ مشکالتی که کام ً ال درک نمی شود؛ تغییر سیستم باید توسعه های ارتباطی/سخت افزاری روی سیستم پیش بینی شود. تعریف نیازهای کیفی بدون دانش ساختار سیستم سخت است. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیند طراحی سیستم ‏ تقسیم بندی نیازها • ‏ نیازهای سازمانی در گروه های مربوطه تعریف زیرسیستم ها • معرفی مجموعه ای از زیرسیستم ها که می توانند مجموعه ای از نیازهای سیستم را دربرگیرند. ‏ تعیین نیازهای زیرسیستم ها ‏ تعیین وظیفه مندی زیرسیستم ها تعریف رابط های زیرسیستم • ‏ • وقتی که از COTSاستفاده شود مشکالتی بروز می کند. فعالیت های بحرانی برای توسعه ی موازی زیرسیستم ها. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیند طراحی سیستم Partition requir ements Define sub-system interfaces Identify sub-systems Specify sub-system functionality Assignequir r ements to sub-systems ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 مشکالت طراحی سیستم ‏ ‏ ‏ نیازهای جزیی سخت افزاری ،نرم افزاری و قطعات ممکن است بحث شود. مشکالت مختلف طراحی بسهولت با کمک نرم افزار حل می شوند. مشکالت سخت افزاری ممکن است برای نیازهای نرم افزاری نامناسب باشند برای اینکه نرم افزار باید آن را جبران کند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 طراحی و نیازها ‏ ‏ ‏ ‏ مهندسی نیازها و طراحی سیستم با هم مرتبطند. محدودیت ها به محیط سیستم و سیستم های مرتبط دیگر مربوط می شود، ممکن است این محدودیت یک نیاز باشد. در طراحی اولیه ممکن است ساختار نیازمندی ها ضروری باشد. در طراحی ،نیازها را کشف می نمایید. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 طراحی مدل حلزونی/نیازمندی ها Requirements Elicitation and Analysis Architectural Design Start Problem Definition Review and Assessment System Requirements and Design ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 مدلسازی سیستم ‏ ‏ ‏ ‏ یک مدل معماری دیدگاهی انتزاعی از زیرسیستم های یک سیستم را نشان می دهد ممکن است شامل جریان اطالعات بین زیرسیستم ها باشد معموالً بصورت یک بالک دیاگرام نشان داده می شود ممکن است انواع مختلفی از قطعات عملیاتی در مدل تعریف شود ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 سیستم ضدسرقت Movement sensors Door sensors Alarm contr oller Siren ©Ian Sommerville 2004 Voice synthesis er Telephone caller External contr ol centr e Software Engineering, 7th edition. Chapter 2 زیرسیستم ها Sub-system Description Movement sensors Detects movement in the rooms monitoredby the system Door sensors Detects door opening in the external doors of the building Alarmcontroller Controls the operation of thesystem Siren Emitsan audible warning whenan intruder is suspected Voicesynthesizer Synthesizesa voicemessagegiving the location of the suspectedintruder Telephone caller Makes external calls to notify security, the police, etc. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 ATC یستمDیسD عمارDم Radar system Position processor Aircraft simulation system Transponder system Backup position processor Data comms . system Aircraft comms . Comms . processor Telephone system Backup comms . processor Flight plan database Weather ma p system Accounting system Contr oller info. system Contr oller consoles Activity lo gging system ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 توسعه ی زیرسیستم ‏ ‏ ‏ ‏ توسعه ی سخت افزاری ،نرم افزاری و ارتباطی موازی پروژه ها. ممکن است سیستم ها بصورت COTSتهیه شوند. فقدان ارتباط بین تیم های پیاده ساز. تغییر در بروکراسی و مکانیزم کند به معنی زمانبندی توسعه است زیراکه نیاز به دوباره کاری دارد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 یکپارچگی سیستم ‏ ‏ ‏ ‏ فرآیند سخت افزار ،نرم افزار و افراد با یکدیگر سیستم را می سازد. باید از عهده ی یکپارچگی زیرسیستم ها در یک زمان برآید. معموالً مشکالت رابط بین زیرسیستم ها در این مرحله پیدا می شود. ممکن است مشکالت با ناهماهنگی قطعات سیستم همراه باشند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 نصب سیستم ‏ قبل از تکمیل ،سیستم در محیط مشتری نصب شود • • • • • فرضیات محیطی ممکن است نادرست باشند؛ ممکن است انسان در برابر سیستم جدید مقاومت کند؛ سیستم ممکن است با سیستم های دیگر همزیستی داشته باشند؛ ممکن است مشکالت فیزیکی نصب (مشکالت کابلی) بوجودآید؛ آموزش اپراتور تعریف شده باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 تکامل سیستم ‏ ‏ سیستم های قدیمی عمری طوالنی داشتند .باید تغییر نیاز انجام شود. تکامل ذاتاً گران است • • • • ‏ تغییرات باید از دیدگاه های تکنیکی و تجاری تحلیل شود؛ زیرسیستم ها می توانند مشکالت پیش بینی نشده داشته باشند؛ تصمیمات طراحی بندرت وجود دارد؛ تغییرات باید در ساختار نامناسب سیستم بوجود آید. سیستم های موجودی که باید نگهداری شود گاهی اوقات سیستم های قدیمی نامیده می شود. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 تجزیه ی سیستم ‏ ‏ سیستم ها قبل از دوره ی استفاده کنارگذارده می شوند. ممکن است نیاز به حذف موادی (شیمیایی) باشد که در محیط است • ‏ طراحی سیستم باید توسط کپسوله سازی برنامه ریزی شود. ممکن است نیاز به داده تغییریافته و قابل استفاده در سیستم مشابه دیگر باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 سازمان ها/افراد/سیستم ها ‏ ‏ سیستم های تکنیکی اجتماعی سیستم های سازمانی هستند که در راستای تجاری یا سازمانی عمل می نماید. درصورتی که درک نکنید در محیط سازمانی چه سیستمی مورد استفاده قرار می گیرد ،سیستم کمتر نیازهای واقعی تجاری و کاربران را درنظر می گیرد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فاکتورهای سازمانی و انسانی ‏ تغییرات فرآیندی • ‏ تغییرFات شغلی • ‏ آیا تغییرات سیستم در فرآیند کاری محیط ضروری است؟ آیا کاربران ناوارد یک محیط باعث تغییر در شیوه ی کاری می شوند؟ تغییرات سازمانی • آیا سیستم ساختار قدرت را در یک سازمان تغییر می دهد؟ ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیندهای سازمانی ‏ ‏ ‏ فرآیند مهندسی سیستم ها در تقابل با فرآیندهای سازمانی می باشد. فرآیندهای سازمانی فرآیندهای درگیر در بکارگیری سیستم می باشد. در سیستم های جدید ،به عنوان بخشی از طراحی سیستم تعریف می شوند. فرآنید سازمانی باید برای انعطاف پذیری طراحی شود و نباید بصورت جزیی عمل کند .مهم است که اپراتورهای انسانی بتوانند در صورت مشکل از آن استفاده کنند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 تهیه/فرآیندهای توسعه Procurement process Development process Operational process ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 تهیه ی سیستم ‏ ‏ بدست آوردن یک سیستم برای یک سازمان برخی مشخصات سیستم و طراحی معماری ضروری است بعد از تهیه • • ‏ تعیین مشخصات برای توسعه ی سیستم نیاز است ممکن است برای قرارداد تجاری استاندارد تعیین مشخصات الزم باشد .معمو ًال توسعه ارزانتر است سیستم های پیچیده ی قدیمی شامل مخلوطی از قطعات استاندارد و طراحی شده ی خاص است .فرآیندهای تهیه برای این نوع از قطعات معموال متفاوتند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 فرآیند تهیه سیستم Off-the-shelf systemvaila a ble Adapt requir ements Choose system Issue equest r for bids Choose supplier Issue equest r to tender Select tender Negotia te contract Let contr act or f development Survey mar ket or f existing systems Custom system requir ed ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 پی آمدهای تهیه ‏ ‏ ‏ نیازها ممکن است برای تطابق ظرفیت های قطعات استاندارد دستکاری شوند. تعیین مشخصات نیازها ممکن است بخشی از قرارداد برای توسعه ی سیستم باشد. قبل از اینکه پیمانکاران سیستمی را انتخاب نمایند معموالً در مذاکرات موافقت تغییرات انجام می شود ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 پیمانکاران و زیرپیمانکاران ‏ ‏ ‏ تهیه ی سیستم سخت افزاری/نرم افزاری بزرگ معموالً بر اساس پیمانکاران جزیی است. زیرپیمانکاران بخشی هایی از سیستم را برای پشتیبانی به کارپردازان دیگر می دهند. مشتریان با زیرپیمانکاران سروکار دارند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 زیرپیمانکار/مدل پیمانکار System customer Principal contractor Subcontr actor 1 ©Ian Sommerville 2004 Subcontractor 2 Subcontractor 3 Software Engineering, 7th edition. Chapter 2 سیستم های قدیمی ‏ ‏ سیستم های تکنیکی اجتماعی که با استفاده از تکنولوژی منسوخ و قدیمی توسعه یافتند. عملیات تجاری بسیار دشوار است و همچنین ریسک این سیستم ها باالست • • ‏ مشتریان بانک؛ سیستم نگهداری هواپیما. سیستم های قدیمی فرآیندهای تجاری جدید را تحمیل کرده و بودجه ی باالیی را مصرف می کند. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 Support software Runs-on System hardware ©Ian Sommerville 2004 Uses Runs-on Embeds knowledge of Application software Uses Application data Business policies and rules Uses Constrains Business processes Software Engineering, 7th edition. Chapter 2 قطعات سیستم قدیمی ‏ سخت افزار -ممکن است سخت افزار منسوخ باشد. ‏ نرم افزار پشتیبان -ممکن است برای پشتیبانی نرم افزار از کارپردازانی که در تجارت قدیمی نیستند استفاده شود. ‏ نرم افزارهای کاربردی -ممکن است در زبان برنامه نویسی منسوخ نوشته شده باشد. ‏ داده های کاربردی -غالباً ناکامل و ناجور است. ‏ فرآیندهای تجاری -ممکن است با ساختار نرم افزاری و وظیفه مندی همراه باشد. ‏ قوانین و سیاست های تجاری -ممکن است ضمنی و جاسازی شده در نرم افزار سیستم باشد. ‏Software Engineering, 7th edition. Chapter 2 ©Ian Sommerville 2004 Socio-technical system Business processes Application software Support software Hardware ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2