Новая технология разработки сложных программных систем.
31 марта 2009 в 01:26

Новая технология разработки сложных программных систем.

Все началось в начале 80-х годов, когда автору довелось участвовать в разработке первой глубоко интегрированной САПР БИС (НИИМЭ и з-д «Микрон»). В настоящее время работа в теоретической своей части проверяется на макете инструментальных средств. Далее предлагаемая технология не может развиваться в узких рамках группы энтузиастов. С удивлением мы обнаружили, что такого рода работы в стране не ведутся и не поддерживаются в настоящее время. Нет для них национального рынка!
Что надо:
Эффект от такого рода разработок косвенный, т.е. требуется создание пула фирм и организаций (подобно OMG или ICC и проч.), которые на основе данной технологии смогли бы:

  1. Поставить единую технологию для создания сверхсложных программмных систем в области прикладного программного обеспечения.
  2. В сжатые сроки относительно небольшими группами профессионалов добиться интегрированного решения в указанных областях.
  3. Добиться высокого уровня глубокой интеграции во всех указанных прикладных областях, что обеспечит создание необходимой информационной инфраструктуры в стратегическом масштабе.
    Что есть:
  4. Получен и проверен ряд принципиальных теоретических результатов организации данных и вычислительных процессов.
  5. Они прекрасно совместимы с объектной парадигмой, т.е. развивают методы и подходы UML & RUP.
  6. Достигнута возможность автоматической генерации кода с высоким уровнем его завершения за счет развития уровня спецификаций.
  7. Расширена область «обозримости» кода за счет объединения представления данных и операций с ними в семантические блоки (кластеры).
  8. Создается макет инструментальных средств на языке С#.
  9. Прорабатываются проблемные предметные области задач управления проектами, финансового и экономического анализа (т.е. базовая основа BI).
  10. Ведутся исследования и проработки в области аналитики социальных информационных систем в масштабе города.

Что может дать внедрение:

  1. Накопление коллективного опыта профессиональных групп.
  2. Сокращение сроков и затрат на порядок и более.
  3. Облегчается сопровождение и развитие систем по сравнению с существующими технологиями.
  4. Создание новых интегрированных средств ИКТ на порядок большего масштаба и сложности.
  5. Сделать серьезный шаг к достижению глубокой интеграции систем (т.е. проблемы синтеза наук).
