Standardy IEEE. Prolozova N.O., Nazarova O.B., Davletkireeva L.Z.

Konserwacja zawsze była uznawana za jeden z głównych etapów cyklu życia oprogramowania. Już w połowie lat 70-tych uznano, że utrzymanie to etap, który pochłania ponad 50% kosztów opracowania i wdrożenia narzędzia programowego.

Od efektywności pracy na etapie wsparcia i utrzymania zależy ciągłość procesów biznesowych i bezpieczeństwo informacji korporacyjnych niezbędnych w życiu firm.

W przypadku złożonych systemów oprogramowania, które wymagają długotrwałego użytkowania i utrzymywania wielu wersji, istnieje pilna potrzeba uregulowania ich cyklu życia, sformalizowania i zastosowania standardowych profili oraz certyfikacji jakości programów.

Stosowanie dokumentów regulacyjnych i normatywnych sprawia, że ​​cykl życia oprogramowania jest bardziej zdefiniowany, przewidywalny pod względem struktury, treści, jakości i kosztów. Dokumentacja, zawartość informacyjna i zrozumiałość decydują o składzie i jakości dokumentacji pomocniczej.

Aby prawidłowo i efektywnie zorganizować najdłuższy i najważniejszy etap cyklu życia oprogramowania – Utrzymanie oprogramowania, które wymaga największych nakładów czasu, pracy i zasobów materialnych, należy uwzględnić zalecenia określone w międzynarodowych i krajowych standardy zawierające zapisy dotyczące optymalnej organizacji tego etapu.

W pierwszej kolejności należy przeanalizować interpretację etapu wsparcia w różnych normach.

Konserwacja oprogramowania jest zdefiniowana w normie IEEE Standard for Software Maintenance (IEEE 1219) jako modyfikacja oprogramowania po wydaniu do użytku w celu wyeliminowania usterek, poprawy wydajności i/lub innych cech (atrybutów) produktu lub przystosowania produktu do użytku w zmodyfikowanym środowisku. Co ciekawe, norma ta porusza także kwestie przygotowania do utrzymania przed oddaniem systemu do eksploatacji, jednakże strukturalnie odbywa się to na poziomie odpowiedniej aplikacji informacyjnej zawartej w normie.

Z kolei norma cyklu życia 12207 (IEEE, ISO/IEC, GOST R ISO/IEC) stawia konserwację jako jeden z głównych procesów cyklu życia. Norma ta opisuje konserwację jako proces modyfikacji oprogramowania pod względem jego kodu i dokumentacji w celu rozwiązania problemów pojawiających się podczas działania lub w celu uświadomienia sobie potrzeby ulepszenia pewnych cech produktu. Wyzwaniem jest modyfikacja produktu przy jednoczesnym zachowaniu jego integralności.

Międzynarodowa norma ISO/IEC 14764 (Standard for Software Engineering – Software Maintenance) definiuje konserwację oprogramowania w taki sam sposób, jak norma 12207, kładąc nacisk na prace przygotowawcze do działań konserwacyjnych przed uruchomieniem systemu, takich jak kwestie planowania, regulacje i operacje wsparcia.

Po oddaniu stacji do eksploatacji istnieje konieczność utrzymania jej wydajności na poziomie wymagań określonych w specyfikacjach technicznych. Zadanie to obejmuje zarówno eliminację usterek i błędów oprogramowania, jak i ewentualne zwiększenie funkcjonalności. Aby zorganizować te prace, należy odwołać się do zapisów określonych w normach.

Szereg źródeł, w szczególności norma IEEE 1216, definiuje trzy kategorie prac konserwacyjnych: dostosowanie, adaptacja i doskonalenie. Klasyfikacja ta została zaktualizowana w normie ISO/IEC 14764 wraz z wprowadzeniem czwartego składnika.

Dlatego dzisiaj mówimy o czterech kategoriach wsparcia:

1. Wsparcie korygujące polega na zmianach spowodowanych koniecznością wyeliminowania (poprawienia) rzeczywistych błędów w oprogramowaniu. Wsparcie naprawcze jest realizowane, jeśli oprogramowanie nie spełnia ustalonych wymagań.

2. Wsparcie adaptacyjne związane z koniecznością dostosowania oprogramowania do zmienionego otoczenia (warunków). Zmiany te związane są z wprowadzeniem nowych wymagań dotyczących interfejsu systemu, samego systemu lub środków technicznych.

3. Pełne wsparcie określa zmiany mające na celu poprawę charakterystyki wydajności oprogramowania i jego łatwości konserwacji. Zmiany te mogą skutkować udostępnieniem użytkownikom nowej funkcjonalności, rewizją technologii opracowywania dokumentów towarzyszących lub zmianami w samych dokumentach.

4. Wsparcie profilaktyczne ma na celu zmiany spowodowane koniecznością wyeliminowania (poprawienia) potencjalnych (ukrytych) błędów w produkcie programowym. Konserwacja zapobiegawcza jest zwykle przeprowadzana w przypadku oprogramowania związanego z zapewnieniem lub ochroną życia ludzkiego.

Łatwość konserwacji jest jednym ze wskaźników jakości oprogramowania, a także ważną cechą dla klienta, dostawcy i użytkownika.

Utrzymywalność lub łatwość konserwacji systemu oprogramowania jest zdefiniowana na przykład w IEEE 610.12-90 Standard Glossary for Software Engineering Terminology, aktualizacja 2002) jako łatwość konserwacji, rozbudowy, adaptacji i dostosowania w celu spełnienia określonych wymagań. Norma ISO/IEC 9126-01 (Inżynieria oprogramowania – Jakość produktu – Część 1: Model jakości, 2001) uznaje łatwość konserwacji za jedną z cech jakości.

Możliwość konserwacji musi zostać określona przed opracowaniem oprogramowania, tj. została sporządzona odpowiednia umowa pomiędzy klientem a dostawcą w ramach prac „przygotowawczych” procesu zamówienia zgodnie z (ISO/IEC, #M12291 1200009075 GOST R ISO/ IEC) 12207#S. Deweloper tworzy plan wsparcia, który powinien odzwierciedlać konkretne metody zapewnienia łatwości konserwacji oprogramowania, odpowiednie zasoby i algorytm wykonywania pracy.

Jakość narzędzia programowego jest ważnym aspektem konserwacji oprogramowania. Opiekunowie oprogramowania powinni posiadać program zapewnienia jakości oprogramowania obejmujący sześć cech jakości zdefiniowanych w normie ISO/IEC 9126. Opiekunowie oprogramowania powinni posiadać odpowiedni proces definiowania, opisywania, wybierania, stosowania i doskonalenia metodologii oceny (pomiaru) cech oprogramowania .

Aby obniżyć koszty dalszego wsparcia, w całym procesie rozwoju konieczne jest określenie, ocena i kontrola cech wpływających na łatwość konserwacji. Regularne wdrażanie takich prac ułatwia dalszą konserwację, zwiększając jej łatwość konserwacji (jako cechę jakościową).Jest to dość trudne do osiągnięcia, ponieważ takie cechy są często ignorowane podczas programowania.

Jak wspomniano wcześniej, utrzymanie oprogramowania jest kosztownym etapem cyklu życia, w celu optymalizacji jego pracy konieczne jest stosowanie różnych metod szacowania kosztów utrzymania.

Na koszt prac pomocniczych wpływa wiele różnych czynników. Norma ISO/IEC 14764 stwierdza, że ​​„istnieją dwie najpopularniejsze metody szacowania kosztów utrzymania: – model parametryczny i wykorzystanie doświadczenia”. Najczęściej oba te podejścia łączy się w celu poprawy trafności oceny.

Istnieją różne metody wewnętrznej oceny produktywności personelu pomocniczego w celu porównania wyników różnych grup wsparcia. Organizacja obsługowa musi określić mierniki, według których będzie oceniana odpowiednia praca. Standardy IEEE 1219 i ISO/IEC 9126-01 (Inżynieria oprogramowania – Jakość produktu – Część 1: Model jakości, 2001) oferują wyspecjalizowane wskaźniki skupiające się szczególnie na kwestiach konserwacji i powiązanych programach.

Prace konserwacyjne muszą być ściśle regulowane i opisane, zawierające szczegółowe dane wejściowe i wyjściowe procesu. Procesy te są ujęte w normach IEEE 1219 i ISO/IEC 14764.

Proces utrzymania rozpoczyna się według normy IEEE 1219 od momentu uruchomienia oprogramowania i dotyczy m.in. planowania działań utrzymaniowych.

Norma ISO/IEC 14764 wyjaśnia postanowienia normy cyklu życia 12207 związane z procesem konserwacji. Prace konserwacyjne opisane w tym standardzie są podobne do prac w IEEE 1219, z tą różnicą, że są nieco inaczej pogrupowane.

Przyjrzyjmy się bliżej fragmentom normy GOST R ISO/IEC 14764-2002, która zawiera pełny autentyczny tekst międzynarodowej normy ISO/IEC 14764.

Zgodnie z normą GOST R ISO/IEC 14764-2002, która opisuje proces konserwacji oprogramowania, szczegóły procesu konserwacji oprogramowania muszą być udokumentowane, aby personel pomocniczy działał w ramach jednego procesu. System wskaźników jakości (metryk) powinien ułatwiać realizację procesu utrzymania i przyczyniać się do doskonalenia (modernizacji) tego oprogramowania.

Konserwator powinien (5.5.2.1 GOST R ISO/IEC 12207) przeanalizować raport o problemie lub propozycję modyfikacji pod kątem jego wpływu na kwestie organizacyjne, istniejący system i połączenia interfejsów z innymi systemami.

Na podstawie analizy konserwator musi (5.5.2.3 GOST R ISO/IEC 12207) opracować opcje wdrożenia zmiany. Przed dokonaniem zmian w systemie konserwator musi (patrz 5.5.2.5 GOST R ISO/IEC 12207) uzyskać zgodę na wybraną opcję zmiany zgodnie z umową i potwierdzenie, że dokonana zmiana spełnia wymagania określone w umowie (patrz 5.5 .4.2 GOST R ISO/IEC 12207). Konserwator musi (5.5.2.4 GOST R ISO/IEC 12207) udokumentować: raport o problemie lub propozycję modyfikacji, wyniki ich analizy i możliwości wdrożenia zmian.

Aby właściwie kontrolować transfer systemu, należy opracować, udokumentować i wykonać plan przeniesienia obiektu (5.5.5.2 GOST R ISO/IEC 12207). Użytkownicy muszą być zaangażowani w planowane prace.

W przypadku działań wspierających istnieje wiele unikalnych stanowisk pracy i praktyk, które należy wziąć pod uwagę przy organizowaniu wsparcia. SWEBOK (ang. Software Engineering Body of Knowledge) podaje następujące przykłady tego rodzaju unikalnych cech.

Audycja:kontrolowane i skoordynowane działanie polegające na przekazywaniu oprogramowania od programistów do grupy, usługi lub organizacji odpowiedzialnej za dalsze wsparcie.

Akceptuj/odrzucaj prośby o modyfikację : Prośby o zmiany można albo przyjąć i przenieść do pracy, albo odrzucić z różnych uzasadnionych powodów - wielkości i/lub złożoności wymaganych zmian, a także wymaganego do tego wysiłku. Odpowiednie decyzje można podjąć także na podstawie priorytetu, oceny wykonalności, braku zasobów (w tym braku możliwości zaangażowania deweloperów w rozwiązywanie zadań modyfikacyjnych, jeśli istnieje realna taka potrzeba), zatwierdzonego planu wdrożenia w następnym zwolnić itp.

Środki powiadamiania personelu konserwacyjnego i śledzenia statusu żądań modyfikacji i raportów o błędach : Funkcja wsparcia użytkownika końcowego, która inicjuje wysiłki w celu oceny potrzeby, ustalenia priorytetów i kosztów modyfikacji związanych z żądaniem lub zgłoszonym problemem.

Analiza wpływu:analiza możliwych konsekwencji zmian wprowadzonych w istniejącym systemie.

Wsparcie oprogramowania: praca nad konsultacją użytkowników, prowadzona w odpowiedzi na ich prośby o informacje, np. dotyczące odpowiednich reguł biznesowych, weryfikacji, zawartości danych oraz konkretnych pytań użytkowników i zgłaszania przez nich problemów (błędy, awarie, nieoczekiwane zachowania, niezrozumienie aspektów pracy z system itp.); P.).

Umowy i zobowiązania: Należą do nich klasyczna umowa o poziomie usług (SLA), a także inne aspekty umowne, w oparciu o które grupa wsparcia/usługa/organizacja wykonuje odpowiednią pracę.

Ponadto istnieją dodatkowe czynności wspierające proces utrzymania ruchu, określane przez SWEBOK jako czynności personelu utrzymaniowego, które nie wymagają bezpośredniej interakcji z użytkownikami, ale są niezbędne do realizacji czynności z nimi związanych. Prace te obejmują: planowanie konserwacji, zarządzanie konfiguracją, weryfikację i certyfikację, ocenę jakości oprogramowania, różne aspekty przeglądu, analizy i oceny, audyt i szkolenie użytkowników. Taka praca specjalna (wewnętrzna) obejmuje także szkolenie personelu pomocniczego.

Tabela 1 poniżej zawiera krótki przegląd głównych standardów stosowanych w organizacji utrzymania systemów informatycznych.

Tabela 1. Standardy w zakresie utrzymania systemów informatycznych

Oprócz omówionych powyżej międzynarodowych i krajowych standardów regulujących proces utrzymania systemów informatycznych, istnieją różne dokumenty regulujące i standardy wewnątrzzakładowe (korporacyjne), których podstawą są standardy międzynarodowe. W tym przypadku szczególną uwagę zwraca się na jakość dokumentacji, która w dużej mierze decyduje o konkurencyjności oprogramowania. Tworząc złożone produkty programowe i zapewniając ich cykl życia, należy wybrać niezbędne standardy i stworzyć cały zestaw dokumentów, czyli profil zapewniający regulację wszystkich etapów i prac utrzymaniowych.

Rozważmy zastosowanie standardów utrzymania systemów informatycznych na konkretnym przykładzie.Wysoka jakość funkcjonowania systemu wymaga ciągłego dostosowywania się do zmieniających się procesów biznesowych organizacji, a także szybkiego reagowania na awarie i rozwiązywania problemów. W związku z tym kierownictwo ZAO Firm SoftInCom zdecydowało o konieczności zawarcia umowy z twórcami korporacyjnego systemu informacyjnego (CIS) Orient Express na aktualizację i utrzymanie systemu.

Utrzymanie Eastern Express CIS obejmuje wsparcie kilku typów (zgodnie z GOST R ISO IEC 14764-2002). Mianowicie wsparcie naprawcze, które wiąże się ze zmianami spowodowanymi koniecznością wyeliminowania (poprawienia) rzeczywistych błędów w oprogramowaniu. Wsparcie naprawcze jest realizowane, jeśli oprogramowanie nie spełnia ustalonych wymagań. A także adaptacyjne i pełne wsparcie modernizujące oprogramowanie.

Konieczność wsparcia naprawczego pojawia się w przypadku wystąpienia błędów systemowych, a także błędów spowodowanych przez użytkownika. Do błędów spowodowanych przez użytkownika zalicza się np. przypadkowe usunięcie ważnych danych, co skutkuje koniecznością skorzystania z kopii zapasowej systemu. Błędy systemowe zdarzają się dość często, szczególnie po zainstalowaniu nowych wydań, ponieważ nowe wydania implikują dość poważne zmiany w istniejących technologiach przetwarzania danych i włączenie nowych modułów.

Potrzeba wsparcia adaptacyjnego pojawia się, gdy zachodzą zmiany w funkcjonowaniu dowolnego procesu biznesowego (przeprowadzenie promocji, zmiana druków zewnętrznych, zamówień z centrali itp.) lub gdy przeprowadzenie jakichkolwiek operacji jest niewygodne i wymaga zmian w interfejsie systemu.

Pełne wsparcie udzielane jest znacznie rzadziej niż pozostałe rodzaje wsparcia. Przeprowadza się go w przypadku pojawienia się wielu podobnych incydentów, próśb i życzeń użytkowników, a także po przeanalizowaniu możliwości systemu przez projektantów CIS.

