SİSTEM MÜHENDİSLİĞİ BİLGİ ALANLARI

SİSTEM MÜHENDİSLİĞİ BİLGİ ALANLARI ÖMER ERTEKİN PSCONSULTECH H D M Sistem Mühendisliği Bilgi Alanları, Sürüm1 1

DERS1.KONU1 PROJE KAPSAMI Sistem Mühendisliği Bilgi Alanları, Sürüm1 2

GEREKSİNİMLERİN TEMELLERİ İhtiyaçların ve problemlerin doğru tanımlanması etkin ve gerçekçi gereksinim yönetimi ile mümkün olabilir. Gereksinim yönetimi de, sistem mühendisliğinin diğer bilgi alanları gibi, hem mühendislik hem de yönetim becerileri ve eforu gerektirir. Günümüzde uygulanan (uygulanmaya çalışılan) gereksinim yönetimi çalışmalarında ise çoğunlukla mühendislik becerileri üzerine yoğunlaşılmış ve ironik bir şekilde sistem mühendisliği usullerinden (bütüncül bakış, bağlam ve kavram dan yola çıkma) çok, bileşen mühendisliği usulleri (teknik olarak doğru yazılmış, izlenebilir gereksinimler) kullanılmıştır. Bütün bunlardan hareketle, etkin ve verimli sistem çözümlerine temel oluşturacak gereksinim yönetimi için, Projenin kapsamı (yetenekler) tanımlı olmalıdır Projenin bağlamı (harekât ihtiyacı, ortamı, personel, süreçler vb.) tanımlı olmalıdır Tüm paydaşlar (iyi ya da kötü yönde etkilenen) dikkate alınmalıdır Gereksinimlerin değişebileceği (ama kontrollü ve sonlara doğru azalarak) kabul edilmelidir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 3

SİSTEM VİZYONU ve PROJE KAPSAMI Sistem Vizyonu Sistemin ulaşması beklenen en son şekil ile ile ilgili uzun vadeli stratejik görü. Proje Kapsamı Erişilmesi planlanan son şeklin, mevcut proje tarafından oluşturulacak kısmı. Kapsam mevcut projeye neyin dahil (neyin hariç) olduğunun belirtilmesidir. Sürüm_1 Proje Kapsamı Sürüm_2 Proje Kapsamı Sürüm_n Proje Kapsamı Sistem Vizyonu Müşteri hemen hemen her zaman vizyonu kapsam yerine koymaya çalışır Satıcı/geliştirici de her zaman elindeki ürünü / kolayca yapabileceğini kapsam olarak kabul ettirmeye çalışır Sistem Mühendisliği Bilgi Alanları, Sürüm1 4

PROJE KAPSAM YÖNETİMİ Sistem Mühendisi de kendi kabulünü her iki tarafa kapsam olarak dayatır doğrusu Proje Kapsam Yönetimi, proje ekibi de dahil olmak üzere tüm proje paydaşlarının Proje tarafından hangi ürünlerin üretileceği ve Proje aşamalarında hangi süreçlerin kullanılacağı konularında hemfikir olmalarının sağlanmasıdır. Sistem Mühendisliği Bilgi Alanları, Sürüm1 5

DERS1.KONU2 SİSTEM BAĞLAMI Sistem Mühendisliği Bilgi Alanları, Sürüm1 6

SİSTEM BAĞLAMI Bir sistemin ortamı, sistemin bir parçası olmayıp da, durumunda bir değişiklik olduğunda sistemi etkileyen, bileşenler ve bu bileşenlerin davranışlarının oluşturduğu bir kümedir. Sistemin özelliklerini ya da davranışlarını etkileyemeyen harici bileşenler sistemin ortamında kabul edilmezler. (Ackoff 1971) Bağlam (analitik): Sistemi ve sistem davranışını anlayabilmek için dikkate almamız gereken harici varlıklar ve durumlar. Simon (1996)a göre ortam, sistemin isterleri karşılamak üzere konumlandırıldığı yuva dır. Bağlam (mimari) : Mimari yapının uyum içinde olması gereken yuva sı. Tasarımcının sağlaması gereken hedefler ve sınırlamaların bir sonucu olarak karşımıza çıkar. Sistem Mühendisliği Bilgi Alanları, Sürüm1 7

KAPSAM ve BAĞLAMI Proje kapsamı, bir sistem uygulamasının bir işin ya da operasyonun hangi kısımlarını destekleyeceğini tanımlar. Proje kapsamı aynı zamanda, sistem uygulamasının, diğer sistemler ve iş/operasyon ile nasıl etkileşim içinde olacağını da tanımlar. Proje kapsamı ancak bir bağlam içinde tanımlanabilir. Bir bağlam diyagramı bir sistemin ya da projenin kapsamını ve sınırlarını tanımlar. Bir proje de kapsam değişebileceğine göre (kapsam değişmeden gereksinimler değişebilir mi?) bağlam da değişebilir. Bağlam diyagramı yerine ortam modeli terminolojisi de kullanılabilir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 8

SİSTEM SINIRLARI KONSEPTİ Diğer Ortam Sistem Diğer Sistem Arayüzler İlgi Sistem Diğer Sistem Sadece sistem, Diğer Sistem Sisteme arayüzü olan harici varlıklar, Ve sistemin bu harici varlıklar ile olan arayüzleri Hedef Harici varlıkları ve arayüzleri içeren (bağlam bakışı) bir model oluşturun. Bu model mimari ekibi tarafından geliştirilen ilk model olacaktır. Farklı seviyeler (sistem, alt sistem, ) için oluşturulabilir Sistem Mühendisliği Bilgi Alanları, Sürüm1 9

DERS1.KONU3 PAYDAŞ ANALİZİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 10

PAYDAŞ NEDİR Paydaşlar, projenin gerçekleştirilmesi ve proje ürünlerinin işletilmesinde doğrudan ya da dolaylı payı olan (etkileyen ya da etkilenen) gerçek ve tüzel kişilerdir. Sistem için kim ödeme yapıyor? Sistem kimin için geliştiriliyor? Sistemi kim idame edecek? Sistem parçalarını kim temin edecek? Sistem konusunda uzmanlık kimlerde mevcut? Sistemi kim tasarlıyor/geliştiriyor? Sistem prensiplerini kim belirliyor? Sistemi kim kullanacak? Bu analizi yaptığınıza göre siz de bir paydaşsınız! Sistem Mühendisliği Bilgi Alanları, Sürüm1 11

PAYDAŞLAR Projeden etkilenen herkes: İşletmenler Sistem girdi ve çıktıları ile ilişkili personel Bağlanılacak diğer sistemlerin sahipleri İş yapış şekilleri etkilenecek bireyler Proje hakkında iletişim içinde olmanız gereken herkes Sistem Mühendisliği Bilgi Alanları, Sürüm1 12

DERS1.KONU4 İŞLETİM KONSEPTİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 13

İŞLETİM KONSEPTİ Sistem işletiminde bir gün Sistem Mühendisliği Bilgi Alanları, Sürüm1 14

Gereksinimler ve İşletim Konsepti The concept of operations (ConOps) document is a bridge between the operational requirements (events occurring over time) and the technical requirements (static, hierarchical description). It is written in narrative prose that is in the user's language. It states priorities, it uses visual images and leads to sofware requirements. IEEE Standard 1362, IEEE Guide for Concept of Operations Document, 1998. Sistem Mühendisliği Bilgi Alanları, Sürüm1 15

TEMELLER NE? Mission Need Statement (MNS)-Görev İhtiyacı Dokümanı An MNS justifies why one system is needed. It doesn t express anything about the new system, except to define problems it should solve, constraints in which it must operate, and some high level objectives it should meet. Concept of Operations (CONOPS)-İşletim Konsepti A CONOPS describes how a proposed system will fit into the existing infrastructure of your organization how it will affect other systems, staffing, logistics, and other concerns at a high level. Operational Requirements Document (ORD)-Harekat İhtiyaçları Dokümanı An ORD describes the overall requirements for one system, how it interacts with other systems, why the existing system isn t good enough, and set performance goals for the new system. An ORD is generally more detailed than a CONOPS. Sistem Mühendisliği Bilgi Alanları, Sürüm1 16

KLAVUZLAR ANSI/AIAA G-043-1992 guide from American National Standards Institute IEEE 1362-1998 IEEE guide for CONOPS document DI-IPSC-81430 DoD data item description for CONOPS document Title page Revision chart Preface Table of contents List of figures List of tables 1. Scope 1.1 Identification 1.2 Document overview 1.3 System overview 2. Referenced docum ents 3. 4. 5. Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints 3.3 Description of the current system or situation 3.4 Modes of operation for the current system or situation 3.5 User classes and other involve d personnel 3.6 Support environment Justification for and nature of changes 4.1 Justication of changes 4.2 Description of desired changes 4.3 Priorities among changes 4.4 Changes considered but not included Concepts for the proposed system 5.1 Background, objectives, and scope 5.2 Operational policies and constraints 5.3 Description of the proposed system 5.4 Modes of operation 5.5 User classes and other involved personnel 5.6 Support environment 6. Operational scenarios 7. Summary of impacts 7.1 Operational impa cts 7.2 Organizational impacts 8. 7.3 Impacts during development Analysis of the proposed system 8.1 Summary of improvements 8.2 Disadvantages and limitations 8.3 Alternatives and - trade offs considered 9. Notes Appendices Glossary Sistem Mühendisliği Bilgi Alanları, Sürüm1 17

DERS1.KONU5 PROBLEM VE İHTİYAÇ ANALİZİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 18

SİSTEM MÜHENDİSLİĞİ Sistem Mühendisliği süreci, bir sosyoteknik problem çözme süreci olup, problem (Sorun ya da fırsat tan kaynaklanan Yetenek İhtiyacı) tanımlama ile başlar, daha sonra muhtemel çözümleri müzakere eder, son olarak da bu çözümlerden birini en uygun çözüm yaklaşımı (ihtiyaçları karşılamaya en uygun olan) olarak seçer. Gereksinim Mühendisliği problem ve çözüm ün beyan edilmesi ve söz konusu beyanın proje boyunca idame ettirilmesidir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 19

PROBLEM TANIMLAMA ve ÇÖZÜMLEME PROBLEM UZAYI ÇÖZÜMUZAYI PROBLEMİ TANIMLA HEDEFLENEN PROBLEMİ VARSAYIMLAR VARSAYIMLARI FONKSİYONU ANALİZ ET ÖNER DEĞERLENDİR TANIMLA BİRİNİ SEÇ DIŞ ARAYÜZLERİ ANALİZ ET PROBLEMİ TANIMLA UYGUNLUK ÖLÇÜTÜNÜ TANIMLA TASARIM KONSEPTLERİ ÖNER TASARIM KONSEPTLERİNİ DEĞERLENDİR BİRİNİ SEÇ GÖREV FONKSİYONLARINI ANALİZ ET Mimari Geliştirme BAŞARIM ÖLÇÜTÜ Sistem Mühendisliği Bilgi Alanları, Sürüm1 20

PROBLEMİ TANIMLAMAK Problem Beyanı Problem beyanı sistemin kazandırması beklenen üst seviye bir yeteneğin (problemi çözecek) tanımlanması ile başlar ve ne (yapılmasına)lere ihtiyaç duyulduğunu gösteren ihtiyaç cümleleri içerir. Doğal dille yazılmış cümleler ya da mühendislik modelleri ile dokümante edilebilir. Son kullanıcılar, işletmenler, faturayı ödeyenler, sahipler, sponsorlar, pazarlama, üretim vb paydaşların girdileriyle oluşturulur, bu nedenle paydaşların doğru belirlenmesi oldukça önemlidir. Modern dünyada problem beyanı, vizyon ve misyona uygun olarak bir değişiklik ihtiyacının ortaya konulması ile başlar. Sistem Mühendisliği Bilgi Alanları, Sürüm1 21

PROBLEM BEYANI Problem beyanı içinde en uygun kelimesi kullanılmamalıdır. Problem çözümü olarak ortaya konacak sistem çözümlerinde, maliyet ve etkinlik analizleri yapabileceğimiz, en uygun seçiminde kullanılacak farklı çözümler olacaktır. Ancak alternatiflerin hiç biri tüm parametrelerin en uygununu bulmamıza olanak vermeyecektir Sistem gereksinimleri en uygun (optimal) çözümü istese bile testler sırasında, seçilen çözümün optimal çözüm olduğu kanıtlanamayacaktır. Yanlış tanımlanmış bir probleme mükemmel bir çözüm geliştirmek değersizde bile daha kötüdür, bu nedenle problem beyanı sistem mühendisliğinin en önemli çıktılarından biridir Sistem Mühendisliği Bilgi Alanları, Sürüm1 22

İHTİYAÇLAR Müşteri ihtiyaçlarını anlayın Ne istediğini bilen müşterilere sık rastlanmaz, bu nedenle sistem mühendisleri müşteri harekat ortamına girmeli ve muhtemel sistem çözümünü harekat ortamına ve görev ihtiyaçlarına nasıl entegre edebileceğini bulmalıdır. Çoğu zaman müşteri beklentilerini karşılamak (state of the art) yetmez, başarı için beklentileri aşmak (innovative) gerekir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 23

