Система как объект анализа и проектирования

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

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

Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики», при этом такое разби­ение должно удовлетворять следующим критериям:

каждый «черный ящик» должен реализовывать единственную функцию системы;

функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации;

связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы

связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.

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

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

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

разбиение системы на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6—7);

ограниченный контекст, включающий лишь существенные на каждом уровне детали;

использование строгих формальных правил записи;

последовательное приближение к конечному результату.

Все наиболее распространенные методы структурного подхо­да базируются на ряде общих принципов. Принципами структурного подхо­да являются (слайд 4):

принцип «разделяй и властвуй» — принцип решения трудных проблем путем разбиения их на множество меньших неза­висимых задач, легких для понимания и решения;

принцип иерархического упорядочения — принцип организа­ции составных частей системы в иерархические древовид­ные структуры с добавлением новых деталей на каждом уровне.

принцип абстрагирования — выделение существенных аспек­тов системы и отвлечение от несущественных;

принцип формализации – применение строго методического подхода к решению проблемы;

принцип упрятывания – упрятывание несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию;

принцип концептуальной общности – следование единой философии на всех этапах ЖЦ (структурный анализ – структурное проектирование – структурное программирование – структурное тестирование);

принцип полноты – контроль за присутствием лишних элементов

принцип непротиворечивости — обоснованность и согласованность элементов системы;

принцип логической независимости – концентрация внимания на логическом проектировании для обеспечения независимости от физического проектирования;

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

принцип структурирования данных — данные должны быть структурированы и иерархически организованы;

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

В структурном анализе основным методом разбиения на уровни абстракции является функциональная декомпозиция, зак­лючающаяся в декомпозиции (разбиении) системы на функцио­нальные подсистемы, которые, в свою очередь, делятся на под­функции, те — на задачи и так далее до конкретных процедур. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе цело­стность теряется, возникают проблемы при описании информа­ционного взаимодействия отдельных компонентов.

Определим ключевые понятия структурного анализа (слайд 5) .

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

Функция – совокупность операций, сгруппированных по определенному признаку.

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

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

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

В структурном анализе и проектировании используются раз­личные модели, описывающие:

функции, которые система должна выполнять;

процессы, обеспечивающие выполнение указанных функций;

данные, необходимые при выполнении функций, и отношения между этими данными;

организационные структуры, обеспечивающие выполнение функций;

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

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

Модель – это абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

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

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

сохранение ключевых соотношений между разными частями;

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

адекватность действительным свойствам оригинала (степень достоверности).

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

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

Средства — аппаратное и программное обеспечение, реализующее выбранную методологию, в том числе построение соответствующих моделей с принятой для них нотацией.

Среди многообразия средств, предусмотренных для проведения структурного анализа, наиболее часто и эффективно применяются (слайд 6):

DFD (Data Flow Diagrams) — диаграммы потоков данных в нотациях Гейна-Сарсона, Йордона-Де Марко и других, обеспечивающие требования анализа и функционального проектирования информационных систем;

STD (State Transition Diagrams) — диаграммы перехода состояний, основанные на расширениях Хартли и Уорда-Меллора для проектирования систем реального времени;

ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь» в нотациях Чена и Баркера;

структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

FDD (Functional Decomposition Diagrams) — диаграммы функциональной декомпозиции;

SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования;

семейство IDEF (Integration Definition for Function Modeling):

Современные структурные методологии анализа и проектирования классифицируются по следующим признакам:

по отношению к школам — Software Еngineering (SE) и Information Engineering (IЕ);

по порядку построения модели — процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;

по типу целевых систем — для систем реального времени (СРВ) и для информационных систем (ИС).

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

IE более новая дисциплина. Она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE более узкая дисциплина, чем SE, т.к. IE используется только для по­строения информационных систем, а SE — для всех типов систем.

Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологи­ях. При этом важен порядок построения модели. Традиционный проце­дурно-ориентированный подход регламентирует первичность проектиро­вания функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функцио­нальные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными — структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, от­личается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных.

Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реа­гирование на эти события во времени — основная и первоочередная функ­ция таких систем. Главные отличия информационных систем от систем реального времени приведены на слайде 7, средствами поддержки этих особенностей и различаются соответствующие структурные методологии.

На слайде 8 классифицированы наиболее часто используемые методо­логии в соответствии с вышеперечисленными признаками

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

Необходимо отметить что для проектирования систем реального времени используются специальные типы структурных диаграмм: диа­граммы потоков управления, диаграммы переходов состояний, контекст­ные графы, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные ме­тодологии проектирования систем реального времени (в частности, мето­дологии Хатли и Уорда-Меллора) базируются на перечисленных методо­логиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.

источник

Что такое системные исследования и системное проектирование, развитие их в технике, возможности и недостатки социального проектирования)

Системный метод исследования представляет собой наиболее общий и широкий способ исследования как реального мира, так и его концептуального отображения в познании. Сама идея о том, что окружающий мир есть единое целое, где вещи и явления связаны друг с другом и образуют отношения, уходит в глубокую древность, она выступает у Фалеса, Демокрита и Гераклита, а затем находит развитие у Сократа, Платона и Аристотеля. Однако этот общий взгляд на природу был недостаточен, в этой связи и возникла необходимость в изучении отдельных процессов природы, конкретных ее явлений, в результате чего появились отдельные науки. Такой переход от изучения мира как единого целого к исследованию отдельных его частей положил начало интеграционным процессам в научном познании.

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

Термин «проектирование» можно определить как процесс создания прототипа, прообраза предполагаемого или возможного объекта или состоя­ния.

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

Выделяют три основных раздела проектирования: а) классическое инженерное; б) системотехническое; в) социотехническое (гуманитарное).

Системное проектирование включает в себя: а) этапы разработки системы; б) описание последовательности фаз и операций системотехнической деятельности; в) анализ проектирования с точки зрения кооперации работ и специалистов.

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

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

Функциональные модели могут быть получены тремя способами:

1. Прототип системы дается в виде блок-схемы.

2. В виде последовательности инструкций.

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

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

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

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

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

Третий раздел системного проектирования – кооперация работ и специалистов в системотехнике.

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

а) как штабная группа при руководителе проекта (обеспечивает планы и ведение программы);

б) как линейная группа во главе с начальником проекта, который является ее непосредственным руководителем (функционирует по всем частям проектной организации);

в) как расчлененная группа, состоящая из руководителей групп оборудования, которые встречаются для выполнения задач проектирования системы в целом;

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

д) как отдельное проектное бюро.

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

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

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

Социотехническое проектирование существенно отличается не только от традиционной инженерной, но и системотехнической деятельности. Социотехническое проектирование выходит за пределы традиционной схемы «наука – инженер – производство» и замыкается на самые разнообразные виды социальной практики (например, на обучение, обслуживание и т.д.), где классическая инженерная установка перестает действовать, а иногда имеет и отрицательное значение.

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

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

– социальный объект — противоречив;

– у социального объекта существует многовекторность развития;

– невозможно описать социальный объект конечным числом терминов любой социальной теории (принципиальная неформализуемость);

– на социальный объект влияет много объективных факторов;

– существует множество субъективных факторов, влияющих на социальный объект, например, исследователь может по-разному оценить зре­лость развития социального объекта и т.п.

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

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

1) человек как общественный индивид и субъект историчес­кого процесса и социальных отношений с егопотребностями, интересами, ценностными ориентациями, установками, соци­альным статусом, престижем, ролями в системе отношений;

2) различные элементы и подсистемы социальной структуры общества (трудовые коллективы, регионы, социальные груп­пы и т. п.);

3) разнообразные общественные отношения (поли­тические, идеологические, управленческие, эстетические, нравственные, межличностные и т. п.);

Анализ объекта и субъекта проектирования позволяет создать «информационный массив», который является главным источником социального проектирования, среди которых – материалы социологических ис­следований, интервьюирование, анализ периодической печа­ти, статистические данные и т. п.

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

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

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

Проект будущих возможных состояний социальных сис­тем, процессов и явлений должен соответствовать следую­щим условиям его разработки:

– он должен быть создан на на­учной основе;

– не противоречить нравственным нормам;

– выра­жать общепринятые социальные ценности;

– выражать социальный заказ;

– быть эффективным с точки зрения реа­лизации;

– не содержать противоречий;

– должен быть предназначен для реализации.

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: На стипендию можно купить что-нибудь, но не больше. 9090 — | 7271 — или читать все.

источник

Козьма Прутков

1.1. Системный анализ как метод

Системный анализ представляет собой совокупность методов и средств, позволяющих исследовать свойства, структуру и функции объектов, явлений или процессов в целом, представив их в качестве систем со всеми сложными межэлементными связями[1].Нетрудно увидеть, что приведенное определение является, по существу, кругом: системный анализ = анализ систем.

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

Не вдаваясь в философские основания такой ситуации, ограничимся имеющимися «рабочими» определениями. Недаром в классификации специальностей, по которым присваиваются ученые степени, Высшая Аттестационная Комиссия не включила в классификатор чистый «Системный анализ», а сопроводила этот термин указанием, в какой области исследований проводился системный анализ. Поэтому системный анализ следует рассматривать как деятельность по исследованию систем в некоторой определенной области, подчиняющейся ряду принципов [1–5]:

1. Выделение некоторого объекта/явления как системы: целостность представления объекта/явления; определение целенаправленности/назначения объекта; определение интегративных свойств объекта; выявление структуры и функций объекта.

2. Формирование модели системы.

3. Исследование модели системы с целью оценки ее свойств и прогнозирования ее поведения в будущем.

Обычно системный анализ применяется к объекту/явлению, выделенному аналитиком из окружающего мира как система.

Особенность применения методов системного анализа к объекту «Информационная система» (ИС) заключается в том, что информационная система при этом может выступать как реально существующий объект или проектируемый объект

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

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

1.2. Информационная система как «система» с точки зрения системного анализа

1.2.1. Целостность представления ИС

Анализ неудач проектов разработки и внедрения информационных систем показывает, что эти неудачи часто связаны с отсутствием целостного понимания информационных систем и процесса их разработки и внедрения. Обычно инженеры – участники процесса проектирования бывают удивлены, когда услышат, что их представление об информационной системе не соответствует целостному представлению о ней. Эта ситуация связана с тем, что в проектирование и внедрение ИС вовлечены специалисты разных специальностей. Даже обладая высокой квалификацией в своей области (программное обеспечение, информационное обеспечение, технические средства и сети передачи данных), они уделяют недостаточно внимания целостному представлению об ИС. Что часто приводит к появлению системных ошибок, которые проявляются только на этапе опытной эксплуатации ИС. Целостное представление об ИС может быть сформировано только там, где специалисты по продажам, проектировщики и разработчики работают как одна команда и регулярно обмениваются информацией о ходе проекта. Такие команды формируются только в тех организациях, в которых процессы продаж, проектирования и внедрения управляются наличием и неукоснительным исполнением Порядков/Регламентов этих процессов.

1.2.2. Определение целенаправленности/назначения проектирования информационной системыС определением целей в проектировании информационных систем вообще дело обстоит неважно. Часто при анализе технических заданий можно обнаружить утверждения, что целью создания информационной системы является «создание информационной системы».

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

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

1.2.3. Определение интегративных свойств информационной системы

Под интегративными свойствами в системном анализепонимаются свойства, присущие системе в целом, но не присущие ее элементам в отдельности [1,2]. Обычно функциональные требования, содержащиеся в ТЗ (Раздел «Общие требования к системе») определяют интегративные свойства информационной системы.

1.2.4. Выявление структуры и функций информационной системы

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

Накопленный опыт создания ИС отразился в структуре нормативных документов по проектированию ИС. Наиболее полезным является ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы». Несмотря на то, что с момента его выхода прошло более 20 лет, этот документ актуален и сегодня. ГОСТ четко сформулировал структуру ИС. Однако с точки зрения системного анализа, необходимо более широкое понимание структуры ИС.

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

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

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

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

Рис. 1. Стратифицированное представление ИС

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

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

Требования со стороны Страты обработки информации и управления включают требования к техническому обеспечению ИС.

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

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

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

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

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

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

Следует заметить, что применение методов системного анализа позволило получить существенные количественные результаты, только в тех случаях, когда использование этих методов основано на выборе соответствующей математической модели. К сожалению, попытки применения методов системного анализа в областях, в которых отсутствуют разработанные математические модели, приводят только к призывам: «Ребята, надо думать системно!».

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

1.2.5. Модели, применяемые для систем, которые не описываются математическими моделями

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

При разработке таких моделей пришлось согласиться с рядом ограничений:

1. В настоящее время не представляется возможным описать ИС единой математической моделью.

2. В отличие от математических моделей моделирование ИС должно использовать некоторые элементы описания ИС на естественном языке. Такие модели принято называть семантическими моделями, в связи с тем, что смысл элементов модели определяется их именами.

3. Если и возможно моделирование ИС, то только совокупностью связанных моделей.

В связи приведенными ограничениями возникла необходимость общего определения понятия модели. Выяснилось, что под моделью M целесообразно понимать непустую совокупность некоторого множества элементов S (базовое множество модели) и заданных на этих элементах свойств A (множество атрибутов) и заданных на этих объектах отношений R (множество отношений). Здесь Aij –некоторое i-ое свойство элемента sj. Значения свойства Aij элемента sj задаются на множествах, именуемых доменами (Dij)

В соответствии с поставленной задачей моделирования были разработаны среды моделирования, обеспечивающие разработку и поддержку взаимосвязанных моделей (Integration Definition — IDEF, BPWIN, Oracle BPA, ARIS Sheer). Наиболее современными средами являются BPA, ARIS [11,12]. Далее приводятся примеры моделей, выполненные в средах Oracle BPA, или ARIS Sheer.

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

источник

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

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

Рассматривая архитектуру как систему, Бархин выделяет три подсистемы второго уровня:

Обнаружение связи объекта и окружения, принятие проектных решений по экологическим характеристикам.

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

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

o Объемно-пространственная (определяет трехмерную координацию компонентов);

o Конструктивно-техническая и экономическая (определяет решения пространственной структуры конструктивно-материальными средствами с учетом требований устойчивости, прочности, долговечности и экономичности объекта);

o Эстетическая (содержит средства построения выразительной художественной формы).

Обучаясь проектированию с помощью данного метода, «студент под руководством педагога рассматривает выделенные подсистемы в тех отношениях, которыми они связаны между собой, их взаимодействие в конкретном объекте, вскрывает противоречивость требований, оценивает их, синтезирует и подчиняет построение руководящей идее». Разрабатывая структурообразующие подсистемы, обучающийся выбирает рациональные непротиворечивые решения согласно следующей схеме: анализ возможных решений, оценка существующих альтернатив и предварительное видение результатов. В итоге при взаимодействии всех подсистем архитектор получает композицию проектируемого объекта как организованную целостность.

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

Бархин, ориентируясь на метод «предположений и опровержений» Карла Поппера, описывает творческий процесс разрешения проблемы как определенный цикл взаимодействия проектной модели и студента:

1. Предварительный анализ цели и постановка проблемы.

2. Выбор способа решения проблемы и предвидение результатов.

3. Обнаружение возможных противоречий, мешающих решению проблемы, и дальнейшее их устранение.

4. Конечная проверка результатов решения.

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

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

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

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

§ Проблема плотности застройки

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

§ Проблема взаимодействия объекта с внешней средой

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

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

источник

75. Системный анализ в проектировании

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

Технология проектирования определяется как совокупность трех составляющих:

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

Рис. 1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

технология должна поддерживать полный ЖЦ ПО; технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т. е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций; технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам; технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования); технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств — в подразделе 5.7.

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

Стандарт проектирования должен устанавливать:

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

Стандарт оформления проектной документации должен устанавливать:

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

Стандарт интерфейса пользователя должен устанавливать:

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

Методики анализа и проектирования при построении корпоративных информационных систем (Часть 1)

Этап анализа и проектирования является определяющим при построении корпоративных информационных систем (КИС). В статье представлены современные методики анализа и проектирования при построении корпоративных информационных систем.

Еще в 70-е годы XX века были выделены этапы процесса разработки информационных систем — системный анализ и проектирование, разработка, кодирование, тестирование, внедрение. Если каждая последующая стадия вытекала из предыдущей, то говорили о каскадной модели (рис. 1).

Рис. 1. Каскадная модель разработки информационных систем

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

Рис. 2. Итерационная модель разработки информационных систем.

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

В последовательности выработки требований заказчика по этапу системного анализа и проектирования выделяют три фазы [3]:

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

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

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

С движением по этапам процесса разработки, возрастает стоимость ошибки. Это еще раз подчеркивает необходимость проведения обследования — что снижает вероятность принятия неправильных проектных решений.

В [1] определены особенности, характерные для крупных проектов КИС. Это:

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

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

Особенности а),б),д) приводят к необходимости использования единой методики и средств системного анализа и проектирования, понятной и удобной на всех стадиях создания информационной системы и для всех участников проекта. Именно такая методика является объектом анализа данной статьи.

КИС как объект проектирования

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

Обязательным свойством КИС является ее системность, то есть понимание КИС как объекта, имеющего новое системное свойство, которым не обладают отдельные компоненты.

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

Под бизнес-процессом будем понимать цепочку работ, которые заканчиваются значимым для клиента и/или организации результатом (рис. 3).

Рис. 3. Схематичное изображение бизнес-процесса.

Компоненты КИС предназначены для автоматизации большей части бизнес-процессов, которые в любой организации можно разделить на две группы (рис. 4):

— основные бизнес-процессы (бизнес-процессы, которые дают результат для клиента);
— вспомогательные бизнес-процессы (бизнес-процессы, дающие результат для основного бизнес-процесса или организации).

Рис. 4. Группы бизнес-процессов организации.

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

Вспомогательные же бизнес-процессы практически идентичны на верхнем уровне абстракции во всех организациях (например, бухгалтерия, логистика, склад, кадры и т. п.), а существующие различия проявляются на нижних уровнях детализации. Такие бизнес-процессы очень хорошо изучены и формализованы. Существует большое количество систем для их автоматизации — от небольших узконаправленных систем (1С-бухгалтерия, БОСС-Кадровик и др.), до комплексных систем класса ERP (SAP/R3, Oracle Applications и др.).

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

Методы и средства проектирования КИС

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

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

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

В структурном анализе используются такие методики, как:

¨ DFD (Data Flow Diagrams) — диаграммы потоков данных;
¨ IDEF0 (Icam DEFinition) — функциональные диаграммы.

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

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

Применение методов и средств проектирования КИС

Поскольку в построении модели предметной области кроме аналитиков на начальной стадии принимают участие эксперты предметной области (рис. 5), к применяемым моделям выдвигаются следующие требования:

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

Рис. 5. Участники процесса разработки модели предметной области.

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

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

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

Рис. 6. Структура модели предметной области.

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

В конце 90-х годов XX века был разработан Унифицированный язык моделирования (Unified Modeling Language, UML), который является объектно-ориентированным графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению [5].

Несмотря на свои достоинства, UML всего лишь язык и является одной из составляющих процесса разработки программного обеспечения. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования и является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Неоспоримой заслугой UML является введение понятия прецедента использования. «Экземпляр юзкейса (сценарий) это последовательность действий, выполняемых в системе, которые позволяют получить результат, наблюдаемый для актера этой системы, юзкейс определяется как совокупность всех своих сценариев» [6]. Однако, UML, вводя это понятие, не дает четких способов применения юзкейсов. Получается, что юзкейсы, интуитивно понятны аналитикам, но их применение в похожих ситуациях зачастую приводит к различным результатам.

В 1998 году была издана монография А. Кобурна «Эффективное написание юзкейсов» [6]. Реакция аудитории на нее была строго положительной и до сих пор в рейтингах электронных книжных магазинов эта работа получает отличные оценки.

