YÖNETİM SİSTEMLERİNDE SİSTEM MÜHENDİSLİĞİ YAKLAŞIMI

1. SİSTEM MÜHENDİSLİĞİ YAKLAŞIMI VE YAŞAM (DEVRİ) SÜREÇLERİ STANDARTLARI

Sistem mühendisliği; pek çok mühendislik bilim dalının ortaya koyduğu ürünlerin bir araya getirilmesiyle oluşan sistemlerle ilgilenerek, diğer mühendislik bilim dallarından ayrılır veya onların bütünleşmiş halini temsil eder. Sistem mühendisliği, dikkatlerin; parçaların meydana getirdiği bütünün tasarımı ve uygulamalarına toplandığı bir mühendislik dalıdır. İhtiyaç veya proje ile ilgili her türlü değişkeni, toplumsal ve teknik yanlarını da gözeterek, bütünsel bir yaklaşımla ele alır. Sistem mühendisliği; disiplinler arası, ihtiyaç sahiplerinin (alıcıların) ihtiyaçlarını karşılamaya yönelik, sistem yaşam (ömür) devri kavramlarını dikkate alan, bütünsel ve bu sayede etkinliği en üst seviye çıkarılmış ortak bir çalışmanın ürünüdür.

Sistem mühendisliği; ihtiyaç makamının (alıcının, müşterinin ve/veya kullanıcının) sunduğu isteklerin analiz edilmesi ile başlayan ve sistemin kullanılabilir ömrünü tamamlamasına kadar devam eden süreçte uygulanan tüm alt süreçleri, faaliyetleri ve/veya görevleri kapsar.

Sistem mühendisliği; günümüzde bilhassa savunma sektörü projelerinde ve yüksek seviyeli yönetim sistemi standartlarında (örneğin; ISO27001: Bilgi Güvenliği Yönetim Sistemi, ISO15288: Sistem Yaşam Devri (döngüsü) Süreçleri, ISO12207: Yazılım Yaşam Devri (döngüsü) Süreçleri, AQAP-160: Yazılım İçin Ömür Devri Boyunca Birleştirilmiş NATO Kalite Gereksinimleri, AQAP-2110: Tasarım, Geliştirme ve Üretim için NATO Kalite Güvence Gerekleri, vb.) yer alan gereksinimlerdendir. Günümüzde sistem (veya ürün, hizmet, proje, yazılım) yaşam devri süreçleri olarak tanımlanan standartlar, sistem mühendisliği disiplinine uygun olarak oluşturulmuştur.

•  Dünyada ilk Sistem Mühendisliği yaklaşımının ortaya konması 1940 yılında olmuştur (BellLabs, MIT, RAND Corp.).
•  ABD, Sistem Mühendisliği yöntemlerini İkinci Dünya Savaşında birçok sistemin geliştirilmesinde yaygın olarak kullanmıştır.
•  İlk Sistem Mühendisliği dersleri MIT ‘de 1950 yılında verilmeye başlamıştır.
•  Günümüzde ABD ve Avrupa başta olmak üzere, birçok gelişmiş ülkede Sistem Mühendisliği uygulamaları standart hale gelmiştir.

Sistem Mühendisliği, ABD’nde Savunma, Havacılık ve Uzay Sanayileri tarafından yıllar süren deneyimlerin sonucu olarak ortaya çıkmış bir mühendislik disiplinidir; bu ülkenin yanı sıra birçok gelişmiş ülkede de yaygın olarak uygulanmakta ve projelerin başarısında kritik rol oynamaktadır. Sistem Mühendisliği, Savunma Sanayinin yanı sıra özellikle Ulaştırma ve Enerji projelerinde de yaygın olarak kullanılmaktadır.

2009 yılında ABD’nde yılın mesleği seçilen Sistem Mühendisliği özellikle büyük sistem entegrasyon projelerinde anahtar rolü oynamaktadır. Ülkemizde de Savunma Sanayi projelerinde olmazsa olmaz olarak uygulanması istenen Sistem Mühendisliği, Ulaştırma ve Enerji sektörlerine de hızla yayılmaktadır.

