🤔 Как можно понять из вчерашнего поста, встроенные системы реального времени часто предъявляют жёсткие требования к надёжности и доступности.

Жизненно важные системы, такие как медицинские устройства и авионика самолётов, не оставляют места для отказа. В таких случаях повышение надёжности становится приоритетной задачей.

Однако определение требований к надёжности должно быть реалистичным и учитывать вероятность и влияние отказа. Чрезмерное усложнение продукта может привести к необоснованным затратам и снижению эффективности ❌

Приведём пример из практики 👀

👉 В одном из городов Америки при отправлении поезда монорельсовой железной дороги от станции не закрылась дверь вагона. Видимо, датчики не уведомили водителя поезда о неисправности.

Разработчики системы для поезда, вероятно, имели требование к надёжности, где говорилось, что такое событие может произойти не чаще одного раза на каждые 100 миллионов часов работы. Однако невозможно перед выпуском прогнать поезд несколько сотен миллионов часов, чтобы проверить выполнение требования.

Вместо этого системы надо проектировать так, чтобы вероятность критически опасного отказа была достаточно низкой, чтобы удовлетворить требование. Но вещи ломаются. В данном случае причиной отказа стала коррозия сразу двух переключателей. Это сочетание отказов, о котором не подумали разработчики 🚫

То есть, мы можем сделать следующие выводы:

✅ Повышение надёжности и доступности не всегда является бесплатным удовольствием.

✅ Необходимо реалистично оценивать требования к надёжности, чтобы избежать чрезмерного усложнения продукта.

✅ Вероятность критически опасного отказа должна быть достаточно низкой, чтобы удовлетворить требования.

#УправТреб #Управлениетребованиями #Реализацияпроекта #ПроектноеУправление #Системыреальноговремени #Полезнознать