Илья Ермаков писал(а):
Подготовлена в качестве пленарного доклада для конференции "Новые информационные технологии-2010" (
http://nit.miem.edu.ru/).
К сожалению, до типографии не успела и в сборнике напечатана не будет.
Да, хорошо сказано... Как обычно, возникают и общие вопросы, и конкретные - теоретические и практические. Конкретные для удобства выделю в другие сообщения - см.
теорию и
практику; здесь в общем по некоторым положениям.
О нефиксации процесса неформального созидания в п.6 Разд.II (что уже хорошо известно в виде правила "указывай человеку-исполнителю, ЧТО делать, но не указывай, КАК"
) - регламентация процессов создания действительно проскальзывает в документах СМК. В то же время никого, наверно, не удивляет существование техподготовки производства, где ставится задача именно разработки некоего процесса создания (ну и обеспечивающих его систем инструмента и приспособлений). В чём тут дело? Полагаю, в том, что исполнитель такой задачи поднимается по отношению к задаче, решаемой созидаемой системой, на более высокий уровень рассмотрения, где процесс созидания системы-решателя автоматически становится
"тем, ЧТО", а не "тем, КАК" - и тем самым оказывается не жёстко фиксированным процесс создания процесса, что и нужно для творчества. Именно это имеется в виду, когда говорят, допустим, о реинжиниринге. Другое дело, что этот процесс в отчуждённом виде будет вполне формальным (не "интеллектуальным", как в сознании, а "интеллектным") - иначе не получится хотя бы по тому же Фридланду - и для творческого созидания во многом рамочным, как та же ТРИЗ. Видимо, это хорошо понимал тот же Грабин - тоже не фиксируя, КАК трудиться разработчику, а только связывая его нормами, ЧТО должно получиться (система/процесс с соблюдением стандартов при минимальной трудоёмкости). В своей отрасли он именно это рассматривал как ключ к преодолению того, что "типовой характер решаемых задач и конвейерный стиль работы способствует сужению кругозора <разработчиков>", что видно из выдержки
в этом сообщении - не будет ли это справедливо и для программной инженерии?
Кстати, автор книги по ТРИЗ, выдержка из которой в этом сообщении хорошо сказал: "любая деятельность вырастает из принципов её организации" (Орлов М.А., с.. Поэтому общее представление о процессе созидания д.б. зафиксировано (отчуждено в документальной форме на общеприменимом комплексе языков) - что не мешает человеку, восприняв его, в конкретном случае действовать по-своему ("ТРИЗ не заменяет творческого мышления, а только является его инструментом" - с. 66, "... конечно, каждая техническая задача по-своему индивидуальна... Магической формулы <поиска решения> нет, но есть приёмы, достаточные для большинства случаев." - с.56). В целом получается то, что выражено "правилом братьев Стругацких" - "инструкция - для тех, кто ещё не умеет" - воспринял человек/коллектив инструктивно формализованный опыт и стал применять его в чём-то по-своему.
Весьма возможно, "мёртвые" примеры фиксации были основаны как раз на отсутствии вышеуказанного иерархического подъёма, попытках дать "раз и навсегда" методику КАК - и в системе ИСО900Х, боюсь, т. зр. и правда не самая оптимальная... Реалистичная и проверенная практикой организация коллективного процесса применительно к ИТ,
IMHO, содержится в методологии IDEF.
Опираясь на результат предыдущей смены уровня рассмотрения, можно подняться ещё раз - и при этом вырастает разновидность той самой "иерархии абстракций", об умении строить которую "поэтапно и аккуратно" Илья тоже говорил здесь в п.3 Разд.II. Да, велика инерция - впервые об этом принципе как основе представления о ПО (да и вообще о сложных системах) я, скажем, прочитал ещё в "Современном компьютере" в статье об ОС - но прошло четверть века, а необходимость этого надо ещё доказывать
В пп.3,4 Разд.I существенное место занимает установление связи математики и информатики. Кроме того, о чём говорил Паронджанов - когнитивной неэргономичности математики (у Ильи "неприученность математиков к хорошей организации формальных текстов — к глубокому
структурированию, простоте и ясности выражения") - здесь надо вспомнить, что существует логика и математика "здравого смысла", что выявлено в попытках построения интеллектных инфорсим. Её "не учат в школе", но именно она служит основой как деятельности, так и её объяснения - для большинства людей единственной. Поэтому "строгой" математики и информатики мало - нужно исходить и из "нестрогой", рассчитанной на исполнение интеллектом, о чём подробнее
в этом сообщении. И только для программирования информашин нужно выделять ограниченную часть модели деятельности, которую можно строго математизировать, и так её и рассматривать как часть.
Что из этого вытекает? Прежде всего необходимость учить общим формальным законам решения задач прежде, чем напускать на конкретные задачи получаемой специальности. Помнится, во втузах есть курс "Основы технического творчества" - но достигает ли он такой цели? Если нет - как бы не пришлось включать этот вопрос в курс общей информатики...
Очень интересна аналогия доказательного синтеза программ и материальных конструкций по результатам расчёта на прочность в п.5 Разд.I - в то же время в сопромате на каждом шагу встречаются "коэффициенты запаса" на неопределённость свойств (прежде всего физических) рассчитываемого объекта. Видимо, что-то должно играть эту роль и для объектов программирования?
Положение о взгляде "между строк" формальной информодели вызывает тоже очень естественную аналогию с тем, как создатель материальных систем по чертежу представляет себе (или симулирует машинно) объект в рабочем движении (всё ли при этом происходит, как задумано) и его элементы (детали, узлы, агрегаты) в процессе создания - обеспечивается ли прежде всего "собираемость", а затем - нужная трудоёмкость сборки? И здесь, думаю, в основе лежат физические состояния информашины как исполнителя - именно их закономерной сменой обеспечивается правильный переход от команды к команде - а если готовят не проектировщика/эксплуатационника оборудования, то надо давать лишь некие понятия об этих состояниях.
Далее, конечно, идут логические состояния, и здесь возникает вопрос - Вейценбаум в приведённой цитате, полагаю, совершенно прав - а что будет альтернативой программированию обработки "специальных случаев" (читай - исключений?)? Имеется в виду, что они исключаются логикой (скажем, контролем данных, чтобы не получались недопустимые значения) и/или что-то иное?
Ну, понимание программы как конструкции,
IMHO, лучше всего формируется при визуальном представлении её структуры - как и сделано в техноязыке... И в сопоставлении визуального с текстовым, наверное, проще всего вырабатывать умение находить подобие и совершать переходы.
И действительно, как хорошо было бы "выбрать язык один раз", как о том пишется в п.5 Разд.II...
О структурировании информационных фондов в п.6 Разд.II - основой для этого,
IMHO, д.б. документ, обеспечивающий структуризацию. Такой принцип установил Паронджанов, говоря о схематизации знаний - и нужен стандарт на схематизирующий проектный документ, позволяющий сочинителю создавать свою структуру, но из типового множества элементов, понимаемых однозначно всеми участниками. Об этом опять-таки подробнее
в другом сообщении.
Хотелось бы публикации и её обсуждения... хотя сегодня, пожалуй, уже формируется другая культура, в т.ч. научная, центричная относительно не натуральной периодики, а как раз инфорсетевых СМИП, напр. данного ресурса - но нормативно это не закреплено.