121

Системный Анализ и Требования / Re: Просчёты аналитиков - примеры из жизни

« : 28 Сентября 2007, 10:29:39 »

<...>Интересы кассиров в данном случае не должны иметь высокого приоритета.

Хорошо, что у них был хороший начальник, который так не думал (даже если так говорил) и помог им отстоять свои интересы . Системы (в идеальном мире без глупости и откатов) делаются для облегчения жизни пользователей.

Тем более что, как я сказал, предполагалась установка терминалов в новые точки.

Старшими кассирами, которые будут учить новичков, поставили бы старых кассиров.

В результате мы потратили значительное время на адаптацию пользовательского интерфейса, заменив его на менее удобный<...>

Менее удобный для Вас?

<...>скрыли часть полезных сервисных операций и разработали новые операции (хотя того же результата позволяли добиться "скрытые").

IMHO не того же.
Действие(10 сек)=результат
не равно
Действие(10 сек)+время на переучивание=результат .

Так что IMHO описанный случай действительно был ошибкой - при разработке Вы не учли требования одной из групп пользователей системы. Эту группу можно было бы попытаться переубедить, обеспечив её наиболее "влиятельным" представителям участие в прототипировании GUI, создании GUI "для себя". Но простое копирование старого GUI - более простое и дешёвое решение.

Оценка удобства GUI - вообще скользкий и очень субъективный вопрос.

122

Варианты Использования (Use Case) / Re: Рефакторинг мельчащих use-case'ов

« : 25 Сентября 2007, 18:36:09 »

Если смотреть на конкретную модель, то я считаю, что верхний уровень по 2 UC - лишний. IMHO дерево должно быть сбалансированным и содержать как можно меньше уровней, и эти уровни должны определяться только удобством.
А последний уровень IMHO действительно лучше не рисовать, а писать. Но это если уверенность что прочитают, иначе – надо рисовать.

123

Системный Анализ и Требования / Re: Wiki в коллективной разработке требований

« : 20 Июля 2007, 18:53:28 »

А у нас MediaWiki в качестве средства для управления требованиями не прижилась. Специализированные не-web-based средства удобнее. Даже "плоские" пользовательские истории количеством больше десятка хранить уже неудобно, вперемешку со специфическими тегами форматирования, а от вбивания в wiki оценок оставшихся/сделанных единиц по этим историям люди отказались на третий день .

124

О Сайте и Форуме / Re: To be or not to be: that is the question?

« : 20 Июля 2007, 17:08:05 »

Глюки есть. Порой страница не соответствует ссылке, особенно в "последних сообщениях". Но лично мне нравится так, как есть. Со всеми разделами. Даже если в сайте главное форум - всё равно сайт нужен! Без него как-то несерьёзено... Тем более кто знает, во что выльется uml2.ru - возможно, в полноценную консалтинговую компанию?

125

Системный Анализ и Требования / Re: Требования = Решения

« : 17 Июля 2007, 18:00:17 »

<...>А дело, на мой взгляд, вот в чём - объективно нет никаких Требований и Решений - есть только Утверждения. И эти Утверждения могут играть Роль Требования или Решения, в зависимости от его отношения к вам. Оно либо приходит к вам (Input, Requirement Statement) и вы его перерабатываете во что-то другое, либо исходит от вас, и тогда для вас оно Решение (Output, Design Statement).
<...>
Что думаете, дерзко? )

Дерзко. Взять отмести мнение большинства гуру.

Действительно, всё, что утверждено заказчиком - требование. Сроки - требование. Функциональность - требование. Графический дизайн - требование. И даже unit-тесты - требование, если их ухитирились утвердить.
А с другой стороны - сроки не на пустом месте возникли, это - решение относительно трудоёмкости и рисков. И функциональность не просто так предлагают, а уж UC/US разработать - ничуть не проще, чем, к примеру, структуру БД. "Сбора" требований нет, они нигде не лежат готовыми, их нужно "вылавливать", "тралить", а лучше - "предлагать".

Лично я склонен подразделять артефакты "до кода" не на "требования" и "решения", а на "требования" и "архитектуру". И оставлять за разработчиками как можно больше архитектуры, которая по определению не требует утверждения у заказчиков. Иначе не будет пространства для манёвра. Запишешь, например, самостоятельно разработанную структуру БД или навигации GUI в требования, утвердят её (задав множество глупых вопросов и потребовав множества глупых, ухудшающих исправлений), а потом перед каждым изменением - снова согласовывать.

Мне кажется, что гуру имели в виду именно такое разделение, не с точки зрения процесса создания, а с точки зрения процесса утверждения и жёсткости фиксации.

126

Идеи и мозговой штурм / Re: Анализ IT-безопасности на предприятиях

« : 04 Июля 2007, 16:28:11 »

<...>Но обратите внимание на мой пост, не просто предлагать решения, но и предлагать за деньги!!! Но учитывая замечания АлексаЗеРайвена, что-то стало как-то не уютно....

Есть вещи, знание которых опасно. Я бы не взялся защищать от утечки чёрную бухгалтерию какой-нибудь крупной российской компании (особенно настраивать контентную фильтрацию) за деньги, на которые не смогу до конца жизни нанимать десяток охранников, бункер в городской черте, пару бронетранспортёров и пару двойников .

127

Идеи и мозговой штурм / Re: Анализ IT-безопасности на предприятиях

« : 04 Июля 2007, 16:22:25 »

Не бывает совершенных систем, и не бывает совершенных средств защиты.<...>

Делаем .
А если серьёзно - единственно возможной защитой является уменьшение экономической целесообразности взлома. Если взлом стоит $2 млн., а в результате получения данных будет получена прибыль всего лишь $1 млн., взлома с большой вероятности не будет - злоумышленники очень хорошо умеют считать деньги.

128

Идеи и мозговой штурм / Re: Анализ IT-безопасности на предприятиях

« : 04 Июля 2007, 14:49:04 »

<...>Так же могу поискать статью про анализ и создание дерева уязвимостей и запостить сюда линку, где-то я недавно ее видела. Надо?

Буду очень признателен. Деревья уязвимости и методику их построения можно увидеть также в книге Шнайера "Секреты и ложь: безопасность данных в цифровом мире"

129

Идеи и мозговой штурм / Re: Анализ IT-безопасности на предприятиях

« : 04 Июля 2007, 14:45:52 »

<...>Как можно гарантировать, что после выдачи рекомендация система безопасности не будет сломана?

Гарантировать - никак. Уменьшить риск - устранив дыру в безопасности в максимально короткие сроки. Но если  рекомендация не выдана и риск не выявлен - его уменьшение невозможно.
Если Вы беспокоитесь, что сломает тот, кто выявил - заранее подпишите с ним договор о неразглашении, а по завершении работ полностью расплатитесь и/или устраните его физически (самая мягкая форма - посадка в тюрьму за "прошлые грехи", прецеденты были).

130

Нововведения / Re: Новый термин (почти тоже что и Наследование)

« : 02 Июня 2007, 21:29:50 »

<...>у меня такой вопрос как назвать такую операцию "НАСЛЕДОВАНИЯ":
1. пусть есть класс с атррибутами (Atta#) С1{Atta1,Atta2,Atta3}
(*)2. пусть есть класс с атррибутами (Atta#) С2{Atta1,Atta2} который является наследником класса С1. <...>

А это и есть наследование. Только на самом деле C1 является наследником C2, причём C2 - не абстрактный.
Можно, конечно, сказать, что Atta3 переопределён на отсутствующий... Но зачем такие извращения?

131

Вакансии / Re: Вакансия: системный аналитик

« : 02 Июня 2007, 15:26:18 »

<...>ведущий специалист отдела системного анализа <...> опыт работы бизнес/системным аналитиком или программистом от 3 лет <...> от 1900 USD (по результатам собеседования)<...>

"От" ниже рыночной. "До" выше рыночной?

132

UML SysML и пр. / Re: Кому, зачем и когда нужен UML

« : 02 Июня 2007, 15:18:56 »

Лично в нашей команде UML нужен для того, чтобы коротко, просто и наглядно сформулировать, как всё должно быть, а потом не забыть этой формулировки. Сформулировать последовательно, на разных уровнях - от "какую цель преследует система" до "как мы будем использовать декоратор, чтобы представить A для В как С". Причём сформулировать ДО того, как сделать. Ну и для того, чтобы знать, например, что: "Ага, изменилась цель (ограничение, UC) A - значит, изменятся алгоритмы (activity) B и C, и объекты Q, W, E, R, T, Y".

133

Варианты Использования (Use Case) / Re: Помогите с диаграммой вариантов использования

« : 02 Июня 2007, 15:07:59 »

Ребята,помогите.Нужно создать диаграмму вариантов использования для системы управления плавательным бассейном

Спросите у людей, которые заказали Вам эту систему, что она должна делать. Наверняка:
- учитывать посетителей, предоставлять им биллинг, возможность электронных платежей;
- резервировать дорожки, регулировать параметры тех. систем бассейна (очистка, температура, график уборки) в зависимости от загруженности бассейна;
- предоставлять информацию для прогнозирования изагрузки в средства анализа, информацию о заказах, счетах и платежах - в учётную систему (а-ля 1С: Бухгалтерия).
Распишите всё это детально, в виде последовательностей - и получите замечательный MUC.

134

Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"

« : 06 Апреля 2007, 14:42:32 »

<...>
Но тем не менее, для масштабных проектов, из твоих слов не очень понял, почему применяемый ТОБОЙ подход требует высокой степени доверия.<...>

IMHO чем меньше доверия - тем более полным (а значит, более формальным и детализированным) должен быть набор требований. А теперь представь себе внешнего заказчика, к-рый подписывается под ТЗ из 30 "фич"... Да иной ПМ программисту отдельную задачу длительностью в полдня детальнее ставит!

135

Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"

« : 05 Апреля 2007, 14:57:12 »

К огромному моему сожалению, присутствовать не смог, хотя семинар проводился в 100 м от моей работы...
Идея простоты - замечательная. Мы уже используем что-то наподобие, принимая что:
- есть потребность: за её удовлетворение готовы заплатить деньги
- есть решение (проект) - человеко-машинная система, пособная удовлетворить эту потребность
- есть... даже не функции или UC, а "фичи" решения, описания того, что же оно должно делать - максимум штук 20-30, можно написать в whitepaper или своём резюме
- есть итерации (спринты) - на одной занимаемся одними фичами, на другой - другими, но после каждой имеем готовое решение, удовлетворяющее часть потребности
- есть задачи - каждая по "фиче", за каждую есть ответственный
- есть работы по выполнению этой задачи, и связанные с ними оценки, а сколько же осталось затратить времени.
Всё это ведётся в довольно простой самодельной системке моего производства .
У нас всё это не исключает детальных вариантов использования, трассированных со статическими и динамическими единицами, относящимися к реализации.

Но в таком упрощении я вижу следующие проблемы:
1) Необходима высокая степень доверия между заказчиком и разработчиком; в случае масштабного проекта на тендерной основе это может вызвать очень большие риски, на которые мало кто пойдёт.
2) Требований меньше не становится, просто проектная команда концентрируется на ключевых, считая, что остальные "сами собой разумеются". Но для разных людей "сами собой разумеются" разные вещи. Опять же, когда в команду вливается новый сотрудник - очень многое приходится рассказывать ему лично.
3) Требованиями в настолько широком плане может заниматься не меньше чем product/project manager, к-рый одновременно заведует маркетингом, разработкой и внедрением. Остальные за деревьями не видят леса. А product/project manager за лесом может не видеть деревьев, и создать требования, по которым трудно будет делать задачи...
4) Граница компетентности такого процесса - порядка 20 сотрудников на создание решения. Каждый такой сотрудник знает всех других и может лично взаимодействовать с ними напрямую.