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

×


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

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


Темы - Galogen

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
121
Следует ли рассмотреть вопрос где и как публиковать статьи членов сообщества?

Следует ли сделать раздел Юлог сообщества, в котором сделать категории Блог члена сообщество ФИО?

Или же просто создавать статью там, где член сообщества считает нужным?

122
IDEF ARIS BPMN и пр. / Oryx: BPMN
« : 08 Июня 2009, 19:25:30 »
Нашел в интернете ссылку на интересный ресурс по использованию инструментов бизнес-анализа.

Ресурс развивает Постдамский университет. Именуется ORYX. Смотреть: здесь.

123
О Сайте и Форуме / Лого в виде ракера
« : 02 Июня 2009, 20:36:57 »
oduduka,

Хорошая идея, спасибо ...
Кстати а не заменить ли кубик в лого таким вот ракером?


124
Хочу привлечь посетителей форума к данной проблеме.

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

Предлагаю обсудить правила использования таких диаграмм на живых примерах, и написать одну или несколько статей по этому поводу

125
Сразу хочу оговориться. Варианты использования - отличный инструмент работы с требованиями, областью знаний и т.п. Вообщем отличное средство. Однако, что касается диаграммы вариантов использования, то тут в семье не без урода.

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

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

Типичный пример (детальнее смотрите здесь)


С какого бодуна вообще решено изображать работу с файловым менеджером таким образом. И выделение пользователей не по ролевому признаку, а по опытности - что за бред??

А как вам нравится это "декомпозиция" ВИ Управление ресурсами файловой системы: Добавление, Правка и Удаление. А что простите такое управление ресурсами, которое должно обязательно включать добавление, правку и удаление - заметьте ОДНОВРЕМЕННО, если все-таки следовать букве закона использования ДВИ.

В общем пришло время поговорить серьезно. Есть плюсы или только минусы? Или минусы - это и есть плюсы?

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

Надеюсь, в споре родится истина. Родится что-то полезное. возможно правило форума - те кто попытается обратится с вопросом по ДВИ - тотчас исключается из форума  ;D

126
Уважаемые аналитики, проектировщики. Обращаюсь за помощью и вариантами.

Нужно придумать хорошую диаграмму изменения состояний заявки в ходе ее жизненного цикла.

Приносят заявку.
Пользователь создает новую заявку и вводит требуемые данные, в том числе указывает дату регистрации. Сохраняет заявку. Заявка принимает состояние Предложена.

Далее пользователь берет одну из заявок в работу, т.е. переводит ее в состояние На экспертизе. При этом заявка доступна только этому пользователю для изменения. В состоянии Предложена и На экспертизе заявка не должна находится больше месяца, т.е. в течение месяца заявка должна быть Принята или Отклонена(отправлена на доработку)

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

После проведения экспертизы, т.е. выставлена оценка, определены доп параметры, пользователь переводит заявку в состояние Принята или Прошла экспертизу либо Отклонена или На доработку.

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

Если переводим в состояние Отклонена - генерируется запрос на создание ответа автору. Если ответ сделан заявка переходт в состояние Отправлен ответ, если нет остается в состоянии Отклонена и потом оповещает, что ответа автору не было

Если заявка находится в состоянии Опубликована на сайте а ответа автору нет, идет оповещение пользователя до тех пор пока ответ не будет создан. После ответа автору заявка переход в состояние Отправлен ответ - изненный цикл завершен.

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

У какого какие предложения и варианты? На все доп вопросы отвечу и с удовольствием...

127
А почему бы нам не сделать аналогичную игру. Я могу быть поставщиком требований :)

Т.к. топик будет большой, то здесь будем давать ссылки на основные сообщения:

1. Команда проекта:
http://www.uml2.ru/forum/index.php?topic=1106.msg11617#msg11617

2. План действий:
http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611
2.1. Подробный план по работе над пп. 2.1-2.3
http://www.uml2.ru/forum/index.php?topic=1106.msg11693#msg11693

3. Шаблоны Документов:
http://www.uml2.ru/forum/index.php?topic=1106.msg11645#msg11645

4. Постановка Задачи:
http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612
http://www.uml2.ru/forum/index.php?topic=1106.msg11613#msg11613
http://www.uml2.ru/forum/index.php?topic=1106.msg11614#msg11614

5. Концепция от veta, StUtk, bustor (последнее обновление - 01.03.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg12632#msg12632
ДБО см. в п. 6

6. Диаграмма Бизнес Объектов (последнее обновление - 28.04.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg13782#msg13782

128
План доклада на семинар:
1. Классификация требований
2. Документирование требований
3. Аспекты классификации унифицированного процесса
4. Методы выявления

Прошу ответить во время семинара на ряд вопросов, если возможно.

1. Зачем нужно классифицировать требования?
2. Почему требуется семинар по классификации требований, если в мире существуют уже устойчивые классификации, а при этом в некоторых организация особо не паряться по поводу классификации требований. Требование есть требования.
3. Как докментируются требования в реальной практике, не как документ для заказчика, тут все ясно, а как документ внутреннего использования. Как вообще организовать документирование и документооборот требований?
4. Как рекомендуется структурировать требования, стоит ли их структурировать? Каковы критерии качественного структурирования требований
5. как выявлятьь требования на тестировние, особенно если они отсутствуют в документальной форме или форма их представления далека от классических норм?

З.Ы. Тема родилась из Re: [Семинар] Классификация требований, 29 ноября, СПб

129
Реализация / Реализация шаблона MVC
« : 21 Октября 2008, 22:49:10 »
Я уже имел консультацию по этому вопросу. Мне было сказано, что я не понимаю назначение MVC, вполне возможно. Даже наверняка. Да нет же совершенно не знаю :) Но хочу знать.

Однако я слышал, читал, видел - что MVC активно используется для веб-приложений. Фаулер даже напирал при этом как на особенность веб-приложений.

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

Задачка следующего типа:
пусть имеется клиент. который делает в какой-то он-лайн системе заказы. Не в даваясь во все возможные ситуации ограничимся двумя часто возникающими вариантами.
1. авторизация (без авторизации можно только посмотреть главную страницу, ну поизучать каталог, почитать сопутсвующую информацию, для создания же заказа нужно регистрироваться и потом уже авторизироваться)
2. создание нового заказа.

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

При авторизации:
Пользователь вводит логин и пароль
Система узнает пользователя, приветствует и предоставляет ему соответствующий доступ

Возможный сценарий реализации может выглядеть так:
1 Пользователь вводит url сайта в командную строку браузера.
2. браузер отображает Главную страницу сайта
3. Пользователь вводит логин и пароль в поля Формы авторизации и нажимает кнопку Войти
4. Браузер пользователя отправляет http- запрос, содержащий введенные значения логина и пароля, Web-серверу
5. Web-сервер перенаправляет запрос соответствующему Скрипту (по сути методу некоего класса-контроллера)
6. Класс-контроллер, выполняя метод, инстанцирует объект Пользователь с параметрами Логин и Пароль:
    если такой объект существует в БД, тогда запускается метод получить данные Клиента
    если такого объекта нема, создается сообщение-уведомление
7. Получив данные Класс-контроллер отправляет пользователю на браузер соотвествующую страницу сайта

Как полагаете пойдет такое?

Как это может выглядеть в виде некоего кода?

1. как я понимаю на action формы будет просто передача параметров нужному скрипту
2. в скрипте инстанциируется контроллер, который получает параметры и запускает метод, который
3. инстанциирует объект бизнес-логики, который
4  посылает запрос в БД
и в обратном порядке?

В общем чего не так? Не слишком все кудряво?

130
Друзья. Я в некотором смятении относительно научной темы для исследований.

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

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

Научные изыскания следует определять в рамках системного анализа (паспорт специализации здесь).

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

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

Некоторые знакомые говорят о проблемах оценивания ИТ проектов.

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

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

131
Для всех / Код vs модели
« : 01 Октября 2008, 17:37:52 »
на сайте omg.org обнаружил ряд статей. В одной из них (выполненных в виде презентации) приведен небольшой пример.

Там представлен код и картинка, его иллюстрирующий.

Вот собственно картинка:


и код, связанный с ней
   Ammount function Accept_deposit (a : Account, d : Amount)
   {
     Amount nb = a.balance + d;
     a.balance = nb;
     return nb;
   }

Не кажется ли вам, что код гораздо понятнее и информативнее, чем картинка?

Как минимум код компактнее, создание его менее трудоемко, чем такой вот картинки


132
На сайте не так давно опубликована новость: http://www.uml2.ru/index.php?option=com_content&task=view&id=221&Itemid=64

Лишний раз убеждаюсь - новое -хорошо забытое старое. Данной "новой" статье как минимум год. Ссылку, конечно, не на нее, а на сайт, где собственно статья была опубликована, я разместил еще в октябре прошлого года: http://www.uml2.ru/index.php?option=com_content&task=view&id=106.

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

134
Требуется разработать и внедрить программный комплекс для автоматизации деятельности сотрудника экспертного центра вуза по экспертизе электронных учебных изданий (ЭУИ).

Цель создания экспертного центра - обеспечить приемлемое качество ЭУИ, обеспечить учет создаваемых ЭУИ в университете, предоставить мотивириованные результаты для определения надбавки преподавателям.

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

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

В настоящее время в центре имеются 3 сотрудника. Один на постоянной основе - руководитель, два, так скажем, в случае цейтнота.

Экспертизы одного ЭУИ, включая прием заявки, собственно оценку, регистрацию результатов, написание рецензии автору, публикация на сайте (http://expert.isuct.ru/content/section/5/32/) занимает не малое время. В среднем около 2 часов.

В настоящий момент количестов поступающих заявок не велико, что связано с началом учебного года, акция началась лишь в конце прошлого учебного года. Однако ожидается к концу 1 семестра достаточно серьезное увеличение потока заявок.

Как я писал выше, преподаватели, которые активно участвуют в разработке ЭУИ, имеют отличные шансы (почти гарантию) на получение надбавки. А с переходом на отраслевую систему оплаты труда, когда дополнительные 30% к фонду оплаты труда будут распределятся ректором на основании показателей деятельности преподавателя, стремление преподавателей предложить свои разработки будут только усиливаться. Очевидно, что в данном случае экспертному центру придется быть той плотиной, которая не пропустит откровенно слабые разработки и будет работать на качество.

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

Использования средств индивидуальной продуктивности типа Excel, хотя и возможно (и используется в настоящее время), но имеет свои проблемы и не так эффективно.

Предполагается создать приложение (АРМ, комплекс программных средств) которое бы позволило:
1. проводить регистрацию заявки (дата, Авторы, Наименование, Кафедра, сопроводительная информация, контактные данные)
2. планировать работу с зарегистрированными заявками
3. проводить экспертизу ЭУИ с использованием набора критериев (значение проставляет эксперт, система предоставляет сами критерии и подсчитывает суммарные баллы)
4. присваивать регистрационный номер в случае успешной экспертизы
5. помогать оформлять и отправлять письма авторам с результатами экспертизы
6. помогать эксперту орагнизовывать работу с зарегистрированными заявками ( например сообщать на e-mail о том что подходит срок проведения экспертизы для некотрого количества заявок и т.п.)
7. публиковать прошедшие экспертизу заявки на сайте
8. готовить требуемые отчеты для руководства и комиссии по надбавкам
9. обеспечивать коллективный разделенный доступ

Концептуально предполагается использовать либо клиент-серверную технологию, либо трехзвенку.
В качестве СУБД firebird.
Сервер нотификации и рассылки (возможно он же сервер приложения)
Клиентское место

В настоящий момент формируется концепция проекта, готовится список вариантов использования, часть их тщательно прописывается.

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

Проект будет выполнятся в течение примерно октября 2008 - июня 2009 (с естественными перерывами в декабре-январе, апреле-мае)

135
Ожидаемый результат: методика преподавания анализа и развития аналитических способностей.

Цель: обеспечить устойчивые навыки применения приемов и методов анализа при разработки ПО и ИС у большей части обучающихся.

Мотивы: отсутствие упорядоченной сбалансированной методики преподавания, как следствие плохое понимание обучающимися того, чему им следует научиться, слабый интерес

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

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

Возможно я что-то опустил или не совсем точно выразил мысль. Надеюсь, в ходе дискуссии что-то здесь изменить.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »