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

×


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

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


Сообщения - Виталий Григораш

Страницы: « 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 »
301
А я, как МП, еще больше рад, что нам выделили супер Дизайнера с другого проекта, чтобы сдать проект во время ;)
:) Договорились... Жду спеки и сроки...

302
Коллеги Аналитики,
Будем делать то, что Виталий предложил? Хватит сил? Мне кажется идея очень хорошей!
Так как я люблю на досуге порисовать, могу выступить в роли дизайнера и "кодера", и по вашим спекам попытаться сделать такое "кликабельное чудо". Заодно проверим качество спеки. Что скажете?

303
Ты хоть название сказал бы программки, кот. тебе "очень понравилось" ;)
Вот список программ.
http://c2.com/cgi/wiki?GuiPrototypingTools
Я себе поставил триалку GUI Design Studio и посмотрел демку iRise Application Simulator, тоже понравилось. Если покопать поглубже, то можно наверное что-нибудь бесплатное найти

304
Ребята, признаюсь честно, не читал весь топик с самого начала, но у меня есть небольшая идея.
Напишите вы концепцию, потом Варианты использования и другие требования, а кодировать никто не будет. Так вот, если вы будете писать требования к UI, то вместо кодирования можно сделать кликабельный интерфейс, в котором описать бизнес-логику, те щелкнул туда, появилось то, щелкнул туда - это. Такой прототип можно использовать как фикцию сдачи продукта заказчику, и соответственно, смоделировать процесс управления изменениями. Сейчас есть много программ для создания подобного рода прототипов. Недавно покопал одну - мне очень понравилось. Причем в некоторых из них даже есть что-то типа базы данных :)
Извините за оффтоп, просто мысли в слух.

305
Потренировать - интересно. :)
Участвовать - уже наверное нет...
Может что-нибудь тогда расскажите на очередном семинаре в Петербурге?

306
Виталий, правильно ли я Вас понял, что для вас основным критерием принятия решения является "нужность" изменения?
Т.е., допустим вам заказчик говорит: "хочу A, B, C". Вы говорите: А - не нужно, B - бантик, а вот С - "действительно нужная" фича, делаем.
А на основании чего? Как вы заказчику мотивируете, что его запросы A и B вы посчитали ерундой и отклонили?
К сожалению я этим не занимаюсь, поэтому всех деталей работы с заказчиком я рассказать не могу. Думаю здесь вступает в силу закон "Учись говорить нет". Можно всегда объяснить, что менее важное требование можно отложить до лучших времен и сделать акцент на более важных моментах. Думаю это зависит от конкретного заказчика. Бывают "самодуры", которые бантики считаю наиболее важной фичей, чем например построение отчетов, аутентификация и тп. Можно объяснить, например, что сейчас вы сможете решать свои проблемы без данной функции, а в дальнейшем (в сл. релизах) мы обязательно это сделаем. Думаю заказчик, то же не будет рисковать тем, что у него появиться бантик, но не будет работать основная функциональность.
Преподаватель на курсах по аналитике (он сейчас ПМ), рассказывал, что прямо обрезал заказчика и говорил, что новое требование выпадает из скоупа, и что для его реализации мы либо:
1. Увеличиваем бюджет и сроки
2. Либо делаем все требования, но не отвечаем за качество, не только нового, но и остальных.

307
У нас на проекте принимают решение о  изменении руководители проекта. Ченж-реквесты, поступившие от заказчика фильтруются. Если "фича" действительно нужная, то приходится вносить изменения, которые влияют пусть и не на всю систему, но на отдельные модули очень сильно. Был случай, когда во время разработки поменялись законы. Пришлось полностью переделать целый модуль, причем все это в рамках ограниченных сроков и бюджета.
А вот различного рода "бантики" обычно замораживают до лучших времен. Т.е. требование есть, но скоуп у него проставлен на конечные релизы. Сейчас у нас также все требования касающиеся GUI идут низким приоритетом и в первую очередь пытаемся успеть завершить всю функциональность к поставке системы.
На счет "не знаем зачем" - это суровая правда. Дело в том, что из 10 аналитиков, требованиями управляем я (процентов на 10%), ведущий аналитик (%40) и ведущий архитектор (%50). Остальные аналитики, не совсем понимали, зачем о каждом изменении и пожелании заказчика сообщать всем. Они просто применяли запрос и вносили изменния в спеку. До разработчиков это доносилось не сразу и было очень много разногласий. Так как система большая и сроки ограничены, менеджеры не успевали отслеживать все изменения. Пришлось объяснять, внедрять жесткий процесс, заставлять его соблюдать...
Зато сейчас у нас стало меньше проблем, обо всех изменениях в требованиях сообщается ведущему аналитику, он принимает решение принимать или нет, ставит приоритеты и скоуп.
Аналитики вносят изменения в доки и оповещают ответственных программистов...

308
Сама по себе идея подобной "политинформации" для сотрудников мне кажется правильной и полезной. Рад за вас, что вы нашли в себе силы сделать первый шаг в этом направлении.
Что касается самого содержания журнала, то наличие в нем ТОЛЬКО отрывков известных книг немного разочаровало. Ну, т.е. по анонсу ожидалось нечто более "свое, выстраданное". Или, по крайней мере, хотя бы дополнение "классиков" какими-то словами о применении описанной теории в вашей реальной практике. Впрочем, подозреваю, что журналы, содержащие ваши ноу-хау или анализ реального состояния дел, вы бы не могли публиковать в интернете.
В любом случае, желаю вам удачи и чтобы ваше начинание не загнулось!

Поделитесь попозже, каков был фидбэк на ваше новшество? Со стороны коллег, руководства?
Михаил, в каждом выпуске журнала предполагается публикация информации примерно следующего содержания:
1. Новости из мира анализа
2. Теоретическая статья или вырезка из книги
3. Практика применения теории на практике (адаптация к реальному проекту)

Такой схемы мы постараемся придерживаться в следующих выпусках. Это был первый журнал и планировалось его делать только для аналитиков с нашего проекта. Но так как народу понравилось, поступили предложения вынести его на уровень всей фирмы, или хотя бы русских локаций для начала.
Из-за отсутсвия времени пока сделали именно в виде "политинформации".
Есть предложения набрать "корреспондентов", которые будут подготавливать журнал: писать статьи самостоятельно, переводить, адаптировать материал из книг.
Причем предполагается привлекать не только сотрудников ЕПАМа, но и сторонних аналитиков.
После разговора с Сашей Байкиным решили вынести его на уровень форума, т.е. в дальнейшем планируется сотрудничество ЕПАМ и UML2.ru.
Пока в планах, но мы будем стараться и развивать направление.

309
Друзья, я и моя коллега по проекту Анастасия Мартыненко, подготовили для аналитиков нашего проекта электронный журнал. Такой журнал теперь будем подготавливать каждый месяц. Решил поделиться с Вами. Хотелось бы услышать советы, критику и все в таком роде.
Возможно, я буду публиковать каждый выпуск журнала на форуме. Если вы хотите подписаться на журнал, то напишите мне на электронную почту с пометкой в теме письма AnalyzeIT.
Журнал в аттаче.

310
Близость к источнику, чем плохо? :) А потом, у него, кстати, очень неплохо разжёвываются основные понятия с конкретными примерами.
Для UML совсем не плохо. Но к сожалению голое знание нотации не позволяет создавать качественные продукты :(
Чтобы писать "нормальные" спеки нужно уметь uml еще и применять. Если дать разработчику в руки модель ВИ я думаю, что они мало что смогут сделать, а вот если дать более или менее описанный сценарий, который в дальнейшем можно детализировать, то сделать думаю смогут намного больше :).
Я не навязываю свою точку зрения, но модель ВИ мы с коллегами обычно делаем после того как опишем потоки событий. Когда в голове есть полное видение тогда и структурировать легче и связи ставить между ВИ. Поэтому, я рекомендую сначала накидать драфт модели ВИ, потом описать все потоки, а потом уже оптимизировать модель и установить связи.

311
Наверное тогда не имеет смысла продолжать эту ветку, я не читал книгу Вигерса.
StUtk, к сожалению в литературе по uml приведена только нотация ВИ, в них никогда толком не рассказывают, что такое варианты использования и с чем их нужно "есть". Основная часть ВИ (об этом кстати немного заикаются) это его описание (текст или диаграмма деятельности). На ДВИ выносят ВИ лишь для того, чтобы структурировать их и показать первое видение модели ВИ и функциональности системы.
Если вы хотите более подробно узнать о ВИ почитайте Коберна. Он рассматривает их исключительно как текстовое описание, изредка обращаясь к модели. Для большего понимания моделирования ВИ я рекомендую книгу Овергаарда Use Case Patterns and Blueprints (в ней и модели и описание). Для того как использовать ВИ в процессе разработки рекомендую почитать Леффингула. На русском есть 1 и 3 книги. Вигерса тоже стоит почитать, но у него  внимание уделено всем типам требований одинаково :)
Книга Леоненкова неплохая, но ИМХО, это переведенная спецификация UML2 :)

312
А можно тогда пример отношения включения?
Самы распространенный пример: "Проверить пин код" :) включен в большое количество ВИ банкомата, например, в "Просмотреть счет", "Снять наличные"...
Отношение включения имеет смысл только тогда, когда ВИ включается в несколько ВИ.
Не всегда....

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

313
Опаньки...) а ведь мы тут рассматриваем Use Case, в котором важна функциональность системы, а последовательность действий - это уже другое. Тут рассматривается статика, только то, что предоставляет система - функия авторизации, функция регистрации, функция оформления заказа и т.д.. имхо...)
По-моему. Вы абсолютно не верно трактуете ВИ (возможно я ошибаюсь :)). ВИ в первую очередь это описание последовательности действий пользователя и откликов системы. Если вы используете диаграмму ВИ для того, чтобы описать функции системы ("статику"), без описания поведения, то я бы Вам посоветовал избавляться от подобной практики.

314
Цитировать
... Без регистрации залогиниться ну никак не получится, а это значит, что выполнение одного ВИ зависит от другого ВИ. ...
Не надо путать предусловия и связь вариантов использования. То что, перед логином пользователь должен быть зарегистрирован, это показывается либо предусловием, либо проверкой в теле самого варианта использования.
Связь dependency ("зависит") и use, которые показывают, что один элемент зависит от другого между вариантами использования не ставятся.

315
И ещё хотел бы обратить внимание на картинку на сайте - FAQ - Use Cases (Варианты Использования).
Там изображён пользователь и два ВИ(логин и регистрация), между которыми установлено отношение расширения (extend). По-моему, это далеко не отношение расширения, это отношение включения, то есть один ВИ (логин) зависит от поведения второго ВИ (регистрация). А отношение расширения - это дополнительный функционал в зависимости от условий, объявленных в перовм ВИ.
Это замечание актуально, конечно, если, корректность картинки принципиальна. =)
Не соглашусь.
Пользователь инициирует ВИ "Логин" и понимает, что нут у него учетки :). Тогда он запускает ВИ "Регистрация" или завершает данный. Если учетка есть, то регистрация нам не нужна.
В данном случае Регистрация  будет являться точкой расширения в ВИ "Логин"
С другой стороны, пользователь может не логиниться, а сразу запустить регистрацию. Включение не покатит, имхо.

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

Страницы: « 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 »