No Image

Что такое релиз программы

СОДЕРЖАНИЕ
1 просмотров
11 марта 2020

Системное программное обеспечение PlayStation Portable — Системное программное обеспечение PlayStation Portable это официальная обновляемая прошивка для PlayStation Portable. Обновления добавляют новые возможности и вносят исправления в безопасность для предотвращения запуска программ без… … Википедия

Релиз — (Release) Содержание Содержание 1. Виды релиза 2. (программное обеспечение) 3. Музыкальный релиз Классификаций музыкальных релизов Статус музыкального релиза Тип релиза Формат релиза Прочие характеристики 4. Технология подготовки и написания… … Энциклопедия инвестора

релиз (в информационных технологиях) — Набор аппаратного обеспечения, программного обеспечения, документации, процессов или других Компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в ИТ услугах. [http://www.dtln.ru/slovar terminov] релиз (в… … Справочник технического переводчика

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

SeaMonkey — SeaMonkey … Википедия

Blender — У этого термина существуют и другие значения, см. Blender (журнал) … Википедия

Bacula — Тип сетевое резервное копирование, архивирование и восстановление данных Написана на C++[1] Операционная система кроссплатформенная Последняя версия 5.2.10 (28 июня 2012) … Википедия

Subversion — У этого термина существуют и другие значения, см. Subversion (игра). Subversion Логотип Subversion Тип централизованная … Википедия

Релиз (жарг. от англ. release [rɪ’liːs] — выпуск) — выпуск программы/кода/библиотеки — готового для использования продукта. Обычно он содержит все обновления, исправления и является версией, готовой для использования конечным потребителем.

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

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

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

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

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

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

Читайте также:  Kyocera taskalfa 180 характеристики

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

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

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

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

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

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

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

Стадии Beta и Alpha не являются показателями нестабильности, так как присваиваются программе один раз или один раз за серию (серией, в данном случае, считается число до первой точки), в зависимости от системы разработки. Они могут присваиваться нескольким выпускаемым версиям подряд.

Содержание

История [ править | править код ]

Терминология тестирования «альфа/бета» впервые появилась в IBM. Подобные термины для разработки программного обеспечения использовались людьми, связанными с IBM, по крайней мере, с 1950-х годов, а возможно и раньше. Тест «A» представлял собой проверку нового продукта перед публичным объявлением. Тест «B» был проверкой перед выпуском продукта в производство. Тест «C» являлся окончательным испытанием перед общей доступностью продукта. Поскольку программное обеспечение стало важной частью продукции IBM, для обозначения теста перед объявлением использовалась терминология альфа-тестирования, а бета-тест — для демонстрации готовности продукта к общей доступности. Мартин Бельский, менеджер некоторых ранних программных проектов IBM, утверждал, что он является автором данной терминологии. IBM отказалась от терминологии Альфа/Бета в 1960-х годах, но к тому времени она получила довольно широкое распространение. Термин «бета-тест» как обозначение тестирования, выполняемого пользователями, появился не в IBM. Вместо этого IBM использовала термин «полевой тест» (англ. field test ).

Читайте также:  Швейная машина с функцией оверлока

Этапы разработки [ править | править код ]

Pre-Alpha — начальная разработка [ править | править код ]

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

Alpha — внутренняя разработка [ править | править код ]

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

Как правило, альфа-тестирование заканчивается заморозкой свойств и переходит в бета-тестирование.

Beta — общественная разработка [ править | править код ]

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

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

Release candidate / предварительная версия [ править | править код ]

Стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании. Если в течение установленного времени не будет найдено крупных недоработок — становится RTM-версией. Пример: Windows 7 RC 7100.

Читайте также:  Kyocera p6021 ошибка 7402

Выпуск [ править | править код ]

После выпуска программное обеспечение обычно называется «стабильным выпуском» (stable release). Формальный термин часто зависит от способа выпуска: физический носитель, онлайн-выпуск или веб-приложение.

Release to manufacturing / выпуск в производство [ править | править код ]

Обозначение готовности программного продукта к тиражированию [1] . Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

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

General availability / общедоступность [ править | править код ]

Общедоступность (англ. general availability ) или общепринятость (англ. general acceptance , GA ) — стадия маркетинга, на которой завершены все необходимые мероприятия по коммерциализации и доступен для покупки программный продукт, в зависимости, однако, от языка, региона, электронной или медийной доступности. Деятельность по коммерциализации может включать проверку безопасности и соответствия требованиям, а также локализацию и продвижение по всему миру. Время между выпуском в производство и общедоступностью может составлять от недели до нескольких месяцев. Это время необходимо для завершения всех мероприятий по коммерциализации, требуемых GA. На данном этапе программное обеспечение «вышло в жизнь» (gone live).

Release to web / веб-релиз [ править | править код ]

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

Поддержка [ править | править код ]

В течение поддерживаемого срока службы программное обеспечение к нему выпускаются сервисные выпуски (service releases), патчи или пакеты обновления, иногда также называемые «промежуточными выпусками» (interim releases).

Например, в операционных системах Windows основная фаза поддержки длится 5-6 лет с момента общедоступности. [2] В ОС типа Ubuntu существуют специальные версии LTS (Long Time Support), срок поддержки которых составляет 5 лет против 1 года у обычных. [3]

Прекращение поддержки [ править | править код ]

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

Комментировать
1 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock detector