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

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

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

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

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

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

Мандмап служит мне шпаргалкой при начале работ, в первую очередь, сбора сведений и требований, на системы мониторинга не из коробки.

Во вторую очередь данная схема дает хорошее представление о структуре информационного обеспечения АСУ. Если есть необходимость писать данный проектный документ, конечно.
Хотя именно П5 является тем самым документом, за счет которого без больших проблем можно набрать необходимые брутто-тонны технического проекта.

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

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

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

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

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

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


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

Как надо проектировать систему мониторинга

Решил под новый год поделится используемому мной подходу к проектированию систем управления. Итак ...

Проектировать систему мониторинга можно 2-я способами:
1. Расписать сколько серверов вы ставите, куда ставите агентов, накатить штатные шаблоны и оставить клиента с полученной спам-машиной один-на-один. Нехай мучается
2. Разработать инженерную модель управляемого объекта и настроить систему мониторинга в соответствии с полученными результатами.

Чем хорош первый вариант? Простотой! Думать не надо. Деньги зарабатываем на лицензиях.
Чем плох? У всех более менее крупных заказчиков этот фокус проворачивали пару раз как минимум. И очень большая конкуренция. И надо быть партнером вендора...

Чем плох второй вариант? Думать надо! Нужны спецы в предметной области. Нужно писать скрипты как минимум. Заказчик не готов за это платить или не хочет.
Чем хорош? Практически нет конкуренции. Нет капитальных и логистических затрат. Если вы влазите в проект и грамотного его делаете, то можно легко перейти на сопровождение и постоянный доход. Вас могут начать приглашать на аутсорс систем управлений.

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

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

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

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

Но все проще:

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

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

Итак - а кому нужна вообще документация? Ведь первый повод отказа от документирования - звучит именно так: "Ее все равно никто не будет читать кроме автора!"

Пишем документацию: Функциональная схема

Описание функциональности АС (П2, ПД и тп) неплохо будет проиллюстрировать картинкой - Схемой функциональной структуры.

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

• описать состав функциональных подсистем
• описать состав входящей информации
• описать состав исходящей информации
• описать схему информационных потоков

Схема достаточно просто делается и для меня в том числе является реальным инструментом проектирования. Схемка включает следующие элементы:

• квадратики изображающие функциональные подсистемы (например для сервисдеск системы: подсистема управления инцидентами; подсистема справочников, подсистема КБД, подсистема SLA).
• стрелочки входящие в квадратик подсистемы извне (от других АС или людей)
• стрелочки исходящие из квадратика подсистемы вовне (к другим АС или людям)
• стрелочки между квадратиками подсистем

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

ТРП - Структурная схема системы

С чего мы начинаем выбор квартиры - с двух схем: 1) Карты района; 2) Плана квартиры.

А сколько типов схем вы используете для иллюстрации примененных или предлагаемых технических решений?

Я использую всего 3. А видел много -). Итак:

1. Структурная схема
2. Функциональная схема (расскажу позже)
3. Схема автоматизации бизнес\технологического процесса (если он есть) (аналогично)

Структурная схема