Компьютерные программы
Программа, как система — это 4D индивид , она занимает место в пространстве-времени, она материальна. Программа — это вещь, по ней можно постучать, ткнуть в неё пальцем! Эта вещь — физическая часть компьютера, которая проводит вычисления этой программы в ходе её работы по назначению (помним, что система определяется по основной её функции в момент, когда она полностью готова и работает, то есть выполняет своё назначение).
У программы-индивида в момент работы есть разные состояния (которые физически представляют собой состояния оперативной памяти и регистров процессора), а компьютер занят физическими процессами в ходе вычисления, эти процессы занимают пространство-время: пространство, в котором расположены взаимодействующие части компьютера, и время, во время которого программа выполняет свою функцию, то есть компьютер проводит вычисления:
Ещё раз подчеркнём: программу следует считать воплощением системы только в тот момент, когда она реально запущена на исполнение и работает, делает то, ради чего она была написана. Это довольно контринтуитивно, но исходный код программы — это не программа, а только описание программы. Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода — эти программисты глубоко неправы, это типичная ошибка. Из признания этой ошибки появилось целое движение DevOps — программисты признали, что они должны выполнять роль не только разработчиков кода программы ( Dev elopment), но и сопровождением работы программы на рабочих серверах ( Op erations).
Исходный код — это описание программы (в классах, как любое проектирование), и перед использованием её нужно изготовить: откомпилировать, собрать, разместить в оперативной памяти нужного компьютера (возможно, перед этим оформив в какой-то контейнер) и передать на неё управление.
Тем самым программа — это процесс, и нас интересует именно тот процесс, который выполняется на правильном компьютере (или компьютерах — например, клиентском и в облаке), в тот момент, когда программа работает и выполняет свою функцию, своё назначение. Понятно, что от исходного кода до вот так работающей программы обычно долгий путь.
Ошибка, которую делают программисты, считая свой исходный код программой, ровно того же сорта, которую проектировщики и конструкторы делают, считая своей системой разрабатываемые ими информационные модели (а раньше — чертежи) и другую проектную и конструкторскую документацию. Карта не территория, меню не едят, на чертежах не летают, исходный код не хранит значений своих переменных в ходе исполнения.
Ещё одна ошибка — это считать программу отдельной системой, ибо регулярно в корпоративной разработке софта клиенты ожидают не столько корректную работу компьютера, сколько корректную работу той части организации, которую должен этот компьютер поддержать. Люди в организации должны вместе с программой сработать по какому-то организационному алгоритму. Такой совместный поток работы людей и компьютеров называется обычно workflow, хотя сейчас его чаще называют оргпроцессом. Чаще всего программа — это только часть этого оргпроцесса. Но для того, чтобы клиент смог получить результат оргпроцесса, эту программу нужно настроить, дать ей какие-то данные, научить с ней работать сотрудников и проверить не столько работу самой программы, сколько работу всего оргпроцесса в целом. Никого не волнует работа программы начисления зарплаты, волнует начисление зарплаты — и если начисления зарплаты не произойдёт, то программистам трудно будет объяснить, что с их программой всё в порядке, а неправы все остальные. Поэтому в проектах по разработке программ очень часто есть часть по работе с людьми и данными.
Ещё лет двадцать назад считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные. Оказалось, что современное программное обеспечение сдвигается в сторону работы со сложными данными, при этом алгоритмы работы с этими данными относительно просты и единообразно устроены. А поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные — это в конечном итоге описания каких-то систем, но в момент их обработки какой-то программой они сами становятся частью системы этой программы, «вещью». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ мы должны научиться их изготавливать из исходных данных — и мы по аналогии с DevOps будем говорить о DataOps .
Системное мышление нужно как программистам, так и специалистам по обработке данных: в силу углубления разделения труда это уже не одно и тоже, а системное мышление поможет этим специалистам договориться между собой, а также с менеджерами и другими сотрудниками предприятий, для которых они работают.
- 1. О мышлении Разные мышления
- Требования к мышлению
- Место системного мышления среди других мышлений
- Варианты системного мышления
- Системная инженерия
- Наш вариант системного подхода
- Наша онтология системного подхода
- Семантика и описания
- Терминология
- Формы мышления
- Можно ли научить мышлению?
- Стадии обучения мышлению
- Особенности решения учебных задач по системному мышлению
- Переход к использованию мышления
- 2. Воплощение системы, стейкхолдеры и интересы Воплощение, определение и описание системы
- Абстрактные объекты
- 4D экстенсионализм
- Отношение состава
- Отверстия
- Процессы и действия
- Компьютерные программы
- Функции
- Физические и функциональные объекты
- Второе поколение системного подхода
- Стейкхолдер
- Театральная метафора
- Мышление о людях: прежде всего они стейкхолдеры
- Позиция
- Лидерство
- Внешние и внутренние стейкхолдеры
- Организационные места, ответственность, звания
- Сколько всего стейкхолдеров
- Луковичная диаграмма
- Интересы
- Кто участвовал в последнем совещании?
- 3. Системная холархия Не всё системы, что ими называют
- Понятие холона и холархии
- Эмерджентность
- Пять видов систем в холархии
- Рекурсивное применение системного мышления
- Потребности, требования, ограничения
- Примеры использования терминологии видов систем
- Системы систем
- Люди в системах
- Государственное строительство и госпроекты
- Будущее
- Общность мышления по мере усложнения систем
- Сложность и меры сложности
- 4. Целевая и использующая система Сначала найти целевую систему
- Система — это продукт, или сервис?
- Признаки целевой системы
- Принцип почтальона
- Типовые ошибки определения целевой системы
- Именование системы
- Использующая система
- Холархия человеческого движения
- Системный подход: для всех видов систем, не только для целевой
- 5. Определение и описание системы Междисциплинарность
- Многерица: единонемыслие единого
- Многерица холархий
- Компонентный анализ и модульный синтез
- Альфы и рабочие продукты
- Описание системы
- Модели и виды моделей
- Мультимодель и междисциплинарность
- Метод описания и мега-модель
- Компонентные описания: принципиальные схемы
- Модульные описания
- Платформы и технологические стеки
- Важность функциональных рассмотрений целевой системы
- Предпринятия
- Необходимость хорошей модульности
- Борьба со сложностью в мышлении
- Требования как часть определения системы
- Два понимания требований
- Требования и холархия
- Целеориентированная инженерия требований
- Проверка и приёмка
- Понятие архитектуры
- Понятие конфигурации
- Инженерия предприятия
- 6. Понятие жизненного цикла Биологический жизненный цикл
- Понятие жизненного цикла системы 1.0
- Изображение жизненного цикла как работ (1.0)
- Проблемы с жизненным циклом 1.0
- Жизненный цикл 2.0
- Эксплуатация как выделенная стадия жизненного цикла
- Три времени жизненного цикла
- Понятие практики
- Дисциплина в составе практики
- Технология в составе практики
- Практики жизненного цикла
- Пример: практики жизненного цикла системной инженерии
- Методологии
- 7. Вид жизненного цикла
- Моделеориентированность в жизненном цикле
- Гибридные модели жизненного цикла
- Управление работами и управление жизненным циклом
- Виды практик управления работами
- Тренды в практиках управления работами
- За пределами жизненного цикла
- Жизненный цикл как архитектура деятельности
- 8. Системная схема проекта и основной жизненный цикл Системная схема проекта
- Альфы — общий объект отслеживания команды
- Альфа возможности
- Альфа стейкхолдеров
- Альфа определения системы
- Альфа воплощения системы
- Альфа работы
- Альфа команды
- Альфа технологии
- За чем следить в проекте
- Состояния альфы и рабочие продукты
- Как работают с системной схемой проекта
- Подальфы
- Основной жизненный цикл
- Модели зрелости и модели готовности технологий
- Системные практики
- Итоговое эссе
- Что дальше