1. Başlangıç verileri
Veri temizleme, veri analizi görevlerinin karşılaştığı zorluklardan biridir. Bu materyal, kadastral değerin oluşumunda veri tabanının analizine ilişkin pratik bir problemin çözülmesi sonucunda ortaya çıkan gelişmeleri ve çözümleri yansıtmaktadır. Buradaki kaynaklar .
“Ek B. KS belirleme sonuçları 5. Kadastral değer belirleme yöntemine ilişkin bilgiler 5.1 Karşılaştırmalı yaklaşım” bölümündeki “Karşılaştırmalı model total.ods” dosyası dikkate alınmıştır.
Tablo 1. “Karşılaştırmalı model total.ods” dosyasındaki veri setinin istatistiksel göstergeleri
Toplam alan sayısı, adet. — 44
Toplam kayıt sayısı, adet. — 365 490
Toplam karakter sayısı, adet. — 101 714 693
Bir kayıttaki ortalama karakter sayısı, adet. — 278,297
Bir kayıttaki karakterlerin standart sapması, adet. — 15,510
Bir girişteki minimum karakter sayısı, adet. — 198
Bir girişteki maksimum karakter sayısı, adet. — 363
2. Giriş kısmı. Temel standartlar
Belirtilen veri tabanını analiz ederken, herkes için açık olduğu gibi, belirtilen veri tabanı kullanıcılar için hukuki ve ekonomik sonuçlar yarattığından, saflaştırma derecesinin gerekliliklerini belirlemek için bir görev oluşturulmuştur. Çalışma sırasında büyük verilerin temizlenme derecesi için özel bir gerekliliğin olmadığı ortaya çıktı. Bu konudaki hukuki normları incelediğimde hepsinin olasılıklardan oluştuğu sonucuna vardım. Yani, belirli bir görev ortaya çıktı, görev için bilgi kaynakları derlendi, ardından bir veri seti oluşturuldu ve oluşturulan veri setine göre sorunu çözmek için araçlar oluşturuldu. Ortaya çıkan çözümler, alternatifler arasından seçim yaparken referans noktalarıdır. Bunu Şekil 1'de gösterdim.
Herhangi bir standart belirleme konusunda kanıtlanmış teknolojilere güvenmek tercih edildiğinden, belirtilen gereksinimleri seçtim. Çünkü bu belgenin bu konu için en kapsamlı belge olduğunu düşünüyorum. Bu belgede özellikle, "Veri bütünlüğü gerekliliklerinin manuel (kağıt) ve elektronik veriler için eşit şekilde geçerli olduğu unutulmamalıdır" bölümü belirtilmektedir. (çeviri: “...veri bütünlüğü gereklilikleri manuel (kağıt) ve elektronik veriler için eşit derecede geçerlidir”). Bu formülasyon, Hukuk Muhakemeleri Kanunu'nun 71. Maddesi hükümlerinde oldukça spesifik olarak “yazılı delil” kavramıyla ilişkilendirilmektedir. 70 CAS, Madde 75 APC, “yazılı olarak” Madde. 84 Hukuk Muhakemeleri Kanunu.
Şekil 2, hukuk biliminde bilgi türlerine yönelik yaklaşımların oluşumunun bir diyagramını sunmaktadır.
Pirinç. 2. Kaynak .
Şekil 3, yukarıdaki “Rehberliğin” görevleri için Şekil 1'deki mekanizmayı göstermektedir. Modern bilgi sistemleri standartlarında bilgi bütünlüğü gerekliliklerini yerine getirirken kullanılan yaklaşımların, hukuki bilgi kavramına göre oldukça sınırlı olduğunu bir karşılaştırma yaparak görmek kolaydır.
Ris.3
Belirtilen belgede (Kılavuz), teknik bölüme bağlantı, veri işleme ve depolama yetenekleri Bölüm 18.2'den bir alıntıyla iyice doğrulanmıştır. İlişkisel veritabanı: "Veriler, veriler ve meta veriler arasındaki ilişkiyi koruyan büyük bir dosya biçiminde tutulduğundan, bu dosya yapısı doğası gereği daha güvenlidir."
Aslında, bu yaklaşımda, mevcut teknik yeteneklerden anormal hiçbir şey yoktur ve kendi içinde bu doğal bir süreçtir, çünkü kavramların genişletilmesi en çok çalışılan faaliyet olan veritabanı tasarımından gelir. Ancak öte yandan, mevcut sistemlerin teknik yeteneklerinde indirim sağlamayan yasal normlar da ortaya çıkıyor, örneğin: .
Pirinç. 4. Teknik yetenek hunisi ().
Bu yönlerden, orijinal veri kümesinin (Şekil 1) her şeyden önce kaydedilmesi ve ikinci olarak ondan ek bilgilerin çıkarılması için temel oluşturması gerektiği açıkça ortaya çıkıyor. Örnek olarak: trafik kurallarını kaydeden kameralar her yerde bulunur, bilgi işlem sistemleri ihlal edenleri ayıklar, ancak diğer tüketicilere, örneğin bir alışveriş merkezine müşteri akışının yapısının pazarlama takibi olarak başka bilgiler de sunulabilir. Bu da BigDat kullanıldığında ek bir katma değer kaynağıdır. Gelecekte bir yerde, şimdi toplanan veri setlerinin, günümüzde 1700'lü nadir basımların değerine benzer bir mekanizmaya göre değere sahip olması oldukça muhtemeldir. Sonuçta geçici veri kümeleri benzersizdir ve gelecekte tekrarlanması pek mümkün değildir.
3. Giriş kısmı. Değerlendirme kriterleri
İşleme sürecinde aşağıdaki hata sınıflandırması geliştirildi.
1. Hata sınıfı (GOST R 8.736-2011'e göre): a) sistematik hatalar; b) rastgele hatalar; c) bir hata.
2. Çokluğa göre: a) mono bozulma; b) çoklu distorsiyon.
3. Sonuçların kritikliğine göre: a) kritik; b) kritik değil.
4. Oluşum kaynağına göre:
A) Teknik – ekipmanın çalışması sırasında meydana gelen hatalar. IoT sistemleri, iletişim kalitesi, ekipman (donanım) üzerinde önemli derecede etkisi olan sistemler için oldukça alakalı bir hata.
B) Operatör hataları - giriş sırasındaki operatör yazım hatalarından veri tabanı tasarımına yönelik teknik özelliklerdeki hatalara kadar geniş bir yelpazedeki hatalar.
C) Kullanıcı hataları - burada "düzeni değiştirmeyi unuttum"dan metreleri ayaklarla karıştırmaya kadar tüm aralıktaki kullanıcı hataları yer almaktadır.
5. Ayrı bir sınıfa ayrılmıştır:
a) “ayırıcının görevi”, yani kopyalandığında boşluk ve “:” (bizim durumumuzda);
b) birlikte yazılan kelimeler;
c) servis karakterlerinden sonra boşluk yok
d) simetrik olarak birden fazla sembol: (), "", "...".
Şekil 5'te sunulan veri tabanı hatalarının sistemleştirilmesiyle birlikte ele alındığında, bu örnek için hataların aranması ve veri temizleme algoritmasının geliştirilmesi için oldukça etkili bir koordinat sistemi oluşturulmuştur.
Pirinç. 5. Veritabanının yapısal birimlerine karşılık gelen tipik hatalar (Kaynak: ).
Doğruluk, Alan Adı Bütünlüğü, Veri Türü, Tutarlılık, Artıklık, Tamlık, Çoğaltma, İş Kurallarına Uygunluk, Yapısal Belirlilik, Veri Anomalisi, Açıklık, Zamanındalık, Veri Bütünlüğü Kurallarına Uyum. (Sayfa 334. BT uzmanları için veri ambarı temelleri / Paulraj Ponniah.—2. baskı.)
İngilizce ifadeler ve Rusça makine çevirisi parantez içinde sunulmuştur.
Kesinlik. Bir veri öğesi için sistemde saklanan değer, veri öğesinin o oluşumu için doğru değerdir. Bir kayıtta kayıtlı bir müşteri adınız ve adresiniz varsa bu adres, o isimdeki müşteri için doğru adrestir. 1000 numaralı sipariş kaydında sipariş edilen miktarı 12345678 adet olarak buluyorsanız bu miktar o sipariş için doğru miktardır.
[Kesinlik. Bir veri öğesi için sistemde saklanan değer, veri öğesinin o oluşumu için doğru değerdir. Bir kayıtta kayıtlı bir müşteri adınız ve adresiniz varsa bu adres, o ada sahip müşteri için doğru adrestir. 1000 numaralı sipariş kaydında sipariş edilen miktarı 12345678 adet olarak görüyorsanız bu miktar o siparişin tam miktarıdır.]
Etki Alanı Bütünlüğü. Bir özelliğin veri değeri, izin verilen, tanımlanmış değerler aralığına girer. Yaygın örnek, cinsiyet verisi öğesi için izin verilen değerlerin "erkek" ve "kadın" olmasıdır.
[Etki Alanı Bütünlüğü. Öznitelik veri değeri, geçerli, tanımlanmış değerler aralığı içindedir. Genel bir örnek, cinsiyet veri öğesi için geçerli "erkek" ve "kadın" değerleridir.]
Veri tipi. Bir veri niteliğinin değeri aslında o nitelik için tanımlanan veri türü olarak depolanır. Mağaza adı alanının veri türü "metin" olarak tanımlandığında, bu alanın tüm örnekleri, sayısal kodlar yerine metin biçiminde gösterilen mağaza adını içerir.
[Veri tipi. Bir veri niteliğinin değeri aslında o nitelik için tanımlanan veri türü olarak depolanır. Mağaza adı alanı veri türü "metin" olarak tanımlanmışsa bu alanın tüm örnekleri, sayısal kodlar yerine metin biçiminde görüntülenen mağaza adını içerir.]
Tutarlılık. Bir veri alanının biçimi ve içeriği birden fazla kaynak sistemde aynıdır. Bir sistemde ABC ürününün ürün kodu 1234 ise bu ürünün kodu her kaynak sistemde 1234'tür.
[Tutarlılık. Veri alanının biçimi ve içeriği farklı kaynak sistemlerde aynıdır. Bir sistemdeki ABC ürününün ürün kodu 1234 ise her kaynak sistemde o ürünün kodu 1234 olur.]
Fazlalık. Bir sistemde aynı veriler birden fazla yerde saklanmamalıdır. Verimlilik nedeniyle bir veri öğesinin bir sistemde birden fazla yerde kasıtlı olarak saklanması durumunda, fazlalık açıkça tanımlanmalı ve doğrulanmalıdır.
[Artıklık. Aynı veriler sistemde birden fazla yerde saklanmamalıdır. Verimlilik nedeniyle, bir veri öğesi kasıtlı olarak bir sistemdeki birden fazla yerde depolanıyorsa, artıklık açıkça tanımlanmalı ve doğrulanmalıdır.]
Tamlık. Sistemde belirli bir nitelik için eksik değer yoktur. Örneğin bir müşteri dosyasında “durum” alanında her müşteri için geçerli bir değer bulunmalıdır. Sipariş detay dosyasında, siparişe ait her detay kaydının eksiksiz olarak doldurulması gerekmektedir.
[Bütünlük. Bu özelliğe ait sistemde eksik değer bulunmamaktadır. Örneğin, istemci dosyasının her istemci için "durum" alanı için geçerli bir değere sahip olması gerekir. Sipariş detay dosyasında her sipariş detay kaydının eksiksiz olarak tamamlanması gerekmektedir.]
Çoğaltma. Bir sistemdeki kayıtların kopyalanması tamamen çözümlenmiştir. Ürün dosyasında mükerrer kayıtların olduğu biliniyorsa, her bir ürün için tüm mükerrer kayıtlar tanımlanır ve bir çapraz referans oluşturulur.
[Kopyalamak. Sistemdeki kayıtların kopyalanması tamamen ortadan kaldırılmıştır. Bir ürün dosyasının mükerrer girişler içerdiği biliniyorsa, her ürün için tüm mükerrer girişler tanımlanır ve bir çapraz referans oluşturulur.]
İş Kurallarına Uygunluk. Her veri öğesinin değerleri, önceden belirlenmiş iş kurallarına uygundur. Açık artırma sisteminde çekicin veya satış fiyatı, rezerv fiyatından düşük olamaz. Bir banka kredi sisteminde kredi bakiyesinin her zaman pozitif veya sıfır olması gerekir.
[İş kurallarına uygunluk. Her veri öğesinin değerleri, belirlenmiş iş kurallarına uygundur. Açık artırma sisteminde çekicin veya satış fiyatı, rezerv fiyatından düşük olamaz. Bir bankacılık kredi sisteminde kredi bakiyesi her zaman pozitif veya sıfır olmalıdır.]
Yapısal Kesinlik. Bir veri öğesinin doğal olarak bireysel bileşenler halinde yapılandırılabildiği her yerde, öğenin bu iyi tanımlanmış yapıyı içermesi gerekir. Örneğin, bir kişinin adı doğal olarak adı, ikinci adı ve soyadı olarak bölünür. Kişi adlarına ilişkin değerler ad, ikinci adın baş harfi ve soyadı olarak saklanmalıdır. Veri kalitesinin bu özelliği standartların uygulanmasını basitleştirir ve eksik değerleri azaltır.
[Yapısal Kesinlik. Bir veri öğesinin doğal olarak bireysel bileşenler halinde yapılandırılabildiği durumlarda, öğenin bu iyi tanımlanmış yapıyı içermesi gerekir. Örneğin, bir kişinin adı doğal olarak adı, ikinci adı ve soyadı olarak bölünür. Bireysel adlara ilişkin değerler, ad, ikinci adın baş harfi ve soyadı olarak saklanmalıdır. Bu veri kalitesi özelliği standartların uygulanmasını basitleştirir ve eksik değerleri azaltır.]
Veri Anomalisi. Bir alan yalnızca tanımlandığı amaç için kullanılmalıdır. Uzun adreslerde olası üçüncü adres satırı için Adres-3 alanı tanımlanmışsa bu alan yalnızca üçüncü satır adresin kaydedilmesi için kullanılmalıdır. Müşterinin telefon veya faks numarasını girmek için kullanılmamalıdır.
[Veri Anomalisi. Bir alan yalnızca tanımlandığı amaç için kullanılmalıdır. Uzun adreslerde olası üçüncü adres satırı için Adres-3 alanı tanımlanmışsa bu alan yalnızca üçüncü adres satırını kaydetmek için kullanılacaktır. Müşterinin telefon veya faks numarasını girmek için kullanılmamalıdır.]
Açıklık. Bir veri öğesi, kaliteli verinin diğer tüm özelliklerine sahip olabilir ancak kullanıcılar bunun anlamını net bir şekilde anlamazsa veri öğesinin kullanıcılar için hiçbir değeri yoktur. Uygun adlandırma kuralları, veri öğelerinin kullanıcılar tarafından iyi anlaşılmasına yardımcı olur.
[Açıklık. Bir veri öğesi, iyi bir verinin diğer tüm özelliklerine sahip olabilir, ancak kullanıcılar bunun anlamını net bir şekilde anlamıyorsa, o zaman veri öğesinin kullanıcılar için hiçbir değeri yoktur. Doğru adlandırma kuralları, veri öğelerinin kullanıcılar tarafından iyi anlaşılmasına yardımcı olur.]
Zamanında. Verilerin güncelliğini kullanıcılar belirler. Kullanıcılar, müşteri boyutu verilerinin bir günden daha eski olmamasını bekliyorlarsa, kaynak sistemlerdeki müşteri verilerinde yapılan değişikliklerin günlük olarak veri ambarına uygulanması gerekir.
[Zamanında. Kullanıcılar verilerin güncelliğini belirler. Kullanıcılar müşteri boyutu verilerinin bir günden daha eski olmamasını bekliyorsa kaynak sistemlerdeki müşteri verilerinde yapılan değişikliklerin veri ambarına günlük olarak uygulanması gerekir.]
Kullanışlılık. Veri ambarındaki her veri öğesi, kullanıcı topluluğunun bazı gereksinimlerini karşılamalıdır. Bir veri öğesi doğru ve kaliteli olabilir, ancak kullanıcılar için hiçbir değeri yoksa o veri öğesinin veri ambarında bulunması tamamen gereksizdir.
[Yarar. Veri deposundaki her veri öğesi, kullanıcı koleksiyonunun bazı gereksinimlerini karşılamalıdır. Bir veri öğesi doğru ve kaliteli olabilir ancak kullanıcılara değer sağlamıyorsa o veri öğesinin veri ambarında bulunmasına gerek yoktur.]
Veri Bütünlüğü Kurallarına Uyum. Kaynak sistemlerin ilişkisel veritabanlarında saklanan veriler, varlık bütünlüğü ve referans bütünlüğü kurallarına uygun olmalıdır. Birincil anahtar olarak null değerine izin veren herhangi bir tablonun varlık bütünlüğü yoktur. Referans bütünlüğü ebeveyn-çocuk ilişkilerinin doğru kurulmasını zorlar. Müşteri-sipariş ilişkisinde referans bütünlüğü, veritabanındaki her sipariş için bir müşterinin varlığını garanti eder.
[Veri bütünlüğü kurallarına uygunluk. Kaynak sistemlerin ilişkisel veritabanlarında saklanan veriler, varlık bütünlüğü ve referans bütünlüğü kurallarına uygun olmalıdır. Birincil anahtar olarak null'a izin veren herhangi bir tablonun varlık bütünlüğü yoktur. Referans bütünlüğü, ebeveynler ve çocuklar arasındaki ilişkinin doğru kurulmasını zorlar. Müşteri-sipariş ilişkisinde referans bütünlüğü, veritabanındaki her sipariş için bir müşterinin var olmasını sağlar.]
4. Veri temizliğinin kalitesi
Büyük veride veri temizliğinin kalitesi oldukça problemli bir konudur. Görevi tamamlamak için ne derecede veri temizlemenin gerekli olduğu sorusunu yanıtlamak her veri analisti için esastır. Güncel problemlerin çoğunda bunu her analist kendisi belirler ve dışarıdan herhangi birinin kendi çözümünde bu hususu değerlendirebilmesi pek olası değildir. Ancak bu davada eldeki görev açısından bu konu son derece önemliydi çünkü yasal verilerin güvenilirliği bire yönelmelidir.
Operasyonel güvenilirliği belirlemek için yazılım test teknolojilerinin dikkate alınması. Bugün bu modellerden daha fazlası var . Modellerin çoğu bir talep hizmeti modeli kullanır:
Şek. 6
Şöyle düşünerek: “Bulunan hata, bu modeldeki arıza olayına benzer bir olay ise o zaman t parametresinin analogu nasıl bulunur?” Ve şu modeli derledim: Bir test uzmanının bir kaydı kontrol etmesi için geçen sürenin (söz konusu veritabanı için) 1 dakika olduğunu, ardından tüm hataları bulması için ihtiyaç duyacağı sürenin 365 dakika olduğunu varsayalım, bu da yaklaşık 494 yıl 3 yıl demektir. ay çalışma süresi. Anladığımız gibi, bu çok büyük miktarda bir iş ve veritabanını kontrol etmenin maliyeti, bu veritabanını derleyen kişi için fahiş olacaktır. Bu yansımada ekonomik maliyet kavramı ortaya çıkıyor ve analiz sonrasında bunun oldukça etkili bir araç olduğu sonucuna vardım. İktisat kanununa göre: “Bir firmanın maksimum kârına ulaştığı üretim hacmi (birim cinsinden), yeni bir birim çıktı üretmenin marjinal maliyetinin bu firmanın alabileceği fiyatla karşılaştırıldığı noktada bulunur. yeni bir birim için.” Sonraki her hatayı bulmanın, kayıtların giderek daha fazla kontrol edilmesini gerektirdiği varsayımına dayanarak, bu bir maliyet faktörüdür. Yani, test modellerinde benimsenen varsayım aşağıdaki modelde fiziksel bir anlam kazanır: eğer i'inci hatayı bulmak için n kaydı kontrol etmek gerekliyse, o zaman sonraki (i+3) hatayı bulmak da gerekli olacaktır m kayıtlarını kontrol etmek ve aynı zamanda n
- Yeni bir hata bulunmadan önce kontrol edilen kayıt sayısı sabitlendiğinde;
- Bir sonraki hatayı bulmadan önce kontrol edilen kayıt sayısı artacaktır.
Kritik değeri belirlemek için, bu durumda sosyal maliyetler kavramını kullanarak şu şekilde formüle edilebilecek ekonomik fizibilite kavramına döndüm: “Hatayı düzeltmenin maliyeti, bunu yapabilecek ekonomik aktör tarafından karşılanmalıdır. en düşük maliyetle." Bir aracımız var; bir kaydı kontrol etmek için 1 dakika harcayan bir test uzmanı. Parasal açıdan günde 6000 ruble kazanırsanız bu 12,2 ruble olacaktır. (yaklaşık olarak bugün). Geriye ekonomi hukukunda dengenin ikinci tarafını belirlemek kalıyor. Ben şöyle mantık yürüttüm. Mevcut bir hata, ilgili kişinin, yani mülk sahibinin, bunu düzeltmek için çaba harcamasını gerektirecektir. Diyelim ki bu 1 günlük bir işlem gerektiriyor (başvuru yapın, düzeltilmiş belge alın). O zaman sosyal açıdan bakıldığında maliyetleri günlük ortalama maaşa eşit olacaktır. Hantı-Mansi Özerk Okrugu'nda tahakkuk eden ortalama maaş 73285 ovmak. veya 3053,542 ruble/gün. Buna göre şuna eşit bir kritik değer elde ederiz:
3053,542: 12,2 = 250,4 kayıt birimi.
Bu, sosyal açıdan bakıldığında, bir test uzmanının 251 kaydı kontrol etmesi ve bir hata bulması, kullanıcının bu hatayı kendisinin düzeltmesine eşdeğerdir. Buna göre, eğer test uzmanı bir sonraki hatayı bulmak için 252 kaydı kontrol etmeye eşit bir süre harcadıysa, bu durumda düzeltme maliyetini kullanıcıya kaydırmak daha iyidir.
Burada basitleştirilmiş bir yaklaşım sunulmaktadır, çünkü sosyal açıdan bakıldığında her uzmanın ürettiği tüm ek değerlerin, yani vergiler ve sosyal ödemeler dahil maliyetlerin hesaba katılması gerekir, ancak model açıktır. Bu ilişkinin bir sonucu olarak uzmanlar için şu gereklilik ortaya çıkıyor: BT sektöründeki bir uzmanın maaşı ulusal ortalamanın üzerinde olmalıdır. Maaşı, potansiyel veritabanı kullanıcılarının ortalama maaşından azsa, tüm veritabanını bizzat kendisinin kontrol etmesi gerekir.
Açıklanan kriter kullanıldığında, veritabanının kalitesine ilişkin ilk gereksinim oluşturulur:
ben(tr). Kritik hataların payı 1/250,4 = %0,39938'i geçmemelidir. Biraz daha az sanayide altın. Ve fiziksel açıdan hatalı kayıtların sayısı 1459'dan fazla değildir.
Ekonomik gerileme.
Aslında, kayıtlarda bu kadar çok hata yaparak toplum aşağıdaki miktarlarda ekonomik kayıpları kabul etmiş olur:
1459*3053,542 = 4 ruble.
Bu miktar, toplumun bu maliyetleri azaltacak araçlara sahip olmaması gerçeğine göre belirlenmektedir. Bundan şu sonuç çıkıyor: Eğer birisi hatalı kayıtların sayısını örneğin 259'a düşürebilecek bir teknolojiye sahipse, o zaman bu, toplumun tasarruf etmesine olanak tanıyacaktır:
1200*3053,542 = 3 ruble.
Ama aynı zamanda yeteneğini ve işini isteyebilir, diyelim ki - 1 milyon ruble.
Yani sosyal maliyetler şu şekilde azaltılır:
3 – 664 = 250 ruble.
Bu etki aslında BigDat teknolojilerinin kullanımından kaynaklanan katma değerdir.
Ancak burada şunu da hesaba katmak gerekir ki bu sosyal bir etkidir ve veri tabanının sahibi belediye yetkilileridir, bu veri tabanına kaydedilen mülk kullanımından elde edilen gelirler %0,3 oranında: 2,778 milyar ruble/ yıl. Ve bu maliyetler (4 ruble) mülk sahiplerine devredildiği için onu pek rahatsız etmiyor. Ve bu açıdan, Bigdata'da daha rafine teknolojilerin geliştiricisinin, bu veritabanının sahibini ikna etme yeteneğini göstermesi gerekecek ve bu tür şeyler ciddi bir yetenek gerektiriyor.
Bu örnekte hata değerlendirme algoritması, güvenilirlik testi sırasında yazılım doğrulamanın Schumann modeline [2] dayalı olarak seçilmiştir. İnternetteki yaygınlığı ve gerekli istatistiksel göstergeleri elde edebilme yeteneği nedeniyle. Metodoloji Monakhov Yu.M.'den alınmıştır. "Bilgi sistemlerinin işlevsel kararlılığı", Şekil 7'deki spoylerin altına bakın. 9-XNUMX.
Pirinç. 7 – 9 Schumann modelinin metodolojisi
Bu materyalin ikinci kısmı, Schumann modelinin kullanılmasının sonuçlarının elde edildiği bir veri temizleme örneği sunmaktadır.
Elde edilen sonuçları sunayım:
Tahmini hata sayısı N = 3167 n.
Parametre C, lambda ve güvenilirlik fonksiyonu:
Ris.17
Esas olarak lambda, her aşamada hataların tespit edilme yoğunluğunun gerçek bir göstergesidir. İkinci kısma bakarsanız bu göstergenin tahmini saatte 42,4 hataydı ki bu da Schumann göstergesiyle oldukça benzer. Yukarıda, geliştiricinin dakikada 1 kayıt kontrol ederken hata bulma oranının 250,4 kayıt başına 1 hatadan az olmaması gerektiği belirlendi. Dolayısıyla Schumann modeli için lambda'nın kritik değeri:
60 / 250,4 = 0,239617.
Yani hata tespit prosedürlerinin yürütülmesi ihtiyacı, mevcut 38,964'ten lambda 0,239617'ye düşene kadar sürdürülmelidir.
Veya N (potansiyel hata sayısı) eksi n (düzeltilmiş hata sayısı) göstergesi kabul edilen eşiğimizin altına düşene kadar - 1459 adet.
Edebiyat
- Monakhov, Yu.M. Bilgi sistemlerinin işlevsel kararlılığı. 3 saat içinde Bölüm 1. Yazılım güvenilirliği: ders kitabı. ödenek / Yu.M. Monakhov; Vladimir. durum üniversite – Vladimir: İzvo Vladimir. durum Üniversite, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Yazılım güvenilirliği tahmini için olasılıksal modeller."
- BT uzmanları için veri ambarı temelleri / Paulraj Ponniah.—2. baskı.
Kaynak: habr.com