RSS    

Видеокурсы

Видеокурсы по ВТ

Опасности в социальных сетях

Социальные сети

Программы для бесплатного просмотра online tv...  

Компьютер заражен? Есть несколько вариантов вылечить ПК...

Стандарт LTE - Long-Term Evolution - или стандарт связи четвертого поколения (4G) считается перспективным... 



Применение ГОСТов при проектировании информационных систем

Зачем, в принципе, нужны ГОСТы при проектировании? 

Получается так, что ГОСТы помогают самому проектировщику.

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

Возникает интересный вопрос: а кому нужно проектирование и все эти пояснительные записки, ТЗ и т.п.? И вот какой интересный ответ у нас получится: на 85% документирование необходимо исполнителю. Оставшиеся 15% нужны заказчику для некоего общего понимания происходящего. Но исполнителю надо четко обозначить как границы проекта, так и признаки его выполнения. Исполнитель должен уметь защищать себя от хаотичности мышления заказчика.

Итак, обратимся к ГОСТам разработчика. Основных у нас их два: ГОСТ 34й серии и ГОСТ 19й серии. 34я серия относится к разработке автоматизированных систем, а 19й – к разработке программного обеспечения. 
Мы будем говорить о ГОСТе 34й серии.

В 34й серии много различных ГОСТов. Нас будут интересовать лишь некоторые из них. А именно:

1. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения
2. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
3. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
4. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем
5. ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем
6. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

ГОСТы чем-то похожи по своей иерархической структуре на каталог. На такой, например, как Active Directory. Вероятно, что если писать документацию четко следуя ГОСТам, то перекрестные ссылки позволят вам ознакомиться с огромным количеством документов. Но что самое главное в ГОСТах, это четкая модель «от общего к частному». Начиная с общих фраз мы дойдем до самого последнего RJ45 в системе.

А теперь более подробно. Основным ГОСТом, вокруг которого идет т.н. пляска является ГОСТ 34.601-90 (Стадии создания). Давайте более подробно посмотрим на этот документ.

госты

Вот такая вот структура встречает нас в данном документе. Что же в этом замечательного? Замечательного в этом то, что мы видим практически полный цикл жизни автоматизированной системы. Почему почти? Потому что тут отсутствует такая стадия как вывод из эксплуатации и утилизация. Но нам это не особо и надо. Пока с лихвой хватит и существующих стадий. Тем более, что стадия утилизации рассмотрена в одном из других ГОСТов, но это выходит за рамки этой статьи.

Как я говорил выше, ГОСТы содержат в себе перекрестные ссылки. И чтобы пойти дальше в наших рассуждениях, мы чуть-чуть заглянем в ГОСТ 34.003-90 (Термины и определения). В нем интересует определение автоматизированной системы. Это важно, т.к. нам все же надо иметь представление, что же мы собираемся создавать.

ГОСТ 34.003-90 в определении автоматизированной системы говорит нам следующее: автоматизированная система; АС: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Т.е. другими словами, АС состоит из 

1. Персонала
2. комплекса средств 
3. некой деятельности, подлежащей автоматизации. 

Так же уточним у ГОСТа 34.003-90

1. комплекс средств автоматизации автоматизированной системы; КСА АС: Совокупность всех компонентов АС, за исключением людей
2. пользователь автоматизированной системы; пользователь AC: Лицо, участвующее в функционировании АС или использующее результаты ее функционирования
3. эксплуатационный персонал автоматизированной системы; эксплуатационный персонал АС
4. компонент автоматизированной системы; компонент AC: Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое

Итак, что же у нас получается? А получается, что мы почувствовали под ногами некоторый фундамент, на который будем опираться. Нам известно, из чего состоит автоматизированная система и уточнили, что персонал бывает двух видов: пользовательский и эксплуатационный. И логически выведем, что компонент АС, выделенный по определенному признаку будет т.с. «hardware» и «software», если совсем просто. И совокупность программы+железо будет комплекс средств автоматизации АС.

Значит, если заказчик, например, скажет «А установите мне Exchange», то это не будет АС по одной простой причине: как минимум в таком задании отсутствует вид автоматизируемой деятельности. А может быть заказчику вообще нужен не Exchange. А может ему совсем нужен не Exchange. А это значит, что требуется обследование объекта автоматизации. А значит начинается стадия первая ГОСТ 34.601-90 (Стадии создания). «Формирование требований к АС»

На этой стадии ГОСТ требует от нас сделать несколько этапов. Если перевести это на человеческий язык, то тут мы должны определить надо ли вообще что-либо разрабатывать. Целесообразно ли это различных точек зрения. В общем, провести оценку необходимости начала работ. Итогом работы по этой стадии становится отчет, который фиксирует результат.

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

В концепции нам необходимо изучить объект, где требуется произвести внедрение. Если в первой стадии мы искали причину создания АС вообще(исходя лишь из бизнес-целей, просто ГОСТ писался тогда, когда таких слов не употребляли), то на второй стадии нам необходимо найти возможные варианты, которые удовлетворяют требованиям заказчика. Например, если заказчик хочет почтовую систему, то это можно реализовать как на Exchange, так и на Postfix или на чем ни будь еще. Со своими плюсами, минусами и вариантами развития. Проводится общая экспертиза объекта и предварительно оцениваются трудозатраты. Мы, как исполнители, тоже ищем для себя наиболее оптимальный вариант.
После того, как мы придем с заказчиком к определенному единому мнению о том, какой именно вариант решения ему подходит в общих чертах больше всего, мы переходим к, не побоюсь этого слова, самому важному пункту проекта «Техническое задание»

Техническое задание, если посмотреть определение ГОСТ 34.602-89, является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

ТЗ настолько важный документ, что ему посвящен персональный ГОСТ. Сейчас мы на этом подробно останавливаться не будем. Замечу лишь, что для правильного формирования ТЗ необходимо, чтобы стадии ГОСТа 34.601-90 «Формирование требований к АС» и «Разработка концепции АС» были выполнены. От качества выполнения этих стадий зависит правильность и корректность создания ТЗ.

По материалам http://habrahabr.ru

 

 

Оставьте свой отзыв:

Похожие статьи:

Добавить комментарий


Защитный код
Обновить

 

Самое читаемое:

Быстрый поиск

Группа вКонтакте: новости

 

Новости в Twitter и Facebook

  подписка на новости в twitter              Подписка на новости facebook

Инструкции к программам

Инструкции к программам

Новые информационные технологии и программы