Методология 2025

Особо нужно отметить о времени жизненного цикла в его 1.0 понимании:

• Понятие жизненного цикла – всегда полные работы на всём протяжении от замысла до ликвидирования системы (это влияние системного мышления)

• Жизненный цикл проекта – работы только на тех стадиях полного жизненного цикла, которые административно входят в проект, подчинение целям проектного управления.

• Возврат к идее цикла, ибо «жизненный цикл» будет выполняться с разными версиями системы, понятие «жизненный цикл» при этом уходит, понятие «проект» остаётся, но это будет «проект по созданию и развитию системы», ключевое слово тут «развитие», подразумевающее «эволюцию системы как вида».

Всё это – работы создателей, но мышление о создателях не ограничивается понятием жизненного цикла, постепенно от этого понятия отказываются. Хотя ещё кроме понятия жизненного цикла в версии 1.0 будет и понятие жизненного цикла 2.0, и там будет речь об оргролях и методах работы создателей. Но потом понятие «полного жизненного цикла» дало сбой, ибо проект перерос жизненный цикл одной системы и жизненный цикл проекта как часть полного жизненного цикла стало уже совсем неудобно применять. Так, в проект начали включать не только работы создания, но и работы развития системы, то есть прохождения многих «полных жизненных циклов системы» в рамках «ещё более полного жизненного цикла». Поэтому всё чаще и чаще вместо упоминания понятия «жизненный цикл» начали просто упоминать «создание и развитии системы», включая туда в том числе и время эксплуатации/использования и выкидывания самых разных получившихся в ходе развития вариантов уже готовой, но ставшей ненужной (просто необратимая поломка или даже моральное старение) системы. Создание системы понимается теперь как выпуск MVP, а развитие системы – всё, что происходит потом с самыми разными версиями системы с улучшаемой функциональностью.

Часто жизненный цикл системы в методе его описания 1.0 (т.е. в представлениях проектного управления) обозначали просто линией времени с засечками для разграничения его стадий/фаз (упрощённая «колбаска»), при этом он всегда обозначался полный: от работ по замыслу до работ момента прекращения существования. В этом указании полного жизненного цикла был смысл системного мышления, удерживать коллективное внимание всех команд всех проектов на всех работах по поводу системы, а не только на работах одной из команд одного проекта. Как всегда, системное внимание разворачивает мышление вовне, от границ одного проекта как работ одного создателя к объемлющему проекту как работе создателей из большого графа создания.

Но на такой линии с засечками для стадий вполне можно было указать и жизненный цикл проекта, который поначалу понимался как часть полного жизненного цикла системы, мышление о проекте как выходящем за пределы одного жизненного цикла ещё не было развито, концепции «непрерывное всё» ещё не было. Например, жизненный цикл проекта мог включать в себя только работы по замыслу и проектированию/design, или только работы по изготовлению/воплощению системы как физического объекта, или только работы по эксплуатации – тут были самые разные варианты, в проектном управлении термин был удобен, а инженеры думали работами и ответственностями оргзвеньев, а не методами работ и мастерством выполнения ролей.

Поскольку проект в классическом project management имеет конкретные даты начала и конца, конкретные ресурсы, то «жизненный цикл проекта» понимается просто как проект из проектного управления, а большие куски жизненного цикла, или даже полный жизненный цикл понимаются уже не как проект, а как программа (иногда даже пишут полностью программа проектов94, иногда программа работ). В проектном управлении программа – это набор проектов, посвящённых какой-то цели, но проекты из этого набора планируются по мере осознания в них потребности, а не сразу в момент старта программы.

Так, в военной системной инженерии киберфизических систем про жизненный цикл какого-то военного самолёта могут говорить как о программе этого самолёта – это ровно вот эта подмена нейтрального для самых разных практик/деятельностей/инженерий (киберфизики, менеджмента, основания предприятий/предпринимательства) понятия жизненного цикла понятием из проектного управления, которое сегодня развилось из просто project management в program and project management (иногда этот переход от «просто к проектов» к «проектам и программам проектов» называют «третье поколение проектного менеджмента», совместное мышление о программах работ и проектах как частях программы работ). При этом при переходе от проекта (от даты-1 до даты-2) переходят к «открытой дате окончания» (её просто не указывают, «работы над системой можно только начать, их нельзя закончить», это неявно отражает переход к концепции «непрерывного всего», но всё-таки с удержанием идей классического проектного и программного управления).

