Создание прототипа ИУС и СТИ

На данном этапе первоначально осуществляется подготовка системно-технической инфраструктуры (СТИ) для создания и последующей эксплуатации Системы.

При подготовке СТИ используется оборудование поставки Заказчика, приобретенное им в соответствии с подготовленной в рамках концептуального проектирования на этапе 1 Спецификацией на поставку компонентов СТИ, включая лицензии на базовое программное обеспечение, для целей создания среды эксплуатации, разработки и тестирования Системы.

Выполнение данных работ может осуществляться в следующей последовательности:

1. Подготовка оборудования к эксплуатации. Проведение тестирования аппаратных компонентов.

2. Базовая установка и интеграция оборудования в имеющуюся СТИ: подключение к СПД, СХД, AD.

3. Настройка кластеризации сервисов.

4. Настройка базового мониторинга и DevOps. Документирование.

В рамках выполнения данных работ проводятся пусконаладочные работы «вхолостую».

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

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

Работы по созданию прототипа Системы выполняются в пределах установленных Календарным планом работ сроков с применением метода проектного управления оперативной разработкой ПО:SCRUM в соответствии с документированными методологическими решениями и спецификациями на базе специализированного ПО собственной разработки по управлению проектными задачами.

Разработка разбивается на спринты длительностью от 1 недели до 4-х недель для разных этапов разработки Системы, предусмотренных Календарных планом выполнения работ, и устанавливается Архитектором Системы. Промежуточные результаты работ по завершении спринта проходят внутреннюю рабочую процедуру функциональной приемки у консультантов по методологии и/или Архитектора Системы в части контроля вопросов соблюдения архитектурных требований и стандартов разработки. Внутренние стандарты разработки учитывают в необходимом объеме рекомендации вендора базового ПО.

Разработка осуществляется с применением выбранной версии типового программного обеспечения без проведения его обновления до актуальной версии в процессе разработки.

Информация обо всех внесенных изменениях в программные конфигурации отражается в Журнале изменений типового функционала конфигураций в хронологическом порядке в момент внесения изменений отдельно для каждой ФСУ в разрезе конфигураций базового ПО.

При внесении изменений в базовые программные конфигурации мы следует базовым принципам, заключающимся в возможности сохранения обновления доработанных конфигураций до уровня последующих типовых релизов вендора базового ПО, а также максимальном документировании сделанных изменений, т.е. использовании для объектов ИУС в рамках данной конфигурации установленных префиксов, комментариев в программном коде и т.п.

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

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

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

К таким объектам относятся: роли, макеты компоновки данных, картинки.

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

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

Изменение типовых форм выполняется программно с использованием общего модуля МодификацияКонфигурацииПереопределяемый, непосредственное изменение типовых форм выполняется только по согласованию Архитектора Системы. Изменение типовых ролей не допускается, при необходимости допустимо создание новых ролей.

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

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

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

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

Для проведения испытаний может составляться Сценарий предварительных испытаний, который фиксирует объем испытаний в отношении объектов прототипа Системы.

В ходе данных испытаний проводится проверка работоспособности основных механизмов и алгоритмов работы Системы в рамках выбранного функционального направления (функционально-модульное тестирование), а также основных механизмов и алгоритмов взаимодействия объектов Системы с объектами смежных функциональных систем (интеграционное тестирования). Также в ходе испытаний пользователями оценивается интерфейс Системы.

Замечания и предложения, поступившие в ходе испытаний от консультантов по методологии, а также администратора Системы и/или ключевых пользователей фиксируются в Протоколе предварительных испытаний и далее нашими специалистами в ходе подготовки Системы к опытной эксплуатации.