ВЭБ ПОДДЕРЖИТ БЕ-200
Тема: ВЭБ ПОДДЕРЖИТ БЕ-200
29.07.11 Молчанов Юрий пишет:
"ИТ-продукты разные бывают. Это может быть игрушка, а может быть корпоративная ERP - система. Внедрение такой системы по сложности вполне сопоставимо с созданием и запуском в производство самолета".
* * *
Меня давно интересует, есть ли какие-нибудь стандарты на разработку ИТ-продуктов, подобных Квалификационным требования КТ-178 на разработку ПО для гражданской авиации?
Есть ли требования на проведение независимой верификации?
Есть ли требования на резервирование ПО?
Есть ли требования на резервирование аппаратной части? - при этом резервы, включая ПО, должны быть разработаны разными разработчиками (исполнителями) на разнородном железе!
Есть ли это в ERP-системах??? - кто может сказать? - сгораю от любопытства!
Кстати, срок службы самолёта 25-30 лет, после чего проводится кап. ремонт с целью восстановления ресурса.
Каков жизненный цикл в ERP-системах???
Ильдус пишет:
1) А разве в Трудовом кодексе написано, что верхняя планка оплаты ограничена? И при капитализме конкуренцию предпринимателей (владельцев фирм и фирмочек) за грамотных специалистов кто-нибудь отменял?
===
А земля - круглая! :)))
2) Я здесь несколько раз поднимал вопрос, как нормировать труд инженера? Всех интересует, сколько стоит разработка самолёта, но никому не интересно оценить стоимость разработки одного чертежа!
===
Вы забыли что главное не чертеж, а идея! Именно она на том же западе ценится дороже всего. Со времен СССР технические идеи в России реально практически ничего не стоят. Патентное право еще очень в зародышевом виде.
3) Поскольку все начинают с оценки конечного окончательного продукта, то стоимость зарплаты определяется деньгами, которые можно на эту оплату пустить. В ИТ-разработке не надо часть денег тратить, например, на содержание всевозможных стендов и обслуживающего этих стендов персонала. Соответственно ИТ-разработчику можно заплатить больше.
====
Ну и что? Вам никогда не приходилось заказывать простейшее изделие - сидушку от унитаза на Боинг? Этот кусок дешевого пластика стоит почти 800 американских рублей, как будто она позолочена
Вот поэтому вопрос ценообразования — основной при обсуждении и согласовании контрактных обязательств. И это надо поднять все разом по всей кооперации, а у нас там более 600 предприятий. Причем это все надо делать с военными представительствами, потом обобщить, представить в Минобороны…
==
Там много очень спорных статей затрат, начиная с налогов и откатов.
А за вооружение клиент, в лице государства, не готов платить достаточную сумму.
===
Вот с этого и надо начинать. А кому готов платить, говорить не буду, люди тут взрослые, сами знают
Там есть разница или нет её в разработке ИТ-продуктов "наземного" назначения и "железа" для самолёта???
===
Принципиальной разницы нет. Однозначно!
Ильдус пишет:
Меня давно интересует, есть ли какие-нибудь стандарты на разработку ИТ-продуктов, подобных Квалификационным требования КТ-178 на разработку ПО для гражданской авиации?
===
Куча стандартов ИСО
Есть ли требования на проведение независимой верификации?
===
Есть
Есть ли требования на резервирование ПО?
====
В зависимости от требований заказчика
Есть ли требования на резервирование аппаратной части? - при этом резервы, включая ПО, должны быть разработаны разными разработчиками (исполнителями) на разнородном железе!
===
Все по потребностям заказчика
Есть ли это в ERP-системах??? - кто может сказать? - сгораю от любопытства!
===
Дык обратитесь например к Евгению Фролову в Бауманку или на его сайт, там много интересного прочитаете, всеж доктор и прфессор. Ссылку дать или сами найдете? ;))
Кстати, срок службы самолёта 25-30 лет, после чего проводится кап. ремонт с целью восстановления ресурса.
====
А вот эта мысль в современном мире просто вредна. Нет никакого заранее известного ресурса. Его определяет эксплуатация
19:40 Ильдус пишет:
Меня давно интересует, есть ли какие-нибудь стандарты на разработку ИТ-продуктов, подобных Квалификационным требования КТ-178 на разработку ПО для гражданской авиации?
***************************************************************************************************************************
Есть. Только они не похожи на RTCA DO-178... Вот, взгляните, если интересно:
http://www.complexdoc.ru/ntdpdf/...
http://www.complexdoc.ru/ntdpdf/...
http://www.complexdoc.ru/ntdpdf/...
http://www.complexdoc.ru/ntdpdf/...
Терминология:
http://www.complexdoc.ru/ntdpdf/...
И вот - требования к содержанию документации:
http://www.computer.edu.ru/data/files/as-50.htm
Назаренко Юрий Анатольевич пишет:
Есть.
==
Это старые ГОСТы, неужели до недавних ИСО/МЭК серии 90000 (именно девяносто тысяч) Вы еще не дошли, например http://www.iso.org/iso/.../catalogue_tc/catalogue_detail.htm?csnumber=35867?
И по ссылкам ISO/IEC 19761:2011
Software engineering — COSMIC: a functional size measurement method
ISO/IEC 15026-2:2011
Systems and software engineering — Systems and software assurance — Part 2: Assurance case
ISO/IEC 20000-1:2011
Information technology — Service management — Part 1: Service management system requirements
Ильдус пишет:
- Меня давно интересует, есть ли какие-нибудь стандарты на разработку ИТ-продуктов, подобных Квалификационным требования КТ- 178 на разработку ПО для гражданской авиации?
Конечно существвует множество стандартов, ту же ЕСПД например, никто не отменял. Но отрасль настолько динамична, что ...
Короче, в области разработки публичного ширпотребовского программного продукта стандарты применяются в той же степени, в какой они применяются Микрософтом. То есть - ...
ERP системы это совсем другое. Эти системы поставляются в виде наборов стандартных функциональных модулей - подсистем, которые настраиваются и дополняются согласно требованиям клиента. Вот на процесс поддержки ЖЦ ERP системы уже делаются корпоративные стандарты по рекомендациям разработчика. Эти стандарты регламентируют процедуры проектирования настроек и дополнений, внесения изменений, поддержания эксплуатации и т.п.
Они достаточно жесткие, поскольку ERP-система охватывает все предприятиях корпорации, и любой серьезный сбой может иметь соответствующие последствия. Поэтому есть все - и независимая верификация, и резервное копирование, и резервирование железа вместе с ПО, резервирование каналов связи.
Сложность ERP-систем в другом измерении - они распределенные, многосвязные, многопользовательские...
Например, наша корпоративная ERP функцирнирует на дюжине площадок в шести городах. Серверы находятся в Москве. Связь по выделенной оптике, резервирование каналов связи - через спутник. Одновременно работают несколько тысяч пользователей.
Охватывает всю деятельность - от заготовки материалов до реализации и управления персоналом.
Поддерживает систему центр компетенции, который тоже распределен в пространстве.
По жизненному циклу - мы начинали внедрение в 2004, в 2005-2006 запускались последовательно на предприятиях. А уже в следующем 2012 начнется переход на новую версию - считайте полный реинжиниринг. Потом просто SAP (разработчик системы) прекратит поддержку старой версии.
Явкин Александр
Знаю.
Были ситуации типа забыли просто про то, что этот этап работ тоже потребуется. Естественно, никто уже не был готов на выделение денег в тот момент, когда про это вспомнили. В результате либо делали бэзвозмэздно, либо начинали придумывать хитрые комбинации из серии "как бы нам обойтись тем, что у нас уже имеется", причем иногда такие, что и рассказывать стыдно, какой бред получился.
Из самых эпических примеров -
1) САУ-140, которую Авионика долго и упорно доводила за свой счет (финансирование от антоновской фирмы вроде уже заглохло), при том, что усомниться в востребованности этого самолета можно было уже тогда.
2) Забыли в разработку КСУ включить изготовление комплекта для межведомственных испытаний. История по выпутыванию из этой ситуации была долгая, увлекательная, и я сильно сомневаюсь, что подробности стоит публиковать.
3) Для КСУ предполагалось не пользоваться КПА, а все работы по обслуживанию системы проводить с выводом всей технологической информации на индикаторы в кабине. Потом люди, причастные к испытаниям системы и самолета еще на стадии РКД взвыли, что прыгать туда-сюда по шайтан-лесенкам - это варварство по отношению к тем, кто будет сопровождать испытания и вообще в дальнейшем обслуживать самолеты. В результате что-то похожее на КПА появилось, но ни о какой оплате разработки, испытаний этого изделия речи уже не шло.
4) Для другой КСУ тоже создавалось что-то похожее на КПА (к счастью, они получились однотипные с предыдущим, поэтому масштаб финансовых потерь получился меньше, чем мог быть). Там забыли включить разработку РКД в ведомости исполнения на систему (или еще в какие-то подобные документы военно-финансового толка). Поэтому по настоянию ВПМОРФ при самолетной фирме этап разработки РКД был исключен из технического задания на эту диагностическую аппаратуру. Я, как носитель этого камня на своей шее, был против, но главный конструктор сказал, что раз так оно вышло, мы будем делать РКД на халяву. Я долго спрашивал "а испытания мы будем проводить на соответствие чему, если, исходя из технического задания, у нас РКД нет вообще?", но меня уже никто не слушал. Там еще пикантность ситуации была в наличии смежников, в планы которых не входило делать свою часть РКД бэзвозмэздно, до чего с ними договорились в результате, я не знаю, ибо уже к тому моменту уволился.
sys пишет:
В зависимости от требований заказчика
. . .
Все по потребностям заказчика
* * *
А в авиации по требованию забугорных ГОСТов
* * *
sys пишет:
А вот эта мысль в современном мире просто вредна. Нет никакого заранее известного ресурса. Его определяет эксплуатация
* * *
Вот тут я с Вами по поводу вредности соглашусь :)
Везде выбрасывают указание о ресурсе и пишут "эксплуатация по состоянию". При этом где-то должно быть указано, как определить предотказное состояние. Но этого нет! Для этого нужны длительные исследования... А деньги где? А что у нас с ЦНИИИ-22 МО?
И этого нет для критических систем, отказ которых может угробить людей. На сегодняшний день эксплуатация по состоянию российской авиатехники - это непредумышленное убийство!
Ильдус пишет:
А в авиации по требованию забугорных ГОСТов
=
Не только в авиации, я ведь не просто так дал ссылку на стандарты ИСО/МЭК.
И этого нет для критических систем, отказ которых может угробить людей.
==
Помнится еще с советское время до 2 этапа испытаний должен быть определен перечень оборудования, единичный отказ которых приводит к аварийной/катастрофической ситуации. Точнее лениво вспоминать.
Ильдус пишет:
На сегодняшний день эксплуатация по состоянию российской авиатехники - это непредумышленное убийство!
=
Помнится лет 15 назад мне приходилось ходить на совещания по этому вопросу уровня руководителей авиаНИИ. Главная проблема такого обслуживания это разобщенность КБ и производства и даже отдельные от всех авиаремзаводы.
Назаренко Юрий Анатольевич пишет:
Есть. Только они не похожи на RTCA DO-178... Вот, взгляните, если интересно:
* * *
Спасибо! Скачал, в понедельник почитаю.
* * * * *
Молчанов Юрий пишет:
Короче, в области разработки публичного ширпотребовского программного продукта стандарты применяются в той же степени, в какой они применяются Микрософтом. То есть - ...
ERP системы это совсем другое...
* * *
Если можно, то короткий ответ на вопрос: "Все ширпотребовские стандарты, включая ИСО... запрещают ситуации, что бы система сказала, что допущена ошибка и она (система) перезагружается?" - или опять на усмотрение клиента?
* * * * *
Молчанов Юрий пишет:
Потом просто SAP (разработчик системы) прекратит поддержку старой версии.
* * *
А я лет двадцать назад закончил разрабатывать систему, а в прошлом году предприятию пришлось писать ремонтную документацию на эту систему. И никаких "прекратил поддержку" ещё лет на десять.
sys пишет:
Помнится еще с советское время до 2 этапа испытаний должен быть определен перечень оборудования, единичный отказ которых приводит к аварийной/катастрофической ситуации. Точнее лениво вспоминать.
* * *
Правильно, был. И сейчас есть перечень систем, отказ которых приводит к аварийной/катастрофической ситуации. Только в этих, например, с четырьмя резервами, системах единичный отказ называется неисправностью (хотя вышел новый ГОСТ на определения в надёжности и может называться иначе). Короче говоря (если забросить тавтологию), система может угробить людей после третьего отказа. - Для новой системы это практически не вероятное событие.
Но как предсказать на старой системе, что сегодня это практически не вероятно, а после завтра в течение полёта можно последовательно получить три отказа и... Ах!-Ох!-Ой!
Справка (ликбез) для любителей:
После изготовления электронной аппаратуры вероятность выхода из строя очень велика. Систему подвергают приработке (что бы электроны притёрлись :). Этот первый временной участок должен остаться у изготовителя. Далее идёт длительный участок с небольшой интенсивностью отказов - это эксплуатация. Затем третий участок, когда вследствие старения элементов интенсивность отказов растёт.
Очень напоминает жизнь человека:
- в детстве болеет часто,
- в зрелом возрасте меньше,
- в старости много.
И как определить, кто, сколько ещё проживёт? Однако, исследования нужны... Где деньги?
А ИТ-продукт морально стареет быстрее, чем физически.
Ильдус пишет:
- Если можно, то короткий ответ на вопрос: "Все ширпотребовские стандарты, включая ИСО... запрещают ситуации, что бы система сказала, что допущена ошибка и она (система) перезагружается?" - или опять на усмотрение клиента?
Это к Биллу Гейтсу. В ERP на компьютере клиента только агент презентации в принципе все равно под чем - Винды, Юникс и т.д.
Вынесет агента или канал связи - с данными ничего не произойдет, транзакция откатится и все. Все крутится на серверах приложений и серверах данных. Отдельное приложение тоже может глюкануть - может проскочить ошибка через все уровни контроля. Это работа центра компетенции - анализ ситуации, устранение ошибки, оповещение клиентов. Максимум час.
Но еще не было такого, чтобы отказали сервера (тьфу, тьфу, тьфу) - это забота группы системной поддержки.
29.07.2011 Ильдус пишет: "Меня давно интересует, есть ли какие-нибудь стандарты на разработку ИТ-продуктов, подобных Квалификационным требования КТ-178 на разработку ПО для гражданской авиации?"
Ну, Ильдус Махмудович, Вы меня, прямо-таки расстроили своим вопросом. Вот перечень российских и зарубежных требований к "софту" и "железу", основные из которых мы включили в ТЗ по доработке ЭДСУ-200Е:
"CS 25.1301, CS 25.1309, EUROCAE ED-12B, RTCA DO-178B, EUROCAE ED-94B, RTCA DO-248B, KT-248B, EUROCAE ED-79, SAE ARP4754, KT4754, AMC 20-115B, EUROCAE ED-80, RTCA DO-254, KT-254, EUROCAE ED-135, SAE ARP4761, EUROCAE ED-14E, RTCA DO-160E, KT-160E, EASA CM SWCEH-001 Is. 01, EASA CM SWCEH–002 Is. 01"
Мы же привозили на "Авионику" экспертов (кстати, лучших в Европе) с презентацией в плане подготовки предприятия к аудиту экспертами EASA, проводимому в процессе Одобрения конструкторской организации (DOA) компании BISP - разработчика самолета-амфибии Бе-200Е. Неужели все напрасно?
Александр Васильевич пишет:
"Ну, Ильдус Махмудович, Вы меня, прямо-таки расстроили своим вопросом..."
* * *
Ещё раз и помедленней.
Александр Васильевич пишет:
"Я уже приводил информацию с сайта компании MS о примере внедрения ЕРМ в компании «Лаборатория Касперского», в котором на равных участвовала компания «Бастион – Интегратор» из Таганрога"
* * *
Я не спрашивал о стандартах в гражданской авиации дополняющих КТ178 (DO178).
Я спрашивал о требованиях к ПО ширпотребовского назначения, в частности к ПО Касперского, подобных по жёсткости к требованиям в КТ178.
* * *
Далее ПО им. Касперского (которым и я пользуюсь) плавно подменилось в обсуждении на ПО промышленного назначения, в частности корпоративная ERP - система.
Молчанов Юрий пишет:
"Отдельное приложение тоже может глюкануть - может проскочить ошибка через все уровни контроля. Это работа центра компетенции - анализ ситуации, устранение ошибки, оповещение клиентов. Максимум час."
- комментарии нужны? Или может кто-нибудь из профессионалов расскажет, что будет, если система управления самолётом кратковременно, всего на час глюканёт?
* * *
Поставлю вопрос по другому.
"Где издержки и накладные расходы больше? - при разработке ПО, которое может на часок глюкануть или при разработке ПО, которое вообще не имеет права на ошибку???
* * *
И возвращаясь к сравнению разработчика "железа" с разработчиком у Касперского.
Каковы издержки и накладные расходы у Касперского на испытание своего ПО на воздействие климатических, механических и биологических воздействий?
* * *
Будем продолжать сравнивать мокрое с холодным?
* * *
Кстати, очень показательное обсуждение.
Если профессионалы авиации считают, что сложности Касперского соизмеримы со сложностями разработки авиатехники, то почему экономисты с юристами в правительстве должны уделять авиапрому внимания больше, чем Касперскому???
![[image]](https://pics.aviaport.ru/cache/news/170x/726599.jpeg)