Выношу на ваш суд методичку "Опыт применения элементов RUP в проектах 1С:Предприятие".


Текущий документ – описание гибкой, итерационной, основанной на RUP технологии реализации проекта по созданию заказного программного решения малого объема.


http://www.liga1c.ru/projects/rup1c/RUP-in-1c_v2_2007.07.08_0000.pdf
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=999&lid=7731

-- [ аннотация ] ----------------------------------------------------

 Рассматриваются принципы управления проектов основанные на итерационном подходе - без заранее четко-прописанного ТЗ.

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

Данная технология – результат «опытной эксплуатации» идей RUP («унифицированный рациональный процесс») и применения UML (унифицированный язык моделирования) в работе с заказчиком в рамках проектов связанных с системой “1С:Предприятие”.

Документ предлагается как руководство для программистов и «технических РП», которые желают применять итерационные технологии в своей работе.

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

___________________________
Приветствуются здоровая критика и обсуждение.

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

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

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

Почитаю только завтра, поздно уже у нас...

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

(0) а где хоть слово про 1С... И ошибок синтаксических хватает.

(3) стр 7.
"Привязанность к 1С"... как в методике "вообще" - она конечно косвенная )

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

  Далее - упрощена "архитектурная ориентированность" RUP - 1С практически предлагает уже готовые типовые элементы.

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

а синтаксис... да наверное фиг с ним...) суть важнее. но отладим со временем )

(2) >>1С-ники не занимаются сбором показаний пользователей))
гм.. неужели? хотя где как наверное.

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

и лучше, если этим будет заниматься именно 1С-ник. тем более в случае небольшого проекта до 100 часов.

попробую сделать маленькое обращение - не пытайтесь увидеть в этой методике "наличие ТЗ". его нет. нет никакого ТЗ )

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

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

ЗДЕСЬ - совершенно иной стиль мышления и управления проектом.

  аналогия? - если вы знаете ООП - вспомните как вы переходили от "функционального програмирования"(метки и подпрограммы; программа как набор функций выполняющихся последовательно) к ООП (классы и события; программа как набор объектов, одновременно реагирующих на события и взаимодействющих друг с другом)
- здесь аналогичный процесс. Надо сменить тип мышления.

(0) Оформление ужасное - читать неприятно. Хочешь писать красивую
документацию - освой LaTeX, если очень хочешь, могу конвертнуть в него и
показать результат.
(6) Функциональное программирование - совсем другое. То, что описываешь -
процедурное.

пока глубоко не читал.

Между тем, ошибок пока не заметил. Хорошо и грамотно написанный текст.

(7) Да - будет интересно увидеть образец оформления документации, который корректно оформлен с твоей точки зрения. хоть пару страниц.

(и спасибо за отзыв)

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

Что за бред? или это про 7.7?
Файлы модулей 8.0 можно выгружать в тексты и загружать обратно.

(9) http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=23965&filename=rup-1c.pdf
Это PDF с началом книги, без изысков - колонтитулы не настраивал.

http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=23966&filename=rup-1c.tex
Это - исходник в LaTeX.

(10) Насчёт документирования согласен - таких средств, как Doxygen, JavaDoc для
1С пока не видел. Думал сам разработать, да энтузиазма не хватило :)

+12 Согласен с (0), в смысле

(10)
>> или это про 7.7?

Что за бред? Файлы модулей 7.7 можно выгружать в тексты и загружать обратно.

(8)
>> Между тем, ошибок пока не заметил. Хорошо и грамотно написанный текст.

Ошибок много на самом деле... Могу выполнить функцию корректора, если есть такая необходимость...

(15) Да уже и тогда заметил, в основном проблема с запятыми. Тока отписываться
не стал :)

(0) Итеративные методы разработки баз данных? чтоб утонуть в непрерывной конвертации данных от одной итерации до другой?
Как-то бредом попахивает...

(10)(14) во первых - причем тут выгрузите кода во внешние файлы? диаграммы кто будет составлять? и далее работать с ними вы тоже будете "выгружая код в тексты и загружая обратно?!"

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

"диаграммы взаимодействия", "диаграммы классов" и им аналогичные, модифицированные "ER диаграммы" и др. - это никак не линкуется в 1С "автоматизированно".

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

