301

Конференции Семинары и Тренинги / Re: Курсы системных аналитиков в Новосибирске

« : 23 Октября 2014, 13:02:15 »

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

Зато у него будет сертификат! и рекомендации преподавателей (черт возьми, как это важно в нашем мире)))

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

Непустая графа "Рекомендации" - это еще один грамм.

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

302

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 20 Октября 2014, 16:38:00 »

Нашел: http://gaperton.livejournal.com/49867.html

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

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

Ну, либо автор пишет о чем-то своем, а не применении ГОСТ в разработке для заказчика.

Работать по ГОСТ-у сложно.

Дело привычки, полагаю. Мне сложно работать не по ГОСТу - нет ни понятных и принятых обеим сторонам правил игры, зад прикрыть нечем (в т.ч. заказчику), зато креатива (с обеих сторон) - хоть отбавляй.

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

Не совсем понял, какое отношение этот текст имеет, скажем, к 34 ГОСТ?
Ну и "план работы" без исполнителей, трудоемкости и активностей - тот еще план.

303

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 20 Октября 2014, 11:52:51 »

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

И да... Не относитесь к этим примерам слишком серьезно. Я пока не видел в интернетах примера ТЗ по 34 ГОСТ, на который можно было бы равняться. Их и в жизни-то крайне мало. В одном хорошо одно, в другом - другое. Поскольку каждое "живое" ТЗ - продукт жесткого компромисса между сроками, функционалом, стоимостью и внутренней согласованностью (безбаговости самого ТЗ, если угодно).

304

Для всех / Re: Пишем ТЗ по ГОСТ 34

« : 20 Октября 2014, 11:26:51 »

В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП

то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.

Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ?

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

Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?

Цель ТЗ - обозначить, что делаем. Как делаем - предмет эскизного (если у вас он предусмотрен) и технического проектов.

А что делать с таким описанием...?

Пронумеровать?

По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".

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

До этого момента предполагал, что в пункте "Требования к функциям (задачам), выполняемым системой" нужно приводить четкие и конкретно сформулированные ФТ по каждой из подсистем.

Да. Чем требование "Система должна позволять ... создание дисциплин" Нечеткое и неконкретное?
Уровень абстракции выбирается исходя из сложившихся реалий и преследуемых целей.

В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).

Да.

То есть раздел "Требования к функциям (задачам), выполняемым системой" - должен представлять собой полное описание всех функциональных требований в развернутой форме со всеми входными и выходными параметрами?

Ну вот что значит "полное"? Например, "Перечень входных сигналов и данных" или "Перечень выходных сигналов (документов)" по ГОСТ 34 - это документы технического проекта (даже не эскизного).
Вообще, для лучшего понимания - что, где и как предусмотрено в ГОСТе, было бы полезно прочитать 34.201, 34.601 и РД 50-34.698-90.

ГОСТ 34 - цельная система. ТЗ, как одна из ее частей, очень сильно связана со всем остальным. Понять, почему ТЗ именно такое, без понимания его места и роли в общей картине (т.е. глядя на мир только "изнутри" ТЗ) достаточно проблематично.

А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".

Описывать там то, что вы наавтоматизировали.

305

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 13 Октября 2014, 13:06:35 »

Я имел в виду некий чек лист (экспертная система - это скорее развитие чек листа), по которому студент может себя проверить перед тем, как сдавать работу.

Аналог "ЧАВО" сделать вполне реалистично. Был бы достаточной объем работ студентов и начинающих аналитиков для систематизации и анализа ошибок. Вопрос - где их взять и где взять на них время.

306

Теория моделирования и нотации / Re: Диаграмма деятельности. Слияние большого числа потоков условий

« : 13 Октября 2014, 11:54:59 »

скажите пожалуйста, допустим у меня есть шаг 1 к нему идут 3-5 альтернатив, как это сделать?

Не знаю, как "по науке". Я просто рисую "грабли" с нужным количеством входящих/исходящих веток и подписываю условие (XOR, OR, AND и/или их частные случаи)

307

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 13 Октября 2014, 11:51:50 »

английский subject - это субъект и предмет и объект и тема

Да, есть такое. Особенно в "просторечии". Однако у нас это разные вещи, особенно в методологической литературе. Вполне вероятно, путаницу внес переводчик, не разобравшись. Соответственно, я бы не стал предлагать ее студентам. Мало ли, где он там еще не разобрался.
Жаль, не удалось посмотреть, как там в оригинале.

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

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

308

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 13 Октября 2014, 11:28:33 »

В дополнение.

1. Я бы разделил активности (столбики) по отдельным операциям. Например, первая же операция у клиента (вводи пина) должна закончится передачей пина. А у банкомата, соответственно, начаться. И закончится передачей доступных опций (примечание: а доступные опции таки зависят от того, чью карту в него засунули). Вторая активность клиента начнется получением "меню", и завершится отправкой введенной суммы.
А у банкомата вообще все - одна сплошная активность. Это непорядок.

2. По-моему, клиент забыл:
а) сунуть карту;
б) забрать наличные.

309

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 18:39:01 »

Кстати, в той же книге сказано:

"1.3. Модель имеет единственный субъект 
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система ... SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования,"

Обычно, "субъект" - это тот, кто выполняет действия над объектом. "Объект", соответственно, то, над чем выполняются действия.
В книге эти понятия применяются несколько странно - я так и не понял из приведенного раздела, кто там кого моделирует и кто кому задает границы.
Тут вариантов несколько: или переводчик чего-то сильно напортачил, или авторы были где-то глубоко в себе, или с 86 года что-то сильно изменилось.

В любом случае, я бы не стал особо доверять конкретно этой книге.

http://thedifference.ru/chem-otlichaetsya-obekt-ot-subekta/

310

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 17:40:16 »

урок 2

Ужас-ужас:
1. Составьте множество вопросов, на которые должна отвечать модель.
2. С помощью этого набора вопросов определите, как будет использоваться модель.
3. Если вы не можете сформулировать, как она будет использоваться, попробуйте записать еще вопросы...

Все, финиш. Терзания на тему "куда бы пристроить эту модель?".

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

То есть, ровно наоборот. Видимо, я совершенно безнадежен.

Что касается точек зрения, то ничего не имею против моделей, описывающих объект с разных сторон. Мы все этим занимаемся, как минимум, "в уме". Кроме того, их было бы прикольно сравнивать ("слон сбоку" vs "слон сзади" vs "слон глазами блохи" vs "слон глазами охотника"). Но во-первых, достоверность (либо детализация) таких моделей будет невелика, а во-вторых, есть более дешевые способы учета интересов "заинтересованных лиц".

311

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 16:10:06 »

Леонид, но мы формулируем не вообще цель проекта, а цель моделирования, цель модели. Основное назначение модели - ответить на вопросы, исходя из этого. Как бы Вы уточнили цель модели(моделирования) и соответственно точку зрения?

Да, я просто предложил дать понять, что эта "цель" не нечто самоценное, а лишь звено в цепочке, которое ведет к полезному в жизни результату.

Если же ограничиться только моделью, то мне не очень понятно, что за цель может быть у модели (это же просто инструмент, довольно универсальный). У нее может быть назначение: "для демонстрации бигбоссу, что мы не зря получаем зарплату", "для создания представления о предметной области у программистов", "для заполнения обязательного раздела технической документации", "в качестве основы для дальнейшего моделирования", "для обозначения границы создаваемой системы" и т.п.

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

С "точкой зрения" скачать что-то затрудняюсь. Если она действительно нужна, то и так неплохо.

312

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 15:31:49 »

А Вы как бы сформулировали данную цель (итог по сути сформулировать требования к информационной системе)?

Например, "разработка исчерпывающей системы требований на создание информационной системы".

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

313

IDEF ARIS BPMN и пр. / Re: Характерные ошибки построения IDEF0 диаграмм

« : 10 Октября 2014, 12:15:26 »

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

Выход
2. "Продукция" и "Прибыль" на этом уровне абстракции - суть две стороны одной медали. "Прибыль", наверное, даже правильнее, поскольку название процесса завершается "и продажей".
3. "Реклама" точно не является результатом производства и продажи мебели. С бОльшими на то основаниями ее можно включить в "механизмы". В качестве "двигателя торговли".

Контроль
4. "Политика" в целом неплохо применима к продажной части процесса. Желательно иметь что-то и для производственной.

Механизмы
5. "Сотрудники" - безусловно, а почему отсутствует "оборудование"?

P.S. по "цель"
1. Я бы не стал начинать формулировку цели с "Понять".
2. Эта цель имеет отношение к изображенной модели? Судя по ее содержанию - она относится к более крупной деятельности, частью (артефактом) которой может являться модель. Соответственно, размещение такой цели рядом с моделью может вводить в заблуждение.

314

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 01 Октября 2014, 15:25:54 »

А зачем выявлять требования, но не описывать их? Agile?.

Нет. Прокурор.

315

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 26 Сентября 2014, 10:48:03 »

Так или иначе, это вне моей компетенции.

Я понимаю. Это для придания осмысленности этой деятельности для студентов.

Ну если почитать определение законодательство РФ, не может. К тому же, что вот Вы вкладываете в понятие БД?

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

К тому же, что вот Вы вкладываете в понятие БД?

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

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

Второй - БД.

И в чем же тут принципиальное различие?

В позиции наблюдателя. В одном случае она внутри ИС, во втором - снаружи.

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

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