Технические процессы. 
Проектирование информационных систем

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

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

В ходе реализации процесса:

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

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

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

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

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

2. Процесс анализа системных требований (6.4.2) состоит в преобразовании определенных требований правообладателей в совокупность необходимых системных технических требований, которыми будут руководствоваться в проекте системы.

Общие направления реализации процесса:

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

Виды деятельности и задачи процесса:

• — спецификация требований (анализ и документирование особенностей планируемого применения разрабатываемой системы, ее функций и возможностей, совокупности предъявляемых требований, проектных ограничений и квалификационных особенностей персонала);
• — оценивание требований па предмет их соответствия условиям заказчика на различных стадиях и этапах жизненного цикла ИС и их документирование.
• 3. Процесс проектирования архитектуры системы (6.4.3) заключается в определении способов распределения системных требований к ИС относительно ее элементов.

Основные операции процесса:

— определение архитектурного проекта ИС, в соответствие с которым идентифицируются элементы системы и удовлетворяются заданные требования;

установление функциональных и нефункциональных системных требований;

• — распределение требований по элементам ИС;
• — определение внутренних и внешних интерфейсов каждого системного элемента;
• — выполнение верификации между системными требованиями и архитектурой системы;
• — отслеживание требований, распределенных по системным элементам и их интерфейсам, относительно базовых требований заказчика;
• — поддержка согласованности и отслеживаемости между системными требованиями и архитектурным проектом системы;
• — отражение системных требований, конструкций, архитектурного проекта ИС и их взаимосвязей относительно базовой совокупности требований заказчика и доведение указанной информации до всех участвующих сторон;

включение в системный проект человеческого фактора, эргономических знаний, технических приемов, методов и средств;

определение и выполнение действий по проектированию, ориентированных на человека.

Виды деятельности и задачи процесса:

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

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

• 4. Процесс реализации (6.4.4) заключается в разработке требуемых элементов системы. Описание направлений, задач и действий процесса изложено в ходе раскрытия процесса реализации ПС, выполненных в виде программных продуктов или услуг, являющегося частным случаем данного процесса (см. процесс 7.1.1 из группы процессов реализации (разработки) ПС класса специальных процессов программных средств).
• 5. Процесс комплексирования системы (6.4.5) состоит в объединении системных элементов (включая составные части технических и программных средств, ручные операции и другие системы) для создания полноценной ИС, которая будет удовлетворять системному проекту и ожиданиям заказчика, выраженным в системных требованиях.

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

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

Виды деятельности и задачи процесса:

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

В ходе процесса:

• — разрабатываются критерии для оценки соответствия ИС системным требованиям;
• — комплексированная система тестируется согласно установленным критериям;
• — результаты тестирования документируются;
• — гарантируется готовность системы к поставке.

Виды деятельности и задачи процесса:

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

Настоящим стандартом допускается проведение процесса квалификационного тестирования системы в рамках процессов верификации или валидации ПС.

7. Процесс инсталляции ПС (6.4.7) заключается в установке программного продукта, удовлетворяющего заданным требованиям, в целевую среду применения.

В ходе процесса:

• — разрабатывается стратегия инсталляции ПС;
• — разрабатываются критерии для инсталляции ПС, предназначенные для демонстрации соответствия с требованиями к инсталляции ПС;
• — программный продукт инсталлируется в целевую среду;
• — обеспечивается готовность программного продукта для использования в среде его применения.

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

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

Основные операции процесса:

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

Основные операции процесса:

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

Виды деятельности и задачи процесса:

• — подготовка к функционированию (разработка плана и эксплуатационных стандартов действий оператора в случае возникновения проблем в ходе функционирования);
• — активизация и контроль функционирования;
• — применение по назначению;
• — поддержка заказчика содействием и консультированием;
• — решение проблем функционирования.
• 10. Процесс сопровождения ПС (6.4.10) заключается в обеспечении эффективной по затратам поддержки поставляемого программного продукта.

Основные операции процесса:

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

Виды деятельности и задачи процесса:

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

Основные операции процесса:

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

Виды деятельности и задачи процесса:

• — планирование прекращения применения ПС;
• — выполнение прекращения применения ПС.

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