• Concept of Operations (COO) - концепция <использования> системы;

• Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;

• Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

• Initial Operational Capability (ioc) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;

• Final Operational Capability (FOC) - готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

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

Рисунок 5. Обновленная спиральная модель c контрольными точками проекта.

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

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

• Rational Unified Process (RUP)

• Enterprise Unified Process (EUP)

• Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как “MSF Formal”)

Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM,...).

2 Вопрос. Стадии разработки программного обеспечения

В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта. Также стадия разработки может отражать количество реализованных функций, запланированных для определённой версии программы. Стадии либо могут быть официально объявлены и регламентируются разработчиками, либо иногда этот термин используется неофициально для описания состояния продукта. Следует отметить, что стадии Beta и Alpha (Pre-Alpha) не являются показателями нестабильности релиза так как присваиваются программе один раз или один раз за серию (серией, в данном случае, считается число до первой точки), в зависимости от системы разработки. Они могут присваиваться нескольким релизам подряд. Релизом в данном случае считается завершённая версия (см. Релиз (программное обеспечение)).

Этапы разработки

Этапы разработки Milestone — каждому этапу присваивается порядковый номер (1, 2, 3 и т. д.). Например: «Компания сделала продукт, который находится в стадии разработки. Сейчас у него этап разработки Milestone 1.». Это может быть как пре-альфа или бета, так и ранний этап разработки (раньше пре-альфы). Некоторые этапы разработки могут помечаться как «pre-». Например pre-Milestone 1.

Пре-альфа

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

Альфа

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

Бета

Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости. Тем не менее, программы этого этапа могут содержать достаточно большое количество ошибок.

Поскольку бета-продукт не является финальной версией, и публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. Таким образом, многие производители уходят от ответственности, предоставляя пользователям только бета-версии продукта. Так, ICQ в версии 2003 года использовала этот трюк, выпустив 2003b (b означает бета) версию этого интернет-мессенджера. Финальной версии ICQ 2003 так и не появилось, вместо этого два года спустя вышли версии ICQ 4 и ICQ 5.

Beta Escrow

Стадия бета-тестирования, релиз-кандидат на Beta.

Релиз-кандидат

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.

RC Escrow

Релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

Релиз

Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

RTM Escrow

Последний этап разработки продукта, который готов стать RTM-релизом.

Пост-релиз

Пост-релиз или Post-RTM (англ. post-release to manufacturing), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестировщикам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.

• Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко.

Общая доступность

Общая доступность или общественность (англ. General availability, General acceptance)

Релиз (программное обеспечение)

Релиз (жарг. от англ. release — выпуск) — выпуск окончательной версии программы — готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней версией ПО.

Управление релизами

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

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

Процесс Управления релизами состоит из трёх этапов:

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

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

3. этап распространения и внедрения.

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

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

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

• Контроль над дополнительными лицензиями программного обеспечения;

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

• Оптимально распределенные ресурсы, необходимые для осуществления всех внедрений;

• Снижение степени риска при внесении изменений в состав систем информационных технологий, а значит и самих сервисов;

• Оптимизацию повторяющихся обновлений по времени и стоимости посредством их синхронизации и автоматизации;

• Максимальный эффект от планируемых изменений;

• Планирование расходов на осуществление тех или иных обновлений.

Отказ от реализации данного процесса приведёт к:

• Несогласованности нескольких вносимых обновлений, которые эффективнее можно было бы внедрять совместно;

• Неопределённости в ответственности, кто на самом деле распространяет и устанавливает все проводимые изменения;

• Необоснованности приобретения дополнительных лицензий и компонентов информационных систем;

• Риску, при котором ожидаемый эффект от вносимых изменений будет неоднозначен;

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

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

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

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

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

• для устранения ошибок;

• для модификации в соответствии с изменяющимися потребностями пользователей.

Структура ИТ-сопровождения

Принято выделять несколько линий сопровождения (структура приведена на примере внешнего сопровождения ПО):

• 0 линия (call-center, информационный центр, горячая линия) - обработка телефонных обращений от клиентов, передача обращений техническим специалистам (1-ая линия сопровождения)

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

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

• 3 линия (инженер по сопровождению, инженер технической поддержки, support engineer) - системное сопровождение/проектная деятельность на этапе запуска ПО на оборудовании заказчика

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