Оптимизация бизнес-процесса разработки ПО для ЦЭ РФ

Обсуждение последних новостей отрасли.
Новости законодательства РФ в области связи.
Интересные статьи посвященные инфокоммуникациям в России.
Alex Rail
Форумчанин
 
Сообщения:
611
Зарегистрирован:
05 фев 2010

Благодарил (а): 0 раз.
Поблагодарили: 55 раз.

Оптимизация бизнес-процесса разработки ПО для ЦЭ РФ

СообщениеAlex Rail » Чт 05 окт, 2017 21:55 »

Оптимизация бизнес-процесса разработки ПО для цифровой экономики России

(вторая из четырех статей по совершенствованию процессов разработки и вывода на рынок ПО для цифровой экономики РФ, Маркетинг в разработке ПО для цифровой экономики РФ )

ПЛАН

1. Введение.
2. Оптимизация бизнес-процесса разработки ПО в компании.
2.1. Выбор модели процесса разработки ПО для разных типов продуктов компании.
2.2. Определение состава и ролевых функций членов команды разработчиков ПО.
2.3. Методология совершенствования бизнес-процесса разработки ПО в российских компаниях.
ПРИЛОЖЕНИЕ 1. Разработка требований к программному продукту в соответствие со стандартами IEEE.
ПРИЛОЖЕНИЕ 2. Пять уровней зрелости производителя ПО в соответствие с моделью CMMI.
ПРИЛОЖЕНИЕ 3. Сертификация ITIL разработчиков ПО для платформ цифровой экономики РФ.

1. Введение

Известно, что для успешного бизнеса ИТ-компании на конкурентном рынке необходимо координированное решение двух ключевых задач: менеджмент продукта и менеджмент компании.

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

• определении бизнес задач, стоящих перед заказчиками, которые могут быть решены с помощью нового продукта компании; на определении рыночных функциональных и технических требований к новому продукту.
• маркетинговых исследованиях по всей продуктовой линейке, с оформлением «Marketing Requirements Document».
• позиционировании новых продуктов (сегментирование рынка), определении их рыночной доли и стратегий продвижения на конкурентные и государственные сегменты (B2B, B2G, B2C) рынка, выполненные с учетом стратегических документов компании (рыночная-маркетинговая-конкурентная-ценовая стратегии на период 2017-2020 годы) и перспектив использования существующего технологического процесса по разработке и массовому выпуску ПО в компании на этот же период.

На базе этих маркетинговых исследований и документов определяются объемы продаж конкретных продуктов, определяются адекватные средства маркетинга, способствующие достижению обозначенных объемов продаж, включая методы «измерения» эффективности способов продвижения продуктов.

Для решения второй задачи можно воспользоваться методологией, известной из публикаций по менеджменту ИТ-компании: современными путями повышения конкурентоспособности (и капитализации) российского производителя ПО могут быть (по приоритетам):

• формирование, совершенствование и оптимизация бизнес-процесса разработки ПО,
• внедрение маркетинговой организации компании (МОК),
• внедрение системы менеджмента качества (СМК),
• внедрение риск –менеджмента в процесс разработки ПО и процессы планирования и операционного управления компанией,
• внедрение менеджмента информационной безопасности компании,
• внедрение системной инженерии в процесс разработки ПО,
• формирование корпоративной культуры, адекватной стратегическим целям и задачам компании.

Эти виды работ сегодня регламентируются международными стандартами, например: ISO 9001, ISO/IEC 31000, ISO/IEC 27001, ISO/IEC 15288 и их российскими аналогами. Мировая практика применения этих стандартов, для выполнения вышеприведенных работ, показала значимый коммерческий эффект, и акционеры ИТ-компаний в странах США и ЕС рассматривают такую деятельность как «средство» увеличения капитализации их бизнеса и, соответственно, инициируют инвестиции в эти работы.

В российских, нестабильных для долговременных инвестиций, «обстоятельствах» и в условиях преобладания государственного и низко конкурентного рынка, собственники компаний – производителей ПО «не всегда» рискуют делать «подобные» долговременные инвестиции в свой бизнес. Однако сегодня, в условиях:

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

можно ожидать, что всё больше российских акционеров ИТ-компаний «будет заинтересовано» в совершенствовании менеджмента компании с целью повышения прибыльности компании и, соответственно, её капитализации.

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

• необходимости повышения прозрачности и управляемости компании (например, вследствие недавней смены акционеров, или низких показателей бизнеса),
• необходимости встраивания бизнес-процессов производителя ПО в бизнес-процессы других компаний (например, при формировании ИТ-холдингов).

2. Оптимизация бизнес-процесса разработки ПО в компании-производителе.

В ИТ-индустрии, под оптимизацией процесса разработки ПО в компании понимают процесс, направленный на обеспечение предсказуемости, повторяемости и управляемости разработки ПО. Как показывает западный опыт, такая оптимизация позволяет производителям ПО увеличить отдачу на инвестиции до 40% за счет сокращения трудоемкости (времени) разработки ПО, без возрастания уровня процессных риска, снижения качества разработки и увеличения затрат.

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

Чтобы приступить к оптимизации бизнес-процесса по разработке ПО в компании, необходимо иметь сами эти процессы и их формализованное описание с учетом особенностей процесса разработки ПО в конкретной ИТ-компании, например, процедуры разработки требований к программному продукту (см. Приложение №1); выбора адекватных моделей организации процесса разработки ПО (тяжелые и/или легкие (lightweight) модели) и соответствующих программных инструментов для управления командой разработчиков (MS Visual Studio/SourceSafe, JIRA); методологии определения состава команды разработчиков и их функций (рекомендации мировых ИТ-лидеров (Microsoft, IBM) и/или уникальный опыт компании).

Качество разработки ПО в конкретных компаниях принято оценивать в соответствие с международными стандартами. Например, по модели CMMI, качество разработки ПО в компании принято ранжировать по пяти уровням зрелости (см. Приложение 2). Сегодня в России только три компании (холдинг ITG, компании ЛАНИТ и RUSSEE) соответствуют начальным уровням зрелости модели CMMI.

С другой стороны, как показывает международная и российская практики, для выполнения разработки ПО в соответствие с процессами уровней зрелости CMMI, в штате компании (на ТОР-х позициях и в функциональных подразделениях) должны находится сертифицированные разработчики ПО. Например, специалисты, имеющие уровни сертификации ITIL не ниже «ITIL Practitioner» (см. Приложение 3).

2.1. Выбор модели процесса разработки ПО для разных типов продуктов в компании.

В мировой ИТ-индустрии используется несколько методологий, которые определяют концепции, правила и приемы организации и выполнения разработок ПО: Microsoft Solution Framework (MSF), Capability Maturity Model Integration (CMMI), Agile, Rational Unified Process (RUP).

Опыт мировых и российских лидеров рынка ПО (например, компании Microsoft, IBM, Лаборатория Касперского) указывает, что именно такие методологии являются основой для создания реальных бизнес-процессов в конкретных компаниях и, в решающей мере, определяют эффективность их бизнеса. При этом важно отметить, что уже при составе команды разработчиков ПО более 5-8 человек, потери от отсутствия «внятного» регламента организации процесса разработки ПО становятся большими, в сравнении с затратами на регламентацию бизнес-процесса и внедрение специализированного ПО для автоматизации процесса разработки.

Из вышеприведенного следует, что формирование, совершенствование и оптимизация бизнес-процесса разработки ПО, на основе апробированных мировой практикой методологий (и/или своих уникальных методологий), является ключевой сегодняшней задачей обозначенных центров компетенции цифровой экономики и многих российских производителей ПО, которые будут участвовать в выполнении «Программы Цифровой Экономики России».

Первым шагом на этом пути является выбор модели организации работ при разработке разных типов ПО: базовые платформы, отраслевые решения, заказные разработки.

Модель «waterfall» предусматривает четкий последовательный переход от этапа к этапу и подходит для проектов по разработке базовых платформ ЦЭ, в которых требования к ПО четко определяются заранее и, с большой вероятностью, не будут корректироваться в период разработки. Важным преимуществом такой модели в компании, будет возможность уменьшения проектных рисков за счет определения, уже в начале работ, состава - ролевых функций - зон ответственности каждого члена команды разработчиков и возможности контроля сроков и качества этапов проекта (KPI).

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

Для выполнения в компании достаточно крупных отраслевых решений (доработки базовой платформы), может быть рекомендована модель методологии Microsoft Solution Framework (MSF), которая обеспечивает компромисс между снижением стоимости и сроков разработки, при допустимом увеличении проектных рисков (сочетаются преимущества водопадной и спиральной моделей: выполнение проекта по этапам с контрольными точками (KPI), сами этапы могут повторяться по спирали).
Примечание: из СМИ известно, что многие российские производители ПО держат в своем штате команды разработчиков, имеющие опыт разработки ПО с использованием различных типов моделей процесса разработки ПО.

2.2. Определение состава и функций членов команды разработчиков ПО в компании.

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

Модель команды разработчиков может быть определена после выбора модели процесса разработки ПО. Задавшись, в силу отсутствия информации о методологии используемой к конкретной компании, моделью Microsoft Solution Framework, можно воспользоваться моделью команды MSF Team Model (эту модель рекомендуется рассматривать лишь в качестве отправной точки: разные коллективы реализуют её по-разному, в зависимости от масштаба проекта, размеров группы, уровня подготовки ее членов и «специфики» сегментов рынка на которых имеются основные объемы продаж продукта).

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

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

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

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

Менеджер продукта (product manager): отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и ведет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействия с клиентом в ходе реализации проекта, в том числе организует встречи с клиентом, демонстрации продукта и другие маркетинговые акции.

Менеджер программы (program manager): управляет процессом разработки ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями и планами.

Разработчик (developer): занимается разработкой ПО в соответствии с заданными спецификациями.

Тестировщик (tester): выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он также оценивает соответствие набора реализованных в продукте функций общей концепции и области действия проекта.

Менеджер по выпуску продукта (release manager): отвечает за развертывание серийного выпуска и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.

Специалист по удобству использования продукта (user experience specialist): занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения его соответствия их потребностям.

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


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

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

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

Аналитик (бизнес-аналитик): работа с заказчиком, сбор требований заказчика и пользователей и формирование требований к ПО, разработка ТП в части выполнения функциональных требований, разработка планов тестирования, концептуальное тестирование функциональности, разработка пользовательской документации.

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

Разработчик: разработка РП (при участии архитектора), разработка функциональности решения, обеспечение качества кода, исправление ошибок в коде, проведение первичного тестирования кода, участие в комплексном тестировании кода.

Тестер: тестирование функциональности, написание Unit тестов, участие в разработке планов тестирования.

Билд-инженер: сборка версии ПО, выпуск версии ПО (после тестирования), подготовка сопроводительных документов к версии ПО.

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

Роль «Управление продуктом». Как правило, к этой задаче привлекается группа бизнес-аналитиков глубоко знакомых с бизнес-процессами в компании-заказчике для определения места разрабатываемого программного обеспечения в бизнес-процессах компании, целей и задач проекта ПО, приоритетов внедрения, формулирования требований к ПО и удовлетворения ожидания пользователей. На основании результатов обследования объекта заказчика осуществляется подготовка технического задания, содержащего детальную спецификацию пользовательских требований к ПО, требований к программной документации, описание основных функционально-технических решений, описание порядка контроля и приемки. Руководитель этой группы - менеджер продукта - обеспечивает взаимодействие с руководством заказчика, несет ответственность за то, чтобы цели и задачи проекта ПО, а также требования и ожидания пользователей однозначно понимались бы всеми членами команды разработчиков ПО, и чтобы функциональные спецификации проекта отвечали требованиям пользователей и приоритетам бизнеса заказчика.

Роль «Управление проектом». Это, прежде всего, декомпозиция решения, постановка частных задач (ЧТЗ) и разработка функциональных спецификаций к проекту. Руководитель этой группы - менеджер проекта - является одновременно руководителем проекта. Он выполняет общее планирование проекта и координирует согласованные действия всех ролей в команде в ходе выполнения проекта. Он отвечает за содержание функциональных спецификаций и отслеживает их изменения в течение всего цикла работ. Он несет ответственность за выполнение проекта в запланированные сроки, следит за использованием в работе только стандартизованных методологических документов РФ и/или отраслевых НМД.

Роль «Разработка программы». Эту работу выполняют программисты, которые создают необходимые программные модули. Руководитель группы - менеджер разработки - руководит процессами создания архитектуры проекта, детального проектирования и созданием программных модулей. Поскольку создание приложений в архитектуре клиент-сервер требует знаний во многих областях: языки программирования, сети, коммуникации, управление базами данных, - это должна быть группа высококвалифицированных специалистов по каждой из описанных областей.

Роль «Тестирование программных модулей». Эта работа выполняется группой тестирования, которая должна обеспечить независимую проверку проекта на соответствие функциональным спецификациям. Менеджер по тестированию разрабатывает стратегию и план тестирования и обеспечивает разработку и проведение всех необходимых тестов. От менеджера по тестированию требуется знание технологий и средств тестирования программных продуктов, методики создания тестовых примеров (часто, это программисты). Члены группы, выполняющие непосредственную прогонку тестов и регистрирующие результаты, могут не иметь профессиональных знаний в области создания программного обеспечения. От них требуется четкость и аккуратность в регистрации ошибок и проблем.

Роль «Обучение пользователей ПО». Для такого обучения, как правило, создается группа, которая обеспечивает подготовку всей необходимой документации как в бумажном, так и в электронном виде. Группа также обеспечивает обучение специалистов технических служб заказчика, которые, в свою очередь, обучают конечных пользователей. Менеджер по обучению разрабатывает план обучения и контролирует процессы создания документации и обучения. Для успешного выполнения своих обязанностей, члены этой группы должны уметь работать с инструментальными средствами создания печатной и онлайновой информации, глубоко понимать требования пользователей ПО и бизнеса, обладать педагогическими навыками.

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

3. Методология совершенствования бизнес-процесса разработки ПО в российских компаниях

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

Такое положение, по-видимому, является отражением сегодняшнего состояния российского ИТ-рынка и будет ощутимым барьером при разработке ИТ-продуктов для цифровой экономики России, и на пути будущего перепрофилирования части высокотехнологичных ИТ-мощностей предприятий ОПК на массовый выпуск ИТ-продукции и продажи на мировых конкурентных рынках (Указ Президента РФ от 2016 года).

В тоже время, можно допустить, что западные консалтинговые компании проводят в России политику технологического сдерживания, которое касается, прежде всего, развития российской ИТ-индустрии (телеком-и оборудование передачи данных, операционные системы, спец. прикладные программные продукты, АПК ИБ КВО РФ, ЭКБ).

Для преодоления двух обозначенных барьеров на пути совершенствования бизнес-процесса разработки ПО в российских ИТ-компаниях, представляется целесообразным:

• взять за основу существующие модели* процесса разработки ПО, состав и ролевые функции членов команды разработчиков ПО, используемые в компании системы командной разработки (MS Visual Studio/ MS Visual SourceSafe) и провести «измерение параметров процесса» при выполнении нескольких последних ИТ-проектов,

• доказательно выбрать модели процесса разработки ПО (каскадные и/или итеративные), определить адекватный состав и ролевые функции членов команды разработчиков ПО, например, по рекомендациям Microsoft, с учетом специфики рынка продаж продуктов и провести внешнюю экспертную оценку,

• внедрить, при необходимости, в процесс разработки ПО, новые модели процесса разработки, ролевые функции членов команды, новые системы командной разработки ПО и провести «измерение параметров процесса» на новых проектах компании,

• провести дополнительные итерации такого цикла работ, при необходимости.


*Примечание: Из СМИ следует, что сегодня ряд российских производителей ПО, при составлении требований (ТЗ) и организации процесса разработки ПО, руководствуются ГОСТ 19.ххх Единая система программной документации (ЕСПД) и ГОСТ 34.ххх Стандарты информационных технологии. В тоже время, лидеры российского рынка производителей ПО реализуют подобные процессы на основе западных методологий, которые требуют разработки ряда документов из приведенного ниже перечня (в каждой компании свои приоритеты):
1. Business Requirements Document –- фокусируются на определении бизнес-задач, стоящих перед пользователями, которые могут быть решены с помощью нового продукта компании (предварительный бизнес-план, включая анализ рынка, стратегию продаж и продвижения, прогнозы объемов продаж и прибылей).
2. Market Requirements Document - фокусируется на определении требований рынка к предлагаемому новому продукту (на основе вариантов его использования). Документ включает: анализ рынка и конкурентов; функциональные возможности, необходимые для решения бизнес задач; функциональные и не функциональные требования, приоритезацию требований и функциональных возможностей.
3. Product Requirements Document - определяет требования к новому продукту с точки зрения самого продукта. Обычно он более детально описывает возможности и функциональные требования и может даже содержать скриншоты и Layout пользовательских интерфейсов.
4. Functional Specifications Document - определяет функциональные требования к продукту с фокусировкой на реализации. FSD может определять продукт последовательно, форму за формой и одну функциональную возможность за другой. Это документ, который уже может непосредственно использоваться командой разработчиков для создания продукта.


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

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

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


Примечание: Опыт компаний «Лаборатория Касперского» указывает на успешность применения модели команды разработчиков ПО, в которой менеджеры продукта и маркетологи входят в команду. Отметим, что для привнесения западной технологической культуры разработки ПО в компанию ЛК, были приглашены высокооплачиваемых ИТ-менеджеры и эксперты по «измерению» и модификации корпоративной культуры компании ЛК из Англии и США).


Косвенным положительным эффектом, выполнения работ по совершенствованию бизнес-процесса, будет снижение рисков процесса разработки ПО в компании, включая:

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

Последним этапом совершенствования бизнес-процесса (при положительных результатах ТЭО) может быть внедрение в компании специализированных программных инструментов по оптимизации бизнес-процесса разработки ПО, например, компаний Microsoft или Borland.

Как промежуточное решение, на пути оптимизации бизнес-процесса разработки ПО в компании, может быть внедрение системы менеджмента качества, которое позволяет совершенствовать бизнес-процесс разработки ПО, но с менее значимыми результатами.



Представленный материал подготовлен маркетологом MBA (Microsoft, Лаборатория Касперского, IDC), при консультациях с профессионалами связи, является авторским, ссылка обязательна.


С уважением,
Alex Rail,
5 октября 2017 года

ПРИЛОЖЕНИЕ 1. Разработка требований к программному продукту в соответствие со стандартами IEEE.

Мировой опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением программными требованиями (Software Requirements):

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

Данная область знаний касается вопросов извлечения (сбора), анализа, специфицировании и утверждения требований к ПО и включает 7 секций (связаны со следующими областями: Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Quality):

• Базис программных требований (Software Requirements Fundamentals),
• Процесс работы с требованиями (Requirements Process)
• Извлечение требований (Requirements Elicitation)
• Анализ требований (Requirements Analysis)
• Спецификация требований (Requirements Specification)
• Проверка требований (Requirements Validation)
• Практические соображения (Practical Considerations)


1. Базис программных требований (Software Requirements Fundamentals)

Формулирование требований (Definition of a Software Requirement), определение требований к продукту и процессу (Product and Process Requirements), разделение требований на группы функциональных и нефункциональных (Functional and Non-functional Requirements).

Группа функциональных требований

• Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

• Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы.

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

Группа нефункциональных требований (Non-Functional Requirements)

• Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д.

2. Процесс работы с требованиями (Requirements Process)

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

2.1 Модель процесса определения требований

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

В частности, процесс определения требований касается всех тех вопросов, которые охватываются в рамках сбора, анализа, специфицировании, утверждения требований, с точки зрения организации этих видов деятельности, для различных типов проектов и значимости тех или иных ограничений по отношению к процессу. В большинстве случаев, процесс определения, работы с требованиями выделен в самостоятельный набор и описан как последовательность (сценарии) действий, связанных с ними ролей и непосредственных результатов (их часто называют “артефактами”, например, RUP – Rational Unified Process), в рамках конкретных методологий разработки программного обеспечения.

2.2 Участники процессов (Process Actors)

В этой теме используется понятие “роли” и дается понимание “ролей” для людей, которые участвуют в процессе работы с требованиями. Таких людей также называют “заинтересованными лицами” (в данном контексте - software stakeholders). Заинтересованное лицо – некто, имеющий возможность (в том числе, материальную) повлиять на реализацию проекта/продукта.

Типичные примеры ролей:

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

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

• Аналитики (Market analysts): продукты массового рынка программного обеспечения не обладают “заказчиками” в понимании персонификации тех, кто “заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль «квалифицированных представителей» потребителей.

• Регуляторы (Regulators): многие области применения (“домены”) являются регулируемыми,
например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами.

• Инженеры по программному обеспечению, инженеры-программисты (Software Enginner):
лица, обладающие обоснованным интересом к разработке программного обеспечения,
например, повторному использованию тех или иных компонент, библиотек, средств и
инструментов. Именно инженеры ответственны за техническую оценку путей решения
поставленных задач и последующую реализацию требований заказчиков.


3. Извлечение требований (Requirements Elicitation)

Рассмотрим вопросы сбора требований как с точки зрения организации процесса, так и определения источников, откуда поступают требования. Это первая стадия построения видения автоматизируемой предметной области. Идентификация заинтересованных лиц, их взаимодействия, выполняемых ими бизнес-процессов – все это является ключевыми вопросами, без четкого и однозначного ответа на которые «не стоит думать» об успешности проекта.

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

3.1 Источники требований (Requirement Sources)

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

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

3.2 Техники извлечения требований (Elicitation Techniques)

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

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

• Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями.

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

• Разъясняющие встречи (facilitated meetings) - достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков.

• Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя.

Существуют и другие, достаточно эффективные практики, например, Requirements Workshop, Role Playing, Story Boards).

4. Анализ требований (Requirements Analysis)

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

Анализ требований включает:

• Обнаружение и разрешение конфликтов между требованиями.
• Определение границ задачи, решаемой создаваемым программным обеспечением; в общем
случае - определение “scope” (или “bounds”), границ и содержания программного проекта.
• Детализацию системных требований для установления программных требований.


4.1 Классификация требований (Requirements Classification)

Требования могут классифицироваться по целому ряду параметров, например:

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


4.2 Концептуальное моделирование (Conceptual Modeling)

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

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

Среди факторов, которые влияют на выбор модели, метода и детализации ее представления, степени связанности с программным кодом, выделяют:

• Природу проблемы (проблемной области)
• Экспертизу и опыт инженеров
• Требования заказчика к процессу
• Доступность методов и инструментов
• Внутрикорпоративные стандарты и регламенты
• Культуру разработки ПО


4.3 Архитектурное проектирование и распределение требований (Architectural Design and
Requirements Allocation)


Считается, что создание архитектуры программных решений является обязательным элементов
успешности проектов ПО. Архитектурное проектирование перекрывается с программным и системным проектированием и иллюстрирует насколько сложно провести четкую грань между различными аспектами проектирования (данная тема тесно связана с секцией “Структура и архитектура программного обеспечения” (Software Structure and Architecture) области знаний “Проектирование программного обеспечения” (Software Design)).

Архитектурное проектирование близко к концептуальному моделированию. Существует ряд стандартов и общепринятых практик, связанных с архитектурным проектированием. Среди них наиболее популярны:
• Стандарт IEEE 1471-2000 «Recommended Practice for Architectural Description of Software Intensive Systems”.
• Модель Захмана – Zachman Framework.
• TOGAF – The Open Group Architecture Framework.


5. Спецификация требований (Requirements Specification)

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

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

• Определение системы (system definition)
• Системные требования (system requirements)
• Программные требования (software requirements)

5.1 Определение системы (System Definition Document)

Содержание документа определяет высокоуровневые требования, часто стратегические цели, для достижения которых создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения. Соответственно, изложение требований в нем ведется в терминах прикладной области. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов.
Примером стандарта для создания и структурирования такого документа является IEEE 1362 “Concept of Operations Document”.

5.2 Спецификация системных требований (System Requirements Specification)

В сложных проектах принято разделять спецификацию системных требований (system requirements) и спецификацию программных требований (software requirements). При таком подходе программные требования порождаются системными требованиями и детализируют требования к компонентам и подсистемам программного обеспечения.
Стандарт IEEE 1233 является одним из признанных руководств по разработке системных требований (см. материалы INCOSE).


5.3 Спецификация программных требований (Software Requirements Specification - SRS)

Часто эту спецификацию называют “требованиями к программному обеспечению” или программными требованиями. Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. Документ может включать процедуры проверки получаемого программного обеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасности и многое другое.

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

Стандарт IEEE 830 является классическим примером стандарта на содержание структурирование и методы описания программных требований – “Recommended Practice for Software Requirements Specifications”.

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

6. Проверка требований (Requirements Validation)

Определение требований напрямую связано с процедурами проверки (verification) и утверждения
(аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.

Часто у производителей ПО, вместо полноценной проверки сути и содержания документов, всё сводиться к так называемому "нормоконтролю" – когда проверка документов требований заключается в проверке на соблюдение принятых стандартов внешнего оформления документа (отступы и размеры поля, подписи таблиц/рисунков и т.п.), но никак ни оценки качества требований. И совершенно неверно считать такой "нормоконтроль" полноценной проверкой требований.

6.1 Обзор требований (Requirements Review)

Один из распространенных методов проверки требований - инспекция или обзор требований. Суть
его заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специально
выделенные специалисты), “вычитывают” требования в поисках необоснованных предположений,
описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов и т.п.

Вопросы обзора требований, вообще говоря, имеют непосредственное отношение к теме качества,
поэтому они также описываются в области знаний SWEBOK “Качество программного обеспечения”
(Software Quality) в теме 2.3 “Обзор и аудит” (Review and Audit).

6.2 Прототипирование (Prototyping)

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

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

6.3 Утверждение модели (Model Validation)

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

6.4 Приемочные тесты (Acceptance Tests)

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

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

Идентификация и разработка приемочных тестов для нефункциональных требований часто
оказывается наиболее трудоемкой задачей. Для ее решения обычно “ищут точку опоры”, то есть
возможность взгляда на описываемые требования с количественной точки зрения, вплоть до пере формулирования и большей степени детализации описания таких требований. Дополнительная информация, связанная с приемочными тестами представлена в области знаний SWEBOK “Тестирование программного обеспечения” (Software Testing) в описании 2.2.4 “Тесты
соответствия” (Conformance testing).

7. Практические соображения (Practical Considerations)

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

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

7.1 Итеративная природа процесса работы с требованиями (Iterative Nature of the Requirements
Process)


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

7.2 Управление изменениями (Change Management)

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

7.3 Атрибуты требований (Requirements Attributes)

