166

Вакансии / Re: Business Analyst/ Ward Howell – Talent Equity Consultants

« : 10 Февраля 2011, 12:45:59 »

Я извиняюсь за занудство, но все тоже самое и на русском. Если можно конечно.

Это все к чему? Ну что к примеру значит  "Fluent English" ?  Свободное владение.
Я согласен язык знать надо, но
Просто к примеру, даже хороший переводчик "поплыл" когда ему предложили текст из  нефтяной области.

И еще  какой смысл на русском форуме писать на английском. Вы же цените таланты .

Компания международная, требования к знанию языка обоснованные (общаться и документы писать). Что не так? Я бы понял если бы российская компания с российским персоналом и заказчиками предъявляла требования к языку и разместила на аглицком объявление ... это бы вызвало удивление. А так все ОК.

167

Вакансии / Вакансия: Главный специалист, Москва

« : 09 Февраля 2011, 11:03:59 »

Главный специалист
Требования:
•   Образование высшее техническое или финансово-экономическое 
•   Знания в областях: программной инженерии, структурного анализа бизнес-процессов на основе  методологий/моделей  IDEF0, цепочки добавленной стоимости (модели верхнего уровня); разработка концепции, технического задания, документации технического проекта автоматизированных систем на базе  ГОСТ 34
•   Практические знания, полученные в рамках участия в проектах аудита состояния ИКТ, разработки ИТ-стратегии в сегменте  GOVERNMENT, COMMERCIAL (очень приветствуется)
•   Разработка методик управления деятельности в секторе GOVERNMENT, COMMERCIAL
•   Коммуникабельность, пунктуальность‚ готовность работать на результат.
Обязанности
•   Участие в разработке нормативно-правовых актов в сфере ИКТ
•   Разработка методик и методических рекомендаций в части мониторинга использования и создания ИКТ в деятельности государственных органов
•   Взаимодействие с контрольно-надзорными органами в части реализации координации информатизации государственных органов
•   Методическое сопровождение деятельности федеральных органов исполнительной власти и внебюджетных фондов в части планирования расходов на ИКТ
•   Разработка требований к информационным системам и регламентов их использования
•   Мониторинг статуса задач по проектам
Условия:
•   Итоговый уровень оплаты труда определяется по результатам собеседования.
•   Соблюдение трудового законодательства‚ "белая" заработная плата‚ молодой коллектив.
•   График работы - полный рабочий день.
•   Прямая и безусловная зависимость роста от успешности проектов.
•   Место работы - 2 минуты от м. Охотный ряд.

З/п от 35 до 75 тыс. руб. Оформление в известном гос. учреждении или подрядной коммерческой организации.
Контакты: smith-ug@ya.ru, +7-910-477-91-31. Юлия.

168

Управление Проектом / Re: Шпаргалка руководителю проекта

« : 04 Февраля 2011, 00:43:19 »

А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!

Вот вторая версия. Все то же, но добавлены роли исполнителей.

Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).

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

169

ПО Аналитика / Re: Первые шаги аналитика. ПО, книги, советы

« : 04 Февраля 2011, 00:24:18 »

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

170

Вакансии / Re: Нужен опытный системный аналитик с прицелом на руководство проектом

« : 01 Февраля 2011, 17:11:57 »

Ждемс автора топа, встреча была бы весьма интересна, и дело не в деньгах!

Дело не в деньгах

171

Примеры / Re: Пример диаграммы для описания функционирования формы

« : 25 Января 2011, 18:52:28 »

Коллеги, не нужно усложнять жизнь .... для начала нужно понять, зачем вообще нужны "картинки", кроме этого речь идет о ТЗ, а не о дизайне .... или есть желание в ТЗ описать дизайн, а не требования??? А так, Ида все сказала.

172

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 18 Января 2011, 15:52:01 »

Скоупом в данной диаграмме как я понял стоит некая система "Сервисный центр" - если это информационная система, БД в которой является ее частью - то не нужно показывать БД в качестве secondary actor, впрочем как и принтер. А если БД является другой, смежной системой (например в ней пишутся логи для службы безопасности), тогда выделение ее в качестве secondary actor оправдано.

