Otomatik Sistemler ve Bilgi Teknolojileri Standartları. ACS kabul testleri. Dokümantasyon standartları nelerdir?

Bugün proje dokümantasyonu için yerel standartlar hakkında konuşacağız. Bu standartlar pratikte nasıl çalışır, neden kötü ve ne iyidir. Kamu ve ciddi özel müşteriler için belgeler geliştirirken, genellikle seçeneğimiz yoktur - TK'yi belgeleme gereksinimlerinde standartlara uygunluk yazılıdır. Uygulamada, standartların yapısının, belgelerde ne olması gerektiği ve bu belgelere neden ihtiyaç duyulduğuna dair yanlış anlaşılma örneklerine rastladım. Sonuç olarak, teknik yazarların, analistlerin ve uzmanların kaleminden bazen öyle değerli taşlar çıkar ki, bunların hangi bilinç durumunda yazıldığı belli olmaz. Ama aslında, her şey oldukça basit. Habr'da yapılan bir araştırma, bu konuyla ilgili az çok eksiksiz materyallere bağlantılar döndürmedi, bu yüzden bu can sıkıcı boşluğu doldurmayı öneriyorum.

Dokümantasyon standartları nelerdir?

Söz konusu 34 seride yalnızca 3 ana belgelendirme standardı bulunmaktadır:

Teknik özelliklerin geliştirilmesi için en sevilen ve popüler standart. Unutulmaması gereken tek şey, serideki diğer standartlarla sıkı bir şekilde bağlantılı olduğu ve bu standarda göre yürütülen bir teknik şartname aldıysanız, doğrudan bir gereklilik olmasa bile diğer standartlara bağlı kalmanız son derece arzu edilir. bunun için. En azından açısından ortak ideoloji(hangisi hakkında aşağıda)

sağlayan temel bir belgedir. tam liste GOST 34 belgeleri, belgelerin kodlanması için öneriler, belgelerin projenin hangi aşamalarına ait olduğu (aşamalar GOST 34.601-90'da açıklanmıştır) ve ayrıca bunların birbirleriyle nasıl birleştirilebileceği.

Aslında bu standart büyük bir açıklamalı tablodur. Kullanım kolaylığı için Excel'e sürülebilir.

Proje belgelerinin içeriğini değişen derecelerde ayrıntıyla açıklayan hacimli bir standart. Yukarıda belirtilen GOST 34.201-89 indeks olarak kullanılır.

RD 50-34.698-90 standardına ilişkin hükümlerinin belirsizliği nedeniyle genellikle müşteri ve yüklenici ve hatta proje ekibinin üyeleri tarafından farklı şekilde anlaşılan birçok soru ve yorumu vardır. Ama ne yazık ki elimizde daha somut bir şey yok.

Şimdi, geleneksel olarak eksilerden başlayarak, standartların artılarını ve eksilerini ele alalım.

Standartların Eksileri

Ana dezavantaj herkes için açıktır - standartlar eskidir. Otomatikleştirilmiş bir sistemin mimarisinin modası geçmiş bir konseptini içerirler. Örneğin:

• bir istemci programı ve bir DBMS sunucusundan oluşan iki katmanlı uygulamalar (üç veya daha fazla "katmanlı" uygulama yok, Weblogic veya JBoss yok)
• açıklanan veritabanı tablolarının yapısı, mantıksal veri modeli hakkında bir fikir verecektir (uygulama ile veritabanı arasında biraz Hazırda Bekletme olabileceği gerçeği, o zaman kötü bir fazlalık gibi görünüyordu)
• kullanıcı arayüzü tek pencerelidir (farklı olabilir mi? "Tarayıcı" nedir?)
• Sistemde çok fazla rapor yoktur, hepsi kağıttır ve nokta vuruşlu yazıcıda yazdırılır.
• Geliştirilen program, net bir girdi ve çıktıya sahip ve son derece uzmanlaşmış olan "bilgi işleme problemini" çözmeye odaklanmıştır. Bilgi işleme bir "algoritmaya" dayanmaktadır. Bazen birkaç "algoritma" vardır. (Nesne yönelimli programlama o zamanlar sadece ilk adımlarını atıyordu ve ciddiye alınmadı.)
• veritabanı yöneticisi tablolarda hangi bilgilerin olduğunu anlar ve sistem dizinlerini düzenlemeye aktif olarak katılır (50 farklı uygulama için gerçekten bir DBMS sunucusu var mı?)

Buna göre, standart aşağıdaki gibi eserler içerir:

5.8. Belge formunun çizimi (video çerçevesi)
Belge, gereksinimlere uygun olarak belge formunun veya video karesinin bir görüntüsünü içermelidir. devlet standartları birleşik dokümantasyon sistemi R 50-77 ve gerekli açıklamalar.

Belgenin anlamı, sürücüleri genellikle mühendislerin kendileri tarafından yazılan yüksek hızlı nokta vuruşlu yazıcıların bulunduğu Sovyet işletmelerinde "Baskı Alanları" olarak adlandırılmasıdır. Bu nedenle, yazdırıldıklarında belgelerin olması gerektiği gibi görünmesini sağlamak için yazdırılması gereken tüm belgelerin bir kaydını tutmaları gerekiyordu.

Bir "video çerçevesi" aynı zamanda bir metin ekranında görüntülenen bir belgedir. Ekranlar her zaman gerekli karakterleri ve gerekli sayıda karakteri yatay ve dikey olarak desteklemiyordu (ve grafikleri hiç desteklemiyordu). Bu nedenle, burada da tüm ekran belgelerinin formlarını ek olarak koordine etmek gerekliydi.

Şimdi "makine-gram", "video çerçevesi", "ADCP" kelimeleri bize hiçbir şey söylemez. 90'larda uzmanlaşmış bir enstitüden mezun olmama rağmen, onları kullanımda da bulamadım. Bu, Windows 3.1'in, VGA ekranların, üç inçlik disketlerin ve ilk yerli İnternet sitelerinin ortaya çıkma zamanıydı. Ancak bu kelimeler standarttır ve müşteri bazen kaprisli bir şekilde GOST 34.201-89'a göre eksiksiz bir belge seti sağlamayı talep eder. Ayrıca, TK'deki benzer formülasyonlar bir bakanlıktan diğerine dolaşıyor ve zaten asli kısmın içine sürüldüğü bir tür söylenmemiş şablon haline geldi.

Bu nedenle, projede "Belge formunun çizimi (video çerçevesi)" aptal adı olan belge boş olmalı ve olmamalıdır.

Standartta ne iyi

Herhangi bir standart iyidir çünkü müşterinin ve yüklenicinin aynı dili konuşmalarına izin verir ve en azından müşterinin iletilen sonuçlar üzerinde "şekil olarak" herhangi bir iddiası olmayacağını garanti eder.

Ve GOST 34 standartları da iyi çünkü derlendiler Zeki insanlar, yıllardır çalışıyorlar ve net bir hedefleri var - herhangi bir ACS'nin temsil ettiği karmaşık bir soyut varlığı kağıt üzerinde mümkün olduğunca eksiksiz bir şekilde tanımlamak.

GOST'lerimizi hiç duymamış olan Batılı müteahhitler için yetkin bir görev belirlemeniz gerektiğinde, bu standartlara veya daha doğrusu içeriklerine, anlamsal bileşenlerine de güvenebilirsiniz. Çünkü yine, bilginin eksiksizliğinin garantisi çok değerlidir. Yüksek düzeyde profesyonelliğimizle kendimizi nasıl şımarttığımız önemli değil, aynı GOST 34.602-89 her şeyi "hatırlarken", gereksinimlerimize temel şeyleri dahil etmeyi unutabiliriz. Batılı müteahhitlerin çalışmalarının sonucunun nasıl görünmesi gerektiğini anlamıyorsanız, önerilen bölümler için dokümantasyon gereksinimlerine bakın. Sizi temin ederim, bununla gelmemek daha iyi! Büyük olasılıkla, standartlarımızın her şeyin daha dolu, daha modern ve daha iyi olabileceği Batı analogları var. Ne yazık ki, GOST'lerimizin yeterli olmayacağına dair tek bir vaka olmadığı için onlara aşina değilim.

Standartların yaratıcılarının java veya .NET, HD monitörler ve İnternet hakkında hiçbir şey bilmediği gerçeğine gülebilirsiniz, ancak çalışmalarının ölçeğini ve profesyonel topluluğumuz için değerini küçümsemenizi tavsiye etmem.

GOST serisi 34 belgelendirme standartları nasıl okunur ve anlaşılır

Standart, tüm belgeleri zaman ve konu alanı olmak üzere iki eksene böler. GOST 34.201-89'daki tablo 2'ye bakarsanız, bu bölüm açıkça görülebilir ("Yaratma aşaması" ve "Projenin bir parçası" sütunları)

Otomatik bir kontrol sistemi oluşturma aşamaları

Oluşturma aşamaları GOST 34.601-90'da tanımlanmıştır. Bunlardan üçü dokümantasyonla ilgilidir:

• Taslak proje (EDS)
• Teknik tasarım (TP)
• Çalışma belgelerinin (RD) geliştirilmesi

ön tasarımİş Tanımı aşamasını takip eder ve ön tasarım çözümlerinin geliştirilmesine hizmet eder.

Teknik proje geleceğin sistemini tüm açılardan tanımlar. TP aşamasının belgeleri, okuduktan sonra, önerilen yaklaşımlar, yöntemler, mimari ve teknik çözümlerde tam bir netlik bırakmalıdır. Bir sonraki aşamada, yaklaşımları tanımlamak ve haklı çıkarmak için çok geç olacak. teknik çözümler Böylece P aşaması anahtardır başarılı teslimat TK gereksinimlerinin tüm çeşitliliğinin P aşamasının belgelerine yansıtılması gerektiğinden çalışır. P aşamasında, sistem hiç mevcut olmayabilir.

Çalışma belgeleri yeni sistemin başarılı bir şekilde devreye alınması, devreye alınması ve daha fazla çalışması için tasarlanmıştır. Bunlar, gelecekteki ihtişamı tanımlayan Aşama P'nin aksine, fiziksel olarak var olan varlıkları tanımlayan çok özel bilgiler içeren belgelerdir.

Otomatik bir kontrol sisteminin oluşturulması için proje belgelerinin bölümleri (bölümleri)

Konu alanı "Hükümler"e ayrılmıştır. İlk başta, böyle bir bölünme gereksiz ve gereksiz görünüyor. Ancak pratikte bu araç seti ile çalışmaya başladığınızda, içinde gömülü olan ideoloji yavaş yavaş gün yüzüne çıkıyor.

GOST derleyicilerinin zihnindeki otomatik bir sistem, farklı kaynaklardan gelen bilgileri belirli algoritmalara göre işleyen ve işleme sonuçlarını belgeler, veri yapıları veya kontrol eylemleri şeklinde veren donanım, yazılım ve iletişim kanallarının bir kombinasyonudur. En basit otomatın ilkel bir modeli.

Bu "otomat" ı tam olarak tanımlamak için aşağıdaki kesimler yapılmıştır (çizimdeki gibi):

Yazılım (MO), hangi soruları yanıtlıyor: "kara kutu"nun içine hangi mantık gömülü? Neden bu algoritmalar, tam olarak bu formüller ve tam olarak bu katsayılar seçilmiştir?

Yazılım, işlemciler veya veritabanları hakkında hiçbir şey bilmiyor. Bu ayrı bir soyut alandır, "boşluktaki küresel atların" meskeni. Ancak yazılım, konu alanıyla çok sıkı bir şekilde bağlantılıdır, yani Gerçek hayat... Örneğin, kontrol sistemleri için kontrol algoritmaları yol trafiği müşteri tarafından kararlaştırılmadan önce trafik polisi ile anlaşmak gerekir. Ve sonra neden ayrı bir kitapta yer aldıklarını anlıyorsunuz. Çünkü trafik polisinde kimse uygulama sunucusunun hangi işletim sistemi üzerinde çalışacağıyla ilgilenmiyor ancak yağmurda veya karda skorbordda hangi işaret ve hız sınırının çıkacağı çok ilginç. Kendi rollerinden sorumludurlar ve başka bir şey imzalamayacaklar. Öte yandan, imzaladıkları zaman, sorunun teknik yönüne dair bir soru olmayacak - neden diğer panoları veya trafik ışıklarını değil de bunları seçtiler. “Ataların” bilgeliği, bu tür pratik durumlarda tam olarak kendini gösterir.

Bilgi desteği (IO)... Sistemin başka bir dilimi. Bu sefer sistemimizin kara kutusu şeffaf hale getirildi ve içinde dolaşan bilgilere bakıyoruz. Diğer tüm organlar görünmezken insan dolaşım sisteminin bir modelini hayal edin. Bu benzer bir şey ve Bilgi desteği var. İçerideki ve dışarıdaki bilgi geçişinin bileşimini ve yollarını, sistemdeki bilgilerin mantıksal organizasyonunu, referans kitaplarının ve kodlama sistemlerinin bir tanımını (üretim için programlar yapanlar, ne kadar önemli olduklarını bilir) açıklar. Ana tanımlayıcı kısım TP aşamasına düşer, ancak "Veritabanları Kataloğu" belgesi gibi bazı "ilkeler" RD aşamasına akar. Daha önce tam olarak başlıkta yazılanları içerdiği açıktır. Ancak bugün, karmaşık bir karmaşık sistem için böyle bir belge oluşturmaya çalışın, çok sık satın alınan alt sistemler, gizemli bilgi depoları ile sistemin bir parçası olarak kullanılır. Bu belgeye şu anda özellikle ihtiyaç duyulmadığından bahsetmiyorum bile.

Veya burada "Makine Bilgi Medyası Bildirimi" var. Eskiden manyetik tamburların veya film makaralarının numaralarını içerdiği açıktır. Ve şimdi oraya ne getirmeli?

Kısacası, AR aşamasında, Bilgi Destek belgeleri resmi olarak olması gerektiği için oldukça zararlı bir ilkedir, ancak bunları doldurmak için özel bir şey yoktur.

Yazılım (yazılım)... Proje dokümantasyonunun herkesin favori kısmı. Evet, sadece bu sadece bir belge olduğu için! Ve sonra, herkes orada neyin kaydedilmesi gerektiğini anlar. Ama yine de tekrar edeceğim.

Bu belgede, IO'da açıklanan bilgileri işleyen, IO'da açıklanan algoritmaların hangi yazılımla yürütüldüğünü söylemeliyiz. Yani burada diğer bölümlerden gelen bilgileri çoğaltmaya gerek yoktur. Sistemin mimarisini, seçilen yazılım teknolojilerinin gerekçesini, tanımlarını (her türlü sistem şeyi: programlama dilleri, çerçeveler, işletim sistemleri vb.) verir. Ayrıca bu belgede bilgi işleme araçlarının nasıl düzenlendiğini açıklıyoruz (mesaj kuyrukları, depolamalar, yedekleme araçları, kullanılabilirlik çözümleri, her türlü uygulama havuzu vb.). standart vardır Detaylı Açıklama herhangi bir uzmanın anlayabileceği bu belgenin içeriği.

Teknik destek (TO)... Proje belgelerinin bir parçası olan herkes tarafından daha az sevilmez. Parlak resim, yalnızca geliştirilmesi gereken belgelerin bolluğu nedeniyle karartılır. Toplamda, standarda göre, 9'u TP aşamasında olan 22 belgenin geliştirilmesi gerekmektedir.

Gerçek şu ki, standart, bilgisayar donanımı ve ağları, mühendislik sistemleri ve hatta (gerekirse) inşaat kısmı dahil olmak üzere tüm teknik desteğin bir tanımını sağlar. Ve bu ekonomi çok sayıda standart ve yönetmelik tarafından düzenlenir, farklı organizasyonlarda koordine edilir ve bu nedenle her şeyi parçalara bölmek ve parçalar halinde koordine etmek (düzenlemek) daha uygundur. Aynı zamanda, standart, bazı belgeleri birbiriyle birleştirmenize izin verir; bu, tüm yığının bir kişi tarafından kabul edilmesi durumunda yapılması mantıklıdır.

Ayrıca, kalite standartları setinin teknik belgelerin muhasebeleştirilmesi ve saklanması anlamına geldiğini ve müşterideki "kitaplarımızın" açıklamanın konusuna bağlı olarak farklı arşivlere dağılabileceğini unutmayın. Bu, belgelerin parçalanması lehine başka bir argümandır.

Kurumsal destek (OO)... Bir teknisyen için normal olan bu bölümü mümkün olan en kısa sürede atlama arzusunu bastırdıktan sonra, daha ayrıntılı olarak ele alacağım. Meslektaşlarım, son yıllarda bu bölümde açıklığa kavuşturulması gereken projelerde kötü eğilimler ana hatlarıyla belirtilmiştir.

TP aşamasında, bölüm yalnızca bir belge içeriyor “ Organizasyon yapısının tanımı"Müşteriye organizasyon yapısını değiştirmek açısından neye hazırlanması gerektiğini söylemeliyiz. Birdenbire sisteminizi işletmek, yeni pozisyonları tanıtmak vb. için yeni bir departman düzenlemeniz gerekiyor.

RD aşamasında, ayrı ayrı ele almak istediğim daha ilginç belgeler ortaya çıkıyor.

Kullanici rehberi... Yorumlar gereksiz bence.

Bilgisayar destekli tasarımın metodolojisi (teknolojisi)... Bu belgeye, gerekirse, yazılım oluşturma, sürüm kontrolü, test etme vb. sürecinin bir tanımını koyabilirsiniz. Ancak bu, TK'de müşterinin yazılımı kişisel olarak bir araya getirmek istemesi durumunda geçerlidir. Buna ihtiyaç duymuyorsa (ve bunun için ödeme yapmıyorsa), o zaman tüm iç mutfağınız onun işi değildir ve bu belgenin yapılmasına gerek yoktur.

teknolojik talimat... İş süreçlerini resmileştirme modası nedeniyle, kurnaz bir müşteri bazen işletme prosedürlerini bu belgeye sıkıştırmaya çalışır. Yani, bu hiçbir şekilde gerekli değildir.

İş süreçlerinin tanımı, rolü ve iş tanımları, iş düzenlemeleri - tüm bunlar bir ORD, yani örgütsel ve idari belgeler. Anladığım kadarıyla sizden satın almayan bir danışmanlık projesinin ürünü. Ve sizden teknik bir proje ve bunun için teknik belgeler satın aldılar.

Teknolojik talimat, ORD ile kullanım kılavuzu arasında bir ara katmandır. RP ayrıntılı olarak açıklar nasıl sistemde belirli işlemleri yapmanız gerekiyor. Teknolojik talimat diyor ki ne tür Sistemin işleyişi ile ilgili belirli durumlarda eylemler gerçekleştirilmelidir. Kabaca söylemek gerekirse, teknolojik bir talimat, belirli bir pozisyon veya rol için RP'nin kısa bir özetidir. Müşterinin tanımlanmış rolleri yoksa veya rolleri ve iş gereksinimlerini kendiniz tanımlamanızı istiyorsa, belgeye en temel rolleri ekleyin, örneğin: operatör, kıdemli operatör, yönetici. Müşterinin "ama beğenmedik" veya "ama beğenmedik" konusundaki yorumlarına bir rol listesi ve bir açıklama eşlik etmelidir. iş sorumlulukları... Çünkü biz iş süreçleri koyma... Biz bu iş süreçleriyiz otomatikleştirmek.

Tarif edilen tırmığı ayrıca renkli örneklerle ayrı ayrı yazacağım çünkü bu "milli ekonomi"nin farklı sektörlerinde ilk kez tekrarlanmıyor.

Veri işlemenin teknolojik sürecinin tanımı (tele işleme dahil)... Özel olarak belirlenmiş "Bilgisayar Operatörleri"nin makineyi delikli kartlarla beslediği ve sonucun çıktısını bir zarfa paketlediği mağara çağının acınası bir kalıntısı. Bu talimat onlar içindir. XXI yüzyılda içine ne yazmalı - size kesin olarak söyleyemem. Kendinizi gevşetin. En iyisi bu belgeyi unutmak.

Sistem çapında çözümler (VEYA)... Standart, OP bölümünün 17 belgesini sağlar. İlk olarak, bunların neredeyse tamamı ön Taslak Tasarım aşamasından gelen belgelerdir. İkincisi, bunlar her türlü tahmin, hesaplama ve Kısa Açıklama otomatik fonksiyonlar. Yani, ana BT üretiminden değil, destek personeli için - yöneticiler, maliyet tahmincileri, satın alma uzmanları, ekonomistler vb.

Üçüncüsü, ameliyathane, fikre göre bir tür Yönetici Özeti olan "Teknik projeye açıklayıcı not" adlı bir mega belge içerir, ancak aslında birçok tasarımcı TP aşamasının tüm yararlı içeriğini içine sokar. . Böyle radikal bir yaklaşım bazen haklı ve hatta hem müşteri hem de yüklenici için karşılıklı olarak faydalıdır, ancak bazı durumlarda.

GOST 34 kullanmanın çeşitleri

1. Standarda tam ve tam bağlılık... Doğal olarak, hiç kimse gönüllü olarak böyle bir belge bulutu yazmayacak. Bu nedenle, yalnızca TK'de güvence altına aldığı ve bir anlaşma ile yukarıdan ezdiği müşterinin ısrarlı talebi üzerine eksiksiz bir belge seti hazırlanır. Bu durumda, her şeyi tam anlamıyla anlamanız ve müşteriye GOST 34.201-89'daki tablo 2'deki belgelerin adlarının görüneceği, kesinlikle gereksiz olanlar hariç, listesi kesinlikle yapmanız gereken fiziksel "kitaplar" vermeniz gerekir. tartışın ve yazılı olarak düzeltin. Belgelerin içeriği de, herhangi bir hayal gücü olmaksızın, bölümlerin başlıklarına kadar RD 50-34.698-90'a uygun olmalıdır. Müşterinin beyninin patlaması için bazen büyük bir sistem alt sistemlere bölünür ve her alt sistem için ayrı bir proje dokümantasyonu düzenlenir. Korkutucu görünüyor ve dünyevi bir zihnin yardımıyla normal kontrole tabi değil. Özellikle alt sistem entegrasyonu açısından. Bu, kabulü büyük ölçüde kolaylaştırır. Ana şey, sizin kafanızın karışmaması ve sisteminizin hala olması gerektiği gibi çalışmasıdır.
2. Biz sadece GOST'ları seviyoruz... Ciddi olarak büyük şirketler aşk standartları. Çünkü insanların birbirlerini daha iyi anlamalarına yardımcı olurlar. Müşterinizin düzen ve standardizasyon sevgisi fark edilirse, teknik şartname tarafından gerekli olmasa bile, belgeleri geliştirirken GOST'un standart ideolojisine bağlı kalmaya çalışın. Koordinasyon uzmanları tarafından daha iyi anlaşılacak ve onaylanacaksınız ve belgelere kendiniz dahil etmeyi unutmayacaksınız. önemli bilgi, belgelerin hedef yapısını daha iyi görecek, yazıları üzerindeki çalışmaları daha doğru planlayacak ve kendinizi ve meslektaşlarınızı çok fazla sinir ve paradan kurtaracaksınız.
3. Her şey yolunda giderse belgelerle ilgilenmiyoruz... Kaybolan türden sorumsuz bir müşteri. Benzer bir dokümantasyon görüşü, küçük ve fakir müşteriler arasında ve ayrıca patronun sadık arkadaşlarla çevrili olduğu perestroika'dan kalan otoriter "aptallar" da bulunabilir - yöneticiler ve tüm sorunlar kişisel görüşmelerde çözülür. Bu gibi durumlarda, genel olarak belgeleri unutmakta özgürsünüz, ancak yine de görüşü düşürmemek ve en azından belgeleri şematik olarak içerikle doldurmamak daha iyidir. Bu müşteriye değilse, bir sonrakine devredin (sat).

Çözüm

Bu makale, ACS'yi belgelemek için GOST standartlarımızla ilgiliydi. GOST'ler eskidir, ancak ortaya çıktığı gibi, evde hala çok faydalıdırlar. Bazı bariz esasların dışında, dokümantasyonun yapısı tamlık ve tutarlılık özelliklerine sahiptir ve standarda bağlılık, varlığı ilk başta tahmin bile edemeyeceğimiz birçok proje riskini ortadan kaldırır.

Umarım sunulan materyal sizin için yararlı olmuştur veya en azından ilginç olmuştur. Dış sıkıntıya rağmen, belgeleme, doğruluğun iyi kod yazmak kadar önemli olduğu önemli ve sorumlu bir iştir. Yazı yazmak iyi belgeler, meslektaşlar! ve ben varım gelecek hafta Arka arkaya iki iş gezisine çıkıyorum, bu yüzden yeni materyallerin yayınlanmasını garanti etmiyorum (dükkanım yok, kafamdan yazıyorum).

M. Ostrogorsky, 2008

GOST 34'ü başarıyla uygulamak için, bu standartlar dizisi açısından otomatik bir sistemin nasıl düzenlendiğini anlamak gerekir. Aksi takdirde, gizemli isimlere sahip uzun bir belge listesi dışında misafirlerde hiçbir şey görmeyeceğiz ve içeriklerinin gereklilikleri bizi bir kez daha birçok bilgelikte çok fazla keder olduğuna ikna edecektir. Bu nedenle, belgelerin kendilerini tartışmadan önce, belgeleme konusunu neyin oluşturduğunu anlamalıyız.

Otomatik sistem, işlevleri ve görevleri

Otomatik bir sistemin tanımı

GOST 34.003-90, otomatik bir sistemin aşağıdaki tanımını içerir: yerleşik işlevleri yerine getirmek için bilgi teknolojisini uygulayan, faaliyetleri için personel ve bir dizi otomasyon aracından oluşan bir sistem. Bu tanım pratikte ne anlama geliyor? Bunu ancak bu standardın diğer tanımlarını okuyarak ve birbirleriyle karşılaştırarak anlayabilirsiniz. Şimdi ne yapacağız.

Etkinliğin amaçları

Otomatik bir sistem, yalnızca belirli bir faaliyette bulunan personelin bulunduğu durumlarda var olabilir. Kural olarak, kullanılan araçlardan bağımsız olarak sonuçları birisi için yararlı olan faaliyetlerden bahsediyoruz. Örneğin, bir bilet için gişeye başvuruyorum ve kasiyer antetli kağıda bir kalemle benim için yazsa benim için iyi olurdu, böylece salona kullanmama izin verirdi. Kasiyer, genel olarak, nasıl bilet alınacağını da umursamıyor. Çok zahmetli olmadığı ve bana bilet satma fırsatı sağladığı sürece herhangi bir yöntem ona uyacaktır. Başka bir deyişle, onunla ortak bir hedefimiz var. GOST 34.003-90'da terim, tanımı için kullanılır. faaliyetin amacı... Ne zaman başka bir seyirci elinde bir biletle pencereden uzaklaşsa ve tiyatro biraz daha zenginleşse, bu etkinlik amacına ulaşılır.

Otomatik sistem fonksiyonları

Birkaç faaliyet hedefi olabilir (ve bir kural olarak vardır). Faaliyetin kendisi dışında faydalı olan herhangi bir sonuç, hedef olarak kabul edilebilir. Yani bir kasiyer sadece bilet satmıyor, iş gününün sonunda üstlerine satış raporu da hazırlıyorsa, günlük rapor hazırlamak başka bir faaliyet hedefi olarak kabul edilebilir.

Kasiyer için masaya bir bilgisayar ve bir yazıcı koyarsak ve kasiyer şefi, bir metin düzenleyicide biletleri ve raporları yazması ve bir yazıcıda yazdırması için bir emir verirse, otomatik bir sistem alırız. Modern görüşlere göre, çok ilkeldir, resmi olarak Gost tanımını karşılayacaktır. Lütfen, otomatik sistemin uygulanmasının bir sonucu olarak faaliyetin hedeflerinin değişmediğini, sadece bunlara ulaşmanın yolunun değiştiğini unutmayın. Eskiden "tıpkı böyle" yapılanlar artık otomatik bir sistem çerçevesinde yapılıyor. GOST 34.003-90'a göre belirli bir hedefe ulaşmayı amaçlayan otomatik bir sistemin eylemlerine buna denir. işlev... Not: Ne düşünürseniz düşünün, personel sistemin bir parçası olarak kabul edilir.

Otomatik bir sistemin işlevi, GOST 34'te temel bir kavramdır. Otomatik bir sistem, her şeyden önce, işlevlerinin toplamı olarak ve ancak o zaman bir grup "yazılım" ve "donanım" olarak kabul edilir. En önemlisi, sistemin ne yaptığı ve nelerden oluştuğu ikincildir.

Yukarıdakiler, okuyucuyu, otomatikleştirilmiş bir sistemdeki her bir faaliyet hedefine tek ve yalnızca bir işlevin karşılık geldiği sonucuna götürebilir. Böyle bir sistemi hayal etmek kolaydır, ancak uygulama daha çeşitlidir. Bir yandan, faaliyetler her zaman tam otomatik değildir. Otomatik bir sistemin devreye girmesinden sonra bile, bazı hedeflere manuel olarak ulaşılması gerekiyor. Öte yandan, farklı koşullar altında aynı sonuca ulaşılabildiği için Farklı yollar, örneğin gişede bilet satmak ve İnternette bilet satmak gibi çeşitli işlevler otomatik bir sistemde tek bir faaliyet hedefine yönlendirilebilir. Ek olarak, herhangi bir otomatik sistem belirli bir bakım gerektirir, bu nedenle yardımcı fonksiyon kavramını tanıtmak gerekir. Tipik bir örnek, verileri yedeklemektir.

Otomatik sistemin görevleri

Genel durumda, bir işlevi yerine getirirken, işin bir kısmı personel tarafından yapılır ve işin bir kısmı ekipman tarafından yapılır, örneğin, bir bilet otomatik olarak yazdırılır ve alıcıya kasiyerler tarafından manuel olarak verilir. Belirli bir türün sonucuna yol açan otomatik (sic) eylemlerin sırası GOST 34.003-90'da çağrılır. görev.

Burada sorunun tanımı tam olarak belirtilmiyor, ancak şimdilik bizim için yeterli olacak ve bu, sonuçta kimsenin standardı kendi başına okuması ayıp değil. Görevin, otomatikleştirilmiş aktivitenin en açık şekilde resmileştirilmiş kısmı olması önemlidir. Yukarıda bahsedilen yedekleme gibi tamamen otomatik olarak gerçekleştirilen bir işlev hayal edilebilir. Bu durumda, işlev bir göreve indirgenir.

Aynı görev, farklı işlevler gerçekleştirilerek çözülebilir. Örneğin, otomatik bir sistemin bilet satmak için çeşitli işlevleri varsa, bunların her birinin yürütülmesi bir noktada biletin çıktısını gerektirebilir.

Otomatik sistemin bileşimi

alt sistemler

Otomatik sistem yeterince karmaşıksa, ikiye ayrılır: alt sistemler... Ne anlama geliyor, yeterince zor, söylemesi yeterince zor. Sistem teorisi, farklı karmaşıklık düzeylerini ve kriterlerini tanımlar. Uygulamada, otomatikleştirilmiş bir sistemde birkaç alt sistemi ayırma ihtiyacı, genellikle organizasyonel ve finansal nedenlerden kaynaklanır, örneğin, alt sistemler sırayla geliştirilir ve devreye alınır.

GOST 34'te alt sistem terimi birçok kez kullanılsa da, bu kavramın resmi bir tanımı yok gibi görünmektedir. Deneyimler, bir alt sistemin otomatikleştirilmiş bir sistemin parçası olduğunu ve özellikle otomatik sistem tanımını da karşılayan tam teşekküllü işlevlere sahip olduğunu göstermektedir.

Bilet satışı örneğine dönersek, otomatik sistemin iki alt sistemden oluştuğuna karar verebiliriz: bilet satış alt sistemi ve günlük raporların üretilmesi için alt sistem. Daha fazla netlik için, kasiyerin biletleri bir metin düzenleyicide yazdığını ve elektronik tablolarda rapor verdiğini kabul edelim.

Bileşenler

Faaliyet amaçlarının, otomatikleştirilmiş bir sistemin işlevlerinin ve gerekirse alt sistemlerinin tahsisi, büyük ölçüde özneldir ve bunu yapmaya karar veren konunun bakış açısına bağlı olarak yapılır. Çözülmekte olan problem bağlamında bir sonuç önemliyse, bunu bir hedef olarak kabul edebilir ve aksi takdirde görmezden gelebiliriz. Kararlarımız bu kavramın içeriğiyle çelişmediği sürece, otomatik sistemi de bize uygun olduğu için alt sistemlere ayıracağız.

Bileşenler, nesnel gerçeklikte otomatik bir sistem oluşturduğumuz parçalardır. Sistem fiziksel olarak bileşenlerinden oluşur, bu nedenle otomatikleştirilmiş bir sistemin bileşenlere bölünmesi en objektiftir.

Her bir bileşeni (ekipman ise) satın alır, monte eder ve bağlarız, kurarız (program ise) ve hizmetini diğer bileşenlerden ayrı yaparız. Bir bilgisayar alıp masaya koyduk - bu bir bileşen. Bir dizi bilet için özel bir metin düzenleyici geliştirdik - başka bir bileşen. İnternetten indirilen ücretsiz elektronik tablolar - yine bir bileşen. Ve hatta kasiyerin kendisi de bir şekilde otomatikleştirilmiş bir sistemin bir parçasıdır.

Otomatikleştirilmiş bir sistemin bileşen bileşimi, sistem için teknik belgeler ve bileşenler farklı şekilde ele alındığından, belgeleri açısından çok önemlidir. Genel olarak, geliştirilmelidir. farklı insanlar, ve bileşen tipine bağlı olarak farklı standartlara göre tasarlanmıştır.

Teminat türleri

Acemi bir GOST 34 kullanıcısı için en zor kavramlardan biri güvenlik türü... Bu nasıl bir güvenlik? Görebilir veya dokunabilir misin? Satmak mı, Almak mı?

Her destek türü, belirli bir yapıya sahip bileşenleri veya teknik çözümleri birleştirir. GOST 34 çok şey anlatıyor farklı şekiller Burada her birini tutarlı bir şekilde tanımlamayacağız, sadece en dikkat çekici olanları listeleyeceğiz:

• bilgi desteği - sistemin çalıştığı tüm veriler ve meta veriler;
• yazılım - sistemin parçası olan tüm programlar;
• teknik destek - sistemin parçası olan tüm teknik araçlar (diğer bir deyişle ekipman, aparat).

Bir kez daha tekrarlıyoruz, bunlar her tür teminat değildir. Bunların en önemlileri olduğunu kesin olarak bile söyleyemeyiz. Örneğin, otomatik proses kontrol sistemleri (APCS) için büyük bir değer metrolojik desteğe sahiptir. Birçok otomatik sistem, karmaşık matematiksel ve dilsel destek gerektirir. Ancak yukarıda listelenen üç destek türünden birinden tamamen yoksun olacak otomatik bir sistem hayal etmek zordur (alıştırma: deneyin).

Tanıtım

Modern dünyada her gün onlarca ve yüzlerce farklı program, uygulama, bilgi sistemi karşımıza çıkıyor. Genel kullanıcılar için olduğu kadar kamu veya ticari sektör için de tasarlanabilirler. Tüm kullanıcıların %90'ı belgeleri okumuyor, sıkıcı, sıkıcı ve ilgi çekici bulmuyor ve kullanım kılavuzunu yalnızca bir şey yolunda gitmediğinde veya talimat olmadan çözmenin kesinlikle imkansız olduğu durumlarda açıyor. Artık, kullanıcı arayüzünü sezgisel olacak şekilde oluşturmak genel olarak kabul edilmektedir ve kullanıcı, uzun kılavuzları okumak zorunda kalmadan sistemi anlayabilir. Bununla birlikte, büyük müşterilerle çalışırken, GOST'a göre hazırlanmış kılavuzlar, talimatlar, tasarım çözümleri gibi belirli bir belge paketi sunmak neredeyse her zaman gereklidir.
GOST'a uygun belge yazımı ile ilk karşılaştığınızda, bu GOST'ler "deniz" olduğundan ve onlar hakkında nasıl ve ne yazılacağı belirsiz hale geldiğinden, bir şaşkınlık ve tam bir şok yaşarsınız.
Bu makale, belge yazmak için GOST'leri ve ana noktalarını tartışmaktadır.

GOST'ler nelerdir?

İlk önce GOST'lerin ne olduğunu bulmanız gerekir. Herkes GOST'un Birlik altında geliştirilen bir şey olduğunu biliyor ve sonsuz sayıda var. BT sektörü için çok fazla GOST standardı olmadığını ve bunların hepsinin yaratılma zamanlarına rağmen alakalarını kaybetmediğini size temin etmek için acele ediyorum.
Her şeyden önce, belge yazma standartları iki türe ayrılır:

1. Uluslararası standartlar (ISO, IEEE Std);
2. Rus veya Sovyet GOST'leri.

Uluslararası standartlar
Uluslararası düzeyde dokümantasyon geliştirmek için uluslararası standartlar kullanılır. Kural olarak, devlet kurumları tarafından geliştirilmediği için özgür değiller, ancak bizimkinin aksine oldukça yakın zamanda geliştirildiler. Tema Uluslararası standartlarçok geniş, bu yüzden başka bir makalede ele alınacaktır. Belgelerin yazılmasıyla yakından ilgili olan birkaç standarda hemen değinilir.
Belge yazmak için başlıca uluslararası standartların listesi:

1. IEEE Std 1063-2001 "Yazılım Kullanıcı Belgeleri için IEEE Standardı" - bir kullanım kılavuzu yazmak için bir standart;
2. IEEE Std 1016-1998 "Yazılım Tasarım Açıklamaları için IEEE Önerilen Uygulama" - bir programın teknik açıklamasını yazmak için bir standart;
3. ISO / IEC FDIS 18019: 2004, "Uygulama yazılımı için kullanıcı belgelerinin tasarımı ve hazırlanmasına ilişkin yönergeler", kullanım kılavuzları yazmak için başka bir standarttır. Bu belgede çok sayıdaörnekler. Yani daha çok kullanım kılavuzu yazmak için bir kılavuza benziyor. Yeni başlayanlar özellikle faydalı olacaktır;
4. ISO / IEC 26514: 2008, Kullanıcı dokümantasyonu tasarımcıları ve geliştiricileri için gereksinimler, kullanıcı dokümantasyonu tasarımcıları ve geliştiricileri için başka bir standarttır.

Aslında, aynı standart hem Avrupalı ​​hem de Asyalı şirketler için her zaman uygun olmayabileceğinden, birçok uluslararası standart vardır ve her ülkede farklıdır.

Rus standartları
Rus standartları devlet düzeyinde geliştirilmektedir. Hepsi tamamen ücretsizdir ve hepsini internette bulmak kolaydır. Program için dokümantasyon yazmak için iki seri GOST 19 ve 34 kullanılır, daha sonra tartışılacak olan onlar hakkındadır.

19 ve 34 serilerinin GOST'leri arasındaki fark nedir?

Ortaya çıkan ilk soru, genel olarak bu GOST 19 ve 34'ün birbirinden nasıl farklı olduğudur.
GOST 19.781-90 “Birleşik program dokümantasyonu sistemi. Bilgi işleme sistemleri yazılımı. Terimler ve tanımlar "tanımlar belirtilmiştir:

1. Program - belirli bir algoritmayı uygulamak için bir bilgi işleme sisteminin belirli bileşenlerini kontrol etmeyi amaçlayan veriler.
2. Yazılım - bilgi işlem sisteminin bir dizi programı ve bu programların çalışması için gerekli program belgeleri.

GOST 34.003-90'da “Bilgi teknolojisi. Otomatik sistemler için standartlar seti. Otomatik sistemler. Terimler ve tanımlar "tanım belirtilir:

1. Otomatik sistem (AS), yerleşik işlevleri yerine getirmek için bilgi teknolojisini uygulayan, faaliyetlerini otomatikleştirmek için personel ve bir araç kompleksinden oluşan bir sistemdir.
   Faaliyet türüne bağlı olarak, örneğin, aşağıdaki AU türleri ayırt edilir: otomatik kontrol sistemleri (ACS), bilgisayar destekli tasarım sistemleri (CAD), otomatik sistemler bilimsel araştırma(ASNI) ve diğerleri.

Kontrol edilen nesnenin (süreç) türüne bağlı olarak ACS, örneğin: Teknolojik süreçlere göre ACS (ACS), işletmelere göre ACS (ACS), vb.
Ayrıca GOST 34, NPP desteği türlerine ayrılmıştır:

1. organizasyonel;
2. metodik;
3. Teknik;
4. Matematiksel;
5. Yazılım;
6. Bilgilendirici;
7. Dilbilimsel;
8. Yasal;
9. Ergonomik.

Sonuç olarak, Otomatik Sistem bir program değil, yazılım da dahil olmak üzere bir dizi destek türüdür. AS, kural olarak, belirli bir kullanıcı ve müşteri için kurumsal bir çözüm taşır ve Program, herhangi bir kuruluşa bağlı olmaksızın çok sayıda kullanıcı için oluşturulabilir ve çoğaltılabilir.
Bu nedenle, belirli bir işletme için oluşturduğunuz bir program için belgeler geliştiriyorsanız, GOST 34'ünüz. Toplu bir program için belgeler yazıyorsanız, GOST 19'unuz.

34

GOST 34 serisi (GOST 34.xxx Bilgi teknolojisi standartları) şunlardan oluşur:

1. GOST 34.201-89 Otomatik sistemler oluştururken belgelerin türleri, eksiksizliği ve tanımları - bu standart, belge türlerini, adını, eksiksizliğini ve sayısını belirler. GOST 34 serisinin ana belgelerinden biridir.Aslında, temel bir belgedir, bu nedenle yeni başlayanlar önce ona aşina olmalıdır.
2. GOST 34.320-96 Kavramsal bir diyagram için kavramlar ve terminoloji ve bilgi tabanı- bu Uluslararası Standart, kavramsal şemaların ve bilgi temellerinin geliştirilmesini, tanımlanmasını ve uygulanmasını, bilgilerin manipüle edilmesini ve ayrıca bilgi sürecinin tanımını ve uygulanmasını kapsayan kavramsal şemalar ve bilgi temellerinin temel kavramlarını ve terimlerini belirler. Standart, kavramsal şemanın rolünü tanımlar. İçinde ana hatları verilen hükümler, doğası gereği tavsiye niteliğindedir ve veritabanı yönetim sistemlerini (DBMS) değerlendirmek için kullanılabilir. Bu belge, kavramsal şema destek araçlarını kullanmaya yönelik belirli yöntemleri açıklamamaktadır. Standartta açıklanan kavramsal şema dilleri standart kabul edilmemelidir.
3. GOST 34.321-96 Bilgi teknolojisi. Veritabanı standartları sistemi. Yönetim Referans Modeli - Bu belge, bir veri yönetimi referans modeli oluşturur.
   Referans Modeli, bilgi sistemleri verileriyle ilgili genel terminolojiyi ve kavramları tanımlar. Bu tür kavramlar, veritabanı yönetim sistemleri veya veri sözlüğü sistemleri tarafından sağlanan hizmetleri tanımlamak için kullanılır.
   Referans model, veri yönetimi için protokolleri dikkate almaz.
   Referans modelin kapsamı, kalıcı verilerin yönetimi ile ilgili süreçleri ve bunların belirli bir sistemin gereksinimlerinden farklı olan süreçlerle etkileşimini içerir. bilgi sistemi yanı sıra verilerin tanımlanması, depolanması, aranması, güncellenmesi, girilmesi, kopyalanması, geri yüklenmesi ve aktarılması için genel veri yönetimi hizmetleri.
4. GOST 34.601-90 Otomatik sistemler. Yaratmanın aşamaları - standart, bir konuşmacı yaratmanın aşamalarını ve aşamalarını belirler.
5. GOST 34.602-89 Otomatik bir sistemin oluşturulması için referans şartları (GOST 24.201-85 yerine) - "Sistemin oluşturulması (geliştirilmesi veya modernizasyonu) için referans şartları" belgesinin hazırlanması için kompozisyon, içerik ve kuralları belirler "
   Bu belge, GOST 34 serisinin en sık kullanılan belgelerinden biridir.Bu GOST'a göre TK geliştirirken, bu belge bu standartlara referanslar içermese bile, diğer standartları hatırlamak gerekir.
6. GOST 34.603-92 Bilgi teknolojisi. Otomatik sistem test türleri - standart, nükleer santraller için test türlerini (otonom, entegre, kabul testleri ve deneme işletimi) ve bunların yürütülmesi için genel gereksinimleri belirler.
7. RD 50-34.698-90 Otomatik sistemler. Belgelerin içeriğine ilişkin gereksinimler, 34 GOST'nin en önemli belgelerinden biridir, çünkü içinde neredeyse tüm belgelerin içeriğinin yanı sıra belgenin her bir paragrafının bir açıklaması açıklanmaktadır.
8. GOST R ISO / IEC 8824-3-2002 Bilgi teknolojisi. Soyut Sözdizimi Gösterimi Sürüm Bir — Bu Uluslararası Standart, Soyut Sözdizimi Gösterimi 1'in (ASN.1) bir parçasıdır ve kullanıcı tanımlı kısıtlamaları ve tablo kısıtlamalarını belirtmek için bir gösterim sağlar.
9. GOST R ISO / IEC 10746-3-2001 Veri yönetimi ve açık dağıtılmış işleme.
   Bu standartta:
   • GOST R ISO/IEC 10746-2'de tanıtılan kavramlar kullanılarak açık dağıtılmış işleme (ODP) sistemlerinin nasıl belirlendiği belirlenir;
   • sistemlerin ODP sistemleri olarak sınıflandırıldığı özellikler tanımlanır.

   Standart, ODP sistemleri için standartların geliştirilmesini koordine etmek için bir çerçeve oluşturur.

10. GOST R ISO / IEC 15271-02 Yazılım yaşam döngüsü süreçleri - bu GOST, bence, nükleer santrallerin tasarımı ve modellemesindeki analistler için daha fazla gereklidir.
    Bu belge, benim açımdan, tamamen eğitim amaçlıdır.
11. GOST R ISO / IEC 15910-2002 Bir yazılım aracı için kullanıcı dokümantasyonu oluşturma süreci - kullanıcı arayüzüne sahip bir yazılım aracı için her türlü kullanıcı dokümantasyonunu oluşturmak için gereken minimum süreci tanımlar. Bu görünümler basılı belgeleri (örneğin, kullanıcı kılavuzları ve hızlı başvuru kartları), çevrimiçi (çevrimiçi) belgeleri, yardım metnini ("yardım") ve çevrimiçi belge sistemlerini kapsar.

Bu nedenle, yukarıda yazılanlara dayanarak, 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 ve GOST 34.602-89'daki ana belgelerin olduğu açıktır.
Bir belge paketi geliştirirken, önce GOST 34.201-89'u açmanız ve Taslak tasarım, Teknik tasarım ve Çalışma belgeleri oluşturma aşamasını seçmeniz gerekir. Ardından, geliştirme aşamasına karşılık gelen geliştirme için belgeler seçmelisiniz.

Belgelerin listesi 34 GOST

Sahne yaratılış	Belgenin başlığı	kod	Bölüm proje	Prinad yatak ile proje ama tahmin nuh rıhtım polis syonlar	Prinad yatak ile sömürmek istasyon nuh yukarı kümen tarifler	Ek talimatlar
EP	Zamanlama tasarım sayfası	EP *	VEYA	—	—	—
	Açıklayıcı not Taslak tasarıma	P1	VEYA	—	—	—
EP, TP	Organizasyon şeması	CO	VEYA	—	—	P3 veya PV belgesine dahil edilmesine izin verilir
	Kompleksin yapısal şeması teknik araçlar	C1 *	SONRA	NS	—
	Fonksiyonel yapı şeması	C2 *	VEYA	—	—	ES aşamasında CO, C1, C2, C3 belgelerini geliştirirken, bunların P1 belgesine dahil edilmesine izin verilir.
	uzman (yeni) teknik araçlar	9'DA	SONRA	NS	—	TP aşamasında gelişirken dahil edilmesine izin verildi P2'yi belgelemek
	otomasyon şeması	C3 *	SONRA	NS	—	—
	Geliştirme için referans şartları uzman (yeni) teknik araçlar	—	SONRA	—	—	Proje şunları içermiyor
TP	Geliştirme atamaları sıhhi ve diğer bölümler proje ile ilgili Sistemin oluşturulması ile	—	SONRA	NS	—	Proje şunları içermiyor
	Teknik proje sayfası	TP *	VEYA	—	—	—
	Satın alınan ürünlerin listesi	Başkan Yardımcısı *	VEYA	—	—	—
	Giriş sinyallerinin listesi ve veri	1 İÇİNDE	VE HAKKINDA	—	—	—
	Çıkış sinyallerinin listesi (belgeler)	2 İÇİNDE	VE HAKKINDA	—	—	—
	Geliştirme görevlerinin listesi inşaat, elektrik, sıhhi ve diğer bölümler proje ile ilgili Sistemin oluşturulması ile	3'TE	SONRA	NS	—	P2 belgesine dahil edilmesine izin verilir
	Açıklayıcı not teknik projeye	P2	VEYA	—	—	Eylem planı içerir nesneyi devreye alma için hazırlamak çalışan sistemler
	Otomatik açıklama fonksiyonlar	P3	VEYA	—	—	—
	Görev ayarının açıklaması (görev seti)	P4	VEYA	—	—	Dahil edilmesine izin verilir P2 veya P3 belgelerine
	Bilgi açıklaması sistem desteği	P5	VE HAKKINDA	—	—	—
	Kuruluşun açıklaması bilgi tabanı	P6	VE HAKKINDA	—	—	—
TP	Sınıflandırma sistemlerinin tanımı ve kodlama	P7	VE HAKKINDA	—	—	—
	Dizi açıklaması bilgi	P8	VE HAKKINDA	—	—	—
	Kompleksin açıklaması teknik araçlar	P9	SONRA	—	—	Görev için GOST 19.101'e göre 46 belgesine dahil edilmesine izin verilir.
	Yazılımın açıklaması güvenceye almak	PA	ÜZERİNDE	—	—	—
	Algoritma açıklaması (tasarım prosedürü)	PB	MO	—	—	P2, P3 veya P4 belgelerine dahil edilmesine izin verilir
	Organizasyonun tanımı yapılar	PV	OO	—	—	—
	Vaziyet planı	C8	SONRA	NS	—	P9 belgesine dahil edilmesine izin verilir
	Ekipman listesi ve malzemeler	—	SONRA	NS	—	—
	Yerel tahmin hesaplaması	B2	VEYA	NS	—	—
TP, RD	Proje değerlendirmesi sistem güvenilirliği	B1	VEYA	—	—	—
	Belge formu çizimi (video çerçevesi)	C9	VE HAKKINDA	—	NS	TP aşamasında, izin verilir belgelere dahil etmek P4 veya P5
RD	Sahipler listesi orijinaller	DP *	VEYA	—	—	—
	Operasyonel beyan belgeler	ED *	VEYA	—	NS	—
	Donanım Spesifikasyonu	AT 4	SONRA	NS	—	—
	Gereksinim beyanı malzemelerde	AT 5	SONRA	NS	—	—
	Makine Medya Listesi bilgi	sanal makine *	VE HAKKINDA	—	NS	—
	Giriş veri dizisi	6'DA	VE HAKKINDA	—	NS	—
RD	Veritabanı dizini	7'DE	VE HAKKINDA	—	NS	—
	Çıktının bileşimi (mesajlar)	8'DE	VE HAKKINDA	—	NS	—
	Yerel tahminler	B3	VEYA	NS	—	—
	Yöntem (teknoloji) otomatik tasarlamak	I1	OO	—	NS	—
	teknolojik talimat	VE 2	OO	—	NS	—
	Kullanici rehberi	I3	OO	—	NS	—
	Şekillendirme talimatları ve veritabanı Bakımı (veri kümesi)	I4	VE HAKKINDA	—	NS	—
	KTS için çalıştırma talimatları	IE	SONRA	—	NS	—
	Harici kablo bağlantı şeması	C4 *	SONRA	NS	—	içinde gerçekleştirmesine izin verilir. tablolar şeklinde
	Bağlantı şeması harici kablolama	C5 *	SONRA	NS	—	Ayrıca
	Bağlantı ve bağlantı tablosu	C6	SONRA	NS	—	—
	Sistem bölme şeması (yapısal)	E1 *	SONRA	—	—	—
	Genel düzenleme çizimi	İÇİNDE*	SONRA	NS	—	—
	Teknik ekipman kurulum çizimi	CA	SONRA	NS	—	—
	Şematik diyagram	Oturdu	SONRA	NS	—	—
	Kompleksin yapısal şeması teknik araçlar	C1 *	SONRA	NS	—	—
	Ekipman yerleşimi ve kablolama	C7	SONRA	NS	—	—
	Teknolojik açıklama işleme süreci veriler (dahil teleişleme)	PG	OO	—	NS	—
	Sistemin genel açıklaması	PD	VEYA	—	NS	—
	Test programı ve metodolojisi (bileşenler, otomasyon sistemleri, alt sistemler, sistemler)	ÖĞLEDEN SONRA *	VEYA	—	—	—
	Biçim	FD *	VEYA	—	NS	—
	Pasaport	not *	VEYA	—	NS	—
* Kodu ESKD standartlarının gerekliliklerine uygun olarak belirlenmiş belgeler

Tabloya not:

1. Tablo aşağıdaki tanımlamaları kullanır:
   • EP - taslak tasarım;
   • TP - teknik tasarım;
   • RD - çalışma belgeleri;
   • VEYA - sistem çapında çözümler;
   • OO - organizasyonel destek çözümleri;
   • K - teknik destek için çözümler;
   • IO - bilgi desteği için çözümler;
   • Yazılım - yazılım çözümleri;
   • MO - yazılım çözümleri.
2. X işareti - tasarım tahminlerine veya operasyonel belgelere ait olduğunu belirtir.
3. Bir isimdeki belgelerin isimlendirilmesi, sistem oluşturulurken alınan tasarım kararlarına bağlı olarak belirlenir.

Belge listesi belirlendiğinde, RD 50-34.698-90'da seçilen belgeleri bulmalı ve kesinlikle belirtilen noktalara göre geliştirmelisiniz. Belirtilen içeriğin tüm noktaları belgede olmalıdır.
Bir Görev Tanımı geliştiriliyorsa, hemen GOST 34.602-89'u açmanız ve kesinlikle paragraflara göre teknik bir şartname geliştirmeniz gerekir.

GOST 19

GOST 19 serisi (GOST 19.xxx Birleşik Programlama Dokümantasyon Sistemi (ESPD)) şunlardan oluşur:

1. 1. GOST 19.001-77 Genel hükümler - çok genel bir belge, pratik değil. Bu nedenle, atlayabilirsiniz.
   2. GOST 19781-90 Terimler ve tanımlar - iyi liste bilgi işleme sistemleri için yazılım alanındaki tanımlar. Tanımlar dışında başka bir şey içermez.
   3. GOST 19.101-77 Program türleri ve program belgeleri - 19 GOST'un ana belgelerinden biri. GOST belgelerinin tam bir listesini ve tanımlarını içerdiğinden, 19 GOST ile çalışmaya başlamalısınız.

Belgelerin listesi 19 GOST

kod	Belge türü	Geliştirme aşamaları
		Kroki proje	Teknik proje	Çalışma taslağı
				bileşen	karmaşık
—	Şartname	—	—
05	Orijinal sahiplerinin listesi	—	—	—
12	Program metni	—	—
13	Program Açıklaması	—	—
20	Operasyonel belgelerin beyanı	—	—
30	Biçim	—	—
31	Uygulama Açıklaması	—	—
32	Sistem Programcısı Kılavuzu	—	—
33	Programcı Kılavuzu	—	—
34	Kullanım klavuzu	—	—
35	Dil Açıklama	—	—
46	Teknik Kılavuz bakım	—	—
51	Test programı ve metodolojisi	—	—
81	Açıklayıcı not			—	—
90-99	Diğer belgeler

Efsane:
- belge zorunludur;
- bağımsız kullanıma sahip bileşenler için belge zorunludur;
- teknik görevin geliştirilmesi ve onaylanması aşamasında bir belge hazırlama ihtiyacı belirlenir;
- - belge düzenlenmemiştir.

1. GOST 19.102-77 Geliştirme aşamaları - geliştirme aşamalarının bir tanımını içerir. Eğitim amaçlı faydalıdır. Benim düşünceme göre, özellikle pratik bir faydası yok.
2. GOST 19.103-77 Programların ve program belgelerinin belirlenmesi - bir belgeye bir sayının (kod) atanmasının bir tanımını içerir. Bu GOST'u okuduktan sonra bile, bu sayının bir belgeye nasıl atanacağı hakkında bir sürü soru var.
3. GOST 19.104-78 Ana yazıtlar - uygulama yöntemlerinden bağımsız olarak, onay sayfasının ana yazılarını ve ESPD standartları tarafından sağlanan program belgelerindeki başlık sayfasını doldurmak için formları, boyutları, yeri ve prosedürü belirler. 19 GOST belgeleri çerçeveler halinde düzenlendiğinden bu belge çok önemlidir.
4. GOST 19.105-78 Program belgeleri için genel şartlar - program belgelerinin tasarımı için genel şartları belirler. Gereksinimler çok genel. Kural olarak, bu GOST bir belgenin geliştirilmesi için neredeyse hiç kullanılmaz, çünkü bir belge için yeterli özel GOST vardır, ancak bu GOST'ta genel bilgi için bir kez bakmak daha iyidir.
5. GOST 19.106-78 Basılı program belgeleri için gereksinimler - GOST 19'un tüm belgelerinin tasarımı için gereksinimleri içerir.
6. GOST 19.201-78 Başvuru koşulları, içerik ve tasarım gereksinimleri - bir program veya yazılım ürününün geliştirilmesi için teknik özelliklerin oluşturulması ve yürütülmesi için prosedürü belirler.

   GOST'un TK 34'ü ve GOST'un 19'u hükümleri farklıdır.

7. GOST 19.601-78 Çoğaltma, muhasebe ve depolama için genel kurallar - Genel kurallar program belgelerinin çoğaltılması, dolaşımı, muhasebeleştirilmesi ve saklanması. GOST'ta, birkaç paragrafta, belgelerin kaybolmadığından nasıl emin olunacağı açıklanmaktadır.
8. GOST 19.602-78 Program belgelerinin çoğaltılması, muhasebeleştirilmesi ve saklanması için kurallar, tamamlanmış baskı. Bu arada - GOST 19.601-78'e ek.
9. GOST 19.603-78 Değişiklik yapmak için genel kurallar - program belgelerinde değişiklik yapmak için genel kurallar belirler. Özünde, belgelerde değişiklik yapmak için uzun bir bürokratik algoritmayı tanımlar.
10. GOST 19.604-78 Basılı olarak yapılan program belgelerinde değişiklik yapma kuralları - Listeden Değişiklik Kayıt Sayfasını çalışma ve doldurma prosedürünü açıklar.

Özel GOST'lerin bir listesi, yani her biri belirli bir belgenin içeriğini ve gereksinimlerini açıklar:

1. GOST 19.202-78 Spesifikasyonu. İçerik ve tasarım gereksinimleri;
2. GOST 19.301-79 Program ve test prosedürü. İçerik ve tasarım gereksinimleri;
3. GOST 19.401-78 Program metni. İçerik ve tasarım gereksinimleri;
4. GOST 19.402-78 Programın tanımı;
5. GOST 19.403-79 Orijinal sahiplerin listesi;
6. GOST 19.404-79 Açıklayıcı not. İçerik ve tasarım gereksinimleri;
7. GOST 19.501-78 Formu. İçerik ve tasarım gereksinimleri;
8. GOST 19.502-78 Uygulamanın tanımı. İçerik ve tasarım gereksinimleri;
9. GOST 19.503-79 Sistem Programcı Kılavuzu. İçerik ve tasarım gereksinimleri;
10. GOST 19.504-79 Programcı Kılavuzu. İçerik ve tasarım gereksinimleri;
11. GOST 19.505-79 Kullanım kılavuzu. İçerik ve tasarım gereksinimleri;
12. GOST 19.506-79 Dilin tanımı. İçerik ve tasarım gereksinimleri;
13. GOST 19.507-79 Operasyonel belgelerin beyanı;
14. GOST 19.508-79 Bakım Kılavuzu. İçerik ve tasarım gereksinimleri.

19 GOST ile çalışma prosedürü:

1. GOST 19.101-77'de, geliştirme aşamasına göre bir belge ve kodunu seçin.
2. GOST 19.103-77'ye göre belgeye bir numara atayın.
3. Ardından, GOST 19.104-78 ve 19.106-78'e göre bir belge hazırlayın.
4. Özel bir GOST listesinden, geliştirilmekte olan belgeye karşılık gelen birini seçmelisiniz.

Çözüm

GOST korkutucu ve kolay değil! Ana şey, neyin yazılması gerektiğini ve bunun için hangi GOST'un kullanıldığını anlamaktır. Belge yazmak için ana GOST 19 ve 34'lerimiz çok eskidir, ancak hala bu günle ilgilidir. Standarda uygun dokümantasyon yazmak, müteahhit ile müşteri arasındaki birçok soruyu ortadan kaldırır. Bu nedenle zamandan ve paradan tasarruf sağlar.

Tanıtım tarihi 01.01.92

Bu standart, aşağıdaki alanlarda kullanılan otomatik sistemlere (AS) uygulanır. farklı şekiller organizasyonlarda, derneklerde ve işletmelerde (bundan böyle organizasyonlar olarak anılacaktır) oluşturulan kombinasyonları da dahil olmak üzere faaliyetler (araştırma, tasarım, yönetim, vb.).

Standart, bir konuşmacı yaratmanın aşamalarını ve aşamalarını belirler. Ek 1, her aşamadaki çalışmanın içeriğini içerir.

1. Genel Hükümler

2. Bir konuşmacı yaratmanın aşamaları ve aşamaları

Ek 1 (referans)

Ek 2 (referans)

1. GENEL HÜKÜMLER

1.1. uygulanması, belirtilen gereksinimleri karşılayan bir AU oluşturmak için gerekli ve yeterli olan, işin aşamaları ve aşamalarında birleştirilmiş, zamana göre düzenlenmiş, birbirine bağlı bir dizidir.

1.2. Bir AU oluşturmanın aşamaları ve aşamaları, belirli bir sonuçla biten, rasyonel planlama ve işin organizasyonu nedenleriyle oluşturma sürecinin bir parçası olarak ayırt edilir.

1.3. AU'nun geliştirilmesi ile ilgili çalışmalar, AU'yu oluşturmak için kullanılan aşamalara ve aşamalara göre gerçekleştirilir.

1.4. Bu standart tarafından belirlenen aşamalarda ve aşamalarda iş yapmak için kompozisyon ve kurallar, belirli tipte nükleer santrallerin oluşturulmasında yer alan kuruluşların ilgili belgelerinde belirlenir.

AU'nun oluşturulması çalışmalarına katılan kuruluşların listesi Ek 2'de verilmiştir.

2. AU'NUN YARATILIŞININ AŞAMALARI VE AŞAMALARI

2.1. Genel durumda bir AU oluşturmanın aşamaları ve aşamaları tabloda gösterilmiştir.

Aşamalar	İşin aşamaları
1. AU için gereksinimlerin oluşumu	1.1. Bir nükleer santral oluşturma ihtiyacının saha araştırması ve gerekçesi
	1.2. Konuşmacı için kullanıcı gereksinimlerinin oluşumu
	1.3. Yapılan çalışma hakkında bir raporun kaydı ve AU'nun geliştirilmesi için bir başvuru (taktik ve teknik görev)
2. AU konseptinin geliştirilmesi	2.1. Nesnenin incelenmesi
	2.2. Gerekli araştırma çalışmalarını yürütmek
	2.3. Hoparlör konsepti için seçeneklerin geliştirilmesi ve hoparlör konseptinin kullanıcının gereksinimlerini karşılayan bir versiyonunun seçimi
	2.4. Yapılan iş hakkında bir raporun kaydı
3. Referans Şartları	3.1. Bir AU'nun oluşturulması için teknik özelliklerin geliştirilmesi ve onaylanması
4. Taslak proje	4.1. Sistem ve parçaları için ön tasarım çözümlerinin geliştirilmesi
	4.2. Nükleer santral ve parçaları için belgelerin geliştirilmesi
5. Teknik tasarım	5.1. Sistem ve parçaları için tasarım çözümlerinin geliştirilmesi
	5.2. Nükleer santral ve parçaları için belgelerin geliştirilmesi
	5.3. AU ve (veya) geliştirmeleri için teknik gereksinimlerin (teknik şartnamelerin) tamamlanması için ürünlerin temini için belgelerin geliştirilmesi ve yürütülmesi
	5.4. Otomasyon nesnesinin projesinin bitişik bölümlerinde tasarım atamalarının geliştirilmesi
6. Çalışma belgeleri	6.1. Sistem ve parçaları için çalışma belgelerinin geliştirilmesi
	6.2. Programların geliştirilmesi veya uyarlanması
7. Eyleme geçirmek	7.1. NPP devreye alma için otomasyon nesnesinin hazırlanması
	7.2. Personel eğitimi
	7.3. Hoparlör sisteminin tedarik edilen ürünlerle (yazılım ve donanım, yazılım ve donanım kompleksleri, bilgi ürünleri) tamamlanması
	7.4. İnşaat ve montaj işleri
	7.5. Devreye alma işleri
	7.6. Ön testler
	7.7. Deneme işlemi
	7.8. Kabul testleri
8. AU'nun Eşliği	8.1. Garanti yükümlülüklerine uygun olarak işin yapılması
	8.2. garanti sonrası servis

2.2. Kuruluşlar tarafından gerçekleştirilen aşamalar ve aşamalar - AU'nun oluşturulması çalışmalarına katılanlar, bu standarda dayanan sözleşmelerde ve görev tanımlarında belirlenir.

"Taslak tasarım" aşamasını ve tüm aşamalarda ayrı çalışma aşamalarını hariç tutmasına, "Teknik tasarım" ve "Çalışma dokümantasyonu" aşamalarını bir aşamada "Teknik tasarım" da birleştirmesine izin verilir. Oluşturulan nükleer sistemlerin özelliklerine ve bunların yaratılma koşullarına bağlı olarak, önceki aşamaların tamamlanmasından önce, iş aşamalarının zamanında yürütülmesine, yeni iş aşamalarının dahil edilmesine paralel olarak, işin bireysel aşamalarını gerçekleştirmesine izin verilir. .

EK 1 Referans

1. Aşama 1.1'de "Tesisin incelenmesi ve bir nükleer santral oluşturma ihtiyacının gerekçesi", genel durumda aşağıdakileri gerçekleştirin:

• otomasyon nesnesi ve yürütülen faaliyetler hakkında veri toplanması;
• nesnenin kalitesinin ve yürütülen faaliyetlerin değerlendirilmesi, otomasyon yoluyla çözümü mümkün olan sorunların belirlenmesi;
• bir AU yaratmanın fizibilitesinin değerlendirilmesi (teknik, ekonomik, sosyal vb.).

2. Aşama 1.2'de "AU için kullanıcı gereksinimlerinin oluşturulması" aşağıdakileri gerçekleştirin:

• AU için gereksinimlerin oluşturulması için ilk verilerin hazırlanması (otomasyon nesnesinin özellikleri, sistem gereksinimlerinin tanımı, geliştirme, devreye alma ve çalıştırma için izin verilen maliyetlerin sınırlandırılması, sistemden beklenen etki, oluşturma koşulları ve sistemin çalışması);
• AU için kullanıcı gereksinimlerinin formülasyonu ve yürütülmesi.

3. "Yapılan çalışma hakkında bir raporun yürütülmesi ve bir AU'nun geliştirilmesi için bir başvuru (taktik ve teknik görev)" aşamasında, bu aşamada gerçekleştirilen çalışma hakkında bir rapor hazırlanır ve geliştirilmesi için bir başvuru bir AU (taktik ve teknik atama) veya onun yerine geçen başka bir belge benzer içerikle hazırlanır.

4. 2.1 "Nesnenin incelenmesi" ve 2.2 "Gerekli araştırma çalışmasının gerçekleştirilmesi" aşamalarında, geliştirici kuruluş, otomasyon nesnesinin ayrıntılı bir çalışmasını ve yol bulma ve olasılık değerlendirme ile ilgili gerekli araştırma çalışmasını (Ar-Ge) yürütür. kullanıcı gereksinimlerini uygulamak, araştırma raporları hazırlamak ve onaylamak.

5. Aşama 2.3 "AU konsepti için seçeneklerin geliştirilmesi ve AU konseptinin kullanıcının gereksinimlerini karşılayan bir versiyonunun seçimi" aşamasında, genel durumda, alternatif seçenekler oluşturulan AU kavramı ve bunların uygulanması için planlar; değerlendirme gerekli kaynaklar bunların uygulanması ve işleyişinin sağlanması için; her seçeneğin avantaj ve dezavantajlarının değerlendirilmesi; önerilen sistem ve seçimin kullanıcı gereksinimlerinin ve özelliklerinin karşılaştırılması en iyi seçenek; sistem kabulünün kalitesini ve koşullarını değerlendirme prosedürünün belirlenmesi; sistemden alınan etkilerin değerlendirilmesi.

6. 2.4 "Yapılan işe ilişkin raporun yürütülmesi" aşamasında, aşamada gerçekleştirilen çalışmanın bir tanımını, sistem kavramının önerilen versiyonunun bir tanımını ve gerekçesini içeren bir rapor hazırlayın ve hazırlayın.

7. Aşama 3.1 "NPP'nin oluşturulması için görev tanımlarının geliştirilmesi ve onaylanması" NPP için görev tanımlarının ve gerekirse NPP kısmı için görev tanımlarının geliştirilmesi, yürütülmesi, koordinasyonu ve onaylanması gerçekleştirilir.

8. Aşama 4.1'de "Sistem ve parçaları için ön tasarım çözümlerinin geliştirilmesi" şunları belirler: AU'nun işlevleri; alt sistemlerin işlevleri, amaçları ve etkileri; görev kümelerinin ve bireysel görevlerin bileşimi; bilgi tabanı kavramı, genişletilmiş yapısı; veritabanı yönetim sistemi işlevleri; bilgi işlem sisteminin bileşimi; ana yazılım araçlarının işlevleri ve parametreleri.

9. "Sistem ve parçaları için tasarım çözümlerinin geliştirilmesi" aşamasında, sistem ve parçaları için genel çözümlerin geliştirilmesini, sistemin işlevsel ve algoritmik yapısını, personelin işlevleri için ve örgütsel yapı, teknik araçların yapısı, problem çözme algoritmaları ve kullanılan diller, bilgi tabanının organizasyonu ve bakımı, bilgi sınıflandırma ve kodlama sistemi, yazılım hakkında.

10. 4.2 ve 5.2 aşamalarında Dokümantasyonun geliştirilmesi NPP'de ve bölümlerinde "benimsenen tasarım çözümlerinin tam setini tanımlamak için gerekli miktarda ve NPP'nin oluşturulması üzerinde daha fazla çalışma için yeterli miktarda belgelerin geliştirilmesi, tescili, koordinasyonu ve onayını gerçekleştirin. Belge türleri - GOST 34.201'e göre.

11. 5.3 "NPP'leri tamamlamak için ürünlerin temini için belgelerin geliştirilmesi ve yürütülmesi ve (veya) bunların geliştirilmesi için teknik gereksinimler (teknik şartnameler)" aşamasında, NPP'leri tamamlamak için ürünlerin temini için belgeler hazırlamak ve yürütmek; seri üretimi olmayan ürünlerin geliştirilmesi için teknik gereksinimlerin belirlenmesi ve teknik şartnamelerin hazırlanması.

12. 5.4 "Otomasyon projesinin bitişik bölümlerindeki tasarım atamalarının geliştirilmesi" aşamasında, otomasyon nesnesinin bitişik bölümlerindeki tasarım atamalarının inşaat, elektrik, sıhhi ve diğer hazırlık çalışmaları için geliştirilmesi, tescili, onaylanması ve onaylanması yaratılış AC.

13. 6.1 "Sistem ve parçaları için çalışma belgelerinin geliştirilmesi" aşamasında, NGS'nin devreye alınması ve işletimi üzerindeki çalışmaların performansının yanı sıra bakımını sağlamak için gerekli ve yeterli tüm bilgileri içeren çalışma belgeleri geliştirilir. kabul edilen tasarım kararları, tescili, koordinasyonu ve onayı uyarınca sistemin operasyonel özelliklerinin (kalitesinin) seviyesi. Belge türleri - GOST 34.201'e göre.

14. 6.2 "Programların geliştirilmesi veya uyarlanması" aşamasında, sistemin programları ve yazılımı geliştirilir, satın alınan yazılımın seçimi, uyarlanması ve (veya) bağlanması, yazılım belgelerinin GOST 19.101'e göre geliştirilmesi.

15. Aşama 7.1'de, "NPP'nin devreye alınması için otomasyon nesnesinin hazırlanması", aşağıdakiler dahil olmak üzere otomasyon nesnesinin organizasyonel olarak hazırlanması üzerinde yürütülür: NPP organizasyon yapısı için tasarım çözümlerinin uygulanması; yönetim nesnesinin alt bölümlerine öğretimsel ve metodolojik materyaller sağlamak; bilgi sınıflandırıcıların tanıtımı.

16. 7.2 "Personel eğitimi" aşamasında, personel eğitilir ve NGS'nin çalışmasını sağlama yetenekleri kontrol edilir.

17. "AU'nun tedarik edilen ürünlerle tamamlanması" aşamasında, seri ve birim üretim bileşenlerinin, malzemelerin ve montaj ürünlerinin alınmasını sağlayın. Gelen kalite kontrolünü gerçekleştirirler.

18. 7.4 "İnşaat ve montaj işleri" aşamasında aşağıdakiler gerçekleştirilir: teknik ekipmanın ve nükleer santral personelinin yerleştirilmesi için özel binaların (tesislerin) inşaatına ilişkin işlerin yürütülmesi; kablo kanallarının yapımı; teknik araçların ve iletişim hatlarının kurulumuna ilişkin çalışmaların yürütülmesi; monte edilmiş teknik araçların test edilmesi; devreye alma için teknik araçların teslimi.

19. 7.5 "Devreye Alma" aşamasında, donanım ve yazılımın bağımsız olarak ayarlanması, veri tabanına bilgi yüklenmesi ve sistemin bakımı için kontrol edilmesi; tüm sistem araçlarının karmaşık ayarı.

20. Aşama 7.6'da "Ön testler" aşağıdakileri gerçekleştirin:

• AU'nun ön testlerin programı ve metodolojisine uygun olarak çalışabilirlik ve referans şartlarına uygunluk testleri;
• test raporuna uygun işletim belgeleri de dahil olmak üzere NPP belgelerinde arızaların ve değişikliklerin ortadan kaldırılması;
• deneme işletmesi için nükleer santralin kabul belgesinin tescili.

21. 7.7 "Deneme işletmesi" aşamasında, NGS'nin deneme işletmesi gerçekleştirilir; nükleer santralin deneysel çalışmasının sonuçlarının analizi; AC yazılımının revizyonu (gerekirse); nükleer santralin teknik araçlarının ek ayarlanması (gerekirse); deneme operasyonunun tamamlanması eyleminin kaydı.

22. 7.8 "Kabul testleri" aşamasında:

• programa ve kabul testleri yöntemlerine uygun olarak referans şartlarına uygunluk testleri;
• AU testlerinin sonuçlarının analizi ve testler sırasında tespit edilen eksikliklerin giderilmesi;
• nükleer santralin kalıcı işletme için kabul belgesinin tescili.

23. 8.1 "Garanti yükümlülüklerine uygun iş performansı" aşamasında, NGS'nin belirlenen garanti süreleri boyunca işletilmesi sırasında tespit edilen eksikliklerin giderilmesi, NGS'nin dokümantasyonunda gerekli değişikliklerin yapılması için çalışmalar yapılır.

24. 8.2 aşamasında "Garanti sonrası servis" çalışması aşağıdakiler üzerinde gerçekleştirilir:

• sistemin işleyişinin analizi;
• NPP'nin fiili operasyonel özelliklerinin tasarım değerlerinden sapmalarının belirlenmesi;
• bu sapmaların nedenlerini belirlemek;
• tespit edilen eksikliklerin giderilmesi ve nükleer santralin operasyonel özelliklerinin istikrarının sağlanması;
• AU belgelerinde gerekli değişiklikleri yapmak.

EK 2. Referans

AU'NUN OLUŞTURULMASINA KATILAN KURULUŞLARIN LİSTESİ

1. NGS'nin oluşturulacağı ve NPP'nin finansmanını, çalışmasını ve işletilmesini ve NPP'nin oluşturulmasına ilişkin bireysel çalışmaların performansını sağlayan kuruluş-müşteri (kullanıcı).

2. AU'nun oluşturulması için çalışmalar yürüten ve müşteriye bir dizi bilimsel ve teknik hizmet sağlayan kuruluş geliştiricisi Farklı aşamalar AU için çeşitli yazılım ve donanım geliştirme ve tedarik etmenin yanı sıra oluşturma aşamaları.

3. Geliştiricinin veya müşterinin talebi üzerine yazılım ve donanım üreten ve tedarik eden bir tedarikçi kuruluş.

4. Otomasyon nesnesinin organizasyon-genel tasarımcısı.

5. Tasarım organizasyonları farklı parçalar bir nükleer santralin oluşturulmasıyla ilgili inşaat, elektrik, sıhhi ve diğer hazırlık çalışmaları için bir otomasyon nesnesinin projesi.

6. İnşaat, montaj, devreye alma ve diğerleri için organizasyonlar.

Notlar:

1. AU'nun oluşturulmasına ilişkin koşullara bağlı olarak, müşteri, geliştirici, tedarikçi ve AU'nun oluşturulmasında yer alan diğer kuruluşların çeşitli işlev kombinasyonları mümkündür.

2. AU'nun oluşturulması konusundaki çalışmalarının aşamaları ve aşamaları bu standart temelinde belirlenir.

BİLGİ VERİSİ

1. SSCB Devlet Ürün Kalite Yönetimi ve Standartları Komitesi tarafından GELİŞTİRİLMİŞ VE TANITILMIŞTIR

GELİŞTİRİCİLER

Yu.Kh. Vermişev, Dr. bilimler; ya.G. Vilençik; VE. Voropaev, Dr. bilimler; L.M. Seidenberg, Cand. teknoloji bilimler; Yu.B. Irz, Cand. teknoloji bilimler; V.D. Kostyukov, Cand. teknoloji bilimler; MA Labutin, koşul. teknoloji bilimler; N.P. Leskovskaya; NS. Mityaev; VF Popov (konu lideri); S.V. Garshina; yapay zeka Sağır inanan; GÜNEŞ IŞIĞI. Zhukov, Cand Tech. bilimler; Z.P. Zadubovskaya; V.G. İvanov; Yu.I. Karavanov, Cand Tech. bilimler; AA parçalar; V.Yu. Korolev; VE. Mahnach, Cand. teknoloji bilimler; S.B. Mikhalev, Dr. bilimler; V.N. Petrikeviç; V.A. Rakhmanov, Cand. ekonomi. bilimler; AA Ratkoviç; RS Sedegov, Dr. bilimler; N.V. Stepanchikova; HANIM. surovets; AV Fleentler; L.O. Khvilevski, Cand. teknoloji bilimler; VC. Çistov, Cand. ekonomi. bilimler

2. SSCB Devlet Komitesi'nin 29 Aralık 1990 tarih ve 3469 Sayılı Ürün Kalite Yönetimi ve Standartları Kararnamesi ile ONAYLANMIŞ VE UYGULAMAYA GİRİŞTİRİLMİŞTİR