Требования должны состоять не только из описания того, что необходимо сделать, но и содержать
информацию, необходимую для интерпретации требований и управления ими. Например, с функциональными требованиями часто ассоциируют сценарии Use Case (как в текстовом, так и графическом представлении) и, в то же время, функциональные требования часто трансформируются в задачи в терминах проектного управления, с которыми связаны параметры законченности (например, в процентах), ответственности (например, кто является “владельцем” требования, кто из инженеров назначается исполнителем или принимает на себя обязанности, связанные с реализацией заданной функциональности, как это принято, например, в других ИТ-технологиях).

7.4 Трассировка требований (Requirements Tracing)

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

7.5 Измерение требований (Measuring Requirements)

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

Техника такого рода численной оценки, определена на концептуальном уровне в стандарте IEEE 14143.1. - измерение объема функциональности (Functional Size Measurement, FSM). Также сущест вуют специальные руководства по созданию различных моделей зрелости требований. Такие работы, в частности, связаны с RUP, например, наиболее популярная модель зрелости в индустрии программного обеспечения – CMMI, включает разный объем и содержание работ по определению и управлению требованиями для уровней зрелости 2 и 3.




ПРИЛОЖЕНИЕ 2. Пять уровней зрелости производителя ПО в соответствие с моделью CMMI.


В конце ХХ века перед министерством обороны США встала проблема повышения качества разрабатываемого по их заказу ПО. Проблема была решена созданием модели, на соответствие которой оценивались все потенциальные исполнители заказа министерства обороны. Задача разработки этой модели была возложена на Software Engineering Institute, для создания модели был проведён анализ ключевых активностей (работ), выполняемых при разработке ПО, и связанных с ними рисков.

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

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

Уровень зрелости 2 – управляемый уровень. На данном этапе основные процессы описаны, их, возможно, использовать неоднократно. Другими словами, проекты, выполняемые организацией, отвечают требованиям. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности. На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства позволяют управлять проектом, однако дают фрагментарное представление о нем. Фактически, производственный процесс можно представить последовательностью черных ящиков и реальное видение проекта присутствует лишь на промежуточных этапах.

Уровень зрелости 3 – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление. На этом уровне становится видимой внутренняя сторона наших черных ящиков. Это внутренняя структура отражает способ применения стандартного производственного процесса производителя ПО.

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

Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес-процессы путем развития существующих методов и техник и внедрения новых практик.


ПРИЛОЖЕНИЕ 3 Сертификация ITIL разработчиков ПО для платформ цифровой экономики РФ


Как показывает международная и российская практики, чтобы производитель ПО соответствовал моделям зрелости CMMI, в штате компании должны находиться сертифицированные ИТ-специалисты (компании 1С и Лаборатория Касперского, имеют десятки сертифицированных специалистов). Для примера, рассмотрим схему сертификации специалистов ITIL, которая, согласно практике инофирм, помогает формировать конкурентоспособные коллективы ИТ-разработчиков и организовать процесс разработки ПО, отвечающий 3-4 уровням модели CMMI:

1. Foundation Level - базовый уровень сертификации, который подтверждает знание основных терминов и концепций процессов ITIL v3. При успешной сдаче данного экзамена ИТ-специалист получает сертификат «ITIL v3 Foundation Certificate in IT Service Management» и зарабатывает первые 2 балла.

2. ITIL Practitioner- новая, появившаяся только в 2016 году ступень сертификации.
Зачастую бывает так, что пройдя курс "ITIL Foundation" сотрудник возвращается на рабочее место с огромным потенциалом, готовый совершить «переворот в своем ИТ-подразделении» на благо организации. Но практического опыта ему для этого часто не хватает, даже если он получил международный сертификат «ITIL Foundation».

Сертификация ITIL Practitioner подтверждает способность применять и адаптировать лучшие практики по построению и постоянному совершенствованию процессов ITSM в контексте компании.
Для допуска к экзамену по направлению ITIL Practitioner необходимо выполнить ряд обязательных требований:

• Иметь в наличии сертификат «ITIL v3. Foundation Certificate in IT Service Management».
• Пройти обучение на соответствующем авторизованном курсе.


3. Следующая ступень сертификации - Intermediate Level. Данный уровень сертификации подтверждает способности специалиста анализировать и применять концепции ITIL, умения по созданию и поддержке отдельно взятых процессов ITIL.

Для допуска к экзамену по любому из перечисленных выше направлений необходимо выполнить ряд обязательных требований:
• Иметь в наличии сертификат «ITIL v3. Foundation Certificate in IT Service Management».
• Пройти обучение на соответствующем авторизованном курсе.
Intermediate Level состоит из 2 направлений:

3а. Lifecycle modules включает в себя 5 модулей (экзаменов), созданных на основе 5 книг ITIL v3: Service Strategy, Service Design, Service Transition, Service Operation и Continual Service Improvement.
Сертификат «ITIL. Intermediate Examination: Intermediate Lifecycle Stream» подтверждает знания соответствующей книги ITIL v3 и приносит 3 балла.
Успешная сдача экзаменов по данному направлению подтверждается следующими сертификатами:
• «ITIL. IntermediateExamination: IntermediateLifecycleStream:ServiceStrategy» - это сертификат, подтверждающий знания взаимодействия ИТ и бизнеса и бизнес-процессов целиком.
• «ITIL. Intermediate Examination: Intermediate Lifecycle Stream: Service Design» - это сертификат, подтверждающий знания по процессу построения сервиса.
• «ITIL. Intermediate Examination: Intermediate Lifecycle Stream: Service Transition» - это сертификат, подтверждающий знания по управлению изменениями и проверкой качества, анализу рисков.
• «ITIL. Intermediate Examination: Intermediate Lifecycle Stream: Service Operation» - это сертификат, подтверждающий знания по достижениям эффективности и ценности процессов поставки и поддержки услуг.
• «ITIL. Intermediate Examination: Intermediate Lifecycle Stream: Continual Service Improvement - это сертификат, подтверждающий знания по оценке предоставляемых сервисов, их анализу и поиску путей для постоянного повышения качества обслуживания.

3b. Capability modules включает в себя 4 модуля (экзамена), которые условно можно сравнить с экзаменами уровня Practitioner второй версии ITIL. Сертификат «ITIL. Intermediate Examination: Intermediate Capability Stream (название экзамена)» подтверждает знания и умения по организации и поддержке 2-3 тесно взаимосвязанных процессов, заявленных в названии экзамена, и приносит 4 балла. Два из четырех экзаменов доступны на русском языке.

Успешная сдача экзаменов по данному направлению подтверждается следующими сертификатами:

• «ITIL. Intermediate Examination: Intermediate Capability Stream: Operational Support & Analysis» (OSA) - это сертификат, подтверждающий знания и умения по организации, поддержке и оптимизации процессов Event, Incident, Request, Problem & Access Management (управление событиями, инцидентами, запросам, проблемами и доступом) а также службы Service Desk (Сервис Деск). Есть возможность сдать экзамен на русском языке.
• «ITIL. Intermediate Examination: Intermediate Capability Stream: Release, Control & Validation» (RCV) - это сертификат, подтверждающий знания и умения по организации, поддержке и оптимизации процессов Service Asset and Configuration, Validation and Testing, Release and Deployment, Request fulfillment, Evolution, Knowledge Management (управление сервисными активами и конфигурациями, подтверждением и тестированием, релизами и развертыванием, запросами на обслуживание, оценкой и знаниями). Есть возможность сдать экзамен на русском языке.
• «ITIL. Intermediate Examination: Intermediate Capability Stream: Service Offerings & Agreements» (SOA) - это сертификат, подтверждающий знания и умения по организации, поддержке и оптимизации процессов Service Portfolio, Service Catalogue, Service Level Management, Demand, Supplier & Financial Management (управление портфелем услуг, каталогом услуг, уровнем сервиса, спросом, поставщиками и финансами).
• ITIL. Intermediate Examination: Intermediate Capability Stream: Planning, Protection & Optimization» (PPO) - это сертификат, подтверждающий знания и умения по организации, поддержке и оптимизации процессов Capacity, Availability, Continuity Management, Information Security & Demand Management (управление мощностью, доступностью, непрерывностью, информационной безопасностью и спросом).

4. ITIL Expert Level - самая высокая ступень сертификации в ITIL третьей версии, доступная для получения на сегодняшний день. Сертификат «ITIL Expert» подтверждает, что его обладатель способен решать как тактические, так и стратегические задачи, возникающие в работе ИТ-подразделения (ИТ-компании).

Для допуска к экзамену необходимо выполнить ряд обязательных требований:

• Набрать 17 баллов на предыдущих ступенях сертификации.
• Пройти обучение на авторизованном курсе «Managing Across the Lifecycle».

Успешная сдача данного экзамена оценивается в 5 баллов и позволяет не только получить один из наиболее высоких статусов в третьей версии ITIL, но и дает право на сертификацию на самый высокий статус - ITIL Master.

5.ITIL Master Level (Advanced Level) - высшая ступень сертификации в ITIL третьей версии. Сертификат «ITIL Master» подтверждает способность ИТ-специалиста применить и анализировать концепцию ITIL в новых областях.

Вернуться в Последние новости отрасли

Поделиться

Кто сейчас на конференции

Сейчас этот форум просматривают: Brandwatch, CommonCrawl и гости: 2