Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Требования, верификация, дизайн

Стоимость верификации софта в Boeing -- 50% от общей его стоимости (http://shemesh.larc.nasa.gov/LFM2008/slides/Session4/Manolios.pdf). Для дизайна интегральных схем -- 30%-70% (http://www.ccs.neu.edu/home/pete/courses/Decision-Procedures/2007-Fall/lectures/Lecture0.pdf). Современный инжиниринг, по идее, должен включать формальную верификацию (http://https://dashlink.arc.nasa.gov/static/dashlink/media/group/Manolios-2008-10-Nasa-Panel.pdf). С другой стороны, верификация и сам дизайн связаны много теснее, чем можно подумать (http://www.cs.cofc.edu/~bowring/classes/csis%20602/docs/ManoliosISSTA.pdf -- тут работали с реальной авионикой Boeing 787, сокращение времени верификации было с нескольких человеко-лет до нескольких человеко-недель, что дало возможность попробовать в дизайне другие архитектуры).

Я ровно месяц назад обсуждал вопрос, что произошло (или вот-вот произойдет) с традиционными проблемами AI в последние несколько лет, когда компьютеры стали весьма мощны (http://ailev.livejournal.com). Вот это и произойдет: использование формальной верификации, сначала в дизайне софта, а затем и любом другом дизайне.

Тем самым к системам работы с требованиями возникают не просто вопросы по а) ее связи с верификацией и валидацией в варианте assurance case (http://ailev.livejournal.com/646290.html), но и б) возможность формулировки требований в виде, доступном для формальной проверки.

Наверняка там будет еще и в), г), д)... В частности, нужна какая-то связь с валидацией (буквально накануне Нового Года услышал историю увольнения линейного менеджера, который сначала заставил подписать топа технические требования, а затем в ответ на удивленный вопрос топа, зачем они в проекте делают заведомо неправильные вещи, ответил: "потому что таковы технические требования, которые вы подписали" -- и был уволен в 24 часа после такого ответа. Все верификации на соответствие техтребованиям прошли, а вот валидация -- нет).

Тем самым рассматривать какой-нибудь CAD вне связи с полным Vee циклом стадии дизайна (это мы еще исключаем concurrent engineering!) "сбор требований -- анализ требований -- (архитектурный, детальный) дизайн -- верификация -- валидация" сейчас нельзя. Это must.
* * *
Все руки не доходят вернуться к "серой бумаге" (http://ailev.livejournal.com/545386.html). Комменты в том постинге пошли в сторону формы -- "языкоориентированности". А нужно разворачиваться в сторону содержания -- какие языки (сиречь "методы описания") нам нужны, как их структурировать, как сделать так, чтобы сделанные на этих языках описания попадали к нуждающимся в них стейкхолдерам. Собственно, это одна из постановок задачи "управления информацией".

Но пока нужно выполнить план по постам (http://ailev.livejournal.com/647552.html). После этого язык изложения (да и в значительной мере то, что этим языком излагается) будет совсем другим, нежели в годичной давности "серой бумаге".
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 28 comments