Проектные и программные менеджеры сегодня (прошли десятки лет с момента появления дисциплины!) уже утеряли связь с системным подходом и методологией, и чаще всего думают о просто «программе работ», связанных с целевой системой, нежели об этих работах как о «жизненном цикле» какой-то системы и уж тем более не думают о времени развития, «программе развития»/«программе работ создания и развития» – и тут же теряют понимание целостности системы, которая берётся в системном мышлении как целое, в том числе в третьем поколении – как развиваемый вид целого. Тут также происходит и утеря мышления о методах/спсобах созданиях систем, то есть утеря методологического мышления. Итого: в обсуждаемой картинке «жизненного цикла проекта» не хватает выхода на полный жизненный цикл, а также выхода в развитие системы, за пределы жизненного цикла, так что приведённую картинку нужно из линии сделать кольцом, а ещё лучше бы чем-то типа витой пружинки, чтобы учесть время (тот самый «не жизненный, но всё-таки цикл»), и «не жизненный, но цикл» проекта изображать как части такой «пружинки».

Всё сразу запутывается в этих сложных представлениях, поэтому от графических представлений в моделировании «не жизненного, но цикла» в рамках изображения техно-эволюции быстро отказываются, разве что иллюстративно на диаграммах всяких «методов разработки» рисуют те или иные кольца (мы приведём примеры чуть позже), и эти кольца ещё и не учитывают создание и развитие создателей в графе создания. Так что сейчас и рисуют на диаграммах, и обычно просто говорят о создании и развитии целевой системы, а слова «жизненный цикл системы» опускаются, просто «создание и развитие системы».

Программа работ чаще всего имеет единого для всех входящих в неё работ управляющего программой, но вот в классическом системном мышлении второго поколения жизненный цикл не требует выделения роли управляющего программой или проектом на всём протяжении жизненного цикла. Системное мышление – фундаментальный метод мышления, это не прикладная дисциплина типа программного и проектного управления, которая подразумевает работу прикладного мастера, владеющего прикладной практикой менеджмента, какого-то из видов классической инженерии, культурного строительства, образования или прикладной практикой какой-то иной деятельности по созданию самых разных систем.

«Программа партии/движения» – это ведь тоже программа работ, где создатель – коллективный агент, такой как партия/«общественное движение»:: сообщество! И «Программа» уже обычно не содержит терминологии «жизненного цикла», она как-то ближе в её понимании к идеям создания и параллельного с использованием непрерывного развития системы, а не просто «задумали, спроектировали, затем родился – жил – умер».

В ходе полного жизненного цикла системы и уж тем более в ходе всего времени развития/эволюции системы выполнять работы могут люди из разных организаций (и они могут включать и представителей разных сообществ и обществ на должностях как раз этих «представителей»), управлять работами будут полномочные для этого люди из этих разных организаций/предприятий/оргзвеньев, а методология на основе системного подхода поддержит целостность представлений о всех работах от замысла системы до её ликвидации, а не только работах программ и проектов отдельных организаций.

Тем самым понятие «жизненный цикл» в его самых разных изводах переносит фокус рассмотрения целевой системы на её создателей, а также из времени эксплуатации системы переносит рассмотрение на время создания. Окружение создателей – иное, нежели окружение целевой системы. Разбиения (иерархии по отношению часть-целое) создателей (их называли иногда «системы ведения жизненного цикла») совсем другие, чем разбиения целевой системы. И между целевой системой и создателем отношение не часть-целое, а создания (то есть оно учитывает методы ведения самых разных стадий работ, да ещё и в их непрестанном повторении для развивающихся версий системы: замысливания, проектирования, изготовления, проверки, обслуживания, модернизации и даже уничтожения после эксплуатации каждого экземпляра системы, но ещё в цикле для развития мемома – проекта/design системы как вида).

Садовник создаёт (в данном случае замышляет, проектирует, выращивает, эксплуатирует, ликвидирует) цветок: ведёт работы по методам замысливания появления цветка в конкретном месте, посадки семечка, полива семечка, а потом и растения, удаления сорняков из окружения растения, удобрения почвы для благоприятного окружения цветка, а после цветения выведения из эксплуатации (ликвидации/выкидывания) уже отцвётшего цветка. Цветок ничего не делает сам, все работы его жизненного цикла делает его система создания в лице садовника.

