Заказ демо
*Отправляя данную форму вы соглашаетесь с политикой конфиденциальности
Заполните поля формы
Информация о программном обеспечении
Все модули системы ФЛЕКС базы данных являются SaaS-решениями и распространяются в виде интернет-сервиса в тех или иных комбинациях модулей.
Специальные действия по установке программного обеспечения на стороне пользователя не требуются. Для использования программного обеспечения, пользователю достаточно перейти на выданный адрес сайта при помощи браузера (мы рекомендуем Chrome последних версий) и ввести полученные логин и пароль.
Также, информируем вас о том, что программное обеспечение является узкоспециализированным и рассчитано на предварительное обучение пользователей.
Полная документация, содержащая описание функциональных характеристик программного обеспечения, встроена в модуль и доступна из выпадающего меню в верхней правой части интернет-страницы, под знаком вопроса.
Специальные действия по установке программного обеспечения на стороне пользователя не требуются. Для использования программного обеспечения, пользователю достаточно перейти на выданный адрес сайта при помощи браузера (мы рекомендуем Chrome последних версий) и ввести полученные логин и пароль.
Также, информируем вас о том, что программное обеспечение является узкоспециализированным и рассчитано на предварительное обучение пользователей.
Полная документация, содержащая описание функциональных характеристик программного обеспечения, встроена в модуль и доступна из выпадающего меню в верхней правой части интернет-страницы, под знаком вопроса.
Краткое описание функциональных характеристик:
Информация о стоимости программного обеспечения:
Стоимость модуля системы рассчитывается индивидуально на основании особенностей и потребностей каждого клиента отдельно. Для уточнения цены пишите на электронную почту contact@flexdbs.ru.
Краткое описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения:
1. Система управления качеством
На Предприятии создана и функционирует документально определенная система управления качеством. Область применения системы управления качества Предприятия включает в себя все подразделения, задействованные на всех этапах жизненного цикла программного обеспечения.
Обеспечение функционирования системы качества и контроль эффективности функционирования осуществляет подразделения обеспечения качества (Quality Assurance).
На Предприятии разработано и поддерживается в рабочем состоянии Руководство по качеству (POL-QA-005 ‘Quality Policy’), которое описывает систему управления качеством, политику и цели в области качества, функции подразделения качества, распределение ответственности руководства.
Подразделение обеспечения качества независимо от производства и отвечает за разработку и поддержание системы качества в соответствии с нормативными требованиями.
На Предприятии используется трехуровневая система документации, включающая верхний уровень (Policy), средний уровень (СОП и рабочие практики/инструкции), и нижний уровень (формы, шаблоны, информационные документы). Документы среднего и нижнего уровней структурированы по функциям/отделам: обеспечения качества, технический отдел, управление персоналом, управление проектами и административный отдел.
Ежегодно проводится обзор системы качества со стороны руководства, в формате встречи руководства и сотрудников подразделения обеспечения качества, с последующей регистрацией результатов встречи.
Система качества регулярно оценивается в ходе внешних и внутренних аудитов. За время работы Предприятие успешно прошло 35 внешних аудитов, включая аудиты независимыми аудиторскими компаниями.
2. Обучение и квалификация сотрудников
На Предприятии внедрена и функционирует система обучения персонала, регламентированная SOP-HRT-012 ‘Training and Qualification Compliance’. Объем необходимого обучения определяется матрицей обучения.
Тренинг осуществляется в следующих формах:
3. Стек технологий
Разработка программного обеспечения осуществляется на базе Microsoft Visual Studio ASP.Net Framework v 4.0 с использованием Microsoft C#. База данных – Firebird.
Контроль версий и обеспечение командной работы обеспечивается с помощью программного обеспечения Microsoft Team Foundation Server.
Данные компьютеризированные системы относятся к категории 1 по GAMP5, установлены согласно требованиям поставщика и имеют зафиксированный номер версии.
4. Валидация
Валидация программного обеспечения проводится согласно SOP-TD-036 ‘System Validation’. Составляется вариационный план согласно шаблону TPL-TD-059 ‘Validation Plan’, который содержит описание системы, оценку критичности системы, категоризацию, организационную структуру и требования к основным этапам валидации.
Квалификация проекта проводится после построения системы. В случае изменений исходного кода системы проводится обзор кода (code review). Обзор кода представляет собой анализ полноты трансляции проектных требований и соответствия стандартам кодирования. По завершении оформляется отчет об обзоре кода согласно шаблону TPL-TD056 (Code Review Report).
Квалификация монтажа (IQ) проводится после установки компьютеризированной системы согласно шаблонам TPL-TD-034 ‘Installation Qualification (virtual machine)’, TPL-TD-035 ‘Installation Qualification (application)’.
Проводится проверка как установленных виртуальных машин, так и корректность установки приложения. Предусмотрена также квалификация установки тестового окружения. По завершении квалификации монтажа оформляется отчет о проведенном тестировании согласно шаблону TPL-TD-036 ‘Installation Report’.
Квалификация функционирования (OQ) проводится после успешного завершения квалификации монтажа согласно шаблонам TPL-TD-027 ’OQ Test Plan’, TPL-TD-030 ‘OQ Testing Summary Report’, TPL-TD-028 ‘Test Cases’, TPL-TD-029 ‘Test Cases Execution Protocol’. Проводится тестирование функционала системы согласно предварительно разработанным сценариям тестирования в тестовом окружении. При разработке тестовых сценариев используется парадигма тестирования черного ящика, то есть тестировщик не знает о программной структуре тестируемой программы. Используются как позитивные, так и негативные (провокационные) тесты. По завершении квалификации функционирования оформляется отчет о проведенном тестировании.
После завершения всех этапов валидации оформляется итоговый валидационный отчет согласно шаблону TPL-TD-060 ‘Validation Summary Report’, матрица прослеживаемости (TPLTD-062 ‘Traceability Matrix’), и валидационный сертификат (TPL-TD-061 ‘Validation Certificate’).
Квалификация эксплуатации (PQ) – приемочное тестирование – проводится после успешного завершения квалификации функционирования согласно шаблонам TPL-TD-023 ‘User Acceptance Test Scenario’, TPL-CSM-037 ‘Screenshots of User Acceptance Test Scenario Execution’. Квалификация проводится в формате пользовательского тестирования согласно заранее разработанным и утвержденным сценариям. По завершении эксплуатации оформляется отчет о проведенном тестировании.
5. Документация
Создание сопроводительной документации на разрабатываемые системы регламентируется SOP-TD-047 ‘Requirements Specification Development’. Перед разработкой системы производится сбор требований пользователя и их документирование в спецификации требований пользователя (User Requirements Specification, URS).
При необходимости в спецификацию включаются регуляторные требования.
Каждому требованию присваивается уникальный код.
После утверждения URS разрабатываются функциональная спецификация (Functional Requirements Specification, FRS) и конфигурационная спецификация (Configuration Requirements Specification), описывающие планируемую реализацию системы. Каждое требования проектных спецификаций имеет уникальный код и прослеживается к кодам пользовательских спецификаций.
6. Разработка
Разработка программного обеспечения регламентируется SOP-TD-013 ‘Software Development’, SOP-TD-033 ‘Change Management’, SOP-TD-049 ‘Production Release and Hotfix Management’. За разработку отвечают отделы разработки и конфигурирования ПО.
Жизненный цикл системы состоит их специфицирования, разработки, тестирования, эксплуатации и вывода из эксплуатации.
Проекты разработки разделяются на «внутреннюю» разработку, связанную с совершенствованием ядра системы (Baseline system) и «внешнюю» разработку – конфигурирование системы под запросы конкретного заказчика. Управление процессом «внешней» разработки регламентируется SOP-CSM -048 ‘Project Management’.
Процесс внесения изменений регламентируется SOP-TD-033 ‘Change Management’. Все изменения классифицируются по уровню риска в зависимости от степени влияния:
В ходе разработки и последующего тестирования для «внутренних» проектов используется трехсистемный ландшафт:
Для «внешних» проектов используется пятисистемный ландшафт:
Разработка кода регламентируется WP-TD-016 ‘Coding Standard’. Код должен быть надлежащим образом комментирован при отправке в систему контроля версий. Комментарий должен обязательно содержать идентификационный код проекта.
Разработанная система допускается к переносу на производственный сервер только в случае успешного прохождения тестирования.
Перенос системы на производственную среду документируется и согласуется с клиентом. Выпускаются формы одобрения переноса проекта (Production Approval Form) и форма выпуска проекта (FRM-CSM-019 ‘Release Note’).
7. Контроль качества
Тестирование разработанных компьютеризированных систем регламентируется WP-TD-062 ‘System Testing’. Ответственный тестировщик пишет тестовые сценарии и проводит тестирование. По результатам тестирования оформляется протокол выполнения тестового сценария согласно шаблону TPL-TD-029 ‘Test Cases Execution Protocol’.
В случае позитивного результата тестирования разрешается перенос на среду контроля качества. В случае негативного результата тестирования код передается на доработку и затем тестирование повторяется.
8. Претензии
Претензии на качество программного обеспечения принимаются службой поддержки пользователей (хелпдеск). Процесс приема претензий и запросов пользователей регламентируется SOP-TD-038 ‘System Support’ и WP-TD-053 ‘Helpdesk Service Monitoring’.
Служба поддержки имеет экстренный телефон, который работает в круглосуточном режиме.
Рутинные запросы принимаются по электронной почте helpdesk@flexdatabases.com.
После получения претензии или запроса пользователей присваивается номер обращения, по которому можно отследить историю рассмотрения обращения.
Проводится оценка риска и в зависимости от приоритета риска определяется время для решения проблемы.
9. Процедура самоинспекции
Внутренние аудиты проводятся для всех критичных с точки зрения системы качества подразделений. Так же проводятся аудиты проектной документации.
- ФЛЕКС Фармаконадзор
- ФЛЕКС Ведение расходов
- ФЛЕКС Управление персоналом
- ФЛЕКС Управление активностями монитора
- ФЛЕКС Хранение проектной документации
- ФЛЕКС Управление центрами и исследователями
- ФЛЕКС Учёт набора и визитов субъектов и выставление счетов
- ФЛЕКС Система управления обучением
- ФЛЕКС Проектный каталог
- ФЛЕКС Конструктор отчётов
- ФЛЕКС Учёт рабочего времени
- ФЛЕКС Управление проектами и бюджетами
- ФЛЕКС Электронная система управления бизнес-процессами
Информация о стоимости программного обеспечения:
Стоимость модуля системы рассчитывается индивидуально на основании особенностей и потребностей каждого клиента отдельно. Для уточнения цены пишите на электронную почту contact@flexdbs.ru.
Краткое описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения:
1. Система управления качеством
На Предприятии создана и функционирует документально определенная система управления качеством. Область применения системы управления качества Предприятия включает в себя все подразделения, задействованные на всех этапах жизненного цикла программного обеспечения.
Обеспечение функционирования системы качества и контроль эффективности функционирования осуществляет подразделения обеспечения качества (Quality Assurance).
На Предприятии разработано и поддерживается в рабочем состоянии Руководство по качеству (POL-QA-005 ‘Quality Policy’), которое описывает систему управления качеством, политику и цели в области качества, функции подразделения качества, распределение ответственности руководства.
Подразделение обеспечения качества независимо от производства и отвечает за разработку и поддержание системы качества в соответствии с нормативными требованиями.
На Предприятии используется трехуровневая система документации, включающая верхний уровень (Policy), средний уровень (СОП и рабочие практики/инструкции), и нижний уровень (формы, шаблоны, информационные документы). Документы среднего и нижнего уровней структурированы по функциям/отделам: обеспечения качества, технический отдел, управление персоналом, управление проектами и административный отдел.
Ежегодно проводится обзор системы качества со стороны руководства, в формате встречи руководства и сотрудников подразделения обеспечения качества, с последующей регистрацией результатов встречи.
Система качества регулярно оценивается в ходе внешних и внутренних аудитов. За время работы Предприятие успешно прошло 35 внешних аудитов, включая аудиты независимыми аудиторскими компаниями.
2. Обучение и квалификация сотрудников
На Предприятии внедрена и функционирует система обучения персонала, регламентированная SOP-HRT-012 ‘Training and Qualification Compliance’. Объем необходимого обучения определяется матрицей обучения.
Тренинг осуществляется в следующих формах:
- самостоятельное изучение документации в электронной системе обучения (Learning Management System)
- внутреннее лекционное обучение
- внешнее обучение.
- актуальное резюме
- должностная инструкция
- записи об обучении в электронном или бумажном виде.
3. Стек технологий
Разработка программного обеспечения осуществляется на базе Microsoft Visual Studio ASP.Net Framework v 4.0 с использованием Microsoft C#. База данных – Firebird.
Контроль версий и обеспечение командной работы обеспечивается с помощью программного обеспечения Microsoft Team Foundation Server.
Данные компьютеризированные системы относятся к категории 1 по GAMP5, установлены согласно требованиям поставщика и имеют зафиксированный номер версии.
4. Валидация
Валидация программного обеспечения проводится согласно SOP-TD-036 ‘System Validation’. Составляется вариационный план согласно шаблону TPL-TD-059 ‘Validation Plan’, который содержит описание системы, оценку критичности системы, категоризацию, организационную структуру и требования к основным этапам валидации.
Квалификация проекта проводится после построения системы. В случае изменений исходного кода системы проводится обзор кода (code review). Обзор кода представляет собой анализ полноты трансляции проектных требований и соответствия стандартам кодирования. По завершении оформляется отчет об обзоре кода согласно шаблону TPL-TD056 (Code Review Report).
Квалификация монтажа (IQ) проводится после установки компьютеризированной системы согласно шаблонам TPL-TD-034 ‘Installation Qualification (virtual machine)’, TPL-TD-035 ‘Installation Qualification (application)’.
Проводится проверка как установленных виртуальных машин, так и корректность установки приложения. Предусмотрена также квалификация установки тестового окружения. По завершении квалификации монтажа оформляется отчет о проведенном тестировании согласно шаблону TPL-TD-036 ‘Installation Report’.
Квалификация функционирования (OQ) проводится после успешного завершения квалификации монтажа согласно шаблонам TPL-TD-027 ’OQ Test Plan’, TPL-TD-030 ‘OQ Testing Summary Report’, TPL-TD-028 ‘Test Cases’, TPL-TD-029 ‘Test Cases Execution Protocol’. Проводится тестирование функционала системы согласно предварительно разработанным сценариям тестирования в тестовом окружении. При разработке тестовых сценариев используется парадигма тестирования черного ящика, то есть тестировщик не знает о программной структуре тестируемой программы. Используются как позитивные, так и негативные (провокационные) тесты. По завершении квалификации функционирования оформляется отчет о проведенном тестировании.
После завершения всех этапов валидации оформляется итоговый валидационный отчет согласно шаблону TPL-TD-060 ‘Validation Summary Report’, матрица прослеживаемости (TPLTD-062 ‘Traceability Matrix’), и валидационный сертификат (TPL-TD-061 ‘Validation Certificate’).
Квалификация эксплуатации (PQ) – приемочное тестирование – проводится после успешного завершения квалификации функционирования согласно шаблонам TPL-TD-023 ‘User Acceptance Test Scenario’, TPL-CSM-037 ‘Screenshots of User Acceptance Test Scenario Execution’. Квалификация проводится в формате пользовательского тестирования согласно заранее разработанным и утвержденным сценариям. По завершении эксплуатации оформляется отчет о проведенном тестировании.
5. Документация
Создание сопроводительной документации на разрабатываемые системы регламентируется SOP-TD-047 ‘Requirements Specification Development’. Перед разработкой системы производится сбор требований пользователя и их документирование в спецификации требований пользователя (User Requirements Specification, URS).
При необходимости в спецификацию включаются регуляторные требования.
Каждому требованию присваивается уникальный код.
После утверждения URS разрабатываются функциональная спецификация (Functional Requirements Specification, FRS) и конфигурационная спецификация (Configuration Requirements Specification), описывающие планируемую реализацию системы. Каждое требования проектных спецификаций имеет уникальный код и прослеживается к кодам пользовательских спецификаций.
6. Разработка
Разработка программного обеспечения регламентируется SOP-TD-013 ‘Software Development’, SOP-TD-033 ‘Change Management’, SOP-TD-049 ‘Production Release and Hotfix Management’. За разработку отвечают отделы разработки и конфигурирования ПО.
Жизненный цикл системы состоит их специфицирования, разработки, тестирования, эксплуатации и вывода из эксплуатации.
Проекты разработки разделяются на «внутреннюю» разработку, связанную с совершенствованием ядра системы (Baseline system) и «внешнюю» разработку – конфигурирование системы под запросы конкретного заказчика. Управление процессом «внешней» разработки регламентируется SOP-CSM -048 ‘Project Management’.
Процесс внесения изменений регламентируется SOP-TD-033 ‘Change Management’. Все изменения классифицируются по уровню риска в зависимости от степени влияния:
- влияние на бизнес
- влияние на группу
- влияние на пользователя.
- простое конфигурирование, в случае пользовательского конфигурирования
- сложное конфигурирование, в случае административного конфигурирования
- разработка на заказ, в случае внесения изменений в исходный код.
В ходе разработки и последующего тестирования для «внутренних» проектов используется трехсистемный ландшафт:
- среда разработки
- среда тестирования
- среда контроля качества
Для «внешних» проектов используется пятисистемный ландшафт:
- среда разработки
- среда тестирования
- среда контроля качества
- промежуточная производственная среда
- производственная среда.
Разработка кода регламентируется WP-TD-016 ‘Coding Standard’. Код должен быть надлежащим образом комментирован при отправке в систему контроля версий. Комментарий должен обязательно содержать идентификационный код проекта.
Разработанная система допускается к переносу на производственный сервер только в случае успешного прохождения тестирования.
Перенос системы на производственную среду документируется и согласуется с клиентом. Выпускаются формы одобрения переноса проекта (Production Approval Form) и форма выпуска проекта (FRM-CSM-019 ‘Release Note’).
7. Контроль качества
Тестирование разработанных компьютеризированных систем регламентируется WP-TD-062 ‘System Testing’. Ответственный тестировщик пишет тестовые сценарии и проводит тестирование. По результатам тестирования оформляется протокол выполнения тестового сценария согласно шаблону TPL-TD-029 ‘Test Cases Execution Protocol’.
В случае позитивного результата тестирования разрешается перенос на среду контроля качества. В случае негативного результата тестирования код передается на доработку и затем тестирование повторяется.
8. Претензии
Претензии на качество программного обеспечения принимаются службой поддержки пользователей (хелпдеск). Процесс приема претензий и запросов пользователей регламентируется SOP-TD-038 ‘System Support’ и WP-TD-053 ‘Helpdesk Service Monitoring’.
Служба поддержки имеет экстренный телефон, который работает в круглосуточном режиме.
Рутинные запросы принимаются по электронной почте helpdesk@flexdatabases.com.
После получения претензии или запроса пользователей присваивается номер обращения, по которому можно отследить историю рассмотрения обращения.
Проводится оценка риска и в зависимости от приоритета риска определяется время для решения проблемы.
9. Процедура самоинспекции
Внутренние аудиты проводятся для всех критичных с точки зрения системы качества подразделений. Так же проводятся аудиты проектной документации.