1801
Варианты Использования (Use Case) / Re: Рефакторинг мельчащих use-case'ов
« : 03 Сентября 2007, 18:25:51 »
Саша, не понял. Что конкретно не так и что делать?
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
А какие еще есть гипотезы, что такое "системный анализ в IT сейчас"?Доминирующая гипотеза, на мой взгляд, что это знание нотаций моделирования UML, IDEF (ошибочно называемых "методологиями") и соответствующих CASE-средств.
Ну, вот расстраивает даже не то, что "не читали", а то, что "не слышали". В русском гугле поиск по "анализ требований" выдает на первой же странице ссылку на книжку Мацяшека, по "управление требованиями" - на Леффингуэалла. Ну, т.е. начни интересоваться, и приведет тебя интернет куда надо...Во-первых, сначала нужно приобрести знание, что системный анализ в IT сейчас - это в значительной мере "анализ и управление требованиями", а это как минимум не очевидно. Как говорится, правильно поставленный вопрос - половина ответа.
А можно подробнее про этот график? Картиночка старенькая, может есть такая посвежее?Ну вообще там показано, что BPM suites находится на пике в августе 2005-го, и период выхода на плато продуктивности (см. легенду) - 2-5 лет. Т.е. по их прогнозам приблизительно сейчас на западе эти технологии должны становиться мейнстримом.
И как его правильно интерпретировать ...http://www.gartner.com/pages/story.php.id.8795.s.8.jsp
В данном примере идет речь о производстве товара. А в дискуссии ранее, речь шла об распространенной ситуации, когда предприятие приглашает к себе Разработчика для внедрения/разработки требуемого ПО или ИС.И там и там - производство цифрового продукта. Заказчик и разработчик игры тоже могут не в одной организации находиться. Разработчик может заниматься внедрением? Ок, так и в случае MMORPG разработчик постоянно занят доработками и развёртыванием версий ПО (игры).
ИМХО сейчас термин ИС равноценен термину АС и термину АИС. Поэтому думаю, что использование терминов ИС и ПО зависят от конкретных частных случаев.Различение этих терминов произведено вот здесь.
World of Warcraft относится к классу прикладного ПО: к мультимедия - компьютерные игры. Заказчик - одно из подразделений компании Blizzard Entertainment. Скорее всего департамент маркетинга совместно с дирекцией.Итак, разработка прикладного ПО на основании требований Заказчика. Какие СУЩЕСТВУЮЩИЕ БИЗНЕС-ПРОЦЕССЫ автоматизируются при создании такого ПО?
Разработчик - тоже один из внутренних департаментов, и тоже скорее всего не один.
С последней фразы я плакальЯ имел в виду - бизнес-процессы как объект изучения и моделирования.
Оказывается это БП нужны для ПО, а не наооборот. Т.е. в принципе ПО существует само по себе, в отрыве от окружающей действительности. Бугога))
Зачем читать то что не написано? Зачем искать черную кошку там где ее нет?Хорошо, простой вопрос - World of Warcraft - это какое ПО по назначению? Заказчик у него есть?
Я написал:
Насколько известно ПО по назначению разделяется на: системное, прикладное и инструментальное.
Речь идет в дисскусии идет о разработке прикладного ПО по требованиям Заказчика. При чем приведенная Вами "классификация" непонятно. Можно конечно долго фантазировать и выдумать собственные типы классификации ПО. Но . . .
Второй раз повторюсь, что я не разработчик, поэтому ЛИЧНО для меня вопрос методологии проектирования ПО до конца не изучен.Проектирование, например, по RUP - одна из 9 дисциплин. Проектирование ПО происходит на основании Требований, Требования появляются на основе целевого Бизнес- и сценарного Моделирования, им предшествует Постановка целей. Вы упорно про Проектирование (которое не отсюда), а нам щас интереснее Постановка целей %)
Оффтоп: Мне просто интересен вопрос использования и применимости существующих методик и стандартов, на всех этапах работы Заказчик - Разработчик. Наверно пожалуй на начала необходимо расписать или выложить готовый схему процесса разработки ПО.Вы не поверите, но схема организации процесса разработки ИС также освещалась мной. Ну и, само собой, в RUP/MSF и книжках по автоматизации - Калянов и проч.
...
Основной задачей при проектировании ПО является автоматизация существующих БИЗНЕС-ПРОЦЕССОВ (БП) предприятия или организации.
Вопрос не в том, насколько полно и точно мы выявляем цели, потребности, мотивы и установки пользователей, а в том насколько точно и полно разрабатываемое ПО маппируется на существующие БП. Т.е. насколько полно разрабатываемое ПО автоматизирует БП (функции, задачи и операции).Это классическая проблема с асфальтированием дорог, по которым ходят коровы. ПО должно не автоматизировать процессы, а помогать решать бизнес-задачи. Вот эти самые бизнес-задачи и формулируются в ходе целеполагания.
К примеру, у нас есть некая организация, которая занимается торговлей канцелярскими товарами со склада. Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.Вы про фазу ПРОЕКТИРОВАНИЯ систем и цели ПОЛЬЗОВАТЕЛЕЙ в рамках целевых бизнес-процессов, мы же - про фазу ИНИЦИАЦИИ и цели ЗАИНТЕРЕСОВАННЫХ ЛИЦ (прежде всего, Заказчика, но не только). Такое ощущение, что вы презентацию Boatman не смотрели.
Хм . . . тогда вопрос в том есть ли какие методы (применяемые и работающие) для выявления требований Заказчика в "типичном варианте"?Эта тема уже раскрывалась мной.