DERS1.KONU6 GEREKSİNİM YÖNETİMİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 24

SÜREÇ İÇİNDE GEREKSİNİMLER Paydaş İhtiyaçları Paydaşlar için sonuçları tanımlamak Ürünü geçerli kılmak Kabul Testleri Sistem Gereksinimleri Sistemin yapması gerekenleri tanımlamak Sistemi doğrulamak Sistem Testleri Alt Sistem Gereksinimleri Maliyet fayda optimizasyonu Gereksinimlerin kalifikasyonu Entegrasyon Testleri Bileşen Gereksinimleri Gereksinimlerin tahsisi Bileşenlerin kalifikasyonu Bileşen Testleri Sistem Mühendisliği Bilgi Alanları, Sürüm1 25

GEREKSİNİM NEDİR? Tanım (EIA 632 V. 1.0 1998): Bir ürünün belirli bir amaca ulaşabilmesi için; neyi, ne kadar iyi ve ne şartlar altında yapması gerektiğini tanımlar Ne tanımlanır, nasıl tanımlanmaz İşletim konsepti (operasyonel konsept) temeline dayanmalıdır. Sistem Mühendisliği Bilgi Alanları, Sürüm1 26

GEREKSİNİM MÜHENDİSLİĞİ NEDİR Gereksinim mühendisliği, gereksinimleri ortaya çıkarma, tanımlama, dokümante etme, çözümleme (türetme), doğrulama, geçerli kılma ve yönetme sürecidir. Problem uzayını anlayıp, çözüm uzayına bağlantı kurmaktır. Sistem Mühendisliği Bilgi Alanları, Sürüm1 27

KAÇ GEREKSİNİMİZ VAR? Sistem Mühendisliği Bilgi Alanları, Sürüm1 28

İHTİYAÇLAR Normal İhtiyaçlar: Her durumdan bağımsız olarak açık ve net olarak tanımlayabildiğimiz gereksinimlerdir.. Bu gereksinimler sistem kullanıcıları ile konuşulduğunda tanımlanabilirler. Umulan İhtiyaçlar: Öyle gereksinimlerdir ki işin doğası gereği zaten yapılmaları gerekir, çoğu zaman konuşulmasına gerek görülmediğinden gereksinim olarak kayıt altına alınmazlar. Bu gereksinimleri dikkate almayan sistem çözümleri başarılı olamazlar; dikkate alan çözümler (in dikkate aldığı) ise fark edilmezler Sevindiren ihtiyaçlar: Bu ihtiyaçlar gereksinim dokümanlarında bulunmazlar, çözüme dahil edilmediklerinde de sistem paydaşları rahatsız olmaz. Sistem mühendisi kullanıcı ortamında bulundukça, problemi ve fırsatları daha iyi anlayacak, kendi tecrübesi ışığında hedef görevin verim ve etkinliğini arttıracak öneriler getirebilecektir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 29

GEREKSİNİMLERİN TAKİBİ İş Vizyonu yorumlanır İş Hedefleri Uygulamaya geçirilir Kurumsal organizasyon ve süreçler Paydaş İhtiyaçları Dönüştürülür/karşılanır Sistem Gereksinimleri Gruplanır/atanır Alt Sistemlere Gerçekleştirilir Bileşen Gereksinim mühendisliği bağlamında izlenebilirlik,üst seviye vizyonun amaçlar, hedefler, beklentiler, ihtiyaçlar alt seviye gereksinimlere nasıl dönüştürüldüğünün takip edilmesidir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 30

DERS2.KONU1 İŞLEVSEL ANALİZ Sistem Mühendisliği Bilgi Alanları, Sürüm1 31

FORM, FIT, FUNCTION Form: the shape, size, dimensions, mass and/or other visual parameters which uniquely characterize an item. This defines the "look" of the part or item. Sometimes weight, balance and center of mass are considerations in 'form'. Fit: the ability of an item to physically interface or interconnect with or become an integral part of another item or assembly. This relates to the associativity of the part in relation to the assembly, or to other parts, and includes tolerances. Function: the action[s] that an item is designed to perform. This is the reason for the item's existence, which also includes secondary applications. http://en.wikipedia.org/wiki/form,_fit_and_function Sistem Mühendisliği Bilgi Alanları, Sürüm1 32

SİSTEM = Form + Fonksiyon İyi bir gözlemci, taş parçasının, kağıt tutucu fonksiyonunu fark edebilir PENCERE Hava Akımı Masa Yer Çekimi Sistem Mühendisliği Bilgi Alanları, Sürüm1 33

REFERANS ÇERÇEVEYE BAĞIMLI OLMA Ya da başka bir gözlemci farklı sınırlar, farklı fonksiyonlar, görebilir aynı sistemi görmeyebilir. KIRIK PENCERE Sistem Mühendisliği Bilgi Alanları, Sürüm1 34

FONKSİYONEL ANALİZ Bir sistemin nasıl kullanılacağını anlamak için uygulanan yapısal bir çözümleme Sistem ürün ve servislerinin yerine getireceği işlevsel mimariyi tanımlayan bir süreç Tasarımı girdi olacak seviyeye kadar detaylandırılmalıdır. Gereksinimler ile işlevler arasında ilişki kurar İzlenebilir ve mantıklı bir sıralama oluşturulur Her türlü kullanım modunu içerir (tüm modlar için bir tane temel analiz vardır) Ürün ya da servislerin çalışmak için ihtiyaç duyacağı işlevler de dahil edilmelidir. İşlevsel analizler esnasında ortaya çıkan performans gereksinimleri, sistem tasarım kriterleri olarak kullanılır. Sistem Mühendisliği Bilgi Alanları, Sürüm1 35

DERS2.KONU2 USE CASE ANALİZİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 36

USE CASE DIAGRAMS USE CASE, ACTOR A Use case yields an observable result to an Actor. Use Cases describe the functionality of a system in terms of how its users use that system to achieve their goals. An actor is used to represent the role of a human, an organization, or any external system that participates in the use of subject system. Sistem Mühendisliği Bilgi Alanları, Sürüm1 37

USE CASE DIAGRAMS RELATIONSHIP Inclusion: The inclusion relationship allows one use case referred to as base use case, to include the functionality of another use case, called the included use case as a part of its functionality when performed. Extension: A use case can extend a base use case using the extend relationship. The extending use case is a fragment of functionality that is not considered part of the normal base use case functionality. Sistem Mühendisliği Bilgi Alanları, Sürüm1 38

