Действительно ли непрограммная разработка программного обеспечения выполнима? [закрытый]

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

Фон

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

Проблема

Система использует очень неловкую модель обратной передачи, чтобы выполнить сторону сервера логических операций и возвратить новые формы/результаты. Это медленно, и подвержено отказу. Простые вещи, как создание форм HTML с помощью существующих инструментов являются намного более трудными, чем это должно быть. Когда требование более интерактивного, и производительного опыта растет, разработчики программного обеспечения находят все больше, что они должны обойти экспертную систему / визуальные инструменты, используемые авторами контента, и писать новые компоненты вручную в JavaScript. Авторы контента все больше чувствуют, что их руки связываются, поскольку они теперь не могут внести новые компоненты.

Подход дизайна: традиционный/Типичный

Я защищал для полного отказа от предыдущей модели и принятия типичного процесса разработки программного обеспечения. Как отмечалось ранее, проект естественно развился к этому, поскольку непрограммные инструменты разработки стали неспособными к удовлетворению потребностей бизнеса.

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

Подход дизайна: непрограммный

Мой коллега, который я уважаю много и подозреваемого, намного более хорошо осведомлен, чем я, чувства, что существующий процесс прекрасен и что мы просто должны создать лучшие инструменты. Я не могу не чувствовать однако, что существует что-то существенно испорченное с этим подходом. Я должен все же найти один экземпляр, или исторический или современный, где эта модель разработки программного обеспечения была успешна. КОБОЛ был разработан с философией, разрешают деловым людям / специалистов по проблемной области для записи приложений без потребности в программисте, и по моему мнению все это сделало был, создают новый вид программиста - программист КОБОЛа. Если бы было возможно разработать эффективные системы, разрешающие непрограммистам создавать нетривиальные приложения, то конечно, спрос на программистов был бы намного ниже? Единственные платформы, что я знаю об этом примерно, соответствуют, эта модель Умные Формы SAP и Dynamix Microsoft AX - обоими из которых являются очень зависящие от домена ERP-системы.

DSLs, обрабатывая языки по шаблону

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

Я также рассмотрел создание пользовательского IDE на основе Visual Studio или Сетевых Бобов с графическими инструментами стиля / инструментами стиля панели инструментов.

Мысли?

Действительно ли непрограммная разработка является глупым поручением? Это будет всегда приводить к чему-то неудовлетворительные, требующие руки на разработку от программиста?

Большое спасибо, если бы Вы не торопились для чтения этого, и я, конечно, ценил бы любую обратную связь.

54
задан 2 revs 11 July 2010 в 13:25
поделиться

15 ответов

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

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

Либо реорганизуйте систему и процессы, чтобы носители знаний действительно входили в знания - ничего больше; или обучить создателей контента выполнять необходимую разработку с помощью существующих инструментов или могут быть DSL.

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

0
ответ дан 7 November 2019 в 08:10
поделиться

Вы говорите:

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

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

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

В результате, существует определенное сообщество "научного программирования", которое в основном состоит из экспертов в данной области, имеющих относительно небольшую формальную подготовку, опыт или даже интерес к программной инженерии. Этим людям больше по душе такие языки/платформы, как Matlab, R и даже Visual Basic (поскольку они могут использовать его для написания сценариев таких приложений, как Excel и ESRI ArcMap). В последнее время я вижу, что Python также набирает обороты в этой области, в основном, я думаю, потому что его относительно легко изучить.

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

Я бы начал с обсуждения с создателями контента некоторых идей о том, как они хотели бы выразить свои решения и выбор. Я думаю, что они будут рады написать "код" (даже если вам не придется называть его кодом), чтобы описать то, что они хотят. Дайте им "отладчик" (инструмент для интерактивного изучения последствий изменений их "кода") и какое-нибудь хорошее приложение для поддержки "IDE", и я думаю, что у вас будет вполне работоспособное решение.

12
ответ дан 7 November 2019 в 08:10
поделиться

Это довольно философская тема, и на нее трудно ответить в каждом конкретном случае, но в целом...

Является ли непрограммная разработка глупой затеей?

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

Редактировать: Sharepoint, InfoPath, некоторые материалы SAP - это те примеры, о которых я говорю. Как я уже сказал выше, "очень узкая область применения". Можно позволить непрограммистам создавать рабочие процессы, сложные формы, некоторые доменные процессы, но не более того. Все, что более универсально, - это просто попытка сделать из непрограммистов программистов, дав им очень грубые инструменты.

1
ответ дан 7 November 2019 в 08:10
поделиться

Я согласен с вами - нетехнические люди не смогут запрограммировать что-либо нетривиальное .

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

Я видел это в действии с бизнесменами, пытающимися построить рабочие процессы в MS Dynamics CRM. Несмотря на то, что продукт был явно предназначен для того, чтобы позволить им делать это без программиста, они просто не могли понять, как заставить работать цикл или условие if-else, независимо от того, насколько «дружественным» пользовательский интерфейс пытался это сделать. Я с изумлением наблюдал, как они боролись с чем-то, что казалось мне совершенно очевидным. После целого дня (!) Этого им удалось создать пару очень простых рабочих процессов, которые в некоторых случаях работали, но не обрабатывали крайние случаи, такие как отсутствующие значения или недопустимые данные. По сути, это была пустая трата времени.

Конечно, Dynamics CRM не является воплощением удобства для пользователя, но я увидел достаточно, чтобы убедить меня, что это действительно глупая затея.

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

1
ответ дан 7 November 2019 в 08:10
поделиться

Я уже писал это в качестве комментария, но решил, что это заслуживает большего внимания.

Определенно существует ряд успешных "непрограммных" инструментов, из них я могу вспомнить Labview, VPL и графовые (edit: I just noticed this link has more far more than just shaders on it) шейдеры, которые преобладают в 3D приложениях.

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

Я сомневаюсь, что инвестиции в разработку таких инструментов будут того стоить (разве что вы сможете продавать их как продукт).

1
ответ дан 7 November 2019 в 08:10
поделиться

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

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

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

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

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

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

4
ответ дан 7 November 2019 в 08:10
поделиться

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

В моем случае я хочу, чтобы врачи могли сформулировать простые правила, такие как: «Если температура пациента становится слишком низкой, отправьте своему врачу текстовое сообщение». Конечно, это сложнее, потому что определение «слишком низкий» зависит от возраста пациента, у пациента может быть много врачей и так далее, но умный врач сможет выяснить эти правила.Реальная проблема заключается в том, что датчик температуры часто падает с пациента и считывает температуру окружающей среды, а это означает, что правило бесполезно, если вы не можете выяснить, как определить, что термометр на самом деле считывает температуру пациента.

Моя большая проблема заключается в том, что, хотя относительно легко создать DSL, чтобы врачи могли выразить IF [температура] [меньше чем] [таблица поиска [возраст]] THEN [send-text- message] , гораздо сложнее создать тот, который может выражать все различные эвристики, которые вам, возможно, придется попробовать, прежде чем придумать правильный способ убедиться, что показания верны.

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

Хотя вы, вероятно, не захотите предоставлять своим пользователям VB, вы можете рассмотреть гибридный подход. У вас будет один «язык» (он может быть графическим, например, конструктор форм VB или Labview), на котором неопытные пользователи могут легко делать простые вещи, и другой язык, позволяющий опытным пользователям делать сложные вещи.

2
ответ дан 7 November 2019 в 08:10
поделиться

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

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

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

5
ответ дан 7 November 2019 в 08:10
поделиться

Подумайте о таблицах.

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

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

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

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

8
ответ дан 7 November 2019 в 08:10
поделиться

Labview - очень успешная непрограммируемая среда программирования.

2
ответ дан 7 November 2019 в 08:10
поделиться

Я думаю, что разработка, не являющаяся разработчиками, обречена на провал. Это достаточно сложно, когда разработчики пытаются это сделать. Какая частота отказов? 50% или выше?

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

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

Обязательно привлекайте экспертов в предметной области. Но не обременяйте их также развитием и обслуживанием.

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

7
ответ дан 7 November 2019 в 08:10
поделиться

Я бы посоветовал вам прочитать эту статью , прежде чем пытаться выбросить всю систему. Я смотрю на это с другой стороны. Что изменилось, чтобы побудить к перепланировке? Эксперты в вашей предметной области не разучились использовать исходную систему, поэтому у вас уже есть несколько компетентных «программистов COBOL» для вашей предметной области. Судя по вашему описанию, в основном изменились требования к производительности и, возможно, возросла потребность в веб-формах.

Таким образом, желаемое решение состоит не в том, чтобы изменить обязанности экспертов в предметной области, а в том, чтобы повысить производительность и упростить создание веб-форм. У вас есть преимущество в виде существующей базы кода, которая точно показывает, на что способны эксперты в вашей предметной области. Было бы очень жаль не использовать его.

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

4
ответ дан 7 November 2019 в 08:10
поделиться

Какая интересная проблема.

В конечном итоге я должен согласиться с вами и не согласиться с вашим коллегой.

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

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

А затем преобразование в программное обеспечение происходит в процессе общения между экспертами в предметной области и программистами.

Я думаю, что попытки создать инструменты «программирования» для экспертов в предметной области - пустая трата времени.

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

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

2
ответ дан 7 November 2019 в 08:10
поделиться

В общем, 2 мысли:

  1. Нельзя свести жизнь к алгоритмам. Все, что мы знаем (философски, научно) и опыт демонстрирует это. (Извините, доктор Мински).

  2. Тем не менее, инструмент, специфичный для конкретного домена, который позволяет непрограммистам выразить конечный язык, определенно выполним, как несколько человек привели примеры. Другим примером такого типа систем является Mathematica и особенно Simulink, которые очень успешно используются в целом ряде приложений. Однако неудачи экспертных систем, нечеткой логики и японского проекта компьютеров пятого поколения 80-х годов демонстрируют трудности, связанные с этим.

3
ответ дан 7 November 2019 в 08:10
поделиться

Непрограммируемая разработка программного обеспечения ЯВЛЯЕТСЯ выполнимой, если вы реалистично представляете, чего могут достичь не разработчики, - все дело в компромиссе между возможностями и простотой использования.

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

Например, предположим, что вы хотите, чтобы эксперты в предметной области могли создавать форму с вводом замаскированного текста:

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

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

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

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

1
ответ дан 7 November 2019 в 08:10
поделиться
Другие вопросы по тегам:

Похожие вопросы: