(дайджест статей на тему subj:о)
Вопрос о том, какова природа программирования - отнюдь не отвлечённый. От того, как мы понимаем свою деятельность, зависит выбор организационной структуры, методов работы и т.д. Сейчас уже очевидно, что крах многих программных проектов был следствием того, что деятельность программиста понималась неадекватно: грубо говоря, промышленное изделие создавали методами, принятыми в искусстве или науке.
Сейчас производственный характер программирования уже почти не вызывает сомнения, поскольку осознана необходимость в стандартизации, регламентации, нормирования, экономического регулирования и т.д. Основная задача технологии программирования сейчас - добиться в производстве ПС степени управляемости, присущей промышленному производству. Однако дело идёт довольно туго. Одна из причин заключается в том, что большинство программистов - по образованию математики, и промышленное мышление им чуждо, а промышленная терминология незнакома. Вторая причина заключается в известном сопротивлении материала: уж очень много у программного изделия свойств, отличающих его от обычного изделия, и поэтому не работают методы теории надёжности, возникают правовые проблемы и организационные. Некоторые проблемы носят характер безвыходности: очевидно, например, что измерять производительность труда программистов в командах нелепо, однако трудно найти другой критерий оценки количества продукции, выпускаемой программистом.
Эта проблема, как и многие другие, являются следствием слишком грубого понимания промышленного характера программирования. На программирование произвольно перенесена идеология машиностроительного производства, хотя очевидно, что это не единственный тип производства. При этом программа отождествляется со сложным техническим изделием, и все действия по её созданию интерпретируется по аналогии. В частности, считается, что программисты изготавливают текст программы, собирают ПИ из деталей и т.д. Многие выводы строятся именно на основе магической фразы "программисты изготавливают программные изделия". Однако фраза эта - всего лишь аналогия, причём можно с таким же успехом предложить и другую аналогию. Фраза эта весьма уязвима: кто и когда доказал, что продукт деятельности программиста обладает свойствами, необходимыми для того, чтобы быть изделием? Скорее наоборот, мы повсюду наталкиваемся на то, что программа - не изделие. Кто и когда доказал, что деятельность программистов есть именно изготовление? Ведь не всякая деятельность в производстве есть изготовление. Ничего не изготавливает водитель автокара, или, положим, технолог станков ЧПУ.
Очевидно, что аналогия - штука неубедительная, и потому её нужно корректно обосновать, прежде чем делать из неё далеко идущие выводы. Раз уж программирование - производство, то нужно грамотно в философско-экономическом смысле определить, где в этом производстве продукт, где инструмент, а где работник. Пока мы будем называть технологию изделием, а инструмент - сырьём, дело не пойдёт.
Данная работа является попыткой анализа программирования с точки зрения науки о человеческой деятельности - праксеологии.
Прежде всего, разберёмся с вопросом, является ли текст программы том или ином виде, т.е. наиболее очевидный продукт труда программистов, изделием.
Оказывается, нет. Во-первых, по сущности своей, текст программы не есть самостоятельно существующий объект - это всего лишь набор правил, инструкций. Реальный объект, которым мы пользуемся и который мы можем назвать изделием, вовсе не является текстом программы: он порождается текстом программы, а это далеко не одно и то же. Словосочетание "мы пользуемся программой" обманчиво, на самом деле процессов два: на основании программы создаётся нечто, чем мы пользуемся, но в силу автоматизированности первого из этих процессов у нас складывается впечатление, что мы пользуемся именно программой. Когда мы говорим, что пользуемся программой, мы имеем в виду работающую программу, а не её текст. Я бы не говорил всех этих очевидных вещей, если бы не в ГОСТ 19.004-80 не было указано, что "программное изделие это программа на носителе данных, являющаяся продуктом промышленного производства", т.е. программное изделие - это текст программы в машинных кодах! Но очевидно, что если изделие - это текст, то и свойства изделия должны быть свойствами текста. Однако ни одна характеристика качества ПИ, кроме, разве что, понятности, не есть характеристики текста. Например, текст не может быть эффективен: эффективна последовательность действий, описанная в тексте, и то не сама по себе, а в зависимости от оборудования, которое эти действия будут осуществлять. То же можно сказать и о надёжности, и об удобстве в работе, и т.д.
Итак, мы приходим к выводу, что изделие - это не текст. Если и имеется в природе программное изделие, то это объект, порождаемый программой. Текст же есть описание технологии изготовления этого объекта. В общем-то, это довольно тривиальный вывод, поскольку по своей природе программы гораздо ближе к технологиям, чем к изделиям. Не разбирая пока природу объектов, порождаемых программой, оценим практические выводы из такого понимания.
1.Деятельность программиста не есть изготовление, а есть описание технологических процессов. Следовательно, аналогом деятельности программиста является не деятельность сборщика машин, а деятельность технолога. В частности, это означает, что для оценки производительности труда не нужно искать способ оценки количества продукции, выпускаемой программистом - поскольку никакая продукция не производится. Нужно установить категории сложности, как у технологов. (Следует отметить, что деятельности технолога предшествует деятельность по разработке технологии, т.е. деятельность научная. Собственно производственный характер работа получает только после выдачи спецификации.)
2.Поскольку продуктом труда коллектива программистов является не изделие, а технологическая схема, то и товарные свойства этого продукта - не товарные свойства изделия, а товарные свойства технологии. Это снимает многие коллизии, связанные с правовым статусом программ.
3.Собственно производство продукции происходит не в ВЦ разработчика, а в ВЦ пользователя, куда передаётся технология. Именно тут действуют стандарты массового производства. В частности, такое понимание требует от разработчика не только и не столько программы (т.е. технологию автоматизированных участков), но и технологию ручных участков, что обычно забывается.
Обратимся теперь к тому, какого рода объекты создаются в ходе технологических процессов, описанных программой.
Если продолжить аналогию с машиностроительным производством, то мы можем предположить, что программа-технология описывает изготовление динамического объекта сложной природы, являющегося материализацией абстрактных понятий. Точно так же, как понятие факториала существует у нас в мозгу как физический объект, т.е. как совокупность конкретных нейтронов, определённым образом связанных меж собой, так и понятие факториала существует в машине в момент выполнения программы вычисления факториала.
Вообще говоря, праксеология допускает такое истолкование изделия: точно так же различается ребёнок как изделие родителей и ребёнок как результат воспитания: у него перестраиваются конкретные физические структуры, а значит, это физически другой объект, т.е. изделие воспитателей.
Но изделие, понимаемое таким образом, имеет ряд настолько необычных свойств, что от него приходится отказаться. Так, оно существует (а значит, и может использоваться) только в момент изготовления и только по частям, причём весьма трудно отличить действия по изготовлению от действий по использованию, и т.д.
Всё это заставляет нас задуматься: а был ли мальчик, т.е. существует ли вообще программное изделие? Ведь, кроме машиностроительной, существуют ещё и добывающая, и перерабатывающая промышленность, в которой не изготавливаются сложные технические изделия, однако существует и стандартизация, и регламентация, и всё то, что так нужно нам в программировании.
Может показаться, что я ломлюсь в открытые двери: никто и не отрицает существования индустрии переработки информации. Но весь вопрос в том, какое место в этой индустрии занимает программа: станка или изделия. Я просто выступаю против эклетики в этом вопросе: если это изделие, то и обращаться нужно, как с изделием, и не делать заявлений типа "да, это изделие, но...". Если же это технология, то её нужно создавать и распространять как технологию, не пытаясь наделить её свойствами изделия.
Итак, предлагается следующая концепция: программирование есть часть индустрии информации, занимающаяся разработкой и внедрением технологических процессов переработка информации. Продукт труда коллектива программистов есть технологическая схема конкретного участка производства, включающая в себя как описание автоматических процессов (программы), так и ручные операции.
Может показаться, что такое понимание - шаг назад, поскольку создание технологии - далеко не столь управляемый процесс, как изготовление изделия, и многие надежды, связанные с промышленным подходом, не оправдаются. Но нужно смотреть правде в глаза: если уж что-то не изделие, то при всём желании мы не сможем сделать это изделием, и если уж мы ушли от истины, то путь к истине неизбежно будет путём назад. Тут уж ничего не поделаешь.
Рассмотрим простой пример. В нашем мозгу понятие факториала существует как физический объект, в виде определённой связи конкретных нейтронов. Когда мы пишем программы вычисления факториала мы фактически передаём это понятие машине. Мы сами понимаем, что такое факториал, и в промежутке между началом и концом выполнения программы машина тоже "понимает", что такое факториал. Более того, это понятие существует в машине как физический объект, как совокупность меняющихся магнитных полей, и вот этот объект мы уже вправе назвать изделием.
Нам могут возразить, что программное изделие не обязано быть физически существующим, поскольку процесс его создания и использования носит сугубо информационный характер. Но и изготовление болта носит информационный характер - мы можем понимать его как процесс записи на носитель информации о длине, размере и направлении резьбы и т.д. Тот факт, что физические усилия преобладают в этом процессе, не говорит о его сугубой неинформационности. Если бы вместо нажатия клавиши на дисплее мы должны были бы бить по ней кувалдой, программирование считалось бы тяжёлым физическим трудом.
Рассматривая болт как изделие, мы можем видеть в нём как минимум три составляющих:
- информационную, или понятие: болт длины такой-то, резьба такая-то;
- физическую, или носитель: конкретное физическое вещество;
- технологическую, или программу: как болт был изготовлен.
Мы можем один и тот же болт вытачивать или штамповать, изготавливать его из различных сортов стали, но это будет одно и то же изделие, если информационная составляющая останется неизменной. Точно так же понятие факториала мы можем изготовить различными программами (технологиями на различном оборудовании (ЭВМ), но это будет одно и то же понятие: факториал. Существенное отличие факториала от болта заключается в том, что материал болта настолько долговечен, что болт может использоваться длительное время после изготовления; носитель же факториала, т.е. динамическая комбинация магнитных полей, недолговечен, и понятие существует в машине только, в момент выполнения программы (впрочем мы можем изготовить существующую микросхему, и тогда понятие станет полноправным изделием). Суть дела от этого не меняется, меняется только размер интервала между изготовлением и использованием - для болта - годы, для факториала - доли секунды.
Итак, программное изделие - это не текст программы, а совокупность понятий, которые во время выполнения программы "оживают" и существуют как физические объекты. Такая концепция позволяет по-новому взглянуть на деятельность программистов.
Деятельность программистов состоит из двух частей - конструкторской и технологической. Конструкторская деятельность заканчивается с утверждением спецификаций: понятия составляющие изделие, определены и определены связи между ними. Технологическая деятельность (собственно программирование) заключается в описании технологии изготовления этих понятий. Поскольку производство весьма автоматизировано, программисты обычно сосредотачивают усилия на программах, пренебрегая описанием технологии на ручных участках. Печальные результаты общеизвестны: вполне отлаженные системы оказываются неработоспособными. Выход из положения, видимо, заключается в том, что официально необходимо признать программистов технологами а стандарты ЕСТПП распространять не на подготовку их деятельности, а на саму деятельность. Программы и руководства обслуживающему персоналу должны выполняться в соответствии с ЕСТД. Собственно производство программных изделий происходит в ВЦ, на которых используют программы, поэтому именно туда надо переносить стандарты массового производства.
Дайджест по материалам работ "Выступление по материалам тезисов "Программирование как деятельность" и о "термине "программное изделие"" (вариант от 15.10.86)" и "ПРОГРАММИРОВАНИЕ КАК ДЕЯТЕЛЬНОСТЬ"
Комментарий из 1999 года.
Эти бредовые мысли, озвученные мною в 1984-1986 годах, к сожалению, не были реализованы в виде каких-либо стандартов, технологий и т.д. Хотя статья "О ТЕРМИНЕ "ПРОГРАММНОЕ ИЗДЕЛИЕ"" наделала шума на второй всесоюзной конференции по технологии программирования, дело так и кончилось шумом. Все мои попытки убедить больших дядей из ГКВТИ в своей правоте закончились ничем. А между тем, как мне представляется, непонимание всех этих вещей здорово тормозит развитие информационных технологий (во, видите, такой термин все-таки появился!). Уж не буду говорить о программистах, которые и поныне нередко наступают на грабли тридцатилетней выдержки, делая программы без учета окружения, в котором эти программы будут работать. Обиднее всего, что пользователи программ не понимают, что они покупают не изделие, а технологию. Именно в этом - причины того, что они недооценивают такие технологически необходимые вещи, как резервное копирование или антивирусная защита. Именно в этом - причина того, что, покупая новую программу, люди пытаются с ее помощью реализовать старую технологию переработки информации. Скажем, я знаю множество примеров, когда мощные текстовые редакторы использовались на уровне пишущей машинки (один мой знакомый доселе вручную расставляет переносы в Word-овских текстах!) . И это происходит не столько от незнания тех или иных возможностей, сколько от того, что люди не понимают: мы не просто меняем пишущую машинку на компьютер, а кардинально изменяем технологию обработки документов. Скажем, если раньше болт вытачивался вручную, теперь он штампуется на станках с ЧПУ. Это я привел простой пример, чтобы было понятно многим, а если подняться повыше, то мы увидим столько чудес... Скажем, большинство проблем при внедрении бухгалтерских программ происходит именно оттого, что ни клиент ни (нередко!) поставщик, не понимают, что надо существенно менять все технологию учета, а не просто поставить бухгалтерскую программу вместо калькулятора. Если бы оба участника процесса понимали, что речь идет не о поставке программного продукта, а о замене технологии бухгалтерского учета, то недоразумений было бы гораздо меньше.
В какой-то степени я пытался растолковать это своим коллегам и клиентам. Скажем, методички для начинающих я писал не как пособия по текстовому редактору или электронным таблицам, а как пособия по технологии автоматизированной обработки документов. Понимания этих вещей я требовал и от преподавателей нашего учебного центра. Не знаю, насколько это удалось... Но, что обидно - проблема, которую я, казалось, разрешил пятнадцать лет назад, до сих пор остается актуальной. Может быть, эта публикация в СТАЛКЕРе кому-то откроет глаза. А если кто не согласен, давайте поспорим! :о)
Опубликовано: "Сталкер"
© Алексей Бабий 1999