106

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

« : 20 Апреля 2011, 16:55:12 »

Система: "консолидация данных по финансовым показателям ОАО".

Основные задачи системы:
- консолидация данных о финансовом состоянии компаний по годам (ОАО обязаны публиковать свои отчеты по РБСУ)
- возможность расчета значений финансовых показателей, сравнений динамики изменения за период времени, сравнение показателей по различным компаниям в том числе с учетом отраслей и т.п.
-
Функциональность:
- ведение справочника компаний, отраслей
- ввод (импорт) балансов по компаниям 
- ввод (импорт) отчетов о прибылях и убытках
- ввод данных по основным показателям компании уставный капитал, номинал акций, и т.п.
- расчет финансовых показателей (оценка стоимости чистых активов, финансовый "леверидж", маржинальный доход, точка безубыточности, запас финансовой прочности, показатели ликвидности, рентабельность капитала, рентабельность заемных средств, факторный анализ прибыли)
- расчеты связанные с оценкой стоимости акций (расчет показателей доходности акций, добавленная рыночная стоимость, экономическая добавленная стоимость)
- отчеты по сравнению динамики изменения показателей компании за период или между различными компаниями

107

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

« : 20 Апреля 2011, 16:49:58 »

Интернет-портал "домашняя бухгалтерия".
Предоставление сервиса по учету домашних финансов ОН-ЛАЙН.

108

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

« : 20 Апреля 2011, 16:47:05 »

Интернет-портал заточенный для публикации резюме и вакансий ИТ-специалистов.
Какие фишки могут отличат его от традиционных сайтов поиска работы.
- ориентирован исключительно на отрасль ИТ
- при формировании как резюме так и вакансий используются рубрикаторы (справочники) позволяющие четко конкретизировать навыки и технологии, системы используемые специалистами. Это позволит организовать поиск по соответствующим значениям классификаторов
- система отзывов и рейтингов по специалистам (по аналогии с freelance.ru) кандидаты могут оцениваться как другими специалистами так и работодателями
- система отзывов и рейтингов вакансий и компаний

Монетизация:
- добровольные или символические взносы участников специалистов (могут окупить хостинг и затраты на модерирование)
- оплата услуг работодателями за различные услуги (например выделение вакансий)
- реклама

109

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

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

1. Нарисуйте, будет понятнее

А вот "конкуренты" похожую тему обсуждают http://forum.uml3.ru/viewtopic.php?f=18&t=51

110

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

« : 15 Апреля 2011, 14:32:37 »

Но что-то я в данном случае бизнеса не вижу.
Некоторые, например RUP, подразделяют BUC на основной бизнес, поддержку бизнеса и управление бизнесом. К какой категории, уважаемый, вы отнесете "Приобретение билета"?
Нормальный пользователь подходит к нормальной системе и выполняет свою цель. Где тут бизнес? Если покупатель BActor, то кто системный Actor?
Тогда любой UC является BUC?
Наверное, мы о разном UML-е речь ведем!

Под понятием "бизнеса" в этом случая я понимаю "деятельность направленную на удовлетворение потребностей".
В данном примере у потребителя есть потребность "приобрести билет" (вызвана требованием иметь билет для поездки куда либо), у продавца потребность - "получить деньги" (за саму ли услуги продажи билета или за услугу для которой приобретается билет не важно).
Это и есть в моем понимании "бизнес ВИ". В предложенном БВИ будет только два ВИ.

Эти потребности заинтересованных сторон предложено реализовать через систему "автомат по продаже билетов".
Автор в одном из сообщений упомянул что точка зрения на диаграмму ВИ должна быть "Мне хочется как можно проще, и максимально понятно тому, кто будет разрабатывать систему."
Тому кто будет проектировать автомат не так важен бизнес ВИ. Ему нужно понимание какие функции и для кого выполняет система, какие в связи с этим есть ограничения и исключения.

111

Вакансии / Re: (КА) Системный аналитик в банк TOP-10, Москва,до 100000 gross

« : 15 Апреля 2011, 14:19:58 »

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

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

112

Вакансии / Re: (КА) Системный аналитик в банк TOP-10, Москва,до 100000 gross

« : 15 Апреля 2011, 13:34:51 »

Да понятно это, что можно найти "400 способов".... Просто на такую ЗП наверно ищут грамотного специалиста, и надо думать что такой специалист не даст себя облапошить. Получаются экономят на ЗП, а может больше потеряют.

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

113

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

« : 15 Апреля 2011, 13:19:27 »

И что, всё проектирование должно вестись прямо на этой диаграмме?

Уважаемый, greesha, где вы на моем примере диаграммы ВИ (извините что в тексте, картинку пока не нарисовал) увидели "проектирование"? Что вы вкладываете в этот термин?

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

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

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

114

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

« : 15 Апреля 2011, 12:46:23 »

Пользовательский ВИ - это в первую цель пользователя. Ну нет цели у Пользователя засунуть в автомат деньги! У него есть цель - получить билет, а уже все детали функционирования ВИ (что делает Пользователь и как отвечает Система) описываются в виде сценария ВИ или ДД/ДП/ДВ.

Уважаемый bas, Вы не могли бы раскрыть что вы вкладываете в термин "Пользовательский ВИ", в чем по вашему выражено наше непонимание сути диаграммы ВИ.

Формируя свои ответы я исходил из самого первого сообщения уважаемого Автора "Use Case vs. Use Cases - какая должна быть степень детализации?".
В его вопросе нигде не сказано с какой точки зрения мы должны посмотреть на проектируемую систему.

У Пассажира нет цели засунуть деньги я с вами согласен, но ведь у "Автомата" (утрирую, конечно у его владельца) - есть бизнес-цель - "получить деньги взамен билета". Данная цель неявна и не отражена на представленных автором диаграммах.
Ранее я предложил свой вариант диаграммы ВИ демонстрирующую точку зрения на проектируемую систему Автомат http://www.uml2.ru/forum/index.php?topic=3729.msg27642#msg27642

Мой вариант диаграммы ВИ:
С Пассажиром связан один ВИ: Продажа билета.
ВИ Продажа билета "включает" ВИ: Прием оплаты, Выдача билета
ВИ Возврат оплаты "расширяет" ВИ Прием оплаты.
ВИ Выдача сдачи "расширяет" ВИ Выдача билета.

Другим Актором будет Администратор, ВИ: Обслуживание.
ВИ Обслуживание "включает" ВИ: Контроль состояния, Инкассация, Загрузка билетов.

 

Пока этот вариант Автором или другими участниками не прокомментирован (возможно потому что не представлена картинка).

115

Вакансии / Re: (КА) Системный аналитик в банк TOP-10, Москва,до 100000 gross

« : 15 Апреля 2011, 11:18:06 »

кого вряд ли устроит? работодателя. Работодатель идет против КЗОТ, устанавливая зп на испытательном сроке ниже. Если он уже в вакансии в открытую говорит, что ему начхать на КЗОТ, то где гарантия соблюдения позже?

Вряд ли будут действовать в нарушение ТК.
Просто предложат человеку подписать трудовой договор с меньшей з/п, и дадут клятвенные уверения в том, что после ИС с ним заключат доп соглашение в котором сумма будет увеличена или за счет увеличения оклада или за счет персональной надбавки, а может вообще будут выплачивать "гарантированную премию" в определенном размере.
Также могут аналогичные условия прописать в "оффере".

116

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

« : 15 Апреля 2011, 10:57:48 »

Почему не отвечает? Система должна продать билет пассажиру. А не ботинки ему почистить, например.
(А такое требование тоже может возникнуть в процессе разработки - эти заказчики такие заказчики!)

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

Насчет концептуальности диаграммы ВИ:
http://www.intuit.ru/department/pl/umlbasics/3/

"Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

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

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

117

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

« : 15 Апреля 2011, 10:06:32 »

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

Такой вариант UC похож на ответ козопаса Шерлоку Холмсу. На вопрос: "Сэр, вы не подскажете, где мы находимся?", он ответил: "В корзине, прикрепленной к воздушному шару".
Задача автора "спроектировать систему". Первый вариант UC не отвечает на вопрос - что должна делать система Автомат для достижения цели Пассажира (Билетоприобретателя). Этот UC - бизнес ВИ, и не отражает концептуальную модель системы.

118

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

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

В дополнении к обсуждению. что вы думаете об этой диаграмме. Поясняет ли она действие 1 диаграммы UC и устраняет потребность во второй?

Нет не поясняет (в смысле не полностью поясняет), нет не устраняет (необходимость и корректность второй UC пока не очевидна).

119

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

« : 14 Апреля 2011, 16:12:30 »

Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?

Да, но только не связанными напрямую с Пассажиром (Билетопокупателем).
Мой вариант диаграммы ВИ:
С Пассажиром связан один ВИ: Продажа билета.
ВИ Продажа билета "включает" ВИ: Прием оплаты, Выдача билета
ВИ Возврат оплаты "расширяет" ВИ Прием оплаты.
ВИ Выдача сдачи "расширяет" ВИ Выдача билета.

Другим Актором будет Администратор, ВИ: Обслуживание.
ВИ Обслуживание "включает" ВИ: Контроль состояния, Инкассация, Загрузка билетов.  

120

Для всех / Re: Каков коэффициент возврата инвестиций при привлечении аналитика?

« : 08 Апреля 2011, 08:58:32 »

Здравствуйте. Согласен с большинством комментаторов, что этот вопрос не простой. Но, мне кажется, что последнее время удалось подойти вплотную  к ответу на него. Тема большая поэтому помещу здесь только ссылку на статью в блоге, где я попытался рассматривать подход к ответу на этот и подобные этому вопросы: какова эффективность руководителя, какова эффективность от взаимодействия, ...
http://www.torins.ru/support/blogs.php?page=post&blog=gladkov&post_id=94
С уважением, Сергей Гладков.

Не очень понятно как эта статья связана с решением проблемы этой темы "Каков коэффициент возврата инвестиций при привлечении аналитика"?