76

Sparx / Re: Версионность и ветвление ЕА в БД

« : 25 Января 2012, 21:45:45 »

Из второго поста я не очень понял, в чем состоит вопрос.
Но вообще да, в ЕА не очень мощные средства работы с версиями. Мы их не используем, в проектах, где нужен полноценный version control все экспортируется в документы MS Office и уже эти документы версионируются.

77

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 25 Января 2012, 18:49:32 »

Т.е. у вас приходит новый Аналитик и вы ему так и говорите - будете делать все, что ПМ №1 скажет, а если вы еще нужны и на проект ПМу №2, то тоже будете делать, что он скажет, и потом не говорите мне, что у вас 24 часа в сутках только?!

Близко, но не совсем так. Время аналитика (40 часов в неделю) делиться между ПМами (например, 10 часов ПМу№1, 30 часов ПМу №2). После этого ПМ №1 говорит аналитику, что тому делать 10 часов, а ПМ №2 - что аналитику делать 30 часов. Если в конкретную неделю на проекте №2 есть работы только на 1 час, а на проекте №1 есть ждущие задачи, то можно с согласия ПМа №2 поработать на проект №1 39 часов.

78

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 25 Января 2012, 13:55:38 »

А если структура матричная? А если проект 100 человек и ПМов там 3-5?

У нас матричная структура, проекты по 100 человек. Неопытных ПМов на проект, в котором 100 человек, не ставят (тренируют на проектах с 1-2 чел). Насчет 5 ПМов на проекте не понял... Шутка? ("В военное время полк имеет 3-5 командиров"?)
Признаков использования должностных инструкций, кроме как для решения вышеупомянутых кадровых вопросов, не наблюдал.

79

Sparx / Re: Версионность и ветвление ЕА в БД

« : 25 Января 2012, 02:08:49 »

http://www.sparxsystems.com/WhitePapers/Version_Control.pdf

80

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 25 Января 2012, 02:04:19 »

хорошо бы рассмотреть задачу со всех точек зрения

Я думал, у вас конкретная жизненная ситуация, а у вас сферический конь в вакууме

существует такой документ как должностная инструкция, в котором подробно написана зона ответственности конкретной должности.

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

81

Sparx / Re: Попытка подружить Enterprise Architect с Mysql

« : 24 Января 2012, 16:38:43 »

Похоже, у базы указан Шведский коллейшен по дефлоту.

82

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 24 Января 2012, 13:28:54 »

div Я же хочу рассмотреть команду в которой присутствуют все перечисленные должности.

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

83

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 23 Января 2012, 18:12:43 »

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

Опытный ПМ подбирает людей в команду, обращая внимание не на должности, а на конкретные умения и навыки людей. Например, если в плане намечается задача "Нарисовать диаграмму развертывания", и ПМ знает, что Вася отлично планирует развертывание, то зачем ему задумываться над вопросами:
1. Должен эту диаграмму рисовать аналитик или архитектор?
2. Что написано у Васи в трудовой книжке: аналитик или архитектор?
Все равно будет рисовать Вася...

84

UML SysML и пр. / Re: UseCase вне границ системы

« : 28 Декабря 2011, 19:44:29 »

У меня встречный вопрос. Если взять, Вашу аналогию с кнопками, то верна ли для неё диаграмма (отношение расширения между UC Create Model и UC Create Project)?

Расширение ИМХО - это когда нажав кнопку основного действия, вы затем можете нажать кнопку расширяющего действия. А можете и не нажать.

Думаете так (картинка во вложении) будет понятнее/формально правильнее?

Лично мне так понятнее.

85

UML SysML и пр. / Re: UseCase вне границ системы

« : 26 Декабря 2011, 21:18:23 »

UC Create Model реализован в "материнской" системе и является как бы предусловием к использованию моей системы. Если модель не была создана в "материнской" системе, то срабатывает точка расширения в моём UC Create Project и модель в "мартеринской" системе создаётся вместе с проектом в моей (UC Create Model).

1. Мне кажется, в таком случае нельзя считать Create Model предусловием Create Project. Предусловие - это в некотором роде булевское выражение, которое вычисляется для определения доступности "кнопки", нажав на которую пользователь вызывает выполение кейза. У вас получается, что "кнопка" (условно) Create Project неактивна ("серая"), если до этого не были выполнены действия из Create Model. А вам нужно, чтобы она всегда была активна ("черная"), но если при ее нажатии Create Model еще не выполнялось, то чтобы оно было выполенено.

2. Соглашусь с bas, что отсутствие указания границ "материнской системы" делает более трудным понимание этой диаграммы и вызывает лишние вопросы.

86

UML SysML и пр. / Re: Как средствами UML описать протокол общение между сервером и клиентом

« : 26 Декабря 2011, 21:02:47 »

не могу понять какими средствами/диаграммами описать протокол общение между клиентом-серврером.
Например у нас есть soap сервис и к нему идет обращение из браузера клиента. Есть определенный формат в виде XML,
Но как его расписать средствами UML?

Что вы хотите сказать, когда просите "расписать формат XML средствами UML"?
UML - это язык построения моделей. Модели применяются для решения проблем. Разные модели UML помогают решать разные проблемы.
Выбор модели зависит от того, какую проблему Вы хотите решить.
Уточните в чем ваша проблема, и вам подскажут, какое средство UML оптимально для ее решения.
Или подскажут, что UML вам в этой задаче не нужен.

87

UML SysML и пр. / Re: UseCase вне границ системы

« : 16 Декабря 2011, 17:51:11 »

1. Поясните, пожалуйста, вот эту фразу:

"вынося UseCase, я хочу показать, что существует некоторая функциональность, которая ... является предусловием к началу использования системы".
Функциональность чего?

2. выполнение какого кейза является предусловием использования системы?

88

Идеи и мозговой штурм / Re: Как сделать так, чтобы не замыливался глаз

« : 15 Декабря 2011, 23:19:45 »

Самый известный и довольно действенный способ - уехать куда-нибудь подальше в отпуск минимум на неделю

89

Для всех / Re: Независимость программного обеспечения от платформы и браузера

« : 15 Декабря 2011, 23:06:29 »

Например, правдоподобно ли заявление, что ПО работает на Internet Explorer 6.0 и выше, Mozilla FireFox, Google Chrome, Opera, Safari (без указаний версий).
Как Вы считаете , в настоящее время это так?
Т.е. разработчики реально протестировали ПО на всех браузерах и платформах?

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

90

Обучение / Re: Литература по анализу - а существует ли она?

« : 09 Ноября 2011, 18:56:03 »

Господа, список рекомендованной литературы - это неплохая вещь. Но в этом списке наиболее интересны не те книги, которые эксперт рекомендует, а те которые эксперт прочитал и признал негодными.

Соглашусь. В таком случае мои 3 копейки в эту кучку:

* Принципы работы с требованиями к программному обеспечению. Унифицированный подход   Дин Леффингуэлл, Дон Уидриг               В плане

Читал. Извлек определенную пользу, но не зацепило.
         

* Бизнес со скоростью мысли   Билл Гейтс               Читал      Не зацепило

Читал. В целом не зацепило, но пара мыслей понравилась.