Мастерская бизнес-анализа

Разработка ПО в эпоху АСУ – взгляд аналитика (постановщика).

28.02.2010 at 12:15 4 комментария

От автора: 

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

Но – вроде материала и много, а для бизнес-аналитика он не подобран, искать и тем более читать его долго и муторно.

Никаноров [9] пишет, что «реальная история создания систем организационного управления для объектов разного типа на базе компьютеризации в СССР так и не написана и ее итог толком неизвестен».

Поэтому возьму на себя смелость обобщить собранный материал и изложить его в кратком виде/  и с известной долей субъктивности. Использованы в основном источники, написанные давно (1977-1999г)

Начну с эмоциональной и широко растиражированной статьи 1999 года  Бориса Вольфмана.

Жажда эволюции в российской индустрии ПО

Эпигаф: «Весь мир программный мы разрушим до основанья, а затем…»

 «История индустрии программного обеспечения в России пережила не одну революцию. Они точно характеризуются представленным эпиграфом, поскольку каждый раз все созданное терялось едва ли не полностью. Последовательного накопления результатов в масштабах отрасли почти не происходило. Если какое-то накопление и было, то только в виде знаний в головах отдельных специалистов. А отрасль страдала глобальными приступами амнезии. …

Не желая программировать в машинных кодах, отечественные энтузиасты в 60-е годы проектировали для этих машин языки программирования, принципиально отличающиеся от американского Фортрана, Алгола или Кобола, самым бурным и последовательным было развитие общесистемного и прикладного программного обеспечения для «Минск-32». К середине 70-х были созданы и успешно эксплуатировались в различных АСУП мощные пакеты прикладных программ. Существовала ассоциация пользователей «Минск-32», распространявшая отечественные программы общего назначения со статусом freeware и shareware. В большинстве случаев программные продукты создавались талантливыми специалистами, объединяющимися в небольшие коллективы

А вот «централизованное» отраслевое ПО, призванное ликвидировать дублирование разработок для однотипных задач, большой популярностью у предприятий не пользовалось. Основные причины — некачественное исполнение, невысокий уровень разработчиков, недостаточные знания объекта внедрения, слабая зависимость вознаграждения авторов от тиража программы.

Первая революция — это переход с машин второго поколения на ЕС ЭВМ и на ОС ЕС. Решение руководства страны по развитию направления ЕС ЭВМ позволило отечественным программистам в максимальной степени интегрироваться в индустрию американского «софта» (а на самом деле — стать к ней в хвост) и сделало абсолютно бесперспективным развитие, сопровождение, эксплуатацию созданных программ на отечественных машинах второго поколения. Большая часть накопленного была потеряна.

Прикладное ПО, не имеющее западных аналогов, было заново написано для ЕС ЭВМ. Правда, теперь уже с применением систем управления базами данных и других пакетов программ. В общесистемном программном обеспечении ведущие институты страны добросовестно заменяли сочетания слов: «IBM 360» на «ЕС ЭВМ»; «IMS» на «OKA»; «CICS» на «KAMA»; «ADABAS» на «ТРИАДА» или «ДИСОД», и так далее и тому подобное. Документация к ПО переводилась, как правило, лингвистами, и устанавливать соответствие между действующими программами и их описанием было затруднительно. Вместе с тем советские программисты постоянно «латали дырки» американского программного обеспечения».

Вторая революция – при революционном переходе с ЕС ЭВМ на ПК и локальные сети»,  но об этом – в другой раз.

А что писали другие источники и намного раньше

Термин «автоматизированная система управления» — АСУ — прочно вошел в обиход как раз в середине 70-х, многие слова прижились, став привычными. «Значительно хуже прижились и не получили распространения сами АСУ, хотя практически каждое предприятие так или иначе подверглось автоматизации, а программисты среднего и старшего поколения, чье становление прошло в годы больших машин, буквально вскормлены на идеях АСУ».

В истории становления и развития Программного обеспечения (ПО) АСУ  выделяют три важных этапа. На первом этапе (60-е годы) элементы ПО АСУ  разрабатывались для каждой конкретной АСУ строго индивидуально. Использовать готовые программы из библиотеки практически не удавалось, поэтому ПО каждой АСУ требовало 3…5 лет работы квалифицированных специалистов, и о широком внедрении АСУ не могло быть и речи.

В 70-х годах, когда произошел всплеск интереса к созданию АСУ, возникло  противоречие между потребностью в АСУ и возможностью их разработки и  внедрения, сформировался второй этап становления ПО АСУ, на основе  концепции типизации методов, моделей, алгоритмов и программ ПО АСУ. Однако практическая реализация такой концепции оказалась возможной далеко не сразу.

70-е годы (вторая половина) — время безраздельного господства машин из клона IBM 360/370.

Компьютеры по-прежнему были безумно дороги, но их мощность и надежность резко возросли. Начали создаваться крупные информационные системы для промышленных и торговых предприятий, банков, социальных учреждений. Пользователи перестали бегать с колодами перфокарт — появились сначала магнитные ленты, потом магнитные диски, а уж потом на рабочих местах возникли дисплеи, подключенные к центральной ЭВМ, расположенной в вычислительном центре фирмы.

«ЕС ЭВМ и СМ ЭВМ не были полными копиями западных машин. Они были разработаны так, чтобы отечественные заводы, чья технология была хуже зарубежной, могли наладить крупносерийный выпуск. А программная совместимость на уровне аппаратной архитектуры семейств ЭВМ третьего поколения была основным решением, принятым во всем мире. Цель обеспечить программную совместимость ЕС ЭВМ и СМ ЭВМ с наиболее распространенными на Западе компьютерами, архитектуры которых стали стандартами де-факто, была вполне оправданной. Совместимость обеспечивала возможности сотрудничества организаций, занимавшихся применением ЭВМ, обмен прикладным и системным программным обеспечением. Конечно, при этом не было «расчета на то, что можно будет наворовать много матобеспечения», а в страну хлынет поток этого обеспечения».

Задача разработки семейства моделей, программно совместимых между собой и с машинами семейств 360 и 370 фирмы IBM, была в инженерном отношении даже более сложной, чем разработка семейства с собственной оригинальной архитектурой. Нужно было не просто «угадать»,  как сделаны западные машины, а обеспечить совместимость с ними, реализуя эту архитектуру на другой элементной базе и конструктивах, которые отвечали бы технологии отечественных заводов да еще с учетом требований военных стандартов СССР. Будь машины ЕС ЭВМ копиями машин фирмы IBM, их нельзя было бы производить на наших заводах, а Министерство обороны СССР не могло бы их применять.

Благодаря программной совместимости с моделями семейств 360 и 370 фирмы IBM, на ЕС ЭВМ выполнялись зарубежные пакеты программ IMS, IDMS, ADABAS. Были выпущены их отечественные аналоги «ОКА» и «КАМА» — передовые по тем временам СУБД с телекоммуникационным доступом. На ЕС ЭВМ функционировало в большинстве применений ПО, разработанное совместными усилиями многих организаций, создававших АСУ, а также западное ПО, причем  не «ворованное», а купленное (только в обход ограничений КОКОМ). Так что страна выиграла от программной совместимости ЭВМ, и это был не провал, а успех принятой технической политики. Это был действительно грандиозный научно-технический проект, в результате которого вычислительная индустрия перешла на новый качественный и количественный уровень, фактически от опытного к промышленному производству».

Для организации вычислительного процесса на этих ЭВМ понадобились операционные системы нового типа, позволяющие организовать диалог большого числа пользователей в режиме разделения времени. Мало того, создание крупных информационных систем поставило перед разработчиками общего ПО  проблему хранения больших массивов данных и организации их обработки множеством  независимых программ.

Возникла концепция систем управления базами данных (СУБД).

Разработка эффективных СУБД оказалась задачей не менее трудоемкой, чем проектирование ОС, первая промышленная СУБД IMS для IBM 360/370 была создана корпорацией IBM в 1969-1970.

Использование СУБД произвело настоящую революцию в индустрии обработки данных, стало одним из основополагающих элементов новых информационных технологий. Многие заказные кустарные программы, осуществляющие стандартные операции над данными, оказались ненужными, они были вытеснены надежными промышленными продуктами.Это — характерный пример того, как специальное ПО становится общим.

История баз данных фактически началась с появлением магнитных дисков. Эти устройства внешней памяти обладали существенно большей емкостью, чем предыдущее поколение носителей — магнитная лента и магнитные барабаны, а также обеспечивали во много раз большую скорость доступа к данным в режиме произвольной выборки. Базы данных на больших ЭВМ и первые СУБД пришли на смену файлам  и файловым системам

В 1968 году была введена в эксплуатацию первая промышленная СУБД – система IMS фирмы IBM, В 1975 году появился первый стандарт СУБД, разработанный ассоциацией по языкам систем обработки данных – Conference of Data System Language (CODASYL). Этот стандарт определил ряд фундаментальных понятий в теории систем баз данных, которые до сих пор являются основополагающими для сетевой модели данных, В 1981 году Э.Ф.Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры.

Идея типового проектирования

получила пусть не очень широкую и удачную, но все же реализацию  лишь на третьем этапе (конец 70-х и 80-е годы) становления и развития АСУ на основе пакетов прикладных программ (ППП) как наборов программно — алгоритмических средств, совокупность которых обеспечивает решение одной или нескольких близких задач АСУ.

«Массовое поступление однотипных ЭВМ третьего поколения в сферу обработки экономической информации поставило по-новому проблему проектирования автоматизированных систем, требовало «индустриальных» методов решения этой проблемы. Современное состояние теории систем электронной обработки информации, советский и зарубежный опыт внедрения таких систем убедительно свидетельствуют о возможности индустриального подхода к проектированию автоматизированных систем». [3]

Основная  роль во внедрении индустриальных методов проектирования отводилась ППП общего назначения, которые являлись  основной формой организации программного обеспечения. В общем случае ППП — это набор программных средств, позволяющий решать определенный класс задач или выполнять определенную совокупность функций.  В виде ППП оформлялись  как программные средства, расширяющие возможности операционной системы и общей системы программирования (системы управления базами данных (СУБД), автоматизации документирования, информационно-вычислительные, обработки данных), так и все типовые классы задач АСУ. ППП выступали важнейшими компонентами программного обеспечения автоматизированных систем. На их основе поддерживается  работа прикладных задач (программ) с обрабатываемыми данными.

Об этом убедительно говорит опыт применения таких пакетов, как «Банк», «Ока», «СИОД», «Набоб» и др. ППП СУБД функционируют с такой же нагрузкой, как и программы операционной системы, и от организации (структурирования) базы данных прямо зависит непроизводительно затрачиваемое машинное время.

К сожалению, набор ППП СУБД, предоставляемый в распоряжение проектировщиков АСУ, … недостаточно полон (в … пакетах недостает средств загрузки базы данных, передачи данных по каналам связи, моделирования базы данных для выбора наилучшей по отношению к конкретным задачам структуры базы данных и т. п.), слабо освещена методика применения таких пакетов».

«Первый опыт работы с системами управления базами данных в автоматизированных информационных системах показал, что для внедрения современной информационной технологии необходимо значительное расширение программного окружения СУБД. Это связано с тем, что спецификация задач и запросов на обработку данных при создании информационных систем, ориентированных на массовых пользователей различной профессиональной ориентации, не могут быть выполнены с применением только алгоритмических языков. Большинство первоначально разработанных СУБД располагало средствами, предназначенными только для пользователей-программистов. Пакетный режим работы с базами данных, ограниченный набор языковых средств, отсутствие словарей-справочников данных и многих сервисных средств — вес это существенно ограничивало возможности применения СУБД в информационных системах. Если к этому добавить ограниченные объемы запоминающих устройств прямого доступа, отсутствие методических материалов по проектированию баз данных, не достаточную надежность вычислительных установок, то станут понятными трудности внедрения технологии работы с базами данных на начальном этапе».[5]

В качестве основных достижений ПO АСУ разрабатывавшегося  и внедрявшегося  на основе ППП, назывались:

• ППП открыты для добавления в них новых модулей, что обеспечивает возможность непрерывного развития ПO;
• ППП позволяют относительно легко и быстро с привлечением специалистов средней квалификации решать наиболее трудоемкую часть разработки и внедрения АСУ — создание программного обеспечения АСУ.

Проблемы и недостатки – их признавали

В это время (на рубеже 80-х годов) уже большое количество предприятий, организаций различных министерств и ведомств прошло через трудности внедрения систем и некоторые даже в повседневной работе начали ощущать преимущества автоматизированного управления, но в целом – первая эйфория массовой автоматизации начала спадать, формулируют  недостатки действующих систем:

• нарушения системного подхода в определении состава автоматизируемых функций управления, заключающиеся, с одной стороны, в неполноте охвата взаимоувязанных функций управления,  неоправданном предпочтении одних функций управления другим, а с другой стороны, в попытке реализовать глобальную систему управления крупным объектом без учета таких факторов, как подготовленность объекта и возможности существующей техники;
•  неполное соответствие алгоритмов управления, заложенных в АСУ, характеристикам реального объекта управления;
•  наличие изменений в деятельности объекта управления, не учитываемых системой;
•  неполная стыковка реализации различных функций управления в системе;
• отдельные неудачные алгоритмические решения;
• слабая надежность функционирования АСУ, вызванная как не достаточной надежностью техники, так и не проработанной в достаточной степени технологией эксплуатации системы.

Кроме того отмечаются: неподготовленность  объектов управления, сложность освоения системных решений, ограниченность технических средств, неукомплектованность службы АСУ, организационные и структурные перестройки объекта управления, нарушение технологии эксплуатации АСУ персоналом объекта управления, функционирование систем  не в полном объеме.

За каждой из этих сглаженных формулировок стоит разочарование.

«Большой вред как в нашей стране, так и за рубежом принесла тенденция к созданию глобальных систем, охватывающих максимальное количество функций управления на достаточно крупных промышленных предприятиях, в условиях применения совершенно не подходящей для этой цели вычислительной техники второго поколения и в условиях чрезвычайно слабой подготовленности предприятий.
«В настоящее время для большинства промышленных предприятий на передний план выходят функции управления основным производством и его материально-техническим обеспечением. Для некоторых типов предприятий существенными будут функции управления технической подготовкой производства, управления сбытом и др. Однако достаточно очевидно, что при использовании ныне выпускаемых ЭВМ третьего поколения невозможно построение комплексных систем, охватывающих большинство функций управления не только на крупном, но даже и на среднем предприятии.» [3]

Движение к стандартизации

В качестве одной из мер, направленных на обеспечение идеи «типизации» было создание общеотраслевых руководящих материалов.  При подготовке этих материалов были существенно переработаны действовавшие ранее временные методики по разработке и внедрению АСУ в машиностроении и приборостроении и утверждены новые общеотраслевые руководящие ма­териалы. Одновременно была начата подготовка новых методических до­кументов, учитывающих опыт внедрения АСУ в 1971 — 1975 гг. и задачи внедрения ЭВМ третьего поколения. Установлен состав, содержание и по­рядок выполнения работ по созданию ОАСУ и АСУП. (эта осторожная формулировка была сделана тогда, когда никаких ГОСТов еще не было — ГОСТ 19. — Единая система программной документации – были разработаны в 1977-1979гг)

А в это время -1976-1978гг – в качестве одного из основных направлений в области разработки и внедрения АСУ предлагалось создание типовых проектов подсистем и типовой проектной доку­ментации (техническое задание, технический и рабочий проекты).

Специально организованные комиссии ото­брали наиболее приемлемые решения различных подсистем ОАСУ и АСУП в министерствах и рекомендовали их для повсеместного применения. Ут­верждены, в частности, типовые проектные решения подсистем технико-экономического планирования, перспективного планирования, бухгалтер­ского учета, материально-технического снабжения и других подсистем АСУП. Использование этих типовых проектных решений позволяет вдвое сократить сроки и стоимость разработки и внедрения ОАСУ и АСУП.

Если к 1970 году в стране действовало около 400 АСУП, то через пять лет их число достигло 3 тыс., не считая секретных, поэтому ко второй половине 70-х   «полезность АСУ стала общепризнанным фактом; АСУ буквально «взломали» сложившуюся архитектуру административно-командной системы, дав толчок к развитию электроники, систем связи, созданию отраслевых НИИ, КБ, главков и министерств (Министерство промышленности средств связи и главные управления по вычислительной технике в каждом из министерств), института Главных конструкторови т.д.; и очень важное: «обнаружилась необходимость незамедлительного проведения на государственном уровне стандартизации и унификации в сфере разработки и внедрения АСУ для их перевода на индустриальные рельсы».

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

И вот что еще очень важно:

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

Правда писали и такое ([2], 1977г.) «Наиболее трудным вопросом использования ЭВМ в планировании и управлении является в настоящее время общение человека с машиной. Электронные машины управляются операторами с помощью дорогостоящих операционных программ…, сложных по содержанию и трудоемких по составлению. Однако уже сейчас очевидно, что в ближайшие десять лет будут созданы ЭВМ, способные распознавать человеческую речь.»

И в заключении

эмоциональные воспоминания некоторых программистов:

«Считалось, что в СССР прекрасные программисты? Да, и заслуженно, вот только причины столь потрясающих успехов и эффективность их работы… Используя каждый бит оперативной памчти, мы умудрялись строить сложнейшие алгоритмы в условиях весьма ограниченных ресурсов. А почему, собственно, ограниченных? Да потому, что труд наш был бесплатным и потратить лишний месяц работы программистского коллектива было проще, чем приобрести дополнительный мегабайт памяти. Да и дело приходилось иметь с устаревшими технологиями и гордость от достижений сменялась злостью на невозможнотсь работы с передовыми СУБД и пакетами прикладных программ. Даже ваш покорный слуга, бывший в те времена отнюдь не самым плохим программистом в построении систем управления производством, отметился в деле совершенствования алгоритмов. Тогда удалось ускорить решение одной из плавных проблем таких систем — разузлование изделий — на порядок. Только вот использовалась в системе передовая в Союзе СУБД СИОД, украденная у IBM через Болгарию и устаревшая уже на момент украдывания» и еще на эту примерно тему: «Мы свою программу разузлования получили из ОФАП, но она работала гораздо больше времени, чем могла протянуть без зависаний ЕС-1022. Мы тогда написали свой комплекс, который, кажется, до сих пор работает»

Литература:

1. Келехсаев А. А., Беляев А. П. Системы интеграции и обработки данных СИОД 1, СИОД 2. М. Статистика. 1977г. 208с
2.  АЛГОРИТМЫ И ОРГАНИЗАЦИЯ РЕШЕНИЯ ЭКОНОМИЧЕСКИХ ЗАДАЧ
   Сборник статей I под редакцией \\В. М. Савинкова, МОСКВА «СТАТИСТИКА» Вып 10 1977
3. Вып 11 Год: 1978
4. Вып 12 Год: 1979
5. Системы управления базами данных для ЕС ЭВМ Под общ. ред. В. М. Савинкова.—М.: Финансы и статистика, 1984.— 224 с.,
6.  АСУ  как много в этом слове… Евгений Щербатюк  Компьютерная газета 1997 22
7.  От атома до космоса 50 лет АСУ    Владимир Исаев
8.  Кого и зачем вводят в заблуждение Н. Евгений Филинов 2000г
9.   АСУ в СССР: взгляд из 90-х в 60-е. Спартак Никановров Экономическая газета, 1999, № 39-40

Entry filed under: Обзоры.