Değişiklikler

760. satır: 760. satır:     
===3.2.2. ÜRÜN AĞACI===
 
===3.2.2. ÜRÜN AĞACI===
 +
Ürün ağacı, ürün yapısının hiyerarşik bir yapıda, ast-üst ilişkileri ile birbirine takip eden kalemler arasındaki ilişkinin kolayca görülebildiği tasarım, planlama, tedarik, üretim ve doğrulama faaliyetlerine baz olan kritik bir ana veridir.
   −
=== Ürün ağacı, ürün yapısının hiyerarşik bir yapıda, ast-üst ilişkileri ile birbirine takip eden kalemler arasındaki ilişkinin kolayca görülebildiği tasarım, planlama, tedarik, üretim ve doğrulama faaliyetlerine baz olan kritik bir ana veridir. ===
   
Bir ürün ağacı ancak tüm birimler ve o birimlerin tasarlanması, tedarik edilmesi, üretilmesi, doğrulanması vb. faaliyetler için gerekli belgeleri veya üstverileri içerdiği surette ürün ömür devrinin tamamında fayda ve verim sağlayan bir araç haline gelebilir.
 
Bir ürün ağacı ancak tüm birimler ve o birimlerin tasarlanması, tedarik edilmesi, üretilmesi, doğrulanması vb. faaliyetler için gerekli belgeleri veya üstverileri içerdiği surette ürün ömür devrinin tamamında fayda ve verim sağlayan bir araç haline gelebilir.
   775. satır: 775. satır:  
Konfigürasyon Temel çizgileri içerdikleri bilgi detayına veya ürün ömür devri safha geçişlerindeki yetki aktarımı dönemlerine göre sınıflandırılırlar.
 
Konfigürasyon Temel çizgileri içerdikleri bilgi detayına veya ürün ömür devri safha geçişlerindeki yetki aktarımı dönemlerine göre sınıflandırılırlar.
   −
===3.2.4.1. GELENEKSEL KONFİGÜRASYON TEMEL ÇİZGİLERİ===
+
====<big>3.2.4.1. GELENEKSEL KONFİGÜRASYON TEMEL ÇİZGİLERİ</big>====
   −
===3.2.4.1.1. İşlevsel Temel Çizgi===
+
=====<big>3.2.4.1.1. İşlevsel Temel Çizgi</big>=====
 
Genellikle Sistem Gereksinim Tanımlama Aşamasının (Kilometre taşı M1) sonunda ürün seviyesi gereksinimlerin müşteri onayı alınarak (Sistem Gereksinimleri Gözden Geçirme Toplantıları ile) dondurulması ile İşlevsel Temel çizgi oluşturulur.
 
Genellikle Sistem Gereksinim Tanımlama Aşamasının (Kilometre taşı M1) sonunda ürün seviyesi gereksinimlerin müşteri onayı alınarak (Sistem Gereksinimleri Gözden Geçirme Toplantıları ile) dondurulması ile İşlevsel Temel çizgi oluşturulur.
   −
===3.2.4.1.2. Tahsis Edilmiş Temel Çizgi===
+
=====<big>3.2.4.1.2. Tahsis Edilmiş Temel Çizgi</big>=====
 
Ön Tasarım Aşamasının (M3) sonunda, son ürün seviyesi gereksinimlerin Konfigürasyon Birimleri’ne kırılarak atanması (tahsis edilmesi) ile her bir Konfigürasyon Birimi için Tahsis Edilmiş Temel çizgi oluşturulur.  
 
Ön Tasarım Aşamasının (M3) sonunda, son ürün seviyesi gereksinimlerin Konfigürasyon Birimleri’ne kırılarak atanması (tahsis edilmesi) ile her bir Konfigürasyon Birimi için Tahsis Edilmiş Temel çizgi oluşturulur.  
===3.2.4.1.3. Geliştirme Konfigürasyonu (Tasarımsal Veya Dahili Temel Çizgi)===
+
=====<big>3.2.4.1.3. Geliştirme Konfigürasyonu (Tasarımsal Veya Dahili Temel Çizgi)</big>=====
 
Tasarım bilgileri, Detay Tasarım Aşaması (M4) boyunca peyderpey oluşturulur. Ortaya konulan her bir tasarım doğrulanmadan bir sonraki aktiviteye geçilmez. Doğrulanamayan tasarım çözümlerinin kontrollü ve proje takvimini riske sokmayacak şekilde güncellenebilmesi için yüklenici kontrolünde idame edilen dahili konfigürasyon temel çizgisine “Geliştirme Konfigürasyonu” denir. Bu dahili temel çizginin değişiklik yetkili ve sorumlusu yüklenicidir.
 
Tasarım bilgileri, Detay Tasarım Aşaması (M4) boyunca peyderpey oluşturulur. Ortaya konulan her bir tasarım doğrulanmadan bir sonraki aktiviteye geçilmez. Doğrulanamayan tasarım çözümlerinin kontrollü ve proje takvimini riske sokmayacak şekilde güncellenebilmesi için yüklenici kontrolünde idame edilen dahili konfigürasyon temel çizgisine “Geliştirme Konfigürasyonu” denir. Bu dahili temel çizginin değişiklik yetkili ve sorumlusu yüklenicidir.
    
Geliştirme safhasının sonunda Geliştirme Konfigürasyonundaki tüm bilgiler nihai doğrulama olan konfigürasyon tetkikleri sonucunda geçerli kılınarak Ürün Temel Çizgisini oluşturacaktır.
 
Geliştirme safhasının sonunda Geliştirme Konfigürasyonundaki tüm bilgiler nihai doğrulama olan konfigürasyon tetkikleri sonucunda geçerli kılınarak Ürün Temel Çizgisini oluşturacaktır.
   −
===3.2.4.1.4. Ürün Temel Çizgisi===
+
=====<big>3.2.4.1.4. Ürün Temel Çizgisi</big>=====
 
Geleneksel yaklaşımda Ürün Temel Çizgisi, Geliştirme safhasının sonunda doğrulanmış ve geçerli kılınmış tasarım bilgileri olarak tanımlanmaktadır. Bu hali ile Ürün Temel Çizgisi aynı zamanda Teknik Veri Paketi’nin (TVP) büyük bir unsurunu oluşturur.
 
Geleneksel yaklaşımda Ürün Temel Çizgisi, Geliştirme safhasının sonunda doğrulanmış ve geçerli kılınmış tasarım bilgileri olarak tanımlanmaktadır. Bu hali ile Ürün Temel Çizgisi aynı zamanda Teknik Veri Paketi’nin (TVP) büyük bir unsurunu oluşturur.
    
Ürün Temel Çizgisinin çekildiği dolayısıyla TVP’nin oluşturulduğu aşama Konfigürasyon Yönetim Planlama faaliyetlerinin bir çıktısı olarak proje takvimi ve ürün olgunluğu göz önüne alınarak netleştirilir. Maliyet etkin bir TVP’nin elde edilebilmesi için düşük ölçekli ilk üretimler tamamlanıp; ürün ve üretim hattının belirli bir olgunluğa ulaşması gerekir. Aksi halde bu olgunluğa ulaşmadan teslim edilen TVP’lerde müşterinin de onaylaması gereken çok sayıda sapma/feragat/değişiklik teklifinin yer alacağı ve olumsuz takvim etkisi yaratacağı değerlendirilmelidir.
 
Ürün Temel Çizgisinin çekildiği dolayısıyla TVP’nin oluşturulduğu aşama Konfigürasyon Yönetim Planlama faaliyetlerinin bir çıktısı olarak proje takvimi ve ürün olgunluğu göz önüne alınarak netleştirilir. Maliyet etkin bir TVP’nin elde edilebilmesi için düşük ölçekli ilk üretimler tamamlanıp; ürün ve üretim hattının belirli bir olgunluğa ulaşması gerekir. Aksi halde bu olgunluğa ulaşmadan teslim edilen TVP’lerde müşterinin de onaylaması gereken çok sayıda sapma/feragat/değişiklik teklifinin yer alacağı ve olumsuz takvim etkisi yaratacağı değerlendirilmelidir.
   −
===3.2.4.2. ÖMÜR DEVRİ KONFİGÜRASYON TEMEL ÇİZGİLERİ===
+
====<big>3.2.4.2. ÖMÜR DEVRİ KONFİGÜRASYON TEMEL ÇİZGİLERİ</big>====
 
Geleneksel konfigürasyon temel çizgilerine ek olarak ömür devrinin farklı safhalarındaki konfigürasyon bilgilerinin sorumluluğunun iç-dış müşteriler arasındaki el değişimi için de temel çizgiler tanımlanabilir. Söz konusu safhaların bitirilme faaliyetini daha kesin hale getirmek ve safha geçişlerindeki yetki ve sorumluluk transferi ile kontrol ihtiyacını sağlam bir zemine oturtabilmek için Ömür Devri Konfigürasyon Temel çizgileri oluşturulabilir.
 
Geleneksel konfigürasyon temel çizgilerine ek olarak ömür devrinin farklı safhalarındaki konfigürasyon bilgilerinin sorumluluğunun iç-dış müşteriler arasındaki el değişimi için de temel çizgiler tanımlanabilir. Söz konusu safhaların bitirilme faaliyetini daha kesin hale getirmek ve safha geçişlerindeki yetki ve sorumluluk transferi ile kontrol ihtiyacını sağlam bir zemine oturtabilmek için Ömür Devri Konfigürasyon Temel çizgileri oluşturulabilir.
   833. satır: 833. satır:  
Arayüz gereksinimleri, birbiri ile fiziksel ve/veya işlevsel arayüze sahip herhangi bir ürüne yapılacak değişikliklerin değerlendirilmesinde göz önünde bulundurulması gereken kısıtlamalar getirmelidir.
 
Arayüz gereksinimleri, birbiri ile fiziksel ve/veya işlevsel arayüze sahip herhangi bir ürüne yapılacak değişikliklerin değerlendirilmesinde göz önünde bulundurulması gereken kısıtlamalar getirmelidir.
   −
===3.2.5.1. BİRLİKTE ÇALIŞABİLİRLİK KONFİGÜRASYON YÖNETİM GEREKSİNİMLERİ===
+
====<big>3.2.5.1. BİRLİKTE ÇALIŞABİLİRLİK KONFİGÜRASYON YÖNETİM GEREKSİNİMLERİ</big>====
 
Birlikte çalışabilme öncelikle Konfigürasyon Yönetimi bilgilerinin aktarımının garanti altına alınmasını şart koşarak bu bilgilerin tüm paydaşlar tarafından anlaşılabilir ve aktarılabilir olmasını gerektirir. Konfigürasyon Yönetimi bilgilerinin kontrol edilebilir ve kullanılabilir olmasını sağlayabilmek için tüm bu bilgilerin uygun şekilde tanımlanmış (kimliklendirilmiş), birbiri ile uyumlu, yetki kontrollü, tamamlanmış ve kullanıcı imkanları ile okunabilir, görülebilir, işlem görebilir olması gerekir.
 
Birlikte çalışabilme öncelikle Konfigürasyon Yönetimi bilgilerinin aktarımının garanti altına alınmasını şart koşarak bu bilgilerin tüm paydaşlar tarafından anlaşılabilir ve aktarılabilir olmasını gerektirir. Konfigürasyon Yönetimi bilgilerinin kontrol edilebilir ve kullanılabilir olmasını sağlayabilmek için tüm bu bilgilerin uygun şekilde tanımlanmış (kimliklendirilmiş), birbiri ile uyumlu, yetki kontrollü, tamamlanmış ve kullanıcı imkanları ile okunabilir, görülebilir, işlem görebilir olması gerekir.
   888. satır: 888. satır:  
Mühendislik Değişiklik Teklifi (MDT), değişiklik yönetimi adımlarının tamamında ancak ihtiyaca göre farklı detay seviye bilgiler içererek yer alır. MDT’lerin hazırlanması için aşağıdaki işlemler yapılır:
 
Mühendislik Değişiklik Teklifi (MDT), değişiklik yönetimi adımlarının tamamında ancak ihtiyaca göre farklı detay seviye bilgiler içererek yer alır. MDT’lerin hazırlanması için aşağıdaki işlemler yapılır:
   −
===3.3.1.1. DEĞİŞİKLİĞİN GERÇEKLEŞTİRİLMESİ (MEŞRU KILINMASI)===
+
====<big>3.3.1.1. DEĞİŞİKLİĞİN GERÇEKLEŞTİRİLMESİ (MEŞRU KILINMASI)</big>====
 
Konfigürasyon değişiklik yönetimi faaliyetleri, efor ve maliyet içeren birçok iş adımı içermektedir. Yapılması önerilen değişikliklerin tüm paydaşlar için en fazla faydayı sağladığından emin olmak için herhangi bir işlem yapılmadan önce, olası etkilerin analiz edilerek pozitif değer katmayacak değişiklik/sapma isteklerinin sistematik olarak elenmesi ve kurum hafızasına alınması gereklidir.
 
Konfigürasyon değişiklik yönetimi faaliyetleri, efor ve maliyet içeren birçok iş adımı içermektedir. Yapılması önerilen değişikliklerin tüm paydaşlar için en fazla faydayı sağladığından emin olmak için herhangi bir işlem yapılmadan önce, olası etkilerin analiz edilerek pozitif değer katmayacak değişiklik/sapma isteklerinin sistematik olarak elenmesi ve kurum hafızasına alınması gereklidir.
   −
===3.3.1.2. DEĞİŞİKLİĞİN NUMARALANDIRILMASI (KİMLİKLENDİRİLMESİ)===
+
====<big>3.3.1.2. DEĞİŞİKLİĞİN NUMARALANDIRILMASI (KİMLİKLENDİRİLMESİ)</big>====
 
Meşru bir değişiklik ihtiyacı belirlendikten sonra değişiklik teklifine tekil (eşsiz) bir numara (kimlik) atanır. Bu numara sadece değişiklik isteklerini birbirlerinden ayırmaya değil takip eden tüm bildirim, değerlendirme ve icra işlemlerinde referans alınacak numara görevini de görür. Bu numaraya ek olarak değişikliği özetleyen kısa bir başlık verilmesi tasnif ve değerlendirme faaliyetlerinde kolaylık sağlar.
 
Meşru bir değişiklik ihtiyacı belirlendikten sonra değişiklik teklifine tekil (eşsiz) bir numara (kimlik) atanır. Bu numara sadece değişiklik isteklerini birbirlerinden ayırmaya değil takip eden tüm bildirim, değerlendirme ve icra işlemlerinde referans alınacak numara görevini de görür. Bu numaraya ek olarak değişikliği özetleyen kısa bir başlık verilmesi tasnif ve değerlendirme faaliyetlerinde kolaylık sağlar.
   −
===3.3.1.3. DEĞİŞİKLİĞİN SINIFLANDIRILMASI===
+
====<big>3.3.1.3. DEĞİŞİKLİĞİN SINIFLANDIRILMASI</big>====
 
Değişiklik sınıflandırması değişikliğin etki derecesinin sınıflandırılmasını sağlar. Bu sayede değişiklik teklifi uygun değişiklik onay makamına yönlendirilir. Değişiklik etki sınıfları en temel anlamda “büyük” ve “küçük” (geleneksel olarak Sınıf 1, Sınıf 2) olarak nitelenebileceği gibi onay makamının tipine ve etki çeşitliliğine göre daha fazla sınıf da belirlenebilir. Bu tür bir belirlemede karmaşıklığa engel olmak için çok fazla bölünmelere gidilmemelidir.
 
Değişiklik sınıflandırması değişikliğin etki derecesinin sınıflandırılmasını sağlar. Bu sayede değişiklik teklifi uygun değişiklik onay makamına yönlendirilir. Değişiklik etki sınıfları en temel anlamda “büyük” ve “küçük” (geleneksel olarak Sınıf 1, Sınıf 2) olarak nitelenebileceği gibi onay makamının tipine ve etki çeşitliliğine göre daha fazla sınıf da belirlenebilir. Bu tür bir belirlemede karmaşıklığa engel olmak için çok fazla bölünmelere gidilmemelidir.
   944. satır: 944. satır:  
|}
 
|}
   −
===3.3.1.4. DEĞİŞİKLİĞİN BELGELENDİRİLMESİ===
+
====<big>3.3.1.4. DEĞİŞİKLİĞİN BELGELENDİRİLMESİ</big>====
 
Değişiklik veya sapma isteklerinin etkin bir değerlendirilmeye tabi olabilmeleri için anlaşılır, özlü ve geçerli bilgiler içerecek şekilde hazırlanması gerekir. Takvim ve maliyet etkileri olası alternatif çözümler ile müşteri/ihtiyaç makamı talebine göre gereken detayda verilir.
 
Değişiklik veya sapma isteklerinin etkin bir değerlendirilmeye tabi olabilmeleri için anlaşılır, özlü ve geçerli bilgiler içerecek şekilde hazırlanması gerekir. Takvim ve maliyet etkileri olası alternatif çözümler ile müşteri/ihtiyaç makamı talebine göre gereken detayda verilir.
  
2.239

değişiklik