91

Для всех / Re: Диаграммы UML для бизнес-процесса "Кредитование физических лиц"

« : 09 Декабря 2014, 08:34:42 »

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

Фантазировать человеческие и бизнес-взаимодействия через ДВИ имхо не путь джедая:)

92

Работа / Re: О переквалификации: из аналитика в тестировщика

« : 04 Декабря 2014, 15:54:05 »

Это на основе чего вывод?
По объему вакансий - тестировщиков требуется больше, чем аналитиков.

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

93

Работа / Re: О переквалификации: из аналитика в тестировщика

« : 04 Декабря 2014, 13:16:02 »

Знаю кучу людей которые перешли из тестировщиков в аналитики, но ни одного который бы перешел обратно.

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

94

Обсуждение статей / Re: О профессиональных стандартах в области ИТ

« : 04 Декабря 2014, 12:08:28 »

Профессиональный стандарт системного аналитика утверждён министром труда: http://school.system-analysis.ru/2014/12/03/profstandart/

Спасибо за труд, прочитал с большим интересом!

Немного резанул глаз  косяк с нумерацией на 21 странице.
Идет 3.2.13, затем внезапно 3.3.14, потом снова нормально 3.2.15.
Он уже в таком виде и утвержден?

95

IDEF ARIS BPMN и пр. / Re: BPMN диаграмма предоставления отпуска сотруднику

« : 03 Декабря 2014, 17:05:24 »

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

И по поводу выплаты отпускных опять. А если дата расчета отпускных между 31 и 6 числом, но з/п приходится менее чем за три дня до отпуска? По закону в таком случае работодатель должен выплачивать не в день з/п, а самое позднее за три дня до отпуска.
Подумайте еще над схемой выплаты, ее надо переделать.

96

Обучение / Re: подскажите студенту

« : 03 Декабря 2014, 16:59:23 »

Мне кажется БАБОК и СВЕБОК тяжеловато для начинающего.
Я бы посоветовал начать с отечественной книжки "Путь аналитика"

97

IDEF ARIS BPMN и пр. / Re: BPMN диаграмма предоставления отпуска сотруднику

« : 01 Декабря 2014, 09:18:19 »

Уважаемые профи! Покритикуйте пожалуйста диаграмму. Спасибо.

Добрый день!
Есть несколько замечаний.

1.Почему при выборе срока планового отпуска используете включающее ИЛИ? Может надо исключающее?
2.Почему при выборе отпуска за свой счет нет вариантов продолжительности?
2.1.Взять на 3 или 4 недели отпуск нельзя? Только 1 или 2 недели?
3.Забыли написать имя события-таймера.
4.Если разветвляете выбор типа отпуска логическим оператором, надо синхронизировать его до того как переходить к событию-таймеру.
5.Использование включающего ИЛИ при расчете отпускных предполагает что отпускные могут перечислять частями, часть в аванс, часть в ЗП. Так и задумывалось? Не противоречит ли это бизнес-правилам компании?
6. Исходя из схемы, получить отпускные сотрудник может только или в аванс или в ЗП. А что если он написал заявление на отпуск после аванса, но уходит в отпуск до ЗП?
При условии, что оплата отпуска производится не позднее чем за три дня до его начала.

98

Вакансии / Re: В Питере окрыто несколько вакансий системного аналитика (ищем джуна и мидла)

« : 29 Октября 2014, 09:55:56 »

По мне так очень мило написано. Искал бы работу - сходил бы!

99

Обучение / Re: Инструментальные средства информационных систем

« : 06 Октября 2014, 16:01:26 »

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

Мне кажется, вы начали плясать не с того конца.  Я бы начал с классификации инструментов в соответствии с жизненным циклом ИС.

Я этот ЖЦ представляю так:

1. Проектирование системы.
2. Разработка и внедрение системы.
4. Эксплуатация  системы в окружении.
5. Ликвидация системы.

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

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

100

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 03 Октября 2014, 12:46:39 »

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

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

Там Записать примечание, а что не понятно, кому примечание пишется?

Да, именно. Т.е. если записать примечание к оценке, то я бы поместил его в CRUD оценок. Если примечание к ДЗ - в CRUD  к ДЗ.
Сразу схема становится  проще к восприятию.

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

101

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 14:00:54 »

Если не считать того что я уже писал про компоновку CRUD (благодаря которой можно было бы уместить всех акторов на одной диаграмме:)), могу заметить следующее:

1.Выйти/войти - вообще не ВИ.
2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а  не одинаковые, но это к самой диаграмме не относится.
3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?
4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.

102

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 21:29:38 »

- случайный дубль

103

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 21:29:22 »

Ага При этом еще у каждого подпотока ведь могут быть какие-то свои альтернативы, нехарактерные для других.

Конечно.

Просто у меня у самого мало настоящего практического (живого) опыта. Только академический. Хотя студенты играют по-взрослому, но все равно есть искусственность.

У меня с практикой тоже не фонтан. Ни заказчики ни разработчики UML не знают, так что я рисую и пишу не по нотации, а чтобы людям понятно было:)

104

Sparx / Re: Удобное отображение пересечения связей на диаграммах в среде Sparx EA

« : 30 Сентября 2014, 21:14:59 »

Я хоть и рисую диаграммы в Visio, а не в Sparx, но пересечения через мостик все равно уродливые.
По этому я всегда так позиционирую элементы диаграммы, чтобы стрелки не пересекались.

А на диаграмме из примера так это вообще очень легко сделать:)

105

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 21:10:59 »

Каждый ВИ обладает определенной целостностью и имеет общие предусловия и постусловия.
Скажем, ясно что изменение расписания невозможно, пока не будет создано само это расписание. Как это все увязывается в единой спецификации варианта использования?

Я кажется понимаю куда вы клоните!
По определению, ВИ - это ровно один прецедент использования системы. Т.е. или создание или редактирование или удаление.
При такой декомпозиции очень просто определить основной поток прецедента и альтернативные.
Например, основной поток - удалить расписание. Если расписаний нет - это уже альтернативный поток.

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

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

Это вы спрашивали?