НовостиОбзорыСобытияIT@WorkРеклама
Идеи и практики автоматизации:

Блог

Кто будет расплачиваться за системные ошибки?

Нежелание заказчиков, фактически незнакомых с процессами создания ПО, оплачивать длительные этапы отладки (а это подчас 60-70% всего проектного времени) хорошо понятно. С какой стати платить за время, потраченное на устранение чужих ошибок? В отношении массовой продукции это справедливо, но чем "корпоративнее" проект, и чем он сложнее, тем больше ресурсов потребуется инвестировать именно в отладку и тестирование. Однако и тут бывают исключения: иногда сроки и бюджеты так безумно затягиваются, что нервы не выдерживают у самых выдержанных менеджеров.

Пример -- свежий октябрьский конфликт между Пентагоном и Lockheed Martin по проекту истребителя пятого поколения F-35.



[spoiler]Озвученная стоимость партии из 2447 машин -- 382 млрд. долл. (150+ млн. долл. за самолет!), привела военных в ярость. Они заявили, что пускай теперь корпорация устраняет проблемы, выявляющиеся в процессе тестирования (а бортовой софт машины сложнее, чем Windows), за свой счет. В перерасходе бюджета имеется, конечно, и немалая вина заказчиков -- в ходе работ над машиной их требования не раз менялись и расширялись, отмечают представители Lockheed Martin, а это всегда ведет к новым и новым багам, особенно учитывая инновационность работ. И тем не менее военные настаивают на подписании новых договоров с фиксированными ценами, по которому должна быть поставлена полностью отлаженная продукция.

Чем сложнее современные высокотехнологичные проекты, тем больше и больше ресурсов уходит на их доводку, зависимость по-моему, здесь уже экспоненциальная. В такой ситуации уже просматривается примерный предельный уровень сложности -- до 50 млн. строк кода (в рамках массовых, мэйнстримовских проектных подходов; но ведь переход на иные методологии в рамках целой индустрии -- мероприятие крайне рискованное само по себе). Так, вполне возможно, что истребители шестого поколения появятся в реальной эксплуатации значительно позже, нежели обещается сегодня. МО США уже сдвинуло соответствующие сроки  на десять лет -- с 2030-х на 2040-е -- и это при том, что прототип, по заверениям Northrop Grumman, практически готов. Десятки лет и сотни миллиардов долларов -- и это в ситуации, когда например имеются прекрасные САПР, а средства разработки очень удобны и эффективны! Обязанность платить за собственные баги наверняка сдвинет эти сроки в бесконечность.

Схожая ситуация и с австралийскими дизель-электрическими подводными лодками Collins, которые планировалось закупить в количестве 12 штук в период 2030-0240 гг. В проект уже вбухано 5 млрд. австралийских долларов, а стоимость годового сопровождения одной лодки достигла рекордных в мировой истории 105 млн. ам. долл. для субмарин данного класса. И это при использовании специализированного maintenance-софта OPUS10 шведской Systecon AB (в Швеции создаются собственные подлодки нового поколения A26). Не в силах справиться с проектом, австралийцы обратились за технологической помощью к США...

У нас намедни решено продолжать развитие атомных подводных лодок "Ясень" и "Борей". Бюджет почти в миллиард долларов согласовывали около полугода. И вот:
"Представители российского Военно-морского флота не хотят принимать на вооружение новые цифровые атомные подводные лодки проекта 955 "Борей" из-за опасности сбоев, которые могут возникнуть в неотлаженной до конца компьютерной системе. В руководстве флотом указывают, что доказательством обоснованности таких подозрений служат первые ходовые испытания АПЛ "Александр Невский", когда были выявлены несколько десятков крупных и тысячи мелких недоработок...
Эти цифровые системы настолько сырые, что с ними просто опасно работать...
"Бореи" стали первыми в истории России подлодками с цифровой системой управления — предыдущие поколения лодок имеют аналоговые. В разработке и изготовлении элементов цифровой системы участвовало несколько десятков предприятий и конструкторских бюро...
В море, на ходу, на лодку влияет много факторов, которые не всегда математически просчитывались разработчиками..."

Но главная проблема, конечно -- это часто меняющиеся требования, особенно если проект долгосрочный, а немало потенциальных влияний на работу системы учесть физически нереально, спасают только тщательные полевые испытания. Например, "Борей" пережил трехкратное перепроектирование под три разные комплекса вооружения".
А уж ситуация с "Фобос"-ом еще более наглядная...

Зарубежный опыт: после банкротства вертолетного проекта RAH-66 Comanche все силы были брошены на развитие армейского геликоптера AH-64 Apache -- и только в последнее октябрьское расширение Block III вошло 26 новых технологий (от цветных дисплеев и подвижных цифровых карт до улучшенного софта радаров и расширенных механизмов самодиагностики, включая электронный контроль за работой двигателя)! Но и бюджет его 619 млн. долл. Главное методическое отличие от предыдущих блоков -- активное применение промышленных стандартов (как это ни удивительно), открытая архитектура и вычислительные ресурсы "с запасом".

Как же успешно бороться со сложностью в современных мега-проектах? Оказывается, подчас достаточно обеспечить элементарные проектные требования -- открытость, стандарты, модульная расширяемая архитектура. Почему это не сделано в проектах с десятилетней историей, понятно, а вот почему так не делается (если не делается) в новых проектах, совершенно неясно, недопустимо и непростительно.
Михаил
подчас достаточно обеспечить элементарные проектные требования -- открытость, стандарты, модульная расширяемая архитектура.
Вот как раз это может привести не к уменьшению, а к увеличению сложности и сроков. Всё зависит от разработчиков.
проблема, конечно -- это часто меняющиеся требования
Нужно устанавливать точку невозврата, когда новые требования должны будут переноситься на следующую версию проекта, иначе мы будем иметь то, что имеем.