Закрывая табы
Откуда берутся открытые табы в браузере?! Главное, их очень жалко закрывать -- с табов долой, из мозга вон.
* * *
Про нормы, декомпозицию, айтишников и инженеров: фраза из одного исследования (http://www.metadataopenforum.org/download.php?fad3d5bd66131c5b085c42f7806dabe8) "Through the analysis on a specific job called “Inspection and maintenance scheduling job”, it is perceived that engineering knowledge can be decomposed into engineering rules, which can be expressed by sentences with several tens of words, without losing the meanings for an engineer but when it is decomposed into smaller pieces, they become meaningless for an engineer".
Там есть и много других восхитительных моментов -- ибо презентация про управление знаниями на японских гидростанциях. Нужно еще заметить, что эти гидростанции безлюдны. Нет людей -- есть знания. Если бы не было знаний, то там нужны были бы люди...
* * *
Очень хочется как-то запоминать отдельные удачные находки на разных слайдах. Например, традиционная присказка про разную цену ошибок, сделанных на разных этапах (из отличной свеженькой майской презентации Ronald Ross по business rules -- http://businessrules.editme.com/files/meeting12052009/About%20RuleSpeak%20v3.pdf):
За что я люблю эти "организационные нормы"? За то, что они по принципу выражаются безатрибутно. У меня всегда было впечатление, что атрибутная запись удобна для технарей (память в фон-неймановских компьютерах -- это же огромные пастбища атрибутов!), но непонятна простым людям. У людей в мозгах атрибутов нет, там другое. Люди много лучше ориентируются с фактами. "Business people don’t set variables and they don’t call functions" (Don Baisley, Microsoft Architect of Rules Modeler while at Unisys).
Очень хорошо пишет Ross про факты: это глаголы. Обратите внимание на язык, не "отношения" (relations), не "явления" (occurances), а глаголы. Что не мешает ему потом над (или под?) всеми записанными выражениями наводить всю необходимую формальную логику с деонтикой и алетикой.
* * *
В ISO 15288:2008 "форма жизненного цикла" встречается однократно:
Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Using stages concurrently and in different orders can lead to life cycle forms with distinctly different characteristics.
Организации по-разному задействуют стадии для проведения различных стратегий ведения дел и снижения рисков. Параллельное или в различном порядке исполнение стадий приводит к весьма различным формам жизненного цикла.
Additional detail regarding life cycle concepts and stages can be found in ISO/IEC TR 19760, A Guide for the application of ISO/IEC 15288 System life cycle processes.
Дополнительные подробности, касающиеся понятий о жизненном цикле и его стадиях, могут быть найдены в: ISO/IEC TR 19760, A Guide for the application of ISO/IEC 15288 System life cycle processes.
NOTE A future Technical Report (ISO/IEC TR 24748, Guide for life cycle management) will also provide further elaboration.
ПРИМЕЧАНИЕ: Готовящийся технический отчет (ISO/IEC TR 24748, Guide for life cycle management) также будет содержать дальнейшую их разработку.
В ISO 19760 такого понятия вообще нет. В ISO 24748 появляется снова:
Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Using stages concurrently and, in a few cases, even in different orders, can lead to life cycle forms with distinctly different characteristics. Sequential, incremental or evolutionary life cycle forms are frequently used. Alternatively, a suitable hybrid of these can be developed. The selection and development of such life cycle forms by an organization depend on several factors, including the business context, the nature and complexity of the system, the stability of requirements, the technology opportunities, the need for different system capabilities at different times and the availability of budget and resources.
Организации применяют стадии для реализации различных организационных стратегий и стратегий снижения рисков. Одновременное или, в редких случаях, в другом порядке применение стадий приводит к формам жизненного цикла с существенно различающимися характеристиками. Часто применяются последовательная, инкрементальная и эволюционная формы жизненного цикла. Кроме того, может быть выработано подходящее сочетание данных форм. Выбор и развитие таких форм жизненного цикла организацией зависит от ряда факторов, включая деловой контекст, природу и уровень сложности системы, стабильность требований, технологические перспективы, потребность в различных возможностях системы в различные моменты времени и доступность денежных средств и иных ресурсов.
И всё, больше термин нигде не встречается.
И именно отсюда мы делаем вывод, что есть "метод управления жизненным циклом" (типа "экстремальное программирование" или "метод пошагового выделения ресурсов"), и этот метод диктует какую-то форму жизненного цикла.
Если речь идет о том, что форма жизненного цикла какая-то уже сложилась, то это вовсе не означает отсутствие такого метода. Какие-то идеи в головах людей, заставляющие их чередовать стадии тем или иным образом, присутствуют. Это и есть их метод -- уж какой есть (если кто в России не знает, что пишет тексты по методу Кирилла без Мефодия, то для него это не проблема. Но это не значит, что метода нет). Другое дело, что не обсуждая метод, и лежащие в его основе идеи, нельзя осмысленно менять форму жизненного цикла.
* * *
А теперь задачка: как графически показать связь форм жизненного цикла различных взаимосвязанных систем? Для простоты возьмем "типовой проект" Design и пару создаваемых по этому проекту систем-в-металле Hardware-1 и Hardware-2 (да, модификация "типового проекта" по итогам полученного опыта его реализации в первой системе подразумевается).
* * *
Про нормы, декомпозицию, айтишников и инженеров: фраза из одного исследования (http://www.metadataopenforum.org/download.php?fad3d5bd66131c5b085c42f7806dabe8) "Through the analysis on a specific job called “Inspection and maintenance scheduling job”, it is perceived that engineering knowledge can be decomposed into engineering rules, which can be expressed by sentences with several tens of words, without losing the meanings for an engineer but when it is decomposed into smaller pieces, they become meaningless for an engineer".
Там есть и много других восхитительных моментов -- ибо презентация про управление знаниями на японских гидростанциях. Нужно еще заметить, что эти гидростанции безлюдны. Нет людей -- есть знания. Если бы не было знаний, то там нужны были бы люди...
* * *
Очень хочется как-то запоминать отдельные удачные находки на разных слайдах. Например, традиционная присказка про разную цену ошибок, сделанных на разных этапах (из отличной свеженькой майской презентации Ronald Ross по business rules -- http://businessrules.editme.com/files/meeting12052009/About%20RuleSpeak%20v3.pdf):
За что я люблю эти "организационные нормы"? За то, что они по принципу выражаются безатрибутно. У меня всегда было впечатление, что атрибутная запись удобна для технарей (память в фон-неймановских компьютерах -- это же огромные пастбища атрибутов!), но непонятна простым людям. У людей в мозгах атрибутов нет, там другое. Люди много лучше ориентируются с фактами. "Business people don’t set variables and they don’t call functions" (Don Baisley, Microsoft Architect of Rules Modeler while at Unisys).
Очень хорошо пишет Ross про факты: это глаголы. Обратите внимание на язык, не "отношения" (relations), не "явления" (occurances), а глаголы. Что не мешает ему потом над (или под?) всеми записанными выражениями наводить всю необходимую формальную логику с деонтикой и алетикой.
* * *
В ISO 15288:2008 "форма жизненного цикла" встречается однократно:
Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Using stages concurrently and in different orders can lead to life cycle forms with distinctly different characteristics.
Организации по-разному задействуют стадии для проведения различных стратегий ведения дел и снижения рисков. Параллельное или в различном порядке исполнение стадий приводит к весьма различным формам жизненного цикла.
Additional detail regarding life cycle concepts and stages can be found in ISO/IEC TR 19760, A Guide for the application of ISO/IEC 15288 System life cycle processes.
Дополнительные подробности, касающиеся понятий о жизненном цикле и его стадиях, могут быть найдены в: ISO/IEC TR 19760, A Guide for the application of ISO/IEC 15288 System life cycle processes.
NOTE A future Technical Report (ISO/IEC TR 24748, Guide for life cycle management) will also provide further elaboration.
ПРИМЕЧАНИЕ: Готовящийся технический отчет (ISO/IEC TR 24748, Guide for life cycle management) также будет содержать дальнейшую их разработку.
В ISO 19760 такого понятия вообще нет. В ISO 24748 появляется снова:
Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Using stages concurrently and, in a few cases, even in different orders, can lead to life cycle forms with distinctly different characteristics. Sequential, incremental or evolutionary life cycle forms are frequently used. Alternatively, a suitable hybrid of these can be developed. The selection and development of such life cycle forms by an organization depend on several factors, including the business context, the nature and complexity of the system, the stability of requirements, the technology opportunities, the need for different system capabilities at different times and the availability of budget and resources.
Организации применяют стадии для реализации различных организационных стратегий и стратегий снижения рисков. Одновременное или, в редких случаях, в другом порядке применение стадий приводит к формам жизненного цикла с существенно различающимися характеристиками. Часто применяются последовательная, инкрементальная и эволюционная формы жизненного цикла. Кроме того, может быть выработано подходящее сочетание данных форм. Выбор и развитие таких форм жизненного цикла организацией зависит от ряда факторов, включая деловой контекст, природу и уровень сложности системы, стабильность требований, технологические перспективы, потребность в различных возможностях системы в различные моменты времени и доступность денежных средств и иных ресурсов.
И всё, больше термин нигде не встречается.
И именно отсюда мы делаем вывод, что есть "метод управления жизненным циклом" (типа "экстремальное программирование" или "метод пошагового выделения ресурсов"), и этот метод диктует какую-то форму жизненного цикла.
Если речь идет о том, что форма жизненного цикла какая-то уже сложилась, то это вовсе не означает отсутствие такого метода. Какие-то идеи в головах людей, заставляющие их чередовать стадии тем или иным образом, присутствуют. Это и есть их метод -- уж какой есть (если кто в России не знает, что пишет тексты по методу Кирилла без Мефодия, то для него это не проблема. Но это не значит, что метода нет). Другое дело, что не обсуждая метод, и лежащие в его основе идеи, нельзя осмысленно менять форму жизненного цикла.
* * *
А теперь задачка: как графически показать связь форм жизненного цикла различных взаимосвязанных систем? Для простоты возьмем "типовой проект" Design и пару создаваемых по этому проекту систем-в-металле Hardware-1 и Hardware-2 (да, модификация "типового проекта" по итогам полученного опыта его реализации в первой системе подразумевается).