О продукте

Общее описание системы.

Gnezdo.online - система автоматического распределения и показа рекламных материалов на веб-сайтах. Данная система позволяет размещать рекламные материалы на веб-страницах существующих сайтов.

Система позволяет автоматически встраивать различные блоки с рекламными материалами в существующие веб-страницы и проводить автоматическую ротацию рекламных материалов.

Доступные типы рекламных блоков:

1. In-content - Баннерная или видео реклама в тексте статьи.
2. Full-screen - полноэкранный баннер, который появляется поверх основного контента сайта на короткий промежуток времени. Баннер закрывается по окончании времени обратного отсчета, при клике на кнопку «Пропустить рекламу», либо при переходе на сайт рекламодателя.
3. Sticker - это современный формат интернет рекламы, который не останется незамеченным пользователем ни на одном мобильном устройстве. Стикер представляет собой интерактивный баннер, который размещается поверх контента на всю ширину экрана. При скролле стикер не изменяет своего положения и всегда находится перед глазами пользователя.
4. NatiGloss - адаптивный баннерный формат, размещается в теле или под материалом.
5. NatiVideo - адаптивный видео формат с текстом или без, размещается в теле или под материалом.

ПО Gnezdo.online не может быть использовано для настройки и запуска рекламных кампаний и загрузки баннеров.

Рекламные материалы, используемые для осуществления работы ПО Gnezdo.online запрашиваются и получаются в результате Server – to – Server запросов, осуществляемых автоматически. Полный список систем, отправляющих рекламные материалы для работы Gnezdo.online можно узнать, сделав запрос, отправив сообщение на почту anton.barsukov@nox.ru

Добавление веб-сайта в систему.

1. Пройти регистрацию на сайте gnezdo.online и модерацию менеджером.
2. Разместить на сайте код вызова выбранной рекламы.

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

Адаптация рекламных материалов для работы в системе

В качестве рекламных материалов, используемых при работе ПО Gnezdo.online могут быть использованы файлы:

Для баннерных форматов:

HTML-баннер, весом не более 2 МБ. Баннер должен быть «тянущимся» и иметь размеры сторон «100% на 100%». В секции баннера должен быть установлен скрипт:

<script src='https://news.2xclick.ru/loader.js' async></script>

Кроме того, для корректного отслеживания взаимодействий с баннером, при осуществлении события «Клик» должна вызываться JavaScript – функция:

function click(hypeDocument, element, event){
event.stopPropagation();
window.banner_api.sendEvent('click')
}

Для видео форматов:

Баннер, подготовленный по стандарту VAST 3.0, общим весом не более 5 МБ.

При использовании в финальном тэге HTML – баннеров, всекциях всех баннеров должны быть установлены скрипты:

<script src='https://news.2xclick.ru/loader.js' async></script>

Кроме того, для корректного отслеживания взаимодействий с баннером, при осуществлении события «Клик» должна вызываться JavaScript – функция:

function click(hypeDocument, element, event){
event.stopPropagation();
window.clientVPAIDApi.sendEvent('click');
}

В случае возникновения вопросов по подготовке креативов вы можете обратиться по почтовому адресу: anton.barsukov@nox.ru

Описание жизненного цикла разработки и эксплуатации программного обеспечения Gnezdo.online

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

1 Общие сведения о документе

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

2 Общие сведения о программном обеспечении

Gnezdo.online - Система автоматического распределения и показа рекламных материалов на веб-сайтах. Данная система позволяет размещать рекламные материалы на веб-страницах существ

3 Процессы, обеспечивающие жизненный цикл программного обеспечения

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

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

3.1 Процессы реализации программных средств

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

1.1.1 Процесс реализации программных средств

1.1.1.1 Цель

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

1.1.1.2 Выходы

В результате успешного осуществления процесса реализации программных средств происходит:

1. определение стратегии реализации;
2. определение ограничений по технологии реализации проекта;
3. изготовление программных элементов системы;

4. передача изготовленных программных элементов в систему контроля версий.

