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

×


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

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


Сообщения - Водолей

Страницы: « 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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
241
Цитата: bas
Features - это 5-10 пунктов, которые Вы бы написали на на коробке своего продукта

Именно!

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

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

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

242
не буду спорить - не вижу предмета для обсуждения, просто дам ссылку (там довольно внятная табличка)

http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D1%82%D1%84%D0%B5%D0%BB%D1%8C_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2

P.S. и к чему тут "бобры"?

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

Что за функции реализованы в продукте - есть короткий ответ на короткий же вопрос: Что делает продукт?

244
В последнем тезисе Вы неправы: "выпекая хлеб", Вы создаете некий уникальный продукт заданного качества (а не прибыль!), за который клиент полюбасику заплатит 100, потому что он ему нужен. Вот если Вы его не создадите или создадите не то, что требуется, то тогда и можно ставить вопрос о "прожигании". И то я бы не стал так торопиться и постарался бы посмотреть на возможность использования того, что было создано взамен.

Ну а про 25+25=50 > 35 - это всего лишь (!) Ваше управленческое решение: каким Вы видите способ создать продукт. Кстати, невсегда выбираемый Вами способ является оптимальным. Все, как говорится, зависит от... Когда-то так, а когда-то этак.

245
вот же каша в голове.... дык о том и речь, что бюджет и прибыль - РАЗНЫЕ (!!!) вещи.

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

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

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

247
2 Elf: ну и сколько вы прибыли приносите хозяину? когда последний раз подсчитывали? :о)))

2 maksiq: дык HR и есть эти самые "бобры"! :о))

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

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

249
Для Нины_К: во всем.
Извините, но Вы пока совсем не понимаете "как правильно моделировать". Но не волнуйтесь - это лечится, этому можно научиться.
Найдите и прочитайте книжку "Методология структурного анализа и проектирования" Дэвида А.Марка и Клемента МакГоуэна (с предисловием Дугласа Т.Росса). для начала хотя бы Главу 1.


250
Цитата: greesha
Абалдеть - это если ты пригласишь всех на бизнес-завтрак в Иваново. :)

и все приедут :о)))

251
Цитата: LDV
а как узнать, что подходит тебе и приносит реальный результат?
а то читаешь-читаешь, читаешь-читаешь, а вдруг не то? ;)

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

А.С.Пушкин

252
как сказал один мой знакомый: опыт - хорошая школа, но только дураки не учатся ни в какой другой

253
скажу кратко, требования за пределами ИТ есть.
т.к. столкнулся к ними непосредственно в ходе проекта автоматизации проектной (в смысле проектирования с помощью CAD) деятельности. из выводов, которые я для себя сделал по результатам этого проекта и определенных знаний о машиностроении и строительстве, все (?) требования в других отраслях по максимуму закладываются в стандарты (а их в других отраслях значительно больше, чем в ИТ) и соответствующий специалист - в моем случае проектировщик/инженер - должен их ПРОСТО ЗНАТЬ, желательно все и наизусть :о)))

Поэтому на стадии использования (тем же инженером) управления нормативными требованиям практически не происходит. Другое дело использование каких-то подходов при выполнении конкретных проектов (напоминаю, что это все CADовское проектирование, т.е. design, construction etc), когда у того же Заказчика существуют какие-то желания, в т.ч. и неосознанные :о)) - что фактически является требованиями. Здесь уж каждый кто во что горазд действует: кто-то вставляет эти требования в настройку своего CAD/PDM/etc, кто-то плодит типовые проекты, кто-то разрабатывает свою нормативку и т.п., кто-то опять "просто помнит"...
Мой опыт в некоторой части как раз был связан с созданием некоего программного компонента, который позволил бы связать требования из документированных источников (документов, отрывков документов и т.п.) с функциональностью и настройкой CAD. Теоретических, технологических препятствий этому в настоящее время, можно сказать, нет, IBM даже божился, что у него есть продукт, как раз предназначенный для таких целей - вот только нам они его так и не показали. В это время производители CAD-систем и PDM/PLM разрабатывают и продвигают свои решения, которые частично могли бы использоваться в подобных целях, но пока они все-таки ориентируются на нужды инженера/конструктора/проектировщика по созданию "живой" документации, обновляемой при обновлении проектируемой модели (если в общих чертах, то аналогично утилитам, типа, make). Обратное движение информации (а для описанного мной случая, оно как раз прямое) их пока не очень интересует, но если говорить о конкретной реализации в конкретном случае, можно встретить неподдельный интерес. Надеюсь, он вызван не только перспективой "впарить" еще сколько-то копий продукта.

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

вот такие соображения, надеюсь, не слишком сумбурно...   

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

255
тут уж ничего не скажешь, кто-то умеет писать сообщения, а кто-то не умеет писать сообщения :о)))

Страницы: « 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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »