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

Процедуры тестирования каскадной модели

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

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


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

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


Качество систем программной продукции ГОСТ Р ИСО 25010-215

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

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



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

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

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

ТТХ БМП-1

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

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

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

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

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

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

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

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

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

Ошибка 1С

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме


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

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

Комментарии (5)


  1. DrPass
    03.06.2017 22:51

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

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


    1. clicker314
      04.06.2017 15:25

      Сразу видно человека знающего всю боль и я надеюсь знающего что со всем этим делать!
      Держись товарищ, ты не одинок!


  1. Mimus_spb
    04.06.2017 12:46

    Всем подобным статьям категорически не хватает кейсов и цифр.


  1. Germanets
    05.06.2017 13:57

    Никогда не вставляйте в статью ссылки, замаскированные под плееры\другие функциональные элементы.


    1. Northeast
      06.06.2017 13:52

      Это право автора.