В дополнение к этим действиям процесс реализации программных средств имеет следующие процессы более низкого уровня:

1. процесс анализа требований к программным средствам;
2. процесс проектирования архитектуры программных средств;
3. процесс детального проектирования программных средств;
4. процесс конструирования программных средств;
5. процесс комплексирования программных средств;
6. процесс квалификационного тестирования программных средств.

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

1.1.2 Процесс анализа требований к программным средствам

1.1.2.1 Цель

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

1.1.2.2 Выходы

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

1. определяются требования к программным элементам системы и их интерфейсам;
2. требования к программным средствам анализируются на корректность и тестируемость;
3. осознается воздействие требований к программным средствам на среду функционирования;
4. устанавливается совместимость и прослеживаемость между требованиями к программным средствам и требованиями к системе;
5. определяются приоритеты реализации требований к программным средствам;
6. требования к программным средствам принимаются и обновляются по мере необходимости;
7. оцениваются изменения в требованиях к программным средствам по стоимости, графикам работ и техническим воздействиям;
8. требования к программным средствам воплощаются в виде базовых линий и доводятся до сведения заинтересованных сторон.

1.1.2.3 Виды деятельности и задачи

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

1.1.2.3.1 Анализ требований

Данный вид деятельности состоит из решения следующих задач:

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

1.1.2.3.1.2 Требования должны уточняться.

1.1.2.3.1.3 Системные требования должны анализироваться на корректность и тестируемость.

1.1.2.3.1.4 Требования должны расставляться по приоритетам, утверждаться и обновляться.

1.1.2.3.1.5 Системные требования должны согласовываться с базовой линией требований заказчика.

1.1.2.3.2 Вычисление оптимального решения

Данный вид деятельности состоит из решения следующих задач:

1.1.2.3.2.1 Должно формироваться и оптимизироваться предпочитаемое проектное решение.

1.1.2.3.2.2 Должна происходить оценка затрат и рисков.

1.1.3 Процесс проектирования архитектуры программных средств

1.1.3.1 Цель

Цель процесса проектирования архитектуры программных средств заключается в определении того, как системные требования следует распределить относительно элементов системы.

1.1.3.2 Выходы

В результате успешной реализации процесса проектирования архитектуры программных средств:

1. разрабатывается проект архитектуры программных средств и устанавливается базовая линия, описывающая программные составные части, которые будут реализовывать требования к программным средствам;
2. определяются внутренние и внешние интерфейсы каждой программной составной части;
3. устанавливаются согласованность и прослеживаемость между требованиями к программным средствам и программным проектом.

1.1.3.3 Виды деятельности и задачи

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

1.1.3.3.1Проектирование архитектуры

Данный вид деятельности состоит из решения следующих задач:

1.1.3.3.1.1 Должна происходить разработка архитектурного проекта системы, в соответствии с которым выполняется идентификация верхнего уровня архитектуры и элементов системы и удовлетворяются заданные требования.

1.1.3.3.1.2 Требования должны распределяться по элементам системы.

1.1.3.3.1.3 Должны определяться внутренние и внешние интерфейсы каждого системного элемента.

1.1.3.3.1.4 Должна произойти верификация между системными требованиями и архитектурой системы.

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

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

3.1.1 Процесс детального проектирования программных средств

1.1.3.4 Цель

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

1.1.3.5 Выходы

Результатом успешного осуществления процесса детального проектирования программных средств является:

1. разработка детального проекта каждого программного компонента, описывающего создаваемые программные модули;
2. определение внешних интерфейсов каждого программного модуля;
3. установка совместимости и прослеживаемости между детальным проектированием, требованиями и проектированием архитектуры.

1.1.3.6 Виды деятельности и задачи

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

1.1.3.6.1 Детальное проектирование

Данный вид деятельности состоит из решения следующих задач:

1.1.3.6.1.1 Детальный проект должен быть разработан для каждого программного компонента программной составной части.

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

1.1.3.6.1.3 Детальный проект базы данных должен быть разработан и документально оформлен.

