?

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-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