V-Modeli - V-Model

Yazılım geliştirmeye özgü sürüm için bkz. V-Modeli (yazılım geliştirme).
Sistem mühendisliği sürecinin V modeli.[1]
Yazılım geliştirme
Çekirdek aktiviteleri
Paradigmalar ve modeller
Metodolojiler ve çerçeveler
Destekleyen disiplinler
Uygulamalar
Araçlar
Standartlar ve Bilgi Yapıları
Sözlükler
Anahatlar

V modeli bir grafik temsilidir sistem geliştirme yaşam döngüsü. Titiz geliştirme yaşam döngüsü modelleri ve proje yönetimi modelleri üretmek için kullanılır. V-modeli üç geniş kategoriye ayrılır, Alman V-Modell, genel bir test modeli ve ABD hükümet standardı.[2]

V-modeli, içinde karşılık gelen çıktılarla birlikte atılması gereken ana adımları özetler. bilgisayarlı sistem doğrulama çerçeve veya proje yaşam döngüsü geliştirme. Ürün geliştirme sırasında gerçekleştirilecek faaliyetleri ve üretilmesi gereken sonuçları açıklar.

"V" nin sol tarafı, gereksinimlerin ayrıştırılmasını ve sistem özelliklerinin oluşturulmasını temsil eder. "V" nin sağ tarafı, parçaların entegrasyonunu ve bunların doğrulanmasını temsil eder.[3][4][5][6][7] Bununla birlikte, gereksinimlerin önce daha yüksek seviye gereksinimlere veya kullanıcı ihtiyaçlarına göre doğrulanması gerekir. Ayrıca, sistem modellerinin doğrulanması gibi bir şey de vardır (örneğin, FEM). Bu kısmen sol tarafta da yapılabilir. Doğrulamanın yalnızca sağ tarafta gerçekleştiğini iddia etmek doğru olmayabilir. En kolay yol, doğrulamanın her zaman gereksinimlere (teknik şartlara) ve doğrulamanın her zaman gerçek dünyaya veya kullanıcı ihtiyaçlarına aykırı olduğunu söylemektir. Havacılık ve uzay standardı RTCA DO-178B, gereksinimlerin doğrulandığını - doğru olduğu onaylandığını - ve son ürünün bu gereksinimleri karşıladığından emin olmak için doğrulandığını belirtir.

Doğrulama, "Doğru şeyi mi inşa ediyorsunuz?" Sorgusuyla ifade edilebilir. ve "Doğru oluşturuyor musunuz?" ile doğrulama

Türler

Üç genel V modeli vardır.

V-Modell

Alman hükümetinin resmi proje yönetimi yöntemi olan Alman V-Modeli "V-Modell". Kabaca eşdeğerdir PRINCE2, ancak yazılım geliştirmeyle daha doğrudan alakalı.[8] Bir "V" temsilini kullanmanın temel özelliği, V'nin sol tarafındaki ürünlerin, V'nin sağ tarafını uygulayan uygun test ve entegrasyon kuruluşu tarafından kabul edilebilir olduğuna dair kanıt istemekti.[9][10][11]

Genel test

Dünya çapındaki test topluluğu boyunca, V modeli, yaygın olarak, yazılım geliştirme sürecinin muğlak açıklayıcı bir tasviri olarak görülüyor. Uluslararası Yazılım Test Yeterlilikler Kurulu Yazılım test ediciler için Temel Ders Programı.[12] Bu modelin tek bir tanımı yoktur ve bu, alternatif makalede daha doğrudan ele alınmaktadır. V-Modeli (yazılım geliştirme).

ABD hükümeti standardı

ABD ayrıca, Alman muadili gibi yaklaşık 20 yıl öncesine dayanan hükümet standardı bir V modeline sahiptir. Kapsamı daha dar bir sistem geliştirme yaşam döngüsü modelidir, ancak Birleşik Krallık'taki çoğu uygulayıcı ve test uzmanının V modelinin anlayacağından çok daha ayrıntılı ve daha titizdir.[13][14][3][4][15][16]

Doğrulama ve doğrulama

