Sistem Muhendisligi Egitimi Kavram ve Ihtiyaclar

Transkript

SİSTEM MÜHENDİSLİĞİ
BİLGİ ALANLARI
ÖMER ERTEKİN
PSCONSULTECH
HDM
Sistem Mühendisliği Bilgi Alanları, Sürüm1
ÖMER ERTEKİN, PSCONSULTECH
1
DERS1.KONU1
PROJE KAPSAMI
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.
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.
Sistem
Vizyonu
Sürüm_1
Proje
Kapsamı
Sürüm_2
Proje
Kapsamı
Sürüm_n
Proje
Kapsamı
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
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.
5
DERS1.KONU2
SİSTEM BAĞLAMI
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.
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.
8
SİSTEM SINIRLARI KONSEPTİ
Ortam
Diğer
Sistem
İlgi
Arayüzler
Diğer
Sistem
Sistem
Sistem
•Sadece
Diğer
Diğer
Sistem
•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
9
DERS1.KONU3
PAYDAŞ ANALİZİ
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 !
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
12
DERS1.KONU4
İŞLETİM KONSEPTİ
13
İŞLETİM KONSEPTİ
Sistem işletiminde bir
gün
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.
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.
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.
••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
•8.2 Disadvantages and limitations
•8.3 Alternatives and •trade
•offs considered
•9.
••Notes
•Appendices
•Glossary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
17
DERS1.KONU5
PROBLEM VE İHTİYAÇ
ANALİZİ
18
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.
19
PROBLEM TANIMLAMA ve
ÇÖZÜMLEME
ÇÖZÜMUZAYI
PROBLEM UZAYI
PROBLEMİ
PROBLEMİ
TANIMLA
ANALİZ ET
HEDEFLENEN
VARSAYIMLAR
VARSAYIMLARI
ÖNER
DEĞERLENDİR
UYGUNLUK
TASARIM
TASARIM
ÖLÇÜTÜNÜ
KONSEPTLERİ
KONSEPTLERİNİ
TANIMLA
ÖNER
DEĞERLENDİR
FONKSİYONU
TANIMLA
BİRİNİ SEÇ
DIŞ
ARAYÜZLERİ
ANALİZ ET
PROBLEMİ
TANIMLA
BİRİNİ SEÇ
GÖREV
FONKSİYONLARINI
Mimari Geliştirme
ANALİZ ET
BAŞARIM ÖLÇÜTÜ
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.
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
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.
23
DERS1.KONU6
GEREKSİNİM YÖNETİMİ
24
SÜREÇ İÇİNDE GEREKSİNİMLER
Paydaş
İhtiyaçları
Sistem
Gereksinimleri
Paydaşlar için sonuçları tanımlamak
Ürünü geçerli kılmak
Sistemin yapması gerekenleri tanımlamak
Sistemi doğrulamak
Alt Sistem
Gereksinimleri
Bileşen
Gereksinimleri
Maliyet fayda optimizasyonu
Gereksinimlerin kalifikasyonu
Gereksinimlerin tahsisi
Bileşenlerin kalifikasyonu
Kabul
Testleri
Sistem
Testleri
Entegrasyon
Testleri
Bileşen
Testleri
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.
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.
27
KAÇ GEREKSİNİMİZ VAR ?
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.
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.
30
DERS2.KONU1
İŞLEVSEL ANALİZ
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
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
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
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.
35
DERS2.KONU2
USE CASE ANALİZİ
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.
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.
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.
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»
Enter or exit
standby mode
Control
temperature
and alarm
«extend»
Handle alarm
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
41
USE CASE DIAGRAMS
•Driver Information System Use Cases
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
43
DERS2.KONU3
SİSTEM TASARIMI
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.
45
TASARIM
46
DOĞRU TASARIM KONSEPTI
Fikirler
PROGRAM
Kaynaklar
/PROJE
SİSTEMİ*
TESLİMAT /ÜRÜN
SİSTEMİ*
YÜZEYSEL/ÜST SEVİYE
KESİN/DETAYLI
• Doğru tasarım konsepti, elenen alternatifler arasında en uygun
olanıdır.
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
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
49
ÖRNEK ÜST SEVİYE MOE
Sistem Etkinliğine krş. Ömür Devri Maliyeti
Operasyonel Etkinlik
İstenilen Sıcaklığı Sabit
Tutabilme Olasılığı
Operasyonel Uygunluk
İstenilen Sıcak Suyu
Sağlayabilme Olasılığı
Ömür Devri Maliyeti
Risk
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ü
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üğü)
Sistem Yetenekleri
Operasyon ve Bakım
Maliyet Modeli
Elverişlilik
Radar Mesafesi
IFF Mesafesi
Değerlendirme
Verimi
Atama Verimi
51
Ö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)
Operasyonel
Uygunluk
İstenilen Sıcak Suyu
Sağlayabilme Olasılığı (.676)
Ömür Devri
Maliyeti (70.000
$/ 20 yıl)
Risk (n/a)
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
Gürültü (Yüksek)
Yatırımın Geri
Dönüş Süresi (o)
Kullanım Ömrü
(Uzun)
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
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ı
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
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ı
56
TASARIM
Alternatiflerin
(Şartnameler)
(Spesifikasyonlar)
Nasıl
(Gereksinimler)
Ne
Analizi
GEREKSİNİMLER VE SPEKLER ARASINDAKİ
KÖPRÜ
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.
58
DERS3.KONU1
YÖNETİMİ
59
TİPİK BİR ORGANİZASYON
Program
Manager
Program
Controls
Systems
Engineering
Engineering
60
SİSTEM MÜHENDİSLİĞİYÖNETİMİ
Systems Engineering Management
Work
Breakdown
Structure
Development
Selection of
Engineering
Design
Method
Cost &
Schedule
Control
Systems
Engineering
Program
Planning
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
61
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
62
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?
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
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
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
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
67
DERS3.KONU2
RİSK YÖNETİMİ
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
69
69
RİSK KAYNAKLARI
Teknoloji
İnsan
Fiziki ortam
Politik ortam
Sözleşmesel sorunlar
70
TEMEL PROBLEM
Risk artarsa= Maliyetler artar!
71
RİSK YÖNETİMİNİN ÖGELERİ
Risk Tanımlama
Risk Değerlendirme
Risk Çözümleme
Risk Önceliklendirme
Risk Yönetimi
Risk Planlama
Risk İzleme
Risk Kontrolü
Risk Azaltma
72
RİSK DEĞERLENDİRME
Gerçekleşme İhtimali(Olasılık)
Muhtemel Etkisi
Hafifletme Maliyeti
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 !
74
DERS3.KONU3
KONFİGÜRASYON YÖNETİMİ
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
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”
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
78
DERS3.KONU4
ÖLÇÜMLERİ (METRİKLER)
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
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
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.
82
DETAYLI V DİYAGRAMI
GÖREV
İHTİYACI
(MNS)
GÖREVE HAZIR
SİSTEM
DOĞRULAMA VE
GEÇERLİLEME
GELİŞTİRME
TO BE
AS IS
HAREKAT İHTİYAÇLARI
ANALİZİ
(HAREKAT İHTİYAÇLARI
DOKÜMANI-ORD)
PERFORMANS ÖLÇÜMLERİ
VE DEĞERLENDİRMELER
ETKİNLİK ÖLÇÜMLERİ (MOE)
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
YAZILIM, DONANIM,
ARAYÜZ GEREKSİNİMLERİ
(SRS, HRS, IRS) VE
TASARIMLARI (SDD, HDD,
IDD)
TPM
SİSTEM VASIFLANDIRMA
TESTLERİ
BİLEŞEN VASIFLANDIRMA/
KABUL TESTLERİ
BİLEŞEN TANIMLAMA
DOKÜMANI (HWCI, CSCI)
YAZILIM, DONANIM
GERÇEKLEŞTİRME
83
TPM
Arama Kurtarma
Görevi Başarım
Olasılığı
MOE
Harekat Analizi
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
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%
•8585
GEREKSİNİM MÜHENDİSLİĞİ
ÖLÇÜMLERİ
OYNAKLIK
Oynama
60,00%
50,00%
40,00%
30,00%
Oynama
20,00%
10,00%
0,00%
Kick-Off
SRR
PDR
CDR
TRR
•8686
İŞLEVSEL ANALİZ ÖLÇÜMLERİ
GEREKSİNİM KARŞILAMA
Kick-Off
Mevcut
Değişen
Eklenen
Silinen
Toplam
Toplam Gereksinim
Karşılanan Gereksinimler
Gereksinim Kapsama
SRR
PDR
CDR
TRR
0
0
47
171
172
0
0
20
10
10
0
67
113
1
0
0
1
0
0
0
67
181
182
182
100
107
118
119
119
0
20
100
119
119
0,00% 18,69% 84,75% 100,00% 100,00%
140
120
100
80
Toplam Gereksinim
60
Karşılanan
Gereksinimler
40
20
0
Kick-Off
SRR
PDR
CDR
TRR
•8787
DERS4.KONU1
SİSTEM TEST VE
DEĞERLENDİRME
88
SÜRECİ
Validation
Customer
Need
Operate
Verification
System
Req’s
System
Verification
Subsystem
Req’s
Subsystem
Design
Build
“V” Model
89
VV ve WBS
Program
SE/PM
System
Comp
Comp
Comp
Comp
Data
Comp
Comp
Level 1
Logistics
Test &
Integ
Test &
Integ
Sys Test
& Integ
Level 2
Level 3
Level 4
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ı?
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?
92
DERS5.KONU1
YENİ GELİŞMELER VE
GİDİŞAT
93
ORTAMI
ETKİLEŞİM
KURUMSAL BAŞARIM
ÖLÇÜTLERİ

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
94
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.
Deneme
Kavram Geliştirme
Dönüşüm Planlama
“Kavram Geliştirme ve Deneme” (CD& E) ve Moda Tasarımı
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”
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 ...
97
ADY, SiS ve SYM
Ağ Destekli Yetenek
«uses»
Sistemler Sistemi
«uses»
Servis Yönelimli Mimari
98
SİSTEMLER SİSTEMİ
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
Sistem-A
Sistem-A Kullanıcısı
Sistem-A Sahibi
Sistem-B
Sistem-B Kullanıcısı
Sistem-B Sahibi
Sistemler Sistemi Kullanıcısı
Üst Sistem Oluşturma
Sistem-C
Sistem-C Kullanıcısı
Sistem-C Sahibi
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.
101
SEMBOLİK MODELLEME
Sistem Modelleme
Gereksinim
Tanımlama &
Yönetimi
SysML
Yazılım Modelleme
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.
102
MİMARİ TASARIM SÜRECİ
Document Based Systems Engineering Process (the old way)
Systems
Analysis & Control
Alternatives Analysis
Output Documents
Tradeoff Studies
(loosely connected)
Effectiveness
Analysis
Requirements Document
Interface
Management
Concept of Operations
Data Management
CM
Requirements Analysis
Input
Needs/Req
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
Functional Decomposition
FFBD/EFFBD, IDEF, DFD Diagrams
Product Breakdown Structure
Design Loop
Verification
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
Output
Output
Systems Decomp. Diagrams
N2 Chart
Test Plans
– 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
103
MBSE
•
•
•
•
Uses the same architecting
process
Creates SysML models
rather than developing
documents
Systems Architecting and Engineering Process (model based)
Input
Needs/Req
Requirements Analysis
Requirements Diagrams [Req]
Analyze Missions and Environments
Identify Functional Requirements
Define Performance & Design Constraint Requirements
Use Cases [UC]
Requirements Loop
Automation tools can be
used to generate routine
artifacts directly
Functional Analysis/Allocation
Sequence Diagrams [SD]
Decompose to Lower-Level Functions
Allocate Perf. Requirements to all Functional Levels
Define/Refine Functional Interfaces (Internal/External)
Define/Refine/Integrate Functional Architecture
Activity Diagrams [AD]
4 Structural
•
1 Cross-Cutting
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Output
•
Block Definition Diagrams [BDD]
Transform Architectures (Functional to Physical)
Define Alternative System Concepts & System Elements
Select Preferred Product and Process Solutions
Define/Refine Physical Interfaces (Internal/External) Verify
SysML Diagrams
Structural Diagrams
4 behavioral
State Machine Diagrams [SMD]
Design Loop
Verification
Loop
Design/Synthesis
SysML provides 9 different
types of diagrams to
represent the architecture,
which can be used to
develop solutions
•
Package Diagram [PKG]
Internal Block Diagram
[IBD]
Cross-Cutting
Diagrams
Block Definition
Diagram [BDD]
Behavioral Diagrams
Use Case Diagram
[UC]
Activity Diagram
[AD]
State Machine
Diagram [SMD]
Sequence Diagram
[SD]
Requirements
Diagram [REQ]
Package Diagram
[PKG]
Parametric Diagram
[PD]
104
Benefits of MBSE
Systems Analysis &
Control (automated)
Integrated Systems Model
Interface to M&S
Analysis Tools
Sequence Diagrams [SD]
(Opnet, XLS)
Activity Diagrams [AD]
Allocate
State Machine Diagrams [SMD]
Test Planning
Block Definition Diagrams [BDD]
Internal Block Diagrams [IBD]
Parametric Diagrams [PD]
Value Build
Defines architectures that can be simulated
with standard tools
Models can be used with many standards
compliant automation tools
Package Diagram [PKG]
Output
Uses a standards based modeling
language
Use Cases [UC]
Satisfy
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
Requirements Diagrams [Req]
Verify
Models use common data sets
•Integrated Architectural Model
•Requirements
•Structure
Automation tools are used to generate
artifacts
Less labor intensive to generate & update
•Behavior
•Parametric
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
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.
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
– Yazılım
– Tasarım
– Veri
– Doğrulama
– Personel
– Geçerli Kılma
– Yönergeler
– Tesisler
108
SysML DİYAGRAM AİLESİ
109

Sistem Muhendisligi Egitimi Kavram ve Ihtiyaclar

Transkript

Benzer belgeler

İKİNCİ ÖĞRETİM BÖLÜMLERİMİZDEN %10`a GİREN

Sistem Uzmanı – BASIS

T.C. BÜLENT ECEVİT ÜNİVERSİTESİ Mühendislik Fakültesi

Özgeçmiş - Maltepe Üniversitesi

İnşaat Mühendisliği tanıtım sunusu için tıklayınız.