5191

Сообщество Аналитиков / Re: МСК - праздник- тусовка ИТ специалистов "мИТинг", 30 августа

« : 03 Июля 2007, 16:16:30 »

ну почему это только в Москве

5192

Идеи и мозговой штурм / Re: Анализ IT-безопасности на предприятиях

« : 03 Июля 2007, 16:11:07 »

Саша, почитай правила эхи

5193

Бизнес-анализ и Целеполагание / Концепция системы и целепологание

« : 03 Июля 2007, 15:58:41 »

Вообще вопрос терминалогии стоит довольно остро.
Надо сказать, что при восприятии нового знания, которое часто формуируется на одном языке, а потом распространяется на другом, вознимкает неоднозначность перевода. Неодназначность - это враг термина. Термин - однозначен и определен. Да в разных ПрОб, один и тот же термин может иметь разные назначения, но  ождной он точно фиксирован. Отсюда понятие тезауруса - как словаря специалиста, отсюда понятие "птичьего" языка. Хтим мы или нет, но он должен быть.
Если посмотреть на понятие "цель" - то в анлгоязычной литературе (а английский здесь законодатель мод) можео встретить кучу определений: goal, objective, aim, purpose, target и другие. И все это часто переводят термином цель. Я согласен еще проводить синонимию слову цель и мишень, т.к. у цели есть значение - "пункт назначения", но полагать слово задача и цель идентичным не правомерно. Задача = проблема, но вовсе не цели. Целью может быть решение задачи, но сказать что у нас задача достижения цели? достаточно не понятно.
Очень важно определится с терминологией и донести ее до общественности. так или иначе, но принять в рамках рассматриваемого вопроса однозначность понимания терминов.
Цель - желаемое состояние системы выраженное количествеными или качественным характеристиками.
Задача - что это? ответ на вопрос? или часть цели? Или самая по себе цель?
Также нужно соотнести англоязычную терминология с русской. Хотя задача сложная ибо англоязычную литературу генерируют не только натуральные носители языка. Взять тот же Open UP, написано просто отвратительно, либо я совершенно не понимаю душу английского языка..

Далее, при определении целей, нужно четко различать конечную и промежуточные цели. Цели идеальне- т.е. не достижимые и цели реальные - достижимые.

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

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

Что это означает? Не то ли, что при целеполагании нужно моделировать не границы системы, а ее окружение?

Закономерность целеобразования. Исследования процесса целеобразо-вания в сложных системах философами, психологами и кибернетиками позво-лили сформулировать некоторые общие закономерности процессов обоснова-ния и структуризации целей в конкретных условиях совершенствования слож-ных систем:
Зависимость представления о цели и формулировки цели от стадии по-знания объекта (процесса). Анализ понятия «цель» позволяет сделать вывод, что, формулируя цель, нужно стремиться отразить в формулировке или в спо-собе представления цели ее активную роль в познании и в то же время сделать ее реалистичной, направить с ее помощью деятельность на получение опреде-ленного результата. При этом формулировка цели и представление о ней зави-сит от стадии познания объекта и в процессе развития представления об объек-те цель может переформулироваться. Коллектив, формирующий цель, должен определить, в каком смысле на данном этапе рассмотрения объекта употребля-ется понятие цель, к какой точке «условной шкалы» («идеальное устремление в будущее» — «конкретный результат деятельности») ближе принимаемая фор-мулировка цели.
Зависимость цели от внутренних и внешних факторов. При анализе при-чин возникновения цели нужно учитывать как внешние по отношению к выде-ленной системе факторы (внешние потребности, мотивы, программы), так и внутренние потребности, мотивы, программы («самодвижение» целостности). При этом цели могут возникать на основе противоречий как между внешними и внутренними факторами, так и между внутренними факторами, имевшимися ранее и вновь возникающими в находившейся в постоянном самодвижении це-лостности. Это очень важное отличие организационных «развивающихся», от-крытых систем от технических (замкнутых, закрытых) систем. Теория управле-ния техническими системами оперирует понятием цели только по отношению к внешним факторам, а в открытых, развивающихся системах цель формирует-ся внутри системы, и внутренние факторы, влияющие на формирование целей, являются такими же объективными, как и внешние.
Возможность сведения задачи формирования общей (главной, глобаль-ной) цели к задаче структуризации цели. Анализ процессов формулирования глобальной цели в сложной системе показывает, что эта цель возникает в соз-нании руководителя или коллектива не как единичное понятие, а как некоторая, достаточно «размытая» область. На любом уровне цель возникает вначале в ви-де «образа» цели. При этом достичь одинакового понимания общей цели всеми исполнителями, по-видимому, принципиально невозможно без ее детализации в виде упорядоченного или неупорядоченного набора взаимосвязанных подце-лей, которые делают ее понятной и более конкретной для разных исполнителей. Таким образом, задача формулирования общей цели в сложных системах долж-на быть сведена к задаче структуризации цели.
Следующие закономерности являются продолжением двух первых при-менительно к структурам цели.
Зависимость способа представления структуры целей от стадии познания объекта или процесса (продолжение первой закономерности). Наиболее рас-пространенным способом представления структур целей является древовидная иерархическая структура. Существуют и другие способы отображения: иерар-хия со «слабыми» связями, табличное или матричное представление, сетевая модель. Иерархическое и матричное описание — это декомпозиция цели в про-странстве, сетевая модель — декомпозиция во времени. Промежуточные под-цели могут формулироваться по мере достижения предыдущей, что может ис-пользоваться как средство управления. Перспективным представляется развер-тывание иерархических структур во времени, т.е. сочетание декомпозиции цели в пространстве и во времени.
Проявление в структуре целей закономерности целостности. В иерархи-ческой структуре целей, как и в любой иерархической структуре, закономер-ность целостности проявляется на каждом уровне иерархии. Применительно к структуре целей это означает, что достижение целей вышележащего уровня не может быть полностью обеспечено достижением подцелей, хотя и зависит от них, и что потребности, мотивы, программы, влияющие на формирование це-лей, нужно исследовать на каждом уровне иерархии.

   Принципы системного анализа [5]:
принцип конечной цели означает абсолютный приоритет конечной це-ли. Имеет правила:
•   для проведения системного анализа необходимо точно сформули-ровать цель;
•   анализ следует проводить на базе уяснения основной цели (функ-ции основного    назначения), при этом определяются существенные свойства показателя качества и критерия оценки;
•   при синтезе любая попытка изменения или улучшения должна оце-ниваться относительно того помогает ли или мешает она достиже-нию цели;
•   цель функционирования системы задается суперсистемой;

5194

Системный Анализ и Требования / Re: К какому типу требований отнести.

« : 02 Июля 2007, 19:31:57 »

Спасибо.
 Будем  выявлять требования!!!

Вообще, если я что-то понимаю, тут разные типы архитектур: и интерактивная, и транзакционная, критическая система тоже имеет место

5195

Системный Анализ и Требования / Re: К какому типу требований отнести.

« : 02 Июля 2007, 17:58:12 »

Задача в целом ясная. И имеет свои реализации. Те же станки с программным управлением. Правда там программа задается один раз оператором и далбше ЧПУ клепает нужные детали из заготовок.
Другой пример фабрика-автомат. Была у нас такая - 8 марта - в годы перестройки загубили.

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

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

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

Судя по запросам, придется решать оптимизационные задачи. задачи обучения системы (если используются нейросетевые методы).

Вообще нужна более конкретизированная постановка, но уже сейчас ясно, что все это и есть требования

5196

Sparx / Re: Практика использования Enterprise Architect

« : 02 Июля 2007, 17:46:50 »

Согласен с предыдущим оратором. Я и сам об этом думал, но как-то постенснялся предложить, так как сам такого не практиковал ни разу. Не было как-то прецедента!
Но способ познания весьма хорош. Сразу становится ясно, что к чему.

5197

Системный Анализ и Требования / Re: К какому типу требований отнести.

« : 02 Июля 2007, 13:51:09 »

Требования определяют:
    * В чем нуждаются заинтересованные лица и
    * Что система должна включать для удовлетворения потребностей заинтересованных лиц.

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

Так что на лицо будут выскокуровневые требования и пользовательские требования., спецификация процесса и т.п.

5198

Sparx / Re: Практика использования Enterprise Architect

« : 02 Июля 2007, 09:12:10 »

Вообще то, я именно так и сделал, причем в ветке "Для всех".
Модератор перенес мое сообщение в эту тему.

Ну извините за нотации.

Спасибо за ответ.

Всегда рад помочь.

А как изобразить такое :

Код: [Выделить]

typedef std::list<ITask*> QList;
?

К сожалению я не знаток C++. Потому не совсем понимаю, что тут такое? Оператор :: что тут указывает? Вызов метода класса без создания объекта? Или нечто иное?

5199

Sparx / Re: Практика использования Enterprise Architect

« : 01 Июля 2007, 21:48:48 »

Вобщем есть у меня набор класов, но в одном класе я хочу определить переменную СВОЕГО типа код на С++ должен получиться приблезительно таким :

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

Ну поругали - теперь ответ на Ваш вопрос.
Прилагается картинка. Есть два способа. UML обычно указывает избегать атрибутов такого типа как класс или перечисление. Т.е. атрибут указывается посредством связи.
Вообщем там два варианта: один - похож на Ваше требование, не знаю только как виртуальный метод изображать; второй вариант - почти такой же, только атрибут удален - и указана связь между классом Менеджер и перечислением Тип-действия

5200

Sparx / Re: Практика использования Enterprise Architect

« : 30 Июня 2007, 21:10:09 »

Хорошо, давайте попробуем так.
И ко мне можно обращаться на "ты" :-)

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

5201

Примеры / Re: Курсовая по UML "Анкетирование" и "Шахматный каталог"

« : 29 Июня 2007, 18:12:58 »

Замечания могут быть такими:
1. Диаграмма вариантов использования - слишком подробна. А что если у Вас появится еще один раздел? Вы же своей диаграммой говорите мне - эти и только эти разделы и больше никакие! Однако в любом случае их можно было описать непосредственно в ВИ. Вряд ли там существуют большие отличия
2. Редактирование шахматного каталога - лучше управление или CRUD, создавать наследование здесь не совсем правильно. Здесь скорее работает шаблон CRUD (но это скорее пожелание, чем критика)
3. На мой взгляд излишняя декомпозиция, причем порой не по уровню цели, а по уровню функции: сортировка там поиск. На мой взгляд любая ИС как минимум должна предоставлять функции поиска сортировки фильтрации отбора, а это уже уровень реализации
4. При описании ВИ используется "интерфейсный" подход. Возможно он не так уж плох, как многие утверждают. Но он ограничивает реализацию: почему нажимает кнопку, а не говорит голосом, или еще как? Я конечнопонимаю, что очень часто так и хочется написать что и где мы нажимаем, но верное ли это? Стоит ли описывать работу с интерфейсом с помощью UC? Не просто ли нарисовать прототип формы, базируясь на более абстрактном UC, без упоминания кнопок и т.п.?
5. неудачные названия для классов предметной области. Почему DataBase - когда говорится о партии?
6. Диаграммы последовательности и кооперации реализованы не на том уровне.
7. Диаграммы состояний = диаграммы деятельности, что на самом деле не так. Уж если писать то о сотоянии объекта - например игры: начата, незавершена, ничья, мат белым, мат черным, пат - ну и так далее..

5202

Примеры / Re: Курсовая по UML "Анкетирование" и "Шахматный каталог"

« : 29 Июня 2007, 17:49:52 »

А что неправильного в диаграмме классов по шахматному каталогу?

Так! Появился автор! Автор в ярости!

5203

Примеры / Re: Курсовая по UML "Анкетирование" и "Шахматный каталог"

« : 29 Июня 2007, 09:50:13 »

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

Саша, я препод! Я могу поставить задачу по-разному. Требования нарисовать ВСЕ виды диаграмм, хотя и избыточно, но может преследовать приобретение навыка рисования таких диаграмм. Правда для курсового проекта лично я вряд ли поставил себе такую задачу.
Постановка твоего плана, много лучше ибо дает студенту гибкость  в применении тех средств, которые наиболее наглядны и информативны.
В данной работе виден явный просчет использования диаграмм деятельности для документирования линейного алгоритма, что ООП не совсем соотвествует.

5204

Обучение / Курс "Корпоративные информационные системы"

« : 28 Июня 2007, 19:14:13 »

Коллеги, друзья, гости!

Я преподаю сию дисциплину уже 5 лет. В начале даже не представлял о чем говорить. Постепенно сложилась некоторая программа: разделил курс на части корпоративная компьютерная инфраструктура и функциональные подсистемы.
ГОс говорит следующее:

Структура корпораций и предприятий; архитектура корпоративных информационных систем (КИС); КИС для автоматизированного управления; КИС для административного управления; информационные технологии управления корпорацией; выбор аппаратно программной платформы; транспортные подсистемы; построение локальных и глобальных связей. Сетевой уровень как средство объединения локальных и глобальных компонентов; межсетевое взаимодействие; межсетевые протоколы; интеллектуальные компоненты; мобильные компоненты; сетевые приложения. Административное управление КИС; технологии ATM, map/top и интранет; моделирование и проектирование КИС; программирование в КИС; примеры КИС.

Примерная программа здесь/ Не уверен только работает ли ссылка.

Реально преподаю в таком духе: понятие управления. цикл управления. оргструктура. виды производств и их потребности
классификация КИС, понятие MRP, проектирование КИС и отличие от проектирования ИС, представители.

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

5205

Идеи и мозговой штурм / Анализ IT-безопасности на предприятиях

« : 28 Июня 2007, 19:02:14 »

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

Давайте обсудим этот аспект.