Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
211
или какова сейчас ситуация на рынке труда в целом?..

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

Работодателей пугает начавшийся кризис. Кое-кто уже занялся "оптимизацией" aka сокращением штатов. Скорее всего, всё действительно будет только хуже.

212
Мы, помнится, тоже всю аэродинамику прошли за одну пару. :)

213
Доброго времени суток. Решил я написать сайт для магазина моего дяди и всё это представить, как курсовой проект в университете. Преподаватель посоветовал начать с UML диаграммы. Вот что у меня получилось. Прошу указать на мои недочеты и чего еще не хватает.

Есть хорошее правило: начинать названия вариантов использования с глаголов. Это сразу меняет подход от абстрактной возможности к конкретной цели, которой хочет достичь пользователь.
То есть не "Просмотр страниц", а "Просматривать страницы", не "Пользователи управление", а "Управлять пользователями".

Ещё одно хорошее правило: представьте, что разрабатываемая система содержит только кнопки, нажимая на которые пользователь достигает своей цели. "Найти товар", "Заказать товар", "Оплатить товар".
И тогда возникают вопросы вроде такого: а вы бы стали нажимать на кнопку "Просматривать страницы"? Есть ли у вас, как у посетителя интернет-магазина, такая цель?


214
Искать по ключевым словам "анимация CSS3".

215
Обязанности:
•   Доработки и дополнительные настройки по задачам, поставленным бизнес-пользователями;
•   Ведение и курирование проектов по доработке АБС и информационных систем;
•   Написание скриптов для администрирования приложений;
•   Предоставление и гарантирование уровня поддержки основных (Инверсия XXI ВЕК, Siebel) и вспомогательных приложений (интерфейсов, средств сверки, и т.д.);
•   Поддержание актуальности версий и сопровождение программ отчетности;
•   Реализация выгрузки данных и предоставление инструментов для самостоятельной обработки выгруженных данных бизнес-пользователями;
•   Поддержка тестовых окружений и копирование данных из «боевых» систем для разработки, отладки и тестирования;
•   Организация процесса тестирования и переноса изменений в промышленные среды;
•   Отладка и тестирование измененного функционала;

Как в том анекдоте: "а если ко мне швабру прицепить, то я вам тут ещё и полы помою".

216
Группа Компаний «Эверест Монтаж» занимается комплексным снабжением трубопроводных систем газоснабжения, водоснабжения и канализирования.

Отраслевое решение ELMA способствует достижению этих целей через организацию единого сквозного процесса.

На сегодня это, безусловно, лучший пост на форуме. :)

217
Гриша, а на чем зиждется такое утверждение. Очень интересно.

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

Для веб-сайтов сценарный подход тоже оказался неприменим. User Stories возникли не случайно. Это откат назад по сравнению с Use Cases: мы отказывается описывать конкретные сценарии взаимодействия пользователя с системой, оставляя только его цель.

Я буквально вчера отчасти об этом в своём курсе рассказывал, и только что выложил ту часть вебинара, где немного об этом говорю. В частности, почему Вигерс в качестве основного документа требований второго уровня выделяет спецификацию вариантов использования: https://vimeo.com/88255472

Фрагмент получился довольно длинным (40 минут), а собственно рассуждения на эту тему начинаются с отметки 21:58. Хотя я его пересмотрел и обнаружил, что в моих примерах тоже постоянно фигурирует понятие сценария. Но я его понимаю более широко, чем "заданный порядок взаимодействия".

218
Я высказался о производственных процессах, в которых основным результатом труда аналитика являются сценарии. Если бы таковых не было, высказываться было бы не о чем. Если бы таковые не применялись все шире, высказываться было бы незачем.

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

219
Допустим я делаю классификацию животных при помощь диаграммы UML.
     Можно ли нажатием на конкретный класс/вид просмотреть все его родовые и видовые отношения?
                 Пример: ПОЗВОНОЧНЫЕ
                                род: Животные
                                         Многоклеточные
                                вид: Рыбы
                                        Земноводные... (и т.д.)

То есть можно ли (помимо UML диаграммы) видеть данные отношения в виде списка. Когда интересует только отдельный объект/класс


Сам по себе язык UML задаёт формат для описания диаграмм. В нём нет понятий вроде "нажатия на определённый класс".

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

220
• Опыт написания ТЗ (высокая скорость, навык создания 1 ТЗ в день);


Какая прелесть! Утащу в фейсбук, пусть аналитики поплачут.

221
Примеры / Re: Полный комплект UML диаграмм
« : 23 Января 2014, 12:20:16 »
Доброго времени суток.

Есть проект, который будет включать в себя программно-аппаратный комлекс. Сам я программист. С такими большими проектами дел не имел. До этого справлялся наброском "в тетрадке". Однако, теперь без UML не обойтись. В сети нашёл множество сайтов по этой тематике. Однако, между ними множество различий, которые со стороны вовсе не понятны. Пытаюсь составить диаграммы в Visio 2010. Возникает множество попутных вопросов, которые хаотическим гуглением не решаются, а наооборот запутываются.
Вроде это полный комлпект UML диаграмм:
  • Use case diagram (диаграммы прецедентов)
  • Deployment diagram (диаграммы топологии)
  • State Maсhine diagram (диаграммы состояний)
{Statechart diagram (диаграмма состояний) / Activity diagram (диаграммы активности)}
  • Interaction diagram (диаграммы взаимодействия)
  • Sequence diagram (диаграммы последовательностей действий)
  • Collaboration diagram (диаграммы сотрудничества)
  • Class diagram (диаграммы классов)
  • Component diagram (диаграммы компонентов)
Без чего из этого списка можно обойтись, а что нужно обязательно?

P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.

Зависит от цели, которую вы перед собой ставите. Если нужно моделировать устройство и поведение объектов, то самые распространённые и удобные:
- диаграмма состояний (state machine diagram aka диаграмма конечного автомата), показывающая возможные состояния объекта и пути перехода из одного состояния в другое;
- диаграмма деятельности (activity diagram aka блок-схема алгоритма), показывающая последовательность выполнения и условия переходов;
- диаграмма последовательности (sequence diagram - неудачное название), показывающая порядок взаимодействия между объектами.

Диаграмму последовательности правильнее было бы назвать диаграммой взаимодействия (interaction diagram), но это название уже оказалось занято другой диаграммой, которую использовать я очень не рекомендую из-за её неудобочитаемости. Они показывают одно и то же, но sequence diagram использует ось времени для изображения последовательности действий, а на interaction diagram порядок действий показывается цифрами возле стрелок - читать невозможно, буэ.

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


Для более высокого уровня абстракции (обзор системы, выявление требований) ещё очень полезны диаграммы:
- диаграмма вариантов использования (use case diagram) - позволяет проиллюстрировать, что кому из пользователей нужно от системы. Приверженцы модели use case в этом месте могут возмутиться, но imho возможности применения этой диаграммы простираются далеко за пределы собственно вариантов использования. С её помощью можно анализировать и возможности, и функции, и ожидания от системы, и ещё много чего.
- диаграмма развёртывания (deployment diagram) - позволяет проиллюстрировать, как логические объекты соотносятся с физическими (например, какие программные компоненты на каких серверах выполняются).

Если нужно документировать нижний, программный, уровень, то пригодятся диаграммы классов и пакетов. Они, на самом деле, тоже были изобретены до UML, но тут уже следование нотации может оказаться полезным. Это не столько диаграммы, сколько визуально структурированный текст.

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

222
Я бы большую часть этой диаграммы преобразовал в диаграмму вариантов использования (с человечками-экторами) и не побоялся представить функции в виде овалов-целей.
Раздел "Веб-интерфейс" - это про сайт или про API? Если про сайт, то его лучше бы представить в виде иерархической структуры страниц сайта. Или не иерархической.

Непонятно, кто управляет торгами: рассматривает заявки на проведение торгов, запускает торги, останавливает.

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

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

Очень большое внимание уделено процедурам регистрации. Имеется в виду регистрация в каких-то гос. органах?

223
Моделирование статусов - это по определению диаграмма состояний (aka диаграмма конечного автомата). В данном случае последнее поле представляет собственно статус, а остальные - атрибуты, которые могут порождать дополнительные статусы (например, если фамилии обозначают сотрудников, а не заказчиков, то могут появиться промежуточные статусы, ожидающие назначения сотрудников).

Другое дело, что в задании речь собственно о "моделировании статусов", возможно, и не идёт. Но постановки задачи как таковой и нет.

224
Не надо только дублировать эту тему в разных ветках, до нас и с первого раза дошло. :)

225
Примеры / Re: Нужна помощь, срочно
« : 15 Декабря 2013, 23:00:59 »
Началось сезонное воспаление хвостов у нерадивых студентов.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »