Опытная эксплуатация – это эксплуатация определённого количества изделий по установленной программе. Цель опытной эксплуатации – совершенствование процесса эксплуатации с учётом реальных условий использования, контроля в этих условиях характеристик изделия и накопления опыта применения.
Опытная эксплуатация может быть направлена на совершенствование конструкции, технических, эксплуатационных и ремонтных характеристик изделия, корректировку эксплуатационной документации, сокращение сроков изучения новой техники и распространение полученного опыта на все изделия данного типа.
В отдельных отраслях промышленности и направлениях деятельности порядок опытной эксплуатации новых изделий устанавливается по нормам и правилам данной отрасли (ведомства). Чаще всего это один из этапов испытаний и внедрения изделия.
Как этап определённой стадии жизненного цикла изделия опытная эксплуатация рассматривается в стандартах на автоматизированные системы (АС). В соответствии с ГОСТ 34.601-90 «КСАС. Автоматизированные системы. Стадии создания» опытная эксплуатация АС является этапом работ на стадии ввода системы в действие на объекте автоматизации.
Начинают опытную эксплуатацию после того, как проведены подготовка объекта, поставка комплекса технических средств и программ, информационных изделий, закончены строительно-монтажные и пусконаладочные работы, прошли предварительные испытания системы и устранены замечания, выявленные при их проведении.
Опытная эксплуатация АС проводится для комплексной проверки всех составных частей, готовности информационной базы, отладки процесса сбора и обработки информации, обучения персонала работе с системой в реальных условиях, проверки полноты и корректности указаний эксплуатационной документации.
Опытная эксплуатация систем осуществляется на основе полного объёма реальной информации в установленных режимах.
В соответствии с требованиями ГОСТ 34.603-92 «Информационная технология. Виды испытаний Автоматизированных систем» опытную эксплуатацию проводят по программе, разработанной на стадии создания рабочей документации.
Программа опытной эксплуатации должна содержать следующую информацию:
- условия и порядок работы АС и её составных частей;
- продолжительность этапа;
- порядок устранения выявленных недостатков.
Все сведения о продолжительности функционирования, отказах, сбоях и аварийных ситуациях, возникших в процессе опытной эксплуатации, должны быть зафиксированы в журнале опытной эксплуатации. Также в данный журнал должны быть занесены все сведения об изменении параметров объекта автоматизации, о корректировке документации и доработке программ, о наладке технических средств, произошедших в ходе данного этапа.
Персонал, осуществляющий процедуры опытной эксплуатации, может вносить в журнал замечания по удобству работы с системой. Форма журнала опытной эксплуатации предоставляется разработчиком и должна обеспечивать возможность рациональной и удобной фиксации необходимых сведений и значений.
Важно!
По результатам опытной эксплуатации принимают решение о возможности предъявления частей АС и системы в целом на приёмочные испытания – оформляется акт о завершении опытной эксплуатации и допуске системы к приёмочным испытаниям.
Наши преимущества Большой накопленный опыт Профессиональное и быстрое оформление технической документации по стандартам. Проекты любой сложности Разрабатываем документацию как на простые изделия, так и на сложные большие системы. Ответственный подход к работе Ценим время и деньги клиента, выполняем взятые обязательства. Полный цикл разработки документации Изделие возможно изготовить на любом современном производстве. Наши клиенты
ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд. 3.)
|
УДК 65.015.13.011.66:006.354 |
Группа П87 |
Содержание
Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р
|
Информационная технология |
ГОСТ 34.603-92 |
ВИДЫ ИСПЫТАНИЙ АВТОМАТИЗИРОВАННЫХ СИСТЕМ |
|
|
Information technology. Types tests automated systems ОКСТУ 0034 |
Дата введения
с 01.01.93г.
1. Общие положения 2. Предварительные испытания 2.2. Автономные испытания 2.3. Комплексные испытания 3. Опытная эксплуатация 4. Приемочные испытания
Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т. п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее — организациях).
Стандарт устанавливает виды испытаний АС и общие требования к их проведению.
Термины, применяемые в настоящем стандарте, и их определения — по ГОСТ 34.003.
Требования настоящего стандарта, кроме пп. 2.2.4, 4.4, 4.5, являются обязательными, требования пп. 2.2.4, 4.4, 4.5 — рекомендуемые.
ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Испытания АС проводят на стадии «Ввода в действие» по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ).
1.2. Испытания АС представляют собой процесс проверки выполнения заданных функций системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик системы, выявления и устранения недостатков в действиях системы, в разработанной документации.
1.3. Для АС устанавливают следующие основные виды испытаний:
- 1) предварительные;
- 2) опытная эксплуатация;
- 3) приемочные.
Примечания:
1. Допускается дополнительно проведение других видов испытаний АС ч их частей.
2. Допускается классификация приемочных испытаний в зависимости от статуса приемочной комиссии (состав членов комиссии и уровень его утверждения).
3. Виды испытаний и статус приемочной комиссии устанавливают в договоре и (или) ТЗ.
1.4. В зависимости от взаимосвязей испытываемых в АС объектов испытания могут быть автономные или комплексные.
Автономные испытания охватывают части АС. Их проводят по мере готовности частей АС к сдаче в опытную эксплуатацию.
Комплексные испытания проводят для групп, взаимосвязанных частей АС или для АС в целом.
1.5. Для планирования проведения всех видов испытаний разрабатывают документ «Программа и методика испытаний». Разработчик документа устанавливается в договоре или ТЗ.
1.6. Программа и методика испытаний должны устанавливать необходимый и достаточный объем испытаний, обеспечивающий. заданную достоверность получаемых результатов.
1.7. Программа и методика испытаний может разрабатываться на AC в целом, на части АС. В качестве приложения могут включаться тесты (контрольные примеры).
1.8. Предварительные испытания АС проводят для определения ее работоспособности и решения вопроса о возможности приемки AC в опытную эксплуатацию.
1.9. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления им соответствующих документов о их готовности к испытаниям, а также после ознакомления персонала АС с эксплуатационной документацией.
1.10. Опытную эксплуатацию АС проводят с целью определения фактических значений количественных и качественных характеристик АС и готовности персонала к работе в условиях функционирования АС, определения фактической эффективности АС,. корректировке (при необходимости) документации.
1.11. Приемочные испытания АС проводят для определения. соответствия АС техническому заданию, оценки качества .опытной эксплуатации и решения вопроса о возможности приемки АС в постоянную эксплуатацию.
1.12. Приемочным испытаниям АС должна предшествовать ее опытная эксплуатация на объекте.
1.13. В зависимости от вида требований, предъявляемых к АС на испытаниях, проверке или аттестации в ней подвергают:
- 1) комплекс программных и технических средств.
- 2) персонал;
- 3) эксплуатационную документацию, регламентирующую деятельность персонала при функционировании АС;
- 4) АС в целом.
1.14. При испытаниях АС проверяют:
- 1) качество выполнения комплексом программных и технических средств автоматических функций во всех режимах функционирования АС согласно ТЗ на создание АС;
- 2) знание персоналом эксплуатационной документации ц наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования АС, согласно ТЗ на создание АС;
- 3) полноту содержащихся в эксплуатационной документации указании персоналу по выполнению им функций во всех режимах функционирования АС согласно ТЗ на создание АС;
- 4) количественные и (или) качественные характеристики выполнения автоматических и автоматизированных функций АС в соответствии с ТЗ;
- 5) другие свойства АС, которым она должна соответствовать по ТЗ.
1.15. Испытания АС следует проводить на объекте заказчика. По согласованию между заказчиком и разработчиком предварительные испытания и приемку программных средств АС допускается проводить на технических средствах разработчика при создании условий получения достоверных результатов испытаний.
1.16. Допускается последовательное проведение испытаний и сдача частей АС в опытную и постоянную эксплуатацию при соблюдении установленной в ТЗ очередности ввода АС в действие.
ПРЕДВАРИТЕЛЬНЫЕ ИСПЫТАНИЯ
2.1. Предварительные испытания АС могут быть:
- 1) автономные;
- 2) комплексные.
2.2. Автономные испытания
2.2.1. Автономные испытания АС следует проводить в соответствии с программой и методикой автономных испытаний, разрабатываемых для каждой части АС.
2.2.2. В программе автономных испытаний указывают:
- 1) перечень функций, подлежащих испытаниям;
- 2) описание взаимосвязей объекта испытаний с другими частями АС;
- 3) условия, порядок и методы проведения испытаний и обработки результатов;
- 4) критерии приемки частей по результатам испытаний.
К программе автономных испытаний следует прилагать график проведения автономных испытаний.
2.2.3. Подготовленные и согласованные тесты (контрольные примеры) на этапе автономных испытаний должны обеспечить:
- 1) полную проверку функций и процедур по перечню, согласованному с заказчиком;
- 2) необходимую точность вычислений, установленную в ТЗ;
- 3) проверку основных временных характеристик функционирования программных средств (в тех случаях, когда это является существенным);
- 4) проверку надежности и устойчивости функционирования программных и технических средств.
2.2.4. В качестве исходной информации для теста рекомендуется использовать фрагмент реальной информации организации-заказчика в объеме, достаточном для обеспечения необходимой достоверности испытаний.
2.2.5 Результаты автономных испытании частей АС следует фиксировать в протоколах испытаний. Протокол должен содержать заключение о возможности (невозможности) допуска части АС к комплексным испытаниям.
2.2.6. В случае, если проведенные автономные испытания будут признаны недостаточными, либо будет выявлено нарушение требований регламентирующих документов по составу или содержанию документации, указанная часть АС может быть возвращена на доработку и назначен новый срок испытаний.
2.3. Комплексные испытания
2.3.1. Комплексные испытания АС проводят путем выполнения комплексных тестов. Результаты испытаний отражают в протоколе. Работу завершают оформлением акта приемки в опытную эксплуатацию.
2.3.2. В программе комплексных испытаний АС или частей АС указывают:
- 1) перечень объектов испытания;
- 2) состав предъявляемой документации;
- 3) описание проверяемых взаимосвязей между объектами испытаний;
- 4) очередность испытаний частей АС;
- 5) порядок и методы испытаний, в том числе состав программных средств и оборудования, необходимых для проведения испытаний, включая специальные стенды и полигоны.
2.3.3. Для проведения комплексных испытаний должны быть представлены:
- 1) программа комплексных испытаний;
- 2) заключение по автономным испытаниям соответствующих частей АС и устранение ошибок и замечаний, выявленных при автономных испытаниях;
- 3) комплексные тесты;
- 4) программные и технические средства и соответствующая им эксплуатационная документация.
2.3.4. При комплексных испытаниях допускается использовать в качестве исходной информацию, полученную на автономных испытаниях частей АС.
2.3.5. Комплексный тест должен:
- 1) быть логически увязанным;
- 2) обеспечивать проверку выполнения функций частей АС во всех режимах функционирования, установленных в ТЗ на АС, в том числе всех связей между ними;
- 3) обеспечивать проверку реакции системы на некорректную информацию и аварийные ситуации.
2.3.6. Протокол комплексных испытаний должен содержать заключение о возможности (невозможности) приемки АС в опытную эксплуатацию, а также перечень необходимых доработок и рекомендуемые сроки их выполнения.
После устранения недостатков проводят повторные комплексные испытания в необходимом объеме.
ОПЫТНАЯ ЭКСПЛУАТАЦИЯ
3.1. Опытную эксплуатацию проводят в соответствии с программой, в которой указывают:
- 1) условия и порядок функционирования частей АС и АС в целом;
- 2) продолжительность опытной эксплуатации, достаточную для проверки правильности функционирования АС при выполнении каждой функции системы и готовности персонала к работе в условиях функционирования АС;
- 3) порядок устранения недостатков, выявленных в процессе опытной эксплуатации.
3.2. Во время опытной эксплуатации АС ведут рабочий журнал, в который заносят сведения о продолжительности функционирования АС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке, технических средств. Сведения фиксируют в журнале с указанием даты и ответственного лица. В журнал могут быть занесены замечания персонала по удобству эксплуатации АС.
3.3. По результатам опытной эксплуатации принимают решение о возможности (или невозможности) предъявления частей АС и системы в целом на приемочные испытания.
Работа завершается оформлением акта о завершении опытной эксплуатации и допуске системы к приемочным испытаниям.
ПРИЕМОЧНЫЕ ИСПЫТАНИЯ
4.1. Приемочные испытания проводят в соответствии с программой, в которой указывают:
- 1) перечень объектов, выделенных в системе для испытаний и перечень требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ);
- 2) критерии приемки системы и ее частей;
- 3) условия и сроки проведения испытаний;
- 4) средства для проведения испытаний;
- 5) фамилии лиц, ответственных за проведение испытаний;
- 6) методику испытаний и обработки их результатов;
- 7) перечень оформляемой документации.
4.2. Для проведения приемочных испытаний должна быть предъявлена следующая документация:
- 1) техническое задание на создание АС;
- 2) акт приемки в опытную эксплуатацию;
- 3) рабочие журналы опытной эксплуатации;
- 4) акт завершения опытной эксплуатации и допуска АС к приемочным испытаниям;
- 5) программа и методика испытаний.
Приемочные испытания следует проводить на функционирующем объекте.
4.3. Приемочные испытания в первую очередь должны включать проверку:
- 1) полноты и качества реализации функций при штатных, предельных, критических значениях параметров объекта автоматизации и в других условиях функционирования АС, указанных в ТЗ;
- 2) выполнения каждого требования, относящегося к интерфейсу системы;
- 3) работы персонала в диалоговом режиме;
- 4) средств и методов восстановления работоспособности АС после отказов;
- 5) комплектности и качества эксплуатационной документации.
4.4. Проверку полноты и качества выполнения функций АС рекомендуется проводить в два этапа. На первом этапе проводят испытания отдельных функций (задач, комплексов задач). При этом проверяют выполнение требований ТЗ к функциям (задачам, комплексам задач). На втором этапе проводят проверку взаимодействия задач в системе и выполнение требований ТЗ к системе в целом.
4.5. По согласованию с заказчиком проверка задач в зависимости от их специфики может проводиться автономно или в составе комплекса. Объединение задач при проверке в комплексах целесообразно проводить с учетом общности используемой информации и внутренних связей.
4.6. Проверку работы персонала в диалоговом режиме проводят с учетом полноты и качества выполнения функций системы в целом.
Проверке подлежит:
- 1) полнота сообщений, директив, запросов, доступных оператору и их достаточность для эксплуатации системы;
- 2) сложность процедур диалога, возможность работы персонала без специальной подготовки;
- 3) реакция системы и ее частей па ошибки оператора, средства сервиса.
4.7. Проверка средств восстановления работоспособности АС после отказов ЭВМ должна включать:
- 1) проверку наличия в эксплуатационной документации рекомендаций по восстановлению работоспособности и полноту их описания;
- 2) практическую выполнимость рекомендованных процедур;
- 3) работоспособность средств автоматического восстановления функций (при их наличии).
4.8. Проверку комплектности и качества эксплуатационной документации следует проводить путем анализа документации на соответствие требованиям нормативно-технических документов ТЗ.
4.9. Результаты испытаний объектов, предусмотренных программой, фиксируют в протоколах, содержащих следующие разделы:
- 1) назначение испытаний и номер раздела требований ТЗ на АС, по которому проводят испытание;
- 2) состав технических и программных средств, используемых при испытаниях;
- 3) указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;
- 4) условия проведения испытаний и характеристики исходных данных;
- 5) средства хранения и условия доступа к конечной, тестирующей программе;
- 6) обобщенные результаты испытаний;
- 7) выводы о результатах испытаний и соответствии созданной системы или ее частей определенному разделу требований ТЗ на АС.
4.10. Протоколы испытаний объектов по всей программе обобщают в едином протоколе, на основании которого делают заключение о соответствии системы требованиям ТЗ на АС и возможности оформления акта приемки АС в постоянную эксплуатацию.
Работу завершают оформлением акта о приемке АС в постоянную эксплуатацию.
Содержание введено для удобства пользования документом.
Что разъединяет их и что объединяет — индивидуальные особенности или специ
Ситуация, в которой руководитель проектной службы и руководитель службы эксплуатации с трудом находят взаимопонимание, а их мнения относительно разрабатываемого или внедряемого программного обеспечения резко различаются, общеизвестна. Это понятно: эксплуатация требует стабильности, в то время как проект постоянно порождает изменения, и стабильность нарушается. Но почему часто бывает проще разработать автоматизированную информационную систему, чем сдать ее в эксплуатацию, обеспечив ее сопровождение и развитие? Находятся ли в противоречии интересы тех, кто проектирует информационные системы, и тех, кто их эксплуатирует?
Чтобы ответить на эти вопросы, необходимо понять поводы и причины «борьбы противоположностей» — проектирования и эксплуатации, проектного менеджера и специалиста по сопровождению.
Варианты эксплуатации
В определениях видов эксплуатации ничего не изменилось за прошедшие два-три десятилетия. Под опытной эксплуатацией следует понимать эксплуатацию системы заказчиком параллельно с основной информационной системой, которая находится в промышленной эксплуатации. В ходе опытной эксплуатации в систему может вводиться заведомо некорректная информация, поэтому результаты ее работы в опытной эксплуатации не используются для принятия бизнес-решений. Результаты работы новой системы служат исключительно для сопоставления с результатами старой либо для сопоставления с бизнес-требованиями заказчика (если система разрабатывается не для замены существующей). Отличительный критерий понятия «опытная эксплуатация» — результаты работы системы на этом этапе не должны использоваться в реальной деятельности предприятия.
Опытно-промышленная эксплуатация отличается тем, что получаемые результаты уже не вызывают сомнений и используются для принятия бизнес-решений. Однако автоматизированная информационная система еще не принята службой эксплуатации под свою ответственность, она еще находится в зоне ответственности разработчика, который оперативно исправляет ошибки, вносит изменения, производит доработки, непосредственно в системе оптимизирует конфигурационные или настроечные файлы. Другими словами, при опытно-промышленной эксплуатации разработчик не только несет ответственность за эксплуатируемую систему, но и имеет все полномочия по ее доработке и настройке.
Общей особенностью этих этапов внедрения является то, что заказчик — пользователь — может отказаться от новой системы и вернуть ее на доработку. Так же и разработчик может отозвать систему из опытной (или даже опытно-промышленной) эксплуатации без нанесения значительного ущерба бизнесу заказчика. Фактически ответственность за использование результатов работы системы несет заказчик, за устранение недоработок и ошибок — разработчик, а за регламентную поддержку оборудования и программного обеспечения отвечает служба эксплуатации. В этих условиях вполне естественно ограничить сроки опытно-промышленной эксплуатации.
Специфика промышленной эксплуатации заключается в том, что система используется без альтернатив и дублирующих систем. Если незапланированная остановка (по любой причине) информационной системы критична для бизнеса, если предприятие несет убытки, недополучает прибыль, теряет клиентов, то говорить об опытной или опытно-промышленной эксплуатации уже нельзя. Если варианты опытной эксплуатации носят временный характер (возможны остановки системы), то промышленная эксплуатация по своей сути является постоянной, то есть стабильной.
При промышленной эксплуатации только служба эксплуатации несет полную ответственность за функционирование и использование системы и разработчики уже не могут самостоятельно вносить какие либо изменения (настройки) в действующую систему. Передача системы в промышленную эксплуатацию, безусловно, не снимает с разработчиков ответственности за локализацию и исправлению ошибок. Однако в этом случае разработчик уже не может модифицировать систему, минуя службу эксплуатации.
Стабильность и развитие
Практически все определения понятия «проект» включают три обязательных компонента: временный характер, наличие конкретных уникальных целей или задач и накладываемые ограничения. В контексте этой статьи важно, что любой проект носит временный, конечный характер.
В данной статье под проектом будем понимать целенаправленную деятельность по изменению сложившейся к настоящему времени и существующей системной архитектуры корпоративной информационной системы предприятия (приложений, данных, оборудования), деятельность по переводу существующей системной архитектуры из текущего состояния в новое, определяемое как целевое. Другими словами, проект стремится к выводу системной архитектуры из текущего состояния, в то время как главная задача службы эксплуатации (вот где противоречие!) — поддержка системной архитектуры в устойчивом состоянии. Только при этом условии служба эксплуатации может гарантировать пользователям информационных систем и ресурсов предоставление услуг надлежащего качества в течение некоторого периода времени.
Поняв первоисточник противоречий между проектным менеджментом и промышленной эксплуатацией информационных систем, рассмотрим несколько типичных конфликтных ситуаций и способов их преодоления. Возможно, эти четыре постулата далеко не бесспорны, но задают свою структуру отношений проекта и эксплуатации.
1. Система должна работать без единого замечания и сбоя не менее заранее установленного и заведомо длительного срока. Желание службы эксплуатации принять для сопровождения систему без единой («последней») ошибки понятно и объяснимо. Но неизбежность ошибок программного обеспечения, имеющего заданный уровень сложности, можно считать доказанной. Известно, что график количества неисправностей, отказов, сбоев, ошибок в работе системы относительно времени их обнаружения (возникновения) имеет вид корытообразной кривой, в начале и в конце эксплуатации они возникают чаще, в середине их количество минимально. Эксплуатация стремится перепоручить устранение краевых (частых) ошибок разработчику, что вполне понятно. Но такова особенность программного обеспечения, что даже спустя значительное время в работающих программах (тем более в программных комплексах), информационных системах обнаруживаются ошибки. Есть интересная статистика, представленная компанией Hewlett-Packard, согласно которой:
- лучшие системы обработки данных (системы реального времени) простаивают из-за сбоев девять часов в год;
- выдающиеся — 43 часа незапланированных простоев в год;
- очень хорошие — 87 часов;
- средние — 175 часов незапланированных простоев в год (при 250 часах плановых).
Считается, что средние системы обеспечивают 98-процентную доступность услуг автоматизированной системы. Тип готовности к работе «24 часа х 6 дней» или «18 часов х 7 дней» не так важен. Доступность должна определяться с позиций пользователя, а не системного администратора.
Пользователь (заказчик системы) вправе решить, что он предпочитает: первым увидеть и опробовать новые решения, осознавая и принимая риски возможных сбоев в работе не до конца отлаженной системы, или же не рисковать и дождаться выпуска финальной версии программы, в которой вероятность возникновения ошибок будет существенно ниже.
Иногда организация разрабатывает автоматизированную информационную систему собственными силами. Это характерно для агрессивных, молодых владельцев, ведущих бизнес на рынке с быстро меняющимися условиями (например, банковский или страховой бизнес). Требование бесперебойной работы системы в течение трех месяцев сводится к тому, что владелец или заказчик готов нести определенные риски от простоев новой системы, в то время как консервативная и стабильная служба эксплуатации не может себе этого позволить. Эксплуатация отвечает за сбои и простои. Главной целью эксплуатации является сокращение этих простоев, для чего и требуется трехмесячная гарантия разработчика, а служба поддержки пока слагает с себя ответственность за сопровождение системы. По сути, службе эксплуатации требуется время освоения системы администратором — не разработчиком или курсы переподготовки.
Три месяца работы без замечаний и сбоев при более пристальном рассмотрении оказываются не более чем карточным домиком. Говорить о стабильности сложной информационной системы, интегрированной в ландшафт окружающих информационных систем предприятия, можно только в случае стабильного функционирования всех других, смежных систем при отсутствии доработок, развития всех этих систем под требования развивающегося бизнеса.
Сложные информационные системы состоят из подсистем, функционирование которых зависит от внешних систем, являющихся поставщиками информации. Отказ в работе внешней системы, невозможность своевременного получения информации, а также получение недостоверной информации означают приостановку в работе или некорректную работу системы, потребляющей эту информацию. Надежность сложной, составной системы определяется как произведение показателей надежности компонентов, из которых построена система. Вот простая, но наглядная иллюстрация (см. таблицу):
Таким образом, три месяца работы без сбоев и замечаний — это хороший показатель для операционной системы, но на уровне прикладных систем — это фантастика. А решение может быть простым: тщательное протоколирование службой эксплуатации всех инцидентов, составление по каждому инциденту и для каждой из подсистем независимого протокола или акта (на основании оперативного аудита) с анализом причин и разработкой плана мероприятий для исключения инцидента в будущем. В акте должны обязательно указываться смежные системы — как вызвавшие инцидент, так и пострадавшие в результате него.
Штатные процедуры разбора произошедших инцидентов и принятых мер должны проводиться еженедельно на уровне руководства службы ИТ предприятия. Только при таком подходе можно ожидать постепенного уменьшения числа отказов и сбоев в работе информационных систем, находящихся в опытно-промышленной эксплуатации.
2. В систему, сданную в эксплуатацию, не должны вноситься изменения. Этот постулат в целом выглядит вполне логично. Как служба эксплуатации может гарантировать бесперебойную работу системы, если в нее вносится очередная серьезная доработка уже на этапе опытно-промышленной эксплуатации? Внесение каждой доработки, видимо, должно вызывать сдвиг срока завершения опытно-промышленной эксплуатации, или начало опытно-промышленной эксплуатации каждый раз заново.
Однако эксплуатация систем в ситуации агрессивного развития бизнеса, оперативной разработки и вывода на рынок новых продуктов и услуг, перманентного изменения требований со стороны законодателей, регуляторов и партнеров ставит под вопрос выполнение требования о невнесении исправлений в сданную в эксплуатацию систему. Это требование выглядит еще более абсурдным при сопоставлении с издаваемыми производителями компьютеров, сетевого оборудования, операционных систем и т.д. томами «заплаток на бреши», которые каждый день вновь отыскиваются хакерами.
При анализе этой проблемы для системы, созданной собственными силами, не следует недооценивать роли заказчика и пользователя, который не хочет или не может сформулировать задание на достаточно целостную, комплексную разработку и оправдывает это постоянно меняющимися рыночными условиями, требованиями законодателей и регуляторов. Нужно понимать, что чаще всего заказчик — не профессиональный проектировщик или разработчик, но это не должно служить оправданием превращения собственной внутренней разработки в «импровизации на тему». У заказчика, как ни у кого другого, в первую очередь должен быть план на заказной проект, а не просто «поток сознания», запечатленный в виде официально оформленных заявок на доделку недоделок. Еще вопрос: чья вина в их появлении?
Если владелец бизнеса, заказчик осознанно идут на разработку системы собственными силами, то это означает, что требования со стороны бизнеса будут изменяться постоянно, заказчик будет требовать их реализации немедленно, а не в течение года до следующей поставки очередной версии системы. Часто эти требования будут носить далеко некосметический характер и предполагать серьезную доработку (по сути, переделку) уже эксплуатируемой системы.
При собственной разработке проектная документация создается с учетом реализации всех имеющихся на конкретный момент времени требований, но требования реализуются и сдаются в эксплуатацию поэтапно. В результате довольно редко возникают ситуации, когда проектная документация полностью соответствует передаваемой в эксплуатацию системе.
Эта достаточно общая, широко распространенная проблема. Подавляющее большинство автоматизированных информационных систем, по сути находящихся в промышленной эксплуатации, формально находится в постоянно продлеваемой опытно-промышленной эксплуатации по этой причине.
Модернизировать или дорабатывать можно только то, что введено в эксплуатацию. Проектный подход предполагает, что нельзя или не следует дорабатывать и менять то, что не введено в опытно-промышленную (продолжительностью три месяца) или постоянную (не ограниченную по времени) эксплуатацию. Доработка системы, которая не эксплуатируется, по сути, есть ее разработка. Если от службы эксплуатации к проектировщикам нет документированных и развернутых в предложения по доработке замечаний, то система должна вводиться в промышленную эксплуатацию по умолчанию. Если замечания и предложения есть — тем более, ведь дорабатывать можно только то, что сдается-принимается в эксплуатацию (пусть и с обязательными доработками).
3. Разработчик не должен иметь доступа к «боевой» системе. Справедливое требование, выдвигаемое службой эксплуатации, заключается в том, что разработчик не должен иметь доступа ни к данным, ни к коду систем, находящихся в промышленной эксплуатации. Ограничение доступа к данным связано с конфиденциальностью хранимой и обрабатываемой информации, в то время как ограничение доступа к коду связано с ответственностью службы эксплуатации за стабильную, устойчивую работоспособность системы.
В части конфиденциальности информации складывается абсурдная ситуация, когда служба эксплуатации является более «доверенным» подразделением, чем проектировщики, при том, что оба подразделения работают на одно предприятие. Это разделение можно считать справедливым, если система была введена в промышленную эксплуатацию. Опытно-промышленная эксплуатация явно предполагает доступ к системе разработчика, ограниченный только списком ответственных сотрудников.
На практике требование конфиденциальности информации выполняется редко. Какой заказчик готов платить деньги за разработку специальных программ генерации тестовых данных, их отладку и, что не менее важно, за поддержание этих программ в актуальном состоянии вместе с развитием основной функциональности самой системы (защиту от своих же разработчиков)? Поэтому зачастую разработка и отладка ведутся на копиях «живых», реальных данных, предоставляемых службой эксплуатации. Второе же требование — ограничение доступа к коду — трактуется и интерпретируется службой эксплуатации весьма жестко: разработчик вообще не должен иметь доступа к промышленной системе.
В результате, если при необходимости разработчик запрашивает диагностическую информацию в службе эксплуатации, она предоставляет ее в течение не часов, а суток, при этом выстраиваются сложные, многоуровневые процедуры тестирования и приемо-сдаточных испытаний по передаче программ, настроечных файлов, документации в эксплуатацию. Все изменения устанавливаются в промышленную систему исключительно и только администраторами службы эксплуатации.
Эти организационно-технические меры разумны и целесообразны при весьма важном условии: все действия администраторов автоматизированных информационных систем должны фиксироваться в журнале аудита, который должен быть отделен от администраторов, но доступен службе аудита ИТ (согласно требованиям стандарта ЦБ РФ по информационной безопасности банковской системы).
4. Служба эксплуатации должна быть во всеоружии! Под этим каждый может подразумевать то, что приходит на ум ему и не пришло в голову оппоненту. Это может быть и исчерпывающе полный комплект документации вводимой в эксплуатацию системы и всех смежных информационных систем, с которыми вводимая в эксплуатацию система взаимодействует. Это может быть и полный комплекс программных средств администрирования, включая не только средства по управлению пользователями системы, но и средства по рассылке уведомлений, сбора статистики, оперативного мониторинга.
Комплекс должен иметь «нормальный» интерфейс, понятный не только администратору, но и рядовому дежурному инженеру (или оператору). Далее: это может быть наличие в службе эксплуатации грамотных, обученных специалистов, имеющих должную для сопровождения системы квалификацию, и пр.
Против таких доводов устоять невозможно. Безусловно, документация должна быть, специалисты службы эксплуатации должны быть обучены, программы для администрирования пользователей должны быть разработаны, сбор статистки и мониторинг также должны быть. Проектный менеджер каждый раз должен планировать работы по проекту с учетом этих факторов и вовлекать службу эксплуатации на самых ранних стадиях проекта для более точного понимания требований и раннего начала работ над этими требованиями.
Равномерное планирование этих работ в ходе всего проекта будет выглядеть гораздо менее акцидентно, чем приостановка работ в проекте «на финишной прямой» перед запуском системы в эксплуатацию — только для того, чтобы залатать допущенные в функциональности или в документировании дыры.
Но следует учитывать, что все эти работы заказчик будет оплачивать из бюджета проекта. Насколько велики по трудозатратам будут требования о приведении службы эксплуатации во всеоружие? Насколько увеличит бюджет реализация этих требований и насколько к этому увеличению бюджета и сроков будет готов заказчик проекта?
Что следует понимать под эксплуатацией
Регламентируя взаимоотношения между проектными службами и службой эксплуатации, следует заранее определить понятия, зафиксировать, что считается и является опытной эксплуатацией, что — опытно-промышленной, а что — промышленной эксплуатацией автоматизированных информационных систем. Если не определить эти понятия и не описать процедуру передачи и сопровождения систем, то через какое-то время множество критически важных приложений будут «плавать» в состоянии опытной эксплуатации.
Чем это чревато? Тем, что нет одного ответственного за сбои? Не только — ведь ресурсы проектировщиков не высвобождаются для других проектов. А насколько эти проекты и эти ресурсы велики? Если говорить о проектах закупки и внедрения систем, то они требуют уже других ресурсов…
Разработка программного обеспечения и разработка автоматизированной информационной системы — совокупности функциональной части, технического, информационного, программного, организационного обеспечения, коммуникаций и персонала — это разные не по масштабам, а по содержанию проекты. Программы всегда разрабатывались собственными силами, включая достаточно сложные программные системы. Гораздо реже программы или программные продукты покупаются в готовом виде. Но информационные системы в принципе делаются только на заказ. Часто это внутренний заказ, и разработка системы ведется собственными силами, поэтому ввод прикладной системы в действие, например в банке, не означает ее опытную, опытно-промышленную и даже промышленную эксплуатацию, поскольку это использование системы заказчиком, сопровождение программного обеспечения разработчиком и обеспечение работоспособности (по сути, эксплуатации) системы службой поддержки. Развитие системы в ходе постоянной эксплуатации — неизбежная особенность жизненного цикла информационной системы. Не признавать этого — лукавство.
Основной вывод, который следует сделать из противопоставления «проект — эксплуатация», следующий: ни опытная, ни опытно-промышленная эксплуатация не является по своей сути промышленной эксплуатацией. При опытной и опытно-промышленной эксплуатации полная ответственность лежит на проектировщиках и разработчиках, служба эксплуатации при этом не несет полной ответственности за эксплуатацию разработанной автоматизированной системы, и на этих этапах единственно возможным решением может стать организация внутри проекта собственной службы тестирования и администрирования системы.
Это может быть осуществлено путем выделения и включения в проект необходимых ресурсов из смежных подразделений или путем привлечения в проект специалистов необходимой квалификации (на временной основе) извне. При таком подходе за счет увеличения сроков опытной и опытно-промышленной эксплуатации количество «внедрений» в промышленную эксплуатацию может быть резко сокращено. Ответственность за опытную эксплуатацию при этом будет нести в полной мере проектная группа, не затрагивая компетенции и не перекладывая непомерно высоких рисков на службу эксплуатации.
Следует обсудить этот вопрос с вашим проектным менеджером и со службой эксплуатации. Тот из них, кто будет готов взять на себя ответственность и риски опытно-промышленной эксплуатации рабочих версий системы, тот вместе с ответственностью должен будет получить и необходимые для этого права.
Виктор Галактионов — главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк» (ОАО); vgalax@mail.ru
Юрий Орлов — независимый эксперт; vodolei1@mail.ru
Таблица. Показатели надежности компонентов в сложной системе
Испытания автоматизированных систем (АС), согласно ГОСТ 34.601.90, проводятся на стадии «Ввод в действие» и являются завершающим и ключевым этапом создания любой АС, определяющим качество проделанной работы по её созданию и требующим экспертного организационного и технического сопровождения для оценки качества этой работы.
Компания «АРТВЕЛЛ», лидер российского рынка информационных и коммуникационных технологий, выступает в роли эксперта по оценке качества ПО и предлагает услуги инженерно-технической экспертизы соответствия создаваемой АС требованиям технического задания (ТЗ).
«АРТВЕЛЛ» предлагает системный подход к испытаниям АС, обеспечивая полный комплекс услуг от анализа проектной документации и разработки программы и методики испытаний (ПМИ) до оформления акта о приёмке АС в постоянную эксплуатацию.
Специалистами «АРТВЕЛЛ» накоплен и обобщен богатейший опыт проектной деятельности, включая комплексный анализ качества и эффективности автоматизированных информационных систем, приложений и веб-сервисов. Это обеспечит заказчику всестороннюю достоверную оценку и контроль качества программной продукции.
Компания АРТВЕЛЛ предоставляет комплексные услуги по тестированию (испытанию) ПО в соответствии с ГОСТ 34.603-92, обеспечивая комплексный анализ АС: проверку выполнения заданных функций системы, определение и проверку соответствия требованиям ТЗ количественных и (или) качественных характеристик системы, выявление недостатков в действиях системы и в разработанной документации.
Для оценки качества АС и готовности к передаче в постоянную эксплуатацию в общем случае проводится три вида испытаний, каждый из которых является отдельным этапом проверки:
- Предварительные испытания проводятся для определения работоспособности АС и решения вопроса о возможности её приёмки в опытную эксплуатацию.
- Опытная эксплуатация проводится с целью определения фактических значений количественных и качественных характеристик АС и готовности персонала к работе в условиях её функционирования, определения фактической эффективности АС, а также оценки готовности документации.
- Приёмочные испытания проводятся для определения соответствия ПО техническому заданию, оценки качества, опытной эксплуатации и решения вопроса о возможности приёмки АС в постоянную эксплуатацию.
Специалисты «АРТВЕЛЛ» обеспечат всестороннюю оценку АС в соответствии с ГОСТ 34.603-92 (Информационная технология. Виды испытаний автоматизированных систем) и проведут проверку по всем соответствующим критериям:
- по качеству выполнения комплексом программных и технических средств автоматических функций во всех режимах функционирования АС согласно ТЗ на создание АС;
- по знанию персоналом эксплуатационной документации и наличию у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования АС, согласно ТЗ на создание АС;
- по полноте содержащихся в эксплуатационной документации указаний персоналу по выполнению им функций во всех режимах функционирования АС согласно ТЗ на создание АС;
- по количественным и (или) качественным характеристикам выполнения автоматических и автоматизированных функций АС в соответствии с ТЗ;
- по другим свойствам АС, которым она должна соответствовать по ТЗ.