Платформа Аллегро ... баннер перед носом ... чуть выше..

← →
Digitman © (2004-04-14 13:08) [40]

> kaif

1. Планируется ли тобой версия платформы для организации 3-звенки ?

2. Извини, у меня не было выбора - демо-движок (то что выложено на сайте) пришлось сломать, чтобы воочию оценить произв-ть операций на значительно больших (>> 1000 записей) наборах данных .. ч.г., мне не очень понравилась производ-ть при массированной вставке-модификации в справочники и документы ... тестировал на FB1.5 RC9 ... где-то, очевидно, есть "узкие места", возможно - в не слишком удачной логике управления транзакциями при таких вот операциях ... не думаю на это как-то влияиет RC9 vs RC4

← →
kaif © (2004-04-14 13:12) [41]

2 Digitman © (14.04.04 12:41) [36]

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

К сожалению, это именно то, что я не посчитал благом.
Потом юзер приходит и просит сделать отчет "по категориям". А там чего только нет:

СПРАВОЧНИК ТОВАРОВ:
Ботинки мужские
Черный цвет
...
Возврат от 10.01.2003
Ботинки женские
Черный цвет
Передано под отчет Васе (партия из 10 пар)
Китай
...
Брак
Чулки женские
...
Деньги наличные (отдали за транспорт в Саратов)
Другое
Остатки на складе на 02.03.2004
-------------------------------
То есть если дать неформализованное "просто дерево" юзеру, то начинается смешение сущностей и совершенно несовместимых понятий. Я не придумываю. Это одна из постоянных болезней справочников 1С. Юзеры не видят причин, по которым в справочник товра не может попасть, например, такая позиция, как "возврат денег" или категория "остатки на такое-то число".
-------------------------------
Если конфигурирующий обязательно хочет реализовать рубрикаторы, он может это реализовать своими средствами (вручную). У него прямой доступ ко всем таблицам. И достаточно оконных компонентов. Провоцировать его на рубрикаторы специально я пока не решился. Рубрикаторы снимают головную боль с программиста и приносят большую радость юзерам. Но потом чудовищный результат для учета и кошмар для программиста (если он не сбежит к тому времени).
-----------------------------
Что касается принципиальной возможности делить по категориям, почему бы не создать пару обычных справочников? Возможно, у меня недостаточное управление справочниками. Например, если бы можно было после выбора значения поля "категория" сужать список "подкатегорий" (второе поле в "трехуровневой" жесткой модели), то, возможно, это решало бы ту задачу, которая стоит в основе проблемы. Если усовершенствовать интерфейс линейных справочников для "какого-то древовидного отображения", то в каких-то случаях это может быть оправдано.
Но если я предоставлю юзеру дерево "как таковое" - потом SQL-щики меня проклянут. А именно этого я бы не хотел.

← →
Digitman © (2004-04-14 13:39) [42]

> kaif © (14.04.04 13:12) [41]

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

> если я предоставлю юзеру дерево "как таковое" - потом SQL-щики
> меня проклянут

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

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

← →
kaif © (2004-04-14 13:47) [43]

Danilka © (14.04.04 12:56) [38]
> В 1С тоже иногда пишутся дельные вещи. Вопрос в том, за
> какое время и какими усилиями.

Кстати, намного быстрее и проще, чем то-же самое, например, на дельфях.
Правда, вот с этим:
> И с какой скоростью потом все это работает.

Allegro позволяет писать так же быстро, как в 1С и даже намного быстрее, так как не требует переключения в "конфигуратор" и обратно и монопольного захвата каждый раз. А результат - сопоставимый с Delphi (по скорости и интерфейсам).

Кстати, а в кредит он будет продаваться?

Да, будет.

И еще, где можно посмотреть версию, я ее смотрел давно очень, файл AllegroSetup.exe от 28 октября, как я понимаю, есть более свежая версия?

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

serge35 (14.04.04 13:02) [39]
И что, пользователь, знакомый только с Excel сможет самостоятельно спроектировать базу данных?

Нет, не сможет. Но если он знаком с базами данных и нормализацией, то сможет создать Метаданные. Для программиста останется разобраться с интерфейсом. Система и не пытается "косить" под пользователя. Она изначально заточнена под программиста - дельфиста.

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

Давайте посчитаем по себестоимости. Допустим один рабочий день программиста, работающего на заказ стоит 50$.
Предположим, что для разработки конфигурации требуется 3 месяца, т.е. 60 рабочих дней.
Таким образом конфигурация обойдется в 3000$
Не так уж и дешево.

Разработка занимает 1 месяц (20 рабочих дней по $50) и стоит, таким образом, $1000. Не так уж и дорого. Именно на этих условиях я писал первую конфигурацию в Allegro.

К тому же простите надо купить лицензию на Delphi и IB.
Да еще заплатить за Allegro.

Покупать Delphi не нужно, так как allegro не содержит в себе (даже замаскированного) кода IDE Delphi. Покупать IB тоже не нужно, так как Firebird бесплатен. Желающие могут купить Yaffil. Он стоит $200. Или могут подождать Firebird 2.0. В него войдет код Yaffil.

Покупать Allegro конечному пользователю (заказчику) тоже не нужно. Allegro нужно купить разработчику (программисту). Так что заказчик платит только за работу, а Allegro (как исполняющую систему-интерпретатор) получает даром. Если только он не собирается "сам заниматься конфигурированием". Итого, разработка конфигурации на заказ $1000. Это ориентировочная цена. Не так уж и дорого.
Есть проекты (совсем маленькие), которые, например, я берусь сделать за неделю и выставляю цену около $200-$300. Согласитесь, что это вообще недорого. Разумеется, многое зависит от опыта и искусства программиста.

← →
Digitman © (2004-04-14 13:51) [44]

> kaif

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

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

← →
kaif © (2004-04-14 13:55) [45]

Digitman © (14.04.04 13:39) [42]
а есть ли возможность посмотреть демо платформы, где рубрикаторы еще "живы" ? хочу таки своими мозгами оценить, во что это выльется в реалии ... был бы премного благодарен ...

Я постараюсь найти эту старую версию. Но она очень старая... Там вводилось сколько угодно рубрикаторов и было поле типа "рубрикатор". Если справочник содержит такое поле - слева возникало дерево в интерфейсе справочника. Один справочник мог содержать несколько альтернативных рубрикаторов. Я не исключаю, что в будущем какое-то может быть более умное решение с рубрикаторами мне удастся найти, если разработчики будут сильно жаловаться на отсутствие рубрикаторов. Но "старт" Allegro во внешний мир я решил дать без излишеств. Чем проще программа в момент рождения, тем больше вероятности, что ее кто-то попробует использовать. Я больше всего боялся создать мертвого монстра с "кучей возможностей". :)

← →
serge35 (2004-04-14 14:09) [46]

А кто платит за составление ТЗ на конфигурацию?
И кто ее составляет.
В посте 12 я уже писал, что разроботка системы с 0 по готовому, проработанному ТЗ не составляет большого труда и не занимает много времени. Вопрос в том, что я лично таких ТЗ на большие системы не встречал. ТЗ на небольшие модули есть, я и сам их писал.
Я бы предпочел в качестве СУБД - Oracle и PL/SQL, да и многие потенциальные покупатели, которые собираются развивать и совершенствовать свою систему прекрасно понимают, что на средствах разработки экономить нельзя. В дальнейшем это выйдет боком.
Люди сейчас готовы заплатить десятки тысяч долларов, но они должны быть уверены, что система будет отвечать всем их требованиям и амбициям.

А в этой фразе уже заложено ограничение для разработчиков:
> если я предоставлю юзеру дерево "как таковое" - потом SQL-щики
> меня проклянут

Зачем мне такое средство разработки, если я не могу на нем сделать Фичу, за которую заказчик готов выложить немалые деньги?

← →
kaif © (2004-04-14 14:11) [47]

2 Digitman © (14.04.04 13:51) [44]
Переложить ответственность на юзера всегда можно, но потом головная боль опять будет у программиста...
Приведу еще один аргумент против рубрикаторов. Существуют фирмы, торгующие алкоголем. У меня товарищ-ларечник работал с такой фирмой. У них такой рубрикатор (1С):

Литраж
Завод-производитель
Вид товара
Марка

Так вот. Заказ у такого поставщика занимает 20-40 минут. Сообщать девочке нужно именно в такой последовательности, в какой она будет открывать папки:
0.7 литра, Кристалл, водка, Гжелка
и так далее.
На поиск каждого товара по такой системе уходит уйма времени. Это реальные потери рабочего времени и они имеют стоимостное выражение. Для сравнения при поиске "по вхождению" в таблице сборных наименований, который обячно используется в Allegro, нужно нажать всего несколько клавиш:
7 гж
И вылезут все Гжелки 0.7 литра.
Я исхожу из следующих соображений. Допустим имеется 10тыс товаров. Один из 10 тыс - это всего 14 бит информации. Каждое нажатие на клавиатуре я оцениваю в 4-5 бит (букв и цифр всего 30-40). Следовательно, любой товар должен быть найден 3-4 нажатиями клавиш. И без всяких мышей. Если пользователь должен нажимать больше клавиш - интерфейс неправильный. Тогда пользователь предпочтет создать и запоминать коды товаров. Коды будут содержать 4 цифры, а он - искать по коду.
Рубрификации хорошо подвергать однородный материал. Например, документы в Allegro лежат "в папочках". А если у нас имеются классы товаров, то это может прийти в противоречие с системой рубрификации (еще одна проблема).
Я не спорю окончательно. Я спорю против рубрикаторов на данном этапе. Когда пользователь вообще еще не работал с классами. И предпочтет рубрикаторы "по инерции". Тогда пусть берет 1С и не заморачивается на строгую аналитику по группам. Но он же хочет эту аналитику! Как тут быть?

← →
serge35 (2004-04-14 14:29) [48]

Начнем с того, что заказчик обычно сам не знает чего хочет.
Какие его действия? Он берет одну демо-версию и смотрит что его устраивает, а что нет. Затем, помотрев десяток демо-версий понимает, что целиком и полностью его не устраивает ни одна из систем.
Тогда он находит программиста и говорит ему, что ему нужна система такая, чтобы часть была из одной, вторая часть из другой системы и чисто от себя он хочет еще парочку наворотов.
И чтобы все работало. А на своем рабочем месте он хотел бы иметь одну больщую кнопку, чтобы нажав на нее он видел бы все, что твориться в его конторе.

← →
Danilka © (2004-04-14 14:34) [49]

[48] serge35 (14.04.04 14:29)

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

← →
Digitman © (2004-04-14 14:41) [50]

> У них такой рубрикатор

ну дебильный же он, этот "пиво-водочный рубрикатор" !... извини за выражение)

по рукам надо дать тому, кто формировал конф-цию, позволяющую создать такое ...

атрибуты

Литраж
Завод-производитель
Марка
Градус

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

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

Категории (виды) алк.продукции
Крепкие алк.напитки
Водка
Коньяк
Шнапс
Косорыловка
Табуретовка
и т.п.

тогда выборка для отчетности выглядела бы так :

ВЫБРАТЬ из "Категории\Крепкие напитки\Водка"
ВСЕ изделия
ГДЕ
Завод-производитель = "ЧП Пупкин и Ко" И
Марка = "Андроповка" И
Градус = "Мало не покажется"

← →
serge35 (2004-04-14 14:42) [51]

Интересно, сколько надо еще постов написать, чтобы донести одну простую мысль: На современном этапе эволюции средств разработки ПО этих средств разработано уже более чем достаточно. Проблема сейчас сводится к ПРАВИЛЬНОЙ ПОСТАНОВКЕ ЗАДАЧИ.

← →
Тимохов © (2004-04-14 14:44) [52]

> serge35 (14.04.04 14:42) [51]

Да с этим никто не спорит. Насколья я понимаю digitman и kaif в основном обсуждают конкретную платформу - ее достоинства и недостатки.

← →
Danilka © (2004-04-14 14:48) [53]

[51] serge35 (14.04.04 14:42)

> современном этапе эволюции средств разработки ПО этих средств
> разработано уже более чем достаточно.

да ладно?
а какой критерий достаточности?

← →
serge35 (2004-04-14 14:51) [54]

> ну дебильный же он, этот "пиво-водочный рубрикатор" !... извини за выражение)

по рукам надо дать тому, кто формировал конф-цию, позволяющую создать такое ...

атрибуты

Литраж
Завод-производитель
Марка
Градус

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

← →
Тимохов © (2004-04-14 14:52) [55]

> Danilka © (14.04.04 14:48) [53]

на дельфи можно написать все что угодно - было бы задание.
согласен в serge35 - самое главное получить задание.

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

← →
serge35 (2004-04-14 14:56) [56]

>а какой критерий достаточности?

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

← →
Danilka © (2004-04-14 14:56) [57]

[55] Тимохов © (14.04.04 14:52)
и что?
например, на асме можно написать ровно столько-же сволько и на дельфях. :))

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

← →
serge35 (2004-04-14 14:58) [58]

> для меня сейчас самое главное - скорость разработки

Учись быстрее печатать.

← →
Irogen (2004-04-14 15:02) [59]

Весьма недурно.

← →
Danilka © (2004-04-14 15:03) [60]

[58] serge35 (14.04.04 14:58)
> Учись быстрее печатать.

глупость какая. :))
в таком случае, могу почсоветовать Вам учиться быстро бегать, вместо того чтобы пользоваться каким-либо транспотром.

К тому-же я слишком для этого ленив - "печатать быстрее". :))

← →
Dmitriy O. © (2004-04-14 15:24) [61]

Эксель самая крутая система учета и анализа.

← →
Тимохов © (2004-04-14 15:24) [62]

> Danilka © (14.04.04 15:03) [60]
> [58] serge35 (14.04.04 14:58)

не глупость.

скорость разработки в дельфи весьма приличная.
быстрее только кошки родятся.

было бы задание.

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

У нас так и есть. Но! Все что в итоге понастроили продвинутые пользователи способно привести в ужас любого.

Вывод (для меня он непоколебим):
конечный продукт должен быть написан на НОРМАЛЬНОМ языке, но в системе обязательно нужна платформа, которая дает возможность продвинутым пользователям понимать, что они хотят посредтвом принятия участия в разработке. В результате настройки платформы нормальные квалифицированные программеры получают задание (весьма замечу точное) и переведя скриптовый язык (исправив по ходу кучу ошибок) в дельфи получаем хороший конечный продукт.

У нас примерно так и есть.

← →
Тимохов © (2004-04-14 15:25) [63]

> Эксель самая крутая система учета и анализа.

lmd

самая крутая система - это голова (своя)

← →
Danilka © (2004-04-14 15:34) [64]

[62] Тимохов © (14.04.04 15:24)
> Утв1: если есть задание точное и непоколебимое, то быстрее
> дельфи ничего нет (по крайней мере сильно быстрее).

Ну-ну. Учет и отчетность чего-либо на 1С-ке, получается делать иногда на порядок быстрее. Плюс к этому - стандартный интерфейс и легкость связи с бухгалтерией и проч. Kaif утверждает, что скорость разработки в Аллегро сопоставима с 1с-кой, возможно это и так, это я еще проверю. :))

> Утв2: чаще заданий нет.

А как браться за задание, если его нет? Не понимаю. Вообще, значительное время уходит на разработку ТЗ. А сама разработка только потом.

И еще, что значит "Нормальный язык", этого мне не понятно. Например, фокс-про, нормальный язык? А сколько было на нем написано еще под ДОС. На моей памяти, в налоговой работали системы за сотню пользователей с базами в сотни мегабайт.

← →
Тимохов © (2004-04-14 15:41) [65]

Данил, не надо придираться к словам.

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

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

← →
Digitman © (2004-04-14 15:45) [66]

> Dmitriy O

ты еще не побывал на http://www.lleo.aha.ru/na ?
кажется, Игорь тебя очень конкретно адресовал ... с учетом еще и текущих твоих комментариев - оч и оч конкретно ... займись лучше "набором команды"

← →
Dmitriy O. © (2004-04-14 15:53) [67]

> Digitman © (14.04.04 15:45)
У нас на заводе один умелец соорудил на Access+Excel такую крутую систему учета и анализа брака. Что наши асушники не могли за два года разработки на Билдер C++ сделать лутше.

← →
Danilka © (2004-04-14 15:58) [68]

[65] Тимохов © (14.04.04 15:41)
> За частую в самом начале известно очень мало - даже заданием
> назвать сложно. Задание конкретизируется в ходе работы.

