Крючков Основы учёта,контроля 2007
.pdfбалк–разделение – позволяет пользователю регистрировать операции изотопного разделения.
• Контейнеризация – подразумевает следующие операции: создание контейнера без привязки к материалу – пустой контей-
нер; помещение контейнеров в другой контейнер;
извлечение контейнеров из контейнера; перемещать материал из контейнера в контейнер.
•Физическая инвентаризация. Эта функция позволяет санкционированному пользователю вводить результаты физической инвентаризации с зарегистрированными наблюдениями. В процессе работы помечается контейнер, подвергшийся проверке и вводятся результаты проверки.
•Учет индикаторов целостности (пломб). Система позволяет пользователю создавать пломбы, обновлять пломбы, получать отчеты о пломбах. Естественно, что все это подразумевается в виртуальном смысле, т.е. связь с реальными пломбами целиком лежит на операторе.
•Создание отчетов. Вообще говоря, система позволяет легко добавлять новые отчеты, что вы и проделаете на лабораторной работе. В качестве базовых отчетов заложены отчеты по группам:
контейнеры (транзакции с контейнерами и содержимое контейнеров);
содержимое на физическом месторасположении; ЗБМ (транзакции в выбранной ЗБМ и содержимое ЗБМ);
транзакции (вывод транзакций упорядоченных по дате и по пользователю).
Кроме того, система поддерживает создание специальных отчетов для Федеральной системы учета ЯМ. Поскольку на момент создания системы форма такого отчета не определена, в системе стоит некоторый произвольный отчет.
Следует так же понимать тот факт, что под «отчетом» разработчики E/Z MAS понимают сформированную по некоторым правилам
иупорядоченную таблицу, выбранную из базы данных с помощью некоторого SQL запроса. В российских требованиях к СУиК есть пункт, по которому наряду с электронной системой должна действовать система сбора и хранения бумажных копий информации. Это требование не накладывает каких–то невыполнимых действий,
401
но надо понимать, что наряду с электронной версией потенциальный российский пользователь E/Z MAS должен предусмотреть получение распечаток отчетов по определенной форме. В среде MS Access это сделать нетрудно.
•Конфигурация данных. Как говорилось ранее, в системе существуют таблицы, которые обновляются очень редко – месторасположения, ЗБМ, предприятия, пользователи. Обновление этих таблиц возможно только для специальных санкционированных пользователей, имеющих статус администратора.
•Взаимодействие базы данных с внешними устройствами. В последней версии E/Z MAS существуют функции, осуществляющие ввод информации в базу данных непосредственно из внешних устройств. Связь была осуществлена с двумя видами устройств – штрихкодовым оборудованием и весами. Связь осуществляется через com–порт одной из рабочих станций специально оборудованной для этого. Программно в asp–файле используется объект Active–X, осуществляющий связь с этим портом. В связи с этой функцией существует не решенная до конца проблема. Когда внешнее оборудование отключено от компьютера, то в интерфейсах системы эти функции отсутствуют. При подключении же одной из рабочих станций к внешним устройствам функции включаются во всех интерфейсах на всех рабочих станциях сети, поскольку они загружаются из одного файла на Web–сервере. Серьезной проблемы это не представляет, один из путей ее решения – включение этой функции для пользователей, санкционированных для проведения измерений или инспекции со специальными login.
•Важную роль в функционировании системы имеют вопросы защищенности системы от несанкционированных действий пользователей. С каждым именем пользователя связан набор функций, которые он может выполнять. E/Z MAS предусматривает три типа пользователей:
пользователи, имеющие право только просматривать санкционированную информацию;
пользователи, имеющие право изменять санкционированную информацию;
администраторы базы данных – пользователи, имеющие право санкционировать права других пользователей.
402
Примеры интерфейсов E/Z MAS
В заключение рассмотрим примеры интерфейсов системы, т.е. реализацию описанной выше функциональности в asp–страницах. Приведем некоторые характерные примеры использования той или иной скриптовой техники и дизайна форм системы.
На рис. 7.13 представлена исходная страница системы E/Z MAS, открывающаяся в броузере при входе в систему. Пользователю предлагается ввести login и пароль. Существует вариант СУиК E/Z MAS, в котором требуется ввод двух независимых идентификаторов пользователя. Этот вариант реализуется для предприятий, где требуется выполнение пресловутого правила двух – осуществлять любое действие с ЯМ или информацией о нем могут только два человека.
Рис. 7.13. Исходная страница E/Z MAS
После ввода идентификатора пользователя и пароля и подтверждения существования пользователя, открывается главная страница системы, представленная на рис. 7.14. На главной странице систе-
403
мы расположены верхний и нижний фрагменты окна, содержащие, соответственно, наименование версии системы и главное меню. Между фрагментами располагается сообщение о благополучном входе в систему.
Рис. 7.14. Главная страница E/Z MAS. Пользовательское меню системы
Использование Е/Z MAS в МИФИ
E/ZMAS – единственная КСУиК ЯМ производства США, которая эксплуатируется на российском предприятии. Она была поставлена в МИФИ в 1999 г., подверглась адаптации к требованиям ФИС, была аттестована и эксплуатируется в течение 8 лет [22]. Модернизация, в основном, коснулась тех таблиц базы данных и функций, которые связаны с требованиями ФИС по учету и контролю ЯМ. Добавлены таблицы кодификаторов и условных обозна-
404
чений, введены функции создания отчетов в электронной форме требуемых ФИС форматов.
Главный недостаток системы заключается в использовании несертифицированного компонента – СУБД MS Access. В связи с необходимостью переаттестации системы, в настоящее время ведутся работы по глубокой модернизации системы на базе базового программного обеспечения с открытым кодом.
В заключение главы о компьтеризированных СУиК ЯМ рассмотрим процесс разработки и ввода в эксплуатацию систем такого рода и регламентацию этого процесса.
7.5. Разработка компьютеризированных СУиК ЯМ
При изучении компьютеризированных СУиК важным разделом является изучение процесса создания программного продукта начиная с начального этапа и заканчивая внедрением его на предприятии. Важно при этом обратить внимание не только на процедуры процесса создания системы, но и на требующуюся документацию.
Российские стандарты в достаточной степени регламентируют этот процесс. Однако в США, где опыт создания больших программных проектов значительно больший, чем в России, выработаны различные процедуры и методы планирования, проектирования, тестирования и ввода в эксплуатацию программного обеспечения. Подходы и методы разработки программных продуктов требуют отдельного специального изучения. В настоящей главе будет приведен лишь краткий обзор и даны некоторые рекомендации.
Требования отраслевого стандарта к порядку разработки, вводу в действие и эксплуатации
Весь процесс создания СУиК отраслевой стандарт [1] разделяет на ряд этапов. Первым этапом является предпроектная стадия. На этом этапе производится обследование объекта. При этом должно быть разработано технико–экономическое и аналитическое (с точки зрения защиты информации) обоснование разработки СУиК. Выпускается техническое задание на разработку, включающее в себя конкретные требования по защите информации.
Следующая стадия – стадия проектирования. Она завершается разработкой технорабочего проекта, включающего организационные и технические решения, разработку программной среды,
405
средств и методов защиты информации. Все решения должны соответствовать нормам и требованиям стандартов и требованиям технического задания.
Разработанные на этом этапе оборудование и программные средства должны пройти ряд испытания. Технические средства:
•испытания на работоспособность в местах установки;
•проверку на соответствие требования защиты информации. Базовое и прикладное программное обеспечение должно пройти
комплекс лабораторных испытаний. Средства защиты информации должны пройти сертификацию на соответствие правилам по защите информации.
Следующая стадия – ввод системы в эксплуатацию. Перед началом эксплуатации СУиК необходимо:
•разработать перечень эксплутационных документов;
•представить общее описание системы, включающее основные характеристики, сведения об областях применения, требуемых технических средствах;
•разработать комплекс рабочей регламентирующей документа-
ции;
•представить описание комплекса организационно–технических мероприятий, организационной структуры и штатного расписания предприятия в части, касающейся СУиК;
•разработать руководство системного программиста, включающего сведения для установки, настройки, тестирования системы, а также восстановления после аварий (следует ссылка на ГОСТы);
•разработать руководство пользователей, содержащие сведения для обеспечения диалога пользователя с программно–аппаратным оснащением СУиК;
•представить акт приемки в эксплуатацию программного обеспечения;
•представить план–график ввода СУиК в эксплуатацию.
При вводе в действие проводится аттестация программно– аппаратного оснащения СУиК на соответствие требованиям защиты информации.
Выделяют опытную эксплуатацию и промышленную. Перед началом опытной эксплуатации комиссия составляет акт о принятии системы в опытную эксплуатацию. Для перевода СУиК в промышленную эксплуатацию создается комиссия, включающая предста-
406
вителей разработчика, заказчика, эксплуатирующей организации. Если СУиК имеет выход в центральную информационную систему, в состав комиссии вводят представителя инспектирующей организации. Составляется акт технической приемки.
Дальнейшие действия стандарт не регламентирует. Существуют ссылки на другие стандарты, касающиеся автоматизированных систем и информационных технологий. Вопросы сопровождения, поддержки и вывода из эксплуатации регламентируются там. Отметим обилие технической документации, сопровождающей проект.
Жизненный цикл программного обеспечения
Американский стандарт вводит понятие жизненного цикла программного обеспечения, который представляет собой все процессы, связанные с конкретным программным продуктом от разработки концепции до вывода из эксплуатации и замены на более современное. Точного перечня этапов жизненного цикла не существует, но основные этапы представлены ниже:
•концепция;
•анализ требований к программному обеспечению;
•разработка;
•реализация;
•тестирование;
•внедрение и проверка;
•эксплуатация и обслуживание.
Для различных проектов, в зависимости от их целей и объемов, соотношение трудозатрат и материальных затрат на этих этапах может быть различным. Основная часть затрат приходится на два этапа – планирование и проектирование (включает в себя первые три графы) и на этап тестирования и внедрения.
Кроме того, следует помнить то, что некоторые разработчики США называют правилом 1:10:100. Понимается это следующим образом: затраты на исправление ошибки (неточности), выявленной на этапе планирования и проектирования, принимаются за 1. Тогда затраты на исправление этой же ошибки на этапе программирования будут равны 10. И, наконец, выявленная ошибка на этапе конечных испытания требует в 100 раз больших трудозатрат. Эти оценки дают представление о важности предварительного этапа разработки.
407
В США в год проводится до 175 тыс. программных проектов в различных областях, на которые тратится до 250 млрд. долларов. Только 16 % из них выполняются в срок и за те деньги, которые были запланированы. 31 % проектов просто проваливаются и не доводятся до конца. Поэтому разработчиками США накоплен достаточно большой как положительный, так и негативный опыт и сформулированы основные требования ко всем этапам создания системы, обеспечивающие успех всего мероприятия.
Планирование систем учета и контроля
Первоначальный этап планирования системы называют «Анализ требований». Суть этого анализа в выработке, анализе и документировании функциональных, информационных, эксплутационных, интерфейсных, характеристических и проектных ограничений программного продукта. На этом этапе проектировщик должен дать подробную формулировку того ЧТО требуется от системы, но ни в коем случае КАК это надо делать. Именно поэтому на данном этапе не рекомендуется участие непосредственно разработчиков ПО. Человек, имеющий опыт создания систем, неизбежно продумывает, как реализовать требования, и при этом может подгонять требования заказчика под готовые решения.
При анализе требований выделяются следующие задачи:
•определение первоначального объема проекта;
•анализ области принадлежности задачи;
•определение основных функций области;
•определение альтернативных схем решения проекта;
•выбор единственного решения;
•создание выходного документа – Спецификации требований к программному обеспечению (SRS);
•определение плана внедрения.
Для выполнения этих этапов создается рабочая группа. Предполагается, что в составе группы должны быть выделены следующие роли:
• бизнес–лидер. Это специалист–предметник из той области деятельности (бизнеса), для которой создается проект. Он отвечает за деловые решения;
408
•координатор – председательствует на заседаниях, специалист в области руководства и ведения проектами. Фактический руководитель проекта;
•управляющий – представитель организации разработчика, отвечает за общее руководство, бюджет, выполнение проекта;
•спонсор – лицо, ответственное за финансирование;
•технический лидер – представитель организации разработчика, осуществляет техническое руководство;
•представитель пользователя – представляет интересы конечных пользователей;
•группа программного проекта – рабочая группа.
Работа началась. Рассмотрим кратко основные этапы планирования и проектирования проекта.
Определение первоначального объема проекта. На этом этапе разработчик четко должен:
•определить, что включается, а что не включается в проект, т.е. во всей области выявить ту подобласть, которая может быть решена за выделенные деньги и выделенное время;
•получить общее понимание проблемы;
•выбрать методики и средства анализа требований;
•согласовать объем проекта с заказчиком и спонсором, это согласие должно быть документировано.
На этом этапе создается группа проекта, чтобы подготовить объекты и оборудование, наметить общий подход.
Методы сбора информации, используемые на этапах планирования: семинары и собеседования. Главное, на чем следует концентрировать внимание, – это необходимость фиксировать всю информацию, не позволять руководителям подавлять мнение участников. Зачастую требуется не допускать руководителей отделов или предприятий на эти семинары. Общение должно быть максимально свободным. Главное на этом этапе – участие непосредственных пользователей. Практика успешных проектов в США показывает, что участие пользователя уже на этапе планирования является главным фактором успеха любого проекта.
Следующий этап уже непосредственно касается проектирования – это анализ функций и процессов, с которыми будет иметь дело проект.
409
Функции это то, что выполняется системой, то, что она должна обеспечить. Процесс это конкретная реализация функции – он начинается, продолжается, заканчивается. Выделенные процессы и функциональные требования документируются и представляются графически. Причем при разработке следует осуществлять декомпозицию функций. Т.е. сначала рассматриваются глобальные функции, например – функция перемещение материала. Затем она подразделяется на функции более низкого уровня – перемещение материала внутри ЗБМ, получение материала извне, отправка материала. И это продолжается до получения элементарных функций, тех, которые уже невозможно разложить на функции более низкого уровня.
Между функциями устанавливаются зависимости. Выделяют:
•прямую зависимость – один процесс начинается после завершения другого;
•взаимоисключающая зависимость – используются условия;
•возвратная зависимость – повторное выполнение процесса;
•параллельная зависимость – результат вызывает выполнение более одного процесса.
Затем необходимо определить объекты деятельности и их атрибуты. Объект – это лицо, место, вещь, событие или идея, о которой необходимо получить информацию для успешного выполнения деятельности. Объекты имеют атрибуты – свойства информационного объекта. В дальнейшем на этапе проектирования базы данных объекты будут реализованы в таблицах, а атрибуты станут полями (столбцами) таблиц. Этот этап крайне важен и требует непременного участия пользователя. Если какой–либо объект не будет выделен на этом этапе, или не будут определены его атрибуты, а появится уже на этапе программирования или внедрения, потребуется изменение всей структуры базы данных.
После выделения объектов между ними устанавливаются взаимоотношения. Этот процесс близок к процессу организации связи между таблицами базы данных.
Следующий этап – определение технических требований. На этом этапе необходимо определить и документировать следующие технические ограничения на будущую систему:
•производительность;
•дизайн;
410