91

Для всех / Руководство администратора: структура документа

« : 12 Декабря 2011, 13:00:23 »

Коллеги, нужен совет.

1. Прошу проконсультировать, какой из документов ГОСТ больше всего соответствует документу "Руководство администратора"?


- Руководство по техническом обслуживанию.
- Руководство оператора.
- Руководство программиста.    
- Руководство системного программиста.


2. После написания нескольких РА, я выработал некоторую структуру этого документа. Прошу покритиковать её.

Аннотация
1   Контроль документа
1.1   История изменений
1.2   Рецензенты
2   Назначение и цели создания системы
2.1   Назначение системы
2.2   Цели создания системы
2.3   Условия применения системы
3   Принципы функционирования системы
4   Обязанности и задачи администратора
5   Обслуживание системы
5.1   Настройка параметров работы системы
5.2   Ведение нормативно-справочной информации
5.3   Учетные записи пользователей и управление ими
5.4   Назначение пользователям прав доступа
5.5   Загрузка и выгрузка данных
6   Проблемы в работе системы и способы их решения
7   Глоссарий
Утверждающие подписи

92

Варианты Использования (Use Case) / Re: ВИ->функция

« : 05 Декабря 2011, 15:24:01 »

В дополнение к сообщению от Эдуарда...
Вот тут (http://it-analysis.blogspot.com/2010/12/use-case.html) я подводил итоги анализа статьи от Юрия Булуй, в которой Юрий как раз обозначил отличия между вариантом использования и функцией системы.

93

Для всех / Re: Многие путают ху из ху. Надо разобратся!

« : 05 Декабря 2011, 10:08:49 »

Вот тут есть ещё информация: http://it-analysis.blogspot.com/2010/12/blog-post_12.html

94

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 02 Декабря 2011, 10:49:50 »

Я ЗА!!!!

Добавил.

95

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 01 Декабря 2011, 10:44:05 »

Предлагаю добавить в ленту материал по BPMN с сайта Анатолия Белайчука: http://mainthing.ru/ru/tag/bpmn/

96

IDEF ARIS BPMN и пр. / Re: BPMN + DFD. Правиьлно ли это?

« : 30 Ноября 2011, 10:15:15 »

Про стрелки в IDEF0 знаю, только никогда не знал, что это так называется одним сокращением )

По сути:
* IO - есть в BPMN
* C - в какой-то мере, это кто исполняет БП (есть BPMN), но более шире
* М - не так часто встречал, что в реальных примерах это использовалось.

Я думаю не зря ушли от CM в более новых нотациях.

Александр, не совсем с тобой соглашусь.

C - это правила, документация, в соответствии с которыми должен выполняться процесс, а вот M - это как раз тот, кто исполняет БП.

Кстати, по поводу ICOM... Я в литературе читал (автор Черемных или Маклаков), что правильно говорить не ICOM-модель, а ICOM-коды. Ведь именно эти коды идентифицируют стрелки, входящие (исходящие) из IDEF-блока.

97

IDEF ARIS BPMN и пр. / Re: BPMN + DFD. Правиьлно ли это?

« : 29 Ноября 2011, 10:23:11 »

Сорри, за глупый вопрос, а что такое ICOM модель?

I - input
C - control
O - output
M - mechanism

По сути, это стрелки, которые входят в IDEF0-блок.

98

IDEF ARIS BPMN и пр. / Re: BPMN + DFD. Правиьлно ли это?

« : 28 Ноября 2011, 09:57:24 »

Выражаю свою точку зрения.

Как я понимаю, Вам необходимо именно в графическом виде изобразить бизнес-процессы? Если да, то почему бы и не описать их именно в таком ключе, указав в итоговом документе общий принцип? Мне такой подход нравится. В нём, как и в других подходах заложен принцип декомпозиции. Единственное в чем разница - это то, что на нижних уровнях Вы используете BPMN, которая, на мой взгляд, является более подробной, насыщенной и понятной, нежели IDEF3.

Но я могу быть не прав. Интересно выслушать мнение коллег.

99

Конференции Семинары и Тренинги / Re: Отзывы о ЛАФ 2011

« : 22 Ноября 2011, 11:06:56 »

Благодарю за труд!

100

Обучение / Re: Почему аналитику вреден опыт программиста?

« : 26 Октября 2011, 11:56:06 »

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

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

101

Для всех / Re: а получили как всегда

« : 20 Октября 2011, 22:03:25 »

Картинка с качелями немного приелась, а тут такой шикарный пример расползания требований в процессе разработки:
http://img-fotki.yandex.ru/get/4710/32070366.1b/0_67d73_c8f3a7a5_orig

Утверждают, что это "Крокодил" за 1982 год.

Журнал под номером 31, http://old-crocodile.livejournal.com/178535.html

102

Обучение / Re: Предложили работать аналитиком сами, и зацепило

« : 19 Октября 2011, 17:35:16 »

Кстати, очень интересный вопрос, которым мы иногда ставим в тупик соискателей на собеседовании, а, в чем, собственно, разница между бизнес и системным аналитиком? Где можно провести границу между их зонами отвественности?

Юрий Веденин как-то в своём блоге заводил обсуждение: http://yuri.vedenin.net/2010/01/08/compare-business-analyst-and-systems-analyst/

Я тоже как-то интересовался этим вопросом: http://it-analysis.blogspot.com/2010/12/blog-post_12.html

103

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 14 Октября 2011, 23:06:10 »

Почему бы и нет

Добавил рубрику "Разработка ПО": http://dev.usecase.ru/

Коллеги, если у вас есть предложения - постите в эту тему. Буду добавлять интересные нам блоги в ленту.
Спасибо.

104

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 14 Октября 2011, 12:28:56 »

http://www.usecase.ru/ - интересен ресурс?

105

Примеры / Re: UC. Жизенный цикл заказа

« : 13 Октября 2011, 14:35:49 »

Спасибо, таким образом я мог на UC показать только общие действия?, например:

• Клиент - (Оформление заказа), (Получение заказа), (Проверка заказа)
• Оператор - (Прием заказа), (Ввод заказа в систему), (Отправка заказа на склад)
• Сотрудник склада - (Формирование заказа), (Выдача заказа), (Компенсация недовложение)

и затем по каждому кейсу составить более подробную диаграмму, например activity?

Применительно к UML допускается строить сначала например общий вид UC, а затем каждый кейс изображать отдельной UC-диаграммой, более детализированной? Или же это не верный подход и детализировать нужно другим типом диаграммы?

Заранее извиняюсь за наивные вопросы, стараюсь понять общие принципы на практике, т.к. в литературе однозначных ответов найти непросто.

Спасибо!

el-niko, есть понятие бизнес вариантов использования, а есть понятия системных вариантов использования. Отличия см. тут: http://www.uml2.ru/index.php?option=com_content&task=view&id=75&Itemid=51

Декомпозиция вариантов использования на варианты использования - в корне неверный подход (хотя, например, Enterprise Architect позволяет это делать).