Причина успеха объясняется тем, что была предложена строгая и логичная система применения юзкейсов; сформулировано новое определение юзкейса, предложена структура его текстового описания (спецификации). «Юзкейс определяет соглашение между заинтересованными лицами (стейкхолдерами — stakeholder) относительно поведения системы. Юзкейс описывает поведение системы в ответ на запрос со стороны одного из стейкхолдеров, который называется основным (primary) актером. Основой актер инициирует запрос для осуществления некоторой цели; система отвечает, защищая интересы своих стейкхолдеров. При этом могут реализоваться различные сценарии в зависимости от конкретного запроса и условий, в которых он был выполнен. Юзкейс объединяет все такие сценарии. Причем, написанный по структуре А. Кобурна юзкейс содержит в себе информацию, которую графически можно изобразить только на нескольких диаграммах, что сразу усложняет усвоение информации.

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

Необходимо обратить внимание на ключевую мысль, которая лейтмотивом проходит через всю книгу: «Написание юзкейсов фундаментально означает написание этюдов в прозе (в оригинале essays in prose) со всеми трудностями, которые присущи написанию хороших текстов в общем случае»[6].

Диаграммы юзкейсов языка UML при этом могут использоваться в качестве:

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

Пример использования методики анализа и проектирования А. Кобурна

В качестве примера рассмотрим упрощенный бизнес-процесс «Контроль исполнения планов», в той или иной форме встречающийся во многих организациях.

Неформализованное описание примера

Будем считать, что организация состоит из центрального офиса, выполняющего руководящие и координирующие функции, и территориально удаленных филиалов, исполняющих задания центра (рис. 7).

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

В течение года филиалы исполняют план, отчитываются по фактическим срокам и объемам выполненных работ перед центром.

Центральный офис в течение года контролирует исполнение плана филиалами и, при необходимости корректирует план.

Рис. 7. Моделируемая организация.

Формализованное описание примера

В данном разделе приведено формализованное описание процессов «как есть» примера. Бизнес-процессы описаны спецификациями юзкейсов.

Функциональная схема примера

Рис. 8. Структура юзкейсов примера.

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

Формировать годовой план
Context of use

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

Scope
Бизнес-процесс «Контроль исполнения планов».
Level
User Goal.
Primary actor
Центральный офис.
Stakeholders & Interests

Сформировать годовой план филиалов, с учетом собственного видения ситуации

Отразить в плане свои предложения

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

6а. Центральный офис не утверждает корректировки филиалов в шаблоне плана.
6а1. Центральный офис корректирует шаблон плана. Переход на шаг 2.

Исполнять годовой план
Context of use

Филиал исполняет годовой план, возможно внесение предложений на изменение плана. Центральный офис принимает или отклоняет предложения. Филиал ежемесячно отчитывается об исполнении плана.

Scope
Бизнес-процесс «Контроль исполнения планов».

Получить данные о фактическом исполнении плана
Получить все необходимые данные для рассмотрения текущих поправок плана

Отчитаться по фактическому исполнению плана
Отразить в плане текущие поправки

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

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

Контролировать исполнение годового плана
Context of use

Центральный офис сравнивает план и факт и может корректировать дальнейший план в случае расхождений. Отчетный месяц закрывается.

Scope
Бизнес-процесс «Контроль исполнения планов».

Primary actor
Центральный офис.
Stakeholders & Interests

Сделать вывод о ходе исполнения плана
Правильно спланировать следующие месяцы

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

Центральный офис ежемесячно сравнивает плановые и фактические показатели плана. Центральный офис делает заключение о соответствии плана и факта. Центральный офис закрывает отчетный месяц (переводит его в состояние «только чтение»).

2а. Центральный офис делает заключение о несоответствии плана и факта.
2а1. Центральный офис вносит коррективы в план на следующие месяцы.
2а2. Центральный офис отправляет откорректированный план в Филиал.
2а3. Филиал получает откорректированный план из Центрального офиса. Переход на шаг 3.

Необходимые пояснения к примеру

На данном примере можно представить, как строится текстовое описание юзкейсов. Структура шаблона полноформатного (fully dressed) юзкейса в зависимости от потребностей разработчиков может сокращаться, или наоборот расширяться. В примере приведены не полноформатные юзкейсы.

Раздел Context of Use применяется для краткого описания юзкейса, он вводит читателя в содержание юзкейса и формирует его представление о нем.

Раздел Scope применяется для позиционирования юзкейса — бизнес юзкейс или же юзкейс информационной системы.

Раздел Level показывает, на каком уровне — суммарном (summary), цели пользователя (user goal) или субфункциональном (subfunction) — написан юзкейс.

Основным и наиболее значимым разделом юзкейса по А. Кобурну является раздел Stakeholders & Interests. Его проработке необходимо уделять самое пристальное внимание. При написании данного раздела сначала надо перечислить всех стейкхолдеров (заинтересованных лиц), назвать их интересы по отношению к операциям юзкейса (при этом будут выделены противоречия в интересах стейкхолдеров, которые должны быть учтены и не забыты при проектировании системы). Данный раздел позволяет уже на этапе описания бизнес-процессов зафиксировать интересы стейкхолдеров к юзкейсу. Интерес существует объективно, стейкхолдер может и не догадываться о нем. Цель данного раздела — породить у экспертов предметной области дискуссии, в ходе которых будут вскрыты и зафиксированы столкновения интересов. Это тем более важно, поскольку при переходе от бизнес-сценариев к проекту системы происходит разрыв интересов — ведь люди работают с системой, а не напрямую друг с другом. Данный раздел, не позволяет забыть об интересах стейкхолдеров, заставляет учесть их в системе — тогда система действительно будет работать для всех и удовлетворять всех.

Каждый юзкейс включает в себя совокупность сценариев, одни из которых заканчиваются успешно (достижением цели), другие завершаются неуспешно (в процессе их выполнения цель не может быть достигнута). Каждый сценарий или фрагмент сценария включает условие, при выполнении которого он начинает выполняться до своего успешного или неуспешного завершения. Среди всех сценариев юзкейса рекомендуется выделить один наиболее типичный сценарий — Главный Успешный Сценарий (раздел Main Success Scenario), в котором достигается цель основного актера и, кроме того, удовлетворяются все интересы стейкхолдеров. Главный успешный сценарий является безальтернативным сценарием — в нем пишутся действия, прямо приводящие к достижению цели. Тогда, все другие сценарии описываются как расширения основного успешного сценария (раздел Extensions). Главный успешный сценарий и его расширения базируются на одной и той же структуре, которая включает следующие компоненты.

Цель, которую надо достигнуть. Для главного успешного сценария это в точности имя юзкейса. Для сценариев расширения цель состоит в том, чтобы либо завершить юзкейс, либо после обработки условия продолжить выполнение основного успешного сценария; Совокупность шагов, определяющих действия в сценарии. Они удовлетворяют одним и тем же правилам для каждого фрагмента каждого сценария; Условие завершения. Цель достигается в конце основного успешного сценария. Фрагмент сценария может завершиться как успешно, так и неуспешно; Возможный набор расширений, записанных как фрагменты сценариев. Расширения основного успешного сценария размещаются в разделе Extensions. Расширения к расширениям размещаются непосредственно внутри тела основного расширения.

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

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

В Главном Успешном Сценарии (Main Success Scenario) шаги перенумеровываются естественным образом.

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

Другие возможности использования методики А. Кобурна

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

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

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

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

Методика опробована на практике и в настоящее время применяется фирмой «Кворум».

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

и АСУ образования и науки

Предопределяющим фактором в достижении высокой эффективности

проектируемых комплексных ИС и АСУ дидактического, научного и управленческого

назначения является опора на системный подход при решении задач анализа,

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

первостепенное значение в комплексном информационном обслуживании научных

исследований, творчества, обучения и управленческой деятельности, так как

органически соединяет анализ и синтез. Системный подход предполагает рассмотрение

сложного объекта как системы, то есть в виде совокупности конечного множества

