Top.Mail.Ru
Новая технология разработки сложных программных систем.
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. Сделать серьезный шаг к достижению глубокой интеграции систем (т.е. проблемы синтеза наук).
682
Комментарии (32)
  • 31 марта 2009 в 08:40 • #
    Андрей Архангельский

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

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

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

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

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

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

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

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

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

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

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

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

  • Цена: 500 000 тңг.

  • 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 систем. Система строится два-три года, за это время бизнес процесс может измениться до неузнаваемости.

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

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

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

  • Программа для торговли

    Цена: 2 500 руб.

  • 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 • #
    Михаил Сидоров

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


Выберите из списка
2021
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
1970