Внедрение в опытную эксплуатацию. Обучение персонала.

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

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

Техническая поддержка программного продукта.

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

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

В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта. Также стадия разработки может отражать количество реализованных функций, запланированных для определенной версии программы. Стадии либо могут быть официально объявлены и регламентируются разработчиками, либо иногда этот термин используется неофициально для описания состояния продукта. Следует отметить, что стадии 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) бывают редко.

Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО).

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

Шаги процесса

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

• Бизнес - моделирование
• Анализ требований
• Планирование
• Разработка архитектуры
• Кодирование
• Тестирование и отладка
• Документирование
• Сертификация
• Внедрение
• Сопровождение

Модели процесса

• Модель водопада (Каскадная модель )
• Итеративный процесс
  • Гибкие методологии разработки
  • Экстремальное программирование
• Формальные методы

Вау!! 😲 Ты еще не читал? Это зря!