Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Чудеса системной инженерии

Подводная лодка New Hampshire была построена на 8 месяцев раньше плана и на $54млн. дешевле бюджета -- http://ap.google.com/article/ALeqM5hrI3P4juOZcJHhRsv8epLuGciIGAD91EL7MO0. Строили General Dynamic's Electric Boat и Northrop Grumman Shipbuilding. The Virginia-class submarines are the latest generation of attack submarines, capable of launching Tomahawk cruise missiles, torpedoes, and autonomous undersea vehicles from anywhere in the world. The New Hampshire is the newest of this class, and it is equipped with cutting edge sonar systems and specialized accommodations for SEALs teams — the Navy's elite special operations component.

А вот за счет чего (http://www.gdeb.com/mainNH2.html):
-- построена из четырех секций, а не десяти, как предыдущая того же класса. Такая модуляризация помогла контролировать стоимость.
-- время строительства было уменьшено с 84 до 72 месяцев (т.е. планировали на 4 месяца короче предыдущей лодки, а по факту уложились на год раньше).
-- заодно в это время вошло покрытие корпуса, чего раньше не было.

Учиться, учиться и учиться. Системной инженерии.
* * *
Небольшой список стандартов системной инженерии:
ISO/IEC 15288:2008 Systems and software engineering — System life cycle processes.
ISO/IEC 26702:2007 Systems engineering — Application and management of the systems engineering process
ISO/IEC 15289:2006 Systems and software engineering — Content of systems and software life cycle process information products (Documentation)
ISO/IEC TR 19760:2003 Systems engineering — A guide for the application of ISO/IEC 15288 (System life cycle processes)
ISO/IEC PDTR 24748 (draft) Systems and software engineering — — Guide for life cycle management
ISO/IEC TR 24774:2007 Software and systems engineering — Life cycle management — Guidelines for process description
ISO/IEC 42010:2007 Systems and software engineering -- Recommended practice for architectural description of software-intensive systems.
ISO/IEC 15504 Information technology -- Process assessment (подробные разъяснения http://en.wikipedia.org/wiki/ISO_15504).
Существенным является также понимание стандартов серии ISO 9000 (на них многочисленные отсылки).
* * *
Внимательное прочтение ISO/IEC TR 19760:2003 обнаруживает много интересных особенностей, например:

Организация -- это именно организация, которая выживает через множество проектов. Антропоморфна: имеет цели и т.д. Проект -- это тоже вполне себе антропоморфное образование, имеет интерес, выживает при переходе от подпроекта к подпроекту. Неожиданно выясняется масштаб: As a rule of thumb, project teams consist of seven plus or minus two members to develop the teamwork necessary for maximizing efficiency and effectiveness (ISO/IEC TR 19760:2003, 5.3.3. Project organizational structure) -- а на картинке 8 там приводится глубокая иерархия проектов и связанных с ними подсистем.

Для процессов нужно иметь обеспечение (5.5.1.3 Enabling mechanisms):
-- рабочую силу для выполнения задач (tasks -- странно, что не использовано слово activities)
-- другие ресурсы, типа зданий, оборудования и бюджета (funds).
-- инструменты (например, софтовые, железные, автоматизированные, ручные) для выполнения действий (а тут именно activities!)
-- технологии, включающие методы, процедуры и техники.

К технологиям выполнения процессов (ISO/IEC TR 19760:2003, 5.5.4 Methods and tools -- как ни странно, слово "технологии" из 5.5.1.3 не используются, тем самым процедуры и техники тоже исчезли. Но по смыслу -- тут именно технологии) тоже есть требования:
-- технология не заменяет сам процесс, которому нужно следовать, но поддерживает действия (activities). Методы выбираются, чтобы соответствовать стадиям жизненного цикла и типу системы, которая инжинирится, используется или поддерживается.
-- инструменты должны быть совместимы с другими инструментами по входам и выходам. Данные инжиниринга должны быть в подходящей форме для учета. К данным люди должны иметь доступ.
-- нужно предусмотреть тренинг по методу или инструменту в раскладах времени: причем не только начальный, но и последующий, если работники некоторое время не пользовались инструментом.
-- нужно предусмотреть администрирование обеспечивающих систем и инструментов.

Самое интересное, конечно -- это описание технических процессов: логический дизайн и его продукты, физический дизайн, способы верификации (осмотр-inspection, например осмотр рисунков; анализ путем моделирования, симулирования или прототипа в виртуальной реальности; демонстрация на физической модели или макете; похожесть на ранние верификации; собственно работа; тестирование) и валидации (приведена китайская классификация по сравнению с валидацией -- ибо валидация много более субъективна, и не метод играет главную роль, а договорка о том, что проверять).

Очень интересно замечание о том, что для прохождения desicion gates должны готовиться специальные work products, чтобы обеспечить информацию для принятия решения о переходе на следующую стадию. Здравый смысл, но такие замечания удобно использовать, чтобы здравый смысл попал в смету и график.

И так далее до самого конца документа: последовательный, итерационный и эволюционный способ прохождения стадий жизненного цикла, Vee-модель, организационный vs системный vs инженерный взгляд на стадии жизненного цикла, technical reviews, configuration audits, tiers of standards (тоже интересная концепция: как использовать множество стандартов для одной и той же деятельности -- приложение A, Relationship between ISO/IEC 15288 and other more detailed standards ), учет в дизайне спецфакторов типа usability или dependability (приложение B, References for design related special factors), замечания к описаниям процессов оригинального стандарта (огромнейший раздел).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 9 comments