2. SİSTEM (ÜRÜN,PROJE, YAZILIM) YAŞAM SÜRECİNDE SİSTEM MÜHENDİSLİĞİ YAKLAŞIMI

Karmaşık sistemlerin geliştirilmesi için Sistem Mühendisliği V-Modeli olarak adlandırılan bir tasarım ve entegrasyon (bütünleştirme) süreci yaygın olarak kullanılmaktadır (bkz. Şekil.1). Bu modele göre, tasarım süreci ihtiyaç makamının (alıcının, müşterinin ve/veya kullanıcının) sunduğu isteklerin analiz edilmesiyle başlar. Bu istekler, kullanıcı ya da ihtiyaç sahibi makamın sistem için öngördüğü operasyonel kavrama uygun olarak belirlediği başlangıç gereksinimleridir. Bu gereksinimler, alıcının kendi kullanım ortamı açısından açık ve tanımlayıcı bilgiler içerse de gereksinimlerin tasarım girdisi olarak kullanılması için tasarımcı açısından anlamlı teknik gereksinimlere dönüştürülmesi ve sınıflandırılması gerekir.

İhtiyaç makamının sunduğu tüm istekler, tasarımcı bakış açısıyla, fiziksel, işlevsel, performans, arayüz, lojistik, çevre, emniyet/güvenlik, vb. sınıflarda gruplandırılır ve tasarımcı bakış açısıyla ifade edilmiş sistem gereksinimlerine dönüştürülür. Elde edilen sistem gereksinimlerinin evrimi sürer ve alt bileşen gereksinimleri ve/veya konfigürasyon ögesi gereksinimlerine kaynaklık eder.

Literatürde birçok kişi tarafından, mimari ve kavramsal tasarım safhası ile ayrıntılı tasarım safhası olarak tanımlanan safhaları, biz “tanımlama” ve “tasarım” olarak düşünelim. Çünkü tasarıma geçmeden önce, ihtiyaç sahibinin (alıcının) gereksinimlerinin çok iyi anlaşılması ve “tanımlanması”, hatalı tasarım ve sonrasında hatalı bir üretimin de önlenmesi anlamına gelir.

Şimdi, sistem (ürün, yazılım, proje, vb.) yaşam sürecinde uygulanan, hem “Sistem Mühendisliği VModeli”ni ve hem de benim tavsiye edeceğim “Sistem (Ürün/Hizmet/Proje) Yaşam Sürecinde Konfigürasyon Yönetimi Modeli”ni, yaşam süreci safhaları ile birlikte açıklayalım. Burada konfigürasyon yönetiminin detaylarına girmeyeceğimi belirtmek isterim.

2.1 Tanımlama Safhası

Kullanıcı (alıcı, müşteri) isteklerinin tasarıma girdi sağlayabilecek sistem gereksinimleri haline getirilmesi amacıyla, sistemin mimari tasarım aşamasına geçilir. Mimari tasarım aşamasında üç ayrı mimari geliştirilir. Bunlar “işlevsel, fiziksel ve operasyonel” mimari olarak adlandırılır. Sistemin işlevsel mimarisi sistemin ne yapması gerektiğini, sistemin işlevlerini ve bunların arasında akan verileri tanımlar. Sistemin fiziksel mimarisi, sistemin işlevlerini yerine getirecek fiziksel kaynakların belirlenmesini kapsar. Operasyonel mimari ise, hangi işlevlerin hangi fiziksel kaynak ile yerine getirileceğini tanımlayan tahsis sürecinin sentezi ile oluşturulur. Mimari tasarım sürecinde, sistemin fiziksel ve işlevsel mimarileri göz önünde bulundurularak arayüzleri de tanımlanır. Bu mimari, sistem ve alt sistem tasarımlarına girdi sağlar ve tasarım ilerledikçe arayüzlerin kontrol altına alınması için temel oluşturur.

O halde, hazır ürün (sistem, vb.) satış siparişi dışındaki teklif ve/veya ihale aşaması ile başlayan süreçte, müşteri gereksinimleri dikkate alınarak ürünün kavramsal / işlevsel konfigürasyonu tanımlanır. Kavramsal /işlevsel tanımlama bitirilip ürünün tasarımına geçilmeye karar verildiğinde konfigürasyon bilgileri güncellenir ve konfigürasyon “Temel” durumuna getirilir. Tanımlama safhasında konfigürasyon durumunu “Temel” durumuna getirebilmenin koşulu; satış sözleşmesi, ilgili plan dokümanları (konfigürasyon yönetimi planı, proje yönetim planı, güvenlik gereksinimleri planı, vb.) ve ilgili gereksinim dokümanlarının tamamlanmış olmasıdır. Ayrıca alıcının (müşteri) da yer aldığı Konfigürasyon Yönetimi Kurulunun safha geçişini onaylaması uygun bir yöntemdir. Ürünün müşteri ortamında (sahada) kurulumu sırasında gerekli olabilecek bileşenlerin varlığı biliniyorsa, bu bileşenlerin tanımlanması için bir keşif yapılır. Böylece Kavramsal / İşlevsel Tanımlama Konfigürasyonu içine kurulumda kullanılacak bileşenler de eklenerek, ürünün tasarımı müşteri gereksinimlerine tam olarak uyacak şekilde başlatılır.

2.2 Tasarım Safhası

Mimari tasarım sürecinin ardından, sistemi oluşturan bileşenlerin de gereksinimlerinin atanmasıyla sistemin sahip olacağı alt sistemler ve görevleri şekillenmiş olmaktadır. Tasarımda temel yapı seviyesi (Tasarım Temel) oluşturulması işlemi, “seçeneklerin ve tekrarlı eylemlerin doğrulanmasına dayanan yaratıcı bir süreç” olarak tanımlanır. Bu yaklaşıma göre tasarımcı, görev gereksinimlerinden yola çıkarak kendi sistemine ait bir temel yapı oluşturmakta, sistemin tüm parametrelerini analiz ederek tekrarlı eylemler gerçekleştirmekte ve belirlediği temel yapının performans gereksinimlerini sağladığını (doğrulama ve geçerleme testleri ile) kontrol etmektedir. Böylece, sistemin ve sistemi oluşturan alt bileşenlerin (ögelerin) yapılandırılması (konfigürasyonu) ve tasarım temel konfigürasyonu oluşturulur.

Tasarım safhasında, ürünün tanımlama (kavramsal / işlevsel) dokümanlarından yararlanılarak ayrıntılı tasarım gerçekleştirilir, doğrulanır (verification) ve geçerlenir (validation). Tasarım safhasında konfigürasyon durumunu “Temel” durumuna getirebilmenin koşulu, tasarım prototipinin geçerlenmesi, yani test ortamındaki testlerin (validation) tamamlanmış olmasıdır.

Tasarımı “Temel” durumuna getirilmiş sistem (ürün, vb.) için seri üretime geçebilmek amacıyla, seri üretim koşullarında bir deneme üretimi yapılması ve bundan sonra alınacak seri üretim yetkisi ile üretime başlanması en çok tercih edilen uygulamadır.

2.3 Üretim, Kurulum/Yayılım ve Bakım Safhaları

Üretim safhası sonunda, müşteri ile birlikte yapılacak kabul testleri sonucunda ilgili ürünlerin (konfigürasyonlarının) müşteriye sevk edilmesi onaylanmış olur, diğer bir ifade ile ilgili konfigürasyon ögesi çıkış için serbest bırakılır (release).

Kurulum ( ve yayılım) safhasında, ilgili sistem(ler) (ürün, yazılım) tanımlanmış dokümanlara uygun olarak sahada (müşterinin anlaşmada belirttiği yerlerde) kurulur ve/veya yayılımı sağlanır. Bu safhada müşterinin isteği üzerine geçici saha kabul testi ve/veya saha kabul testi de uygulanabilir.

Sistemin (ürün, yazılım) kurulup müşteriye (alıcıya) teslim edildikten sonra başlayan bakım safhasında; ürün konfigürasyonunda ortaya çıkacak değişiklikler “Konfigürasyon Değişikliklerinin Kontrolü ve Uygulanması” maddesinde anlatılan yöntem ile takip edilir.

Sistem mühendisliği yaklaşımının benimsenmesi ile, sistemlerin tasarım safhası gibi üretim, kurulum (ve yayılım) ve bakım safhalarında da tutarlı ve etkin bir işletim sağlanır. Şekil. 3‘de bu safhalardaki konfigürasyon yönetimi ve geçiş koşulları ile ilgili dokümanlar gösterilmiştir.

2.4 V-Modeli

V-Modeli, çevik yöntem savunucuları ve diğer bazı kişiler tarafından çeşitli nedenlerle yazılım geliştirmede yetersiz bir model olarak eleştirilmektedir. Eleştirilerden bazıları şunlardır:

• V-Modeli, yazılım geliştirme ile ilgili bir proje yönetimi görünümünü yansıtır ve yazılım geliştiriciler veya kullanıcılardan ziyade, proje yöneticilerinin, muhasebecilerin ve avukatların ihtiyaçlarını karşılar.
• Yeni başlayanlar tarafından kolaylıkla anlaşılsa da, V-Modelinin pratikte nasıl uyarlanacağı ve genişletilmesi konusunda daha kapsamlı ve detaylı bir çaba gerekir.
• Esnek değildir. Yazılım geliştirmede katı ve doğrusal bir bakışı teşvik eder. Değişime cevap verebilme kabiliyeti yoktur.
• Şelale modelinde ufak bir çeşitlilik sağlar ve bu nedenle bu modelle aynı eleştirilere tabidir. Teste ve özellikle erken test planlamasının önemine daha fazla önem verir.
• Verimsiz ve etkisiz test metodolojilerini özendirir.
• Tutarlılık ve hassaslıktan yoksundur. V-Modelinin tam olarak ne olduğu konusunda yaygın bir karışıklık vardır.

V-Model’in destekçileri, modelin zamanla evrimleştiğini ve gelişim süreci boyunca esneklik ve çevikliği desteklediğini savunmaktadır. Ayrıca, oldukça disiplinli bir yaklaşım olmanın yanı sıra istikrarlı yazılım ürünleri üretmek için, titiz tasarım, geliştirme ve dokümantasyon geliştirdiğini söylemektedirler.

2.5 Sistem (Ürün/Hizmet/Proje) Yaşam Sürecinde Konfigürasyon Yönetimi Modeli

Sistem (veya Ürün, Hizmet, Proje) yaşam sürecinin safhalara ayrılması bilinen bir kavramdır. Bu kavram ile konfigürasyon yönetimi kavramını birleştirip uyguladığımızda, ki büyük ölçekli ve standartlara uygun çalışan kuruluşlar için yeni bir şey değildir, ortaya çok daha tutarlı ve güvenilir bir uygulama modeli çıkmaktadır. Sistem (veya Ürün, Hizmet, Proje) yaşam sürecinde konfigürasyon yönetimi modeli Şekil.2’de kavramsal olarak gösterilmiştir.

Konfigürasyon yönetiminin temel amacı, ürünlerin (hizmetlerin); yaşam sürecinin tüm safhalarında, müşteri gereklerini tam olarak karşılayacak şekilde doğru ve tam olarak oluşturulmasını sağlamaktır. Dolayısıyla yaşam süreci safhalarının belirlenmesi, bu safhalar arasında geçiş kurallarının oluşturulması ve her bir safhada gerçekleştirilecek faaliyetler ile oluşturulacak çıktıların tanımlanması çok önemlidir. Bu hususlar ile ilgili özet bilgiler; Şekil. 3’de şematik olarak gösterilmiş, Tablo’1 de ise ilgili doküman tanımları açıklanmıştır. Şekil. 3’de ve Tablo’1 de belirtilen geçiş koşulları ve dokümanlar, en önemlilerinden seçilerek örnek olarak verilmiştir. Şekil. 3’de verilen doküman kısaltmaları, aynı şekil üzerinde olabildiğince çok dokümanı gösterebilmek için tanımlanmıştır. Bu kısaltmalar, farklı kuruluşlarda benzer ve/veya farklı olabilir.

Burada konfigürasyon yönetiminin detaylarına girmeyeceğim. Fakat özet olarak konfigürasyon yönetiminin: konfigürasyon ögesinin (sistem, ürün, alt sistem, alt ürün, vb.);

✓fonksiyonel (işlevsel) ve fiziksel özelliklerini tanımlamak ve dokümante etmek,
✓ özelliklerinde ortaya çıkan değişiklikleri kontrol etmek ve değişiklik işlemlerini kaydetmek,
✓ ilerleme durumunu kaydetmek ve raporlamak,
✓ belirlenen gereklere uygunluğunu denetlemek,

için uygulanan yöntem, kaynak ve araçlardan oluşan bir süreç olduğunu söyleyebiliriz.

Şekil. 3 Ürün (Hizmet/Proje/Sistem) Yaşam Süreci Safhalarında Konfigürasyon Yönetimi ve Dokümanlar

Şekil. 3’de ilgili safhalar için belirtilen doküman kısaltmalarının açılımı (doküman tanımları) Tablo.1’ de gösterilmiştir. Burada belirtilen dokümanlar, tüm dokümanlar değildir, örnek olarak verilmiştir.

 Tablo. 1 Ürün (Hizmet/Proje/Sistem) Yaşam Süreci Safhalarındaki Dokümanlar

2.6 Konfigürasyon Değişikliklerinin Kontrolü ve Uygulanması

Sistem (ürün, yazılım) yaşam sürecinin herhangi bir safhasında veya yerinde ortaya çıkan konfigürasyon değişikliği isteği, değişikliklerin ayrıntılı olarak açıklandığı bir doküman ile (“Ürün Konfigürasyon Değişikliği Dokümanı”, vb.) değişikliği uygulayacak bölümlere ve Konfigürasyon Yönetimi Kuruluna gönderilir. Alıcıya (müşteriye) veya ilgili taraflara değişiklikler hakkında bilgi verilir. Ürün Konfigürasyon Değişikliklerinin görüşülmesi ve onaylanması; ilgili birimlerden temsilcilerin katıldığı “Konfigürasyon Yönetimi Kurulu” toplantılarında yapılır. Müşteri tarafından talep edildiğinde bu toplantıya müşterinin temsilcisi de katılır. Toplantıya katılanların onayı ile değişikliğin yürürlük tarihi ve değişiklik sınıfı belirlenir. Değişiklik sınıfları; değişikliklerin, önem ve etkileri (şekil, uygunluk, işlev değişiklikleri, vb.) göz önünde bulundurularak belirlenir. Konfigürasyon Yönetimi Kurulu tarafından reddedilen değişiklik önerisi işleme sokulmaz. Sistem (ürün, yazılım) konfigürasyon değişikliği yaşam sürecindeki hangi safhayı ilgilendiriyorsa, ilgili safhadaki yaşam süreci faaliyetleri gerçekleştirilir ve ilgili değişiklikler uygulandıktan sonra konfigürasyon Temel hale getirilerek yaşam süreci devam ettirilir. Sistem (ürün, yazılım) ve dokümanlarındaki değişikliklerin izlenebilirliği ve kontrolünü sağlamak amacıyla; doküman seti, doküman seti değişiklik bilgileri, ürün konfigürasyon değişiklik yetkisi, konfigürasyon ögesi, konfigürasyon ögesi durumu, konfigürasyon numarası, uygulama tarihi, değişiklik sınıfı, ürün konfigürasyon değişiklik yetkisi numarası, Konfigürasyon Yönetimi Kurulu karar tarihi, vb. bilgilerin izlenmesi gerekir. Bu bilgilerin kolay ve doğru olarak izlenmesi amacıyla bir “Konfigürasyon Yönetim Sistemi” yazılımının kullanılması uygun olur. Burada, konfigürasyon yönetiminin detaylarına girmediğimi tekrar belirtmeliyim.

3. YAŞAM (DEVRİ) SÜREÇLERİ İLE İLGİLİ STANDARTLAR

Günümüzde ülkemiz savunma sanayi projelerinde de öne çıkan sistem (ürün) yaşam (devri) süreçleri ile ilgili standartlardan bazıları bilgi amacıyla Tablo.2 de gösterilmiştir.