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

Каждая АС должна иметь документ Правила и методика испытаний.
Разработка части Программа испытаний формализована и достаточна проста. Достаточно идти по пунктам РД50 и просто описывать в формате регламента.

Методики испытаний сложнее и многогранее -)
Метаний с ними много бывает. Согласования также выводят нас на кривую дорожку излишней детализации.

Схему о которой пойдет речь, я придумал не сразу, а пришел к ней постепенно. Аналогичное не встречал, посему решил задокументировать.

Итак...
Главная цель данной методы - сократить трудозатраты, объем описания и уложить ПМ в общую канву ТРП.

Майндмап регламента резервного копирования

Для каждой АС должен быть разработан регламент резервного копирования данных и их востановления. Это часть обязательно и даже регламентируется в ТЗ по ГОСТ34.

Как выглядит самый правильный формуляр - к вопросу как готовить ГОСТ 34

Самый правильный Формуляр на АС (для тех кто понимает что это за документ по ГОСТ34) у самого правильного Заказчика должен содержать текста не более странички

Что такое роль в физическом смысле

Наконец таки услышал внятное определение - "Что такое роль"


Ролью называется та выделенная во времени часть людей, которая выполняет определенный ряд работ, требующих какой-то особой квалификации

ЧТЗ vs. ДТЗ

Когда использовать ДТЗ, а когда ЧТЗ? Иногда заказчики путаются, а мы должны им помочь определится в выгодную нам сторону.

Что такое дополнительное техническое задание не знает никто -) Но это не мешает заказчикам активно использовать этот термин. И подразумевать гостовское (34.602) определение "дополнения к техническому заданию".

Под ЧТЗ заказчик часто подразумевает полноценное ТЗ (34.602), но которое почему-то надо оформить как часть чего-то большого. Формально ЧТЗ - это ТЗ на функционально законченную часть какой-то большой системы, чаще всего либо платформенной архитектуры, либо вообще без системы. В последнем случае ЧТЗ выпускается к некоемому абстрактному ТЗ типа "Система автоматизации деятельности государства"

Чем хорошо ДТЗ - по ДТЗ оформляются доработки того что уже есть и ДТЗ включает описание только того, что надо изменить. Типа - "Пункт 3.2.3.4 добавить подпункт - "взаимодействие с клиентов должно идти по HTTPs".
 И все. Никакой около технической фигни типа требований к информационной безопасности и информационному обеспечению. И еще - согласовывать надо только то что изменяется, что уже + в гос заказчике.
Так что если вам нужно доработать систему гос заказчику - не соглашайтесь на ЧТЗ, требуйте ДТЗ.

Пишем ТРП: Технико-экономические показатели

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

Я по наивности считал, и до сих пор считаю -), экономические показатели это TCO, ROI и тп подобное...

Но все проще:

Пишем ТЗ: Требования по сохранности информации

Простой и понятный раздел если не понимать его буквально

---

В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.

---

Если вам не требуется сохранять информацию с  нулевой потерей, то чтобы не напрягаться, следует написать что-то подобного вида:

Пишем ТЗ: Требования к надежности

Этот раздел на вой взгляд самый не нужный в современных АС общего назначения, то есть 90-а% всех АС разрабатываемых сейчас.

Что должно входить в документацию на АС?

Интересный вопрос.
Сколько людей, столько мнений. В ГОСТ34 этих документов 2-е страницы -).
И хотя у меня 4-е выделенных человека описывают проектные решения я его, ГОСТ, не поддерживаю.

По моему мнению документация на АС должна содержать только документы востребованные для:
1. обязательно - Эксплуатации
2. необязательно - Сопровождения

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

Как удержать в голове структуру документов

Как удержать в голове требуемую структуру документов?
Например требования к структуре ТЗ, ПД и других ДДЗ?
В самом простом пакете документов которые мы передаем заказчику содержится около 12 документов. Хорошо если я более менее помню ГОСт. Но структура может меняться. И забываться.

В качестве справочника я использую вот что:

1. перевел в формат мозговой карты РД50
2. распечатал в формате "один документ - один лист"
3. переплел в альбом и постоянно держу под рукой

Получилось, что-то типа такого - Ссылка

Ну если есть желание могу поделится исходниками -)

Пишем Техническое задание. Общие сведения

Общие сведения идут в ТЗ под номером 1

2.3. В разделе «Общие сведения» указывают: полное наименование системы и ее условное обозначение; шифр темы или шифр (номер) договора; наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; перечень документов, на основании которых создается система, кем и когда утверждены эти документы; плановые сроки начала и окончания работы по созданию системы; сведения об источниках и порядке финансирования работ; порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

Казалось бы ничего сложного. Но есть ньюансы -)

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

Я использую для 3-х последних пунктов магическую фразу следующего вида -  Порядок и объем финансирования работ/сдачи работ/и тп определяется договорными материалами между Заказчиком и Исполнителем.

Вторая порция ньюансов связана с перечнем документов на основании которых проводятся работы. Надо сказать что не стоит сюда вставлять, что попало (для этого есть раздел "источники разработки"). В принципе достаточно сюда воткнуть ссылку на договор по которому вы делаете проект. И все. В крупных конторах можно дополнительно притянуть - План капитальных затрат (если в нем есть пункт выделения денег на ваш проект), какое-либо распоряжение о проведении работ\проекта. Главное правило - документ должны быть реальными и утвержденными с указанием даты утверждения. Различные концепции, целевые программы, типовые проекты вносятся в другой раздел.

Третий ньюанс. В первом пункте укажите после краткого названия системы в скобках (далее - Система). Это позволит вам во всех своих документах и проектах именовать Систему однообразно и позволит избежать ошибки копипаста. Ну или можно использовать подставляемые поля Ворда.

Пишем Техническое задание. Описание объектов автоматизации

2.5. В разделе «Характеристики объекта автоматизации» приводят: краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию; сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

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

Я использую следующий общий подход по его написанию:

Пишем Техническое задание. Показатели назначения

Показатели назначения... Одна из самых мутных статей ГОСТа.
В самом госте требования к содержанию Показателей мутны и непонятны. Вот посмотрите:

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

Но что тут надо писать реально, история умалчивает. Я встречал разные альтернативные мнения и подходы из которых можно выделить 3-и:

Пишем ТЗ: Что такое Назначение Системы, Цели и Задачи

Этим постом я открываю серию публикаций, а в реальности серию заметок для себя по вопросам написания проектных документов, оформления требований, SRS и концепций и прочей "фигни" которая отравляет жизнь настоящего творца, но без которой сделать проект в России для гос заказчика нереально -). Итак...

Очень часто когда обычных ИТ-шников просят написать VISION на систему на них сходит ступор. С чего начать? Особенно если вас просят начать с ТЗ по ГОСТ34 -). А оно начинается с Назначение, Цели и Задачи. А есть еще Показатели назначения, о которых рекомендуется не писать вообще.  По первой я то же не сразу приобрел легкость бытия, но регулярно встречаю различные перлы на эту тему. Приступим: