Какие вы знаете средства документирования техзаданий для 1с программистов? #579573

Здравствуйте, хотел поинтересоваться кто нибудь использует какие нибудь средства визуализации при анализе предметной области и формализации потребностей в виде справочников документов и отчетов (желательно даже регистров). То есть что бы не рисовать документы прямоугольниками в ком нибудь MS офис пакте, а создавать справочники, документы и отчеты. Описывать их реквизиты и назначение, указывая что из чего формируется. Знаю что есть куча софтин типа UML, но мне интересны средства моделирования которые реально используют 1с разработчики в своей деятельности ?

руки + моск

ворд+визио

УПП собрался написать с нуля?

эээ...   чо?

карандаш и листок А4.

"То есть что бы не рисовать документы прямоугольниками в ком нибудь MS офис пакте, а создавать справочники, документы и отчеты" - открываешь конфигуратор и создаешь справочники, документы, отчеты, регистры. с тебя 500$ за решение.

мне надо пройти по большой строительной конторе и зафиксировать все потребности всех подразделений в понятном виде, потом это перенести виде ТЗ для УПП. Как тоже 1с писала УПП, думаю нечто подобное должно существовать.

>> средства визуализации при анализе предметной области и формализации потребностей пятницо-вечер?

словами пишется. называется по версии Спольски "спецификация"

нет ни какой связи между опросными листками, ТЗ и тех.проектом

"справочник для хранения пользователей базы данных. Называться будет "Пользователи". Обязательно должен иметь три отдльных реквизита - "Фамилия" (тип строка, длина 50 символов), "Имя" (тип строка, длина 50 симв) .... должен иметь реквизит представление (для отображения в печатных формах)........" не?

неа, какой-то бородатый справочник

MS Office чем не канает?

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

этож "предварительная" спецификация. Как будет окнчательная - будет гладко выбритый. И будет называться "БлэкДжэк и Ко"

"все потребности всех подразделений " Как это не правильно... До автоматизации они перекладывали бумажки с одного края стола на другой. Тебе это поможет при автоматизации? У людей может всё поменяться! Рабочее место, компьютер, программа, должность. Вплоть до того что недовольные уволяться. Исходите из потребностей заплнения данных в твоей мегапрограммулине.

огромное спасибо, как мама отправит в школу - сразу начну читать

аминь проекту

имеется ввиду потребности и алгоритмика должности, а не конкретной личности, наверное

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

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

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

Как это ни странно, но абсолютно согласен с

я очень-очень тупой и просто не догоняю. что можно начать рисовать в умл прежде чем это будет описано на бумаге словами ?

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

>> Мы отклонились от темы вопросы, используете средства, если да то какие? не использую ибо необходимости в этом еще ни разу не возникло, уверен , что и не возникнет.

например,

+100500 единственный необходимый девайс это диктофон

а, это не то

а вопрос, где-то готовят таких специалистов?

каких?

Как втюхнуть клиенту втридорога типовое решение (типа УСФ) с небольшими доработками ? Без визуализации тут не обойтись !

умеющих документировать техзадания

а причем тут продажи? такой клиент обычно не сможет прочитать техзадание

пока не знаю )

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

хорроший ответ :) Тогда еще два вопроса. А зачем? Какой смысл вести техническую документацию, когда нет тех, кто сможет ее прочитать. Может ты о чем-то другом говоришь, просто мне однажны попадался пример спецификации на элемент ПО в качестве теста. Так вот разобраться в нем было все равно что понять фразу на немецком, когда ты изучал английский. Буквы вроде знакомые, а в предложение не складываются. И, кому это надо? Архитектору? Так на нем вся ИС держится. Если архитектор уходит и нет тех документации на систему, то система умирает. Сомневаюсь, что кто-то со стороны сможет заменить его. Программисту? Вроде надо. У меня бывают ситуации когда не поймешь то ли ошибку нашел, то ли так и задумано. Приходится спрашивать у архитектора, а так можно было бы по документации разобраться. Получается это надо только тем владельцам продукта разработки, которые не являются архитекторами, чтобы сохранить контроль над полученным продуктам. Много ты таких знаешь?

