Возможно ли разработка программного обеспечения без программных средств?

Ответ 1

Вы говорите:

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

• Тем не менее, инструмент, специфичный для домена, который позволяет не программистам выражать конечный язык, определенно выполним, как показали несколько человек. Другим примером такого типа системы является Mathematica и особенно Simulink, которые очень успешно используются в ряде приложений. Тем не менее, неудача компьютерных систем Expert Systems, Fuzzy logic и Japan Fifth Generation от 80 до взлета демонстрирует трудность в этом.

Ответ 8

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

Ответ 9

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

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

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

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

И тогда переход к программному обеспечению происходит между коммуникацией между экспертами домена и программистами.

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

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

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

Ответ 10

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

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

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

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

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

Ответ 11

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

Непрограммное развитие - это безумное дело?

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

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

Ответ 12

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

Есть определенно ряд успешных "непрограммных" инструментов, вне руки, я могу думать о Labview, VPL и graph based (изменить: я только заметил эту ссылку имеет гораздо больше, чем просто шейдеры на нем) шейдеры, которые распространены в 3D-приложениях.

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

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

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

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

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

Ответ 15

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

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

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

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

Ответ 16

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

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

Я, следовательно, со своим коллегой, но, конечно, специфика не может сделать это общее решение подходящим!