Ana makaleler: Doğrulama ve onaylama ve Doğrulama (ilaç üretimi)

Bazen doğrulamanın "Doğru şeyi mi inşa ediyorsun?" Sorgusuyla ifade edilebileceği söylenir. ve "Doğru inşa ediyor musunuz?" ile doğrulama Uygulamada, bu terimlerin kullanımı değişiklik gösterir.

PMBOK kılavuzu tarafından da benimsenmiştir IEEE standart olarak (INCOSE, Sistem mühendisliği Araştırma Konseyi SERC ve IEEE Bilgisayar Topluluğu tarafından ortaklaşa sürdürülmektedir) bunları 4. baskısında aşağıdaki gibi tanımlamaktadır:[17]

  • "Doğrulama. Bir ürün, hizmet veya sistemin müşterinin ve diğer belirlenen paydaşların ihtiyaçlarını karşıladığının güvencesi. Genellikle dış müşterilerle kabul ve uygunluğu içerir. İle kontrast doğrulama."
  • "Doğrulama. Bir ürünün, hizmetin veya sistemin bir yönetmelik, gereklilik, şartname veya empoze edilen koşula uygun olup olmadığının değerlendirilmesi. Genellikle dahili bir süreçtir. İle kontrast doğrulama."

Hedefler

V-modeli, projelerin planlanması ve gerçekleştirilmesi için rehberlik sağlar. Aşağıdaki hedeflere bir proje yürütme ile ulaşılması amaçlanmıştır:

  • Proje risklerinin en aza indirilmesi: V modeli, standartlaştırılmış yaklaşımları belirleyerek ve ilgili sonuçları ve sorumlu rolleri tanımlayarak proje şeffaflığını ve proje kontrolünü geliştirir. Planlama sapmalarının ve risklerin erken tanınmasına izin verir ve süreç yönetimini iyileştirerek proje riskini azaltır.
  • Kalitenin iyileştirilmesi ve garantisi: Standartlaştırılmış bir süreç modeli olarak V-Modeli, sağlanacak sonuçların eksiksiz ve istenen kalitede olmasını sağlar. Tanımlanan ara sonuçlar erken bir aşamada kontrol edilebilir. Tek tip ürün içerikleri okunabilirliği, anlaşılırlığı ve doğrulanabilirliği artıracaktır.
  • Tüm proje ve sistem yaşam döngüsü boyunca toplam maliyetin azaltılması: Bir sistemin geliştirilmesi, üretimi, işletilmesi ve bakımı için çaba, standartlaştırılmış bir süreç modeli uygulanarak şeffaf bir şekilde hesaplanabilir, tahmin edilebilir ve kontrol edilebilir. Elde edilen sonuçlar tekdüzedir ve kolayca geri çekilebilir. Bu, devralanın tedarikçiye bağımlılığını ve sonraki faaliyetler ve projeler için gösterilen çabayı azaltır.
  • Tüm paydaşlar arasındaki iletişimin iyileştirilmesi: Tüm ilgili unsurların ve terimlerin standartlaştırılmış ve tek tip tanımı, tüm paydaşlar arasındaki karşılıklı anlayışın temelini oluşturur. Böylece kullanıcı, edinen, tedarikçi ve geliştirici arasındaki sürtünme kaybı azaltılır.

V-model konuları

Sistem mühendisliği ve doğrulama.[18]

Sistem mühendisliği ve doğrulama

Sistem mühendisliği süreci (SEP), sistem sahibinin tasarımdan kullanımdan kalkmaya kadar sistemin tüm ömrü boyunca deneyimlediği karmaşık sistemlerin maliyet etkinliğini iyileştirmek için bir yol sağlar.[1]

Hedeflerin erken ve kapsamlı bir şekilde tanımlanmasını, kullanıcı ihtiyaçlarını ve işletim ortamını tanımlayan bir operasyon kavramı, kapsamlı ve test edilebilir sistem gereksinimleri, ayrıntılı tasarım, uygulama, belirtilen gereksinimleri karşıladığından emin olmak için uygulanan sistemin titiz kabul testini (sistem doğrulama ), hedeflere ulaşma (sistem doğrulama), devam eden çalışma ve bakım, zaman içinde sistem yükseltmeleri ve nihayetinde kullanımdan kalkma konusundaki etkinliğini ölçmek.[1][3][4][7]

