2.6.2 Программа опытной эксплуатации
- Перед опытной эксплуатацией создается Программа опытной эксплуатации.
- Во время опытной эксплуатации заполняется Журнал опытной эксплуатации. В нем указываются сведения о продолжительности функционирования АС, отказах, сбоях, аварийных ситуациях и т. д. Шаблон журнала может быть оформлен приложением к Программе опытной эксплуатации.
- По окончании опытной эксплуатации формируется Акт о завершении опытной эксплуатации с решением о возможности допуска АС к приемочным испытаниям.Также может оформляться Отчет о проведении опытной эксплуатации с приложением заполненного Журнала опытной эксплуатации.
3 Чек-лист по стилю и содержанию
Документ | Требование к документу | Отметка о выполнении |
ТЗ | Структура соответствует ГОСТ 34.602‑89 как минимум в части основных разделов: 1. Общие сведения. 2. Назначение и цели создания (развития) системы. 3. Характеристика объектов автоматизации. 4. Требования к системе. 5. Состав и содержание работ по созданию (развитию) системы. 6. Порядок контроля и приемки системы. 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. 8. Требования к документированию. 9. Источники разработки | ☐ |
Формулировки требований с долженствованием | ☐ | |
Требования емкие, четкие, идентифицируемые, выполнимые, непротиворечивые, объективные и проверяемые | ☐ | |
Приведены требования ко всем разрабатываемым/развиваемым модулям или подсистемам. Состав модулей/подсистем не меняется. Например, если указан список модулей/подсистем в задачах п. 2, то в пп. 4.1 и 4.2 приведены требования для того же состава модулей/подсистем | ☐ | |
Нет путаницы терминов «модуль» и «подсистема». Если компоненты АС названы «модулями», то этот термин используется во всем ТЗ | ☐ | |
П. 1 – сроки этапов работ в п. 1 соответствуют срокам в п. 5 | ☐ | |
П. 2 – при описании назначения АС указаны сведения об автоматизации деятельности, процессов | ☐ | |
П. 2 – при перечислении целей указаны значения технических, технологических, производственно-экономических и других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС. Цели четкие и измеримые. Реализация требований по созданию/развитию АС и обеспечение готовности к вводу в постоянную эксплуатацию – НЕ цель | ☐ | |
П. 4.1 «Требования к системе в целом» – при описании показателей назначения указаны проверяемые количественные показатели, которые необходимо достичь: количество пользователей, число обрабатываемых объектов, быстродействие, время получения отчетности | ☐ | |
П. 4.2 «Требования к функциям (задачам), выполняемым системой» – приведены требования к функциям АС, а не к работам по созданию/развитию АС или чему-либо еще | ☐ | |
П. 4.2 – требования к функциям сформулированы так, что их можно вынести в заголовки пунктов для детализации в ЧТЗ, а также перенести в другие документы, например в ПЗ и ПМИ, и легко сопоставить с ТЗ, ЧТЗ | ☐ | |
П. 5 – при указании результатов работ верно сопоставлены этапы работ и соответствующая им документация. Названия документов совпадают с теми, что встречаются по тексту ТЗ | ☐ | |
П. 6 – виды испытаний и разрабатываемые для них документы соответствуют видам испытаний и документам в п. 5 | ☐ | |
П. 8 – список разрабатываемых документов соответствуетсписку документов в п. 5 | ☐ | |
Нет скриншотов существующей АС, только макеты | ☐ | |
Нет «смеси» из ГОСТов 34 и 19 | ☐ | |
Единообразие в употреблении сокращений и обозначений, например «Заявитель» или «заявитель», «Заказчик» или «заказчик», или «Государственный заказчик», «СПО» – системное или специальное программное обеспечение | ☐ | |
ЧТЗ | Структура документа соответствует ТЗ на АС | ☐ |
Требования к функциям АС детализированы | ☐ | |
Количественные значения показателей уточнены | ☐ | |
Если в ТЗ есть формулировка наподобие «должно быть приведено на этапе предварительного проектирования / этапе разработки ЧТЗ», то требуемая информация должна быть указана в ЧТЗ | ☐ | |
Отсутствуют формулировки, скопированные из ТЗ и не подходящие для ЧТЗ, например «…настоящего ТЗ» | ☐ | |
Соблюдены другие требования, перечисленные для ТЗ | ☐ | |
ТП | Использование будущего времени | ☐ |
В заголовках вместо «Требования к…» используется формулировка «Предложения по…» | ☐ | |
Нет формулировок с долженствованием, перенесенных из ТЗ (проверить поиском по «долж», «необходим», «обяз», «треб» и т. п.) | ☐ | |
ПЗ | Описаны технические решения для всехкомпонентов АС, которые указаны в ТЗ | ☐ |
Технические решения соответствуют требованиям ТЗ и ЧТЗ | ☐ | |
В заголовках вместо «Требования к…» используется формулировка «Решения по…» | ☐ | |
Использование настоящего и прошедшего времени, описание реализованных функций АС | ☐ | |
Скриншоты существующей АС | ☐ | |
Нет формулировок с долженствованием, перенесенных из ТЗ и ЧТЗ | ☐ | |
РП/РА | Обезличенные формулировки наподобие «Для… необходимо выполнить…» | ☐ |
Нет формулировок наподобие «Вы должны» (читатель ничего не должен), «пользователю нужно» (как будто речь о каком-то абстрактном пользователе) | ☐ | |
Нет сленга наподобие «кликать», «галочка», «хинт» и т. п. | ☐ | |
Текст описания соответствует информации на скриншотах | ☐ | |
Описаны все действия, которые выполняет пользователь или администратор в соответствии со своими обязанностями | ☐ | |
ПМИ | Описаны сценарии проверок реализованных функций АС, ожидаемые результаты и условия проведения испытаний | ☐ |
Для каждой проверки указаны пункты ТЗ и ЧТЗ, содержащие требования к функции | ☐ | |
Для каждого вида испытаний указан верный состав предъявляемых документов | ☐ | |
В тексте документа указан верный вид испытаний: предварительные, опытная эксплуатация, приемочные | ☐ | |
Нет сленга наподобие «кликать», «галочка», «хинт» и т. п. | ☐ |