871

Примеры / Re: СКУД в школе

« : 11 Ноября 2013, 19:28:21 »

Может это поможет в дискуссии.
Рекомендации по написанию спецификаций вариантов использования. Это выжимка из книги, авторы которой весьма известные в западных кругах тренеры.

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

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

872

Работа / Re: Банальная просьба оценить скиллы :)

« : 11 Ноября 2013, 19:18:02 »

Я думаю Вы вполне можете себя попробовать.
1. имеется опыт работы
2. риск-менеджмент - должен сочетаться с аналитическим складом
3. знание языков плюс

Если работа будет связанная с системами для банковской сферы, то добавляется глубокое знание предметной области и изнутри.
Если не найдете себя в ИТ-аналитике может станете продукт менеджером?

873

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 11 Ноября 2013, 19:11:44 »

Эд, а посмотри: http://blog.shumoos.com/archives/288
Это гипотеза, но довольно вероятная.

Может быть трудно сказать. Ясно, что размещать их в ТЗ не следует. Но оговорюсь, у того же Вигерса ТЗ идет следом за ВИ, а не наоборот. При ВИ у него вытекает из Образа решения.

874

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 11 Ноября 2013, 19:05:31 »

Я искренне не понимаю, зачем в ГОСТе искать место тому, что там не предусмотрено.

Я пытался сказать в первом посте, что студенты делают выпускные работы, придерживаясь методических указаний, которые представляются собой компиляцию из ГОСТ. А в проектировании используют UML и в том числе варианты использования.

Потому и хочется соединить, как ты выражаешься несоединимое.

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

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

875

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 09 Ноября 2013, 15:23:41 »

Business use cases — в требованиях пользователей (stakeholder requirements)
System use cases — в ЭП/ТП

Спасибо. Денис. А как на твой взгляд будут отличаться BUCs от SUCs, Есть подозрение, что сделать это студенту будет не просто, а преподавателю -руководителя тоже. Понятно, что критерием будет контекст.

Тем не менее, следую твоим советам, варианты использования следует помещать в область технического проекта. А в каком разделе? Схема функциональной структуруы?

876

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 08 Ноября 2013, 23:51:46 »

Для начала нужно понять что в ГОСТ подразумевается под требованиями пользователя к АС.... это скорее то что называется stakeholder requests в RUP.

Юра, а зачем понимать. Мы достаточно опытные люди и можем определить этом место сами.

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

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

В любом раскладе мы можем пофантазировать, подумать и определить место ВИ в пояснительной записке. Где? в Части формирования требований пользователей, в части формирования концепции, в ТЗ или же все-таки в техническом проекте?

877

Варианты Использования (Use Case) / Место вариантов использования в ГОСТ 34

« : 08 Ноября 2013, 20:32:27 »

Мы в вузе используем ГОСТ 34.601-90. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ. при выполнении курсовых и дипломных работ.

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

Типично размещают их в техническом проекте, как часть функциональной схемы. Однако мое мнение, что эти ВИ лучше размещать в 1. Формирование требований к АС, в пункте 1.2. Формирование требований пользователя к АС.

А у вас какие мнения?

878

Для всех / К вопросу о термине "анализ"

« : 08 Ноября 2013, 20:13:45 »

К сожалению по моей неосторожности и невнимательности в теме СКУД в школе, разгорелся спор, в результате которого страдает тема и страдают люди.

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

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

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

Судя по ссылке: http://students.mimuw.edu.pl/~zbyszek/posi/ibm/RUP_Eval/, Виктор прав. Прав ли при этом RUP, вопрос для дискуссии.

879

Примеры / Re: СКУД в школе

« : 07 Ноября 2013, 21:59:00 »

Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?

А какой смысл в actors без вариантов использования?

А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?

880

Примеры / Re: СКУД в школе

« : 07 Ноября 2013, 10:13:01 »

Я никого не считаю идиотами, без шуток.

Виктор, простите мой моветон. Конечно, это просто оборот речи, некая эмоциональная краска.

Книга Коберна "Writing Effective Use Cases" на русский переведена как " Современные методы описания функциональных требований к системам". В рамках RUP и Open UP написание сценариев ВИ и составление диаграммы ВИ отнесены к процессу определения требований. В рамках Agile UP сценарии ВИ и диаграммы ВИ являются частью модели требований. Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.

Опять же, может я не прав (да и обсуждение темы оффтоп для данного треда), но разве сбор и описание требований не являются частью анализа - аналитической деятельности? Или Вы здесь вкладываете совершенно определенный смысл - создание аналитической модели и именно в контексте ООАД?

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

На самом деле не утверждаю, что это обычный путь. Хотя некоторые так делают, я бы остановился на уровне просто БП, без перехода на бизнес-ВИ.

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

Насчет книги. Она не случайно называется системный анализ и проектирование с припиской с помощью UML. Т.е. тут описаны процессы системной инженерии, а UML лишь приложение. Может потому у Вас возник определенный диссонанс?

881

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 22:41:19 »

Просто в книге описывается, как и вы говорите, с построения use case specification. Но у нас все как то наоборот, сначала мы строим диаграмму, по ней создаем use case diagram,  далее идет use case specification и в конце уже class diagram. В виду этого я поэтому так и делаю) Даже если вы посмотрите на задания, в каком порядке они идут то заметите что я начал по задачам курсовой.
Спасибо за время, сегодня сделаю тогда диаграмму только получения доступа. Отправку отчета и запись тогда отложу на попозже.

Конечно, я не знаю, что Вам преподают и как, но есть такой довольно распространенный подход.
1. Изучив предметную область, построить диаграмму деятельности для описания бизнес-процесса (типично используют диаграммы BPMN)
2. Этапы такого бизнес-процесса выделяются и определяются как варианты использований
3. Совокупность вариантов использований и акторов, им соответствующих, образуют диаграммы ВИ
4. Каждый ВИ специфицируется до основного и альтернативных потоков
5. Для каждого ВИ возможно строится диаграмма классов, участников данного ВИ (обычно такие классы делать на сущностные, граничные и управляющие)
6. Частные диаграммы классов объединяются и образуют общую диаграмму классов
и т.п.

Может что-то подобное и в вашем случае?

882

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 22:34:57 »

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

Наверное, Вы правы, но если я не ошибаюсь эстетика и прагматика спецификации UML2 предполагает использование decision и merge node для разделения и слияния потоков управления, типа в одну activity или action две стрелки входить не должны. Прагматика насколько я понимаю проистекает из того, что теперь понимается под диаграммой деятельности, а именно сеть Петри, а не вырожденная диаграмма состояний.
Но, могу заблуждаться.

883

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 22:29:14 »

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

Виктор, простите, может я такой же идиот из Индианы, но в чем проблема отнесении ВИ и ДВИ к стадии анализа?

884

Для всех / Re: Нужна помощь по бюджетам

« : 02 Ноября 2013, 19:26:24 »

Попробуйте посмотреть в сторону ПФР - по нему есть много открытой информации как по бюджету (план), так и по его исполнению (годовые отчеты ПФР).

Спасибо за идею. Посмотрел, наверное это поможет.

885

Для всех / Нужна помощь по бюджетам

« : 29 Октября 2013, 17:00:56 »

У нас в вузе принята такая норма. Студент летом проходит технологическую практику, изучает предметную область, пишет ТЗ, а потом в ходе первого семестра 5 курса пишет курсовую работу по специальности по теме его практики.

Есть отчет по практике, но он так ужасен, что мне стыдно его выложить.
В рамках практики было предложено ознакомится с программами по бюджету http://www.keysystems.ru/products/budget-execution/, но практика была крайне формальна, соответственно и ТЗ и отчет еще формален и бесполезен.

Думаю, думаю, придумал студенту тему
Разработка системы учета оборота денежных средств бюджета организации методами MDA технологии

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

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

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