Ну, вообще-то да. Но это уже другой класс систем. Заключайется долгосрочный контракт, который оплачивается поэтапно.
Например, фирма Х делает для Y корпоративную систему под орокол, в которой более 600 таблиц и более 900 вьюх. Делается это в своей самописной (на дельфи правда) системе. Причем, если-бы абсолютно все делалось на дельфи, то было-бы затрачено на намного больше времени. А сейчас скорость разработки намного выше. Когда одних только отчетов свыше тысячи - сколько надо людей чтобы все это в квик-репорте нарисовать? Под это дело написана система позволяющая делать отчеты на порядок быстрее, или даже еще быстрее, конечно со своими ограничениями, под которые не попало, допустим, 10% отчетов.

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

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

А на чем писать - от этого зависит скорость разработки, когда ты закончишь, а значит и стоимость системы. Чем выше скорость, тем меньше стоимость разработки, тем больше заказчиков к тебе обратится :))

← →
serge35 (2004-04-14 16:08) [72]

Я писал и на FoxPro (DOS) и на Excel.
Помню, году эдак в 1995, когда Ельцин отменил 3 незначащих ноля у рубля, ко мне пришли знакомые, у которых стояла 1С и слезно умоляли убрать у них в базе эти нули за предыдующий год.
Я взял у них DBF-ки, разобрался и меньше чем за час написал прогу на Фоксе, которая удаляла эти нули.
Тогда 1С была самой защищенной программой. Но это только для бухгалтеров.

Не даром Билл купил FoxPro - это был язык, который мог составить конкуренцию VB.

[69] Тимохов © (14.04.04 16:04)
У нас в конторе, целая система написана, одних *.pas - файлов на 40 мегабайт, зато теперь полностью сосредотачиваешься на sql, я дельфи на работе не запускал уже бог знает когда - возможностей системы уже на все хватает.

> Dmitriy O. © (14.04.04 15:53) [67]

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

← →
serge35 (2004-04-14 16:14) [75]

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

[75] serge35 (14.04.04 16:14)
Зачем? У нас примерно также, только под орокол. :)

Конечно, кроме скорости разработки еще и очень важны ограничения системы, но об этом написано полсотни постов назад, вот-тут:
[32] Anatoly Podgoretsky © (14.04.04 11:51)
:))

Извиняюсь за длинный постинг, но короче, видимо, не получится...
Как обычно происходит работа на заказ? Имеется успешно работающая на рынке фирмочка, которая что-то хочет за $500. Имеется программист, знающий относительно неплохо Delphi, но не работающий на крутой должности где-нибудь за $1500 в месяц. Так вот фирма (обычно через знакомых или еще как-то) обращается к нему, типа "можешь наприсать такую вот вещь?". Он думает - "а почему бы и нет?". Дельфя у него как правило пиратская, разработка явно тянет на $1000 (пару месяцев работы), но задача интересная, да и опыта коммерческих разработок набраться хочется... Он говорит, бог с вами - давайте сделаю вам это. Начинается обсуждение подробностей (постановка задачи). Потом начинаются переделки и "добавления". Программист начинает нервничать. Одно дело - поднапрячься и за месяц в экстремальном режиме сделать то, что по уму нужно было спокойно делать 2 месяца (минус $500), Другое дело - делать в 3 раза больший объем (уже минус $2500). А кушать что-то тоже хочется... А заказчик все больше "борзеет"...
Зададимся вопросом, а что собственно происходит? Почему это так? Может быть все нормально? Ответ, на самом деле очень прост. Все дело именно в выборе Delphi в качестве средства для такой разработки. Разработка на самом деле стоит намного дороже, чем платит за нее заказчик. В этом вся соль. Он искренне полагает, что если "вот это" стоит $500, то почему бы не добавить еще $200 и получить, например, "вот это"?
Поэтому есть единственный выход - снижение стоимости "эволюционной" разработки. Без применения достаточно мощных CASE-средств это невозможно. Если программист изучит полный набор средств, который позволяет вести "эволюционную" разработку без г#морроя, то он может уже идти смело в фирму, работающую с жирными заказчиками, где ему будут платить $1500. А суммарно все лицензионное ПО для такой работы будет стоить не менее $10,000.
Так что, значит та фирмочка должна остаться вообще без программы? Выходит, что так. Можно, конечно, выучить 1C и пытаться что-то сделать в ней. Но дельфист этим заниматься не хочет, если только голодная смерть еще не на пороге... :)
Я подумал, как сократить время разработки для дельфиста-фаната SQL? Как избежать тех проблем, что возникают в 1С? И нашел определенные решения. Например совершенно другую систему справочников, совершенно другой бухгалтерский баланс и совершенно другой взгляд на именование и доступ к объектам базы данных, чем в 1С. И наконец, другую политику продаж и лицензирования.
В результате удалось выровнять отношения заказчик-программист. Первая конфигурация, которую я писал на заказ в Allegro, через один месяц работы имела версию номер 7 (!!!). При этом я не поссорился с заказчиком, а он "осознал" все, что ему принципиально нужно, быстро, и при этом еще как-то сам интуитивно понял, что такое нормализация, минимализм и требования к уникальности. Такого взаимопонимания раньше с заказчиками у меня так легко не складывалось. Он сам стал стремиться все упростить и выбросить все лишнее.
Это не только мой опыт. Уже несколько человек использовали Allegro для коммерческих заказов. Все отмечают высокую скорость разработки и отсутствие конфликтов с заказчиком в условиях очень плохо формализованных изначально задач.
Вообще четкая схема ТЗ->программа, ИМХО, есть совершенная утопия, если речь, конечно, не идет о заказе более, чем в 10 тыс зеленых.
Я рекомендую попробовать действовать так. Берется Allegro и городятся справочники под клиента. Это можно сделать вместе с ним, у него на фирме за пару часов. Далее городится система счетов баланса. Если заказчик не очень понимает GAAP-баланс. ему можно на пальцах все объяснить или дать программу LEADER Classic http://www.lclassic.ru , чтобы он потыркался в ней. Потом нужно у него выяснить, какой интерфейс решает сразу 90% проблем. Обычно, это интерфейс ввода заказов. Или "сдельной работы". Или еще что-то. Всегда есть такое узкое место на фирме. Обычно даже бывает уже готовый способ как-то это вести в Excel, разработанный добросовестным и талантливым менеджером. Далее уже надо думать. Сделать пару интерфейсов, чтобы заказчик мог поиграться и почувствовать мощь системы. А после этого уже обсуждать условия сотрудничества, сроки и цены. Заказчик должен понимать, что задачу ставит он вместе с Вами. Задача полностью поставлена обычно тогда, когда программа уже внедрена и успешно работает. И только так. На малой фирме, по крайней мере. А этих малых фирм... много. Очень много. Неправда, что им не нужен реальный учет. Это не так. Нужен. И они готовы платить разработчикам. И с ними приятно иметь дело. Там нет бюрократии и ситуаций, когда один платит, другой решения принимает, а третий юзать должен...

А если фирмочка хочет ещё и "правильную" бухгалтерию?

2 DiamondShark © (14.04.04 17:59) [78]
Из Allegro можно связаться с 1C, как COM-сервером и экспортировать оттуда документы в "правильную бухгалтерию".
:-)
Однако, как правило, такая задача и не стоит.
Кстати, что касается прозрачности учета. Грядет налоговая реформа. Социальный налог будет снижен с 35% до 26% для зарплат ниже определенной величины, а для более высоких - прогрессивно падать вплоть до 2%. МИНФИН уже подготовил все документы. Я ожидаю резкого уменьшения бутафорского учета, так как именно социальный налог был главной помехой на этом пути. Многие захотят работать вообще вбелую. И тогда ценность бутафорского учета может резко снизиться. Кормушка в налоговой в результате начнет уходить в небытие. И люди начнут задумываться о том, чтобы выбирать более прозрачное и адекватное представление данных. Лучше двустороннего баланса в стиле GAAP пока никто ничего не придумал. Я вынужден быть оптимистом. Или мы имеем реальный учет и управляем бизнесом по-человечески - или вообще ничего не имеем и обманываем сами себя.

Тенденция в сторону GAAP уже становится фактом:
Компании могут быть освобождены от обязанности вести бухгалтерскую и финансовую отчетность по российским стандартам.
http://www.arni.ru/arni/smpage.fwx?page=1435&news=1000

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