А вот за счет чего (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), замечания к описаниям процессов оригинального стандарта (огромнейший раздел).
