SİSTEM MÜHENDİSLİĞİ
BİLGİ ALANLARI
ÖMER ERTEKİN PSCONSULTECH
H D M
PROJE KAPSAMI
DERS1.KONU1
İ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
GEREKSİNİMLERİN TEMELLERİ
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İSTEM VİZYONU ve PROJE KAPSAMI
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
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.
PROJE KAPSAM YÖNETİMİ
Sistem Mühendisi de kendi kabulünü her iki tarafa kapsam olarak dayatır
SİSTEM BAĞLAMI
DERS1.KONU2
• “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
SİSTEM BAĞLAMI
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.
Diğer Sistem
İlgi Sistem Diğer
Sistem
Diğer Sistem
Ortam
Arayüzler
Diğer Sistem
SİSTEM SINIRLARI KONSEPTİ
•Sadece
•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
PAYDAŞ ANALİZİ
DERS1.KONU3
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?
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
PAYDAŞLAR
İŞLETİM KONSEPTİ
DERS1.KONU4
Sistem işletiminde bir gün
İŞLETİM KONSEPTİ
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.
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.
TEMELLER NE ?
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. • •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 •
•4. • •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 •
•5. • •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 •
•7.3 Impacts during development •
•8. • •Analysis of the proposed system •
•8.1 Summary of improvements •
PROBLEM VE İHTİYAÇ ANALİZİ
DERS1.KONU5
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.
PROBLEM TANIMLAMA ve ÇÖZÜMLEME
PROBLEMİ TANIMLA
PROBLEMİ ANALİZ ET
HEDEFLENEN FONKSİYONU TANIMLA
PROBLEM UZAYI
PROBLEMİ TANIMLA
DIŞ ARAYÜZLERİ
ANALİZ ET
GÖREV FONKSİYONLARINI
ANALİZ ET
UYGUNLUK ÖLÇÜTÜNÜ TANIMLA
Mimari Geliştirme
ÇÖZÜMUZAYI
VARSAYIMLAR ÖNER
VARSAYIMLARI
DEĞERLENDİR BİRİNİ SEÇ
TASARIM KONSEPTLERİ
ÖNER
TASARIM KONSEPTLERİNİ
DEĞERLENDİR
BİRİNİ SEÇ
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
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
İ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.
GEREKSİNİM YÖNETİMİ
DERS1.KONU6
SÜREÇ İÇİNDE GEREKSİNİMLER
Paydaş İhtiyaçları
Sistem
Gereksinimleri
Alt Sistem Gereksinimleri
Bileşen
Gereksinimleri
Bileşen Testleri
Entegrasyon Testleri
Sistem Testleri
Kabul Testleri
Gereksinimlerin tahsisi Bileşenlerin kalifikasyonu Maliyet fayda optimizasyonu Gereksinimlerin kalifikasyonu
Sistemin yapması gerekenleri tanımlamak Sistemi doğrulamak
Paydaşlar için sonuçları tanımlamak
Ürünü geçerli kılmak
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.
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.
KAÇ GEREKSİNİMİZ VAR ?
İ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.
İş Vizyonu
yorumlanır
İş Hedefleri
Uygulamaya geçirilir
Kurumsal organizasyon ve süreçler
GEREKSİNİMLERİN TAKİBİ
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.
İŞLEVSEL ANALİZ
DERS2.KONU1
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
SİSTEM = Form + Fonksiyon
İyi bir gözlemci, taş parçasının, kağıt tutucu fonksiyonunu fark
edebilir
PENCERE
Masa
Hava Akımı
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
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.
FONKSİYONEL ANALİZ
USE CASE ANALİZİ
DERS2.KONU2
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
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
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.
USE CASE CLASIFICATION
uc [Package] UseCaseDiagramsPkg [Use Cases f or SpaPoolTempControl System]
Operator Operator
Set up system
Operate system
Adjust set point and set or unset low -temp
alarm
Tune control algorithm
Calibrate sensor
Activate or deactivate system
Enter or exit standby mode Control
temperature and alarm
«inc lude»
«inc lude»
«extend» Handle alarm
«extend»
Scenarios for the general use
case are also scenarios of the
specialized use case
USE CASE DIAGRAMS
USE CASE DIAGRAMS
•Driver Information System Use Cases
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,
SİSTEM TASARIMI
DERS2.KONU3
FORM + FONKSİYON
Aralarında etkileşimli bir birlik görülen elemanlar = Form
Fonksiyonel olarak bakıldığında = Fonksiyon
TASARIM
DOĞRU TASARIM KONSEPTI
Fikirler Kaynaklar
PROGRAM /PROJE
SİSTEMİ*
YÜZEYSEL/ÜST SEVİYE KESİN/DETAYLI
TESLİMAT /ÜRÜN
SİSTEMİ*
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
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
ÖRNEK ÜST SEVİYE MOE
Sistem Etkinliğine krş. Ömür Devri Maliyeti
Operasyonel Etkinlik
İstenilen Sıcaklığı Sabit Tutabilme Olasılığı
Isı Kayıpları
Verilen Isı
Kontrol Duyarlılığı
Odalar arası farklılık
Elverişlilik
İstenilen Sıcak Suyu Sağlayabilme Olasılığı
Su İhtiyacı
Verilen Isı
Kontrol Duyarlılığı
Dağıtım Kayıpları
Elverişlilik
Operasyonel Uygunluk
Güvenilirlik
Sürdürülebilirlik
Elverişlilik
Genişleyebilirlik
Güvenlik
Gürültü
Ömür Devri Maliyeti
AR&GE Maliyeti
Ekipman Maliyeti
Bina Değişiklik Maliyeti
Bakım Maliyetleri
İşletme Maliyetleri
Yatırımın Geri Dönüş Süresi
Risk
Alt Sistem Perf. Riski
Sistem Performans Riski
Maliyet Riski
Takvim Riski
Yakıt Maliyeti
Riski
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üğü)
Sistem Yetenekleri
Radar Mesafesi
IFF Mesafesi
Değerlendirme Verimi
Elverişlilik
Operasyon ve Bakım
Maliyet Modeli
ÖRNEK ÜST SEVİYE MOE
Sistem Etkinliğine krş. Ömür Devri Maliyeti (.153 / 70.000 $)
Operasyonel Etkinlik (.153)
İstenilen Sıcaklığı Sabit Tutabilme Olasılığı (.226)
Isı Kayıpları (.498)
Verilen Isı (.665)
Kontrol Duyarlılığı (.943)
Odalar arası farklılık (.727)
Elverişlilik (.996)
İstenilen Sıcak Suyu Sağlayabilme Olasılığı (.676)
Su İhtiyacı (100 l/sa)
Verilen Isı (80K btu/sa)
Kontrol Duyarlılığı (.97)
Dağıtım Kayıpları (36K
btu)
Elverişlilik (.999)
Operasyonel Uygunluk
Güvenilirlik (3285 saat)
Sürdürülebilirlik (12 sa)
Elverişlilik (.996)
Genişleyebilirlik (n/a)
Güvenlik (n/a)
Gürültü (Yüksek)
Ömür Devri Maliyeti (70.000
$/ 20 yıl)
AR&GE Maliyeti (0)
Ekipman Maliyeti (0)
Bina Değişiklik Maliyeti (0)
Bakım Maliyetleri (150
$/yıl)
İşletme Maliyetleri (3350
$ / yıl)
Yatırımın Geri Dönüş Süresi (o)
Risk (n/a)
Alt Sistem Perf.
Riski
Sistem Performans Riski
Maliyet Riski
Takvim Riski
Yakıt Maliyeti
Riski
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ı
Ü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ı
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
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ı
Alternatiflerin Analizi
Ne (Ge re k s ini m le r) N as ıl (S pes if ik a s y onl a r) (Ş art nam el er)
TASARIM
GEREKSİNİMLER VE SPEKLER ARASINDAKİ
KÖPRÜ
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.
SİSTEM MÜHENDİSLİĞİ YÖNETİMİ
DERS3.KONU1
Program Manager
Systems Engineering
Program Controls
Engineering
TİPİK BİR ORGANİZASYON
Preliminary Detail System Production Operational Managing
the Organization
Supplier Evaluation, Selection, &
Control Systems
Engineering Program Planning
Cost &
Schedule Control
Technical Control Work
Breakdown Structure
Development Design
Review and Evaluation Selection of
Engineering Design Method
Systems Engineering
Systems Engineering Management
SİSTEM MÜHENDİSLİĞİYÖNETİMİ
Conceptual Design
Preliminary System
Design
Detail System Design &
Development
Production and/or Construction
Operational Use & System
Support Systems
Engineering Program Planning
Cost & Schedule Control Technical Control
Managing the Organization
Supplier Evaluation, Selection, & Control
SİSTEM MÜHENDİSLİĞİYÖNETİMİ
Conceptual Design
Preliminary System
Design
Detail System Design &
Development
Production and/or Construction
Operational Use & System
Support Systems
Engineering Program Planning
Cost & Schedule Control Technical Control
Managing the Organization
Supplier Evaluation, Selection, & Control
What is my management
approach?
What steps of the SE process will I execute?
What resources do
SİSTEM MÜHENDİSLİĞİYÖNETİMİ
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
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
WBS
Project activities
Functions
Tasks
Subtasks
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
WBS
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
IMP/IMS
RİSK YÖNETİMİ
DERS3.KONU2
Risk Örnekler Proje Tehditleri Yetersiz bütçe
Uygun olmayan tesisler Teknoloji Performans problemleri
Arayüz problemleri
Personel Yetersiz tecrübe/beceri Değişime direnç/korku Yönetim İhtiyaçlar değişir
GENEL PROJE RİSKLERİ
RİSK KAYNAKLARI
Teknoloji
İnsan
Fiziki ortam
Politik ortam
Sözleşmesel sorunlar
TEMEL PROBLEM
Risk artarsa= Maliyetler artar!
RİSK YÖNETİMİNİN ÖGELERİ
Risk Yönetimi
Risk Değerlendirme
Risk Kontrolü
Risk Tanımlama
Risk Çözümleme
Risk Önceliklendirme
Risk Planlama
Risk İzleme
Risk Azaltma
Gerçekleşme İhtimali(Olasılık)
Muhtemel Etkisi
Hafifletme Maliyeti
RİSK DEĞERLENDİRME
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 !
KONFİGÜRASYON YÖNETİMİ
DERS3.KONU3
“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
KONFİGÜRASYON YÖNETİMİ
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”
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
SİSTEM MÜHENDİSLİĞİ
ÖLÇÜMLERİ (METRİKLER)
DERS3.KONU4
Metric :
Greek metrikE, from feminine of metrikos in meter, by measure, from metron measure ( http://www.m-w.com/cgi- bin/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)
ETİMOLOJİ
METRİK YÖNETİMİ : PROJENİN KADERİNİN YÖNETİMİDİR
“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.
SÜREÇ ÖLÇME
METRİK YÖNETİMİ : PROJENİN KADERİNİN YÖNETİMİDİR
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.
MOE, MOP, TPM
HAREKAT KONSEPTİ DOKÜMANI (OCD)
GELİŞTİRME DOĞRULAMA VE
GEÇERLİLEME
HAREKAT İHTİYAÇLARI ANALİZİ (HAREKAT İHTİYAÇLARI
DOKÜMANI-ORD) GÖREV
İHTİYACI (MNS)
İŞLEVSEL ANALİZ (İŞLEVSEL GEREKSİNİMLER DOKÜMANI-FRD)
SİSTEMLER SİSTEMİ (SoS) ŞARTNAMESİ (Spec) SİSTEM GEREKSİNİMLERİ
DOKÜMANI (SSS) SİSTEM TASARIMI (SSDD)
YAZILIM, DONANIM, ARAYÜZ GEREKSİNİMLERİ
(SRS, HRS, IRS) VE TASARIMLARI (SDD, HDD,
IDD)
BİLEŞEN VASIFLANDIRMA/
KABUL TESTLERİ
SİSTEM VASIFLANDIRMA TESTLERİ
HAREKAT TESTLERİ
PERFORMANS ÖLÇÜMLERİ VE DEĞERLENDİRMELER
KABUL
GÖREVE HAZIR SİSTEM
ETKİNLİK ÖLÇÜMLERİ (MOE)
TPM MOP
AS IS TO BE
DETAYLI V DİYAGRAMI
İzleme Kapasitesi
Arama Kurtarma Görevi Başarım
Olasılığı
İntikal/Manevra Kaabiliyeti
Muhabere Kaabiliyeti
Seyir Sürati Yakıt Deposu
Büyüklüğü Ağırlık
MOE Harekat Analizi
MOP Sistem Analizi
TPM Tasarım
TPM
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%
GEREKSİNİM MÜHENDİSLİĞİ ÖLÇÜMLERİ
OYNAKLIK
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
Oynama
Oynama
İŞ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%
60 80 100 120 140
Toplam Gereksinim Karşılanan
Gereksinimler
SİSTEM TEST VE
DEĞERLENDİRME
DERS4.KONU1
SİSTEM MÜHENDİSLİĞİ SÜRECİ
Customer Need
System Req’s
Subsystem
Req’s Subsystem
System
Operate Validation
Verification
Verification
VV ve WBS
Program
System SE/PM Data Logistics Sys Test
& Integ
Comp Comp Comp Test &
Integ
Comp Comp Comp Test &
Integ
Level 1
Level 2
Level 3
Level 4
TANIMLAR
Geçerli Kılma
Doğrulama
Kalite Güvence
Sistem kullanıcı ihtiyaçlarını karşılıyor mu ? Örneğin, doğru gereksinimler yazılmış mı?
Sistem gereksinimleri karşılıyor mu?
Sistem geliştirme sırasında denenmiş
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?
ANLAŞILMASI İÇİN
YENİ GELİŞMELER VE GİDİŞAT
DERS5.KONU1
ETKİLEŞİM O RT A MI
Değişime ayak uydurabilme
İçerde ve dışarıda işbirliği / Birlikte çalışabilme
Teknolojiyi kullanabilme
KURUMSAL BAŞARIM
ÖLÇÜTLERİ
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ı
ram G eli ştirme Denem e
n ü şüm P lanlam a
DÖNÜŞÜM
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
AĞ DESTEKLİ YETENEK
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
ÇEVİK HAREKAT
Ağ Destekli Yetenek
Sistemler Sistemi
Servis Yönelimli Mimari
«uses»
«uses»
ADY, SiS ve SYM
SİSTEMLER SİSTEMİ
Sistem-A Sistem-B Sistem-C
Sistemler Sistemi Üst Sistem Oluşturma Sistemler Sistemi Entegratörü Sistemler Sistemi Kullanıcısı
Sistem-A Kullanıcısı Sistem-B Kullanıcısı Sistem-C Kullanıcısı
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 .
SİSTEMLER SİSTEMİ (SiS)
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
SERVİS YÖNELİMLİ MİMARİ
(SYM)
SEMBOLİK MODELLEME
Yazılım Modelleme UML
Donanım Modelleme VHDL, CAD, … Sistem Modelleme
SysML Gereksinim
Tanımlama &
Yönetimi
SysML, Sistem Mühendisliği (özellikle Sistem Analiz ve Tasarımı)
süreçlerinde kullanılmak üzere UML’den türetilmiştir.
Analysis framework is solid
Artifacts routinely lack specificity and are sometimes ambiguous, which leads to various
Requirements Analysis Analyze Missions and Environments Identify Functional Requirements
Define Performance & Design Constraint Requirements
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
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
Output
– Decision Database
– System/Config Item Architecture – Specifications and Baselines
Document Based Systems Engineering Process (the old way)
Requirements Loop
Design Loop
Verification Loop
Output Documents (loosely connected) Requirements Document Concept of Operations
Functional Decomposition
FFBD/EFFBD, IDEF, DFD Diagrams Product Breakdown Structure
Systems Decomp. Diagrams N2 Chart
Test Plans Input
Needs/Req
Output
Systems Analysis & Control
Alternatives Analysis
Tradeoff Studies Effectiveness Analysis Interface Management Data Management
CM
MİMARİ TASARIM SÜRECİ
• 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
Requirements Analysis Analyze Missions and Environments Identify Functional Requirements
Define Performance & Design Constraint Requirements
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
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 Architecting and Engineering Process (model based)
Requirements Loop
Design Loop Verification
Loop Input
Needs/Req
Output
Block Definition Diagrams [BDD]
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Activity Diagrams [AD]
Sequence Diagrams [SD]
Use Cases [UC]
Requirements Diagrams [Req]
State Machine Diagrams [SMD]
Package Diagram [PKG]
SysML Diagrams
Structural Diagrams
Block Definition Diagram [BDD]
Internal Block Diagram [IBD]
Behavioral Diagrams
Activity Diagram [AD]
Use Case Diagram [UC]
Cross-Cutting Diagrams
Requirements Diagram [REQ]
MBSE
Benefits of MBSE
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 •Structure
•Integrated Architectural Model
Block Definition Diagrams [BDD]
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Activity Diagrams [AD]
Sequence Diagrams [SD]
Use Cases [UC]
Requirements Diagrams [Req]
State Machine Diagrams [SMD]
Value Build Allocate Systems Analysis &
Control (automated)
Output
Package Diagram [PKG]
Verify
Satisfy
Interface to M&S Analysis Tools
(Opnet, XLS)
Test Planning Integrated Systems Model
