1. Initiële gegevens
Het opschonen van gegevens is een van de uitdagingen waarmee data-analysetaken worden geconfronteerd. Dit materiaal weerspiegelde de ontwikkelingen en oplossingen die ontstonden als gevolg van het oplossen van een praktisch probleem bij het analyseren van de database bij de vorming van de kadastrale waarde. Bronnen hier .
Er is gekeken naar het bestand “Vergelijkingsmodel total.ods” in “Bijlage B. Resultaten van het bepalen van KS 5. Informatie over de methode voor het bepalen van de kadastrale waarde 5.1 Vergelijkende aanpak”.
Tabel 1. Statistische indicatoren van de dataset in het bestand “Vergelijkend model total.ods”
Totaal aantal velden, stuks. – 44
Totaal aantal records, stuks. — 365 490
Totaal aantal tekens, stuks. — 101 714 693
Gemiddeld aantal tekens in een record, stuks. — 278,297
Standaardafwijking van tekens in een record, stuks. — 15,510
Minimumaantal tekens in een invoer, stuks. – 198
Maximaal aantal tekens in een invoer, stuks. — 363
2. Inleidend deel. Basisnormen
Bij het analyseren van de gespecificeerde database werd een taak gevormd om de vereisten voor de mate van zuivering te specificeren, aangezien, zoals voor iedereen duidelijk is, de gespecificeerde database juridische en economische consequenties voor gebruikers met zich meebrengt. Tijdens de werkzaamheden bleek dat er geen specifieke eisen waren aan de mate van opschoning van big data. Toen ik de wettelijke normen in deze kwestie analyseerde, kwam ik tot de conclusie dat ze allemaal zijn gevormd uit mogelijkheden. Dat wil zeggen, er is een bepaalde taak verschenen, er worden informatiebronnen voor de taak samengesteld, vervolgens wordt een dataset gevormd en, op basis van de gemaakte dataset, hulpmiddelen om het probleem op te lossen. De resulterende oplossingen zijn referentiepunten bij het kiezen uit alternatieven. Ik heb dit weergegeven in figuur 1.
Omdat het bij het bepalen van normen de voorkeur verdient om te vertrouwen op bewezen technologieën, heb ik gekozen voor de vereisten die zijn uiteengezet in , omdat ik dit document het meest uitgebreide vond voor deze kwestie. In dit document staat met name: “Opgemerkt moet worden dat de vereisten voor gegevensintegriteit in gelijke mate van toepassing zijn op handmatige (papieren) en elektronische gegevens.” (vertaling: “...gegevensintegriteitsvereisten zijn zowel van toepassing op handmatige (papieren) als op elektronische gegevens”). Deze formulering wordt heel specifiek geassocieerd met het concept van “schriftelijk bewijs”, in de bepalingen van artikel 71 van het Wetboek van Burgerlijke Rechtsvordering, art. 70 CAS, artikel 75 APC, “schriftelijk” art. 84 Wetboek van Burgerlijke Rechtsvordering.
Figuur 2 geeft een diagram weer van de vorming van benaderingen van soorten informatie in de jurisprudentie.
Rijst. 2. Bron .
Figuur 3 toont het mechanisme van Figuur 1, voor de taken van de bovenstaande “Begeleiding”. Door een vergelijking te maken, is het gemakkelijk in te zien dat de benaderingen die worden gebruikt bij het voldoen aan de vereisten voor informatie-integriteit in moderne standaarden voor informatiesystemen aanzienlijk beperkt zijn in vergelijking met het juridische concept van informatie.
Afb.3
In het gespecificeerde document (Guidance) wordt de verbinding met het technische gedeelte, mogelijkheden voor het verwerken en opslaan van gegevens, goed bevestigd door een citaat uit hoofdstuk 18.2. Relationele database: "Deze bestandsstructuur is inherent veiliger, omdat de gegevens in een groot bestandsformaat worden bewaard, waardoor de relatie tussen gegevens en metadata behouden blijft."
In feite is er in deze benadering - vanuit de bestaande technische mogelijkheden - niets abnormaals en op zichzelf is dit een natuurlijk proces, aangezien de uitbreiding van concepten voortkomt uit de meest bestudeerde activiteit: databaseontwerp. Maar aan de andere kant verschijnen er wettelijke normen die niet voorzien in kortingen op de technische mogelijkheden van bestaande systemen, bijvoorbeeld: .
Rijst. 4. Trechter van technische mogelijkheden ().
In deze aspecten wordt het duidelijk dat de originele dataset (Fig. 1) in de eerste plaats zal moeten worden opgeslagen en in de tweede plaats de basis zal moeten vormen voor het extraheren van aanvullende informatie daaruit. Als voorbeeld: camera's die verkeersregels registreren zijn alomtegenwoordig, informatieverwerkingssystemen elimineren overtreders, maar andere informatie kan ook aan andere consumenten worden aangeboden, bijvoorbeeld als marketingmonitoring van de structuur van de klantenstroom naar een winkelcentrum. En dit is een bron van extra toegevoegde waarde bij het gebruik van BigDat. Het is heel goed mogelijk dat de datasets die nu, ergens in de toekomst, worden verzameld waarde zullen hebben volgens een mechanisme dat vergelijkbaar is met de waarde van zeldzame edities van 1700 op dit moment. Tijdelijke datasets zijn immers uniek en zullen in de toekomst waarschijnlijk niet meer worden herhaald.
3. Inleidend deel. Evaluatiecriteria
Tijdens het verwerkingsproces is de volgende classificatie van fouten ontwikkeld.
1. Foutklasse (gebaseerd op GOST R 8.736-2011): a) systematische fouten; b) willekeurige fouten; c) een blunder.
2. Door veelheid: a) monovervorming; b) multi-vervorming.
3. Afhankelijk van de ernst van de gevolgen: a) kritisch; b) niet kritisch.
4. Naar bron van voorval:
A) Technisch – fouten die optreden tijdens de werking van de apparatuur. Een redelijk relevante fout voor IoT-systemen, systemen met een aanzienlijke mate van invloed op de kwaliteit van communicatie, apparatuur (hardware).
B) Operatorfouten - fouten in een breed scala van typefouten door operators tijdens invoer tot fouten in de technische specificaties voor databaseontwerp.
C) Gebruikersfouten - hier zijn gebruikersfouten in het hele bereik van "vergeten de lay-out te veranderen" tot het verwarren van meters met voeten.
5. Gescheiden in een aparte klasse:
a) de "taak van het scheidingsteken", dat wil zeggen de spatie en ":" (in ons geval) toen deze werd gedupliceerd;
b) samen geschreven woorden;
c) geen spatie na servicetekens
d) symmetrisch meerdere symbolen: (), "", "...".
Alles bij elkaar genomen, met de systematisering van databasefouten weergegeven in figuur 5, wordt een redelijk effectief coördinatensysteem gevormd voor het zoeken naar fouten en het ontwikkelen van een algoritme voor het opschonen van gegevens voor dit voorbeeld.
Rijst. 5. Typische fouten die overeenkomen met de structurele eenheden van de database (Bron: ).
Nauwkeurigheid, domeinintegriteit, gegevenstype, consistentie, redundantie, volledigheid, duplicatie, conformiteit met bedrijfsregels, structurele zekerheid, gegevensafwijking, duidelijkheid, tijdigheid, naleving van regels voor gegevensintegriteit. (Pagina 334. Basisbeginselen van datawarehousing voor IT-professionals / Paulraj Ponniah. – 2e ed.)
Gepresenteerde Engelse tekst en Russische automatische vertaling tussen haakjes.
Nauwkeurigheid. De in het systeem opgeslagen waarde voor een data-element is de juiste waarde voor het voorkomen van het data-element. Als u een klantnaam en een adres in een record hebt opgeslagen, dan is het adres het juiste adres voor de klant met die naam. Als u in het record voor bestelnummer 1000 het bestelde aantal van 12345678 eenheden aantreft, dan is dat aantal het juiste aantal voor die bestelling.
[Nauwkeurigheid. De in het systeem opgeslagen waarde voor een data-element is de juiste waarde voor het voorkomen van het data-element. Als u de naam en het adres van een klant in een record hebt opgeslagen, is het adres het juiste adres voor de klant met die naam. Als u in het record voor bestelnummer 1000 het bestelde aantal van 12345678 eenheden aantreft, dan is dat aantal het exacte aantal voor die bestelling.]
Domeinintegriteit. De gegevenswaarde van een attribuut valt binnen het bereik van toegestane, gedefinieerde waarden. Het gebruikelijke voorbeeld zijn de toegestane waarden ‘mannelijk’ en ‘vrouwelijk’ voor het gendergegevenselement.
[Domeinintegriteit. De attribuutgegevenswaarde valt binnen het bereik van geldige, gedefinieerde waarden. Een algemeen voorbeeld zijn de geldige waarden "male" en "female" voor een genderdata-element.]
Data type. De waarde voor een data-attribuut wordt feitelijk opgeslagen als het datatype dat voor dat attribuut is gedefinieerd. Wanneer het gegevenstype van het winkelnaamveld is gedefinieerd als 'tekst', bevatten alle exemplaren van dat veld de winkelnaam, weergegeven in tekstformaat en niet in numerieke codes.
[Data type. De waarde van een data-attribuut wordt feitelijk opgeslagen als het datatype dat voor dat attribuut is gedefinieerd. Als het gegevenstype van het winkelnaamveld is gedefinieerd als 'tekst', bevatten alle exemplaren van dit veld de winkelnaam weergegeven in tekstformaat in plaats van numerieke codes.]
Samenhang. De vorm en inhoud van een gegevensveld is hetzelfde in meerdere bronsystemen. Als de productcode voor product ABC in het ene systeem 1234 is, dan is de code voor dit product in elk bronsysteem 1234.
[Samenhang. De vorm en inhoud van het gegevensveld zijn in verschillende bronsystemen hetzelfde. Als de productcode voor product ABC op één systeem 1234 is, dan is de code voor dat product op elk bronsysteem 1234.]
Ontslag. Dezelfde gegevens mogen niet op meer dan één plaats in een systeem worden opgeslagen. Als een data-element om redenen van efficiëntie opzettelijk op meer dan één plaats in een systeem wordt opgeslagen, moet de redundantie duidelijk worden geïdentificeerd en geverifieerd.
[Ontslag. Dezelfde gegevens mogen niet op meer dan één plaats in het systeem worden opgeslagen. Als een data-element om redenen van efficiëntie opzettelijk op meerdere locaties in een systeem wordt opgeslagen, moet de redundantie duidelijk worden gedefinieerd en geverifieerd.]
Volledigheid. Er zijn geen ontbrekende waarden voor een bepaald attribuut in het systeem. In een klantenbestand moet er bijvoorbeeld voor iedere klant een geldige waarde in het veld “status” staan. In het bestand voor ordergegevens moet ieder detailrecord voor een order volledig ingevuld zijn.
[Volledigheid. Er zijn geen ontbrekende waarden in het systeem voor dit attribuut. Het klantenbestand moet bijvoorbeeld voor elke klant een geldige waarde hebben voor het veld "status". In het orderdetailbestand moet elk orderdetailrecord volledig worden ingevuld.]
Duplicatie. Het dupliceren van records in een systeem is volledig opgelost. Als bekend is dat het productbestand dubbele records bevat, worden alle dubbele records voor elk product geïdentificeerd en wordt er een kruisverwijzing gemaakt.
[Duplicaat. Duplicatie van records in het systeem is volledig geëlimineerd. Als bekend is dat een productbestand dubbele vermeldingen bevat, worden alle dubbele vermeldingen voor elk product geïdentificeerd en wordt er een kruisverwijzing gemaakt.]
Conformiteit met bedrijfsregels. De waarden van elk data-item voldoen aan voorgeschreven bedrijfsregels. In een veilingsysteem kan de hamer- of verkoopprijs niet lager zijn dan de minimumprijs. In een bankleningssysteem moet het leningsaldo altijd positief of nul zijn.
[Naleving van bedrijfsregels. De waarden van elk data-element voldoen aan vastgestelde bedrijfsregels. In een veilingsysteem kan de hamer- of verkoopprijs niet lager zijn dan de minimumprijs. In een bancair kredietsysteem moet het leningsaldo altijd positief of nul zijn.]
Structurele bepaaldheid. Overal waar een data-item op natuurlijke wijze in afzonderlijke componenten kan worden gestructureerd, moet het item deze goed gedefinieerde structuur bevatten. De naam van een persoon wordt bijvoorbeeld op natuurlijke wijze verdeeld in voornaam, middelste initiaal en achternaam. Waarden voor namen van personen moeten worden opgeslagen als voornaam, middelste initiaal en achternaam. Dit kenmerk van datakwaliteit vereenvoudigt de handhaving van normen en vermindert ontbrekende waarden.
[Structurele zekerheid. Waar een data-element op natuurlijke wijze in afzonderlijke componenten kan worden gestructureerd, moet het element deze goed gedefinieerde structuur bevatten. De naam van een persoon is bijvoorbeeld natuurlijk verdeeld in voornaam, middelste initiaal en achternaam. Waarden voor individuele namen moeten worden opgeslagen als voornaam, middelste initiaal en achternaam. Dit kenmerk van datakwaliteit vereenvoudigt de toepassing van standaarden en vermindert ontbrekende waarden.]
Gegevensafwijking. Een veld mag alleen worden gebruikt voor het doel waarvoor het is gedefinieerd. Als het veld Adres-3 is gedefinieerd voor een eventuele derde adresregel voor lange adressen, dan mag dit veld alleen worden gebruikt voor het vastleggen van de derde adresregel. Het mag niet worden gebruikt voor het invoeren van een telefoon- of faxnummer voor de klant.
[Gegevensafwijking. Een veld mag alleen worden gebruikt voor het doel waarvoor het is gedefinieerd. Als het veld Adres-3 is gedefinieerd voor een mogelijke derde adresregel voor lange adressen, dan zal dit veld alleen worden gebruikt om de derde adresregel vast te leggen. Het mag niet worden gebruikt om een telefoon- of faxnummer voor een klant in te voeren.]
Helderheid. Een data-element kan alle andere kenmerken van kwaliteitsgegevens bezitten, maar als de gebruikers de betekenis ervan niet duidelijk begrijpen, heeft het data-element geen waarde voor de gebruikers. Juiste naamgevingsconventies helpen ervoor te zorgen dat de gegevenselementen goed begrepen worden door de gebruikers.
[Helderheid. Een data-element kan alle andere kenmerken van goede data hebben, maar als gebruikers de betekenis ervan niet duidelijk begrijpen, heeft het data-element geen waarde voor gebruikers. Juiste naamgevingsconventies zorgen ervoor dat gegevenselementen goed worden begrepen door gebruikers.]
Tijdig. De gebruikers bepalen de actualiteit van de data. Als de gebruikers verwachten dat klantdimensiegegevens niet ouder zijn dan één dag, moeten de wijzigingen in klantgegevens in de bronsystemen dagelijks worden doorgevoerd in het datawarehouse.
[Tijdig. Gebruikers bepalen de actualiteit van data. Als gebruikers verwachten dat klantdimensiegegevens niet ouder zijn dan één dag, moeten wijzigingen in klantgegevens in de bronsystemen dagelijks worden toegepast op het datawarehouse.]
Bruikbaarheid. Elk data-element in het datawarehouse moet voldoen aan een aantal eisen van de verzameling gebruikers. Een data-element kan accuraat en van hoge kwaliteit zijn, maar als het geen waarde heeft voor de gebruikers, dan is het totaal onnodig dat dat data-element zich in het datawarehouse bevindt.
[Nutsvoorziening. Elk gegevensitem in het gegevensarchief moet aan een aantal vereisten van de gebruikersverzameling voldoen. Een data-element kan accuraat en van hoge kwaliteit zijn, maar als het geen waarde biedt voor gebruikers, dan is het niet nodig dat dat data-element zich in het datawarehouse bevindt.]
Naleving van regels voor gegevensintegriteit. De gegevens die zijn opgeslagen in de relationele databases van de bronsystemen moeten voldoen aan de regels voor entiteitsintegriteit en referentiële integriteit. Elke tabel die null als primaire sleutel toestaat, heeft geen entiteitsintegriteit. Referentiële integriteit dwingt het correct tot stand brengen van de ouder-kindrelaties af. In een klant-tot-orderrelatie garandeert referentiële integriteit het bestaan van een klant voor elke bestelling in de database.
[Naleving van regels voor gegevensintegriteit. Gegevens die zijn opgeslagen in relationele databases van bronsystemen moeten voldoen aan de regels van entiteitsintegriteit en referentiële integriteit. Elke tabel die null als primaire sleutel toestaat, heeft geen entiteitsintegriteit. Referentiële integriteit dwingt ertoe dat de relatie tussen ouders en kinderen correct tot stand komt. In een klant-orderrelatie zorgt referentiële integriteit ervoor dat er voor elke bestelling in de database een klant bestaat.]
4. Kwaliteit van het opschonen van gegevens
De kwaliteit van het opschonen van gegevens is een nogal problematisch probleem in bigdata. Het beantwoorden van de vraag welke mate van data-opschoning nodig is om de taak te voltooien, is van fundamenteel belang voor elke data-analist. Bij de meeste actuele problemen bepaalt iedere analist dit zelf en het is onwaarschijnlijk dat iemand van buitenaf dit aspect in zijn oplossing kan beoordelen. Maar voor de taak die in dit geval moest worden uitgevoerd, was deze kwestie uiterst belangrijk, omdat de betrouwbaarheid van juridische gegevens naar één zou moeten neigen.
Het overwegen van softwaretesttechnologieën om de operationele betrouwbaarheid te bepalen. Tegenwoordig zijn er meer dan deze modellen . Veel van de modellen maken gebruik van een claimservicemodel:
Fig. 6
Denk als volgt: "Als de gevonden fout een gebeurtenis is die vergelijkbaar is met de foutgebeurtenis in dit model, hoe kun je dan een analoog van de parameter t vinden?" En ik heb het volgende model samengesteld: Laten we ons voorstellen dat de tijd die een tester nodig heeft om één record te controleren 1 minuut is (voor de database in kwestie), en dat hij dan 365 minuten nodig heeft om alle fouten te vinden, wat ongeveer 494 jaar en 3 minuten is. maanden arbeidstijd. Zoals we begrijpen is dit een zeer grote hoeveelheid werk en zullen de kosten voor het controleren van de database onbetaalbaar zijn voor de samensteller van deze database. In deze reflectie komt het economische concept van kosten naar voren en na analyse kwam ik tot de conclusie dat dit een redelijk effectief instrument is. Gebaseerd op de wet van de economie: “Het productievolume (in eenheden) waarbij de maximale winst van een bedrijf wordt behaald, bevindt zich op het punt waar de marginale kosten voor het produceren van een nieuwe eenheid product worden vergeleken met de prijs die dit bedrijf kan ontvangen. voor een nieuwe eenheid.” Gebaseerd op het uitgangspunt dat het vinden van elke volgende fout steeds meer controle van de records vereist, is dit een kostenfactor. Dat wil zeggen, het postulaat dat wordt aangenomen in het testen van modellen krijgt een fysieke betekenis in het volgende patroon: als het nodig was om n records te controleren om de i-de fout te vinden, dan zal het nodig zijn om de volgende (i+3) fout te vinden. om m records te controleren en tegelijkertijd n
- Wanneer het aantal gecontroleerde records voordat een nieuwe fout wordt gevonden, stabiliseert;
- Wanneer het aantal gecontroleerde records voordat de volgende fout wordt gevonden, toeneemt.
Om de kritische waarde te bepalen, heb ik mij gericht op het concept van economische haalbaarheid, dat in dit geval, gebruikmakend van het concept van sociale kosten, als volgt kan worden geformuleerd: ‘De kosten van het corrigeren van de fout moeten worden gedragen door de economische agent die dat kan doen. tegen de laagste kosten.” We hebben één agent: een tester die één minuut besteedt aan het controleren van één record. In geld uitgedrukt: als u 1 roebel per dag verdient, is dit 6000 roebel. (ongeveer vandaag). Rest ons nog de tweede kant van het evenwicht in het economisch recht te bepalen. Ik redeneerde zo. Een bestaande fout vereist dat de betrokken persoon moeite doet om deze te corrigeren, dat wil zeggen de eigenaar van het onroerend goed. Laten we zeggen dat hiervoor 12,2 dag actie nodig is (aanvraag indienen, gecorrigeerd document ontvangen). Dan zijn zijn kosten vanuit sociaal oogpunt gelijk aan het gemiddelde salaris per dag. Gemiddeld opgebouwd salaris in het autonome Okrug Khanty-Mansi 73285 wrijven. of 3053,542 roebel/dag. Dienovereenkomstig verkrijgen we een kritische waarde gelijk aan:
3053,542: 12,2 = 250,4 eenheden records.
Dit betekent vanuit sociaal oogpunt dat als een tester 251 records controleert en één fout vindt, dit gelijk staat aan het feit dat de gebruiker deze fout zelf oplost. Dienovereenkomstig, als de tester tijd besteedde die gelijk was aan het controleren van 252 records om de volgende fout te vinden, dan is het in dit geval beter om de correctiekosten naar de gebruiker te verschuiven.
Hier wordt een vereenvoudigde aanpak gepresenteerd, omdat het vanuit sociaal oogpunt noodzakelijk is om rekening te houden met alle extra waarde die door elke specialist wordt gegenereerd, dat wil zeggen kosten inclusief belastingen en sociale uitkeringen, maar het model is duidelijk. Een gevolg van deze verhouding is de volgende eis aan specialisten: een specialist uit de IT-branche moet een salaris hebben dat hoger is dan het landelijk gemiddelde. Als zijn salaris lager is dan het gemiddelde salaris van potentiële databasegebruikers, moet hij zelf de hele database handmatig controleren.
Bij gebruik van het beschreven criterium wordt de eerste vereiste voor de kwaliteit van de database gevormd:
ik(tr). Het aandeel kritische fouten mag niet groter zijn dan 1/250,4 = 0,39938%. Iets minder dan goud in de industrie. En fysiek gezien zijn er niet meer dan 1459 records met fouten.
Economische terugtocht.
Door zoveel fouten in de administratie te maken, stemt de samenleving feitelijk in met economische verliezen ter hoogte van:
1459*3053,542 = 4 roebel.
Dit bedrag wordt bepaald door het feit dat de samenleving niet over de instrumenten beschikt om deze kosten te verlagen. Hieruit volgt dat als iemand een technologie heeft waarmee hij het aantal records met fouten kan terugbrengen tot bijvoorbeeld 259, de samenleving hierdoor het volgende kan besparen:
1200*3053,542 = 3 roebel.
Maar tegelijkertijd kan hij om zijn talent en werk vragen, laten we zeggen - 1 miljoen roebel.
Dat wil zeggen dat de sociale kosten worden verlaagd door:
3 – 664 = 250 roebel.
In essentie is dit effect de toegevoegde waarde van het gebruik van BigDat-technologieën.
Maar hier moet er rekening mee worden gehouden dat dit een sociaal effect is, en de eigenaar van de database zijn gemeentelijke autoriteiten, hun inkomsten uit het gebruik van eigendommen die in deze database zijn geregistreerd, tegen een tarief van 0,3%, bedragen: 2,778 miljard roebel / jaar. En deze kosten (4 roebel) storen hem niet veel, omdat ze worden overgedragen aan de eigenaren van onroerend goed. En in dit opzicht zal de ontwikkelaar van meer verfijningstechnologieën in Bigdata moeten laten zien dat hij de eigenaar van deze database kan overtuigen, en zulke dingen vereisen aanzienlijk talent.
In dit voorbeeld werd het foutbeoordelingsalgoritme gekozen op basis van het Schumann-model [2] van softwareverificatie tijdens betrouwbaarheidstests. Vanwege de prevalentie ervan op internet en de mogelijkheid om de nodige statistische indicatoren te verkrijgen. De methodologie is overgenomen van Monakhov Yu.M. “Functionele stabiliteit van informatiesystemen”, zie onder de spoiler in Fig. 7-9.
Rijst. 7 – 9 Methodologie van het Schumann-model
Het tweede deel van dit materiaal presenteert een voorbeeld van het opschonen van gegevens, waarbij de resultaten van het gebruik van het Schumann-model worden verkregen.
Ik zal de verkregen resultaten presenteren:
Geschat aantal fouten N = 3167 n.
Parameter C, lambda en betrouwbaarheidsfunctie:
Afb.17
In wezen is lambda een feitelijke indicator van de intensiteit waarmee fouten in elke fase worden gedetecteerd. Als je naar het tweede deel kijkt, bedroeg de schatting voor deze indicator 42,4 fouten per uur, wat redelijk vergelijkbaar is met de Schumann-indicator. Hierboven is bepaald dat de snelheid waarmee een ontwikkelaar fouten ontdekt niet lager mag zijn dan 1 fout per 250,4 records, bij het controleren van 1 record per minuut. Vandaar de kritische waarde van lambda voor het Schumann-model:
60 / 250,4 = 0,239617.
Dat wil zeggen dat de noodzaak om foutdetectieprocedures uit te voeren moet worden uitgevoerd totdat lambda, van de bestaande 38,964, afneemt naar 0,239617.
Of totdat de indicator N (potentieel aantal fouten) minus n (gecorrigeerd aantal fouten) onder onze geaccepteerde drempel daalt - 1459 stuks.
Literatuur
- Monakhov, Yu. M. Functionele stabiliteit van informatiesystemen. In 3 uur Deel 1. Betrouwbaarheid van software: leerboek. toelage / Yu.M. Monakhov; Vladim. staat universiteit – Vladimir: Izvo Vladimir. staat Universiteit, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Probabilistische modellen voor het voorspellen van de betrouwbaarheid van software."
- Basisbeginselen van datawarehousing voor IT-professionals / Paulraj Ponniah. – 2e ed.
Bron: www.habr.com