Система создания цветка не часть его окружения (садовник не часть каких-то систем окружения цветка, времени эксплуатации. Если агент, играющий роль садовника и любуется цветком, то это будет другая роль, не садовника). Системы окружения (время эксплуатации!) не части создателей (время создания!), создатели не части систем окружения, они рассматриваются в разных временах. Я жарю шницель: шницель не часть меня, я не часть шницеля! Это другое отношение, отношение создания. Я рисую/описываю дерево: дерево не часть меня, я не часть дерева, я и дерево не части описания, описание не часть меня или дерева. Есть и другие отношения, кроме отношений «часть-целое»/композиции. Отслеживайте типы объектов, но отслеживайте и типы отношений, минимально это классификация, специализация, композиция, реализация/воплощение, создание. Без знания теории понятий (работа с типами и отношениями объектов) и онтологии (учение о многоуровневой нарезке мира на объекты, находящиеся друг с другом в каких-то отношениях) системное мышление невозможно!

Итого: жизненный цикл в начальном (1.0) понимании – это по-крупному разбитые на стадии/фазы/этапы все работы создателей над замысливаемой, разрабатываемой, воплощаемой, эксплуатируемой, уничтожаемой целевой системой. По инерции сейчас в такое понимание включают и работы развития MVP до следующих версий системы, но раньше этого не было, всё мыслилось как «однократный проход по жизненному циклу», однократное выполнение работ над одной версией системы. А уж одна создающая организация выполняет все эти работы, или много разных, занятых разными жизненными циклами проекта – это менее важно. Главное тут было – не забывать о полноте жизненного цикла, уйти от жизненного цикла отдельного проекта к полному жизненному циклу.

Проблемы с жизненным циклом 1.0

Но не успело новое (по сравнению с жизненным циклом как сменой состояний целевой системы, из биологии, нулевая версия) понятие жизненного цикла (как поделённых на стадии работ создателей, первая версия) прижиться, как начались проблемы: в реальных проектах по созданию систем массово начала вырождаться стадийность.

Сначала в agile95 (гибких) подходах к разработке софта появились не тематические по видам работ «стадии», а безымянные «итерации» какой-то фиксированной длины – и на этих итерациях было очень трудно отследить, какая же там преимущественная тематика работ, чтобы по ним назвать стадию/фазу/этап. По факту там в каждой итерации и замышляли кусочек системы, и разрабатывали её, и делали, и испытывали, и эксплуатировали, и вроде как понятно было, что всё это нужно обсуждать, но вот идея «стадия как время ведения каких-то одних видов работ, а потом другая стадия как время ведения других видов работ» не выжила. Тем самым и провалилась попытка назвать работы в их крупном делении по имени метода – скажем, «изготовление» отсылало к содержанию работ в стадии, а при переходе к итерациям – все признаки «этапа» были, а вот отсылки к преимущественным методам работ исчезли. Это похоже на то, как был «лакокрасочный цех», а потом там стали делать и сборку, и тестирование, и даже сварку – и пришлось назвать «цех №4», специфика метода работы исчезли. Так и тут – этапы/фазы/стадии стали номерными, их специфика исчезла, красивые картинки «типового жизненного цикла» перестали описывать жизнь.

Эпоха «водопада/каскада/cascade» как «последовательного прохождения стадий жизненного цикла, как вода течёт в водопадах всегда сверху вниз» закончилась даже до появления полноценной идеи «непрерывного развития», в которой множество линейных жизненных циклов и системы в целом, и её фич замыкались в изначальное «квазибиологическое» кольцо/цикл. Квазибиологическое кольцо, когда никакая версия системы не является последней – это всё-таки техно-эволюция, когда создатели делают всё новые и новые версии системы, но не система делает себя сама снова и снова как в дарвиновской биологической эволюции (в техноэволюции мутации не случайны, это smart mutations, а наследственный материал не реплицируется вместе с системой – он хранится где-нибудь в конструкторском бюро). Но это уже была эволюция, не «от рождения до смерти» даже с учётом проектирования, и даже не «круговерть рождений и смертей», как в биологической эволюции, а круговерть доработок системы – и доработок в замысливании, и доработок в разработке, и доработок в изготовлении – типичная инженерия из идеализированной greenfield («с нуля») инженерии превратилась в повсеместную brownfield (не с нуля, доработка уже имеющегося) инженерию.