Prace pomocnicze można podzielić na cztery etapy: analiza usterek i modyfikacji, wdrożenie modyfikacji, ocena i akceptacja wyników wsparcia, przeniesienie na inną platformę. Każdy z tych etapów zawiera określone dane wejściowe i wyjściowe i musi zostać udokumentowany.

Tabela 2 przedstawia główne etapy wsparcia i wyniki w załączonym akapicie dokumentacji.

Tabela 2. Etapy procesu utrzymania systemu informatycznego

Zgodnie z 5.5.2.1 GOST R ISO/IEC 12207, konserwator musi przeanalizować raporty użytkowników dotyczące problemu. Aby zautomatyzować rejestrację i rejestrację wniosków od użytkowników Orient Express CIS, wykorzystywany jest system rejestracji incydentów MantisBT. Na podstawie danych zarejestrowanych w systemie MantisBT generuje dokument „Raport o usterkach zidentyfikowanych przez użytkowników” zawierający następujące pola: numer zdarzenia, data powstania, kategoria, istota incydentu, proponowane rozwiązanie.

Na podstawie analizy konserwator musi (5.5.2.3 GOST R ISO/IEC 12207) opracować opcje wdrożenia zmian. W tym celu opracowywany jest dokument „Dziennik przygotowanych i zatwierdzonych dostosowań nowej podstawowej wersji CIS”, zawierający następujące dane: kategoria, wada zidentyfikowana przez organizację wspierającą, wada zidentyfikowana przez użytkowników CIS, korekta.

Następnie konserwator musi (5.5.4.2 GOST R ISO/IEC 12207) uzyskać potwierdzenie, że dokonana zmiana spełnia wymagania określone w umowie. W tym celu generowany jest dokument „Powiadomienie użytkowników o wydaniu nowej wersji CIS” i oczekuje się potwierdzenia zgody na instalację nowej wersji.

Aby właściwie kontrolować transfer systemu, musi istnieć

Struktura cyklu życia oprogramowania zgodnie z normą ISO/IEC 12207 opiera się na trzech grupach procesów (rys. 1):

· główne procesy cyklu życia oprogramowania (zakup, dostawa, rozwój, eksploatacja, wsparcie);

· procesy pomocnicze zapewniające realizację procesów głównych (dokumentacja, zarządzanie konfiguracją, zapewnienie jakości, weryfikacja, certyfikacja, ocena, audyt, rozwiązywanie problemów);

· procesy organizacyjne (zarządzanie projektami, tworzenie infrastruktury projektowej, definiowanie, ocena i doskonalenie samego cyklu życia, szkolenia).

Ryż. 1. Procesy cyklu życia oprogramowania.

Proces nabycia(proces przejęcia). Składa się z działań

i zadania Klienta kupującego oprogramowanie. Proces ten obejmuje następujące kroki:

1) wszczęcie przejęcia;

2) przygotowanie propozycji ofert;

3) przygotowanie i dostosowanie umowy;

4) nadzór nad działalnością dostawcy;

5) odbiór i zakończenie pracy.

Proces dostarczenia(proces dostawy). Obejmuje czynności i zadania wykonywane przez dostawcę, który dostarcza klientowi oprogramowanie lub usługę. Proces ten obejmuje następujące kroki:

1) rozpoczęcie dostawy;

2) przygotowanie odpowiedzi na propozycje ofert;

3) przygotowanie umowy;

4) planowanie;

5) wykonanie i kontrola;

6) kontrola i ocena;

7) dostawę i zakończenie robót.

Proces rozwoju(proces rozwoju). Przewiduje czynności i zadania realizowane przez programistę i obejmuje tworzenie oprogramowania i jego komponentów zgodnie z określonymi wymaganiami, w tym przygotowanie dokumentacji projektowej i operacyjnej, przygotowanie materiałów niezbędnych do sprawdzenia funkcjonalności i odpowiedniej jakości oprogramowania produkty, materiały niezbędne do organizacji szkolenia personelu itp.

Proces rozwoju obejmuje następujące kroki:

1) analiza wymagań systemowych;

2) projektowanie architektury systemu;

3) analiza wymagań oprogramowania;

4) projektowanie architektury oprogramowania;

5) szczegółowy projekt oprogramowania;

6) kodowanie i testowanie oprogramowania;

7) integracja oprogramowania;

8) testowanie kwalifikacji oprogramowania;

9) integracja systemu;

10) badania kwalifikacyjne systemu;

11) instalacja oprogramowania;

12) akceptacja oprogramowania.

Proces operacyjny(proces operacyjny). Obejmuje działania i zadania operatora – organizacji obsługującej system. Proces ten obejmuje następujące kroki:

1) testy operacyjne;

2) działanie systemu;

3) wsparcie użytkowników.

Proces konserwacji(proces konserwacji). Przewiduje czynności i zadania realizowane przez organizację towarzyszącą (służbę eskortową). Proces ten uruchamia się, gdy zmiany (modyfikacje) oprogramowania i związanej z nim dokumentacji wynikają z problemów lub konieczności modernizacji lub adaptacji oprogramowania. Zgodnie ze standardem IEEE-90 konserwacja oznacza wprowadzanie zmian w oprogramowaniu w celu skorygowania błędów, poprawy wydajności lub dostosowania się do zmienionych warunków pracy lub

wymagania. Zmiany dokonane w istniejącym oprogramowaniu nie mogą naruszać

jego integralność. Proces konserwacji obejmuje przeniesienie oprogramowania na inne środowisko (migrację) i kończy się wycofaniem oprogramowania.

Proces konserwacji obejmuje następujące działania:

1) analiza problemów i wniosków o modyfikację oprogramowania;

2) modyfikacja oprogramowania;

3) kontrola i odbiór;

4) przeniesienie oprogramowania na inne środowisko;

5) likwidacja oprogramowania.

Do grupy procesów pomocniczych zalicza się:

Dokumentacja;

Zarządzanie konfiguracją; Zapewnienie jakości;

Weryfikacja; orzecznictwo;

Ocena partycypacyjna;

Rozwiązanie problemu.

Proces dokumentowania(proces dokumentacyjny). Zapewnia sformalizowany opis informacji tworzonych w trakcie cyklu życia oprogramowania. Proces dokumentowania obejmuje następujące kroki:

1) projektowanie i rozwój;

2) udostępnienie dokumentacji;

3) obsługa dokumentacji.

Proces zarządzania konfiguracją(proces zarządzania konfiguracją). Polega na stosowaniu procedur administracyjnych i technicznych w całym cyklu życia oprogramowania w celu ustalenia stanu komponentów oprogramowania w systemie, zarządzania modyfikacjami oprogramowania, opisywania i przygotowywania raportów o stanie komponentów oprogramowania oraz wniosków o modyfikację, zapewniania kompletności, kompatybilności i poprawności komponentów oprogramowania, zarządzaj przechowywaniem i dostawą BY. Zgodnie ze standardem IEEE-90 przez konfigurację oprogramowania rozumie się ogół jego cech funkcjonalnych i fizycznych.

charakterystyki ustalone w dokumentacji technicznej i zaimplementowane w oprogramowaniu.

Zarządzanie konfiguracją pozwala organizować, systematycznie uwzględniać i kontrolować zmiany w oprogramowaniu na wszystkich etapach cyklu życia. Ogólne zasady i zalecenia dotyczące zarządzania konfiguracją oprogramowania znajdują odzwierciedlenie w projekcie normy ISO/I EC CD 12207-2:1995 „Technologia informatyczna – Procesy cyklu życia oprogramowania. Część 2.

Zarządzanie konfiguracją oprogramowania”. Proces zarządzania konfiguracją obejmuje następujące działania:

1) identyfikacja konfiguracji;

2) kontrola konfiguracji;

3) rozliczanie stanu konfiguracji;

4) ocena konfiguracji;

5) zarządzanie wydaniami i dostarczanie.

Proces zapewnienia jakości(proces zapewnienia jakości). Zapewnia odpowiednią pewność, że oprogramowanie i jego procesy cyklu życia są zgodne z określonymi wymaganiami i zatwierdzonymi planami. Jakość oprogramowania rozumiana jest jako zbiór właściwości charakteryzujących zdolność oprogramowania do spełnienia określonych wymagań. Aby uzyskać rzetelną ocenę tworzonego oprogramowania, proces zapewnienia jego jakości musi odbywać się niezależnie od podmiotów bezpośrednio związanych z tworzeniem oprogramowania. Można wykorzystać wyniki innych procesów wspierających, takich jak weryfikacja, walidacja, wspólna ocena, audyt i rozwiązywanie problemów. Proces zapewnienia jakości obejmuje następujące działania:

1) zapewnienie jakości produktu;

2) zapewnienie jakości procesu;

3) zapewnienie innych wskaźników jakości systemu.

Proces weryfikacji(proces weryfikacji). Polega na stwierdzeniu, że produkty programowe powstałe w wyniku jakiegoś działania w pełni spełniają wymagania lub warunki określone wcześniejszymi działaniami (weryfikacja w wąskim znaczeniu oznacza formalne potwierdzenie poprawności oprogramowania).

Proces atestacji(proces walidacji). Polega na określeniu kompletności zgodności określonych wymagań i stworzonego systemu lub oprogramowania z ich konkretnym przeznaczeniem funkcjonalnym. Certyfikacja zwykle odnosi się do potwierdzenia i oceny wiarygodności testowania oprogramowania.

Proces oceny partycypacyjnej(proces wspólnego przeglądu). Ma na celu ocenę stanu prac nad projektem i oprogramowaniem powstałym w trakcie realizacji tych prac (działań). Koncentruje się przede wszystkim na kontrolowaniu planowania i zarządzaniu zasobami projektu, personelem, sprzętem i narzędziami.

Proces audytu(proces audytu). Jest to określenie zgodności z wymaganiami, planami i warunkami umowy.

Proces rozwiązywania problemów(proces rozwiązywania problemu). Polega na analizie i rozwiązywaniu problemów (w tym wykrytych niespójności) niezależnie od ich pochodzenia lub źródła, które zostały wykryte podczas rozwoju, eksploatacji, konserwacji lub innych procesów. Każdy wykryty problem musi zostać zidentyfikowany, opisany, przeanalizowany i rozwiązany.

Do grupy procesów organizacyjnych cyklu życia oprogramowania zalicza się:

Kontrola;

Tworzenie infrastruktury;

Poprawa;

Wydanie nowych wersji;

Edukacja.

Proces zarządzania(proces zarządzania). Składa się z czynności i zadań, które może wykonać każda strona zarządzająca swoimi procesami. Ta strona (menedżer) jest odpowiedzialna za zarządzanie wydaniem produktu, zarządzanie projektami i zarządzanie zadaniami powiązanych procesów, takich jak nabycie, dostawa, rozwój, obsługa, konserwacja itp.

Proces tworzenia infrastruktury(proces infrastrukturalny). Obejmuje wybór i wsparcie (utrzymanie) technologii, standardów i narzędzi, wybór i instalację sprzętu i oprogramowania wykorzystywanego do rozwoju, obsługi lub konserwacji oprogramowania. Infrastruktura musi być modyfikowana i utrzymywana zgodnie ze zmianami wymagań dla odpowiednich procesów. Infrastruktura z kolei jest jednym z obiektów zarządzania konfiguracją.

Proces doskonalenia(proces doskonalenia). Zapewnia ocenę, pomiar, kontrolę i doskonalenie procesów cyklu życia oprogramowania. Doskonalenie procesów cyklu życia oprogramowania ma na celu zwiększenie produktywności wszystkich zaangażowanych w nie specjalistów poprzez doskonalenie stosowanej technologii, metod zarządzania, doboru narzędzi i szkoleń

personel.

Proces uczenia(proces szkoleniowy). Obejmuje szkolenie wstępne i późniejszy ciągły rozwój personelu.

W dziedzinie IT najbardziej praktyczne standardy publikują następujące organizacje:

• Instytut Inżynierii Elektrycznej i Elektroniki(IEEE, www.ieee.org) od wielu lat jest wiodącą organizacją naukowo-techniczną, m.in. zajmującą się tworzeniem standardów dokumentacji oprogramowania. Większość standardów jest opracowywana przez różne komitety składające się z doświadczonych i odpowiedzialnych profesjonalnych inżynierów. Niektóre standardy IEEE stały się również standardami ANSI (American National Standards Institute). Podstawą przygotowania MU dla CP były głównie standardy IEEE. Schmidt M. Wdrażanie standardów inżynierii oprogramowania IEEE.
• Międzynarodowa Organizacja Normalizacyjna (ISO) ma ogromne wpływy na całym świecie, zwłaszcza wśród organizacji producentów zajmujących się Unią Europejską (UE). Obecnie praktycznie wszystkie współczesne standardy informatyczne przetłumaczone i przyjęte w Federacji Rosyjskiej są normami przygotowanymi przez ISO wspólnie z Międzynarodową Komisją Elektrotechniczną – IEC. Wiesz, że szczególną uwagę przywiązuje się do kwestii zapewnienia jakości produktów na poziomie międzynarodowym, dlatego zgodnie z dekretem rządu rosyjskiego nr 113 z 02.02.1998, zgodność z wymaganiami ISO 9000 (szereg norm regulujących zarządzanie jakością w przedsiębiorstwach) jest warunkiem uzyskania zamówienia rządowego.
• Instytut Technologii Inżynierii Oprogramowania(Software Engineering Institute - SEI, sei.cmu.edu - ponad 1000 artykułów) został powołany przez Departament Obrony USA na Uniwersytecie Carnegie Mellon w celu podniesienia poziomu technologii oprogramowania wśród wykonawców Departamentu Obrony. Prace SEI zostały również przyjęte przez wiele firm komercyjnych, które uznają doskonalenie procesu tworzenia oprogramowania za strategiczny cel firmy. Przyjrzymy się jednemu ze standardów opracowanych przez SEI, zwanym Capability Maturity Model (CMM).
• Konsorcjum Technologii Manipulacji Obiektami(Object Management Group, www.omg.org) to organizacja non-profit zrzeszająca około 700 firm członkowskich. OMG wyznacza standardy rozproszonego przetwarzania obiektowego. Należy zauważyć, że OMG używa ujednoliconego języka modelowania UML jako standardu do opisu projektów. Przeanalizujemy szczegółowo UML, ponieważ... użycie tego języka w połączeniu z ujednoliconym procesem Rational stanowi podstawę do opracowania rdzenia projektu kursu.

Pojęcie cyklu życia systemu

Potrzebę standaryzacji tworzenia oprogramowania najlepiej opisuje wprowadzenie standardu GOST R ISO/IEC 12207-99 „Technologie informacyjne. Procesy cyklu życia oprogramowania”: „Oprogramowanie jest integralną częścią technologii informatycznych i tradycyjnych systemów, takich jak transport, wojsko, medycyna i finanse. Istnieje wiele różnych standardów, procedur, metod, narzędzi i typów środowisk operacyjnych do tworzenia oprogramowania i zarządzania nim. Ta różnorodność stwarza wyzwania w projektowaniu oprogramowania i zarządzaniu nim, szczególnie przy łączeniu produktów i usług oprogramowania. Strategia rozwoju oprogramowania wymaga przejścia od tej wielości do wspólnego porządku, który pozwoli specjalistom zajmującym się oprogramowaniem „mówić tym samym językiem” podczas tworzenia oprogramowania i zarządzania nim. Ten międzynarodowy standard zapewnia taki ogólny porządek.”

Norma GOST R ISO/IEC 12207-99 definiuje podstawową koncepcję systemu oprogramowania – „cykl życia” (GOST R ISO/IEC TO 15271-2002 „Technologia informatyczna. Wytyczne dotyczące stosowania GOST R ISO/IEC 12207”).

GOST R ISO/IEC 12207-99 wprowadza koncepcję modelu cyklu życia jako struktury składającej się z procesów obejmujących życie systemu od ustalenia dla niego wymagań aż do zakończenia jego użytkowania. Proponuje się skorygowanie tej definicji i podzielenie jej na dwie definicje:

1. koło życia– zespół procesów podzielonych na prace i zadania, obejmujący rozwój, obsługę i konserwację oprogramowania, obejmujący czas życia systemu od ustalenia dla niego wymagań aż do zaprzestania jego używania.
2. model cyklu życia– struktura określająca kolejność procesów, prac i zadań realizowanych w całym cyklu życia systemu oprogramowania, a także zależności między nimi.

Procesy cyklu życia dzielą się na trzy grupy: główny, pomocniczy i organizacyjny.

Do grupy procesów głównych zalicza się: nabycie, dostawa, rozwój, obsługa i wsparcie. Główne procesy cyklu życia są wdrażane pod kontrolą głównych stron zaangażowanych w cykl życia oprogramowania. Strona główna to jedna z tych organizacji, która inicjuje lub przeprowadza rozwój, obsługę lub konserwację oprogramowania. Głównymi stronami są klient, dostawca, programista, operator i personel wsparcia oprogramowania.

Rysunek – Główne procesy cyklu życia IS

Do grupy procesów pomocniczych zalicza się procesy zapewniające realizację procesów głównych:

• dokumentacja;
• Zarządzanie konfiguracją;
• Zapewnienie jakości;
• weryfikacja;
• orzecznictwo;
• stopień;
• rewizja;
• rozwiązywanie problemów.

Do grupy procesów organizacyjnych zalicza się procesy:

• zarządzanie projektami;
• tworzenie infrastruktury projektowej;
• zdefiniowanie, ocena i doskonalenie samego cyklu życia;
• Edukacja.

W tekście GOST 12207-99 Prace wchodzące w skład procesów głównych, pomocniczych i organizacyjnych scharakteryzowano bardzo ogólnie, w zasadzie nakreślono jedynie ich kierunki, dlatego aby rozpocząć projektowanie potrzebne będą standardy i dodatkowa literatura ujawniająca treść każdego pojedynczego procesu lub, jeszcze lepiej, praca indywidualna.
Z grupy procesów głównych największe zainteresowanie budzi proces rozwoju.
Należy zauważyć, że GOST 34.601-90 „Systemy zautomatyzowane. Etapy tworzenia” proces tworzenia zautomatyzowanego systemu dzieli się na następujące etapy:

• tworzenie wymagań dla prelegentów,
• opracowanie koncepcji AC,
• zadanie techniczne,
• projekt wstępny,
• projekt techniczny,
• dokumentacja robocza,
• uruchomienie,
• akompaniament.

Etapy są podzielone na etapy, których treść pokrywa się z treścią szeregu zadań opisanych w GOST 12207-99.

Proces rozwoju

proces rozwoju przewiduje czynności i zadania realizowane przez twórcę oraz obejmuje prace nad stworzeniem oprogramowania i jego komponentów zgodnie z określonymi wymaganiami, w tym przygotowanie dokumentacji projektowej i operacyjnej; przygotowanie materiałów niezbędnych do badania wydajności i odpowiedniej jakości oprogramowania, materiałów niezbędnych do organizacji szkoleń personelu itp.

Rysunek - Struktura procesu rozwoju

Praca przygotowawcza

rozpoczyna się od wyboru modelu cyklu życia PS, który odpowiada skali, znaczeniu i złożoności projektu. Działania i zadania procesu rozwojowego muszą odpowiadać wybranemu modelowi. Deweloper musi wybrać, dostosować się do warunków projektu i zastosować uzgodnione z klientem standardy, metody i narzędzia rozwojowe, a także sporządzić plan realizacji prac.

Analiza wymagań

Analiza wymagań oprogramowania polega na określeniu następujących cech każdego komponentu oprogramowania:

• funkcjonalność, w tym charakterystykę wydajności i środowisko operacyjne komponentu;
• interfejsy zewnętrzne;
• specyfikacje niezawodności i bezpieczeństwa;
• wymagania ergonomiczne;
• wymagania dotyczące wykorzystywanych danych;
• wymagania dotyczące instalacji i odbioru;
• wymagania dotyczące dokumentacji użytkownika;
• wymagania dotyczące obsługi i konserwacji.

Projekt architektury

System na wysokim poziomie polega na określeniu elementów jego wyposażenia, oprogramowania i operacji wykonywanych przez personel obsługujący system. Architektura systemu musi być zgodna z wymaganiami systemowymi oraz przyjętymi standardami i praktykami projektowymi.
Projektowanie architektury oprogramowania obejmuje następujące zadania (dla każdego komponentu oprogramowania):

• przekształcenie wymagań wobec oprogramowania w architekturę, która na wysokim poziomie definiuje strukturę oprogramowania i skład jego komponentów;
• opracowywanie i dokumentowanie interfejsów oprogramowania do systemów oprogramowania i baz danych;
• opracowanie wstępnej wersji dokumentacji użytkownika;
• opracowanie i dokumentacja wstępnych wymagań testowych oraz planu integracji oprogramowania.

Szczegółowy projekt

PS obejmuje następujące zadania:

• opis komponentów oprogramowania i interfejsów pomiędzy nimi na niższym poziomie, wystarczającym do ich późniejszego samodzielnego kodowania i testowania;
• opracowanie i udokumentowanie szczegółowego projektu bazy danych;
• opracowywanie i dokumentowanie wymagań testowych oraz planu testów komponentów oprogramowania;

Kodowanie i testowanie

PS obejmuje następujące zadania:

• rozwój (kodowanie) i dokumentacja każdego komponentu oprogramowania i bazy danych, a także zestawu procedur testowych i danych do ich testowania;
• testowanie każdego komponentu oprogramowania i bazy danych pod kątem zgodności z stawianymi im wymaganiami. Wyniki testów komponentów muszą być udokumentowane;
• aktualizacja (jeśli to konieczne) dokumentacji użytkownika;
• aktualizacja planu integracji PS.

Dla każdego z zagregowanych komponentów opracowywane są zestawy testów i procedury testowe w celu weryfikacji każdego z wymagań kwalifikacyjnych podczas kolejnych testów kwalifikacyjnych. Wymóg kwalifikacyjny to zestaw kryteriów lub warunków, które muszą zostać spełnione, aby zakwalifikować oprogramowanie jako spełniające jego specyfikacje i gotowe do użycia w terenie.

GOST R ISO/IEC 12119-2000 „Technologie informacyjne. Pakiety oprogramowania. Wymagania jakościowe i testowanie” zawiera instrukcje określające procedurę badania produktu na zgodność z jego wymaganiami jakościowymi. Testowanie jest procesem pracochłonnym. Zdaniem części ekspertów odsetek
Rozkład czasu pomiędzy procesami projektowania – rozwoju – testowania kształtuje się w proporcji 40-20-40. W związku z tym systemy automatyzacji testów stają się coraz bardziej powszechne. Norma IEEE 1209-1992 „Zalecana praktyka dotycząca oceny i wyboru narzędzi CASE” określa ogólne wymagania dotyczące funkcjonalności narzędzi do automatyzacji testów.

Integracja systemu

polega na montażu wszystkich jego elementów, w tym podstacji i wyposażenia. Po integracji system z kolei przechodzi badania kwalifikacyjne na zgodność z zestawem stawianych mu wymagań. Jednocześnie przygotowywany i weryfikowany jest także komplet dokumentacji systemu.

Instalacja systemu

prowadzone przez dewelopera zgodnie z planem w środowisku i na sprzęcie przewidzianym umową. Podczas procesu instalacji sprawdzana jest funkcjonalność oprogramowania oraz baz danych.

Akceptacja systemu

przewiduje ocenę wyników badań kwalifikacyjnych oprogramowania i systemu oraz dokumentowanie wyników oceny, które Klient przeprowadza przy pomocy programisty. Deweloper dokonuje ostatecznego przekazania oprogramowania klientowi zgodnie z umową, zapewniając jednocześnie niezbędne szkolenia i wsparcie. Nasz kurs ma na celu przede wszystkim szczegółowe zbadanie pierwszych czterech prac procesu tworzenia oprogramowania. Każdej z tych prac poświęcony zostanie odrębny rozdział, a teraz dla dalszej prezentacji wypada powiedzieć kilka słów o modelach cyklu życia PS.

Modele cyklu życia oprogramowania

Model cyklu życia– struktura określająca kolejność procesów, prac i zadań realizowanych w całym cyklu życia systemu informacyjnego, a także zależności między nimi.

Do chwili obecnej najbardziej rozpowszechnione stały się dwa główne modele cyklu życia:

• model kaskady (wodospadu);
• model spiralny.

Model kaskadowy

Model kaskadowy demonstruje klasyczne podejście do rozwoju różnych systemów w różnych obszarach zastosowań. Do rozwoju systemów informatycznych model ten był szeroko stosowany w latach 70. i pierwszej połowie lat 80. Jest to model kaskadowy, który stanowi podstawę serii GOST 34.xxx i normy Departamentu Obrony USA DOD-STD-2167A. Przetwarza GOST 12207-99 w GOST 34.601-90 „Systemy zautomatyzowane. Etapy tworzenia” nazywane są etapami i różnią się nieznacznie składem.
Model kaskadowy zapewnia sekwencyjną organizację procesów. Co więcej, przejście do następnego procesu następuje dopiero po całkowitym zakończeniu wszystkich prac nad poprzednim. Każdy proces kończy się wydaniem kompletnego zestawu dokumentacji, wystarczającego, aby prace mogły być kontynuowane przez inny zespół programistów.

Główną wadą modelu kaskadowego jest to, że błędy i niedociągnięcia na każdym etapie pojawiają się z reguły na kolejnych etapach pracy, co prowadzi do konieczności cofnięcia się. Według firmy konsultingowej The Standish Group, w 1998 roku w Stanach Zjednoczonych ponad 28% projektów dotyczących systemów informatycznych przedsiębiorstw zakończyło się niepowodzeniem; prawie 46% projektów IT zostało zrealizowanych powyżej budżetu (średnio 189%); a jedynie 26% projektów mieści się w przydzielonych ramach czasowych i budżecie.

Ponadto wady modelu kaskadowego obejmują:

• trudność w pracy równoległej;
• złożoność zarządzania projektami;
• wysoki poziom ryzyka i nierzetelna inwestycja (powrót do poprzednich etapów może wiązać się nie tylko z błędami, ale także ze zmianami, jakie zaszły w temacie lub wymaganiach klienta w trakcie developmentu. Ponadto oddanie projektu do rewizji z tych powodów nie powoduje gwarantuje, że do czasu powstania kolejnej wersji projektu tematyka nie ulegnie już zmianie, a de facto oznacza to, że istnieje możliwość, że proces deweloperski będzie przebiegał „cyklicznie” i system nigdy nie osiągnie punktu uruchomienie.Koszty projektu będą stale rosły, a czas dostawy gotowego produktu stale się opóźnia).

Model spiralny

W przeciwieństwie do kaskady polega na iteracyjnym procesie tworzenia systemu informacyjnego. Model spiralny został zaproponowany w połowie lat 80. XX wieku przez Barry'ego Boehma. Każdy obrót spirali odpowiada stworzeniu fragmentu lub wersji oprogramowania, gdzie wyjaśniane są cele i cechy projektu, określana jest jego jakość i planowana jest praca nad kolejnym zakrętem spirali. Przy każdej iteracji szczegóły projektu są pogłębiane i konsekwentnie doprecyzowywane, a także gromadzone są dane metryczne, które służą optymalizacji kolejnych iteracji. Jednak mechanizmy zapewnienia integralności dokumentacji stają się bardziej skomplikowane (gdy dany wymóg lub definicja jest podana w tekście tylko raz), co wymaga użycia specjalnych narzędzi.
Główne cechy modelu spiralnego:

• odmowa ustalenia wymagań i przypisania priorytetów wymaganiom użytkownika;
• opracowanie sekwencji prototypów zaczynając od wymagań o najwyższym priorytecie;
• identyfikacja i analiza ryzyka w każdej iteracji;
• Ocena wyników na końcu każdej iteracji i planowanie kolejnej iteracji.

Szybki rozwój aplikacji

W latach 90-tych XX wieku w oparciu o model spiralny powstała praktyczna technologia zwana „szybkim tworzeniem aplikacji” – RAD (Rapid Application Development). W tym przypadku cykl życia składał się z czterech etapów:

• analiza i planowanie wymagań,
• projekt,
• realizacja,
• realizacja.

Podstawowe zasady RAD:

• tworzenie aplikacji w iteracjach;
• opcjonalne zakończenie prac na każdym etapie cyklu życia oprogramowania;
• obowiązkowe zaangażowanie użytkowników w proces rozwoju;
• wykorzystanie narzędzi do zarządzania konfiguracją ułatwiających wprowadzanie zmian w projekcie i utrzymanie gotowego systemu;
• wykorzystanie prototypowania w celu lepszego zrozumienia i zaspokojenia potrzeb użytkowników;
• testowanie i rozwój projektu, prowadzone równolegle z rozwojem;
• rozwój przez mały, dobrze zarządzany zespół profesjonalistów;
• kompetentne zarządzanie rozwojem systemu, jasne planowanie i kontrola realizacji prac.

Na początku 2001 roku kilku czołowych ekspertów w dziedzinie inżynierii oprogramowania (Martin Fowler, Kent Beck itp.) utworzyło grupę zwaną Agile Alliance w celu wspierania i rozwijania nowego podejścia do projektowania – „szybkiego tworzenia oprogramowania” (Agile Software Rozwój). Jedną z realizacji tego podejścia jest programowanie ekstremalne (XP).

Zasady programowania ekstremalnego są następujące:

1. Zespół składa się z trzech do dziesięciu programistów. Jeden lub więcej klientów musi być w stanie w sposób ciągły zapewniać specjalistyczną wiedzę.
2. Programy są opracowywane w trzytygodniowych iteracjach. Każda iteracja generuje działający, przetestowany kod, który może być natychmiast wykorzystany przez klientów. Gotowy system jest wysyłany do użytkowników końcowych na koniec każdego okresu wydawniczego, który może zająć od dwóch do pięciu iteracji.
3. Jednostką zebranych wymagań oprogramowania jest „historia użytkownika” zapisana na karcie indeksowej, która opisuje funkcjonalność z punktu widzenia użytkownika, którą można opracować w jednej iteracji. Klienci i programiści planują pracę nad kolejną iteracją w następujący sposób:
   • programiści szacują czas wykonania każdej karty;
   • klienci ustalają priorytety, zmieniają je i weryfikują w razie potrzeby. Tworzenie historii rozpoczyna się od dyskusji pomiędzy programistami a ekspertem klienta.
4. Programiści pracują w parach i przestrzegają rygorystycznych standardów kodowania, które ustalili na początku projektu. Tworzą testy jednostkowe dla wszystkiego, co piszą i zapewniają, że testy te będą uruchamiane za każdym razem, gdy kod zostanie poddany obowiązkowej kontroli wersji i zarządzaniu konfiguracją.
5. Podczas gdy programiści pracują, klienci odwiedzają programistów, aby wyjaśnić pomysły, napisać testy akceptacyjne systemu do uruchomienia podczas iteracji, a na koniec iteracji wybrać historie do wdrożenia w następnej iteracji.
6. Zespół codziennie organizuje spotkania operacyjne, podczas których programiści rozmawiają o tym, nad czym pracują, co idzie dobrze, a co wymaga pomocy. Na koniec każdej iteracji odbywa się kolejne spotkanie, podczas którego oceniają, co poszło dobrze, a nad czym należy popracować następnym razem. Lista ta jest publikowana, aby każdy mógł ją zobaczyć podczas pracy nad następną iteracją.
7. Jedna osoba w zespole zostaje wyznaczona na „mentora”. Razem z członkami zespołu ocenia wykorzystanie przez nich podstawowych technik: programowania i testowania w parach, rotacji par, utrzymywania prostoty rozwiązań projektowych, komunikacji itp. w celu ciągłego doskonalenia procesu rozwoju.

Podejście szybkiego tworzenia oprogramowania nie jest uniwersalne i ma zastosowanie tylko do projektów określonej klasy. Aby scharakteryzować takie projekty, Alistair Coburn wprowadził dwa parametry – krytyczność i skalę.
Krytyczność jest określana na podstawie konsekwencji spowodowanych defektami w oprogramowaniu i może mieć jeden z czterech poziomów:

• C – wady powodują utratę wygody;
• D – wady powodują utratę możliwych do odzyskania środków (materialnych lub finansowych);
• E – wady powodują utratę niezastąpionych środków;
• L – wady zagrażające życiu ludzkiemu.

Skalę wyznacza liczba deweloperów uczestniczących w projekcie:

• od 1 do 6 osób – mała skala;
• od 6 do 20 osób – skala średnia;
• powyżej 20 osób – duża skala.

Według Coburna szybkie tworzenie oprogramowania ma zastosowanie tylko w przypadku małych i średnich projektów o niskiej krytyczności (C lub D). Oznacza to, że technologie RAD i XP najlepiej sprawdzają się w przypadku stosunkowo małych projektów realizowanych dla konkretnego klienta i nie mają zastosowania do budowy skomplikowanych programów obliczeniowych, systemów operacyjnych czy programów do zarządzania złożonymi obiektami w czasie rzeczywistym, a także systemów, od których zależy bezpieczeństwo ludzi.

Ujednolicony proces tworzenia oprogramowania

Obecnie trwają prace nad stworzeniem pewnego rodzaju uniwersalnego procesu rozwoju SI. W 1999 Pracownicy Rational Ivar Jacobson, Gradi Booch i James Rumbaugh opublikowali książkę Unified Software Development Process, która została przetłumaczona na język rosyjski i wydana przez wydawnictwo Peter Publishing House w 2002 roku. Unified Process jest próbą połączenia modeli kaskadowych i iteracyjnych J C.

Jednocześnie cykl życia dzieli się na 4 fazy:

1. Początek: przeprowadzana jest wstępna ocena projektu.
   • tworzony jest uproszczony model przypadków użycia zawierający przypadki użycia najbardziej krytyczne z punktu widzenia wdrożenia;
   • tworzona jest wersja próbna architektury zawierająca najważniejsze podsystemy;
   • ryzyka są identyfikowane i ustalane priorytety;
   • planowana jest faza projektowania;
   • cały projekt jako całość jest z grubsza oceniany;
2. wyjaśnienie (opracowanie): większość przypadków użycia jest szczegółowo opisana i opracowana jest architektura systemu. Na koniec fazy projektowania kierownik projektu oblicza zasoby potrzebne do ukończenia projektu. Należy odpowiedzieć na pytanie: czy przypadki użycia, architektura i plan są wystarczająco opracowane, aby można było nałożyć zobowiązania umowne na wykonanie robót i przystąpić do przygotowania i podpisania „Specyfikacji Technicznych”?;
3. budowa– tworzenie produktu. Na koniec tej fazy produkt zawiera wszystkie przypadki użycia, które programiści i klienci zdecydowali się uwzględnić w bieżącej wersji;
4. wdrożenie (przejście)- Wprowadzenie produktu. Wersja beta produktu jest testowana przez dział testowy firmy, przy okazji organizowane są próby działania systemu przez użytkowników. Następnie programiści naprawiają wszelkie znalezione błędy i włączają niektóre z sugerowanych ulepszeń do głównej wersji, która jest gotowa do szerokiej dystrybucji.

Każda faza USDP może obejmować jedną lub więcej iteracji, w zależności od wielkości projektu. Podczas każdej iteracji można wykonać 5 głównych i pewną liczbę dodatkowych wątków roboczych.
Główne kierunki pracy w USDP obejmują:

• definicja wymagań (RD);
• analiza (A);
• projekt (P);
• wdrożenie (P);
• testowanie (T).

Dodatkowe wątki robocze mogą obejmować:

• prace związane z zapewnieniem jakości (K),
• dokumentacja (D),
• zarządzanie projektami (P),
• zarządzanie konfiguracją (CM),
• tworzenie i zarządzanie infrastrukturą (I)
• i inni.

Rysunek - Model cyklu życia według ujednoliconego procesu tworzenia oprogramowania

Wybór modelu cyklu życia w dużej mierze zależy od rodzaju i skali opracowywanego systemu. Do opracowywania większości zautomatyzowanych systemów sterowania z wolnym czasem zastosowanie ma iteracyjny model cyklu życia, natomiast model kaskadowy jest bardziej odpowiedni dla systemów czasu rzeczywistego. Podczas wykładów, studiując zagadnienia projektowania SI, szczególną uwagę zwrócimy na wykorzystanie Unified Modeling Language (UML), a ponieważ jego twórcami są Grady Booch i James Rumbaugh, zwrócimy się także ku ideologii Unified Development Process.

Rysunek - Dokumenty regulacyjne towarzyszące procesowi rozwoju

Wspieranie procesów cyklu życia

Proces zapewnienia jakości

Proces zapewnienia jakości zapewnia odpowiednie gwarancje, że system oprogramowania i jego procesy cyklu życia są zgodne z określonymi wymaganiami i zatwierdzonymi planami. Jakość oprogramowania rozumiana jest jako zespół cech charakteryzujących zdolność oprogramowania do spełnienia określonych wymagań.

Rysunek - Struktura pomocniczych procesów cyklu życia

W kontekście GOST R ISO/IEC 9126-93. "Technologia informacyjna. Ocena oprogramowania. Charakterystyki jakościowe i wytyczne dotyczące ich stosowania Przez cechę jakości rozumie się „zestaw właściwości (atrybutów) oprogramowania, za pomocą których opisywana i oceniana jest jego jakość”.

Standard definiuje sześć kompleksowych cech opisujących jakość oprogramowania przy minimalnym powielaniu:

• funkcjonalność– zbiór atrybutów związanych z istotą zbioru funkcji i ich specyficznymi właściwościami. Funkcje to te, które realizują stwierdzone lub przewidywane potrzeby;
• niezawodność– zbiór atrybutów związanych ze zdolnością oprogramowania do utrzymania poziomu wydajności w określonych warunkach przez określony czas;
• praktyczność– zespół atrybutów związanych z zakresem prac niezbędnych do użytkowania i indywidualną oceną takiego użytkowania przez określony lub zamierzony krąg użytkowników;
• efektywność– zbiór atrybutów związanych z zależnością pomiędzy poziomem jakości działania oprogramowania a ilością zasobów wykorzystywanych w określonych warunkach
• łatwość konserwacji– zbiór atrybutów związanych z zakresem prac niezbędnych do przeprowadzenia określonych zmian (modyfikacji);
• Mobilność– zbiór atrybutów związanych ze zdolnością oprogramowania do przenoszenia z jednego środowiska do drugiego.

GOST 28195-89 „Ocena jakości oprogramowania. Postanowienia ogólne" na najwyższym, pierwszym poziomie identyfikuje 6 wskaźników - czynniki jakości: niezawodność, poprawność, łatwość obsługi, wydajność, wszechstronność i łatwość konserwacji. Czynniki te są szczegółowo ujęte w 19 kryteriach jakości na drugim poziomie. Dalsze uszczegółowienie wskaźników jakości reprezentują metryki i elementy oceny, których jest około 240. Zaleca się fachową ocenę każdego z nich w skali od 0 do 1. Proponuje się wybrać skład zastosowanych czynników, kryteriów i metryk w zależności od celu, funkcji i etapów cyklu życia oprogramowania.

Standard GOST 28806-90 „Jakość oprogramowania. Warunki i definicje" ogólne koncepcje programu, narzędzia programowego, oprogramowania i ich jakości są sformalizowane. Podano definicje 18 najczęściej używanych terminów związanych z oceną cech programu. Wyjaśniono pojęcia podstawowych wskaźników jakości podane w GOST 28195-89.
Kwestia zapewnienia jakości oprogramowania wymaga szczególnej uwagi, gdyż według Rządu Federacji Rosyjskiej nr 113 z 02.02.1998 spełnienie wymagań międzynarodowej normy dotyczącej zapewniania jakości i zarządzania jakością ISO 9000 jest warunkiem otrzymania zamówienie rządowe.
Na obecnym etapie nie wystarczy mieć tylko metody oceny jakości produkowanego i wykorzystywanego oprogramowania (kontrola wyników), trzeba umieć planować jakość, mierzyć ją na wszystkich etapach cyklu życia oprogramowania i dostosowywać proces produkcji oprogramowania w celu poprawy jakości.

Normy serii ISO 9000 są zbyt ogólne. Każda firma produkująca oprogramowanie i pragnąca wdrożyć skuteczny system zarządzania jakością w oparciu o normy serii ISO 9000 musi uwzględnić specyfikę swojej branży i opracować system wskaźników jakości, który odzwierciedlałby realny wpływ czynników jakościowych na produkt programowy. W tym celu wiele organizacji ustanowiło oddzielny, systematyczny i kompleksowy proces weryfikacji – Zapewnienie Jakości – który rozpoczyna się w momencie uruchomienia projektu, obejmuje inspekcję i testowanie i najlepiej jest przeprowadzać go niezależna organizacja. W rzeczywistości najczęściej kontrolę jakości przeprowadza grupa współpracowników autora dzieła.
Celem kontroli jest sprawdzenie części projektu pod kątem wad:

• dokumentacja,
• wymagania,
• Wyniki analizy,
• projekt,
• zestawienia itp.

Znaczenie inspekcji wykazano poprzez porównanie kosztów oraz wykrycie i skorygowanie defektu podczas inspekcji i podczas integracji, według Fagina, M., „Design and Code Inspections to Redukuj błędy w rozwoju programu”, IBM Systems Journal. Niektórzy autorzy uważają te dane za bardzo niedoszacowane.

Kwestię wyszukiwania defektów zaczęto traktować znacznie poważniej po tym, jak wart kilka miliardów dolarów amerykański satelita wysłany na Wenus stracił kontrolę z powodu literówki w podprogramie korekcji trajektorii - zamiast przecinka wstawiono średnik.
Ocena i doskonalenie jakości odbywa się poprzez zastosowanie metryk - ilościowych cech określonych wskaźników procesu.

Aby przeprowadzić kontrolę, wymagane są następujące kroki:

1. Proces kontroli rozpoczyna się od planowania. Trwają prace nad klasyfikacją wad według opisu, nasilenia i rodzaju. Wybór mierników, według których będzie przeprowadzona kontrola, dobór narzędzi do gromadzenia i analizowania uzyskanych danych, a także podział ról pomiędzy inspektorami dokonywany jest:
   • Za prawidłowe przeprowadzenie kontroli odpowiada lider.
   • Korektor odpowiada za działania zespołu i kieruje go we właściwym kierunku. Korektor bierze udział w kontroli.
   • Za zapisanie opisu i klasyfikacji usterek, zgodnie ze zwyczajem w zespole, odpowiedzialny jest rejestrator. W kontroli uczestniczy również rejestrator.
   • Inspektor wyspecjalizowany to specjalista w pewnej wąskiej dziedzinie, do której należy kontrolowany fragment.
2. W razie potrzeby można zorganizować warsztaty przeglądowe, aby lepiej zrozumieć przedmiot kontroli.
3. Przeprowadzenie inspekcji. Inspektorzy sprawdzają całość prac na swoich stanowiskach pracy (np. sprawdzając, czy sprawdzany kod programu odpowiada projektowi wykonawczemu). Inspektorzy zazwyczaj rejestrują wszystkie defekty w bazie danych (np. dostępnej za pośrednictwem sieci) wraz z opisami i klasyfikacjami. Sprawdzane części systemu muszą być logicznie kompletne.
4. Odbywa się spotkanie kontrolne, podczas którego uczestnicy przedstawiają swoje wyniki.
5. Autor poprawia wady (faza rewizji).
6. Na ostatnim spotkaniu po zakończeniu pracy korektor i autor sprawdzają, czy wszystkie braki zostały usunięte. Nie oznacza to jednak szczegółowej weryfikacji całego dzieła przez korektora. Za wszelkie poprawki odpowiada autor, który jest odpowiedzialny za swoje dzieło.
7. Podobnie jak w przypadku innych procesów, grupa spotyka się, aby omówić sam proces inspekcji i zdecydować, w jaki sposób można go ulepszyć.

Firma prowadzi rejestr czasu spędzonego na inspekcjach i ilości pracy poddanej inspekcji w celu dalszego wykorzystania przy ocenie przyszłych inspekcji. W warunkach ścisłych ograniczeń czasowych, tzw system „opiekuńczy”, w którym każdym członkiem zespołu opiekuje się jego kolega.
Aby wziąć pod uwagę wszystkie czynniki kontroli jakości, wygodnie jest skorzystać z list kontrolnych. Takie listy zawierają pozycje, które należy sprawdzać sekwencyjnie.
Przykładowo Plan Zapewnienia Jakości Oprogramowania (SQAP) zgodny z normą IEEE 739-1989 określa:

• kto będzie odpowiedzialny za jakość – osoba, menedżer, grupa, organizacja itp.;
• jaka dokumentacja jest wymagana;
• jakie metody będą stosowane w celu zapewnienia jakości - kontrola, testowanie itp.;
• jakie działania należy realizować podczas zarządzania procesowego – spotkania, audyty, przeglądy itp.

Niezawodność i bezpieczeństwo

Jedną z najważniejszych cech objętych pojęciem jakości jest właściwość niezawodności.
Zgodnie z definicją zawartą w GOST 13377-75 „Niezawodność w technologii. Terminy i definicje”, niezawodność to właściwość obiektu do wykonywania określonych funkcji, utrzymująca w czasie wartości ustalonych wskaźników eksploatacyjnych w określonych granicach, odpowiadających określonym sposobom i warunkom użytkowania, konserwacji, naprawy, przechowywania i transportu. Zatem niezawodność jest wewnętrzną właściwością systemu, nieodłączną podczas jego tworzenia i objawiającą się w czasie podczas eksploatacji i eksploatacji.
Niezawodność działania podstacji najpowszechniej charakteryzuje stabilność, czyli zdolność do bezawaryjnej pracy oraz możliwość przywrócenia stanu operacyjnego po wystąpieniu awarii lub awarii.
Monitorowanie niezawodności i bezpieczeństwa tworzonych i modyfikowanych programów powinno towarzyszyć całemu cyklowi życia oprogramowania poprzez specjalnie zorganizowany, skuteczny system technologiczny zapewniający ich jakość. Weryfikacja i potwierdzenie jakości złożonego i krytycznego oprogramowania musi być zapewniona poprzez certyfikację przez certyfikowane, certyfikowane laboratoria zorientowane na problem.

Standardy bezpieczeństwa informacji dzielą się na dwie grupy:

• standardy oceny przeznaczone do oceny i klasyfikacji sprzętu IP i bezpieczeństwa zgodnie z wymogami bezpieczeństwa - norma Departamentu Obrony USA „Kryteria oceny zaufanych systemów komputerowych”, „Zharmonizowane kryteria krajów europejskich”, międzynarodowa norma „Kryteria oceny bezpieczeństwa technologii informacyjnych”, Dokumenty przewodnie Państwowej Komisji Technicznej Rosji;
• specyfikacje regulujące różne aspekty wdrażania i stosowania narzędzi i technik bezpieczeństwa, opublikowane przez Internet Engineering Task Force (IETF) i jej pododdziały, Grupę Roboczą ds. Bezpieczeństwa.

Do najważniejszych standardów ewaluacji należą:

• Państwowa Komisja Techniczna Rosji. Dokument przewodni. Wyposażenie komputerowe. Zapory ogniowe. Ochrona przed nieuprawnionym dostępem do informacji. Wskaźniki bezpieczeństwa przed nieuprawnionym dostępem do informacji. – Moskwa, 1997 – klasyfikuje zapory ogniowe według poziomu filtrowania przepływu danych siedmiopoziomowego modelu referencyjnego.
• ISO/IEC 15408:1999 Kryteria oceny bezpieczeństwa technologii informatycznych.

Do drugiej grupy zaliczają się następujące dokumenty:

• X.800 „Architektura bezpieczeństwa dla wzajemnych połączeń systemów otwartych.” Wyróżniono główne usługi bezpieczeństwa sieci: uwierzytelnianie, kontrola dostępu, zapewnienie poufności i/lub integralności danych. W celu realizacji usług zapewniane są następujące mechanizmy bezpieczeństwa sieci i ich kombinacje: szyfrowanie, elektroniczny podpis cyfrowy, kontrola dostępu, kontrola integralności danych, uwierzytelnianie, dodawanie ruchu, kontrola routingu, notarialne.
• Specyfikacja społeczności internetowej RFC 1510, Kerberos Network Authentication Service (V5), rozwiązuje problem uwierzytelniania w heterogenicznym środowisku rozproszonym, obsługując koncepcję pojedynczego logowania do sieci;
• X.500 „Usługi katalogowe: przegląd koncepcji, modeli i usług”, X.509 „Usługi katalogowe: ramy certyfikatów klucza publicznego i atrybutów”.

Procesy weryfikacji, certyfikacji i audytu

Weryfikacja, kwalifikacja i audyt są integralną częścią planu kontroli jakości SQAP IEEE 739-1989.
Weryfikacja odpowiada na pytanie: „Czy na tym etapie robimy to, co zaplanowaliśmy?” Certyfikacja i audyt odpowiadają na pytanie: „Czy budowany obiekt spełnia potrzeby Klienta?”
Standard IEEE 1012-1986 Software Verification and Validation Plan (SVVP) łączy procesy certyfikacji i audytu zwane walidacją i określa sposób ich przeprowadzania.

Podczas procesu weryfikacji sprawdzane są następujące warunki:

• spójność wymagań wobec systemu i stopień uwzględnienia potrzeb użytkowników;
• zdolność dostawcy do spełnienia określonych wymagań;
• zgodność wybranych procesów cyklu życia PS z warunkami umowy;
• adekwatność standardów, procedur i środowiska programistycznego do procesów cyklu życia PS;
• zgodność specyfikacji projektu stacji elektroenergetycznej z określonymi wymaganiami;
• poprawność opisu w specyfikacjach projektowych danych wejściowych i wyjściowych, sekwencji zdarzeń, interfejsów, logiki itp.;
• zgodność kodu ze specyfikacjami i wymaganiami projektowymi;
• testowalność i poprawność kodu, jego zgodność z przyjętymi standardami kodowania;
• poprawna integracja komponentów oprogramowania z systemem;
• adekwatność, kompletność i spójność dokumentacji.

Proces wspólnego przeglądu

Proces wspólnego przeglądu ma na celu ocenę stanu prac nad projektem i koncentruje się głównie na monitorowaniu planowania i zarządzania zasobami, personelem, sprzętem i narzędziami projektu.
Ocena stosowana jest zarówno podczas zarządzania projektem, jak i podczas technicznej realizacji projektu i przeprowadzana jest przez cały czas trwania umowy. Proces ten może być realizowany przez dowolne dwie strony umowy, przy czym jedna strona weryfikuje drugą.

Proces rozwiązywania problemów

Proces rozwiązywania problemów obejmuje analizę i rozwiązywanie problemów (w tym wykrytych niespójności) niezależnie od ich pochodzenia lub źródła, które zostały wykryte podczas rozwoju, eksploatacji, konserwacji lub innych procesów. Proces rozwiązywania problemów jest ściśle powiązany z zarządzaniem ryzykiem. Czynniki prowadzące do niepowodzenia projektu objawiają się w postaci ryzyka. Zarządzanie ryzykiem obejmuje identyfikację, planowanie eliminacji, ustalanie priorytetów, eliminację (lub łagodzenie).

Przyczyny pojawienia się zagrożeń mogą być następujące:

1. Niejasne i/lub niekompletne sformułowanie wymagań;
2. Niewystarczające zaangażowanie interesariuszy w projekt;
3. Złe planowanie – brak kompetentnego zarządzania projektem;
4. Częste zmiany wymagań spowodowane zmianami zakresu, celów projektu i innymi przyczynami;
5. Niedoskonałość zastosowanej technologii projektowania;
6. Brak wiedzy lub umiejętności wśród wykonawców.

Istnieją dwa sposoby zapobiegania zagrożeniom:

1. dokonanie zmian w wymaganiach projektu, które eliminują przyczynę ryzyka;
2. rozwój technologii rozwiązujących problem związany z pojawieniem się ryzyka.

W procesie zarządzania projektem menedżer musi od czasu do czasu inicjować proces identyfikacji ryzyk w różnych częściach projektu, aby sporządzić listę ryzyk oczekujących na leczenie. Dla każdego ryzyka wyznaczane są trzy wartości: prawdopodobieństwo wystąpienia ryzyka; szkody wyrządzone projektowi przez to ryzyko, jeżeli wystąpią; oszacowanie kosztu wyeliminowania ryzyka. Wszystkie wartości używają tej samej skali, na przykład 1 – 10.

Proces zarządzania dokumentacją i konfiguracją

„Zarządzanie dokumentacją projektu oprogramowania wymaga znacznych wysiłków organizacyjnych, ponieważ... dokumentacja to złożony system, podlegający ciągłym zmianom, które może wprowadzać jednocześnie wiele osób” (E. Braude)

Proces dokumentowania zapewnia sformalizowany opis informacji powstałych w trakcie cyklu życia PS. Proces ten składa się z zestawu działań, które planują, projektują, rozwijają, produkują, edytują, dystrybuują i utrzymują dokumenty potrzebne wszystkim interesariuszom (menedżerom, specjalistom technicznym i użytkownikom systemu).

GOST R ISO/IEC 9294-93. "Technologia informacyjna. Przewodnik po zarządzaniu dokumentacją oprogramowania” zawiera zalecenia dotyczące skutecznego zarządzania dokumentacją oprogramowania. Celem standardu jest pomoc w zdefiniowaniu strategii dokumentowania oprogramowania; wybór standardów dokumentacji; wybór procedur dokumentacyjnych; określenie wymaganych zasobów; sporządzanie planów dokumentacji.

Zarządzanie dokumentami oznacza utrzymanie kompletności i spójności (niektórzy autorzy uwzględniają tutaj zarządzanie konfiguracją).

Kompletność dokumentacji charakteryzuje się liczbą standardów i dokumentów regulacyjnych, które stanowią podstawę zbioru dokumentacji towarzyszącej danemu procesowi w cyklu życia oprogramowania.
Spójność dokumentacji oznacza, że ​​zbiór dokumentów nie zawiera sprzeczności wewnętrznych. Osiąga się to poprzez umieszczenie każdej specyfikacji tylko w jednym miejscu – nazywa się to dokumentacją holistyczną. Integralność dokumentacji jest zapewniona poprzez zastosowanie hiperłączy.

Każde wymaganie musi być identyfikowalne Aby to osiągnąć, każdemu wymaganiu przypisany jest unikalny numer, do którego następnie odwołuje się podczas opracowywania koncepcji, projektowania i aż do wykazu metod.

• // wymaganie 4.3
• // autor
• // wersja
• // argumenty
• ...lista metod...

Części projektu obejmują nie tylko kod źródłowy programów, ale także całą dokumentację, w tym plan projektu. Projekty w trakcie swojego życia ulegają zmianom w dwóch kierunkach:

• Po pierwsze jest to zakup nowych części,
• Po drugie, uzyskanie nowych wersji istniejących części. Aby prawidłowo śledzić te zmiany, stosuje się specjalnie zorganizowany zestaw procedur administracyjnych i technicznych, które dotyczą procesu zarządzania konfiguracją.

Aby śledzić części projektu, należy zdefiniować ich granice i zidentyfikować elementy konfiguracji (elementy konfiguracji - CI). Elementami konfiguracji mogą być klasy, rzadziej funkcje, istotne zbiory danych – tabele globalne, dokumentacja. Rozliczanie stanu konfiguracji odbywa się poprzez rejestrację stanu komponentów oprogramowania, sporządzanie raportów o wszystkich wdrożonych i odrzuconych modyfikacjach wersji komponentów oprogramowania. Zestaw raportów zapewnia jednoznaczne odzwierciedlenie aktualnego stanu systemu i jego komponentów, a także zachowanie historii modyfikacji.
Istnieją specjalne narzędzia programowe do zarządzania konfiguracją (na przykład Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion itp.).

Zazwyczaj systemy zarządzania konfiguracją spełniają następujące minimalne wymagania:

• możliwość definiowania elementów konfiguracyjnych;
• przechowywanie w bazie danych zarządzania konfiguracją pełnych chronologii wersji każdego obiektu powstałych lub zmienionych w procesie rozwoju systemu (obejmuje to kod programu źródłowego, biblioteki, programy wykonywalne, modele, dokumentację, testy, strony internetowe i katalogi);
• wsparcie dla oddalonych geograficznie zespołów programistycznych;
• odmowa praw do modyfikacji, aby uniemożliwić więcej niż jednej osobie pracę nad elementem konfiguracji w tym samym czasie;
• kontrola zmian dokonanych we wszystkich obiektach systemu;
• składanie wersji oprogramowania z komponentów projektu.

IEEE opracowało standard IEEE 828-1990„Plan zarządzania konfiguracją oprogramowania (SCMP)”. Tytuł normy i przykład Planu Zarządzania Konfiguracją podano w książce Erica Braude’a.

Rysunek - Dokumenty regulacyjne dotyczące pomocniczych procesów cyklu życia

Procesy cyklu życia organizacji

Do procesów organizacyjnych cyklu życia zalicza się: proces tworzenia infrastruktury, proces doskonalenia, proces szkolenia, proces zarządzania.

Rysunek - Struktura procesów cyklu życia organizacji

Proces tworzenia infrastruktury

to proces tworzenia i zapewniania (utrzymywania) infrastruktury, która może obejmować sprzęt i oprogramowanie, narzędzia, metodologie, standardy i warunki rozwoju, eksploatacji lub konserwacji. Na I etapie tworzenia infrastruktury następuje wybór systemu wspomagającego projektowanie CASE, wybór języka programowania oraz DBMS; organizacja służb wsparcia – administratorzy systemów, administratorzy sieci, administratorzy baz danych, sekretarki itp.
Rozwiązując problem selekcji z wykorzystaniem źródeł literackich, należy przeanalizować możliwości najpowszechniejszych systemów instrumentalnych w celu zbudowania klasyfikacji, a następnie w ramach określonej grupy klasyfikacyjnej określić parametry, według których dokonana zostanie selekcja.
Sama procedura selekcji obejmuje następujące etapy:

1. Zidentyfikowano podstawowe wskaźniki wybranego systemu, które są istotne przy projektowaniu danego SPS, biorąc pod uwagę jego cechy, ograniczenia, zasoby itp.
2. Wszystkie wskaźniki podsumowano w tabeli (patrz tabela 5), ​​w której na podstawie ocen ekspertów każdemu wskaźnikowi przypisano współczynnik wagi Vi (na przykład od 1 do 10), który charakteryzuje znaczenie tego wskaźnika w porównaniu z innymi. Suma wartości wszystkich współczynników ważących musi być równa górnej granicy współczynnika ważącego (na przykład 10).
3. Wykorzystując dane zaczerpnięte ze źródeł literackich i/lub od ekspertów, dla każdego i-tego wskaźnika dla każdego j-tego systemu wyznaczany jest stopień użyteczności Ui,j (od 1 – minimum do 10 – maksimum). Na przykład stosunkowo drogi system zarządzania konfiguracją może mieć ocenę użyteczności wynoszącą 1, podczas gdy ogólnodostępny system miałby ocenę użyteczności wynoszącą 10.
4. Dla każdego j-tego porównywanego układu wartość funkcji oceny oblicza się ze wzoru: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Na podstawie wartości funkcji oceny wyciąga się wniosek o celowości zastosowania konkretnego systemu w danym projekcie, biorąc pod uwagę wybrane kryteria i określone ograniczenia. Spośród porównywanych alternatyw najlepszy pod względem wyboru jest układ, dla którego wartość funkcji oceny jest większa.

Proces uczenia

to proces zapewniania wstępnego i ustawicznego szkolenia personelu. Zamawianie, dostawa, rozwój, obsługa i konserwacja oprogramowania w dużej mierze zależą od kwalifikacji personelu. Dlatego szkolenie personelu należy zaplanować i przeprowadzić z wyprzedzeniem, aby przygotować go do pracy przy zamawianiu, dostawie, opracowywaniu, obsłudze lub utrzymaniu projektu oprogramowania.

Proces doskonalenia

to proces ustanawiania, oceny, pomiaru, kontrolowania i ulepszania dowolnego procesu cyklu życia oprogramowania. W praktyce inżynierskiej przy opracowywaniu SI stosuje się metryki - charakterystykę ilościową niektórych wskaźników.

Najczęściej stosowane metryki to:

• ilość wykonanej pracy, mierzona w jednostkach fizycznych (na przykład liczba linii kodu);
• czas spędzony w pracy;
• wskaźnik defektów (na przykład liczba defektów na 1000 linii kodu, liczba defektów na stronę dokumentacji itp.).

Wstępne lub pożądane wartości metryki są przewidywane z wyprzedzeniem, a następnie porównywane z uzyskanymi wynikami.
Ponieważ metryki związane z wadliwością odgrywają szczególną rolę, podajemy niektóre z nich:

1. Liczba defektów na tysiąc linii kodu oprogramowania zidentyfikowanych w ciągu 12 tygodni od dostarczenia projektu.
2. Odchylenia w harmonogramie na każdym etapie: (Czas rzeczywisty - Czas planowany) / Czas trwania planowany.
3. Odchylenia w kosztach: (Koszt rzeczywisty – Koszt planowany) / Koszt planowany.
4. Całkowity czas projektowania / Całkowity czas programowania (według niektórych szacunków powinien wynosić co najmniej 50%).
5. Stopień, w jakim defekty pojawiają się i są wykrywane na pewnym etapie, jest jednym z najprostszych wskaźników.

Porównując wyniki wykrywania defektów ze standardami organizacji, oceniany jest cały proces tworzenia systemu jako całość, a nie tylko konkretny projekt. Zgromadzone dane dotyczące usterek na każdym etapie są zestawiane w sposób pokazany na przykład w tabeli.

Analiza etapu „Formowania wymagań”. pokazuje, że stopień wykrycia defektów jest niższy od normalnego na wszystkich etapach projektu. Więcej wad konstrukcyjnych wykryto bezpośrednio na etapie ich produkcji, a mniej w późniejszych fazach. Zwykle osiąga się to poprzez kontrolę.

Sekwencja działań, które należy podjąć w całym cyklu życia projektu, aby go ulepszyć, może wyglądać na przykład następująco:

1. Zidentyfikuj i zdefiniuj wskaźniki, które będą wykorzystywane przez zespół na każdym etapie, w tym:
   • czas poświęcony na badania, wdrażanie i analizę wyników;
   • rozmiar (na przykład liczba linii kodu);
   • liczbę defektów wykrytych w module (np. ilość linii kodu) i źródło wykrycia defektu;
   • ocena jakości w skali od 1 do 10.
2. Dokumentuj informacje otrzymane w SQAP.
3. Zbieraj statystyki na każdym etapie.
4. Przydziel programistów odpowiedzialnych za gromadzenie danych na każdym etapie, np. „oficera ds. jakości”.
5. Zaplanuj przeglądy danych metrycznych, które będą przydatne w przyszłości. Konieczne jest wcześniejsze podjęcie decyzji, jakie mogą być wartości wskaźników i jakie powinny być. Uzyskane dane staną się podstawą do stworzenia bazy danych projektów firmy.

Model dojrzałości zdolności organizacyjnych

Proces doskonalenia technologii tworzenia oprogramowania znajduje odzwierciedlenie w planach strategicznych organizacji, jej strukturze, stosowanych technologiach, ogólnej kulturze społecznej i systemie zarządzania.
Na początku lat 90-tych Amerykański Instytut Inżynierii Oprogramowania (SEI of Carnegie Mellon University (Pittsburgh, Pensylwania, USA)) stworzył model dojrzałości technologicznej organizacji CMM (Capability Maturity Model). Obecnie na Zachodzie firma deweloperska ma duże trudności z uzyskaniem zamówienia, jeśli nie posiada certyfikatu CMM.
CMM jest materiałem metodologicznym, który określa zasady kształtowania systemu zarządzania tworzeniem i utrzymaniem oprogramowania oraz metody stopniowego i ciągłego doskonalenia kultury produkcyjnej. Celem CMM jest dostarczenie organizacjom rozwojowym niezbędnych wskazówek dotyczących wyboru strategii poprawy jakości procesów poprzez analizę stopnia ich dojrzałości technologicznej oraz czynników, które w największym stopniu wpływają na jakość produktów. Na każdym poziomie SMM ustalane są wymagania, których spełnienie zapewnia stabilizację najważniejszych wskaźników procesu.

Proces zarządzania

Zarządzanie projektami polega na osiągnięciu równowagi pomiędzy kosztami, możliwościami, jakością i harmonogramem. Z procesem zarządzania projektami wiąże się kilka aspektów: zarządzanie personelem, harmonogramowanie, szacowanie kosztów projektu.

Zarządzanie personelem

Wiadomo, że dane empiryczne pozwalają określić optymalną liczbę członków zespołu.

Rysunek - Zależność efektywności zespołu deweloperskiego od jego składu

Zależność ta prowadzi do konieczności stosowania hierarchicznych struktur zarządzania

Rysunek – Hierarchiczna struktura zarządzania

Pomimo tego, że liczba połączeń każdego pracownika jest zadowalająca, nie biorą oni udziału w formułowaniu problemu, co narusza jeden z głównych wymogów analizy systemowej – w dyskusji nad problemem powinna uczestniczyć maksymalna możliwa liczba interesariuszy .
Alternatywny schemat organizacji zespołu pracowników nazywany jest „zespołem równych”. W tym przypadku wszyscy członkowie zespołu znajdują się na tym samym poziomie hierarchii, a role są między nimi rozdzielone. Co więcej, po pewnym czasie podział ról może się zmienić. Problem zwiększenia liczby komunikacji w dużym projekcie w tym przypadku rozwiązuje się poprzez podkreślenie roli osoby odpowiedzialnej za komunikację zewnętrzną.

W koncepcji programowania ekstremalnego zaproponowanej przez Kenta Becka. nacisk położony jest na ciągłą relację pomiędzy programistami a klientem (a klient staje się jednym z uczestników rozwoju), chęć radykalnego uproszczenia procesu rozwoju systemu oraz programowania w parach. Co więcej, w przypadku programowania w parach programiści pracują tylko razem na jednym komputerze, na zmianę. Wdraża to formę ciągłej kontroli.

Przygotowanie harmonogramu

Istnieje wiele standardów opisujących tworzenie i utrzymywanie planów zarządzania projektami oprogramowania. Zaleca się stosowanie planu zarządzania projektami oprogramowania IEEE 1058.1-1987 (SPMP). SPMP zapewnia harmonogram określający, w jaki sposób i kiedy należy zakończyć poszczególne etapy projektu. Po zakończeniu każdego kolejnego etapu projektowania harmonogram wymaga uzupełnienia i dostosowania. Najpopularniejszą formą prezentacji harmonogramu projektu jest wykres Gantta.

Rysunek — Przybliżony widok wykresu Gantta

Zaleca się, aby plan uwzględniał okresy buforowe, w których nie zaplanowano uruchomienia żadnych procesów. Harmonogram w formie wykresu Gantta budowany jest najczęściej w programie Microsoft Office Project.
Proces planowania prac mających na celu realizację projektu w szczególności i zarządzanie projektem w ogóle wiąże się z szacowaniem kosztów i czasu trwania projektu. Informacje te znajdują się w punkcie 5.4. „Przydział budżetu i zasobów” SPMP, a dodatkowo wstępna ocena kosztów projektu może mieć wpływ na ostateczną wersję umowy pomiędzy klientem a wykonawcą, dlatego musi zostać przeprowadzona przed podpisaniem SIWZ.

Oszacowanie kosztów stworzenia PS

Proces szacowania pracochłonności z reguły rozpoczyna się jednocześnie z rozpoczęciem projektu i trwa nawet na etapie pisania kodu programu.

Do najpopularniejszych metod oceny pracochłonności zalicza się:

• Modelowanie algorytmiczne. Metoda opiera się na analizie danych statystycznych dotyczących wcześniej ukończonych projektów i określa zależność pracochłonności projektu od jakiegoś ilościowego wskaźnika produktu programowego (zwykle wielkości kodu programu). Wskaźnik ten ocenia się dla danego projektu, po czym za pomocą modelu prognozuje się przyszłe koszty.
• Oceny ekspertów. Przeprowadza się ankietę wśród kilku ekspertów w dziedzinie technologii wytwarzania oprogramowania, którzy znają zakres zastosowań tworzonego produktu programistycznego. Każdy z nich samodzielnie ocenia pracochłonność projektu. Następnie wszystkie szacunki są porównywane i omawiane.
• Ocena przez analogię. Metodę tę stosuje się, jeżeli w danym obszarze zastosowań tworzonego oprogramowania podobne projekty były już realizowane. Metoda polega na porównaniu planowanego projektu z wcześniejszymi projektami, które mają podobną charakterystykę. Wykorzystuje dane eksperckie lub przechowywane dane projektowe. Eksperci obliczają szacunkowy najwyższy, najniższy i najbardziej prawdopodobny nakład pracy na podstawie różnic między nowym projektem a poprzednimi projektami.

Każda metoda oceny ma swoje mocne i słabe strony, dlatego obecnie stosuje się podejścia łączące różne metody.

Procedura oceny pracochłonności tworzenia oprogramowania składa się z następujących kroków:

1. szacowanie wielkości opracowywanego produktu;
2. ocena pracochłonności w osobo-miesiącach lub osobogodzinach;
3. oszacowanie czasu trwania projektu w miesiącach kalendarzowych;
4. kosztorys projektu.

Główne jednostki miary rozmiaru oprogramowania to:

• liczba linii kodu (LOC – Lines of Code);
• punkty funkcyjne (FP – Punkty Funkcyjne).

Metodologia oceny wielkości funkcjonalnej

Metodologia oceny wielkości funkcjonalnej (FP – Punkty Funkcjonalne) polega na jednolitym mierzeniu wszystkich możliwości aplikacji i wyrażeniu rozmiaru aplikacji w postaci pojedynczej liczby. Liczbę tę można następnie wykorzystać do oszacowania liczby linii kodu, kosztu i harmonogramu projektu.
Aby obliczyć rozmiar funkcjonalny, dla każdej cechy informacyjnej systemu określa się rangę i złożoność. Międzynarodowa Grupa Użytkowników Punktów Funkcyjnych (IFPUG, www.ifpug.org) opublikowała kryteria identyfikacji cech informacji, które podzielono na pięć grup:

• – rozpoznawana przez użytkownika grupa logicznie powiązanych danych, która znajduje się w aplikacji i jest obsługiwana poprzez dane wejściowe zewnętrzne.

• – rozpoznawalna przez użytkownika grupa logicznie powiązanych danych, która znajduje się w innej aplikacji i jest przez nią obsługiwana. Zewnętrzny plik danej aplikacji jest wewnętrznym plikiem logicznym w innej aplikacji.

• – elementarny proces, który przenosi dane ze środowiska zewnętrznego do aplikacji. Dane mogą pochodzić kanałami komunikacji, od użytkownika na ekranie wejściowym lub z innej aplikacji. Dane mogą być wykorzystywane do aktualizacji wewnętrznych plików logicznych i mogą zawierać zarówno informacje zarządcze, jak i biznesowe. Dane sterujące nie mogą modyfikować wewnętrznego pliku logicznego (np. pola wprowadzania danych, komunikaty o błędach, wartości obliczone, przyciski).

• – elementarny proces, który przenosi dane obliczone w aplikacji do środowiska zewnętrznego. Ponadto w trakcie tego procesu mogą zostać zaktualizowane wewnętrzne pliki logiczne. Dane tworzą raporty lub pliki wyjściowe, które są wysyłane do innych aplikacji. Raporty i pliki tworzone są w oparciu o wewnętrzne pliki logiczne i pliki interfejsu zewnętrznego. Dodatkowo proces ten może wykorzystywać dane wejściowe zawierające kryteria wyszukiwania i parametry, które nie są obsługiwane przez wewnętrzne pliki logiczne. Dane wejściowe pochodzą z zewnątrz, ale mają charakter tymczasowy i nie są przechowywane w wewnętrznym pliku logicznym (np. pola danych w raportach, wartości obliczone, komunikaty o błędach).

• – elementarny proces, który działa zarówno z danymi wejściowymi, jak i wyjściowymi, składający się z kombinacji żądanie-odpowiedź, ale niezwiązany z obliczaniem danych pochodnych lub aktualizacją ILF. Jego wynikiem są dane zwrócone z wewnętrznych plików logicznych i plików interfejsu zewnętrznego. Część wejściowa procesu nie modyfikuje wewnętrznych plików logicznych, a część wyjściowa nie przenosi danych obliczonych przez aplikację (taka jest różnica między żądaniem a wyjściem). Przykładowo: elementy wejściowe - pole wykorzystywane do wyszukiwania, kliknięcie myszką; wyświetlane elementy – pola wyświetlane na ekranie.

GOST R 56376-2015/IEEE C37.92(2005)

NORMA KRAJOWA FEDERACJI ROSYJSKIEJ

Elektryczne przetworniki pomiarowe

WEJŚCIA ANALOGOWE PRZEKAŹNIKÓW OCHRONNYCH ELEKTRONICZNYCH PRZETWORNIKÓW NAPIĘCIA I PRĄDU

Przetworniki elektryczne. Wejścia analogowe do przekaźników ochronnych z elektronicznych przetworników napięcia i prądu

OKS 17.020

Data wprowadzenia 2016-01-01

Przedmowa

Przedmowa

1 PRZYGOTOWANE przez Federalne Państwowe Przedsiębiorstwo Unitarne „Ogólnorosyjski Instytut Badawczy Służby Metrologicznej” (FSUE „VNIIMS”) na podstawie własnego tłumaczenia na język rosyjski angielskiej wersji normy określonej w ust. 4

2 WPROWADZONE przez Techniczny Komitet Normalizacyjny TC 445 „Metrologia gospodarki efektywnej energetycznie”

3 ZATWIERDZONE I WEJŚCIE W ŻYCIE zarządzeniem Federalnej Agencji ds. Regulacji Technicznych i Metrologii z dnia 27 marca 2015 r. N 192-st

4 Norma ta jest identyczna z normą międzynarodową IEEE Standard C37.92(2005)* „Standard IEEE dotyczący wejść analogowych do przekaźników ochronnych” z elektronicznych przetworników napięcia i prądu, IDT).
________________
* Dostęp do dokumentów międzynarodowych i zagranicznych wymienionych w tekście można uzyskać kontaktując się z Obsługą Klienta. - Uwaga producenta bazy danych.


Nazwa tej normy została zmieniona w stosunku do nazwy określonej normy międzynarodowej w celu dostosowania jej do GOST R 1.5-2012 (punkt 3.5).

Przy stosowaniu tej normy zaleca się stosowanie zamiast odniesienia do norm międzynarodowych odpowiednich norm krajowych, o których informacja znajduje się w dodatkowym załączniku TAK

5 WPROWADZONE PO RAZ PIERWSZY

6 REPUBLIKACJA. kwiecień 2019

Zasady stosowania tego standardu zostały określone w Artykuł 26 ustawy federalnej z dnia 29 czerwca 2015 r. N 162-FZ „O normalizacji w Federacji Rosyjskiej” . Informacje o zmianach w tym standardzie publikowane są w corocznym (stan na dzień 1 stycznia bieżącego roku) indeksie informacyjnym „Normy Krajowe”, natomiast oficjalny tekst zmian i poprawek publikowany jest w miesięcznym indeksie informacyjnym „Standardy Krajowe”. W przypadku rewizji (wymiany) lub unieważnienia niniejszej normy odpowiednia informacja zostanie opublikowana w następnym numerze miesięcznego indeksu informacyjnego „Normy Krajowe”. Odpowiednie informacje, powiadomienia i teksty są również publikowane w publicznym systemie informacji - na oficjalnej stronie internetowej Federalnej Agencji Regulacji Technicznych i Metrologii w Internecie (www.gost.ru)

1 obszar zastosowania

1.1 Postanowienia ogólne

Niniejsza norma określa charakterystykę interfejsu pomiędzy systemami pomiaru napięcia lub prądu, czujnikami optycznymi z wyjściami analogowymi i specjalnie zaprojektowanymi przekaźnikami zabezpieczeniowymi lub innym sprzętem pomiarowym podstacji. Te systemy pomiarowe wytwarzają przebiegi proporcjonalne do prądów i napięć w sieci elektrycznej.

W niniejszej normie określono również wymagania dotyczące dodatkowych sumatorów pośrednich lub wzmacniaczy skalujących niezbędnych do dodawania lub odejmowania sygnałów z wyjść więcej niż jednego optycznego czujnika pomiarowego podczas pomiaru za pomocą pojedynczego przekaźnika lub urządzenia pomiarowego.

1.2 Cele

Znormalizowany sygnał pomiarowy pomiędzy systemem pomiarowym a przekaźnikowymi układami zabezpieczającymi jest analogowym sygnałem elektrycznym o maksymalnej amplitudzie ±11,3 V i maksymalnej mocy 3,2 mW.

Przykładem układu pomiarowego z analogowym wyjściem elektronicznym jest optyczny układ przekładników napięciowych lub prądowych z interfejsem optyczno-elektronicznym. Na rysunku 1 przedstawiono typową konfigurację elementów układu optycznego pomiaru prądu w stacji wysokiego napięcia. W tej konfiguracji czujniki optyczne przekładników prądowych są umieszczone na szynie wysokiego potencjału. W innych przypadkach czujniki można zamontować wewnątrz transformatora zasilającego lub izolatora. Sygnały optyczne przesyłane są kablami światłowodowymi do potencjału uziemienia, gdzie są przekształcane na skalowane i znormalizowane sygnały elektryczne wykorzystywane przez przekaźniki zabezpieczające i inne inteligentne urządzenia elektroniczne (IED).

Moduł konwersji optyczno-elektronicznej zwykle znajduje się w sterowni ogólnej podstacji, ale może być również umieszczony w rozdzielnicy w pobliżu urządzenia IED. Niniejsza norma określa charakterystykę sygnałów elektrycznych pomiędzy optyczno-elektronicznym modułem konwersji a przekaźnikiem zabezpieczeniowym lub innym urządzeniem IED wykorzystującym te sygnały. Interfejs pomiędzy czujnikami optycznymi a modułem konwertującym jest autorskim rozwiązaniem technicznym umożliwiającym zbudowanie układu pomiarowego konkretnego producenta, niepodlegającego standaryzacji. Do prawidłowej interakcji z urządzeniami zewnętrznymi konieczna jest normalizacja charakterystyki wyjścia modułu konwersji, wejścia zacisków ochronnych przekaźnika i szeregu innych funkcji pomiarowych.

Obszar zaznaczony na rysunku 1 pokazuje lokalizację interfejsów zdefiniowanych przez ten standard.

Rysunek 1 - Optyczny system pomiaru prądu ze znormalizowanym interfejsem analogowym

2 Odniesienia normatywne

W niniejszej normie zastosowano odniesienia normatywne do następujących norm. W przypadku odniesień datowanych obowiązuje wyłącznie cytowane wydanie. W przypadku niedatowanych – wydanie najnowsze (ze wszystkimi poprawkami i zmianami).

IEEE Std 525™, Przewodnik IEEE dotyczący projektowania i instalacji systemów kablowych w podstacjach
_______________
Publikacje IEEE można kupić w Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/).


IEEE Std 1050™, Przewodnik IEEE dotyczący uziemienia oprzyrządowania i sprzętu sterującego w stacjach prądotwórczych

IEEE Std C37.90™, norma IEEE dotycząca przekaźników i systemów przekaźnikowych powiązanych z urządzeniami zasilania elektrycznego (przekaźniki i systemy przekaźników stosowane do ochrony i sterowania urządzeniami zasilającymi)

IEEE Std C37.90.1™, standardowe testy odporności na przepięcia IEEE (SWC) dla przekaźników i systemów przekaźnikowych powiązanych z urządzeniami elektroenergetycznymi (testy odporności na przepięcia przekaźników i systemów przekaźnikowych stosowanych do ochrony i sterowania urządzeniami zasilającymi)

IEEE Std C37.90.2™, norma IEEE dotycząca odporności systemów przekaźnikowych na emitowane zakłócenia elektromagnetyczne z urządzeń nadawczo-odbiorczych

IEEE Std C57.13™, wymagania normy IEEE dla przekładników przyrządowych. Publikacje IEEE można uzyskać w Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/) (Wymagania dotyczące transformatora przyrządowego)

3 Terminy i definicje

W niniejszym standardzie przyjęto następujące terminy i definicje. Terminy nieujęte w tym standardzie można znaleźć w The Authoritative Dictionary of IEEE Standards, wydanie siódme.

3.1 jedna jednostka względna jedna na jednostkę (w skrócie: 1 p.u.): Zmierzona wartość wyjściowa lub moc wyjściowa układu pomiarowego, która odpowiada nominalnej pierwotnej wartości skutecznej zmierzonej napięcia lub prądu w obwodzie pomiarowym.

3.2 wejście przekaźnikowe(wejście przekaźnikowe): Analogowe wejście elektroniczne dowolnego terminala przekaźnikowego, miernika, urządzenia pomiarowego lub sterującego lub inteligentnego urządzenia elektronicznego zgodnego z niniejszą normą.

3.3 System pomiarowy(system czujnikowy): Czujnik elektroniczny, urządzenie, interfejs optyczno-elektroniczny lub źródło sygnału analogowego, które generuje zmierzone wartości napięcia lub prądu w sieci elektrycznej, którego moc wyjściowa jest zgodna z niniejszą normą.

4 Wymagania ogólne

4.1 Urządzenia przyłączeniowe

Wyjście układu pomiarowego i wejście przekaźnika należy wyposażyć w powszechnie dostępne złącza standardowe, odporne na przepięcia wysokonapięciowe zgodnie z wymaganiami p. 4.4. Złącza powinny być zaprojektowane tak, aby umożliwiały łatwe podłączenie i zakończenie kabla. Preferowanym rozwiązaniem są zaciski śrubowe. Każde wejście lub wyjście zawiera parę zacisków sygnałowych, oznaczonych zgodnie z 4.3. Dostawca sprzętu zapewni dodatkowe nieuziemione zaciski lub środki do podłączenia ekranów zgodnie z klauzulą ​​7.

4.2 Izolacja galwaniczna od ziemi

Obydwa zaciski wyjściowe systemu pomiarowego i każde wejście przekaźnika muszą być odizolowane od uziemienia ochronnego lub uziemienia ramy, gdy są wystawione na działanie sygnałów prądu stałego lub częstotliwości sieciowej. Dopuszczalna pojemność pomiędzy dowolnym zaciskiem a masą nie powinna przekraczać 0,01 µF.

4.3 Oznaczenia biegunowości i odporność na odwrotną polaryzację

Interfejsy muszą mieć oznaczenia biegunowości składające się z tradycyjnych „cts” i „vts”. Zobacz normę IEEE C57.13.
_______________
Informacje o linkach znajdują się w sekcji 2.


W przypadku wyjścia niezbalansowanego układu pomiarowego, zacisk wyjściowy sygnału musi być oznaczony odpowiednim oznaczeniem polaryzacji lub jako zacisk wtórny X1 tradycyjnego transformatora pomiarowego.

Kiedy prąd pierwotny sieci elektrycznej zostaje zamieniony na napięcie na wyjściu układu pomiarowego, wówczas dodatnia wartość napięcia na zacisku z odpowiednim znakiem polaryzacji musi odpowiadać kierunkowi prądu na zacisku pierwotnym z odpowiednią polaryzacją podpisać.

Każdy układ pomiarowy i każdy przekaźnik musi posiadać naklejkę producenta informującą, że występuje on wyłącznie w wersji z nieodwracalną polaryzacją lub że można go stosować w wersji z odwrotną polaryzacją.

Odwracalna polaryzacja oznacza w pełni izolowane lub zbalansowane wejście lub wyjście, które można podłączyć w dowolnej polaryzacji, zgodnie ze specyfikacją.

Nieodwracalna polaryzacja odnosi się do jednoprzewodowego lub niezbalansowanego wejścia lub wyjścia (gdzie jeden przewodnik służy do przenoszenia sygnału, a drugi służy jako przewód uziemiający, np. kabel koncentryczny), co polega na podłączeniu przewodu sygnałowego wyłącznie do zacisk sygnałowy i przewód wspólny tylko do zacisku wspólnego.

Zwykle pojedynczy sygnał na wyjściu układu pomiarowego jest rozgałęziany na kilka przekaźników lub urządzeń wykorzystujących ten sygnał. Podczas wykonywania tego połączenia należy wziąć pod uwagę następujące kwestie:

- jeżeli jedno lub więcej wejść kilku przekaźników ma nieodwracalną polaryzację, użytkownik nie zawsze będzie w stanie uzyskać wymaganą polaryzację podłączenia do wszystkich urządzeń, nawet jeśli źródło ma odwrotną polaryzację.

Uwaga – Ustawienia wewnętrzne lub programowe konkretnego przekaźnika zabezpieczeniowego mogą zmienić polaryzację wejścia;


- jeżeli dla każdego wejścia kilku przekaźników zostanie zastosowana odwracalna polaryzacja, wówczas każdy przekaźnik można podłączyć z wymaganą polaryzacją, nawet jeśli wyjście ze źródła nie jest nieodwracalne.

Zwiększa to elastyczność wykorzystania przekaźników i innych urządzeń z odwrotną polaryzacją wejść wykorzystujących wyjścia analogowe elektronicznego układu pomiarowego.

Symetryczne lub odwracalne zaciski wyjściowe muszą być symetryczne względem masy.

4.4 Dodatkowe wyjścia układów pomiarowych

4.4.1 Wyjście ostrzegawcze

Jest to dodatkowy sygnał przeznaczony do sygnalizowania wszelkich problemów w układzie pomiarowym, który powinien informować o każdej awarii, awarii lub pogorszeniu właściwości, tj. powiadomić o konieczności konserwacji lub naprawy. Na przykład wadliwe zasilanie układu pomiarowego może skutkować takim sygnałem.

Wyjście to musi być stykiem typu „C”, bezpotencjałowym i określonym przez producenta układu pomiarowego. W normalnych warunkach pracy uzwojenie przekaźnika (cewka) musi być zawsze pod napięciem, aby wygenerować alarm w przypadku utraty zasilania, a także w przypadku awarii układu pomiarowego.

4.4.2 Sygnał wyjściowy poprawności przesyłanych danych

Jest to sygnał obowiązkowy, który musi odzwierciedlać wyniki wszystkich kontroli wewnętrznych podczas autodiagnostyki elektroniki układu pomiarowego, którego obecność oznacza, że ​​występuje problem z analogowym sygnałem wyjściowym, co może prowadzić do nieprawidłowej pracy miernika. podłączone przekaźniki. Stosowany jest także do sygnalizacji podczas włączania i/lub wyłączania, podczas których sygnał wyjściowy układu pomiarowego obarczony jest dużymi błędami. Podłączone przekaźniki mogą błędnie wykorzystać ten sygnał do zablokowania wyłączenia.

Dane wyjściowe mogą mieć jedną lub obie z następujących form:

- styk typu „A”, bezpotencjałowy, określony przez producenta układu pomiarowego. W normalnych, prawidłowych warunkach pracy uzwojenie przekaźnika (cewka) musi być zawsze pod napięciem, aby zapewnić sygnał lub zapewnić blokadę zabezpieczającą w przypadku nieprawidłowego sygnału wyjściowego. Kontakt musi być wykonany zgodnie z normą IEEE Std C37.90. Opóźnienie blokowania wyjścia w przypadku wystąpienia efektu wyzwalania (odbicia styku) nie powinno przekraczać 12 ms;

- Poziom logiczny TTL (0 do 5 V) ma czas reakcji 1 ms lub szybszy (patrz 5.8). W tym przypadku poziom logiczny (5 V) oznacza poprawność przesyłanych danych.

4.5 Test kompatybilności elektromagnetycznej

Do weryfikacji wyjść układu pomiarowego, kompatybilnych analogowych wejść i wyjść przekaźników elektronicznych sygnalizujących awarię układu pomiarowego oraz poprawność przesyłanych danych, a także do weryfikacji wejść przekaźnikowych i urządzeń pośredniczących opisanych w pkt. pkt 6. Badanie to ma charakter dodatkowy w stosunku do innych badań zdolności przekaźników i elektroniki układu pomiarowego do wytrzymywania warunków otaczającego środowiska elektromagnetycznego, których wymagania podano w odpowiednich normach.

4.5.1 Badania dielektryczne

Testy te należy przeprowadzić zgodnie z metodami testów dielektrycznych opisanymi w normie IEEE Std C37.90. Napięcie testowe jest przykładane tylko w trybie wspólnym pomiędzy każdą parę zacisków wejściowych lub wyjściowych a uziemieniem ochronnym lub uziemieniem ramy. Obwody sygnałowe do 50 V są testowane przy niższym napięciu testowym dielektryka zgodnie ze standardem IEEE Std C37.90.

5.1.1 Opis sygnału dla aktualnego układu pomiarowego

Zakres dynamiki: 0,05 do 40 nominalnie;

Nominalny poziom wyjściowy (lub 1 p.u.): 200 mV (rms);

Maksymalna wartość chwilowa: 0,200x40x1,414 = 11,3 V (szczyt).

Błędy amplitudy i fazy to maksymalne odchylenie od rzeczywistej wartości skalowanego sygnału pierwotnego przy 50 lub 60 Hz.

Tabela 1 - Opis sygnału dla aktualnego układu pomiarowego

Całkowita wartość współczynnika zniekształceń nieliniowych musi być mniejsza lub równa błędowi amplitudy.

Stosunek sygnału do szumu musi być większy lub równy 54 dB przy sygnale większym niż 0,1 p.u. Pomiar należy przeprowadzić na sygnale o częstotliwości sieciowej, a szerokość pasma pomiaru szumu musi mieścić się w granicach 120 Hz.

Układ pomiaru prądu może być wyposażony w dodatkowe wyjście o wartości nominalnej 2 Vrms przy 1 p.u., z maksymalną wartością wyjściową 4 p.u. Wyjście to przeznaczone jest do zastosowań, w których wymagana dokładność pomiaru jest wyższa niż ogólnie przyjęta. W przypadku zastosowań związanych z transferem rozliczeniowym producent czujnika musi oddzielnie wykazać zgodność z odpowiednią normą dokładności, taką jak IEEE Std C57.13 lub jej części.

5.1.2 Opis sygnałów dla układów pomiaru napięcia

Zakres dynamiki od 0,05 do 2,0-krotności wartości nominalnej.

Nominalny poziom wyjściowy (lub 1 p.u.): 4 V (rms).

Maksymalna moc wyjściowa: 4,0 x 2,0 x 1,414 = 11,3 V (szczyt).

Błędy amplitudy i fazy to maksymalne odchylenie od wartości rzeczywistego skalowanego sygnału pierwotnego przy 50 lub 60 Hz.

Tabela 2 - Opis sygnału układu pomiaru napięcia

Całkowita wartość współczynnika zniekształcenia nieliniowego musi być mniejsza lub równa wartości błędu.

Stosunek sygnału do szumu musi być większy lub równy 70 dB przy sygnale większym niż 0,85 p.u. Pomiarów należy dokonywać przy użyciu sygnału o częstotliwości sieciowej i szerokości pasma pomiaru szumu wynoszącej co najmniej 120 Hz.

Dotyczy to zastosowań związanych z przekaźnikami zabezpieczeniowymi lub pomiarami, dla których akceptowalna jest powyższa dokładność.

W przypadku zastosowań związanych z transferem rozliczeniowym producent czujnika musi osobno wykazać zgodność z odpowiednimi normami dokładności, takimi jak IEEE Std C57.13 lub ich częściami.

5.2 Korekta fazy

W celu uzyskania większej dokładności producent układu pomiarowego może określić wartość korekcji fazy przy częstotliwości sieciowej, której wartość wpisuje się jako korektę do wszystkich wartości w celu uzyskania większej dokładności niż podana powyżej.

UWAGA Nie eliminuje to konieczności stosowania się systemu pomiarowego do błędów kątowych wymienionych powyżej.

5.3 Obciążenie znamionowe

Dokładność układu pomiarowego musi spełniać wymagania tej normy przy podłączeniu obciążenia około 5 kOhm i obciążeniu pojemnościowym do 5 nF. Do jednego wyjścia układu pomiarowego można podłączyć równolegle kilka przekaźników lub innych urządzeń pomiarowych. Przekaźnik lub inne podłączone urządzenie musi mieć impedancję wejściową co najmniej 50 kOhm, ale nie większą niż 200 kOhm.

5.4 Redukcja trybu wspólnego

Tłumienie sygnału wspólnego dla wejść i wyjść obwodu pomiarowego musi być większe niż 86 dB przy 50 lub 60 Hz dla sygnału sygnału wspólnego do ±50 V. Wartość ta jest określona dla zaburzeń napięcia 20 V na wejściu pomiaru prądu system, przy którym wartość prądu wynosi 0,5 p.u, a szum wspólnego typu jest mniejszy niż 10% mierzonego poziomu sygnału.

5.5 Odchylenie sygnału wyjściowego od strefy zerowej

Odchylenie sygnału wyjściowego w stanie ustalonym od strefy zerowej (przesunięcie składowej stałej sygnału wyjściowego) powinno być mniejsze niż 3 mV. Odnosi się to do wymagań dla elektroniki prądu stałego na wyjściu wzmacniacza, ale nie ma zastosowania do wykładniczego zaniku sygnałów prądu zwarciowego „offset DC”.

Odchylenie sygnału wyjściowego w stanie ustalonym od strefy zerowej wzmacniacza powinno być mniejsze niż 3 mV. Odnosi się to do charakterystyki elektronicznej z długoterminową składową prądu stałego na wyjściu wzmacniacza, ale nie jest związane z wykładniczym zanikiem „sygnału przesunięcia prądu stałego” dla sygnałów prądu zwarciowego.

5.6 Przepustowość i reakcja przejściowa

Dostawca systemu pomiarowego musi określić charakterystykę częstotliwościową. Odchylenie częstotliwości sieciowej (częstotliwości sieciowej) określone w 5.1 musi mieścić się w przedziale od 45 do 65 Hz. Odpowiedź powinna wynosić co najmniej 0 do -1 dB do 3 kHz i 0 do -3 dB do 5 kHz. Dolna częstotliwość odcięcia (jeśli występuje) musi być ustawiona w taki sposób, aby system mógł spełnić następujące wymagania dotyczące stałej odpowiedzi na offset sygnału.

Aby w pełni skompensować reakcję wykładniczego zaniku prądu pierwotnego („stałe przesunięcie sygnału”) o wartości 20 p.u. Chwilowy błąd współczynnika skalowania nie powinien przekraczać 10% dla żadnej stałej czasowej do 100 ms.

W przypadku napięcia pierwotnego odpowiedź przejściowa jest określana na podstawie odpowiedzi na impuls skokowy, tj. zmianę wartości kształtu impulsu w zakresie na zero, natomiast sygnał na wyjściu układu pomiarowego powinien w czasie 4 ms obniżyć się do poziomu mniejszego niż 10% wartości początkowej i spaść poniżej 10% dopiero po tym razem.

Niektórzy klienci mogą wymagać działania systemu dla częstotliwości w zakresie od 65 do 75 Hz przy zmniejszonych wymaganiach dotyczących dokładności. Zaleca się, aby dostawca systemu pomiarowego określił wymagania dotyczące parametrów technicznych jego pracy w tym zakresie częstotliwości.

5.7 Konfigurowanie wykrywania sygnału błędu

Wyjście interfejsu systemu pomiarowego musi zostać zablokowane na zero w przypadku wykrycia błędu wewnętrznego, aby uniknąć powodowania poważnych problemów lub fałszywych alarmów. Zapewnia to rezerwowe zasilanie układu pomiarowego lub wyłączenie w przypadku stanów przejściowych. Czas od zidentyfikowania problemu do jego usunięcia nie powinien być dłuższy niż 0,2 ms.

Zwykle identyfikacja problemu odbywa się tą samą metodą, co przy wykrywaniu błędów, tak jak ma to miejsce podczas sprawdzania poprawności transmisji danych z wyjścia, opisanego w p. 4.4.2.

5.8 Opis sygnału poprawności przesyłanych danych

Opcjonalny sygnał przekazujący informację o ważności danych 4.4.2 powinien być sygnałem o poziomie TTL (0 lub 5 V), odizolowanym od uziemienia ochronnego i przeznaczonym do transmisji przy użyciu tej samej metody połączenia, jak w przypadku transmisji sygnałów analogowego systemu pomiarowego (patrz rozdział 7). Jednostka logiczna od 3,0 do 5,5 V informuje o obecności prawidłowych danych na wyjściu układu pomiarowego. Zero logiczne w zakresie od 0 do 0,5 V powinno wskazywać błąd danych na wyjściu układu pomiarowego. Wyjście tego opcjonalnego sygnału musi być w stanie zapewnić napięcie mieszczące się w określonych specyfikacjach przy impedancji obciążenia wynoszącej 200 omów lub większej. Opóźnienie od zdarzenia wyzwalającego do zmiany stanu wyjścia nie powinno przekraczać 1 ms.

Obwody wejściowe przekaźnika ochronnego, aby odbierać ten sygnał, muszą być odizolowane od uziemienia ochronnego i mieć rezystancję wejściową większą niż 2 kOhm. W takim przypadku jako jednostkę logiczną należy postrzegać jedynie sygnały o poziomie powyżej 2,5 V.

6 urządzeń pośrednich

6.1 Cel

Za pomocą urządzeń pośrednich można utworzyć sumę lub różnicę poszczególnych wyjść układów pomiarowych. Można nimi także izolować wejścia różnego typu przekaźników lub liczników podłączonych do jednego wyjścia układu pomiarowego. Urządzenia pośrednie mogą mieć wzmocnienie jednostkowe lub mogą obejmować skalowanie poszczególnych wejść w celu zmiany wzmocnienia systemu pomiarowego.

Urządzenia pośrednie można również zastosować w celu dopasowania wyjść tradycyjnych przekładników do wyjść elektronicznego układu pomiarowego. Wymagania eksploatacyjne określone w tym rozdziale dotyczą wyłącznie urządzeń pośrednich z analogowymi wyjściami elektronicznymi.

6.2 Wymagania eksploatacyjne dla urządzeń pośrednich

Dokładność, szerokość pasma i stosunek sygnału do szumu urządzeń pośrednich muszą być znacznie lepsze niż samych systemów pomiarowych. Poniżej znajdują się wymagania dotyczące urządzeń pośrednich.

Tabela 3 – Wymagania dotyczące wydajności urządzenia pośredniego

Wymagania wydajnościowe wzmacniacza muszą być spełnione łącznie ze złączami wejściowymi i wyjściowymi. Wymagania dotyczące wydajności należy określić przy wzmocnieniu jedności. Producent musi określić charakterystykę działania przy wzmocnieniu innym niż jedność.

6.3 Inne wymagania dotyczące urządzeń pośrednich

Urządzenia pośrednie powinny spełniać wszystkie pozostałe wymagania rozdziałów 4 i 5, z wyjątkiem tych określonych w 6.2. Muszą spełniać wymagania w zakresie warunków eksploatacji, transportu i przechowywania określonych w IEEE Std C37.90.

7 Instrukcja montażu urządzeń pośrednich

Rysunki 2, 3 i 4 przedstawiają przykłady połączeń dla pojedynczych i wielu źródeł oraz obciążeń. Przedstawiono je w celu zilustrowania odpowiednich połączeń dla odległości mniejszych niż 50 m pomiędzy układem pomiarowym a najbardziej odległym wejściem przekaźnika. Skrętkę ekranowaną instaluje się najczęściej w obrębie ogólnego centrum sterowania stacją, gdzie różnica potencjałów zerowych przyłączanych układów w przypadku wystąpienia zwarcia nie przekracza 20 V. Przewody o przekroju 24 AWG i większym są dość dopuszczalne do tych celów. Jeżeli kilka skrętek jest zamkniętych w jednym wspólnym ekranie, wówczas wzajemne oddziaływanie kanałów podczas połączenia różnicowego nie powinno przekraczać poziomu 70 dB.

Należy zwrócić uwagę na następujące główne cechy wspólne dla wszystkich rysunków:

- w przypadku połączenia przewodowego zakłada się, że urządzenie przeszło test odrzucenia trybu wspólnego określony w sekcji 4 i znany jest współczynnik odrzucenia trybu wspólnego określony w sekcji 5;

- żaden ze skręconych przewodów sygnałowych nie jest w żadnym miejscu uziemiony;

- tylko jeden koniec ekranu, zwykle strona przekaźnika lub koniec połączenia, jest bezpośrednio uziemiony. W przypadku wielu systemów pomiarowych i/lub instalacji z wieloma przekaźnikami zdefiniowany jest pojedynczy punkt uziemienia ekranu. Uziemienie to zapewnia jedynie ekranowanie elektrostatyczne, a nie magnetyczne przy częstotliwości sieciowej. Aby zapewnić tylko jeden punkt uziemienia dla wielu przekaźników, ekrany można łączyć łańcuchowo, zapewniając pojedynczy punkt uziemienia;

- należy pamiętać, że każdy system pomiarowy lub przekaźnik z jednostronną lub nieodwracalną polaryzacją, mający wewnętrzne połączenie ze wspólnym lub niespolaryzowanym wyjściem interfejsu uziemienia bezpieczeństwa, może powodować problemy z sygnałem lub zagrażać bezpieczeństwu izolacji innych urządzeń;

Rysunek 2 - Jeden układ pomiarowy i jedno wejście przekaźnikowe

Rysunek 3 – Jeden system pomiarowy z wieloma wejściami przekaźnikowymi

Rysunek 4 - Wiele systemów pomiarowych i urządzenie pośrednie

- Aby zapewnić lepsze ekranowanie elektromagnetyczne wysokiej częstotliwości, można zainstalować dodatkowe ceramiczne kondensatory dyskowe 10 nF pomiędzy ekranem a masą w każdym nieuziemionym punkcie połączenia ekranu. Mogą być instalowane przez użytkownika lub umieszczane wewnątrz urządzeń producentów. Należy zauważyć, że instalacja takich kondensatorów jest ogólnie akceptowalna w przypadku krótkich kabli sterujących, ale stwarza problem w przypadku ekranowania wysokich częstotliwości w przypadku dłuższych kabli sterujących.

Aby podłączyć sprzęt przełączający znajdujący się w rozdzielnicy zewnętrznej, gdzie nie ma sprzyjających warunków dla wysokiej jakości ekranowania elektromagnetycznego wysokiej częstotliwości, klient musi dokładniej przestudiować schematy ekranowania, uziemienie ekranów i izolację elementów. Zobacz standard IEEE 525.

W takim przypadku wymagany jest dodatkowy, niezawodny ekran zewnętrzny, uziemiony na obu końcach, aby wyeliminować wpływ prądów indukowanych przez pola magnetyczne i elektromagnetyczne o częstotliwości przemysłowej w ekranach skrętki na sygnały pomiarowe niskiego poziomu. W takim przypadku elektroniczne źródło sygnału będzie musiało zostać odizolowane od potencjału masy.

Dodatek A (w celach informacyjnych). Bezpieczne użytkowanie

załącznik A
(informacyjny)

Istnieją znaczne różnice w działaniu nowoczesnych analogowych elektronicznych systemów pomiarowych i tradycyjnych pasywnych systemów pomiarowych z przekładnikami.

Nowe i szczególnie ważne dla ich zastosowania są charakterystyki w obszarze niskich częstotliwości, procesy przejściowe przy włączaniu i wyłączaniu systemu, reakcja na stany przejściowe sieci elektrycznej, opóźnienia fazowe, reakcja na stany przejściowe sieci elektrycznej, opóźnienia fazowe, moc wyjściowa nośność, usterki i sygnały awaryjne, kalibracja. Dyskutowany jest kontrast między interfejsami analogowymi i cyfrowymi.

A.1 Odpowiedź amplitudowo-częstotliwościowa w obszarze niskich częstotliwości

Tradycyjne przetworniki z rdzeniem żelaznym reagują na niskie częstotliwości, dopóki urządzenie nie zostanie nasycone prądem przemiennym powyżej określonego limitu woltów na herc. Oznacza to, że takie konwertery odtwarzają tylko bardzo niskie poziomy sygnału bez zniekształceń przy niskich częstotliwościach. Nasycenie pojawia się nagle podczas półcyklu prądu, a sygnał wyjściowy całkowicie i nagle zanika, aż do odwrócenia polaryzacji. Z drugiej strony, analogowe elektroniczne systemy pomiarowe określone w tej normie mogą charakteryzować się spadkiem niskiej częstotliwości lub mogą całkowicie pomijać składową stałą sygnału. Włączenie filtra dolnoprzepustowego może prowadzić do różnych i nieprzewidywalnych stanów nieustalonych, dla których nie zaprojektowano przekaźników ani innych szybkich systemów pomiarowych. Specyficzne zjawiska obejmują: przesunięcie punktu odniesienia, niedokładną reakcję na wykładniczo zanikające charakterystyki przejściowe (pojawienie się stałego napięcia polaryzacji) oraz tłumiony proces oscylacyjny o niskiej częstotliwości w odpowiedzi na wejściowe charakterystyki przejściowe.

Projektanci przekaźników muszą ocenić wpływ komponentów o niskiej częstotliwości na algorytmy pomiarowe, a zwłaszcza te, które są specjalnie zaprojektowane do pracy z przesunięciami prądu stałego, często spotykanymi w przypadku prądów zwarciowych. Dokładność określona w 5.6 obejmuje wymóg działania polaryzacji DC.

A.3 Odpowiedź krokowa

Tryb przejściowy lub odpowiedź na stan przejściowy może się znacznie różnić w zależności od szerokości pasma częstotliwości, chociaż jest ściśle powiązany z odpowiednią charakterystyką filtrowania górnoprzepustowego w elektronice systemu pomiarowego. Zwarcia i przełączanie powodują dodatnie lub ujemne przeregulowanie sygnału wyjściowego i ewentualnie tłumienie oscylacji o wysokiej częstotliwości.

Użytkownik powinien sprawdzić reakcję przekaźnika na te zniekształcenia. Należy pamiętać, że dodatnie lub ujemne przepięcia mogą spowodować nieprawidłowe działanie przekaźników dużej prędkości.

Należy również wiedzieć, że w szerokopasmowych szybkich obwodach różnicowych występują różnice w charakterystyce przenoszenia systemów pomiarowych różnych generacji, różnych producentów, co może również prowadzić do nieprawidłowych i różnych wartości wyjściowych oraz prowadzić do zmniejszonej niezawodności lub nawet fałszywe alarmy.

Problemy nie mogą pojawić się, jeśli częstotliwość odcięcia filtra antyaliasingowego (filtra antyaliasingowego - w celu wyeliminowania efektów aliasingu (podczas próbkowania) podłączonego przekaźnika zabezpieczającego mikroprocesor jest trzy lub więcej razy mniejsza niż szerokość pasma układu pomiarowego i istniejące zniekształcenia częstotliwości .

Należy zauważyć, że 5.6 uwzględnia charakterystykę przejściową układu pomiarowego, określoną na podstawie odpowiedzi na impuls skokowy.

A.4 Opóźnienie fazy

Opóźnienie czasowe mierzonej wartości pierwotnej w sieci elektrycznej, zanim układ pomiarowy przedstawi tę wartość podłączonym układom przekaźnikowym, może być krótkie w porównaniu z odstępem czasu pomiaru i na pierwszy rzut oka nieistotne. Może to jednak stanowić poważny problem dla każdego przekaźnika lub systemu pomiarowego, który porównuje dwie wielkości pochodzące z dwóch różnych typów systemów pomiarowych. Porównanie prądu różnicowego jest dobrym przykładem sytuacji, w której obwody o dużej prędkości są wrażliwe na różnicę opóźnień fazowych między dwoma systemami pomiarowymi. Przekaźniki odległościowe i kierunkowe, a w szczególności komercyjne liczniki energii, mogą nawet sprawiać problemy, ponieważ muszą dokładnie odzwierciedlać zależności między napięciami i prądami.

Systemy pomiaru napięcia wykorzystują inne metody niż pomiar prądu, nie zapewniając jednakowych opóźnień w pomiarze sygnałów prądu pierwotnego i napięcia.

W rozdziale 5.2 opisano dodatkową opcję wyboru korekcji fazy, którą zapewnia producent.

A.5 Nośność

Tryb wyjścia napięciowego układu pomiarowego musi być w stanie dostarczyć prąd do całego podłączonego obciążenia, rozpatrywanego jako równoległa grupa wejść. Zwiększanie obciążenia może prowadzić do pogorszenia dokładności generowania sygnału i jest określane przez impedancję źródła, ale sygnały wyjściowe mogą być nadal wykorzystywane w wielu zastosowaniach. Można dokonać porównania z wpływem obciążeń na tradycyjne przekładniki prądowe i napięciowe (CT i VT).

A.6 Usterki i alarmy

Projektanci muszą być w stanie określić tryb awarii w szczególności elementów elektronicznych i ocenić wpływ zdarzeń takich jak uszkodzenia, przerwy lub pęknięcia kabla światłowodowego. Nie da się uniknąć wszystkich problemów, ale istnieją dodatkowe środki bezpieczeństwa, które zapobiegają niektórym z nich.

W tym względzie projektant może pomóc, dostarczając danych na temat wysokiej wydajności systemów samokontroli, które potrafią wykryć tłumienie lub tłumienie sygnału wyjściowego. Należy pamiętać, że tłumiony sygnał wyjściowy może zakłócać działanie przekaźnika zabezpieczenia różnicowego, co może skutkować fałszywym wyłączeniem, chyba że do zablokowania wyłączenia zostanie zastosowany dodatkowy sygnał nieprawidłowych danych. Utrata napięcia na zdalnym przekaźniku spowoduje nieprawidłowe działanie lub utratę potencjalnej logiki (jeśli jest używana), co znacznie ograniczy możliwości zabezpieczenia.

Zdolność systemu pomiarowego do samodiagnostyki drobnych problemów i generowania alarmów innych niż awaryjne, bez tłumienia lub blokowania, daje personelowi konserwacyjnemu perspektywę rozwiązania problemu, zanim spowoduje on negatywne konsekwencje. Port transmisji danych, który może raportować określone informacje diagnostyczne za pośrednictwem modemu lub portu WAN, zwiększa prawdopodobieństwo, że technicy przybędą na miejsce z właściwymi częściami i sprzętem.

A.7 Kalibracja

Dostawca ma obowiązek przeszkolić użytkownika w zakresie metod przeprowadzania i późniejszej konserwacji wstępnej kalibracji układu pomiarowego. W szczególności należy upewnić się, że dostarczone urządzenie IED ma właściwości, które mogą być wymagane do przeprowadzenia procedury kalibracji.

Dostawca systemu pomiarowego musi poinstruować klienta, co zrobić z kalibracją systemu w przypadku wymiany wadliwego elektronicznego modułu konwersji.

A.8 Interfejsy cyfrowe

Niniejsza norma obejmuje jedynie interfejsy analogowe niskiego poziomu, w tym te wbudowane w duże systemy, które mają cyfrowe interfejsy danych i gdzie interoperacyjność interfejsów analogowych jest ważna zarówno dla producentów, jak i użytkowników.

Interfejsy cyfrowe wymagają specyfikacji procesów próbkowania, wydajności i wielowarstwowych warstw protokołów komunikacyjnych do komunikacji pomiędzy systemem pomiarowym a przekaźnikiem. Cyfrowe interfejsy danych do dostarczania informacji o sieci elektrycznej są przewidziane w normach IEC 61850-9-1, IEC 61850-9-2, IEC 60044-7 i IEC 60044-8.

Załącznik TAK (wymagane). Informacja o zgodności referencyjnych norm międzynarodowych z normami krajowymi

Zastosowanie TAK
(wymagany)

Tabela DA.1

Bibliografia

IEEE P1331 Draft 8.3, kwiecień 1999: Próbne zastosowanie standardu dla wejść sygnałów analogowych o niskiej energii do przekaźników ochronnych

Tekst dokumentu elektronicznego
przygotowane przez Kodeks JSC i zweryfikowane względem:
oficjalna publikacja
M.: Standartinform, 2019

Wykład 3

Cykl życia oprogramowania

Podstawowe pojęcia związane z definiowaniem cyklu życia

Proces rozwoju

Proces rozwoju

10. Analiza wymagań systemowych

11. Analiza wymagań oprogramowania

12. Projektowanie architektury oprogramowania

13. Szczegółowy projekt oprogramowania (plan prac nad rozwojem oprogramowania)

14. Kodowanie i testowanie oprogramowania polega na rozwiązaniu następujących zadań:

15. Integracja systemu

16. Testowanie kwalifikacyjne oprogramowania

17. Instalacja i akceptacja oprogramowania

18. Obsługa oprogramowania

19. Konserwacja oprogramowania (wg standardu IEEE – 90)

20. Wspieranie procesów cyklu życia oprogramowania

21. Proces dokumentowania

22. Zarządzanie konfiguracją

23. Proces zapewnienia jakości

24. Weryfikacja

25. Certyfikacja

26. Procesy organizacyjne cyklu życia oprogramowania

27. Grupy standardów ESPD

28. Wykaz dokumentów ESPD

29. Zalety stosowania standardów ESPD

30. Wady standardów ESPD

31. Standard GOST 34.601-90: etapy i etapy tworzenia zautomatyzowanego systemu

32.