Süreç, gereksinimlere dayalı tasarım ve testi vurgular. Tüm tasarım öğeleri ve kabul testleri, bir veya daha fazla sistem gereksinimine göre izlenebilir olmalı ve her gereksinime en az bir tasarım öğesi ve kabul testi ile hitap edilmelidir. Böyle bir titizlik, hiçbir şeyin gereksiz yere yapılmamasını ve gerekli olan her şeyin gerçekleştirilmesini sağlar.[1][3]

İki akarsu

Şartname akışı

Spesifikasyon akışı esas olarak şunlardan oluşur:

  • Kullanıcı gereksinimi özellikleri
  • Fonksiyonel gereksinim özellikleri
  • Tasarım özellikleri

Akış testi

Test akışı genellikle şunlardan oluşur:

  • Kurulum yeterliliği (IQ)
  • Operasyonel yeterlilik (OQ)
  • Performans yeterliliği (PQ)

Geliştirme akışı (sistem türüne ve geliştirme kapsamına bağlı olarak) özelleştirme, yapılandırma veya kodlamadan oluşabilir.

Başvurular

Çekirdek Dışı alternatifler (yukarı ve aşağı doğru yinelemeleri ve Zaman ve Olgunluk boyutunu gösterir). Kaynak - K. Forsberg ve H. Mooz 2004[3][7]

V modeli, Alman federal idaresi içindeki yazılım geliştirme sürecini düzenlemek için kullanılır. Bugünlerde, bölgedeki yazılım geliştiricilerinin yanı sıra Alman federal idaresi ve savunma projeleri için hala standarttır.

V modeli kavramı, 1980'lerin sonunda Almanya ve Amerika Birleşik Devletleri'nde eşzamanlı, ancak bağımsız olarak geliştirildi:

  • Alman V modeli, ilk olarak IABG tarafından, Federal Savunma Bakanlığı için Koblenz'deki Federal Savunma Teknolojisi ve Tedarik Ofisi ile işbirliği içinde, Münih yakınlarındaki Ottobrunn'da geliştirildi. Federal İçişleri Bakanlığı tarafından sivil kamu otoriteleri alanı için 1992 yazında devralındı.[19]
  • 1991 tarihli davada belgelendiği gibi ABD V modeli Ulusal Sistem Mühendisliği Konseyi (NCOSE; şimdi INCOSE, 1995 itibariyle),[7] donanım, yazılım ve insan etkileşimini içeren uydu sistemleri için geliştirilmiştir.
  • V modeli ilk olarak Hughes Uçağı FAA Gelişmiş Otomasyon Sistemi (AAS) programı için ön teklif çabasının bir parçası olarak yaklaşık 1982. Sonunda Hughes AAS Tasarım Yarışması Aşaması (DCP) teklifi için test stratejisini oluşturdu. Yazılımdaki gizli kusurları ortaya çıkarmak için yeni zorlukların yol açtığı test ve entegrasyon yaklaşımını göstermek için oluşturuldu. Bu yeni gizli kusur tespiti düzeyine duyulan ihtiyaç, otomatikleştirilmiş hava trafik kontrol (AERA) programı tarafından öngörüldüğü gibi hava trafik kontrolörünün düşünme ve planlama süreçlerini otomatikleştirmeye başlama hedefi tarafından yönlendirildi. V'nin bu kadar güçlü olmasının nedeni, tüm metni ve analizi çok boyutlu görüntülere bağlama Hughes kültüründen kaynaklanıyor. Sıralı Tematik Yayın Organizasyonu'nun (STOP) temeliydi [20] Hughes tarafından 1963'te yaratıldı ve Hughes, Howard Hughes Tıp Enstitüsü 1985'te.[21]
  • ABD Savunma Bakanlığı, sistem Mühendisi etkileşimleri bir V modeli ilişkisine dönüştürür.[22]

Artık hem ticari hem de savunma programlarında yaygın uygulama bulmuştur. Birincil kullanımı proje yönetimindedir[3][4] ve proje yaşam döngüsü boyunca.

ABD V modelinin temel özelliklerinden biri, zaman ve olgunluğun soldan sağa doğru hareket etmesi ve kişinin zamanda geriye gidememesidir. Tüm yineleme, şekilde gösterildiği gibi, sistem hiyerarşisindeki daha yüksek veya daha düşük seviyelere dikey bir çizgi boyunca yapılır.[3][4][7] Bunun, modelin önemli bir yönü olduğu kanıtlanmıştır. Modelin dual-Vee konseptine genişletilmesi referans olarak ele alınmıştır.[3]

V modeli halka açık olduğundan birçok şirket de bunu kullanıyor. Proje yönetiminde karşılaştırılabilir bir yöntemdir. PRINCE2 ve proje yönetimi yöntemlerinin yanı sıra sistem Geliştirme. V-Modeli, süreçte katı olmasına rağmen, özellikle Sistem Geliştirme Yaşam Döngüsü normal parametrelerinin alanı dışındaki kapsamla ilgili olduğu için uygulamada çok esnek olabilir.

Avantajlar

V modelinin diğer sistem geliştirme modellerinin önünde sunduğu avantajlar şunlardır:

  • V modelinin kullanıcıları, V modelinin geliştirilmesine ve bakımına katılır. Bir değişiklik kontrol panosu, V-Modelini kamuya açık olarak korur. Değişiklik kontrol panosu, her günden haftaya kadar her yerde toplanır ve sistem geliştirme ve test sırasında alınan tüm değişiklik taleplerini işler.[23]
  • V modeli, bir faaliyetin nasıl uygulanacağına ve iş adımlarına dair somut yardım sağlar ve bir iş adımını tamamlamak için gereken olayları açık bir şekilde tanımlar: her bir faaliyet şeması, faaliyetin talimatlarını, tavsiyelerini ve ayrıntılı açıklamalarını içerir.[24]

Limitler

Aşağıdaki hususlar V modeli tarafından kapsanmamaktadır, ek olarak düzenlenmelidir veya V Modeli buna göre uyarlanmalıdır:[25][26]

  • Hizmetler için sözleşmelerin yapılması düzenlenmemiştir.
  • Sistemin işletilmesi, bakımı, onarımı ve bertarafının organizasyonu ve icrası V modeli kapsamında değildir. Ancak, bu görevler için bir konseptin planlanması ve hazırlanması V modelinde düzenlenmiştir.
  • V-modeli, bütün bir organizasyon yerine bir proje içindeki yazılım geliştirmeyi ele alır.

Ayrıca bakınız

Referanslar

  1. ^ a b c d Clarus Operasyon Konsepti Arşivlendi 2009-07-05 de Wayback Makinesi, Yayın No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005.
  2. ^ "Tehlikeli ve Baştan Çıkarıcı V Modeli", 9 Ocak 2013'te erişildi.
  3. ^ a b c d e f g h Forsberg, K., Mooz, H., Cotterman, H. Proje Yönetiminin Görselleştirilmesi, 3. baskı, John Wiley and Sons, New York, NY, 2005. Sayfalar 108-116, 242-248, 341-360.
  4. ^ a b c d e Uluslararası Sistem Mühendisliği Konseyi (INCOSE), Sistem Mühendisliği El Kitabı Sürüm 3.1, Ağustos 2007, sayfalar 3.3 - 3.8
  5. ^ Forsberg, K., Mooz, H. (1998). "Daha Hızlı, Daha Ucuz, Daha İyi Sistem Mühendisliği" (PDF). Sistem Yönetimi Merkezi. Arşivlenen orijinal (PDF) 20 Nisan 2003. Alıntı dergisi gerektirir | günlük = (Yardım)CS1 bakım: birden çok isim: yazar listesi (bağlantı)
  6. ^ "SE VEE". SEOR, George Mason Üniversitesi. Arşivlenen orijinal 18 Ekim 2007. Alındı 26 Mayıs 2007.
  7. ^ a b c d e Forsberg, K. ve Mooz, H., "Sistem Mühendisliğinin Proje Döngüsü ile İlişkisi" Arşivlendi 2009-02-27 de Wayback Makinesi Ulusal Sistem Mühendisliği Konseyi (NCOSE) Birinci Yıllık Sempozyumu, Ekim 1991
  8. ^ "V-Modell sitesi (Almanca)", 10 Temmuz 2020'de erişildi.
  9. ^ Alman Direktifi 250, Alman Federal Silahlı Kuvvetleri için Yazılım Geliştirme Standardı, V-Modeli, Yazılım Yaşam Döngüsü Süreci Modeli, Ağustos 1992
  10. ^ "V-Modell'in Temelleri". Alındı 14 Nisan 2016.
  11. ^ "V-Modell XT, Bölüm 1: V-Modell'in Temelleri" (PDF). Alındı 14 Nisan 2016.
  12. ^ "Uluslararası Yazılım Test Yeterlilikler Kurulu - Temel Düzey Ders Programı", 9 Ocak 2013'te erişildi.
  13. ^ "Akıllı Ulaşım Sistemleri için Sistem Mühendisliği" (PDF). ABD Ulaştırma Bakanlığı. s. 10. Alındı 9 Haziran 2007.
  14. ^ "ABD Ulaştırma Bakanlığı, Federal Karayolu İdaresi. ITS için Sistem Mühendisliği Kılavuzu", 9 Ocak 2013'te erişildi.
  15. ^ "BİR MİRAS ÜZERİNE İNŞA ETMEK: SAVUNMA EDİNMESİNDE SİSTEM MÜHENDİSLİĞİ ÜZERİNE YENİLENEN ODAK" (PDF). Alındı 14 Nisan 2016.
  16. ^ "Test için V Modellerini Kullanma". Alındı 14 Nisan 2016.
  17. ^ IEEE. IEEE Kılavuzu - Proje Yönetim Enstitüsü (PMI) Standardının Kabulü Proje Yönetimi Bilgi Yapıları İçin Bir Kılavuz (PMBOK Kılavuzu) - Dördüncü Baskı. s. 452. doi:10.1109 / IEEESTD.2011.6086685. ISBN  978-0-7381-6817-3. Alındı 7 Aralık 2012.
  18. ^ Sistem Mühendisliği Temelleri. Defence Acquisition University Press, 2001.
  19. ^ "V Modeli Yaşam Döngüsü Süreci Modeli". v-modell.iabg.de. Arşivlenen orijinal Mart 3, 2016. Alındı 24 Aralık 2015.
  20. ^ "Yayınların Sıralı Tematik Organizasyonu (STOP)". Arşivlenen orijinal 3 Şubat 2008. Alındı 24 Aralık 2015.
  21. ^ Sobkiw Walter (2008/01/01). Yaratıcı Sistem Mühendisliği ile Sürdürülebilir Kalkınma Mümkün. ISBN  978-0615216300.
  22. ^ "Yeni Bir Sistem Mühendisliği Modeli ve Eski, Tanıdık Bir Arkadaş; Şekil 2 V-9 Süreç Etkileşimleri" (PDF). Savunma AT&L. Nisan 2006. s. 51. Alındı 7 Nisan 2016.
  23. ^ "V-Modell'in Daha Fazla Geliştirilmesi (bozuk bağlantı)". v-modell.iabg.de. Arşivlenen orijinal 23 Nisan 2011. Alındı 24 Aralık 2015.
  24. ^ "V-Modell'in Etkinlik Modeline Genel Bakış (bozuk bağlantı)". v-modell.iabg.de. Arşivlenen orijinal 19 Temmuz 2011. Alındı 24 Aralık 2015.
  25. ^ "VModel'in sınırları". v-modell.iabg.de. Arşivlenen orijinal 21 Mayıs 2011. Alındı 24 Aralık 2015.
  26. ^ Christian Bucanac, V-Modeli

Dış bağlantılar