толковая книга? реально помогает?

Spolsky Joel - "Joel on Software". Реально помогает По существу: Если нужно визуализировать форму, использую 1С формы без кода, делаю скрины Если нужно описать взаимосвязи, описываю словами в Ворде. Блок-схемы в визио, проще и быстрее не придумаешь. Планируемое время работы простыми движениями в проджекте, фактическое там же. В своё время тоже пытался найти единственный ПП панацею. Вряд ли УМЛ применима к чему-то меньшему чем разработка УПП или САП. Всё чисто ИМХО

ну точно - 86! > Надо ставить цель что должна делать программа. целью большинства контор является некий бизнес, а не функционирование программы и что она "должна делать". Делать она должна то, что идет на пользу бизнесу, то что скажут юзвери (болтология с юзверями внятному разработчику дает много) - КАК программа будет это делать - это компетенция разработчика.

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

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

Как думаешь, заказчику не пофиг как его задача будет технически реализована? К тому же даже элементарные остатки товара можно хранить в справочнике, можно в регистре, а можно перебором документов. И ты готов на этапе обсуждения, не видя всей картины в целом однозначно сказать где и как будут храниться данные? Да ты крут. Ну и напоследок - привязываться на этапе собеседования к объектам 1С - дурной тон. Сначала разрабатывают функционал, т.е. твои блок-схемы. И вот этот функционал уже согласовывается с заказчиком. А в каких объектах 1С это будет храниться - это уже вопрос последний и уж точно к заказчику имеет мало отношения.

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

теоретик? Сбор информации с пользователей крайне желателен.

т. е. чуть что сразу в конфигуратор? Так и запишем...

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

Бизнесс Студио посмотри

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

UML в чистом виде слабо подходит... надо "дорисовывать" специфические свойства объектов 1С для наглядности... а это в visio секос еще тот... а из диаграмм нужны только ER, кейсы, активность и последовательность... моделировать можно, но конечный выхлоп не велик... нельзя по модели сгенерить сущности... 1С позволяет сделать только "реверс" в терминах ER-win

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

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

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

С усложнением собственно среды разработки появляется все большое число 1С-программистов, которые могут писать очень грамотный код не вдаваясь в детали предметной области. Специализация, блин. Аналитик - отдельно, программист - отдельно. Сейчас на крупных проектах высококлассный программист на проекте часто вообще не общается с заказчиками. Собственно, автор и предлагает обсудить какая-такая письменная форма общения между разработчиком и аналитиком является оптимальной. И чтоб при этом еще и заказчик что-то понимал. ИМХО, подход получается индивидуальным. В каждом случае по-разному. Мой прогноз на будущее: дальше тенденция приведет и к специализации внутри разработчиков. Появятся спецы по запросам, специальные 1С-дизайнеры, и т.п. И им тоже между собой нужно будет как-то письменно общаться.

ага.. спец по циклам, спец по таблицам значений.. точно.. все к тому и идет...

Это как бы во всех отраслях знаний. Возьмем, например, историю. Раньше был: "историк". Затем "специалист по истории средних веков". Позже "по истории средних веков во франции". А теперь уже какой-нить "специалист по истории торговых взаимоотношений между Нормандией и Бургундией во второй половине 17-го века". И этим занимается до пенсии

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

Т.е. если по теме, ты считаешь, если жизнь заставит то опять народятся 1С-ники 90-ых? Которым не нужно ТЗ, которые знают бух.учет лучше любого буха, которые за неделю на семерке реализуют любую бизнес-потребность?

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

они есть такие и сейчас.. знаю нескольких.. да и сам к тому стремлюсь :) клиенты за такой "скилл" готовы платить и неплохо так.. оказывается, что клиентам гораздо приятнее работать с "1Сником" которы знает ответы на все вопросы и которому не надо звонить " офис" и искать там специалиста по зарплатной конфигурации ибо он сам специалист по УНФ но приехал к заказчику у которого УПП стоит...

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

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

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

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

все уже написано давно.. 1С разработку платформ между прочим ведет на этой конфе:

В моей программе будет часть функционала из BS.

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

