Зиндер Евгений Захарович Методический руководитель НААП e@zinder.ru 1 XX VII конференция «Инжиниринг предприятий и управление знаниями» ( ИПУЗ-2024 ) Москва, РЭУ им. Плеханова 28-29 ноября 2024 г
Идеологии, бывают крайне важны, например, идеология безопасности в ядерной энергетике ( Б.Г. Гордон. Идеология безопасности. // Труды НТЦ ЯРБ. Москва, 236 стр., 2006. ) Идеологии многообразны. М огут приносить и пользу, и вред созданию полезных заказчику ПС, например : « Если идеологии децентрализации смогут избавиться от своей часто религиозной связи с неэффективными блокчейнами, с шумихой вокруг Web3 и со схемами крипто-пирамиды, мы, возможно, увидим, что они вернутся в [ наш ] общий разговор о предприятиях. » ( Jason English, Don’t break the code: When ideology bends technology. // Cortex Newsletter, August 23, 2022. ) - 2 -
Рассмотреть варианты настоящего и будущего идеологии ИПС Выделить факторы, определяющие идеологию ИПС, в том числе, сформировавшие идеологию ИПС ~~ к 2010 году, Охарактеризовать её турбулентное настоящее и варианты будущих идеологий Обратить внимание но то, что преподаватели университетов находятся «на передовой» в формировании идеологии для « Software engineering » - 3 - ~~2010 ~1 995 ~~20 3 0 ~20 3 0 ?! ~~20 3 0
Обобщённое рабочее определение: « Идеология – это совокупность определенных ценностей, идей и принципов, применяемых в некотором сообществе или в области деятельности » Переходя к Software Engineering надо помнить, что по принятым определениям инжиниринг – это строгий упорядоченный подход к разработке, эксплуатации и сопровождению [ объектов ], опирающийся на измерения Примеры разных направлений анализа и применения идеологий: Варианты влияния профессиональных идеологий на работу команд программистов-разработчиков Влияние идеологий на ощущения и легенды потребителей технологий - 4 -
Программы – неосязаемые абстрактные объекты высокой сложности, которые никогда не бывают отлажены на 100 % и которые так легко изменять… Для работы с ПС особенно важно, чтобы работа велась командой, членами которой приняты общие основные профессиональные идеи, ценности и принципы работы – её ИДЕОЛОГИЯ Отношения «личность – компания» и СОВМЕСТИМОСТЬ идеологий: ИТ-компании (разработчику ПС) важно оценивать совместимость идеологии кандидата с идеологией самой этой компании Специалисту, выбирающему место работы, полезно понимать идеологию компании – разработчика ПС и примерять её к себе - 5 - Про текучку кадров разработчиков из-за несовместимости идеологий: « уходят они из-за [ того, что ] … нет матчинга с ценностями компании, не ужились в команде и т. д. … ». (из обзора Russia DevOps Report 2023, https://devopsreport.rbc.ru/article 3.html?utm_source=rbc&utm_medium=main&utm_campaign=t1sphr24sp-a3-sniraulka-m&from=2
- 6 - ПС, как продукты инжиниринга по созданию новых ПС-платформ и приложений. В т.ч. – сервисы как компоненты нового приложения или новой платформы для работы конечного пользователя или для платформы нижнего уровня ПС имеют общесистемный, инструментальный или прикладной характер Более того, часть ПС может быть платформами для создания других платформ*). Инжиниринг платформ и приложений разных типов может порождать разные в деталях идеологии инжиниринга Например, нотация BPMN и инструмент моделирования для неё будут платформой и приложением для работы аналитика по описанию б.-процесса. А подготовленное описание с «движком»-интерпретатором для него будут платформой для работы конечного пользователя в ходе выполнения им этого б.-процесса. ______________ *) далее «платформа» используется подобно «популярным» публикациям по теме ЦТ ПРИМЕЧАНИЕ. Особый вопрос: сложные структуры ПС могут в одном проекте порождать разные идеологии разных коллективных и единоличных субъектов.
Профессиональная идеология компании XXX в области инжиниринга ПС Профессиональная идеология сотрудника YYY компании XXX в области ПС Общая профессиональная идеология в области инжиниринга ПС Вчера Сегодня 1.2. О масштабах, связях и основаниях общей и частных идеологий ИПС
Примеры из области организации и обработки данных: р еляционная модель данных ( и связь с ЯОД, ЯМД), Э. Кодд модель «сущность-связь» и ER- диаграмма для представления онтологий в ИТ, П. Чен нормализация отношений в реляционной БД (Э. Кодд, К. Дейт, и др.) а также многофазная фиксация транзакций, многоверсионное упр -е параллельностью в C УБД, сетевая модель данных ( «программист как навигатор» ), ANSI-SPARC, у ниверсальные СУБД (например, реляционные) Другие примеры см. в тексте доклада, в т.ч.: в системах программирования, в практике создания систем : метод описания формальной семантики ЯП ( IBM corp. - VDL, VDM), иерархия ЯП и их типы; стековые модели и протоколы взаимодействия открытых систем (концепция моделей OSI и OSE, уровни протоколов TCP/IP ); в системах (платформах) программирования и отладки программ для разных ЯП ( например, Borland C++) и типов моделей; «концептуальное программирование» Э. Тыугу, включающее БЗ о решаемых задачах; методы и практика длительного сопровождения ПС с их модернизацией ( R 2- R3 -…; OS/VM- /ESA-…) также в областях сетевых ПС и систем, в аппаратных ИТ, … - 8 -
Идея – лозунг: Ценности и принципы: - 9 - ~1 995 «Мы можем сделать любую программную систему!» ?!
Ценности: обоснованные методы дизайна ПС и реализации ИПС, обеспечивающие прочный научный фундамент сложных ПС ( то есть, достижения ИПС ) ; практическое применение этих методов; способность реализации ПС практически любой сложности, а также в составе развивающихся систем любой сложности; возможности типизации и длительного сопровождения ПС, включая системные, прикладные и инструментальные ПС. Принципы: систематически накапливать измеряемый практический опыт применения формализованных методов разработки; развивать применение модульной (компонентной) архитектуры и стандартов открытой архитектуры; накапливать и стандартизовать измеряемую практику длительного сопровождения развивающихся ПС. - 10 - (списки не претендуют на полноту, не жёстко связаны с хронологией)
Низкая и неясная польза от ПС, т.е. низкая экономическая и иная эффективность систем, создаваемых на основе ПС Недостаточное – плохое или почти нулевое взаимопонимание сторон: заказчик / пользователь vs разработчик («Диполь Тыугу ») Большой шлейф ошибок («остаточные дефекты») в ПС, часть – результат несоответствия нуждам, часть выявляется в ходе длительной эксплуатации Требования к АС и ПС не отражают нужды и потребности потребителя / пользователя – с начала проекта или в момент сдачи перекос в сторону технических требований к ПС ( и ПТК, АС ) Плохое соблюдение сроков выполнения и объёма содержания проектов ПС Недоверие к ПС и АС ( «Э. Деминг: «Данные находятся в компьютере»… Там они и остаются! … » ) Стандарты процессов SwE /SE превратились в «трясину», которая вносит много путаницы при попытках их использования - 11 -
Развитие стандарта ANSI/IEEE Std 830 - IEEE Guide to Software Requirements Specifications (доп. рекомендации, методы, …) Разработка моделей и методик оценки эффективности ПС и АС, примеры: – «Решётка Макфарлана » для предприятий, – модель зрелости инвестиций в ИТ для организаций ( SIO Counsil ), – модели типа PRM – Performance Reference Model (FEAF), – ММЭФ – Метамодель Эффективности (ФОСТАС), – попытки применения общих методов оценки экономической и технико-экономической эффективности для АС ( ГОСТ 24.702-85 ; метод. рекомендации по оценке эффективности инвестиционных проектов, 21.06.1999 г. № ВК477 Минэк РФ) «1.6. Целесообразные варианты построения АСУ выбирают путем балансирования показателей приращения эффективности Э, получаемой за счет создания или совершенствования АСУ, и затрат Q. Математически эту задачу формируют в виде: max Э при Q = const или в виде обратной задачи: min Q при Э = const. В тех случаях, когда приращение эффекта представлено в денежном выражении, определяют экономическую эффективность АСУ.» (ГОСТ 24.702-85, изд-во Стандартинформ, 2009 г. – переиздание) Во многих методиках предусматривалась также возможность управления портфелем проектов. - 12 -
Формирование системы управления требованиями должно ( бы ) включать принципы и правила: согласовывать схему работ по определению потребностей [ ЗЛ ] и требований к [ объемлющей ] системе и к ПС выявлять реальные персонифицированные нужды ЗЛ и их конфликты (в т.ч. объективные условия среды ПС) связывать отдельные нужды, требования и последующие решения причинными и иными (в т.ч. конфликтными) связями отражать конфликты интересов разных категорий ЗЛ: нужды потребителя, интересы бизнеса, требования работников, и др. определять приоритеты и компромиссы удовлетворения разных потребностей и интересов (в т.ч. законы и др. ограничения среды) выполнять регулярный пересмотр и прослеживание всех решений к принятым интересам и нуждам разных ЗЛ определять риски выбора решений и способы управления рисками (в т.ч. – процесс прослеживания к потребностям) - 13 - Этот аспект ИПС и сейчас далёк от исправления: «… основной проблемой стал дефицит квалифицированных специалистов (42%). Вторая по важности проблема — отсутствие системного подхода к сбору требований (34%) » - см. отчёт DevOps-2023
Его сотрудники в 1997 г. рассказали, что в ~~ 1990 году Р. Перо получил от них на срочное утверждение документ «Техническое и коммерческое предложение» для тендера у важного возможного Заказчика. Но Р. Перо исчез на две недели. - 14 - Р. Перо. Основатель компании EDS, сооснователь с Джеймсом Чампи и руководитель известной, весьма успешной и уважаемой компании « Perot Systems » А также стартовый инвестор в компанию Стива Джобса, и др. Независимый кандидат в президенты США на выборах 1992 и 1996 годов. На эти две недели Р. Перо нанялся и официально проработал в одном из низовых отделений организации Заказчика. На основании полученного знания о нуждах Заказчика ТКП было коренным образом переделано, компания « Perot Systems » выиграла конкурс, успешно выполнила заказ, и т.д. (А также подтвердила вхождение в число наиболее уважаемых компаний по предоставлению подобных услуг.)
- 15 - « Качество по-прежнему является главной проблемой в SW- индустрии. Разработка программных средств обходится слишком дорого, результаты часто получаются слишком поздно, а поставляемые продукты слишком некачественны. Общее мнение состоит в том, что в среднем индустрия разработки программного обеспечения не достигает уровня инженерного профессионализма, ожидаемого в других инженерных дисциплинах. Можно выявить значительные недостатки, особенно в использовании стандартизированной терминологии и применения общеотраслевых стандартов» (Integration via Standards - Blessing or Curse? From Gerhard Chroust, ~ 1997) ______ Ясен комплексный характер проблемы, начиная с качества требований к ПС Этот аспект ИПС и сейчас далёк от исправления: «… основной проблемой стал дефицит квалифицированных специалистов (42%). Вторая по важности проблема — отсутствие системного подхода к сбору требований (34%) » (из обзора Russia DevOps Report 2023 с участием ВШЭ. https://devopsreport.rbc.ru/article-3.html?utm_source=rbc&utm_medium=main&utm_campaign=t1sphr24sp-a3-sniraulka-m&from=2
1984 - ANSI/IEEE Std 830- IEEE Guide to Software Requirements Specifications - 16 - 19 97 - Chroust, Gerhard - цитата о недостаточном качестве ПС и ИПС 2014 - Reengineering SRS – « Выявление, анализ и написание правильных требований - самые сложные части SRE » 2012 - П роблемы и модели – « Эффективные решения пока не найдены » « Наиболее часто используемые методы выявления требований включают в себя проведение встреч, создание прототипов » Около половины недостатков ПС порождены ситуативными проблемами в составлении требований 2021 - « Огромный недостаток разработки ПС по Agile » 2024 - « Риск-менеджмент – выявлять, классифицировать, управлять» «Пренебрежение дизайном UI/UX при разработке ПС, чрезмерное внимание техническим аспектам и функциональности https://www.researchgate.net/publication/266011849_A_review_of_requirements_engineering_processes_problems_and_models https://www.researchgate.net/publication/287489669_Reengineering_Requirements_Specification_Based_on_IEEE_830_Standard_and_Traceability https://www.inc.com/adam-fridman/the-massive-downside-of-agile-software-development.html https://simpleone.ru/blog/6-riskov-pri-razrabotke-po-kotorye-vsegda-aktualny
АП – результат понимания ограниченности предыдущих методик планирования ИС (пример – IBM BSP ( 1981 ), Дж. Захман и др. ) один из ответов на потребность в качественных требованиях к ПС, АС, … (обоснованных, учитывающих нужды бизнеса, и т.д.) С помощью и средствами АП возможен переход на новый уровень комплексного определения целостных систем требований не только к предприятию в целом, но и к частям предприятий, включая ПС Требования уровня АП – обычно высокоуровневые, их детализация может по-разному проводиться для каждой компоненты предприятия и каждой архитектурной области (детализация – «вотчина» отдельных проектов, но с прослеживанием к АП) Основа АП быстро формировалась с конца 1980-х и до 2000 (первый международный стандарт) АП продолжает развиваться, сохраняя ценности и осваивая новые, но Часто АП приписывают чуждые ей свойства (например, каскадный стиль проектирования, необходимость огромных детальных диаграмм, сложность таблиц или пирамид, которыми иллюстрируют метамодели АП, обязательность анализа и использования всех возможных аспектов архитектуры, и др.) пытаясь отменить или «облегчить» её базовые ценности (ссылаясь на динамику ЦТ и прочее) В правовом поле в РФ часто АП соотносят именно с ФЗ об архитектурной деятельности в РФ Усилиями международных сообществ ( ACM, IEEE, AIS) сформированы учебные планы, в которых для многих ИТ-специализаций курс или хотя бы компетенции по АП являются обязательными - 17 -
АП по отношению к ИТ в явном виде нацелена на реализацию принципа «Поставить лошадь впереди телеги» Он означает, что требования к ПС предприятия определяются на основе деловых потребностей предприятия внутренних потребностей / решений ЗЛ принятых ограничений среды Он несёт значительные ценности и даёт множество определённых выгод, но требует компетенций, дисциплины и дополнительных затрат (время, специалисты) как и в строительной архитектуре, он не всегда «приживается», часто воспринимается как «недружественное поглощение» ( см. в стандартах Open Group ) – отъём ресурсов и полномочий у руководителей программ и высших управленцев: “Enterprise Architecture tends to be viewed as a hostile takeover by program managers and executives who have previously had a lot of independence in developing solutions for their own requirements ” ( Scott Bernard. An Introduction to Enterprise Architecture. AuthorHouse, 2012. ) - 18 - C хема фреймвока NIST (У. Б. Ригдон, McDonnell Douglas ), 19 8 9 Фреймвок, принятый за основу в группе NIST Дж. Захмана Идея: определять нужды Заказчика в форме целостного «связного» и полного описания, на этой основе – согласованные с ним требования к ПС
Главн ые ценности архитектурного подхода, которые нужно чувствовать Руководителям (Заказчика и Разработчика) – и обеспечивать: взгляд на Предприятие в целом ("Big picture "), общая картина в её динамике 2) комплексность подхода (цели, внешняя среда, функции, особенности рабочих процессов, эргономика, законы и др. регулирование, учет как человеческого фактора, так и "машин" в широком смысле, экономика реализации, возможность эксплуатации и развития, …) _ в противовес сооружению «времянок» – взгляд в будущее, концентрация на более долговременных целях (без игнорирования «горящих» потребностей)
4) обоснование реализуемости стратегии и трансформаций с исключением решений технических вопросов «раньше времени» и «закапываний в детали» 5) управление сложностью Архитектуры, сочетающее решение локальных и комплексных задач 6) контроль за тем, чтобы техническое конструирование и модернизация не нарушали стратегии и архитектурного замысла 7) качество архитектурных решений на основе использования специальных профессиональных методов работы с комплексом разнохарактерных аспектов 8) понятность и убедительность как для высшего менеджмента, так и для людей разных специальностей
9) возможности для инженерного, экономического и социального управления изменениями Предприятия 10) взгляд со стороны - его использование для объективного формирования реализуемых и перспективных решений формирование части среды обитания человека – его рабочей среды *) (как и для классической архитектуры) поиск «стиля организации пространства» как формирование стиля организации рабочей среды и среды экосистемы именно этого предприятия и возможностей его функционирования. _______________ *) дополнительный фактор: Внимание к экологии растёт, это усиливает внимание к среде предприятия в широком смысле, т.е. включая стандарты его экологии.
Ценности: Такие технические требования, модели функционала и данных ПС, которые явным образом состыкованы с параметрами потребностей, функционирования, зрелости и эффективности предприятия (которые «поставляет» Архитектура предприятия) - 22 - ~~2010 «Мы проектируем и реализуем эффективные ПС для реальных нужд бизнеса» ~1 995 «Мы можем сделать любую программную систему!» ?! Идея: т.е. делаем то, что нужно бизнесу, с достаточными экономическими, функциональными и иными показателями качества
Методы измерения вклада ПС (и других ИТ-инвестиций) в продуктивное функционирование и стратегию предприятия. Измеримые параметры ПС в контексте предприятия – например, техническая производительность, надёжность, безопасность, эргономика для конечного пользователя, TCO и детализированная стоимость эксплуатации ПС (например, «цена за транзакцию обработки заявки») Умение и практика работы системных аналитиков и разработчиков ПС в составе комплексных команд, с людьми от менеджмента и бизнес-дисциплин (экономика, маркетинг, технологи основного производства, и др.), а также с пользователями Наличие м ножества методов практического дизайна и реализации инжиниринга ПС, гарантировано обеспечивающих прочный научно обоснованный фундамент сложных ПС (и некоторых смежных компонент) – в развитие фундамента, указанного для начального витка - 23 -
Проектирование и реализация ПС для задач и предприятий практически любой сложности (в т.ч. виртуальных, сетевых, и т.д.) Типизация прикладных ПС для широкого спектра предприятий-заказчиков, включая возможности адаптации ПС – в т.ч. с применением новых высокоуровневых языков (платформ) – и в развитие фундамента, указанного для начала витка Практика длительного сопровождения ПС, поддерживающего расширения состава ПС и модернизацию компонент – как общесистемных (ОС, СУБД, …), так и прикладных ПС Свойства открытой архитектуры, в т.ч. переносимость, расширяемость, масштабируемость, интероперабельность в нужных аспектах (бизнеса, семантики, синтаксиса,…) - 24 - (список не претендует на исчерпывающую полноту )
Обилие реальных и лишь заявляемых новшеств и возможностей, рост турбулентности и изменчивости ( фреймвоки «могут мешать» ) «Новые ИТ» – « Цифровые» + призывы «Покупай быстрее!» объявления новой техно-революции и попытки её «свершения» лозунги ЦТ и новых архитектур предприятий (любых?) и ПС с большим % неудач платформы – для чего / кого? роль «самообслуживания» слабо видна интересные многомодельные СУБД, «нишевые» модели данных и высокие риски «лоскутной автоматизации» Влияния на состав будущей идеологии инжиниринга ПС сосуществование «цифрового» назначения ПС, ЦТ и ценностей ИПС 1-го витка, компонентные модели для лучшей интеграции ПС и АС («композитные» онтологии), новые удобства для пользователя (развитие NLP), большая поддержка бизнеса (интеллектуальные агенты) развитие облегчённых форм гибкого управления разработкой (малые команды и их кооперации, разумное MVA, создание платформ разных типов и «программирование» на них ) - 25 - ( о ЦТ см. в eLIBRARY в сборнике https://www.elibrary.ru/download/elibrary_50214217_39157388.pdf )
~~2010 «Мы проектируем и реализуем эффективные ПС для реальных нужд бизнеса » - 26 - ~1 995 «Мы можем сделать любую программную систему!» ~~ «Чтобы вам не отстать от конкурентов, мы найдём и внедрим для вашей ЦТ новейшие ПС, находящиеся на пике популярности» ~~20 3 0 ?! ~~ «Мы найдём или сделаем ПС, актуальные именно и только для реальных нужд вашего предприятия»
Избегать применений идеологически «крайних» путей для инжиниринга ПС – избегать применять только их, тем более – лишь одного из них, уметь выбирать и формировать подходящий путь (см. далее схему раздвоения пути развития Идеологии ИПС) Для разных частей предприятия могут требоваться разные стили инжиниринга. Идеология должна предусматривать гибкость применения разных стилей, в том числе – гибридных вариантов Стремиться к тому, чтобы Minimum viable architecture (MVA) не превращалось в Just Enough (в варианте «и так сойдёт»), не генерировала новой, «цифровой» лоскутной автоматизации проникнуться проблемами и нуждами пользователя, использовать применимые базовые подходы АП Проверить использование метафоры «дерево с пышной кроной» для выбора архитектуры и компонент ПС и данных Для конкретного проекта выбрать полезное для него – из DP BoK, Open Agile Architecture, а также из других методик, моделей, стандартов (старых и новых) - 27 -
Избегать идеологий типа « История начинается с нас! », формировать рациональный путь, использующий подходящее и из зрелого нового, и из накопленного ранее Выбор рационального путь включает ценности выделения эффективных проектов, создания ПС достаточно высокого качества, использования на конкретном участке предприятия подходящий для него путь развития, адаптации готовых методов к предприятию и проекту Идеи, ценности и методы первого витка не только актуальны и работоспособны, но и необходимы – при условии умения выполнять их адаптации, когда они нужны В будущую идеологию целесообразно включать ценность владения хорошо оснащённой МАСТЕРСКОЙ методов, схем и других инструментов. Метафора Мастерской означает знание, владение и умение совместно применять достаточно богатый арсенал формализованных методов, концептуальных схем, стандартов, ЯП и иных программных средств-инструментов. Повторно – о радикальных перекосах: « Если децентрализованные идеологии смогут избавиться от своей часто религиозной связи … мы, возможно, увидим, что они снова войдут в общий разговор о предприятиях. » ( Jason English, Don’t break the code: When ideology bends technology. ) - 28 -
управление потребностями и требованиями, качество ПС в их контексте полноценная модель конечного пользователя, балансирование интересов ЗЛ прозрачное и непрерывное интегрированное управление эффективностью (ПС и предприятия) и стратегией предприятия ПС-средства, поддерживающие управление эффективностью, управление рисками в новых сетевых средах, самообеспечение пользователя ИБ человека на всех уровнях систем, исключение манипулирования, движение к информационной симметрии восполнение дефицитов знаний для реального создания качественных ПС – в т.ч. за счёт опережающих учебных программ по направлению SwE и смежным - 29 -
Евгений Захарович Зиндер e@zinder.ru +7(965)415-42-25 - 30 - Большой материал о цифровой трансформации, а также о времени предприятия, см. в eLIBRARY в сборнике Е.З. Зиндера https://www.elibrary.ru/download/elibrary_50214217_39157388.pdf
- 31 -
- 32 -
Software : программное обеспечение, ПО ( но не по ГОСТ 34); здесь – это ПС ; компьютерные программы, процедуры и, возможно, связанная с ними документация и данные, (относящиеся к работе компьютерной системы) (IEEE 828-2012 Standard for Configuration Management ) используется также – Software product, Software package, Program pack, Application package Software engineering: применение строгого, систематизированного, упорядоченного, измеримого подхода к разработке, эксплуатации и сопровождению ПС (на основе ISO/IEC/IEEE 24765:2017 – Vocabulary ) Примечание. Иногда включает и исследование этого подхода. Также: Software engineering: a branch of computer science that deals with the design, implementation, and maintenance of complex computer programs ( www.merriam-webster.com ) Выделяется (в узком смысле) среда инжиниринга программ ( Software engineering environment ) – окружение, которое предоставляют для выполнения инжиниринга сервисы контекста автоматизированной системы и конкретные программные сервисы (например, управление проектами и процессами) – платформы, системное ПО, утилиты и установленные CASE- инструменты - 33 -
Systems Engineering – это инжиниринг систем Также сравните с аннотацией к предшественнику – стандарту EIA 632: “ Overview of the EIA 632 standard: processes for engineering a system Abstract: The EIA 632 standard has been developed that describes the "processes for engineering a system". This standard evolved from EIA/IS 632-the interim standard that described a systems engineering process. This paper will describe the structure of the standard, elements of the process, and key concepts such as stakeholder requirements, enabling products, building blocks, and development layers. ” Согласно стандарту-словарю ( IEEE и др.) engineering – это строгий, измеримый ПОДХОД к работе - 34 -
В инженерных профессиональных областях идеология существует на всех уровнях субъектности и зависит от специфики предмета деятельности профессионалов, влияния социально-экономической идеологии (рынка, моды …) текущей государственной политики. Из идеологии гражданской авиации – по материалам Аэрофлота, IATA : Ценности: приоритет надёжности авиаперевозок ; достаточный уровень комфорта пассажиров ; обеспечение необходимой независимости и самостоятельности в создании средств перевозки и подготовки персонала. Принципы обслуживания пассажиров: в каждом полёте обеспечивать требуемый и более высокий уровень безопасности ; измерять степень удовлетворённости пассажиров и планировать мероприятия по его повышению; в каждом случае – … доставка до аэропорта назначения при ЧС ( https://rg.ru/2019/10/23/iata-priznala-zaslugi-aeroflota-v-razvitii-globalnoj-grazhdanskoj-aviacii.html ) ВАЖНО: переходя к Software Engineering помнить, что инжиниринг – это строгий инженерный подход, опирающийся на измерения - 35 -
Enterprise Что мы сейчас должны делать? Ведь компьютер показал, что мы уже приземлились, и мы не можем сделать это еще раз?!
- 37 - Диполь Тыугу Диполь: уточнение в обсуждении с Иванниковым (Зиндер Е.З. Диполь Тыугу, или Как преодолеть искажения ИС. // Директор информационной службы. 1999, № 06 ) А.П. Ершов. Академик, СО РАН Э.Х. Тыугу. Докторант ВЦ СО РАН, ак. ЭАН В.П. Иванников. Академик, РАН
Варианты решения для разработчиков-одиночек (и очень малых команд). Заказчик и разработчик – с одной стороны ПрО Эффект «стремительного поумнения заказчика» не устраняется Пошаговая работа Работа с прототипом Вариант – дополнительно выбрать упростить и адаптировать вариант подхода Agile ( определите отличия) См. также рекомендации DP BoK для действий разного масштаба ( стандарт Open Group) - 38 - ( Кисин М. Диполь Тыугу – взгляд кустаря-одиночки // Директор информаци - онной службы. 1999, № 24) Информационное пространство заказчика Видимая часть инфопространства постоянно увеличивается за счет совместной работы Заказчик Исполнитель
- 39 - Варианты решения для средних и больших проектов Подбор постановщика / бизнес-технолога / бизнес-аналитика а также системного аналитика / архитектора ИТ-решения Его тесные контакты с Заказчиком и Разработчиком. Выбор платформы разработки – позже! (Зиндер Е.З. Диполь Тыугу, или Как преодолеть искажения ИС.// Директор информационной службы. 1999, № 06 ) Постановщик-технолог Диполь++ См. также ISO/IEC 12207, рекомендации DP BoK 2019 ( стандарт Open Group) для работы индивида, малой команды, команды команд, для Предприятия в целом, «гибриды» с правилами Scrum, другие гибридные подходы
Аспект: Т. Зрения (перспектива) : Ячейка: Стратегии:
- 42 - 3.2. В АП в явном виде предлагается формировать ПС на основе знания бизнес-архитектуры объекта В группе Дж. Захмана обсуждался аспект планирования развития ИС. В группе было предложено базировать его на фундаменте комплексной схемы ранней таблицы Захмана. В группе Б. Ригдона фиксировали, что дискуссии в основном касались технологических ИТ-проблем, и это стало проблемой. Было решено, что – нужно расширять старое представление и описать такую архитектуру предприятия, которая включает в себя акцент на бизнес-требованиях и требованиях к бизнес-информации. – эти более высокие уровни влияют на архитектуру данных и технологий и принимаемые решения. C хема фреймвока NIST (У. Б. Ригдон, McDonnell Douglas ), 19 8 9
- 43 - разрывы vs Software Engineering Документ « Computing Curricula 2005 The Overview Report » Нулевое пересечение SE с нуждами заказчика – даже при заботах о будущем Это консервативная и противоречивая разработка, не учитывающая содержание NIST-1989, стандартов SSE (ISO/IEC 12207), рост требований к качеству ПС, и др.
- 44 - Например, по работе (Integration via Standards - Blessing or Curse? From Gerhard Chroust. https://www.researchgate.net/figure/The-standards-quagmire_fig1_228751578 )
45 Выводы исследователей: Около половины Т. не доживают до плато продуктивности БольшАя часть Т. достигает зрелости за > 10 лет развития (иногда за 20 лет), новизна Т относительна и также условна автономные беспилотники 4 уровня (и др.) еще не достигли устойчивой продуктивности для реального массового промышленного применения, блокчейн и дополненная реальность используются в малых объемах и на упрощённых задачах Альтернативы для предприятий: Либо всерьёз вкладываться в доработки Т. вместе с разработчиком Либо ждать и проверять зрелость Т. на «Плато продуктивности» кривой хайпа ( на Gartner Hype Cycle или на своем аналоге ) Предприятию стоит определять «момент зрелости» Т. индивидуально для себя Для промышленных предприятий этот момент должен быть близок к «Плато продуктивности» или находится на нём (см. в eLIBRARY доступен сборник https://www.elibrary.ru/download/elibrary_50214217_39157388.pdf )
- 46 -
Особые специфические свойства программ: неосязаемый (невидимый) предмет, не воспринимаемый органами чувств людей абстрактный предмет (даже при наличии нескольких представлений), что позволяет иметь разные трактовки свойств программы разными людьми возможность лёгкого внесения изменений («в любой момент»), может восприниматься как свойство теоретически бесконечной изменяемости программы практически произвольная, в т.ч. очень высокая алгоритмическая сложность практически произвольный размер (от одной машинной команды до мыслимой практической бесконечности) программ как объектов понимание требует восприятия динамики программы при её исполнении Примеры следствий, порождающих низкое качество ПС: сложность оценки затрат на разработку (модернизацию) программы высокая вероятность ошибок – скрытых, не выявленных при разработке относительная лёгкость злонамеренного внесения в программу изменений относительная лёгкость входа в инженерную профессию разработчиков недостаточной квалификации особые субкультуры программистов, стимулируемые ощущением творческого владения бесконечными возможностями ( «Порождать любые миры из нулей и единиц!» ) сложность защиты прав на программу как на объект интеллектуальной собственности - 47 -
Идеология инжиниринга прикладных ПС, (включая инструменты конечного пользователя и «бизнес - технолога», «бизнес-аналитика»), на этом этапе охватывает преимущественно изготовление программ и их комплексов, но не напрямую интересы конечных пользователей, для которых они формально делаются Идея «Мы можем всё» столкнулась с ростом сложности и изменчивости программных систем и комплексных производственных систем (бизнес-систем) – и тут же начала всё более ограничиваться - 48 -
- 49 - 2) Определение частоты (индивидуально) уточнений концепции. Периодическая совместная работа с макетом и прототипом. 3) Тэйлоринг формы ЖЦ по ISO/IEC 12207 или аналогично. 4) Регулярные (период индивидуален) совместные испытания на стенде, затем - в реальной среде, возможность совместного применения ISO/IEC 12207, ГОСТ 34 и фирменных методик (гибридные варианты). 5) Вариант – версии методологии Agile ( «найдите сходства и отличия»). В варианте Scrum роли Постановщика и Аналитика в модели Диполь++ могут заменяться на роли Product Owner, Scrum Master. 6) В реальных сложных проектах, например, требующих нормативного документирования и т.п., практика позволяет использовать гибридные методы, при этом выбираются нужные действия каждой итерации. Например, в зависимости от сложности этапа реализации ПС (в т.ч. может быть продуктивным интеграция функций роли Scrum Master и системной поддержки непрерывной интеграции – « Scrum SuperMacter » ). 7) Полезно начинать согласование проекта с планами / стратегией предприятия. Не пропускать моменты для сверки результатов и планов с проекта со стратегическим планом и ИТ-стратегией предприятия. 8) См. также рекомендации DP BoK ( стандарт Open Group) для работы индивида, малой команды, команды команд, для Предприятия в целом
- 50 -
- 51 -
- 52 -
- 53 -
- 54 -
