|
марта 10
|
Когда иностранцы говорят, что в науке мы отстали от них навсегда, речь идет не столько о технологиях, сколько о наших «привычках» в работе. Особо тоскливо становится тогда, когда привычки превращаются в «обряды».
Что такое 34-й ГОСТ? Это инструкция проведения обряда! Считается, что если разработка автоматизированной системы проводится с выполнением всех предписаний обряда, то великое “Нечто” дарует системе те качества, которые ожидает получить разработчик.
Как показывает практика, разработка АС по требованиям вышеуказанного стандарта не только не приводит к желаемым результатам, но и приводит к бессмысленным трудозатратам.
Возьмем документ ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.
Согласно этому документу разработка АС должна происходить в следующие стадии:
1. Формирование требований к АС
2. Разработка концепции АС.
3. Техническое задание.
4. Эскизный проект.
5. Технический проект.
6. Рабочая документация.
7. Ввод в действие.
8. Сопровождение АС.
На каждой стадии помимо нужных документов предлагается разрабатывать кучу всякой ерунды, которая работе не помогает и вообще она никому не нужна. Но это еще полбеды. Основная проблема стандарта кроется в подходе. Согласно стандарту, для разработки и внедрения АС мы обязаны проходить последовательные стадии от формирования требований к системе и заканчивая вводом в действие и сопровождением. А что делать если в самом начале мы не можем сформировать все требования? Или в момент разработки рабочей документации требования к системе (например, со стороны бизнеса) поменялись? Или при вводе в действие нужно внести изменения в ТП? По всей видимости нужно возвращаться на несколько стадий назад и начинать работу заново. А что делать если создание системы занимает месяцы или годы? Сколько раз нужно все переделывать?…
Ответы на эти вопросы уже давно есть.
Более того:
Уже 40 лет весь цивилизованный мир не использует подход 34-го ГОСТА!
34-й ГОСТ использует, так называемую “Каскадную модель” жизненного цикла, которая была предложена еще в 1970 г. г-ном Ройсом. Здесь мы проходим все классические стадии:
1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.
Однако эта модель не работает, когда требования к системе невозможно сразу сформулировать или условия использования системы могут поменяться. В результате мы получаем не последовательное выполнение каждого этапа, а что-то вроде этого:
Очевидно что в результате получить “живую” систему довольно сложно.
Поэтому еще в начале 80-х годов прошлого века японцы стали применять так называемую «Спиральную модель», которую в середине 80-х украл и выдал за свою Барри Боэм.
Суть модели сводится к постепенной выработке конечного решения. Например, мы не можем выставить четкие требования на систему сразу, а имеем лишь концепцию или видение конечного результата. В таком случае исходя из видения мы проводим первичное проектирование, вырабатываем решение, тестируем его, анализируем результаты и дорабатываем первичное техническое задание и так до тех пор пока не получим готового технического решения, которое отвечает всем требованиям. В общем-то это вариация на тему цикла Деминга, но подача немного другая.
На основе “Спиральной модели” в 1994 году Microsoft разработали и опубликовали свою методологию разработки программного обеспечения Microsoft Solutions Framework. В настоящий момент практически все производители ПО используют этот подход.
Итого
34-й ГОСТ морально устарел. И все крики некоторых экспертов на тему обязательности соответствия этому ГОСТу равносильны призывам выполнять древний обряд.
Однако стоит оговориться:
… другого ГОСТа нет и окончательно и бесповоротно отказываться от единственного документа нельзя. Правила хоть и плохие, но они есть и их нужно стараться выполнять. Без паранойи, но выполнять. Ну а на перспективу остается только надеяться, что многочисленная армия чиновников или общественников обратят внимание на принципиальную проблему нашего сообщества. Разработка нового стандарта – это титаническая работа, но она необходима.
Может быть недавно образованный АРСИБ запустит процесс? Посмотрим…
.
.
Не секрет, что проверки Роскомнадзора ориентируются, в основном, на проверку существующей документации касающейся обработки персональных данных.
Последние комментарии