5596

Бизнес-анализ и Целеполагание / Роль бизнес-аналитика

« : 15 Марта 2007, 12:24:51 »

Коллеги, давайте все-таки подискутируем и определимся окончательно, кто что и как понимает под понятием бизнес-анализ и бизнес-аналитик. Что это за роль , какое место она занимает, как соотносится с ИТ-проектами.

Т.е. я все-таки от себя постулирую тот факт, что понимание, анализ и поиск путей решения проблем бизнеса, задача не тривиальная и требует серьезной подготовки и солидного опыта. Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.

Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.

Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.

Основными ролями в проектной команде по RUP, участвующими в бизнес моделирования являются:
•   бизнес аналитик (Business-Process Analyst);
•   бизнес проектировщик (Business Designer);
•   рецензент моделей бизнес процессов и моделей анализа бизнеса (Business-Model Reviewer).

Основными видами деятельности бизнес аналитика являются:
•   оценка организации заказчика;
•   определение и уточнение целей организации заказчика;
•   определение бизнес правил;
•   разработка словаря бизнес терминов;
•   выявление бизнес процессов и действующих лиц, инициирующих процесс или являющихся потребителями его результатов;
•   уточнение связей между бизнес процессами;
•   описание архитектуры бизнеса;
•   разработка рекомендаций по бизнес моделированию.
Результатами деятельности бизнес аналитика являются:
•   разработанные модели бизнес процессов и модели анализа или объектные модели, описывающие реализа-ции бизнес процессов;
•   подготовленные документы:
•   документ Оценка автоматизируемой организации (Target-Organization Assessment);
•   документ Архитектура бизнеса (Business Architecture Document);
•   документ  Словарь предметной области (Business Glossary);
•   документ  Бизнес правила (Business Rule);
•   документ  Концепция развития организации (Business Vision);
•   документ Дополнительные требования к деятельности организации (Supplementary Business Specifications);
•   документ Рекомендации по бизнес моделированию (Guidelines).

Основными видами деятельности бизнес проектировщика являются:
•   описание бизнес процессов;
•   определение участников бизнес процессов;
•   детальное описание участников бизнес процессов;
•   детальное описание бизнес сущностей;
•   определение требований к системе на основе документов и моделей.
Основными результатами деятельности бизнес проектировщика являются:
•   документ Описание бизнес процесса (Business Use Case);

Основными видами деятельности рецензента моделей бизнес процессов и моделей анализа бизнеса или объект-ных моделей бизнеса являются:
•   рецензирование модели бизнес процессов;
•   рецензирование моделей анализа или объектных моделей бизнеса.
Результатами деятельности рецензента моделей бизнес процессов и объектных моделей бизнеса являются:
•   рецензии на модели бизнес процессов;
•   рецензии на модели анализа бизнеса или объектные модели бизнеса.

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

Как мы видим процесс бизнес-моделирования включает как минимум три различные роли. Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?

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

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

5597

Системный Анализ и Требования / Re: Источники требований, полнота требований, взаимосвязь с целями

« : 15 Марта 2007, 11:37:06 »

О, ОБЕСПЕЧЕНИЕ - это один из самых дурацких терминов, всё давно хочу пройтись по нему Что такое в данном случае ОБЕСПЕЧЕНИЕ - это ОБЪЕКТ, ПРОЦЕСС, УСЛОВИЕ, ПОДСИСТЕМА? Что-то другое? Что?

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

По поводу "и т.д." - лингвистическое обеспечение нужно? А технологическое? А где полный перечень? Где-таки ответы на вопросы А-Г? Кто сказал, что люой системе нужно каждое это ОБЕСПЕЧЕНИЕ?

Читай основы информационных систем. Нужно или нет любой ИС каждое из обеспечений вопрос, конечно, спорный. Однако мы можем точно сказать исходя из определения ИС, что требуются технические, программные средства, информационная составляющая и персонал. Без этого нет ИС, а остается например приложение. Можно ли назвать систему Гарант информационной - и да, и нет. Если это отчуждаемый продукт - то мы знаем для его работу нужен компьютер и приложение. Однако кто-то занимается наполнением Гаранта, его обновлением и прочее. Так или иначе я бы не стал называть гарант ИС - есть предоставление информации, но нет ввода, обновления и изменения ее, кроме как общее обновления релиза.
А вот скажем систему управления контентом Joomla, Drupal и т.п. можно смело называть ИС - присутствуют все необходимые ее компоненты. Не будет администратора - система превратится в простую справочную...

ВЫТЕКАЕТ - это хорошо сказано. А если системой будут пользоваться не люди, а она инфраструктурная?

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

Т.е. мы должны иметь перечень правил формирования требований типа:
...
Правило 143.2.а Если систему будут использовать люди, ТО нужна пользовательская документация. ЕСЛИ систему не будут использовать люди, ТО пользовательская документация не нужна.
...

есть понятие ручная информационная система
автоматизированная ИС
автоматическая ИС

Нужнали пользовательская документация? Весь вопрос в том кто пользуется. Ясно что если система делается для реализации функций людей - нужна однозначно (справка или документация не важно)
Если система полностью автоматическая - нужна документация ориентированная на обслуживающий персонал - читай теже пользователи

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

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

У меня есть идея для метода выявления требований, но она никак не "прекрасно видима".
Короче, сплошной постмодернизм. Значит, владелец системы, который сформировал концепцию системы, которой созданная система соответствует, целостным видением её не обладает?
Я бы даже сказал так, что под определённым углом всё есть требования, как всё есть игра и т.д.

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

Модератор: подкорректировал отображение цитат

5598

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 18:46:43 »

Ребята! Я с вами полностью согласен.

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

Поэтому надо определиться с местом бизнес-анализа в преломлении задач, решение которых связано с информационными технологиями. И тут тоже есть несколько направление - реализация ИТ-проектов устраняющих СУЩЕСТВУЮЩИЕ проблемы или проблемы, КОТОРЫЕ МОГУТ ВОЗНИКНУТЬ. Другое направление может быть связано с использованием информационных технологий для самого бизнес-анализа.

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

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

5599

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 14:16:12 »

А ты кто?

Я преподаватель. Если представить себе роль в ИТ-индустрии, то скорее тот, кто реализует решение

Это уже не целеполагание, это переход к конкретным задачам. Цель в приведённом тобой примере - это скорее всего "сохранение темпов производства" или "увеличение темпов производства"

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

Ты серьёзно думаешь, что ИТ-специалист захочет обращаться к аналитику?

ИТ-специалист = фирма, которая реализует систему

5600

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 14 Марта 2007, 10:59:21 »

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

Лично я не очень понимаю твою упертость в бизнес-анализ, целеполагание и прочее.
Не моя это область деятельности. Не я должен сам себе целеполагать. ИМХО и бизнес-аналитик не должен целеполагать, вернее он должен целеполагать в рамках создаваемого решения, устраняющего проблему.
Какую проблему? Возникла у некой организации проблема - падение темпов производства и уменьшение прибыли. В ходе анализа этой проблемы выяснилось, что это происходит от несвоевременности принятия решения. А это в свою очередь связано с запаздыванием получения статистических данных, а запаздывание связано с тем, что информация во многом собирается хоть и системно, но во многом в ручную, часто одна и таже информация дублируется, требуется много времени на обработку информации. Стратеги от бизнеса решают - да проблему можно попытаться устранить вероятно улучшением информационного фактооборота. Вот и дальше идет целеполагание. Приглашается ИТ-специалист и с ним начинается работа. У этого ИТ-специалиста есть свой бизнес-аналитик, который с одной стороны понимает нужды бизнеса. с другой стороны умеет мыслить в категориях требований и т.п.

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

И ты мне теперь будешь утверждать, что твои theiiba имеют в виду именно анализ вообще бизнеса? Думаю ты ошибаешься, это будет веротяно консалтинг, аудит , что-то еще. Зачем бизнес-аналитку (эксперту бинеса) знать понимать что есть ИТ???

5601

Системный Анализ и Требования / Re: Источники требований, полнота требований, взаимосвязь с целями

