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

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

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

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

Терминология тестирования «альфа/бета» впервые появилась в IBM. Подобные термины для разработки программного обеспечения использовались людьми, связанными с IBM, по крайней мере, с 1950-х годов, а возможно, и раньше.

Тест «A» представлял собой проверку нового продукта перед публичным объявлением.

Тест «B» был проверкой перед выпуском продукта в производство.

Тест «C» являлся окончательным испытанием перед общей доступностью продукта.

Поскольку программное обеспечение стало важной частью продукции IBM, для обозначения теста перед объявлением использовалась терминология альфа-тестирования, а бета-тест — для демонстрации готовности продукта к общей доступности. Мартин Бельский, менеджер некоторых ранних программных проектов IBM, утверждал, что он является автором данной терминологии. IBM отказалась от терминологии альфа/бета в 1960-х годах, но к тому времени она получила довольно широкое распространение.

Термин «бета-тест» как обозначение тестирования, выполняемого пользователями, появился не в IBM. Вместо этого IBM использовала термин «полевой тест» (англ. field test).

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

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

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

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

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

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

Тим О’Райли, поборник открытого ПО, выводит особый вид программ — «вечная бета», когда программа находится в бета-стадии неопределённый период времени. Такой механизм уместен в интернете, где ПО обладает такими свойствами:

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

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

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

Формальный термин часто зависит от способа выпуска: физический носитель, онлайн-выпуск или веб-приложение.

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

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

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

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

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

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

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

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

Изначально эти 7 этапов использовались на сайте SourceForge. Впоследствии эту нумерацию подхватил PyPI, хостинг пакетов для языка Python.

1. Планирование (planning). Автор зарезервировал название за проектом и начал очерчивание функциональности. Версии, как правило, не имеет.
2. Преальфа (pre-alpha). Уже есть какая-то программа, дающая представление о том, что она будет делать. Идёт разработка, добавление новой функциональности, рефакторинг. Архитектура программы в любой момент может полностью измениться. В этот момент программа уже может получить версию, обычно 0.x.y.
3. Альфа (alpha). Архитектура программы очевидна. Близкие к разработчику люди уже могут пользоваться программой. Идёт тестирование и доведение до продукта.
4. Бета (beta). Программа полнофункциональна. Идёт тестирование, исправление ошибок и проблем с производительностью, совершенствование эргономики.
5. Готовая/стабильная (production/stable). Нет критичных ошибок, оттестированы все основные сценарии использования. Идёт исправление ошибок, добавление новой функциональности. В этот момент программе можно дать версию 1.0.
6. Зрелая (mature). Больше года в состоянии «готовая/стабильная», не просят крупной функциональности, нет крупных и критичных ошибок. Идёт исправление мелких ошибок.
7. Брошенная (inactive). Разработка давно не ведётся. Найденные проблемы, скорее всего, не будут исправлены. Разумеется, проект могут снова взять в разработку и вернуться к одному из предыдущих этапов.

• Free Software Project Management HOWTO (англ.)
• Этапы разработки программных продуктов (рус.)