76

Бизнес-анализ и Целеполагание / Re: Портал - автоматизированная или информационная система? ГОСТ

« : 27 Октября 2009, 14:23:16 »

Корпоративный ресурс, на котором будут размещены различные информационные материалы, новости, справочники, шаблоны документов и т.п.

Определение информационной системы дается в ФЗ 149 от 27 июля 2006 г - "Об информации, информационных технологиях и о защите информации": "информационная система - совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;"

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

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

А вообще, всё это конечно словоблудие, имхо.

77

Бизнес-анализ и Целеполагание / Re: Портал - автоматизированная или информационная система? ГОСТ

« : 27 Октября 2009, 13:22:52 »

А можно немного поподробнее о портале?
Понятие "потрал" оставить нельзя, должно быть всё по ГОСТу или иным отечественным нормативным документам, так я понимаю?

И что мешает обозвать портал информационной системой? Базы данных есть? А информационные технологии и технические средства обработки информации - весьма расплывчатые понятия, имхо. А понятие сервиса не подразумевает какую-то обработку определённой информации? К примеру, сервис "получение телефона сотрудника" - как ни крути, а к инфе в базе данных обратишься.

Если бы я был руководителем, мне бы тоже не понравилось название "АРМ Руководителя", меня бы устроило понятие "Командный пункт" - не меньше!

78

Примеры / Re: тестовый пример "типография"

« : 27 Октября 2009, 00:12:50 »

А тут какието пять ВИ вызывают вполне серьезную полемику и неоднозначность!!!! Именно в таких случаях текст работает... А теперь представьте себе что вариантов будет не пять а сто пять и разбираться в такой схеме/схемах да еще при наличии наследований и прочих "прелестей" UML будет очень проблематично и говорить об однозначном прочтении таких диаграмм скорее всего не придется

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

79

Примеры / Re: тестовый пример "типография"

« : 26 Октября 2009, 21:32:51 »

Делать так "Менеджер наследует Клиента" - честно говоря очень не нравится, так как читающий эту диаграмму может понять такое наследование по своему...

Вообще то я тоже так думаю, но с наследованием, я так понимаю, правильнее, и вот как быть в таком случае? Делать как правильно или как понятнее?

А еще лучше словами, словами - четче и понятнее))

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

------------------------------------------------------------------------------

Новый вариант ДВИ:

80

Примеры / Re: тестовый пример "типография"

« : 26 Октября 2009, 12:45:32 »

Формирование заявки не создает экземпляров. Это абстракция, которая конкретно реализуется либо в заявку клиента, либо в заявку от имени клиента

Но ведь и другие ВИ тоже не создают экземпляров. Чего-то я не допонимаю...(

И ещё вопрос, а чем не абстрактный ВИ "Формирование заявки" у меня? По этой причине:

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

?

81

Примеры / Re: тестовый пример "типография"

« : 23 Октября 2009, 14:13:55 »

Аааааааааааа, побью сейчас
Ну причем тут в ПТ идет архитектура?? Это должно быть все в ограничениях или НФТ, ну на крайняк в примечании в ВИ.

А, ну, я это и имел в виду, просто очень своеобразно, литературно так сказать, выразился...))
 

82

Примеры / Re: тестовый пример "типография"

« : 23 Октября 2009, 13:34:07 »

1. Формирование заявки - абстрактный ВИ - его лучше сделать так

Почему лучше? С целью наиболее понятного представления? Абстрактный ВИ может быть связан с каким-нибудь актёром? (с точки зрения нотации)

1. Все ВИ должны быть образованы от ГЛАГОЛА

А как более отглагольно должны выглядеть названия ВИ по сравнению с существующими? Формировать - формирование, получить - получение, изменить - изменение, просмотреть - просмотр?

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

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

83

Примеры / Re: тестовый пример "типография"

« : 22 Октября 2009, 17:46:43 »

StUtk,
А чем тебе не понравился пример, который мы делали по ВУЗу? Там и описание было и концепция и т.д.

Пример по ВУЗу мне очень понравился, только как-то он сейчас застопорился, всё же там последние результаты были от veta'ы, а проверить их некому (это не претензия, а просто факт). И я готов продолжать тот пример.
Данный пример не такой глобальный и больше ориентирован именно на UML.
Через этот пример, в качестве основы, хотца попрактиковаться в создании диаграммы последовательности.

84

Примеры / тестовый пример "типография"

« : 22 Октября 2009, 16:46:39 »

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

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

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