Затем в строительных проектах появилась параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным «тематическим» стадиям жизненного цикла: одновременно велось и проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать (например, крыло недостроенного здания).

Тем самым в начале нулевых годов 21 века возникли вопросы к идее о том, что работы на стадиях жизненного цикла ведутся с каким-то определённым состоянием целевой системы и поэтому группируются по каким-то методам. Система разными своими частями находилась в разных состояниях, а все методы работ применялись одновременно к разным частям системы: если корабль красили, то не как раньше – сначала зачищали всю поверхность, потом всю её грунтовали, потом всю красили, всю сушили. Нет, чаще всего сначала зачищали кусочек, потом его грунтовали, и одновременно начинали зачищать следующий кусочек, потом первый кусочек красили, второй грунтовали, а третий начинали зачищать – и «сначала» и «потом» оказывалось сугубо локальным для кусочка, а не глобальным для всей целевой системы. Стадии «зачистки», «грунтовки», «покраски», «просушки» оказывались перекрывающимися во времени/параллельными/concurrent, то есть они перестали быть последовательными стадиями, группировкой последовательности работ! В этом месте программисты могут вспомнить, как соотносятся декларативные функциональные описания и выполняемые на компьютере с хорошим распараллеливанием в процессорных ядрах императивные команды машинного языка. Описание жизненного цикла в его первой версии выглядело как процедурное, «последовательность крупных шагов», но оказалось функциональным!

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Найдите «разложение» в Википедии

2

Найдите Program Synthesis в Википедии

3

Найдите Logic Synthesis в Википедии

4

Это довольно легко найти в различных философских энциклопедиях

5

https://plato.stanford.edu/search/searcher.py?query=methodology, но можно искать и по запросу «философия науки», https://plato.stanford.edu/search/search?query=%22philosophy+of+science%22 – и там по тексту видно, что это в большинстве случаев синонимы. В частности, сравните с результатами поиска в другой энциклопедии https://cse.google.com/cse?cx=001101905209118093242%3Arsrjvdp2op4&ie=UTF-8&q=+methodology&sa=Search

6

https://plato.stanford.edu/entries/pragmatism/

7

https://t.me/knowledge_accumulator/175

8

IPU – information-processing unit как эволюционная реплицирующаяся единица, вводится в работе https://www.pnas.org/doi/full/10.1073/pnas.2120037119, обсуждалась в курсе системного мышления.

9

https://psyarxiv.com/fgcy5/

10

https://www.constructortheory.org

11

ISO/IEC 24744:2014 Software engineering – Metamodel for development methodologies, https://www.iso.org/standard/62644.html

12

https://en.wikipedia.org/wiki/Method_engineering

13

https://ailev.livejournal.com/750878.html

14

https://ru.wikipedia.org/wiki/СМД-методология – и там интересная дискуссия про «значимость работы» и «маргинальность» подхода в связи с идеей удалить статью с изложением принципов СМД-методологии. Довольно мало людей разбирается в тонких различиях между разными философскими школами и что там считать «маргинальностью», или чем философская школа отличается от методологической школы. Требования Википедии интересны, например, в ньютоновской механике вроде как нельзя использовать ссылки на работы Ньютона, чтобы она не была признана маргинальной, в СМД-методологии требуют убрать ссылки на работы Г.П.Щедровицкого, который и сформулировал многие её принципы – из-за чего уже пару лет и стоит вопрос об удалении статьи как маргинальной!

15

Это подробней рассказывается в курсе системного мышления, дальше мы не будем делать таких оговорок, знание материала этого курса – пререквизит к нашему курсу.

16

https://system-school.ru/engineering

17

https://en.wikipedia.org/wiki/Normativity

18

https://en.wikipedia.org/wiki/Praxeology

19

https://en.wikipedia.org/wiki/Division_of_labour

20

https://arxiv.org/abs/2301.10077 и проект продукта NeuralPilot на основе этих результатов: https://artificialneuralcomputing.com/neurapilot

21

