?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

ГОСТ-овский стиль управления

Posted on 2010.08.22 at 17:32

Comments:


li_538 at 2010-09-11 15:32 (UTC) (Link)
Добавлю свой отзыв.

С удовольствием отмечаю, что наконец наши русские разработчики стали возвращаться к отработанным годами конструкторским советским документам. Результат их _вдумчивого_ применения - рабочее изделие, а не процесс и ворохи проектно-сметной документации с заложенными золотыми унитазами. Очень верно вынесена мысль, что заказчику (не формальному - контрактодержателю), а заказывающему подразделению в общем-то пофиг на все эти красивые процессные подходы и шильдики. Ему нужно полностью соответствующе затребованным ТТХ изделие. А тут как раз замок технического _замысла_, оформленного в виде ТЗ как изделия в целом (не тождественно продукту в зарубежных подходах, т.к. ТЗ также фиксирует подготовку объектов к пусконаладке и ввводу изделия в действие) закрывается ПМИ - то, что реально будет принимать заказчик. И кроме ПМИ вывешивать кучу названий использованных при разработке новомодных подходов - бессмысленно, ибо заказчику пофигу - главное чтобы комплекс работал.

Также за годы наблюдения разработки ИС/АС по гражданским ГОСТ (19 и 34) замечу, что ТЗ и ЧТЗ (хотя корректно - СЧ ТЗ) в основном пользуются как средство освоения бюджета и максимального усложнения проектной документации для обоснования выигранной победителем конкурса стоимости контракта. Со стороны заказчика ситуация похожая - формальный заказчик ратует исключительно за соблюдение оформительских требований и ему пофигу на функционал, а заказывающие подразделения _не умеют_ читать техническую документацию по отечественным ГОСТ, т.к. соответствующая техническая конструкторская школа по сути - умерла и студентам ГОСТ дается не как спасение для структурированния своей дальнейшей работы, а как очередной ненужный довесок. Который все резко забывают.

И выходит, что ГОСТ по сути нужен исключительно системному разработчику, причем высокопрофессинальному, т.е. не тому, который спосбен формировать тонны отчетных материалов, а тому, который ведет свои проектные команды к рабочему изделию - а не во имя процесса и для разработки _макета_, который попытаться выдать на испытаниях за целевой разрабатываемый комплекс.

Вот как-то так.

Причем если сравнивать подходы к разработке действительно _высокосложных_ изделий, в т.ч. включающих в качестве составной части программные средства - подход наших более "жестоких" ГОСТ РВ за исключением одного принципиального различия - точь-в-точь совпадает с американскими DoD MIL STD - XXXX. Отличие простое - у нас предложен фиксированный перечень этапов работ (и неспроста - по ним финансовые акты закрываются), у друзей - итеративная модель разработки, по мере прохода итераций закрываются пункты ТТЗ. Причем у них заказчик на формализованной основе ведет мониторинг хода закрытия пунктов ТТЗ по окончанию каждой итерации. У нас - ПМИ и различные виды испытаний, что дает несколько больше свободы разработчику изделия. И опять-таки, несмотря на наш жестко зафиксированный перечень этапов разработки изделий по ГОСТ РВ в реальной работе разработчиков ПО никто не мешает использовать и XP и SCRUM и прочее. Главное, что все инженерные коллективы при этом работают не на процесс, а на закрытие пунктов ТТЗ. В т.ч., например, подготовка полигона к проведению испатаний, завоз комплектующих испытательного стенда, его сборка и т.д. - все подчинено только созданию изделия. Лишние активности как правило при этом только отъедают драгоценнное время. Как минус - системный разработчик должен очень аккуратно отнестись к процессу документирования конструкторских решений (читай - архитектуры, в случае ПО).

Вот :)
Gaperton
gaperton at 2010-09-12 20:44 (UTC) (Link)
Класс! Спасибо за столь развернутый и глубокий комментарий.

Вопрос - не могли бы Вы раскрыть тему итеративности DoD MIL STD ХХХХ, и дать точные ссылки/номера? И Заодно - расшифровать "ТТЗ".

Что до ЧТЗ или СЧ ТЗ - это и так понятно. :) СЧ - есть Составная Часть ОКР, если кто из читателей не понял. :) То самое "частное" ТЗ, на которые дробится крупное общее ТЗ.
li_538 at 2010-09-14 03:39 (UTC) (Link)
ТТЗ - Тактико-техническое задание. Как правило, разрабатывается на изделия вооружения и военной техники. В т.ч., иногда, содержащих и программные средства.

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

В части MIL STD - вам более понятен будет MIL STD 498 - на ПО и отчетную техническую документацию, разрабатываемую в ходе работы.

Суть крайне проста. Еще на этапе выхода на конкурс участник в составе конкурсной заявки описывает не только и не столько технические подходы к разработке изделия, а также бьет все предъявленные требования на группы, вырабатывает перечень и состав _итераций_, в ходе прохождения которых заказчик получает конкретные закрываемые пункты ТЗ. Аналогично и с затребованными ТТХ по все параметрам (в т.ч. и надежностные) - их достижение вкладывается в итерации. Создается некоторый каталогизатор (что-то наподобие CMDB в ITIL) со стандартным DoD-кодированием, в который под пункт ТЗ вносятся все разработанные модули, подсистемы изделия, закупаемые материалы и комплектующие. Полученные таким образом итерации вместе с конкурсной заявкой отдаются заказчику. По выигрышу - получаемый в результате план-график работы становится утвержденным, а по завершению каждого этапа к исполнителю путешествует комиссия, проверяющая закрытие соответствующих пунктов ТЗ. Как плюс - постоянный контроль за ходом работ и отсутствие необходимости предварительных (заводских) испытаний.

У нас согласно ГОСТ РВ - жестко заданный перечень этапов (взять тот же библейский 15.210). Однако, тут организации-разработчику мне кажется есть большая свобода, т.к. при разработке техники никогда неясно, какой путь в итоге окажется верным. Если зажать тисками как у коллег сделано - стало бы совсем худо.

Еще раз замечу - нигде ни в отечественных ГОСТ РВ, ни в MIL STD нет работы на процесс. Есть работа на создание изделия, которая подчинена _замыслу_ и ТТХ, зафиксированным в ТТЗ. Это не только разработка ПО, документации. В 95% случаев - по минимуму аппаратно-программные комплексы "под ключ" с подготовкой объектов к вводу в эксплуатацию, а зачастую - гораздо более сложная техника.
Gaperton
gaperton at 2010-09-14 10:58 (UTC) (Link)
> В части MIL STD - вам более понятен будет MIL STD 498 - на ПО и отчетную техническую документацию, разрабатываемую в ходе работы.

Мне будет понятен любой MIL STD, не только на ПО. Я уже давно чистым софтом не занимаюсь.

Не могли бы Вы привести точную ссылку на документ стандарта с "итерациями"? SPD из 498 никаких итераций не содержит.

Он их не запрещает, конечно же. Но в этом же смысле и работу по ГОСТ можно нарезать на СЧ ОКР, так, что она станет итеративна.
li_538 at 2010-09-14 11:20 (UTC) (Link)
Тот же DoD MIL STD 498, п. 4.1, изображения 9-10 и прочие в конце документа.
Gaperton
gaperton at 2010-09-14 12:49 (UTC) (Link)
Так. Смотрим.
http://www.abelia.com/498pdf/498-STD.PDF

Да, действительно, не только не запрещает итеративность, но и показывает, как выбирать между предварительным проектированием, планируемыми итерациями, и "гибкими" итерациями в стиле Agile.

Appendix G вообще крайне любопытен. Особенно таблица с анализом risks/opportunities при выборе стратегии.

Спасибо.
Previous Entry  Next Entry