оно не нужно

Кому не нужно, прошу не беспокоиться :)

по этому многие упертые гуру сидят на 7ке.. ибо там было проще.. примитивная платформа, примитивный язык...

Спасибо. Доступно и всерьез! :-)

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

ага... клюшечники молча зубрят многочисленные талмуды по 8ке :)

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

если уж немного потроллить на эту тему... Я, например, искренне уважаю братьев за 8-шный проект. Они вполне могли потратить N миллионов долларов на что-то иное. Семерочная монополия позволяла жить безбедно еще оооооочень долго. А у людей шило в нужном месте, хочется технологически нового. И они вкладываются собственную базу данных, в совсем новую платформу и т.п. ИМХО, вряд ли по чисто  экономическим причинам, чтоб заработать больше бабла.

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

не та сфера... Где была бы сейчас майкрософт, там и остановившись они на своей некогда революционной виндоус 95?

Если программеры не совсем овощи, то ТЗ им ставят в виде подробного документа в doc, а архитектуру они сами разрабатывают. Если программеры овощи, то проще открыть новую конфигу и накидать объектов с именами, а они пусть обвязку пишут. Если нужен учет работ в ИТ отделе - это уже другая фишка, где-то была конфига под это дело.

конфу не смотрел. Но скажу :) разработка платформы  разработка прикладной конфы требуют разных подходов. Платформа создается программистами для программистов. И им на порядок проще объясняться между собой, "а что, собственно, надо? и зачем?"

никогда не сталкивался с другим? Абсолютно не овощ, а говорит: непонятно написал, напиши по-другому. Вот ТС и ищет волшебную палочку, чтоб махнул и все сразу поняли: и программисты, и заказчики.

а я и не отрицаю... тиражные решения - они не для людей написаны.. они для неких сферических коней в вакууме... и любая нормальная контора которая хочет работать ЭФФЕКТИВНО очень быстро приходит к пониманию того, что тиражные решени я- это всего лишь начальный этап... . так что уж прости, не быть тебе эффективным менеджером... ;-)

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

О! тут ты как в воду глядел... сижу сейчас на одно мелком рабочем месте - хочется застрелиться от практической безысходности... учет, который практически вслет ложится на план счетов (для своих, не бух целей) или даже на регистры - реализован кучей справочников, документов, с кучей разорванный связей, все это недокументировано, для реализации очередной нужной хотелки встаешь перед выбором - либо писать по принципу "хрен с ним", либо пытаться сделать нормально... пока что опыт показывает что нормально - сделать практически нереально..  не получается стоять чистым среди кучи грязи... . так что ТЗ - писать НАДО! хоть какое-то - но надо...

>и, конечно, не мсразу когда появилась 8-ка.. но достаточно быстро (по крайней мере мне) стало понятно что пойдет сегрегация 1С-программистов на грамотных кодеров, консультанотов и внедренцев - причем это будет существенно заметнее и выраженнее чем на 7.7... мне т ак кажется раньше и сейчас... в появлении консультантов виноват не снеговик... требования бизнеса растут. меняется инфраструктура IT... один уже в поле не воин... раньше стояло три писюка с рынка и коаксиальная сеть между ними и принтер матричный... теперь иногда 1С "вхожа" в рынок где играют по крупному...

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

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

>Кроме того, все-таки язык не такой простой. кто не в силах осознать "ссылка <> объект" и читать СП - у нас заводы стоят... у всех разные способности что поделать - я не умею стихи писать - я же в литераторы не лезу...

про общение я все написал в (50, 59)... нех велосипеды выдумывать... берите литературу и читайте - computer science слава богу уже > 50 лет как есть...

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

в то что на завод/холдинг в 1000 мест придет чувак с клюшками и в одно лицо будет внедрять/админить/сапортить/реализовывать все потребности - никуа не верю... его банально затрахают "Доступ к базе данных на сервере возможен только из одного каталога" и прочими милыми родовыми травмами...

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

согласен. но есть же куроводители которые ЭКОНОМЯТ!

Данный материал помогает понять значимость визуализации данных, для задач 1с ценность сомнительная...