[kos]

В этой теме предлагается обсуждать технологии разработки приложений под AutoCAD, взаимоотношения "пользователь-постановщик-программист".
Тема возникла, как водится, случайно (см. ссылку http://dwg.ru/forum/viewtopic.php?t=...5332a28a02dd3d).
Admin'у: может есть смысл продублировать здесь сообщения, относящиеся к данной теме из темы "Из Минска здесь кто-нибудь есть?"

Итак: поехали...

[MIP]

Вот решил поставить задачку!
См ветку http://dwg.ru/forum/viewtopic.php?t=2650
Может кто поможет.

[Кулик Алексей aka kpblc]

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

[MIP]

Как правило (ИМХО) программа (разговор, я так понял, ведется для заказных систем) пишется для автоматизации каких-то действий, которые руками выполнять или лень, или долго, или что-то еще, или все вместе. Т.е. уже есть результат, которого достигли хоть раз (и плевать, что руками).

Такой принцип автоматизации хорош при незначительном объеме написания утилит или для долговременного сотрудничества с разработчикам, задачу постовили, утилитку написали, протестировали, доработали ура, товарищи! Цикл может продолжаться n раз. На некотором этапе это может начать объединяться в что то целое. А нужно что то конкретное и прямо сейчас с возможностью дальнейшей доработки. Я просто не знаю Вашей специфики работы, поэтому мне немного трудно Вам объяснить свою позицию по отношению к постановке задач и написанию программ, но в нашем случае это очень большая работа и начинать заказывать где то софт под себя не оправданная роскошь!
Поэтому мы имеем основные программы по нашему направлению деятельности и сотрудничаем с разработчиками, если есть возможность, в плане оптимизации софта под нас.
Ведь Вы когда то верно подметили фазы развития контор, так вот хорошо когда разработчик с легкостью идет на встречу и него есть потенциал к развитию, хуже когда он уже начинает созерцать себя любимого и пытаться навязать свои решения простым пользователям, мол бери и не привередничай, а когда нибудь возможно мы сделаем что Вы хотите!
Вот что я хотел сказать фразой о плодотворном сотрудничестве между потребителем (постановщиком задач) и разработчиком.
kpblc >> Отдельное спасибо текты в теме юмор! Продолжайте в том же духе!

[Кулик Алексей aka kpblc]

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

[MIP]

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

[Кулик Алексей aka kpblc]

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

[MIP]

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

[Кулик Алексей aka kpblc]

Лучше стабильно, чем быстро

[MIP]

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

[Кулик Алексей aka kpblc]

По поводу быстродействия и стабильности: Был сделан чертеж (7 листов, оформление "пополам" - часть в модели, основной объем - в листе) кад вылетал с завидным упорством (минут через 30-40 работы) на элементарных операциях (переход по пространствам модели / листа, удаление объектов, выполнение chspace и т.п.). Когда расколотил все объекты СПДС и вошел в голый кад, все стало нормально (3 часа на ура). (http://www.autocad.ru/cgi-bin/f1/board.cgi?t=2768JA)
Кажись, тема уходит в сторону.
Резюме:
1. Со стороны пользователей выделяется группа постановки задач. Группой может выступать весь коллектив фирмы при условии последующих доработок ПО. Эта группа описывает все аспекты решаемых проблем, закономерности поведения объектов, выдаваемые отчеты, степень автоматизации, граничные условия работы программ (программы) и т.п. и предоставляет их в письменной форме разрабочикам ПО (т.н. "Техническое задание"). Изменение ТЗ невозможно до момента поставки последней версии ПО. Все ТЗ хранятся у пользователей и разработчиков.
Крайне желательно, чтобы пользователи предоставляли не только тексты, но и рисунки, поясняющие их требования.
2. Разработчик проверяет полученное ТЗ и оговаривает сроки поставки условия работы и обновления ПО, и приступает к работе. Обновление не должно затрагивать уже работающее ПО (т.е. использование нового ПО не должно запрещать параллельное использование старого). Ограничение на время тестировки ПО должно быть не меньше 2-3 месяцев.
Если новые версии ПО создают новые виды объектов, не поддерживаемых напрямую старыми версиями ПО, надо предусматривать возможность конвертации объектов в воспринимаемые старыми версиями ПО (естественно, должна быть и корректная "прямая" конвертация объектов старых версий в новые объекты).
3. Пользователи (или назначенная группа) тестируют полученное ПО и в пределах ранее сделанного ТЗ высказывают свои пожелания и требования. При необходимости разработчики ПО проводят обучение пользователей работе с новыми версиями ПО. При необходимости пишется новое ТЗ и выдается разработчикам.

И так до бесконечности

Сие не есть обязательное требование ко всем разработчикам, работающим "на заказ". MIP - хотелось бы увидеть другую точку зрения

[MIP]

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