136

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

« : 07 Октября 2011, 15:22:01 »

Во вложении, как пример.

137

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

« : 07 Октября 2011, 15:20:32 »

В целом все равно придется делать что-то свое, с учетом Вашей специфики.
Есть например,  ГОСТ Р ИСО/МЭК 15910—2002

Или был такой отраслевой стандарт   ОСТ 4.071.030 . Он отменен , но использовать при разработке своих рекомендаций можно.

138

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

« : 07 Октября 2011, 15:00:04 »

В целом методики есть, но они обычно подстраиваются под каждого.
Например, можно универсально считать что написание ТЗ - это 160 часов.

Также есть ряд статей.
Например,   Подход к оценке сроков создания технической документации

139

Обсуждение статей / Re: Семинар

« : 04 Октября 2011, 12:07:43 »

Я надеюсь, на этом же сайте потом и презентация появиться с материалами семинара

140

Вакансии / Re: Старший аналитик, Москва

« : 04 Октября 2011, 11:58:04 »

Это конечно хорошо, что так информативно.
При этом все-таки сколько могут дать по результатам собеседования (или от или до)?

141

Управление Проектом / Re: Работа с Исполнителем

« : 30 Сентября 2011, 17:54:45 »

Увы. Что делать?
Конечно можно посмотреть всякие там договоры, обязанности и все с этим связанное .
Но раз нет у Вас путей влияния на Исполнителя то
Осознать полученный опыт.

142

Управление Проектом / Re: Работа с Исполнителем

« : 28 Сентября 2011, 18:21:35 »

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

Согласен 

Конкуренции у него нет, вот отсюда и проблемы.

Бывает и такое но Вы же сказали что есть тех поддержка.
Осталось всего-то определить что в рамках тех.поддержки делается  .

Исполнитель не выдерживает сроки.

Значит в договоре нет таких требований.

отношение разработчика к нашим проблемам тормозит развитие нашего бизнеса

А разработчику часто все равно до Вашего бизнеса. Вы же платите им - они довольны (Вы же сами об этом и сказали).
Зачем еще что-то делать?

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

143

Системный Анализ и Требования / Re: Обеспечение повтороного использования требований - кому это надо?

« : 28 Сентября 2011, 18:10:47 »

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

144

Системный Анализ и Требования / Re: Обеспечение повтороного использования требований - кому это надо?

« : 28 Сентября 2011, 18:08:35 »

Приведу данные из статьи Управление требованиями к IT-проектам

Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований.

Так вот.
Повторное использование равно применение точно таких же технических решений или нет?
В этой же статье говориться что требования должны обладать 10 характеристиками.
Соответственно это все надо оформить. А когда (времени всегда не хватает)?

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

145

Вакансии / Re: Работа аналитиком требований в компании Гранит-Центр

« : 25 Сентября 2011, 12:28:32 »

Вопрос в следующем,
У нас уже государственные заказчики требуют знание UML?
(знание  и практическое применение UML; опыт работы с государственными заказчиками; )

Или UML нужен, чтобы сделать постановку задач разработчику web-приложений?

146

Управление Проектом / Re: Управление командой. просрочки

« : 25 Сентября 2011, 12:21:40 »

Согласен с Денисом.
Важная часть планирование.
Информация доводиться до руководителя проекта.
Сотруднику объясняется, что решение должно уладываться в рамки цена-качество-время.

Обычно после диалога в основном понимают

147

Примеры / Re: Описание поведения GUI средствами UML

« : 11 Сентября 2011, 21:18:25 »

Спасибо , за уточнение.

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

148

Примеры / Re: Описание поведения GUI средствами UML

« : 11 Сентября 2011, 13:53:38 »

политикой описания поведения пользовательских интерфейсов в UML

А скажите пожалуйста, часто ли Вам приходиться описывать поведение интерфейса в UML?

Сам делаю это крайне редко, именно в UML.
А прототипирование делаю чере другие прграммы, например Visio.

149

Обсуждение статей / Re: КС \

« : 09 Сентября 2011, 00:54:02 »

Думаю надо и здесь Александрам благодарность объявить.
Как участник хочу сказать Спасибо идейным вдохновителям  Алексею Киселевуи Павлу Тарханову, а также основным методологам – Александру Байкину и Александру Белину за формирование понимания и указания направления в решении вопросов  связанных с аббревиатурой UML.

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

150

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 09 Сентября 2011, 00:26:57 »

Например, в PMBOK 4 издания CCB переводиться как
Совет по управлению изменениями (Change Control Board, CCB)
Формальная группа участников проекта, ответственная за изучение, оценку, одобрение,
отсрочку или отклонение внесения изменений в проект, причем все решения и рекомендации
совета записываются.