ACTOR CLASIFICATION Actors can be classified using standard generalization relationship. A specialized actor participates in all the use cases that the more general actor participates in. Sistem Mühendisliği Bilgi Alanları, Sürüm1 39

USE CASE CLASIFICATION uc [Package] UseCaseDiagramsPkg [Use Cases f or SpaPoolTempControl System] Set up system Adjust set point and set or unset low-temp alarm Tune control algorithm Scenarios for the general use case are also scenarios of the specialized use case Operator Calibrate sensor Operate system Activate or deactivate system «inc lude» Control temperature and alarm Enter or exit standby mode «extend» Handle alarm Sistem Mühendisliği Bilgi Alanları, Sürüm1 40

USE CASE DIAGRAMS Actors associated with a general use case do not participate in any scenarios solely described by a specialized use case. 2008 Elsevier, Inc.: A Practical Guide to SysML Sistem Mühendisliği Bilgi Alanları, Sürüm1 41

USE CASE DIAGRAMS Driver Information System Use Cases Sistem Mühendisliği Bilgi Alanları, Sürüm1 42

USE CASE DIAGRAMS GPS Start-up (extension or classification?) The hot start is when the GPS device remembers its last calculated position and the satellites in view, the almanac used (information about all the satellites in the constellation), the UTC Time and makes an attempt to lock onto the same satellites and calculate a new position based upon the previous information. This is the quickest GPS lock but it only works if you are generally in the same location as you were when the GPS was last turned off. The warm start is when the GPS device remembers its last calculated position, almanac used, and UTC Time, but not which satellites were in view. It then performs a reset and attempts to obtain the satellite signals and calculates a new position. The receiver has a general idea of which satellites to look for because it knows its last position and the almanac data helps identify which satellites are visible in the sky. This takes longer than a hot start but not as long as a cold start. And finally the cold start is when the GPS device dumps all the information, attempts to locate satellites and then calculates a GPS lock. This takes the longest because there is no known information Sistem Mühendisliği Bilgi Alanları, Sürüm1 43

DERS2.KONU3 SİSTEM TASARIMI Sistem Mühendisliği Bilgi Alanları, Sürüm1 44

FORM + FONKSİYON Aralarında etkileşimli bir birlik görülen elemanlar = Form Fonksiyonel olarak bakıldığında = Fonksiyon Bilinen tüm sistemlerin tüm durumlarına uygulanabilir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 45

TASARIM Sistem Mühendisliği Bilgi Alanları, Sürüm1 46

DOĞRU TASARIM KONSEPTI Fikirler Kaynaklar YÜZEYSEL/ÜST SEVİYE PROGRAM /PROJE SİSTEMİ* TESLİMAT /ÜRÜN SİSTEMİ* KESİN/DETAYLI Doğru tasarım konsepti, elenen alternatifler arasında en uygun olanıdır. Sistem Mühendisliği Bilgi Alanları, Sürüm1 47

FIT, FORM SEÇİMİ İÇİN TEMEL KOŞULDUR Darwin e göre evrim için de geçerlidir Uyum (Fit) gösteren hayatta kalır Mühendislik Fit = Maliyet Etkin Sistem Çözümü Etkinlik, estetik de dahil olmak üzere, seçim anında dikkate aldığımız her türlü değişkenin birleşimidir Etkinlik Operasyonel Etkinlik (Görev ne kadar iyi ifa edildi) Operasyonel Uygunluk ( estetik ve diğer görev ile direkt bağlantısı olmayan değişkenler) Maliyetler ve Riskler Sistem Mühendisliği Bilgi Alanları, Sürüm1 48

SİSTEM ETKİNLİĞİ Sistem Etkinliği, bir sistemden, belirlenen görev hedefleri için, ulaşmasını beklediğimiz; olasılık cinsinden ve görevi tamamlama maliyeti olarak tanımlanabilecek sayılabilir bir ölçümdür FIT (B52) = Hedefe gönderilebilen faydalı yükün ton başına maliyeti FIT (747) = Koltuk+Mil başına düşen toplam uçuş maliyet Sistem Mühendisliği Bilgi Alanları, Sürüm1 49

ÖRNEK ÜST SEVİYE MOE Sistem Etkinliğine krş. Ömür Devri Maliyeti Operasyonel Etkinlik Operasyonel Uygunluk Ömür Devri Maliyeti Risk İstenilen Sıcaklığı Sabit Tutabilme Olasılığı İstenilen Sıcak Suyu Sağlayabilme Olasılığı Güvenilirlik AR&GE Maliyeti Alt Sistem Perf. Riski Isı Kayıpları Su İhtiyacı Sürdürülebilirlik Ekipman Maliyeti Sistem Performans Riski Verilen Isı Verilen Isı Elverişlilik Bina Değişiklik Maliyeti Maliyet Riski Kontrol Duyarlılığı Kontrol Duyarlılığı Genişleyebilirlik Bakım Maliyetleri Takvim Riski Odalar arası farklılık Dağıtım Kayıpları Güvenlik İşletme Maliyetleri Yakıt Maliyeti Riski Elverişlilik Elverişlilik Gürültü Yatırımın Geri Dönüş Süresi Kullanım Ömrü Sistem Mühendisliği Bilgi Alanları, Sürüm1 50

FONKSİYONEL TEMELÇİZGİ AWACS MALİYET ETKİNLİK AĞACI Sistem Maliyet Etkinliği (% yıpranma krş. USD) Sistem Etkinliği (% yıpranma krş. Kuvvet Büyüklüğü) Operasyon ve Bakım Maliyet Modeli Sistem Yetenekleri Elverişlilik Radar Mesafesi IFF Mesafesi Değerlendirme Verimi Atama Verimi Sistem Mühendisliği Bilgi Alanları, Sürüm1 51

ÖRNEK ÜST SEVİYE MOE Sistem Etkinliğine krş. Ömür Devri Maliyeti (.153 / 70.000 $) Operasyonel Etkinlik (.153) Operasyonel Uygunluk Ömür Devri Maliyeti (70.000 $/ 20 yıl) Risk (n/a) İstenilen Sıcaklığı Sabit Tutabilme Olasılığı (.226) İstenilen Sıcak Suyu Sağlayabilme Olasılığı (.676) Güvenilirlik (3285 saat) AR&GE Maliyeti (0) Alt Sistem Perf. Riski Isı Kayıpları (.498) Su İhtiyacı (100 l/sa) Sürdürülebilirlik (12 sa) Ekipman Maliyeti (0) Sistem Performans Riski Verilen Isı (.665) Verilen Isı (80K btu/sa) Elverişlilik (.996) Bina Değişiklik Maliyeti (0) Maliyet Riski Kontrol Duyarlılığı (.943) Kontrol Duyarlılığı (.97) Genişleyebilirlik (n/a) Bakım Maliyetleri (150 $/yıl) Takvim Riski Odalar arası farklılık (.727) Dağıtım Kayıpları (36K btu) Güvenlik (n/a) İşletme Maliyetleri (3350 $ / yıl) Yakıt Maliyeti Riski Elverişlilik (.996) Elverişlilik (.999) Gürültü (Yüksek) Yatırımın Geri Dönüş Süresi (o) Kullanım Ömrü (Uzun) Sistem Mühendisliği Bilgi Alanları, Sürüm1 52

TASARIM NEDİR? Tasarım, bir ürüne ait gereksinimlerin, o ürünün tarifine dönüştürülmesi sırasında ortaya çıkan teknik bilgilerin tamamıdır.* İki ana kategoriden söz edilebilir: Üst seviye Detaylı * EIA 649 National Consensus Standard for Configuration Management Sistem Mühendisliği Bilgi Alanları, Sürüm1 53

ÜST SEVİYE TASARIM Gereksinimler ile detaylı tasarım arasındaki aşama. Ne den Nasıl a Mimari Alt Sistem Tanımları Alt Sistem Doğrulama Planları Arayüz Tanımları Sistem Mühendisliği Bilgi Alanları, Sürüm1 54

DETAYLI TASARIM Ürünün bileşen seviyesinde tam tarifi Konfigürasyon Birimi Tanımları Bileşen Özellikleri Yazılım Özellikleri Donanım Özellikleri Doğrulama Prosedürleri Sistem Mühendisliği Bilgi Alanları, Sürüm1 55

SİSTEM TASARIMI NEDİR? Sistem bileşenlerinin ve etkileşimlerinin, sistem gereksinimlerini karşılayacak şekilde seçilmesi ve bir araya getirilmesi ve Tasarımı anlatan spesifikasyon dokümanlarının hazırlanması Sistem Mühendisliği Bilgi Alanları, Sürüm1 56

Ne (Gereksinimler) TASARIM Nasıl (Spesifikasyonlar) (Şartnameler) Alternatiflerin Analizi GEREKSİNİMLER VE SPEKLER ARASINDAKİ KÖPRÜ Sistem Mühendisliği Bilgi Alanları, Sürüm1 57

TASARIM SPEK (ÖZELLİK)LERİ Tasarım özellikleri, sistem tasarımı ve gereksinimlerine dayanılarak geliştirilir Spesifikasyonlar Nasıl ı tanımlar Spesifikasyonlar da gereksinimler ile aynı yapıda yazılmalıdırlar. Sistem Mühendisliği Bilgi Alanları, Sürüm1 58

DERS3.KONU1 SİSTEM MÜHENDİSLİĞİ YÖNETİMİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 59

TİPİK BİR ORGANİZASYON Program Manager Program Controls Systems Engineering Engineering Sistem Mühendisliği Bilgi Alanları, Sürüm1 60

SİSTEM MÜHENDİSLİĞİYÖNETİMİ Systems Engineering Management Work Breakdown Structure Development Selection of Engineering Design Method Systems Engineering Program Planning Cost & Schedule Control Design Review and Evaluation Technical Control Managing the Organization Supplier Evaluation, Selection, & Control Systems Engineering Conceptual Design Preliminary System Design Detail System Design & Development Production and/or Construction Operational Use & System Support Sistem Mühendisliği Bilgi Alanları, Sürüm1 61

SİSTEM MÜHENDİSLİĞİYÖNETİMİ Systems Engineering Program Planning Cost & Schedule Control Technical Control Supplier Evaluation, Selection, & Control Managing the Organization Conceptual Design Preliminary System Design Detail System Design & Development Production and/or Construction Operational Use & System Support Sistem Mühendisliği Bilgi Alanları, Sürüm1 62

SİSTEM MÜHENDİSLİĞİYÖNETİMİ Systems Engineering Program Planning What is my management approach? Cost & Schedule Control Technical Control Supplier Evaluation, Selection, & Control Managing the Organization Conceptual Design Preliminary System Design Detail System Design & Development Production and/or Construction Operational Use & System Support What steps of the SE process will I execute? What resources do I require? Sistem Mühendisliği Bilgi Alanları, Sürüm1 63

SEMP Kapsamı Proje Kapsamı Proje Mühendislik Yönetimi ve Program Yönetimi ile İlişkisi Sistem Mühendisliği Yönetimi Sistem Mühendisliği Analiz ve Tasarım Süreçleri Alan Uzmanlığı Entegrasyonu Özel Mühendislik Alanları Sistem Mühendisliği Riskleri Sistem Mühendisliği Bilgi Alanları, Sürüm1 64

WBS Follows SOW generation Product-oriented family tree that leads to identification of activities, functions, tasks, subtasks, work packages, etc., that must be performed for the completion of a given program Is not an organization chart for personnel Project activities Functions Tasks Subtasks Sistem Mühendisliği Bilgi Alanları, Sürüm1 65

WBS Is a representation of organization of work packages The purpose of the WBS is to be a framework for: Considering the products, services, and information need to fulfill objectives and scope of the project (MM) Project planning and control Program planning, budgeting, contracting, and reporting Project activities Functions Tasks Subtasks Sistem Mühendisliği Bilgi Alanları, Sürüm1 66

IMP/IMS The Even Planning Process: A hierarchical planning framework Steps Level 1: Make a list of major activities in general order of occurrence (about 2 to 20 activities) Level 2: Breakdown each Level 1 activity into 2 to 20 tasks Level 3: Breakdown each Level 2 task into 2 to 20 subtasks Continue until tasks at each level are manageable Fundamental: Be sure all tasks at a specific level are at the same level of detail (or level of generality) Project manager usually performs Level 1 and delegates lower levels to those who will do work Objectives are from project master plan Sistem Mühendisliği Bilgi Alanları, Sürüm1 67

DERS3.KONU2 RİSK YÖNETİMİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 68

GENEL PROJE RİSKLERİ Risk Proje Tehditleri Teknoloji Personel Yönetim Örnekler Yetersiz bütçe Uygun olmayan tesisler Performans problemleri Arayüz problemleri Yetersiz tecrübe/beceri Değişime direnç/korku İhtiyaçlar değişir Yetersiz kaynaklar Sistem Mühendisliği Bilgi Alanları, Sürüm1 69 69

RİSK KAYNAKLARI Teknoloji İnsan Fiziki ortam Politik ortam Sözleşmesel sorunlar Sistem Mühendisliği Bilgi Alanları, Sürüm1 70

TEMEL PROBLEM Risk artarsa= Maliyetler artar! Sistem Mühendisliği Bilgi Alanları, Sürüm1 71

RİSK YÖNETİMİNİN ÖGELERİ Risk Tanımlama Risk Değerlendirme Risk Çözümleme Risk Yönetimi Risk Önceliklendirme Risk Planlama Risk Kontrolü Risk İzleme Risk Azaltma Sistem Mühendisliği Bilgi Alanları, Sürüm1 72

RİSK DEĞERLENDİRME Gerçekleşme İhtimali(Olasılık) Muhtemel Etkisi Hafifletme Maliyeti Sistem Mühendisliği Bilgi Alanları, Sürüm1 73

RİSK YÖNETİMİ Risklerinizi bilin Etkilerini anlayın Hafifletmek için planlar yapın Takip edin Hafifletme planını uygulayın Paydaşların desteğini alın Gerçekten iyi sonuçlar alırsınız! Sistem Mühendisliği Bilgi Alanları, Sürüm1 74

DERS3.KONU3 KONFİGÜRASYON YÖNETİMİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 75

KONFİGÜRASYON YÖNETİMİ A management process for establishing and maintaining consistency of a product s performance, functional and physical attributes with its Requirements, design, and operational information throughout its life A process intended to ensure that the system performs as intended, and is documented to a level of detail sufficient to meet needs for operation, maintenance, repair and replacement ANSI/EIA 649 1998 National Consensus for Configuration Management Sistem Mühendisliği Bilgi Alanları, Sürüm1 76

KONFİGÜRASYON the functional and physical characteristics of a product, both hardware and software, that are described or defined by associated documentation and actually incorporated into the product s delivered end item. Physical = size, weight, shape, material, structure Functional = performance, operation, use, abilities Form, Fit and Function Sistem Mühendisliği Bilgi Alanları, Sürüm1 77

YANİ. Konfigürasyon Yönetiminin öncelikli hedefleri: 1) Sistem ve proje bütünlüğünü sağlamak 2) Ömür devri boyunca bu bütünlüğü sürdürmek Sistem Mühendisliği Bilgi Alanları, Sürüm1 78

DERS3.KONU4 SİSTEM MÜHENDİSLİĞİ ÖLÇÜMLERİ (METRİKLER) Sistem Mühendisliği Bilgi Alanları, Sürüm1 79

ETİMOLOJİ Metric : Greek metrike, from feminine of metrikos in meter, by measure, from metron measure (http://www.m-w.com/cgibin/dictionary) Ölçü : ölçmek/ölçemek tahmin etmek, değer takdir etmek (xiv) = *ülmek ölçmek (http://www.nisanyan.com/sozluk) Kader : qader [msd.] 1. ölçme, değer biçme, 2. ilahi kudret, kader < #qdr gücü yetme (http://www.nisanyan.com/sozluk) METRİK YÖNETİMİ : PROJENİN KADERİNİN YÖNETİMİDİR Sistem Mühendisliği Bilgi Alanları, Sürüm1 80

SÜREÇ ÖLÇME A measurement taken over a period of time that communicates vital information about a process or activity. A metric should drive appropriate action. Timely and accurate information is needed to ensure progress and resolve problems/issues. Measurement is an alternative to schedule-based management. METRİK YÖNETİMİ : PROJENİN KADERİNİN YÖNETİMİDİR Sistem Mühendisliği Bilgi Alanları, Sürüm1 81

MOE, MOP, TPM Measure of Effectiveness (MOE): The metrics by which an acquirer will measure satisfaction with products produced by a technical effort. Measure of Performance (MOP): An engineering performance measure that provides design requirements that are necessary to satisfy an MOE. There are typically several MOPs for each MOE. Technical Performance Measure (TPM): Key indicators of system performance, TPMs are critical MOPs which, if not met, put the project at cost, schedule, or performance risk. Sistem Mühendisliği Bilgi Alanları, Sürüm1 82

DETAYLI V DİYAGRAMI GÖREV İHTİYACI (MNS) GÖREVE HAZIR SİSTEM GELİŞTİRME TO BE AS IS DOĞRULAMA VE GEÇERLİLEME HAREKAT İHTİYAÇLARI ANALİZİ (HAREKAT İHTİYAÇLARI DOKÜMANI-ORD) ETKİNLİK ÖLÇÜMLERİ (MOE) PERFORMANS ÖLÇÜMLERİ VE DEĞERLENDİRMELER KABUL HAREKAT KONSEPTİ DOKÜMANI (OCD) İŞLEVSEL ANALİZ (İŞLEVSEL GEREKSİNİMLER DOKÜMANI-FRD) HAREKAT TESTLERİ SİSTEMLER SİSTEMİ (SoS) ŞARTNAMESİ (Spec) SİSTEM GEREKSİNİMLERİ DOKÜMANI (SSS) SİSTEM TASARIMI (SSDD) MOP SİSTEM VASIFLANDIRMA TESTLERİ YAZILIM, DONANIM, ARAYÜZ GEREKSİNİMLERİ (SRS, HRS, IRS) VE TASARIMLARI (SDD, HDD, IDD) TPM BİLEŞEN VASIFLANDIRMA/ KABUL TESTLERİ BİLEŞEN TANIMLAMA DOKÜMANI (HWCI, CSCI) YAZILIM, DONANIM GERÇEKLEŞTİRME Sistem Mühendisliği Bilgi Alanları, Sürüm1 83

TPM MOE Harekat Analizi Arama Kurtarma Görevi Başarım Olasılığı MOP Sistem Analizi İzleme Kapasitesi İntikal/Manevra Kaabiliyeti Muhabere Kaabiliyeti TPM Tasarım Seyir Sürati Yakıt Deposu Büyüklüğü Ağırlık Sistem Mühendisliği Bilgi Alanları, Sürüm1 84

GEREKSİNİM MÜHENDİSLİĞİ ÖLÇÜMLERİ OYNAKLIK Kick-Off SRR PDR CDR TRR Değişmeyen 100 48 82 102 103 Değişen 0 50 20 10 10 Eklenen 0 5 10 1 0 Silinen 0 2 1 0 0 Toplam 100 103 112 113 113 Oynama 0,00% 53,40% 26,79% 9,73% 8,85% Sistem Mühendisliği Bilgi Alanları, Sürüm1 85 85

GEREKSİNİM MÜHENDİSLİĞİ ÖLÇÜMLERİ OYNAKLIK 60,00% Oynama 50,00% 40,00% 30,00% Oynama 20,00% 10,00% 0,00% Kick-Off SRR PDR CDR TRR Sistem Mühendisliği Bilgi Alanları, Sürüm1 86 86

İŞLEVSEL ANALİZ ÖLÇÜMLERİ GEREKSİNİM KARŞILAMA Kick-Off SRR PDR CDR TRR Mevcut 0 0 47 171 172 Değişen 0 0 20 10 10 Eklenen 0 67 113 1 0 Silinen 0 1 0 0 Toplam 0 67 181 182 182 Toplam Gereksinim 100 107 118 119 119 Karşılanan Gereksinimler 0 20 100 119 119 Gereksinim Kapsama 0,00% 18,69% 84,75% 100,00% 100,00% 140 120 100 80 60 40 Toplam Gereksinim Karşılanan Gereksinimler 20 0 Kick-Off SRR PDR CDR TRR Sistem Mühendisliği Bilgi Alanları, Sürüm1 87 87

DERS4.KONU1 SİSTEM TEST VE DEĞERLENDİRME Sistem Mühendisliği Bilgi Alanları, Sürüm1 88

SİSTEM MÜHENDİSLİĞİ SÜRECİ Customer Need Validation Operate System Req s Verification System Subsystem Req s Verification Subsystem Design Build V Model Sistem Mühendisliği Bilgi Alanları, Sürüm1 89

VV ve WBS Program Level 1 System SE/PM Data Logistics Sys Test & Integ Level 2 Comp Comp Comp Test & Integ Level 3 Comp Comp Comp Test & Integ Level 4 Sistem Mühendisliği Bilgi Alanları, Sürüm1 90

TANIMLAR Geçerli Kılma Sistem kullanıcı ihtiyaçlarını karşılıyor mu? Örneğin, doğru gereksinimler yazılmış mı? Doğrulama Sistem gereksinimleri karşılıyor mu? Kalite Güvence Sistem geliştirme sırasında denenmiş doğru süreçler kullanıldı mı? Sistem Mühendisliği Bilgi Alanları, Sürüm1 91

ANLAŞILMASI İÇİN Geçerli Kılma Doğru sistemi mi geliştirdik? Doğrulama Sistemi doğru geliştirdik mi? Kalite Güvence Sistemi doğru yollarla mı geliştirdik? Sistem Mühendisliği Bilgi Alanları, Sürüm1 92

DERS5.KONU1 YENİ GELİŞMELER VE GİDİŞAT Sistem Mühendisliği Bilgi Alanları, Sürüm1 93

KURUMSAL BAŞARIM ÖLÇÜTLERİ ETKİLEŞİM ORTAMI Değişime ayak uydurabilme İçerde ve dışarıda işbirliği / Birlikte çalışabilme Teknolojiyi kullanabilme Göreve ulaşmada etkinlik ve verimlilik Sistem Mühendisliği Bilgi Alanları, Sürüm1 94

Dönüşüm Planlama Kavram Geliştirme Deneme DÖNÜŞÜM NATO MC 324/1 [1] yayınında dönüşüm; NATO ve müttefik kuvvetlerin etkinliğini ve birlikte çalışabilirliğini iyileştirmek için yürütülen sürekli ve öngörülü geliştirmeler ve bu geliştirmelerin yenilikçi kavram, doktrin ve yetenekler ile bütünleştirilmesi süreci olarak tanımlanmaktadır. Kavram Geliştirme ve Deneme (CD& E) ve Moda Tasarımı Sistem Mühendisliği Bilgi Alanları, Sürüm1 95

AĞ DESTEKLİ YETENEK A usually informally interconnected group or association of persons (as friends or professional colleagues) An interconnected or interrelated chain, group or system (e.g., a network of hotels); a system of computers, terminals and databases connected by communications lines Ağ Destekli Yetenek: kullanılabilir/uygulanabilir bilgilerin, bir araya getirilebilmesi; ortak ve anlaşılabilir bir yapıda müttefiklerle paylaşılabilmesi; değerlendirilerek ve iyileştirilerek yeni bilgilere dönüştürülebilmesi; ihtiyaç duyan taraflara düzeltilmiş ve odaklanmış bir halde aktarılabilmesi; ve bütün bunların ihtiyaç duyulan kararların en ekonomik ve verimli şekilde verilebilmesini sağlayacak bir zaman diliminde yapılabilmesi Sistem Mühendisliği Bilgi Alanları, Sürüm1 96

ÇEVİK HAREKAT Neden Çok farklı görevler için hazır olmak Birbirinden çok farklı ortaklıklar içinde olabilmek Sürekli değişen ve belirsizliği çözülemeyen ortamlarda görev yapabilmek Nasıl Çevik Karar Mekanizmaları (Komuta Kontrol) Çevik Personel Çevik Organizasyonlar Çevik Sistemler Çevik... Sistem Mühendisliği Bilgi Alanları, Sürüm1 97

ADY, SiS ve SYM Ağ Destekli Yetenek «uses» Sistemler Sistemi «uses» Servis Yönelimli Mimari Sistem Mühendisliği Bilgi Alanları, Sürüm1 98

SİSTEMLER SİSTEMİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 99

SİSTEMLER SİSTEMİ (SiS) Sistemler Sistemi (SoS-System of Systems), farklı bağımsız ve kendi başına kullanılabilir sistemlerin, daha büyük bir sistem olarak bileşenlerinden farklı yetenekler sunmak üzere bir küme ya da farklı bir tertiplenme ile bir araya gelmesi olarak tanımlanmaktadır. Sistemler Sistemi Entegratörü Sistemler Sistemi Kullanıcısı Sistemler Sistemi Üst Sistem Oluşturma Sistem-A Sistem-B Sistem-C Sistem-A Kullanıcısı Sistem-A Sahibi Sistem-B Kullanıcısı Sistem-B Sahibi Sistem-C Kullanıcısı Sistem-C Sahibi Sistem Mühendisliği Bilgi Alanları, Sürüm1 100

SERVİS YÖNELİMLİ MİMARİ (SYM) Sistemler Sistemi çeşitli servislerin (yetenekler/işlevler) bir araya getirilerek belirli bir operasyonel bağlamda kullanılması olarak tanımlanabilir. Servis ise hem kullanıcılar hem de servis sağlayıcılar tarafından bakıldığında bir sonuca ulaştıran uyumlu faaliyetler bütünü olarak tanımlanabilir. Kullanıcı Servis Servis Sağlayıcı Servis Yönelimli Mimari (SOA-Service Oriented Architecture), etkileşim içindeki servislerin, birbirleri ile gevşek olarak bağlandığı mimari sitilidir. Gevşek bağlantı, servislerin gerçek bir bağlantı olmasa da birlikte çalışabilmeleri ve servislerden birinin işlevlerini yerine getirebilmesi için diğerine en az seviyede bağımlı olması olarak yorumlanabilir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 101

SEMBOLİK MODELLEME Gereksinim Tanımlama & Yönetimi Yazılım Modelleme Sistem Modelleme SysML Donanım Modelleme UML VHDL, CAD, SysML, Sistem Mühendisliği (özellikle Sistem Analiz ve Tasarımı) süreçlerinde kullanılmak üzere UML den türetilmiştir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 102

MİMARİ TASARIM SÜRECİ Input Needs/Req Document Based Systems Engineering Process (the old way) Requirements Analysis Analyze Missions and Environments Identify Functional Requirements Define Performance & Design Constraint Requirements Requirements Loop Output Documents (loosely connected) Requirements Document Concept of Operations Systems Analysis & Control Alternatives Analysis Tradeoff Studies Effectiveness Analysis Interface Management Data Management CM Functional Analysis/Allocation Decompose to Lower-Level Functions Allocate Perf. Requirements to all Functional Levels Define/Refine Functional Interfaces (Internal/External) Define/Refine/Integrate Functional Architecture Functional Decomposition FFBD/EFFBD, IDEF, DFD Diagrams Product Breakdown Structure Verification Loop Design Loop Design/Synthesis Transform Architectures (Functional to Physical) Define Alternative System Concepts & System Elements Select Preferred Product and Process Solutions Define/Refine Physical Interfaces (Internal/External) Verify Systems Decomp. Diagrams N2 Chart Test Plans Output Decision Database System/Config Item Architecture Specifications and Baselines Analysis framework is solid Artifacts routinely lack specificity and are sometimes ambiguous, which leads to various interpretations Visualizing designs with this approach is labor intensive, which makes it costly to update & synchronize artifacts Output Sistem Mühendisliği Bilgi Alanları, Sürüm1 103

MBSE Uses the same architecting process Creates SysML models rather than developing documents Automation tools can be used to generate routine artifacts directly SysML provides 9 different types of diagrams to represent the architecture, which can be used to develop solutions 4 behavioral 4 Structural 1 Cross-Cutting Input Needs/Req Internal Block Diagram [IBD] Package Diagram [PKG] Systems Architecting and Engineering Process (model based) Requirements Analysis Analyze Missions and Environments Identify Functional Requirements Define Performance & Design Constraint Requirements Requirements Loop Functional Analysis/Allocation Decompose to Lower-Level Functions Allocate Perf. Requirements to all Functional Levels Define/Refine Functional Interfaces (Internal/External) Define/Refine/Integrate Functional Architecture Verification Loop Structural Diagrams Design Loop Design/Synthesis Transform Architectures (Functional to Physical) Define Alternative System Concepts & System Elements Select Preferred Product and Process Solutions Define/Refine Physical Interfaces (Internal/External) Verify Block Definition Diagram [BDD] Parametric Diagram [PD] SysML Diagrams Cross-Cutting Diagrams Requirements Diagram [REQ] Use Case Diagram [UC] State Machine Diagram [SMD] Requirements Diagrams [Req] Use Cases [UC] Package Diagram [PKG] Sequence Diagrams [SD] Activity Diagrams [AD] State Machine Diagrams [SMD] Block Definition Diagrams [BDD] Internal Block Diagrams [IBD] Parametric Diagrams [PD] Behavioral Diagrams Output Activity Diagram [AD] Sequence Diagram [SD] Sistem Mühendisliği Bilgi Alanları, Sürüm1 104

Output Benefits of MBSE Systems Analysis & Control (automated) Integrated Systems Model Models use common data sets Provides a consistent view of the architecture Can lead directly to system specifications & test plans Reduces systems integration and testing risks Promotes traceability Makes it possible to identify gaps and overlaps Facilitates model reuse and integration Uses a standards based modeling language Defines architectures that can be simulated with standard tools Models can be used with many standards compliant automation tools Requirements Diagrams [Req] Use Cases [UC] Package Diagram [PKG] Sequence Diagrams [SD] Activity Diagrams [AD] State Machine Diagrams [SMD] Block Definition Diagrams [BDD] Internal Block Diagrams [IBD] Parametric Diagrams [PD] Allocate Value Build Satisfy Verify Integrated Architectural Model Requirements Structure Interface to M&S Analysis Tools (Opnet, XLS) Test Planning Automation tools are used to generate artifacts Less labor intensive to generate & update Behavior Parametric Sistem Mühendisliği Bilgi Alanları, Sürüm1 105

SysML nedir OMG Systems Modeling Language (OMG SysML ) Sistem Mühendisliği uygulamaları için geliştirilmiş genel amaçlı bir modelleme dilidir. Donanım, yazılım, bilgi, süreç, personel ve süreçler içeren karmaşık sistemlerin, tanımlanması, analizi, tasarımı, doğrulanması ve geçerli kılınması faaliyetlerin de kullanılabilir. SysML karmaşık sistemlerin sistem mühendisliği seviyesinde analiz ve tasarımının yapılmasını sağlayan bir modelleme aracıdır. SysML nin sağladıkları Semantik : Anlam Notasyon : Anlamın gösterilişi OMG: Object Management Group Sistem Mühendisliği Bilgi Alanları, Sürüm1 106

SysML ile NE MODELLENEBİLİR Sistem mühendisliği problemlerinin modellenmesinde basit ama kapsamlı yapılar sunar SysML dilindeki bütün kelimeleri kullanmak şart değildir. Sadece Blok kelimesi ve yapıları ile (Blok Tanımlama ve Dahili Blok Diyagramları) sistem mühendisliği faaliyetlerinin ihtiyaç duyduğu birçok model üretilebilir. Özellikle, gereksinim, yapı, davranış modellenmesinde etkin kullanılabilir. Yapısal analiz ya da Nesne Yönelimli analiz usullerinde kullanılabilir. SysML sistem mühendisliği çerçevesinde soyut tasarım araçlarını sunmakla beraber herhangi bir metodoloji dikte etmez. Çeşitli geliştirme süreçleri ve SysML araçları kullanılarak sistem modelleme yapılabilir. Sistem Mühendisliği Bilgi Alanları, Sürüm1 107

SysML ile NE MODELLENEBİLİR SysML, herhangi bir sistem geliştirme sürecinde kullanılan yada oluşturulan bilgileri göstermek için kullanılan bir sembol dilidir. Analiz Donanım Spesifikasyon Tasarım Doğrulama Geçerli Kılma Yazılım Veri Personel Yönergeler Tesisler Sistem Mühendisliği Bilgi Alanları, Sürüm1 108

SysML DİYAGRAM AİLESİ Sistem Mühendisliği Bilgi Alanları, Sürüm1 109