« : 14 Марта 2007, 10:30:38 »

Вот, что я думаю по этому поводу.

Любая информационная система включает такие важные элементы как
информационное обеспечение
техническое обеспечение
математическое и программное обеспечение
организационное обеспечение
правовое обеспечение и т.п.

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

Система должна иметь документацию о внутреннем устройстве.  Любая система как элемент содержит такую составляющую как персонал. Соотвественно данная документация направлена на обеспечение нормальной работы персонала ИС.

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

5602

Бизнес-анализ и Целеполагание / Re: Пошаговый перевод избранных мест из BABOK

« : 14 Марта 2007, 10:16:20 »

Цель блаародная. Ссылка не туда.

Исправлено.

По организации процесса перевода мне думается надо бы:
а) убедиться во вменяемости и полезности материала
б) связаться с ЗЫИИБОЙ на тему прав и их взгляда на такую деятельность
в) организовать перевод на базе wiki-системы  с параллельным формированием словаря, желательно с возможностью генерации PDF/OpenDocument.
г) найти спонсора, чтобы работалось веселее
Если у bas'а хостинг совсем каюк, могу поставить wiki у себя.

а) - ты считаешь что материал не вменяемый? Мне он показался на первых парах очень неплохой.
б) - не понял
с) - согласен, можешь настроить систему у себя, а я сделаю на сайте url ссылку на материал. Какую будешь ставить систему? mediawiki требует рнр 5, docuwiki хранить материал в виде файлов. В общем прошу тебя организовать ресурс, провести ликбез. Инструмент от joomla для реализации вики контента мне не очень нравится.
г) - было бы не плохо

5603

Бизнес-анализ и Целеполагание / Пошаговый перевод избранных мест из BABOK

« : 13 Марта 2007, 20:32:53 »

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

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

1.4.2. Определение требований
Требование это:
1. Условие или способность, необходимая участнику для решение проблемы (задачи) и достижения цели.
2. Условие или способность, которому должна соотвествовать или которым должна обладать систему или системный компонент для удовлетворения соглашения, стандарта, спецификации или другим формально введенным (определенным) документам.
Требования служат основанием систем или системных компонентов. Требование может быть представлено как нечто необходимое или обязательное для исполнения; как свойство существенно важное для выполнения системой ее функций. Требования различаются в назначении и типах свойств. Они могут быть функциями, ограничениями или другими элементами, которые необходимы для удовлетворения потребностей предполагаемых участников. Требования могут быть описаны как условия или способности необходимые клиенту (пользователю) для решения проблемы (задачи) или достижения цели. Для прояснения целей (намерений) требования должны сопровождаться описателем (идентификатором типа требования): бизнес-требования, требования пользователя, функциональные требования.

5604

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

« : 12 Марта 2007, 22:23:38 »

Немного уточним цели проекта или исходную задачу проекта.

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


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

обеспечение проведения сессии
        выдача допуска на сессию
        подготовка и распространение экзаменационных ведомостей
        получение и обработка заполенных экзаменнационных ведомостей
        ввод данных по итогам сессии в систему "Студент"
        подведение итогов сессии, формирование статистики, вычисление общего семестрового и суммарного рейтинга, формирование на его основе списков стипендиатов
        выдача квитков, организация аппеляционных комиссии
        перевод студентов по итогом годичной сессии на следующий курс
        закрытие сессии
(Здесь мы видим тоже взаимодействие с системой Студент. Инофрмация накапливается и на 5 курсе является основой для печати вкладышей в диплом. Важным также является фиксация задолжников, грамотная работа по ним, учет квитков на экзамены (в случае неявки студента или в случае продления сессии))

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

Вопрос отстается открытым:
1. имеет ли смысл проводить в данном случае бизнес-моделирование.
2. ограничиться ли только изучением предметной области - т.е. построения концептуальной диаграммы классов
3. что будет являться в данном случае бизнес-моделированием - изучение внешних действующих лиц и их потребностей, или изучение потребностей внутренних действующих лиц - исполнителей этих самых процессов: работников деканата, декана.

К сожалению работники деканата и сам декан - не может поставить перед нами проблему. Она как бы есть, но ее все же нет:-))
Через студентку я пытался выяснить, может проблема в системе Студент? Ответ не понятны - работники деканата вроде говорят есть некоторые проблемы, создатели системы утверждают - проблемы в работниках, не хотят делать как все - мол все деканаты устраивает, только Ваш не устраивает.

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

5605

Системный Анализ и Требования / Re: BABOK - Руководство к своду знаний по Бизнес-анализу

« : 12 Марта 2007, 21:48:10 »

Я сегодня переводил оглавление BABOK'а для нашего файлохранилища, и с удивлением обнаружил, что он посвящён в основном работе с требованиями. Вот это оглавление:

Денис, а мне, кажется, тут нет противоречия. Правда, я могу и ошибаться. Однако бизнес-анализ сам по себе в нашем случае не нужен. Его потребность важна в преломлении будущего ИТ-проекта. В этом случае основной результат любого бизнес-анализа - формирование требований.

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

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

А вот самое интересное мы упускаем: это зарождение, выявление проблемы, анализ самой постановки задачи, проблемный анализ.

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

5606

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 12 Марта 2007, 10:10:48 »

Мне думается, выбирает очень сложный и громоздкий проект не целесообразно, Проблема обозримости! Кроме того в большом проекте быстро потеряешься сам и потеряешь к нему интерес.
С другой стороны малый проект тоже не так интересен.
Вообще проект следует выбирать настолько сложный, насколько он позволяет рассмотреть все характерные стороны проектирования и описания таких систем без излишних сложностей.

5607

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 12 Марта 2007, 10:07:11 »

а можете порекомендовать конкретные проекты к изучению?

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

5608

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

« : 10 Марта 2007, 17:04:47 »

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

Существуют множество различных определений системного анализа. Но так или иначе все они сводятся к одному: системный анализ - методология решения проблемы.
Вот что по этому поводу пишет в свойе книге "Системный анализв в управлении" Анфилатов и др.

"
В процессе создания информационных систем стремятся к наиболее полному и объективному представлению объекта автоматизации – описанию его внутренней структуры, объясняющей причинно-следственные (казуальные) законы функционирования и позволяющей предсказать, а, следовательно, управлять его поведением. Одним из условий автоматизации является представление объекта в виде сложной системы.
 
Существует несколько подходов к описанию сложных систем. Наиболее общим является теоретико-множественный подход, при котором система S представляет собой отношение S < X х Y, где Х и Y – это входные и выходные объекты. Предполагается, что задано семейство множеств Vi, где i е I (множество индексов) и система задается на Vi как некоторое собственное множество декартового произведения, все компоненты которого являются объектами системы. Такое определение ориентировано на исследование общих свойств системы и лежит в основе общей теории систем.

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

Применение системного анализа при построении ИС дает возможность выделить перечень и указать целесообразную последовательность выполнения взаимосвязанных задач, позволяющих не упустить из рассмотрения важные стороны и связи изучаемого объекта автоматизации. Иногда говорят, что системный анализ – это методика улучшающего вмешательства в проблемную ситуацию.

В состав задач системного анализа в процессе создания ИС входят задачи декомпозиции, анализа и синтеза.
Задачи декомпозиции   - представление системы в виде подсистем, которые состоят из более мелких элементов. Часто задачу декомпозиции рассматривают как составную часть анализа.
Задачи анализа – нахождение различного рода свойств системы и среды. Цель анализа – определение закона преобразования информации, задающего поведение системы. В этом случае говорят об агрегации (композиции) системы в один элемент (“черный ящик”).
Задача синтеза системы противоположна задаче анализа. Необходимо по описанию закона преобразования построить систему, фактически выполняющую это преобразование по определенному алгоритму. При этом предварительно определяется класс элементов, из которых состоит искомая система, реализующая алгоритм функционирования.
"

Этапы использования системного анализа и его структуру можно описать так

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

Основные задачи системного анализа могут быть представлены в виде трехуровневого дерева функций.
На этапе декомпозиции осуществляется:
1.   Определение и декомпозиция общей цели и основной функции для ограничения траекторий пространства состояний системы или области допустимых ситуаций. Декомпозиция проводится путём построения дерева целей и функций.
2.   Выделение системы из среды по критерию участия каждого рассматриваемого элемента в процессе, приводящем к результату (результат определяется целью).
3.      Описание воздействующих факторов
4.      Описание тенденции развития неопределенностей
5.      Описание системы как черный ящик
6.      Функциоанльная композиционная и структурная декомпозиция.

На этапе анализа осуществляется:
1.   Функционально-структурный анализ. Он включает уточнение состава и законов функционирования элементов, алгоритмов функционирования и взаимовлияния подсистем, разделение управляемых и неуправляемых характеристик, задание пространства состояний Z, задание параметрического пространства T, анализ целостности системы, формирование требований системы.
2.   Морфологический анализ заключается в анализе взаимосвязи компонентов.
3.   Генетический анализ – анализ предыстории, развития ситуации, тенденций, причин их вызывающих, прогнозирование.
4.   Анализ аналогов.
5.   Анализ эффективности включает выбор шкалы измерения, формирование показателей эффективности, критериев эффективности, оценивание и анализ полученных оценок.
6.   Формирование требований к создаваемой системе включает выбор критериев оценки и ограничений.

На этапе синтеза:
1.   Разработка модели – выбор математического аппарата, моделирование, оценка модели по критериям адекватности, простоты, соответствия и т. д.
2.   Синтез альтернативных структур системы, снимающих проблемы.
3.   Синтез параметров системы, снимающих проблемы.
4.   Оценивание вариантов синтезирования систем, обоснование схемы оценивания, реализация модели, проведение эксперимента, обработка результатов, анализ результатов и выбор наилучшего варианта. Оценка степени снятия проблемы проводится при завершении системного анализа.

"

Можно сказать, что представленное описание направлено скорее не технические или организационно-технические системы., системы управляемые.

Ясно, что часть вопросов представленных здесь, не столь актуальны, другие вполне применимы.

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

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

Вопрос - можно ли рассматривать отдельную сторону такой системы независимо, если можно, то как это определить?

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

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

Цель научного изыскания - определить возможность такого процесса или его невозможность

Цель инженерной практики - определить наименее затратный путь достижения ситуации Б.

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

Какой путь имеет смысл избрать нам с вами? Второй, очевидно, сильно зависит от задачи. Первый, вероятно, мало кому интересен?

PS. Кстати давно запущена, но никем неоткомментирована задача по деканату. Может есть желающие обратить на нее внимание и использовать в качестве примера?

5609

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

« : 10 Марта 2007, 11:55:33 »

Не совсем понятно почему отождествляется IDEF0 и activity диаграмма UML. Тогда уж IDEF3 нужно сравнивать. Да и я как-то с трудом себе предстваляю как на IDEF0 можно увидеть переплетение маршрутов ...

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

5610

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

« : 09 Марта 2007, 21:39:37 »

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

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

Вот еще пример. У нас в вузе эксплуатируется система "Студент". БД реализования на mysql, приложение на Access. Исходная реализация предложена человеком далеким от программирования как такового в то время, скорее большим любителем. Однако не плохо. На смену ему пришел человек, который в прошлом был любителем basic. С большим воодушевлением он стал дорабатывать систему, адаптировать ее и совершенствовать. Сейчас во все деканат система вндерена и признана ректором эталоном и приказом объявлена единственно возможной.
В личной беседе я пытался узнать существует ли какая-то общая концепция, структура системы, и т.п. Оказалось нет. Я намекнул на некоторый риск такой системы - система авторская и поддерживается и развивается только при наличии автора.
Предложил услуги реинжиниринга, составления описания системы. Получил отказ - всем система нравится, она внедрена, переделки не требует, возможно требует дополнительного функционала.
В данном случае - очень показательно - инициирование процесса переработки должно идти сверху, а не снизу. Правило уяснилось, "нечего вперед батьки в пекло лезьти".

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

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