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



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

Требования к качеству системы/программной продукции

Самое главное при пропуске этапа — это не потерять качество разрабатываемого продукта. Для этого разберём раздел требований к качеству в ГОСТ Р ИСО/МЭК 25010-215. В нем приводятся основные характеристики качества системы (программной продукции):

• функциональная пригодность,
• уровень производительности,
• совместимость,
• удобство пользования,
• надежность,
• защищенность,
• сопровождаемость,
• переносимость.

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

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



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

С недоработками категории 2 и 3 уже можно бороться на этапе промышленной эксплуатации при условии достаточности ресурсов для обеспечения одновременных устранений замечаний.

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



Например, 1С: БСП (Библиотека стандартных подсистем) используется в большом количестве программ. Тестировать её производительность не имеет смысла, так как она неоднократно протестирована в реальных условиях эксплуатации до вашего проекта. Более того, создать лучше производителя вряд ли получится.

Большие модули собственной разработки или масштабный проект требуют тестирования.

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

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

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

Надёжность. Это способность системы продолжительное время сохранять рабочее состояние. Если рассматривать проект автоматизации на базе технологической платформы «1С Предприятие 8», то надежность обеспечивается рядом условий:

• надёжностью технологических платформ 1С, СУБД (зависит от разработчиков).
• квалифицированном построении технической и программной архитектуры системы.
• квалифицированной настройкой.

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

Ошибки бываю разные, некоторые увлекательные :)



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

Общего правила выбора варианта работы от количества пользователей нет, требуется аналитический подход. Если посадить 10 пользователей с разными ролями менеджера, продавца, кассира, кладовщика и т.д., то возможно потянет файловый вариант, а если 10 кассиров, то однозначно клиент-серверный вариант. Аналитик понимает процесс конкуренции за ресурсы.

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

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

Надо ли тестировать надёжность? Если это сложная архитектура, то нагрузочное тестирование необходимо вплоть до падения для определения максимальной возможности системы (задача — уронить базу).

Защищённость. Если защита конфиденциальной информации стоит остро, то настоятельно рекомендую разработать техническое задание на доступ к системе и не пропускать тестовую эксплуатацию.

Существует 2 способа работы с полномочиями пользователей в новой системе:

1. «От большего к меньшему» — даём всем полный доступ, а после устойчивого состояния проекта начинаем процедуру ограничения.
2. «От меньшего к большему» — создаём минимально необходимый набор прав, а по мере поступления запроса — увеличиваем.

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

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

Сопровождаемость и Переносимость.

Длительность тестового периода редко превышает месяц. Это обусловлено большими трудозатратами персонала. Экономически не выгодно.

Большой связи между этими определениями и тестовой эксплуатацией не нахожу.

Резюме

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

Получить шаблон реестра рисков можно по почте «doc@ingraf.su» с указанием темы «Риски».