• Bilgi sisteminin geliştirilmesi için görev tanımı “Ticari işlemlerin muhasebesi. Otomatik bir bilgi sisteminin oluşturulması için görev tanımı

    GOST 34.602-89 Bilgi teknolojisi. Otomatik sistemler için standartlar seti. teknik görev otomatik bir sistemin oluşturulması için (GOST 24.201-85 yerine)

    Giriş tarihi 01.01.1990.

    Bu standart, kombinasyonları da dahil olmak üzere çeşitli faaliyet türlerini (yönetim, tasarım, araştırma vb.) Otomatikleştirmek için otomatik sistemler (AS) için geçerlidir ve "Oluşturma için Görev Tanımı ( geliştirme veya modernizasyon) sistemleri" (bundan sonra nükleer santraller için TK olarak anılacaktır).

    1. GENEL HÜKÜMLER

    1.1. NGS için Görev Tanımı, NPP'nin geliştirilmesinin ve devreye alma üzerine kabulünün gerçekleştirildiği otomatik bir sistemin oluşturulması (geliştirme veya modernizasyon - daha fazla oluşturma) için gereklilikleri ve prosedürü tanımlayan ana belgedir.

    1.2. Nükleer santrallere ilişkin şartnameler, sistemin bütünü için geliştirilmekte, bağımsız veya başka bir sistemin parçası olarak çalışmak üzere tasarlanmaktadır.

    Ek olarak, NGS'nin bazı bölümleri için Görev Tanımı geliştirilebilir:

    • bu standardın gerekliliklerine uygun olarak NPP'nin alt sistemleri, NPP'nin görev kompleksleri vb.
    • ESKD ve SRPP standartlarına uygun donanım bileşenleri ile yazılım ve donanım sistemleri için;
    • ESPD standartlarına uygun yazılımlar için;
    • NPP müşterisinin departmanında yürürlükte olan GOST 19.201 ve NTD uyarınca bilgi ürünleri için.

    Not. Birbiriyle ilişkili nesneler grubu için otomatik kontrol sistemi için Görev Tanımında, yalnızca bir nesne grubu için ortak olan gereksinimler dahil edilmelidir. Ayrı bir kontrol nesnesinin özel gereksinimleri, bu nesnenin ACS'si için Görev Tanımına yansıtılmalıdır.

    1.3. Bu standardın belirlediği kapsamdaki AU gereksinimleri, yeni oluşturulan bir otomasyon nesnesinin tasarımına yönelik atamaya dahil edilebilir. Bu durumda nükleer santraller için teknik şartnameler geliştirilmemiştir.

    1.4. NGS'ler için Görev Tanımında yer alan gereksinimler, bilim ve teknolojinin mevcut gelişme düzeyine karşılık gelmeli ve en iyi modern yerel ve yabancı analoglar. Görev Tanımında nükleer santraller için belirtilen gereklilikler, sistem geliştiricisini en etkili teknik, fizibilite ve diğer çözümlerin araştırılması ve uygulanmasında sınırlamamalıdır.

    1.5. Nükleer santrallerin özellikleri, GOST 24.601 tarafından belirlenen "NGS'lerin oluşturulması için araştırma ve gerekçelendirme" aşamasının nihai belgelerinde yer alanlar da dahil olmak üzere ilk verilere dayanarak geliştirilir.

    1.6. Nükleer santraller için Görev Tanımı, yalnızca mevcut NTD'de yer alan bu türdeki sistemlere yönelik gereksinimleri (ACS, CAD, ASNI, vb.) tamamlayan gereksinimleri içerir ve sistemin ilgili olduğu belirli nesnenin özellikleri tarafından belirlenir. yaratıldı.

    1.7. NGS'deki Görev Tanımı'ndaki değişiklikler, müşteri ve geliştirici tarafından imzalanan bir protokol veya bir ek ile resmileştirilir. Ek veya belirtilen protokol, NPP için İş Tanımının ayrılmaz bir parçasıdır. AC'deki TK'nin başlık sayfasında "Geçerli olan ..." girişi olmalıdır.

    2. YAPI VE İÇERİK

    2.1. NPP için İş Tanımı, alt bölümlere ayrılabilen aşağıdaki bölümleri içerir:

    • 1) genel bilgiler;
    • 2) sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri;
    • 3) otomasyon nesnelerinin özellikleri;
    • 4) sistem gereksinimleri;
    • 5) sistemi oluşturmak için işin bileşimi ve içeriği;
    • 6) sistemin kontrolü ve kabulü için prosedür;
    • 7) sistemi faaliyete geçirmek için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler;
    • 8) dokümantasyon gereksinimleri;
    • 9) geliştirme kaynakları.

    Başvurular, AU için Görev Tanımına dahil edilebilir.

    2.2. Otomasyon nesnesinin türüne, amacına, belirli özelliklerine ve sistemin çalışma koşullarına bağlı olarak, Görev Tanımının bölümlerinin uygulamalar şeklinde hazırlanmasına, Görev Tanımının alt bölümlerinin eklenmesine, hariç tutulmasına veya birleştirilmesine izin verilir.

    Sistemin bölümleri için Görev Tanımı, bir bütün olarak NPP için Görev Tanımı bölümlerinin içeriğini kopyalayan bölümleri içermez.

    2.3. Bölümde " Genel bilgi" belirtmek:

    • 1) sistemin tam adı ve sembolü;
    • 2) konunun şifresi veya sözleşmenin şifresi (numarası);
    • 3) sistemin geliştiricisi ve müşterisinin (kullanıcısının) işletmelerinin (derneklerinin) adı ve detayları;
    • 4) sistemin oluşturulduğu, bu belgelerin kim tarafından ve ne zaman onaylandığı temelinde belgelerin bir listesi;
    • 5) sistemin oluşturulmasına yönelik çalışmaların başlaması ve tamamlanması için planlanan tarihler;
    • 6) işin finansmanı için kaynaklar ve prosedür hakkında bilgi;
    • 7) sistemin (parçalarının) oluşturulması, bireysel araçların (donanım, yazılım, bilgi) ve yazılım ve donanımın (yazılım ve metodolojik) üretimi ve ayarlanması ile ilgili çalışmaların sonuçlarını resmileştirme ve müşteriye sunma prosedürü sistemin kompleksleri.

    2.4. "Sistemin oluşturulmasının (geliştirilmesinin) amacı ve hedefleri" bölümü alt bölümlerden oluşur:

    • 1) sistemin amacı;
    • 2) sistemin oluşturulma amacı.

    2.4.1. "Sistemin amacı" alt bölümünde, otomatik etkinliğin türünü (yönetim, tasarım vb.) ve kullanılması gereken otomasyon nesnelerinin (nesneler) listesini belirtin.

    Otomatik kontrol sistemleri için, otomatik kontrol organlarının (noktalar) ve yönetilen nesnelerin bir listesi ayrıca belirtilir.

    2.4.2. "Sistem oluşturma hedefleri" alt bölümünde, bir AU oluşturma sonucunda ulaşılması gereken otomasyon nesnesinin teknik, teknolojik, üretim-ekonomik veya diğer göstergelerinin adlarını ve gerekli değerlerini verin ve bir sistem oluşturma hedeflerine ulaşılmasını değerlendirmek için kriterler.

    2.5. "Otomasyon nesnesinin özellikleri" bölümünde şunları verin:

    • 1) kısa bilgi otomasyon nesnesi veya bu tür bilgileri içeren belgelere bağlantılar hakkında;
    • 2) otomasyon nesnesinin çalışma koşulları ve ortamın özellikleri hakkında bilgi.

    Not: CAD için, bölüm ek olarak tasarım nesnelerinin ana parametrelerini ve özelliklerini sağlar.

    2.6. Sistem Gereksinimleri bölümü aşağıdaki alt bölümlerden oluşur:

    • 1) bir bütün olarak sistem gereksinimleri;
    • 2) sistem tarafından gerçekleştirilen işlevler (görevler) için gereksinimler;
    • 3) teminat türleri için gereklilikler.

    NGS'ler için İş Tanımının bu bölümünde yer alan sistem gereksinimlerinin bileşimi, belirli bir sistemin tipine, amacına, belirli özelliklerine ve çalışma koşullarına bağlı olarak belirlenir. Her alt bölüm, karşılık gelen türdeki sistemler için gereksinimleri tanımlayan mevcut NTD'ye bağlantılar sağlar.

    2.6.1. "Bir bütün olarak sistem gereksinimleri" alt bölümünde şunları belirtin:

    • sistemin yapısı ve işleyişi için gereksinimler;
    • sistem personelinin sayısı ve nitelikleri ile çalışma şekli için gereklilikler;
    • hedef göstergeleri;
    • güvenilirlik gereksinimleri;
    • güvenlik gereksinimleri;
    • ergonomi ve teknik estetik gereksinimleri;
    • mobil AS için taşınabilirlik gereksinimleri;
    • sistem bileşenlerinin çalıştırılması, bakımı, onarımı ve depolanması için gereksinimler;
    • bilgilerin yetkisiz erişimden korunması için gereklilikler;
    • kaza durumunda bilgilerin güvenliği için gereklilikler;
    • dış etkilerin etkisinden korunma gereksinimleri;
    • patent saflığı için gereksinimler;
    • standardizasyon ve birleştirme gereksinimleri;
    • Ek gereksinimler.

    2.6.1.1. Sistemin yapısı ve işleyişi için gereksinimler şunları içerir:

    • 1) alt sistemlerin bir listesi, amaçları ve temel özellikleri, hiyerarşi seviyelerinin sayısı için gereklilikler ve sistemin merkezileşme derecesi;
    • 2) sistem bileşenleri arasında bilgi alışverişi için iletişim yöntemleri ve araçları için gereklilikler;
    • 3) ilgili sistemlerle oluşturulan sistemin ara bağlantılarının özellikleri için gereklilikler, bilgi alışverişinin nasıl yapılacağına ilişkin talimatlar da dahil olmak üzere uyumluluğu için gereklilikler (otomatik olarak, belge göndererek, telefonla vb.);
    • 4) sistemin çalışma modları için gereksinimler;
    • 5) sistemin teşhisi için gereklilikler;
    • 6) gelişme beklentileri, sistemin modernizasyonu.

    2.6.1.2. NGS'lerdeki personel sayısı ve nitelikleri için gereklilikler şunları içerir:

    • nükleer santralin personel (kullanıcı) sayısı için gereksinimler;
    • personelin kalifikasyonu için gereklilikler, eğitim prosedürleri ve bilgi ve becerilerin kontrolü;
    • NPP personelinin gerekli çalışma şekli.

    2.6.1.3. AS'nin amacına ilişkin göstergelerin gerekliliklerinde, sistemin amacına uygunluk derecesini karakterize eden parametrelerin değerleri verilmiştir.

    ACS için şunu belirtin:

    • sistemin süreçlerdeki ve yönetim yöntemlerindeki değişikliklere, kontrol nesnesinin parametrelerindeki sapmalara uyarlanabilirlik derecesi;
    • sistemin modernizasyonunun ve gelişiminin kabul edilebilir sınırları;
    • sistemin amaçlanan amacının korunduğu olasılıksal-zamansal özellikler.

    2.6.1.4. Güvenilirlik gereksinimleri şunları içerir:

    • 1) bir bütün olarak sistem veya alt sistemleri için güvenilirlik göstergelerinin bileşimi ve nicel değerleri;
    • 2) güvenilirlik gereksinimlerinin düzenlenmesi gereken acil durumların bir listesi ve ilgili göstergelerin değerleri;
    • 3) güvenilirlik gereksinimleri teknik araçlar ve yazılım;
    • 4) güvenilirlik göstergelerini değerlendirme ve izleme yöntemleri için gereklilikler Farklı aşamalar mevcut düzenleyici ve teknik belgelere uygun bir sistemin oluşturulması.

    2.6.1.5. Güvenlik gereksinimleri, sistemin teknik araçlarının kurulumu, devreye alınması, çalıştırılması, bakımı ve onarımı sırasında güvenliğin sağlanmasına yönelik gereksinimleri içerir (karşı koruma elektrik akımı, elektromanyetik alanlar, akustik gürültü, vb.), izin verilen aydınlatma seviyeleri, titreşim ve gürültü yükleri ile.

    2.6.1.6. Ergonomi ve teknik estetik gereklilikleri, insan-makine etkileşiminin gerekli kalitesini ve personel çalışma koşullarının rahatlığını belirten AS göstergelerini içerir.

    2.6.1.7. Mobil nükleer santraller için taşınabilirlik gereksinimleri, sistemin teknik araçlarının taşınabilirliğini sağlayan tasarım gereksinimlerinin yanı sıra araçlar için gereksinimleri içerir.

    2.6.1.8. İşletme, bakım, onarım ve depolama gereklilikleri şunları içerir:

    • 1) sistemin teknik araçlarının (TS) kullanımını, sistemin TS'sinin bakım türleri ve sıklığı veya bakımsız çalıştırmanın kabul edilebilirliği dahil olmak üzere belirtilen teknik göstergelerle kullanılmasını sağlaması gereken çalışma koşulları ve düzenlemeleri (modları). ;
    • 2) personelin yerleştirilmesi için izin verilen alanlar ve sistemin TS'si, güç kaynağı ağlarının parametreleri vb. için ön gereksinimler;
    • 3) bakım personelinin sayısı, nitelikleri ve çalışma biçimleri için gereklilikler;
    • 4) bir dizi yedek ürün ve cihazın bileşimi, yerleştirilmesi ve saklama koşulları için gereklilikler;
    • 5) bakım programı gereksinimleri.

    2.6.1.9. Bilgileri yetkisiz erişime karşı koruma gereklilikleri, müşterinin endüstrisinde (bölümünde) faaliyet gösteren NTD'de belirlenen gereklilikleri içerir.

    2.6.1.10. Bilgi güvenliği gerekliliklerinde, sistemdeki bilgilerin güvenliğinin sağlanması gereken kazalar, teknik araçların arızaları (güç kaybı dahil) vb. Olayların bir listesi verilir.

    2.6.1.11. Dış etkilere karşı koruma araçlarına ilişkin gereksinimlerde aşağıdakiler verilmiştir:

    • 1) nükleer santral tesislerinin radyo-elektronik koruması için gereklilikler;
    • 2) dış etkilere (kullanım ortamı) karşı direnç, kararlılık ve dayanıklılık gereklilikleri.

    2.6.1.12. Patent saflığı gereklilikleri, sistemin ve parçalarının patent saflığının sağlanması gereken ülkelerin bir listesini belirtir.

    2.6.1.13. Standardizasyon ve birleştirme gereksinimleri şunları içerir: sağlanan sistemin işlevlerini (görevlerini) uygulamak için standart, birleşik yöntemlerin gerekli kullanım derecesini belirleyen göstergeler yazılım araçları, tipik matematiksel yöntemler ve modeller, standart tasarım çözümleri, GOST 6.10.1 tarafından oluşturulan birleşik yönetim belgeleri biçimleri, teknik ve ekonomik bilgilerin tüm Birlik sınıflandırıcıları ve kapsamlarına göre diğer kategorilerin sınıflandırıcıları, tipik otomatik iş istasyonlarının, bileşenlerin ve bileşenlerin kullanım gereksinimleri kompleksler.

    2.6.1.14. Ek gereksinimler şunları içerir:

    • 1) sistemin personel eğitimi için cihazlarla (simülatörler, benzer amaçlı diğer cihazlar) donatılması ve bunlara ilişkin belgeler;
    • 2) servis ekipmanı gereksinimleri, sistem elemanlarının kontrol edilmesi anlamına gelir;
    • 3) özel çalışma koşullarıyla ilgili sistem gereksinimleri;
    • 4) sistem geliştiricisinin veya müşterisinin takdirine bağlı olarak özel gereksinimler.

    2.6.2. Sistem tarafından gerçekleştirilen "İşlevler (görevler) için gereksinimler" alt bölümünde aşağıdakiler verilmiştir:

  • 1) her alt sistem için, otomatikleştirilecek işlevlerin, görevlerin veya bunların komplekslerinin (sistemin parçalarının etkileşimini sağlayanlar dahil) bir listesi;

    iki veya daha fazla kuyrukta bir sistem oluştururken - 1. ve sonraki sıralarda yürürlüğe giren işlevsel alt sistemlerin, bireysel işlevlerin veya görevlerin bir listesi;

  • 2) her işlevin, görevin (veya görevler dizisinin) uygulanması için zaman çizelgesi;
  • 3) her bir işlevin (görev veya görevler dizisi) uygulama kalitesi, çıktı bilgilerinin sunulma biçimi, gerekli doğruluk ve yürütme süresinin özellikleri, bir grubun yürütülmesinin eşzamanlılığı için gereksinimler fonksiyonlar, sonuçların güvenilirliği;
  • 4) güvenilirlik gereksinimlerinin belirtildiği her fonksiyon için bir liste ve başarısızlık kriterleri.

    2.6.3. “Destek türleri için gereksinimler” alt bölümünde, sistemin türüne bağlı olarak, sistem için matematiksel, bilgi, dil, yazılım, teknik, metrolojik, organizasyonel, metodolojik ve diğer destek türleri için gereksinimler verilmektedir.

    2.6.3.1. Sistemin matematiksel desteği için, bileşim, kapsam (sınırlamalar) ve yöntemler, matematiksel yöntem ve modellerin sistemde kullanımı, tipik algoritmalar ve geliştirilecek algoritmalar için gereksinimler verilir.

    2.6.3.2. Sistemin bilgi desteği için aşağıdaki gereksinimler verilmiştir:

    • 1) sistemdeki verileri düzenlemenin bileşimi, yapısı ve yöntemleri;
    • 2) sistem bileşenleri arasında bilgi alışverişine;
    • 3) bitişik sistemlerle bilgi uyumluluğuna;
    • 4) belirli bir işletmede faaliyet gösteren tüm Birlik ve kayıtlı cumhuriyetçi, endüstri sınıflandırıcıları, birleşik belgeler ve sınıflandırıcıların kullanımı hakkında;
    • 5) veri tabanı yönetim sistemlerinin kullanımı hakkında;
    • 6) sistemde veri toplama, işleme, aktarma ve veri sunma sürecinin yapısına;
    • 7) sistemdeki kazalar ve elektrik kesintileri durumunda verileri yok edilmekten korumak;
    • 8) verilerin kontrolü, depolanması, güncellenmesi ve kurtarılması;
    • 9) verme prosedürüne yasal güç AU'nun teknik araçlarıyla üretilen belgeler (GOST 6.10.4 uyarınca).

    2.6.3.3. Sistemin dil desteği için, sistemde programlama dillerinin kullanımına yönelik gereksinimler verilmiştir. yüksek seviye, kullanıcılar ve sistemin teknik araçları arasındaki etkileşim dillerinin yanı sıra verileri kodlama ve kod çözme gereksinimleri, veri giriş / çıkış dilleri, veri işleme dilleri, açıklama araçları konu alanı(otomasyon nesnesi), bir diyalog düzenleme yollarına.

    2.6.3.4. Sistem yazılımı için, satın alınan yazılımların yanı sıra gereksinimlerin bir listesi verilir:

    • 1) yazılımın kullanılan CVT'den ve işletim ortamından bağımsız olması;
    • 2) yazılımın kalitesinin yanı sıra sağlama ve kontrol etme yöntemlerine;
    • 3) Yeni geliştirilen yazılımların algoritma ve program fonu ile uyumlu hale getirilmesi gerekiyorsa.

    2.6.3.5. Sistemin teknik desteği için aşağıdaki gereksinimler verilmiştir:

    • 1) teknik araç kompleksleri, yazılım ve donanım kompleksleri ve sistemde kullanılması kabul edilen diğer bileşenler dahil olmak üzere teknik araç türlerine;
    • 2) sistemin teknik desteğinin işlevsel, yapıcı ve operasyonel özelliklerine.

    2.6.3.6. Metrolojik destek gereksinimleri şunları içerir:

    • 1) ölçüm kanallarının bir ön listesi;
    • 2) parametrelerin ölçümlerinin doğruluğu ve (veya) ölçüm kanallarının metrolojik özellikleri için gereklilikler;
    • 3) sistemin teknik araçlarının metrolojik uyumluluğu için gereklilikler;
    • 4) doğruluk özelliklerinin değerlendirilmesi gereken sistemin kontrol ve bilgi işlem kanallarının bir listesi;
    • 5) sistemin ölçüm kanallarının bir parçası olan donanım ve yazılımın, araçların, yerleşik kontrolün, ölçüm kanallarının metrolojik uygunluğunun ve sistemin ayarlanmasında ve test edilmesinde kullanılan ölçüm cihazlarının metrolojik desteği için gereklilikler;
    • 6) uygulama prosedürünün ve sertifikasyonu yürüten kuruluşların bir göstergesi ile metrolojik sertifika türü (eyalet veya departman).

    2.6.3.7. Organizasyonel destek için aşağıdaki gereksinimler verilmiştir:

  • 1) sistemin işletilmesinde veya işletilmesinde yer alan birimlerin yapı ve işlevlerine;
  • 2) sistemin işleyişinin organizasyonu ve NPP personeli ile otomasyon nesnesinin personeli arasındaki etkileşim prosedürü;
  • 3) sistem personelinin hatalı eylemlerine karşı koruma.

    2.6.3.8. CAD'nin metodolojik desteği için, düzenleyicinin bileşimine ilişkin gereklilikler teknik döküman sistem (çalışması sırasında kullanılan standartların, düzenlemelerin, yöntemlerin vb. listesi).

    2.7. "Sistemin oluşturulması (geliştirilmesi) ile ilgili işin bileşimi ve içeriği" bölümü, GOST 24.601'e göre sistemin oluşturulmasına ilişkin çalışma aşamalarının ve aşamalarının bir listesini, bunların uygulanma zamanını, kuruluşların bir listesini içermelidir. işin yapılması, bu kuruluşların bir sistemin oluşturulmasına katılma onayını teyit eden belgelere bağlantılar veya bu işleri yürütmekten sorumlu kişiyi (müşteri veya geliştirici) tanımlayan bir kayıt.

    Bu bölüm ayrıca şunları sağlar:

    • 1) ilgili çalışma aşamalarının ve aşamalarının sonunda sunulan, GOST 34.201-89 uyarınca belgelerin bir listesi;
    • 2) teknik dokümantasyon incelemesinin türü ve prosedürü (aşama, aşama, kontrol edilen dokümantasyonun kapsamı, organizasyon uzmanı);
    • 3) geliştirilmekte olan sistemin gerekli güvenilirlik seviyesini sağlamayı amaçlayan bir çalışma programı (gerekirse);
    • 4) sistemin oluşturulmasının tüm aşamalarında metrolojik destek ile ilgili çalışmaların bir listesi, son tarihlerini ve yürütme kuruluşlarını (gerekirse) gösterir.

    2.8. "Sistemin izlenmesi ve kabulü için prosedür" bölümünde şunları belirtin:

    • 1) sistemin türleri, bileşimi, kapsamı ve test yöntemleri ve oluşturan parçalar(geliştirilmekte olan sisteme uygulanabilir mevcut standartlara uygun test türleri);
    • 2) aşamalara göre işin kabulü için genel gereklilikler (katılan işletmelerin ve kuruluşların listesi, yer ve zamanlama), kabul belgelerini kabul etme ve onaylama prosedürü;
    • H) kabul komitesinin durumu (devlet, bölümler arası, bölüm).

    2.9. "Sistemi işletmeye almak için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler" bölümünde, otomasyon nesnesini devreye almak için hazırlarken gerçekleştirilmesi gereken ana faaliyetlerin ve gerçekleştirenlerin bir listesini sağlamak gerekir. AU faaliyete geçti.

    Ana faaliyetlerin listesi şunları içerir:

    • 1) sisteme giren bilgilerin (bilgi ve dil desteği gerekliliklerine uygun olarak) bilgisayar kullanılarak işlenmeye uygun bir forma getirilmesi;
    • 2) otomasyon nesnesinde yapılması gereken değişiklikler;
    • 3) oluşturulan sistemin görev tanımında yer alan gerekliliklere uygunluğunun garanti edildiği otomasyon nesnesinin işleyişi için koşulların oluşturulması;
    • 4) sistemin işleyişi için gerekli alt bölümlerin ve hizmetlerin oluşturulması;
    • 5) personel alımı ve personel eğitimi için şartlar ve prosedür.

    Örneğin, ACS için şunları verirler:

    • uygulanan yönetim yöntemlerindeki değişiklikler;
    • ACS bileşenlerinin çalışması için, sistemin TOR'da yer alan gerekliliklere uygunluğunun garanti edildiği koşulların oluşturulması.

    2.10. "Dokümantasyon Gereksinimleri" bölümünde aşağıdakiler verilmiştir:

    • 1) sistem geliştiricisi ve Müşteri tarafından kabul edilen, GOST 34.201-89 ve müşteri endüstrisinin NTD gereksinimlerini karşılayan geliştirilecek belge setlerinin ve türlerinin bir listesi;
      makine ortamında yayınlanan belgelerin listesi;
      mikrofilme alma belgeleri için gereklilikler;
    • 2) ESKD ve ESPD gerekliliklerine uygun olarak sektörler arası uygulamanın bileşen öğelerini belgelemek için gereklilikler;
    • 3) sistem öğelerinin belgelenmesi için gereksinimleri tanımlayan devlet standartlarının yokluğunda, bu tür belgelerin bileşimi ve içeriği için ek gereksinimleri içerirler.

    2.11. Geliştirme Kaynakları bölümü belgeleri ve bilgi materyalleri(fizibilite çalışması, tamamlanmış araştırma çalışmaları hakkında raporlar, yerli, yabancı analog sistemler hakkında bilgi materyalleri vb.), Görev Tanımının geliştirildiği ve sistemi oluştururken kullanılması gerekenler.

    2.12. Onaylanmış yöntemlerin mevcudiyetinde NPP'lerdeki Görev Tanımının bileşimi, aşağıdakileri içeren uygulamaları içerir:

    • 1) sistemin beklenen veriminin hesaplanması;
    • 2) sistemin bilimsel ve teknik seviyesinin değerlendirilmesi.

    Başvurular, sistemin geliştiricisi ve müşterisi arasında kararlaştırıldığı şekilde NGS için Görev Tanımına dahil edilir.

    3. TASARIM KURALLARI

    3.1. NPP'deki İş Tanımının bölümleri ve alt bölümleri, 5. bölümde belirtilen şekilde yerleştirilmelidir. Bu standardın 2.

    3.2. AU için TK, GOST 2.105.95 gerekliliklerine uygun olarak, GOST 2.301'e uygun olarak A4 formatındaki sayfalarda çerçevesiz, ana yazıt ve ek sütunlar olmadan hazırlanmıştır.

    Sayfa (sayfa) numaraları, AC'de TK kodu belirlendikten sonra, başlık sayfasını takip eden ilk sayfadan başlayarak sayfanın en üstüne (metnin üstünde, ortada) yazılır.

    3.3. Göstergelerin, normların ve gereksinimlerin değerleri, kural olarak maksimum sapmalar veya maksimum ve minimum değerlerle belirtilir. Bu göstergeler, normlar, gereksinimler açık bir şekilde NTD tarafından düzenleniyorsa, NPP için Görev Tanımı bu belgelere veya bölümlerine bir bağlantı ve ayrıca oluşturulan sistemin özelliklerini dikkate alan ek gereksinimler sağlamalıdır. NPP'de Görev Tanımının geliştirilmesi sürecinde göstergelerin, normların ve gereksinimlerin belirli değerleri belirlenemezse, bu göstergelerin, normların ve gereksinimlerin oluşturulması ve üzerinde anlaşmaya varma prosedürünü kaydetmelidir:

    "Nihai gereklilik (değer) süreçte belirtilir ... ve ... ile protokol tarafından ... aşamasında ..." üzerinde anlaşmaya varılır.

    Aynı zamanda NGS için Görev Tanımı metninde herhangi bir değişiklik yapılmamaktadır.

    3.4. Başlık sayfasında müşteri, geliştirici ve koordinatör kuruluşların kaşe ile mühürlenmiş imzaları bulunur. Gerekirse, başlık sayfası birkaç sayfada düzenlenir. NGS için Şartname hazırlayanların ve NGS için taslak Şartnamenin onaylanması ve gözden geçirilmesinde yer alan yetkililerin imzaları son sayfada yer almaktadır.

    TK'nın AU için başlık sayfasının formu Ek 2'de verilmiştir. TK'nın AU için son sayfasının formu Ek 3'te verilmiştir.

    3.5. Gerekirse, TK'nın AU'daki başlık sayfasına, sektörde yerleşik kodların yerleştirilmesine izin verilir, örneğin: güvenlik damgası, iş kodu, TK kayıt numarası vb.

    3.6. Baş sayfa NGS için Görev Tanımına yapılan eklemeler, teknik görevlendirmenin başlık sayfasıyla aynı şekilde düzenlenir. "Görev Tanımı" adı yerine "AC için Görev Tanımına ... Ek No. ..." yazıyorlar.

    3.7. AU'daki İş Tanımı Ekinin sonraki sayfalarında, değişikliğin temeli, değişikliğin içeriği ve bu değişikliklerin yapıldığı belgelere bağlantılar yerleştirilmiştir.

    3.8. Görev Tanımına ek metni sunulurken, Ana Görev Tanımının AU üzerindeki ilgili paragraf, alt paragraf, tablo vb. numaraları belirtilmeli ve “değiştir”, “ek”, “sil”, “ yeni baskıda belirt” ifadesi kullanılmalıdır.

    NGS'LER İÇİN Görev Tanımının GELİŞTİRİLMESİ, ANLAŞILMASI VE ONAYLANMASI PROSEDÜRÜ

    1. NGS'ler için taslak Görev Tanımı, sistem geliştiricisi tarafından müşterinin katılımıyla teknik gereklilikler (uygulama, performans spesifikasyonu vb.) temelinde geliştirilir.

    Rekabetçi iş organizasyonunda, nükleer santral için taslak Görev Tanımı seçenekleri, ya tercih edilen seçeneği seçen ya da karşılaştırmalı bir analize dayalı olarak, NGS için Görev Tanımının nihai versiyonunu hazırlayan müşteri tarafından dikkate alınır. geleceğin NPP geliştiricisinin katılımı.

    2. NGS'ler için taslak İş Tanımının devlet denetim makamları ve diğer ilgili kuruluşlar nezdinde onaylanma ihtiyacı, sistemin müşterisi ve nükleer santralde taslak İş Tanımının geliştiricisi tarafından ortaklaşa belirlenir,

    AC için taslak Görev Tanımının onaylanmasına ilişkin çalışma, her biri kendi bakanlığının (dairesinin) kuruluşlarında, NGS için Görev Tanımını geliştiren ve sistemin müşterisi tarafından ortaklaşa yürütülür.

    3. Her kuruluşta nükleer santraller için taslak İş Tanımının onaylanma süresi, alındığı tarihten itibaren 15 günü geçmemelidir. Nükleer santraller için taslak İş Tanımının kopyalarının (kopyalarının) aynı anda tüm kuruluşlara (bölümlere) onay için gönderilmesi önerilir.

    4. NPP'ler için taslak İş Tanımı hakkındaki yorumlar teknik gerekçelerle birlikte sunulmalıdır. Yorumlarla ilgili kararlar, NGS için İş Tanımının onaylanmasından önce, NGS için taslak İş Tanımının geliştiricisi ve sistemin müşterisi tarafından verilmelidir.

    5. NPP'de taslak Görev Tanımı üzerinde anlaşmaya varılırken geliştirici ile müşteri (veya diğer ilgili kuruluşlar) arasında anlaşmazlıklar ortaya çıkarsa, bir anlaşmazlık protokolü düzenlenir (keyfi form) ve öngörülen şekilde belirli bir karar verilir.

    6. Taslak Görev Tanımının NPP'de onaylanmasının ayrı bir belge (mektup) olarak hazırlanmasına izin verilir. Bu durumda, "Kabul edildi" başlığı altında bu belgeye bir bağlantı oluşturun.

    7. Nükleer santraller için teknik şartnamelerin onaylanması, sistemin geliştiricisi ve müşterisinin işletme (kuruluş) başkanları tarafından gerçekleştirilir.

    8. NGS spesifikasyonu (şartnameye ek), onay için sunulmadan önce, spesifikasyonu geliştiren kuruluşun normatif kontrol servisi tarafından kontrol edilmeli ve gerekirse metrolojik incelemeye tabi tutulmalıdır.

    9. NGS için onaylanan İş Tanımının kopyaları, onaydan sonraki 10 gün içinde sistemin oluşturulmasında katılımcılara nükleer santral için İş Tanımının geliştiricisi tarafından gönderilir.

    10. NGS'ler için Şartname'ye yapılan eklemelerin koordinasyonu ve onaylanması, NGS'ler için Şartname'de belirlenen şekilde gerçekleştirilir.

    11. NGS'lerdeki Görev Tanımı değişiklikleri, sistem veya sırası kabul testlerine sunulduktan sonra onaylanamaz.

    12. NGS'de teknik şartnamelerin kaydı, muhasebesi ve saklanması ve bunlara yapılan eklemeler GOST 2.501 gerekliliklerine uygun olarak gerçekleştirilir.

    BAŞLIK SAYFASININ ŞEKLİ AC ON TK

    ________________________________________________________

    İsim
    kuruluş - nükleer santraller için teknik özelliklerin geliştiricisi

    ONAYLAMAK

    süpervizör
    (pozisyon, işletmenin adı - NPP müşterisi)

    kişisel imza
    Ad Soyad

    Fok

    tarih

    ONAYLAMAK

    süpervizör
    (pozisyon, işletmenin adı - geliştirici” AS)

    kişisel imza
    Ad Soyad

    Fok

    tarih


    ________________________________________________________

    AC tipinin adı


    ________________________________________________________

    Nesne adı
    otomasyon


    ________________________________________________________

    kısaltılmış
    AC adı

    TEKNİK GÖREV

    ____ sayfada

      Aktif
      İle

    KABUL

    süpervizör
    (pozisyon, koordinasyon kuruluşunun adı)

    kişisel imza
    Ad Soyad

    Fok

    tarih

    SON SAYFANIN ŞEKLİ AC ON TK

    (TK kodu)

    KABUL EDİLMİŞTİR

    EK 4
    Referans

    OTOMATİK SİSTEMLER İÇİN BİRLEŞİK BİR STANDART KOMPLEKSİ OLUŞTURMA HÜKÜMLERİ

    1. Kompleksin oluşturulması için ilk ön koşullar

    1.1. Çeşitli sınıf ve amaçlara sahip otomatik sistemlerin oluşturulması ve uygulanması, birçok endüstride, sistemlerin entegrasyonunu ve etkin ortak işleyişini engelleyen çeşitli organizasyonel, metodolojik ve teknik normlar, kurallar ve düzenlemeler oluşturan düzenleyici ve teknik belgelere göre gerçekleştirilir. .

    1.2. SSCB Gosstandart'ının sektörler arası standart komplekslerini iyileştirme kararı aldığı dönemde, aşağıdaki standart kompleksleri ve sistemleri yürürlükteydi ve aşağıdakiler için gereklilikler belirlendi: çeşitli tipler AC:

    • 1) tek sistem otomatik kontrol sistemleri, otomatik kontrol sistemleri, otomatik süreç kontrol sistemleri ve diğer organizasyonel ve ekonomik sistemler için geçerli olan otomatik kontrol sistemleri standartları (24. sistem);
    • 2) bir dizi standart (sistem 23501); bilgisayar destekli tasarım sistemlerine uzanan;
    • 3) üretimin teknolojik olarak hazırlanması için otomatik sistemleri kapsayan 14. standartlar sisteminin dördüncü grubu.

    1.3. Otomatik kontrol sistemleri, CAD, otomatik proses kontrol sistemleri, ASTPP için standart uygulama pratiği, aynı kavramsal aparatı kullandıklarını, birçok ortak standardizasyon nesnesi olduğunu, ancak standartların gerekliliklerinin kendi aralarında koordine edilmediğini göstermiştir. işin kompozisyonu ve içeriğindeki farklılıklar, belgelerin tanımı, kompozisyonu, içeriği ve biçimlendirilmesindeki vb. farklılıklardır.

    1.4. AS oluşturma alanında birleşik bir teknik politikanın bulunmamasının arka planına karşı, standartların çeşitliliği, etkileşimleri sırasında AS'nin geniş uyumluluğunu sağlamadı, sistemlerin çoğaltılmasına izin vermedi ve gelecek vaat eden alanların geliştirilmesini engelledi. bilgisayar teknolojisinin kullanımı.

    1.5. Şu anda, otomatik kontrol sistemlerini içeren karmaşık AS'nin (yabancı CAD sistemleri - CAM) oluşturulmasına geçiş devam etmektedir. teknolojik süreçler ve endüstriler, CAD - tasarımcı, CAD - teknoloji uzmanı, ASNI ve diğer sistemler. Bu tür sistemler oluşturulurken birbiriyle çelişen kuralların kullanılması, kalitenin düşmesine, iş maliyetinin artmasına ve NGS'nin devreye alınmasının gecikmesine neden olmaktadır.

    1.6. Otomatik sistemler için tek bir standartlar ve yönergeler seti uygulanmalıdır çeşitli amaçlar için: ASNI, CAD, OASU, APCS, APCS, APCS, ASK, ASTPP, bunların entegrasyonu dahil.

    1.7. Sektörler arası belgeler geliştirirken, standardizasyon nesneleri olarak AU'nun aşağıdaki özellikleri dikkate alınmalıdır:

    • 1) görev tanımı, AU'nun oluşturulması ve müşteri tarafından kabulünün gerçekleştirildiği ana belgedir;
    • 2) NGS'ler, kural olarak, NGS'nin işletmeye alınması için gerekli olan inşaat, kurulum, işletmeye alma ve işletmeye alma işlerini yürüten, seri ve tek üretim tam bir ürün seti ile tasarım yoluyla oluşturulur;
    • 3) genel durumda, AS (AS alt sistemi), yazılım ve donanım (STC), yazılım ve metodolojik kompleksler (PMC) ve teknik, yazılım ve bilgi desteği bileşenlerinden oluşur.
      Bu tür desteklerin bileşenleri ile PMK ve PTK'nın endüstriyel amaçlar için ürün olarak üretilmesi ve tedarik edilmesi gerekir.
      Bileşenler, AS'ye bağımsız parçalar olarak dahil edilebilir veya kompleksler halinde birleştirilebilir;
    • 4) kuruluşlarda (işletmelerde) AS oluşturulması, sistem kullanıcılarının ve bakım personelinin özel eğitimini gerektirir;
    • 5) AS ve komplekslerin işleyişi, oluşturma sürecinde yasal, metodolojik, dilbilimsel, matematiksel, organizasyonel ve diğer destek türlerinin bileşenleri olarak kabul edilen bir dizi organizasyonel ve metodolojik belge ile sağlanır. Bu yazılımların geliştirilmesi sürecinde elde edilen ayrı çözümler, teknik, yazılım veya bilgi yazılımı bileşenleri olarak uygulanabilir;
    • 6) ortak işleyiş ve etkileşim çeşitli sistemler ve kompleksler temelinde gerçekleştirilir yerel ağlar BİLGİSAYAR.

    Sistemlerin, komplekslerin ve bileşenlerin uyumluluğunu sağlamak için yerel bilgisayar ağları için kabul edilen spesifikasyonlar ve anlaşmalar zorunludur.

    2. CEN AU'nun diğer sistemler ve standart dizileriyle karşılıklı ilişkisi

    2.1. AS alanındaki standardizasyon, genelleştirilmiş "Bilgi Teknolojisi" sorunu üzerindeki çalışmanın ayrılmaz bir parçasıdır.

    2.2. Otomatik sistemler için dokümanları yöneten tek bir standart seti, diğer sistemler ve standart setleri ile birlikte, AS'nin oluşturulması ve işleyiş süreçleri için eksiksiz bir düzenleyici ve teknik destek oluşturmalıdır.

    2.3. EKS A.Ş. otomatik sistemlere özgü standardizasyon alanlarını kapsamalı ve geleneksel standardizasyon alanlarını yazılım ve donanıma, yazılım ve metodolojik komplekslere ve genel olarak otomatik sistemlere genişletmelidir.

    2.4. AS'nin oluşturulması ve işletilmesi süreçlerinin normatif ve teknik desteğinde standardizasyon yönergeleri ve görevleri aşağıdaki şekilde gruplandırılmıştır:

    • 1) ürünler için teknik gereksinimlerin oluşturulması;
    • 2) ürünlerin onaylanması ve belgelendirilmesi için test yöntemleri ve kurallarının düzenlenmesi;
    • 3) geliştirme kurallarının ve prosedürünün düzenlenmesi;
    • 4) dokümantasyon kurallarının oluşturulması;
    • 5) uyumluluğun sağlanması;
    • 6) sistemlerin işleyişinin organizasyonel ve metodolojik konularının düzenlenmesi.

    Talimatlar 1-4, ürünlerin geliştirilmesi, üretimi ve tedarikinde gelenekseldir. Yönergeler 5, 6 özeldir ve AS'nin doğasında bulunan özellikleri takip eder.

    2.5. Nükleer santrallerin bir bütün olarak ve bileşenlerinin, kabul edilen standardizasyon alanları ve görevleri çerçevesinde düzenleyici ve teknik dokümantasyonu ile sağlanması farklıdır.

    Endüstriyel amaçlı ürünler olarak teknik, yazılım ve bilgi desteği bileşenleri sırasıyla tasarım, yazılım ve bilgi ürünleri olarak kabul edilir. Bu ürünler mevcut ESKD, SRPP, ESPD, SGIP, USD standart setlerine, teknik ve ekonomik bilgilerin sınıflandırıcılarına ve kodlayıcılarına, "OTT", "Test yöntemleri", "TU" tipi standart setlerine tabidir. müşterinin OTT'si olarak.

    2.5.1. Tasarım ürünlerinin tüm yaşam döngüsü, makine mühendisliği ve enstrüman yapımında yürürlükte olan düzenleyici ve teknik belgelerle tam olarak sağlanır.

    2.5.2. Yazılım ürünleri, müşterinin ESPD ve OTT'sine dahil olan NTD ile sağlanır. Ancak, bu NTD'lerin kapsamı, yazılım ürünlerinin geliştirilmesi, oluşturulması, dağıtılması ve işletilmesi ile ilgili konuları yansıtacak şekilde genişletilmelidir.

    2.5.3. Bilgi ürünleri şu anda NTD ile sağlanmamaktadır, ancak DDD, teknik ve ekonomik bilgilerin sınıflandırıcıları ve kodlayıcıları çerçevesinde belirli konular üzerinde çalışılmıştır.

    2.6. Yazılım ve donanım ile yazılım ve metodolojik kompleksler, makine mühendisliğinde benzeri olmayan karmaşık ürünler olarak kabul edilir. PTK ve PMK'nın endüstriyel amaçlı ürünler olarak statüsü dikkate alındığında, bunların geliştirilmesine ilişkin kurallar ve prosedür, ürünlerin geliştirilmesi ve üretilmesi (SRPP) için sistem standartları tarafından belirlenen gerekliliklere benzer olmalıdır.

    • TEKNİK GÖREV

    bir bilgi sisteminin geliştirilmesi için

    1. Genel bilgiler

    4. Sistem gereksinimleri

    6. Sistemin kontrolü ve kabulü için prosedür

    1. Genel bilgiler

    TechnoPlus LLC (bundan sonra Geliştirici olarak anılacaktır) ve OptoTrading LLC (bundan sonra Müşteri olarak anılacaktır) arasındaki MP23 sayılı anlaşma uyarınca, Geliştirici veritabanını tasarlar, "Ticaret işlemleri için Muhasebe" bilgi sistemini geliştirir ve devreye alır.

    BDB tasarımının başladığı gün, bu Görev Tanımının imzalanmasını takip eden gündür.

    Geliştirme sürecinde Müşteri bu belgede açıklanan gereksinimleri değiştirirse, bunlar ayrı bir belge olarak düzenlenir ve Müşteri ile Veritabanı Geliştiricisi arasındaki Sözleşmede uygulama ve ödeme süresi açısından bir değişiklik veya ekleme gerektirir. anlaşmanın

    Müşteri, N XXX sözleşmesine uygun olarak DB Developer'ın çalışması için ödeme yapar.

    2. Sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri

    IS "Ticaret İşlemleri Muhasebesi", Müşterinin ana faaliyetleriyle ilgili bilgileri depolamak, işlemek ve analiz etmek için tasarlanmıştır.

    IS "Ticari İşlemlerin Muhasebesi" oluşturmanın amacı şudur:

    Tamamlanan ticaret işlemleri hakkında bilgi depolamak;

    Ticari işlemlerin muhasebeye yansıması;

    Alım satım işlemlerinin finansal sonuçlarının analizi;

    Terminoloji ve karşı taraflar bağlamında alım satım faaliyetinin analizi.

    3. Otomasyon nesnelerinin özellikleri

    3.1. Müşteri'nin ana faaliyet konusu mobilya ve ilgili ürünlerin banka havalesi yoluyla satışıdır.

    3.2. Müşteri KDV mükellefi değil

    3.3. Müşteri, gün içerisinde mal alım satımı için 100'den fazla alım satım işlemi yapmaz.

    3.4. Toplam ürün yelpazesi 3000 birimi geçmez

    3.5. Toplam yüklenici - tedarikçi sayısı 100 birimden fazla değildir.

    3.6. Karşı tarafların - alıcıların - sayısı sınırlı değildir. Sözleşme imzalandığında N XXX 300 birimdi.

    3.7. Müşteri, ağırlıklı ortalama maliyet yöntemine göre malları depodan siler.

    3.9. Gider hesabı olarak sadece 9. sınıf hesaplar kullanılmaktadır.

    3.10. İşletmenin ticari faaliyetinin mali sonuçları (nakit akışı ve operasyonların nakit akışı), 702 ve 902 perakende gelirleri esas alınarak hesaplanır.

    3.11. Alım satım işlemleri birincil belgeler olan Fatura, Harcama, Banka ekstresine kaydedilir.

    Pributkov irsaliyesi (PN) pіdpriєmstva deposuna teslim edilen malların gerçeğini kontrol edin ve bu bilgilerle birlikte:

    - sayı;

    - tarih;

    – karşı tarafın adı (firma - çalışan sonrası);

    – Ürün adı;

    - miktar;

    – cіnu tek ürün;

    - toplam.

    Vidatkov irsaliyesi (VN) vіdobrazhuє aslında vіdvantazhennya malları zі depo pіdpriієmstva satın alma ve mіstit іnformacіyu, PN'de іnformacіyu'ya gidiyorum (şirket satın alma siparişi vermek için yalnızca şirket-posta çalışanının yardımcısı).

    Banka hesabı satırı / vibuttya koshtіv іz rozrahunkovy rahunka (r / r) kabulü ve bu tür bilgilerin intikamı ihtiyacının gerçeğini doğrular:

    - tarih;

    – geliş işareti / vitrati koshtiv;

    – karşı tarafın adı (kime aldınız / kime para ödendi).

    3.12. Dış görünüm birincil belgesi є zdіysnennya pevnih ilanları için pіdstavoy, yakі zdіysnyuyut zmіni snіh muhasebe rakhunkіv. Ticari işletmenin operasyonları bu tür ilanları gerektirir (Tablo 3.1)

    Tablo 3.1 - Müşterinin işletmesinde muhasebede kullanılan kayıtlar

    Operasyon

    belge

    Hesap borcu

    Hesap kredisi

    Kayıt tutarı

    Gönderme

    Satınalma faturası

    belge tutarı

    Malların sevkiyatı

    Satış faturası

    belge tutarı

    sevk edilen malların maliyeti

    Cari hesaba para girişi

    Banka ekstresi (makbuz)

    belge tutarı

    Bir çek hesabından para transferi

    Banka ekstresi (harcama)

    belge tutarı

    Finansal sonuçların tanımı

    902 hesap kapatma tutarı için

    702 hesap kapatma tutarı için

    de 281 - stoktaki mallar;

    311 - ülkenin para biriminde rozrahunkovy rahunok;

    361 - vіtchiznyanimi alımları ile rozrahunki;

    631 - çalışanlar sonrası votchiznyani ile rozrakhunki;

    702 - mal satışından elde edilen gelir;

    902 - satılan malların toplanması (vitrati).

    3.13. Muhasebe açısından zvіtnostі vykoristovuєtsya ciro-sentetik görünüm bilançosu tablo 3.2'deki gibi görünüyor.

    Tablo 3.2 - Sentetik görünümün ciro denge değeri

    Pozisyon numarası

    Koçan dengesi

    kurt adam

    Kіntseve dengesi

    birlikte

    4. Sistem gereksinimleri

    IS "Ticaret işlemlerinin muhasebesi" aşağıdaki gereklilikleri karşılamalıdır:

    4.1. IS "Ticaret İşlemlerinin Muhasebeleştirilmesi" veritabanı, referans ve bilgilerin depolanmasını, görüntülenmesini ve düzenlenmesini sağlamalıdır. operasyon bilgisi.

    Referans bilgisi:

    o malların tanımı:

    Terminoloji (ürün) numarası;

    Ürün adı;

    Tanım;

    o yükleniciler - tedarikçiler;

    Karşı taraf numarası;

    Karşı tarafın adı;

    karşı taraf adresi;

    Kişiler;

    o karşı taraflar - alıcılar;

    Karşı taraf numarası;

    Karşı tarafın adı;

    karşı taraf adresi;

    Kişiler;

    o ticari işlemleri hesaba katmak ve finansal sonuçları analiz etmek için muhasebenin yürütüldüğü hesap planı;

    o tablo 3.1'de olduğu gibi, aşağıdaki forma sahip birincil belgelerden kaynaklanan, muhasebede ticari işlemleri görüntülemek için temel kayıtların listesi;

    Operatif bilgi:

    o Birincil belgeler: Fatura, Giden fatura, Banka ekstresi (belgelerin açıklaması 3.11'de verilmiştir)

    o Birincil belgelerden kaynaklanan muhasebe kayıtları (girişlerin türü tablo 3.2'de verilmiştir)

    o Stoktaki mallar hakkında bilgi:

    Ürün numarası;

    Miktar;

    toplam;

    Ortalama fiyat.

    4.2. IS "Ticaret İşlemleri için Muhasebe", aşağıdaki işlemleri otomatikleştirmenize izin vermelidir:

    4.2.1 Malların depoya kaydedilmesi (makbuz) ve sevkıyatına ilişkin gerçekleri yansıtın, yani depodaki mal miktarını ve ortalama maliyetini yeniden hesaplayın.

    4.2.2 Otomatik modda birincil belgelere göre muhasebe girişleri oluşturun.

    4.2.3 Aşağıdaki bilgileri arayın:

    Belirli bir süre için belirtilen türden birincil belgeler;

    Belirli bir tarih için belirtilen belge türü için kayıtlar;

    Karşı taraf hakkında bilgi

    Ürün Bilgisi

    4.2.4 Aşağıdaki bölümlerde belirtilen dönem için ticari faaliyet analizi yapın:

    Alım satım faaliyetlerinin finansal sonuçları;

    Her karşı taraf için uzlaşma sonuçları;

    Her kalem için depodaki mal kalıntıları;

    Her karşı taraf için işlemlerin maliyeti;

    Her mal türü için satış maliyeti ve miktarı

    4.2.5 Belirtilen dönem için raporlar oluşturun:

    IC'nin kurulu olduğu ekipman, kesintisiz bir güç kaynağı ile donatılmalıdır. Elektrik kesintisi durumunda, IC veri kaybı olmadan otomatik olarak kapanmalıdır.

    IS, yedekleme mekanizmaları sağlamalıdır, IS uygun donanım ve yazılımla donatılmalıdır:

    Güvenilirlik göstergelerinin nicel değerleri:

    - otomatik kapanma süresi 1 dakikadan fazla olmamalıdır;

    - bir arızadan sonra kurtarma süresi 30 dakikadan fazla olmamalıdır;

    - dizin hata toleransı IS 11/7 olmalıdır, yani IS'nin haftanın 7 günü, günde 11 saat kesintisiz çalışması.

    IS'nin bakımı, çalışmasına ara verilmeden yapılmalıdır.

    4.5 Deneme işletimi aşamasında güvenilirlik göstergelerini değerlendirme ve izleme yöntemleri için gereklilikler

    IS'nin deneme işletimi aşamalarındaki güvenilirlik göstergelerini kontrol etmek için bakım personelinin aşağıdaki bilgi işaretlerini içermesi gereken bir Arıza Günlüğü tutması gerekir:

    Hatanın oluştuğu tarih;

    Nesnenin çalışmasının başlangıcından hatanın tespit edilmesine kadar geçen toplam çalışma süresi;

    Hatanın dış belirtileri ve doğası;

    Hatanın tespit edildiği işin türü.

    4.6 IC performans gereksinimleri

    Sistem, günde 1000 belgeye kadar işleme yeteneğini desteklemelidir.

    Sistem aşağıdaki performansa sahip olmalıdır:

    İşlemlerin %80'inde yanıt süresi (işlem süresi) 1 saniyeden kısa olmalıdır;

    İşlemlerin %15'i - 5 saniyeden itibaren. 10 saniyeye kadar;

    İşlemlerin %5'i - 10 saniyeden fazla, ancak 30 dakikadan fazla değil.

    4.7 Hacim gereksinimleri (ölçeklenebilirlik)

    Sistem, verilere erişimi 10 yıl boyunca desteklemelidir.

    Bir günlük çalışma için veritabanı hacmindeki tahmini artış 20Mb'dir.

    4.8 BS personelinin sayısı, görevleri ve nitelikleri ile bunların çalışma şekli için gereklilikler

    IS ile çalışma, Müşterinin aşağıdaki personeli tarafından yürütülecektir:

    yönetici:

    Adet: 1;

    Yeterlilik: ağ yöneticisi, veritabanı yöneticisi;

    Fonksiyonlar: sistem güvenlik yönetimi, destek olmak her iş günü başında veri, yılda bir veri arşivleme;

    Çalışma saatleri: Haftada 5 gün, günde 1 saat

    Bir ticaret işlemi gerçeğini düzelten ve ticaret faaliyetlerinin sonuçlarını analiz eden bir operatör (kullanıcı):

    Miktar: 2;

    Yeterlilik: muhasebeci, PC kullanıcısı;

    İşlevler: birincil belgelerin girilmesi, depo hakkındaki mevcut bilgilerin korunması, muhasebe kayıtlarının oluşturulması, ticari faaliyetlerin sonuçlarının analizi, çalışma gününün başında veri yedekleme, Cumartesi ve Pazar günleri düşüyor.

    Çalışma Şekli: Sistemin haftanın 7 günü, günde 11 saat çalışmasını sağlayacak şekilde vardiyalı olarak;

    İşe erişim: 8 saatlik eğitim kursu;

    Personelin çalışma izni alabilmesi için IS'yi devreye almadan önce 8 saatlik bir eğitim kursunu tamamlaması gerekmektedir. Kursu tamamladıktan sonra, pratik problemleri çözmenin doğruluğu ve hızının yanı sıra iş bilgisi ve teknik talimatların değerlendirildiği bir test yapılır.

    Sistem, bir parola belirleyerek yalnızca kayıtlı IS kullanıcılarına işlevlerine erişim sağlamalıdır.

    4.10 Yazılım gereksinimleri ve DB IS'nin bileşimi, yapısı ve organizasyon yöntemleri

    Sistemdeki veriler şu adreste saklanmalıdır: ilişkisel VTYS MS SQL Sunucusu 2000.

    - T-SQL (SQL dilinin bir lehçesi);

    İLE # .

    Yazılım, masrafları Müşteri'ye ait olmak üzere satın alınan genel sistem yazılımından (satın alınan yazılım) ve IS oluşturma çalışmalarının bir parçası olarak geliştirilen özel yazılımdan oluşur.

    Sistem genelinde yazılım olarak aşağıdaki yazılımlar kullanılmalıdır:

    İşletim sistemi;

    Veritabanı yönetim sistemi MS SQL Server 2000;

    Yedekleme yazılımı;

    4.11 Donanım gereksinimleri

    Veritabanı sunucusu, 2 iş istasyonu.

    Ağ bant genişliği - 100 Mbps.

    4.12 Gelişme beklentileri için gereklilikler, IS'nin modernizasyonu

    IS yöneticisi tarafından Geliştiricinin katılımı olmadan IS'yi modernize etmek ve geliştirmek aşağıdaki seviyelerde mümkün olmalıdır:

    - IS referans bilgilerinin eklenmesi, değiştirilmesi, silinmesi;

    - yeni IP kullanıcılarının bağlanması/silinmesi;

    - şifre değişiklikleri;

    - verileri içe/dışa aktarma dış kaynaklar veri.

    Eski raporların yükseltilmesi ve yeni raporların oluşturulması düzeyinde Geliştiricinin sınırlı katılımıyla (telefon görüşmeleri) BS'yi yükseltmek ve geliştirmek mümkün olmalıdır. Geliştirici tarafından IP modernizasyonu konusunda telefonla danışmanlık imkanı ve koşulları, yeni bir sözleşme imzalanarak ayrı ayrı müzakere edilir.

    5. Sistemin oluşturulmasına ilişkin çalışmanın bileşimi ve içeriği

    IS "Ticaret İşlemlerinin Muhasebesi" tasarımına ilişkin çalışmalar üç aşamada gerçekleştirilmektedir.

    İlk aşama şunları içerir:

    İlk verilere dayanarak Müşteri tarafından talep edilen tüm bilgilerin elde edilme olasılığının kontrol edilmesi;

    DB IS tasarımı;

    Geliştirilen veritabanını bir test veri seti ile doldurmak;

    Kullanıcı arayüzü tasarımının geliştirilmesi;

    "Ticaret işlemleri için muhasebe" IS'nin geliştirilmesi için düşük seviyeli bir teknik şartnamenin geliştirilmesi

    İlk aşamanın tamamlanması, yapılan işle ilgili dahili bir Kanunun imzalanması ve IS'nin geliştirilmesi için düşük seviyeli bir teknik şartnamenin onaylanmasıyla teyit edilir.

    İkinci aşama, IS "Ticaret İşlemleri Muhasebesi" nin test versiyonunun geliştirilmesidir. bitirme bu aşama deneme işletimine bir test sürümünün getirilmesidir.

    Üçüncü aşama, bu Görev Tanımı ile belirlenen hataların, eksikliklerin ve tutarsızlıkların ortadan kaldırılmasını içeren IS "Ticari İşlemlerin Muhasebeleştirilmesi" pilot operasyonudur. İkinci aşamanın sonu, IS'nin ticari operasyona girmesidir.

    Her ikinci ve üçüncü aşamanın sonu, Anlaşmanın Tarafları tarafından Transfer ve Kabul Belgesi'nin imzalanmasıyla teyit edilir.

    İlk etabın süresi 10 gündür. Birinci aşamanın başlangıcı, Müşteri ve DB Geliştiricisi tarafından işbu Görev Tanımı'nın imzalandığı günü takip eden gün olarak kabul edilir.

    İkinci aşamanın süresi 20 gündür. İkinci aşamanın başlangıcı, IS'nin geliştirilmesi için düşük seviyeli teknik şartnamenin onaylandığı günü takip eden gündür.

    Üçüncü aşamanın süresi 20 gündür. Üçüncü aşamanın başlangıcı, Müşteri ve DB Geliştiricisi tarafından kabul Sertifikasının imzalandığı ve IS'nin test sürümünün deneme işletimi için devredildiği günü takip eden gün olarak kabul edilir.

    IS testi için veri seti Müşteri tarafından sağlanır.

    İşin ikinci aşamasının tamamlanmasının ardından, DB Geliştiricisi, Müşterinin test sunucusuna bir test IS'si kurar ve Müşteriye, IS Ticaret Muhasebesi ile çalışmak için gerekli prosedürlerin açıklamasını içeren bir ön kullanım kılavuzunu sağlar. Açıklamalar şurada sağlanır: elektronik formatta.

    Üçüncü çalışma aşamasının sonunda, DB Geliştiricisi Müşteriye veritabanını sunucuya kurmak için bir programın yanı sıra kullanıcı ve programcı talimatları ve IS'yi kurmak için talimatlar ile birlikte çalışmak için gerekli prosedürlerin açıklamalarını sağlar. IS "Ticaret İşlemlerinin Muhasebesi".

    6. Sistemin kontrolü ve kabulü için prosedür

    Birinci aşamanın sonunda, yapılan işle ilgili bir İç Kanun imzalanır ve alt düzey bir veri Sayfası IS'nin gelişimi için.

    İkinci ve üçüncü tasarım aşamalarının tamamlanmasının ardından Geliştirici, Müşteri'de BS'yi kurar, BS'nin işbu Görev Tanımı'nda belirtilen gerekliliklere uygun çalıştığını gösterir ve Devir ve Kabul Belgesi'ni imzalar.

    7. Sistemi faaliyete geçirmek için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler

    Deneme işletiminin başladığı gün Müşteri, Geliştiriciye IS "Muhasebe İşlemleri" test sürümünün konuşlandırılacağı sunucuya gerekli erişimi sağlamakla yükümlüdür.

    IS "Ticaret İşlemleri Muhasebesi" veritabanını kurmak için bir sunucunun bulunmaması, deneme veya ticari operasyon için IS "Ticari İşlemler Muhasebesi" Kabul Sertifikasını imzalamayı reddetmek için bir neden olamaz.

    BS'nin geliştirilmesine yönelik ikinci aşama olan "Ticari İşlemlerin Muhasebeleştirilmesi"nin sonunda, Geliştirici, Müşterinin personeli ile BS'ye hizmet verilmesi konusunda 8 saatlik bir eğitim kursu düzenler. Bu kursun sonunda Müşteri personeli test edilir.

    8. Dokümantasyon gereklilikleri

    Üçüncü aşamanın sonunda, IS "Ticari İşlemlerin Muhasebeleştirilmesi" Geliştiricisi aşağıdaki belgeleri Müşteriye aktarır:

    1. Programcının talimatları.

    Programcı El Kitabı, IS "Ticari İşlemlerin Muhasebeleştirilmesi" ile çalışmak için gerekli prosedürleri açıklar. Prosedürlerin açıklaması şunları içerir:

    Prosedürün adı;

    Prosedür tarafından gerçekleştirilen eylemlerin açıklaması;

    Parametrenin türünü, kayıt biçimini ve varsa varsayılan değeri gösteren giriş parametrelerinin açıklaması, parametre için tanımlanır;

    Çıktı parametrelerinin ve (veya) döndürülen kayıt kümelerinin, türlerini ve biçimlerini gösteren açıklaması

    Bir prosedür çağrısı örneği ve dönüş değerleri. Bir prosedürde birden çok çağrı seçeneği olabilirse, her seçenek için örnekler.

    2. IS "Ticari İşlemler için Muhasebe" kurulum talimatları.

    3. IS "Ticaret işlemleri için muhasebe" kullanıcısı için talimatlar.

    Diğer belgeler Müşteriye sağlanmaz. Talimatlar hem basılı hem de elektronik biçimde sağlanır. Basılı formdaki talimatlar tek bir kopya halinde sağlanır.

    Ana Sayfa > İş Tanımı

    RUSYA FEDERASYONU KÜLTÜR BAKANLIĞI

    Sankt Petersburg Devlet Üniversitesi kültür ve sanat

    Bilişim Bölümü ve Bilişim Teknolojileri

    BİLGİ SİSTEMİ TASARIMI

    TEKNİK GÖREV

    geliştirme için

    eğitim bilgi sistemi

    < Sistemin tam adı ve sembolü >

    4 sayfada

    __.__.200_ yayınlandı

    Sankt Petersburg

      Genel bilgi

        gelişme nedenleri

    "Bilgi sistemlerinin tasarımı ve kullanımı" dersinin incelenmesi ve geliştirilmesi kapsamında bir eğitim bilgi sistemi geliştirilmektedir.
        İşin başlaması ve tamamlanması için planlanan tarihler ile işin sonuçlarının işlenmesi ve Müşteriye sunulması prosedürü, bu İş Tanımının 4. ve 5. paragraflarında belirlenir.

      Bir eğitim bilgi sistemi oluşturmanın amacı ve hedefleri

        Amaç
    Eğitim bilgi sisteminin amacı:
      bir düzen olarak kullanılmak üzere "Bilgi sistemlerinin tasarımı ve kullanımı" dersinin içeriğinin öğrenci tarafından özümsenme derecesini göstermek daha fazla iş ah gerçek bir bilgi sistemi oluşturmak veya geliştirmek.
        Bir bilgi sisteminin eğitim projesi oluşturmanın hedefleri
    Eğitim bilgi sistemi aşağıdakiler için oluşturulmuştur:
      öğrencinin sistem tasarım sürecinin temel kavramlarını anlama, temel kavramlar ve tasarım yöntemleri arasındaki bağlantılarda ustalaşma, bir sistem projesi ve belgeleme geliştirme ve ayrıca gerçek bir IS oluşturma becerisi, sonuçlarını gösterme başarısı iş ve içeriğin asimilasyon derecesi Eğitim Kursu, projeyi ve pratik uygulamasını iyileştirmek için daha fazla çalışma için temel oluşturmak.

      Eğitim bilgi sisteminin raporlama materyalleri için gereklilikler

        Genel olarak malzemeler için gereklilikler
          Raporlama malzemelerinin bileşimi. Raporlama malzemeleri iki ana bölümden oluşmalıdır: proje belgeleri ve ACCESS DBMS (veya başka bir sistem) kullanılarak uygulanan bir bilgi sistemi düzeni (istekler, formlar, raporlar, erişim sayfaları ile birlikte tamamlanmış bir veritabanı). Yerleşim planı projeye uygun olarak uygulanmalıdır. Tasarım malzemeleri, yerleşimi ve yeteneklerini tanımlamalıdır.
        Proje belgelerinin içeriği
    Proje belgeleri aşağıdaki bölümleri içermelidir.
          Öngörülen IC'nin adının, geliştiricinin ve müşterinin bir göstergesi olan başlık sayfası. Konu alanının kısa bir açıklamasını içeren "Fizibilite çalışması" bölümü:
      Genel özellikleri konu alanı ve otomasyon üzerinde çalışmanın durumu bilgi faaliyetleri Bu bölgede; mevcut benzer sistemlerin yetenek ve özelliklerinin analizi; öngörülen IS'nin oluşturulmakta olduğu kuruluşun organizasyon yapısı; öngörülen IS'yi kullanan kuruluşun (sistemin) amacı nedir, işlevleri (kurumsal, "maddi", bilgilendirici); kuruluşun faaliyetlerinin temel teknik ve ekonomik göstergeleri; bilgi süreçleri, aralarındaki bağlantılar; kullanılan belgelerin bileşimi ve amaçları.
          Kısa Referans Koşulları. İş Tanımı şunları yansıtmalıdır:
      IS oluşturmanın amacı ve amacı; bir bütün olarak sistem gereksinimleri; ana otomatik işlevler ve görevler, problem çözmenin zamansal özellikleri ve sistemde bilgi sunmak için gereklilikler;
      geliştirilmekte olan sistemin etkinliği için kriterler (geliştirilmekte olan sistemin yararlılığını belirleyen faktörler, bunların değerlendirilmesi için kriterler); işin aşamalarının ve aşamalarının bir listesi ve bunların uygulanma zamanlaması, proje belgelerinin geliştirilmesinin zamanlaması.
          Aşağıdaki alt bölümleri içeren "Teknik tasarım" bölümü:
      sistemin işlevsel modeli (bir bağlam diyagramı, bir birinci düzey diyagram ve bir veya iki ikinci düzey diyagram sunun; ana işlevlerin bileşimini, aralarındaki ilişkileri tanımlayın: girdi, çıktı, kontrol akışları); veri akışı modeli (bir bağlam diyagramı, bir birinci düzey diyagram ve bir veya iki ikinci düzey diyagram sunun; sürücülerin bileşimini, ana işlevleri, bunların bilgi bağlantıları: giriş ve çıkış akışları; her veri depolama cihazı için, güncellemenin hacmini, sıklığını ve yoğunluğunu karakterize edin); bilgi desteğinin tanımı: girdi ve çıktı belgelerinin biçimleri, hacimlerinin özellikleri, sıklığı, güncelleme yoğunluğu, yapılarının analizi (ayrıntılar, açıklanan varlıklar), kullanılan sınıflandırıcılar, kodlama yöntemleri, veri güvenilirliğini sağlamak için gereklilikler.
          Kullanılan kaynakların listesi (literatür). Aşağıdaki alt bölümleri içeren "Çalışma taslağı" bölümü:
      yazılımın kavramsal şeması ve sistem veritabanının fiziksel şeması (Power Designer sistemi aracılığıyla geliştirilmiştir); IP projesinin uygulanması için belirli bir geliştirmenin açıklaması:
        ACCESS'teki (veya başka bir DBMS'deki) veritabanı şemasının bir açıklaması, Teknik Tasarımda formüle edilen işlevleri uygulayan görevlerin bir açıklaması (bu görevlerde kullanılan sorgular, formlar, raporlar, erişim sayfaları dahil). Diyalog formlarına ve bunların nasıl kullanılacağına dair talimatlara sahip olmak gereklidir. Projede karmaşık formlar, raporlar yoksa puan 1 puan düşürülür.
          Sonuç: Çalışmanın sonuçlarının özetlenmesi. Teknik Tasarım hükümlerinden hangilerinin ikinci bölümde uygulanıp uygulanmadığının ve nedenlerinin belirtilmesi.
        Bilgi sistemi düzeni

    Bilgi sisteminin yerleşimi projeye uygun olarak uygulanmalıdır. Projede açıklanan görevleri uygulayan sorgular, formlar, raporlar içeren tamamlanmış bir veritabanı olmalıdır.

        Dokümantasyon gereksinimleri
    Belgeleri geliştirirken aşağıdaki gereksinimleri göz önünde bulundurun:
      raporlama belgesinin bölümlerinin ve alt bölümlerinin bileşimi, "Tasarım belgelerinin içeriği" paragrafında listelenenlere karşılık gelmelidir, işlevsel modelin şemaları, veri akış modelleri, kavramsal ve fiziksel modeller şu şekilde hazırlanır: şekiller ve ana metinde yer alan; ana metinde ayrıca istek metinleri, formların sunum çizimleri, raporlar, erişim sayfaları, örnek belgeler, modelleri açıklayan tablolar, veri tabanı alanlarının özelliklerini açıklayan tablolar ek olarak verilmiştir.

      Çalışma aşamalarının listesi ve bunların uygulanması için son tarihler

    İşler verilen programa göre yürütülür. sonraki Sayfa(tablo 4.1).

      Raporlama malzemelerinin kontrolü ve kabulü için prosedür

        Raporlama materyalleri iki dönemde sunulur:
      Güz döneminde, programın ilk beş maddesine karşılık gelen bir rapor sunulur. İlkbahar döneminde, çalışmanın nihai sonuçları sunulur: bir rapor (önceki dönemin revize edilmiş sonuçları dahil) ve ayrıca bir veritabanı - geliştirilen IS'nin bir modeli.
        Güz döneminde yapılan çalışmaların değerlendirilmesi sınav şeklinde yapılır. Bahar yarıyılında tüm yıl çalışmaları dönem ödevi olarak teslim edilir. Sınava sadece dönem ödevini savunan öğrenciler girebilir. cezalar.
    Tasarım sonuçları, programda belirtilen süre içinde teslim edilmelidir. Son teslim tarihlerinin ihlali ceza gerektirir.Geliştirici (öğrenci) programda belirtilen süre içinde ilk raporu teslim etmezse, geçmesine izin verilmez. Rapor geç sunulursa, teste kabul kararı Müşteri (öğretmen) tarafından bir hafta içinde verilir. Geliştirici (öğrenci) nihai raporlama materyallerini programda belirtilen son teslim tarihinden sonra teslim ederse, ders çalışması 1 puan azaltılır. Koruma dönem ödevi raporlama materyallerinin sunulmasından en geç bir hafta sonra gerçekleşebilir. Sınava girme kararı, ders çalışmasını savunmanın sonuçlarına göre öğretmen tarafından verilir. Geliştiricinin burs alma isteği cezaların iptaline esas teşkil etmez..

    Raporlama materyallerinin geliştirilmesine ilişkin çalışma programı

    Tablo 4.1.

    Sahne adı

    Son teslim tarihi

    Sunulan malzemeler

    GÜZ DÖNEMİ ÇALIŞMALARI
    1 Bilgi sisteminin tasarlanması gereken konu alanı ve organizasyonun seçimi İlk dersten bir hafta sonra IP adı
    2 Konu alanının "anketi" (literatürde ve uzmanlarla iletişim sonucunda) Üçüncü dersten bir hafta sonra
    3 İşlevsel bir modelin geliştirilmesi Dördüncü dersten sonraki hafta El yazısı biçiminde fonksiyonel diyagramlar
    4 Veri akışı modelinin geliştirilmesi Beşinci dersten bir hafta sonra El Yazısı Veri Akış Şemaları
    5 Girdi ve çıktı belgelerinin açıklamalarının geliştirilmesi 25 Kasım'da sona eriyor Belgenin props yapısı, işlevsel bağımlılıklar detaylar
    6 3.2.1 - 3.2.5 paragrafları uyarınca proje belgelerinin geliştirilmesi Devam etmekte. pratik sınıflar.
    7 Proje belgelerinin teslimi 20 Aralık Rapor şeklinde belgeler
    BAHAR DÖNEMİ ÇALIŞMALARI
    8 Bağlamsal bir etki alanı şemasının geliştirilmesi İkinci dersten sonraki hafta El yazısı biçimindeki yazılımın bağlam diyagramı
    9 Seçilen VTYS'nin dilinde bir veritabanı şemasının geliştirilmesi İkinci uygulama sonunda sınıflar
    10 Sistemin uygulanması (veritabanı tablolarının doldurulması, sorguların, formların, raporların, erişim sayfalarının geliştirilmesi) Beşincinin sonunda pratik oturum İstekler, formlar vb. ile tamamlanmış veritabanı; öğretmene sunuldu
    11 Sonuçların kaydı (proje ve veri tabanı) 9. noktadan bir hafta sonra Kurs: rapor şeklinde ve bir dosyada belgeler; veri tabanı
    12 Ders savunması Bir önceki son teslim tarihinden sonra bir haftadan daha erken olmamak
  • Bir bilgi sisteminin yaşam döngüsü (LC). Temel yaşam döngüsü süreçleri. Yardımcı işlemler. örgütsel süreçler. Bilgi sistemleri tasarım teknolojileri.
  • Bir bilgi sisteminin tasarımı için görev tanımı. Görev tanımının ana bölümleri. Görev tanımlarını açıklayan standartlar. Gereksinimlerin analizi ve geliştirilmesi.
  • Bilgi sistemleri kullanıcılarının kimlik doğrulama yöntemleri.
  • Feistel ağı: çalışma prensibi ve blok şifreleme algoritmalarında kullanım
  • Elektronik teknik belgelerin geliştirilmesi için ana teknolojilerin analizi
  • Elektronik teknik belgelerin tipik yapıları
  • Bir multimedya ürünü tasarlamak ve uygulamak için teknolojiler.
  • 26. Bilgisayar grafik sistemlerinin sınıflandırılması. Vektör ve raster grafik bilgilerinin kodlanması. Raster grafikler görüntü nesneleridir. Vektör grafikleri görüntü nesneleridir.
  • 27. Renk modelleri rgb, cmYk, hsv (hsb), hsl, lab. Renk temsili, kodlama, atama.
  • 28. Yapısal kablolama: topolojiler, alt sistemler, pasif ekipman kategorileri.
  • 29. Yapısal bir kablolama sistemi tasarlama prosedürü.
  • 30. Küresel İnternet. ağ protokolleri. eksen modeli. Alan adı sistemi, alan adının ip adresine çevrilmesi. İnternette paket yönlendirme.
  • 31. Prolog'da mantıksal programlama. Prolog bilgi tabanının gerçekleri ve kuralları şeklinde konu alanı hakkındaki bilginin temsili. Tekrarların organizasyonu.
  • 1.1. Başarısızlıktan sonra geri alma yöntemi.
  • 33. İşletim sisteminin çekirdeği. İşletim sistemlerinin çekirdeklerinin sınıflandırılması. İşletim sistemi çekirdeklerinin çeşitli mimarilerinin avantajları ve dezavantajları.
  • 34. İşletim sisteminin bir bileşeni olarak dosya sistemi: tanım, ana işlevler ve yetenekler. Dosya sistemlerinin uygulama örnekleri.
  • 35. Bilgi ve entropi. Bilgi miktarını ölçmek. Bilgi özellikleri. Hartley ve Shannon formülleri.
  • 37. İletim hatalarını algılayan ve düzelten kodlar. Sistematik bir kod oluşturma. Hamming kodu.
  • 38. Programlama dillerinde değişken kavramı. atama operatörü. Uygulamada veri girişi ve çıkışının organizasyonu. Programlama dillerinde dallanma ve döngülerin organizasyonu.
  • 39. Verileri organize etmenin bir yolu olarak dizi. Dizilerin çeşitli programlama dillerinde gerçeklenmesi. Tek boyutlu ve çok boyutlu diziler. Dizileri işlemek için tipik algoritmalar.
  • 40. Programlama dillerinde alt programlar (yöntemler). Resmi ve gerçek parametreler. Küresel ve yerel değişkenler. Bir alt programın yinelemeli yürütülmesi.

    1. Bir bilgi sisteminin tasarımı için görev tanımı. Görev tanımının ana bölümleri. Görev tanımlarını açıklayan standartlar. Gereksinimlerin analizi ve geliştirilmesi.

    teknik görev- sistem için bir takım gereksinimleri belirten ve hem müşteri/kullanıcı hem de sistemin yüklenicisi/üreticisi tarafından onaylanan bir teknik belge (şartname). Bu spesifikasyon şunları da içerebilir: sistem gereksinimleri ve test gereksinimleri.

    Görev Tanımı aşağıdaki bölümleri içerir:

      Genel bilgi. Bu bölüm şunları içerir: geliştirmenin tam adı, müşterinin ve yüklenicinin tam adı ve ayrıntıları, geliştirmeye temel teşkil eden belgelerin bir listesi, işe başlama ve bitiş için olası tarihler, işleme prosedürü ve sistemi veya parçalarını oluşturmak için yapılan çalışmaların sonuçlarını müşteriye sunmak.

      Gelişimin temelleri ve amacı. Geliştirmenin amacı, otomatikleştirilmiş faaliyet süreçlerinin türü olarak anlaşılmaktadır.

      sistem gereksinimleri. Bir bütün olarak sistem için gereklilikleri ve sistem tarafından gerçekleştirilen işlevleri içeren alt bölümleri içerir.

      Sistemin oluşturulmasına ilişkin çalışmanın bileşimi ve içeriği. Bu proje kapsamında yapılması öngörülen işlerin listesi ve içerikleri

      Sistemin kontrol ve kabul sırası. Ara denetim için tahmini tarihleri ​​ve müşteriye tahmini teslimat tarihini içerir.

      Sistemi faaliyete geçirmek için geliştirme nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler. Sistemi işletmeye almak için yapılan hazırlık çalışmaları anlatılmaktadır.

      Dokümantasyon gereksinimleri. Sistem belgelerinin bir listesini ve bileşimini içerir.

      Geliştirme kaynakları. Sistemin geliştirilmesinde kullanılacak belgelerin ve literatürün bir listesini içerir.

    IC tasarımı için görev tanımlarını açıklayan üç standart vardır: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.

    Gereksinim geliştirme anketler, anketler vb. temelinde oluşturulabilir. Ek olarak, gereksinimler bir beyin fırtınası oturumu, üretim faaliyetlerinin gözlemlenmesi, yasal belgelerin analizi, önceden oluşturulmuş IS'lerin analizi, kullanımdaki IS versiyonlarının analizi temelinde oluşturulabilir.

    Gereksinimleri geliştirirken, genellikle bireysel gereksinimlerin belirsizliği, eksikliği ve tutarsızlığı sorunları ortaya çıkar. Gereksinim geliştirme aşamasında bu sorunları ortadan kaldırmak, aynı sorunları geliştirmenin sonraki aşamalarında düzeltmekten birkaç kat daha ucuza mal olur.

      Bilgi sistemlerinin kullanıcı arabirimi. Genel İlkeler yapı. kullanıcı arabirimi stilleri. Kullanıcı arabirimi performans kriterleri. Bir kullanıcı arabirimi oluşturmak için yönergeler. Tasarım kuralları.

    Kullanıcı arayüzü- bu, kullanıcının programla iletişim kurduğu cihazların yönetiminden sorumlu bilgi sisteminin yazılım kısmıdır.

    Kullanıcı arayüzünün planlanması ve tasarımı aşağıdaki modellere dayanmalıdır:

    - ruhsal model- bir kişinin gerçeklik duygusuna ve bilgisayarla ilgili bilgi ve deneyimine dayalı bazı beklentileri.

    - Özel Model- Kullanıcıların kendileri için yeni bir arayüzle nasıl çalıştıklarını gözlemleyerek ve çalışma hakkındaki geri bildirimlerini analiz ederek, gelecekteki arayüz hakkında genel bir fikir edinebilirsiniz. Kullanıcının IS üzerindeki çalışmaya mümkün olduğunca erken dahil edilmesi önemlidir.

    - Programcı Modeli- profesyonel faaliyetlerine dayanarak bir programcının kafasında doğar.

    kullanıcı arabirimi stilleri. Dört ana kullanıcı arayüzü stili vardır:

    - Grafiksel kullanıcı arayüzü (Grafiksel kullanıcı Arayüz, GUI) - Bu arayüz dört temel öğeye dayanmaktadır: pencereler, işaretçi (fare), menüler ve simgeler. Diğer öğeler de kullanılır: düğmeler, anahtarlar, giriş alanları vb. Bu arabirimin bir özelliği, gelişmiş ekran tasarım seçenekleri ve fare imleci kullanılarak kontrol edilmesidir.

    - ağ-arayüz (ağ kullanıcı Arayüz, WUI) - arayüz, GUI arayüzüne benzer, ancak başlangıçta ondan daha zayıftı. İçinde, özellikle, bir pencere modu kullanıldı ve nesnelerin "sürükle ve bırak" olasılığı yoktu. JavaScript ve Ajax'ın geliştirilmesiyle daha çok bir GUI arabirimi haline geldi.

    - ArayüzHUI (insan kullanıcı Arayüz) elde taşınır cihazlar için kullanıcı arabirimidir. Tipik olarak, bu cihazların çok küçük bir ekranı vardır. Menü öğeleri ve simgeler gibi bazı GUI öğelerini içerir.

    - Arayüzün nesne stili. Nesne programlama yetenekleri, nesne doğasını kullanıcı arabirimine aktarmanıza olanak tanır. Nesne yaklaşımı, sürükle ve bırak gibi özelliklerle karakterize edilir. bağlam menüsü, araç ipuçları vb.

    Bir dizi kullanıcı arayüzü kalite kriteri düşünün:

    - Kullanıcıları anlamak - Kullanıcıların ihtiyaçlarının program arayüzüne nasıl yansıdığı.

    - Tasarım Süreci Verimliliği– ürünün dikkatlice düşünülüp tasarlanmadığını belirler.

    - proje ihtiyacı- ürünün ekonomik ve sosyal önemi olup olmadığı.

    - Çalışma ve kullanım için uygunluk– ürünün öğrenilmesi ve kullanılmasının ne kadar zor olduğu.

    - YazışmaÜrün tasarımı sorunları çözmeye uygun mu?

    - estetik duygular– ürünün kullanımının estetik açıdan ne kadar hoş olduğu.

    - değişebilirlik– tasarımın kullanıcı gereksinimlerine göre ne kadar değişebileceği.

    - kontrol edilebilirlik- ürün yönetilebilirlik işlevinin ne ölçüde uygulandığı: kurulum yönetimi, eğitim, bakım.

    Grafik arayüz oluşturmanın genel ilkeleri:

    Sözde masaüstü şeklinde tek bir kullanıcı ortamı kullanmak;

    Verileri görüntülemek için grafik pencerelerini kullanma;

    Klavye dışı girdi kullanımı (fare kullanılarak).

    Kullanıcı Arayüzü Tasarım Kuralları:

    - Kullanıcı kontrolü - geliştiriciler, kullanıcıya IP üzerinde en eksiksiz kontrolü vermelidir (güvenliğin izin verdiği ölçüde). Bu ilkenin birkaç özel uygulamasını ele alalım:

    1) bellek üzerindeki yükü azaltmak - kullanıcının belleği çok büyük değil ve çok hızlı değil.

    2) arayüz uyumluluğu - kullanıcıların deneyimlerini ve bilgilerini yeni yazılımlarla çalışmak için aktarma yeteneği.

      Bilgi sistemlerinin modellenmesi. Modelleme dillerine duyulan ihtiyaç. DilUML. Nesne yönelimli tasarımın ilkeleri. Dil şemalarına genel bakışUML. Durum diyagramlarını ve sınıf diyagramlarını kullanın.

    modelleme- bu, incelenen nesnenin (orijinal) koşullu görüntüsü veya başka bir nesne (model) ile değiştirilmesi ve modelin özelliklerini inceleyerek orijinalin özelliklerinin incelenmesidir.

    İki koşul karşılanırsa simülasyon verimliliği elde edilebilir: model, orijinalin özelliklerinin doğru bir şekilde görüntülenmesini sağlar; model, gerçek bir nesne üzerinde ölçüm almanın doğasında var olan sorunları ortadan kaldırır.

    Modelleme dili - projeleri tanımlamak için kullanılan, çoğunlukla grafik olan bir notasyondur. Gösterim modelde kullanılan grafik nesnelerin bir koleksiyonudur. Gösterim, bir modelleme dilinin sözdizimidir. Modelleme dili bir yandan tasarımcının kararlarını kullanıcı için anlaşılır hale getirmeli, diğer yandan tasarımcılara bilgi sisteminin en resmi temsili için araçlar sağlamalıdır. Bir grafik görüntü, genellikle bilgi sunumunun en anlaşılır şeklidir.

    UML (birleşik modelleme dil- Birleştirilmiş Modelleme Dili) yazılım geliştirme alanında nesne modelleme için bir grafik tanımlama dilidir. UML, bir sistemin UML modeli adı verilen soyut bir modelini temsil etmek için grafik gösterim kullanır. Bu dil IS modelleme için geliştirilmiştir.UML bir programlama dili değildir, ancak UML modeline göre kod üretilir.

    Nesne Yönelimli Model IS'nin yapısının ve davranışının çeşitli yönlerini UML dilini kullanarak açıklayan bir dizi diyagramdır.

    DiyagramUML- Bu, genellikle köşeler (varlıklar) ve kenarlar (ilişkiler) içeren bir grafik olarak tasvir edilen bir dizi öğenin grafiksel bir temsilidir.

    Devamını oku: