IEEE стандарти. Пролозова Н.О., Назарова О.Б., Давлеткиреева Л.З.

Поддръжката винаги е била призната за един от основните етапи от жизнения цикъл на софтуера. Още в средата на 70-те години беше признато, че поддръжката е етап, който поема повече от 50% от разходите за разработване и внедряване на софтуерен инструмент.

Непрекъснатостта на бизнес процесите и безопасността на корпоративната информация, необходима за живота на компаниите, зависят от ефективността на работата на етапа на поддръжка и поддръжка.

За сложни софтуерни системи, които изискват дългосрочна употреба и поддръжка на множество версии, има спешна необходимост от регулиране на техния жизнен цикъл, формализиране и прилагане на стандартни профили и сертифициране на качеството на програмата.

Използването на регулаторни и нормативни документи прави жизнения цикъл на софтуера по-дефиниран, предвидим по структура, съдържание, качество и цена. Документацията, информационното съдържание и разбираемостта определят състава и качеството на поддържащата документация.

За правилното и ефективно организиране на най-дългия и важен етап от жизнения цикъл на софтуера - Поддръжката на софтуера, който изисква най-голям разход на време, труд и материални ресурси, е необходимо да се вземат предвид препоръките, изложени в международни и национални стандарти, съдържащи разпоредби за оптимална организация на този етап.

Първо, необходимо е да се анализира тълкуването на етапа на поддръжка в различни стандарти.

Софтуерната поддръжка се дефинира от стандарта IEEE за софтуерна поддръжка (IEEE 1219) като модификация на софтуерен продукт след пускане в експлоатация за отстраняване на повреди, подобряване на производителността и/или други характеристики (атрибути) на продукта или адаптиране на продукта за употреба в модифицирана среда. Интересно е, че този стандарт също така разглежда въпроси за подготовка за поддръжка преди системата да бъде пусната в експлоатация, но структурно това се прави на нивото на съответното информационно приложение, включено в стандарта.

От своя страна стандартът за жизнения цикъл 12207 (IEEE, ISO/IEC, GOST R ISO/IEC) позиционира поддръжката като един от основните процеси на жизнения цикъл. Този стандарт описва поддръжката като процес на модифициране на софтуерен продукт по отношение на неговия код и документация за решаване на проблеми, които възникват по време на работа или за осъзнаване на необходимостта от подобряване на определени характеристики на продукта. Предизвикателството е да се модифицира продуктът, като същевременно се запази неговата цялост.

Международният стандарт ISO/IEC 14764 (Стандарт за софтуерно инженерство – Софтуерна поддръжка) дефинира поддръжката на софтуера със същите термини като стандарта 12207, като набляга на подготвителната работа за дейности по поддръжка, преди системата да започне да работи, като проблеми с планирането, разпоредби и поддръжка.

След пускане в експлоатация на подстанцията е необходимо нейната работа да се поддържа на нивото на изискванията, заложени в техническите спецификации. Тази задача включва както премахване на софтуерни проблеми и грешки, така и евентуално увеличаване на функционалността. За да организирате тези работи, е необходимо да се обърнете към разпоредбите, посочени в стандартите.

Редица източници, по-специално стандартът IEEE 1216, дефинират три категории работа по поддръжката: настройка, адаптиране и подобрение. Тази класификация беше актуализирана в ISO/IEC 14764 с въвеждането на четвърти компонент.

Така днес говорим за четири категории подкрепа:

1. Коригираща поддръжка включва промени, причинени от необходимостта от отстраняване (коригиране) на действителни грешки в софтуерния продукт. Коригираща поддръжка се извършва, ако софтуерният продукт не отговаря на установените изисквания.

2. Адаптивна поддръжка свързано с необходимостта от адаптиране на програмния продукт към променената среда (условия). Тези промени са свързани с въвеждането на нови изисквания към системния интерфейс, самата система или техническите средства.

3. Пълна подкрепа определя промени за подобряване на характеристиките на производителността на софтуера и неговата поддръжка. Тези промени могат да доведат до предоставяне на нова функционалност на потребителите, преразглеждане на технологията за разработване на придружаващи документи или промени в самите документи.

4. Превантивна подкрепа е насочен към промени, причинени от необходимостта от отстраняване (коригиране) на потенциални (скрити) грешки в софтуерен продукт. Превантивната поддръжка обикновено се извършва за софтуерни продукти, свързани с осигуряване или защита на човешкия живот.

Поддържаемостта е един от показателите за качество на софтуера, както и важна характеристика за клиента, доставчика и потребителя.

Поддържаемостта или поддържаемостта на софтуерна система се определя, например, от IEEE 610.12-90 Стандартен речник за терминология на софтуерното инженерство, актуализация 2002) като лекота на поддръжка, разширение, адаптиране и настройка, за да се отговори на определени изисквания. Стандартът ISO/IEC 9126-01 (Софтуерно инженерство - Качество на продукта - Част 1: Модел на качеството, 2001) разглежда поддържаемостта като една от характеристиките на качеството.

Поддържаемостта трябва да бъде определена преди разработването на софтуера, т.е. е изготвено подходящо споразумение между клиента и доставчика като част от „подготвителната“ работа на процеса на поръчка съгласно (ISO/IEC, #M12291 1200009075 GOST R ISO/ IEC) 12207#S. Разработчикът създава план за поддръжка, който трябва да отразява конкретни методи за осигуряване на поддръжка на софтуера, подходящи ресурси и алгоритъм за извършване на работа.

Качеството на софтуерния инструмент е важен аспект от поддръжката на софтуерния продукт. Поддържащите трябва да имат програма за осигуряване на качеството на софтуера, обхващаща шестте характеристики на качеството, определени в ISO/IEC 9126. Поддържащите софтуер трябва да разполагат с подходящ процес за дефиниране, описание, избор, прилагане и подобряване на методологиите за оценка (измерване) на характеристиките на софтуера .

За да се намалят разходите за по-нататъшна поддръжка, по време на процеса на разработка е необходимо да се уточнят, оценят и контролират характеристиките, които влияят на поддръжката. Редовното изпълнение на такава работа улеснява по-нататъшната поддръжка, повишавайки нейната поддръжка (като качествена характеристика).Това е доста трудно за постигане, тъй като такива характеристики често се игнорират по време на разработката.

Както беше обсъдено по-рано, поддръжката на софтуера е скъп етап от жизнения цикъл, за оптимизиране на работата на който е необходимо да се прилагат различни методи за оценка на разходите за поддръжка.

Цената на поддръжката се влияе от много различни фактори. ISO/IEC 14764 гласи, че „има два най-популярни метода за оценка на разходите за поддръжка: – параметричният модел и използването на опита“. Най-често и двата подхода се комбинират, за да се подобри точността на оценката.

Съществуват различни методи за вътрешна оценка на производителността на помощния персонал, за да се сравни представянето на различни групи за поддръжка. Организацията за поддръжка трябва да определи показателите, по които ще се оценява съответната работа. Стандартите IEEE 1219 и ISO/IEC 9126-01 (Софтуерно инженерство - Качество на продукта - Част 1: Модел на качеството, 2001) предлагат специализирани показатели, фокусирани конкретно върху проблеми с поддръжката и свързани програми.

Работата по поддръжката трябва да бъде строго регламентирана и описана, като съдържа подробни входове и изходи на процеса. Тези процеси са обхванати от стандартите IEEE 1219 и ISO/IEC 14764.

Процесът на поддръжка започва в съответствие със стандарта IEEE 1219 от момента на пускане на софтуера в експлоатация и засяга въпроси като планиране на дейности по поддръжка.

Стандартът ISO/IEC 14764 изяснява разпоредбите на стандарта за жизнен цикъл 12207, свързани с процеса на поддръжка. Работата по поддръжката, описана в този стандарт, е подобна на работата в IEEE 1219, с изключение на това, че е групирана малко по-различно.

Нека разгледаме по-подробно извадки от стандарта GOST R ISO/IEC 14764-2002, който съдържа пълния автентичен текст на международния стандарт ISO/IEC 14764.

В съответствие с GOST R ISO/IEC 14764-2002, който описва процеса на поддръжка на софтуера, подробностите за процеса на поддръжка на софтуера трябва да бъдат документирани, така че поддържащият персонал да действа в рамките на един процес. Системата от индикатори за качество (метрики) трябва да улесни изпълнението на процеса на поддръжка и да допринесе за подобряването (модернизирането) на този софтуер.

Поддържащият трябва (5.5.2.1 GOST R ISO/IEC 12207) да анализира доклада за проблема или предложението за модификация за въздействието му върху организационни въпроси, съществуващата система и интерфейсните връзки с други системи.

Въз основа на анализа поддържащият трябва (5.5.2.3 GOST R ISO/IEC 12207) да разработи варианти за прилагане на промяната. Преди да направи промени в системата, поддържащият трябва (виж 5.5.2.5 GOST R ISO/IEC 12207) да получи одобрение за избраната опция за промяна в съответствие с договора и потвърждение, че направената промяна удовлетворява изискванията, установени в договора (виж 5.5 .4.2 GOST R ISO/IEC 12207). Поддържащият трябва (5.5.2.4 GOST R ISO/IEC 12207) да документира: доклад за проблем или предложение за модификация, резултатите от техния анализ и варианти за прилагане на промените.

За да се контролира правилно прехвърлянето на системата, трябва да се разработи, документира и изпълни план за прехвърляне на съоръжението (5.5.5.2 GOST R ISO/IEC 12207). Потребителите трябва да бъдат включени в планираната работа.

За поддържащите дейности има редица уникални работни места и практики, които трябва да се вземат предвид при организирането на поддръжката. SWEBOK (Съвкупност от знания за софтуерно инженерство) дава следните примери за този вид уникални характеристики.

Излъчване:контролираната и координирана дейност по прехвърляне на софтуер от разработчиците към групата, услугата или организацията, отговорна за по-нататъшната поддръжка.

Приемане/отхвърляне на заявки за модификация : Заявките за промени могат да бъдат приети и прехвърлени в работа или отхвърлени поради различни основателни причини - обемът и/или сложността на необходимите промени, както и усилията, необходими за това. Подходящи решения могат да бъдат взети и въз основа на приоритет, оценка на осъществимостта, липса на ресурси (включително липса на възможност за включване на разработчици в решаването на задачи за модификация, ако има реална необходимост от това), одобрено планиране за изпълнение в следващите освобождаване и др.

Средства за уведомяване на персонала по поддръжката и проследяване на състоянието на заявки за модификация и доклади за грешки : Функция за поддръжка на краен потребител, която инициира усилия за оценка на необходимостта, приоритизиране и цена на модификации, свързани със заявка или докладван проблем.

Анализ на въздействието:анализ на възможните последици от промени, направени в съществуващата система.

Софтуерна поддръжка: работа по консултиране на потребители, извършена в отговор на техните искания за информация, например по отношение на съответните бизнес правила, проверка, съдържание на данни и конкретни потребителски въпроси и техните доклади за проблеми (грешки, повреди, неочаквано поведение, неразбиране на аспекти на работа с система и др.); П.).

Договори и задължения: Те включват класическото споразумение за ниво на обслужване (SLA), както и други договорни аспекти, въз основа на които групата/услугата/организацията за поддръжка извършва съответната работа.

Освен това има допълнителни дейности, които поддържат процеса на поддръжка, описани от SWEBOK като дейности на персонала по поддръжката, които не включват изрично взаимодействие с потребителите, но са необходими за извършване на свързаните дейности. Тази работа включва: планиране на поддръжката, управление на конфигурацията, проверка и сертифициране, оценка на качеството на софтуера, различни аспекти на преглед, анализ и оценка, одит и обучение на потребители. Такава специална (вътрешна) работа включва и обучение на помощен персонал.

Таблица 1 по-долу предоставя кратък преглед на основните стандарти, използвани при организирането на поддръжката на информационните системи.

Таблица 1. Стандарти в областта на поддръжката на информационни системи

В допълнение към международните и национални стандарти, регулиращи процеса на поддържане на информационни системи, разгледани по-горе, съществуват различни уреждащи документи и вътрешнофирмени (корпоративни) стандарти, в основата на които са международните стандарти. В този случай се обръща специално внимание на качеството на документацията, което до голяма степен определя конкурентоспособността на софтуера. При създаването на сложни софтуерни продукти и осигуряването на техния жизнен цикъл е необходимо да се изберат необходимите стандарти и да се създаде целия набор от документи, т.е. профил, който осигурява регулиране на всички етапи и поддръжка.

Нека разгледаме прилагането на стандарти за поддържане на информационни системи, използвайки конкретен пример.Висококачественото функциониране на системата изисква постоянно адаптиране към променящите се бизнес процеси на организацията, както и бърза реакция при повреди и отстраняване на проблеми. Във връзка с това ръководството на ZAO Firm SoftInCom взе решение за необходимостта от сключване на споразумение с разработчиците на корпоративната информационна система (CIS) Orient Express за актуализиране и поддръжка на системата.

Поддръжката на Eastern Express CIS включва поддръжка на няколко типа (съгласно GOST R ISO IEC 14764-2002). А именно коригираща поддръжка, която е свързана с промени, причинени от необходимостта от отстраняване (коригиране) на действителни грешки в софтуерния продукт. Коригираща поддръжка се извършва, ако софтуерният продукт не отговаря на установените изисквания. Както и адаптивна и пълна поддръжка, която модернизира софтуерния продукт.

Необходимостта от коригираща поддръжка възниква при възникване на системни грешки, както и грешки, причинени от потребителя. Грешките, причинени от потребителя, включват например случайно изтриване на важни данни, което води до необходимостта от използване на резервно копие на системата. Системните грешки възникват доста често, особено след инсталиране на нови версии, тъй като новите версии предполагат доста сериозни промени в съществуващите технологии за обработка на данни и включването на нови модули.

Необходимостта от адаптивна поддръжка възниква, когато има промени във функционирането на всеки бизнес процес (провеждане на промоция, промяна на външни печатни форми, поръчки от централния офис и т.н.) или когато извършването на някакви операции е неудобно, което изисква промени в системния интерфейс.

Пълната поддръжка се предоставя много по-рядко от други видове поддръжка. Извършва се, когато възникнат много подобни инциденти, заявки и желания на потребителите, както и след като дизайнерите на CIS са анализирали възможностите на системата.

Работата по поддръжката може да бъде разделена на четири етапа: анализ на дефекти и модификации, внедряване на модификации, оценка и приемане на резултатите от поддръжката, прехвърляне към друга платформа. Всеки от тези етапи съдържа специфични входове, изходи и трябва да бъде документиран.

Таблица 2 показва основните етапи на поддръжката и резултатите в параграфа на придружаващата документация.

Таблица 2. Етапи на процеса на поддръжка на информационната система

В съответствие с 5.5.2.1 от GOST R ISO/IEC 12207, поддържащият трябва да анализира докладите на потребителите за проблема. За автоматизиране на регистрацията и записването на заявки от потребители на Orient Express CIS се използва системата за регистрация на инциденти MantisBT. Въз основа на данни, регистрирани в системата MantisBT генерира документ „Доклад за дефекти, идентифицирани от потребители“, съдържащ следните полета: номер на инцидента, дата на създаване, категория, същност на инцидента, предложено решение.

Въз основа на анализа поддържащият трябва (5.5.2.3 GOST R ISO/IEC 12207) да разработи варианти за внедряване на промените. За тази цел се разработва документът „Дневник на изготвените и одобрени корекции на новата основна версия на CIS“, съдържащ следните данни: категория, дефект, идентифициран от поддържащата организация, дефект, идентифициран от потребителите на CIS, корекция.

След това поддържащият трябва (5.5.4.2 GOST R ISO/IEC 12207) да получи потвърждение, че направената промяна отговаря на изискванията, установени в договора. За тези цели се генерира документ „Уведомление за потребителите за пускането на нова версия на CIS“ и се очаква потвърждение за съгласие за инсталиране на новата версия.

За да контролирате правилно прехвърлянето на системата, трябва да има

Структурата на жизнения цикъл на софтуера в съответствие със стандарта ISO/IEC 12207 се базира на три групи процеси (фиг. 1):

· основни процеси от жизнения цикъл на софтуера (закупуване, доставка, разработка, експлоатация, поддръжка);

· спомагателни процеси, които осигуряват изпълнението на основните процеси (документиране, управление на конфигурацията, осигуряване на качеството, проверка, сертифициране, оценка, одит, решаване на проблеми);

· организационни процеси (управление на проекти, създаване на проектна инфраструктура, дефиниране, оценка и подобряване на самия жизнен цикъл, обучение).

Ориз. 1. Процеси на жизнения цикъл на софтуера.

Процес на придобиване(процес на придобиване). Състои се от действия

и задачи на клиента, закупуващ софтуера. Този процес включва следните стъпки:

1) започване на придобиване;

2) изготвяне на тръжни предложения;

3) подготовка и коригиране на договора;

4) надзор върху дейността на доставчика;

5) приемане и завършване на работата.

Процес на доставка(процес на доставка). Той обхваща дейностите и задачите, изпълнявани от доставчика, който доставя на клиента софтуерен продукт или услуга. Този процес включва следните стъпки:

1) започване на доставката;

2) изготвяне на отговор на тръжни предложения;

3) подготовка на договора;

4) планиране;

5) изпълнение и контрол;

6) проверка и оценка;

7) доставка и завършване на работата.

Процес на развитие(процес на разработка). Той предвижда действията и задачите, изпълнявани от разработчика, и обхваща създаването на софтуер и неговите компоненти в съответствие с определени изисквания, включително подготовка на проектна и експлоатационна документация, подготовка на материали, необходими за тестване на функционалността и подходящо качество на софтуера продукти, материали, необходими за организиране на обучението на персонала и др.

Процесът на разработка включва следните стъпки:

1) анализ на системните изисквания;

2) проектиране на системна архитектура;

3) анализ на софтуерните изисквания;

4) проектиране на софтуерна архитектура;

5) подробен софтуерен дизайн;

6) софтуерно кодиране и тестване;

7) софтуерна интеграция;

8) тестване на квалификацията на софтуера;

9) системна интеграция;

10) квалификационно изпитване на системата;

11) инсталиране на софтуер;

12) приемане на софтуер.

Операционен процес(операционен процес). Обхваща действията и задачите на оператора – организацията, оперираща със системата. Този процес включва следните стъпки:

1) оперативно тестване;

2) работа на системата;

3) потребителска поддръжка.

Процес на поддръжка(процес на поддръжка). Той предвижда действията и задачите, изпълнявани от придружаващата организация (ескорт служба). Този процес се активира, когато промени (модификации) на софтуерния продукт и свързаната с него документация са причинени от проблеми или необходимост от модернизация или адаптация на софтуера. В съответствие със стандарта IEEE-90 поддръжката се отнася до извършване на промени в софтуера с цел коригиране на грешки, подобряване на производителността или адаптиране към променени условия на работа или

изисквания. Промените, направени в съществуващия софтуер, не трябва да нарушават

неговата цялост. Процесът на поддръжка включва прехвърляне на софтуер в друга среда (миграция) и завършва с извеждане от експлоатация на софтуера.

Процесът на поддръжка включва следните действия:

1) анализ на проблеми и искания за модификация на софтуера;

2) модификация на софтуера;

3) проверка и приемане;

4) прехвърляне на софтуер в друга среда;

5) извеждане от експлоатация на софтуера.

Групата спомагателни процеси включва:

документация;

Управление на конфигурацията; осигуряване на качеството;

Проверка; сертифициране;

Оценка с участие;

Решаване на проблеми.

Процес на документиране(процес на документиране). Той предоставя формализирано описание на информацията, създадена по време на жизнения цикъл на софтуера. Процесът на документиране включва следните стъпки:

1) проектиране и разработка;

2) издаване на документация;

3) документация.

Процес на управление на конфигурацията(процес на управление на конфигурацията). Включва използването на административни и технически процедури през целия жизнен цикъл на софтуера, за да се определи състоянието на софтуерните компоненти в системата, да се управляват софтуерните модификации, да се опишат и изготвят доклади за състоянието на софтуерните компоненти и заявки за модификация, да се гарантира пълнота, съвместимост и коректност на софтуерни компоненти, управление на съхранение и доставка от BY. Съгласно стандарта IEEE-90 софтуерната конфигурация се разбира като съвкупността от неговите функционални и физически характеристики.

характеристики, установени в техническата документация и внедрени в софтуера.

Управлението на конфигурацията ви позволява да организирате, систематично да отчитате и контролирате промените в софтуера на всички етапи от жизнения цикъл. Общите принципи и препоръки за управление на конфигурацията на софтуера са отразени в проекта на стандарт ISO/I EC CD 12207-2: 1995 "Информационни технологии - Процеси на жизнения цикъл на софтуера. Част 2.

Управление на конфигурацията за софтуер". Процесът на управление на конфигурацията включва следните действия:

1) идентификация на конфигурацията;

2) контрол на конфигурацията;

3) отчитане на състоянието на конфигурацията;

4) оценка на конфигурацията;

5) управление и доставка на освобождаване.

Процес за осигуряване на качеството(процес за осигуряване на качеството). Той осигурява подходяща увереност, че софтуерът и процесите на неговия жизнен цикъл отговарят на определени изисквания и одобрени планове. Качеството на софтуера се разбира като набор от свойства, които характеризират способността на софтуера да удовлетворява определени изисквания. За да се получат надеждни оценки на създавания софтуер, процесът на осигуряване на неговото качество трябва да се извършва независимо от субектите, пряко свързани с разработката на софтуер. Могат да се използват резултатите от други поддържащи процеси като проверка, валидиране, съвместна оценка, одит и разрешаване на проблеми. Процесът на осигуряване на качеството включва следните дейности:

1) осигуряване на качеството на продукта;

2) осигуряване на качеството на процеса;

3) осигуряване на други показатели за качество на системата.

Процес на проверка(процес на проверка). Състои се в установяване, че софтуерните продукти, които са резултат от някакво действие, напълно отговарят на изискванията или условията, определени от предишни действия (проверка в тесен смисъл означава формално доказателство за коректността на софтуера).

Процес на атестиране(процес на валидиране). Той включва определяне на пълното съответствие на зададените изисквания и създадената система или програмен продукт с тяхното специфично функционално предназначение. Сертифицирането обикновено се отнася до потвърждение и оценка на надеждността на софтуерното тестване.

Процес на оценяване с участие(процес на съвместен преглед). Предназначен е за оценка на състоянието на работата по проекта и софтуера, създаден по време на изпълнението на тези работи (действия). Фокусира се основно върху контролирането на планирането и управлението на проектни ресурси, персонал, оборудване и инструменти.

Процес на одит(процес на одит). Това е определяне на съответствието с изискванията, плановете и договорните условия.

Процес на разрешаване на проблеми(процес на разрешаване на проблеми). Включва анализ и разрешаване на проблеми (включително открити несъответствия) независимо от техния произход или източник, които са открити по време на разработка, експлоатация, поддръжка или други процеси. Всеки открит проблем трябва да бъде идентифициран, описан, анализиран и решен.

Групата организационни процеси на жизнения цикъл на софтуера включва:

контрол;

Създаване на инфраструктура;

Подобряване;

Пускане на нови версии;

образование.

Процес на управление(процес на управление). Състои се от дейности и задачи, които могат да се изпълняват от всяка страна, управляваща своите процеси. Тази страна (мениджър) отговаря за управлението на пускането на продукта, управлението на проекти и управлението на задачите на свързани процеси, като придобиване, доставка, разработка, експлоатация, поддръжка и др.

Процес на създаване на инфраструктура(инфраструктурен процес). Той обхваща избора и поддръжката (поддръжката) на технологии, стандарти и инструменти, избора и инсталирането на хардуер и софтуер, използвани за разработване, експлоатация или поддръжка на софтуер. Инфраструктурата трябва да се модифицира и поддържа в съответствие с промените в изискванията за съответните процеси. Инфраструктурата от своя страна е един от обектите на управление на конфигурацията.

Процес на подобряване(процес на подобрение). Той осигурява оценка, измерване, контрол и подобряване на процесите на жизнения цикъл на софтуера. Подобряването на процесите на жизнения цикъл на софтуера е насочено към повишаване на производителността на всички специалисти, участващи в тях, чрез подобряване на използваната технология, методите на управление, избора на инструменти и обучение

персонал.

Учебен процес(обучителен процес). Обхваща първоначално обучение и последващо текущо развитие на персонала.

В ИТ сферата най-практичните стандарти се публикуват от следните организации:

• Институт на инженерите по електротехника и електроника(IEEE, www.ieee.org) е водеща научна и техническа организация от много години, включително в създаването на стандарти за софтуерна документация. Повечето стандарти са разработени от различни комитети, състоящи се от опитни и отговорни професионални инженери. Някои от стандартите на IEEE също са станали стандарти на ANSI (Американски национален институт по стандартизация). Най-вече стандартите IEEE формират основата за подготовката на MU за CP. Schmidt M. Прилагане на стандартите за софтуерно инженерство на IEEE.
• Международна организация по стандартизация (ISO)има огромно влияние в целия свят, особено сред организациите на производители, работещи с Европейския съюз (ЕС). В момента практически всички съвременни ИТ стандарти, преведени и приети в Руската федерация, са стандарти, изготвени от ISO съвместно с Международната електротехническа комисия - IEC. Знаете, че се обръща специално внимание на въпросите за осигуряване на качеството на продуктите на международно ниво, следователно, съгласно Указ на руското правителство № 113 от 02.02.1998 г., съответствие с изискванията на ISO 9000 (серия от стандарти, регулиращи управлението на качеството в предприятия) е предпоставка за получаване на държавна поръчка.
• Институт по софтуерни инженерни технологии(Институт за софтуерно инженерство - SEI, sei.cmu.edu - повече от 1000 статии) е създаден от Министерството на отбраната на САЩ в университета Карнеги Мелън, за да повиши нивото на софтуерните технологии сред изпълнителите на Министерството на отбраната. Работата на SEI също е възприета от много търговски компании, които считат подобряването на процеса на разработка на софтуер за стратегическа корпоративна цел. Ще разгледаме един от стандартите, разработен от SEI, наречен Capability Maturity Model (CMM).
• Технологичен консорциум за манипулиране на обекти(Object Management Group, www.omg.org) е организация с нестопанска цел с приблизително 700 компании-членове. OMG определя стандарти за разпределени обектно-ориентирани изчисления. Трябва да се отбележи, че OMG използва унифицирания език за моделиране UML като свой стандарт за описание на проекти. Ще проучим подробно UML, защото... използването на този език във връзка с унифицирания процес от Rational е основата за разработване на ядрото на курсовия проект.

Понятие за жизнения цикъл на системата

Необходимостта от стандартизация на разработката на софтуер е най-добре описана във въведението на стандарта GOST R ISO/IEC 12207-99 „Информационни технологии. Процеси на жизнения цикъл на софтуера": „Софтуерът е неразделна част от информационните технологии и традиционните системи като транспортни, военни, медицински и финансови. Има много различни стандарти, процедури, методи, инструменти и видове операционни среди за разработване и управление на софтуер. Това разнообразие създава предизвикателства при проектирането и управлението на софтуера, особено когато се комбинират софтуерни продукти и услуги. Стратегията за разработка на софтуер изисква преминаване от това множество към общ ред, който ще позволи на практикуващите софтуер да „говорят на един език“, когато разработват и управляват софтуер. Този международен стандарт осигурява този общ ред.

Стандарт GOST R ISO/IEC 12207-99определя основната концепция за софтуерна система - „жизнен цикъл“ (GOST R ISO/IEC TO 15271-2002 „Информационни технологии. Указания за прилагане на GOST R ISO/IEC 12207“).

GOST R ISO/IEC 12207-99въвежда концепцията за модел на жизнения цикъл като структура, състояща се от процеси, която обхваща живота на системата от установяването на изискванията към нея до края на нейната употреба. Предлага се да се коригира това определение и да се раздели на две определения:

1. жизнен цикъл– съвкупност от процеси, разделени на работи и задачи, включително разработването, експлоатацията и поддръжката на софтуерен продукт, обхващащи живота на системата от установяването на изисквания към нея до прекратяването на нейното използване.
2. модел на жизнения цикъл– структура, която определя последователността на процесите, работите и задачите, изпълнявани през целия жизнен цикъл на софтуерната система, както и връзките между тях.

Процесите на жизнения цикъл са разделени на три групи:основни, спомагателни и организационни.

Групата от основни процеси включва:придобиване, доставка, развитие, експлоатация и поддръжка. Основните процеси на жизнения цикъл се изпълняват под контрола на основните страни, участващи в жизнения цикъл на софтуера. Основната страна е една от онези организации, които инициират или извършват разработването, експлоатацията или поддръжката на софтуерни продукти. Основните страни са клиент, доставчик, разработчик, оператор и персонал за поддръжка на софтуер.

Фигура - Основни процеси от жизнения цикъл на ИС

Групата спомагателни процеси включва процеси, които осигуряват изпълнението на основните процеси:

• документация;
• управление на конфигурацията;
• осигуряване на качеството;
• проверка;
• сертифициране;
• степен;
• одит;
• разрешаване на проблем.

Групата организационни процеси включва процесите:

• управление на проекти;
• създаване на проектна инфраструктура;
• определяне, оценка и подобряване на самия жизнен цикъл;
• образование.

В текста на GOST 12207-99Работата, която е част от основните, спомагателните и организационните процеси, се характеризира много общо, всъщност са очертани само техните направления, следователно, за да започне проектирането, ще са необходими стандарти и допълнителна литература, които разкриват съдържанието на всеки отделен процес или още по-добре индивидуална работа.
От групата на основните процеси най-голям интерес представлява процесът на развитие.
Трябва да се отбележи, че GOST 34.601-90 „Автоматизирани системи. Етапи на създаване" процесът на създаване на автоматизирана система е разделен на следните етапи:

• формиране на изисквания към ораторите,
• развитие на AC концепцията,
• техническо задание,
• идеен проект,
• технически проект,
• работна документация,
• въвеждане в експлоатация,
• акомпанимент.

Етапите са разделени на етапи, чието съдържание се припокрива със съдържанието на редица задачи, описани в GOST 12207-99.

Процес на развитие

процес на развитиепредвижда действия и задачи, изпълнявани от разработчика, и обхваща работата по създаването на софтуера и неговите компоненти в съответствие с определени изисквания, включително изготвянето на проектна и експлоатационна документация; подготовка на материали, необходими за тестване на производителността и подходящото качество на софтуерните продукти, материали, необходими за организиране на обучение на персонала и др.

Фигура - Структура на процеса на разработка

Подготвителна работа

започва с избора на модел на жизнения цикъл на PS, който съответства на мащаба, значимостта и сложността на проекта. Дейностите и задачите на процеса на разработка трябва да съответстват на избрания модел. Разработчикът трябва да избере, адаптира към условията на проекта и да използва стандарти, методи и инструменти за разработка, съгласувани с клиента, както и да изготви план за изпълнение на работата.

Анализ на изискванията

Анализът на софтуерните изисквания включва определяне на следните характеристики за всеки софтуерен компонент:

• функционалност, включително работни характеристики и работна среда на компонента;
• външни интерфейси;
• спецификации за надеждност и безопасност;
• ергономични изисквания;
• изисквания към използваните данни;
• изисквания за монтаж и приемане;
• изисквания към потребителската документация;
• изисквания за експлоатация и поддръжка.

Архитектурен дизайн

система на високо ниво е да се определят компонентите на нейното оборудване, софтуер и операции, извършвани от персонала, работещ със системата. Архитектурата на системата трябва да отговаря на системните изисквания и приетите стандарти и практики за проектиране.
Проектирането на софтуерна архитектура включва следните задачи (за всеки софтуерен компонент):

• трансформиране на изискванията към софтуера в архитектура, която определя на високо ниво структурата на софтуера и състава на неговите компоненти;
• разработване и документиране на софтуерни интерфейси за софтуерни системи и бази данни;
• разработване на предварителна версия на потребителска документация;
• разработване и документиране на предварителни изисквания за изпитване и план за интегриране на софтуер.

Детайлен дизайн

PS включва следните задачи:

• описание на софтуерните компоненти и интерфейсите между тях на по-ниско ниво, достатъчно за последващото им самостоятелно кодиране и тестване;
• разработване и документиране на подробен дизайн на база данни;
• разработване и документиране на изисквания за тестване и план за тестване на софтуерни компоненти;

Кодиране и тестване

PS покрива следните задачи:

• разработване (кодиране) и документиране на всеки софтуерен компонент и база данни, както и набор от тестови процедури и данни за тяхното тестване;
• тестване на всеки софтуерен компонент и база данни за съответствие с изискванията към тях. Резултатите от изпитването на компонентите трябва да бъдат документирани;
• актуализиране (при необходимост) на потребителска документация;
• актуализация на плана за интегриране на PS.

За всеки от агрегираните компоненти се разработват набори от тестове и процедури за тестване, за да се провери всяко от изискванията за квалификация по време на последващо тестване за квалификация. Изискването за квалификация е набор от критерии или условия, които трябва да бъдат изпълнени, за да се квалифицира даден софтуерен продукт като отговарящ на спецификациите си и готов за използване в полето.

GOST R ISO/IEC 12119-2000 „Информационни технологии. Софтуерни пакети. Изисквания за качество и изпитване"съдържа инструкции, които определят процедурата за изпитване на продукт за съответствие с неговите изисквания за качество. Тестването е трудоемък процес. Според някои експерти процентът
Разпределението на времето между процесите на проектиране – разработка – тестване е в съотношение 40-20-40. В тази връзка системите за автоматизация на тестовете стават широко разпространени. Стандартът IEEE 1209-1992, „Препоръчителна практика за оценка и избор на CASE инструменти“, определя общи изисквания за функционалността на инструментите за автоматизация на тестове.

Системна интеграция

се състои от сглобяване на всички негови компоненти, включително подстанции и оборудване. След интегрирането системата от своя страна се подлага на квалификационни тестове за съответствие с набор от изисквания към нея. В същото време се изготвя и верифицира и пълен комплект документация за системата.

Инсталиране на системата

извършва се от предприемача в съответствие с плана в околната среда и върху оборудването, предвидено в договора. По време на инсталационния процес се проверява функционалността на софтуера и базите данни.

Приемане на системата

осигурява оценка на резултатите от квалификационните тестове на софтуера и системата и документиране на резултатите от оценката, които се извършват от клиента с помощта на разработчика. Разработчикът извършва окончателното прехвърляне на софтуера на клиента в съответствие с договора, като същевременно осигурява необходимото обучение и поддръжка. Нашият курс е насочен основно към подробно разглеждане на първите четири произведения от процеса на разработка на софтуер. Всяка от тези работи ще бъде посветена на отделен раздел, а сега за по-нататъшно представяне е необходимо да кажем няколко думи за моделите на жизнения цикъл на PS.

Модели на жизнения цикъл на софтуера

Модел на жизнения цикъл– структура, която определя последователността на процесите, работите и задачите, изпълнявани през целия жизнен цикъл на една информационна система, както и връзките между тях.

Към днешна дата най-разпространени са два основни модела на жизнения цикъл:

• модел каскада (водопад);
• спираловиден модел.

Каскаден модел

Каскаден моделдемонстрира класически подход към разработването на различни системи в различни области на приложение. За развитието на информационните системи този модел се използва широко през 70-те и първата половина на 80-те години. Това е каскадният модел, който формира основата на GOST серия 34.xxx и стандарта на Министерството на отбраната на САЩ DOD-STD-2167A. Процеси GOST 12207-99 в GOST 34.601-90 „Автоматизирани системи. Етапи на създаване"се наричат ​​етапи и се различават леко по състав.
Каскадният модел осигурява последователна организация на процесите. Освен това преходът към следващия процес става само след като цялата работа по предишния е напълно завършена. Всеки процес завършва с издаването на пълен набор от документация, достатъчна, за да може работата да бъде продължена от друг екип за разработка.

Основният недостатък на каскадния модел е, че грешките и недостатъците на всеки етап се появяват, като правило, на следващите етапи на работа, което води до необходимостта от връщане назад. Според консултантската компания The Standish Group през 1998 г. в САЩ повече от 28% от проектите за корпоративни информационни системи (ИТ проекти) са завършили с неуспех; почти 46% от ИТ проектите са завършени над бюджета (средно 189%); и само 26% от проектите се вписват както в разпределената времева рамка, така и в бюджета.

В допълнение, недостатъците на каскадния модел включват:

• трудности при паралелизиране на работата;
• сложност на управлението на проекти;
• високо ниво на риск и ненадеждна инвестиция (връщането към предишни етапи може да бъде свързано не само с грешки, но и с промени, настъпили в предметната област или в изискванията на клиента по време на разработката. Освен това връщането на проекта за ревизия поради тези причини не гаранция, че тематичната област няма да се промени отново до момента, в който бъде готова следващата версия на проекта.Всъщност това означава, че има възможност процесът на разработка да „върви на цикли“ и системата никога да не достигне точката на Разходите за проекта непрекъснато ще нарастват, а времето за доставка на готовия продукт постоянно се забавя).

Спирален модел

За разлика от каскадата, той включва итеративен процес на разработване на информационна система. Спираловидният модел е предложен в средата на 80-те години от Бари Бьом. Всяко завъртане на спиралата съответства на създаването на фрагмент или версия на софтуерен продукт, където се изясняват целите и характеристиките на проекта, определя се неговото качество и се планира работата за следващия завой на спиралата. При всяка итерация детайлите на проекта се задълбочават и последователно се уточняват и се събират метрични данни, които се използват за оптимизиране на следващите итерации. Механизмите за осигуряване на целостта на документацията обаче стават по-сложни (когато конкретно изискване или определение е дадено в текста само веднъж), което налага използването на специални инструменти.
Основни характеристики на спиралния модел:

• отказ да се определят изисквания и да се определят приоритети на изискванията на потребителите;
• разработване на последователност от прототипи, като се започне с изискванията с най-висок приоритет;
• идентифициране и анализ на риска при всяка итерация;
• Оценяване на резултатите в края на всяка итерация и планиране на следващата итерация.

Бързо разработване на приложения

През 90-те години на 20-ти век на базата на спиралния модел се създава практическа технология, наречена „бърза разработка на приложения” - RAD (Rapid Application Development). В този случай жизненият цикъл се състои от четири етапа:

• анализ на изискванията и планиране,
• дизайн,
• изпълнение,
• изпълнение.

Основни принципи на RAD:

• разработване на приложения в итерации;
• незадължителното завършване на работа на всеки етап от жизнения цикъл на софтуера;
• задължително включване на потребителите в процеса на разработка;
• използването на инструменти за управление на конфигурацията, които улесняват извършването на промени в проекта и поддържането на готовата система;
• използването на прототипи за по-добро разбиране и задоволяване на нуждите на потребителите;
• тестване и развитие на проекта, извършвано едновременно с разработването;
• развитие от малък, добре управляван екип от професионалисти;
• компетентно управление на развитието на системата, ясно планиране и контрол на изпълнението на работата.

В началото на 2001 г. редица водещи експерти в областта на софтуерното инженерство (Мартин Фаулър, Кент Бек и др.) сформираха група, наречена Agile Alliance, за да подкрепят и разработят нов подход към дизайна - „бърза разработка на софтуер“ (Agile Software развитие). Една реализация на този подход е екстремното програмиране (XP).

Принципите на екстремното програмиране са следните:

1. Екипът се състои от трима до десет програмисти. Един или повече клиенти трябва да могат непрекъснато да предоставят постоянен експертен опит.
2. Програмите се разработват на триседмични итерации. Всяка итерация произвежда работещ, тестван код, който може да бъде използван незабавно от клиентите. Завършената система се изпраща на крайните потребители в края на всеки период на пускане, който може да отнеме от две до пет итерации.
3. Единицата от събраните софтуерни изисквания е „потребителска история“, написана на индексна карта, която описва функционалността от гледна точка на потребителя, която може да бъде разработена в една итерация. Клиентите и програмистите планират работа за следващата итерация по следния начин:
   • програмистите изчисляват времето за попълване на всяка карта;
   • клиентите определят приоритети, променят ги и ги преразглеждат, ако е необходимо. Развитието на една история започва с нейното обсъждане между програмисти и клиентски експерт.
4. Програмистите работят по двойки и следват стриктни стандарти за кодиране, които определят в началото на проекта. Те създават модулни тестове за всичко, което пишат, и гарантират, че тези тестове се изпълняват всеки път, когато кодът бъде подложен на задължителен контрол на версиите и управление на конфигурацията.
5. Докато програмистите работят, клиентите посещават програмистите, за да изяснят идеи, да напишат тестове за приемане на системата, които да се изпълняват по време на итерацията, и в края на итерацията да изберат истории, които да внедрят в следващата итерация.
6. Всеки ден екипът провежда оперативни срещи, на които програмистите говорят върху какво работят, какво върви добре и какво има нужда от помощ. В края на всяка итерация има друга среща, на която те оценяват какво е минало добре и върху какво трябва да се работи следващия път. Този списък е публикуван, за да го видят всички, докато работят през следващата итерация.
7. Един човек от екипа е определен като „ментор“. Заедно с членовете на екипа той оценява тяхното използване на основни техники: програмиране и тестване на двойки, ротация на двойки, опростяване на дизайнерските решения, комуникация и др. с цел непрекъснато подобряване на процеса на развитие.

Подходът за бърза разработка на софтуер не е универсален и е приложим само за проекти от определен клас. За да характеризира такива проекти, Алистър Кобърн въвежда два параметъра - критичност и мащаб.
Критичността се определя от последствията, причинени от дефекти в софтуера и може да има едно от четири нива:

• C – дефектите причиняват загуба на удобство;
• D – дефектите причиняват загуба на възстановими средства (материални или финансови);
• E – дефектите причиняват загуба на незаменими средства;
• L – дефектите представляват заплаха за човешкия живот.

Мащабът се определя от броя на разработчиците, участващи в проекта:

• от 1 до 6 души – малък мащаб;
• от 6 до 20 души – среден мащаб;
• над 20 души – голям мащаб.

Според Кобърн бързото разработване на софтуер е приложимо само за малки до средни проекти с ниска критичност (C или D). Това означава, че технологиите RAD и XP са най-подходящи за сравнително малки проекти, разработени за конкретен клиент, и не са приложими за изграждане на сложни изчислителни програми, операционни системи или програми за управление на сложни обекти в реално време, както и системи, от които зависи безопасността от хора.

Единен процес на разработка на софтуер

В момента продължава работата по създаването на някакъв универсален процес на разработка на ИС. През 1999г Служителите на Rational Ivar Jacobson, Gradi Booch и James Rumbaugh публикуваха книгата Unified Software Development Process, която беше преведена на руски и публикувана от Peter Publishing House през 2002 г. Unified Process е опит за комбиниране на водопад и итеративни модели JC.

В същото време жизненият цикъл е разделен на 4 фази:

1. Начало:извършва се първоначална оценка на проекта.
   • създава се опростен модел на случаи на употреба, съдържащ най-критичните случаи на употреба от гледна точка на внедряване;
   • създава се пробна версия на архитектурата, съдържаща най-важните подсистеми;
   • рисковете са идентифицирани и приоритизирани;
   • фазата на проектиране е планирана;
   • грубо се оценява целият проект като цяло;
2. уточнение (разработка):повечето случаи на използване са описани подробно и архитектурата на системата е разработена. В края на фазата на проектиране ръководителят на проекта изчислява ресурсите, необходими за завършване на проекта. Необходимо е да се отговори на въпроса: достатъчно ли са разработени случаите на използване, архитектурата и планът, така че да е възможно да се дадат договорни задължения за извършване на работата и да се пристъпи към изготвяне и подписване на „Технически спецификации“?;
3. строителство– създаване на продукт. В края на тази фаза продуктът включва всички случаи на употреба, които разработчиците и клиентът са решили да включат в текущата версия;
4. изпълнение (преход)– освобождаване на продукта. Бета версията на продукта се тества от тестовия отдел на компанията и едновременно с това се организира пробна експлоатация на системата от потребители. След това разработчиците поправят всички открити грешки и включват някои от предложените подобрения в основна версия, която е готова за широко разпространение.

Всяка фаза на USDP може да включва една или повече итерации, в зависимост от размера на проекта. По време на всяка итерация могат да бъдат изпълнени 5 основни и няколко допълнителни работни нишки.
Основните работни потоци в USDP включват:

• дефиниране на изискванията (RD);
• анализ (А);
• дизайн (P);
• изпълнение (P);
• тестване (T).

Допълнителните работни теми могат да включват:

• работа по осигуряване на качеството (K),
• документация (D),
• управление на проекти (P),
• управление на конфигурацията (CM),
• създаване и управление на инфраструктура (I)
• и други.

Фигура - Модел на жизнения цикъл според унифицирания процес на разработка на софтуер

Изборът на модел на жизнения цикъл до голяма степен зависи от вида и мащаба на разработваната система. За разработването на повечето автоматизирани системи за управление със свободно време е приложим итеративният модел на жизнения цикъл, докато водопадният модел е по-подходящ за системи в реално време. По време на лекциите, когато изучаваме проблемите на дизайна на IS, ще обърнем специално внимание на използването на Unified Modeling Language (UML), а тъй като негови създатели са Grady Booch и James Rumbaugh, ще се обърнем и към идеологията на Unified Development Process.

Фигура - Нормативни документи, съпътстващи процеса на разработка

Поддържане на процесите на жизнения цикъл

Процес за осигуряване на качеството

Процес на осигуряване на качествотопредоставя подходящи гаранции, че софтуерната система и процесите на нейния жизнен цикъл отговарят на определени изисквания и одобрени планове. Качеството на софтуера се разбира като набор от свойства, които характеризират способността на софтуера да удовлетворява определени изисквания.

Фигура - Структура на спомагателни процеси в жизнения цикъл

В контекста на GOST R ISO/IEC 9126-93. "Информационни технологии. Оценка на софтуерни продукти. Характеристики на качеството и насоки за тяхното използване" Характеристика на качеството се разбира като "набор от свойства (атрибути) на софтуерен продукт, чрез които се описва и оценява неговото качество."

Стандартът определя шест изчерпателни характеристики, които описват качеството на софтуера с минимално дублиране:

• функционалност– набор от атрибути, свързани със същността на набора от функции и техните специфични свойства. Функциите са тези, които реализират заявени или очаквани нужди;
• надеждност– набор от атрибути, свързани със способността на софтуера да поддържа нивото си на производителност при определени условия за определен период от време;
• практичност– набор от атрибути, свързани с обхвата на работата, необходима за използване, и индивидуалната оценка на такова използване от определен или предвиден кръг от потребители;
• ефективност– набор от атрибути, свързани с връзката между нивото на качество на работата на софтуера и количеството използвани ресурси при определени условия
• ремонтопригодност– набор от атрибути, свързани с обхвата на работата, необходима за извършване на конкретни промени (модификации);
• мобилност– набор от атрибути, свързани със способността на софтуера да се прехвърля от една среда в друга.

GOST 28195-89 „Оценка на качеството на софтуера. Общи разпоредби"на най-горното, първо ниво, той идентифицира 6 показателя - качествени фактори: надеждност, коректност, лекота на използване, ефективност, гъвкавост и поддръжка. Тези фактори са детайлизирани колективно чрез 19 критерия за качество на второ ниво. По-нататъшното уточняване на показателите за качество е представено от метрики и елементи за оценка, от които има около 240. Всеки от тях се препоръчва да бъде експертно оценен в диапазона от 0 до 1. Предлага се да се избере съставът на използваните фактори, критерии и показатели в зависимост от предназначението, функциите и етапите от жизнения цикъл на софтуера.

Стандартът GOST 28806-90 „Качество на софтуера. Термини и определения"формализирани са общите понятия за програма, софтуерен инструмент, софтуерен продукт и тяхното качество. Дадени са дефиниции на 18-те най-често използвани термина, свързани с оценката на характеристиките на програмата. Изяснени са понятията за основните показатели за качество, дадени в GOST 28195-89.
Въпросът за осигуряване на качеството на софтуера изисква специално внимание, тъй като съгласно Правителството на Руската федерация № 113 от 02.02.1998 г., съответствието с изискванията на международния стандарт за осигуряване и управление на качеството ISO 9000 е предпоставка за получаване на държавна поръчка.
На настоящия етап не е достатъчно да има само методи за оценка на качеството на произвеждания и използван софтуер (изходен контрол), необходимо е да можете да планирате качеството, да го измервате на всички етапи от жизнения цикъл на софтуера и да коригирате. процесът на производство на софтуер за подобряване на качеството.

Серията стандарти ISO 9000 е твърде обща. Всяка компания, която произвежда софтуер и желае да внедри ефективна система за управление на качеството, базирана на стандарти от серия ISO 9000, трябва да вземе предвид спецификата на своята индустрия и да разработи система от показатели за качество, която да отразява реалното въздействие на факторите за качество върху софтуерния продукт. За тази цел много организации са създали отделен, систематичен и всеобхватен процес на проверка - Осигуряване на качеството - който започва със стартирането на проекта, включва проверка и тестване и в идеалния случай се провежда от независима организация. В действителност най-често контролът на качеството се извършва от група колеги на автора на произведението.
Целта на проверката е да се проверят части от проекта за дефекти:

• документация,
• изисквания,
• резултати от анализи,
• дизайн,
• обяви и др.

Уместността на инспекцията се показва чрез сравняване на разходите и откриването и коригирането на дефект по време на инспекция и по време на интеграция според Fagin, M., „Проверки на дизайна и кода за намаляване на грешките в разработката на програми“, IBM Systems Journal. Някои автори смятат тези данни за силно подценени.

Въпросът за откриване на дефекти започна да се приема много по-сериозно, след като американски спътник на стойност няколко милиарда долара, изпратен до Венера, загуби контрол поради печатна грешка в подпрограмата за корекция на траекторията - вместо запетая беше поставена точка и запетая.
Оценката и подобряването на качеството се извършва чрез използване на метрики - количествени характеристики на определени показатели на процеса.

За извършване на проверка са необходими следните стъпки:

1. Процесът на проверка започва с планиране.Разработва се класификация на дефектите по описание, тежест и вид. Извършват се избор на метрики, по които ще се извършва проверката, избор на инструменти за събиране и анализ на получените данни, както и разпределение на ролите между инспекторите:
   • Ръководителят носи отговорност за правилното провеждане на проверката.
   • Коректорът отговаря за дейността на екипа и го насочва в правилната посока. В проверката участва коректорът.
   • Регистраторът отговаря за записването на описанието и класификацията на дефектите, както е обичайно в екипа. В проверката участва и регистраторът.
   • Специализиран инспектор е специалист в определена тясна област, към която принадлежи проверяваният фрагмент.
2. Ако е необходимо, може да се организира семинар за преглед, за да се разбере по-добре предметът на проверката.
3. Провеждане на оглед. Инспекторите проверяват цялата работа на работните си места (например проверка дали проверяваният програмен код отговаря на работния проект). Инспекторите обикновено записват всички дефекти в база данни (напр. достъпна през мрежа) заедно с описания и класификации. Проверяваните части на системата трябва да бъдат логически завършени.
4. Провежда се среща за проверка, по време на която участниците представят своите резултати.
5. Авторът коригира дефектите (фаза на преразглеждане).
6. На последната среща след завършване на работата коректорът и авторът се уверяват, че всички дефекти са коригирани. Това обаче не означава детайлна ревизия на цялата работа от коректор. Всички корекции остават отговорност на автора, който носи отговорност за работата си.
7. Както при други процеси, групата се събира, за да обсъди самия процес на проверка и да реши как може да бъде подобрен.

Компанията поддържа записи на времето, изразходвано за инспекции, и количеството инспектирана работа за по-нататъшно използване при оценка на бъдещи инспекции. При условия на строги времеви ограничения, т.нар система за „настойничество“, при която за всеки член на екипа се грижи негов колега.
За да се вземат предвид всички фактори за контрол на качеството, е удобно да се използват контролни списъци. Такива списъци съдържат елементи, които трябва да бъдат проверени последователно.
Например планът за осигуряване на качеството на софтуера (SQAP) в съответствие със стандарта IEEE 739-1989 определя:

• кой ще отговаря за качеството - физическо лице, ръководител, група, организация и др.;
• каква документация е необходима;
• какви методи ще се използват за осигуряване на качеството - проверка, изпитване и др.;
• какви дейности трябва да се извършват по време на управлението на процеса - срещи, одити, прегледи и др.

Надеждност и безопасност

Една от най-важните характеристики, включени в понятието качество, е свойството надеждност.
Съгласно определението, установено в GOST 13377-75 „Надеждност в технологията. Термини и определения“, надеждността е свойството на обекта да изпълнява определени функции, поддържайки във времето стойностите на установените експлоатационни показатели в определени граници, съответстващи на определени режими и условия на използване, поддръжка, ремонт, съхранение и транспортиране. По този начин надеждността е вътрешно свойство на системата, присъщо по време на нейното създаване и проявяващо се във времето по време на работа и експлоатация.
Надеждността на работата на подстанция се характеризира най-широко със стабилност или способност да работи без повреда и възможност за възстановяване на работно състояние след повреда или повреда.
Мониторингът на надеждността и безопасността на създадените и модифицирани програми трябва да съпътства целия жизнен цикъл на софтуера чрез специално организирана ефективна технологична система за осигуряване на тяхното качество. Проверката и потвърждението на качеството на сложния и критичен софтуер трябва да се осигури чрез сертифициране от сертифицирани сертифицирани лаборатории, ориентирани към проблеми.

Стандартите за информационна сигурност се разделят на две групи:

• стандарти за оценка, предназначени да оценят и класифицират IP и оборудване за сигурност според изискванията за сигурност - стандартът на Министерството на отбраната на САЩ „Критерии за оценка на надеждни компютърни системи“, „Хармонизирани критерии на европейските страни“, международният стандарт „Критерии за оценка на сигурността на информационните технологии”, Ръководни документи на Държавната техническа комисия на Русия;
• спецификации, управляващи различни аспекти на внедряването и използването на инструменти и техники за сигурност, публикувани от Internet Engineering Task Force (IETF) и нейните подразделения, Security Working Group.

Най-значимите стандарти за оценка включват:

• Държавна техническа комисия на Русия. Ръководен документ. Компютърни съоръжения. Защитни стени. Защита срещу неоторизиран достъп до информация. Индикатори за сигурност срещу неоторизиран достъп до информация. – Москва, 1997 г. – класифицира защитните стени в съответствие с нивото на филтриране на потока от данни на седемстепенния референтен модел.
• ISO/IEC 15408:1999 Критерии за оценка на сигурността на информационните технологии.

Втората група включва следните документи:

• X.800 „Архитектура на сигурността за взаимно свързване на отворени системи.“ Подчертани са основните услуги за мрежова сигурност: удостоверяване, контрол на достъпа, гарантиране на поверителност и/или цялост на данните. За реализиране на услуги се предоставят следните механизми за сигурност на мрежата и техните комбинации: криптиране, електронен цифров подпис, контрол на достъпа, контрол на целостта на данните, удостоверяване, добавяне на трафик, контрол на маршрутизиране, нотариална заверка.
• Спецификацията на интернет общността RFC 1510, Kerberos Network Authentication Service (V5), разглежда проблема с удостоверяването в хетерогенна разпределена среда с поддръжка на концепцията за единично влизане в мрежата;
• X.500 „Указателни услуги: Преглед на концепции, модели и услуги“, X.509 „Указателни услуги: рамки за публичен ключ и сертификат за атрибути“.

Процеси на проверка, сертифициране и одит

Проверката, квалификацията и одитът са неразделна част от плана за контрол на качеството на SQAP IEEE 739-1989.
Проверката отговаря на въпроса: „Правим ли планираното на този етап?“ Сертификацията и одитът отговарят на въпроса: „Изгражданият обект отговаря ли на нуждите на клиента?“
Стандартът IEEE 1012-1986 План за проверка и валидиране на софтуер (SVVP) съчетава процесите на сертифициране и одит, наречени валидиране, и определя как се извършват.

По време на процеса на проверка се проверяват следните условия:

• последователност на изискванията към системата и степента, в която се вземат предвид нуждите на потребителите;
• способността на доставчика да отговаря на определени изисквания;
• съответствие на избраните процеси от жизнения цикъл на ПС с условията на договора;
• адекватност на стандартите, процедурите и средата за разработка към процесите от жизнения цикъл на ПС;
• съответствие на проектните спецификации на подстанцията с посочените изисквания;
• коректност на описанието в проектните спецификации на входни и изходни данни, последователност от събития, интерфейси, логика и др.;
• съответствие на кода с проектните спецификации и изисквания;
• възможност за тестване и коректност на кода, съответствието му с приетите стандарти за кодиране;
• правилно интегриране на софтуерни компоненти в системата;
• адекватност, пълнота и последователност на документацията.

Съвместен процес на преглед

Съвместен процес на прегледе предназначен за оценка на състоянието на работата по даден проект и е фокусиран основно върху наблюдението на планирането и управлението на ресурсите, персонала, оборудването и инструментите на проекта.
Оценката се прилага както по време на управлението на проекта, така и по време на техническото изпълнение на проекта и се извършва през целия срок на договора. Този процес може да се извърши от две страни, участващи в договора, като едната страна проверява другата.

Процес на разрешаване на проблеми

Процес на разрешаване на проблемивключва анализ и разрешаване на проблеми (включително открити несъответствия) независимо от техния произход или източник, които са открити по време на разработка, експлоатация, поддръжка или други процеси. Процесът на разрешаване на проблеми е тясно свързан с управлението на риска. Факторите, водещи до провал на проекта, се проявяват под формата на рискове. Управлението на риска се състои от идентифициране, планиране на елиминиране, приоритизиране, елиминиране (или смекчаване).

Причините за появата на рискове могат да бъдат следните:

1. Неясно и/или непълно формулиране на изискванията;
2. Недостатъчно участие на заинтересованите страни в проекта;
3. Лошо планиране – липса на компетентно управление на проекти;
4. Чести промени в изискванията, причинени от промени в обхвата, целите на проекта и други причини;
5. Несъвършенство на използваната технология за проектиране;
6. Липса на знания или умения сред изпълнителите.

Има два начина за предотвратяване на рисковете:

1. извършване на промени в изискванията на проекта, които отстраняват причината за риска;
2. разработване на технологии, които решават проблема, свързан с появата на риск.

По време на процеса на управление на проекта мениджърът трябва от време на време да инициира процеса на идентифициране на рисковете в различни части на проекта, за да състави списък с рискове, които очакват лечение. За всеки риск се определят три стойности: вероятността за възникване на риска; щети, причинени на проекта от този риск, ако възникне такъв; оценка на разходите за елиминиране на риска. Всички стойности използват една и съща скала, например 1 – 10.

Процес на управление на документация и конфигурация

„Управлението на документацията на софтуерния проект изисква значителни организационни усилия, тъй като... документацията е сложна система, подложена на постоянни промени, които могат да се правят едновременно от много хора" (Е. Брауде)

Процесът на документиране осигурява формализирано описание на информацията, създадена по време на жизнения цикъл на PS. Този процес се състои от набор от дейности, които планират, проектират, разработват, произвеждат, редактират, разпространяват и поддържат документи, необходими на всички заинтересовани страни (мениджъри, технически специалисти и потребители на системата).

GOST R ISO/IEC 9294-93. "Информационни технологии. Ръководство за управление на софтуерна документация“ установява препоръки за ефективно управление на софтуерна документация. Целта на стандарта е да подпомогне определянето на стратегия за документиране на софтуера; избор на стандарти за документация; избор на процедури за документиране; определяне на необходимите ресурси; изготвяне на документационни планове.

Управление на документиозначава поддържането му пълно и последователно (някои автори включват управление на конфигурацията тук).

Пълнота на документациятахарактеризира се с броя на стандартите и регулаторните документи, които формират основата на набора от документация, придружаваща определен процес в жизнения цикъл на софтуера.
Съгласуваност на документациятаозначава, че наборът от документи не съдържа вътрешни противоречия. Това се постига чрез поставяне на всяка спецификация само на едно място – това се нарича холистична документация. Целостта на документацията се осигурява чрез използването на хипервръзки.

Всяко изискване трябва да бъде проследимоЗа да се постигне това, на всяко изискване се дава уникален номер, който след това се препраща по време на разработването на концепцията, дизайна и до списъците с методи.

• // изискване 4.3
• // автор
• // версия
• // аргументи
• ...списък с методи...

Частите на проекта включват не само изходния код на програмите, но и цялата документация, включително плана на проекта. По време на своя живот проектите претърпяват промени в две посоки:

• Първо, това е придобиването на нови части,
• Второ, получаване на нови версии на съществуващи части. За правилното проследяване на тези промени се използва специално организиран набор от административни и технически процедури, които се отнасят до процеса на управление на конфигурацията.

За да следите части от проект, трябва да дефинирате техните граници и да идентифицирате конфигурационни елементи (Конфигурационни елементи - CI). Конфигурационните елементи могат да бъдат класове, по-рядко функции, значими масиви от данни - глобални таблици, документация. Отчитането на състоянието на конфигурацията се извършва чрез регистриране на състоянието на софтуерните компоненти, изготвяне на отчети за всички изпълнени и отхвърлени модификации на версии на софтуерните компоненти. Набор от отчети осигурява недвусмислено отразяване на текущото състояние на системата и нейните компоненти, както и поддържане на история на модификациите.
Има специални софтуерни инструменти за управление на конфигурацията (например Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion и др.).

Обикновено системите за управление на конфигурацията отговарят на следните минимални изисквания:

• възможност за дефиниране на конфигурационни елементи;
• съхраняване в базата данни за управление на конфигурацията на пълни хронологии на версии на всеки обект, създаден или променен по време на процеса на разработка на системата (това включва изходен програмен код, библиотеки, изпълними програми, модели, документация, тестове, уеб страници и директории);
• поддръжка на географски отдалечени екипи за разработка;
• отказ от права за модификация, за да се попречи на повече от едно лице да работи върху конфигурационен елемент едновременно;
• контрол на промените, направени във всички системни обекти;
• асемблиране на софтуерни версии от компоненти на проекта.

IEEE разработи стандарта IEEE 828-1990„План за управление на софтуерната конфигурация (SCMP).“ Заглавието на стандарта и пример за план за управление на конфигурацията са дадени в книгата на Ерик Брауде.

Фигура - Нормативни документи на спомагателни процеси от жизнения цикъл

Процеси на жизнения цикъл на организацията

Организационните процеси от жизнения цикъл включват: процес на създаване на инфраструктура, процес на подобряване, процес на обучение, процес на управление.

Фигура - Структура на процесите на жизнения цикъл на организацията

Процес на създаване на инфраструктура

е процес на създаване и предоставяне (поддържане) на инфраструктура, която може да съдържа хардуер и софтуер, инструменти, методологии, стандарти и условия за развитие, експлоатация или поддръжка. На първия етап от създаването на инфраструктура се прави избор на система за поддръжка на дизайна на CASE, избор на език за програмиране и СУБД; организиране на поддържащи услуги - системни администратори, мрежови администратори, администратори на бази данни, секретари и др.
При решаване на проблема с подбора с помощта на литературни източници е необходимо да се анализират възможностите на най-често срещаните инструментални системи, за да се изгради класификация и след това в рамките на определена класификационна група да се определят параметрите, по които ще се извършва подборът.
Самата процедура по подбор включва следните стъпки:

1. Идентифицирани са основните показатели на избраната система, които са значими при проектирането на дадена СКУД, като се вземат предвид нейните характеристики, ограничения, ресурси и др.
2. Всички показатели са обобщени в таблица (виж Таблица 5), в която въз основа на експертни оценки на всеки индикатор е присвоен коефициент на тежест Vi (например от 1 до 10), който характеризира значимостта на този показател в сравнение с други. Сумата от стойностите на всички тегловни коефициенти трябва да бъде равна на горната граница на тегловния коефициент (например 10).
3. Използвайки данни, получени от литературни източници и/или от експерти, за всеки i-ти показател за всяка j-та система се определя степента на полезност Ui,j (от 1 - минимум, до 10 - максимум). Например, система за управление на конфигурацията, която е сравнително скъпа, може да има рейтинг на полезност 1, докато свободно достъпна система би имала рейтинг на полезност 10.
4. За всяка j-та система, която се сравнява, стойността на функцията за оценка се изчислява по формулата: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Въз основа на стойността на функцията за оценка се прави заключение за целесъобразността на използването на определена система в даден проект, като се вземат предвид избраните критерии и посочените ограничения. Системата, за която стойността на функцията за оценка е по-голяма, е най-добрата по отношение на избора измежду сравняваните алтернативи.

Учебен процес

е процес на предоставяне на първоначално и продължаващо обучение на персонала. Поръчването, доставката, разработването, експлоатацията и поддръжката на софтуерни продукти до голяма степен зависят от квалификацията на персонала. Ето защо обучението на персонала трябва да се планира и провежда предварително, за да се подготви за работа по поръчка, доставка, разработване, експлоатация или поддръжка на софтуерен проект.

Процес на подобряване

е процес на установяване, оценяване, измерване, контролиране и подобряване на всеки процес на жизнения цикъл на софтуера. В инженерната практика при разработването на ИС се използват метрики - количествени характеристики на определени показатели.

Най-често използваните показатели са:

• количеството извършена работа, измерено във физически единици (например броя на редовете код);
• време, прекарано на работа;
• процент на дефекти (например брой дефекти на 1000 реда код, брой дефекти на страница с документация и т.н.).

Предварителните или желаните метрични стойности се предвиждат предварително и след това се сравняват с получените резултати.
Тъй като показателите, свързани с дефектността, играят специална роля, ние изброяваме някои от тях:

1. Броят на дефектите на хиляда реда софтуерен код, идентифициран в рамките на 12 седмици след доставката на проекта.
2. Отклонения в графика на всяка фаза: (Действителна продължителност - Планирана продължителност) / Планирана продължителност.
3. Отклонения в себестойността: (Действителна себестойност - Планирана себестойност) / Планирана себестойност.
4. Общо време за проектиране / Общо време за програмиране (според някои оценки трябва да бъде поне 50%).
5. Степента, до която дефектите се появяват и откриват на даден етап, е един от най-простите показатели.

Когато резултатите от откриването на дефекти се сравняват със стандартите на организацията, се оценява целият процес на създаване на системата като цяло, а не само конкретен проект. Натрупаните данни за дефекти на всеки етап се представят в таблица, както е показано например в табл.

Анализ на етап „Формиране на изискванията”.показва, че степента на откриване на дефекти е по-ниска от нормалната на всички етапи от проекта. Повече дефекти в дизайна бяха открити веднага във фазата, когато бяха произведени, и по-малко дефекти бяха открити в по-късните фази. Обикновено това се постига чрез проверка.

Последователността от действия, които трябва да се предприемат през целия жизнен цикъл на проекта, за да се подобри, може да бъде например следната:

1. Идентифицирайте и дефинирайте показатели, които ще бъдат използвани от екипа във всяка фаза, включително:
   • време, изразходвано за проучване, внедряване и анализ на резултатите;
   • размер (например брой редове код);
   • броя на откритите дефекти в модула (например брой редове код) и източника на откриването на дефекта;
   • оценка на качеството по скала от 1 до 10.
2. Документирайте получената информация в SQAP.
3. Събирайте статистика на всяка фаза.
4. Назначете разработчици, отговорни за събирането на данни на всяка фаза, например „отговорник по качеството“.
5. Планирайте прегледи на метрични данни, които ще бъдат полезни в бъдеще. Необходимо е предварително да се реши какви могат да бъдат стойностите на показателите и какви трябва да бъдат. Получените данни ще станат основа за създаване на база данни с фирмени проекти.

Модел на зрялост на организационните способности

Процесът на усъвършенстване на технологията за създаване на софтуер се отразява в стратегическите планове на организацията, нейната структура, използваните технологии, общата социална култура и система за управление.
В началото на 90-те години Американският институт за софтуерно инженерство (SEI на университета Карнеги Мелън (Питсбърг, Пенсилвания, САЩ)) формира модел на технологична зрялост на CMM организациите (Capability Maturity Model). В момента на Запад една развойна компания изпитва значителни трудности при получаване на поръчка, ако не е сертифицирана според CMM.
CMM е методически материал, който определя правилата за формиране на система за управление на създаването и поддържането на софтуер и методите за постепенно и непрекъснато подобряване на производствената култура. Целта на CMM е да предостави на организациите за развитие необходимите инструкции за избор на стратегия за подобряване на качеството на процесите чрез анализиране на степента на тяхната технологична зрялост и факторите, които най-много влияят върху качеството на продуктите. На всяко ниво на SMM се установяват изисквания, чието изпълнение осигурява стабилизиране на най-значимите показатели на процеса.

Процес на управление

Управлението на проекти е свързано с постигането на баланс между разходи, възможности, качество и график. Има няколко аспекта, свързани с процеса на управление на проекта: управление на персонала, планиране, оценка на разходите по проекта.

Управление на персонала

Известни са емпирични данни за определяне на оптималния брой членове на екипа.

Фигура - Зависимост на ефективността на екипа за разработка от неговия състав

Тази зависимост води до необходимостта от използване на йерархични структури на управление

Фигура - Йерархична структура на управление

Въпреки факта, че броят на връзките на всеки служител е задоволителен, те не участват във формулирането на проблема, което нарушава едно от основните изисквания на системния анализ - максималния възможен брой заинтересовани страни трябва да участват в обсъждането на проблема .
Алтернативна схема за организиране на екип от служители се нарича „екип на равни“. В този случай всички членове на екипа са на едно ниво в йерархията и ролите са разпределени между тях. Освен това разпределението на ролите може да се промени след определен период от време. Проблемът с увеличаването на броя на комуникациите в голям проект в този случай се решава чрез подчертаване на ролята на лицето, отговорно за външните комуникации.

В концепцията за екстремно програмиране, предложена от Кент Бек. акцентът е върху непрекъснатата връзка между разработчиците и клиента (и клиентът е направен един от участниците в разработката), желанието за радикално опростяване на процеса на разработка на системата и програмирането по двойки. Освен това при програмирането по двойки разработчиците работят само заедно на един компютър, като се редуват. Това прилага форма на непрекъсната проверка.

Изготвяне на график

Има много стандарти, които описват създаването и поддържането на планове за управление на софтуерни проекти. Препоръчително е да използвате IEEE 1058.1-1987 план за управление на софтуерен проект (SPMP). SPMP предоставя график, който определя как и кога трябва да бъдат завършени различните етапи на проекта. При завършване на всеки следващ етап от проектирането е необходимо графикът да се допълва и коригира. Най-често срещаната форма за представяне на график на проекта е диаграма на Гант.

Фигура - Приблизителен изглед на диаграма на Гант

Препоръчително е планът да включва буферни периоди, когато не са планирани да се изпълняват процеси. График под формата на диаграма на Гант в повечето случаи се изгражда с помощта на Microsoft Office Project.
Процесът на планиране на работата по изпълнението на даден проект в частност и управлението на проекта като цяло е свързан с оценка на разходите и продължителността на проекта. Тази информация е предоставена в раздел 5.4. „Разпределяне на бюджет и ресурси“ SPMP и, в допълнение, предварителна оценка на стойността на проекта може да повлияе на окончателния вариант на договора между клиента и изпълнителя и следователно трябва да се извърши преди подписване на техническото задание.

Оценка на разходите за създаване на ПС

Процесът на оценка на трудоемкостта, като правило, започва едновременно със стартирането на проекта и продължава дори на етапа на писане на програмен код.

Сред най-разпространените методи за оценка на интензивността на труда са следните:

• Алгоритмично моделиране.Методът се основава на анализ на статистически данни за предварително завършени проекти и се определя зависимостта на трудоемкостта на проекта от някакъв количествен показател на софтуерния продукт (обикновено размера на програмния код). Този показател се оценява за даден проект, след което чрез модела се прогнозират бъдещи разходи.
• Експертни оценки.Провежда се проучване на няколко специалисти по технологии за разработка на софтуер, които познават обхвата на приложение на създавания софтуерен продукт. Всеки от тях дава собствена оценка за трудоемкостта на проекта. След това всички оценки се сравняват и обсъждат.
• Оценка по аналогия.Този метод се използва, ако подобни проекти вече са реализирани в дадена област на приложение на създавания софтуер. Методът се основава на сравняване на планирания проект с предишни проекти, които имат подобни характеристики. Той използва експертни данни или съхранени данни за проекта. Експертите изчисляват висока, ниска и най-вероятна оценка на усилията въз основа на разликите между новия проект и предишните проекти.

Всеки метод за оценка има своите силни и слаби страни, така че в момента се използват подходи, които комбинират различни методи.

Процедурата за оценка на трудоемкостта на разработката на софтуер се състои от следните стъпки:

1. оценка на размера на разработвания продукт;
2. оценка на трудоемкостта в човекомесеци или човекочасове;
3. оценка на продължителността на проекта в календарни месеци;
4. оценка на разходите по проекта.

Основните единици за измерване на размера на софтуера са:

• брой редове код (LOC – Lines of Code);
• функционални точки (FP – Function Points).

Методика за оценка на функционалния размер

Методика за оценка на функционалния размер (FP – Functional Points)е да измерва еднакво всички възможности на дадено приложение и да изразява размера на приложението като едно число. След това това число може да се използва за оценка на броя редове код, цената и графика на проекта.
За изчисляване на функционалния размер се определят рангът и сложността на всяка информационна характеристика на системата. Международната група потребители на функционални точки (IFPUG, www.ifpug.org) публикува критерии за идентифициране на информационни характеристики, които са разделени на пет групи:

• – група от логически свързани данни, разпозната от потребителя, която се намира в приложението и се обслужва чрез външни входове.

• – група от логически свързани данни, разпознаваема от потребителя, която се намира в друго приложение и се поддържа от него. Външният файл на дадено приложение е вътрешен логически файл в друго приложение.

• – елементарен процес, който премества данни от външната среда към приложението. Данните могат да идват чрез комуникационни канали, от потребителя на екран за въвеждане или от друго приложение. Данните могат да се използват за актуализиране на вътрешни логически файлове и могат да съдържат както управленска, така и бизнес информация. Контролните данни не трябва да променят вътрешния логически файл (напр. полета за въвеждане на данни, съобщения за грешки, изчислени стойности, бутони).

• – елементарен процес, който премества данни, изчислени в приложение, във външната среда. В допълнение, вътрешните логически файлове могат да бъдат актуализирани по време на този процес. Данните създават отчети или изходни файлове, които се изпращат до други приложения. Отчетите и файловете се създават въз основа на вътрешни логически файлове и външни интерфейсни файлове. Освен това този процес може да използва входни данни, които включват критерии за търсене и параметри, които не се поддържат от вътрешните логически файлове. Входните данни идват отвън, но са временни и не се съхраняват във вътрешен логически файл (например полета с данни в отчети, изчислени стойности, съобщения за грешка).

• – елементарен процес, който работи както с входни, така и с изходни данни, състоящ се от комбинация заявка-отговор, но не свързан с изчисляване на извлечени данни или актуализиране на ILF. Резултатът от него са данни, върнати от вътрешни логически файлове и външни интерфейсни файлове. Входната част на процеса не променя вътрешните логически файлове, а изходната част не носи данни, изчислени от приложението (това е разликата между заявка и изход). Например: елементи за въвеждане - поле за търсене, щракване с мишката; показани елементи – полета, показани на екрана.

ГОСТ Р 56376-2015/IEEE C37.92(2005)

НАЦИОНАЛЕН СТАНДАРТ НА РУСКАТА ФЕДЕРАЦИЯ

Електрически измервателни преобразуватели

АНАЛОГОВИ ВХОДОВЕ НА ЗАЩИТНИ РЕЛЕТА ОТ ЕЛЕКТРОННИ ПРЕОБРАЗУВАТЕЛИ НА НАПРЕЖЕНИЕ И ТОК

Електрически преобразуватели. Аналогови входове към защитни релета от електронни преобразуватели на напрежение и ток

OKS 17.020

Дата на въвеждане 2016-01-01

Предговор

Предговор

1 ИЗГОТВЕНО от Федералното държавно унитарно предприятие "Всеруски научноизследователски институт по метрологична служба" (FSUE "VNIIMS") въз основа на собствен превод на руски език на английската версия на стандарта, посочен в параграф 4

2 ВЪВЕДЕНО от Техническия комитет по стандартизация TC 445 „Метрология на енергийно ефективна икономика“

3 ОДОБРЕНО И ВЛИЗАНО В СИЛА със Заповед на Федералната агенция за техническо регулиране и метрология от 27 март 2015 г. N 192-st

4 Този стандарт е идентичен с международния стандарт IEEE Standard C37.92(2005)* „IEEE Standard for analog inputs to protective relays” from electronic napetost и ток преобразуватели“, IDT).
________________
* Достъп до международни и чуждестранни документи, споменати в текста, можете да получите, като се свържете с отдела за поддръжка на клиенти. - Бележка на производителя на базата данни.


Името на този стандарт е променено спрямо името на посочения международен стандарт, за да го приведе в съответствие с GOST R 1.5-2012 (клауза 3.5).

При прилагането на този стандарт се препоръчва вместо референтни международни стандарти да се използват съответните национални стандарти, информация за които е дадена в допълнителното приложение ДА

5 ПРЕДСТАВЕНО ЗА ПЪРВИ ПЪТ

6 РЕПУБЛИКАЦИЯ. април 2019 г

Правилата за прилагане на този стандарт са установени вЧлен 26 от Федералния закон от 29 юни 2015 г. N 162-FZ „За стандартизацията в Руската федерация“ . Информацията за промените в този стандарт се публикува в годишния (от 1 януари на текущата година) информационен индекс "Национални стандарти", а официалният текст на промените и допълненията се публикува в месечния информационен индекс "Национални стандарти". В случай на преразглеждане (замяна) или отмяна на този стандарт, съответното съобщение ще бъде публикувано в следващия брой на месечния информационен индекс "Национални стандарти". Съответната информация, съобщения и текстове се публикуват и в системата за публична информация - на официалния уебсайт на Федералната агенция за техническо регулиране и метрология в Интернет (www.gost.ru)

1 област на използване

1.1 Общи положения

Този стандарт определя характеристиките на интерфейса между системи за измерване на напрежение или ток, оптични сензори с аналогови изходи и специално проектирани защитни релета или друго оборудване за измерване на подстанции. Тези измервателни системи произвеждат вълни, пропорционални на токовете и напреженията в електрическата мрежа.

Този стандарт също така определя изискванията за допълнителни междинни комбиниращи устройства или мащабиращи усилватели, необходими за добавяне или изваждане на сигнали от изходите на повече от един оптичен сензор за измерване при измерване с едно реле или измервателно устройство.

1.2 Цели

Нормализираният измервателен сигнал между измервателната система и системите за релейна защита е аналогов електрически сигнал с максимална амплитуда ±11,3 V и максимална мощност 3,2 mW.

Пример за измервателна система с аналогов електронен изход е оптична система от напреженови или токови трансформатори с оптико-електронен интерфейс. Фигура 1 показва типична конфигурация на елементи на система за измерване на оптичен ток в подстанция за високо напрежение. В тази конфигурация оптичните сензори на токовите трансформатори са разположени на високопотенциалната шина. В други случаи сензорите могат да бъдат монтирани вътре в силов трансформатор или изолатор. Оптичните сигнали се предават чрез кабели от оптични влакна към земния потенциал, където се преобразуват в мащабирани и нормализирани електрически сигнали, използвани от защитни релета и други интелигентни електронни устройства (IED).

Модулът за оптично-електронно преобразуване обикновено се намира в общата контролна зала на подстанцията, но може да бъде разположен и близо до IED в разпределителната уредба. Този стандарт определя характеристиките на електрическите сигнали между модул за оптично-електронно преобразуване и защитно реле или друго IED, което използва тези сигнали. Интерфейсът между оптичните сензори и преобразуващия модул е ​​собствено техническо решение за изграждане на измервателна система от конкретен производител, което не подлежи на стандартизация. За правилно взаимодействие с външно оборудване е необходимо да се нормализират характеристиките на изхода на модула за преобразуване, входа на клемите за релейна защита и редица други измервателни функции.

Зоната, маркирана на Фигура 1, показва местоположението на интерфейсите, определени от този стандарт.

Фигура 1 - Оптична система за измерване на ток със стандартизиран аналогов интерфейс

2 Нормативни справки

Този стандарт използва нормативни препратки към следните стандарти. За датирани препратки се прилага само цитираното издание. За тези без дата, последното издание (включително всички допълнения и промени).

IEEE Std 525™, Ръководство на IEEE за проектиране и инсталиране на кабелни системи в подстанции
_______________
Публикациите на IEEE могат да бъдат закупени от Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, САЩ (http://standards.ieee.org/).


IEEE Std 1050™, Ръководство на IEEE за заземяване на апаратура и контролно оборудване в генераторни станции

IEEE Std C37.90™, IEEE стандарт за релета и релейни системи, свързани с електроенергийни апарати (Релета и релейни системи, използвани за защита и управление на захранващи устройства)

IEEE Std C37.90.1™, IEEE стандартни тестове за издръжливост на пренапрежение (SWC) за релета и релейни системи, свързани с електрически апарати (Тестове за устойчивост на пренапрежение на релета и релейни системи, използвани за защита и контрол на захранващи апарати)

IEEE Std C37.90.2™, IEEE стандарт за способност за устойчивост на релейни системи към излъчвани електромагнитни смущения от приемо-предаватели

IEEE Std C57.13™, Стандартни изисквания на IEEE за измервателни трансформатори. Публикациите на IEEE са достъпни от Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, САЩ (http://standards.ieee.org/) (Изисквания за инструментален трансформатор)

3 Термини и определения

Следните термини и определения са приети в този стандарт. Термините, които не са представени в този стандарт, могат да бъдат намерени в The Authoritative Dictionary of IEEE Standards, Seventh Edition.

3.1 една относителна единицаедин на единица (съкратено: 1 p.u.): Измерената изходна стойност или изход на измервателна система, която съответства на номиналната първична средноквадратична измерена стойност на напрежението или тока в измервателната верига.

3.2 релеен вход(релеен вход): Аналоговият електронен вход на всеки релеен терминал, измервателен уред, измервателно или контролно устройство или интелигентно електронно устройство, което отговаря на този стандарт.

3.3 измервателна система(сензорна система): Електронен сензор, устройство, оптично-електронен интерфейс или източник на аналогов сигнал, който генерира измерени стойности на напрежение или ток в електрическа мрежа, чийто изход е в съответствие с този стандарт.

4 Общи изисквания

4.1 Свързващи устройства

Изходът на системата за измерване и входът на релето трябва да бъдат оборудвани с общодостъпни стандартни съединители, които могат да издържат на пренапрежения с висок потенциал в съответствие с изискванията на 4.4. Конекторите трябва да са проектирани така, че да позволяват лесно свързване и завършване на кабела. Винтовите клеми са предпочитаното решение. Всеки вход или изход включва двойка сигнални клеми, обозначени съгласно 4.3. Доставчикът на оборудване трябва да осигури допълнителни незаземени клеми или средства за свързване на екрани в съответствие с точка 7.

4.2 Галванична изолация от земята

И двата изходни терминала на измервателната система и всеки релеен вход трябва да бъдат изолирани от защитно заземяване или заземяване на рамката, когато са изложени на постоянен ток или честотни сигнали. Разрешеният капацитет между който и да е терминал и земята не трябва да надвишава 0,01 µF.

4.3 Маркировки за полярност и устойчивост на обратна полярност

Интерфейсите трябва да имат маркировки за полярност, състоящи се от традиционните "cts" и "vts". Вижте IEEE Std C57.13.
_______________
Информацията за връзката е предоставена в раздел 2.


За небалансиран изход на измервателна система, клемата за изход на сигнала трябва да бъде маркирана с подходяща маркировка за полярност или като вторична клема X1 на традиционен измервателен трансформатор.

Когато първичният ток на електрическата мрежа се преобразува в напрежение на изхода на измервателната система, тогава положителната стойност на напрежението на клемата със съответния знак за полярност трябва да съответства на посоката на тока на първичната клема със съответния поляритет знак.

Всяка измервателна система и всяко реле трябва да има етикет на производителя, който посочва, че се предлага само с необратима полярност или че може да се използва с обратна полярност.

Реверсивната полярност се отнася до напълно изолиран или балансиран вход или изход, който може да бъде свързан с всяка полярност, както е посочено.

Необратимият поляритет се отнася до едножилен или небалансиран вход или изход (където един проводник се използва за пренасяне на сигнала, а другият проводник служи като заземяващ проводник, като например коаксиален кабел), което включва свързване на сигналния проводник само към сигналната клема и общия проводник само към общата клема.

Обикновено единичен сигнал на изхода на измервателна система се разклонява на няколко релета или устройства, които използват този сигнал. При осъществяването на тази връзка трябва да се вземе предвид следното:

- ако един или повече входове на няколко релета имат необратима полярност, потребителят не винаги ще може да получи необходимата полярна връзка към всички устройства, дори ако източникът има обратна полярност.

Забележка - Вътрешни или софтуерни настройки на конкретно защитно реле може да променят полярността на входа;


- ако се използва обратима полярност за всеки вход на няколко релета, тогава всяко реле може да бъде свързано с необходимата полярност, дори ако изходът от източника не е необратим.

Това увеличава гъвкавостта при използване на релета и други устройства с входове с обратна полярност, използвайки аналоговите изходи на електронната измервателна система.

Симетричните или обратими изходни клеми трябва да са симетрични по отношение на земята.

4.4 Допълнителни изходи на измервателни системи

4.4.1 Изход за предупреждение

Това е допълнителен сигнал, предназначен да сигнализира за всеки проблем в измервателната система, който трябва да уведоми за всяка неизправност, повреда или влошаване на характеристиките, т.е. уведомява за необходимостта от поддръжка или ремонт. Например, дефектно захранване на измервателната система може да доведе до такъв сигнал.

Този изход трябва да бъде контакт тип "C", без потенциал и определен от производителя на измервателната система. При нормални условия на работа намотката (бобината) на релето трябва винаги да е под напрежение, за да генерира аларма при загуба на захранване, както и при повреда в измервателната система.

4.4.2 Изходен сигнал за коректността на предадените данни

Това е задължителен сигнал, който трябва да отразява резултатите от всички вътрешни проверки при самодиагностика на електрониката на измервателната система, наличието на който означава, че има проблем с аналоговия изходен сигнал и това може да доведе до неправилна работа на свързани релета. Използва се и за индикация при включване и/или изключване, при което изходният сигнал на измервателната система има големи грешки. Свързаните релета може погрешно да използват този сигнал, за да попречат на изключването.

Този резултат може да приеме една или и двете от следните форми:

- тип контакт "А", безпотенциален и определен от производителя на измервателната система. При нормални, правилни условия на работа, намотката на релето (бобината) трябва винаги да бъде захранена, за да осигури сигнал или да осигури защитно заключване за неправилен изходен сигнал. Контактът трябва да бъде осъществен в съответствие с IEEE Std C37.90. Закъснението при блокиране на изхода в случай на тригерен ефект (отскачане на контакт) не трябва да надвишава 12 ms;

- TTL логическото ниво (0 до 5 V) има реакция от 1 ms или по-бърза (вижте 5.8). В този случай логическото ниво (5 V) означава коректността на предадените данни.

4.5 Тест за електромагнитна съвместимост

Следните видове тестове се използват за проверка на изходите на системата за измерване, съвместимите аналогови електронни релейни входове и изходи, които сигнализират за повреда на системата за измерване и коректността на предадените данни, както и за проверка на входовете на релето и междинните устройства, описани в клауза 6. Този тест е допълнение към други тестове за способността на релетата и електрониката на измервателната система да издържат на условията на околната електромагнитна среда, изискванията за които са дадени в съответните стандарти.

4.5.1 Диелектрични тестове

Тези тестове се провеждат в съответствие с методите за диелектрични тестове, описани в IEEE Std C37.90. Тестовото напрежение се прилага само в общ режим между всяка двойка входни или изходни клеми и защитното заземяване или заземяването на рамката. Сигналните вериги до 50 V се тестват при по-ниското изпитвателно напрежение на диелектрика съгласно IEEE Std C37.90.

5.1.1 Описание на сигнала за система за измерване на ток

Динамичен диапазон: 0,05 до 40 номинал;

Номинално изходно ниво (или 1 p.u.): 200 mV (rms);

Максимална моментна стойност: 0,200x40x1,414 = 11,3 V (пикова).

Амплитудните и фазовите грешки са максималното отклонение от действителната стойност на мащабирания първичен сигнал при 50 или 60 Hz.

Таблица 1 - Описание на сигнала за текущата измервателна система

Общата стойност на коефициента на нелинейно изкривяване трябва да бъде по-малка или равна на амплитудната грешка.

Съотношението сигнал/шум трябва да бъде по-голямо или равно на 54 dB със сигнал, по-голям от 0,1 p.u. Измерването трябва да се извърши на сигнал с мощностна честота и честотната лента на измерване на шума трябва да бъде в рамките на 120 Hz.

Системата за измерване на ток може да бъде снабдена с допълнителен изход номинално 2 Vrms при 1 p.u., с максимална изходна стойност от 4 p.u. Този изход е предназначен за онези приложения, където изискваната точност на измерване е по-висока от общоприетата. За приложения за попечителско прехвърляне производителят на сензор трябва отделно да демонстрира съответствие с подходящ стандарт за точност, като IEEE Std C57.13 или части от него.

5.1.2 Описание на сигнала за системи за измерване на напрежение

Динамичен диапазон от 0,05 до 2,0 пъти номиналната стойност.

Номинално изходно ниво (или 1 p.u.): 4 V (rms).

Максимална мощност: 4,0 x 2,0 x 1,414 = 11,3 V (пикова).

Амплитудните и фазовите грешки са максималното отклонение от стойността на действителния мащабиран първичен сигнал при 50 или 60 Hz.

Таблица 2 - Описание на сигнала на системата за измерване на напрежението

Общата стойност на коефициента на нелинейно изкривяване трябва да бъде по-малка или равна на стойността на грешката.

Съотношението сигнал/шум трябва да бъде по-голямо или равно на 70 dB със сигнал, по-голям от 0,85 p.u. Измерванията трябва да се извършват с използване на сигнал с мощност и честотна лента на измерване на шума от най-малко 120 Hz.

Това се отнася за защитни релета или измервателни приложения, за които посочената по-горе точност е приемлива.

За приложения за прехвърляне на попечителство производителят на сензора трябва отделно да демонстрира съответствие със съответните стандарти за точност, като IEEE Std C57.13 или части от него.

5.2 Фазова корекция

За постигане на по-висока точност, производителят на измервателната система може да посочи стойност на фазова корекция при честота на захранване, чиято стойност се въвежда като корекция на всички стойности, за да се получи по-висока точност от посочената по-горе.

ЗАБЕЛЕЖКА: Това не премахва необходимостта измервателната система да отговаря на ъгловите грешки, споменати по-горе.

5.3 Номинален товар

Точността на измервателната система трябва да отговаря на изискванията на този стандарт при свързване на товар от около 5 kOhm и капацитивен товар до 5 nF. Един изход на една измервателна система може да бъде свързан към няколко релета или други измервателни устройства паралелно. Релето или друго свързано устройство трябва да има входен импеданс най-малко 50 kOhm, но не повече от 200 kOhm.

5.4 Намаляване на общ режим

Затихването в общ режим за измервателните входове и изходи трябва да бъде по-голямо от 86 dB при 50 или 60 Hz за сигнал в общ режим до ±50 V. Тази стойност е определена за смущения на напрежението от 20 V на входа на системата за измерване на ток , при която текущата стойност е 0,5 p.u., и когато общият тип шум е по-малък от 10% от измереното ниво на сигнала.

5.5 Отклонение на изходния сигнал от нулевата зона

Стационарното отклонение на изходния сигнал от нулевата зона (отместване на DC компонента на изходния сигнал) трябва да бъде по-малко от 3 mV. Това се отнася до изискванията за електрониката за постоянен ток на изхода на усилвателя, но не се отнася за експоненциалното затихване на "DC отместване" на сигналите за ток на повреда.

Стационарното отклонение на изходния сигнал от нулевата зона на усилвателя трябва да бъде по-малко от 3 mV. Това се отнася до електронни характеристики с компонент на дълъг постоянен ток на изхода на усилвателя, но не е свързано с експоненциалното затихване на "изместването на постояннотоковия сигнал" за сигнали за ток на късо съединение.

5.6 Широчина на честотната лента и преходен отговор

Доставчикът на измервателната система трябва да посочи честотната характеристика. Отклонението на честотата на захранването (мрежовата честота), посочено в 5.1, трябва да бъде между 45 и 65 Hz. Реакцията трябва да бъде поне 0 до -1 dB до 3 kHz и 0 до -3 dB до 5 kHz. Долната гранична честота (ако има такава) трябва да бъде настроена така, че системата да може да изпълни следното изискване за постоянна реакция на отместване на сигнала.

За пълно компенсиране на реакцията на експоненциално затихване на първичния ток ("постоянно изместване на сигнала") със стойност от 20 p.u. Моментната грешка на коефициента на мащабиране не трябва да надвишава 10 % за която и да е времева константа до 100 ms.

За първичното напрежение преходният отговор се определя от отговора на стъпков импулс, т.е. промяна на стойността на формата на импулса в диапазона до нула, докато сигналът на изхода на измервателната система трябва да намалее до ниво под 10% от първоначалната си стойност за време от 4 ms и да падне под 10% едва след този път.

Някои клиенти може да изискват работа на системата за честоти в диапазона от 65 до 75 Hz с намалени изисквания за точност. Препоръчва се доставчикът на измервателната система да определи изискванията към техническите характеристики на нейната работа в този честотен диапазон.

5.7 Настройка на откриване на сигнал за грешка

Изходът на интерфейса на измервателната система трябва да бъде фиксиран на нула, когато бъде открита вътрешна повреда, за да се избегне причиняването на сериозни проблеми или фалшиви аларми. Това се осигурява чрез резервно захранване на измервателната система или чрез изключване при преходни условия. Времето от идентифициране на проблем до отстраняването му трябва да бъде не повече от 0,2 ms.

Обикновено идентифицирането на проблема се извършва по същия метод като за откриване на грешки, както се прави по време на проверката за коректност за предаване на данни от изхода, описана в 4.4.2.

5.8 Описание на сигнала за коректност на предаваните данни

Незадължителният сигнал, предаващ 4.4.2 информация за валидност на данните, трябва да бъде сигнал с ниво на TTL (0 или 5 V), изолиран от защитно заземяване и предназначен да бъде предаван, използвайки същия метод на свързване, както при предаването на сигнали на аналогова измервателна система (виж раздел 7). Логическа единица от 3,0 до 5,5 V информира за наличието на коректни данни на изхода на измервателната система. Логическа нула в диапазона от 0 до 0,5 V трябва да означава грешка в данните на изхода на измервателната система. Изходът на този незадължителен сигнал трябва да може да доставя напрежения в рамките на определените спецификации в импеданс на натоварване от 200 ома или повече. Закъснението от задействащото събитие до промяната в изходното състояние не трябва да надвишава 1 ms.

Входните вериги в защитното реле, за да получат този сигнал, трябва да бъдат изолирани от защитно заземяване и да имат входно съпротивление повече от 2 kOhm. В този случай само сигнали с ниво над 2,5 V трябва да се възприемат като логическа единица.

6 Междинни устройства

6.1 Цел

Междинните устройства могат да се използват за създаване на сумата или разликата на отделните изходи на измервателните системи. Те могат да се използват и за изолиране на входовете на различни видове релета или измервателни уреди, свързани към един изход на измервателната система. Междинните устройства могат да имат единично усилване или могат да включват мащабиране на отделни входове за промяна на усилването на измервателната система.

Междинните устройства могат също да се използват за съпоставяне на изходите на традиционните измервателни трансформатори с изходите на измервателна електронна система. Дефинираните в този раздел експлоатационни изисквания се отнасят само за междинни устройства с аналогови електронни изходи.

6.2 Изисквания за производителност на междинните устройства

Точността, честотната лента и съотношението сигнал/шум на междинните устройства трябва да са много по-добри от самите измервателни системи. По-долу са изискванията за междинните устройства.

Таблица 3 - Изисквания за междинни характеристики на устройството

Изискванията за производителност на усилвателя трябва да бъдат изпълнени заедно с входните и изходните конектори. Изискванията за производителност трябва да се определят при единично усилване. Производителят трябва да посочи работните характеристики при усилване, различно от единица.

6.3 Други изисквания към междинните устройства

Междинните устройства трябва да отговарят на всички други изисквания на раздели 4 и 5, но не и на тези, посочени в 6.2. Те трябва да отговарят на изискванията в диапазона от условия на работа, транспортиране и съхранение, посочени в IEEE Std C37.90.

7 Инструкции за монтаж на междинни устройства

Фигури 2, 3 и 4 показват примери за свързване за единични и множество източници и товари. Те са представени, за да илюстрират подходящи връзки за разстояния, по-малки от 50 m между измервателната система и най-отдалечения релеен вход. Екранираните проводници с усукана двойка обикновено се инсталират в общия център за управление на подстанцията, където разликата между нулевите потенциали на свързаните системи при възникване на късо съединение не надвишава 20 V. Проводници с напречно сечение от 24 AWG и по-големи са доста приемливи за тези цели. Ако няколко усукани двойки са затворени в един общ екран, тогава взаимното влияние между каналите по време на диференциално свързване не трябва да надвишава ниво от 70 dB.

Трябва да обърнете внимание на следните основни характеристики, общи за всички чертежи:

- кабелната връзка предполага, че оборудването е преминало теста за отхвърляне на общ режим, както е посочено в раздел 4, и коефициентът на отхвърляне на общ режим, както е посочено в раздел 5, е известен;

- нито един от усуканите сигнални проводници не е заземен в нито една точка;

- само единият край на екрана, обикновено страната на релето или приемащият край на връзката, е директно заземен. За множество системи за измерване и/или множество релейни инсталации се дефинира една точка на заземяване на екрана. Това заземяване осигурява само електростатично екраниране, но не и магнитно екраниране при захранваща честота. За да осигурят само една точка на заземяване за множество релета, екраните могат да бъдат верижно свързани, като същевременно осигуряват една точка на заземяване;

- имайте предвид, че всяка система за измерване или реле с еднопосочен или необратим поляритет, която има вътрешна връзка към общия или неполяризиран изход на интерфейса за безопасно заземяване, може да причини проблеми със сигнала или да компрометира безопасността на изолацията на други устройства;

Фигура 2 - Една измервателна система и един релеен вход

Фигура 3 - Една измервателна система с множество релейни входове

Фигура 4 - Множество измервателни системи и междинно устройство

- За да се осигури подобрено високочестотно електромагнитно екраниране, допълнителни 10 nF керамични дискови кондензатори могат да бъдат инсталирани между екрана и земята във всяка незаземена точка на свързване на екрана. Те могат да бъдат инсталирани от потребителя или разположени в оборудването на производителя. Имайте предвид, че инсталирането на такива кондензатори обикновено е приемливо за къси контролни кабели, но представлява проблем за високочестотно екраниране за по-дълги контролни кабели.

За свързване на комутационно оборудване, разположено във външна разпределителна уредба, където няма благоприятни условия за висококачествено високочестотно електромагнитно екраниране, клиентът трябва по-внимателно да проучи схемите за екраниране, заземяването на екраните и изолацията на елементите. Вижте IEEE Std 525.

В този случай е необходим допълнителен надежден външен екран, заземен в двата края, за да се елиминира влиянието на токовете, индуцирани от магнитни и електромагнитни полета с промишлена честота в екрани с усукана двойка върху измервателни сигнали с ниско ниво. В този случай електронният източник на сигнал ще трябва да бъде изолиран от земния потенциал.

Приложение A (за справка). Безопасна употреба

Приложение А
(информативен)

Съществуват значителни разлики в работата между съвременните аналогови електронни измервателни системи и традиционните пасивни измервателни системи с измервателни трансформатори.

Нови и особено важни за приложението им са характеристики в нискочестотната област, преходни процеси при включване и изключване на системата, реакция на преходни състояния на електрическата мрежа, фазови закъснения, реакция на преходни състояния на електрическата мрежа, фазови закъснения, изход товароносимост, повреди и аварийни сигнали, калибриране. Контрастът между аналоговия и цифровия интерфейс е предмет на обсъждане.

A.1 Амплитудно-честотна характеристика в нискочестотната област

Традиционните преобразуватели с желязна сърцевина реагират на ниски честоти, докато устройството се насити с променлив ток над определена граница за волта на херц. Тоест само много ниски нива на сигнала се възпроизвеждат от такива преобразуватели без изкривяване при ниски честоти. Насищането възниква внезапно по време на текущия полупериод, като изходният сигнал изчезва напълно и внезапно, докато полярността не бъде обърната. Аналоговите електронни измервателни системи, посочени в този стандарт, от друга страна, може да имат нискочестотно спадане или да пропуснат изцяло DC компонента на сигнала. Включването на нискочестотен филтър може да доведе до различни и непредвидими преходни процеси, за които релетата и другите високоскоростни измервателни системи не са предназначени. Специфичните явления включват: изместване на референтната точка, неточен отговор на експоненциално затихващи преходни характеристики (поява на постоянно преднапрежение) и нискочестотен затихващ осцилационен процес като отговор на входни преходни характеристики.

Проектантите на релета трябва да оценят ефекта на нискочестотните компоненти върху алгоритмите за измерване и особено тези, които са специално проектирани за работа от DC компенсации, често срещани при токове на повреда. Точността, посочена в 5.6, включва изискването за работа с постоянен ток.

A.3 Реакция на стъпка

Преходният режим или преходният отговор може да варира значително в зависимост от честотната лента, въпреки че е тясно свързан със съответните високочестотни филтриращи характеристики в електрониката на измервателната система. Късите съединения и превключването водят до положително или отрицателно превишаване на изхода и евентуално затихване на високочестотни трептения.

Потребителят трябва да провери реакцията на релето към тези изкривявания. Моля, имайте предвид, че положителните или отрицателните пренапрежения могат да доведат до неправилна работа на високоскоростните релета.

Също така е необходимо да се знае, че в широколентовите високоскоростни диференциални вериги има разлики в преносните характеристики на измервателни системи от различни поколения, от различни производители, което също може да доведе до неправилни и различни изходни стойности и да доведе до намалена надеждност или дори фалшиви положителни резултати.

Проблеми може да не възникнат, ако граничната честота на филтъра против нагласяне (филтър против нагласяне - за елиминиране на ефектите на нагласяне (по време на вземане на проби) на свързаното реле за защита на микропроцесора е три или повече пъти по-ниска от честотната лента на измервателната система и съществуващите честотни изкривявания .

Трябва да се отбележи, че 5.6 включва преходните характеристики на измервателната система, определени от реакцията на стъпков импулс.

A.4 Фазово забавяне

Времезакъснението на измерената първична стойност в електрическата мрежа преди измервателната система да представи тази стойност на свързаните релейни системи може да бъде кратко в сравнение с интервала от време на измерване и на пръв поглед незначително. Това обаче може да бъде сериозен проблем за всяко реле или измервателна система, която сравнява две величини, идващи от два различни типа измервателни системи. Сравнението на диференциалния ток е добър пример за това, когато високоскоростните вериги са чувствителни към разликата във фазовите закъснения между две измервателни системи. Релетата за разстояние и посоката, и по-специално търговските измервателни уреди за енергия, могат дори да имат проблеми, защото трябва точно да съответстват на връзките между напрежения и токове.

Системите за измерване на напрежението използват методи, различни от измерването на ток, без да гарантират, че закъсненията при измерване на първичния ток и сигналите за напрежение са идентични.

Раздел 5.2 описва допълнителна опция за избор на фазова корекция, предоставена от производителя.

A.5 Товароносимост

Режимът на изходно напрежение на измервателната система трябва да може да доставя ток на целия свързан товар, разглеждан като паралелна група от входове. Увеличаването на натоварването може да доведе до влошаване на точността на генериране на сигнал и се определя от импеданса на източника, но изходните сигнали все още могат да се използват в много приложения. Може да се направи паралел с влиянието на товарите върху традиционните токови и напреженови трансформатори (CTs и VTs).

A.6 Неизправности и аларми

Проектантите трябва да могат да определят режима на повреда на електронните компоненти по-специално и да оценят въздействието на събития като повреда, счупвания или пукнатини в оптичния кабел. Невъзможно е да се избегнат всички проблеми, но има допълнителни мерки за безопасност за предотвратяване на някои от тях.

В това отношение дизайнерът може да помогне, като предостави данни за високата производителност на системите за самоконтрол, които могат да открият затихване или потискане на изходния сигнал. Обърнете внимание, че затихващият изходен сигнал може да попречи на релето за диференциална защита, което може да доведе до фалшиво изключване, освен ако не се използва допълнителен сигнал за невалидни данни, за да се попречи на изключване. Загубата на напрежение на дистанционното реле ще причини фалшива работа или ще доведе до загуба на потенциална логика (ако се използва такава), което значително ще ограничи възможностите за защита.

Способността на системата за измерване да диагностицира самостоятелно незначителни проблеми и да задейства аларми, които не са спешни, без потискане или блокиране, дава на персонала по поддръжката перспективата за разрешаване на проблем, преди той да причини негативни последици. Порт за комуникация на данни, който може да докладва определена диагностика чрез модем или WAN порт, увеличава вероятността техниците за ремонт да пристигнат с правилните части и оборудване.

A.7 Калибриране

Доставчикът е длъжен да обучи потребителя на методите, по които се извършва първоначалното калибриране на измервателната система и впоследствие се поддържа. По-специално, уверете се, че доставеното IED има характеристиките, които може да са необходими за извършване на процедурата за калибриране.

Доставчикът на измервателна система трябва да инструктира клиента какво да прави с калибрирането на системата при смяна на дефектен електронен модул за преобразуване.

A.8 Цифрови интерфейси

Този стандарт обхваща само аналогови интерфейси от ниско ниво, включително тези, вградени в големи системи, които имат интерфейси за цифрови данни и където оперативната съвместимост за аналоговите интерфейси е важна както за производителите, така и за потребителите.

Цифровите интерфейси изискват спецификация на процесите на вземане на проби, производителността и многослойните слоеве на комуникационния протокол за комуникация между измервателната система и релето. Интерфейси за цифрови данни за предоставяне на информация за електрическата мрежа са предоставени в IEC 61850-9-1, IEC 61850-9-2, IEC 60044-7 и IEC 60044-8.

Приложение ДА (задължително). Информация за съответствието на референтните международни стандарти с националните стандарти

Приложение ДА
(задължително)

Таблица DA.1

Библиография

IEEE P1331 Проект 8.3, април 1999 г.: Стандарт за пробна употреба за нискоенергийни аналогови сигнални входове към защитно релейно предаване

Текст на електронен документ
изготвен от Кодекс АД и проверен спрямо:
официална публикация
М.: Стандартинформ, 2019

Лекция 3

Жизнен цикъл на софтуера

Основни понятия, включени в дефинирането на жизнения цикъл

Процес на развитие

Процес на развитие

10. Анализ на системните изисквания

11. Анализ на софтуерните изисквания

12. Проектиране на софтуерна архитектура

13. Подробен дизайн на софтуера (работен план за разработка на софтуер)

14. Софтуерното кодиране и тестване включва решаването на следните задачи:

15. Системна интеграция

16. Тестване на квалификацията на софтуера

17. Инсталиране и приемане на софтуер

18. Операция на софтуера

19. Софтуерна поддръжка (по стандарт IEEE – 90)

20. Поддържащи процеси от жизнения цикъл на софтуера

21. Процес на документиране

22. Управление на конфигурацията

23. Процес на осигуряване на качеството

24. Проверка

25. Сертифициране

26. Организационни процеси на жизнения цикъл на софтуера

27. Групи ESPD стандарти

28. Списък на ЕСПД документи

29. Предимства от използването на ESPD стандарти

30. Недостатъци на ESPD стандартите

31. Стандарт GOST 34.601-90: етапи и етапи на създаване на автоматизирана система

32.