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

×


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

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


Сообщения - Denis Beskov

2221
Введение в анализ, синтез и моделирование систем
Типичный пример вузовского подхода - теория настолько общая, что применений к практике особо не видно) Но полезно местами.

Проектирование информационных систем

Нотация и семантика языка UML

Визуальное моделирование в среде IBM Rational Rose 2003

Компонентный подход в программировании
На самом деле этот отличнейший вводный курс посвящён в основном инженерии ПО и компонентному подходу в разработке ИС. Его особенно рекомендую проектировщикам и архитекторам.

2222
Эдуард, было бы здорово, если бы вы дали ссылку на источник.

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

2223
О Сайте и Форуме / Re: Разделы Форума №2
« : 02 Января 2007, 14:05:32 »
...тратить силы учасников и модераторов на классификацию и пересортировку такого маленького множества тем считаю нецелесообразным.
Как будто тратить силы на пересортировку БОЛЬШОГО множества будет целесообразней )

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

В качестве одного из таких терминов предлагаю рассмотреть понятие "Предметная область". Как я понимаю, в русском языке ему соответствуют смежные понятия "Область исследования", "Область изучения", "Предмет интереса". В английском языке - Domain, Field of Study.

Так вот, ряд авторов, например Эрик Иванс, автор книги и методики Domain Driven Design ("Проектирование от предметной области"), похоже, под моделью предметной области прежде всего понимает структурно-классовую модель сущностей, их свойств и связей и, что важно, пренебрегает остальными.

В RUP и соответствующих ему инструментах говорится о BOM (Business Оbject Model) - Модель бизнес-объектов и BUC (Business Use-Case Model) - Модели бизнес-прецедентов.

В среде аналитиков бизнеса я неоднократно встречал документы, высказывания и т.д., из которых следует, что они склонны сводить описание ПрОбл (Предметной области) к модели бизнес-процессов, а старая школа -> + модели потоков и модели функций/алгоритмов.

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

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

Итак, на мой взгляд, описание предметной области в общем случае должно включать:
  • Определения терминов (какой смысл рисовать BUC "Выпедряниванивание агломериков", если в модели не определено, что означают составляющие его термины?).
  • Концептуальная модель взаимосвязи понятий (Когнитивная карта, Карта концептов, Семантическая сеть, Фрейм) - чтобы получить целостную понятийную картину.
  • Описание основных событий и их взаимосвязи.
  • Описание процессов.
  • Описание потоков.
  • Описание действующих лиц, ролей или субъектов и их взаимосвязи.
  • Описание интересов действующих лиц
  • Описание сущностей, их свойств и их взаимосвязей.
  • Описание правил взаимодействия сущностей и актёров, протекания процессов и возникновения события.
  • Описание состояний сущностей и правил перехода между ними.

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

Конкретный набор типов описаний, которые имеют смысл в данном проекте, должен определяться аналитиками.

2225
ESB, Enterprise Service Bus, Сервисная шина предпрития - один из уровней IT-архитектуры современного "гибкого" предприятия, представляющий единый интерфейс к имеющимся сервисам.

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

см. http://en.wikipedia.org/wiki/Enterprise_service_bus

2226
SOA - подход к построению IT-архитектуры приложений современного предприятия, Service-Oriented Architecture, Сервисно-Ориентированная Архитектура. Предполагает ре/организацию IT-ресурсов предприятия таким образом, чтобы они имели стандартизированные интерфейсы доступа, например, в виде веб-сервисов, работающие по единому принципу. Считается, что такая организация поможет IT быстро перестраиваться под быстроизменяющийся бизнес за счёт выстраивания цепочек бизнес-процессов из сервисов (служб), построенных на приложениях различной степени свежести и технологий и их быстрой реорганизации. Организация и управление набором служб и соответсвующих бизнес-процессов получили название Service Orchestration, Choreography и Business Process Management.

см. http://en.wikipedia.org/wiki/Service-oriented_architecture

2227
Посмотрел конечно бегло, но отличий не так уж много от РУП, в чем преимущество данного процесса разработки?
Преимущество процесса - он оптимизмирован под Agile, убрано всё то избыточное, чем можно пожертвовать, согласно принципу KISS, который поддерживают многие агилисты. Преимущество данной базы знаний - то, что она открытая, бесплатная и её можно настраивать как угодно с помощью открытого Eclipse Process Composer.

см. http://en.wikipedia.org/wiki/OpenUP/Basic

2228
В качестве примера цели, ресурсов и ограничений:

Цель: Создать методику преподавания системного анализа для студентов специальности "Информационные системы".

(Т.е. продукт, система - Методика)

Критерии достижения цели
  • Применение данной методики позволяет систематически обучать студентов с получением среднего бала по группе не ниже 4,0 по разработанной системе тестов по перечню навыков или
  • Не менее 40% cтудентов, обучаемых согласно данной методике, могут успешно работать (по признанию работодателя) в качестве помощника аналитика по окончанию обучения.

Ресурсы
Для реализации методики могут использоваться аудиторный фонд института (в пределах 50 часов), интернет-ресурсы (в пределах 30 часов). Для преподавания могут быть привлечены 2 преподавателя.

Ограничения
Методика обучения не должна тематически серьёзно отличаться от ГОСа.
Методика обучения должна позволять обучение студентам, закончившим 2 курса технического вуза.
Методика обучения должна позволять достижение целей обучения за 1 семестр и 74 часа занятий.
Методика должна позволять обучение не менее 30 человек/семестр.
Использование методики не должно предполагать закупку нового оборудования или ПО сверх имеющегося фонда.

... и т.д.

2229
Хотите среду - давайте смотреть Naumen Agile Tools.

Они действительно хотели сделать что-то работающее или просто отработали гранд?
Насколько я понял из семинара и общения с ними - действительно хотели, но с июля никаких видимых подвижек сделано не было - ПМ объяснял это тем, что свалились срочные работы, в частности, как я понял, гос-во хотело тысячи страниц документации по проекту, наверняка туда ушли все ресурсы. Такой вот Agile, умертвлённый в anti-agile формализме гос-ва )

2230
Проблемы:
* Организация итерационного процесса разработки
* Организация управления качеством ПО
* Организация распределённой разработки

Задачи:

Исследование и применение SOA
Исследование концепии ESB

Создание принципов, концепции и прототипа системы управления техническими знаниями

Поверхностное знакомство с темами:
* Бухучёт
* Планирование
* Операционный менеджмент
* Управленческий учёт

Освоение методики ARIS

Изучение языков Java(Oracle)/Smalltalk/Ruby/Python

2231
Вот спасибо удружил. Заколебался ставить. Ладно сама программа весит 13 метров, так еще пришлось качать NET framework 2.0, а также windowsinstaller 3.0 все всместе уже к 70 метров потянуло
Если вы хотите ставить новый разнообразный софт, то вам рано или поздно придётся поставить JavaJRE, .Net Framework и проч. библиотеки.
Цитировать
Поставил - торомза ужас, а рисование - без кружки пива не поймешь, стрелки то рисуются то нет, то сами вдруг разветвляются. Да если внедрять такой продукт
Зачем внядрять? Речь шла об использовании в учебном процессе с возможностью разработки небольших проектов.
Цитировать
то сначала самому надо полгода его разбирать. И какие ресурсы под систему требуются? Если на Sempronaх 2800 крепко тормозит?
А вы как хотели - на блюдечке с голубой каёмочкой? )

Вуз вам должен выдать бесплатные версии профессионального ПО, чтобы вы могли на нём обучать студентов, с одной стороны, подсаживая на конкретные продукты, а с другой - не давая им возможности заработать с их помощью, получить отдачу от своих знаний, т.к. стоимость рабочей лицензии профессионального коммерческого ПО - несколько сотен долларов, в отличие от систем типа Eclipse?

Рубцов, автор IDEF0/Doctor - одиночка-энтузиаст. Если вы хотите, чтобы существовали хорошие и бесплатные инструменты, лучшее, что можно сделать - связаться с автором, изложить ему предложения по развитию системы, обратить внимание на узкие места и проблемы и т.д.

2232
Ссылка-то не работает http://archive.beskov.ru/openup/
У меня работает и из офиса и из дома, в чём может быть дело - не знаю, может браузер, может java.

2233
ИМХО, оффтопик, есть же специальная тема для обсуждения разделов Форума:
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=49.0
ну так остеки и перенеси тему

2234
1. Целеполагаение (на очень люблю введенное еще ГОСТ 19 словосочетание "постановка задачи") может быть по отношению к бизнесу (бизнес-цели, миссия в классическом смысле) и по отношнению к создаваемой системе. Очевидно, что не все бизнес-цели из иерархии должна "обслуживать" создаваемая система. Получается стоит явно указать что за целепологание.
Я здесь имел в виду цели проекта.

Цитировать
2. Что "за процессы разработки ПО есть сказать"? Как отделить от вышеперечисленного, по каким признакам?
Это взгляд на картину вцелом + обсуждение отдельных дисциплин знаний (Управление качеством и тестирование, Управление изменениями, Окружение, Управление конфигурацией), которые не были пока выделены явно в отдельные разделы.

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