hedgeov: (Default)
Вытащу из комментариев и дополню разборки с применением ТОС к софтостроению.

Имеем в самом общем случае такую цепочку (да, тут совершенно нет стадии написания документации, где она я пока не знаю):

Новая функциональность
         |  
        \|/
      Анализ -> Проектирование -> Кодирование -> Тестирование -> Внедрение
         ^                                                           |
         |   Обнаружение ошибок на этапе эксплуатации            < —-



Полное время обработки новой фичи с момента поступления запроса на имплементацию до выпуска нового релиза:

  1. Время наладки: наладки нет>

  2. Время обработки: время, нужное ресурсу для имплементации

  3. Время ожидания в очереди к ресурсу, пока ресурс занят предыдущими фичами, либо исправлением ошибок

  4. Время ожидания тестирования и выпуска билда.


Что видим: видим что если аналитики с разработчиками заняты разгребанием багов, на новые фичи им времени может не хватить.


"Выработка — это скорость, с которой система генерирует доходы посредством продажи.
Запасы — это деньги, вложенные системой в приобретение вещей, которые она намеревается продать.
Операционные расходы — все деньги, которые система затрачивает на то, чтобы превратить запасы в выработку."

Получается что

  • Выработка — поставка новых оплаченных фич пользователям.

  • Запасы — Вообще складывается ощущение, что запасы в основном это фича-реквесты от пользователей и мозги программистов :) Ну и тулы в том смысле, что это какие-то исследования/новые технологии, которые ты потом будешь продавать (блин, вот не то всё-таки).

  • Операционные расходы — зарплата, офис и компьютеры; Кроме того интересно: вот ты фичу выпустил, а в ней бага. Ты потратил деньги на выпуск фичи + на исправление баги (потому что пользователь тебе заплатил только за фичу, а не за исправление баги). Так что это еще и расходы на исправление багов.



В чем тут проблема: у нас выпадает установка и настройка системы новому пользователю, а это какая-то иная цепочка вроде бы как.
hedgeov: (Default)
Бродил/читал про Modelica, Simantics, VirtualTestBed и набрёл на свободно распространяемую систему поддержки жизненного цикла продукта, Aras Innovator.

Надо подумать где бы её применить.
hedgeov: (Default)
Интересно, оказывается продвижением системной инженерии в родном отечестве занимаются не вояки, не какое-нибудь правительство, а Росатом.
UPD. Да, при этом в США основная заинтересованная в системной инженерии сторона — министерство обороны.
hedgeov: (Default)
Когда мне было лет 10, я осознал, что любой товар народного потребления спроектирован таким образом, чтобы при штатной эксплуатации не привести к гибели человека. Когда я начал работать с компьютерами я понял, что даже если включить шлейф FDD наоборот — компьютер не сгорит, потому что в него встроены защиты. Автомобиль может проехать тыщу другую километров без моторного масла (да, потом двигатель может и помереть). При отказе ГУРа руль всё-таки можно повернуть. Если неправильно вставить CD в привод, то ничего страшного не случится. Иными словами — разработчики серийных изделий предусмотрели возможные нештатные ситуации и сделали конструкцию таким образом , чтобы и устройство не сильно испортилось и человек не пострадал.

Начав в 2000 году программировать микроконтроллеры я несколько раз вставлял микроконтроллер неправильно. Он грелся, но после правильного включения начинал работать как ни в чем не бывало. То есть и тут разработчики предусмотрели защиты от нештатных ситуаций. В 2003 году я начал работать в фирме изготавливающей источники рентгеновского излучения. Спалив плату интерфейса RS-232 и увидев масштабы разрушения силового моста при КЗ непосредственно на силовых транзисторах я понял, что что-то в этой благостной картине не чисто. Где-то в течение года, спроектировав свою систему цифрового управления источником рентгеновского излучения пришло понимание, что отныне я с коллегами-электронщиками выступаю в роли тех самых разработчиков, которые должны предусмотреть разнообразные защиты нашего изделия от действий неквалифицированного пользователя и от некоторых нештатных ситуаций. При этом без риска для жизни (в блоке управления 380 вольт 1 кВт нормальное явление, в блоке излучателя напряжение до 200 кВ) лезть внуть изделия с паяльником или даже просто с пробником может только высококвалифицированный инженер-электронщик.

К чему всё это многабукаф.

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

1960. Тюратам. Взорвалась ракета Р-16. Погиб главком РВСН М.И. Неделин. Причины — нарушение технологии разработки системы управления, спешка к празднику, высокое начальство на площадке, нарушение правил техники безопасности
1986. Припять. Взрыв на ЧАЭС. Радиационное заражение планеты. Причины — нарушения правил эксплуатации, длительная работа в опасном режиме по команде диспетчера электросети , ошибки проектирования.
2009. Черемушки. Разрушение машинного зала СШГЭС. Гибель около 100 человек. Причины — пока что только нарушение правил эксплуатации, износ оборудования, ожидание высокого начальства на площадке, ожидание пуска ГА6.
hedgeov: (Default)
Одно из многих.
Системный кризис нааамного страшнее, нежели жалкий экономический. Плохо. Очень. При этом брать огонь на себя кишка тонка, а вероятность выплыть весьма и весьма мала. :(
Page generated Sep. 23rd, 2017 11:41 pm
Powered by Dreamwidth Studios