173

Обсуждение статей / Re: Предисловие к интегрированной архитектуре

« : 19 Декабря 2010, 13:18:49 »

Леонид Борисович похоже теперь переключился с RUP на EA ...

174

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 17 Декабря 2010, 15:28:44 »

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

1. Юзабилити тут как раз очень даже причем. Ибо собственно определение стиля оформления GUI и использования определенных решений (например использовать тачскрины) - это тема именно юзабилити. В требованиях можно только обозначить некоторые общие положения, типа НАЛИЧИЯ единого стиля.
2. Не уверен, что если поля логин/пароль в разных окнах имеют разные лэйблы (логин, имя пользователя, ...) - то это обязательно проблема требований. Честно говоря, я не встречал в ТЗ ТАКОЙ детализации .... разве только где-нить в change requests, которые могут поступить от тестирощиков ... Просто в любом случае, кто-то должен контролировать "техническую эстетику", и совсем не обязательно что это задача аналитиков. Посему - скорее это таки вопрос к юзабилитию

175

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 16 Декабря 2010, 16:46:13 »

скорее стандартные компоненты с определенными требованиями, которые повторно используются (и сами компоненты и требования к ним) - и так мы плавно перетекаем к управлению программными активами 

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

176

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 15 Декабря 2010, 21:48:37 »

IMHO это не от абстрагирования зависит, а от распределения зон ответственности за компоненты. ну и от архитектуры, ессно.

Стандарты на GUI должны быть по-идее ...

177

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 14 Декабря 2010, 22:47:23 »

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

Да, так пишу ... при таком описании мы не указываем конкретных элементов пользовательского интерфейса. Тот же список может быть выпадающим, скролируемым и т.п., посему, только говоря о списках, у нас уже появляется двусмысленность :-). "Пользователь вводит данные" - кто сказал что это именно в контрол типа Edit вводит пользователь значение? А может он вводит непосредственно в Grid??? Тут тоже нет однозначного указания на контрол. Так что пока я не увидел подтверждения вашего тезиса "IMHO это и есть недвусмысленное указание на те самые элементы" :-).

Хотя "меня терзают смутные сомнения" (с) - мне кажется, что мы подразумеваем одно и то же - т.е. что следует избегать написания в UC таких действий как "Пользователь нажимает кнопку <Распечатать>", или "Пользователь выбирает из выпадающего списка ...", а стараться заменять их более абстрактными утверждениями. Если вы хотели сказать именно это, правда пытались это сказать как-то очень сложно .... - то вопрос исчерпан :-)

178

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 14 Декабря 2010, 18:05:10 »

не в целях спорить:
1. От себя сошлюсь на Фаулера, который определяет UseCase (вариант использования) как множество сценариев, объединенных вместе некоторой общей целью пользователя (например "Настроить принтер" - пример мой).
Описание сценариев же выполняется в стиле "Пользователь делает это" - "Система делает то", отсюда и термин "интерфейс "пользователь-система".

Поясню также термин "грубо говоря" -  в данном случае он не означает, что UseCase определяется до уровня кнопок (несмотря на написанное выше :о))) - действительно UseCases ведь разрабатываются, когда система еще не существует, о каких конкретно элементах управления может идти речь. Но тем не менее те или иные (назовем их - стандартные или типовые) абстрактные элементы все-таки подразумеваются: элементы выбора - списки, меню, справочники и тп.; элементы продолжения - типа кнопки, элементы для ввода значений и т.д. и т.п. Кстати, с их использованием был разработан стандарт CUA и поныне используемый в Windows, MacOs, Linux и других системах.

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

2. Вообще-то я написал выше IMHO, и оно (это самое IMHO) распространяется на все три пункта. Извините, если это неочевидно.
Действительно, UseCase "Настроить принтер" может попасться под руку и при печати документа, и при печати форм, и при настройке устройства печати, и при переформатировании документа Портрет/Альбом, и ... да когда угодно! Поэтому наверняка не существует жесткой и однозначной связи между функциями системы (или может лучше Функциями Системы), которые пишут на коробке, и какими-то там UseCases. Однако существует ряд UseCase, которые связаны ТОЛЬКО с Функциями Системы - это те, которые относятся к основной ее функциональности (опять пардон за тавтологию), т.е. содержат то, для чего система создавалась (пример - "набор сообщения" в клиенте почтовой системы, каждый может по своим системам мноооого таких примеров насобирать). Их, кстати, можно (и нужно!) использовать при сравнении систем сходной функциональности.

всё вышенаписанное - IMHO.

Честно говоря, не вполне уловил логику, невзирая на IMHO :-) ... Я после некоторого опыта, стал очень осторожно относиться к указанию каких-либо элементов управления в теле варианта использования. Т.к. это часто воспринимается разработчиками буквально, а это не факт что наиболее оптимально с т.з. эргономики. Очевидно, что зависит от системы и контекста.

179

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 14 Декабря 2010, 12:24:30 »

Именно!
В дополнение к вышесказанному и ранее написанному обсуждаю :о))) (не в целях сказать что-то против высказанных мыслей, а развития темы для) Признаться, часть, содержащая описание двух подходов и сама состоящая из трех частей, сделала попытку меня запутать :о)))
IMHO:
Use cases - это фактически описание интерфейса "пользователь-система" (или какие-то другие варианты взаимодействия с системой): как пользователь будет оперировать с системой, грубо говоря: какие кнопки нажимать, в какие поля и что вводить, и что при этом будет происходить с системой...
Функция - это некая, пардон за тавтологию, функционально законченная и реализованная возможность системы, то же "управление корпоративной печатью", которая(-ое ?) может детализироваться далее и далее на всё более мелкие функции, типа: "настройка устройства печати", "печать документа в различных форматах" и т.д. и т.п. пока не дойдет до уровня операций, выраженных с помощью Use Case "Настроить принтер"
Т.е. в конечном счете - это больше похоже на (мне больше нравится) третий подход (насколько я эти подходы понял из приведенного описания). Причем это действительно помогает "мэппить" требования на функции системы практически напрямую (хотя конечно так происходит не всегда).

P.S. и личное... Юрий (и другие коллеги), я Вас очень прошу: Не ставьте мягкий знак в глаголах третьего лица. Пожалуйста.

1. Не вполне понял что понимается под интерфейсом "пользователь-система", коими предлагается считать UC (вариант использования). Если это интерпретировать как "в какие поля что вводить" и в "какие кнопки нажимать" - то боюсь, что это не вполне отражает изначальное назначение UC. Если посмотреть того же Коберна, так он настойчиво предлагает не указывать в UC про нажатия кнопок и т.п. Более того, считается одной из распространенных ошибок описание деталей пользовательского интерфейса в UC.
2. Совершенно не факт, что UC и функции соотносятся таким образом. Если я правильно понял, то предлагается считать, что варианты использования будут "встроены" в иерархию функций системы. Хотя совершенно не факт, т.к. собственно варианты использования в большей части могут не найти прямого отражения в списке функций. Другой вопрос, что UC будет включать в себя "дергание" одной или более функций.
3. Проблема написания мягкого знака в глаголах 3 лица - известная проблема, присущая не только мне одному. Кстати у меня есть еще один "паразит", если кто заметил - это произношение слова "звонит", я часто говорю "звОнит", и "созвОнимся" :-).  Как сказала одна знакомая психолог - следует соотнести усилия направленные на контроль этого, с результатом :-).

180

Системный Анализ и Требования / Re: Что именно является функцией программного продукта ?

« : 13 Декабря 2010, 17:40:41 »

Коллеги, вопрос сподвиг меня на небольшую заметку в моем блоге по этой теме (юзкейсы и функции) - http://yurybuluy.blogspot.com/2010/12/use-cases.html. Welcome .... можно обсуждать как в блоге, так и тут ...