481

Задачи студентов / Re: Диаграммы UML для Библиотеки

« : 27 Декабря 2013, 15:34:55 »

Согласен, что можно в просторечии так сказать, но даже здесь мы говорим База данных ГИБДД, на самом деле понимая целую систему. Однако студенту - это противопоказано. Пусть сначала научится теории следовать.

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

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

482

Задачи студентов / Re: Подскажите с описанием функций подсистемы и выбора цели автоматизации

« : 06 Декабря 2013, 16:12:06 »

   
Объект автоматизации и подсистемы как их  описать от чего отталкиваться.

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

483

Методологии / Re: Положение о контроле соответствия требованиям

« : 29 Ноября 2013, 19:05:57 »

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

Я чувствую, следующим Вашим топиком будет "Организация N желает подешевле "написать" проект Постановления Правительства.

Первый совет - воззвать к разуму озадачивающих.
Второй, если первый не подействует, то поискать:
- примеры технических регламентов (как упомянуто в ответе Nanaly);
- стандарты качества 9000 серии (на предмет работы с документами, например);
- административные регламенты предоставления каких-нибудь нескольких госуслуг (как прописаны разделение ответственности и оргвопросы).
- прямые аналоги в других сферах деятельности;
- нормативные акты всяческих регуляторов.

Из суммы всего этого теоретически можно родить приличное организационное решение. Теоретически. После энного количества собранных грабель. Оно Вам надо?

484

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 21 Ноября 2013, 16:22:19 »

То при чём тут user story? Тут, как говорится, надо или крестик снять или трусы надеть.

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

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

485

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 21 Ноября 2013, 14:00:43 »

Какая разница, куда вы вставите и как назовёте?

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

486

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 21 Ноября 2013, 13:54:26 »

Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.

В "Приложение [буква]".

Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?

Если в истории будут слова, что пользователь посидел на стуле, входящем в комплект АРМ, и почитал Положение об отделе, в котором он работает, а потом поклацал кнопками (или наоборот) - то ко всей системе. Если только поклацал - можно к ПО.

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

Да. Но конкретное ТЗ(ЧТЗ) - про вполне конкретные составляющие системы.

487

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

« : 18 Ноября 2013, 11:45:21 »

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

Так и я не подписывался. Я говорил про такую распространенность явления, которая успешно продвигает новые методологические решения. Переход, так сказать, количества в качество.
Наличие "разных" никаким сомнениям не подвергаю.

Ну так ровно тоже можно сказать о DFD, BPMN, IDEF0 и IDEF3.

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

А из каких по Вашему кубиков должна состоять тогда пояснительная записка?

Из одинаковых. А каких именно - это уж как договоритесь.

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

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

Ага, первая фраза на работе- забудьте то, чему вас учили в вузе. У нас все по другому. Потому не стоит видимо и пытаться.

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

488

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

« : 14 Ноября 2013, 23:30:45 »

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

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

Т.е. Вы полагаете, что до введения ВИ у студентов было системное мышление и их этому учили? Можно подробнее о наблюдениях?

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

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

1. Вы не совсем поняли. Есть методуказания по оформлению и требования к содержанию. Они есть аля ГОСТ 34...
2. UML в методичке не прописан, методологии по которым им следует разрабатывать свои проекты тоже. Так что нет никаких скрещиваний.
3. Проблемы возникают при оформлении работы. Это да. Вот я и поднял дискуссию, чтобы пройтись по этой теме.

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

4. То, что студенты приходят на "производство" (это слово уж точно не для ИТ-индустрии)

Почему? Можете раскрыть мысль?

и делают не так как ожидает "производитель" - ну эту песню я слышу всю свою жизнь. Не подумайте, что СССР, потом Россия, так уж уникальны в этом, при всей феншуйности западного образования.
5. Ну впрочем эта очень философичная тема и я ее поднимать здесь не хочу. Без обид, Леонид?

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

489

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

« : 14 Ноября 2013, 13:11:28 »

В моем понимание ТП - это архитектура решения. СВИ - это требования уровня пользователя. Поэтому я придерживаюсь позиции:
В ТЗ пишем кратко состав функций, а в приложении ДВИ и спецификация.

(на правах примечания, а не вторжения в частное мнение)

В понимании ГОСТ, ТП - это всеобъемлющее описание проектируемого решения. Включающее в т.ч. и архитектуру, которая в норме составляет довольно небольшую часть ТП.

"Масштабы" ТП можно оценить по совокупности ГОСТ 34.201-89 и РД 50-34.698-90.

490

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

« : 14 Ноября 2013, 11:10:22 »

Эдуард, я как раз тут (http://it-analysis.blogspot.ru/2013/10/use-cases-34.html) излагал свои мысли по этому поводу.

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

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

491

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

« : 14 Ноября 2013, 10:44:20 »

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

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

1. Описания ВИ применяются в "Программе и методике испытаний" (код "ПМ") в качестве методов проверки системы на соответствие требованиям ТЗ.
2. Диаграмму ВИ можно применять в том же документе для пояснения, каким образом решены  задачи разработки системы (из раздела 2 ТЗ), но будет избыточный "бантик".

Соответственно, где-то между стадиями "Рабочая документация" и "Ввод в действие". В зависимости от того, на какую стадию конкретного проекта запланирована разработка ПМ.

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

Переход от системного мышления к "клиповому". Наблюдаю то же самое в среде "молодых специалистов".

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

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

Мое мнение, что ВИ - суть сырье для разработки требований, один из источников. И если очень хочется включить исходные материалы в дополнение к требованиям - почему бы и нет? ГОСТ не запрещает. Можно и в упомянутые документы, и в ТЗ, и в технорабочий проект (как минимум, в качестве приложений). Другое дело, что это не сильно нужно, может вызвать соответствующие вопросы и увеличивает объем документации, не увеличивая ее содержательное наполнение.

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

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

492

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

« : 08 Ноября 2013, 10:12:20 »

Если позволите... С точки зрения практики, это разумный, дельный совет.
С формальной точки зрения можно указать пример, когда два фрагмента будут неэквивалентны.
...
В случае не исключающих друг друга сторожевых условий guard1 и guard2 в 1-м фрагменте можем получить два параллельных потока, если условия истинны одновременно. Во втором фрагменте в тех же условиях будет единственный поток -- либо верхний, либо нижний, выбранный случайным образом.
Первому фрагменту полностью эквивалентен 3-й:
...

Все верно. Нужно изобразить параллельные потоки - формулируем неисключающие условия.  Нужно "один из" - взаимоисключающие.

493

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

« : 07 Ноября 2013, 09:07:45 »

Что если просто добавить действие чтение после использования?
Вот так:

Если выделять отдельное действие, то тогда возникает вопрос, почему бы не сделать "классически"? То есть, сначала считать карту, а затем авторизовать ее по правилу "Тип карты" ИЛИ ("Время прохода" И "Локация").

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

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

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

494

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

« : 06 Ноября 2013, 17:37:06 »

Вот такой сейчас вариант

Осталось уязвимое место. Ветка "полного доступа" отрабатывает до проверки прав. Это не есть хорошо. Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.

495

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

« : 06 Ноября 2013, 16:32:50 »

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

1. Отправка отчета Вам не нужна, это другой процесс.
2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб.  Модель получится симметричной.

Что такое "Save data"? Почему недостаточно "Record"?