488
Комментарии (32)
  • 31 марта 2009 в 08:40 • #
    Андрей Архангельский

    Пока общие рекламные слова. А конкретно?
    Интересует пункты 6 и 7 - где можно почитать, что конкретно сделано, какие результаты исследований?

    Мои исследования показали, что проектированием сейчас не занимаются, основной упор на кодирование, рисование интерфейсов и высасывание денег у лохов.

  • 31 марта 2009 в 09:36 • #
    Денис Шаповаленко

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

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

    Программное обеспечение в некоторых работах сравнивают с постройкой корабля или здания. В примере со зданием, проектирование сравнивается с закладкой фундамента, что с одной стороны верно, а с другой закладывает ряд существенных ограничений на гибкость разработки.

    С одной стороны, если вы разрабатываете инструмент типа Автокада, то там проектирование вполне уместно - основные процессы и действия пользователей не меняются многие годы: черти себе и проектируй.

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

    В контексте выше сказнного, можно прийти к заключению, что пункты 6 и 7 либо не будут иметь конечного срока завершения, либо на момент завершения кодирования все исследования и проработки будут устаревшими и не будут соответствовать реальным бизнес-процессам

    Все это ИМХО на личном опыте разработки и внерения среднего размера систем (до 50 конечных пользователей)

  • 31 марта 2009 в 09:46 • #
    Андрей Архангельский

    Таким образом, Вы утверждаете, что "раз бизнес-процессы будут меняться в течении жизненного цикла, то и проектировать систему не нужно". Именно поэтому все ERP системы походят на "тришкин кафтан" - здесь заплатка, там кармашек и прочее.
    По крайней мере я не нашел ни одной системы ERP (и не только) где бы применялось реальное проектирование.

  • 31 марта 2009 в 10:04 • #
    Денис Шаповаленко

    Вы это определяете по конечному результату?
    Я уверен, что в начале было реальное проектирование, потом начали кодирование, а потом клиент изменил свои требования, в результате начался "тришкин кафтан". Проблемы современных крупных систем именно в попытке применить системы разработки 20-ти летней давности или технологии управления проектами в строительстве в той области, где изменения в процессах и принципах происходит постоянно.

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

    Проектирование крайне необходимо, но не в том виде, в котором большинство его воспринимает. Проектирование крупных информационных систем не имеет ничего общего с проектированием мостов и космических кораблей.

  • 31 марта 2009 в 11:06 • #
    Михаил Сидоров

    Ну вот стандартный спор о проектировании… Люди которые не умеют проектировать, разумеется, при всем своем желании, в процессе выполнения проекта ERP системы получат лоскуты и заплатки. А те кто умеет (видел такого человека раз в жизни), заложат гибкость там, где она нужна (где требования заказчика могут измениться), а не там, где ему захочется, тем самым избавившись от заплаток. Дело только в профессиональном уровне и личных качествах людей занимающихся проектированием.

  • 31 марта 2009 в 11:07 • #
    Михаил Сидоров

    Ну вот стандартный спор о проектировании… Люди которые не умеют проектировать, разумеется, при всем своем желании, в процессе выполнения проекта ERP системы получат лоскуты и заплатки. А те кто умеет (видел такого человека раз в жизни), заложат гибкость там, где она нужна (где требования заказчика могут измениться), а не там, где ему захочется, тем самым избавившись от заплаток. Дело только в профессиональном уровне и личных качествах людей занимающихся проектированием.

  • 31 марта 2009 в 17:22 • #
    Юрий Горбунов

    Дорогой Михаил!
    Не хочется расстраивать Вас, но начало было о новой технологии разработки программного обеспечения. В ней не только проектирование, но и этап системного анализа системы (что еще круче).
    Интересно, что в процессе созданния нашей технологии мы очень тщательно отнеслись к анализу RUP. Снимаем шляпу перед ее создателями. Но они показали как надо работать, а нам удалось доказать почему именно так и в каком окружении. Неужели Вам не интерсно понять эту логику?

  • 31 марта 2009 в 14:53 • #
    Сергей Агеев

    Согласен с большинством тезисов, коллега!

    Скорость изменения бизнес-процессов сравнима со скоростью разработки ERP-like систем. Система строится два-три года, за это время бизнес процесс может измениться до неузнаваемости.

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

    Конечно, все большие системы строятся на принципах параметризации, гибкости, функциональной избыточности и т.д. Это совсем не тоже самое, что мост (пусть даже очень сложный) построить, там же ланшафт во время проектирования не меняется.

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

  • 31 марта 2009 в 17:08 • #
    Юрий Горбунов

    Дорогой Сергей!

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

  • 1 апреля 2009 в 01:10 • #
    Юрий Горбунов

    Господа, я не Михаил Прохоров! Это глюки среды!
    Всегда Ваш, Юрий Горбунов.

  • 2 апреля 2009 в 19:00 • #
    Андрей Архангельский

    А представляете какая очередная "волшебная палочка" получится, если удасться из лохов денег высосать?
    Для того чтобы о чем-то говорить нужны подробности, хоть какая-то конкретика.

  • 3 апреля 2009 в 01:15 • #
    Юрий Горбунов

    Дорогой Андрей!

    Вы окончили МИЭТ, а я в нем преподпавал. И дело не в "из лохов денег...", мне кажется, что ставки значительно выше. Что Вам мешает задавать вопросы? Моя задача - попытаться собрать сообщество профессионалов, готовых к совместной работе. А это означает диалог, а не "гипотезы о мотивации".
    С нетерпением жду ответа, чтобы понять Ваш профессиональный уровень и область интересов. Если имеются, интересно посмотреть Ваши научные публикации.

    Юрий Горбунов.

  • 31 марта 2009 в 16:53 • #
    Юрий Горбунов

    Проектирование программных систем отличается от проектирования мостов, но и имеет с ним много общего. Не случайно паттерны пришли в программирование из архитектуры. Но уровень рефлексии в програмировании, естественно, выше. Более сложно ответить на вопрос:"Что я думаю о том, как я думаю?". Если строго следовать этому правилу при программировании, то теряется темп, напор и уверенность в правильности выбранного решения. Но возрастает понимание, чем собственно мы занимаемся при программировании - исправляем свои ошибки при попытках отражения реального мира в формальной форме.
    Если есть глубокое понимание этого в некоторой области - то можно построить формальную теорию "оптимального поведения при программировании". А еще лучше - сделать автомат, управляемый спецификацией для генерации кода...
    Вот отсюда и до новой технологии программирования недалеко.

  • 31 марта 2009 в 17:33 • #
    Сергей Агеев

    Автоматы управляемые спецификацией мы для себя разработали и сейчас используем, правда в узкой области - для "сборки/разборки" XML файлов (с целью их выгрузки/загрузки" в БД).

  • 1 апреля 2009 в 01:15 • #
    Юрий Горбунов

    Это правильно, но что мешает идти дальше в этом направлении?

    Простите, меня сделали г-ном Прохоровым. Это глюк системы.
    Я простой профессионал, Горбунов Юрий, не имею отношения к ОНЭКСИМ...
    Всегда Ваш, Юрий Горбунов.

  • 31 марта 2009 в 17:41 • #
    Юрий Горбунов

    Дорогой Андрей!
    Все западные компании, пришедшие в Россию, имеют свои собственные технологии создания и настройки ERP систем. Вы их знаете - SAP, Sputnik, Colombus, Oracle, IBM, Tivolli и т.д. Из отечественных это IBS, Lixsoft, РБКсофт и проч. Молчу про навязшие в зубах Axapty и Navision...
    Но нашей индустрии бы до уровня MS Project дорасти бы...

    Надо понимать разницу в обладании и владении технологией. Так одна из наших фирм не могла закончить в срок до 70% заказов, пока реально не поставила систему управления качеством. "Тришкин кафтан" есть расплата за концептуальные ошибки руководства (т.е. игнорирование этапов системного анализа и проектирования из экономии) младшим исполнительским составом. Вам не очень повезло.

  • 31 марта 2009 в 16:07 • #
    Юрий Горбунов

    Дорогой Денис!
    Создание ERP важная, но далеко не самая главная задача. Рассмотрим проблему с которой все началось: создание интегрированной САПР СБИС, например, проектирование процессора на котором работает Ваш компьютер. Мы имеем четыре категории моделей: топологическую, схемотехническую, функционально-логическую и физико-приборную. Они теснейшим образом связаны между собой и формируют основные четыре категории моделей: во-времени (дискретном-непрерывном) и пространстве (дискретном-непрерывном). Краткий перечень видов задач и алгоритмов - тома для каждой категории. Даже внутри их возникли деревья специализации инженеров. Задача проста - интегрировать данные в общей системе и достичь взаимопонимания специалистов.
    В свое время был создан консорциум, в который вощли ведущие фирмы - производители БИС (больших интегральных схем). В нем рассматривалась общая задача проектирования (с аспектами ERP и управления качеством и проч. - 9 секций). Выделилось два направления: инженерная интеграция (всего) и глубокая интеграция. Победила инженерная, консорциум распался...
    Но это была пирова победа. Возникло несколько "монстров", которые за бешенные деньги стали предлагать средства САПР БИС, собранные в комплексы на основе сложных проектных систем. Считанные единицы специалистов могут полноценно работать и развивать их. Основная масса людей не понимает, что и как, и почему, и зачем... Но задача "виртуального предприятия" обслуживающего чипами ИКТ была решена.
    Вы совершенно верно описываете ситуацию в своем сегменте специализации в области ERP. Я узнаю до боли знакомые о до сих пор не решенные проблемы, которые высасывают из Вас время и силы. В электронике сложилась аналогичная, кризисная ситуация в связи с переходом в диапазон 45нм. Здесь традиционные модели не работают! Меняется все - квантовая механика есть особая область, где учет взаимовлияний процессов особенно причудлив. США закрыли области этих исследований, как имеющие стратегический характер. Все, что раньше казалось естественным - оказывается совершенно иным...
    А иначе и быть не может. Развитие всегда меняет критерии хорошего и плохого.
    А если экстенсивные методы исчерпали себя, надо искать интенсивные...
    В нашем случае - новые теории и методы мышления. Это сложно, но возможно. В основе предлагаемой технологии содержится новый взгляд на старые задачи. Это прежде всего технология согласованного творческого мышления с фиксаций не фактов, а приемов мышления в единой унифицированной среде данных.

  • 31 марта 2009 в 14:08 • #
    Юрий Горбунов

    Вы правы, описание поверхностно. Но это не реклама, а сжатая форма описания.

    Это страшная беда России - отсутствие серьезных инфраструктурных разработок в области создания програмных комплексов. Ирония истории в том, что на Западе их создают наши же коллеги (не знаю, как у Вас, а мои - на 95% давно уже там...).

    Возможно, если нет в России рынка на эти решения, и мне следует обратиться к мировым лидерам в области программных технологий?

  • 31 марта 2009 в 15:22 • #
    Сергей Агеев

    Я из Украины, но как мне кажется, для ответа на вопрос "почему это никому не нужно тут в (России / Украине)" аналогичен:

    1. Крупные проекты у нас заказывает в основном государство. Государственный чиновник по понятным причинам чаще всего заинтересован в больших бюджетах (начиная от того, что "больше тратишь - больше дадут на следующий год", заканчивая тем "больше сумма - больше доля").
    2. Крупные разработчики программного обеспечения заинтересованы в больших бюджетах, поэтому как при фиксированном проценте прибыльности, им проще зарабатывать на большем обороте (если рынок позволяет, а госсектор это позволяет), чем на экономии издержек.

    Так что большие бюджеты выгодны (на данном этапе) как бизнесу, так и государственным чиновникам. Поэтому никто особенно не хочет ничего менять.

    Вот и получается, что оптимизация расходов на информатизацию государству вобщем-то нужна, но конкретным отдельным чиновникам - нет. Поэтому и зарываются колоссальные деньги "в землю". По моим оценкам, КПД денег потраченных на информацизацию госсектора 20%.

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

    Зарубежом интеграция между приложениями, открытые интерфейсы и спецификации практически обязательное требование крупного заказчика, у нас пока в основном требуют "наполнения функционалом", интеграция - вторична.

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

    Зарубежных заказчиков все это заинтересовать может, вот только достучаться до них - проблема. Бюрократия (например) в IBM вполне сравнима с государственной.

    PS: Многое из того что говорю - сам испытал на своей шкуре, когда пытался продвинуть в госструктуры несколько толковых идей в сфере управления проектами для повышения эффективности информацизации.

  • 31 марта 2009 в 16:36 • #
    Юрий Горбунов

    Дорогой Сергей!

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

    Особенно эффективной оказалась идея интеграции модели данных и процессов их использоания в ПП. На ее основе построена объектно-ориентиированная бинарная модель данных (БМД). Завершает теоретический костяк технологии общая теория данных, в рамках которой показано концептуальное единство реляционой и бинарной моделей данных.

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

  • 31 марта 2009 в 18:55 • #
    Андрей Архангельский

    Так а где поконкретнее взять?

  • 31 марта 2009 в 15:38 • #
    Stanislav Tambovski

    Есть такая замечательная книга - "Психбольница в руках пациентов" Алана Купера. Есть на www.books.ru. Полное название "Психбольница в руках пациентов или Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие":
    цена : 250,00 руб
    доступна электронная версия этой книги (цена: 150,00 руб)
    Очень рекомендую. Лейтмотив - как раз проектирование. Взаимодействия.

    -stass

  • 31 марта 2009 в 17:13 • #
    Юрий Горбунов

    Дорогой Станислав!

    Спасибо за внимание к "городским сумашедшим"! Объязательно прочту. Давно знаю и читаю книги А. Купера. Благодарю за шикарную ассоциацию, действительно в России проектирование есть занятие для сумашедших...
    Что же тут скажешь о новой технологии програмирования...
    Один мой знакомый вспомнил Салтыкова - Щедрина, а точнее его героев с проектом "О введении единомыслия в России". Очень много общего...

  • 31 марта 2009 в 18:39 • #
    Stanislav Tambovski

    :-)

  • 1 апреля 2009 в 01:08 • #
    Юрий Горбунов

    Станислав, меня неожидано сделали г-ном Прохоровым.
    Я не виноват, это глюки среды.
    Ваш Юрий Горбунов.

  • 1 апреля 2009 в 10:10 • #
    Михаил Сидоров

    Ну хорошо… Ваша система, это смесь аналитики + какая то теоретическая возможность проектирования. Где можно взять версию чтобы, наконец - то ознакомиться с ней? Где взять мануалы, чтобы не тупить, вникая в нюансы? Надеюсь, вы не хотите брать деньги за все вышеперечисленное?

  • 1 апреля 2009 в 19:46 • #
    Юрий Горбунов

    Дорогой Михаил!
    В настоящее время технология, как и всякое сложное изделие, проверяется. С этой целью изготавливается макет и техническая документация. Я не сказал бы что это произойдет быстро, но к октябрю этого года протестированный варинт с описаниями будет готов. Мне кажется, что важно в этой точке зафиксировать состояние дел для успешной деятельности в будущем.
    С другой стороны, новая технология программирования (НТП) уже может и должна продвигаться далее параллельно. Для этого необходима "крыша" и круг заинтересованных лиц. Наконец, любая идея что-нибудь стоит, если ее есть кому защищать. Я представляю группу лиц, которые вкладывают в разработку НТП свои силы и время. Хотите ли Вы к ней присоединиться? И на каких условиях?
    К сожалению, нельзя основную часть НТП считать объектом патентной защиты нельзя (математические теории, алгоритмы и т.д.), а ее программную инструментальную среду защищать можно. Но это преждевременные вопросы.
    Жду от Вас более четкого изложения позиции. Отвечу на любые Ваши вопросы.
    Искренне Ваш, Юрий Горбунов.

  • 2 апреля 2009 в 12:22 • #
    Михаил Сидоров

    Я, занимаюсь достаточно большим спектром проектов, в том числе и разработкой клиент - серверных приложений на трехзвенной архитектуре. Я бы с удовольствием попробовал использовать предлагаемый вами инструментарий и может быть даже, поучаствовал в его доработке.
    Пока что я не понимаю, что представляет собой предлагаемая вами НТП, так что об условиях говорить рано.

  • 3 апреля 2009 в 01:04 • #
    Юрий Горбунов

    Дорогой Михаил!

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

  • 2 апреля 2009 в 12:22 • #
    Михаил Сидоров

    Я, занимаюсь достаточно большим спектром проектов, в том числе и разработкой клиент - серверных приложений на трехзвенной архитектуре. Я бы с удовольствием попробовал использовать предлагаемый вами инструментарий и может быть даже, поучаствовал в его доработке.
    Пока что я не понимаю, что представляет собой предлагаемая вами НТП, так что об условиях говорить рано.

  • Желаете ознакомиться с остальными комментариями или оставить свой? в сеть, чтобы получить полный доступ к функционалу Профессионалов.ru! Еще не участник сети?