5611

Системный Анализ и Требования / Re: Рекомендации по анализу

« : 09 Марта 2007, 21:39:37 »

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

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

Вот еще пример. У нас в вузе эксплуатируется система "Студент". БД реализования на mysql, приложение на Access. Исходная реализация предложена человеком далеким от программирования как такового в то время, скорее большим любителем. Однако не плохо. На смену ему пришел человек, который в прошлом был любителем basic. С большим воодушевлением он стал дорабатывать систему, адаптировать ее и совершенствовать. Сейчас во все деканат система вндерена и признана ректором эталоном и приказом объявлена единственно возможной.
В личной беседе я пытался узнать существует ли какая-то общая концепция, структура системы, и т.п. Оказалось нет. Я намекнул на некоторый риск такой системы - система авторская и поддерживается и развивается только при наличии автора.
Предложил услуги реинжиниринга, составления описания системы. Получил отказ - всем система нравится, она внедрена, переделки не требует, возможно требует дополнительного функционала.
В данном случае - очень показательно - инициирование процесса переработки должно идти сверху, а не снизу. Правило уяснилось, "нечего вперед батьки в пекло лезьти".

Уяснил и второе правило: должна существовать четкая проблема или задача (тут надо оговорится problem по ангельски - это и задача и проблема, problem statement - постановка задачи). Решение задачи функционирования деканат (которая была поставлена моей студентки) как раз не хватало этой самой постановки проблемы (задачи). Заказчик хотел иметь набор красивых картинок, однако это оказалось не таким простым делом, картинки картинками - но содержание первично...

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

5612

Системный Анализ и Требования / Рекомендации по анализу

« : 09 Марта 2007, 09:29:59 »

а посты нужно уже в другие ветки переносить ... т.к. явно не про работу.

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

Спасибо за интерес к теме, но так просто тебе не отделаться:-))

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

Я понимаю It depends - такая сладкая формула. Понятно что нет общих универсальных решений, но есть спектр частных решений. Нет нужды приводить все возможные решения, но можно обсудить типичные. Умному достаточно!!!

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

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

5613

Книги, статьи и ресурсы / Re: Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.

« : 09 Марта 2007, 09:19:03 »

Вообще у меня есть серьёзные сомнения насчёт уместности термина "Анализ Приложения", о чём в принципе немного упоминают и авторы. Анализировать, на мой взгляд, можно только нечто существующее, как-то - Предметную область, Требования, Систему. Если же системы нет, она только создаётся, то можно её только синтезировать, проектировать, конструировать, но не анализировать.

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

Вообще не стоит путать понятие дейтельности, артефактов с собственно с моделью. Авторя ясно и многократно повторяют: есть три модели, три напраления моделирование: моделирование и модель структуры, модель состояний и модель взаимодействия.

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

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

На этапе анализа приложения формируется модель приложения, т.е. читай системы. Здесь по мнению авторов важным становится взаимодействие частей системы между сосбой и внешними пользователями. На данном этапе анализ продалжается, но уже сосредоточен на событиях, которые должны возникать при эксплуатации системы, при удовлетворении потребностей пользователей. Выделяются, обнаруживаются, понимаются, детализируются, то есть АНАЛИЗИРУЮТСЯ внешние события, нетипичные сценарии, исключительные ситуации, произовдится структуризация взаимодейстивия (что очень правильно, ибо на стади анализа предметной области такая структуризация будет только вредить и усложнять понимание, а на стадии анализа приложения - это уже внутреняя работа разработчика). Синтез никогда не происходит без анализа. Заметь у автора везде указывается: проверка того-то по тому-то, а проверка разве не есть анализ?

Кроме того анализируется как раз НЕЧТО существующее, т.е. некоторое умозрительное представление

5614

Системный Анализ и Требования / Рекомендации по анализу

« : 08 Марта 2007, 13:32:33 »