(17) во первых, никто не заставляет вас применять итеративные методы при разработке баз данных. Речь идет об информационных системах.

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

Никто же не тонет в конвертации между версиями 1С при обновлении? как минимум потому что есть подсистема конвертации и объединения (да- со своими заскоками но есть).

(19) "при создании "прототипа" ещё и проработать структуру БД" - а чем это отличается от водопадной модели разрабтки? в чем тут преимущества итеративного подхода? Ведь для создания прототипа я должен буду спроектировать сразу все...

(20) Нет, со структурой БД ты не работаешь. ты работаешь (в случае
1С:Предприятия) с ORM, которая уже сама решает, в каком виде хранить данные, и
как их конвертировать при рефакторинге.
В случае того же 1С:Предприятия тебе отдельно эту подсистему выдумывать не
надо, всё уже до тебя выдумано.

(11) спасибо - посмотрю.

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

Спасибо за предложенную помощь.

(21)
1. "со структурой БД ты не работаешь. ты работаешь (в случае 1С:Предприятия) с ORM" - не могли бы привести пример получения, например, кор оборотов по группе счетов за неделю при помощи ORM?

2. Захотил я изменить структуру хранения доп характеристик, как сама система решит, что именно и куда надо сконвертировать?

3. в 1С:Предприятии столько странного навыдумано, что думать приходится много больше, чем хотелось бы...

(23)
1. Ты не поверишь, прям как в книжке... Удалил счёт - не сможешь к нему
обратиться/сделать по нему запрос. И т.д., см. определение ORM и зачем оно
нужно.
2. 1С за тебя сама решила, как их хранить надо. Или я не понял?
3. Не, надо просто постичь философию ейную. Вот она-то моск и ломает почище
синтетики.

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

в общем экстремальное программирование мне ближе да и на 1С оно лучше ложится.
А UML всё же заточено на ООП, а раз мы не можем проектировать классы, то и толку от него нет

(24)
1. Повторяю, мне не надо удалять счет, мне нужны кор обороты. Как здесь использовать ORM?
2. Хочу хранить произвольное количество произвольных доп характеристик для сотрудников. Система может решить какие для этого нужны сущьности и как их хранить?
3. Для того, чтобы постичь философию, надо чтобы она была. А есть ли философия в 1С:Предприятии или там куча обрывков каких-то мыслей, сваленная в одну кучу?

(20) нет не все-сразу.
(далее я говорю в рамках оригинального RUP а не в рамках топика)
Структура БД - да её надо прорабатывать наиболее четко.
но то что делается на этапе "исследование"(RUP) с БД больше должно походить на проработку структуры классов приложения.

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

__________________
а вообще - никто не говорит что во всех областях применимы все методы. Если вы считате что структуру БД надо прорабатывать сразу и намертво - делайте это.

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

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

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

(26) Я тебе привёл простейший пример, каую именно роль играет ORM в системе.
1.
Счет->ВыбратьКорреспонденции();
while ( Счет->ПолучитьКорреспонденцию() )
{
 Счет->ЧитаюКорреспонденцию();
}
2. Это легко решает кнопка "Сделать всё заебись".
3. Философия как раз в том и кроется - что ORM за тебя всё не сделает, а вот
рутину (типа ненарушения целостности базы при добавлении реквизита
справочника) - вполне.

(25)
1) ваши предложения? по стилю изложения?

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

2) я не пытаюсь "строго формализовать проектирование".
я предлагаю инструменты которые проверены на практике и должны на мой взгляд _заложить_основу_для_понимания_ более общих и _полноценных_методик_.

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

3) "Куда больше пользы было бы от формулирования пары предложений о том что надо сделать великим русским языком" - это возможно _ТОЛЬКО_ в том случае, если у вас существует "синхронизированный контекст" и вы понимаете одно и тоже. Но это редкость и заблужения о понятиях - это наичастейшая, если не повальная, ошибка разработчиков. "Мы составляем 2 фразы - а выясняется что заказчик услышал совершенно иное чем мы." - вот к чему чаще всего приводит такой подход.

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

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

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

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

5) диаграммы с наверное дополню и построю сквозной пример. с большими и понятными иллюстрацияими и описанием нотаций. Текущий вид даиграмм действительно мало-понятен.

_____________________
Спасибо за мнение.

Наживание денех на наживании денех

(18) Да, то что в 1С нельзя работать с конфигурацией программно - сильный тормоз разития 1це. ;-)

даже больший тормоз, чем отсутствие ООП

(28) рискую стать "свиньей в апельсинах" но предположу что ведушие проект не смогли пречечь "полет фантации заказчика".
Мы один из первых проектов завалили "и по этой причине тоже".

Управление требованиями - действительно одна из самых сложных областей.

Без контекста прошедших проектов о которых вы говорите - рассуждать мне далее  будет глупо. ретируюсь )

(30)
1. Откуда возьмется ORM для корреспонденции? Система сама догадается что мне это нужно и сделает? Или же я сам должен будут нарисовать этот маппинг объектов на БД? Если же я сам должен рисовать этот маппинг, то преимущества ORM мне не понятны, скорее в нем больше минусов, чем плюсов.
2. Откуда возьмется эта кнопка? Опять я ее должен делать сам? Тогда в чем плюсы Вашего подхода, раз я в любом случае все должен делать сам.
3. Не понял о каком нарушении целостности идет речь в случае ДОБАВЛЕНИЯ реквизита...

(31) ой. Смущён столь подробным и обстоятельным ответом.. тут у нас так не принято :)
Ну покритикую ещё, можно ?
по стилю изложения:
хотелось бы побольше конкретной информации и поменьше общих теорий
(вообще не представляю как это нуб сможет прочитать)
Первые несколько страниц вообще можно выкинуть ;)

И хотелось бы без терминологии, простыми словами...

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

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

А вот если можно как-то в схеме нарисовать и структуру документов/регистров и описать проводки и обозначить виды отчётов - было бы здорово. Я думал как раз кто-то и научился это делать в UML.

Раз Вы и правда это умеете - вместо описания терминологии интереснее было бы нарисовать значки и как они используются. В идеале даже с примерчиками :))
Те примерчики которые я видел (хотя не очень видел - мелковато) мне бы было затруднительно использовать для кодирования. Хотя я вроде не нуб...

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

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

(37) зацени http://www.rapidshare.ru/340581

(37) собственно для критики и предложения я это сюда и выложил и распространяю - заметьте - по свободной лицензии ;) )

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

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

(39) да, вот идея что не надо делать максимально подробное ТЗ очень понравилась

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

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

(40) сколько раз видел, как эти "не необходимые детали" превышали сроки основного проекта...
Красивая сказка, но насколько она реальна?

(40)
возможно (41) ? ))
вы пытаетесь натянуть представления о работе по ТЗ на идеи RUP.
Ничего не выйдет ;)

Ладно.. наверное(надеюсь) из примеров будет понятно, как уточняется задание и понимание о системе в процессе итераций, и как развивается система "отталкиваясь от прецедентов".

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

Во-первых, спасибо автору за труд.

Прочитав, понял, что основной упор делается на итеративности и обратной связи с заказчиком.
Вобщем то, это не открытие RUP.
Существует немало "свободных" методологий, например XP. Те же принципы - Игра в планирование, Заказчик на рабочей площадке.
Хорошо, что проиллюстрирован жизненный цикл и приведены конкретные документы и понятия. Однако все это можно и в книжке прочитать.
Не раскрыта заявленная тема. Т.е. вопрос - А при чем тут 1С?
Не увидел в методичке связи с 1С.
Не понял, как же модифицироваллась методика от использования ее в приложении к 1С.
Если никак, то смысл статьи только в одном - RUP можно применять при разработке на 1С.

>> Не раскрыта заявленная тема. Т.е. вопрос - А при чем тут 1С?
>> Не увидел в методичке связи с 1С.
>> Не понял, как же модифицироваллась методика от использования ее в приложении к 1С.
-->> (4)

>> ... смысл статьи только в одном - RUP можно применять при разработке на 1С.
В основном да - RUP можно и нужно применять при разработке на 1С. Кроме просто примера - это набор опытных средств и шаблон процесса.
это "конкретная реализация" , немного "перепрофилированная" на косяки 1С, с  рекомендациями и разъяснениями.

ещё, наверное - заполнение "методического" вакуума в области проектирования в 1С. (мёртворожденная "ТиповаяСистемаКачестваФранчайзи" - не в счет.)

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

_____________
я постараюсь подробнее разъяснть как это относиться к 1С в следующей редакции.

Спасибо за мнение.

+ (44) : я ещё (как я понимаю) несколько иначе работаю с прецедентами.
Возможно это не совсем к 1С относится, скорее к "упрощению системы" связанной с ориентацией на ручной труд, который уже "навязывается" профилем 1С.

(36) 1. А система не сможет "догадаться" средствами ORM. У нас что-то спор ушёл
уже от начальной темы. ORM как раз позволяет абстрагироваться от структуры
данных именно в терминах constraints (первичные ключи, внешние ключи, not null
и прочее). Первыми робкими шагами к этому в SQL стали, ИМХО, триггеры и
constraint check.
2. Да, кнопку должен делать ты. Именно за счёт того, что всё наилучшим образом
универсально не автоматизировать, и приходится ещё кое-что программить
самому :)
3. А если добавляемый реквизит - внешний ключ? :)

(38) Книга знаний: Использование методологии RUP для написания приложений на платформе 1С:Предприятие
это оно?

(31) как и обещал - более подробны

(37) как и обещал - более подробный ответ.

для начала формально отмахнусь от "мелковатости примеров диаграмм"

>>Те примерчики которые я видел (хотя не очень видел - мелковато) мне бы было
>>затруднительно использовать для кодирования.
а вы поставьте увеличение 400% при просмотре стр.12 - все стразу станет четко, понятно и букавки будут все читабельны. ;)

теперь болеее серьезно про то на что я не ответил.

>>Что такое статическая и динамическая структура так и не понял. Особенно
>>динамическая. И зачем мне это вообще было бы нужно знать не ясно.

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

>>Сценарии использования в 1С вообще имеют мало смысла, т.е. сценарий всегда
>>один и тот же - забей данные в документ, выведи данные в отчёт.
>>И текстом не вижу смысла это писать и уж схемы рисовать - тем более.
  гм... не согласен. имхо "забей данные в документ" - это допустимо только в случае "однопланового" документа или отчета с малым числом параметров.
  Когда звучит фраза вида "а вот если это аванс - он должен делать ЭТО" - начинаются "половецкие пляски". надо прописывать что в каком случае надо прописать что мы вводим, и что в каком виде хотим получить на выходе. В том или ином виде абстракции (см главу "развитие прецедентов").
 

>>А вот если можно как-то в схеме нарисовать и структуру документов/регистров
   см стр 12 документа в масшабе 400% ;) там есть и регистры, и документы и отчеты. обзорно, но описано как они связаны, на что влияет документ. Это кстаи поледняя версия модели. и именно этот проект я скорее всего буду разбирать в "иллюстрациях и примерах"
   Это конечно не UML - это "модифицированная ER-диаграмма". или "семантическая диаграмма" если это можно так назвать - ибо она отражает словесные представления заказчика о системе и составляется "real-time" со слов заказчика прямо на собеседовании призаказчике (важно что бы он видел что и как ты рисуешь - тогда проявляется основаня "прелесть" этой даграммы - заказчик зачастую начинает через 5 минут тыкать пальцами в твою бумажку и править диаграмму за тебя)
 
>>хотелось бы побольше конкретной информации и поменьше общих теорий
>>И хотелось бы без терминологии, простыми словами...
  гм... наверное я попробую просто получше описать примеры.
  теория нужна - т.к. в данном случае - важно (имхо) дать понять что то что мы будем делать - это только пример и "частная вариация" - только в этом случае нам удастся избежать "формализации проектирования".
  Я не думаю что реально свести этот документ до "рабочих инструкций".
  да и не стоит этого делать - потому что в этом случае это будет применение "в лоб", которое скорее принесет плачевные рузультаты.

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

  Вот эти вещи и надо моделировать. то как и с чем работает кодер - вопрос важный, "но как правило не здесь". не стоит мешать все в одну кучу.
  рассмотрим er-диаграмму - сперва мы должны описать представления заказчика (в идеале конечно сразу прикидывая что будет чем - что будет справочником, что документов а что вообще - строкой в лог-файле).
  НО! первоначальная ER-диаграмма не содержит таких привязок(только если заказчик не указывает явно - "это хочу чтобы было справочник" - но и надо думать о его адекватности - можно вообще сделать обработку в стиле регламентных форм отчетности 7.7); А то что приведено на 12-й стр - это результат двух недель возни и 3-х итераций работы.
  Иногда вообще сложно сказать КАК это реализовать и ЧТО это будет - тогда приходится добавлять дополнительные сущности и т.д. Как правило я прорабатываю реализационные моенты - после собеседования, в начале итерации.

+(49) +(50) кстати - первые диаграммы на стр 13 и 14 - ("диаграммы взаимодействия" и классов) - тоже смотреть в 400% увеличении ) они все с одного проекта и однйо итерации.

ещё в дополненение к (49)
>>Сценарии использования в 1С вообще имеют мало смысла, т.е.
>>сценарий всегда одинаков

пусть даже и так что он всегда одинаков.
но сценарии - играют ещё одну важную роль окромя того что они четко описывают границы системы.
- Они достаточно четко описывают функциональные требования и их количество. и даже если он такой типа "заполнить номенклатурой-провести" он должен быть. потому что если мы просто скажем "документ такой-то" то заказчик потом может начать говорть что ему нужен документ который будет ещё и остаток в статус строке отображать и ввод счет-фактуры реализовывать. в случае описания в стиле прецедентов - мы уже добавим 2 или даже 3 прецедента.
и уже будет более четкая связь - больше функций - дороже система.

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

Так Господа, прошу покорнейше меня простить, хорошего примера сегодня не будет. описать комментарии я не успеваю - надо спать.

Пока С КУЧЕЙ ОГОВОРОК (!!!) предлагаю вам на рассмотрение выдержки из проекта "согласование заявок".
http://www.liga1c.ru/projects/rup1c/sample1_2006.07.12_soglasovaniye_zayavok.zip

Проект формально стартовал 2005.07.12 (первая консультация)

На рассмотрение предлагаются документы:
(в хронологическом порядке. это не все документы, а те который я вытащил из демок к резюме.)

2005.07.18 итерация 1.   Документ "Собеседование". Задание на первую итерацию
2005.07.19 итерация 1;2. Документ "Собеседование". (между ит. 1 и 2)
2005.07.25 итерация 2.   Документ "Проект" до внесения изменений по второй итерации. Фактически 2005.07.18 (!!)
2005.07.25 итерация 2. документ "Развитие проекта". Окончание второй итерации.
2005.09.12 итерация n. Документ "Проект". Последняя версия в проекте.
____________________________________
Что я хочу чтобы вы увидели:

- примеры документов "Собеседование" и "Развитие проекта"
- как и чем отличаются док. "Проект" в версиях от 2005.07.25 и 2005.09.12
- диаграммы просматривать в увеличении 400%. тогда все что нужно вижно )
- различия в составе и описаниях прецедентов.

- док."Проект" от 2005.09.12 :: обратите внимание на вторую и третью диаграмму раздела "взаимодействие подсистем..." это достаточно важная часть которой нет в методичке... (а я не знаю почему... :( посыпаю голову пеплом... )
  Эти диаграммы - в некотором смысле "сборка прецедентов в бизнес-процесс".
  т.е. : Заказчика интересует как с помощью данного инструментария решать его проблемы - эти диаграммы должны собрать разрозренные прецеденты в единую последовательность и предложить типовые схемы применения системы.
  В следующей версии методички я постараюсь восполнить это досадное упущение.

____________________________________
Чего я не хочу что бы увидели. ( прошу смотреть на некоторые вещи снисходительно )

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

- не сильно-хорошие примеры прецедентов. Сейчас они мне не нравятся - но 2 года назад я видел многие вещи несколько иначе.
  Хотя с другой стороны, для первой версии (2005.07.25) их описать подробнее нет большого смысла ; а в версии 2005.09.12 они уже напоминают то что и должны напоминать - а главное - описывают то что нужно.

- док. "проект" от 2005.09.12 :: на цветовые маркировки пожалуйста не обращайте внимания - в то время они были наполнены неким тайным смыслом, который ныне утерян.

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

.
немного надо оговорить о понимании термина "прецедент".

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

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

Насколько этот подход хорош - надеюсь покажет время.