1.1.3.6.1.4 Пользовательская документация должна совершенствоваться по мере необходимости.

1.1.3.6.1.5 Должны определяться и документироваться требования к

тестированию и графики работ по тестированию программных блоков.

1.1.3.6.1.6 Должны обновляться требования к тестированию и графики работ по комплексированию программных средств.

1.1.3.6.1.7 Должны оцениваться требования к тестированию и детальный проект для программных средств.

1.1.3.6.1.8 Результаты оценки должны быть оформлены документально.

3.1.2 Процесс конструирования программных средств

1.1.3.7 Цель

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

1.1.3.8 Выходы

В результате успешного осуществления процесса конструирования программных средств:

1. определяются критерии верификации для всех программных блоков относительно требований;
2. изготавливаются программные блоки, определенные проектом;
3. устанавливается совместимость и прослеживаемость между программными блоками, требованиями и проектом;
4. завершается верификация программных блоков относительно требований и проекта.

1.1.3.9 Виды деятельности и задачи

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

1.1.3.9.1 Конструирование программных средств Данный вид деятельности состоит из решения следующих задач:

1.1.3.9.1.1 Должны быть разработаны и документально оформлены программные блоки, база данных и процедуры по их тестированию.

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

1.1.3.9.1.3 Документация пользователя должна быть улучшена при необходимости.

1.1.3.9.1.4 Требования к тестированию и графики работ по комплексированию программных средств должны иметь возможность совершенствоваться.

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

3.1.3 Процесс комплексирования программных средств

1.1.3.10 Цель

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

1.1.3.11 Выходы

В результате успешного осуществления процесса комплексирования программных средств:

1. разрабатывается стратегия комплексирования для программных блоков, согласованная с программным проектом и с требованиями к программным средствам, расположенными по приоритетам;
2. разрабатываются критерии верификации для программных составных частей, которые гарантируют соответствие требованиям к программным средствам;
3. изготавливаются программные составные части, определенные стратегией комплексирования;
4. регистрируются результаты комплексного тестирования;
5. устанавливаются согласованность и прослеживаемость между программным проектом и программными составными частями;
6. разрабатывается и применяется стратегия регрессии для повторной верификации программных составных частей при возникновении изменений в программных блоках.

1.1.3.12 Виды деятельности и задачи

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

1.1.3.12.1 Комплексирование программных средств Данный вид деятельности состоит из решения следующих задач:

1.1.3.12.1.1 Должен быть разработан план комплексирования для объединения программных блоков и программных компонентов в программную составную часть. План должен быть оформлен документально.

1.1.3.12.1.2 Программные блоки, программные компоненты и тесты должны быть объединены. Результаты комплексирования и тестирования должны быть оформлены документально.

1.1.3.12.1.3 Пользовательская документация должна обновляться по мере необходимости.

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

1.1.3.12.1.5 Должна произойти оценка плана комплексирования, проекта, кода, тестов, результатов тестирования и пользовательской документации. Результаты оценки должны быть оформлены документально.

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

1.1.3.13 Цель

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

1.1.3.14 Выходы

В результате успешного осуществления процесса квалификационного тестирования программных средств:

1. определяются критерии для комплектованных программных средств с целью демонстрации соответствия требованиям к программным средствам;
2. комплектованные программные средства верифицируются с использованием определенных критериев;
3. записываются результаты тестирования;
4. разрабатывается и применяется стратегия регрессии для повторного тестирования комплектованного программного средства при проведении изменений в программных составных частях.

1.1.3.15 Виды деятельности и задачи

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

1.1.3.15.1 Квалификационное тестирование программных средств Данный вид деятельности состоит из решения следующих задач:

1.1.3.15.1.1 Критерии для оценки соответствия системным требованиям должны быть разработаны;

1.1.3.15.1.2 Системы должна пройти тестирование после сборки;

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

3.2 Процессы поддержки программных средств

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

3.2.1 Процесс менеджмента документации программных средств

1.1.3.16 Цель

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

1.1.3.17 Выходы

В результате успешного осуществления процесса менеджмента документации программных средств происходит:

1. разработка стратегии идентификации документации, которая реализуется в течение жизненного цикла программного продукта или услуги;
2. определение стандартов, которые применяются при разработке программной документации;
3. определение документации, которая производится процессом или проектом;
4. определение и утверждение содержания и целей всей документации;
5. разработка документации и организация доступа к ней в соответствии с определенными стандартами;
6. сопровождение документации в соответствии с определенными критериями.

1.1.3.18 Виды деятельности и задачи

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

1.1.3.18.1 Разработка документации

Данный вид деятельности состоит из решения следующих задач:

1.1.3.18.1.1 Стратегия менеджмента документации должна быть

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

1. заголовок или название;
2. цели и содержание;
3. круг пользователей, которым она предназначена;
4. процедуры и ответственность при формировании исходных данных, разработке, ревизиях, модификации, утверждении, производстве, хранении, распределении, сопровождении и менеджменте конфигурации;
5. версионность документов с указанием даты создания версии.

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

1.1.3.18.1.3 Источник и правомерность использования исходных данных для документов должны быть подтверждены. Могут применяться автоматизированные средства поддержки документирования.

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

1.1.3.18.1.5 Документы должны изготавливаться и поставляться в соответствии с планом.

3.2.2 Процесс менеджмента конфигурации программных средств

1.1.3.19 Цель

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

1.1.3.20 Выходы

В результате успешного осуществления процесса менеджмента конфигурации программных средств происходит:

1. разработка плана менеджмента конфигурации программных средств;
2. идентификация, определение и ввод в базовой линии системы составных частей, порождаемых процессом или проектом;
3. контроль модификаций и выпусков этих составных частей;
4. обеспечение доступности модификаций и выпусков для заинтересованных сторон;
5. регистрация и предоставление информации о статусе составных частей и модификаций;
6. обеспечение завершенности и согласованности составных частей;
7. контроль хранения, обработки и поставки составных частей.

1.1.3.21 Виды деятельности и задачи

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

1.1.3.21.1 Разработка конфигураций

Данный вид деятельности состоит из решения следующих задач:

1.1.3.21.1.1 План менеджмента конфигурации программных средств должен описывать:

1. действия менеджмента конфигурации;
2. процедуры и графики работ для выполнения этих действий;
3. организацию (организации), ответственную за выполнение этих действий, и ее отношения с другими организациями, например, разрабатывающими или сопровождающими программные средства.

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

1.1.3.21.2 Управление конфигурацией

Данный вид деятельности состоит из решения следующих задач:

1.1.3.21.2.1 Управление конфигурацией должно осуществляется на основании плана и включать в себя:

1. идентификацию и регистрацию запросов на изменения;
2. анализ и оценка изменений;
3. принятие или отклонение запросов;
4. реализацию, верификацию и выпуск модифицированной составной части;
5. проверочныеиспытания,наоснованиикоторыхможно прослеживать каждую модификацию, ее причины и полномочия на проведение изменений;
6. управление и аудит всего доступа к контролируемым программным составным частям, связанным с выполнением критических функций по безопасности или защите.

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

1.1.3.21.3 Поддержка конфигурацией

Данный вид деятельности состоит из решения следующей задачи:

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

3.2.3 Процесс обеспечения гарантии качества программных средств

1.1.3.22 Цель

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

1.1.3.23 Выходы

В результате успешного осуществления процесса обеспечения гарантии качества программных средств происходит:

1. разработка стратегии обеспечения гарантии качества;
2. создание и поддержка свидетельств гарантии качества;
3. идентификация и регистрация проблем и (или) несоответствий с требованиями;
4. верификация соблюдения продукцией, процессами и действиями соответствующих стандартов, процедур и требований.

1.1.3.24 Виды деятельности и задачи

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

1.1.3.24.1 Обеспечение гарантий качества

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

1.1.3.24.1.2 План проведения действий и задач процесса гарантии качества должен реализовываться и сопровождаться в течение срока жизни контракта. План включает в себя:

1. стандарты качества, методологии, процедуры и инструментарий для выполнения действий по обеспечению гарантии качества (или ссылки на официальную документацию организации);
2. процедуры пересмотра контракта и их координацию;
3. процедуры идентификации, сбора, регистрации, сопровождения и распространения записей о качестве;
4. ресурсы, графики работ и ответственность за проведение действий по обеспечению гарантии качества;
5. выбранные действия и задачи из поддерживающих процессов.

3.2.4 Процесс верификации программных средств

1.1.3.25 Цель

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

1.1.3.26 Выходы

В результате успешного осуществления процесса верификации программных средств происходит:

1. разработка и осуществление стратегии верификации;
2. определение критериев верификации всех необходимых программных рабочих продуктов;
3. выполнение требуемых действий по верификации;
4. определение и регистрация дефектов;
5. предоставление результатов верификации заказчику и другим заинтересованным сторонам.

1.1.3.27 Виды деятельности и задачи

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

1.1.3.27.1 Верификация программных средств

Данный вид деятельности состоит из решения следующих задач:

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

1.1.3.27.1.2 Требования должны быть верифицированы с учетом следующих критериев:

1. системные требования являются согласованными, выполнимыми и тестируемыми;
2. системные требования распределены по техническим, программным элементам и ручным операциям согласно критериям проекта;
3. требования к программным средствам согласованы, выполнимы, проверяемы и точно отражают системные требования;
4. требования к программным средствам, связанные с безопасностью, защитой и критичностью, являются корректными.

1.1.3.27.1.3 Проект должен быть верифицирован с учетом следующих критериев:

1. проект корректируется и согласуется с требованиями;
2. проект осуществляет последовательность событий, входы, результаты, интерфейсы, логические связи, назначение сроков и размеров финансирования, а также обнаружение ошибок, локализацию и восстановление;
3. выбранный проект может быть выведен из требований;
4. проект корректно реализует требования по безопасности, защищенности и другим критическим свойствам.

1.1.3.27.1.4 Код должен быть верифицирован с учетом следующих критериев:

1. код является следствием проекта и требований тестируемости и правильности. Он соответствует установленным требованиям и стандартам, относящимся к кодированию;
2. код осуществляет последовательность событий, согласованные интерфейсы, корректные данные и поток команд управления, завершений, адекватного распределения времени и размеров финансирования, а также определение ошибок, локализацию и восстановление;
3. выбранный код может следовать из проекта или требований;
4. код корректно реализует требования по безопасности, защищенности и другим критическим свойствам.

1.1.3.27.1.5 Комплексирование должно быть верифицировано с учетом следующих критериев:

1. программные компоненты и модули каждого программного элемента полностью и корректно комплектуются в программный элемент.
2. технические и программные элементы, а также ручные операции системы комплексируются в систему;
3. задачи комплексирования выполняются в соответствии с планом комплексирования.

1.1.3.27.1.6 Документация должна быть верифицирована с учетом следующих критериев:

1. документация является адекватной, полной и согласованной;
2. подготовка документации осуществляется своевременно;
3. менеджмент конфигурации документов следует установленным процедурам.

3.2.5 Процесс валидации программных средств

1.1.3.28 Цель

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

1.1.3.29 Выходы

В результате успешного осуществления процесса валидации программных средств происходит:

1. разработка и реализация стратегии валидации;
2. определение критериев валидации для всей требуемой рабочей продукции;
3. идентификация и регистрация проблем;
4. обеспечение свидетельств того, что созданные рабочие программные продукты пригодны для применения по назначению;
5. предоставление результатов действий по валидации заказчику и другим заинтересованным сторонам.

1.1.3.30 Виды деятельности и задачи

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

1.1.3.30.1 Валидация программных средств

Данный вид деятельности состоит из решения следующих задач:

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

1.1.3.30.1.2 План должен включать в себя:

1. элементы, подвергаемые валидации;
2. задачи валидации, которые будут выполняться;
3. ресурсы, ответственности и графики выполнения работ по валидации;
4. процедуры передачи отчетов приобретающей стороне и другим сторонам.

1.1.3.30.1.3 План должен быть выполняем. Проблемы и несоответствия, обнаруженные в процессе работ по валидации, передаются в процесс решения проблем в программных средствах.

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

1.1.3.30.1.5 План валидации должен включать в себя следующие проверки:

1. тестирование в условиях повышенной нагрузки, граничных значений параметров и необычных входов;
2. тестирование программного продукта на его способность изолировать и минимизировать влияние ошибок; то есть осуществлять плавную деградация после отказов, обращение к заказчику за помощью в условиях повышенной нагрузки, граничных значений параметров и необычных входов;
3. тестирование того, что основные пользователи могут успешно решать намеченные задачи, используя данный программный продукт;
4. тестирование программного продукта на соответствие своему назначению;
5. тестирование программного продукта в выбранных областях заданной среды применения по назначению.

3.2.6 Процесс ревизии программных средств

1.1.3.31 Цель

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

1.1.3.32 Выходы

В результате успешного осуществления процесса ревизии программных средств происходит:

1. выполнение технических ревизий и ревизий менеджмента на основе потребностей проекта;
2. оценка состояния и результатов действий процесса посредством ревизии деятельности;
3. предоставление результатов ревизии всем участвующим сторонам;
4. идентификация и регистрация рисков и проблем.

1.1.3.33 Виды деятельности и задачи

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

1.1.3.33.1 Ревизия программных средств

Данный вид деятельности состоит из решения следующих задач:

1.1.3.33.1.1 Периодические ревизии должны проводиться в

предварительно определенные сроки, указанные в плане проекта.

1.1.3.33.1.2 Для проведения каждой ревизии должны устанавливаться:

1. повестка дня заседания;
2. состав программных продуктов (результатов деятельности);
3. проблемы, подлежащие обсуждению;
4. области применения и процедуры;
5. исходные и итоговые критерии для ревизии.

1.1.3.33.1.3 Проблемы, выявленные при проведении ревизии, должны быть зарегистрированы и переданы в процесс решения проблем в программных средствах.

1.1.3.33.1.4 Результаты ревизии должны быть задокументированы. Дается оценка адекватности ревизии. Результаты ревизии предоставляются заинтересованным сторонам. Участвующие стороны согласовывают итоговый результат ревизии, ответственность за позиции, требующие действий, и критерии завершения.

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

1. активизацию работ в соответствии с планом, основанную на оценке деятельности или состояния программного продукта;
2. поддержание глобального управления проектом посредством соответствующего распределения ресурсов;
3. изменение направления развития проекта или определение потребности в дополнительном планировании;
4. оценку и руководство решением вопросов, связанных с риском, которые могут угрожать успеху проекта.

1.1.3.33.1.6 Технические ревизии должны проводиться для оценки программных продуктов или услуг с позиции следующих критериев:

1. полнота комплектации;
2. соответствие принятым стандартам и спецификациям;
3. соответствие процессу менеджмента конфигурации;
4. соответствие установленному графику работ.

3.2.7 Процесс аудита программных средств

1.1.3.34 Цель

Цель процесса аудита программных средств заключается в независимом определении соответствия выбранных продуктов и процессов требованиям, планам и соглашениям.

1.1.3.35 Выходы

В результате успешного осуществления процесса аудита программных средств происходит:

1. разработка и осуществление стратегии аудита;
2. определение соответствия отобранных рабочих программных продуктов, услуг или процессов требованиям, планам и соглашениям;
3. выявление проблем и передача их для решения ответственным сторонам.

1.1.3.36 Виды деятельности и задачи

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

1.1.3.36.1 Аудит программных средств

Данный вид деятельности состоит из решения следующих задач:

1.1.3.36.1.1 Аудиторские проверки должны проводиться в

предварительно установленные контрольные сроки, указанные в плане проекта.

1.1.3.36.1.2 По каждому аудиту должны быть установлены:

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

1.1.3.36.1.3 Проблемы, выявленные при проведении аудитов, должны передаваться процессу решения проблем в программных средствах.

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

3.2.8 Процесс решения проблем в программных средствах

1.1.3.37 Цель

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

1.1.3.38 Выходы

В результате успешного осуществления процесса решения проблем в программных средствах происходит:

1. разработка стратегии менеджмента проблем;
2. регистрация, идентификация и классификация проблем;
3. анализ и оценка проблем для определения приемлемого решения (решений);
4. выполнение решений проблем;
5. отслеживание проблем вплоть до их закрытия.

1.1.3.39 Виды деятельности и задачи

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

1.1.3.39.1 Решение проблем в программных средствах

Данный вид деятельности состоит из решения следующих задач:

1.1.3.39.1.1 Процесс решения проблем в программных средствах должен быть циклическим. Обнаруженные в других процессах проблемы вводятся в процесс решения проблем.

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

1.1.3.39.1.3 При необходимости заинтересованные стороны должны информироваться о существовании проблем.

1.1.3.39.1.4 Должен проводиться анализ тенденций в известных проблемах. Устанавливаются и анализируются причины проблем, которые далее, если возможно, устраняются.

1.1.3.39.1.5 Состояние проблемы должно отслеживаться и отражаться в отчетах.

4 Требования к уровню квалификации специалистов

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

Создание и развитие ПО выполнялись и осуществляются силами специалистов разработки.

Для обеспечения надлежащего развития и поддержки ПО в команде разработчика присутствуют специалисты, отвечающие следующим требованиям:

1. знание JavaScript, Python
2. знание основных принципов работы HTTP и веб-сервисов;
3. знание архитектуры REST
4. опыт работы c OS семейства Windows и Linux, Mac.
5. опыт работы с базой данных MongoDB

В зависимости от технической необходимости поддержки проекта команда может оказывать поддержку в рабочее время (пн-пт с 10:00 до 19:00 GMT+3).

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

Фактический адрес расположения команды технической поддержки: 117420, г. Москва, ул. Профсоюзная, д.57, эт. 8, пом. I, комн. 29-31.

Связи с командой технической поддержки осуществляется через электронную почту: anton.barsukov@nox.ru.

Описание функциональных характеристик продукта Gnezdo.online.

Цели и назначение:

Gnezdo.online - система автоматического распределения и показа рекламных материалов на веб-сайтах. Данная система позволяет размещать рекламные материалы на веб-страницах существующих сайтов.

Система позволяет автоматически встраивать различные блоки с рекламными материалами в существующие веб-страницы

Ключевые функции для конечного пользователя:

• Автоматический поиск на веб-страницах подходящего места для размещения рекламных материалов
• Осуществление запроса на получение рекламных материалов
• Загрузка и расположение на веб-странице полученных рекламных материалов
• Автоматический выбор того, какой именно рекламный материал будет показан.
• Сбор данных о взаимодействиях с рекламными материалами

Основные функциональные характеристики:

• функционал продукта представлен JavaScript – скриптом, взаимодействующим с сервером с развернутой версией ПО. Выделенный визуальный интерфейс для взаимодействия с ПО отсутствует;
• ПО позволяет автоматически показывать и распределять рекламные материалы, полученные из сторонних источников, на Веб-страницах, подключенных к ПО;
• хранение информации в базе данных (БД);
• модификация веб-страниц;
• журналирование действий пользователей и работы системы.

Аппаратные требования для установки ПО:

Gnezdo.online - это веб-приложение из одного модуля.

Модуль 1. Loader.js использует JavaScript, устанавливается на Веб – страницы и обрабатывается на устройстве пользователя.

Требования для работы модуля 1.:

• ЦП: 1 ядро
• ОЗУ: 2 Гб
• Использование любого интернет браузера, выпущенного после 2012 года.

Прайс-лист к Лицензионному Договору на право использования программного обеспечения «Gnezdo.online: Система автоматического распределения и показа рекламных материалов на вебсайтах»

Скачать