Запуск систем по «каскадной модели» имеет такие этапы проекта, как предпроектное обследование, разработка системы, опытная эксплуатация и промышленная эксплуатация.
По усмотрению сторон можно детализировать проект на множество подуровней и, например, использовать его не как «разработку системы», а как «разработку технического задания» и «программирование в среде разработки».
В любом случае, согласно модели, этапы могут проходить только последовательно и только после завершения предыдущего этапа.
Любой этап для заказчика системы стоит времени, дополнительных кадровых работ и финансовых затрат, поэтому я представлю особенности, согласно которым можно пропустить тестовый период из жизни проекта.
Требования к качеству системы/программного обеспечения
Самое главное при пропуске этапа — не потерять качество разрабатываемого продукта.Для этого обратимся к разделу «Требования к качеству» в ГОСТ Р ИСО/МЭК 25010-215. .
Он обеспечивает основные характеристики качества системы (программного продукта):
- функциональный фитнес,
- уровень исполнения,
- совместимость,
- простота использования,
- надежность,
- безопасность,
- сопровождение,
- портативность.
ГОСТ предоставляет полный перечень требований, поэтому ответ на каждое из них дает полное представление о целесообразности и экономической эффективности проекта без этапа опытной эксплуатации.
Функциональный фитнес.
На этапе функционального моделирования (до начала разработки системы) описываются выявленные ограничения, которые необходимо классифицировать по важности.
Наибольший вес придается «критике» (категория 1 на рисунке), подразумевающей невозможность использования предлагаемой системы или ее части.
Если в ходе предпроектных работ не было выявлено критических замечаний, то, скорее всего, к моменту запуска их не будет. Если происходят корректировки из-за критических требований, последует пересмотр этапов, куда можно включить тестовый период.
С дефектами 2 и 3 категории можно бороться уже на этапе промышленной эксплуатации при наличии достаточных ресурсов для обеспечения одновременного устранения замечаний.
Уровень исполнения.
Модульный подход к разработке программ и не только их, но и всего остального существенно упрощает запуск новых систем.
Если я разрабатываю квадрокоптер, то используя компоненты с подробным описанием технических характеристик электродвигателя, процессора, антенны от производителя, я могу быстро построить устройство с представлением ТТХ.
Технический специалист должен быть знаком с продукцией вендоров, а аналитик учитывать специфику проекта.
Например, 1С:БСП (Библиотека типовых подсистем) используется в большом количестве программ.
Тестировать его работоспособность нет смысла, так как перед вашим проектом он неоднократно тестировался в реальных условиях эксплуатации.
Более того, вряд ли удастся создать лучшего производителя.
Большие модули собственной разработки или масштабный проект требуют тестирования.
Совместимость.
Сложная система по умолчанию предусматривает работу всех подсистем.
Пэчворк требует анализа совместимости как программных модулей, так и аппаратного обеспечения.
Совместимость между программами , СУБД, веб-сервисы, оборудование, не использовавшееся в вашей практике, требует проверки.
Простота использования.
Если вернуться к выявлению замечаний в ходе предпроектной проверки, то мы заметим наличие не только критических замечаний, но и «неудобных».
Например, отсутствие сервиса заполнения сумм в документе не критично, так как всегда можно посчитать на калькуляторе и ввести вручную.
Не забывайте и об обратной стороне луны: тестовый период увеличивает нагрузку на сотрудника, работающего в двух системах (новой и старой), что доставляет еще больше неудобств, чем ввод суммы документа вручную.
Надежность.
Это способность системы сохранять рабочее состояние в течение длительного времени.
Если рассматривать проект автоматизации на базе технологической платформы 1С Предприятие 8, то надежность обеспечивается рядом условий:
- надежность технологических платформ 1С, СУБД (в зависимости от разработчиков).
- квалифицированное построение технической и программной архитектуры системы.
- квалифицированная настройка.
Повторяю, любой.
Будь то 350-тысячная корпорация Toyota, отзывающая свои автомобили из-за производственных ошибок, или платформа 1С, выпускающая обновление для устранения ошибок.
Бывают разные ошибки, некоторые интересны :) 
Архитектор 1С обязан предоставить профессиональное и экономичное решение.
Если вы вводите много оперативной документации, то для надежности нужен клиент-серверный вариант с кластеризацией серверов и репликацией.
Если документов много, а пользователей мало, то клиент-файлового режима достаточно.
Общего правила выбора варианта работы в зависимости от количества пользователей не существует; необходим аналитический подход. Если у вас 10 пользователей с разными ролями менеджер, продавец, кассир, кладовщик и т.д., то возможно подойдет файловый вариант, а если кассиров 10, то обязательно клиент-серверный вариант. Аналитик понимает процесс конкуренции за ресурсы.
Также следует отметить, что любая техническая конструкция ломается (пишу этот текст на фоне новостей о глобальном провале Мегафона), а надежность подразумевает в том числе сохранность данных и скорость восстановления архитектуры.
.
Продолжая пример 1С, отмечу, что на практике я провожу ежедневное архивирование.
По состоянию на текущий рабочий день должны быть архивы за последние 90 дней, далее по 1 экземпляру за каждый месяц.
Нужно ли проверять надежность? Если это сложная архитектура, то необходимо нагрузочное тестирование до краша для определения максимальной возможности системы (задача — сбросить базу).
Безопасность.
Если защита конфиденциальной информации имеет решающее значение, то я настоятельно рекомендую разработать техническое задание на доступ в систему и не пропускайте тестовую операцию.
В новой системе есть 2 способа работы с правами пользователей:
- «От большинства к минимуму» — даем всем полный доступ и после того, как проект окажется в стабильном состоянии, начинаем процедуру ограничения.
- «От меньшего к большему» — создаем минимально необходимый набор прав, и увеличиваем его по мере поступления запроса.
Помимо санкционированного доступа к информации, необходимо решать общие вопросы безопасности (взлом пароля, копирование архива данных и т.п.
).
Эти действия настраиваются операционной системой или вспомогательным программным обеспечением.
Ремонтопригодность и портативность.
Продолжительность испытательного периода редко превышает месяц.
Это связано с высокими трудозатратами персонала.
«экономически не выгодно».
Я не нахожу особой связи между этими определениями и тестовой эксплуатацией.
Краткое содержание
Проанализируйте все пункты, описанные выше, создайте SWOT-анализ и примите решение о целесообразности.Но в любом случае, если запускаете без тестовой эксплуатации, обязательно включите этот пункт в реестр рисков и опишите реакцию на него .
Образец реестра рисков вы можете получить на электронную почту «[email protected]» с указанием темы «Риски».
Теги: #водопад #качество системы #испытательная эксплуатация #Управление разработкой #Управление проектами #Управление продуктом #Бизнес-модели
-
Как Точно Оценить Проект За 6 Шагов
19 Oct, 24 -
Указатели На Методы Класса В C++
19 Oct, 24 -
Автоматизация: Как Работать С Обновлениями
19 Oct, 24 -
Может Ли Природа Быть Неестественной?
19 Oct, 24 -
Microsoft Борется С Google В Космосе
19 Oct, 24 -
События На Хабрахабре
19 Oct, 24