«Всё новое в методологию приходит сбоку», https://ailev.livejournal.com/1725419.html

22

https://ru.wikipedia.org/wiki/Парадокс_Моравека

23

https://www.quora.com/In-artificial-intelligence-which-is-better-policies-or-plans-and-why

24

https://mises.org/library/praxeology-reply-mr-schuller

25

https://en.wikipedia.org/wiki/Hybrot

26

Обложка альбома The Dark Side of The Moon группы Pink Floyd, https://ru.wikipedia.org/wiki/The_Dark_Side_of_the_Moon

27

https://systemsworld.club/t/topic/4319

28

https://systemsworld.club/t/post-na-pomidorku-kapoejra/12031

29

https://ru.wikipedia.org/wiki/Спектр

30

https://www.youtube.com/watch?v=JlXeQxAkDf0

31

https://www.researchgate.net/profile/Wim-Gielingh/publication/228797525_A_theory_for_the_modelling_of_complex_and_dynamic_systems/links/00b7d516e525eab19e000000/A-theory-for-the-modelling-of-complex-and-dynamic-systems.pdf

32

https://ru.wikipedia.org/wiki/Схемотехника

33

https://kimray.com/training/how-read-oil-and-gas-pid-symbols

34

https://systemdynamics.org/

35

https://modelica.org/

36

https://www.digitalengineering247.com/article/a-case-for-merging-system-modeling-and-finite-element-analysis/

37

https://juliahub.com/products/juliasim

38

https://www.researchgate.net/publication/336846217_Multi-Mode_DAE_Models_-_Challenges_Theory_and_Implementation

39

Causal vs Acausal Modeling By Example: Why Julia ModelingToolkit. jl Scales (Chris Rackauckas, SciML) – https://www.youtube.com/watch?v=ZYkojUozeC4

40

https://fmi-standard.org/

41

https://en.wikipedia.org/wiki/Variable_structure_system

42

https://arxiv.org/abs/2008.05166, раздел 12

43

https://docs.sciml.ai/ModelingToolkit/stable/

44

https://help.juliahub.com/juliasim/stable/

45

https://en.wikipedia.org/wiki/Expression_problem, https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions, объяснение «на пальцах» https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/

46

https://en.wikipedia.org/wiki/Simula

47

https://en.wikipedia.org/wiki/Multiscale_modeling

48

https://docs.sciml.ai/Surrogates/dev/

49

https://www.linkedin.com/pulse/mixture-experts-yacine-bouaouni-ehc5c/

50

https://en.wikipedia.org/wiki/Neural_network_(machine_learning)

51

https://en.wikipedia.org/wiki/Transformer_(deep_learning_architecture)

52

https://t.me/gonzo_ML

53

https://t.me/gonzo_ML/2, далее обсуждаемая статья – https://arxiv.org/abs/1901.04596

54

https://www.cs.toronto.edu/~kriz/cifar.html

55

https://t.me/gonzo_ML/2580

56

https://arxiv.org/abs/2403.14608

57

https://arxiv.org/abs/2407.02423

58

https://ailev.livejournal.com/1727440.html

59

https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs

60

https://habr.com/ru/articles/505928/

61

https://habr.com/ru/companies/piter/articles/521120/

62

https://en.wikipedia.org/wiki/Programming_paradigm

63

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

64

https://www.youtube.com/watch?v=40CB12cj_aM – тут ровно про это обобщение computer до constructor.

65

https://ru.wikipedia.org/wiki/Арабские_цифры

66

https://www.researchgate.net/profile/Danielle-Macbeth/publication/267433879_Seeing_How_It_Goes_Paper-and-Pencil_Reasoning_in_Mathematical_Practice/links/5554fbc108ae6fd2d821bb1b/Seeing-How-It-Goes-Paper-and-Pencil-Reasoning-in-Mathematical-Practice.pdf

67

https://ru.wikipedia.org/wiki/Теория_речевых_актов_Джона_Остина

68

https://ru.wikipedia.org/wiki/Перформатив

69

https://ee-institute.org/

70

https://ru.wikipedia.org/wiki/Автоматное_программирование

71

https://en.wikipedia.org/wiki/Frame_(artificial_intelligence)

72

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7250653/

73

https://en.wikipedia.org/wiki/Agda_(programming_language)