136

Идеи и мозговой штурм / Re: Тематика старт-апа

« : 19 Апреля 2011, 23:29:48 »

Берем примеры: Одноклассники, ВКонтакте, Дарбери и т.д. Таких скопированных стартапов тысячи ....

Понял примерно так: идея чего то такого ..., что к авторству не придраться, а реализация своя?

137

Идеи и мозговой штурм / Re: Тематика старт-апа

« : 19 Апреля 2011, 23:17:35 »

Мне непонятно, зачем заказчику отправлять RequisitePro? Это инструмент проектной группы! Ему нужно документы отправлять сгенерированные.

Но, извините, это не по теме!

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

138

Идеи и мозговой штурм / Re: Тематика старт-апа

« : 19 Апреля 2011, 22:58:57 »

Пока кроме Саша и Дениса ничего дельного.
Вообще странно, опубликовал специально на форуме Идеи и мозговой штурм, чтобы тухлыми яйцами не кидались, что это без своей критики обошлись. Нет не могем.

Тут нам про пуговицы, за которые 5 баллов раздают, тут и Ржевский нарисовался.

Ребята я вам стартап не предлагаю, с направлением помогите, тематикой. Считаете упустите свою коммерческую выгоду? Ну не делитесь!

Только давайте успокойтесь, ладно?

Прости, наболело!

А, все же, цель какая? Заработать или поучиться проекты делать (кто не делал) и, при случае, заработать?
Если второе, проект должен быть небольшим.

Вот,на домашней странице внизу партнеры перечислены. Среди них на первом месте "CM Consalt". Они не только консультируют, но и разработки делают и продают, в том числе - на запад. В том числе полезные примочки для IBM Rational. Ну, естественно, являются партнером IBM и т.д.

Я думаю, Саша не обидится, если сыграть на их поле. Например, сделать некоторое интересное добавление к RequisitePro. Если интересно, могу показать, как тупо это сделано сейчас, и как классно можно сделать. Но это не 10 минут печатать и не одно сообщение на форуме.

Если пропиарить, покупатели найдутся.

139

Идеи и мозговой штурм / Re: Тематика старт-апа

« : 19 Апреля 2011, 22:02:26 »

- Стоп! - себе думаю. Но за телеграфы не берусь!

Так подумал я, когда прочитал предложение Эдуарда. (С этих слов начинается почти каждая флотская (капитанская) байка.

Товарищи (по цеху) высказали очень дельные мысли о тематике (например, про пуговицы) и т.п. Вот здорово!

А потом отрезвление пошло...

Ребята! Мы дальше первого требования не пройдем! Мы друг другу глотки перегрызем: UC - это функция или не функция? А сколько еще других вопросов?!...

Простите, если выступил в роли поручика Ржевского!

140

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 19:25:33 »

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

Конечно, требования есть функциональные и нефункциональные ("чтобы можно было поднять одной рукой"). И гвоздь можно забить не только молотком. Но если нужно точно молотком, то нужно указать на молоток.

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

Ограничения нужно устанавливать осторожно.
В начале 90-x на Калининской АЭС было требование на поставку любого ПО: язык PowerBuilder. Обоснование: 100% работников IT прошло соответствующее обучение и за деньги Еврокомиссии было закуплено соответствующее программное обеспечение. Редкий случай, когда требование использования платформы было обосновано.

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

141

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 18:37:10 »

не обязательно правой, а в остальном, прекрасная маркиза....

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

В общем случае, не рекомендуется ограничивать проектировщика в выборе решений, наилучшим образом реализующих цель пользователя: Забить гвоздь. Например, мы ограничили проектировщика определением элементов интерфейсов "Ручка" и "Плоская ударная поверхность".

Проектировщик создаст кооперацию реализации UC и начнет рисовать диаграмму последовательности. В процессе рисования и определятся соответствующие объекты: экземпляры ручки и "ударника" с его плоской поверхностью.

На основе модели реализации будет уточнено и детализировано описание UC (не обязательно, но полезно, т.к. описание UC - это плацдарм для написания руководства пользователя и тест-кейса).

Я работаю в RSA и наделал множество шаблонов SoDA на разные случаи жизни. Спецификацию UC, Руководство пользователя и TestCase я генерю из одной и той же модели UC.

142

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 17:55:18 »

Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.

Можно на русском?

UC 1: Забивание гвоздя
Краткое описание: Дядька берет молоток за ручку правой рукой и, предварительно замахнувшись, ударяет плоской ударной поверхностью по шляпке гвоздя, предварительно приставленного к нужному месту.

Primary actor: Дядька

Actor: Гвоздь

Думаю, этого достаточно. Можно нарисовать диаграмму деятельности, предусмотрев альтернативный поток на случай, если гвоздь согнется, и цикл, если за один раз не выйдет!

143

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 17:37:47 »

какое-то нагромождение понятий.
Вроде как UC = описание взаимодействия с системой, грубо говоря описание последовательности нажатий кнопок. Если между нажатиями пользователь должен выполнять какие-нибудь строго (или не очень строго) предписанные действия, описываемые в UC, то значит система их (эти действия) охватывает, т.е. возникает коллизия между определением и содержанием границы системы.

UC при этом не принадлежит системе и не является ее свойством. Он ее всего лишь описывает в ракурсе "как с нею взаимодействовать пользователю". в этом описании "упоминаются" используемые пользователем функции (вот они - свойства системы) для достижения его цели.

Может быть, я пишу сложно. Но так UML устроен.

UML рассматривает любой объект с двух точек зрения: снаружи (что объект делает) и изнутри (как он это делает взаимодействием своих внутренних объектов).

Дихотомия "UC - UCRealization" - это как раз такой случай. Это один элемент, который представляет две точки зрения: аналитика и проектировщика (кодера).

В системе не может быть UC, если нет UCRealization. Ну, а UCRealization не может существовать без UC хотя бы потому, что UC - это описание функциональности UCRealization.

Т.о., если быть абсолютно точным, то UCRealization реализует функцию системы, а UC - описывает эту функцию в терминах взаимодействий системы с внешним миром (actor-ом человеком или другой системой). Другими словами, UC описывает функцию системы. Полный набор всех UC описывает все функции системы.

Если кто из аналитиков не помнит, UCRealization на диаграммах представляется эллипсом с пунктирным контуром и должна иметь одинаковое с UC название. Это стандартный стереотип UML модельного элемента Collaboration.

144

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 15:47:59 »

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

Простите, но Actor взаимодействует с системой через UC.
Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).

И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?

Загибаешь!

UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?

А какой пример функции, который не является реализацией UC?

145

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 18:55:58 »

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

потом по аналогии можно рассмотреть софтовый телевизор и сравнить получившиеся результаты. тоже научный метод познания.

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

146

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 17:44:01 »

Относительно первого - Word.

Ну почему же, Эдуард. Требования к любому инструменту, реализующему взаимодействия, можно описать с помощью UC.

И Юрий правильно определил цель пользователя. М.б., я другими словами, но содержание то же, что у Юры: создание, чтение и редактирование текстового документа. Внутри эллипса вполне допустимо написать: "Работа с документом". Единственная цель. Один UC уровня пользователя.
Затем можно написать огромное текстовое описание пользовательского UC по Коберну или нарисовать огромную (по площади и глубине) диаграмму деятельности со множеством вложений.

Мне непонятно почему, но многие забывают очень важную роль UC как объекта планирования в итерационном инкрементном процессе разработки.
Если об этом вспомнить, то проясняется необходимость декомпозиции (ой! ...выделения...) абстрактных UC, в нашей ситуации, в основном это UCE.

Я не знаю, использовал ли Microsoft термины UC, UCI, UCE. Но есть вещи, которые выполняются одинаково или почти одинаково, независимо от того, как их называют. Думаю, Word делали не один год, определяли цели, рисовали какие-то схемы взаимодействий, определяли спецификации (процессов, функций, UC - все равно, как они их называли!), планировали, для реализации функциональности создавали или использовали существующие классы и компоненты.

Ну, не нравится кому-то называть это UC. Ради Бога! Это как материя, существует независимо от нашего сознания.

147

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 17:08:10 »

Простите, попросили лампочку вывернуть!

По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!

По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.

Возвращаясь к предыдущему: цель пользователя - получить информацию для принятия решения и/или зафиксировать решение.

148

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 16:56:09 »

По второму вопросу целиком согласен: цель пользователя - получить информацию для принятия решения. Но на диаграмме вполне можно нарисовать эллипс с надписью "Принятие решения". Ведь UC - это не эллипс, а описание последовательности взаимодействий. Пренятие решения - вне границ используемой системы. Точно так же, как решить, нажать OK или Cancel!

По поводу Word, если интересует мое мнение, чуть позже. Мне сейчас отойти надо.

149

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 16:42:19 »

Ну на вопрос ты не ответил.

Ты сформулировал непонятную для меня фразу. Думаю, не только я не понял. Расшифруй, если можешь, свои слова.

Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

Каждое слово по отдельности у меня сомнений не вызывает. Но что фраза означает - я не понимаю.

Ты победил!
Мне добавить нечего.

150

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 14:40:03 »

Эдуард!

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

Ну какая, в сущности, разница для практиков, можно ли UC называть подкатегорией функции (не функции в программировании, а в широком смысле).

Мы с Юрием, в большинстве случаев, одинаково определяем UC, понимаем, зачем использовать абстрактные UC, и что требования бывают функциональные и не функциональные и т.д. Вот это имеет смысл!

Или ты о примерах с Word и принятия решений?