элементов, связанных в единое целое структурно как части другой более широкой

системы и в то же время как целостной системы, состоящей из подсистем, которые

могут изучаться в качестве самостоятельных объектов. Так, например,

информационные системы поддержки отдельных учебных дисциплин могут

одновременно представлять подсистемы информационного обеспечения той или иной

специальности высшей школы на весь период обучения, а ИС специальностей, в свою

очередь, входить в комплексную ИС всего многопрофильного процесса обучения в

вузе и\или в единую межвузовскую отраслевую ИС по данной специальности. Точно

также отдельные частные направления творчества и научных исследований

поддерживаются на системном и подсистемном уровнях по отношению к

многоплановым исследованиям и проектам учреждения, ведомства, отрасли, региона и

Характерные признаки сложной системы – многомерность, многообразие и

переменность структуры, тесная взаимосвязь элементов, изменение их связей и

состояния. Именно эти характеристики как нельзя более относятся к образованию,

Одним из важнейших принципов системного подхода является исследование

элементов сложной системы. Только на основе u1076 детального качественного изучения

элементов системы возможен достоверный синтез и познание интегральных

закономерностей системы как целого. Такой анализ позволяет выявить противоречия в

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

рациональные способы их разрешения на каждом этапе развития.

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

проблем на основе системного подхода и рассмотрения объекта исследования в виде

системы. Системный анализ предусматривает использование наряду с

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

– вместе с выявлением и всесторонним анализом проблем разрабатываются

конкретные меры по их решению.

Логика системного анализа, с одной стороны предусматривает структуризацию

каждой проблемы, разбивку ее на подпроблемы, которые требуют особого подхода

(вследствие специфичности условий и факторов их разрешения) и имеют частные

оптимальные решения; с другой стороны, предопределяет целостность решения

проблемы, что предполагает подчинение частных решений общей цели ее разрешения.

Такой подход подразумевает: определение целей функционирования и развития

данной системы, анализ уровней ее иерархии и выделение отдельных подсистем,

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

разрешимости, формирование альтернативных разрешений проблем на основе анализа

и использования факторов и усилий.

Применительно к образовательным технологиям в ходе системного анализа

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

накоплении знаний, умений и навыков учащимися в процессе реализации комплекса

работ, мер, усилий по овладению учебным материалом и его творческой компонентой

в результате пошагового обучения и творчества (от темы к теме, от задачи к задаче) в

целостной подсистеме единой информсреде данной учебной дисциплины в ее

взаимосвязях с другими учебными u1076 дисциплинами и учебно-творческими задачами

различного уровня вплоть до выпускной итоговой творческой отчетной работы

(дипломного проекта для студентов вузов и техникумов, выпускной творческой работы

в учреждениях дополнительного образования, диссертации в аспирантуре и

докторантуре и т. п.). При этом информсреда образования и науки равно как и средства

ее поддержки (ИС, АСУ) не являются застывшим явлением, а наоборот, непрерывно

расширяются, развиваются и совершенствуются. Это обусловлено прежде всего тем,

что в практике работ и на основании специально проводимого системного анализа

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

определяются и оцениваются альтернативные пути их разрешения. При этом нужно

руководствоваться следующими принципами:

• рассматривать проблемы во взаимосвязи;

• учитывать целевую ориентацию их разрешения;

• исходить из возможности решения каждой проблемы различными путями;

• использовать однотипный подход к исследованию групп проблем, объединенных

по определенным признакам;

• учитывать ближайшие и более отдаленные профессионально-значимые,

экономические и социальные последствия разрешения важнейших проблем;

• исходить из понимания четкой и постоянно укрепляющейся связи образования,

науки, культуры и социологии, а также возрастании роли личности каждого

участника образовательных и научных процессов в их реализации;

• видеть в информатизации всех процессов и явлений в образовании и науке

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

эффективность информатизации опирается исключительно на эффективное

создание и применение современных высокопродуктивных ИС и АСУ,

функционирующих в мировом информационном Интернет-пространстве с

широким использованием современных Интернет\Экстранет/Интранет-технологий.

источник