Заинтересованные лица: менеджер, оператор, кассир, клиент.
1. Менеджер принимает исходный материал (принесённый на электронных носителях, напечатанные листы) и формирует заявку на месте, выдаёт готовую продукцию.
2. Оператор согласно очереди выполняет заявку (печатет, брошюруюет)
3. Кассир принимает оплату по заявкам и отмечает у заявки факт оплаты.
4. Клиент формирует заявку через интернет или приносит материалы менеджеру, который сам формирует заявку, после чего клиент оплачивает услуги в кассе и после печати (и брошюровки) материалов получает их у менеджера.


Для начала выявленные ВИ:

ВИ.01 Простмотр списка услуг
Актёры: клиент
Цель: получение сведений о предоставляемых услугах
Краткое описание: Клиент заходит на сайт типографии, где получает информацию о предоставляемых услугах.

ВИ.02 Формирование заявки через интернет
Актёры: клиент
Цель: загрузить материалы в систему через интернет, получить номер заявки
Краткое описание: клиент со своей локальной машины загружает материалы в систему типографии, выбирает параметры заявки.

ВИ.03 Формирование заявки локально (в типографии)
Актёры: менеджер
Цель: загрузить материалы в систему с локального компьютера в типографии, получить номер заявки
Краткое описание: менеджер со своего локального компьютера в типографии загружает материалы клиента в систему (если клиенту не нужна только брошюровка), выбирает параметры заявки.

ВИ.04 Изменение статуса заявки
Актёры: кассир, оператор
Цель: изменить статус заявки для попадания заявки в очередь на производство и удаления заявки из очереди после выполнения
Краткое описание: кассир после получения оплаты клиентом заявки устанавливает статус на "оплачено", после чего заявка попадает в очередь на выполнение. Оператор устанавливает статус "выполнено" для обработанной заявки, после чего заявка удаляется из очереди.

ВИ.05 Получение очереди заявок
Актёры: оператор
Цель: взять заявку из очереди на выолнение
Краткое описание: оператор получает список заявок, выбирает заявку на выполнение, после чего система устанавливает для заявки статус "в процессе".

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


Ну и собственно ДВИ в аттаче.
Жду критику по всем аспектам темы. Желательно конструктивную. 

85

Системный Анализ и Требования / Re: Сбор и документирование требований к OLAP-отчету

« : 22 Октября 2009, 10:43:48 »

ну хоть в теории сошлись... )))))
а как на практике ? Делитесь... раз уж безудержный интерес)))

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

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

Посмею вмешаться, лично я вообще никогда не воспринимал лоскуты как однозначное зло. Встречается даже в некой классификации вид информационной архитектуры в предприятии - "Лоскутное одеяло", имеющий право на жизнь. =) Так что всё зависит от конкретики. Но всё же в банке, моё глубокое имхо, увы, не основанное на практике, лоскутов быть не должно... может я неправ.

86

Системный Анализ и Требования / Re: Сбор и документирование требований к OLAP-отчету

« : 21 Октября 2009, 17:45:29 »

2 KIRILLSS:
Побойтесь Бога, никто на человека не набрасывался! Просто безудержный интерес к теме накладывает эмоциональный отпечаток на стиль изложения. =)

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

87

Системный Анализ и Требования / Re: Сбор и документирование требований к OLAP-отчету

« : 21 Октября 2009, 15:21:39 »

Вообще тут речь идёт о хранилище, поэтому поток данных должен быть направлен именно в хранилище, иначе подобные лоскуты и костыли будут плодиться и дальше, а хранилище теряет смысл. И вообще, создание дополнительного источника данных в обход хранилища для отчётов, да ещё в виде ручного экселя - это вообще ересь, если нет каких-то неозвученных особенных факторов.
ИМХО.

88

О Сайте и Форуме / Re: ДР сайта 2009 - подготовка

« : 21 Октября 2009, 14:14:09 »

Лично для меня лучше Сретенский бульвар
на втором месте Садовая-Черногрязская.

89

Системный Анализ и Требования / Re: Сбор и документирование требований к OLAP-отчету

« : 21 Октября 2009, 14:11:00 »

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

90

Системный Анализ и Требования / Re: Сбор и документирование требований к OLAP-отчету

« : 20 Октября 2009, 09:41:04 »

Хранилища тоже бывают разными, может быть хватит какой-нить а-ля федеративной архитектуры, то есть некой надстройки над уже существующими хранилищами. А так же важно учесть необходимость (будет ли она вообще) масштабирования всей системы, может быть нужны такие отчёты, которые с высокой долей вероятности не притерпят изменений, то есть не потребуются дополнительные данные из другиз ИС или изменения формы и принципа построения. И исходя из требований бизнеса нужно строить информационную основу. Но в любом случае, как было уже сказано коллегами, отчёты, основанные на некорректных и неактуальных данных - нафиг никому не нужны. =)
ИМХО.