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

×


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

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


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

Страницы: « 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 »
676
IMHO лучше потратить не очень много денег и в каком-нибудь торговом центре (и т.п.) посмотреть как подобный автомат работает (например, на практике сначала в него закладываются деньги, а потом уже осуществляется выбор напитка - а не так как Вы пишите), записав последовательность выполняемых действий. Подобная запись поможет при проектировании...

To greesha: курсовик небось...

677
Цитата: Анна Абрамова
Требовать от участников форума, чтобы они нам, не сходя с места, устраивали тренинги мы действительно не можем. =))

Консультацию или тренинг можно и на другой основе сделать... Ну или на рынке найти

678
Как я написал ранее, я мог бы помочь с описанием процессов техподдержки, и, возможно, по другим направлениям. Но судя по всему круг желающих расширился :о))
К тому же тема техподдержки совсем не относится к тематике форума, да и описание процессов лишь частично.

P.S. про направление движения я вроде тоже ранее ответил.

679
Цитата: StUtk
А можно варианты решения, дальнейшее обсуждение темы не прятать в лички, дабы данная общедоступная ветка форума не теряла своей информационной значимости для других читателей. :-)

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

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

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

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

681
Про нотации:
Уж коль Вы зацепили цепочки добавленной стоимости, возможно имеет смысл использовать ARIS (упомянутую VAC и eEPC). Правда, сам инструмент ARIS Toolset (в комплекте) довольно дорогой. Но использование того же Visio несколько упрощает задачу моделирования, но не разработки регламентирующей документации, с которой при помощи ARISа легко справиться.

Напишите мне в личку, если есть интерес.

682
В таком случае Вам больше подойдет методология компании HP, которая является вендором продукта подходящего по вашей тематике (HP Service Desk OV).

683
IMHO в принципе правильно, только очень долго придется идти. Проще взять готовые процессы той же технической поддержки, да и софт тоже.

Встречный вопрос, правильно ли я понял, что нужно в принципе нужно спроектировать "внутренние" процессы технической поддержки, но в то же время сферой Вашей ответственности является проектирование софта для этой технической поддержки?

Если, да, то следует обратить внимание (возможно не Вам) на описание работы Service Desk в стандарте ITIL (раздел Service Support во второй версии, Service Operations в третьей - пользуйтесь той, которую найдете). На подобную тему достаточно много есть готового софта. Подробнее можно узнать на itsmforum.ru

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

Для "рисования" процессов можно взять любую пригодную нотацию или даже просто рисовать квадратики/кружочки/стрелочки в Визио. Текстовое описание процессов можно писать руками или сгенерить из диаграммы процесса, если выбранные средства моделирования это позволяют.

Пожалуйста, почетче структурируйте/формулируйте Ваши вопросы/потребности. А то сразу обо всём довольно сложно рассказывать.

684
В ГОСТе 34.003-90 Термины и определения АС определяется как:
Автоматизированная система (АС) - система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
Комплекс средств автоматизации в том же ГОСТе определяется как совокупность всех компонентов АС, за исключением людей.

В стандартах же 19-й серии (ЕСПД) "устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ". (ГОСТ 19.001-77 Общие положения)

У Вас типичная автоматизированная система, предназначенная для автоматизации деятельности разработчика и чего-то там еще. Поэтому было бы логично использовать 34-ю серию ГОСТ. И не парьтесь насчет АПК своего. Если сильно приспичит, то можно включить в ТЗ требования к техническим средствам функционирования АС, например, чтобы они имели платформу INTEL.

Также присоединюсь к Galogen'у насчет требований к документации на Вашу АСУ. Пишите что-нить в следующее:
В ходе разработки автоматизированной системы должна быть разработана следующая документация:
 - Технический проект
 - Рабочая документация
 - Руководство пользователя
 - Руководство администратора
(или что там у Вас планируется)
Полный перечень документов по стандарту можно посмотреть в 34.201-84 Виды документов при создании АС. Полный перечень приводить не надо: во-первых, не все виды документов необходимы или применимы для Вашего случая, а во-вторых, как я понимаю, Вам их потом разрабатывать. Лучше подумать и оставить лишь безусловно необходимые.

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

P.S. Не deadline, а цейтнот скорее всего :о))
 


685
IDEF ARIS BPMN и пр. / Re: еEPC и циклы
« : 11 Марта 2009, 23:50:02 »
Элементарно, Ватсон! (с)

циклов в подобной модели быть действительно не должно

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

никаких процессов "ожидание" делать не надо.

P.S. читайте Шеера.

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

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

Позволите встречный вопрос: "система управления" - что это? из чего состоит? Не согласен, что КИС - сама есть система управления. В узком смысле возможно, в широком вряд ли.

С приведенным списком литературы не знаком, но навскидку что-то он у меня доверия не вызывает - кто эти люди?

Нет, всё-таки не удержусь от "нападок" :о))
Кстати, нет в природе "бизнес-процессов принятия управленческих решений". Возможно Вы имели в виду бизнес-процессов сбора и представления информации для принятия управленческих решений?

То, что Вы назвали признаками КИС, на самом деле является некоторым набором принципов построения этих самых КИС, причем на деле он (набор) более широкий, чем приведен. Частный антитезис: если АСУ не является открытой или масштабируемой - это уже не КИС получается?

+ еще есть немного по мелочи...

P.S. напоследок, раз звучит термин "корпоративные", значит и его нужно тоже определять.

P.P.S. надеюсь остался в конструктивном русле и не обидел Вас чем-либо. Цели такой точно не было

687
ОК, понял. с виду нормальное содержание для одного семестра на старшем курсе

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




688
Да нет, не подумайте, у меня к Вам претензий нет. По форуму видно, что Вы пытаетесь и сами чему-то научиться и до студентов что-то полезное донести

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

P.S. а всё-таки о чем курс КИС если не секрет?

689
Мда...
IMHO одного семестра мало, а второй семестр 4-го курса - поздновато, чтобы начинать, т.к. голова у студентов уже чем-то другим занята.

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

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

690
Как же теперь всё запущено в нынешнем высшем образовании...

Расскажу коротенько, каким у меня было обучение, только это давно было:

Во-первых, на старших курсах у нас был курс, который назывался просто ЖЦРПО (там, конечно, были свои заморочки насчет "дискретно" и "несогласованно")
Во-вторых,  где-то параллельно в течение всего (!) учебного года выполнялась курсовая работа по разработке некоей программной системы.
В-третьих, эта работа выполнялась бригадой из 4-5-6 человек, состав бригады не менялся (разве что кого-то отчислят).
В-четвертых, были какие-то контрольные точки (своего рода зачеты), когда надо было сделать и представить какую-то часть работы преподавателю.

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

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

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

To Galogen:
Вы ведь действительно можете разделить свои классы курсовых во времени, и выдать (предварительно перетасовав) в качестве задания "проектировщикам" разработанные их товарищами ТЗ.

P.S. А, кстати, 200 часов - это один семестр или два?

Страницы: « 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 »