Интересно, автор объявления как-то прокомментирует тут фантазии завсегдатаев форума?

Участникам форума - Юрию и Сергею в первую очередь - есть вполне очевидное направление:
А. описание (краткое ясное без слюней) методик и методологий проектирования (RUP, EUP, Agile анд аверз)
B. более детальное описание, рекомендации по этапам и позициям процесса.
1. когда и зачем делаем бизнес-анализ
2. чем отличаются бизнес-требования от требований пользователя требований к системе, когда одно и тоже описание требования может фигурировать на разных уровнях под разными типами, почему. Какие методики сбора требований существуют, чем они отличаются, как реализуются, когда их следует использовать и почему
3. всегда ли требуются требования к системе? какие системы нуждаются в анализе требований, а какие нет.
4. с чего следует начинать анализ предметной о области: сначала понять требования или сначала построить структуру Пр Об, почему в одних случаях можно начать сразу с диагарммы классов, а в другом лучше пройти этап сценарии ВИ, диаграмм взаимодействия, а потом диаграмм классов
5. когда и почему можно вообще обойтись без понимания структуры классов, как накладывать результаты моделирования на конкретные системы программирования (скажем Дельфи, где все объекты так или иначе наследники TObject)
6. какую пользу дают диаграммы состояний - как они практически трансформируются в практическое решение?
7. кому и когда и чем полезна та или иная диаграмма, что помимо единого понимания системы дают все эти диаграммы.
8 насколько каждая диаграмма полезна, каково ее реальное время жизни, т.е. какие диаграммы следует считать вспомогательными, а какие основными - скажем так системоописательными. Насколько вообще следует уделять внимания на документирование моделей.
9 Что такое трассировка требований, как ее правильно проводит, как она проявляется на практике.
10. Есть ли четкие теоретические основы практики моделирования - или они основаны на наблюдении и эмпирическом опыте?

5615

Вакансии / Re: Ищется проетировщик 2000$ ~ 50-55 т.р.

« : 06 Марта 2007, 17:41:51 »

За знание теории СУБД нужно как минимум 5k платить )

Эк ты махнул. Там же написано опыт работы с Оракл, а знание теории СУБД (имхо имелось в виду теории РБД)

5616

О Сайте и Форуме / Re: Переместить темы с книгами в раздел обучение

« : 06 Марта 2007, 12:31:55 »

согласен, это дейстивтельно ближе к обучению

5617

Вакансии / Re: Ищется проетировщик 2000$ ~ 50-55 т.р.

« : 06 Марта 2007, 12:31:20 »

а контакты для связи?
Непосредственно с Вами?

5618

Книги, статьи и ресурсы / Re: Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.

« : 06 Марта 2007, 10:29:25 »

несмотря на то, что книга названа UML 2.0, в ней вообще не рассматриваются диаграммы компонентов и развёртывания

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

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

Так что? Это недостаток или достоинство книги?

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

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

Проблема корректного перевода действительно существует, но это не вина авторов, а переводчиков к сожалению или к счастию.

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

5619

Консалтинг и Внедрение / Re: ERP обзор

« : 03 Марта 2007, 23:56:20 »

Keen_G,
в следующем году (учебном), буду читать курс корпоративные информационные системы.
Не впервые, его читаю уже 3 года.
Раньше заставлял студентов делать рефераты на тему: КИС, технологий, направлений и т.п.
Теперь уж наверное заставлять не буду:-), Буду отсылать к твоим запискам. Может все-таки оформить его как обзор? Да еще с анализом от коллег? Ну и поместить в раздел авторских статей сайта.

5620

Консалтинг и Внедрение / Re: Прогноз на несколько лет

« : 01 Марта 2007, 18:20:39 »

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

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

5621

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 01 Марта 2007, 18:15:24 »

Для продолжения предложена такая схема рекомендаций:

Задание
   Скорректируйте свои презентации с учетом заданных вопросов и обнаруженных ошибок и неточностей.
   Идентифицировать проблемы.
   Точно и однозначно сформулировать бизнес-процессы в рамках установленной проблемы.
   Составить модель Действующие лица и их цели в рамках выделенных для анализа бизнес процессов.
   Дать краткое описание целей действующих лиц.
   Ранжировать (определить уровень действия) цели.
   Выделить основные понятия предметной области и функции Вашего бизнеса.

Рекомендации:
   Для идентификации проблемы используйте шаблон представленный ниже;
   Попытайтесь определить корневую причину проблемы или нескольких проблем.
   Проведите мозговой штурм с целью идентификации всех действующих лиц (потребителей Вашего бизнеса, Исполнителей Вашего бизнеса, внешних лиц так или иначе затронутых в вашем бизнесе);
   Проведите мозговой штурм по идентификации всех возможных целей действующих лиц;
   Проанализируйте модель Действующие лица и Цели. Удалите повторяющиеся цели, нечеткие цели, цели, не имеющие значения в контексте Вашей проблемы. Определите область действия Вашей цели:
•   Цели, достигаемые в течение длительного цикла (день, неделя, месяц, год);
•   Цели, достигаемые за один сеанс работы (до 1 часа);
•   Цели, поддерживающие выполнение выше названных целей.
   Дайте краткое описание цели или процесса, обеспечивающего выполнение цели. Уделите внимание конкретным фактам выполнения процесса, бизнес-правилам и ограничениям. Именно эта информация будет средством проверки правильности Вашего анализа и моделирования в дальнейшем. Вам следует четко описать все нюансы выполнения процессов;
   При выполнении задания используйте рекомендации и дополнительные материалы задания  №1 и 2

Надеюсь, что форумчане выскажут свое мнение, сделают пожелания и внесут конструктивные предложения

5622

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 01 Марта 2007, 18:11:49 »

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

А. Студенческое кафе "ВАССАМ"
Б. Магазин по продаже учебной литературы "Ботаник"
В. Изготовление мебели на заказа "Авандгард"
Г. Магазин продажи и проката видео "Avalon"

Общие впечатления: студенты увлеклись придумыванием бизнеса в целом и практически забыли о конкретных деталях.

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

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

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

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

Выводы:
1. Студенты восприняли задания как игру, пытались произвести хорошее впечатление, искренне были заинтересованы в результате. Тем не менее многие увлеклись и потеряли суть задания - построение достаточно точного и фиксированного бизнес-случая. Наиболее полным по заявленным требованиям (будут приложены ниже) оказался проект Б.

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

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

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

В качестве рекомендаций был предложен такой список (правда идея была не давать никаких рекомендаций):
   Какие цели у Вашего бизнеса (основное назначение бизнеса, его миссия);
   Что является предметом Вашего бизнеса (продукт, услуга, некоторая ценность, которую производит Ваш бизнес);
   Для кого Вы строите свой бизнес (кто является клиентом Вашего бизнеса);
   Какие функции и процессы необходимо реализовать для Вашего бизнеса;
   Что Вам нужно для организации бизнеса (финансовые, кадровые, информационные, материальные ресурсы);
   Кто будет исполнять или помогать в Вашем бизнесе (роли исполнителей);
   Описать требования к организации бизнеса (ограничения, документация, правила и нормы);

Также включил взятую из литературы схему описания бизнес-процесса:
   Название бизнес-процесса.
   Условия начала выполнения бизнес-процесса.
   Документы и данные, необходимые для выполнения бизнес-процесса и их источники.
   Документы, создаваемые в результате выполнения бизнес-процесса и их получатели.
   Действующие лица, принимающие участие в выполнении бизнес-процесса.
   Материальные ценности необходимые для выполнения бизнес-процесса, если таковые есть.
   Материальные ценности – результат выполнения бизнес-процесса, если таковые есть.
   Результаты выполнения бизнес-процесса (кроме вошедших в п.7).
   Цель данного бизнес-процесса, его место и роль в общих задачах (процессах) Вашего бизнеса.
   Проблемы, возникающие при выполнении бизнес-процесса.
   Нештатное завершение (выполнение) бизнес-процесса.
   Последовательность действий выполнения бизнес-процесса (типовое описание бизнес-процесса в произвольной и/или графической форме).

Кроме того были предложены вспомогательные материалы, прицепленные ниже для придумывания бизнеса с перспективой разработки ИТ-проекта

5623

Консалтинг и Внедрение / Re: Прогноз на несколько лет

« : 01 Марта 2007, 16:39:28 »

Интересный результат.

Если посмотреть общую тенденцию и принять во внимание некторую статистическую погрешность, видим очень стабильное состояние рынка и его доволно четкую стратификацию

Для меня стало новостью, что наши системы (1С) активно используется и зарубежом

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

Положение дел сохранится еще на приличное время

5624

Консалтинг и Внедрение / Re: Прогноз на несколько лет

« : 01 Марта 2007, 09:34:28 »

В качестве информации.

Я не могу считать себя специалистом в области ERP систем, хотя даже читаю подобный курс в университете, но вынужден чаще всего давать декларативную информацию о существующих КИС.

Правда имел некоторый опыт общения с Галактикой, ТБ Корпорация, 1с, BEST Office.

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

Другой пример - наша пивоваренная компания, вернее дочернее представительство Интербрю - так кажется.
3 года назад обратились в одну компанию для разработки конфигурации под 1с. Через год проект был сдан и вызвал огромный интерес на всех площадках отрасли. Однако сейчас они активно планируют переходить на SAP. Это обусловленно рядом причин, одна из которых корпоративное решение, т.е. руководство-то за рубежом и естественно стремится к единой платформе на всех своих предприятиях.

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

5625

Примеры / Re: Модуль учета, первые шаги.

« : 27 Февраля 2007, 21:03:45 »

ЗЫ: Просьба ногами сильно не пинать

А руками бить можно? :-)

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

Однако по порядку.
1. Что за ВИ мы описываем? Видно: обобщеный, по стилю описания прозрачный, тип бизнес процесс? Или все-таки системный? Мне думается смешение точек зрения в одном прецеденте.

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

3. Не очень понятно условие 3а, как оно согласуется с шагом 2 основного сценария и триггером - деньги уже либо перечислены, либо принесены

4. Условие 3б неожиданно сообщает нам, что клиент должен быть зарегистрирован в системе. С другой стороны это понятно, а как иначе можно перечислить деньги (есть клиент - значит есть виртуальный счет)

5. если следовать логике Коберна диаграмма ВИ фактически есть модель Действующие лица и цели, цели, которые они пытаются достичь, используя систему!
Как Вы сами указываете, Клиент не Основное действующее лицо, но он инициирует процесс. Непосредственно с системой работают Менеджер и Бухгалтер, следовательно для нас важны цели именно этих действующих лиц:
Менеджер: Сформировать платеж "Зачисление", Сформировать платеж "Оплата"
Бухгалтер: Подтвердить платеж "Зачисление", Подтвердить платеж "Оплата". Причем что примечательно, действия бухгалтера не имеют самостоятельного значения - они должны быть произведены в ответ на создание документов Менеджером. Я бы вероятно выделил два ВИ Принять деньги клиента - Оформить оплату, где участвуют помимо системы менеджер и бухгалтер - как видно из постановки задачи - жить они не могут друг без друга.

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

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

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

Далее как я понимаю оплата услуги совершается постфактум, т.е. когда услуга оказана? А если так, кто мешает оплатить услугу на основании документа "Оказанная услуга" .

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

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


Итого. Вариант использования в целом - 4 "хорошо", Диаграмма вариантов использования - "посредственно". Но это только мое мнение:-)